From jiangyuanlong@huawei.com Tue May 1 19:09: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 AE0B421E80A9 for ; Tue, 1 May 2012 19:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.132, 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 ndpTpa3n5wkc for ; Tue, 1 May 2012 19:09:38 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5F921E8013 for ; Tue, 1 May 2012 19:09:38 -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 AFT14278; Tue, 01 May 2012 22:09:38 -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, 1 May 2012 19:06:51 -0700 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 1 May 2012 19:06:55 -0700 Received: from SZXEML508-MBX.china.huawei.com ([169.254.5.215]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0323.003; Wed, 2 May 2012 10:06:44 +0800 From: Jiangyuanlong To: Daniel Cohn , "Fedyk, Donald (Don)" , "Henderickx, Wim (Wim)" , Lucy yong , "josh.rogers@twcable.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: AQHNI1NEA18PKDoBDEy6zAcXiVu2LpasuNMAgAYGiYCAAAzygIAAAjQAgAAAAYCAAASFAIAAAOoAgAAYGACAAAPTgIACzjKA Date: Wed, 2 May 2012 02:06:43 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA51A54@SZXEML508-MBX.china.huawei.com> References: <44F4E579A764584EA9BDFD07D0CA08130777C912@tlvmail1> <14C7F4F06DB5814AB0DE29716C4F6D67023ECB0FE3@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <44F4E579A764584EA9BDFD07D0CA08130777C944@tlvmail1> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA08130777C944@tlvmail1> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: x+o= AOQA CAFT E8GA FZDA Ftsf HAw+ HW7Z HbLl NbBX P7S+ bj7r kntB qBYA ue07 1PVj; 5; ZABhAG4AaQBlAGwAYwBAAG8AcgBjAGsAaQB0AC4AYwBvAG0AOwBkAG8AbgBhAGwAZAAuAGYAZQBkAHkAawBAAGEAbABjAGEAdABlAGwALQBsAHUAYwBlAG4AdAAuAGMAbwBtADsAagBvAHMAaAAuAHIAbwBnAGUAcgBzAEAAdAB3AGMAYQBiAGwAZQAuAGMAbwBtADsAbAAyAHYAcABuAEAAaQBlAHQAZgAuAG8AcgBnADsAdwBpAG0ALgBoAGUAbgBkAGUAcgBpAGMAawB4AEAAYQBsAGMAYQB0AGUAbAAtAGwAdQBjAGUAbgB0AC4AYwBvAG0A; Sosha1_v1; 7; {5BF640CF-971A-4449-82F1-80FD65DCDD78}; agBpAGEAbgBnAHkAdQBhAG4AbABvAG4AZwBAAGgAdQBhAHcAZQBpAC4AYwBvAG0A; Wed, 02 May 2012 02:06:34 GMT; UgBFADoAIABUAGgAZQAgAHMAdABhAHQAdQBzACAAbwBmACAAdABoAGUAIABhAHAAcAByAG8AYQBjAGgAZQBzACAAdABvACAAdABoAGUAIABFAC0AVAByAGUAZQAgAHMAbwBsAHUAdABpAG8AbgA/AA== x-cr-puzzleid: {5BF640CF-971A-4449-82F1-80FD65DCDD78} x-originating-ip: [10.70.40.73] 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, 02 May 2012 02:09:39 -0000 Hi Daniel, As you can see, both cases are discussed in the I-D.=20 With regard to case 1) (that is, S-VLAN translation), since the access VLAN= and the E-Tree attributes (root/leaf) are services' attributes, they need = to be configured on a PE anyway, and as the past emails by Lucy, Don and Wi= m indicated, the access S-VLAN can be recovered by 1:1 mapping. With regard to S-VID space reduction, the constraint is valid only when a g= lobal VLAN space is used per PE, in fact, multi-VLAN space is more typical = and with no such limits as we already discussed in the f2f meeting. Even if there are 4094 S-VLANs in a single E-Tree access as you described (= not sure this is a valid use case in real life), PBB-VPLS can still be used= . Regards, Yuanlong -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Monday, April 30, 2012 10:34 PM To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; Jiangyuanlong; j= osh.rogers@twcable.com Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? 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 ---------------------------------------------------------------------- From xuxiaohu@huawei.com Tue May 1 19:56: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 A1AC921E80AC for ; Tue, 1 May 2012 19:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.388 X-Spam-Level: * X-Spam-Status: No, score=1.388 tagged_above=-999 required=5 tests=[AWL=-0.555, 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 xlyxks24uZ+N for ; Tue, 1 May 2012 19:56:41 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id D405F21E809B for ; Tue, 1 May 2012 19:56:40 -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 AFL14041; Tue, 01 May 2012 22:56:40 -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; Tue, 1 May 2012 19:54:58 -0700 Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 1 May 2012 19:55:02 -0700 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.182]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.01.0323.003; Wed, 2 May 2012 10:54:51 +0800 From: Xuxiaohu To: John E Drake , Linda Dunbar , Lucy yong , Mach Chen , Giles Heron , "l2vpn@ietf.org" Subject: re: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0kdUdSO48LuIhSPkS8Et2e3RTHugAJ0cmQABqEpVAAcwK+MAAEDOFgAAYZkLAAARDbgABDg9Dg Date: Wed, 2 May 2012 02:54:52 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02F1CBD0@szxeml525-mbs.china.huawei.com> 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: 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: Wed, 02 May 2012 02:56:41 -0000 Sm9obiwNCg0KSSdtIG5vdCB3b25kZXJpbmcgdGhhdCB5b3Ugc2FpZCB0aGF0IHdvcmQgc2luY2Ug eW91IGhhZCBldmVyIGRvdWJ0ZWQgYW5kIGV2ZW4gc2Nvcm5lZCB0aGUgbW90aXZhdGlvbiBvZiBO Vm8zIGFuZCBub3cgTlZvMyBXRyBpcyBmb3JtZWQgd2hpY2ggbWF5IG1ha2UgeW91IHZlcnkgcmFn aW5nLg0KDQpYaWFvaHUNCg0KPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gt6K8/sjLOiBsMnZwbi1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBKb2hu IEUNCj4gRHJha2UNCj4gt6LLzcqxvOQ6IDIwMTLE6jXUwjHI1SAyOjMzDQo+IMrVvP7IyzogTGlu ZGEgRHVuYmFyOyBMdWN5IHlvbmc7IE1hY2ggQ2hlbjsgR2lsZXMgSGVyb247IGwydnBuQGlldGYu b3JnDQo+INb3zOI6IFJFOiBJbnRlcmVzdCBpbiBJUy1JUyBWUExTDQo+IA0KPiBIb3cgYWJvdXQg RE9BPyAgKERlYWQgT24gQXJyaXZhbCkNCj4gDQo+IFNlbnQgZnJvbSBteSBpUGhvbmUNCj4gDQo+ IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogTGluZGEgRHVuYmFy IFttYWlsdG86bGluZGEuZHVuYmFyQGh1YXdlaS5jb21dDQo+ID4gU2VudDogTW9uZGF5LCBBcHJp bCAzMCwgMjAxMiAxMTowMiBBTQ0KPiA+IFRvOiBMdWN5IHlvbmc7IEpvaG4gRSBEcmFrZTsgTWFj aCBDaGVuOyBHaWxlcyBIZXJvbjsgbDJ2cG5AaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSRTogSW50 ZXJlc3QgaW4gSVMtSVMgVlBMUw0KPiA+DQo+ID4gQWdyZWUgd2l0aCBMdWN5LCAgREMtVlBOIG1p Z2h0IGJlIGEgYmV0dGVyIG5hbWUuDQo+ID4NCj4gPiBMaW5kYQ0KPiA+DQo+ID4gPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogbDJ2cG4tYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+ID4gQmVoYWxmDQo+ID4gPiBPZiBM dWN5IHlvbmcNCj4gPiA+IFNlbnQ6IE1vbmRheSwgQXByaWwgMzAsIDIwMTIgMTA6MzkgQU0NCj4g PiA+IFRvOiBKb2huIEUgRHJha2U7IE1hY2ggQ2hlbjsgR2lsZXMgSGVyb247IGwydnBuQGlldGYu b3JnDQo+ID4gPiBTdWJqZWN0OiBSRTogSW50ZXJlc3QgaW4gSVMtSVMgVlBMUw0KPiA+ID4NCj4g PiA+IEpvaG4sDQo+ID4gPg0KPiA+ID4gSVMtSVMgVlBMUyBpcyBjb21wbGV0ZWx5IGRpZmZlcmVu dCBmcm9tIFRSSUxMIGFuZCBTUEIgYWx0aG91Z2ggdGhleQ0KPiA+ID4gYWxsIHVzZSBvZiBJUy1J UyBwcm90b2NvbCBpbiBjb250cm9sIHBsYW5lLiBJUy1JUyBWUExTIGRhdGEgcGxhbmUNCj4gPiB1 c2VzDQo+ID4gPiBhbiBJUC9HUkUgdHVubmVsIGNhcnJ5aW5nIFZQTiBpbnN0YW5jZXMgZGlmZmVy ZW50aWF0ZWQgYnkgTVBMUw0KPiA+IGxhYmVscy4NCj4gPiA+IFRSSUxMIGFuZCBTUEIgZGF0YSBw bGFuZXMgYXJlIEV0aGVybmV0IGJhc2VkLCBpLmUuIHRoZSBmcmFtZXMgYXJlDQo+ID4gPiBFdGhl cm5ldCBmcmFtZXMuDQo+ID4gPg0KPiA+ID4gSXNuJ3QgaXQgZ29vZCB0aGF0IG9uZSBjb250cm9s IHBsYW5lIHByb3RvY29sIGNhbiBhcHBseSB0byBkaWZmZXJlbnQNCj4gPiA+IGRhdGEgcGxhbmVz Pw0KPiA+ID4NCj4gPiA+IEkgYWdyZWUgdGhhdCBWUExTIGhhcyBiZWVuIHdlbGwgZGVmaW5lZCBh bmQgdXNlZCBpbiBTZXJ2aWNlIFByb3ZpZGVyDQo+ID4gPiBuZXR3b3Jrcy4gSVMtSVMgVlBMUyBw cm92aWRlcyB0aGUgc2ltcGxpZmllZCB2ZXJzaW9uIG9mIFZQTFMgdGhhdCBjYW4NCj4gPiA+IGFw cGx5IHRvIGRhdGEgY2VudGVyIG5ldHdvcmtzLiBUaGlzIG1heSBiZSBiZXR0ZXIgdGhhbiBkZXZl bG9waW5nDQo+ID4gPiBzb21ldGhpbmcgY29tcGxldGVseSBuZXcgaW4gZGF0YSBjZW50ZXIuDQo+ ID4gPg0KPiA+ID4gTWF5YmUgd2UgbmVlZCBjb25zaWRlciBhbm90aGVyIG5hbWUgZm9yIHRoaXMs IGZvciBleGFtcGxlIERDLVZQTj8gSW4NCj4gPiA+IGRhdGEgY2VudGVyLCBhbiBWUE4gaXMgbm90 IG5lY2Vzc2FyeSB0byBwcm92aWRlIGEgc2VydmljZSB0byBhbg0KPiA+ID4gY3VzdG9tZXIsIHRo ZSBpbmZyYXN0cnVjdHVyZSBuZWVkIFZQTiBjYXBhYmlsaXR5Lg0KPiA+ID4NCj4gPiA+IFJlZ2Fy ZHMsDQo+ID4gPiBMdWN5DQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogSm9obiBFIERyYWtlIFttYWlsdG86amRyYWtlQGp1 bmlwZXIubmV0XQ0KPiA+ID4gU2VudDogTW9uZGF5LCBBcHJpbCAzMCwgMjAxMiA4OjEyIEFNDQo+ ID4gPiBUbzogTWFjaCBDaGVuOyBMdWN5IHlvbmc7IEdpbGVzIEhlcm9uOyBsMnZwbkBpZXRmLm9y Zw0KPiA+ID4gU3ViamVjdDogUkU6IEludGVyZXN0IGluIElTLUlTIFZQTFMNCj4gPiA+DQo+ID4g PiBXZSBhbHJlYWR5IGhhdmUgVFJJTEwgYW5kIFNQQi4gIFdoeSBpcyB5ZXQgYW5vdGhlciBJUy1J UyB2YXJpYW50DQo+ID4gPiBuZWNlc3NhcnksIHBhcnRpY3VsYXJseSBvbmUgdGhhdCBpcyBzbyBj b21wbGV0ZWx5IHVuZGVyLXNwZWNpZmllZD8NCj4gPiA+DQo+ID4gPiBTZW50IGZyb20gbXkgaVBo b25lDQo+ID4gPg0KPiA+ID4NCj4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g PiA+ID4gRnJvbTogbDJ2cG4tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwydnBuLWJvdW5jZXNA aWV0Zi5vcmddIE9uDQo+ID4gPiBCZWhhbGYNCj4gPiA+ID4gT2YgTWFjaCBDaGVuDQo+ID4gPiA+ IFNlbnQ6IFNhdHVyZGF5LCBBcHJpbCAyOCwgMjAxMiAzOjA0IEFNDQo+ID4gPiA+IFRvOiBMdWN5 IHlvbmc7IEdpbGVzIEhlcm9uOyBsMnZwbkBpZXRmLm9yZw0KPiA+ID4gPiBTdWJqZWN0OiBSRTog SW50ZXJlc3QgaW4gSVMtSVMgVlBMUw0KPiA+ID4gPg0KPiA+ID4gPiBGdWxseSBhZ3JlZSB3aXRo IGx1Y3kgaGVyZS4NCj4gPiA+ID4NCj4gPiA+ID4gSW4gYWRkaXRpb24sIHNpbmNlIHRoZSBJU0lT IFZQTFMgbGV2ZXJhZ2VzIGEgdW5pZm9ybSBwcm90b2NvbChJU0lTKQ0KPiA+ID4gZm9yDQo+ID4g PiA+IHNpZ25hbGluZyBhbmQgYXV0byBkaXNjb3ZlcnksIGl0IHdvdWxkIGdyZWF0bHkgc2ltcGxp ZnkgdGhlDQo+ID4gPiBkZXBsb3ltZW50DQo+ID4gPiA+IGFuZCBtYWludGVuYW5jZSwgZXNwZWNp YWxseSBmb3IgdGhlIERDIG5ldHdvcmtzIHRoYXQgaGF2ZSBhbHJlYWR5DQo+ID4gPiA+IGRlcGxv eWVkIElTSVMgZm9yIElQIHJvdXRpbmcuIFNvIEknZCBsaWtlIHRvIHNlZSB0aGUgZHJhZnQgbW92 aW5nDQo+ID4gPiA+IGZvcndhcmQuDQo+ID4gPiA+DQo+ID4gPiA+IEJlc3QgcmVnYXJkcywNCj4g PiA+ID4gTWFjaA0KPiA+ID4gPg0KPiA+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+ID4gPiA+ID4gRnJvbTogbDJ2cG4tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwydnBuLWJv dW5jZXNAaWV0Zi5vcmddIE9uDQo+ID4gPiA+IEJlaGFsZg0KPiA+ID4gPiA+IE9mIEx1Y3kgeW9u Zw0KPiA+ID4gPiA+IFNlbnQ6IFNhdHVyZGF5LCBBcHJpbCAyOCwgMjAxMiAyOjQzIEFNDQo+ID4g PiA+ID4gVG86IEdpbGVzIEhlcm9uOyBsMnZwbkBpZXRmLm9yZw0KPiA+ID4gPiA+IFN1YmplY3Q6 IFJFOiBJbnRlcmVzdCBpbiBJUy1JUyBWUExTDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBIaSBHaWxl cywNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEl0IHNlZW1zIHRoYXQgdGhlIElTLUlTIFZQTFMgcHJv dmlkZXMgdGhlIHNvbHV0aW9uIGZvciBhIHNjYWxhYmxlDQo+ID4gPiA+IGRhdGENCj4gPiA+ID4g PiBjZW50ZXIgbmV0d29yayBhcyBtZW50aW9uZWQgaW4gdGhlIGRyYWZ0LiBJIGFtIG5vdCBzdXJl IGl0IGlzDQo+ID4gPiBwcm9wZXINCj4gPiA+ID4gPiB0byB3ZWlnaHQgc2VydmljZSBwcm92aWRl cnMgbW9yZSBvbiB0aGlzLiBJIGNhbiBzZWUgaWYgYSBzZXJ2aWNlDQo+ID4gPiA+ID4gcHJvdmlk ZXIgYWxyZWFkeSBkZXBsb3llZCBleGlzdGluZyBWUExTLCB0aGUgZ2FpbiBmcm9tIElTLUlTIFZQ TFMNCj4gPiA+IGlzDQo+ID4gPiA+ID4gbGVzcyB0aGFuIHRoZSBjb3N0IG9uIHVwZ3JhZGluZyBh bGwgdGhlIGVkZ2UgZGV2aWNlcyB0byBzdXBwb3J0DQo+ID4gPiA+ID4gdGhlDQo+ID4gPiA+IHNv bHV0aW9uLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gSG93ZXZlciwgZm9yIGRhdGEgY2VudGVyIG5l dHdvcmssIElTLUlTIFZQTFMgY291bGQgYmUgYSB1c2VmdWwNCj4gPiA+ID4gPiBzb2x1dGlvbi4g SXQgc2ltcGxpZmllcyBjdXJyZW50IFZQTFMgbWVjaGFuaXNtLCBwcm92aWRlcyBhIGdvb2QNCj4g PiA+ID4gPiBzY2FsYWJpbGl0eSwgYW5kIHJlcXVpcmVzIElQIG9ubHkgZnVuY3Rpb24gb24gY29y ZSBzd2l0Y2hlcy4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEEgdmVuZG9yIHByb3ZpZGVzIGRldmlj ZXMgZm9yIGJvdGggc2VydmljZSBwcm92aWRlciBuZXR3b3JrIGFuZA0KPiA+ID4gZGF0YQ0KPiA+ ID4gPiA+IGNlbnRlciBuZXR3b3JrLCB0aGUgc29sdXRpb24gYnJpbmdzIGEgc3luZXJneSBpbiBs ZXZlcmFnaW5nIFZQTFMNCj4gPiA+ID4gPiBzb2x1dGlvbiBpbnRvIERDLg0KPiA+ID4gPiA+DQo+ ID4gPiA+ID4gVGh1cywgSSBsaWtlIHRvIHNlZSB0aGlzIHdvcmsgbW92aW5nIGZvcndhcmQuDQo+ ID4gPiA+ID4NCj4gPiA+ID4gPiBSZWdhcmRzLA0KPiA+ID4gPiA+IEx1Y3kNCj4gPiA+ID4gPg0K PiA+ID4gPiA+DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiA+ID4gPiA+IEZyb206IGwydnBuLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsMnZwbi1i b3VuY2VzQGlldGYub3JnXSBPbg0KPiA+ID4gPiBCZWhhbGYNCj4gPiA+ID4gPiBPZiBHaWxlcyBI ZXJvbg0KPiA+ID4gPiA+IFNlbnQ6IEZyaWRheSwgQXByaWwgMjcsIDIwMTIgNzo1NyBBTQ0KPiA+ ID4gPiA+IFRvOiBsMnZwbkBpZXRmLm9yZw0KPiA+ID4gPiA+IFN1YmplY3Q6IEludGVyZXN0IGlu IElTLUlTIFZQTFMNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEhpLA0KPiA+ID4gPiA+DQo+ID4gPiA+ ID4gQXQgdGhlIElFVEYgbWVldGluZyBpbiBQYXJpcyBJIHRvb2sgYW4gYWN0aW9uIChhcyBub3Rl ZCBpbiB0aGUNCj4gPiA+ID4gPiBtaW51dGVzKSB0byBwb2xsIHRoZSBXRyB0byBzZWUgaWYgdGhl cmUgd2FzIGFueSBpbnRlcmVzdCAob3RoZXINCj4gPiA+IHRoYW4NCj4gPiA+ID4gPiBieSB0aGUg YXV0aG9ycyBvZg0KPiA+ID4gPiA+IGNvdXJzZSkgaW4gcHJvZ3Jlc3NpbmcgdGhlIElTLUlTIFZQ TFMgZHJhZnQuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBXb3VsZCB5b3UgcGxlYXNlIHJlc3BvbmQg dG8gdGhpcyBlbWFpbCBpbmRpY2F0aW5nIHdoZXRoZXIgb3Igbm90DQo+ID4gPiB5b3UNCj4gPiA+ ID4gPiBoYXZlIGludGVyZXN0IGluIHNlZWluZyB0aGlzIGRyYWZ0IHByb2dyZXNzLCBpZGVhbGx5 IGdpdmluZw0KPiA+ID4gcmVhc29uaW5nDQo+ID4gPiA+ID4gZm9yIHlvdXIgcG9zaXRpb24uICBJ dCdkIGJlIGVzcGVjaWFsbHkgaW50ZXJlc3RpbmcgdG8gc2VlDQo+ID4gPiA+ID4gcmVzcG9uc2Vz IGZyb20gc2VydmljZSBwcm92aWRlcnMgb2YgY291cnNlLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4g SWYgdGhlcmUgYXJlIG5vIChvciB2ZXJ5IGZldykgcmVzcG9uc2VzIHRvIHRoaXMgZW1haWwgdGhl biBOYWJpbA0KPiA+ID4gYW5kDQo+ID4gPiA+IEkNCj4gPiA+ID4gPiB3aWxsIHByb2JhYmx5IGlu dGVycHJldCB0aGF0IGFzIG1lYW5pbmcgdGhlcmUncyBpbnN1ZmZpY2llbnQNCj4gPiA+IGludGVy ZXN0DQo+ID4gPiA+ID4gdG8gcHJvZ3Jlc3MuICBPZiBjb3Vyc2UgaXQgbWF5IGp1c3QgbWVhbiB0 aGF0IHlvdSBhbGwgbWlzc2VkIHRoaXMNCj4gPiA+ID4gPiBlbWFpbCBpbiB0aGUgZGVsdWdlIG9m IGRlYmF0ZSBvbiBFLVRyZWUgOykNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEdpbGVzDQo+ID4gPiA+ ID4NCg0K From zhangmingui@huawei.com Tue May 1 20:26: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 15EE221E8013 for ; Tue, 1 May 2012 20:26:26 -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 2v3r0K4sjzb0 for ; Tue, 1 May 2012 20:26:25 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 46D5721F8827 for ; Tue, 1 May 2012 20:26:03 -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 AFL15793; Tue, 01 May 2012 23:26:03 -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; Tue, 1 May 2012 20:23:35 -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; Tue, 1 May 2012 20:23:34 -0700 Received: from SZXEML507-MBS.china.huawei.com ([169.254.7.245]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.01.0323.003; Wed, 2 May 2012 11:23:21 +0800 From: Mingui Zhang 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+MAAEDOFgAEt9zQA= Date: Wed, 2 May 2012 03:23:20 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E728CD336A@SZXEML507-MBS.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D3264C7F8@dfweml505-mbx> <5E893DB832F57341992548CDBB333163A56EEDE9C5@EMBX01-HQ.jnpr.net> <2691CE0099834E4A9C5044EEC662BB9D330E4B68@dfweml505-mbx> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D330E4B68@dfweml505-mbx> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.73] 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, 02 May 2012 03:26:26 -0000 Hi, Conceptually, TRILL/SPB/ISIS-VPLS are all "L2VPN" techniques. They all leve= rage ISIS as the control plane but utilize different silicon. SPB tries to = utilize existing Ethernet-silicon. TRILL develops a new data plane and ther= e are several vendors who would like to support this with new "TRILL-silico= n". Except TRILL/SPB, there is a blue ocean where one can utilize existing = IP/MPLS silicon. I agree with Lucy that their differences in control plane = are trivial while the differences in data plane really distinguish them . Thanks, Mingui > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf= Of > Lucy yong > Sent: Monday, April 30, 2012 11:39 PM > 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 al= l 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 da= ta > 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 d= ata > 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 custom= er, 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 neces= sary, > 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 Beha= lf > > 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 deployme= nt > > 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 prop= er > > > 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 th= e > > 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 da= ta > > > 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 th= an > > > by the authors of > > > course) in progressing the IS-IS VPLS draft. > > > > > > Would you please respond to this email indicating whether or not y= ou > > > have interest in seeing this draft progress, ideally giving reason= ing > > > for your position. It'd be especially interesting to see response= s > > > from service providers of course. > > > > > > If there are no (or very few) responses to this email then Nabil a= nd > > I > > > will probably interpret that as meaning there's insufficient inter= est > > > to progress. Of course it may just mean that you all missed this > > > email in the deluge of debate on E-Tree ;) > > > > > > Giles > > > From xuxiaohu@huawei.com Tue May 1 21:07: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 AE8FD21E802C for ; Tue, 1 May 2012 21:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.409 X-Spam-Level: * X-Spam-Status: No, score=1.409 tagged_above=-999 required=5 tests=[AWL=-0.534, 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 4oXf1uYs63Nr for ; Tue, 1 May 2012 21:07:16 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id D1E8221E8013 for ; Tue, 1 May 2012 21:07: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 AFT20995; Wed, 02 May 2012 00:07:15 -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, 1 May 2012 21:05:07 -0700 Received: from SZXEML427-HUB.china.huawei.com (10.72.61.35) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 1 May 2012 21:05:10 -0700 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.182]) by szxeml427-hub.china.huawei.com ([10.72.61.35]) with mapi id 14.01.0323.003; Wed, 2 May 2012 12:04:57 +0800 From: Xuxiaohu To: Lucy yong , Gregory Mirsky , Giles Heron , "l2vpn@ietf.org" Subject: re: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0kdUdSO48LuIhSPkS8Et2e3RTHugAJ0cmQABqEpVAAcwK+MAAEDOFgAAFHrFAAAmp48ABIunyQ Date: Wed, 2 May 2012 04:04:56 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02F1CC39@szxeml525-mbs.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D3264C7F8@dfweml505-mbx> <5E893DB832F57341992548CDBB333163A56EEDE9C5@EMBX01-HQ.jnpr.net> <2691CE0099834E4A9C5044EEC662BB9D330E4B68@dfweml505-mbx> <2691CE0099834E4A9C5044EEC662BB9D330E5C27@dfweml505-mbx> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D330E5C27@dfweml505-mbx> 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: Wed, 02 May 2012 04:07:16 -0000 QXMgc2FpZCBpbiB0aGUgY3VycmVudCBMMlZQTiBXRyBjaGFydGVyLCAiLi4uSXQgd2lsbCBhbHNv IGFkZHJlc3MgcmVxdWlyZW1lbnRzIGRyaXZlbiBieSBjbG91ZCBjb21wdXRpbmcgc2VydmljZXMg YW5kIGRhdGEgY2VudGVycyBhcyB0aGV5IGFwcGx5IHRvIExheWVyLTIgVlBOIHNlcnZpY2VzLiIg VGhhdCdzIHdoeSB0aGUgY28tYXV0aG9ycyBvZiB0aGlzIGRyYWZ0IHRyaWVkIHRvIHB1c2ggdGhp cyB3b3JrIGluIEwyVlBOIFdHLg0KDQpJIGZ1bGx5IHVuZGVyc3RhbmQgdGhhdCBzb21lIEUtVlBO IGZvbGtzIGFyZSBhdHRlbXB0aW5nIHRvIGJsb2NrIHRoaXMgd29yayAob3IgZXZlbiBhbnkgb3Ro ZXIgY29tcGV0aW5nIHByb3Bvc2FsKSBhbmQgYXQgbGVhc3QgZXhjbHVkZSBpdCBmcm9tIEwyVlBO IFdHLiBJZiB0aGF0IHdhcyBtZSwgSSBtYXkgYWxzbyBjb25zaWRlciB0byBkbyB0aGF0LCBidXQg dGhyb3VnaCBwcm92aWRpbmcgbW9yZSBvYmplY3RpdmUsIGNvbmNyZXRlIGFuZCBjb25zaWRlcmVk IHJlYXNvbnMsIHJhdGhlciB0aGFuIHBlcnNvbmFsIHByZWZlcmVuY2VzIGFuZCBldmVuIC4uLg0K DQpBcyBmb3Igd2h5IHdlIG5lZWQgYW5vdGhlciBwcm9wb3NhbCBnaXZlbiBUUklMTC9TUEIgYXJl IGFscmVhZHkgdGhlcmUsIHlvdSBjYW4gZmluZCB0aGUgY2xlYXIgYW5zd2VyIGZyb20gdGhlIE5W bzMgY2hhcnRlciB0aGF0IGhhcyBiZWVuIHB1Ymxpc2hlZC4NCg0KQXMgZm9yIHdoeSB3ZSBuZWVk IGFub3RoZXIgcHJvcG9zYWwgZ2l2ZW4gRVZQTiBpcyBhbHJlYWR5IHRoZXJlIGFuZCBpcyBkZWVt ZWQgYXMgZ29vZCBlbm91Z2ggYnkgc29tZWJvZHksIHlvdSBjYW4gZmluZCB0aGUgYW5zd2VyIGZy b20gdGhlIHJlY2VudCBkaXNjdXNzaW9ucyBpbiBOVm8zIG1haWxpbmctbGlzdCBhbmQgZXZlbiBm cm9tIHRoZSBtb3RpdmF0aW9uIGZvciBzaW1wbGlmeWluZyBFLVZQTi4NCg0KQmVzdCByZWdhcmRz LA0KWGlhb2h1IA0KDQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogbDJ2cG4tYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gTHVjeQ0K PiB5b25nDQo+ILeiy83KsbzkOiAyMDEyxOo11MIxyNUgMDo1OA0KPiDK1bz+yMs6IEdyZWdvcnkg TWlyc2t5OyBHaWxlcyBIZXJvbjsgbDJ2cG5AaWV0Zi5vcmcNCj4g1vfM4jogUkU6IEludGVyZXN0 IGluIElTLUlTIFZQTFMNCj4gDQo+IEF1dGhvcnMgd2FudCB0byBicmluZyB0aGlzIHdvcmsgaW50 byBOVjAzLiBIb3dldmVyLCBOVjAzIGp1c3Qgc3RhcnRzIHRoZQ0KPiBwcm9ibGVtIHN0YXRlbWVu dCBhbmQgcmVxdWlyZW1lbnQuIEl0IGlzIG5vdCBpbiB0aGUgc3RhZ2Ugb2YgYW55IHNvbHV0aW9u IHlldC4NCj4gSVMtSVMgVlBMUyBpcyBqdXN0IGFuIGV2b2x1dGlvbiBvZiBWUExTLCBpdCBmaXRz IEwyVlBOIHRvby4NCj4gDQo+IEx1Y3kNCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IEdyZWdvcnkgTWlyc2t5IFttYWlsdG86Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24u Y29tXQ0KPiBTZW50OiBNb25kYXksIEFwcmlsIDMwLCAyMDEyIDExOjUwIEFNDQo+IFRvOiBMdWN5 IHlvbmc7IEdpbGVzIEhlcm9uOyBsMnZwbkBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogSW50ZXJl c3QgaW4gSVMtSVMgVlBMUw0KPiANCj4gRGVhciBMdWN5LA0KPiBJZiBhdXRob3JzIGJlbGlldmUg dGhhdCBhcHBsaWNhYmlsaXR5IGFyZWEgZm9yIHRoZSBkb2N1bWVudCBpcywgcHJpbWFyaWx5LCBp biBEQw0KPiBWUE5zLCB0aGVuLCBJTUhPLCBOVk8zIFdHIG1pZ2h0IGJlIHN1aXRhYmxlIFdHIHRv IGNvbnRpbnVlIHdvcmsgYXNzdW1pbmcNCj4gdGhlIHByb3Bvc2FsIHNhdGlzZmllcyBmdW5jdGlv bmFsIGFuZCBwZXJmb3JtYW5jZSwgaW5jbHVkaW5nIHNjYWxpbmcsDQo+IHJlcXVpcmVtZW50cyB0 aGF0IGJlZW4gcmVmZXJlbmNlZCBpbiBOVk8zIFdHIGNoYXJ0ZXIgYW5kIHdpbGwgYmUgZGV0YWls ZWQgaW4NCj4gZnJhbWV3b3JrIGFuZCBhcmNoaXRlY3R1cmFsIGRvY3VtZW50cy4NCj4gQW5kIEkg Y29uY3VyIHdpdGggU2FzaGEsIHdobyByZW1pbmRlZCB1cywgZGV2ZWxvcGVycywgdGhhdCBwYXJ0 aWN1bGFyIGludGVyZXN0DQo+IGFuZCB2YWx1ZSBiZSBwYWlkIHRvIGZlZWRiYWNrIGZyb20gc2Vy dmljZSBwcm92aWRlcnMuDQo+IA0KPiAJUmVnYXJkcywNCj4gCQlHcmVnDQo+IA0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBsMnZwbi1ib3VuY2VzQGlldGYub3JnIFttYWls dG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+IEx1Y3kgeW9uZw0KPiBT ZW50OiBNb25kYXksIEFwcmlsIDMwLCAyMDEyIDg6MzkgQU0NCj4gVG86IEpvaG4gRSBEcmFrZTsg TWFjaCBDaGVuOyBHaWxlcyBIZXJvbjsgbDJ2cG5AaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IElu dGVyZXN0IGluIElTLUlTIFZQTFMNCj4gDQo+IEpvaG4sDQo+IA0KPiBJUy1JUyBWUExTIGlzIGNv bXBsZXRlbHkgZGlmZmVyZW50IGZyb20gVFJJTEwgYW5kIFNQQiBhbHRob3VnaCB0aGV5IGFsbCB1 c2Ugb2YNCj4gSVMtSVMgcHJvdG9jb2wgaW4gY29udHJvbCBwbGFuZS4gSVMtSVMgVlBMUyBkYXRh IHBsYW5lIHVzZXMgYW4gSVAvR1JFIHR1bm5lbA0KPiBjYXJyeWluZyBWUE4gaW5zdGFuY2VzIGRp ZmZlcmVudGlhdGVkIGJ5IE1QTFMgbGFiZWxzLiBUUklMTCBhbmQgU1BCIGRhdGENCj4gcGxhbmVz IGFyZSBFdGhlcm5ldCBiYXNlZCwgaS5lLiB0aGUgZnJhbWVzIGFyZSBFdGhlcm5ldCBmcmFtZXMu DQo+IA0KPiBJc24ndCBpdCBnb29kIHRoYXQgb25lIGNvbnRyb2wgcGxhbmUgcHJvdG9jb2wgY2Fu IGFwcGx5IHRvIGRpZmZlcmVudCBkYXRhIHBsYW5lcz8NCj4gDQo+IEkgYWdyZWUgdGhhdCBWUExT IGhhcyBiZWVuIHdlbGwgZGVmaW5lZCBhbmQgdXNlZCBpbiBTZXJ2aWNlIFByb3ZpZGVyIG5ldHdv cmtzLg0KPiBJUy1JUyBWUExTIHByb3ZpZGVzIHRoZSBzaW1wbGlmaWVkIHZlcnNpb24gb2YgVlBM UyB0aGF0IGNhbiBhcHBseSB0byBkYXRhIGNlbnRlcg0KPiBuZXR3b3Jrcy4gVGhpcyBtYXkgYmUg YmV0dGVyIHRoYW4gZGV2ZWxvcGluZyBzb21ldGhpbmcgY29tcGxldGVseSBuZXcgaW4NCj4gZGF0 YSBjZW50ZXIuDQo+IA0KPiBNYXliZSB3ZSBuZWVkIGNvbnNpZGVyIGFub3RoZXIgbmFtZSBmb3Ig dGhpcywgZm9yIGV4YW1wbGUgREMtVlBOPyBJbiBkYXRhDQo+IGNlbnRlciwgYW4gVlBOIGlzIG5v dCBuZWNlc3NhcnkgdG8gcHJvdmlkZSBhIHNlcnZpY2UgdG8gYW4gY3VzdG9tZXIsIHRoZQ0KPiBp bmZyYXN0cnVjdHVyZSBuZWVkIFZQTiBjYXBhYmlsaXR5Lg0KPiANCj4gUmVnYXJkcywNCj4gTHVj eQ0KPiANCj4gDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKb2hu IEUgRHJha2UgW21haWx0bzpqZHJha2VAanVuaXBlci5uZXRdDQo+IFNlbnQ6IE1vbmRheSwgQXBy aWwgMzAsIDIwMTIgODoxMiBBTQ0KPiBUbzogTWFjaCBDaGVuOyBMdWN5IHlvbmc7IEdpbGVzIEhl cm9uOyBsMnZwbkBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogSW50ZXJlc3QgaW4gSVMtSVMgVlBM Uw0KPiANCj4gV2UgYWxyZWFkeSBoYXZlIFRSSUxMIGFuZCBTUEIuICBXaHkgaXMgeWV0IGFub3Ro ZXIgSVMtSVMgdmFyaWFudCBuZWNlc3NhcnksDQo+IHBhcnRpY3VsYXJseSBvbmUgdGhhdCBpcyBz byBjb21wbGV0ZWx5IHVuZGVyLXNwZWNpZmllZD8NCj4gDQo+IFNlbnQgZnJvbSBteSBpUGhvbmUN Cj4gDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogbDJ2cG4t Ym91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs Zg0KPiA+IE9mIE1hY2ggQ2hlbg0KPiA+IFNlbnQ6IFNhdHVyZGF5LCBBcHJpbCAyOCwgMjAxMiAz OjA0IEFNDQo+ID4gVG86IEx1Y3kgeW9uZzsgR2lsZXMgSGVyb247IGwydnBuQGlldGYub3JnDQo+ ID4gU3ViamVjdDogUkU6IEludGVyZXN0IGluIElTLUlTIFZQTFMNCj4gPg0KPiA+IEZ1bGx5IGFn cmVlIHdpdGggbHVjeSBoZXJlLg0KPiA+DQo+ID4gSW4gYWRkaXRpb24sIHNpbmNlIHRoZSBJU0lT IFZQTFMgbGV2ZXJhZ2VzIGEgdW5pZm9ybSBwcm90b2NvbChJU0lTKQ0KPiA+IGZvciBzaWduYWxp bmcgYW5kIGF1dG8gZGlzY292ZXJ5LCBpdCB3b3VsZCBncmVhdGx5IHNpbXBsaWZ5IHRoZQ0KPiA+ IGRlcGxveW1lbnQgYW5kIG1haW50ZW5hbmNlLCBlc3BlY2lhbGx5IGZvciB0aGUgREMgbmV0d29y a3MgdGhhdCBoYXZlDQo+ID4gYWxyZWFkeSBkZXBsb3llZCBJU0lTIGZvciBJUCByb3V0aW5nLiBT byBJJ2QgbGlrZSB0byBzZWUgdGhlIGRyYWZ0DQo+ID4gbW92aW5nIGZvcndhcmQuDQo+ID4NCj4g PiBCZXN0IHJlZ2FyZHMsDQo+ID4gTWFjaA0KPiA+DQo+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiA+ID4gRnJvbTogbDJ2cG4tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwydnBu LWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+ID4gQmVoYWxmDQo+ID4gPiBPZiBMdWN5IHlvbmcNCj4g PiA+IFNlbnQ6IFNhdHVyZGF5LCBBcHJpbCAyOCwgMjAxMiAyOjQzIEFNDQo+ID4gPiBUbzogR2ls ZXMgSGVyb247IGwydnBuQGlldGYub3JnDQo+ID4gPiBTdWJqZWN0OiBSRTogSW50ZXJlc3QgaW4g SVMtSVMgVlBMUw0KPiA+ID4NCj4gPiA+IEhpIEdpbGVzLA0KPiA+ID4NCj4gPiA+IEl0IHNlZW1z IHRoYXQgdGhlIElTLUlTIFZQTFMgcHJvdmlkZXMgdGhlIHNvbHV0aW9uIGZvciBhIHNjYWxhYmxl DQo+ID4gZGF0YQ0KPiA+ID4gY2VudGVyIG5ldHdvcmsgYXMgbWVudGlvbmVkIGluIHRoZSBkcmFm dC4gSSBhbSBub3Qgc3VyZSBpdCBpcyBwcm9wZXINCj4gPiA+IHRvIHdlaWdodCBzZXJ2aWNlIHBy b3ZpZGVycyBtb3JlIG9uIHRoaXMuIEkgY2FuIHNlZSBpZiBhIHNlcnZpY2UNCj4gPiA+IHByb3Zp ZGVyIGFscmVhZHkgZGVwbG95ZWQgZXhpc3RpbmcgVlBMUywgdGhlIGdhaW4gZnJvbSBJUy1JUyBW UExTIGlzDQo+ID4gPiBsZXNzIHRoYW4gdGhlIGNvc3Qgb24gdXBncmFkaW5nIGFsbCB0aGUgZWRn ZSBkZXZpY2VzIHRvIHN1cHBvcnQgdGhlDQo+ID4gc29sdXRpb24uDQo+ID4gPg0KPiA+ID4gSG93 ZXZlciwgZm9yIGRhdGEgY2VudGVyIG5ldHdvcmssIElTLUlTIFZQTFMgY291bGQgYmUgYSB1c2Vm dWwNCj4gPiA+IHNvbHV0aW9uLiBJdCBzaW1wbGlmaWVzIGN1cnJlbnQgVlBMUyBtZWNoYW5pc20s IHByb3ZpZGVzIGEgZ29vZA0KPiA+ID4gc2NhbGFiaWxpdHksIGFuZCByZXF1aXJlcyBJUCBvbmx5 IGZ1bmN0aW9uIG9uIGNvcmUgc3dpdGNoZXMuDQo+ID4gPg0KPiA+ID4gQSB2ZW5kb3IgcHJvdmlk ZXMgZGV2aWNlcyBmb3IgYm90aCBzZXJ2aWNlIHByb3ZpZGVyIG5ldHdvcmsgYW5kIGRhdGENCj4g PiA+IGNlbnRlciBuZXR3b3JrLCB0aGUgc29sdXRpb24gYnJpbmdzIGEgc3luZXJneSBpbiBsZXZl cmFnaW5nIFZQTFMNCj4gPiA+IHNvbHV0aW9uIGludG8gREMuDQo+ID4gPg0KPiA+ID4gVGh1cywg SSBsaWtlIHRvIHNlZSB0aGlzIHdvcmsgbW92aW5nIGZvcndhcmQuDQo+ID4gPg0KPiA+ID4gUmVn YXJkcywNCj4gPiA+IEx1Y3kNCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBsMnZwbi1ib3VuY2VzQGlldGYub3JnIFttYWls dG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZ10gT24NCj4gPiBCZWhhbGYNCj4gPiA+IE9mIEdpbGVz IEhlcm9uDQo+ID4gPiBTZW50OiBGcmlkYXksIEFwcmlsIDI3LCAyMDEyIDc6NTcgQU0NCj4gPiA+ IFRvOiBsMnZwbkBpZXRmLm9yZw0KPiA+ID4gU3ViamVjdDogSW50ZXJlc3QgaW4gSVMtSVMgVlBM Uw0KPiA+ID4NCj4gPiA+IEhpLA0KPiA+ID4NCj4gPiA+IEF0IHRoZSBJRVRGIG1lZXRpbmcgaW4g UGFyaXMgSSB0b29rIGFuIGFjdGlvbiAoYXMgbm90ZWQgaW4gdGhlDQo+ID4gPiBtaW51dGVzKSB0 byBwb2xsIHRoZSBXRyB0byBzZWUgaWYgdGhlcmUgd2FzIGFueSBpbnRlcmVzdCAob3RoZXIgdGhh bg0KPiA+ID4gYnkgdGhlIGF1dGhvcnMgb2YNCj4gPiA+IGNvdXJzZSkgaW4gcHJvZ3Jlc3Npbmcg dGhlIElTLUlTIFZQTFMgZHJhZnQuDQo+ID4gPg0KPiA+ID4gV291bGQgeW91IHBsZWFzZSByZXNw b25kIHRvIHRoaXMgZW1haWwgaW5kaWNhdGluZyB3aGV0aGVyIG9yIG5vdCB5b3UNCj4gPiA+IGhh dmUgaW50ZXJlc3QgaW4gc2VlaW5nIHRoaXMgZHJhZnQgcHJvZ3Jlc3MsIGlkZWFsbHkgZ2l2aW5n DQo+ID4gPiByZWFzb25pbmcgZm9yIHlvdXIgcG9zaXRpb24uICBJdCdkIGJlIGVzcGVjaWFsbHkg aW50ZXJlc3RpbmcgdG8gc2VlDQo+ID4gPiByZXNwb25zZXMgZnJvbSBzZXJ2aWNlIHByb3ZpZGVy cyBvZiBjb3Vyc2UuDQo+ID4gPg0KPiA+ID4gSWYgdGhlcmUgYXJlIG5vIChvciB2ZXJ5IGZldykg cmVzcG9uc2VzIHRvIHRoaXMgZW1haWwgdGhlbiBOYWJpbCBhbmQNCj4gPiBJDQo+ID4gPiB3aWxs IHByb2JhYmx5IGludGVycHJldCB0aGF0IGFzIG1lYW5pbmcgdGhlcmUncyBpbnN1ZmZpY2llbnQN Cj4gPiA+IGludGVyZXN0IHRvIHByb2dyZXNzLiAgT2YgY291cnNlIGl0IG1heSBqdXN0IG1lYW4g dGhhdCB5b3UgYWxsDQo+ID4gPiBtaXNzZWQgdGhpcyBlbWFpbCBpbiB0aGUgZGVsdWdlIG9mIGRl YmF0ZSBvbiBFLVRyZWUgOykNCj4gPiA+DQo+ID4gPiBHaWxlcw0KPiA+ID4NCg0K From kireeti@juniper.net Tue May 1 23:10: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 AE93921F8A43 for ; Tue, 1 May 2012 23:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 VFQhVu4Zj5t0 for ; Tue, 1 May 2012 23:10:52 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEF121F8932 for ; Tue, 1 May 2012 23:10:50 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKT6DP6dp+j8o/LY7S+785JrcDfSdolLf3@postini.com; Tue, 01 May 2012 23:10:51 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Tue, 1 May 2012 23:09:20 -0700 From: Kireeti Kompella To: Xuxiaohu Date: Tue, 1 May 2012 23:09:19 -0700 Subject: Re: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0oKhy+BE2g4ou2QqOQ0TkFU/BK5Q== Message-ID: <7081784B-29A8-4B9B-9E91-235FB8EB7C9E@juniper.net> References: <2691CE0099834E4A9C5044EEC662BB9D3264C7F8@dfweml505-mbx> <5E893DB832F57341992548CDBB333163A56EEDE9C5@EMBX01-HQ.jnpr.net> <2691CE0099834E4A9C5044EEC662BB9D330E4B68@dfweml505-mbx> <2691CE0099834E4A9C5044EEC662BB9D330E5C27@dfweml505-mbx> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02F1CC39@szxeml525-mbs.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02F1CC39@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="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, 02 May 2012 06:10:53 -0000 On May 1, 2012, at 21:07, "Xuxiaohu" wrote: > I fully understand that some E-VPN folks are attempting to block this wor= k That's one interpretation. Another is a genuine interest in positive feedba= ck from a *Service Provider* or other entity that cares to deploy this tech= nology. All I've seen so far is positive feedback from a _single vendor_. = Perhaps I've missed something; at times, my eyes glaze over on this topic. I'm a simple guy: before I torque my implementation of the IGP that constit= utes the backbone of several of my biggest customers, I want to see a subst= antial justification for doing so. I see a big risk; if there's a big rewar= d, I'll consider it. I'm still waiting. Kireeti From jiangyuanlong@huawei.com Wed May 2 00:50: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 B71FE21F8A41 for ; Wed, 2 May 2012 00:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, 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 cS0YOMiYhG-w for ; Wed, 2 May 2012 00:50:15 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2771421F8A43 for ; Wed, 2 May 2012 00:50: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 AFL30736; Wed, 02 May 2012 03:50:14 -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; Wed, 2 May 2012 00:46:42 -0700 Received: from SZXEML424-HUB.china.huawei.com (10.82.67.163) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 2 May 2012 00:46:40 -0700 Received: from SZXEML508-MBX.china.huawei.com ([169.254.5.215]) by szxeml424-hub.china.huawei.com ([10.82.67.163]) with mapi id 14.01.0323.003; Wed, 2 May 2012 15:46:33 +0800 From: Jiangyuanlong To: David Allan I 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: AQHNKDex1y2bdkyBxEeUDx/kgi6ZzA== Date: Wed, 2 May 2012 07:46:33 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA52BC5@SZXEML508-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.70.40.73] 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, 02 May 2012 07:50:16 -0000 Hi Dave, The document is trying to capture the generic E-Tree solution for the whole= 802.1Q, rather than for 802.1aq specifically. As you know, IEEE 802.1 can revise the general aspects of 802.1Q in any spe= cific sub-task project (such as 802.1aq). I must say I am somewhat puzzled at how to properly reference their E-Tree = work myself... With regard to asymmetric VLAN, I will add a note with its publishing detai= ls (It seems published as early as 2003, or did I miss something?). =20 Thanks, Yuanlong ________________________________ 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 From DanielC@orckit.com Wed May 2 00:53: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 F1E2A11E8096 for ; Wed, 2 May 2012 00:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 JYdVjj+BZKwu for ; Wed, 2 May 2012 00:53:24 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id 51C9311E808C for ; Wed, 2 May 2012 00:53:23 -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: Wed, 2 May 2012 10:55:21 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA08130777CB13@tlvmail1> In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA51A54@SZXEML508-MBX.china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: AQHNI1NEA18PKDoBDEy6zAcXiVu2LpasuNMAgAYGiYCAAAzygIAAAjQAgAAAAYCAAASFAIAAAOoAgAAYGACAAAPTgIACzjKAgABsbmA= References: <44F4E579A764584EA9BDFD07D0CA08130777C912@tlvmail1> <14C7F4F06DB5814AB0DE29716C4F6D67023ECB0FE3@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <44F4E579A764584EA9BDFD07D0CA08130777C944@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA51A54@SZXEML508-MBX.china.huawei.com> From: "Daniel Cohn" To: "Jiangyuanlong" , "Fedyk, Donald (Don)" , "Henderickx, Wim (Wim)" , "Lucy yong" , 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, 02 May 2012 07:53:25 -0000 Hi Yuanlong, The problem is not with the total number of S-VLAN IDs, I agree that normally there won't be more than 2047. The problem is that if you don't support all VLAN IDs, you need S-VLAN space coordination with the providers, e.g. "I can only transparently preserve S-VLAN ID 1 to 2047". Which won't always be in line with an existing deployment. Relying on PBB-VPLS imposes additional limitations on backward compatibility. Daniel -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Wednesday, May 02, 2012 5:07 AM To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; josh.rogers@twcable.com Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi Daniel, As you can see, both cases are discussed in the I-D.=20 With regard to case 1) (that is, S-VLAN translation), since the access VLAN and the E-Tree attributes (root/leaf) are services' attributes, they need to be configured on a PE anyway, and as the past emails by Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 mapping. With regard to S-VID space reduction, the constraint is valid only when a global VLAN space is used per PE, in fact, multi-VLAN space is more typical and with no such limits as we already discussed in the f2f meeting. Even if there are 4094 S-VLANs in a single E-Tree access as you described (not sure this is a valid use case in real life), PBB-VPLS can still be used. Regards, Yuanlong -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Monday, April 30, 2012 10:34 PM To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; Jiangyuanlong; josh.rogers@twcable.com Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? 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 ---------------------------------------------------------------------- From xuxiaohu@huawei.com Wed May 2 01:00: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 EAC8D21F883C for ; Wed, 2 May 2012 01:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.842 X-Spam-Level: X-Spam-Status: No, score=-0.842 tagged_above=-999 required=5 tests=[AWL=1.757, 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 2q8wDYpbCnXC for ; Wed, 2 May 2012 01:00:00 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 64DF021F87D0 for ; Wed, 2 May 2012 01:00:00 -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 AFL31307; Wed, 02 May 2012 04:00:00 -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, 2 May 2012 00:57:39 -0700 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 2 May 2012 00:57:37 -0700 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.182]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.01.0323.003; Wed, 2 May 2012 15:57:35 +0800 From: Xuxiaohu To: Kireeti Kompella Subject: re: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0kdUdSO48LuIhSPkS8Et2e3RTHugAJ0cmQABqEpVAAcwK+MAAEDOFgAAFHrFAAAmp48ABIunyQ//+k+ID//2Kj8A== Date: Wed, 2 May 2012 07:57:34 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02F1CCB8@szxeml525-mbs.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D3264C7F8@dfweml505-mbx> <5E893DB832F57341992548CDBB333163A56EEDE9C5@EMBX01-HQ.jnpr.net> <2691CE0099834E4A9C5044EEC662BB9D330E4B68@dfweml505-mbx> <2691CE0099834E4A9C5044EEC662BB9D330E5C27@dfweml505-mbx> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02F1CC39@szxeml525-mbs.china.huawei.com> <7081784B-29A8-4B9B-9E91-235FB8EB7C9E@juniper.net> In-Reply-To: <7081784B-29A8-4B9B-9E91-235FB8EB7C9E@juniper.net> 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="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, 02 May 2012 08:00:01 -0000 > I'm a simple guy: before I torque my implementation of the IGP that const= itutes > the backbone of several of my biggest customers, I want to see a substant= ial > justification for doing so. I see a big risk; if there's a big reward, I'= ll consider it. Hi Kireeti, IS-IS VPLS is just intended to be used in a closed environment such as a da= ta center network, rather than across the WAN backbone. In addition, the on= ly extended TLV required in IS-IS VPLS could be processed as an unknown TLV= by those core routers (i.e., P routers) within data centers. According to = ISO 10589 and RFC 1195, IS-IS routers would ignore unknown TLVs in the LSP = and pass them on to other neighbors unchanged. In other words, there are no= need for core routers to parse any unknown TLVs in an IS-IS packet. Hence = there is no big risk as you imagined.=20 Best regards, Xiaohu > I'm still waiting. >=20 > Kireeti From jiangyuanlong@huawei.com Wed May 2 02:32: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 3567121F8AE4 for ; Wed, 2 May 2012 02:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, 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 IEudIERG6bZw for ; Wed, 2 May 2012 02:32:57 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9C121F8830 for ; Wed, 2 May 2012 02:32: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 AFT39532; Wed, 02 May 2012 05:32:56 -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; Wed, 2 May 2012 02:30:31 -0700 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 2 May 2012 02:30:29 -0700 Received: from SZXEML508-MBX.china.huawei.com ([169.254.5.215]) by szxeml405-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Wed, 2 May 2012 17:30:17 +0800 From: Jiangyuanlong To: Daniel Cohn , "Fedyk, Donald (Don)" , "Henderickx, Wim (Wim)" , Lucy yong , "josh.rogers@twcable.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: AQHNI1NEA18PKDoBDEy6zAcXiVu2LpasuNMAgAYGiYCAAAzygIAAAjQAgAAAAYCAAASFAIAAAOoAgAAYGACAAAPTgIACzjKAgABsbmCAABSDMA== Date: Wed, 2 May 2012 09:30:15 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA52C12@SZXEML508-MBX.china.huawei.com> References: <44F4E579A764584EA9BDFD07D0CA08130777C912@tlvmail1> <14C7F4F06DB5814AB0DE29716C4F6D67023ECB0FE3@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <44F4E579A764584EA9BDFD07D0CA08130777C944@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA51A54@SZXEML508-MBX.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130777CB13@tlvmail1> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA08130777CB13@tlvmail1> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.40.73] 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, 02 May 2012 09:32:58 -0000 Hi Daniel, Please see my comments in line. -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Wednesday, May 02, 2012 3:55 PM To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; j= osh.rogers@twcable.com Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi Yuanlong, The problem is not with the total number of S-VLAN IDs, I agree that normally there won't be more than 2047. The problem is that if you don't support all VLAN IDs, you need S-VLAN space coordination with the providers, e.g. "I can only transparently preserve S-VLAN ID 1 to 2047". Which won't always be in line with an existing deployment. [JY] This is not the case. If the total number is no more than 2047, it sur= ely can be supported. The S-VLAN space of user domain is totally different = from the S-VLAN in the provider domain and they can be overlapped, I don't = see why we need S-VLAN space coordination between them.=20 Relying on PBB-VPLS imposes additional limitations on backward compatibility. [JY] If the SPs really have to support so many S-VLANs in a E-Tree, I think= they may well need MAC-in-MAC in their networks for the scalability issue.= As you know, only PBB VPLS can provide both. Daniel -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Wednesday, May 02, 2012 5:07 AM To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; josh.rogers@twcable.com Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi Daniel, As you can see, both cases are discussed in the I-D.=20 With regard to case 1) (that is, S-VLAN translation), since the access VLAN and the E-Tree attributes (root/leaf) are services' attributes, they need to be configured on a PE anyway, and as the past emails by Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 mapping. With regard to S-VID space reduction, the constraint is valid only when a global VLAN space is used per PE, in fact, multi-VLAN space is more typical and with no such limits as we already discussed in the f2f meeting. Even if there are 4094 S-VLANs in a single E-Tree access as you described (not sure this is a valid use case in real life), PBB-VPLS can still be used. Regards, Yuanlong -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Monday, April 30, 2012 10:34 PM To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; Jiangyuanlong; josh.rogers@twcable.com Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? 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 ---------------------------------------------------------------------- From DanielC@orckit.com Wed May 2 04:59: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 61BB421F8A85 for ; Wed, 2 May 2012 04:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 kSzlolksU+je for ; Wed, 2 May 2012 04:59:06 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id C46C621F89E1 for ; Wed, 2 May 2012 04:59: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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: The status of the approaches to the E-Tree solution? Date: Wed, 2 May 2012 15:01:00 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA08130777CB80@tlvmail1> In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA52C12@SZXEML508-MBX.china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: AQHNI1NEA18PKDoBDEy6zAcXiVu2LpasuNMAgAYGiYCAAAzygIAAAjQAgAAAAYCAAASFAIAAAOoAgAAYGACAAAPTgIACzjKAgABsbmCAABSDMIAAJEvQ References: <44F4E579A764584EA9BDFD07D0CA08130777C912@tlvmail1> <14C7F4F06DB5814AB0DE29716C4F6D67023ECB0FE3@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <44F4E579A764584EA9BDFD07D0CA08130777C944@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA51A54@SZXEML508-MBX.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130777CB13@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA52C12@SZXEML508-MBX.china.huawei.com> From: "Daniel Cohn" To: "Jiangyuanlong" , "Fedyk, Donald (Don)" , "Henderickx, Wim (Wim)" , "Lucy yong" , 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, 02 May 2012 11:59:07 -0000 Inline. -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Wednesday, May 02, 2012 12:30 PM To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; josh.rogers@twcable.com Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi Daniel, Please see my comments in line. -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Wednesday, May 02, 2012 3:55 PM To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; josh.rogers@twcable.com Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi Yuanlong, The problem is not with the total number of S-VLAN IDs, I agree that normally there won't be more than 2047. The problem is that if you don't support all VLAN IDs, you need S-VLAN space coordination with the providers, e.g. "I can only transparently preserve S-VLAN ID 1 to 2047". Which won't always be in line with an existing deployment. [JY] This is not the case. If the total number is no more than 2047, it surely can be supported. The S-VLAN space of user domain is totally different from the S-VLAN in the provider domain and they can be overlapped, I don't see why we need S-VLAN space coordination between them.=20 [DC] If we use global S-VIDs in the VPLS (to simply mapping provisioning), then the IEEE S-VID to VPLS S-VID mapping should be fixed, and therefore the IEEE S-VID that can be supported is also fixed. Of course you can configure the mapping in each PE according to operator requirements but as we discussed before this increases complexity.=20 Relying on PBB-VPLS imposes additional limitations on backward compatibility. [JY] If the SPs really have to support so many S-VLANs in a E-Tree, I think they may well need MAC-in-MAC in their networks for the scalability issue. As you know, only PBB VPLS can provide both. Daniel -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Wednesday, May 02, 2012 5:07 AM To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; josh.rogers@twcable.com Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi Daniel, As you can see, both cases are discussed in the I-D.=20 With regard to case 1) (that is, S-VLAN translation), since the access VLAN and the E-Tree attributes (root/leaf) are services' attributes, they need to be configured on a PE anyway, and as the past emails by Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 mapping. With regard to S-VID space reduction, the constraint is valid only when a global VLAN space is used per PE, in fact, multi-VLAN space is more typical and with no such limits as we already discussed in the f2f meeting. Even if there are 4094 S-VLANs in a single E-Tree access as you described (not sure this is a valid use case in real life), PBB-VPLS can still be used. Regards, Yuanlong -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Monday, April 30, 2012 10:34 PM To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; Jiangyuanlong; josh.rogers@twcable.com Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? 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 ---------------------------------------------------------------------- From prvs=0469c0b7e0=hshah@ciena.com Wed May 2 06:49: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 27C0621F85E4 for ; Wed, 2 May 2012 06:49:02 -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=[AWL=0.000, 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 qO7aXmZM43pI for ; Wed, 2 May 2012 06:49:01 -0700 (PDT) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) by ietfa.amsl.com (Postfix) with ESMTP id E7B8921F85DD for ; Wed, 2 May 2012 06:49:00 -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 q42DjHpI020112; Wed, 2 May 2012 09:48:55 -0400 Received: from mdwexght02.ciena.com (LIN1-118-36-29.ciena.com [63.118.36.29]) by mx0b-00103a01.pphosted.com with ESMTP id 14k5p7g3mb-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 02 May 2012 09:48:55 -0400 Received: from MDWEXCHCGSIHT01.ciena.com (10.4.140.106) by MDWEXGHT02.ciena.com (10.4.140.213) with Microsoft SMTP Server (TLS) id 8.3.192.1; Wed, 2 May 2012 09:48:55 -0400 Received: from MDWEXGMB02.ciena.com ([::1]) by MDWEXCHCGSIHT01.ciena.com ([::1]) with mapi; Wed, 2 May 2012 09:48:55 -0400 From: "Shah, Himanshu" To: Kireeti Kompella , Xuxiaohu Date: Wed, 2 May 2012 09:48:53 -0400 Subject: RE: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0oKhy+BE2g4ou2QqOQ0TkFU/BK5QAOyGjA Message-ID: References: <2691CE0099834E4A9C5044EEC662BB9D3264C7F8@dfweml505-mbx> <5E893DB832F57341992548CDBB333163A56EEDE9C5@EMBX01-HQ.jnpr.net> <2691CE0099834E4A9C5044EEC662BB9D330E4B68@dfweml505-mbx> <2691CE0099834E4A9C5044EEC662BB9D330E5C27@dfweml505-mbx> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02F1CC39@szxeml525-mbs.china.huawei.com> <7081784B-29A8-4B9B-9E91-235FB8EB7C9E@juniper.net> In-Reply-To: <7081784B-29A8-4B9B-9E91-235FB8EB7C9E@juniper.net> 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-18878.006 X-TM-AS-Result: No--23.756300-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7580, 1.0.260, 0.0.0000 definitions=2012-05-02_02:2012-05-01, 2012-05-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-1205020121 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, 02 May 2012 13:49:02 -0000 I make following observations - - IETF mission statement: individual contributions/opinions, no company all= iances. Given that being true, positive feedback from individuals should not be brushed aside as from a = _single vendor_. Besides, I observe that harder pushback is from individuals from evpn coa= uthor member companies - feedback from *service provider*: =20 - yes it is important, but carry equal weight as any other individual. - In early days, TRILL chair was asked if any SP wants this solution, answ= er was "no, but we think this is an interesting problem to solve, so we are going to go ahead and= do it" (paraphrasing). - Several SPs with deployments asked for -bhh- solution to be considered i= n MPLS-TP, with no avail. - in my view, need for SP feedback argument is used at convenience - take it nvo3: but we just changed the L2VPN charter to work on DCN soluti= ons... - multiple protocols: but we have OSPF & ISIS in routing and more recently = LDP & BGP in L2VPN.. - Xiahou responded to your concern on IGP. ISIS-VPLS can also be viewed as = favorable solution for smaller networks.. Thanks, himanshu -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of K= ireeti Kompella Sent: Wednesday, May 02, 2012 2:09 AM To: Xuxiaohu Cc: l2vpn@ietf.org Subject: Re: Interest in IS-IS VPLS On May 1, 2012, at 21:07, "Xuxiaohu" wrote: > I fully understand that some E-VPN folks are attempting to block this wor= k That's one interpretation. Another is a genuine interest in positive feedba= ck from a *Service Provider* or other entity that cares to deploy this tech= nology. All I've seen so far is positive feedback from a _single vendor_. = Perhaps I've missed something; at times, my eyes glaze over on this topic. I'm a simple guy: before I torque my implementation of the IGP that constit= utes the backbone of several of my biggest customers, I want to see a subst= antial justification for doing so. I see a big risk; if there's a big rewar= d, I'll consider it. I'm still waiting. Kireeti From lizhong.jin@zte.com.cn Wed May 2 07:47: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 482A021F8630 for ; Wed, 2 May 2012 07:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 3NcAh5LFYZbd for ; Wed, 2 May 2012 07:47:03 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id C0E3621F861F for ; Wed, 2 May 2012 07:46:59 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 62129577109098; Wed, 2 May 2012 22:45:02 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 60658.683968793; Wed, 2 May 2012 22:46:56 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q42Ekme4034634; Wed, 2 May 2012 22:46:48 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: giles.heron@gmail.com Subject: Re: Interest in IS-IS VPLS MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Lizhong Jin Date: Wed, 2 May 2012 22:46:36 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-05-02 22:46:52, Serialize complete at 2012-05-02 22:46:52 Content-Type: multipart/alternative; boundary="=_alternative 00513143482579F2_=" X-MAIL: mse02.zte.com.cn q42Ekme4034634 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, 02 May 2012 14:47:04 -0000 This is a multipart message in MIME format. --=_alternative 00513143482579F2_= Content-Type: text/plain; charset="US-ASCII" Hi Giles, I am not interested in seeing this draft progress. Since ISIS VPLS is mainly trying to solve the datacenter problem, then it should belong to NVO3. The NVO3 WG now only starts problem statement, but this should not be the reason why ISIS VPLS belong to L2VPN WG. Since it is a solution, we should wait to see if ISIS VPLS really solves the datacenter problem, and right now, it is time to contribute to the NVO3 problem statement. Lizhong > ---------------------------------------------------------------------- > > 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 > > > > --=_alternative 00513143482579F2_= Content-Type: text/html; charset="US-ASCII"
Hi Giles,
I am not interested in seeing this draft progress.
Since ISIS VPLS is mainly trying to solve the datacenter problem, then it should belong to NVO3. The NVO3 WG now only starts problem statement, but this should not be the reason why ISIS VPLS belong to L2VPN WG. Since it is a solution, we should wait to see if ISIS VPLS really solves the datacenter problem, and right now, it is time to contribute to the NVO3 problem statement.

Lizhong


> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 27 Apr 2012 13:57:19 +0100
> From: Giles Heron <giles.heron@gmail.com>
> To: <l2vpn@ietf.org>
> Subject: Interest in IS-IS VPLS
> Message-ID: <CBC0563F.1A33B%giles.heron@gmail.com>
> 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
>
>
>
> --=_alternative 00513143482579F2_=-- From david.i.allan@ericsson.com Wed May 2 08:48: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 5F7B621E805D for ; Wed, 2 May 2012 08:48:06 -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, 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 dmM2a0FstjYM for ; Wed, 2 May 2012 08:48:05 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id B46E221E8054 for ; Wed, 2 May 2012 08:48:05 -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 q42FlwTB015476; Wed, 2 May 2012 10:47:59 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.69]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 2 May 2012 11:47:52 -0400 From: David Allan I To: Jiangyuanlong Date: Wed, 2 May 2012 11:47:51 -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: AQHNKDex1y2bdkyBxEeUDx/kgi6ZzJa2ofqg Message-ID: <60C093A41B5E45409A19D42CF7786DFD523264FF1D@EUSAACMS0703.eamcs.ericsson.se> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA52BC5@SZXEML508-MBX.china.huawei.com> In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA52BC5@SZXEML508-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: 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, 02 May 2012 15:48:06 -0000 Hi Yuanlong:=20 You wrote: > The document is trying to capture the generic E-Tree solution for the who= le 802.1Q, rather than for 802.1aq specifically. Understood, that is why I seggested the change to avoid confusion between t= he attributes of how ETREE is achieved in the various revisions to 802.1Q. > As you know, IEEE 802.1 can revise the general aspects of 802.1Q in any s= pecific sub-task project (such as 802.1aq). Yep... > I must say I am somewhat puzzled at how to properly reference their E-Tre= e work myself... These days most of the recent amendments got rolled up in Q-rev so 802.1Q(2= 011) jst about covers the waterfront. 802.1aq did not complete in time. > With regard to asymmetric VLAN, I will add a note with its publishing det= ails (It seems published as early as 2003, or did I miss something?).=20 You're right, I checked, I thought it was in an annex of 802.1ad, but it is= earlier: IEEE standard 802.1Q-2003, Annex B.1.3 Cheers Dave=20 ________________________________ 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 From jdrake@juniper.net Wed May 2 10:29: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 3F51C21F853D for ; Wed, 2 May 2012 10:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[AWL=-2.245, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2MVAwz8tq2j for ; Wed, 2 May 2012 10:29:02 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF5F21F853B for ; Wed, 2 May 2012 10:29:02 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKT6Fu2Txu46M/HVzjnxcBO1R+Ktkd3XHB@postini.com; Wed, 02 May 2012 10:29:02 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Wed, 2 May 2012 10:28:26 -0700 From: John E Drake To: Xuxiaohu , Lucy yong , Gregory Mirsky , Giles Heron , "l2vpn@ietf.org" Date: Wed, 2 May 2012 10:28:16 -0700 Subject: RE: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0kdUdSO48LuIhSPkS8Et2e3RTHugAJ0cmQABqEpVAAcwK+MAAEDOFgAAFHrFAAAmp48ABIunyQABy0EGA= Message-ID: <5E893DB832F57341992548CDBB333163A577283BB5@EMBX01-HQ.jnpr.net> References: <2691CE0099834E4A9C5044EEC662BB9D3264C7F8@dfweml505-mbx> <5E893DB832F57341992548CDBB333163A56EEDE9C5@EMBX01-HQ.jnpr.net> <2691CE0099834E4A9C5044EEC662BB9D330E4B68@dfweml505-mbx> <2691CE0099834E4A9C5044EEC662BB9D330E5C27@dfweml505-mbx> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02F1CC39@szxeml525-mbs.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02F1CC39@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="gb2312" 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: Wed, 02 May 2012 17:29:03 -0000 Q29tbWVudHMgaW5saW5lDQoNClNlbnQgZnJvbSBteSBpUGhvbmUNCg0KDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGwydnBuLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzps MnZwbi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4gT2YgWHV4aWFvaHUNCj4gU2VudDog VHVlc2RheSwgTWF5IDAxLCAyMDEyIDk6MDUgUE0NCj4gVG86IEx1Y3kgeW9uZzsgR3JlZ29yeSBN aXJza3k7IEdpbGVzIEhlcm9uOyBsMnZwbkBpZXRmLm9yZw0KPiBTdWJqZWN0OiByZTogSW50ZXJl c3QgaW4gSVMtSVMgVlBMUw0KPiANCj4gQXMgc2FpZCBpbiB0aGUgY3VycmVudCBMMlZQTiBXRyBj aGFydGVyLCAiLi4uSXQgd2lsbCBhbHNvIGFkZHJlc3MNCj4gcmVxdWlyZW1lbnRzIGRyaXZlbiBi eSBjbG91ZCBjb21wdXRpbmcgc2VydmljZXMgYW5kIGRhdGEgY2VudGVycyBhcw0KPiB0aGV5IGFw cGx5IHRvIExheWVyLTIgVlBOIHNlcnZpY2VzLiIgVGhhdCdzIHdoeSB0aGUgY28tYXV0aG9ycyBv ZiB0aGlzDQo+IGRyYWZ0IHRyaWVkIHRvIHB1c2ggdGhpcyB3b3JrIGluIEwyVlBOIFdHLg0KPiAN Cj4gSSBmdWxseSB1bmRlcnN0YW5kIHRoYXQgc29tZSBFLVZQTiBmb2xrcyBhcmUgYXR0ZW1wdGlu ZyB0byBibG9jayB0aGlzDQo+IHdvcmsgKG9yIGV2ZW4gYW55IG90aGVyIGNvbXBldGluZyBwcm9w b3NhbCkgYW5kIGF0IGxlYXN0IGV4Y2x1ZGUgaXQNCj4gZnJvbSBMMlZQTiBXRy4gSWYgdGhhdCB3 YXMgbWUsIEkgbWF5IGFsc28gY29uc2lkZXIgdG8gZG8gdGhhdCwgYnV0DQo+IHRocm91Z2ggcHJv dmlkaW5nIG1vcmUgb2JqZWN0aXZlLCBjb25jcmV0ZSBhbmQgY29uc2lkZXJlZCByZWFzb25zLA0K PiByYXRoZXIgdGhhbiBwZXJzb25hbCBwcmVmZXJlbmNlcyBhbmQgZXZlbiAuLi4NCg0KSkQ6ICBO bywgdGhlIGlzc3VlIGlzIHNpbXBseSB0aGF0IGRldmVsb3BpbmcgeWV0IGFub3RoZXIgVlBOIGlz IGEgd2FzdGUgb2YgZXZlcnlvbmUncyB0aW1lLCBwYXJ0aWN1bGFybHkgd2hlbiB0aGUgb25seSB0 ZWNobmljYWwganVzdGlmaWNhdGlvbiBmb3IgaXQgaXMgdGhhdCBpdCB3aWxsIG1ha2UgdGhpbmdz ICJiZXR0ZXIgYW5kIGJldHRlciIuICANCg0KPiANCj4gQXMgZm9yIHdoeSB3ZSBuZWVkIGFub3Ro ZXIgcHJvcG9zYWwgZ2l2ZW4gVFJJTEwvU1BCIGFyZSBhbHJlYWR5IHRoZXJlLA0KPiB5b3UgY2Fu IGZpbmQgdGhlIGNsZWFyIGFuc3dlciBmcm9tIHRoZSBOVm8zIGNoYXJ0ZXIgdGhhdCBoYXMgYmVl bg0KPiBwdWJsaXNoZWQuDQoNCkpEOiAgV2hlcmUgZXhhY3RseT8NCg0KPiANCj4gQXMgZm9yIHdo eSB3ZSBuZWVkIGFub3RoZXIgcHJvcG9zYWwgZ2l2ZW4gRVZQTiBpcyBhbHJlYWR5IHRoZXJlIGFu ZCBpcw0KPiBkZWVtZWQgYXMgZ29vZCBlbm91Z2ggYnkgc29tZWJvZHksIHlvdSBjYW4gZmluZCB0 aGUgYW5zd2VyIGZyb20gdGhlDQo+IHJlY2VudCBkaXNjdXNzaW9ucyBpbiBOVm8zIG1haWxpbmct bGlzdCBhbmQgZXZlbiBmcm9tIHRoZSBtb3RpdmF0aW9uDQo+IGZvciBzaW1wbGlmeWluZyBFLVZQ Ti4NCg0KSkQ6ICBXaGVyZSBleGFjdGx5Pw0KIA0KPiANCj4gQmVzdCByZWdhcmRzLA0KPiBYaWFv aHUNCj4gDQo+IA0KPiA+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiA+ILeivP7IyzogbDJ2cG4tYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmddILT6se0NCj4gTHVj eQ0KPiA+IHlvbmcNCj4gPiC3osvNyrG85DogMjAxMsTqNdTCMcjVIDA6NTgNCj4gPiDK1bz+yMs6 IEdyZWdvcnkgTWlyc2t5OyBHaWxlcyBIZXJvbjsgbDJ2cG5AaWV0Zi5vcmcNCj4gPiDW98ziOiBS RTogSW50ZXJlc3QgaW4gSVMtSVMgVlBMUw0KPiA+DQo+ID4gQXV0aG9ycyB3YW50IHRvIGJyaW5n IHRoaXMgd29yayBpbnRvIE5WMDMuIEhvd2V2ZXIsIE5WMDMganVzdCBzdGFydHMNCj4gPiB0aGUg cHJvYmxlbSBzdGF0ZW1lbnQgYW5kIHJlcXVpcmVtZW50LiBJdCBpcyBub3QgaW4gdGhlIHN0YWdl IG9mIGFueQ0KPiBzb2x1dGlvbiB5ZXQuDQo+ID4gSVMtSVMgVlBMUyBpcyBqdXN0IGFuIGV2b2x1 dGlvbiBvZiBWUExTLCBpdCBmaXRzIEwyVlBOIHRvby4NCj4gPg0KPiA+IEx1Y3kNCj4gPg0KPiA+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogR3JlZ29yeSBNaXJza3kgW21h aWx0bzpncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb21dDQo+ID4gU2VudDogTW9uZGF5LCBBcHJp bCAzMCwgMjAxMiAxMTo1MCBBTQ0KPiA+IFRvOiBMdWN5IHlvbmc7IEdpbGVzIEhlcm9uOyBsMnZw bkBpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJFOiBJbnRlcmVzdCBpbiBJUy1JUyBWUExTDQo+ID4N Cj4gPiBEZWFyIEx1Y3ksDQo+ID4gSWYgYXV0aG9ycyBiZWxpZXZlIHRoYXQgYXBwbGljYWJpbGl0 eSBhcmVhIGZvciB0aGUgZG9jdW1lbnQgaXMsDQo+ID4gcHJpbWFyaWx5LCBpbiBEQyBWUE5zLCB0 aGVuLCBJTUhPLCBOVk8zIFdHIG1pZ2h0IGJlIHN1aXRhYmxlIFdHIHRvDQo+ID4gY29udGludWUg d29yayBhc3N1bWluZyB0aGUgcHJvcG9zYWwgc2F0aXNmaWVzIGZ1bmN0aW9uYWwgYW5kDQo+ID4g cGVyZm9ybWFuY2UsIGluY2x1ZGluZyBzY2FsaW5nLCByZXF1aXJlbWVudHMgdGhhdCBiZWVuIHJl ZmVyZW5jZWQgaW4NCj4gPiBOVk8zIFdHIGNoYXJ0ZXIgYW5kIHdpbGwgYmUgZGV0YWlsZWQgaW4g ZnJhbWV3b3JrIGFuZCBhcmNoaXRlY3R1cmFsDQo+IGRvY3VtZW50cy4NCj4gPiBBbmQgSSBjb25j dXIgd2l0aCBTYXNoYSwgd2hvIHJlbWluZGVkIHVzLCBkZXZlbG9wZXJzLCB0aGF0IHBhcnRpY3Vs YXINCj4gPiBpbnRlcmVzdCBhbmQgdmFsdWUgYmUgcGFpZCB0byBmZWVkYmFjayBmcm9tIHNlcnZp Y2UgcHJvdmlkZXJzLg0KPiA+DQo+ID4gCVJlZ2FyZHMsDQo+ID4gCQlHcmVnDQo+ID4NCj4gPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IGwydnBuLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiBCZWhhbGYNCj4gPiBPZiBM dWN5IHlvbmcNCj4gPiBTZW50OiBNb25kYXksIEFwcmlsIDMwLCAyMDEyIDg6MzkgQU0NCj4gPiBU bzogSm9obiBFIERyYWtlOyBNYWNoIENoZW47IEdpbGVzIEhlcm9uOyBsMnZwbkBpZXRmLm9yZw0K PiA+IFN1YmplY3Q6IFJFOiBJbnRlcmVzdCBpbiBJUy1JUyBWUExTDQo+ID4NCj4gPiBKb2huLA0K PiA+DQo+ID4gSVMtSVMgVlBMUyBpcyBjb21wbGV0ZWx5IGRpZmZlcmVudCBmcm9tIFRSSUxMIGFu ZCBTUEIgYWx0aG91Z2ggdGhleQ0KPiA+IGFsbCB1c2Ugb2YgSVMtSVMgcHJvdG9jb2wgaW4gY29u dHJvbCBwbGFuZS4gSVMtSVMgVlBMUyBkYXRhIHBsYW5lDQo+IHVzZXMNCj4gPiBhbiBJUC9HUkUg dHVubmVsIGNhcnJ5aW5nIFZQTiBpbnN0YW5jZXMgZGlmZmVyZW50aWF0ZWQgYnkgTVBMUw0KPiBs YWJlbHMuDQo+ID4gVFJJTEwgYW5kIFNQQiBkYXRhIHBsYW5lcyBhcmUgRXRoZXJuZXQgYmFzZWQs IGkuZS4gdGhlIGZyYW1lcyBhcmUNCj4gRXRoZXJuZXQgZnJhbWVzLg0KPiA+DQo+ID4gSXNuJ3Qg aXQgZ29vZCB0aGF0IG9uZSBjb250cm9sIHBsYW5lIHByb3RvY29sIGNhbiBhcHBseSB0byBkaWZm ZXJlbnQNCj4gZGF0YSBwbGFuZXM/DQo+ID4NCj4gPiBJIGFncmVlIHRoYXQgVlBMUyBoYXMgYmVl biB3ZWxsIGRlZmluZWQgYW5kIHVzZWQgaW4gU2VydmljZSBQcm92aWRlcg0KPiBuZXR3b3Jrcy4N Cj4gPiBJUy1JUyBWUExTIHByb3ZpZGVzIHRoZSBzaW1wbGlmaWVkIHZlcnNpb24gb2YgVlBMUyB0 aGF0IGNhbiBhcHBseSB0bw0KPiA+IGRhdGEgY2VudGVyIG5ldHdvcmtzLiBUaGlzIG1heSBiZSBi ZXR0ZXIgdGhhbiBkZXZlbG9waW5nIHNvbWV0aGluZw0KPiA+IGNvbXBsZXRlbHkgbmV3IGluIGRh dGEgY2VudGVyLg0KPiA+DQo+ID4gTWF5YmUgd2UgbmVlZCBjb25zaWRlciBhbm90aGVyIG5hbWUg Zm9yIHRoaXMsIGZvciBleGFtcGxlIERDLVZQTj8gSW4NCj4gPiBkYXRhIGNlbnRlciwgYW4gVlBO IGlzIG5vdCBuZWNlc3NhcnkgdG8gcHJvdmlkZSBhIHNlcnZpY2UgdG8gYW4NCj4gPiBjdXN0b21l ciwgdGhlIGluZnJhc3RydWN0dXJlIG5lZWQgVlBOIGNhcGFiaWxpdHkuDQo+ID4NCj4gPiBSZWdh cmRzLA0KPiA+IEx1Y3kNCj4gPg0KPiA+DQo+ID4NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiA+IEZyb206IEpvaG4gRSBEcmFrZSBbbWFpbHRvOmpkcmFrZUBqdW5pcGVyLm5ldF0N Cj4gPiBTZW50OiBNb25kYXksIEFwcmlsIDMwLCAyMDEyIDg6MTIgQU0NCj4gPiBUbzogTWFjaCBD aGVuOyBMdWN5IHlvbmc7IEdpbGVzIEhlcm9uOyBsMnZwbkBpZXRmLm9yZw0KPiA+IFN1YmplY3Q6 IFJFOiBJbnRlcmVzdCBpbiBJUy1JUyBWUExTDQo+ID4NCj4gPiBXZSBhbHJlYWR5IGhhdmUgVFJJ TEwgYW5kIFNQQi4gIFdoeSBpcyB5ZXQgYW5vdGhlciBJUy1JUyB2YXJpYW50DQo+ID4gbmVjZXNz YXJ5LCBwYXJ0aWN1bGFybHkgb25lIHRoYXQgaXMgc28gY29tcGxldGVseSB1bmRlci1zcGVjaWZp ZWQ/DQo+ID4NCj4gPiBTZW50IGZyb20gbXkgaVBob25lDQo+ID4NCj4gPg0KPiA+ID4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IGwydnBuLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiA+ID4gQmVoYWxmIE9mIE1hY2gg Q2hlbg0KPiA+ID4gU2VudDogU2F0dXJkYXksIEFwcmlsIDI4LCAyMDEyIDM6MDQgQU0NCj4gPiA+ IFRvOiBMdWN5IHlvbmc7IEdpbGVzIEhlcm9uOyBsMnZwbkBpZXRmLm9yZw0KPiA+ID4gU3ViamVj dDogUkU6IEludGVyZXN0IGluIElTLUlTIFZQTFMNCj4gPiA+DQo+ID4gPiBGdWxseSBhZ3JlZSB3 aXRoIGx1Y3kgaGVyZS4NCj4gPiA+DQo+ID4gPiBJbiBhZGRpdGlvbiwgc2luY2UgdGhlIElTSVMg VlBMUyBsZXZlcmFnZXMgYSB1bmlmb3JtIHByb3RvY29sKElTSVMpDQo+ID4gPiBmb3Igc2lnbmFs aW5nIGFuZCBhdXRvIGRpc2NvdmVyeSwgaXQgd291bGQgZ3JlYXRseSBzaW1wbGlmeSB0aGUNCj4g PiA+IGRlcGxveW1lbnQgYW5kIG1haW50ZW5hbmNlLCBlc3BlY2lhbGx5IGZvciB0aGUgREMgbmV0 d29ya3MgdGhhdA0KPiBoYXZlDQo+ID4gPiBhbHJlYWR5IGRlcGxveWVkIElTSVMgZm9yIElQIHJv dXRpbmcuIFNvIEknZCBsaWtlIHRvIHNlZSB0aGUgZHJhZnQNCj4gPiA+IG1vdmluZyBmb3J3YXJk Lg0KPiA+ID4NCj4gPiA+IEJlc3QgcmVnYXJkcywNCj4gPiA+IE1hY2gNCj4gPiA+DQo+ID4gPiA+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+IEZyb206IGwydnBuLWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiA+ID4gQmVoYWxm DQo+ID4gPiA+IE9mIEx1Y3kgeW9uZw0KPiA+ID4gPiBTZW50OiBTYXR1cmRheSwgQXByaWwgMjgs IDIwMTIgMjo0MyBBTQ0KPiA+ID4gPiBUbzogR2lsZXMgSGVyb247IGwydnBuQGlldGYub3JnDQo+ ID4gPiA+IFN1YmplY3Q6IFJFOiBJbnRlcmVzdCBpbiBJUy1JUyBWUExTDQo+ID4gPiA+DQo+ID4g PiA+IEhpIEdpbGVzLA0KPiA+ID4gPg0KPiA+ID4gPiBJdCBzZWVtcyB0aGF0IHRoZSBJUy1JUyBW UExTIHByb3ZpZGVzIHRoZSBzb2x1dGlvbiBmb3IgYSBzY2FsYWJsZQ0KPiA+ID4gZGF0YQ0KPiA+ ID4gPiBjZW50ZXIgbmV0d29yayBhcyBtZW50aW9uZWQgaW4gdGhlIGRyYWZ0LiBJIGFtIG5vdCBz dXJlIGl0IGlzDQo+ID4gPiA+IHByb3BlciB0byB3ZWlnaHQgc2VydmljZSBwcm92aWRlcnMgbW9y ZSBvbiB0aGlzLiBJIGNhbiBzZWUgaWYgYQ0KPiA+ID4gPiBzZXJ2aWNlIHByb3ZpZGVyIGFscmVh ZHkgZGVwbG95ZWQgZXhpc3RpbmcgVlBMUywgdGhlIGdhaW4gZnJvbQ0KPiA+ID4gPiBJUy1JUyBW UExTIGlzIGxlc3MgdGhhbiB0aGUgY29zdCBvbiB1cGdyYWRpbmcgYWxsIHRoZSBlZGdlDQo+IGRl dmljZXMNCj4gPiA+ID4gdG8gc3VwcG9ydCB0aGUNCj4gPiA+IHNvbHV0aW9uLg0KPiA+ID4gPg0K PiA+ID4gPiBIb3dldmVyLCBmb3IgZGF0YSBjZW50ZXIgbmV0d29yaywgSVMtSVMgVlBMUyBjb3Vs ZCBiZSBhIHVzZWZ1bA0KPiA+ID4gPiBzb2x1dGlvbi4gSXQgc2ltcGxpZmllcyBjdXJyZW50IFZQ TFMgbWVjaGFuaXNtLCBwcm92aWRlcyBhIGdvb2QNCj4gPiA+ID4gc2NhbGFiaWxpdHksIGFuZCBy ZXF1aXJlcyBJUCBvbmx5IGZ1bmN0aW9uIG9uIGNvcmUgc3dpdGNoZXMuDQo+ID4gPiA+DQo+ID4g PiA+IEEgdmVuZG9yIHByb3ZpZGVzIGRldmljZXMgZm9yIGJvdGggc2VydmljZSBwcm92aWRlciBu ZXR3b3JrIGFuZA0KPiA+ID4gPiBkYXRhIGNlbnRlciBuZXR3b3JrLCB0aGUgc29sdXRpb24gYnJp bmdzIGEgc3luZXJneSBpbiBsZXZlcmFnaW5nDQo+ID4gPiA+IFZQTFMgc29sdXRpb24gaW50byBE Qy4NCj4gPiA+ID4NCj4gPiA+ID4gVGh1cywgSSBsaWtlIHRvIHNlZSB0aGlzIHdvcmsgbW92aW5n IGZvcndhcmQuDQo+ID4gPiA+DQo+ID4gPiA+IFJlZ2FyZHMsDQo+ID4gPiA+IEx1Y3kNCj4gPiA+ ID4NCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gPiA+ID4gRnJvbTogbDJ2cG4tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwydnBuLWJvdW5j ZXNAaWV0Zi5vcmddIE9uDQo+ID4gPiBCZWhhbGYNCj4gPiA+ID4gT2YgR2lsZXMgSGVyb24NCj4g PiA+ID4gU2VudDogRnJpZGF5LCBBcHJpbCAyNywgMjAxMiA3OjU3IEFNDQo+ID4gPiA+IFRvOiBs MnZwbkBpZXRmLm9yZw0KPiA+ID4gPiBTdWJqZWN0OiBJbnRlcmVzdCBpbiBJUy1JUyBWUExTDQo+ ID4gPiA+DQo+ID4gPiA+IEhpLA0KPiA+ID4gPg0KPiA+ID4gPiBBdCB0aGUgSUVURiBtZWV0aW5n IGluIFBhcmlzIEkgdG9vayBhbiBhY3Rpb24gKGFzIG5vdGVkIGluIHRoZQ0KPiA+ID4gPiBtaW51 dGVzKSB0byBwb2xsIHRoZSBXRyB0byBzZWUgaWYgdGhlcmUgd2FzIGFueSBpbnRlcmVzdCAob3Ro ZXINCj4gPiA+ID4gdGhhbiBieSB0aGUgYXV0aG9ycyBvZg0KPiA+ID4gPiBjb3Vyc2UpIGluIHBy b2dyZXNzaW5nIHRoZSBJUy1JUyBWUExTIGRyYWZ0Lg0KPiA+ID4gPg0KPiA+ID4gPiBXb3VsZCB5 b3UgcGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBlbWFpbCBpbmRpY2F0aW5nIHdoZXRoZXIgb3Igbm90 DQo+ID4gPiA+IHlvdSBoYXZlIGludGVyZXN0IGluIHNlZWluZyB0aGlzIGRyYWZ0IHByb2dyZXNz LCBpZGVhbGx5IGdpdmluZw0KPiA+ID4gPiByZWFzb25pbmcgZm9yIHlvdXIgcG9zaXRpb24uICBJ dCdkIGJlIGVzcGVjaWFsbHkgaW50ZXJlc3RpbmcgdG8NCj4gPiA+ID4gc2VlIHJlc3BvbnNlcyBm cm9tIHNlcnZpY2UgcHJvdmlkZXJzIG9mIGNvdXJzZS4NCj4gPiA+ID4NCj4gPiA+ID4gSWYgdGhl cmUgYXJlIG5vIChvciB2ZXJ5IGZldykgcmVzcG9uc2VzIHRvIHRoaXMgZW1haWwgdGhlbiBOYWJp bA0KPiA+ID4gPiBhbmQNCj4gPiA+IEkNCj4gPiA+ID4gd2lsbCBwcm9iYWJseSBpbnRlcnByZXQg dGhhdCBhcyBtZWFuaW5nIHRoZXJlJ3MgaW5zdWZmaWNpZW50DQo+ID4gPiA+IGludGVyZXN0IHRv IHByb2dyZXNzLiAgT2YgY291cnNlIGl0IG1heSBqdXN0IG1lYW4gdGhhdCB5b3UgYWxsDQo+ID4g PiA+IG1pc3NlZCB0aGlzIGVtYWlsIGluIHRoZSBkZWx1Z2Ugb2YgZGViYXRlIG9uIEUtVHJlZSA7 KQ0KPiA+ID4gPg0KPiA+ID4gPiBHaWxlcw0KPiA+ID4gPg0KDQo= From jdrake@juniper.net Wed May 2 10:29: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 1A8CA21E8026 for ; Wed, 2 May 2012 10:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.247 X-Spam-Level: X-Spam-Status: No, score=-4.247 tagged_above=-999 required=5 tests=[AWL=-2.190, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UI7fx8Ocn5Qz for ; Wed, 2 May 2012 10:29:11 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id E218111E80A6 for ; Wed, 2 May 2012 10:29:10 -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 DSNKT6Fu0DejA/zdV3Gz7sdDIYXw5V3OMLAM@postini.com; Wed, 02 May 2012 10:29:10 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; Wed, 2 May 2012 10:28:26 -0700 From: John E Drake To: Xuxiaohu , Linda Dunbar , Lucy yong , Mach Chen , Giles Heron , "l2vpn@ietf.org" Date: Wed, 2 May 2012 10:28:25 -0700 Subject: RE: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0kdUdSO48LuIhSPkS8Et2e3RTHugAJ0cmQABqEpVAAcwK+MAAEDOFgAAYZkLAAARDbgABDg9DgAB48wxA= Message-ID: <5E893DB832F57341992548CDBB333163A577283BB3@EMBX01-HQ.jnpr.net> References: <2691CE0099834E4A9C5044EEC662BB9D3264C7F8@dfweml505-mbx> <5E893DB832F57341992548CDBB333163A56EEDE9C5@EMBX01-HQ.jnpr.net> <2691CE0099834E4A9C5044EEC662BB9D330E4B68@dfweml505-mbx> <4A95BA014132FF49AE685FAB4B9F17F6339049E4@dfweml505-mbx> <5E893DB832F57341992548CDBB333163A56EEDED4C@EMBX01-HQ.jnpr.net> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02F1CBD0@szxeml525-mbs.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02F1CBD0@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="gb2312" 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: Wed, 02 May 2012 17:29:12 -0000 TmljZSByYW50LCBidXQgYSBiaXQgb2ZmIHRvcGljLg0KDQpTZW50IGZyb20gbXkgaVBob25lDQoN Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogWHV4aWFvaHUgW21haWx0bzp4 dXhpYW9odUBodWF3ZWkuY29tXQ0KPiBTZW50OiBUdWVzZGF5LCBNYXkgMDEsIDIwMTIgNzo1NSBQ TQ0KPiBUbzogSm9obiBFIERyYWtlOyBMaW5kYSBEdW5iYXI7IEx1Y3kgeW9uZzsgTWFjaCBDaGVu OyBHaWxlcyBIZXJvbjsNCj4gbDJ2cG5AaWV0Zi5vcmcNCj4gU3ViamVjdDogcmU6IEludGVyZXN0 IGluIElTLUlTIFZQTFMNCj4gDQo+IEpvaG4sDQo+IA0KPiBJJ20gbm90IHdvbmRlcmluZyB0aGF0 IHlvdSBzYWlkIHRoYXQgd29yZCBzaW5jZSB5b3UgaGFkIGV2ZXIgZG91YnRlZA0KPiBhbmQgZXZl biBzY29ybmVkIHRoZSBtb3RpdmF0aW9uIG9mIE5WbzMgYW5kIG5vdyBOVm8zIFdHIGlzIGZvcm1l ZCB3aGljaA0KPiBtYXkgbWFrZSB5b3UgdmVyeSByYWdpbmcuDQo+IA0KPiBYaWFvaHUNCj4gDQo+ ID4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ID4gt6K8/sjLOiBsMnZwbi1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZ10gtPqx7Q0KPiBKb2huIEUNCj4gPiBEcmFr ZQ0KPiA+ILeiy83KsbzkOiAyMDEyxOo11MIxyNUgMjozMw0KPiA+IMrVvP7IyzogTGluZGEgRHVu YmFyOyBMdWN5IHlvbmc7IE1hY2ggQ2hlbjsgR2lsZXMgSGVyb247DQo+IGwydnBuQGlldGYub3Jn DQo+ID4g1vfM4jogUkU6IEludGVyZXN0IGluIElTLUlTIFZQTFMNCj4gPg0KPiA+IEhvdyBhYm91 dCBET0E/ICAoRGVhZCBPbiBBcnJpdmFsKQ0KPiA+DQo+ID4gU2VudCBmcm9tIG15IGlQaG9uZQ0K PiA+DQo+ID4NCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBM aW5kYSBEdW5iYXIgW21haWx0bzpsaW5kYS5kdW5iYXJAaHVhd2VpLmNvbV0NCj4gPiA+IFNlbnQ6 IE1vbmRheSwgQXByaWwgMzAsIDIwMTIgMTE6MDIgQU0NCj4gPiA+IFRvOiBMdWN5IHlvbmc7IEpv aG4gRSBEcmFrZTsgTWFjaCBDaGVuOyBHaWxlcyBIZXJvbjsgbDJ2cG5AaWV0Zi5vcmcNCj4gPiA+ IFN1YmplY3Q6IFJFOiBJbnRlcmVzdCBpbiBJUy1JUyBWUExTDQo+ID4gPg0KPiA+ID4gQWdyZWUg d2l0aCBMdWN5LCAgREMtVlBOIG1pZ2h0IGJlIGEgYmV0dGVyIG5hbWUuDQo+ID4gPg0KPiA+ID4g TGluZGENCj4gPiA+DQo+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+ IEZyb206IGwydnBuLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYu b3JnXSBPbg0KPiA+ID4gQmVoYWxmDQo+ID4gPiA+IE9mIEx1Y3kgeW9uZw0KPiA+ID4gPiBTZW50 OiBNb25kYXksIEFwcmlsIDMwLCAyMDEyIDEwOjM5IEFNDQo+ID4gPiA+IFRvOiBKb2huIEUgRHJh a2U7IE1hY2ggQ2hlbjsgR2lsZXMgSGVyb247IGwydnBuQGlldGYub3JnDQo+ID4gPiA+IFN1Ympl Y3Q6IFJFOiBJbnRlcmVzdCBpbiBJUy1JUyBWUExTDQo+ID4gPiA+DQo+ID4gPiA+IEpvaG4sDQo+ ID4gPiA+DQo+ID4gPiA+IElTLUlTIFZQTFMgaXMgY29tcGxldGVseSBkaWZmZXJlbnQgZnJvbSBU UklMTCBhbmQgU1BCIGFsdGhvdWdoDQo+ID4gPiA+IHRoZXkgYWxsIHVzZSBvZiBJUy1JUyBwcm90 b2NvbCBpbiBjb250cm9sIHBsYW5lLiBJUy1JUyBWUExTIGRhdGENCj4gPiA+ID4gcGxhbmUNCj4g PiA+IHVzZXMNCj4gPiA+ID4gYW4gSVAvR1JFIHR1bm5lbCBjYXJyeWluZyBWUE4gaW5zdGFuY2Vz IGRpZmZlcmVudGlhdGVkIGJ5IE1QTFMNCj4gPiA+IGxhYmVscy4NCj4gPiA+ID4gVFJJTEwgYW5k IFNQQiBkYXRhIHBsYW5lcyBhcmUgRXRoZXJuZXQgYmFzZWQsIGkuZS4gdGhlIGZyYW1lcyBhcmUN Cj4gPiA+ID4gRXRoZXJuZXQgZnJhbWVzLg0KPiA+ID4gPg0KPiA+ID4gPiBJc24ndCBpdCBnb29k IHRoYXQgb25lIGNvbnRyb2wgcGxhbmUgcHJvdG9jb2wgY2FuIGFwcGx5IHRvDQo+ID4gPiA+IGRp ZmZlcmVudCBkYXRhIHBsYW5lcz8NCj4gPiA+ID4NCj4gPiA+ID4gSSBhZ3JlZSB0aGF0IFZQTFMg aGFzIGJlZW4gd2VsbCBkZWZpbmVkIGFuZCB1c2VkIGluIFNlcnZpY2UNCj4gPiA+ID4gUHJvdmlk ZXIgbmV0d29ya3MuIElTLUlTIFZQTFMgcHJvdmlkZXMgdGhlIHNpbXBsaWZpZWQgdmVyc2lvbiBv Zg0KPiA+ID4gPiBWUExTIHRoYXQgY2FuIGFwcGx5IHRvIGRhdGEgY2VudGVyIG5ldHdvcmtzLiBU aGlzIG1heSBiZSBiZXR0ZXINCj4gPiA+ID4gdGhhbiBkZXZlbG9waW5nIHNvbWV0aGluZyBjb21w bGV0ZWx5IG5ldyBpbiBkYXRhIGNlbnRlci4NCj4gPiA+ID4NCj4gPiA+ID4gTWF5YmUgd2UgbmVl ZCBjb25zaWRlciBhbm90aGVyIG5hbWUgZm9yIHRoaXMsIGZvciBleGFtcGxlIERDLVZQTj8NCj4g PiA+ID4gSW4gZGF0YSBjZW50ZXIsIGFuIFZQTiBpcyBub3QgbmVjZXNzYXJ5IHRvIHByb3ZpZGUg YSBzZXJ2aWNlIHRvDQo+IGFuDQo+ID4gPiA+IGN1c3RvbWVyLCB0aGUgaW5mcmFzdHJ1Y3R1cmUg bmVlZCBWUE4gY2FwYWJpbGl0eS4NCj4gPiA+ID4NCj4gPiA+ID4gUmVnYXJkcywNCj4gPiA+ID4g THVjeQ0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiA+ID4gPiBGcm9tOiBKb2huIEUgRHJha2UgW21haWx0bzpqZHJha2VAanVu aXBlci5uZXRdDQo+ID4gPiA+IFNlbnQ6IE1vbmRheSwgQXByaWwgMzAsIDIwMTIgODoxMiBBTQ0K PiA+ID4gPiBUbzogTWFjaCBDaGVuOyBMdWN5IHlvbmc7IEdpbGVzIEhlcm9uOyBsMnZwbkBpZXRm Lm9yZw0KPiA+ID4gPiBTdWJqZWN0OiBSRTogSW50ZXJlc3QgaW4gSVMtSVMgVlBMUw0KPiA+ID4g Pg0KPiA+ID4gPiBXZSBhbHJlYWR5IGhhdmUgVFJJTEwgYW5kIFNQQi4gIFdoeSBpcyB5ZXQgYW5v dGhlciBJUy1JUyB2YXJpYW50DQo+ID4gPiA+IG5lY2Vzc2FyeSwgcGFydGljdWxhcmx5IG9uZSB0 aGF0IGlzIHNvIGNvbXBsZXRlbHkgdW5kZXItDQo+IHNwZWNpZmllZD8NCj4gPiA+ID4NCj4gPiA+ ID4gU2VudCBmcm9tIG15IGlQaG9uZQ0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiA+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+ID4gRnJvbTogbDJ2cG4tYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+ID4gPiA+IEJlaGFsZg0K PiA+ID4gPiA+IE9mIE1hY2ggQ2hlbg0KPiA+ID4gPiA+IFNlbnQ6IFNhdHVyZGF5LCBBcHJpbCAy OCwgMjAxMiAzOjA0IEFNDQo+ID4gPiA+ID4gVG86IEx1Y3kgeW9uZzsgR2lsZXMgSGVyb247IGwy dnBuQGlldGYub3JnDQo+ID4gPiA+ID4gU3ViamVjdDogUkU6IEludGVyZXN0IGluIElTLUlTIFZQ TFMNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEZ1bGx5IGFncmVlIHdpdGggbHVjeSBoZXJlLg0KPiA+ ID4gPiA+DQo+ID4gPiA+ID4gSW4gYWRkaXRpb24sIHNpbmNlIHRoZSBJU0lTIFZQTFMgbGV2ZXJh Z2VzIGEgdW5pZm9ybQ0KPiA+ID4gPiA+IHByb3RvY29sKElTSVMpDQo+ID4gPiA+IGZvcg0KPiA+ ID4gPiA+IHNpZ25hbGluZyBhbmQgYXV0byBkaXNjb3ZlcnksIGl0IHdvdWxkIGdyZWF0bHkgc2lt cGxpZnkgdGhlDQo+ID4gPiA+IGRlcGxveW1lbnQNCj4gPiA+ID4gPiBhbmQgbWFpbnRlbmFuY2Us IGVzcGVjaWFsbHkgZm9yIHRoZSBEQyBuZXR3b3JrcyB0aGF0IGhhdmUNCj4gPiA+ID4gPiBhbHJl YWR5IGRlcGxveWVkIElTSVMgZm9yIElQIHJvdXRpbmcuIFNvIEknZCBsaWtlIHRvIHNlZSB0aGUN Cj4gPiA+ID4gPiBkcmFmdCBtb3ZpbmcgZm9yd2FyZC4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEJl c3QgcmVnYXJkcywNCj4gPiA+ID4gPiBNYWNoDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+ID4gPiBGcm9tOiBsMnZwbi1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZ10NCj4gPiA+ID4gPiA+IE9uDQo+ ID4gPiA+ID4gQmVoYWxmDQo+ID4gPiA+ID4gPiBPZiBMdWN5IHlvbmcNCj4gPiA+ID4gPiA+IFNl bnQ6IFNhdHVyZGF5LCBBcHJpbCAyOCwgMjAxMiAyOjQzIEFNDQo+ID4gPiA+ID4gPiBUbzogR2ls ZXMgSGVyb247IGwydnBuQGlldGYub3JnDQo+ID4gPiA+ID4gPiBTdWJqZWN0OiBSRTogSW50ZXJl c3QgaW4gSVMtSVMgVlBMUw0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IEhpIEdpbGVzLA0KPiA+ ID4gPiA+ID4NCj4gPiA+ID4gPiA+IEl0IHNlZW1zIHRoYXQgdGhlIElTLUlTIFZQTFMgcHJvdmlk ZXMgdGhlIHNvbHV0aW9uIGZvciBhDQo+ID4gPiA+ID4gPiBzY2FsYWJsZQ0KPiA+ID4gPiA+IGRh dGENCj4gPiA+ID4gPiA+IGNlbnRlciBuZXR3b3JrIGFzIG1lbnRpb25lZCBpbiB0aGUgZHJhZnQu IEkgYW0gbm90IHN1cmUgaXQgaXMNCj4gPiA+ID4gcHJvcGVyDQo+ID4gPiA+ID4gPiB0byB3ZWln aHQgc2VydmljZSBwcm92aWRlcnMgbW9yZSBvbiB0aGlzLiBJIGNhbiBzZWUgaWYgYQ0KPiA+ID4g PiA+ID4gc2VydmljZSBwcm92aWRlciBhbHJlYWR5IGRlcGxveWVkIGV4aXN0aW5nIFZQTFMsIHRo ZSBnYWluDQo+IGZyb20NCj4gPiA+ID4gPiA+IElTLUlTIFZQTFMNCj4gPiA+ID4gaXMNCj4gPiA+ ID4gPiA+IGxlc3MgdGhhbiB0aGUgY29zdCBvbiB1cGdyYWRpbmcgYWxsIHRoZSBlZGdlIGRldmlj ZXMgdG8NCj4gPiA+ID4gPiA+IHN1cHBvcnQgdGhlDQo+ID4gPiA+ID4gc29sdXRpb24uDQo+ID4g PiA+ID4gPg0KPiA+ID4gPiA+ID4gSG93ZXZlciwgZm9yIGRhdGEgY2VudGVyIG5ldHdvcmssIElT LUlTIFZQTFMgY291bGQgYmUgYQ0KPiB1c2VmdWwNCj4gPiA+ID4gPiA+IHNvbHV0aW9uLiBJdCBz aW1wbGlmaWVzIGN1cnJlbnQgVlBMUyBtZWNoYW5pc20sIHByb3ZpZGVzIGENCj4gPiA+ID4gPiA+ IGdvb2Qgc2NhbGFiaWxpdHksIGFuZCByZXF1aXJlcyBJUCBvbmx5IGZ1bmN0aW9uIG9uIGNvcmUN Cj4gc3dpdGNoZXMuDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gQSB2ZW5kb3IgcHJvdmlkZXMg ZGV2aWNlcyBmb3IgYm90aCBzZXJ2aWNlIHByb3ZpZGVyIG5ldHdvcmsNCj4gPiA+ID4gPiA+IGFu ZA0KPiA+ID4gPiBkYXRhDQo+ID4gPiA+ID4gPiBjZW50ZXIgbmV0d29yaywgdGhlIHNvbHV0aW9u IGJyaW5ncyBhIHN5bmVyZ3kgaW4gbGV2ZXJhZ2luZw0KPiA+ID4gPiA+ID4gVlBMUyBzb2x1dGlv biBpbnRvIERDLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IFRodXMsIEkgbGlrZSB0byBzZWUg dGhpcyB3b3JrIG1vdmluZyBmb3J3YXJkLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IFJlZ2Fy ZHMsDQo+ID4gPiA+ID4gPiBMdWN5DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4g PiA+DQo+ID4gPiA+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPiA+ID4g RnJvbTogbDJ2cG4tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5v cmddDQo+ID4gPiA+ID4gPiBPbg0KPiA+ID4gPiA+IEJlaGFsZg0KPiA+ID4gPiA+ID4gT2YgR2ls ZXMgSGVyb24NCj4gPiA+ID4gPiA+IFNlbnQ6IEZyaWRheSwgQXByaWwgMjcsIDIwMTIgNzo1NyBB TQ0KPiA+ID4gPiA+ID4gVG86IGwydnBuQGlldGYub3JnDQo+ID4gPiA+ID4gPiBTdWJqZWN0OiBJ bnRlcmVzdCBpbiBJUy1JUyBWUExTDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gSGksDQo+ID4g PiA+ID4gPg0KPiA+ID4gPiA+ID4gQXQgdGhlIElFVEYgbWVldGluZyBpbiBQYXJpcyBJIHRvb2sg YW4gYWN0aW9uIChhcyBub3RlZCBpbg0KPiB0aGUNCj4gPiA+ID4gPiA+IG1pbnV0ZXMpIHRvIHBv bGwgdGhlIFdHIHRvIHNlZSBpZiB0aGVyZSB3YXMgYW55IGludGVyZXN0DQo+ID4gPiA+ID4gPiAo b3RoZXINCj4gPiA+ID4gdGhhbg0KPiA+ID4gPiA+ID4gYnkgdGhlIGF1dGhvcnMgb2YNCj4gPiA+ ID4gPiA+IGNvdXJzZSkgaW4gcHJvZ3Jlc3NpbmcgdGhlIElTLUlTIFZQTFMgZHJhZnQuDQo+ID4g PiA+ID4gPg0KPiA+ID4gPiA+ID4gV291bGQgeW91IHBsZWFzZSByZXNwb25kIHRvIHRoaXMgZW1h aWwgaW5kaWNhdGluZyB3aGV0aGVyIG9yDQo+ID4gPiA+ID4gPiBub3QNCj4gPiA+ID4geW91DQo+ ID4gPiA+ID4gPiBoYXZlIGludGVyZXN0IGluIHNlZWluZyB0aGlzIGRyYWZ0IHByb2dyZXNzLCBp ZGVhbGx5IGdpdmluZw0KPiA+ID4gPiByZWFzb25pbmcNCj4gPiA+ID4gPiA+IGZvciB5b3VyIHBv c2l0aW9uLiAgSXQnZCBiZSBlc3BlY2lhbGx5IGludGVyZXN0aW5nIHRvIHNlZQ0KPiA+ID4gPiA+ ID4gcmVzcG9uc2VzIGZyb20gc2VydmljZSBwcm92aWRlcnMgb2YgY291cnNlLg0KPiA+ID4gPiA+ ID4NCj4gPiA+ID4gPiA+IElmIHRoZXJlIGFyZSBubyAob3IgdmVyeSBmZXcpIHJlc3BvbnNlcyB0 byB0aGlzIGVtYWlsIHRoZW4NCj4gPiA+ID4gPiA+IE5hYmlsDQo+ID4gPiA+IGFuZA0KPiA+ID4g PiA+IEkNCj4gPiA+ID4gPiA+IHdpbGwgcHJvYmFibHkgaW50ZXJwcmV0IHRoYXQgYXMgbWVhbmlu ZyB0aGVyZSdzIGluc3VmZmljaWVudA0KPiA+ID4gPiBpbnRlcmVzdA0KPiA+ID4gPiA+ID4gdG8g cHJvZ3Jlc3MuICBPZiBjb3Vyc2UgaXQgbWF5IGp1c3QgbWVhbiB0aGF0IHlvdSBhbGwgbWlzc2Vk DQo+ID4gPiA+ID4gPiB0aGlzIGVtYWlsIGluIHRoZSBkZWx1Z2Ugb2YgZGViYXRlIG9uIEUtVHJl ZSA7KQ0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IEdpbGVzDQo+ID4gPiA+ID4gPg0KDQo= From jdrake@juniper.net Wed May 2 10:29: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 D553821E801B for ; Wed, 2 May 2012 10:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.466 X-Spam-Level: X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=0.133, 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 JRr5Ky1CujmW for ; Wed, 2 May 2012 10:29:46 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id E584A11E809F for ; Wed, 2 May 2012 10:29:45 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKT6FvB5dsZ5pcwJ5IhBjArK1S52thWH1+@postini.com; Wed, 02 May 2012 10:29:45 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 2 May 2012 10:28:26 -0700 From: John E Drake To: Mingui Zhang , Lucy yong , Mach Chen , Giles Heron , "l2vpn@ietf.org" Date: Wed, 2 May 2012 10:28:22 -0700 Subject: RE: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0kdUdSO48LuIhSPkS8Et2e3RTHugAJ0cmQABqEpVAAcwK+MAAEDOFgAEt9zQAAHXTFQA== Message-ID: <5E893DB832F57341992548CDBB333163A577283BB4@EMBX01-HQ.jnpr.net> References: <2691CE0099834E4A9C5044EEC662BB9D3264C7F8@dfweml505-mbx> <5E893DB832F57341992548CDBB333163A56EEDE9C5@EMBX01-HQ.jnpr.net> <2691CE0099834E4A9C5044EEC662BB9D330E4B68@dfweml505-mbx> <4552F0907735844E9204A62BBDD325E728CD336A@SZXEML507-MBS.china.huawei.com> In-Reply-To: <4552F0907735844E9204A62BBDD325E728CD336A@SZXEML507-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="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, 02 May 2012 17:29:46 -0000 Mingui, This completely misses the point. I have yet to hear anyone say that IS-IS= VPLS can do anything that SPB or TRILL cannot. Given that they exist and that IS-IS VPLS does not, why would should we wor= k an yet another solution? Asserting that it performs the same function in= a different way seems to be a less than compelling rationalization. Thanks, John Sent from my iPhone > -----Original Message----- > From: Mingui Zhang [mailto:zhangmingui@huawei.com] > Sent: Tuesday, May 01, 2012 8:23 PM > To: Lucy yong; John E Drake; Mach Chen; Giles Heron; l2vpn@ietf.org > Subject: RE: Interest in IS-IS VPLS >=20 > Hi, >=20 > Conceptually, TRILL/SPB/ISIS-VPLS are all "L2VPN" techniques. They all > leverage ISIS as the control plane but utilize different silicon. SPB > tries to utilize existing Ethernet-silicon. TRILL develops a new data > plane and there are several vendors who would like to support this with > new "TRILL-silicon". Except TRILL/SPB, there is a blue ocean where one > can utilize existing IP/MPLS silicon. I agree with Lucy that their > differences in control plane are trivial while the differences in data > plane really distinguish them . >=20 > Thanks, > Mingui >=20 > > -----Original Message----- > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > Behalf Of > > Lucy yong > > Sent: Monday, April 30, 2012 11:39 PM > > 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 agmalis@gmail.com Wed May 2 12:10: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 9390B21E8088 for ; Wed, 2 May 2012 12:10:40 -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 2SOyXIHELbI8 for ; Wed, 2 May 2012 12:10:40 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id F41C221E8083 for ; Wed, 2 May 2012 12:10:39 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1240610ghb.31 for ; Wed, 02 May 2012 12:10:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=63BSZv1jnGLgFOxPBU8GUav+xQwrtH4KEodHMv0BJqc=; b=izblxRn4crZykxRwUr+jgAwnUf5o5Sp6FZdMPfR7gVRJoUqOg5tlqOkEbmMj8oiDIi r74/Xekx4RhEqqBDcvYnhwUnSz9dAr8bFQL+HIAyY2F5uPm+yMzGWUAVW5oXeZvLzAW9 KlI68QLABcVif8lFYUMyLF6NcaSu5GxmRS0TPED79XO7YsdbN1xT9Y+rp5kW3dPobOvX r48oXySLEWNfeIiyrQgBTtH76yliq6tf+HJ0/r55NPskQs5xTz67uOYHspuyJ9JO3ujz 0KLvxuoHb/nQ/tKUc/G2z97lQeUWvqpg5zx5RyHa5s4bmnsmsWaaIt7REX8WVvVbGdjE msMw== Received: by 10.50.179.104 with SMTP id df8mr6191004igc.11.1335985839233; Wed, 02 May 2012 12:10:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.184.231 with HTTP; Wed, 2 May 2012 12:10:19 -0700 (PDT) In-Reply-To: References: From: "Andrew G. Malis" Date: Wed, 2 May 2012 15:10:19 -0400 Message-ID: Subject: Re: Interest in IS-IS VPLS To: Lizhong Jin Content-Type: text/plain; charset=GB2312 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, 02 May 2012 19:10:40 -0000 This "service provider person" agrees with Lizhong, let's wait for NVO3 to figure out the problem it's trying to solve, and the resulting protocol requirements. Only then should we start proposing solutions, existing or new, to meet those requirements. Cheers, Andy On Wed, May 2, 2012 at 10:46 AM, Lizhong Jin wrote: > > Hi Giles, > I am not interested in seeing this draft progress. > Since ISIS VPLS is mainly trying to solve the datacenter problem, then it > should belong to NVO3. The NVO3 WG now only starts problem statement, but > this should not be the reason why ISIS VPLS belong to L2VPN WG. Since it is > a solution, we should wait to see if ISIS VPLS really solves the datacenter > problem, and right now, it is time to contribute to the NVO3 problem > statement. > > Lizhong > > >> ---------------------------------------------------------------------- >> >> 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 >> >> >> >> From vishwas.ietf@gmail.com Wed May 2 12:58: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 389E421E80C5 for ; Wed, 2 May 2012 12:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.479 X-Spam-Level: X-Spam-Status: No, score=-3.479 tagged_above=-999 required=5 tests=[AWL=0.119, 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 C++4VrRu4nRO for ; Wed, 2 May 2012 12:58:11 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6BAF621E80C0 for ; Wed, 2 May 2012 12:58:11 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so1642087obb.31 for ; Wed, 02 May 2012 12:58:11 -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=7ev09+fXp3N0MSIumB1JFxDxx7iK7nFjvS4mUb18n08=; b=i2gvl1tvj2/61YkScN1ru55IzoMcK6I6+Pk/ey09j3H1M1dSPqKYv3923lKP7DB8HK Q0dHwrC6K5vgzWMurYwpzUNS7mEw7MTbCEeJxEF7ehApx1m+EN32dX/biTCMhp8c7Q2b JcdSTpf0p2baPOX4RoimgGT0CarDCnNhQvXGYQNtFfZhRZKvQQcI2NvflKYkKvDYXcYL 5myr8c1SJrwjzpGFwv+iAFa4Ybpo29xP2FF5rvLp3hywtrJnAJOWynJAzMrGHfAkIm3z mMl40DqOauYe7sOQPvfuLtbEn0Nf/tmc71TxRmrBaaZAJP6Z5XbhNG2argNYfFeRB4Hv gcwQ== MIME-Version: 1.0 Received: by 10.182.111.39 with SMTP id if7mr17556953obb.55.1335988690971; Wed, 02 May 2012 12:58:10 -0700 (PDT) Received: by 10.182.19.201 with HTTP; Wed, 2 May 2012 12:58:10 -0700 (PDT) In-Reply-To: References: <2691CE0099834E4A9C5044EEC662BB9D3264C7F8@dfweml505-mbx> Date: Wed, 2 May 2012 12:58:10 -0700 Message-ID: Subject: Re: Interest in IS-IS VPLS From: Vishwas Manral To: Mach Chen Content-Type: multipart/alternative; boundary=14dae9399087596cab04bf131b2b 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, 02 May 2012 19:58:12 -0000 --14dae9399087596cab04bf131b2b Content-Type: text/plain; charset=ISO-8859-1 Hi Giles, I would agree here too. I would like to see this work progress ahead as well. Thanks, Vishwas On Sat, Apr 28, 2012 at 3:04 AM, Mach Chen wrote: > 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 > > > > --14dae9399087596cab04bf131b2b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Giles,

I would agree here too. I would like to see this work prog= ress ahead as well.

Thanks,
Vishwas

On Sat, Apr 28, 2012 at 3:04 AM, Mach Chen <mach.chen@huawei.com<= /a>> wrote:
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.o= rg] On Behalf
> Of Lucy yong
> Sent: Saturday, April 28, 2012 2:43 AM
> To: Giles Heron; l2vpn@ietf.org<= br> > 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 weigh= t
> service providers more on this. I can see if a service provider alread= y
> 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 solutio= n. 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 solut= ion
> into DC.
>
> Thus, I like to see this work moving forward.
>
> Regards,
> Lucy
>
>
>
> -----Original Message-----
> From: l2vpn-bounces@ietf.org= [mailto:l2vpn-bounces@ietf.o= rg] 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 author= s 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 y= our
> position. =A0It'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 t= o
> progress. =A0Of course it may just mean that you all missed this email= in the
> deluge of debate on E-Tree ;)
>
> Giles
>


--14dae9399087596cab04bf131b2b-- From giles.heron@gmail.com Wed May 2 13:37: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 B045C21E810C for ; Wed, 2 May 2012 13:37:39 -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 uRpOkO0Zawqh for ; Wed, 2 May 2012 13:37:39 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id D448121E80E7 for ; Wed, 2 May 2012 13:37:38 -0700 (PDT) Received: by wibhr17 with SMTP id hr17so4412538wib.1 for ; Wed, 02 May 2012 13:37:38 -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=QhNZ6WD0VrtngnJxddvXyB4t2f4ctk1tKmOnrL6H38g=; b=on56Af+CNFsEqFNrKB7DwghTsBCKvhNL5aYtO8pJpN4PrMviaqvIiTSiKfjgnYGERf QU7AAnqEsB8MVQFlnqbNBav56cGCkKZIyWEk64UBj+kfk5af3xYEGZMs9e2oMUV+hr8d JP7pzqFdAwJdHKf5JHuCdeySDOtmRo/+yIcb+MGB2eCnA654vrRipwYBY4eMSr4GUQzW wGalzqskV7Cv5w5Vc394Vtpne/TBEJyb1QloiKiToHMx3m9xm+x0EB3/7TUy9Ft4fiZ2 fogagcteSMxqqz5KJdQxeF5lWo2Qx0Y/7Mjjbg5D2Dx78RUxaF96TFC46oa9O3Fi62KK sg+g== Received: by 10.180.91.10 with SMTP id ca10mr1943018wib.17.1335991057750; Wed, 02 May 2012 13:37:37 -0700 (PDT) Received: from [10.55.89.41] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id h8sm10255597wix.4.2012.05.02.13.37.33 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 May 2012 13:37:36 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 02 May 2012 21:37:53 +0100 Subject: Re: Interest in IS-IS VPLS From: Giles Heron To: Vishwas Manral , Mach Chen Message-ID: Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0oo3KJ1wSZdtM/HEigFxRLQ5av6A== In-Reply-To: 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, 02 May 2012 20:37:39 -0000 Interesting. As someone who has his name on various TRILL drafts what's your thinking on the relationship between ISIS VPLS and TRILL? Giles On 02/05/2012 20:58, "Vishwas Manral" wrote: > Hi Giles, > > I would agree here too. I would like to see this work progress ahead as > well. > > Thanks, > Vishwas > > On Sat, Apr 28, 2012 at 3:04 AM, Mach Chen wrote: > >> 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 Wed May 2 14:10:14 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01F7411E809B for ; Wed, 2 May 2012 14:10:14 -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 0uDm-kNWwRCf for ; Wed, 2 May 2012 14:10:13 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id D9EAB11E808F for ; Wed, 2 May 2012 14:10:12 -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 AFT82095; Wed, 02 May 2012 17:10:12 -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, 2 May 2012 14:07:23 -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, 2 May 2012 14:07:15 -0700 From: Lucy yong To: Giles Heron , Vishwas Manral , Mach Chen Subject: RE: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0kdUdSO48LuIhSPkS8Et2e3RTHugAJ0cmQABqEpVAA9HxfAAABYxiAAA4B/eA= Date: Wed, 2 May 2012 21:07:15 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D330E8A73@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.154.40] 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, 02 May 2012 21:10:14 -0000 I share my 2 cents. >From the technology perspective, IS-IS VPLS and TRILL are two different tec= hnologies. From the applicability perspective, TRILL applies to enterprise = DC and campus; IS-IS VPLS can apply to multi-tenant required and larger sca= le DCs that provides the services to enterprise customers. I personally do not work on TRILL technology and like to see others' opinio= n. Lucy=20 -----Original Message----- From: Giles Heron [mailto:giles.heron@gmail.com]=20 Sent: Wednesday, May 02, 2012 3:38 PM To: Vishwas Manral; Mach Chen Cc: Lucy yong; l2vpn@ietf.org Subject: Re: Interest in IS-IS VPLS Interesting. As someone who has his name on various TRILL drafts what's your thinking on the relationship between ISIS VPLS and TRILL? Giles On 02/05/2012 20:58, "Vishwas Manral" wrote: > Hi Giles, >=20 > I would agree here too. I would like to see this work progress ahead as > well. >=20 > Thanks, > Vishwas >=20 > On Sat, Apr 28, 2012 at 3:04 AM, Mach Chen wrote: >=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 a= nd >> maintenance, especially for the DC networks that have already deployed I= SIS >> 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 soluti= on >>> 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 yo= ur >>> 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 >>=20 From gregory.mirsky@ericsson.com Wed May 2 14:41: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 34F9D11E80CB for ; Wed, 2 May 2012 14:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.435 X-Spam-Level: X-Spam-Status: No, score=-6.435 tagged_above=-999 required=5 tests=[AWL=0.164, 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 pYAeu-muv475 for ; Wed, 2 May 2012 14:41:50 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7983A11E80BD for ; Wed, 2 May 2012 14:41:50 -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 q42LfcM6004237; Wed, 2 May 2012 16:41:48 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.10]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 2 May 2012 17:41:43 -0400 From: Gregory Mirsky To: Lucy yong Date: Wed, 2 May 2012 17:41:40 -0400 Subject: RE: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0kdUdSO48LuIhSPkS8Et2e3RTHugAJ0cmQABqEpVAA9HxfAAABYxiAAA4B/eAAGyNsMA== Message-ID: References: <2691CE0099834E4A9C5044EEC662BB9D330E8A73@dfweml505-mbx> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D330E8A73@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: Wed, 02 May 2012 21:41:51 -0000 Dear Lucy, I'm intrigued how IS-IS VPLS would address scaling requirements outlined in= NVO3 charter when its TLV is limited to 255 bytes and thus can carry only = up to 30 VPLS ID-VPLS Labels tuples. Wouldn't OSPF Opaque LSA scale better?= Or BGP? What is the overwhelming benefit, technically speaking, of IS-IS VPLS propo= sal vs. BGP E-VPN? Regards, Greg -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of L= ucy yong Sent: Wednesday, May 02, 2012 2:07 PM To: Giles Heron; Vishwas Manral; Mach Chen Cc: l2vpn@ietf.org Subject: RE: Interest in IS-IS VPLS I share my 2 cents. >From the technology perspective, IS-IS VPLS and TRILL are two different tec= hnologies. From the applicability perspective, TRILL applies to enterprise = DC and campus; IS-IS VPLS can apply to multi-tenant required and larger sca= le DCs that provides the services to enterprise customers. I personally do not work on TRILL technology and like to see others' opinio= n. Lucy=20 -----Original Message----- From: Giles Heron [mailto:giles.heron@gmail.com] Sent: Wednesday, May 02, 2012 3:38 PM To: Vishwas Manral; Mach Chen Cc: Lucy yong; l2vpn@ietf.org Subject: Re: Interest in IS-IS VPLS Interesting. As someone who has his name on various TRILL drafts what's your thinking on= the relationship between ISIS VPLS and TRILL? Giles On 02/05/2012 20:58, "Vishwas Manral" wrote: > Hi Giles, >=20 > I would agree here too. I would like to see this work progress ahead=20 > as well. >=20 > Thanks, > Vishwas >=20 > On Sat, Apr 28, 2012 at 3:04 AM, Mach Chen wrote: >=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 movin= g forward. >>=20 >> Best regards, >> Mach >>=20 >>> -----Original Message----- >>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On=20 >>> 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=20 >>> data >> center >>> network as mentioned in the draft. I am not sure it is proper to=20 >>> 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 sol= ution. >>>=20 >>> However, for data center network, IS-IS VPLS could be a useful solution= . >> It >>> simplifies current VPLS mechanism, provides a good scalability, and=20 >>> requires IP only function on core switches. >>>=20 >>> 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. >>>=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=20 >>> 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=20 >>> minutes) >> to >>> poll the WG to see if there was any interest (other than by the=20 >>> authors >> of >>> course) in progressing the IS-IS VPLS draft. >>>=20 >>> 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. >>>=20 >>> If there are no (or very few) responses to this email then Nabil and=20 >>> I >> will >>> probably interpret that as meaning there's insufficient interest to=20 >>> progress. Of course it may just mean that you all missed this email=20 >>> in >> the >>> deluge of debate on E-Tree ;) >>>=20 >>> Giles >>>=20 >>=20 >>=20 From vishwas.ietf@gmail.com Wed May 2 15:06: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 9A84211E80AE for ; Wed, 2 May 2012 15:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.494 X-Spam-Level: X-Spam-Status: No, score=-3.494 tagged_above=-999 required=5 tests=[AWL=0.104, 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 0dArbYBBLgjM for ; Wed, 2 May 2012 15:06:51 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 951FA11E808F for ; Wed, 2 May 2012 15:06:51 -0700 (PDT) Received: by yhq56 with SMTP id 56so1457776yhq.31 for ; Wed, 02 May 2012 15:06:51 -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=At+LgpG1JPAb9e8zd+sxsFVOOjSxjUKDnknY0hOQL3o=; b=FABf3oauYwYr4WbwDT9BRipd85Ihixzff6KeyjH7/hVP5CcLfzP0OMGLrjIezged6j iltqinErz4GZuU2a4QRV88ePPeMNp21Rn4NaRhviPiqzt+Ddyk7ztHjMy5nMIJWe71b5 k7hTHei+SeYoOvy7kAfuTGdFocDnQeVO6TCBD0moAgALuBCnJfIbt22zgeGs/TS1+M1O /iKq2jR8fB66D6bTh+zghhcAAd+a3V7ZcX0hYeDi590gNr4Um7+ef9EQlbpG0I3HGCWk FRPR4xwwSvgUpFIy+BSBTnlalzyG5KxJ2RB3YV79CgKZkqqs4u8105GKYAY4gf0IuzYp CsuA== MIME-Version: 1.0 Received: by 10.60.14.4 with SMTP id l4mr41541852oec.39.1335996411062; Wed, 02 May 2012 15:06:51 -0700 (PDT) Received: by 10.182.19.201 with HTTP; Wed, 2 May 2012 15:06:50 -0700 (PDT) In-Reply-To: References: Date: Wed, 2 May 2012 15:06:50 -0700 Message-ID: Subject: Re: Interest in IS-IS VPLS From: Vishwas Manral To: Giles Heron Content-Type: multipart/alternative; boundary=e89a8fb1f54680aab904bf14e7b4 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, 02 May 2012 22:06:52 -0000 --e89a8fb1f54680aab904bf14e7b4 Content-Type: text/plain; charset=ISO-8859-1 Hi Giles, I did not make the TRILL to VPLS connection, as clearly as you probably did. I may be wrong, but my thought is if TRILL is to be used between DC's, we will have the CE devices communicating directly (in an overlay). The draft seems to be talking about PE devices, connecting over IP core. We could use L2TP/ GRE tunnels between the PE and use an IS-IS VPLS draft defined mechanism to encapsulate packets. We could ofcourse use an MPLS based solution in the core to achieve the same thing, we could use TRILL for Layer-2 core, we could also use solutions like EVN from Cisco for IP core, or we could use overlays which the IS-IS VPLS solution provides. Am I missing the point? Thanks, Vishwas On Wed, May 2, 2012 at 1:37 PM, Giles Heron wrote: > Interesting. > > As someone who has his name on various TRILL drafts what's your thinking on > the relationship between ISIS VPLS and TRILL? > > Giles > > On 02/05/2012 20:58, "Vishwas Manral" wrote: > > > Hi Giles, > > > > I would agree here too. I would like to see this work progress ahead as > > well. > > > > Thanks, > > Vishwas > > > > On Sat, Apr 28, 2012 at 3:04 AM, Mach Chen wrote: > > > >> 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 > >>> > >> > >> > > > --e89a8fb1f54680aab904bf14e7b4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Giles,

I did not make the TRILL to VPLS connection, as clearly as= you probably did.

I may be wrong, but my thought is if TRILL is to = be used between DC's, we will have the CE devices communicating directl= y (in an overlay). The draft seems to be talking about PE devices, connecti= ng over IP core. We could use L2TP/ GRE tunnels between the PE and use an I= S-IS VPLS draft defined mechanism to encapsulate packets.

We could ofcourse use an MPLS based solution in the core to achieve the= same thing, we could use TRILL for Layer-2 core, we could also use solutio= ns like EVN from Cisco for IP core, or we could use overlays which the IS-I= S VPLS solution provides.

Am I missing the point?

Thanks,
Vishwas

On Wed, May 2, 2012 at 1:37 PM, Giles Heron = <giles.heron@= gmail.com> wrote:
Interesting.

As someone who has his name on various TRILL drafts what's your thinkin= g on
the relationship between ISIS VPLS and TRILL?

Giles

On 02/05/2012 20:58, "Vishwas Manral" <vishwas.ietf@gmail.com> wrote:

> Hi Giles,
>
> I would agree here too. I would like to see this work progress ahead a= s
> well.
>
> Thanks,
> Vishwas
>
> On Sat, Apr 28, 2012 at 3:04 AM, Mach Chen <mach.chen@huawei.com> wrote:
>
>> 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 deploy= ment and
>> maintenance, especially for the DC networks that have already depl= oyed 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-bounce= s@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 scala= ble 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 provide= r 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 an= d data
>>> center network, the solution brings a synergy in leveraging VP= LS solution
>>> into DC.
>>>
>>> Thus, I like to see this work moving forward.
>>>
>>> Regards,
>>> Lucy
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: l2vpn-bounces@= ietf.org [mailto:l2vpn-bounce= s@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 th= e authors
>> of
>>> course) in progressing the IS-IS VPLS draft.
>>>
>>> Would you please respond to this email indicating whether or n= ot you
>>> have
>>> interest in seeing this draft progress, ideally giving reasoni= ng for your
>>> position. =A0It'd be especially interesting to see respons= es from service
>>> providers of course.
>>>
>>> If there are no (or very few) responses to this email then Nab= il and I
>> will
>>> probably interpret that as meaning there's insufficient in= terest to
>>> progress. =A0Of course it may just mean that you all missed th= is email in
>> the
>>> deluge of debate on E-Tree ;)
>>>
>>> Giles
>>>
>>
>>



--e89a8fb1f54680aab904bf14e7b4-- From giles.heron@gmail.com Wed May 2 15:24: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 BCAB611E80C1 for ; Wed, 2 May 2012 15:24:06 -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 EAVhjuJcrgFs for ; Wed, 2 May 2012 15:24:06 -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 92D6011E809B for ; Wed, 2 May 2012 15:24:05 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so782891wgb.13 for ; Wed, 02 May 2012 15:24:04 -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=fX9FqNEYo0rZm1LbXHcR+kfLMxSLkc/cZCZ4SdgxOX4=; b=0mxnnxdIVfJvt1KieIt8aijtTxn/RPyZzRrMy8nlNkBMRVPz9n2u1xEsoJreOln34h kYGNmNpIuiUqnMH/gT8mEgd7VTskfuNk4IDQ1d0jwyTdURm/Tx3r8fQELdiX0THRY8d8 cFD7IgNf7dgepsWAZwdHBWHWBj0ZIQ8R535BnUt2QR0bxQihAYFmmuofn8IoBMQuiza8 AvkcLNZeG+ShOQV5sDbdLKPgkr7+MQst2st5U0mZkleSG6O9s/0DILSjm83gEoCxYtGM 4uHIvyVroJdPibkB5rAlUAJxom+aPL88goLX5qH3xRnjr6HSrYU8jcnZiOGmjyczC5Cr dU3Q== Received: by 10.216.133.96 with SMTP id p74mr18409250wei.30.1335997443689; Wed, 02 May 2012 15:24:03 -0700 (PDT) Received: from [192.168.1.7] (host217-41-3-38.in-addr.btopenworld.com. [217.41.3.38]) by mx.google.com with ESMTPS id l5sm47219913wia.11.2012.05.02.15.23.58 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 May 2012 15:24:02 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 02 May 2012 23:24:28 +0100 Subject: Re: Interest in IS-IS VPLS From: Giles Heron To: Vishwas Manral Message-ID: Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0oslZAsSwhOt7dfUGmi4hyMdvfnw== In-Reply-To: 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, 02 May 2012 22:24:06 -0000 Hi Vishwas, I guess I made the TRILL/IS-IS VPLS connection based on earlier comments in the thread suggesting that there was no need for a third ISIS-controlled data-centre technology. I suppose I'd see the TRILL/IS-IS VPLS differences as: 1) TRILL runs over a flat address space (TRILL nicknames) so you can't use route aggregation in the core (whereas IS-IS VPLS runs over IP). Not sure that's an issue other than in the very largest data centres (and the TRILL nickname approach has benefits in auto-configuration etc.) 2) TRILL (IIRC) is designed around a flat VLAN space whereas VPN solutions like IS-IS VPLS tend to be better at supporting multi-tenancy. Would you agree? So it might be that we're better off comparing IS-IS VPLS to LDP/BGP VPLS (I guess we've did a lot of that in the Paris meeting, and consensus in the meeting at least seemed to be that there was no need for a third flavour of VPLS) or to the NVO3 solution space (not that the NVO3 WG has got to solutions yet). Giles On 02/05/2012 23:06, "Vishwas Manral" wrote: > Hi Giles, > > I did not make the TRILL to VPLS connection, as clearly as you probably did. > > I may be wrong, but my thought is if TRILL is to be used between DC's, we > will have the CE devices communicating directly (in an overlay). The draft > seems to be talking about PE devices, connecting over IP core. We could use > L2TP/ GRE tunnels between the PE and use an IS-IS VPLS draft defined > mechanism to encapsulate packets. > > We could ofcourse use an MPLS based solution in the core to achieve the > same thing, we could use TRILL for Layer-2 core, we could also use > solutions like EVN from Cisco for IP core, or we could use overlays which > the IS-IS VPLS solution provides. > > Am I missing the point? > > Thanks, > Vishwas > > On Wed, May 2, 2012 at 1:37 PM, Giles Heron wrote: > >> Interesting. >> >> As someone who has his name on various TRILL drafts what's your thinking on >> the relationship between ISIS VPLS and TRILL? >> >> Giles >> >> On 02/05/2012 20:58, "Vishwas Manral" wrote: >> >>> Hi Giles, >>> >>> I would agree here too. I would like to see this work progress ahead as >>> well. >>> >>> Thanks, >>> Vishwas >>> >>> On Sat, Apr 28, 2012 at 3:04 AM, Mach Chen wrote: >>> >>>> 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 tnadeau@lucidvision.com Wed May 2 16:08: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 6593011E808D for ; Wed, 2 May 2012 16:08:24 -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=[AWL=0.000, 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 FsR-3WBv85y7 for ; Wed, 2 May 2012 16:08:24 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id BE2F611E8074 for ; Wed, 2 May 2012 16:08:23 -0700 (PDT) Received: from [192.168.1.94] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 0607920F7152; Wed, 2 May 2012 19:08:22 -0400 (EDT) Subject: Re: Interest in IS-IS VPLS Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Thomas Nadeau In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D67023EBC82CC@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> Date: Wed, 2 May 2012 19:08:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <83B6F689-2AF7-4CF3-B602-9838C801FE52@lucidvision.com> References: <14C7F4F06DB5814AB0DE29716C4F6D67023EBC82CC@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> To: "Henderickx, Wim (Wim)" X-Mailer: Apple Mail (2.1257) 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, 02 May 2012 23:08:24 -0000 +1 --Tom On Apr 30, 2012:1:19 PM, at 1:19 PM, Henderickx, Wim (Wim) wrote: > Not interested. If the problem needs to be solved it should be = discussed in NVO3 >=20 > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of Giles Heron > Sent: vrijdag 27 april 2012 14:57 > 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 >=20 From tnadeau@lucidvision.com Wed May 2 16:18: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 631CC21F8585 for ; Wed, 2 May 2012 16:18:33 -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=[AWL=0.000, 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 Zw-jt4SSrQYZ for ; Wed, 2 May 2012 16:18:32 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9A721F8584 for ; Wed, 2 May 2012 16:18:32 -0700 (PDT) Received: from [192.168.1.94] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id EB31620F72F4; Wed, 2 May 2012 19:18:31 -0400 (EDT) Subject: Re: Interest in IS-IS VPLS Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Thomas Nadeau In-Reply-To: <5E893DB832F57341992548CDBB333163A56EEDED4C@EMBX01-HQ.jnpr.net> Date: Wed, 2 May 2012 19:18:31 -0400 Content-Transfer-Encoding: 7bit Message-Id: <08DE4AD8-2204-4BF1-910B-C565E9C63004@lucidvision.com> References: <2691CE0099834E4A9C5044EEC662BB9D3264C7F8@dfweml505-mbx> <5E893DB832F57341992548CDBB333163A56EEDE9C5@EMBX01-HQ.jnpr.net> <2691CE0099834E4A9C5044EEC662BB9D330E4B68@dfweml505-mbx> <4A95BA014132FF49AE685FAB4B9F17F6339049E4@dfweml505-mbx> <5E893DB832F57341992548CDBB333163A56EEDED4C@EMBX01-HQ.jnpr.net> To: John E Drake X-Mailer: Apple Mail (2.1257) 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, 02 May 2012 23:18:33 -0000 I like John's naming suggestion. --Tom On Apr 30, 2012:2:32 PM, at 2:32 PM, John E Drake wrote: > 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 >> >> Agree with Lucy, DC-VPN might be a better name. >> >> 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 >>> >>> 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 xuxiaohu@huawei.com Wed May 2 18:44: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 3015F11E80C0 for ; Wed, 2 May 2012 18:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.366 X-Spam-Level: * X-Spam-Status: No, score=1.366 tagged_above=-999 required=5 tests=[AWL=-0.577, 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 xOaibjLWpjY4 for ; Wed, 2 May 2012 18:44:35 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 75C1611E80BF for ; Wed, 2 May 2012 18:44:35 -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 AFT95588; Wed, 02 May 2012 21:44:35 -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, 2 May 2012 18:41:33 -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; Wed, 2 May 2012 18:41:38 -0700 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.182]) by szxeml438-hub.china.huawei.com ([10.72.61.73]) with mapi id 14.01.0323.003; Thu, 3 May 2012 09:41:26 +0800 From: Xuxiaohu To: Gregory Mirsky , Lucy yong Subject: re: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0kdUdSO48LuIhSPkS8Et2e3RTHugAJ0cmQABqEpVAA1Q2+AAABYxmAAAEGj4AAATO1AAAZHpOg Date: Thu, 3 May 2012 01:41:26 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02F1CF6B@szxeml525-mbs.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D330E8A73@dfweml505-mbx> 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 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, 03 May 2012 01:44:36 -0000 SGkgR3JlZywNCg0KVGhpcyBpc3N1ZSBoYXMgYmVlbiBzb2x2ZWQgYnkgcmZjNTMxMS4NCg0KWGlh b2h1DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogbDJ2cG4tYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmddILT6se0NCj4gR3JlZ29yeSBNaXJz a3kNCj4gt6LLzcqxvOQ6IDIwMTLE6jXUwjPI1SA1OjQyDQo+IMrVvP7IyzogTHVjeSB5b25nDQo+ ILOty806IGwydnBuQGlldGYub3JnDQo+INb3zOI6IFJFOiBJbnRlcmVzdCBpbiBJUy1JUyBWUExT DQo+IA0KPiBEZWFyIEx1Y3ksDQo+IEknbSBpbnRyaWd1ZWQgaG93IElTLUlTIFZQTFMgd291bGQg YWRkcmVzcyBzY2FsaW5nIHJlcXVpcmVtZW50cyBvdXRsaW5lZCBpbg0KPiBOVk8zIGNoYXJ0ZXIg d2hlbiBpdHMgVExWIGlzIGxpbWl0ZWQgdG8gMjU1IGJ5dGVzIGFuZCB0aHVzIGNhbiBjYXJyeSBv bmx5IHVwIHRvDQo+IDMwIFZQTFMgSUQtVlBMUyBMYWJlbHMgdHVwbGVzLiBXb3VsZG4ndCBPU1BG IE9wYXF1ZSBMU0Egc2NhbGUgYmV0dGVyPyBPcg0KPiBCR1A/DQo+IFdoYXQgaXMgdGhlIG92ZXJ3 aGVsbWluZyBiZW5lZml0LCB0ZWNobmljYWxseSBzcGVha2luZywgb2YgSVMtSVMgVlBMUyBwcm9w b3NhbA0KPiB2cy4gQkdQIEUtVlBOPw0KPiANCj4gDQo+IAlSZWdhcmRzLA0KPiAJCUdyZWcNCj4g DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGwydnBuLWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gTHVj eSB5b25nDQo+IFNlbnQ6IFdlZG5lc2RheSwgTWF5IDAyLCAyMDEyIDI6MDcgUE0NCj4gVG86IEdp bGVzIEhlcm9uOyBWaXNod2FzIE1hbnJhbDsgTWFjaCBDaGVuDQo+IENjOiBsMnZwbkBpZXRmLm9y Zw0KPiBTdWJqZWN0OiBSRTogSW50ZXJlc3QgaW4gSVMtSVMgVlBMUw0KPiANCj4gSSBzaGFyZSBt eSAyIGNlbnRzLg0KPiANCj4gRnJvbSB0aGUgdGVjaG5vbG9neSBwZXJzcGVjdGl2ZSwgSVMtSVMg VlBMUyBhbmQgVFJJTEwgYXJlIHR3byBkaWZmZXJlbnQNCj4gdGVjaG5vbG9naWVzLiBGcm9tIHRo ZSBhcHBsaWNhYmlsaXR5IHBlcnNwZWN0aXZlLCBUUklMTCBhcHBsaWVzIHRvIGVudGVycHJpc2Ug REMNCj4gYW5kIGNhbXB1czsgSVMtSVMgVlBMUyBjYW4gYXBwbHkgdG8gbXVsdGktdGVuYW50IHJl cXVpcmVkIGFuZCBsYXJnZXIgc2NhbGUgRENzDQo+IHRoYXQgcHJvdmlkZXMgdGhlIHNlcnZpY2Vz IHRvIGVudGVycHJpc2UgY3VzdG9tZXJzLg0KPiANCj4gSSBwZXJzb25hbGx5IGRvIG5vdCB3b3Jr IG9uIFRSSUxMIHRlY2hub2xvZ3kgYW5kIGxpa2UgdG8gc2VlIG90aGVycycgb3Bpbmlvbi4NCj4g DQo+IEx1Y3kNCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEdpbGVz IEhlcm9uIFttYWlsdG86Z2lsZXMuaGVyb25AZ21haWwuY29tXQ0KPiBTZW50OiBXZWRuZXNkYXks IE1heSAwMiwgMjAxMiAzOjM4IFBNDQo+IFRvOiBWaXNod2FzIE1hbnJhbDsgTWFjaCBDaGVuDQo+ IENjOiBMdWN5IHlvbmc7IGwydnBuQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBJbnRlcmVzdCBp biBJUy1JUyBWUExTDQo+IA0KPiBJbnRlcmVzdGluZy4NCj4gDQo+IEFzIHNvbWVvbmUgd2hvIGhh cyBoaXMgbmFtZSBvbiB2YXJpb3VzIFRSSUxMIGRyYWZ0cyB3aGF0J3MgeW91ciB0aGlua2luZyBv bg0KPiB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gSVNJUyBWUExTIGFuZCBUUklMTD8NCj4gDQo+ IEdpbGVzDQo+IA0KPiBPbiAwMi8wNS8yMDEyIDIwOjU4LCAiVmlzaHdhcyBNYW5yYWwiIDx2aXNo d2FzLmlldGZAZ21haWwuY29tPiB3cm90ZToNCj4gDQo+ID4gSGkgR2lsZXMsDQo+ID4NCj4gPiBJ IHdvdWxkIGFncmVlIGhlcmUgdG9vLiBJIHdvdWxkIGxpa2UgdG8gc2VlIHRoaXMgd29yayBwcm9n cmVzcyBhaGVhZA0KPiA+IGFzIHdlbGwuDQo+ID4NCj4gPiBUaGFua3MsDQo+ID4gVmlzaHdhcw0K PiA+DQo+ID4gT24gU2F0LCBBcHIgMjgsIDIwMTIgYXQgMzowNCBBTSwgTWFjaCBDaGVuIDxtYWNo LmNoZW5AaHVhd2VpLmNvbT4NCj4gd3JvdGU6DQo+ID4NCj4gPj4gRnVsbHkgYWdyZWUgd2l0aCBs dWN5IGhlcmUuDQo+ID4+DQo+ID4+IEluIGFkZGl0aW9uLCBzaW5jZSB0aGUgSVNJUyBWUExTIGxl dmVyYWdlcyBhIHVuaWZvcm0gcHJvdG9jb2woSVNJUykNCj4gPj4gZm9yIHNpZ25hbGluZyBhbmQg YXV0byBkaXNjb3ZlcnksIGl0IHdvdWxkIGdyZWF0bHkgc2ltcGxpZnkgdGhlDQo+ID4+IGRlcGxv eW1lbnQgYW5kIG1haW50ZW5hbmNlLCBlc3BlY2lhbGx5IGZvciB0aGUgREMgbmV0d29ya3MgdGhh dCBoYXZlDQo+ID4+IGFscmVhZHkgZGVwbG95ZWQgSVNJUyBmb3IgSVAgcm91dGluZy4gU28gSSdk IGxpa2UgdG8gc2VlIHRoZSBkcmFmdCBtb3ZpbmcNCj4gZm9yd2FyZC4NCj4gPj4NCj4gPj4gQmVz dCByZWdhcmRzLA0KPiA+PiBNYWNoDQo+ID4+DQo+ID4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiA+Pj4gRnJvbTogbDJ2cG4tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwydnBuLWJv dW5jZXNAaWV0Zi5vcmddIE9uDQo+ID4+PiBCZWhhbGYgT2YgTHVjeSB5b25nDQo+ID4+PiBTZW50 OiBTYXR1cmRheSwgQXByaWwgMjgsIDIwMTIgMjo0MyBBTQ0KPiA+Pj4gVG86IEdpbGVzIEhlcm9u OyBsMnZwbkBpZXRmLm9yZw0KPiA+Pj4gU3ViamVjdDogUkU6IEludGVyZXN0IGluIElTLUlTIFZQ TFMNCj4gPj4+DQo+ID4+PiBIaSBHaWxlcywNCj4gPj4+DQo+ID4+PiBJdCBzZWVtcyB0aGF0IHRo ZSBJUy1JUyBWUExTIHByb3ZpZGVzIHRoZSBzb2x1dGlvbiBmb3IgYSBzY2FsYWJsZQ0KPiA+Pj4g ZGF0YQ0KPiA+PiBjZW50ZXINCj4gPj4+IG5ldHdvcmsgYXMgbWVudGlvbmVkIGluIHRoZSBkcmFm dC4gSSBhbSBub3Qgc3VyZSBpdCBpcyBwcm9wZXIgdG8NCj4gPj4+IHdlaWdodCBzZXJ2aWNlIHBy b3ZpZGVycyBtb3JlIG9uIHRoaXMuIEkgY2FuIHNlZSBpZiBhIHNlcnZpY2UNCj4gPj4+IHByb3Zp ZGVyIGFscmVhZHkgZGVwbG95ZWQgZXhpc3RpbmcgVlBMUywgdGhlIGdhaW4gZnJvbSBJUy1JUyBW UExTIGlzDQo+ID4+PiBsZXNzIHRoYW4gdGhlIGNvc3Qgb24gdXBncmFkaW5nIGFsbCB0aGUgZWRn ZSBkZXZpY2VzIHRvIHN1cHBvcnQgdGhlDQo+IHNvbHV0aW9uLg0KPiA+Pj4NCj4gPj4+IEhvd2V2 ZXIsIGZvciBkYXRhIGNlbnRlciBuZXR3b3JrLCBJUy1JUyBWUExTIGNvdWxkIGJlIGEgdXNlZnVs IHNvbHV0aW9uLg0KPiA+PiBJdA0KPiA+Pj4gc2ltcGxpZmllcyBjdXJyZW50IFZQTFMgbWVjaGFu aXNtLCBwcm92aWRlcyBhIGdvb2Qgc2NhbGFiaWxpdHksIGFuZA0KPiA+Pj4gcmVxdWlyZXMgSVAg b25seSBmdW5jdGlvbiBvbiBjb3JlIHN3aXRjaGVzLg0KPiA+Pj4NCj4gPj4+IEEgdmVuZG9yIHBy b3ZpZGVzIGRldmljZXMgZm9yIGJvdGggc2VydmljZSBwcm92aWRlciBuZXR3b3JrIGFuZCBkYXRh DQo+ID4+PiBjZW50ZXIgbmV0d29yaywgdGhlIHNvbHV0aW9uIGJyaW5ncyBhIHN5bmVyZ3kgaW4g bGV2ZXJhZ2luZyBWUExTDQo+ID4+PiBzb2x1dGlvbiBpbnRvIERDLg0KPiA+Pj4NCj4gPj4+IFRo dXMsIEkgbGlrZSB0byBzZWUgdGhpcyB3b3JrIG1vdmluZyBmb3J3YXJkLg0KPiA+Pj4NCj4gPj4+ IFJlZ2FyZHMsDQo+ID4+PiBMdWN5DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+Pj4gRnJvbTogbDJ2cG4tYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+ID4+PiBCZWhhbGYgT2YgR2lsZXMg SGVyb24NCj4gPj4+IFNlbnQ6IEZyaWRheSwgQXByaWwgMjcsIDIwMTIgNzo1NyBBTQ0KPiA+Pj4g VG86IGwydnBuQGlldGYub3JnDQo+ID4+PiBTdWJqZWN0OiBJbnRlcmVzdCBpbiBJUy1JUyBWUExT DQo+ID4+Pg0KPiA+Pj4gSGksDQo+ID4+Pg0KPiA+Pj4gQXQgdGhlIElFVEYgbWVldGluZyBpbiBQ YXJpcyBJIHRvb2sgYW4gYWN0aW9uIChhcyBub3RlZCBpbiB0aGUNCj4gPj4+IG1pbnV0ZXMpDQo+ ID4+IHRvDQo+ID4+PiBwb2xsIHRoZSBXRyB0byBzZWUgaWYgdGhlcmUgd2FzIGFueSBpbnRlcmVz dCAob3RoZXIgdGhhbiBieSB0aGUNCj4gPj4+IGF1dGhvcnMNCj4gPj4gb2YNCj4gPj4+IGNvdXJz ZSkgaW4gcHJvZ3Jlc3NpbmcgdGhlIElTLUlTIFZQTFMgZHJhZnQuDQo+ID4+Pg0KPiA+Pj4gV291 bGQgeW91IHBsZWFzZSByZXNwb25kIHRvIHRoaXMgZW1haWwgaW5kaWNhdGluZyB3aGV0aGVyIG9y IG5vdCB5b3UNCj4gPj4+IGhhdmUgaW50ZXJlc3QgaW4gc2VlaW5nIHRoaXMgZHJhZnQgcHJvZ3Jl c3MsIGlkZWFsbHkgZ2l2aW5nDQo+ID4+PiByZWFzb25pbmcgZm9yIHlvdXIgcG9zaXRpb24uICBJ dCdkIGJlIGVzcGVjaWFsbHkgaW50ZXJlc3RpbmcgdG8gc2VlDQo+ID4+PiByZXNwb25zZXMgZnJv bSBzZXJ2aWNlIHByb3ZpZGVycyBvZiBjb3Vyc2UuDQo+ID4+Pg0KPiA+Pj4gSWYgdGhlcmUgYXJl IG5vIChvciB2ZXJ5IGZldykgcmVzcG9uc2VzIHRvIHRoaXMgZW1haWwgdGhlbiBOYWJpbCBhbmQN Cj4gPj4+IEkNCj4gPj4gd2lsbA0KPiA+Pj4gcHJvYmFibHkgaW50ZXJwcmV0IHRoYXQgYXMgbWVh bmluZyB0aGVyZSdzIGluc3VmZmljaWVudCBpbnRlcmVzdCB0bw0KPiA+Pj4gcHJvZ3Jlc3MuICBP ZiBjb3Vyc2UgaXQgbWF5IGp1c3QgbWVhbiB0aGF0IHlvdSBhbGwgbWlzc2VkIHRoaXMgZW1haWwN Cj4gPj4+IGluDQo+ID4+IHRoZQ0KPiA+Pj4gZGVsdWdlIG9mIGRlYmF0ZSBvbiBFLVRyZWUgOykN Cj4gPj4+DQo+ID4+PiBHaWxlcw0KPiA+Pj4NCj4gPj4NCj4gPj4NCj4gDQoNCg== From jiangyuanlong@huawei.com Wed May 2 19:33: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 72CB021F853D for ; Wed, 2 May 2012 19:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113, 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 NfN5Ww8Ut7jI for ; Wed, 2 May 2012 19:33:15 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1C921F853C for ; Wed, 2 May 2012 19:33: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 AFT98339; Wed, 02 May 2012 22:33:14 -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, 2 May 2012 19:31:04 -0700 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 2 May 2012 19:31:09 -0700 Received: from SZXEML508-MBX.china.huawei.com ([169.254.5.215]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.003; Thu, 3 May 2012 10:30:59 +0800 From: Jiangyuanlong To: Daniel Cohn , "Fedyk, Donald (Don)" , "Henderickx, Wim (Wim)" , Lucy yong , "josh.rogers@twcable.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: AQHNI1NEA18PKDoBDEy6zAcXiVu2LpasuNMAgAYGiYCAAAzygIAAAjQAgAAAAYCAAASFAIAAAOoAgAAYGACAAAPTgIACzjKAgABsbmCAABSDMIAAJEvQgADhaeA= Date: Thu, 3 May 2012 02:30:58 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA55D29@SZXEML508-MBX.china.huawei.com> References: <44F4E579A764584EA9BDFD07D0CA08130777C912@tlvmail1> <14C7F4F06DB5814AB0DE29716C4F6D67023ECB0FE3@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <44F4E579A764584EA9BDFD07D0CA08130777C944@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA51A54@SZXEML508-MBX.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130777CB13@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA52C12@SZXEML508-MBX.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130777CB80@tlvmail1> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA08130777CB80@tlvmail1> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.40.73] 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, 03 May 2012 02:33:16 -0000 Daniel,=20 Not aware that we had a discussion on this before, but IMHO the allocation = of internal S-VLAN can be automatic, and manuel configuration of this mappi= ng may not be needed at all. For example, an S-VLAN allocation module in th= e management plane in a PE can do this kind of job, allocating two internal= S-VLAN IDs for a E-Tree service (with a single external S-VLAN ID) in a to= pdown, bottom-up, or just any random way from a free S-VLAN ID pool. Once t= he interal S-VLANs are allocated, the mapping is determined and no other co= nfiguration is needed. The only difference from RFC 6246 is, for E-LAN, we only need to allocate a= single S-VLAN in the VPLS domain, but for E-Tree, we need to allocate two = S-VLANs in the VPLS domain. On the other hand, for the multi-PW approach, two PWs need to be configured= for a E-Tree service. When MS-PW is used in the network, for every S-PE, w= e need to configure two ingress PW segments and two egress PW segments. In = this case, I don't think we need to use fixed PW labels across the network = for fear of configuration complexity. Regards, Yuanlong -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Wednesday, May 02, 2012 8:01 PM To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; j= osh.rogers@twcable.com Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Inline. -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Wednesday, May 02, 2012 12:30 PM To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; josh.rogers@twcable.com Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi Daniel, Please see my comments in line. -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Wednesday, May 02, 2012 3:55 PM To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; josh.rogers@twcable.com Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi Yuanlong, The problem is not with the total number of S-VLAN IDs, I agree that normally there won't be more than 2047. The problem is that if you don't support all VLAN IDs, you need S-VLAN space coordination with the providers, e.g. "I can only transparently preserve S-VLAN ID 1 to 2047". Which won't always be in line with an existing deployment. [JY] This is not the case. If the total number is no more than 2047, it surely can be supported. The S-VLAN space of user domain is totally different from the S-VLAN in the provider domain and they can be overlapped, I don't see why we need S-VLAN space coordination between them.=20 [DC] If we use global S-VIDs in the VPLS (to simply mapping provisioning), then the IEEE S-VID to VPLS S-VID mapping should be fixed, and therefore the IEEE S-VID that can be supported is also fixed. Of course you can configure the mapping in each PE according to operator requirements but as we discussed before this increases complexity.=20 Relying on PBB-VPLS imposes additional limitations on backward compatibility. [JY] If the SPs really have to support so many S-VLANs in a E-Tree, I think they may well need MAC-in-MAC in their networks for the scalability issue. As you know, only PBB VPLS can provide both. Daniel -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Wednesday, May 02, 2012 5:07 AM To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; josh.rogers@twcable.com Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi Daniel, As you can see, both cases are discussed in the I-D.=20 With regard to case 1) (that is, S-VLAN translation), since the access VLAN and the E-Tree attributes (root/leaf) are services' attributes, they need to be configured on a PE anyway, and as the past emails by Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 mapping. With regard to S-VID space reduction, the constraint is valid only when a global VLAN space is used per PE, in fact, multi-VLAN space is more typical and with no such limits as we already discussed in the f2f meeting. Even if there are 4094 S-VLANs in a single E-Tree access as you described (not sure this is a valid use case in real life), PBB-VPLS can still be used. Regards, Yuanlong -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Monday, April 30, 2012 10:34 PM To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; Jiangyuanlong; josh.rogers@twcable.com Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? 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 ---------------------------------------------------------------------- From zhangmingui@huawei.com Wed May 2 19:46: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 2503521E8018 for ; Wed, 2 May 2012 19:46:26 -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 KkN3HbiD57TP for ; Wed, 2 May 2012 19:46:25 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3BEA921E8015 for ; Wed, 2 May 2012 19:46:25 -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 AFT99082; Wed, 02 May 2012 22:46:25 -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, 2 May 2012 19:44:25 -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, 2 May 2012 19:44:29 -0700 Received: from SZXEML507-MBS.china.huawei.com ([169.254.7.245]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.003; Thu, 3 May 2012 10:44:26 +0800 From: Mingui Zhang To: "l2vpn@ietf.org" Subject: RE: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0kdUdSO48LuIhSPkS8Et2e3RTHugAJ0cmQABqEpVAAcwK+MAAEDOFgAEt9zQAAHXTFQAARJekA Date: Thu, 3 May 2012 02:44:25 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E728CD35E7@SZXEML507-MBS.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D3264C7F8@dfweml505-mbx> <5E893DB832F57341992548CDBB333163A56EEDE9C5@EMBX01-HQ.jnpr.net> <2691CE0099834E4A9C5044EEC662BB9D330E4B68@dfweml505-mbx> <4552F0907735844E9204A62BBDD325E728CD336A@SZXEML507-MBS.china.huawei.com> <5E893DB832F57341992548CDBB333163A577283BB4@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A577283BB4@EMBX01-HQ.jnpr.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.73] 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, 03 May 2012 02:46:26 -0000 Hi John, It is a misunderstanding that I am asserting they "perform the same functio= n". Repetitive explanation seems unnecessary since differences have been we= ll explained by subsequent comments on the mailing list.=20 Actually, I was wondering whether ISIS-VPLS can be used to achieve intercon= nection of TRILL/SPB. Thanks, Mingui > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Thursday, May 03, 2012 1:28 AM > To: Mingui Zhang; Lucy yong; Mach Chen; Giles Heron; l2vpn@ietf.org > Subject: RE: Interest in IS-IS VPLS >=20 > Mingui, >=20 > This completely misses the point. I have yet to hear anyone say that = IS-IS > VPLS can do anything that SPB or TRILL cannot. >=20 > Given that they exist and that IS-IS VPLS does not, why would should w= e work > an yet another solution? Asserting that it performs the same function= in a > different way seems to be a less than compelling rationalization. >=20 > Thanks, >=20 > John >=20 > Sent from my iPhone >=20 >=20 > > -----Original Message----- > > From: Mingui Zhang [mailto:zhangmingui@huawei.com] > > Sent: Tuesday, May 01, 2012 8:23 PM > > To: Lucy yong; John E Drake; Mach Chen; Giles Heron; l2vpn@ietf.org > > Subject: RE: Interest in IS-IS VPLS > > > > Hi, > > > > Conceptually, TRILL/SPB/ISIS-VPLS are all "L2VPN" techniques. They a= ll > > leverage ISIS as the control plane but utilize different silicon. SP= B > > tries to utilize existing Ethernet-silicon. TRILL develops a new dat= a > > plane and there are several vendors who would like to support this w= ith > > new "TRILL-silicon". Except TRILL/SPB, there is a blue ocean where o= ne > > can utilize existing IP/MPLS silicon. I agree with Lucy that their > > differences in control plane are trivial while the differences in da= ta > > plane really distinguish them . > > > > Thanks, > > Mingui > > > > > -----Original Message----- > > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > > Behalf Of > > > Lucy yong > > > Sent: Monday, April 30, 2012 11:39 PM > > > 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 th= at > > can apply to > > > data center networks. This may be better than developing someth= ing > > > 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 varian= t > > 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-I= S > > 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 use= ful > > > > > 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 o= r > > 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 insufficien= t > > interest > > > > > to progress. Of course it may just mean that you all misse= d > > this > > > > > email in the deluge of debate on E-Tree ;) > > > > > > > > > > Giles > > > > > From josh.rogers@twcable.com Wed May 2 19:51: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 E8C0421E8019 for ; Wed, 2 May 2012 19:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.075 X-Spam-Level: X-Spam-Status: No, score=0.075 tagged_above=-999 required=5 tests=[AWL=-0.062, 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 TQSFF6-KQ3JJ for ; Wed, 2 May 2012 19:51:23 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6013A21E8018 for ; Wed, 2 May 2012 19:51:23 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.75,520,1330923600"; d="scan'208";a="359292164" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 02 May 2012 22:50:20 -0400 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.36]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Wed, 2 May 2012 22:51:22 -0400 From: "Rogers, Josh" To: Jiangyuanlong , Daniel Cohn , "Fedyk, Donald (Don)" , "Henderickx, Wim (Wim)" , Lucy yong Date: Wed, 2 May 2012 22:51:19 -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: Ac0o158hfgTZt2V1RCeKKgniRwk70A== Message-ID: In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA55D29@SZXEML508-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" 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, 03 May 2012 02:51:26 -0000 Yuanlong, Or better yet, include in the draft a 'standard' value for root sourced VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You would also have to require the the implementation NOT use global VLAN's, however (since each instance would be using the same values). In this way, no signaling or manual configuration is required for remote PE's to know how to classify traffic. Regarding switching PE's=8A Multi-PW means more than one PW, yes. I don't see this as a real problem. In general, design should try and avoid using S-PE's, but if you must, its going to mean extra work, no matter how you look at it. Two PW's for each Etree being switched instead of one is not alarming or concerning to me. On the other hand, if you use a dot1q (E-NNI) between MPLS domains, you have to deal with two ingress VLAN's an two egress VLAN's if you want the Etree to be handled on both sides (and if you use the 'standard' VID's as I mentioned above, you'd have to do mapping to non-standard and back) In general, I still prefer multi-PW, primarily because I prefer the separation of the traffic in the network's forwarding plane, rather than shipping it everywhere and deciding whether to forward to the AC when it gets to the egress PE. I'm having a hard time putting my finger exactly on what it is, or articulating the idea, but it seems that by having the traffic placed into two psuedowires, I have more flexibility and ease of configuration when it comes to E-NNI's, service multiplexed UNI's, and H-VPLS (both psuedowire based and vlan based). Of course my 'ease of configuration' statement assumes BGP-VPLS, as was pointed out earlier LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of PW's could really change that perception. I hope we can move forward with one of these soon, Josh On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >Daniel, > >Not aware that we had a discussion on this before, but IMHO the >allocation of internal S-VLAN can be automatic, and manuel configuration >of this mapping may not be needed at all. For example, an S-VLAN >allocation module in the management plane in a PE can do this kind of >job, allocating two internal S-VLAN IDs for a E-Tree service (with a >single external S-VLAN ID) in a topdown, bottom-up, or just any random >way from a free S-VLAN ID pool. Once the interal S-VLANs are allocated, >the mapping is determined and no other configuration is needed. > >The only difference from RFC 6246 is, for E-LAN, we only need to allocate >a single S-VLAN in the VPLS domain, but for E-Tree, we need to allocate >two S-VLANs in the VPLS domain. > >On the other hand, for the multi-PW approach, two PWs need to be >configured for a E-Tree service. When MS-PW is used in the network, for >every S-PE, we need to configure two ingress PW segments and two egress >PW segments. In this case, I don't think we need to use fixed PW labels >across the network for fear of configuration complexity. > >Regards, >Yuanlong > >-----Original Message----- >From: Daniel Cohn [mailto:DanielC@orckit.com] >Sent: Wednesday, May 02, 2012 8:01 PM >To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >josh.rogers@twcable.com >Cc: l2vpn@ietf.org >Subject: RE: The status of the approaches to the E-Tree solution? > >Inline. > >-----Original Message----- >From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >Sent: Wednesday, May 02, 2012 12:30 PM >To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >josh.rogers@twcable.com >Cc: l2vpn@ietf.org >Subject: RE: The status of the approaches to the E-Tree solution? > >Hi Daniel, Please see my comments in line. > > >-----Original Message----- >From: Daniel Cohn [mailto:DanielC@orckit.com] >Sent: Wednesday, May 02, 2012 3:55 PM >To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >yong; josh.rogers@twcable.com >Cc: l2vpn@ietf.org >Subject: RE: The status of the approaches to the E-Tree solution? > >Hi Yuanlong, > >The problem is not with the total number of S-VLAN IDs, I agree that >normally there won't be more than 2047. The problem is that if you don't >support all VLAN IDs, you need S-VLAN space coordination with the >providers, e.g. "I can only transparently preserve S-VLAN ID 1 to 2047". >Which won't always be in line with an existing deployment. >[JY] This is not the case. If the total number is no more than 2047, it >surely can be supported. The S-VLAN space of user domain is totally >different from the S-VLAN in the provider domain and they can be >overlapped, I don't see why we need S-VLAN space coordination between >them. > >[DC] If we use global S-VIDs in the VPLS (to simply mapping >provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >fixed, and therefore the IEEE S-VID that can be supported is also fixed. > >Of course you can configure the mapping in each PE according to operator >requirements but as we discussed before this increases complexity. > >Relying on PBB-VPLS imposes additional limitations on backward >compatibility. >[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >think they may well need MAC-in-MAC in their networks for the >scalability issue. As you know, only PBB VPLS can provide both. > >Daniel > >-----Original Message----- >From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >Sent: Wednesday, May 02, 2012 5:07 AM >To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >josh.rogers@twcable.com >Cc: l2vpn@ietf.org >Subject: RE: The status of the approaches to the E-Tree solution? > >Hi Daniel, > >As you can see, both cases are discussed in the I-D. > >With regard to case 1) (that is, S-VLAN translation), since the access >VLAN and the E-Tree attributes (root/leaf) are services' attributes, >they need to be configured on a PE anyway, and as the past emails by >Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >mapping. > >With regard to S-VID space reduction, the constraint is valid only when >a global VLAN space is used per PE, in fact, multi-VLAN space is more >typical and with no such limits as we already discussed in the f2f >meeting. > >Even if there are 4094 S-VLANs in a single E-Tree access as you >described (not sure this is a valid use case in real life), PBB-VPLS can >still be used. > >Regards, >Yuanlong > >-----Original Message----- >From: Daniel Cohn [mailto:DanielC@orckit.com] >Sent: Monday, April 30, 2012 10:34 PM >To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >Jiangyuanlong; josh.rogers@twcable.com >Cc: l2vpn@ietf.org >Subject: RE: The status of the approaches to the E-Tree solution? > >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] >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 > >---------------------------------------------------------------------- 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 xuxiaohu@huawei.com Wed May 2 20:06: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 4A21721E802A for ; Wed, 2 May 2012 20:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.386 X-Spam-Level: * X-Spam-Status: No, score=1.386 tagged_above=-999 required=5 tests=[AWL=-0.557, 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 zbxcLCpNGSUf for ; Wed, 2 May 2012 20:06:09 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 56C8D21E8015 for ; Wed, 2 May 2012 20:06:09 -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 AFL98526; Wed, 02 May 2012 23:06:09 -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; Wed, 2 May 2012 20:03:13 -0700 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 2 May 2012 20:03:11 -0700 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.182]) by szxeml405-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Thu, 3 May 2012 11:02:59 +0800 From: Xuxiaohu To: Gregory Mirsky , Lucy yong Subject: re: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0kdUdSO48LuIhSPkS8Et2e3RTHugAJ0cmQABqEpVAA1Q2+AAABYxmAAAEGj4AAATO1AAAbCX2w Date: Thu, 3 May 2012 03:02:58 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02F1D01A@szxeml525-mbs.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D330E8A73@dfweml505-mbx> 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 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, 03 May 2012 03:06:10 -0000 SGkgR3JlZywNCg0KQXMgZm9yIHRoZSBMUyBQRFUgc3BhY2UgbGltaXRhdGlvbiwgdGhlIG1ldGhv ZCBkZWZpbmVkIGluIFNpbXBsaWZpZWQgRXh0ZW5zaW9uIG9mIExpbmsgU3RhdGUgUERVIChMU1Ap IFNwYWNlIGZvciBJUy1JUyBbUkZDNTMxMV0gY2FuIGJlIHVzZWQgdG8gc29sdmUgdGhhdCBpc3N1 ZS4gDQoNCkNvbXBhcmVkIHRvIE9TUEYsIElTLUlTIGlzIG1vcmUgYWR2YW50YWdlb3VzIGluIHRo ZSBhc3BlY3Qgb2YgYXV0by1jb25maWd1cmF0aW9uIChlLmcuLCBwbHVnJnBsYXkpLCBmb3IgZXhh bXBsZSwgdGhlcmUgaXMgbm8gbmVlZCBmb3IgY29uZmlndXJpbmcgSVAgYWRkcmVzc2VzIG9uIHRo ZSBpbnRlcmZhY2VzIGJldHdlZW4gSVMtSVMgcm91dGVycyBkdWUgdG8gdGhlIHVubnVtYmVyZWQg aW50ZXJmYWNlIHVzYWdlLiBJbiBhZGRpdGlvbiwgaXQgY291bGQgbmF0dXJhbGx5IHJldXNlIHRo ZSBNQUMtUmVhY2hhYmlsaXR5IFRMViBkZWZpbmVkIGluIFtSRkM2MTY1XSB0byByZWFsaXplIHRo ZSBjb250cm9sLXBsYW5lIGJhc2VkIE1BQyBsZWFybmluZyBtZWNoYW5pc20uDQoNCkNvbXBhcmVk IHRvIEVWUE4sIElTLUlTIFZQTFMgaXRzZWxmIGNvdWxkIGVhc2lseSBzd2l0Y2ggb3ZlciBiZXR3 ZWVuIGNvbnRyb2wtcGxhbmUgYmFzZWQgTUFDIGxlYXJuaW5nIG1lY2hhbmlzbSBhbmQgZGF0YS1w bGFuZSBiYXNlZCBNQUMgbGVhcm5pbmcgbWVjaGFuaXNtIG9uIGEgcGVyIFZQTFMgaW5zdGFuY2Ug YmFzaXMsIGFuZCBtb3N0IGltcG9ydGFudGx5LCB3aXRob3V0IHJlcXVpcmluZyB0aGUgYXNzaXN0 YW5jZSBvZiBhbiBhZGRpdGlvbmFsIFBCQiBsYXllci4gSW4gZmFjdCwgSSBoYWQgZXZlciB0aG91 Z2h0IGFib3V0IHVzaW5nIEJHUCBmb3IgYWR2ZXJ0aXNpbmcgcGVyIFZQTFMgaW5zdGFuY2UgbGFi ZWwgKHdoaWNoIGlzIGRpZmZlcmVudCBmcm9tIHRoZSBQVyBsYWJlbCkgYXMgd2hhdCBJUy1JUyBW UExTIGRvZXMuIFRoaXMgZGlmZmVyZW5jZSBmcm9tIEUtVlBOIGlzIHRoZXJlIGlzIG5vIG5lZWQg dG8gYWR2ZXJ0aXNlIE1BQyByb3V0ZXMgaW4gdGhlIEJHUCB1cGRhdGVzLiBJbiBvdGhlciB3b3Jk cywgaXQgc3RpbGwgdXNlcyB0aGUgZGF0YS1wbGFuZSBiYXNlZCBNQUMgbGVhcm5pbmcgbWVjaGFu aXNtLiBUaGUgZGlmZmVyZW5jZSBmcm9tIGV4aXRpbmcgUFctYmFzZWQgVlBMUyBzb2x1dGlvbnMg W1JGQzQ3NjEsIFJGQzQ3NjJdIGlzIHRoYXQgdGhlcmUgaXMgbm8gbmVlZCBmb3IgYSBmdWxsLW1l c2ggb2YgUFdzIGJldHdlZW4gUEUgcm91dGVycy4gDQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0K DQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6IGwydnBuLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnXSC0+rHtDQo+IEdyZWdvcnkgTWlyc2t5DQo+ ILeiy83KsbzkOiAyMDEyxOo11MIzyNUgNTo0Mg0KPiDK1bz+yMs6IEx1Y3kgeW9uZw0KPiCzrcvN OiBsMnZwbkBpZXRmLm9yZw0KPiDW98ziOiBSRTogSW50ZXJlc3QgaW4gSVMtSVMgVlBMUw0KPiAN Cj4gRGVhciBMdWN5LA0KPiBJJ20gaW50cmlndWVkIGhvdyBJUy1JUyBWUExTIHdvdWxkIGFkZHJl c3Mgc2NhbGluZyByZXF1aXJlbWVudHMgb3V0bGluZWQgaW4NCj4gTlZPMyBjaGFydGVyIHdoZW4g aXRzIFRMViBpcyBsaW1pdGVkIHRvIDI1NSBieXRlcyBhbmQgdGh1cyBjYW4gY2Fycnkgb25seSB1 cCB0bw0KPiAzMCBWUExTIElELVZQTFMgTGFiZWxzIHR1cGxlcy4gV291bGRuJ3QgT1NQRiBPcGFx dWUgTFNBIHNjYWxlIGJldHRlcj8gT3INCj4gQkdQPw0KPiBXaGF0IGlzIHRoZSBvdmVyd2hlbG1p bmcgYmVuZWZpdCwgdGVjaG5pY2FsbHkgc3BlYWtpbmcsIG9mIElTLUlTIFZQTFMgcHJvcG9zYWwN Cj4gdnMuIEJHUCBFLVZQTj8NCj4gDQo+IA0KPiAJUmVnYXJkcywNCj4gCQlHcmVnDQo+IA0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBsMnZwbi1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+IEx1Y3kgeW9u Zw0KPiBTZW50OiBXZWRuZXNkYXksIE1heSAwMiwgMjAxMiAyOjA3IFBNDQo+IFRvOiBHaWxlcyBI ZXJvbjsgVmlzaHdhcyBNYW5yYWw7IE1hY2ggQ2hlbg0KPiBDYzogbDJ2cG5AaWV0Zi5vcmcNCj4g U3ViamVjdDogUkU6IEludGVyZXN0IGluIElTLUlTIFZQTFMNCj4gDQo+IEkgc2hhcmUgbXkgMiBj ZW50cy4NCj4gDQo+IEZyb20gdGhlIHRlY2hub2xvZ3kgcGVyc3BlY3RpdmUsIElTLUlTIFZQTFMg YW5kIFRSSUxMIGFyZSB0d28gZGlmZmVyZW50DQo+IHRlY2hub2xvZ2llcy4gRnJvbSB0aGUgYXBw bGljYWJpbGl0eSBwZXJzcGVjdGl2ZSwgVFJJTEwgYXBwbGllcyB0byBlbnRlcnByaXNlIERDDQo+ IGFuZCBjYW1wdXM7IElTLUlTIFZQTFMgY2FuIGFwcGx5IHRvIG11bHRpLXRlbmFudCByZXF1aXJl ZCBhbmQgbGFyZ2VyIHNjYWxlIERDcw0KPiB0aGF0IHByb3ZpZGVzIHRoZSBzZXJ2aWNlcyB0byBl bnRlcnByaXNlIGN1c3RvbWVycy4NCj4gDQo+IEkgcGVyc29uYWxseSBkbyBub3Qgd29yayBvbiBU UklMTCB0ZWNobm9sb2d5IGFuZCBsaWtlIHRvIHNlZSBvdGhlcnMnIG9waW5pb24uDQo+IA0KPiBM dWN5DQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBHaWxlcyBIZXJv biBbbWFpbHRvOmdpbGVzLmhlcm9uQGdtYWlsLmNvbV0NCj4gU2VudDogV2VkbmVzZGF5LCBNYXkg MDIsIDIwMTIgMzozOCBQTQ0KPiBUbzogVmlzaHdhcyBNYW5yYWw7IE1hY2ggQ2hlbg0KPiBDYzog THVjeSB5b25nOyBsMnZwbkBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogSW50ZXJlc3QgaW4gSVMt SVMgVlBMUw0KPiANCj4gSW50ZXJlc3RpbmcuDQo+IA0KPiBBcyBzb21lb25lIHdobyBoYXMgaGlz IG5hbWUgb24gdmFyaW91cyBUUklMTCBkcmFmdHMgd2hhdCdzIHlvdXIgdGhpbmtpbmcgb24NCj4g dGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIElTSVMgVlBMUyBhbmQgVFJJTEw/DQo+IA0KPiBHaWxl cw0KPiANCj4gT24gMDIvMDUvMjAxMiAyMDo1OCwgIlZpc2h3YXMgTWFucmFsIiA8dmlzaHdhcy5p ZXRmQGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0KPiA+IEhpIEdpbGVzLA0KPiA+DQo+ID4gSSB3b3Vs ZCBhZ3JlZSBoZXJlIHRvby4gSSB3b3VsZCBsaWtlIHRvIHNlZSB0aGlzIHdvcmsgcHJvZ3Jlc3Mg YWhlYWQNCj4gPiBhcyB3ZWxsLg0KPiA+DQo+ID4gVGhhbmtzLA0KPiA+IFZpc2h3YXMNCj4gPg0K PiA+IE9uIFNhdCwgQXByIDI4LCAyMDEyIGF0IDM6MDQgQU0sIE1hY2ggQ2hlbiA8bWFjaC5jaGVu QGh1YXdlaS5jb20+DQo+IHdyb3RlOg0KPiA+DQo+ID4+IEZ1bGx5IGFncmVlIHdpdGggbHVjeSBo ZXJlLg0KPiA+Pg0KPiA+PiBJbiBhZGRpdGlvbiwgc2luY2UgdGhlIElTSVMgVlBMUyBsZXZlcmFn ZXMgYSB1bmlmb3JtIHByb3RvY29sKElTSVMpDQo+ID4+IGZvciBzaWduYWxpbmcgYW5kIGF1dG8g ZGlzY292ZXJ5LCBpdCB3b3VsZCBncmVhdGx5IHNpbXBsaWZ5IHRoZQ0KPiA+PiBkZXBsb3ltZW50 IGFuZCBtYWludGVuYW5jZSwgZXNwZWNpYWxseSBmb3IgdGhlIERDIG5ldHdvcmtzIHRoYXQgaGF2 ZQ0KPiA+PiBhbHJlYWR5IGRlcGxveWVkIElTSVMgZm9yIElQIHJvdXRpbmcuIFNvIEknZCBsaWtl IHRvIHNlZSB0aGUgZHJhZnQgbW92aW5nDQo+IGZvcndhcmQuDQo+ID4+DQo+ID4+IEJlc3QgcmVn YXJkcywNCj4gPj4gTWFjaA0KPiA+Pg0KPiA+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gPj4+IEZyb206IGwydnBuLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsMnZwbi1ib3VuY2Vz QGlldGYub3JnXSBPbg0KPiA+Pj4gQmVoYWxmIE9mIEx1Y3kgeW9uZw0KPiA+Pj4gU2VudDogU2F0 dXJkYXksIEFwcmlsIDI4LCAyMDEyIDI6NDMgQU0NCj4gPj4+IFRvOiBHaWxlcyBIZXJvbjsgbDJ2 cG5AaWV0Zi5vcmcNCj4gPj4+IFN1YmplY3Q6IFJFOiBJbnRlcmVzdCBpbiBJUy1JUyBWUExTDQo+ ID4+Pg0KPiA+Pj4gSGkgR2lsZXMsDQo+ID4+Pg0KPiA+Pj4gSXQgc2VlbXMgdGhhdCB0aGUgSVMt SVMgVlBMUyBwcm92aWRlcyB0aGUgc29sdXRpb24gZm9yIGEgc2NhbGFibGUNCj4gPj4+IGRhdGEN Cj4gPj4gY2VudGVyDQo+ID4+PiBuZXR3b3JrIGFzIG1lbnRpb25lZCBpbiB0aGUgZHJhZnQuIEkg YW0gbm90IHN1cmUgaXQgaXMgcHJvcGVyIHRvDQo+ID4+PiB3ZWlnaHQgc2VydmljZSBwcm92aWRl cnMgbW9yZSBvbiB0aGlzLiBJIGNhbiBzZWUgaWYgYSBzZXJ2aWNlDQo+ID4+PiBwcm92aWRlciBh bHJlYWR5IGRlcGxveWVkIGV4aXN0aW5nIFZQTFMsIHRoZSBnYWluIGZyb20gSVMtSVMgVlBMUyBp cw0KPiA+Pj4gbGVzcyB0aGFuIHRoZSBjb3N0IG9uIHVwZ3JhZGluZyBhbGwgdGhlIGVkZ2UgZGV2 aWNlcyB0byBzdXBwb3J0IHRoZQ0KPiBzb2x1dGlvbi4NCj4gPj4+DQo+ID4+PiBIb3dldmVyLCBm b3IgZGF0YSBjZW50ZXIgbmV0d29yaywgSVMtSVMgVlBMUyBjb3VsZCBiZSBhIHVzZWZ1bCBzb2x1 dGlvbi4NCj4gPj4gSXQNCj4gPj4+IHNpbXBsaWZpZXMgY3VycmVudCBWUExTIG1lY2hhbmlzbSwg cHJvdmlkZXMgYSBnb29kIHNjYWxhYmlsaXR5LCBhbmQNCj4gPj4+IHJlcXVpcmVzIElQIG9ubHkg ZnVuY3Rpb24gb24gY29yZSBzd2l0Y2hlcy4NCj4gPj4+DQo+ID4+PiBBIHZlbmRvciBwcm92aWRl cyBkZXZpY2VzIGZvciBib3RoIHNlcnZpY2UgcHJvdmlkZXIgbmV0d29yayBhbmQgZGF0YQ0KPiA+ Pj4gY2VudGVyIG5ldHdvcmssIHRoZSBzb2x1dGlvbiBicmluZ3MgYSBzeW5lcmd5IGluIGxldmVy YWdpbmcgVlBMUw0KPiA+Pj4gc29sdXRpb24gaW50byBEQy4NCj4gPj4+DQo+ID4+PiBUaHVzLCBJ IGxpa2UgdG8gc2VlIHRoaXMgd29yayBtb3ZpbmcgZm9yd2FyZC4NCj4gPj4+DQo+ID4+PiBSZWdh cmRzLA0KPiA+Pj4gTHVjeQ0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gPj4+IEZyb206IGwydnBuLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiA+Pj4gQmVoYWxmIE9mIEdpbGVzIEhlcm9u DQo+ID4+PiBTZW50OiBGcmlkYXksIEFwcmlsIDI3LCAyMDEyIDc6NTcgQU0NCj4gPj4+IFRvOiBs MnZwbkBpZXRmLm9yZw0KPiA+Pj4gU3ViamVjdDogSW50ZXJlc3QgaW4gSVMtSVMgVlBMUw0KPiA+ Pj4NCj4gPj4+IEhpLA0KPiA+Pj4NCj4gPj4+IEF0IHRoZSBJRVRGIG1lZXRpbmcgaW4gUGFyaXMg SSB0b29rIGFuIGFjdGlvbiAoYXMgbm90ZWQgaW4gdGhlDQo+ID4+PiBtaW51dGVzKQ0KPiA+PiB0 bw0KPiA+Pj4gcG9sbCB0aGUgV0cgdG8gc2VlIGlmIHRoZXJlIHdhcyBhbnkgaW50ZXJlc3QgKG90 aGVyIHRoYW4gYnkgdGhlDQo+ID4+PiBhdXRob3JzDQo+ID4+IG9mDQo+ID4+PiBjb3Vyc2UpIGlu IHByb2dyZXNzaW5nIHRoZSBJUy1JUyBWUExTIGRyYWZ0Lg0KPiA+Pj4NCj4gPj4+IFdvdWxkIHlv dSBwbGVhc2UgcmVzcG9uZCB0byB0aGlzIGVtYWlsIGluZGljYXRpbmcgd2hldGhlciBvciBub3Qg eW91DQo+ID4+PiBoYXZlIGludGVyZXN0IGluIHNlZWluZyB0aGlzIGRyYWZ0IHByb2dyZXNzLCBp ZGVhbGx5IGdpdmluZw0KPiA+Pj4gcmVhc29uaW5nIGZvciB5b3VyIHBvc2l0aW9uLiAgSXQnZCBi ZSBlc3BlY2lhbGx5IGludGVyZXN0aW5nIHRvIHNlZQ0KPiA+Pj4gcmVzcG9uc2VzIGZyb20gc2Vy dmljZSBwcm92aWRlcnMgb2YgY291cnNlLg0KPiA+Pj4NCj4gPj4+IElmIHRoZXJlIGFyZSBubyAo b3IgdmVyeSBmZXcpIHJlc3BvbnNlcyB0byB0aGlzIGVtYWlsIHRoZW4gTmFiaWwgYW5kDQo+ID4+ PiBJDQo+ID4+IHdpbGwNCj4gPj4+IHByb2JhYmx5IGludGVycHJldCB0aGF0IGFzIG1lYW5pbmcg dGhlcmUncyBpbnN1ZmZpY2llbnQgaW50ZXJlc3QgdG8NCj4gPj4+IHByb2dyZXNzLiAgT2YgY291 cnNlIGl0IG1heSBqdXN0IG1lYW4gdGhhdCB5b3UgYWxsIG1pc3NlZCB0aGlzIGVtYWlsDQo+ID4+ PiBpbg0KPiA+PiB0aGUNCj4gPj4+IGRlbHVnZSBvZiBkZWJhdGUgb24gRS1UcmVlIDspDQo+ID4+ Pg0KPiA+Pj4gR2lsZXMNCj4gPj4+DQo+ID4+DQo+ID4+DQo+IA0KDQo= From lucy.yong@huawei.com Wed May 2 20:24: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 AE2BF11E8076 for ; Wed, 2 May 2012 20:24:35 -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.022, 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 rqxQ0bBJywFr for ; Wed, 2 May 2012 20:24:34 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4649B11E8074 for ; Wed, 2 May 2012 20:24:31 -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 AFU01344; Wed, 02 May 2012 23:24:30 -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, 2 May 2012 20:21:52 -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; Wed, 2 May 2012 20:21:55 -0700 From: Lucy yong To: Gregory Mirsky Subject: RE: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0kdUdSO48LuIhSPkS8Et2e3RTHugAJ0cmQABqEpVAA9HxfAAABYxiAAA4B/eAAGyNsMAAuQIyw Date: Thu, 3 May 2012 03:21:55 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D330E8BF9@dfweml505-mbx> References: <2691CE0099834E4A9C5044EEC662BB9D330E8A73@dfweml505-mbx> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: ETRa EcqF FS2j GBd+ JxRn KtmV Lhua LmiO Net1 OoBD O5rz O6kU RWyK TPjA Vgo2 Vii6; 2; ZwByAGUAZwBvAHIAeQAuAG0AaQByAHMAawB5AEAAZQByAGkAYwBzAHMAbwBuAC4AYwBvAG0AOwBsADIAdgBwAG4AQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {2FBD3D4E-1EF7-4BCC-B341-8E0176E8B0C4}; bAB1AGMAeQAuAHkAbwBuAGcAQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Thu, 03 May 2012 03:21:51 GMT; UgBFADoAIABJAG4AdABlAHIAZQBzAHQAIABpAG4AIABJAFMALQBJAFMAIABWAFAATABTAA== x-cr-puzzleid: {2FBD3D4E-1EF7-4BCC-B341-8E0176E8B0C4} x-originating-ip: [10.47.129.164] 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, 03 May 2012 03:24:35 -0000 Hi Gregory, I like to answer your second question first. Comparing IS-IS VPLS vs. BGP E-VPN, I think, is about comparing apple with = orange. Two have different objectives. Here is some analysis on two. The objective of E-VPN is to support multi-homing with active-active mode. = E-VPN solution chooses BGP as the control plane protocol, so you name it BG= P E-VPN. The E-VPN brings SP a new service. Current E-VPN draft use MPLS tu= nnel carrying the VPN traffic but mentions the potential to use of IP tunne= l carrying the VPN traffic. The objective of IS-IS VPLS is to simplify current VPLS mechanism, which ca= n be scale and require only IP functions (no MPLS) in core switches. These = features fit more in DC environment. Current VPLS solution requires full-me= shed structure among all the PEs or PEs related to a VPN instance, which is= not scale. H-VPLS solves it hub-spoke structure. However, DC architecture = is very simple: ToR, Aggregation switch, and core switch. Thus H-VPLS does = not apply to DC. IS-IS VPLS uses IP tunnel and a global VPN label so it doe= s not have a full-meshed structure, which makes scale well. IS-IS VPLS does= not provide any new service feature as E-VPN. Although it can apply to SP = networks and bring the benefits, given the situation that VPLS/H-VPLS have = been widely deployed now and is a popular service SP offers, We see it appl= ying to DCs more than SP network. DC people look for some cost effective solution and have some similar requi= rements as the VPN in service provider networks. It becomes very popular th= at DC core switch and aggregation switch to run IP only. When running IP, w= e need a routing protocol for sure. However, do we need MPLS capability and= signaling protocol in these switches? With current chip technology, IP for= warding is equally as good as label forwarding. MPLS function seems unneces= sary on these switches, which is cost saving. If IS-IS protocol can help to= auto-configuring a VPN, we do not need LDP/BGP to construct the VPN as cur= rent VPLS. This reduces weight too. One trade-off is that IS-IS VPLS can't = use of MPLS TE capability. But we don't think DC people want to use TE capa= bility. Thus, IS-IS VPLS provides a cost effective L2 VPN solution for the = DCs that require multi-tenancy and large scale. Since IS-IS VPLS uses of al= l existing PE process procedures except MAC binding to IP tunnel instead of= PW, there is no need to re-spin the whole wheel and we can reuse existing = stuff that was developed in this WG.=20 Regarding your first question, I don't think that is correct. 20 bit labels= can support a lots of VPNs. IS-IS has been used in DC today. Regards, Lucy =20 -----Original Message----- From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]=20 Sent: Wednesday, May 02, 2012 4:42 PM To: Lucy yong Cc: l2vpn@ietf.org Subject: RE: Interest in IS-IS VPLS Dear Lucy, I'm intrigued how IS-IS VPLS would address scaling requirements outlined in= NVO3 charter when its TLV is limited to 255 bytes and thus can carry only = up to 30 VPLS ID-VPLS Labels tuples. Wouldn't OSPF Opaque LSA scale better?= Or BGP? What is the overwhelming benefit, technically speaking, of IS-IS VPLS propo= sal vs. BGP E-VPN? Regards, Greg -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of L= ucy yong Sent: Wednesday, May 02, 2012 2:07 PM To: Giles Heron; Vishwas Manral; Mach Chen Cc: l2vpn@ietf.org Subject: RE: Interest in IS-IS VPLS I share my 2 cents. >From the technology perspective, IS-IS VPLS and TRILL are two different tec= hnologies. From the applicability perspective, TRILL applies to enterprise = DC and campus; IS-IS VPLS can apply to multi-tenant required and larger sca= le DCs that provides the services to enterprise customers. I personally do not work on TRILL technology and like to see others' opinio= n. Lucy=20 -----Original Message----- From: Giles Heron [mailto:giles.heron@gmail.com] Sent: Wednesday, May 02, 2012 3:38 PM To: Vishwas Manral; Mach Chen Cc: Lucy yong; l2vpn@ietf.org Subject: Re: Interest in IS-IS VPLS Interesting. As someone who has his name on various TRILL drafts what's your thinking on= the relationship between ISIS VPLS and TRILL? Giles On 02/05/2012 20:58, "Vishwas Manral" wrote: > Hi Giles, >=20 > I would agree here too. I would like to see this work progress ahead=20 > as well. >=20 > Thanks, > Vishwas >=20 > On Sat, Apr 28, 2012 at 3:04 AM, Mach Chen wrote: >=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 movin= g forward. >>=20 >> Best regards, >> Mach >>=20 >>> -----Original Message----- >>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On=20 >>> 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=20 >>> data >> center >>> network as mentioned in the draft. I am not sure it is proper to=20 >>> 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 sol= ution. >>>=20 >>> However, for data center network, IS-IS VPLS could be a useful solution= . >> It >>> simplifies current VPLS mechanism, provides a good scalability, and=20 >>> requires IP only function on core switches. >>>=20 >>> 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. >>>=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=20 >>> 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=20 >>> minutes) >> to >>> poll the WG to see if there was any interest (other than by the=20 >>> authors >> of >>> course) in progressing the IS-IS VPLS draft. >>>=20 >>> 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. >>>=20 >>> If there are no (or very few) responses to this email then Nabil and=20 >>> I >> will >>> probably interpret that as meaning there's insufficient interest to=20 >>> progress. Of course it may just mean that you all missed this email=20 >>> in >> the >>> deluge of debate on E-Tree ;) >>>=20 >>> Giles >>>=20 >>=20 >>=20 From sajassi@cisco.com Wed May 2 22:03: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 7830821F857D for ; Wed, 2 May 2012 22:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.688 X-Spam-Level: X-Spam-Status: No, score=-9.688 tagged_above=-999 required=5 tests=[AWL=-0.081, 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 mXou852EXPsg for ; Wed, 2 May 2012 22:03:45 -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 B998521F84D2 for ; Wed, 2 May 2012 22:03:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sajassi@cisco.com; l=903; q=dns/txt; s=iport; t=1336021425; x=1337231025; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=PSACkqy+acIcNfg/O6xG2APfNmGkB05f0PN4dVCUjmk=; b=WpmZNNgvEhS7A1EAlLccPtPzelJw2uAvNg6qY0ZEWi6YE4WiANAXCsLV vb995+OEH6ncWkVe0esstk2hENFqvMyVCQ9LnHew0L+8J+Of327eD9U+8 iqGmGnhg/BrWdeIKLh9NZEK/tx5dUrRX64XmhsXHDtD6+/dqnItgnyLm7 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGoRok+rRDoH/2dsb2JhbABEsyOBB4ILAQQSAScCATwSAQgJgRQBAQQOIAeHagGbDKAUkQgEiGKFL4dtjlmBaYJ3 X-IronPort-AV: E=Sophos;i="4.75,520,1330905600"; d="scan'208";a="43282264" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 03 May 2012 05:03: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 q4353gLD000929; Thu, 3 May 2012 05:03: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); Wed, 2 May 2012 22:03:41 -0700 Received: from 10.21.118.141 ([10.21.118.141]) by xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) with Microsoft Exchange Server HTTP-DAV ; Thu, 3 May 2012 05:03:41 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 02 May 2012 22:03:40 +0900 Subject: Re: Interest in IS-IS VPLS From: sajassi To: Giles Heron , "Bitar, Nabil N" Message-ID: Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0oo3KJ1wSZdtM/HEigFxRLQ5av6AARqg4S In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 03 May 2012 05:03:41.0913 (UTC) FILETIME=[1BE60490:01CD28EA] 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, 03 May 2012 05:03:46 -0000 Giles, Nabil: I am wondering if there is a plan to yet again re-charter L2VPN. Since this draft intends to use a completely different data-plane and control plane mechanism outside VPLS framework and RFC 4761 & 4762. When we introduced evpn/pbb-evpn, because of different data-plane/control-plane processing, we had to go through re-chartering and thus the evpn solution is now explicitly called out in the charter. Every solution that this WG has worked on so far has explicitly been called out in the charter. If the intention is to re-charter the WG yet again, then it would be nice to solicit AD's opinion first specially in light of the new NOV3 WG which is specifically intended to cover this kind of topic. If ADs (or you) think that this solution should be covered in NVo3 WG, then all these discussions around this draft in this WG is a moot point. Regards, Ali From jiangyuanlong@huawei.com Wed May 2 22:11: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 BE53621F85F1 for ; Wed, 2 May 2012 22:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.191 X-Spam-Level: X-Spam-Status: No, score=-2.191 tagged_above=-999 required=5 tests=[AWL=-0.192, 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 KUKxjokw7Y7u for ; Wed, 2 May 2012 22:11:30 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 557DA21F85E6 for ; Wed, 2 May 2012 22:11:30 -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 AFU07170; Thu, 03 May 2012 01:11:30 -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, 2 May 2012 22:07:44 -0700 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 2 May 2012 22:07:49 -0700 Received: from SZXEML508-MBX.china.huawei.com ([169.254.5.215]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0323.003; Thu, 3 May 2012 13:07:35 +0800 From: Jiangyuanlong To: "Rogers, Josh" , Daniel Cohn , "Fedyk, Donald (Don)" , "Henderickx, Wim (Wim)" , 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: AQHNI1NEA18PKDoBDEy6zAcXiVu2LpasuNMAgAYGiYCAAAzygIAAAjQAgAAAAYCAAASFAIAAAOoAgAAYGACAAAPTgIACzjKAgABsbmCAABSDMIAAJEvQgADhaeD//53EgIAAk10g Date: Thu, 3 May 2012 05:07:34 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA55F9F@SZXEML508-MBX.china.huawei.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA55D29@SZXEML508-MBX.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.40.73] Content-Type: text/plain; charset="iso-8859-2" 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, 03 May 2012 05:11:31 -0000 Josh, please see my comments in line. Thanks Yuanlong -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com]=20 Sent: Thursday, May 03, 2012 10:51 AM To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim);= Lucy yong Cc: l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? Yuanlong, Or better yet, include in the draft a 'standard' value for root sourced VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You would also have to require the the implementation NOT use global VLAN's, however (since each instance would be using the same values). In this way, no signaling or manual configuration is required for remote PE's to know how to classify traffic. [JY] Indeed, we discussed this possibility during the f2f meeting in Paris.= But, there are some restrictions as you mentioned, and furthermore:=20 1) Some vendors already used S-VLAN to distinguish their VSIs in the PE;=20 2) Forwarding plane of a PE needs to be revised to be aware of this VLAN ID= . Therefore, this 'standard value' approach seems more disruptive compared wi= th the other means and not a good candidate option. Regarding switching PE's=A9 Multi-PW means more than one PW, yes. I don't see this as a real problem. In general, design should try and avoid using S-PE's, but if you must, its going to mean extra work, no matter how you look at it. Two PW's for each Etree being switched instead of one is not alarming or concerning to me. On the other hand, if you use a dot1q (E-NNI) between MPLS domains, you have to deal with two ingress VLAN's an two egress VLAN's if you want the Etree to be handled on both sides (and if you use the 'standard' VID's as I mentioned above, you'd have to do mapping to non-standard and back) [JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service requ= irements from MEF, it has nothing to do with the solutions. Could you give = a hint on how you can provision this service E-NNI otherwise? BTW, if confi= guring or signalling two PWs is not a problem, why configuring or signallin= g two VLANs will become a problem? After all, more nodes may need to be con= figured or signalled for 2PW (T-PEs and S-PEs) compared with 2VLAN (only T-= PEs). In general, I still prefer multi-PW, primarily because I prefer the separation of the traffic in the network's forwarding plane, rather than shipping it everywhere and deciding whether to forward to the AC when it gets to the egress PE. I'm having a hard time putting my finger exactly on what it is, or articulating the idea, but it seems that by having the traffic placed into two psuedowires, I have more flexibility and ease of configuration when it comes to E-NNI's, service multiplexed UNI's, and H-VPLS (both psuedowire based and vlan based). Of course my 'ease of configuration' statement assumes BGP-VPLS, as was pointed out earlier LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of PW's could really change that perception. [JY] Are you saying that we need to develop a totally new forwarding plane = rather than using the Ethernet forwarding plane as described in the existin= g work?=20 I hope we can move forward with one of these soon, [JY] me too. Josh On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >Daniel, > >Not aware that we had a discussion on this before, but IMHO the >allocation of internal S-VLAN can be automatic, and manuel configuration >of this mapping may not be needed at all. For example, an S-VLAN >allocation module in the management plane in a PE can do this kind of >job, allocating two internal S-VLAN IDs for a E-Tree service (with a >single external S-VLAN ID) in a topdown, bottom-up, or just any random >way from a free S-VLAN ID pool. Once the interal S-VLANs are allocated, >the mapping is determined and no other configuration is needed. > >The only difference from RFC 6246 is, for E-LAN, we only need to allocate >a single S-VLAN in the VPLS domain, but for E-Tree, we need to allocate >two S-VLANs in the VPLS domain. > >On the other hand, for the multi-PW approach, two PWs need to be >configured for a E-Tree service. When MS-PW is used in the network, for >every S-PE, we need to configure two ingress PW segments and two egress >PW segments. In this case, I don't think we need to use fixed PW labels >across the network for fear of configuration complexity. > >Regards, >Yuanlong > >-----Original Message----- >From: Daniel Cohn [mailto:DanielC@orckit.com] >Sent: Wednesday, May 02, 2012 8:01 PM >To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >josh.rogers@twcable.com >Cc: l2vpn@ietf.org >Subject: RE: The status of the approaches to the E-Tree solution? > >Inline. > >-----Original Message----- >From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >Sent: Wednesday, May 02, 2012 12:30 PM >To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >josh.rogers@twcable.com >Cc: l2vpn@ietf.org >Subject: RE: The status of the approaches to the E-Tree solution? > >Hi Daniel, Please see my comments in line. > > >-----Original Message----- >From: Daniel Cohn [mailto:DanielC@orckit.com] >Sent: Wednesday, May 02, 2012 3:55 PM >To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >yong; josh.rogers@twcable.com >Cc: l2vpn@ietf.org >Subject: RE: The status of the approaches to the E-Tree solution? > >Hi Yuanlong, > >The problem is not with the total number of S-VLAN IDs, I agree that >normally there won't be more than 2047. The problem is that if you don't >support all VLAN IDs, you need S-VLAN space coordination with the >providers, e.g. "I can only transparently preserve S-VLAN ID 1 to 2047". >Which won't always be in line with an existing deployment. >[JY] This is not the case. If the total number is no more than 2047, it >surely can be supported. The S-VLAN space of user domain is totally >different from the S-VLAN in the provider domain and they can be >overlapped, I don't see why we need S-VLAN space coordination between >them. > >[DC] If we use global S-VIDs in the VPLS (to simply mapping >provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >fixed, and therefore the IEEE S-VID that can be supported is also fixed. > >Of course you can configure the mapping in each PE according to operator >requirements but as we discussed before this increases complexity. > >Relying on PBB-VPLS imposes additional limitations on backward >compatibility. >[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >think they may well need MAC-in-MAC in their networks for the >scalability issue. As you know, only PBB VPLS can provide both. > >Daniel > >-----Original Message----- >From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >Sent: Wednesday, May 02, 2012 5:07 AM >To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >josh.rogers@twcable.com >Cc: l2vpn@ietf.org >Subject: RE: The status of the approaches to the E-Tree solution? > >Hi Daniel, > >As you can see, both cases are discussed in the I-D. > >With regard to case 1) (that is, S-VLAN translation), since the access >VLAN and the E-Tree attributes (root/leaf) are services' attributes, >they need to be configured on a PE anyway, and as the past emails by >Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >mapping. > >With regard to S-VID space reduction, the constraint is valid only when >a global VLAN space is used per PE, in fact, multi-VLAN space is more >typical and with no such limits as we already discussed in the f2f >meeting. > >Even if there are 4094 S-VLANs in a single E-Tree access as you >described (not sure this is a valid use case in real life), PBB-VPLS can >still be used. > >Regards, >Yuanlong > >-----Original Message----- >From: Daniel Cohn [mailto:DanielC@orckit.com] >Sent: Monday, April 30, 2012 10:34 PM >To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >Jiangyuanlong; josh.rogers@twcable.com >Cc: l2vpn@ietf.org >Subject: RE: The status of the approaches to the E-Tree solution? > >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] >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 > >---------------------------------------------------------------------- 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 May 2 23:57: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 86E0821F85B8 for ; Wed, 2 May 2012 23:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.183 X-Spam-Level: X-Spam-Status: No, score=-2.183 tagged_above=-999 required=5 tests=[AWL=-0.184, 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 oy9BilwM2-I2 for ; Wed, 2 May 2012 23:57:39 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACF421F85A2 for ; Wed, 2 May 2012 23:57:39 -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 AFU12735; Thu, 03 May 2012 02:57:38 -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, 2 May 2012 23:56:31 -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; Wed, 2 May 2012 23:56:36 -0700 Received: from SZXEML508-MBX.china.huawei.com ([169.254.5.215]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.003; Thu, 3 May 2012 14:56:22 +0800 From: Jiangyuanlong To: "Rogers, Josh" , Daniel Cohn , "Fedyk, Donald (Don)" , "Henderickx, Wim (Wim)" , 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: AQHNI1NEA18PKDoBDEy6zAcXiVu2LpasuNMAgAYGiYCAAAzygIAAAjQAgAAAAYCAAASFAIAAAOoAgAAYGACAAAPTgIACzjKAgABsbmCAABSDMIAAJEvQgADhaeD//53EgIAAuN9Q Date: Thu, 3 May 2012 06:56:22 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA55FCE@SZXEML508-MBX.china.huawei.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA55D29@SZXEML508-MBX.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.40.73] Content-Type: text/plain; charset="iso-8859-2" 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, 03 May 2012 06:57:40 -0000 Josh, please see my comments in line. Thanks Yuanlong -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com]=20 Sent: Thursday, May 03, 2012 10:51 AM To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim);= Lucy yong Cc: l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? Yuanlong, Or better yet, include in the draft a 'standard' value for root sourced VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You would also have to require the the implementation NOT use global VLAN's, however (since each instance would be using the same values). In this way, no signaling or manual configuration is required for remote PE's to know how to classify traffic. [JY] Indeed, we had discussed this approach during the f2f meeting in Paris= . But there are restrictions as you mentioned, furthermore: 1) some vendors already use S-VLANs to distinguish their VSIs in a PE; 2) the forwarding plane of a PE needs to be revised to be aware of this VLA= N and process it accordingly. Therefore, it seemed that this approach is not a good option compared with = other means. Regarding switching PE's=A9 Multi-PW means more than one PW, yes. I don't see this as a real problem. In general, design should try and avoid using S-PE's, but if you must, its going to mean extra work, no matter how you look at it. Two PW's for each Etree being switched instead of one is not alarming or concerning to me. On the other hand, if you use a dot1q (E-NNI) between MPLS domains, you have to deal with two ingress VLAN's an two egress VLAN's if you want the Etree to be handled on both sides (and if you use the 'standard' VID's as I mentioned above, you'd have to do mapping to non-standard and back) [JY] As I am aware, configuring two S-VLANs for E-Tree E-NNI is one of the = service requirements from the MEF, and it has nothing to do with the soluti= on we used, that is, no matter what solution we adopt, the configuration of= two S-VLAN is needed for E-Tree E-NNI. BTW, if configuring or signalling 2= PWs for more nodes (both T-PEs and S-PEs in MS-PW) is not a problem, why co= nfiguring or signalling 2VLANs for less nodes (only T-PEs) will become a pr= oblem? Furthermore, if PW OAM is to be deployed, configuring OAM for 2PW me= ans double our configuration work. In general, I still prefer multi-PW, primarily because I prefer the separation of the traffic in the network's forwarding plane, rather than shipping it everywhere and deciding whether to forward to the AC when it gets to the egress PE. I'm having a hard time putting my finger exactly on what it is, or articulating the idea, but it seems that by having the traffic placed into two psuedowires, I have more flexibility and ease of configuration when it comes to E-NNI's, service multiplexed UNI's, and H-VPLS (both psuedowire based and vlan based). Of course my 'ease of configuration' statement assumes BGP-VPLS, as was pointed out earlier LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of PW's could really change that perception. [JY] Are you suggesting to develop a totally new forwarding plane rather th= an using the Ethernet forwarding plane? I am also not sure whether "separat= ion of the traffic in the network's forwarding plane, rather than shipping = it everywhere and deciding whether to forward to the AC when it gets to the= egress PE" is a unique advantage for 2PW approach: if the egress PE is att= ached with pure leafs, 2VLAN approach can also separate the leaf traffic in= the forwarding plane of the ingress PE and filter it; if the egress PE is = attached with pure roots or with both roots and leafs, then all traffic mus= t be transported to the egress PE and be filtered there, I see no differenc= e for these solutions.=20 I hope we can move forward with one of these soon, [JY] Me too:) Josh On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >Daniel, > >Not aware that we had a discussion on this before, but IMHO the >allocation of internal S-VLAN can be automatic, and manuel configuration >of this mapping may not be needed at all. For example, an S-VLAN >allocation module in the management plane in a PE can do this kind of >job, allocating two internal S-VLAN IDs for a E-Tree service (with a >single external S-VLAN ID) in a topdown, bottom-up, or just any random >way from a free S-VLAN ID pool. Once the interal S-VLANs are allocated, >the mapping is determined and no other configuration is needed. > >The only difference from RFC 6246 is, for E-LAN, we only need to allocate >a single S-VLAN in the VPLS domain, but for E-Tree, we need to allocate >two S-VLANs in the VPLS domain. > >On the other hand, for the multi-PW approach, two PWs need to be >configured for a E-Tree service. When MS-PW is used in the network, for >every S-PE, we need to configure two ingress PW segments and two egress >PW segments. In this case, I don't think we need to use fixed PW labels >across the network for fear of configuration complexity. > >Regards, >Yuanlong > >-----Original Message----- >From: Daniel Cohn [mailto:DanielC@orckit.com] >Sent: Wednesday, May 02, 2012 8:01 PM >To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >josh.rogers@twcable.com >Cc: l2vpn@ietf.org >Subject: RE: The status of the approaches to the E-Tree solution? > >Inline. > >-----Original Message----- >From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >Sent: Wednesday, May 02, 2012 12:30 PM >To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >josh.rogers@twcable.com >Cc: l2vpn@ietf.org >Subject: RE: The status of the approaches to the E-Tree solution? > >Hi Daniel, Please see my comments in line. > > >-----Original Message----- >From: Daniel Cohn [mailto:DanielC@orckit.com] >Sent: Wednesday, May 02, 2012 3:55 PM >To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >yong; josh.rogers@twcable.com >Cc: l2vpn@ietf.org >Subject: RE: The status of the approaches to the E-Tree solution? > >Hi Yuanlong, > >The problem is not with the total number of S-VLAN IDs, I agree that >normally there won't be more than 2047. The problem is that if you don't >support all VLAN IDs, you need S-VLAN space coordination with the >providers, e.g. "I can only transparently preserve S-VLAN ID 1 to 2047". >Which won't always be in line with an existing deployment. >[JY] This is not the case. If the total number is no more than 2047, it >surely can be supported. The S-VLAN space of user domain is totally >different from the S-VLAN in the provider domain and they can be >overlapped, I don't see why we need S-VLAN space coordination between >them. > >[DC] If we use global S-VIDs in the VPLS (to simply mapping >provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >fixed, and therefore the IEEE S-VID that can be supported is also fixed. > >Of course you can configure the mapping in each PE according to operator >requirements but as we discussed before this increases complexity. > >Relying on PBB-VPLS imposes additional limitations on backward >compatibility. >[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >think they may well need MAC-in-MAC in their networks for the >scalability issue. As you know, only PBB VPLS can provide both. > >Daniel > >-----Original Message----- >From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >Sent: Wednesday, May 02, 2012 5:07 AM >To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >josh.rogers@twcable.com >Cc: l2vpn@ietf.org >Subject: RE: The status of the approaches to the E-Tree solution? > >Hi Daniel, > >As you can see, both cases are discussed in the I-D. > >With regard to case 1) (that is, S-VLAN translation), since the access >VLAN and the E-Tree attributes (root/leaf) are services' attributes, >they need to be configured on a PE anyway, and as the past emails by >Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >mapping. > >With regard to S-VID space reduction, the constraint is valid only when >a global VLAN space is used per PE, in fact, multi-VLAN space is more >typical and with no such limits as we already discussed in the f2f >meeting. > >Even if there are 4094 S-VLANs in a single E-Tree access as you >described (not sure this is a valid use case in real life), PBB-VPLS can >still be used. > >Regards, >Yuanlong > >-----Original Message----- >From: Daniel Cohn [mailto:DanielC@orckit.com] >Sent: Monday, April 30, 2012 10:34 PM >To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >Jiangyuanlong; josh.rogers@twcable.com >Cc: l2vpn@ietf.org >Subject: RE: The status of the approaches to the E-Tree solution? > >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] >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 > >---------------------------------------------------------------------- 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 xuxiaohu@huawei.com Thu May 3 00:40: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 1179921F85D6 for ; Thu, 3 May 2012 00:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.405 X-Spam-Level: * X-Spam-Status: No, score=1.405 tagged_above=-999 required=5 tests=[AWL=-0.538, 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 2xBxc9c3uV+E for ; Thu, 3 May 2012 00:40:35 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF9C21F85D5 for ; Thu, 3 May 2012 00:40:35 -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 AFM13760; Thu, 03 May 2012 03:40:35 -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, 3 May 2012 00:37:05 -0700 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 3 May 2012 00:37:10 -0700 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.182]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.003; Thu, 3 May 2012 15:36:58 +0800 From: Xuxiaohu To: Gregory Mirsky , Lucy yong Subject: re: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0kdUdSO48LuIhSPkS8Et2e3RTHugAJ0cmQABqEpVAA1Q2+AAABYxmAAAEGj4AAATO1AAAbCX2wAAo3UMA= Date: Thu, 3 May 2012 07:36:57 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02F1D1ED@szxeml525-mbs.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D330E8A73@dfweml505-mbx> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02F1D01A@szxeml525-mbs.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02F1D01A@szxeml525-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.99] 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: Thu, 03 May 2012 07:40:36 -0000 TW9yZSBzcGVjaWZpY2FsbHkgc3BlYWtpbmcsIHRvIG92ZXJjb21lIHRoZSAyNTUtYnl0ZSBUTFYg bGltaXQsIElTLUlTIGFsbG93cyB0aGUgaW50ZXJwcmV0YXRpb24gb2YgbXVsdGlwbGUgVExWcyBv ZiBhIGdpdmVuIHR5cGUgdG8gYmUgY29uc2lkZXJlZCBhZGRpdGl2ZSByYXRoZXIgdGhhbiBtdXR1 YWxseSBleGNsdXNpdmUuIEZvciBtb3JlIGRldGFpbHMsIHBsZWFzZSBzZWUgc2VjdGlvbiA2LjQg b2YgUkZDNTMxMS4NCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCj4gLS0tLS3Tyrz+1K28/i0t LS0tDQo+ILeivP7IyzogbDJ2cG4tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwydnBuLWJvdW5j ZXNAaWV0Zi5vcmddILT6se0NCj4gWHV4aWFvaHUNCj4gt6LLzcqxvOQ6IDIwMTLE6jXUwjPI1SAx MTowMw0KPiDK1bz+yMs6IEdyZWdvcnkgTWlyc2t5OyBMdWN5IHlvbmcNCj4gs63LzTogbDJ2cG5A aWV0Zi5vcmcNCj4g1vfM4jogcmU6IEludGVyZXN0IGluIElTLUlTIFZQTFMNCj4gDQo+IEhpIEdy ZWcsDQo+IA0KPiBBcyBmb3IgdGhlIExTIFBEVSBzcGFjZSBsaW1pdGF0aW9uLCB0aGUgbWV0aG9k IGRlZmluZWQgaW4gU2ltcGxpZmllZCBFeHRlbnNpb24NCj4gb2YgTGluayBTdGF0ZSBQRFUgKExT UCkgU3BhY2UgZm9yIElTLUlTIFtSRkM1MzExXSBjYW4gYmUgdXNlZCB0byBzb2x2ZSB0aGF0DQo+ IGlzc3VlLg0KPiANCj4gQ29tcGFyZWQgdG8gT1NQRiwgSVMtSVMgaXMgbW9yZSBhZHZhbnRhZ2Vv dXMgaW4gdGhlIGFzcGVjdCBvZg0KPiBhdXRvLWNvbmZpZ3VyYXRpb24gKGUuZy4sIHBsdWcmcGxh eSksIGZvciBleGFtcGxlLCB0aGVyZSBpcyBubyBuZWVkIGZvcg0KPiBjb25maWd1cmluZyBJUCBh ZGRyZXNzZXMgb24gdGhlIGludGVyZmFjZXMgYmV0d2VlbiBJUy1JUyByb3V0ZXJzIGR1ZSB0byB0 aGUNCj4gdW5udW1iZXJlZCBpbnRlcmZhY2UgdXNhZ2UuIEluIGFkZGl0aW9uLCBpdCBjb3VsZCBu YXR1cmFsbHkgcmV1c2UgdGhlDQo+IE1BQy1SZWFjaGFiaWxpdHkgVExWIGRlZmluZWQgaW4gW1JG QzYxNjVdIHRvIHJlYWxpemUgdGhlIGNvbnRyb2wtcGxhbmUgYmFzZWQNCj4gTUFDIGxlYXJuaW5n IG1lY2hhbmlzbS4NCj4gDQo+IENvbXBhcmVkIHRvIEVWUE4sIElTLUlTIFZQTFMgaXRzZWxmIGNv dWxkIGVhc2lseSBzd2l0Y2ggb3ZlciBiZXR3ZWVuDQo+IGNvbnRyb2wtcGxhbmUgYmFzZWQgTUFD IGxlYXJuaW5nIG1lY2hhbmlzbSBhbmQgZGF0YS1wbGFuZSBiYXNlZCBNQUMNCj4gbGVhcm5pbmcg bWVjaGFuaXNtIG9uIGEgcGVyIFZQTFMgaW5zdGFuY2UgYmFzaXMsIGFuZCBtb3N0IGltcG9ydGFu dGx5LA0KPiB3aXRob3V0IHJlcXVpcmluZyB0aGUgYXNzaXN0YW5jZSBvZiBhbiBhZGRpdGlvbmFs IFBCQiBsYXllci4gSW4gZmFjdCwgSSBoYWQgZXZlcg0KPiB0aG91Z2h0IGFib3V0IHVzaW5nIEJH UCBmb3IgYWR2ZXJ0aXNpbmcgcGVyIFZQTFMgaW5zdGFuY2UgbGFiZWwgKHdoaWNoIGlzDQo+IGRp ZmZlcmVudCBmcm9tIHRoZSBQVyBsYWJlbCkgYXMgd2hhdCBJUy1JUyBWUExTIGRvZXMuIFRoaXMg ZGlmZmVyZW5jZSBmcm9tDQo+IEUtVlBOIGlzIHRoZXJlIGlzIG5vIG5lZWQgdG8gYWR2ZXJ0aXNl IE1BQyByb3V0ZXMgaW4gdGhlIEJHUCB1cGRhdGVzLiBJbiBvdGhlcg0KPiB3b3JkcywgaXQgc3Rp bGwgdXNlcyB0aGUgZGF0YS1wbGFuZSBiYXNlZCBNQUMgbGVhcm5pbmcgbWVjaGFuaXNtLiBUaGUN Cj4gZGlmZmVyZW5jZSBmcm9tIGV4aXRpbmcgUFctYmFzZWQgVlBMUyBzb2x1dGlvbnMgW1JGQzQ3 NjEsIFJGQzQ3NjJdIGlzIHRoYXQNCj4gdGhlcmUgaXMgbm8gbmVlZCBmb3IgYSBmdWxsLW1lc2gg b2YgUFdzIGJldHdlZW4gUEUgcm91dGVycy4NCj4gDQo+IEJlc3QgcmVnYXJkcywNCj4gWGlhb2h1 DQo+IA0KPiA+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiA+ILeivP7IyzogbDJ2cG4tYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmddILT6se0NCj4gPiBHcmVnb3J5 IE1pcnNreQ0KPiA+ILeiy83KsbzkOiAyMDEyxOo11MIzyNUgNTo0Mg0KPiA+IMrVvP7IyzogTHVj eSB5b25nDQo+ID4gs63LzTogbDJ2cG5AaWV0Zi5vcmcNCj4gPiDW98ziOiBSRTogSW50ZXJlc3Qg aW4gSVMtSVMgVlBMUw0KPiA+DQo+ID4gRGVhciBMdWN5LA0KPiA+IEknbSBpbnRyaWd1ZWQgaG93 IElTLUlTIFZQTFMgd291bGQgYWRkcmVzcyBzY2FsaW5nIHJlcXVpcmVtZW50cyBvdXRsaW5lZCBp bg0KPiA+IE5WTzMgY2hhcnRlciB3aGVuIGl0cyBUTFYgaXMgbGltaXRlZCB0byAyNTUgYnl0ZXMg YW5kIHRodXMgY2FuIGNhcnJ5IG9ubHkgdXANCj4gdG8NCj4gPiAzMCBWUExTIElELVZQTFMgTGFi ZWxzIHR1cGxlcy4gV291bGRuJ3QgT1NQRiBPcGFxdWUgTFNBIHNjYWxlIGJldHRlcj8gT3INCj4g PiBCR1A/DQo+ID4gV2hhdCBpcyB0aGUgb3ZlcndoZWxtaW5nIGJlbmVmaXQsIHRlY2huaWNhbGx5 IHNwZWFraW5nLCBvZiBJUy1JUyBWUExTIHByb3Bvc2FsDQo+ID4gdnMuIEJHUCBFLVZQTj8NCj4g Pg0KPiA+DQo+ID4gCVJlZ2FyZHMsDQo+ID4gCQlHcmVnDQo+ID4NCj4gPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IGwydnBuLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzps MnZwbi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gPiBMdWN5IHlvbmcNCj4gPiBT ZW50OiBXZWRuZXNkYXksIE1heSAwMiwgMjAxMiAyOjA3IFBNDQo+ID4gVG86IEdpbGVzIEhlcm9u OyBWaXNod2FzIE1hbnJhbDsgTWFjaCBDaGVuDQo+ID4gQ2M6IGwydnBuQGlldGYub3JnDQo+ID4g U3ViamVjdDogUkU6IEludGVyZXN0IGluIElTLUlTIFZQTFMNCj4gPg0KPiA+IEkgc2hhcmUgbXkg MiBjZW50cy4NCj4gPg0KPiA+IEZyb20gdGhlIHRlY2hub2xvZ3kgcGVyc3BlY3RpdmUsIElTLUlT IFZQTFMgYW5kIFRSSUxMIGFyZSB0d28gZGlmZmVyZW50DQo+ID4gdGVjaG5vbG9naWVzLiBGcm9t IHRoZSBhcHBsaWNhYmlsaXR5IHBlcnNwZWN0aXZlLCBUUklMTCBhcHBsaWVzIHRvIGVudGVycHJp c2UNCj4gREMNCj4gPiBhbmQgY2FtcHVzOyBJUy1JUyBWUExTIGNhbiBhcHBseSB0byBtdWx0aS10 ZW5hbnQgcmVxdWlyZWQgYW5kIGxhcmdlciBzY2FsZQ0KPiBEQ3MNCj4gPiB0aGF0IHByb3ZpZGVz IHRoZSBzZXJ2aWNlcyB0byBlbnRlcnByaXNlIGN1c3RvbWVycy4NCj4gPg0KPiA+IEkgcGVyc29u YWxseSBkbyBub3Qgd29yayBvbiBUUklMTCB0ZWNobm9sb2d5IGFuZCBsaWtlIHRvIHNlZSBvdGhl cnMnIG9waW5pb24uDQo+ID4NCj4gPiBMdWN5DQo+ID4NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiA+IEZyb206IEdpbGVzIEhlcm9uIFttYWlsdG86Z2lsZXMuaGVyb25AZ21haWwu Y29tXQ0KPiA+IFNlbnQ6IFdlZG5lc2RheSwgTWF5IDAyLCAyMDEyIDM6MzggUE0NCj4gPiBUbzog VmlzaHdhcyBNYW5yYWw7IE1hY2ggQ2hlbg0KPiA+IENjOiBMdWN5IHlvbmc7IGwydnBuQGlldGYu b3JnDQo+ID4gU3ViamVjdDogUmU6IEludGVyZXN0IGluIElTLUlTIFZQTFMNCj4gPg0KPiA+IElu dGVyZXN0aW5nLg0KPiA+DQo+ID4gQXMgc29tZW9uZSB3aG8gaGFzIGhpcyBuYW1lIG9uIHZhcmlv dXMgVFJJTEwgZHJhZnRzIHdoYXQncyB5b3VyIHRoaW5raW5nIG9uDQo+ID4gdGhlIHJlbGF0aW9u c2hpcCBiZXR3ZWVuIElTSVMgVlBMUyBhbmQgVFJJTEw/DQo+ID4NCj4gPiBHaWxlcw0KPiA+DQo+ ID4gT24gMDIvMDUvMjAxMiAyMDo1OCwgIlZpc2h3YXMgTWFucmFsIiA8dmlzaHdhcy5pZXRmQGdt YWlsLmNvbT4gd3JvdGU6DQo+ID4NCj4gPiA+IEhpIEdpbGVzLA0KPiA+ID4NCj4gPiA+IEkgd291 bGQgYWdyZWUgaGVyZSB0b28uIEkgd291bGQgbGlrZSB0byBzZWUgdGhpcyB3b3JrIHByb2dyZXNz IGFoZWFkDQo+ID4gPiBhcyB3ZWxsLg0KPiA+ID4NCj4gPiA+IFRoYW5rcywNCj4gPiA+IFZpc2h3 YXMNCj4gPiA+DQo+ID4gPiBPbiBTYXQsIEFwciAyOCwgMjAxMiBhdCAzOjA0IEFNLCBNYWNoIENo ZW4gPG1hY2guY2hlbkBodWF3ZWkuY29tPg0KPiA+IHdyb3RlOg0KPiA+ID4NCj4gPiA+PiBGdWxs eSBhZ3JlZSB3aXRoIGx1Y3kgaGVyZS4NCj4gPiA+Pg0KPiA+ID4+IEluIGFkZGl0aW9uLCBzaW5j ZSB0aGUgSVNJUyBWUExTIGxldmVyYWdlcyBhIHVuaWZvcm0gcHJvdG9jb2woSVNJUykNCj4gPiA+ PiBmb3Igc2lnbmFsaW5nIGFuZCBhdXRvIGRpc2NvdmVyeSwgaXQgd291bGQgZ3JlYXRseSBzaW1w bGlmeSB0aGUNCj4gPiA+PiBkZXBsb3ltZW50IGFuZCBtYWludGVuYW5jZSwgZXNwZWNpYWxseSBm b3IgdGhlIERDIG5ldHdvcmtzIHRoYXQgaGF2ZQ0KPiA+ID4+IGFscmVhZHkgZGVwbG95ZWQgSVNJ UyBmb3IgSVAgcm91dGluZy4gU28gSSdkIGxpa2UgdG8gc2VlIHRoZSBkcmFmdCBtb3ZpbmcNCj4g PiBmb3J3YXJkLg0KPiA+ID4+DQo+ID4gPj4gQmVzdCByZWdhcmRzLA0KPiA+ID4+IE1hY2gNCj4g PiA+Pg0KPiA+ID4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4+PiBGcm9tOiBs MnZwbi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZ10gT24N Cj4gPiA+Pj4gQmVoYWxmIE9mIEx1Y3kgeW9uZw0KPiA+ID4+PiBTZW50OiBTYXR1cmRheSwgQXBy aWwgMjgsIDIwMTIgMjo0MyBBTQ0KPiA+ID4+PiBUbzogR2lsZXMgSGVyb247IGwydnBuQGlldGYu b3JnDQo+ID4gPj4+IFN1YmplY3Q6IFJFOiBJbnRlcmVzdCBpbiBJUy1JUyBWUExTDQo+ID4gPj4+ DQo+ID4gPj4+IEhpIEdpbGVzLA0KPiA+ID4+Pg0KPiA+ID4+PiBJdCBzZWVtcyB0aGF0IHRoZSBJ Uy1JUyBWUExTIHByb3ZpZGVzIHRoZSBzb2x1dGlvbiBmb3IgYSBzY2FsYWJsZQ0KPiA+ID4+PiBk YXRhDQo+ID4gPj4gY2VudGVyDQo+ID4gPj4+IG5ldHdvcmsgYXMgbWVudGlvbmVkIGluIHRoZSBk cmFmdC4gSSBhbSBub3Qgc3VyZSBpdCBpcyBwcm9wZXIgdG8NCj4gPiA+Pj4gd2VpZ2h0IHNlcnZp Y2UgcHJvdmlkZXJzIG1vcmUgb24gdGhpcy4gSSBjYW4gc2VlIGlmIGEgc2VydmljZQ0KPiA+ID4+ PiBwcm92aWRlciBhbHJlYWR5IGRlcGxveWVkIGV4aXN0aW5nIFZQTFMsIHRoZSBnYWluIGZyb20g SVMtSVMgVlBMUyBpcw0KPiA+ID4+PiBsZXNzIHRoYW4gdGhlIGNvc3Qgb24gdXBncmFkaW5nIGFs bCB0aGUgZWRnZSBkZXZpY2VzIHRvIHN1cHBvcnQgdGhlDQo+ID4gc29sdXRpb24uDQo+ID4gPj4+ DQo+ID4gPj4+IEhvd2V2ZXIsIGZvciBkYXRhIGNlbnRlciBuZXR3b3JrLCBJUy1JUyBWUExTIGNv dWxkIGJlIGEgdXNlZnVsIHNvbHV0aW9uLg0KPiA+ID4+IEl0DQo+ID4gPj4+IHNpbXBsaWZpZXMg Y3VycmVudCBWUExTIG1lY2hhbmlzbSwgcHJvdmlkZXMgYSBnb29kIHNjYWxhYmlsaXR5LCBhbmQN Cj4gPiA+Pj4gcmVxdWlyZXMgSVAgb25seSBmdW5jdGlvbiBvbiBjb3JlIHN3aXRjaGVzLg0KPiA+ ID4+Pg0KPiA+ID4+PiBBIHZlbmRvciBwcm92aWRlcyBkZXZpY2VzIGZvciBib3RoIHNlcnZpY2Ug cHJvdmlkZXIgbmV0d29yayBhbmQgZGF0YQ0KPiA+ID4+PiBjZW50ZXIgbmV0d29yaywgdGhlIHNv bHV0aW9uIGJyaW5ncyBhIHN5bmVyZ3kgaW4gbGV2ZXJhZ2luZyBWUExTDQo+ID4gPj4+IHNvbHV0 aW9uIGludG8gREMuDQo+ID4gPj4+DQo+ID4gPj4+IFRodXMsIEkgbGlrZSB0byBzZWUgdGhpcyB3 b3JrIG1vdmluZyBmb3J3YXJkLg0KPiA+ID4+Pg0KPiA+ID4+PiBSZWdhcmRzLA0KPiA+ID4+PiBM dWN5DQo+ID4gPj4+DQo+ID4gPj4+DQo+ID4gPj4+DQo+ID4gPj4+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+ID4gPj4+IEZyb206IGwydnBuLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzps MnZwbi1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiA+ID4+PiBCZWhhbGYgT2YgR2lsZXMgSGVyb24N Cj4gPiA+Pj4gU2VudDogRnJpZGF5LCBBcHJpbCAyNywgMjAxMiA3OjU3IEFNDQo+ID4gPj4+IFRv OiBsMnZwbkBpZXRmLm9yZw0KPiA+ID4+PiBTdWJqZWN0OiBJbnRlcmVzdCBpbiBJUy1JUyBWUExT DQo+ID4gPj4+DQo+ID4gPj4+IEhpLA0KPiA+ID4+Pg0KPiA+ID4+PiBBdCB0aGUgSUVURiBtZWV0 aW5nIGluIFBhcmlzIEkgdG9vayBhbiBhY3Rpb24gKGFzIG5vdGVkIGluIHRoZQ0KPiA+ID4+PiBt aW51dGVzKQ0KPiA+ID4+IHRvDQo+ID4gPj4+IHBvbGwgdGhlIFdHIHRvIHNlZSBpZiB0aGVyZSB3 YXMgYW55IGludGVyZXN0IChvdGhlciB0aGFuIGJ5IHRoZQ0KPiA+ID4+PiBhdXRob3JzDQo+ID4g Pj4gb2YNCj4gPiA+Pj4gY291cnNlKSBpbiBwcm9ncmVzc2luZyB0aGUgSVMtSVMgVlBMUyBkcmFm dC4NCj4gPiA+Pj4NCj4gPiA+Pj4gV291bGQgeW91IHBsZWFzZSByZXNwb25kIHRvIHRoaXMgZW1h aWwgaW5kaWNhdGluZyB3aGV0aGVyIG9yIG5vdCB5b3UNCj4gPiA+Pj4gaGF2ZSBpbnRlcmVzdCBp biBzZWVpbmcgdGhpcyBkcmFmdCBwcm9ncmVzcywgaWRlYWxseSBnaXZpbmcNCj4gPiA+Pj4gcmVh c29uaW5nIGZvciB5b3VyIHBvc2l0aW9uLiAgSXQnZCBiZSBlc3BlY2lhbGx5IGludGVyZXN0aW5n IHRvIHNlZQ0KPiA+ID4+PiByZXNwb25zZXMgZnJvbSBzZXJ2aWNlIHByb3ZpZGVycyBvZiBjb3Vy c2UuDQo+ID4gPj4+DQo+ID4gPj4+IElmIHRoZXJlIGFyZSBubyAob3IgdmVyeSBmZXcpIHJlc3Bv bnNlcyB0byB0aGlzIGVtYWlsIHRoZW4gTmFiaWwgYW5kDQo+ID4gPj4+IEkNCj4gPiA+PiB3aWxs DQo+ID4gPj4+IHByb2JhYmx5IGludGVycHJldCB0aGF0IGFzIG1lYW5pbmcgdGhlcmUncyBpbnN1 ZmZpY2llbnQgaW50ZXJlc3QgdG8NCj4gPiA+Pj4gcHJvZ3Jlc3MuICBPZiBjb3Vyc2UgaXQgbWF5 IGp1c3QgbWVhbiB0aGF0IHlvdSBhbGwgbWlzc2VkIHRoaXMgZW1haWwNCj4gPiA+Pj4gaW4NCj4g PiA+PiB0aGUNCj4gPiA+Pj4gZGVsdWdlIG9mIGRlYmF0ZSBvbiBFLVRyZWUgOykNCj4gPiA+Pj4N Cj4gPiA+Pj4gR2lsZXMNCj4gPiA+Pj4NCj4gPiA+Pg0KPiA+ID4+DQo+ID4NCg0K From giles.heron@gmail.com Thu May 3 01:51: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 93A6C21F84BF for ; Thu, 3 May 2012 01:51:43 -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 hkc34pbIr5BH for ; Thu, 3 May 2012 01:51:42 -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 9206921F8474 for ; Thu, 3 May 2012 01:51:42 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1015452wgb.13 for ; Thu, 03 May 2012 01:51:41 -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=o9yvPorCW4OWryeArKvunRISypdtZ3i06yV4Xq7hfD8=; b=fOTCZ7Jqr1Tx9CNEW0SL2jRY/3wAyHpYXCycyKaq6E2u/A85byL03HB2ZJFat/zrDl lknxbe8wJENpIe2qH7gHAm7GgUWQ1CkJrHZ+l9mphTEuc5CpZzuRd7Arr+M8o0lJQ7g6 WmJ817SJGW9Pstog9ZDcDTg6gn+g9joStsFRDabAuwoMIhbew9n4qS5YfeshbkEGSfAW ARmRb0r0TNILz6DY0d7AQy7jwhxywyqeosVHWyP5PbVxYUexplhxv0UbzarFElT/kXXA XDcPoaf2Zc7xT8UiUe7Hf/+L/gESD7LKJuMFMnAkqnkSIpd+xLh5OX8Hau5ldRH9n90P yuig== Received: by 10.216.135.219 with SMTP id u69mr848036wei.89.1336035101790; Thu, 03 May 2012 01:51:41 -0700 (PDT) Received: from [10.147.56.14] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id ff2sm1376759wib.9.2012.05.03.01.51.39 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 May 2012 01:51:40 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Thu, 03 May 2012 09:52:10 +0100 Subject: Re: Interest in IS-IS VPLS From: Giles Heron To: sajassi , Nabil Bitar Message-ID: Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0oo3KJ1wSZdtM/HEigFxRLQ5av6AARqg4SAAf687w= In-Reply-To: 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: Thu, 03 May 2012 08:51:43 -0000 Hi Ali, On 02/05/2012 14:03, "sajassi" wrote: > > > Giles, Nabil: > > I am wondering if there is a plan to yet again re-charter L2VPN. Since this > draft intends to use a completely different data-plane and control plane > mechanism outside VPLS framework and RFC 4761 & 4762. When we introduced > evpn/pbb-evpn, because of different data-plane/control-plane processing, we > had to go through re-chartering and thus the evpn solution is now explicitly > called out in the charter. No plans. But equally, as you well know, we have always allowed discussion on out-of-charter items (either pending charter changes - as with E-VPN/E-Tree, or because they've been within the broad scope of layer 2 VPN - your own discussions of TRILL E-VPN for example...) ;) > Every solution that this WG has worked on so far has explicitly been called > out in the charter. Indeed. > If the intention is to re-charter the WG yet again, then it would be nice to > solicit AD's opinion first specially in light of the new NOV3 WG which is > specifically intended to cover this kind of topic. As I've said above - no plans to re-charter at this point. Though we may need to address that for TRILL E-VPN, for example. It was within the scope of our first drafts of the new charter but appears to be excluded now (largely because I hacked vast quantities of verbiage out of the charter at the ADs' insistence). > If ADs (or you) think that this solution should be covered in NVo3 WG, then > all these discussions around this draft in this WG is a moot point. Well, all the proponents of IS-IS VPLS on this thread seem to see it as a data-centre solution. A data-centre solution that is an overlay on IP seems (to me at least) to be better aligned to the NVO3 scope than the L2VPN scope. Or that could just be me being lazy and saying "IS-IS VPLS isn't my problem" and punting it to Matthew and Benson ;) Giles > Regards, > Ali > From nabil.n.bitar@verizon.com Thu May 3 07:46: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 3DC5D21F8495 for ; Thu, 3 May 2012 07:46:49 -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 m2cxHkCsveHn for ; Thu, 3 May 2012 07:46:48 -0700 (PDT) Received: from fldsmtpe03.verizon.com (fldsmtpe03.verizon.com [140.108.26.142]) by ietfa.amsl.com (Postfix) with ESMTP id 6788421F85EF for ; Thu, 3 May 2012 07:46:48 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by fldsmtpe03.verizon.com with ESMTP; 03 May 2012 14:46:44 +0000 From: "Bitar, Nabil N" To: Giles Heron , Sagessi , "Bitar, Nabil N" X-IronPort-AV: E=Sophos;i="4.75,523,1330905600"; d="scan'208";a="264366730" Received: from fldp1lumxc7hb01.verizon.com (HELO FLDP1LUMXC7HB01.us.one.verizon.com) ([166.68.45.78]) by fldsmtpi01.verizon.com with ESMTP; 03 May 2012 14:46:42 +0000 Received: from fldp1lumxc7v63.us.one.verizon.com ([169.254.3.170]) by FLDP1LUMXC7HB01.us.one.verizon.com ([166.68.45.78]) with mapi; Thu, 3 May 2012 10:46:42 -0400 Date: Thu, 3 May 2012 10:46:37 -0400 Subject: Re: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0pO43RmKP06QWzR6uXQBPJa3Jxhg== 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.10.0.110310 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, 03 May 2012 14:46:49 -0000 Hi, Thanks Giles. I concur with Giles, and have nothing to add. Thanks, Nabil On 5/3/12 4:52 AM, "Giles Heron" wrote: >Hi Ali, > >On 02/05/2012 14:03, "sajassi" wrote: > >>=20 >>=20 >> Giles, Nabil: >>=20 >> I am wondering if there is a plan to yet again re-charter L2VPN. Since >>this >> draft intends to use a completely different data-plane and control plane >> mechanism outside VPLS framework and RFC 4761 & 4762. When we introduced >> evpn/pbb-evpn, because of different data-plane/control-plane >>processing, we >> had to go through re-chartering and thus the evpn solution is now >>explicitly >> called out in the charter. > >No plans. But equally, as you well know, we have always allowed >discussion >on out-of-charter items (either pending charter changes - as with >E-VPN/E-Tree, or because they've been within the broad scope of layer 2 >VPN >- your own discussions of TRILL E-VPN for example...) ;) >=20 >> Every solution that this WG has worked on so far has explicitly been >>called >> out in the charter. > >Indeed. > >> If the intention is to re-charter the WG yet again, then it would be >>nice to >> solicit AD's opinion first specially in light of the new NOV3 WG which >>is >> specifically intended to cover this kind of topic. > >As I've said above - no plans to re-charter at this point. Though we may >need to address that for TRILL E-VPN, for example. It was within the >scope >of our first drafts of the new charter but appears to be excluded now >(largely because I hacked vast quantities of verbiage out of the charter >at >the ADs' insistence). > >> If ADs (or you) think that this solution should be covered in NVo3 WG, >>then >> all these discussions around this draft in this WG is a moot point. > >Well, all the proponents of IS-IS VPLS on this thread seem to see it as a >data-centre solution. A data-centre solution that is an overlay on IP >seems >(to me at least) to be better aligned to the NVO3 scope than the L2VPN >scope. > >Or that could just be me being lazy and saying "IS-IS VPLS isn't my >problem" >and punting it to Matthew and Benson ;) > >Giles > >> Regards, >> Ali >>=20 > > From prvs=0470f48b73=hshah@ciena.com Thu May 3 08:17: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 2EEFC21F8618 for ; Thu, 3 May 2012 08:17:58 -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=[AWL=0.000, 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 AvPnlncN0Djf for ; Thu, 3 May 2012 08:17:57 -0700 (PDT) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) by ietfa.amsl.com (Postfix) with ESMTP id 984C221F85D7 for ; Thu, 3 May 2012 08:17:57 -0700 (PDT) Received: from pps.filterd (m0000419 [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.14.4/8.14.4) with SMTP id q43FFm2Y011363; Thu, 3 May 2012 11:17:55 -0400 Received: from mdwexght01.ciena.com (LIN1-118-36-28.ciena.com [63.118.36.28]) by mx0a-00103a01.pphosted.com with ESMTP id 14kuuvg6ya-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 03 May 2012 11:17:54 -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; Thu, 3 May 2012 11:17:54 -0400 Received: from MDWEXGMB02.ciena.com ([::1]) by MDWEXCHCGSIHT01.ciena.com ([::1]) with mapi; Thu, 3 May 2012 11:17:54 -0400 From: "Shah, Himanshu" To: "Bitar, Nabil N" , Giles Heron , Sagessi Date: Thu, 3 May 2012 11:17:51 -0400 Subject: RE: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0pO43RmKP06QWzR6uXQBPJa3JxhgAAwmdg Message-ID: References: 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-18880.007 X-TM-AS-Result: No--18.519200-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7580, 1.0.260, 0.0.0000 definitions=2012-05-03_06:2012-05-03, 2012-05-03, 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-1205030147 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, 03 May 2012 15:17:58 -0000 All - Based on the current discussions/feedback expressed on the mailing list,=20 We, the authors, have decided to suspend IS-IS VPLS draft considerations=20 as a work item in L2VPN WG. We will reevaluate the applicability and the target WG once the NVO3 requirements are clarified. Thanks for the input. Xiahou and Himanshu -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of B= itar, Nabil N Sent: Thursday, May 03, 2012 10:47 AM To: Giles Heron; Sagessi; Bitar, Nabil N Cc: l2vpn@ietf.org Subject: Re: Interest in IS-IS VPLS Hi, Thanks Giles. I concur with Giles, and have nothing to add. Thanks, Nabil On 5/3/12 4:52 AM, "Giles Heron" wrote: >Hi Ali, > >On 02/05/2012 14:03, "sajassi" wrote: > >>=20 >>=20 >> Giles, Nabil: >>=20 >> I am wondering if there is a plan to yet again re-charter L2VPN. Since >>this >> draft intends to use a completely different data-plane and control plane >> mechanism outside VPLS framework and RFC 4761 & 4762. When we introduced >> evpn/pbb-evpn, because of different data-plane/control-plane >>processing, we >> had to go through re-chartering and thus the evpn solution is now >>explicitly >> called out in the charter. > >No plans. But equally, as you well know, we have always allowed >discussion >on out-of-charter items (either pending charter changes - as with >E-VPN/E-Tree, or because they've been within the broad scope of layer 2 >VPN >- your own discussions of TRILL E-VPN for example...) ;) >=20 >> Every solution that this WG has worked on so far has explicitly been >>called >> out in the charter. > >Indeed. > >> If the intention is to re-charter the WG yet again, then it would be >>nice to >> solicit AD's opinion first specially in light of the new NOV3 WG which >>is >> specifically intended to cover this kind of topic. > >As I've said above - no plans to re-charter at this point. Though we may >need to address that for TRILL E-VPN, for example. It was within the >scope >of our first drafts of the new charter but appears to be excluded now >(largely because I hacked vast quantities of verbiage out of the charter >at >the ADs' insistence). > >> If ADs (or you) think that this solution should be covered in NVo3 WG, >>then >> all these discussions around this draft in this WG is a moot point. > >Well, all the proponents of IS-IS VPLS on this thread seem to see it as a >data-centre solution. A data-centre solution that is an overlay on IP >seems >(to me at least) to be better aligned to the NVO3 scope than the L2VPN >scope. > >Or that could just be me being lazy and saying "IS-IS VPLS isn't my >problem" >and punting it to Matthew and Benson ;) > >Giles > >> Regards, >> Ali >>=20 > > From josh.rogers@twcable.com Thu May 3 08:27: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 E904D21F85D8 for ; Thu, 3 May 2012 08:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.078 X-Spam-Level: X-Spam-Status: No, score=0.078 tagged_above=-999 required=5 tests=[AWL=-0.059, 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 qqihR45h-6VD for ; Thu, 3 May 2012 08:27:58 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9AC21F853C for ; Thu, 3 May 2012 08:27:57 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.75,523,1330923600"; d="scan'208";a="359513086" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 03 May 2012 11:25:50 -0400 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.36]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Thu, 3 May 2012 11:26:53 -0400 From: "Rogers, Josh" To: Jiangyuanlong , Daniel Cohn , "Fedyk, Donald (Don)" , "Henderickx, Wim (Wim)" , Lucy yong Date: Thu, 3 May 2012 11:26:52 -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: Ac0pQSraGW4rn0+KRdOJ0wAsLb60PA== Message-ID: In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA55F9F@SZXEML508-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" 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, 03 May 2012 15:28:00 -0000 [JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service requirements from MEF, it has nothing to do with the solutions. Could you give a hint on how you can provision this service E-NNI otherwise? BTW, if configuring or signalling two PWs is not a problem, why configuring or signalling two VLANs will become a problem? After all, more nodes may need to be configured or signalled for 2PW (T-PEs and S-PEs) compared with 2VLAN (only T-PEs). There is no other way (if both MPLS domains are part of the same ETREE, rather than doing something more like H-VPLS, where one domain has point to points to the other domain which handles the ETREE instance) if you are using an ENNI. The other method, (not mentioned earlier) is tying the two MPLS domains together via labeled unicast (much preferred over E-NNI in my opinion) Configuring two VLAN's isn't really a 'problem' any more than two PW's. I wasn't saying that configuring two VLAN's was difficult, I was objecting to the statement that configuring two PW's is difficult. I find the differences between these two methods rather slight. The 'tie-breaker' for me is by placing the forwarding decision on the ingress PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get more control over where the traffic goes, and in my mind it provides a cleaner destination between customer traffic and forwarding plane. I'm accustomed to looking at a psuedowire and knowing where its going, with the 2vlan method, I can see the psuedowire, but must go to the egress PE to see if it will be dropped there, or forwarded to one or more AC's. Again, the difference here is slight, and I would honestly be happy to see either of them come to fruition. Please don't infer that I think the 2vlan method is 'bad' or has intrinsic problems, because I don't believe that. I just prefer the multi-PW method. -Josh On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: >Josh, please see my comments in line. > >Thanks >Yuanlong > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Thursday, May 03, 2012 10:51 AM >To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >(Wim); Lucy yong >Cc: l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >Yuanlong, > >Or better yet, include in the draft a 'standard' value for root sourced >VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You would also >have to require the the implementation NOT use global VLAN's, however >(since each instance would be using the same values). In this way, no >signaling or manual configuration is required for remote PE's to know how >to classify traffic. >[JY] Indeed, we discussed this possibility during the f2f meeting in >Paris. But, there are some restrictions as you mentioned, and >furthermore: >1) Some vendors already used S-VLAN to distinguish their VSIs in the PE; >2) Forwarding plane of a PE needs to be revised to be aware of this VLAN >ID. >Therefore, this 'standard value' approach seems more disruptive compared >with the other means and not a good candidate option. > >Regarding switching PE's=A9 Multi-PW means more than one PW, yes. I don'= t >see this as a real problem. In general, design should try and avoid using >S-PE's, but if you must, its going to mean extra work, no matter how you >look at it. Two PW's for each Etree being switched instead of one is not >alarming or concerning to me. On the other hand, if you use a dot1q >(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's an >two egress VLAN's if you want the Etree to be handled on both sides (and >if you use the 'standard' VID's as I mentioned above, you'd have to do >mapping to non-standard and back) >[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >requirements from MEF, it has nothing to do with the solutions. Could you >give a hint on how you can provision this service E-NNI otherwise? BTW, >if configuring or signalling two PWs is not a problem, why configuring or >signalling two VLANs will become a problem? After all, more nodes may >need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >with 2VLAN (only T-PEs). > >In general, I still prefer multi-PW, primarily because I prefer the >separation of the traffic in the network's forwarding plane, rather than >shipping it everywhere and deciding whether to forward to the AC when it >gets to the egress PE. I'm having a hard time putting my finger exactly >on what it is, or articulating the idea, but it seems that by having the >traffic placed into two psuedowires, I have more flexibility and ease of >configuration when it comes to E-NNI's, service multiplexed UNI's, and >H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >configuration' statement assumes BGP-VPLS, as was pointed out earlier >LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >PW's could really change that perception. >[JY] Are you saying that we need to develop a totally new forwarding >plane rather than using the Ethernet forwarding plane as described in the >existing work? > >I hope we can move forward with one of these soon, >[JY] me too. > >Josh > > >On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: > >>Daniel, >> >>Not aware that we had a discussion on this before, but IMHO the >>allocation of internal S-VLAN can be automatic, and manuel configuration >>of this mapping may not be needed at all. For example, an S-VLAN >>allocation module in the management plane in a PE can do this kind of >>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>way from a free S-VLAN ID pool. Once the interal S-VLANs are allocated, >>the mapping is determined and no other configuration is needed. >> >>The only difference from RFC 6246 is, for E-LAN, we only need to allocate >>a single S-VLAN in the VPLS domain, but for E-Tree, we need to allocate >>two S-VLANs in the VPLS domain. >> >>On the other hand, for the multi-PW approach, two PWs need to be >>configured for a E-Tree service. When MS-PW is used in the network, for >>every S-PE, we need to configure two ingress PW segments and two egress >>PW segments. In this case, I don't think we need to use fixed PW labels >>across the network for fear of configuration complexity. >> >>Regards, >>Yuanlong >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Wednesday, May 02, 2012 8:01 PM >>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>josh.rogers@twcable.com >>Cc: l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Inline. >> >>-----Original Message----- >>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>Sent: Wednesday, May 02, 2012 12:30 PM >>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>josh.rogers@twcable.com >>Cc: l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi Daniel, Please see my comments in line. >> >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Wednesday, May 02, 2012 3:55 PM >>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>yong; josh.rogers@twcable.com >>Cc: l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi Yuanlong, >> >>The problem is not with the total number of S-VLAN IDs, I agree that >>normally there won't be more than 2047. The problem is that if you don't >>support all VLAN IDs, you need S-VLAN space coordination with the >>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to 2047". >>Which won't always be in line with an existing deployment. >>[JY] This is not the case. If the total number is no more than 2047, it >>surely can be supported. The S-VLAN space of user domain is totally >>different from the S-VLAN in the provider domain and they can be >>overlapped, I don't see why we need S-VLAN space coordination between >>them. >> >>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>fixed, and therefore the IEEE S-VID that can be supported is also fixed. >> >>Of course you can configure the mapping in each PE according to operator >>requirements but as we discussed before this increases complexity. >> >>Relying on PBB-VPLS imposes additional limitations on backward >>compatibility. >>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>think they may well need MAC-in-MAC in their networks for the >>scalability issue. As you know, only PBB VPLS can provide both. >> >>Daniel >> >>-----Original Message----- >>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>Sent: Wednesday, May 02, 2012 5:07 AM >>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>josh.rogers@twcable.com >>Cc: l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi Daniel, >> >>As you can see, both cases are discussed in the I-D. >> >>With regard to case 1) (that is, S-VLAN translation), since the access >>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>they need to be configured on a PE anyway, and as the past emails by >>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>mapping. >> >>With regard to S-VID space reduction, the constraint is valid only when >>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>typical and with no such limits as we already discussed in the f2f >>meeting. >> >>Even if there are 4094 S-VLANs in a single E-Tree access as you >>described (not sure this is a valid use case in real life), PBB-VPLS can >>still be used. >> >>Regards, >>Yuanlong >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Monday, April 30, 2012 10:34 PM >>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>Jiangyuanlong; josh.rogers@twcable.com >>Cc: l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>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] >>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 >> >>---------------------------------------------------------------------- > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use of the individual or entity to which it is addressed. If you >are not the intended recipient of this E-mail, you are hereby notified >that any dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this 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 sajassi@cisco.com Thu May 3 10:05: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 C993721F8665 for ; Thu, 3 May 2012 10:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.172 X-Spam-Level: X-Spam-Status: No, score=-10.172 tagged_above=-999 required=5 tests=[AWL=0.427, 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 iyRETVuKD25s for ; Thu, 3 May 2012 10:05:05 -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 2B13A21F8664 for ; Thu, 3 May 2012 10:05:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sajassi@cisco.com; l=984; q=dns/txt; s=iport; t=1336064705; x=1337274305; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=ZC/FbGaA00Aoi3wvRlNK2c6+npdOZCtqOxzaXE8UUrc=; b=JDqiGbPWqosy7JW7Eyo8q4vl91mAZ5e2vQHoF+7B/ZLWYthWogCboA7c 8bI1yMfcbsESE+npi2u0y7qQnRKWPlPQ76Mj/WqIT4NqGElgpJNLqJw0o z4+nTsGYFicc4x4m6yw7ls4mZO2Beud2r5IdGAr5+xpStVQvYuW7riqHC 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAGK6ok+rRDoH/2dsb2JhbABEsneBB4IJAQEBAwESAScCATwSAQgJgRQBAQQBDSAHh2YEAZpYoBiRCASIZIUth22OWYFpgwg X-IronPort-AV: E=Sophos;i="4.75,524,1330905600"; d="scan'208";a="40788580" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 03 May 2012 17:05:05 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q43H54Zh003682; Thu, 3 May 2012 17:05:04 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, 3 May 2012 10:05:04 -0700 Received: from 10.128.2.24 ([10.128.2.24]) by xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) with Microsoft Exchange Server HTTP-DAV ; Thu, 3 May 2012 17:05:04 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Thu, 03 May 2012 10:05:03 -0700 Subject: Re: Interest in IS-IS VPLS From: sajassi To: Giles Heron , Nabil Bitar Message-ID: Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0oo3KJ1wSZdtM/HEigFxRLQ5av6AARqg4SAAf687wAETa4Gg== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 03 May 2012 17:05:04.0656 (UTC) FILETIME=[E26C7900:01CD294E] 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, 03 May 2012 17:05:06 -0000 Hi Giles, > > As I've said above - no plans to re-charter at this point. Though we may > need to address that for TRILL E-VPN, for example. It was within the scope > of our first drafts of the new charter but appears to be excluded now > (largely because I hacked vast quantities of verbiage out of the charter at > the ADs' insistence). > TRILL-EVPN is a member of E-VPN family solution (just like PBB-EVPN) and it shows how E-VPN can be used to connect TRILL islands across MPLS/IP core using E-VPN solution (e.g., it is an inter-DC solution for MPLS/IP core). And it adheres to the charter specification: "5. Ethernet VPN (E-VPN) - An enhanced Layer-2 service that emulates an Ethernet (V)LAN across a PSN. E-VPN supports load-sharing across multiple connections from a Layer-2 site to an L2VPN service. E-VPN is primarily targeted to support large-scale L2VPNs with resiliency requirements not satisfied by other L2VPN solutions" Cheers, Ali From giles.heron@gmail.com Thu May 3 10:55: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 BDC2221F864C for ; Thu, 3 May 2012 10:55:47 -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 KafVy0wJ+xmE for ; Thu, 3 May 2012 10:55:47 -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 4BC4821F8652 for ; Thu, 3 May 2012 10:55:40 -0700 (PDT) Received: by werf13 with SMTP id f13so264457wer.31 for ; Thu, 03 May 2012 10:55:39 -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=o//1EZI2LhzQ8zcktUzOjo4Eps+i4962YpAq0hQVy3Y=; b=zFzJ8AKAkvpsqAVvukp7V8aYyg+wvnQn8LyKtbo90sm7zz/pvTirA15gtBcWsZiURw r6W242NN8vCl2aUJgsnz32JPVq7C9h2/dnLdX8QofLIisAaenLbya6ljZhxZnVq0FrEA G0C/+i7hnbmGJwoJ/WrrSOs/4fqKD8co/7U13P3eiO5yeq+asbaUfa5G3iD6clBOWeBu M9XuFiO85IR3EZpg87mu+cQnojmhACLztptX30OpMGaWhTPyGxdn8BJSIJdgzwkh+PeV juHuQcBjJ2GLBZYnisYBfOZ68YBXox1Kwxv/Wbrr6nBzvinoaRA3siRmvc/YBURdxsGm R4IA== Received: by 10.180.86.197 with SMTP id r5mr5432353wiz.21.1336067739480; Thu, 03 May 2012 10:55:39 -0700 (PDT) Received: from [10.55.84.33] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id 6sm1202740wiz.1.2012.05.03.10.55.35 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 May 2012 10:55:38 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Thu, 03 May 2012 18:56:03 +0100 Subject: Re: Interest in IS-IS VPLS From: Giles Heron To: sajassi , Nabil Bitar Message-ID: Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0oo3KJ1wSZdtM/HEigFxRLQ5av6AARqg4SAAf687wAETa4GgABx/o7 In-Reply-To: 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: Thu, 03 May 2012 17:55:47 -0000 Hi Ali, On 03/05/2012 18:05, "sajassi" wrote: > Hi Giles, > > >> >> As I've said above - no plans to re-charter at this point. Though we may >> need to address that for TRILL E-VPN, for example. It was within the scope >> of our first drafts of the new charter but appears to be excluded now >> (largely because I hacked vast quantities of verbiage out of the charter at >> the ADs' insistence). >> > > TRILL-EVPN is a member of E-VPN family solution (just like PBB-EVPN) and it > shows how E-VPN can be used to connect TRILL islands across MPLS/IP core > using E-VPN solution (e.g., it is an inter-DC solution for MPLS/IP core). > And it adheres to the charter specification: > > "5. Ethernet VPN (E-VPN) - An enhanced Layer-2 service that > emulates an Ethernet (V)LAN across a PSN. E-VPN supports > load-sharing across multiple connections from a Layer-2 site > to an L2VPN service. E-VPN is primarily targeted to support > large-scale L2VPNs with resiliency requirements not satisfied > by other L2VPN solutions" Except a TRILL island isn't an Ethernet (V)LAN. Though I guess you could argue that neither is a PBB network. The earlier drafts had wording along the lines of: "For instance, interworking between an IEEE 802.1q, 802.1ah, 802.1aq or TRILL data plane or control plane with an L2VPN data plane or control plane should be identified when needed and solutions described." I hacked that out - at the ADs' insistence. And they're the ones now saying it's out of scope ;) Giles > > Cheers, > Ali > From sajassi@cisco.com Thu May 3 12:19: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 6E64A21F8680 for ; Thu, 3 May 2012 12:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.225 X-Spam-Level: X-Spam-Status: No, score=-10.225 tagged_above=-999 required=5 tests=[AWL=0.374, 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 qsIXslcIHhJY for ; Thu, 3 May 2012 12:19:34 -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 D1B3A21F8655 for ; Thu, 3 May 2012 12:19:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sajassi@cisco.com; l=1024; q=dns/txt; s=iport; t=1336072774; x=1337282374; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=IZuNUerS0D9qkrS+LgwmdMY4SSoGRZtpA0JyFkyvB0M=; b=mHe0k96SkSPwnGtW9HrH/x7UsC+houYc4l/OkxCfLEWXoJo06WLmnzNZ /h+8izdw34t2HRRv4qUNEhN2OgEujs1cYTqnTqMeeIC6GFsrnoPwOSHUI Ih45bVi2BWqLgmads8thjeRfF4ZE7xgiS8lX+7+plu4D6ju56y/s27Jxp s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAPjZok+rRDoI/2dsb2JhbABFsnuBB4IJAQEBAwESAScCATwSAQgJgRQBAQQBDSAHh2YEAZpboCSRCASIZIUth22OWYFpgwg X-IronPort-AV: E=Sophos;i="4.75,526,1330905600"; d="scan'208";a="43384073" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 03 May 2012 19:19:33 +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 q43JJXA4004188; Thu, 3 May 2012 19:19:33 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, 3 May 2012 12:19:32 -0700 Received: from 10.128.2.24 ([10.128.2.24]) by xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) with Microsoft Exchange Server HTTP-DAV ; Thu, 3 May 2012 19:19:32 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Thu, 03 May 2012 12:19:31 -0700 Subject: Re: Interest in IS-IS VPLS From: sajassi To: Giles Heron , Nabil Bitar Message-ID: Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0oo3KJ1wSZdtM/HEigFxRLQ5av6AARqg4SAAf687wAETa4GgABx/o7AALqQB8= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 03 May 2012 19:19:32.0928 (UTC) FILETIME=[AB7D1400:01CD2961] 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, 03 May 2012 19:19:35 -0000 Hi Giles, > > Except a TRILL island isn't an Ethernet (V)LAN. Though I guess you could > argue that neither is a PBB network. TRILL network provides (V)LAN services just like PBB/SPB network that provides (V)LAN services. Although I agree with you it is not an 802.1Q network :-) > > The earlier drafts had wording along the lines of: > > "For instance, interworking between an IEEE 802.1q, 802.1ah, 802.1aq or > TRILL data plane or control plane with an L2VPN data plane or control plane > should be identified when needed and solutions described." > > I hacked that out - at the ADs' insistence. And they're the ones now saying > it's out of scope ;) If the ADs still think it is outside of the scope of L2VPN, then the question is where to cover them ? Because it is clearly outside of TRILL WG scope and it fits much better within L2VPN WG. Or maybe, they want to spin off another WG to just cover that :-) Cheers, Ali > > Giles > > >> >> Cheers, >> Ali >> > > From lucy.yong@huawei.com Thu May 3 13:34: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 8038021F867E for ; Thu, 3 May 2012 13:34:03 -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.021, 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 mpFmJmxwRuab for ; Thu, 3 May 2012 13:34:03 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id B28BA21F8664 for ; Thu, 3 May 2012 13:34:02 -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 AFM59685; Thu, 03 May 2012 16:34:02 -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; Thu, 3 May 2012 13:31:57 -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; Thu, 3 May 2012 13:31:58 -0700 From: Lucy yong To: sajassi , Giles Heron , Nabil Bitar Subject: RE: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0oo3KJO48LuIhSPkS8Et2e3RTHugARqg4SAAf687wAETa4GgAG6vgw Date: Thu, 3 May 2012 20:31:57 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D330E8F11@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.102] 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, 03 May 2012 20:34:03 -0000 Hi Ali, "5. Ethernet VPN (E-VPN) - An enhanced Layer-2 service that emulates an Ethernet (V)LAN across a PSN. E-VPN supports load-sharing across multiple connections from a Layer-2 site to an L2VPN service. E-VPN is primarily targeted to support large-scale L2VPNs with resiliency requirements not satisfied by other L2VPN solutions" [[LY]] IMO, E-VPN enhancement is to support multi-homing with active-active= mode. Load-sharing across multiple connections from a layer-2 site is desi= red when this mode is used. Current VPLS can provide resiliency requirement= when the multi-homing site configured with active-standby mode. Regards, Lucy Cheers, Ali =20 From jiangyuanlong@huawei.com Thu May 3 18:22: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 21E8621F860F for ; Thu, 3 May 2012 18:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.175 X-Spam-Level: X-Spam-Status: No, score=-2.175 tagged_above=-999 required=5 tests=[AWL=-0.176, 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 X9k6880fJ+2q for ; Thu, 3 May 2012 18:22:27 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 80CF821F85DD for ; Thu, 3 May 2012 18:22:27 -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 AFU75883; Thu, 03 May 2012 21:22:26 -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; Thu, 3 May 2012 18:20:45 -0700 Received: from SZXEML433-HUB.china.huawei.com (10.72.61.61) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 3 May 2012 18:20:51 -0700 Received: from SZXEML508-MBX.china.huawei.com ([169.254.5.215]) by szxeml433-hub.china.huawei.com ([10.72.61.61]) with mapi id 14.01.0323.003; Fri, 4 May 2012 09:20:40 +0800 From: Jiangyuanlong To: "Rogers, Josh" , Daniel Cohn , "Fedyk, Donald (Don)" , "Henderickx, Wim (Wim)" , 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: AQHNI1NEA18PKDoBDEy6zAcXiVu2LpasuNMAgAYGiYCAAAzygIAAAjQAgAAAAYCAAASFAIAAAOoAgAAYGACAAAPTgIACzjKAgABsbmCAABSDMIAAJEvQgADhaeD//53EgIAAk10ggAA/vACAASTWUA== Date: Fri, 4 May 2012 01:20:40 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA560F0@SZXEML508-MBX.china.huawei.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA55F9F@SZXEML508-MBX.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.40.73] Content-Type: text/plain; charset="iso-8859-2" 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: Fri, 04 May 2012 01:22:29 -0000 Josh, thank you for the comments, please see my further comments with [JY2]= . -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com]=20 Sent: Thursday, May 03, 2012 11:27 PM To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim);= Lucy yong Cc: l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? [JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service requirements from MEF, it has nothing to do with the solutions. Could you give a hint on how you can provision this service E-NNI otherwise? BTW, if configuring or signalling two PWs is not a problem, why configuring or signalling two VLANs will become a problem? After all, more nodes may need to be configured or signalled for 2PW (T-PEs and S-PEs) compared with 2VLAN (only T-PEs). There is no other way (if both MPLS domains are part of the same ETREE, rather than doing something more like H-VPLS, where one domain has point to points to the other domain which handles the ETREE instance) if you are using an ENNI. The other method, (not mentioned earlier) is tying the two MPLS domains together via labeled unicast (much preferred over E-NNI in my opinion) Configuring two VLAN's isn't really a 'problem' any more than two PW's. I wasn't saying that configuring two VLAN's was difficult, I was objecting to the statement that configuring two PW's is difficult. [JY2] Thanks, I see your point. I take the example of 2PW configuration jus= t to show that using fixed global values to simplify configuration makes no= sense. Personally I also don't think configuration is a problem for both s= olutions. I find the differences between these two methods rather slight. The 'tie-breaker' for me is by placing the forwarding decision on the ingress PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get more control over where the traffic goes, and in my mind it provides a cleaner destination between customer traffic and forwarding plane. I'm accustomed to looking at a psuedowire and knowing where its going, with the 2vlan method, I can see the psuedowire, but must go to the egress PE to see if it will be dropped there, or forwarded to one or more AC's. [JY2] if the egress PE is attached with pure leafs, 2VLAN approach can also= separate the leaf traffic in the ingress PE and filter it there (already d= etailed in the Optimization Mode in the I-D); if the egress PE is attached = with pure roots or with both roots and leafs, it seems all traffic must be = transported to the egress PE and be filtered there, I see no difference in = behaviour for these solutions. Or did I miss something? Again, the difference here is slight, and I would honestly be happy to see either of them come to fruition. Please don't infer that I think the 2vlan method is 'bad' or has intrinsic problems, because I don't believe that. I just prefer the multi-PW method. -Josh On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: >Josh, please see my comments in line. > >Thanks >Yuanlong > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Thursday, May 03, 2012 10:51 AM >To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >(Wim); Lucy yong >Cc: l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >Yuanlong, > >Or better yet, include in the draft a 'standard' value for root sourced >VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You would also >have to require the the implementation NOT use global VLAN's, however >(since each instance would be using the same values). In this way, no >signaling or manual configuration is required for remote PE's to know how >to classify traffic. >[JY] Indeed, we discussed this possibility during the f2f meeting in >Paris. But, there are some restrictions as you mentioned, and >furthermore: >1) Some vendors already used S-VLAN to distinguish their VSIs in the PE; >2) Forwarding plane of a PE needs to be revised to be aware of this VLAN >ID. >Therefore, this 'standard value' approach seems more disruptive compared >with the other means and not a good candidate option. > >Regarding switching PE's=A9 Multi-PW means more than one PW, yes. I don'= t >see this as a real problem. In general, design should try and avoid using >S-PE's, but if you must, its going to mean extra work, no matter how you >look at it. Two PW's for each Etree being switched instead of one is not >alarming or concerning to me. On the other hand, if you use a dot1q >(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's an >two egress VLAN's if you want the Etree to be handled on both sides (and >if you use the 'standard' VID's as I mentioned above, you'd have to do >mapping to non-standard and back) >[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >requirements from MEF, it has nothing to do with the solutions. Could you >give a hint on how you can provision this service E-NNI otherwise? BTW, >if configuring or signalling two PWs is not a problem, why configuring or >signalling two VLANs will become a problem? After all, more nodes may >need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >with 2VLAN (only T-PEs). > >In general, I still prefer multi-PW, primarily because I prefer the >separation of the traffic in the network's forwarding plane, rather than >shipping it everywhere and deciding whether to forward to the AC when it >gets to the egress PE. I'm having a hard time putting my finger exactly >on what it is, or articulating the idea, but it seems that by having the >traffic placed into two psuedowires, I have more flexibility and ease of >configuration when it comes to E-NNI's, service multiplexed UNI's, and >H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >configuration' statement assumes BGP-VPLS, as was pointed out earlier >LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >PW's could really change that perception. >[JY] Are you saying that we need to develop a totally new forwarding >plane rather than using the Ethernet forwarding plane as described in the >existing work? > >I hope we can move forward with one of these soon, >[JY] me too. > >Josh > > >On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: > >>Daniel, >> >>Not aware that we had a discussion on this before, but IMHO the >>allocation of internal S-VLAN can be automatic, and manuel configuration >>of this mapping may not be needed at all. For example, an S-VLAN >>allocation module in the management plane in a PE can do this kind of >>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>way from a free S-VLAN ID pool. Once the interal S-VLANs are allocated, >>the mapping is determined and no other configuration is needed. >> >>The only difference from RFC 6246 is, for E-LAN, we only need to allocate >>a single S-VLAN in the VPLS domain, but for E-Tree, we need to allocate >>two S-VLANs in the VPLS domain. >> >>On the other hand, for the multi-PW approach, two PWs need to be >>configured for a E-Tree service. When MS-PW is used in the network, for >>every S-PE, we need to configure two ingress PW segments and two egress >>PW segments. In this case, I don't think we need to use fixed PW labels >>across the network for fear of configuration complexity. >> >>Regards, >>Yuanlong >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Wednesday, May 02, 2012 8:01 PM >>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>josh.rogers@twcable.com >>Cc: l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Inline. >> >>-----Original Message----- >>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>Sent: Wednesday, May 02, 2012 12:30 PM >>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>josh.rogers@twcable.com >>Cc: l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi Daniel, Please see my comments in line. >> >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Wednesday, May 02, 2012 3:55 PM >>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>yong; josh.rogers@twcable.com >>Cc: l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi Yuanlong, >> >>The problem is not with the total number of S-VLAN IDs, I agree that >>normally there won't be more than 2047. The problem is that if you don't >>support all VLAN IDs, you need S-VLAN space coordination with the >>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to 2047". >>Which won't always be in line with an existing deployment. >>[JY] This is not the case. If the total number is no more than 2047, it >>surely can be supported. The S-VLAN space of user domain is totally >>different from the S-VLAN in the provider domain and they can be >>overlapped, I don't see why we need S-VLAN space coordination between >>them. >> >>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>fixed, and therefore the IEEE S-VID that can be supported is also fixed. >> >>Of course you can configure the mapping in each PE according to operator >>requirements but as we discussed before this increases complexity. >> >>Relying on PBB-VPLS imposes additional limitations on backward >>compatibility. >>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>think they may well need MAC-in-MAC in their networks for the >>scalability issue. As you know, only PBB VPLS can provide both. >> >>Daniel >> >>-----Original Message----- >>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>Sent: Wednesday, May 02, 2012 5:07 AM >>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>josh.rogers@twcable.com >>Cc: l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi Daniel, >> >>As you can see, both cases are discussed in the I-D. >> >>With regard to case 1) (that is, S-VLAN translation), since the access >>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>they need to be configured on a PE anyway, and as the past emails by >>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>mapping. >> >>With regard to S-VID space reduction, the constraint is valid only when >>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>typical and with no such limits as we already discussed in the f2f >>meeting. >> >>Even if there are 4094 S-VLANs in a single E-Tree access as you >>described (not sure this is a valid use case in real life), PBB-VPLS can >>still be used. >> >>Regards, >>Yuanlong >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Monday, April 30, 2012 10:34 PM >>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>Jiangyuanlong; josh.rogers@twcable.com >>Cc: l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>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] >>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 >> >>---------------------------------------------------------------------- > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use of the individual or entity to which it is addressed. If you >are not the intended recipient of this E-mail, you are hereby notified >that any dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this 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 aldrin.isaac@gmail.com Thu May 3 20:50: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 90B6621F856C for ; Thu, 3 May 2012 20:50:22 -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 EJNZhJsCLDeT for ; Thu, 3 May 2012 20:50:21 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id C9F5921F8566 for ; Thu, 3 May 2012 20:50:21 -0700 (PDT) Received: by qcsq13 with SMTP id q13so1927936qcs.31 for ; Thu, 03 May 2012 20:50:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=8JmJocsCvEYRnYGGHjirESCn3rvjwnSw+nXUOxAGwVs=; b=fLxoeGtxirdaw75WPusbASp/zdeXbffpehab/5liJjjwAkEc8LJ9qOvu/HLSYJdoHs WS+xCpSXjz++1IEUzTdyy2Ne24jO+25/0nvYspM6mUoAlnRwOLGsJNfbLMHLPJ/mu/9g s2DJYj64lWEDto8zSkvg1ZUqk00cQwWLEPdFFXbiKAmu0BxaStI5E3K6qLSur+ros+GB uC9n2MF9IOSGwq1m2WFhZAG2+pwDBRcexUX0Sx3nK5A/v8KdqwB6BXE8phHjyDAW8veq X3cipaiCCH1VrZf1qcklQJtkBaCGKQ9eFRLWvXNAfjCuywGoUCaoH4ZuHKlRC486isfH 9ksQ== Received: by 10.224.217.138 with SMTP id hm10mr7658008qab.76.1336103421326; Thu, 03 May 2012 20:50:21 -0700 (PDT) Received: from mymac.home (ool-435396f4.dyn.optonline.net. [67.83.150.244]) by mx.google.com with ESMTPS id gy2sm12795052qab.10.2012.05.03.20.50.19 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 May 2012 20:50:20 -0700 (PDT) Subject: Re: Interest in IS-IS VPLS Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Aldrin Isaac In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D330E8F11@dfweml505-mbx> Date: Thu, 3 May 2012 23:50:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2E819CEF-4A49-439B-86DF-C17503A75398@gmail.com> References: <2691CE0099834E4A9C5044EEC662BB9D330E8F11@dfweml505-mbx> To: Lucy yong X-Mailer: Apple Mail (2.1257) Cc: "l2vpn@ietf.org" , sajassi 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, 04 May 2012 03:50:22 -0000 I'm not trying to sell E-VPN here, but I'd like to point out that = multi-homing isn't the only reason why E-VPN came about. It's just the = one that satisfies the L2VPN charter. E-VPN also supports policy based-topologies versus simple = point-to-point, flat or tree VLANs. It can support point-to-point, = tree, mesh, one-way, or pretty much any other "complex" or overlapped = topologies (depending on how you like to see it). An example is ability = to natively recreate private vlan, community vlan topologies (which = happen to be quite common in DC networks) and any number of combinations = of these simultaneously to a single port. A BGP E-VPN VPN is also = decoupled from the edge EVI/ESI such that it is not limited to a single = tenant/vlan but can span tenants/vlans (l2 extranet) if so required. = This is native to E-VPN. E-VPN supports interconnecting end-stations or interconnecting L2 = networks. Procedures to easily span STP based networks across an E-VPN = network without loops comes with the base spec. Extensions to E-VPN, = such as PBB-EVPN, simplify the fully functional spanning of non-EVPN = networks across an E-VPN network. An SVI/IRB interface can also be a member of both an E-VPN EVI and an IP = VRF allowing for easily bringing together virtual L2 and L3 topologies = anywhere in the network without a physical port. E-VPN builds on top of years of work in the IETF; traffic engineering, = scaling with route reflectors and RT constrain, multicast via NG-MVPN, = etc. Can also use IP for transport tunnel. But my understanding is that = popular merchant silicon has support for MPLS push/pop/swap these days = (?). This was captured by EVPN at it's inception, which is why the PE = is referred to as MES (MPLS-enabled switch) in E-VPN. The way I see it, a major reason why STP-based LANS are fickle and don't = scale well is on account of insufficient decoupling of core from edge = created by requirement for plug-and-play and how that played out over = time. Conversely the reason (among other things) why IP networks are = more stable is because they are not inherently plug-and-play, and with = MPLS/BGP allows excellent decoupling of core and edge. I don't know = enough about TRILL or PBB to comment on those -- I just know that I'm = not interested for enough good reasons. E-VPN enables a dynamic edge = over a stable decoupled core while giving each operator room for service = differentiation. It is especially interesting to operators that have = invested in MPLS technology and operations. I can find a lot of folks = that understand BGP/MPLS IPVPN and in short order have them know the ins = and outs of basic E-VPN. It's quite hard for me to find non-vendor folk = who really actually understand the other technologies used to span = Ethernet aside from basic STP.=20 This is an operator perspective. On May 3, 2012, at 4:31 PM, Lucy yong wrote: > Hi Ali, >=20 >=20 > "5. Ethernet VPN (E-VPN) - An enhanced Layer-2 service that > emulates an Ethernet (V)LAN across a PSN. E-VPN supports > load-sharing across multiple connections from a Layer-2 site > to an L2VPN service. E-VPN is primarily targeted to support > large-scale L2VPNs with resiliency requirements not satisfied > by other L2VPN solutions" >=20 > [[LY]] IMO, E-VPN enhancement is to support multi-homing with = active-active mode. Load-sharing across multiple connections from a = layer-2 site is desired when this mode is used. Current VPLS can provide = resiliency requirement when the multi-homing site configured with = active-standby mode. >=20 > Regards, > Lucy >=20 > Cheers, > Ali =20 >=20 From josh.rogers@twcable.com Fri May 4 05:26: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 B5D7921F8629 for ; Fri, 4 May 2012 05:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.082 X-Spam-Level: X-Spam-Status: No, score=0.082 tagged_above=-999 required=5 tests=[AWL=-0.055, 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 Q87fuyg2vlhx for ; Fri, 4 May 2012 05:26:40 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id CFE6D21F85FB for ; Fri, 4 May 2012 05:26:39 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.75,530,1330923600"; d="scan'208";a="359939486" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 04 May 2012 08:25:31 -0400 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.36]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Fri, 4 May 2012 08:26:37 -0400 From: "Rogers, Josh" To: Jiangyuanlong , Daniel Cohn , "Fedyk, Donald (Don)" , "Henderickx, Wim (Wim)" , Lucy yong Date: Fri, 4 May 2012 08:26:37 -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: Ac0p8SZudXdUVFYtR0yVQC30XAUvyg== Message-ID: In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA560F0@SZXEML508-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" 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: Fri, 04 May 2012 12:26:41 -0000 [JY2] if the egress PE is attached with pure leafs, 2VLAN approach can also separate the leaf traffic in the ingress PE and filter it there (already detailed in the Optimization Mode in the I-D); if the egress PE is attached with pure roots or with both roots and leafs, it seems all traffic must be transported to the egress PE and be filtered there, I see no difference in behaviour for these solutions. Or did I miss something? The point is with the multi-PW method the traffic is split/separated (by psuedowire) on the ingress PE, rather than the egress. The distinction is 2VLAN will 'classify' the frame on the ingress PE, so that the egress PE knows how to forward it to the appropriate AC's. Both methods have inefficiencies (one duplicates traffic for transport, while the other transports where it doesn't need to go). I like the idea of classify and forwarding on the ingress PE, rather than marking it on the ingress, and deciding on the egress. -Josh On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: >Josh, thank you for the comments, please see my further comments with >[JY2]. > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Thursday, May 03, 2012 11:27 PM >To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >(Wim); Lucy yong >Cc: l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >requirements from MEF, it has nothing to do with the solutions. Could you >give a hint on how you can provision this service E-NNI otherwise? BTW, if >configuring or signalling two PWs is not a problem, why configuring or >signalling two VLANs will become a problem? After all, more nodes may need >to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >2VLAN (only T-PEs). > > >There is no other way (if both MPLS domains are part of the same ETREE, >rather than doing something more like H-VPLS, where one domain has point >to points to the other domain which handles the ETREE instance) if you are >using an ENNI. The other method, (not mentioned earlier) is tying the two >MPLS domains together via labeled unicast (much preferred over E-NNI in my >opinion) > >Configuring two VLAN's isn't really a 'problem' any more than two PW's. I >wasn't saying that configuring two VLAN's was difficult, I was objecting >to the statement that configuring two PW's is difficult. > >[JY2] Thanks, I see your point. I take the example of 2PW configuration >just to show that using fixed global values to simplify configuration >makes no sense. Personally I also don't think configuration is a problem >for both solutions. > >I find the differences between these two methods rather slight. The >'tie-breaker' for me is by placing the forwarding decision on the ingress >PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >more control over where the traffic goes, and in my mind it provides a >cleaner destination between customer traffic and forwarding plane. I'm >accustomed to looking at a psuedowire and knowing where its going, with >the 2vlan method, I can see the psuedowire, but must go to the egress PE >to see if it will be dropped there, or forwarded to one or more AC's. > >[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >also separate the leaf traffic in the ingress PE and filter it there >(already detailed in the Optimization Mode in the I-D); if the egress PE >is attached with pure roots or with both roots and leafs, it seems all >traffic must be transported to the egress PE and be filtered there, I see >no difference in behaviour for these solutions. Or did I miss something? > >Again, the difference here is slight, and I would honestly be happy to see >either of them come to fruition. Please don't infer that I think the >2vlan method is 'bad' or has intrinsic problems, because I don't believe >that. I just prefer the multi-PW method. > > >-Josh > > >On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: > >>Josh, please see my comments in line. >> >>Thanks >>Yuanlong >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Thursday, May 03, 2012 10:51 AM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>Yuanlong, >> >>Or better yet, include in the draft a 'standard' value for root sourced >>VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You would als= o >>have to require the the implementation NOT use global VLAN's, however >>(since each instance would be using the same values). In this way, no >>signaling or manual configuration is required for remote PE's to know how >>to classify traffic. >>[JY] Indeed, we discussed this possibility during the f2f meeting in >>Paris. But, there are some restrictions as you mentioned, and >>furthermore: >>1) Some vendors already used S-VLAN to distinguish their VSIs in the PE; >>2) Forwarding plane of a PE needs to be revised to be aware of this VLAN >>ID. >>Therefore, this 'standard value' approach seems more disruptive compared >>with the other means and not a good candidate option. >> >>Regarding switching PE's=A9 Multi-PW means more than one PW, yes. I don= 't >>see this as a real problem. In general, design should try and avoid >>using >>S-PE's, but if you must, its going to mean extra work, no matter how you >>look at it. Two PW's for each Etree being switched instead of one is not >>alarming or concerning to me. On the other hand, if you use a dot1q >>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's an >>two egress VLAN's if you want the Etree to be handled on both sides (and >>if you use the 'standard' VID's as I mentioned above, you'd have to do >>mapping to non-standard and back) >>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>requirements from MEF, it has nothing to do with the solutions. Could you >>give a hint on how you can provision this service E-NNI otherwise? BTW, >>if configuring or signalling two PWs is not a problem, why configuring or >>signalling two VLANs will become a problem? After all, more nodes may >>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>with 2VLAN (only T-PEs). >> >>In general, I still prefer multi-PW, primarily because I prefer the >>separation of the traffic in the network's forwarding plane, rather than >>shipping it everywhere and deciding whether to forward to the AC when it >>gets to the egress PE. I'm having a hard time putting my finger exactly >>on what it is, or articulating the idea, but it seems that by having the >>traffic placed into two psuedowires, I have more flexibility and ease of >>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>PW's could really change that perception. >>[JY] Are you saying that we need to develop a totally new forwarding >>plane rather than using the Ethernet forwarding plane as described in the >>existing work? >> >>I hope we can move forward with one of these soon, >>[JY] me too. >> >>Josh >> >> >>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >> >>>Daniel, >>> >>>Not aware that we had a discussion on this before, but IMHO the >>>allocation of internal S-VLAN can be automatic, and manuel configuration >>>of this mapping may not be needed at all. For example, an S-VLAN >>>allocation module in the management plane in a PE can do this kind of >>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>way from a free S-VLAN ID pool. Once the interal S-VLANs are allocated, >>>the mapping is determined and no other configuration is needed. >>> >>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>allocate >>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to allocate >>>two S-VLANs in the VPLS domain. >>> >>>On the other hand, for the multi-PW approach, two PWs need to be >>>configured for a E-Tree service. When MS-PW is used in the network, for >>>every S-PE, we need to configure two ingress PW segments and two egress >>>PW segments. In this case, I don't think we need to use fixed PW labels >>>across the network for fear of configuration complexity. >>> >>>Regards, >>>Yuanlong >>> >>>-----Original Message----- >>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>Sent: Wednesday, May 02, 2012 8:01 PM >>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>yong; >>>josh.rogers@twcable.com >>>Cc: l2vpn@ietf.org >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Inline. >>> >>>-----Original Message----- >>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>Sent: Wednesday, May 02, 2012 12:30 PM >>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>josh.rogers@twcable.com >>>Cc: l2vpn@ietf.org >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Hi Daniel, Please see my comments in line. >>> >>> >>>-----Original Message----- >>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>Sent: Wednesday, May 02, 2012 3:55 PM >>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>yong; josh.rogers@twcable.com >>>Cc: l2vpn@ietf.org >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Hi Yuanlong, >>> >>>The problem is not with the total number of S-VLAN IDs, I agree that >>>normally there won't be more than 2047. The problem is that if you don't >>>support all VLAN IDs, you need S-VLAN space coordination with the >>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to 2047". >>>Which won't always be in line with an existing deployment. >>>[JY] This is not the case. If the total number is no more than 2047, it >>>surely can be supported. The S-VLAN space of user domain is totally >>>different from the S-VLAN in the provider domain and they can be >>>overlapped, I don't see why we need S-VLAN space coordination between >>>them. >>> >>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>fixed, and therefore the IEEE S-VID that can be supported is also fixed. >>> >>>Of course you can configure the mapping in each PE according to operator >>>requirements but as we discussed before this increases complexity. >>> >>>Relying on PBB-VPLS imposes additional limitations on backward >>>compatibility. >>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>think they may well need MAC-in-MAC in their networks for the >>>scalability issue. As you know, only PBB VPLS can provide both. >>> >>>Daniel >>> >>>-----Original Message----- >>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>Sent: Wednesday, May 02, 2012 5:07 AM >>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>josh.rogers@twcable.com >>>Cc: l2vpn@ietf.org >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Hi Daniel, >>> >>>As you can see, both cases are discussed in the I-D. >>> >>>With regard to case 1) (that is, S-VLAN translation), since the access >>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>they need to be configured on a PE anyway, and as the past emails by >>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>mapping. >>> >>>With regard to S-VID space reduction, the constraint is valid only when >>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>typical and with no such limits as we already discussed in the f2f >>>meeting. >>> >>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>described (not sure this is a valid use case in real life), PBB-VPLS can >>>still be used. >>> >>>Regards, >>>Yuanlong >>> >>>-----Original Message----- >>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>Sent: Monday, April 30, 2012 10:34 PM >>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>Jiangyuanlong; josh.rogers@twcable.com >>>Cc: l2vpn@ietf.org >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>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] >>>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 >>> >>>---------------------------------------------------------------------- >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject to >>copyright belonging to Time Warner Cable. This E-mail is intended solely >>for the use of the individual or entity to which it is addressed. If you >>are not the intended recipient of this E-mail, you are hereby notified >>that any dissemination, distribution, copying, or action taken in >>relation to the contents of and attachments to this E-mail is strictly >>prohibited and may be unlawful. If you have received this 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 lucy.yong@huawei.com Fri May 4 07:18: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 EA18A21F86D3 for ; Fri, 4 May 2012 07:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.279 X-Spam-Level: X-Spam-Status: No, score=-2.279 tagged_above=-999 required=5 tests=[AWL=-0.280, 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 r5Ay4Eqwg8dw for ; Fri, 4 May 2012 07:18:43 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1A43D21F86D5 for ; Fri, 4 May 2012 07:18:43 -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 AFN17392; Fri, 04 May 2012 10:18:42 -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, 4 May 2012 07:16:37 -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; Fri, 4 May 2012 07:16:37 -0700 From: Lucy yong To: "Rogers, Josh" , Jiangyuanlong , Daniel Cohn , "Fedyk, Donald (Don)" , "Henderickx, Wim (Wim)" 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/4Txq0Y50G6N17p5Mncd5asuNMAgAYGiYCAAAzygIAAAjQAgAAAAYCAAASFAIAAAOoAgAAYGACAAAPTgIACzjKAgABsbmCAABSDMIAAJEvQgADhaeD//53EgIAAk10ggAE7MQCAAKXoAIAAuhCA//+oHEA= Date: Fri, 4 May 2012 14:16:36 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D330E9114@dfweml505-mbx> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA560F0@SZXEML508-MBX.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.150.230] Content-Type: text/plain; charset="iso-8859-2" 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: Fri, 04 May 2012 14:18:45 -0000 Josh, You simply say that you don't like IEEE Tree solution. IEEE Tree solution i= s for ingress port to mark and for egress port to filter. Regards, Lucy -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com]=20 Sent: Friday, May 04, 2012 7:27 AM To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim);= Lucy yong Cc: l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? [JY2] if the egress PE is attached with pure leafs, 2VLAN approach can also separate the leaf traffic in the ingress PE and filter it there (already detailed in the Optimization Mode in the I-D); if the egress PE is attached with pure roots or with both roots and leafs, it seems all traffic must be transported to the egress PE and be filtered there, I see no difference in behaviour for these solutions. Or did I miss something? The point is with the multi-PW method the traffic is split/separated (by psuedowire) on the ingress PE, rather than the egress. The distinction is 2VLAN will 'classify' the frame on the ingress PE, so that the egress PE knows how to forward it to the appropriate AC's. Both methods have inefficiencies (one duplicates traffic for transport, while the other transports where it doesn't need to go). I like the idea of classify and forwarding on the ingress PE, rather than marking it on the ingress, and deciding on the egress. -Josh On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: >Josh, thank you for the comments, please see my further comments with >[JY2]. > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Thursday, May 03, 2012 11:27 PM >To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >(Wim); Lucy yong >Cc: l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >requirements from MEF, it has nothing to do with the solutions. Could you >give a hint on how you can provision this service E-NNI otherwise? BTW, if >configuring or signalling two PWs is not a problem, why configuring or >signalling two VLANs will become a problem? After all, more nodes may need >to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >2VLAN (only T-PEs). > > >There is no other way (if both MPLS domains are part of the same ETREE, >rather than doing something more like H-VPLS, where one domain has point >to points to the other domain which handles the ETREE instance) if you are >using an ENNI. The other method, (not mentioned earlier) is tying the two >MPLS domains together via labeled unicast (much preferred over E-NNI in my >opinion) > >Configuring two VLAN's isn't really a 'problem' any more than two PW's. I >wasn't saying that configuring two VLAN's was difficult, I was objecting >to the statement that configuring two PW's is difficult. > >[JY2] Thanks, I see your point. I take the example of 2PW configuration >just to show that using fixed global values to simplify configuration >makes no sense. Personally I also don't think configuration is a problem >for both solutions. > >I find the differences between these two methods rather slight. The >'tie-breaker' for me is by placing the forwarding decision on the ingress >PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >more control over where the traffic goes, and in my mind it provides a >cleaner destination between customer traffic and forwarding plane. I'm >accustomed to looking at a psuedowire and knowing where its going, with >the 2vlan method, I can see the psuedowire, but must go to the egress PE >to see if it will be dropped there, or forwarded to one or more AC's. > >[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >also separate the leaf traffic in the ingress PE and filter it there >(already detailed in the Optimization Mode in the I-D); if the egress PE >is attached with pure roots or with both roots and leafs, it seems all >traffic must be transported to the egress PE and be filtered there, I see >no difference in behaviour for these solutions. Or did I miss something? > >Again, the difference here is slight, and I would honestly be happy to see >either of them come to fruition. Please don't infer that I think the >2vlan method is 'bad' or has intrinsic problems, because I don't believe >that. I just prefer the multi-PW method. > > >-Josh > > >On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: > >>Josh, please see my comments in line. >> >>Thanks >>Yuanlong >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Thursday, May 03, 2012 10:51 AM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>Yuanlong, >> >>Or better yet, include in the draft a 'standard' value for root sourced >>VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You would als= o >>have to require the the implementation NOT use global VLAN's, however >>(since each instance would be using the same values). In this way, no >>signaling or manual configuration is required for remote PE's to know how >>to classify traffic. >>[JY] Indeed, we discussed this possibility during the f2f meeting in >>Paris. But, there are some restrictions as you mentioned, and >>furthermore: >>1) Some vendors already used S-VLAN to distinguish their VSIs in the PE; >>2) Forwarding plane of a PE needs to be revised to be aware of this VLAN >>ID. >>Therefore, this 'standard value' approach seems more disruptive compared >>with the other means and not a good candidate option. >> >>Regarding switching PE's=A9 Multi-PW means more than one PW, yes. I don= 't >>see this as a real problem. In general, design should try and avoid >>using >>S-PE's, but if you must, its going to mean extra work, no matter how you >>look at it. Two PW's for each Etree being switched instead of one is not >>alarming or concerning to me. On the other hand, if you use a dot1q >>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's an >>two egress VLAN's if you want the Etree to be handled on both sides (and >>if you use the 'standard' VID's as I mentioned above, you'd have to do >>mapping to non-standard and back) >>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>requirements from MEF, it has nothing to do with the solutions. Could you >>give a hint on how you can provision this service E-NNI otherwise? BTW, >>if configuring or signalling two PWs is not a problem, why configuring or >>signalling two VLANs will become a problem? After all, more nodes may >>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>with 2VLAN (only T-PEs). >> >>In general, I still prefer multi-PW, primarily because I prefer the >>separation of the traffic in the network's forwarding plane, rather than >>shipping it everywhere and deciding whether to forward to the AC when it >>gets to the egress PE. I'm having a hard time putting my finger exactly >>on what it is, or articulating the idea, but it seems that by having the >>traffic placed into two psuedowires, I have more flexibility and ease of >>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>PW's could really change that perception. >>[JY] Are you saying that we need to develop a totally new forwarding >>plane rather than using the Ethernet forwarding plane as described in the >>existing work? >> >>I hope we can move forward with one of these soon, >>[JY] me too. >> >>Josh >> >> >>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >> >>>Daniel, >>> >>>Not aware that we had a discussion on this before, but IMHO the >>>allocation of internal S-VLAN can be automatic, and manuel configuration >>>of this mapping may not be needed at all. For example, an S-VLAN >>>allocation module in the management plane in a PE can do this kind of >>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>way from a free S-VLAN ID pool. Once the interal S-VLANs are allocated, >>>the mapping is determined and no other configuration is needed. >>> >>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>allocate >>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to allocate >>>two S-VLANs in the VPLS domain. >>> >>>On the other hand, for the multi-PW approach, two PWs need to be >>>configured for a E-Tree service. When MS-PW is used in the network, for >>>every S-PE, we need to configure two ingress PW segments and two egress >>>PW segments. In this case, I don't think we need to use fixed PW labels >>>across the network for fear of configuration complexity. >>> >>>Regards, >>>Yuanlong >>> >>>-----Original Message----- >>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>Sent: Wednesday, May 02, 2012 8:01 PM >>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>yong; >>>josh.rogers@twcable.com >>>Cc: l2vpn@ietf.org >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Inline. >>> >>>-----Original Message----- >>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>Sent: Wednesday, May 02, 2012 12:30 PM >>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>josh.rogers@twcable.com >>>Cc: l2vpn@ietf.org >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Hi Daniel, Please see my comments in line. >>> >>> >>>-----Original Message----- >>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>Sent: Wednesday, May 02, 2012 3:55 PM >>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>yong; josh.rogers@twcable.com >>>Cc: l2vpn@ietf.org >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Hi Yuanlong, >>> >>>The problem is not with the total number of S-VLAN IDs, I agree that >>>normally there won't be more than 2047. The problem is that if you don't >>>support all VLAN IDs, you need S-VLAN space coordination with the >>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to 2047". >>>Which won't always be in line with an existing deployment. >>>[JY] This is not the case. If the total number is no more than 2047, it >>>surely can be supported. The S-VLAN space of user domain is totally >>>different from the S-VLAN in the provider domain and they can be >>>overlapped, I don't see why we need S-VLAN space coordination between >>>them. >>> >>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>fixed, and therefore the IEEE S-VID that can be supported is also fixed. >>> >>>Of course you can configure the mapping in each PE according to operator >>>requirements but as we discussed before this increases complexity. >>> >>>Relying on PBB-VPLS imposes additional limitations on backward >>>compatibility. >>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>think they may well need MAC-in-MAC in their networks for the >>>scalability issue. As you know, only PBB VPLS can provide both. >>> >>>Daniel >>> >>>-----Original Message----- >>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>Sent: Wednesday, May 02, 2012 5:07 AM >>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>josh.rogers@twcable.com >>>Cc: l2vpn@ietf.org >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Hi Daniel, >>> >>>As you can see, both cases are discussed in the I-D. >>> >>>With regard to case 1) (that is, S-VLAN translation), since the access >>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>they need to be configured on a PE anyway, and as the past emails by >>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>mapping. >>> >>>With regard to S-VID space reduction, the constraint is valid only when >>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>typical and with no such limits as we already discussed in the f2f >>>meeting. >>> >>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>described (not sure this is a valid use case in real life), PBB-VPLS can >>>still be used. >>> >>>Regards, >>>Yuanlong >>> >>>-----Original Message----- >>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>Sent: Monday, April 30, 2012 10:34 PM >>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>Jiangyuanlong; josh.rogers@twcable.com >>>Cc: l2vpn@ietf.org >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>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] >>>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 >>> >>>---------------------------------------------------------------------- >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject to >>copyright belonging to Time Warner Cable. This E-mail is intended solely >>for the use of the individual or entity to which it is addressed. If you >>are not the intended recipient of this E-mail, you are hereby notified >>that any dissemination, distribution, copying, or action taken in >>relation to the contents of and attachments to this E-mail is strictly >>prohibited and may be unlawful. If you have received this 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 josh.rogers@twcable.com Fri May 4 07: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 BAB8221F860B for ; Fri, 4 May 2012 07:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.415 X-Spam-Level: X-Spam-Status: No, score=-0.415 tagged_above=-999 required=5 tests=[AWL=0.448, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 5-WLlFOg1Qup for ; Fri, 4 May 2012 07:31:16 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 2910D21F859A for ; Fri, 4 May 2012 07:31:14 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.75,530,1330923600"; d="scan'208";a="376639702" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 04 May 2012 10:30:13 -0400 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.36]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Fri, 4 May 2012 10:30:38 -0400 From: "Rogers, Josh" To: Lucy yong , Jiangyuanlong , Daniel Cohn , "Fedyk, Donald (Don)" , "Henderickx, Wim (Wim)" Date: Fri, 4 May 2012 10:30:38 -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: Ac0qAnmRBhsjEiYaQwOTqv8PpH42Gw== Message-ID: In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D330E9114@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 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, 04 May 2012 14:31:17 -0000 To be more accurate, I like it less than the multi-PW solution. I'd be happy to use the 2VLAN solution in the real world, if it was ratified as the standard. On 5/4/12 9:16 AM, "Lucy yong" wrote: >Josh, > >You simply say that you don't like IEEE Tree solution. IEEE Tree solution >is for ingress port to mark and for egress port to filter. > >Regards, >Lucy > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Friday, May 04, 2012 7:27 AM >To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >(Wim); Lucy yong >Cc: l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >also separate the leaf traffic in the ingress PE and filter it there >(already detailed in the Optimization Mode in the I-D); if the egress PE >is attached with pure roots or with both roots and leafs, it seems all >traffic must be transported to the egress PE and be filtered there, I see >no difference in behaviour for these solutions. Or did I miss something? > > >The point is with the multi-PW method the traffic is split/separated (by >psuedowire) on the ingress PE, rather than the egress. The distinction is >2VLAN will 'classify' the frame on the ingress PE, so that the egress PE >knows how to forward it to the appropriate AC's. > >Both methods have inefficiencies (one duplicates traffic for transport, >while the other transports where it doesn't need to go). I like the idea >of classify and forwarding on the ingress PE, rather than marking it on >the ingress, and deciding on the egress. > >-Josh > > > >On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: > >>Josh, thank you for the comments, please see my further comments with >>[JY2]. >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Thursday, May 03, 2012 11:27 PM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>requirements from MEF, it has nothing to do with the solutions. Could you >>give a hint on how you can provision this service E-NNI otherwise? BTW, >>if >>configuring or signalling two PWs is not a problem, why configuring or >>signalling two VLANs will become a problem? After all, more nodes may >>need >>to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >>2VLAN (only T-PEs). >> >> >>There is no other way (if both MPLS domains are part of the same ETREE, >>rather than doing something more like H-VPLS, where one domain has point >>to points to the other domain which handles the ETREE instance) if you >>are >>using an ENNI. The other method, (not mentioned earlier) is tying the >>two >>MPLS domains together via labeled unicast (much preferred over E-NNI in >>my >>opinion) >> >>Configuring two VLAN's isn't really a 'problem' any more than two PW's. >>I >>wasn't saying that configuring two VLAN's was difficult, I was objecting >>to the statement that configuring two PW's is difficult. >> >>[JY2] Thanks, I see your point. I take the example of 2PW configuration >>just to show that using fixed global values to simplify configuration >>makes no sense. Personally I also don't think configuration is a problem >>for both solutions. >> >>I find the differences between these two methods rather slight. The >>'tie-breaker' for me is by placing the forwarding decision on the ingress >>PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >>more control over where the traffic goes, and in my mind it provides a >>cleaner destination between customer traffic and forwarding plane. I'm >>accustomed to looking at a psuedowire and knowing where its going, with >>the 2vlan method, I can see the psuedowire, but must go to the egress PE >>to see if it will be dropped there, or forwarded to one or more AC's. >> >>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>also separate the leaf traffic in the ingress PE and filter it there >>(already detailed in the Optimization Mode in the I-D); if the egress PE >>is attached with pure roots or with both roots and leafs, it seems all >>traffic must be transported to the egress PE and be filtered there, I see >>no difference in behaviour for these solutions. Or did I miss something? >> >>Again, the difference here is slight, and I would honestly be happy to >>see >>either of them come to fruition. Please don't infer that I think the >>2vlan method is 'bad' or has intrinsic problems, because I don't believe >>that. I just prefer the multi-PW method. >> >> >>-Josh >> >> >>On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: >> >>>Josh, please see my comments in line. >>> >>>Thanks >>>Yuanlong >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Thursday, May 03, 2012 10:51 AM >>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>(Wim); Lucy yong >>>Cc: l2vpn@ietf.org >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Yuanlong, >>> >>>Or better yet, include in the draft a 'standard' value for root sourced >>>VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You would al= so >>>have to require the the implementation NOT use global VLAN's, however >>>(since each instance would be using the same values). In this way, no >>>signaling or manual configuration is required for remote PE's to know >>>how >>>to classify traffic. >>>[JY] Indeed, we discussed this possibility during the f2f meeting in >>>Paris. But, there are some restrictions as you mentioned, and >>>furthermore: >>>1) Some vendors already used S-VLAN to distinguish their VSIs in the PE; >>>2) Forwarding plane of a PE needs to be revised to be aware of this VLAN >>>ID. >>>Therefore, this 'standard value' approach seems more disruptive compared >>>with the other means and not a good candidate option. >>> >>>Regarding switching PE's=A9 Multi-PW means more than one PW, yes. I >>>don't >>>see this as a real problem. In general, design should try and avoid >>>using >>>S-PE's, but if you must, its going to mean extra work, no matter how you >>>look at it. Two PW's for each Etree being switched instead of one is >>>not >>>alarming or concerning to me. On the other hand, if you use a dot1q >>>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's >>>an >>>two egress VLAN's if you want the Etree to be handled on both sides (and >>>if you use the 'standard' VID's as I mentioned above, you'd have to do >>>mapping to non-standard and back) >>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>requirements from MEF, it has nothing to do with the solutions. Could >>>you >>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>if configuring or signalling two PWs is not a problem, why configuring >>>or >>>signalling two VLANs will become a problem? After all, more nodes may >>>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>>with 2VLAN (only T-PEs). >>> >>>In general, I still prefer multi-PW, primarily because I prefer the >>>separation of the traffic in the network's forwarding plane, rather than >>>shipping it everywhere and deciding whether to forward to the AC when it >>>gets to the egress PE. I'm having a hard time putting my finger exactly >>>on what it is, or articulating the idea, but it seems that by having the >>>traffic placed into two psuedowires, I have more flexibility and ease of >>>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>>PW's could really change that perception. >>>[JY] Are you saying that we need to develop a totally new forwarding >>>plane rather than using the Ethernet forwarding plane as described in >>>the >>>existing work? >>> >>>I hope we can move forward with one of these soon, >>>[JY] me too. >>> >>>Josh >>> >>> >>>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >>> >>>>Daniel, >>>> >>>>Not aware that we had a discussion on this before, but IMHO the >>>>allocation of internal S-VLAN can be automatic, and manuel >>>>configuration >>>>of this mapping may not be needed at all. For example, an S-VLAN >>>>allocation module in the management plane in a PE can do this kind of >>>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>>way from a free S-VLAN ID pool. Once the interal S-VLANs are allocated, >>>>the mapping is determined and no other configuration is needed. >>>> >>>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>>allocate >>>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to allocate >>>>two S-VLANs in the VPLS domain. >>>> >>>>On the other hand, for the multi-PW approach, two PWs need to be >>>>configured for a E-Tree service. When MS-PW is used in the network, for >>>>every S-PE, we need to configure two ingress PW segments and two egress >>>>PW segments. In this case, I don't think we need to use fixed PW labels >>>>across the network for fear of configuration complexity. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 8:01 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Inline. >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 12:30 PM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, Please see my comments in line. >>>> >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 3:55 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Yuanlong, >>>> >>>>The problem is not with the total number of S-VLAN IDs, I agree that >>>>normally there won't be more than 2047. The problem is that if you >>>>don't >>>>support all VLAN IDs, you need S-VLAN space coordination with the >>>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to >>>>2047". >>>>Which won't always be in line with an existing deployment. >>>>[JY] This is not the case. If the total number is no more than 2047, it >>>>surely can be supported. The S-VLAN space of user domain is totally >>>>different from the S-VLAN in the provider domain and they can be >>>>overlapped, I don't see why we need S-VLAN space coordination between >>>>them. >>>> >>>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>>fixed, and therefore the IEEE S-VID that can be supported is also >>>>fixed. >>>> >>>>Of course you can configure the mapping in each PE according to >>>>operator >>>>requirements but as we discussed before this increases complexity. >>>> >>>>Relying on PBB-VPLS imposes additional limitations on backward >>>>compatibility. >>>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>>think they may well need MAC-in-MAC in their networks for the >>>>scalability issue. As you know, only PBB VPLS can provide both. >>>> >>>>Daniel >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 5:07 AM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, >>>> >>>>As you can see, both cases are discussed in the I-D. >>>> >>>>With regard to case 1) (that is, S-VLAN translation), since the access >>>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>>they need to be configured on a PE anyway, and as the past emails by >>>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>>mapping. >>>> >>>>With regard to S-VID space reduction, the constraint is valid only when >>>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>>typical and with no such limits as we already discussed in the f2f >>>>meeting. >>>> >>>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>>described (not sure this is a valid use case in real life), PBB-VPLS >>>>can >>>>still be used. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Monday, April 30, 2012 10:34 PM >>>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>Jiangyuanlong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>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] >>>>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 >>>> >>>>---------------------------------------------------------------------- >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to >>>copyright belonging to Time Warner Cable. This E-mail is intended solely >>>for the use of the individual or entity to which it is addressed. If you >>>are not the intended recipient of this E-mail, you are hereby notified >>>that any dissemination, distribution, copying, or action taken in >>>relation to the contents of and attachments to this E-mail is strictly >>>prohibited and may be unlawful. If you have received this 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 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 ju1738@att.com Fri May 4 07: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 23AE321F864D for ; Fri, 4 May 2012 07:35:15 -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 ZfVt4p+bVr9r for ; Fri, 4 May 2012 07:35:14 -0700 (PDT) Received: from nbfkord-smmo08.seg.att.com (nbfkord-smmo08.seg.att.com [209.65.160.95]) by ietfa.amsl.com (Postfix) with ESMTP id 112AB21F8779 for ; Fri, 4 May 2012 07:35:11 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo08.seg.att.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.11.0-8) with ESMTP id f19e3af4.2aaab6ee8940.1800031.00-578.4959864.nbfkord-smmo08.seg.att.com (envelope-from ); Fri, 04 May 2012 14:35:11 +0000 (UTC) X-MXL-Hash: 4fa3e91f1e49432b-86b62e9c7a1be7f524e163e9bddacc722e44fe29 Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id f09e3af4.0.1799946.00-290.4959613.nbfkord-smmo08.seg.att.com (envelope-from ); Fri, 04 May 2012 14:34:55 +0000 (UTC) X-MXL-Hash: 4fa3e90f6bff5ba3-c2788a14eb69a3ecb7aeec782ca4a5500d96395c Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q44EYsrO007450; Fri, 4 May 2012 10:34:54 -0400 Received: from sflint04.pst.cso.att.com (sflint04.pst.cso.att.com [144.154.234.231]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q44EYYJN006161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 May 2012 10:34:50 -0400 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (misout7msghub9c.itservices.sbc.com [144.151.223.82]) by sflint04.pst.cso.att.com (RSA Interceptor); Fri, 4 May 2012 10:33:55 -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; Fri, 4 May 2012 10:33:55 -0400 From: "UTTARO, JAMES" To: "'Aldrin Isaac'" , Lucy yong Subject: RE: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0oo3KJO48LuIhSPkS8Et2e3RTHugARqg4SAAf687wAETa4GgAG6vgwABf/yQAADheKoA== Date: Fri, 4 May 2012 14:33:54 +0000 Message-ID: References: <2691CE0099834E4A9C5044EEC662BB9D330E8F11@dfweml505-mbx> <2E819CEF-4A49-439B-86DF-C17503A75398@gmail.com> In-Reply-To: <2E819CEF-4A49-439B-86DF-C17503A75398@gmail.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="us-ascii" Content-Transfer-Encoding: quoted-printable 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.146] X-AnalysisOut: [v=1.0 c=1 a=g8Qva45Ca7EA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHo] X-AnalysisOut: [wA:10 a=kj9zAlcOel0A:10 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a=48] X-AnalysisOut: [vgC7mUAAAA:8 a=TxJGqv__BJyQqbQQsq8A:9 a=WIgZPJe4doa5zvSpDX] X-AnalysisOut: [gA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=pr4DhunS-NCz7aa] X-AnalysisOut: [r:21 a=ZGcQcH3MwKEFth74:21] Cc: "l2vpn@ietf.org" , sajassi 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, 04 May 2012 14:35:15 -0000 +1 Jim Uttaro -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of A= ldrin Isaac Sent: Thursday, May 03, 2012 11:50 PM To: Lucy yong Cc: l2vpn@ietf.org; sajassi Subject: Re: Interest in IS-IS VPLS I'm not trying to sell E-VPN here, but I'd like to point out that multi-hom= ing isn't the only reason why E-VPN came about. It's just the one that sat= isfies the L2VPN charter. E-VPN also supports policy based-topologies versus simple point-to-point, f= lat or tree VLANs. It can support point-to-point, tree, mesh, one-way, or = pretty much any other "complex" or overlapped topologies (depending on how = you like to see it). An example is ability to natively recreate private vl= an, community vlan topologies (which happen to be quite common in DC networ= ks) and any number of combinations of these simultaneously to a single port= . A BGP E-VPN VPN is also decoupled from the edge EVI/ESI such that it is = not limited to a single tenant/vlan but can span tenants/vlans (l2 extranet= ) if so required. This is native to E-VPN. E-VPN supports interconnecting end-stations or interconnecting L2 networks.= Procedures to easily span STP based networks across an E-VPN network with= out loops comes with the base spec. Extensions to E-VPN, such as PBB-EVPN,= simplify the fully functional spanning of non-EVPN networks across an E-VP= N network. An SVI/IRB interface can also be a member of both an E-VPN EVI and an IP VR= F allowing for easily bringing together virtual L2 and L3 topologies anywhe= re in the network without a physical port. E-VPN builds on top of years of work in the IETF; traffic engineering, scal= ing with route reflectors and RT constrain, multicast via NG-MVPN, etc. Can also use IP for transport tunnel. But my understanding is that popular= merchant silicon has support for MPLS push/pop/swap these days (?). This = was captured by EVPN at it's inception, which is why the PE is referred to = as MES (MPLS-enabled switch) in E-VPN. The way I see it, a major reason why STP-based LANS are fickle and don't sc= ale well is on account of insufficient decoupling of core from edge created= by requirement for plug-and-play and how that played out over time. Conve= rsely the reason (among other things) why IP networks are more stable is be= cause they are not inherently plug-and-play, and with MPLS/BGP allows excel= lent decoupling of core and edge. I don't know enough about TRILL or PBB t= o comment on those -- I just know that I'm not interested for enough good r= easons. E-VPN enables a dynamic edge over a stable decoupled core while gi= ving each operator room for service differentiation. It is especially inte= resting to operators that have invested in MPLS technology and operations. = I can find a lot of folks that understand BGP/MPLS IPVPN and in short orde= r have them know the ins and outs of basic E-VPN. It's quite hard for me t= o find non-vendor folk who really actually understand the other technologie= s used to span Ethernet aside from basic STP.=20 This is an operator perspective. On May 3, 2012, at 4:31 PM, Lucy yong wrote: > Hi Ali, >=20 >=20 > "5. Ethernet VPN (E-VPN) - An enhanced Layer-2 service that > emulates an Ethernet (V)LAN across a PSN. E-VPN supports > load-sharing across multiple connections from a Layer-2 site > to an L2VPN service. E-VPN is primarily targeted to support > large-scale L2VPNs with resiliency requirements not satisfied > by other L2VPN solutions" >=20 > [[LY]] IMO, E-VPN enhancement is to support multi-homing with active-acti= ve mode. Load-sharing across multiple connections from a layer-2 site is de= sired when this mode is used. Current VPLS can provide resiliency requireme= nt when the multi-homing site configured with active-standby mode. >=20 > Regards, > Lucy >=20 > Cheers, > Ali =20 >=20 From donald.fedyk@alcatel-lucent.com Fri May 4 07:50: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 ACC4C21F8771 for ; Fri, 4 May 2012 07:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.699 X-Spam-Level: X-Spam-Status: No, score=-8.699 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pII3xuQSotlh for ; Fri, 4 May 2012 07:50:28 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 10C7421F85E3 for ; Fri, 4 May 2012 07:50:27 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q44EnpxD020644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 May 2012 09:49:51 -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 q44Enowh005389 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 4 May 2012 09:49:51 -0500 Received: from USNAVSXCHMBSC2.ndc.alcatel-lucent.com ([135.3.39.145]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Fri, 4 May 2012 09:49:51 -0500 From: "Fedyk, Donald (Don)" To: "Rogers, Josh" , Lucy yong , Jiangyuanlong , Daniel Cohn , "Henderickx, Wim (Wim)" Date: Fri, 4 May 2012 09:49:49 -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: Ac0qAnmRBhsjEiYaQwOTqv8PpH42GwAAH6Qw Message-ID: References: <2691CE0099834E4A9C5044EEC662BB9D330E9114@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-2" Content-Transfer-Encoding: quoted-printable 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.12 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, 04 May 2012 14:50:30 -0000 Hi We might do better to separate marking of the traffic from the transport me= chanism in all cases. In the 2 VLAN model in the IEEE there are multiple i= mplementations that have varying degrees of efficiency as well. Compare for= example shared VLAN learning on STP with QinQ versus PBB using SPB it is a= similar argument Josh is making about efficiency. Don -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com] Sent: Friday, May 04, 2012 10:31 AM To: Lucy yong; Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx,= Wim (Wim) Cc: l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? To be more accurate, I like it less than the multi-PW solution. I'd be happy to use the 2VLAN solution in the real world, if it was ratified as the standard. On 5/4/12 9:16 AM, "Lucy yong" wrote: >Josh, > >You simply say that you don't like IEEE Tree solution. IEEE Tree solution >is for ingress port to mark and for egress port to filter. > >Regards, >Lucy > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Friday, May 04, 2012 7:27 AM >To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >(Wim); Lucy yong >Cc: l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >also separate the leaf traffic in the ingress PE and filter it there >(already detailed in the Optimization Mode in the I-D); if the egress PE >is attached with pure roots or with both roots and leafs, it seems all >traffic must be transported to the egress PE and be filtered there, I see >no difference in behaviour for these solutions. Or did I miss something? > > >The point is with the multi-PW method the traffic is split/separated (by >psuedowire) on the ingress PE, rather than the egress. The distinction is >2VLAN will 'classify' the frame on the ingress PE, so that the egress PE >knows how to forward it to the appropriate AC's. > >Both methods have inefficiencies (one duplicates traffic for transport, >while the other transports where it doesn't need to go). I like the idea >of classify and forwarding on the ingress PE, rather than marking it on >the ingress, and deciding on the egress. > >-Josh > > > >On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: > >>Josh, thank you for the comments, please see my further comments with >>[JY2]. >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Thursday, May 03, 2012 11:27 PM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>requirements from MEF, it has nothing to do with the solutions. Could you >>give a hint on how you can provision this service E-NNI otherwise? BTW, >>if >>configuring or signalling two PWs is not a problem, why configuring or >>signalling two VLANs will become a problem? After all, more nodes may >>need >>to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >>2VLAN (only T-PEs). >> >> >>There is no other way (if both MPLS domains are part of the same ETREE, >>rather than doing something more like H-VPLS, where one domain has point >>to points to the other domain which handles the ETREE instance) if you >>are >>using an ENNI. The other method, (not mentioned earlier) is tying the >>two >>MPLS domains together via labeled unicast (much preferred over E-NNI in >>my >>opinion) >> >>Configuring two VLAN's isn't really a 'problem' any more than two PW's. >>I >>wasn't saying that configuring two VLAN's was difficult, I was objecting >>to the statement that configuring two PW's is difficult. >> >>[JY2] Thanks, I see your point. I take the example of 2PW configuration >>just to show that using fixed global values to simplify configuration >>makes no sense. Personally I also don't think configuration is a problem >>for both solutions. >> >>I find the differences between these two methods rather slight. The >>'tie-breaker' for me is by placing the forwarding decision on the ingress >>PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >>more control over where the traffic goes, and in my mind it provides a >>cleaner destination between customer traffic and forwarding plane. I'm >>accustomed to looking at a psuedowire and knowing where its going, with >>the 2vlan method, I can see the psuedowire, but must go to the egress PE >>to see if it will be dropped there, or forwarded to one or more AC's. >> >>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>also separate the leaf traffic in the ingress PE and filter it there >>(already detailed in the Optimization Mode in the I-D); if the egress PE >>is attached with pure roots or with both roots and leafs, it seems all >>traffic must be transported to the egress PE and be filtered there, I see >>no difference in behaviour for these solutions. Or did I miss something? >> >>Again, the difference here is slight, and I would honestly be happy to >>see >>either of them come to fruition. Please don't infer that I think the >>2vlan method is 'bad' or has intrinsic problems, because I don't believe >>that. I just prefer the multi-PW method. >> >> >>-Josh >> >> >>On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: >> >>>Josh, please see my comments in line. >>> >>>Thanks >>>Yuanlong >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Thursday, May 03, 2012 10:51 AM >>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>(Wim); Lucy yong >>>Cc: l2vpn@ietf.org >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Yuanlong, >>> >>>Or better yet, include in the draft a 'standard' value for root sourced >>>VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You would al= so >>>have to require the the implementation NOT use global VLAN's, however >>>(since each instance would be using the same values). In this way, no >>>signaling or manual configuration is required for remote PE's to know >>>how >>>to classify traffic. >>>[JY] Indeed, we discussed this possibility during the f2f meeting in >>>Paris. But, there are some restrictions as you mentioned, and >>>furthermore: >>>1) Some vendors already used S-VLAN to distinguish their VSIs in the PE; >>>2) Forwarding plane of a PE needs to be revised to be aware of this VLAN >>>ID. >>>Therefore, this 'standard value' approach seems more disruptive compared >>>with the other means and not a good candidate option. >>> >>>Regarding switching PE's=A9 Multi-PW means more than one PW, yes. I >>>don't >>>see this as a real problem. In general, design should try and avoid >>>using >>>S-PE's, but if you must, its going to mean extra work, no matter how you >>>look at it. Two PW's for each Etree being switched instead of one is >>>not >>>alarming or concerning to me. On the other hand, if you use a dot1q >>>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's >>>an >>>two egress VLAN's if you want the Etree to be handled on both sides (and >>>if you use the 'standard' VID's as I mentioned above, you'd have to do >>>mapping to non-standard and back) >>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>requirements from MEF, it has nothing to do with the solutions. Could >>>you >>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>if configuring or signalling two PWs is not a problem, why configuring >>>or >>>signalling two VLANs will become a problem? After all, more nodes may >>>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>>with 2VLAN (only T-PEs). >>> >>>In general, I still prefer multi-PW, primarily because I prefer the >>>separation of the traffic in the network's forwarding plane, rather than >>>shipping it everywhere and deciding whether to forward to the AC when it >>>gets to the egress PE. I'm having a hard time putting my finger exactly >>>on what it is, or articulating the idea, but it seems that by having the >>>traffic placed into two psuedowires, I have more flexibility and ease of >>>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>>PW's could really change that perception. >>>[JY] Are you saying that we need to develop a totally new forwarding >>>plane rather than using the Ethernet forwarding plane as described in >>>the >>>existing work? >>> >>>I hope we can move forward with one of these soon, >>>[JY] me too. >>> >>>Josh >>> >>> >>>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >>> >>>>Daniel, >>>> >>>>Not aware that we had a discussion on this before, but IMHO the >>>>allocation of internal S-VLAN can be automatic, and manuel >>>>configuration >>>>of this mapping may not be needed at all. For example, an S-VLAN >>>>allocation module in the management plane in a PE can do this kind of >>>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>>way from a free S-VLAN ID pool. Once the interal S-VLANs are allocated, >>>>the mapping is determined and no other configuration is needed. >>>> >>>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>>allocate >>>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to allocate >>>>two S-VLANs in the VPLS domain. >>>> >>>>On the other hand, for the multi-PW approach, two PWs need to be >>>>configured for a E-Tree service. When MS-PW is used in the network, for >>>>every S-PE, we need to configure two ingress PW segments and two egress >>>>PW segments. In this case, I don't think we need to use fixed PW labels >>>>across the network for fear of configuration complexity. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 8:01 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Inline. >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 12:30 PM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, Please see my comments in line. >>>> >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 3:55 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Yuanlong, >>>> >>>>The problem is not with the total number of S-VLAN IDs, I agree that >>>>normally there won't be more than 2047. The problem is that if you >>>>don't >>>>support all VLAN IDs, you need S-VLAN space coordination with the >>>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to >>>>2047". >>>>Which won't always be in line with an existing deployment. >>>>[JY] This is not the case. If the total number is no more than 2047, it >>>>surely can be supported. The S-VLAN space of user domain is totally >>>>different from the S-VLAN in the provider domain and they can be >>>>overlapped, I don't see why we need S-VLAN space coordination between >>>>them. >>>> >>>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>>fixed, and therefore the IEEE S-VID that can be supported is also >>>>fixed. >>>> >>>>Of course you can configure the mapping in each PE according to >>>>operator >>>>requirements but as we discussed before this increases complexity. >>>> >>>>Relying on PBB-VPLS imposes additional limitations on backward >>>>compatibility. >>>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>>think they may well need MAC-in-MAC in their networks for the >>>>scalability issue. As you know, only PBB VPLS can provide both. >>>> >>>>Daniel >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 5:07 AM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, >>>> >>>>As you can see, both cases are discussed in the I-D. >>>> >>>>With regard to case 1) (that is, S-VLAN translation), since the access >>>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>>they need to be configured on a PE anyway, and as the past emails by >>>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>>mapping. >>>> >>>>With regard to S-VID space reduction, the constraint is valid only when >>>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>>typical and with no such limits as we already discussed in the f2f >>>>meeting. >>>> >>>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>>described (not sure this is a valid use case in real life), PBB-VPLS >>>>can >>>>still be used. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Monday, April 30, 2012 10:34 PM >>>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>Jiangyuanlong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>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] >>>>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 >>>> >>>>---------------------------------------------------------------------- >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to >>>copyright belonging to Time Warner Cable. This E-mail is intended solely >>>for the use of the individual or entity to which it is addressed. If you >>>are not the intended recipient of this E-mail, you are hereby notified >>>that any dissemination, distribution, copying, or action taken in >>>relation to the contents of and attachments to this E-mail is strictly >>>prohibited and may be unlawful. If you have received this 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 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 Fri May 4 08:10: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 3729D21F8717 for ; Fri, 4 May 2012 08:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.27 X-Spam-Level: X-Spam-Status: No, score=-2.27 tagged_above=-999 required=5 tests=[AWL=-0.271, 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 jKACEuJsNhQt for ; Fri, 4 May 2012 08:10:09 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 72F0621F8606 for ; Fri, 4 May 2012 08:10:09 -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 AFV22636; Fri, 04 May 2012 11:10:09 -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; Fri, 4 May 2012 08:08:05 -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; Fri, 4 May 2012 08:07:59 -0700 From: Lucy yong To: Aldrin Isaac Subject: RE: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0oo3KJO48LuIhSPkS8Et2e3RTHugARqg4SAAf687wAETa4GgAG6vgwAB5JHAAAB1Ax0A== Date: Fri, 4 May 2012 15:07:58 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D330E918C@dfweml505-mbx> References: <2691CE0099834E4A9C5044EEC662BB9D330E8F11@dfweml505-mbx> <2E819CEF-4A49-439B-86DF-C17503A75398@gmail.com> In-Reply-To: <2E819CEF-4A49-439B-86DF-C17503A75398@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.150.230] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l2vpn@ietf.org" , sajassi 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, 04 May 2012 15:10:10 -0000 Hi Isaac, Thank you for the reply. Please see inline. Regards, Lucy -----Original Message----- From: Aldrin Isaac [mailto:aldrin.isaac@gmail.com]=20 Sent: Thursday, May 03, 2012 10:50 PM To: Lucy yong Cc: sajassi; Giles Heron; Nabil Bitar; l2vpn@ietf.org Subject: Re: Interest in IS-IS VPLS I'm not trying to sell E-VPN here, [[LY]] Sound like. But We like to hear operator views on it for sure. but I'd like to point out that multi-homing isn't the only reason why E-VP= N came about. It's just the one that satisfies the L2VPN charter. [[LY]] Does that mean some E-VPN functions are not in Charter? Don't have t= o answer, WG already agree to work on E-VPN now. E-VPN also supports policy based-topologies versus simple point-to-point, f= lat or tree VLANs. It can support point-to-point, tree, mesh, one-way, or = pretty much any other "complex" or overlapped topologies (depending on how = you like to see it). An example is ability to natively recreate private vl= an, community vlan topologies (which happen to be quite common in DC networ= ks) and any number of combinations of these simultaneously to a single port= . A BGP E-VPN VPN is also decoupled from the edge EVI/ESI such that it is = not limited to a single tenant/vlan but can span tenants/vlans (l2 extranet= ) if so required. This is native to E-VPN. [[LY]] Such policy based-topologies are useful for service provider network= , but may too complex for intra DCs. One reason that customers often want t= o choose with L2VPN service is "it is simple". However, L3VPN have its appl= ications although some operators often complain the complexities to configu= re these policies. Typical example is the a firewall only placed at a locat= ion. Could you share why operator want such policy based-topology for L2VPN= ? E-VPN supports interconnecting end-stations or interconnecting L2 networks.= Procedures to easily span STP based networks across an E-VPN network with= out loops comes with the base spec. Extensions to E-VPN, such as PBB-EVPN,= simplify the fully functional spanning of non-EVPN networks across an E-VP= N network. [[LY]] current L2VPN support all these except active-active mode which caus= es the loop. An SVI/IRB interface can also be a member of both an E-VPN EVI and an IP VR= F allowing for easily bringing together virtual L2 and L3 topologies anywhe= re in the network without a physical port. [[LY]] Could you please share how operator plan to use this? Which service = will you sell to customer in this case? E-VPN builds on top of years of work in the IETF; traffic engineering, scal= ing with route reflectors and RT constrain, multicast via NG-MVPN, etc. [[LY]] Agree. These are useful features for service provider network. Howev= er, these functions may not necessary within DC although they had been prov= ed works well.=20 Can also use IP for transport tunnel. But my understanding is that popular= merchant silicon has support for MPLS push/pop/swap these days (?). This = was captured by EVPN at it's inception, which is why the PE is referred to = as MES (MPLS-enabled switch) in E-VPN. [[LY]] Yes, current draft aims on MPLS solution only. But it states the pot= ential to extend to the use of IP tunnel.=20 The way I see it, a major reason why STP-based LANS are fickle and don't sc= ale well is on account of insufficient decoupling of core from edge created= by requirement for plug-and-play and how that played out over time. Conve= rsely the reason (among other things) why IP networks are more stable is be= cause they are not inherently plug-and-play, and with MPLS/BGP allows excel= lent decoupling of core and edge. I don't know enough about TRILL or PBB t= o comment on those -- I just know that I'm not interested for enough good r= easons. E-VPN enables a dynamic edge over a stable decoupled core while gi= ving each operator room for service differentiation. It is especially inte= resting to operators that have invested in MPLS technology and operations. = I can find a lot of folks that understand BGP/MPLS IPVPN and in short orde= r have them know the ins and outs of basic E-VPN. It's quite hard for me t= o find non-vendor folk who really actually understand the other technologie= s used to span Ethernet aside from basic STP.=20 [[LY]] Thank you to share this in the mailing list.=20 This is an operator perspective. [[LY]] This is great! On May 3, 2012, at 4:31 PM, Lucy yong wrote: > Hi Ali, >=20 >=20 > "5. Ethernet VPN (E-VPN) - An enhanced Layer-2 service that > emulates an Ethernet (V)LAN across a PSN. E-VPN supports > load-sharing across multiple connections from a Layer-2 site > to an L2VPN service. E-VPN is primarily targeted to support > large-scale L2VPNs with resiliency requirements not satisfied > by other L2VPN solutions" >=20 > [[LY]] IMO, E-VPN enhancement is to support multi-homing with active-acti= ve mode. Load-sharing across multiple connections from a layer-2 site is de= sired when this mode is used. Current VPLS can provide resiliency requireme= nt when the multi-homing site configured with active-standby mode. >=20 > Regards, > Lucy >=20 > Cheers, > Ali =20 >=20 From lucy.yong@huawei.com Fri May 4 13:44: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 3A07821E8024 for ; Fri, 4 May 2012 13:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[AWL=-0.262, 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 dXa++16d9ohR for ; Fri, 4 May 2012 13:44:41 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6F04B11E8089 for ; Fri, 4 May 2012 13:44: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 AFN41099; Fri, 04 May 2012 16:44:41 -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; Fri, 4 May 2012 13:42:21 -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; Fri, 4 May 2012 13:42:22 -0700 From: Lucy yong To: "Rogers, Josh" , Jiangyuanlong , Daniel Cohn , "Fedyk, Donald (Don)" , "Henderickx, Wim (Wim)" 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/4Txq0Y50G6N17p5Mncd5asuNMAgAYGiYCAAAzygIAAAjQAgAAAAYCAAASFAIAAAOoAgAAYGACAAAPTgIACzjKAgABsbmCAABSDMIAAJEvQgADhaeD//53EgIAAk10ggAE7MQCAAKXoAIAAuhCAgAATKuA= Date: Fri, 4 May 2012 20:42:21 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D330E933A@dfweml505-mbx> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA560F0@SZXEML508-MBX.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.150.230] Content-Type: text/plain; charset="iso-8859-2" 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: Fri, 04 May 2012 20:44:43 -0000 Hi Josh, I don't understand your following statement. - Both methods have inefficiencies (one duplicates traffic for transport, while the other transports where it doesn't need to go). =20 Both method allows the optimization to avoid transporting where it doesn't = need to go. Regards, Lucy -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com]=20 Sent: Friday, May 04, 2012 7:27 AM To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim);= Lucy yong Cc: l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? [JY2] if the egress PE is attached with pure leafs, 2VLAN approach can also separate the leaf traffic in the ingress PE and filter it there (already detailed in the Optimization Mode in the I-D); if the egress PE is attached with pure roots or with both roots and leafs, it seems all traffic must be transported to the egress PE and be filtered there, I see no difference in behaviour for these solutions. Or did I miss something? The point is with the multi-PW method the traffic is split/separated (by psuedowire) on the ingress PE, rather than the egress. The distinction is 2VLAN will 'classify' the frame on the ingress PE, so that the egress PE knows how to forward it to the appropriate AC's. Both methods have inefficiencies (one duplicates traffic for transport, while the other transports where it doesn't need to go). I like the idea of classify and forwarding on the ingress PE, rather than marking it on the ingress, and deciding on the egress. -Josh On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: >Josh, thank you for the comments, please see my further comments with >[JY2]. > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Thursday, May 03, 2012 11:27 PM >To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >(Wim); Lucy yong >Cc: l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >requirements from MEF, it has nothing to do with the solutions. Could you >give a hint on how you can provision this service E-NNI otherwise? BTW, if >configuring or signalling two PWs is not a problem, why configuring or >signalling two VLANs will become a problem? After all, more nodes may need >to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >2VLAN (only T-PEs). > > >There is no other way (if both MPLS domains are part of the same ETREE, >rather than doing something more like H-VPLS, where one domain has point >to points to the other domain which handles the ETREE instance) if you are >using an ENNI. The other method, (not mentioned earlier) is tying the two >MPLS domains together via labeled unicast (much preferred over E-NNI in my >opinion) > >Configuring two VLAN's isn't really a 'problem' any more than two PW's. I >wasn't saying that configuring two VLAN's was difficult, I was objecting >to the statement that configuring two PW's is difficult. > >[JY2] Thanks, I see your point. I take the example of 2PW configuration >just to show that using fixed global values to simplify configuration >makes no sense. Personally I also don't think configuration is a problem >for both solutions. > >I find the differences between these two methods rather slight. The >'tie-breaker' for me is by placing the forwarding decision on the ingress >PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >more control over where the traffic goes, and in my mind it provides a >cleaner destination between customer traffic and forwarding plane. I'm >accustomed to looking at a psuedowire and knowing where its going, with >the 2vlan method, I can see the psuedowire, but must go to the egress PE >to see if it will be dropped there, or forwarded to one or more AC's. > >[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >also separate the leaf traffic in the ingress PE and filter it there >(already detailed in the Optimization Mode in the I-D); if the egress PE >is attached with pure roots or with both roots and leafs, it seems all >traffic must be transported to the egress PE and be filtered there, I see >no difference in behaviour for these solutions. Or did I miss something? > >Again, the difference here is slight, and I would honestly be happy to see >either of them come to fruition. Please don't infer that I think the >2vlan method is 'bad' or has intrinsic problems, because I don't believe >that. I just prefer the multi-PW method. > > >-Josh > > >On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: > >>Josh, please see my comments in line. >> >>Thanks >>Yuanlong >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Thursday, May 03, 2012 10:51 AM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>Yuanlong, >> >>Or better yet, include in the draft a 'standard' value for root sourced >>VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You would als= o >>have to require the the implementation NOT use global VLAN's, however >>(since each instance would be using the same values). In this way, no >>signaling or manual configuration is required for remote PE's to know how >>to classify traffic. >>[JY] Indeed, we discussed this possibility during the f2f meeting in >>Paris. But, there are some restrictions as you mentioned, and >>furthermore: >>1) Some vendors already used S-VLAN to distinguish their VSIs in the PE; >>2) Forwarding plane of a PE needs to be revised to be aware of this VLAN >>ID. >>Therefore, this 'standard value' approach seems more disruptive compared >>with the other means and not a good candidate option. >> >>Regarding switching PE's=A9 Multi-PW means more than one PW, yes. I don= 't >>see this as a real problem. In general, design should try and avoid >>using >>S-PE's, but if you must, its going to mean extra work, no matter how you >>look at it. Two PW's for each Etree being switched instead of one is not >>alarming or concerning to me. On the other hand, if you use a dot1q >>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's an >>two egress VLAN's if you want the Etree to be handled on both sides (and >>if you use the 'standard' VID's as I mentioned above, you'd have to do >>mapping to non-standard and back) >>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>requirements from MEF, it has nothing to do with the solutions. Could you >>give a hint on how you can provision this service E-NNI otherwise? BTW, >>if configuring or signalling two PWs is not a problem, why configuring or >>signalling two VLANs will become a problem? After all, more nodes may >>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>with 2VLAN (only T-PEs). >> >>In general, I still prefer multi-PW, primarily because I prefer the >>separation of the traffic in the network's forwarding plane, rather than >>shipping it everywhere and deciding whether to forward to the AC when it >>gets to the egress PE. I'm having a hard time putting my finger exactly >>on what it is, or articulating the idea, but it seems that by having the >>traffic placed into two psuedowires, I have more flexibility and ease of >>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>PW's could really change that perception. >>[JY] Are you saying that we need to develop a totally new forwarding >>plane rather than using the Ethernet forwarding plane as described in the >>existing work? >> >>I hope we can move forward with one of these soon, >>[JY] me too. >> >>Josh >> >> >>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >> >>>Daniel, >>> >>>Not aware that we had a discussion on this before, but IMHO the >>>allocation of internal S-VLAN can be automatic, and manuel configuration >>>of this mapping may not be needed at all. For example, an S-VLAN >>>allocation module in the management plane in a PE can do this kind of >>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>way from a free S-VLAN ID pool. Once the interal S-VLANs are allocated, >>>the mapping is determined and no other configuration is needed. >>> >>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>allocate >>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to allocate >>>two S-VLANs in the VPLS domain. >>> >>>On the other hand, for the multi-PW approach, two PWs need to be >>>configured for a E-Tree service. When MS-PW is used in the network, for >>>every S-PE, we need to configure two ingress PW segments and two egress >>>PW segments. In this case, I don't think we need to use fixed PW labels >>>across the network for fear of configuration complexity. >>> >>>Regards, >>>Yuanlong >>> >>>-----Original Message----- >>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>Sent: Wednesday, May 02, 2012 8:01 PM >>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>yong; >>>josh.rogers@twcable.com >>>Cc: l2vpn@ietf.org >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Inline. >>> >>>-----Original Message----- >>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>Sent: Wednesday, May 02, 2012 12:30 PM >>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>josh.rogers@twcable.com >>>Cc: l2vpn@ietf.org >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Hi Daniel, Please see my comments in line. >>> >>> >>>-----Original Message----- >>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>Sent: Wednesday, May 02, 2012 3:55 PM >>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>yong; josh.rogers@twcable.com >>>Cc: l2vpn@ietf.org >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Hi Yuanlong, >>> >>>The problem is not with the total number of S-VLAN IDs, I agree that >>>normally there won't be more than 2047. The problem is that if you don't >>>support all VLAN IDs, you need S-VLAN space coordination with the >>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to 2047". >>>Which won't always be in line with an existing deployment. >>>[JY] This is not the case. If the total number is no more than 2047, it >>>surely can be supported. The S-VLAN space of user domain is totally >>>different from the S-VLAN in the provider domain and they can be >>>overlapped, I don't see why we need S-VLAN space coordination between >>>them. >>> >>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>fixed, and therefore the IEEE S-VID that can be supported is also fixed. >>> >>>Of course you can configure the mapping in each PE according to operator >>>requirements but as we discussed before this increases complexity. >>> >>>Relying on PBB-VPLS imposes additional limitations on backward >>>compatibility. >>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>think they may well need MAC-in-MAC in their networks for the >>>scalability issue. As you know, only PBB VPLS can provide both. >>> >>>Daniel >>> >>>-----Original Message----- >>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>Sent: Wednesday, May 02, 2012 5:07 AM >>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>josh.rogers@twcable.com >>>Cc: l2vpn@ietf.org >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Hi Daniel, >>> >>>As you can see, both cases are discussed in the I-D. >>> >>>With regard to case 1) (that is, S-VLAN translation), since the access >>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>they need to be configured on a PE anyway, and as the past emails by >>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>mapping. >>> >>>With regard to S-VID space reduction, the constraint is valid only when >>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>typical and with no such limits as we already discussed in the f2f >>>meeting. >>> >>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>described (not sure this is a valid use case in real life), PBB-VPLS can >>>still be used. >>> >>>Regards, >>>Yuanlong >>> >>>-----Original Message----- >>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>Sent: Monday, April 30, 2012 10:34 PM >>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>Jiangyuanlong; josh.rogers@twcable.com >>>Cc: l2vpn@ietf.org >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>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] >>>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 >>> >>>---------------------------------------------------------------------- >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject to >>copyright belonging to Time Warner Cable. This E-mail is intended solely >>for the use of the individual or entity to which it is addressed. If you >>are not the intended recipient of this E-mail, you are hereby notified >>that any dissemination, distribution, copying, or action taken in >>relation to the contents of and attachments to this E-mail is strictly >>prohibited and may be unlawful. If you have received this 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 aldrin.isaac@gmail.com Fri May 4 17:20: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 751AA11E8079 for ; Fri, 4 May 2012 17:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxozXkZvgwMb for ; Fri, 4 May 2012 17:20:28 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5A66111E8072 for ; Fri, 4 May 2012 17:20:28 -0700 (PDT) Received: by qcsq13 with SMTP id q13so2638701qcs.31 for ; Fri, 04 May 2012 17:20:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=0a0GxsegE9bnkffy+k3jh/0PFwBkL1Zm6Yv3Qs8RMOg=; b=J1NP6NMC/pEqjKz5GqHIHnlHyxvzIW1j+tOyea8loXsaCcdF0k4jkMKRoQ7EpBzsWY YkzxlwEUlC9Jw57z5JAq6/6XEAaG7NT45E4nGpNCrKrPMO39NFvuYIwZqzShnhBQKk+r tQTcFlTU6YKiuEPeaMBvKZAWpxVRRQERKKFjhvLoeSqtihZgRHVVaHxlE9GtkMHUYpJe 3kZEIHLoUZcQZV6PmkGpMOS+DBxRh73+Mb48xJlYT7zSApe35nnlDo5TnotdJPHAtMBO scup/wM3Z9wzc80uPta1lUa7rP7Pu7mi4zJgtJDfyMIXAMe/U8bv7a2klzUIwLKSCchC 80dg== Received: by 10.229.135.210 with SMTP id o18mr3838665qct.109.1336177227714; Fri, 04 May 2012 17:20:27 -0700 (PDT) Received: from mymac.home (ool-435396f4.dyn.optonline.net. [67.83.150.244]) by mx.google.com with ESMTPS id gy2sm18052232qab.10.2012.05.04.17.20.25 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 04 May 2012 17:20:26 -0700 (PDT) Subject: Re: Interest in IS-IS VPLS Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Aldrin Isaac In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D330E918C@dfweml505-mbx> Date: Fri, 4 May 2012 20:20:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <03B0FD5F-D9F5-4C4E-A7FD-0A2C36A7B092@gmail.com> References: <2691CE0099834E4A9C5044EEC662BB9D330E8F11@dfweml505-mbx> <2E819CEF-4A49-439B-86DF-C17503A75398@gmail.com> <2691CE0099834E4A9C5044EEC662BB9D330E918C@dfweml505-mbx> To: Lucy yong X-Mailer: Apple Mail (2.1257) Cc: "l2vpn@ietf.org" , sajassi 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, 05 May 2012 00:20:29 -0000 Hi Lucy, Please see inline On May 4, 2012, at 11:07 AM, Lucy yong wrote: > Hi Isaac, >=20 > Thank you for the reply. Please see inline. >=20 > Regards, > Lucy >=20 > -----Original Message----- > From: Aldrin Isaac [mailto:aldrin.isaac@gmail.com]=20 > Sent: Thursday, May 03, 2012 10:50 PM > To: Lucy yong > Cc: sajassi; Giles Heron; Nabil Bitar; l2vpn@ietf.org > Subject: Re: Interest in IS-IS VPLS >=20 ...=20 > E-VPN also supports policy based-topologies versus simple = point-to-point, flat or tree VLANs. It can support point-to-point, = tree, mesh, one-way, or pretty much any other "complex" or overlapped = topologies (depending on how you like to see it). An example is ability = to natively recreate private vlan, community vlan topologies (which = happen to be quite common in DC networks) and any number of combinations = of these simultaneously to a single port. A BGP E-VPN VPN is also = decoupled from the edge EVI/ESI such that it is not limited to a single = tenant/vlan but can span tenants/vlans (l2 extranet) if so required. = This is native to E-VPN. > [[LY]] Such policy based-topologies are useful for service provider = network, but may too complex for intra DCs. One reason that customers = often want to choose with L2VPN service is "it is simple". However, = L3VPN have its applications although some operators often complain the = complexities to configure these policies. Typical example is the a = firewall only placed at a location. Could you share why operator want = such policy based-topology for L2VPN? Policy-based topologies are generally complex when used to interconnect = IP networks because there are generally multiple prefixes in a vrf, and = often different prefixes need to be associated to different VPNs or = routing behavior. In the DC, L2VPN role is to interconnect host ports = so the policies for basic are very simple --- list of import route = targets and list of export route targets where each import/export pair = correspond to a VPN (tenant, service, ...). An example of how a DC = operator might use this for example is to meet a requirement for private = vlan and community vlans which are very common for DMZs. Hopefully you = are familiar with these very common use cases. It is even possible to = recreate more complex switch "features" like MVR (in addition to private = VLANs which are also considered "features") using E-VPN. It took me = three years to get the MVR feature into a particular vendor's switch to = meet a business need. I'll sacrifice plug-and-play simplicity for = business agility. I'm sure my peers are with me on this one. If simple "plug-and-play" is important, one could imagine RRs sending = out an "RR TLV" such that RRs in an IGP area auto-connect with each = other and RR-clients connect to the closest RR based on SPF (some = details like peer-group, etc would need to be factored in to make it = more powerful). Other BGP/MPLS configuration is, IMHO, trivial unless = you CHOOSE to use more advanced capabilities (i.e. not locked in). =20 Maybe the reason why MPLS comes across as complex is because of how IETF = deals with requirements lately by creating point solutions. E-VPN tries = to put new capabilities on the table while trying not to take existing = value off the table. There is no reason why a solution can't bring more = value than what the standards body calls for. > E-VPN supports interconnecting end-stations or interconnecting L2 = networks. Procedures to easily span STP based networks across an E-VPN = network without loops comes with the base spec. Extensions to E-VPN, = such as PBB-EVPN, simplify the fully functional spanning of non-EVPN = networks across an E-VPN network. > [[LY]] current L2VPN support all these except active-active mode which = causes the loop. Base E-VPN spec will natively deal with the STP case through an = active/standby mode and BPDU-snooping -- detect root bridge and use that = as ESI (ethernet segment id) to indicate unique STP network with = active/standby bit set to ensure only one forwarding link among links = with same ESI. Tags (vlans) can potentially each have a different = active link within the member links of an ESI allowing for automatic = tag(tenant)/vlan level load-balancing into an STP network. Edge = networks that don't have mac-move issue will be able to take full = advantage of active-active load-balancing without need for LAG/MLAG. > An SVI/IRB interface can also be a member of both an E-VPN EVI and an = IP VRF allowing for easily bringing together virtual L2 and L3 = topologies anywhere in the network without a physical port. > [[LY]] Could you please share how operator plan to use this? Which = service will you sell to customer in this case? The service will be where a customer wants to communicate to a = destination network that is not in his subnet. Operators most = interested in EVPN already have IPVPN services on their network. This = is the gateway point between the EVPN virtual networks and [existing] = IPVPN virtual networks. No physical port required. > E-VPN builds on top of years of work in the IETF; traffic engineering, = scaling with route reflectors and RT constrain, multicast via NG-MVPN, = etc. > [[LY]] Agree. These are useful features for service provider network. = However, these functions may not necessary within DC although they had = been proved works well.=20 I'm not sure how eventually re-inventing these capabilities (yes it will = happen) on behalf of a new protocol will be better than simply = leveraging proven technology. Vendors don't need to implement every = MPLS RFC ever written to be able to implement the basic E-VPN. > Can also use IP for transport tunnel. But my understanding is that = popular merchant silicon has support for MPLS push/pop/swap these days = (?). This was captured by EVPN at it's inception, which is why the PE = is referred to as MES (MPLS-enabled switch) in E-VPN. > [[LY]] Yes, current draft aims on MPLS solution only. But it states = the potential to extend to the use of IP tunnel.=20 > The way I see it, a major reason why STP-based LANS are fickle and = don't scale well is on account of insufficient decoupling of core from = edge created by requirement for plug-and-play and how that played out = over time. Conversely the reason (among other things) why IP networks = are more stable is because they are not inherently plug-and-play, and = with MPLS/BGP allows excellent decoupling of core and edge. I don't = know enough about TRILL or PBB to comment on those -- I just know that = I'm not interested for enough good reasons. E-VPN enables a dynamic = edge over a stable decoupled core while giving each operator room for = service differentiation. It is especially interesting to operators that = have invested in MPLS technology and operations. I can find a lot of = folks that understand BGP/MPLS IPVPN and in short order have them know = the ins and outs of basic E-VPN. It's quite hard for me to find = non-vendor folk who really actually understand the other technologies = used to span Ethernet aside from basic STP.=20 > [[LY]] Thank you to share this in the mailing list.=20 >=20 > This is an operator perspective. > [[LY]] This is great! >=20 >=20 > On May 3, 2012, at 4:31 PM, Lucy yong wrote: >=20 >> Hi Ali, >>=20 >>=20 >> "5. Ethernet VPN (E-VPN) - An enhanced Layer-2 service that >> emulates an Ethernet (V)LAN across a PSN. E-VPN supports >> load-sharing across multiple connections from a Layer-2 site >> to an L2VPN service. E-VPN is primarily targeted to support >> large-scale L2VPNs with resiliency requirements not satisfied >> by other L2VPN solutions" >>=20 >> [[LY]] IMO, E-VPN enhancement is to support multi-homing with = active-active mode. Load-sharing across multiple connections from a = layer-2 site is desired when this mode is used. Current VPLS can provide = resiliency requirement when the multi-homing site configured with = active-standby mode. >>=20 >> Regards, >> Lucy >>=20 >> Cheers, >> Ali =20 >>=20 >=20 From yuqun.cao@gmail.com Fri May 4 19:08: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 F0FD821F847C for ; Fri, 4 May 2012 19:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.718 X-Spam-Level: X-Spam-Status: No, score=-2.718 tagged_above=-999 required=5 tests=[AWL=0.281, 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 wnXDITb8c03D for ; Fri, 4 May 2012 19:08:46 -0700 (PDT) Received: from mail-pz0-f52.google.com (mail-pz0-f52.google.com [209.85.210.52]) by ietfa.amsl.com (Postfix) with ESMTP id 95F7321F847B for ; Fri, 4 May 2012 19:08:46 -0700 (PDT) Received: by dadz9 with SMTP id z9so5665277dad.39 for ; Fri, 04 May 2012 19:08: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:thread-index :x-mimeole:in-reply-to; bh=YjT9O7Zdd5Fx/Bdd6wH4Y698eNZ24MGS+hN7vuYktEA=; b=uuNcrcNiICit1NwIkMa8ApDLDI//7UvPs3ksRPNbfJVB/B0UhuQvUWl+1daMP4EHkD On5o6KtpRunOCREm+QKXxgGR4sFbu33ewpWkNnpKM4Vj03jugsEzfr0YQra2H07qix2Q Ru8mlaEtpFV6hlOtvbqEYhMdGroS5S6nKajQIYndzSPe9o5tTAm9PPmUdrJZzSUA1QBa kmVl4WD1B/krt8Ej4uf21OO/HMCqkzuZ5Qi7FGBwlBgIjhoDfx4ykbM0fsRJ8SWjNJhH LOgNNA8K4Cf/OZURaAdNLtzrxRwFQ/JMAPbuCFL9ZoT2xpm7SMSPULFciZDmBRIK+pZ1 FmeA== Received: by 10.68.226.163 with SMTP id rt3mr9435179pbc.41.1336183726166; Fri, 04 May 2012 19:08:46 -0700 (PDT) Received: from R01842 ([110.90.119.113]) by mx.google.com with ESMTPS id mr6sm10309110pbb.29.2012.05.04.19.08.37 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 04 May 2012 19:08:44 -0700 (PDT) From: "Sam Cao" To: References: Subject: RE: L2vpn Digest, Vol 96, Issue 15 Date: Sat, 5 May 2012 10:08:58 +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: Ac0qAqy9LTtQ75h0R2+YJ9mGFYIsPwAWFG9Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 In-Reply-To: Cc: 'Jiangyuanlong' 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, 05 May 2012 02:08:50 -0000 Lucy/Yuanlong, I agree that we can not say which approach is better simply, but I really agree with Josh's comments. Multi-PW is easy to implement E-Tree. First of all, we discussed 2 approaches for a long time and many rounds, and for me, there are no pending issues on Multi-PW till now or co-authors of multi-PW have given reasonable reply to L2VPN members' questions, but there are still pending issues for Dual-VLAN. Please trace the mailing list. Second, Sasha has his concern in NP, or forwarding performance. Compared to current VPLS, Multi-PW has a little effect on forwarding performance since it reuse PW label as AC indicator; Dual-VLAN will have higher side effect on forwarding performance because it SHOULD use additional indicator. Is there one prototype for Dual-VLAN? BTW, there is no reply on chip limit. Third, the difference between Multi-PW and dual-VLAN is, transport ingress traffic in one "LSP" or 2 "LSP". Multi-PW classifies and transforms ingress traffic into right "path", and egress just pop-out PW label and forward the frame to ACs. Dual-VLAN has more work on ingress PE or egress PE. Fourth, maybe Giles has figured this out, Dual-VLAN has capacity limit. Only 4094 VLAN ID are available, so only 2K E-Tree instances can be supported on one PE for Dual-VLAN approach. There is no such limit for Multi-PW approach, Finally, in this thread we don't make agreement on VLAN ID allocation. We also have questions on VLAN ID negotiation among PEs (signaling protocol). Yuanlong wishes to update, but there is no update till now. For me, why IEEE uses VLAN ID to identify AC type? IEEE has no LABEL :), and it has label, it also wish to use label to identify AC types. I think that both solutions need much time to be perfect. Mutli-PW has less extension work to do. But now we are focusing on technical details and can not move forward :). Thanks, Sam -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of l2vpn-request@ietf.org Sent: Friday, May 04, 2012 10:31 PM To: l2vpn@ietf.org Subject: L2vpn Digest, Vol 96, Issue 15 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) 2. Re: The status of the approaches to the E-Tree solution? (Rogers, Josh) ---------------------------------------------------------------------- Message: 1 Date: Fri, 4 May 2012 14:16:36 +0000 From: Lucy yong To: "Rogers, Josh" , Jiangyuanlong , Daniel Cohn , "Fedyk, Donald (Don)" , "Henderickx, Wim (Wim)" Cc: "l2vpn@ietf.org" Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: <2691CE0099834E4A9C5044EEC662BB9D330E9114@dfweml505-mbx> Content-Type: text/plain; charset="iso-8859-2" Josh, You simply say that you don't like IEEE Tree solution. IEEE Tree solution is for ingress port to mark and for egress port to filter. Regards, Lucy -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com] Sent: Friday, May 04, 2012 7:27 AM To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong Cc: l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? [JY2] if the egress PE is attached with pure leafs, 2VLAN approach can also separate the leaf traffic in the ingress PE and filter it there (already detailed in the Optimization Mode in the I-D); if the egress PE is attached with pure roots or with both roots and leafs, it seems all traffic must be transported to the egress PE and be filtered there, I see no difference in behaviour for these solutions. Or did I miss something? The point is with the multi-PW method the traffic is split/separated (by psuedowire) on the ingress PE, rather than the egress. The distinction is 2VLAN will 'classify' the frame on the ingress PE, so that the egress PE knows how to forward it to the appropriate AC's. Both methods have inefficiencies (one duplicates traffic for transport, while the other transports where it doesn't need to go). I like the idea of classify and forwarding on the ingress PE, rather than marking it on the ingress, and deciding on the egress. -Josh On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: >Josh, thank you for the comments, please see my further comments with >[JY2]. > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Thursday, May 03, 2012 11:27 PM >To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >(Wim); Lucy yong >Cc: l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >requirements from MEF, it has nothing to do with the solutions. Could you >give a hint on how you can provision this service E-NNI otherwise? BTW, if >configuring or signalling two PWs is not a problem, why configuring or >signalling two VLANs will become a problem? After all, more nodes may need >to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >2VLAN (only T-PEs). > > >There is no other way (if both MPLS domains are part of the same ETREE, >rather than doing something more like H-VPLS, where one domain has point >to points to the other domain which handles the ETREE instance) if you are >using an ENNI. The other method, (not mentioned earlier) is tying the two >MPLS domains together via labeled unicast (much preferred over E-NNI in my >opinion) > >Configuring two VLAN's isn't really a 'problem' any more than two PW's. I >wasn't saying that configuring two VLAN's was difficult, I was objecting >to the statement that configuring two PW's is difficult. > >[JY2] Thanks, I see your point. I take the example of 2PW configuration >just to show that using fixed global values to simplify configuration >makes no sense. Personally I also don't think configuration is a problem >for both solutions. > >I find the differences between these two methods rather slight. The >'tie-breaker' for me is by placing the forwarding decision on the ingress >PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >more control over where the traffic goes, and in my mind it provides a >cleaner destination between customer traffic and forwarding plane. I'm >accustomed to looking at a psuedowire and knowing where its going, with >the 2vlan method, I can see the psuedowire, but must go to the egress PE >to see if it will be dropped there, or forwarded to one or more AC's. > >[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >also separate the leaf traffic in the ingress PE and filter it there >(already detailed in the Optimization Mode in the I-D); if the egress PE >is attached with pure roots or with both roots and leafs, it seems all >traffic must be transported to the egress PE and be filtered there, I see >no difference in behaviour for these solutions. Or did I miss something? > >Again, the difference here is slight, and I would honestly be happy to see >either of them come to fruition. Please don't infer that I think the >2vlan method is 'bad' or has intrinsic problems, because I don't believe >that. I just prefer the multi-PW method. > > >-Josh > > >On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: > >>Josh, please see my comments in line. >> >>Thanks >>Yuanlong >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Thursday, May 03, 2012 10:51 AM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>Yuanlong, >> >>Or better yet, include in the draft a 'standard' value for root sourced >>VID and leaf sourced VID. i.e., 4093=root, 4094=leaf. You would also >>have to require the the implementation NOT use global VLAN's, however >>(since each instance would be using the same values). In this way, no >>signaling or manual configuration is required for remote PE's to know how >>to classify traffic. >>[JY] Indeed, we discussed this possibility during the f2f meeting in >>Paris. But, there are some restrictions as you mentioned, and >>furthermore: >>1) Some vendors already used S-VLAN to distinguish their VSIs in the PE; >>2) Forwarding plane of a PE needs to be revised to be aware of this VLAN >>ID. >>Therefore, this 'standard value' approach seems more disruptive compared >>with the other means and not a good candidate option. >> >>Regarding switching PE's? Multi-PW means more than one PW, yes. I don't >>see this as a real problem. In general, design should try and avoid >>using >>S-PE's, but if you must, its going to mean extra work, no matter how you >>look at it. Two PW's for each Etree being switched instead of one is not >>alarming or concerning to me. On the other hand, if you use a dot1q >>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's an >>two egress VLAN's if you want the Etree to be handled on both sides (and >>if you use the 'standard' VID's as I mentioned above, you'd have to do >>mapping to non-standard and back) >>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>requirements from MEF, it has nothing to do with the solutions. Could you >>give a hint on how you can provision this service E-NNI otherwise? BTW, >>if configuring or signalling two PWs is not a problem, why configuring or >>signalling two VLANs will become a problem? After all, more nodes may >>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>with 2VLAN (only T-PEs). >> >>In general, I still prefer multi-PW, primarily because I prefer the >>separation of the traffic in the network's forwarding plane, rather than >>shipping it everywhere and deciding whether to forward to the AC when it >>gets to the egress PE. I'm having a hard time putting my finger exactly >>on what it is, or articulating the idea, but it seems that by having the >>traffic placed into two psuedowires, I have more flexibility and ease of >>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>PW's could really change that perception. >>[JY] Are you saying that we need to develop a totally new forwarding >>plane rather than using the Ethernet forwarding plane as described in the >>existing work? >> >>I hope we can move forward with one of these soon, >>[JY] me too. >> >>Josh >> >> >>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >> >>>Daniel, >>> >>>Not aware that we had a discussion on this before, but IMHO the >>>allocation of internal S-VLAN can be automatic, and manuel configuration >>>of this mapping may not be needed at all. For example, an S-VLAN >>>allocation module in the management plane in a PE can do this kind of >>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>way from a free S-VLAN ID pool. Once the interal S-VLANs are allocated, >>>the mapping is determined and no other configuration is needed. >>> >>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>allocate >>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to allocate >>>two S-VLANs in the VPLS domain. >>> >>>On the other hand, for the multi-PW approach, two PWs need to be >>>configured for a E-Tree service. When MS-PW is used in the network, for >>>every S-PE, we need to configure two ingress PW segments and two egress >>>PW segments. In this case, I don't think we need to use fixed PW labels >>>across the network for fear of configuration complexity. >>> >>>Regards, >>>Yuanlong >>> >>>-----Original Message----- >>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>Sent: Wednesday, May 02, 2012 8:01 PM >>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>yong; >>>josh.rogers@twcable.com >>>Cc: l2vpn@ietf.org >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Inline. >>> >>>-----Original Message----- >>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>Sent: Wednesday, May 02, 2012 12:30 PM >>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>josh.rogers@twcable.com >>>Cc: l2vpn@ietf.org >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Hi Daniel, Please see my comments in line. >>> >>> >>>-----Original Message----- >>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>Sent: Wednesday, May 02, 2012 3:55 PM >>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>yong; josh.rogers@twcable.com >>>Cc: l2vpn@ietf.org >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Hi Yuanlong, >>> >>>The problem is not with the total number of S-VLAN IDs, I agree that >>>normally there won't be more than 2047. The problem is that if you don't >>>support all VLAN IDs, you need S-VLAN space coordination with the >>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to 2047". >>>Which won't always be in line with an existing deployment. >>>[JY] This is not the case. If the total number is no more than 2047, it >>>surely can be supported. The S-VLAN space of user domain is totally >>>different from the S-VLAN in the provider domain and they can be >>>overlapped, I don't see why we need S-VLAN space coordination between >>>them. >>> >>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>fixed, and therefore the IEEE S-VID that can be supported is also fixed. >>> >>>Of course you can configure the mapping in each PE according to operator >>>requirements but as we discussed before this increases complexity. >>> >>>Relying on PBB-VPLS imposes additional limitations on backward >>>compatibility. >>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>think they may well need MAC-in-MAC in their networks for the >>>scalability issue. As you know, only PBB VPLS can provide both. >>> >>>Daniel >>> >>>-----Original Message----- >>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>Sent: Wednesday, May 02, 2012 5:07 AM >>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>josh.rogers@twcable.com >>>Cc: l2vpn@ietf.org >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Hi Daniel, >>> >>>As you can see, both cases are discussed in the I-D. >>> >>>With regard to case 1) (that is, S-VLAN translation), since the access >>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>they need to be configured on a PE anyway, and as the past emails by >>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>mapping. >>> >>>With regard to S-VID space reduction, the constraint is valid only when >>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>typical and with no such limits as we already discussed in the f2f >>>meeting. >>> >>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>described (not sure this is a valid use case in real life), PBB-VPLS can >>>still be used. >>> >>>Regards, >>>Yuanlong >>> >>>-----Original Message----- >>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>Sent: Monday, April 30, 2012 10:34 PM >>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>Jiangyuanlong; josh.rogers@twcable.com >>>Cc: l2vpn@ietf.org >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>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] >>>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 >>> >>>---------------------------------------------------------------------- >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject to >>copyright belonging to Time Warner Cable. This E-mail is intended solely >>for the use of the individual or entity to which it is addressed. If you >>are not the intended recipient of this E-mail, you are hereby notified >>that any dissemination, distribution, copying, or action taken in >>relation to the contents of and attachments to this E-mail is strictly >>prohibited and may be unlawful. If you have received this 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. ------------------------------ Message: 2 Date: Fri, 4 May 2012 10:30:38 -0400 From: "Rogers, Josh" To: Lucy yong , Jiangyuanlong , Daniel Cohn , "Fedyk, Donald (Don)" , "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="iso-8859-2" To be more accurate, I like it less than the multi-PW solution. I'd be happy to use the 2VLAN solution in the real world, if it was ratified as the standard. On 5/4/12 9:16 AM, "Lucy yong" wrote: >Josh, > >You simply say that you don't like IEEE Tree solution. IEEE Tree solution >is for ingress port to mark and for egress port to filter. > >Regards, >Lucy > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Friday, May 04, 2012 7:27 AM >To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >(Wim); Lucy yong >Cc: l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >also separate the leaf traffic in the ingress PE and filter it there >(already detailed in the Optimization Mode in the I-D); if the egress PE >is attached with pure roots or with both roots and leafs, it seems all >traffic must be transported to the egress PE and be filtered there, I see >no difference in behaviour for these solutions. Or did I miss something? > > >The point is with the multi-PW method the traffic is split/separated (by >psuedowire) on the ingress PE, rather than the egress. The distinction is >2VLAN will 'classify' the frame on the ingress PE, so that the egress PE >knows how to forward it to the appropriate AC's. > >Both methods have inefficiencies (one duplicates traffic for transport, >while the other transports where it doesn't need to go). I like the idea >of classify and forwarding on the ingress PE, rather than marking it on >the ingress, and deciding on the egress. > >-Josh > > > >On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: > >>Josh, thank you for the comments, please see my further comments with >>[JY2]. >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Thursday, May 03, 2012 11:27 PM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>requirements from MEF, it has nothing to do with the solutions. Could you >>give a hint on how you can provision this service E-NNI otherwise? BTW, >>if >>configuring or signalling two PWs is not a problem, why configuring or >>signalling two VLANs will become a problem? After all, more nodes may >>need >>to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >>2VLAN (only T-PEs). >> >> >>There is no other way (if both MPLS domains are part of the same ETREE, >>rather than doing something more like H-VPLS, where one domain has point >>to points to the other domain which handles the ETREE instance) if you >>are >>using an ENNI. The other method, (not mentioned earlier) is tying the >>two >>MPLS domains together via labeled unicast (much preferred over E-NNI in >>my >>opinion) >> >>Configuring two VLAN's isn't really a 'problem' any more than two PW's. >>I >>wasn't saying that configuring two VLAN's was difficult, I was objecting >>to the statement that configuring two PW's is difficult. >> >>[JY2] Thanks, I see your point. I take the example of 2PW configuration >>just to show that using fixed global values to simplify configuration >>makes no sense. Personally I also don't think configuration is a problem >>for both solutions. >> >>I find the differences between these two methods rather slight. The >>'tie-breaker' for me is by placing the forwarding decision on the ingress >>PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >>more control over where the traffic goes, and in my mind it provides a >>cleaner destination between customer traffic and forwarding plane. I'm >>accustomed to looking at a psuedowire and knowing where its going, with >>the 2vlan method, I can see the psuedowire, but must go to the egress PE >>to see if it will be dropped there, or forwarded to one or more AC's. >> >>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>also separate the leaf traffic in the ingress PE and filter it there >>(already detailed in the Optimization Mode in the I-D); if the egress PE >>is attached with pure roots or with both roots and leafs, it seems all >>traffic must be transported to the egress PE and be filtered there, I see >>no difference in behaviour for these solutions. Or did I miss something? >> >>Again, the difference here is slight, and I would honestly be happy to >>see >>either of them come to fruition. Please don't infer that I think the >>2vlan method is 'bad' or has intrinsic problems, because I don't believe >>that. I just prefer the multi-PW method. >> >> >>-Josh >> >> >>On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: >> >>>Josh, please see my comments in line. >>> >>>Thanks >>>Yuanlong >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Thursday, May 03, 2012 10:51 AM >>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>(Wim); Lucy yong >>>Cc: l2vpn@ietf.org >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Yuanlong, >>> >>>Or better yet, include in the draft a 'standard' value for root sourced >>>VID and leaf sourced VID. i.e., 4093=root, 4094=leaf. You would also >>>have to require the the implementation NOT use global VLAN's, however >>>(since each instance would be using the same values). In this way, no >>>signaling or manual configuration is required for remote PE's to know >>>how >>>to classify traffic. >>>[JY] Indeed, we discussed this possibility during the f2f meeting in >>>Paris. But, there are some restrictions as you mentioned, and >>>furthermore: >>>1) Some vendors already used S-VLAN to distinguish their VSIs in the PE; >>>2) Forwarding plane of a PE needs to be revised to be aware of this VLAN >>>ID. >>>Therefore, this 'standard value' approach seems more disruptive compared >>>with the other means and not a good candidate option. >>> >>>Regarding switching PE's? Multi-PW means more than one PW, yes. I >>>don't >>>see this as a real problem. In general, design should try and avoid >>>using >>>S-PE's, but if you must, its going to mean extra work, no matter how you >>>look at it. Two PW's for each Etree being switched instead of one is >>>not >>>alarming or concerning to me. On the other hand, if you use a dot1q >>>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's >>>an >>>two egress VLAN's if you want the Etree to be handled on both sides (and >>>if you use the 'standard' VID's as I mentioned above, you'd have to do >>>mapping to non-standard and back) >>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>requirements from MEF, it has nothing to do with the solutions. Could >>>you >>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>if configuring or signalling two PWs is not a problem, why configuring >>>or >>>signalling two VLANs will become a problem? After all, more nodes may >>>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>>with 2VLAN (only T-PEs). >>> >>>In general, I still prefer multi-PW, primarily because I prefer the >>>separation of the traffic in the network's forwarding plane, rather than >>>shipping it everywhere and deciding whether to forward to the AC when it >>>gets to the egress PE. I'm having a hard time putting my finger exactly >>>on what it is, or articulating the idea, but it seems that by having the >>>traffic placed into two psuedowires, I have more flexibility and ease of >>>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>>PW's could really change that perception. >>>[JY] Are you saying that we need to develop a totally new forwarding >>>plane rather than using the Ethernet forwarding plane as described in >>>the >>>existing work? >>> >>>I hope we can move forward with one of these soon, >>>[JY] me too. >>> >>>Josh >>> >>> >>>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >>> >>>>Daniel, >>>> >>>>Not aware that we had a discussion on this before, but IMHO the >>>>allocation of internal S-VLAN can be automatic, and manuel >>>>configuration >>>>of this mapping may not be needed at all. For example, an S-VLAN >>>>allocation module in the management plane in a PE can do this kind of >>>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>>way from a free S-VLAN ID pool. Once the interal S-VLANs are allocated, >>>>the mapping is determined and no other configuration is needed. >>>> >>>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>>allocate >>>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to allocate >>>>two S-VLANs in the VPLS domain. >>>> >>>>On the other hand, for the multi-PW approach, two PWs need to be >>>>configured for a E-Tree service. When MS-PW is used in the network, for >>>>every S-PE, we need to configure two ingress PW segments and two egress >>>>PW segments. In this case, I don't think we need to use fixed PW labels >>>>across the network for fear of configuration complexity. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 8:01 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Inline. >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 12:30 PM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, Please see my comments in line. >>>> >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 3:55 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Yuanlong, >>>> >>>>The problem is not with the total number of S-VLAN IDs, I agree that >>>>normally there won't be more than 2047. The problem is that if you >>>>don't >>>>support all VLAN IDs, you need S-VLAN space coordination with the >>>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to >>>>2047". >>>>Which won't always be in line with an existing deployment. >>>>[JY] This is not the case. If the total number is no more than 2047, it >>>>surely can be supported. The S-VLAN space of user domain is totally >>>>different from the S-VLAN in the provider domain and they can be >>>>overlapped, I don't see why we need S-VLAN space coordination between >>>>them. >>>> >>>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>>fixed, and therefore the IEEE S-VID that can be supported is also >>>>fixed. >>>> >>>>Of course you can configure the mapping in each PE according to >>>>operator >>>>requirements but as we discussed before this increases complexity. >>>> >>>>Relying on PBB-VPLS imposes additional limitations on backward >>>>compatibility. >>>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>>think they may well need MAC-in-MAC in their networks for the >>>>scalability issue. As you know, only PBB VPLS can provide both. >>>> >>>>Daniel >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 5:07 AM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, >>>> >>>>As you can see, both cases are discussed in the I-D. >>>> >>>>With regard to case 1) (that is, S-VLAN translation), since the access >>>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>>they need to be configured on a PE anyway, and as the past emails by >>>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>>mapping. >>>> >>>>With regard to S-VID space reduction, the constraint is valid only when >>>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>>typical and with no such limits as we already discussed in the f2f >>>>meeting. >>>> >>>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>>described (not sure this is a valid use case in real life), PBB-VPLS >>>>can >>>>still be used. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Monday, April 30, 2012 10:34 PM >>>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>Jiangyuanlong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>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] >>>>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 >>>> >>>>---------------------------------------------------------------------- >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to >>>copyright belonging to Time Warner Cable. This E-mail is intended solely >>>for the use of the individual or entity to which it is addressed. If you >>>are not the intended recipient of this E-mail, you are hereby notified >>>that any dissemination, distribution, copying, or action taken in >>>relation to the contents of and attachments to this E-mail is strictly >>>prohibited and may be unlawful. If you have received this 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 and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this 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 96, Issue 15 ************************************* From yuqun.cao@gmail.com Fri May 4 21:11: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 6A3BE21F845E for ; Fri, 4 May 2012 21:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 Knyp9BUot7CK for ; Fri, 4 May 2012 21:11:29 -0700 (PDT) Received: from mail-pz0-f52.google.com (mail-pz0-f52.google.com [209.85.210.52]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE3C21F8446 for ; Fri, 4 May 2012 21:11:29 -0700 (PDT) Received: by dadz9 with SMTP id z9so5789384dad.39 for ; Fri, 04 May 2012 21:11:29 -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=Z6+ZQY1ij1CEkGg5Sm2zw9kU6vvt97kdZX4CagCVD7A=; b=EUO+zh0+WxVjw/mz7az+psimPXztAYerA4Qg+0EhT6aeRVoJm9Lvextgc158slC7jX fxeQoxhDxMsWaW1UU17tuno/kzkl2Sx9pxjTNl3dJKvAheEDB0SzzBwnc3Sh+r2H/lsy gkrGZRv13nY5pDda2p1DqSW8cWyKJEj/E4MMMmSynQeR/yIChU2WuzkcFRVfSy/EaQEU /vB9PF4HSDVocirgsKMKU16q44iDh3B11uHGrnNZcg2FHXU4yUQZGBjEVLr7tWpTbnF3 ilr0oVvGu2x0A6tzFEMBfxlQu2xsFV1IB5BNRYtBRXAFO4bjRCJQLhjEuVvTxOK3YS7z Rxjg== Received: by 10.68.244.40 with SMTP id xd8mr7926362pbc.132.1336191088559; Fri, 04 May 2012 21:11:28 -0700 (PDT) Received: from R01842 ([110.90.119.113]) by mx.google.com with ESMTPS id qc2sm1769472pbc.51.2012.05.04.21.11.14 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 04 May 2012 21:11:26 -0700 (PDT) From: "Sam Cao" To: References: Subject: RE: L2vpn Digest, Vol 96, Issue 18 Date: Sat, 5 May 2012 12:11:23 +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: Ac0qVOiAV3aLlzgvTaSeicLY3fDOZgAHI1/Q 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: Sat, 05 May 2012 04:11:31 -0000 I guess the following case is what Josh mentioned, PE1 has Root AC and Leaf AC, but PE2 has leaf-AC only. Both methods should setup PW between PE1 and PE2. So one unknown or broadcast frame originated from Leaf AC on PE1 will be forwarded to PE2, but this is really not necessary. Sam -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of l2vpn-request@ietf.org Sent: Saturday, May 05, 2012 8:21 AM To: l2vpn@ietf.org Subject: L2vpn Digest, Vol 96, Issue 18 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) 2. Re: Interest in IS-IS VPLS (Aldrin Isaac) ---------------------------------------------------------------------- Message: 1 Date: Fri, 4 May 2012 20:42:21 +0000 From: Lucy yong To: "Rogers, Josh" , Jiangyuanlong , Daniel Cohn , "Fedyk, Donald (Don)" , "Henderickx, Wim (Wim)" Cc: "l2vpn@ietf.org" Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: <2691CE0099834E4A9C5044EEC662BB9D330E933A@dfweml505-mbx> Content-Type: text/plain; charset="iso-8859-2" Hi Josh, I don't understand your following statement. - Both methods have inefficiencies (one duplicates traffic for transport, while the other transports where it doesn't need to go). Both method allows the optimization to avoid transporting where it doesn't need to go. Regards, Lucy -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com] Sent: Friday, May 04, 2012 7:27 AM To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong Cc: l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? [JY2] if the egress PE is attached with pure leafs, 2VLAN approach can also separate the leaf traffic in the ingress PE and filter it there (already detailed in the Optimization Mode in the I-D); if the egress PE is attached with pure roots or with both roots and leafs, it seems all traffic must be transported to the egress PE and be filtered there, I see no difference in behaviour for these solutions. Or did I miss something? The point is with the multi-PW method the traffic is split/separated (by psuedowire) on the ingress PE, rather than the egress. The distinction is 2VLAN will 'classify' the frame on the ingress PE, so that the egress PE knows how to forward it to the appropriate AC's. Both methods have inefficiencies (one duplicates traffic for transport, while the other transports where it doesn't need to go). I like the idea of classify and forwarding on the ingress PE, rather than marking it on the ingress, and deciding on the egress. -Josh On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: >Josh, thank you for the comments, please see my further comments with >[JY2]. > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Thursday, May 03, 2012 11:27 PM >To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >(Wim); Lucy yong >Cc: l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >requirements from MEF, it has nothing to do with the solutions. Could you >give a hint on how you can provision this service E-NNI otherwise? BTW, if >configuring or signalling two PWs is not a problem, why configuring or >signalling two VLANs will become a problem? After all, more nodes may need >to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >2VLAN (only T-PEs). > > >There is no other way (if both MPLS domains are part of the same ETREE, >rather than doing something more like H-VPLS, where one domain has point >to points to the other domain which handles the ETREE instance) if you are >using an ENNI. The other method, (not mentioned earlier) is tying the two >MPLS domains together via labeled unicast (much preferred over E-NNI in my >opinion) > >Configuring two VLAN's isn't really a 'problem' any more than two PW's. I >wasn't saying that configuring two VLAN's was difficult, I was objecting >to the statement that configuring two PW's is difficult. > >[JY2] Thanks, I see your point. I take the example of 2PW configuration >just to show that using fixed global values to simplify configuration >makes no sense. Personally I also don't think configuration is a problem >for both solutions. > >I find the differences between these two methods rather slight. The >'tie-breaker' for me is by placing the forwarding decision on the ingress >PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >more control over where the traffic goes, and in my mind it provides a >cleaner destination between customer traffic and forwarding plane. I'm >accustomed to looking at a psuedowire and knowing where its going, with >the 2vlan method, I can see the psuedowire, but must go to the egress PE >to see if it will be dropped there, or forwarded to one or more AC's. > >[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >also separate the leaf traffic in the ingress PE and filter it there >(already detailed in the Optimization Mode in the I-D); if the egress PE >is attached with pure roots or with both roots and leafs, it seems all >traffic must be transported to the egress PE and be filtered there, I see >no difference in behaviour for these solutions. Or did I miss something? > >Again, the difference here is slight, and I would honestly be happy to see >either of them come to fruition. Please don't infer that I think the >2vlan method is 'bad' or has intrinsic problems, because I don't believe >that. I just prefer the multi-PW method. > > >-Josh > > >On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: > >>Josh, please see my comments in line. >> >>Thanks >>Yuanlong >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Thursday, May 03, 2012 10:51 AM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>Yuanlong, >> >>Or better yet, include in the draft a 'standard' value for root sourced >>VID and leaf sourced VID. i.e., 4093=root, 4094=leaf. You would also >>have to require the the implementation NOT use global VLAN's, however >>(since each instance would be using the same values). In this way, no >>signaling or manual configuration is required for remote PE's to know how >>to classify traffic. >>[JY] Indeed, we discussed this possibility during the f2f meeting in >>Paris. But, there are some restrictions as you mentioned, and >>furthermore: >>1) Some vendors already used S-VLAN to distinguish their VSIs in the PE; >>2) Forwarding plane of a PE needs to be revised to be aware of this VLAN >>ID. >>Therefore, this 'standard value' approach seems more disruptive compared >>with the other means and not a good candidate option. >> >>Regarding switching PE's? Multi-PW means more than one PW, yes. I don't >>see this as a real problem. In general, design should try and avoid >>using >>S-PE's, but if you must, its going to mean extra work, no matter how you >>look at it. Two PW's for each Etree being switched instead of one is not >>alarming or concerning to me. On the other hand, if you use a dot1q >>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's an >>two egress VLAN's if you want the Etree to be handled on both sides (and >>if you use the 'standard' VID's as I mentioned above, you'd have to do >>mapping to non-standard and back) >>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>requirements from MEF, it has nothing to do with the solutions. Could you >>give a hint on how you can provision this service E-NNI otherwise? BTW, >>if configuring or signalling two PWs is not a problem, why configuring or >>signalling two VLANs will become a problem? After all, more nodes may >>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>with 2VLAN (only T-PEs). >> >>In general, I still prefer multi-PW, primarily because I prefer the >>separation of the traffic in the network's forwarding plane, rather than >>shipping it everywhere and deciding whether to forward to the AC when it >>gets to the egress PE. I'm having a hard time putting my finger exactly >>on what it is, or articulating the idea, but it seems that by having the >>traffic placed into two psuedowires, I have more flexibility and ease of >>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>PW's could really change that perception. >>[JY] Are you saying that we need to develop a totally new forwarding >>plane rather than using the Ethernet forwarding plane as described in the >>existing work? >> >>I hope we can move forward with one of these soon, >>[JY] me too. >> >>Josh >> >> >>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >> >>>Daniel, >>> >>>Not aware that we had a discussion on this before, but IMHO the >>>allocation of internal S-VLAN can be automatic, and manuel configuration >>>of this mapping may not be needed at all. For example, an S-VLAN >>>allocation module in the management plane in a PE can do this kind of >>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>way from a free S-VLAN ID pool. Once the interal S-VLANs are allocated, >>>the mapping is determined and no other configuration is needed. >>> >>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>allocate >>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to allocate >>>two S-VLANs in the VPLS domain. >>> >>>On the other hand, for the multi-PW approach, two PWs need to be >>>configured for a E-Tree service. When MS-PW is used in the network, for >>>every S-PE, we need to configure two ingress PW segments and two egress >>>PW segments. In this case, I don't think we need to use fixed PW labels >>>across the network for fear of configuration complexity. >>> >>>Regards, >>>Yuanlong >>> >>>-----Original Message----- >>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>Sent: Wednesday, May 02, 2012 8:01 PM >>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>yong; >>>josh.rogers@twcable.com >>>Cc: l2vpn@ietf.org >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Inline. >>> >>>-----Original Message----- >>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>Sent: Wednesday, May 02, 2012 12:30 PM >>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>josh.rogers@twcable.com >>>Cc: l2vpn@ietf.org >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Hi Daniel, Please see my comments in line. >>> >>> >>>-----Original Message----- >>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>Sent: Wednesday, May 02, 2012 3:55 PM >>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>yong; josh.rogers@twcable.com >>>Cc: l2vpn@ietf.org >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Hi Yuanlong, >>> >>>The problem is not with the total number of S-VLAN IDs, I agree that >>>normally there won't be more than 2047. The problem is that if you don't >>>support all VLAN IDs, you need S-VLAN space coordination with the >>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to 2047". >>>Which won't always be in line with an existing deployment. >>>[JY] This is not the case. If the total number is no more than 2047, it >>>surely can be supported. The S-VLAN space of user domain is totally >>>different from the S-VLAN in the provider domain and they can be >>>overlapped, I don't see why we need S-VLAN space coordination between >>>them. >>> >>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>fixed, and therefore the IEEE S-VID that can be supported is also fixed. >>> >>>Of course you can configure the mapping in each PE according to operator >>>requirements but as we discussed before this increases complexity. >>> >>>Relying on PBB-VPLS imposes additional limitations on backward >>>compatibility. >>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>think they may well need MAC-in-MAC in their networks for the >>>scalability issue. As you know, only PBB VPLS can provide both. >>> >>>Daniel >>> >>>-----Original Message----- >>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>Sent: Wednesday, May 02, 2012 5:07 AM >>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>josh.rogers@twcable.com >>>Cc: l2vpn@ietf.org >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Hi Daniel, >>> >>>As you can see, both cases are discussed in the I-D. >>> >>>With regard to case 1) (that is, S-VLAN translation), since the access >>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>they need to be configured on a PE anyway, and as the past emails by >>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>mapping. >>> >>>With regard to S-VID space reduction, the constraint is valid only when >>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>typical and with no such limits as we already discussed in the f2f >>>meeting. >>> >>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>described (not sure this is a valid use case in real life), PBB-VPLS can >>>still be used. >>> >>>Regards, >>>Yuanlong >>> >>>-----Original Message----- >>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>Sent: Monday, April 30, 2012 10:34 PM >>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>Jiangyuanlong; josh.rogers@twcable.com >>>Cc: l2vpn@ietf.org >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>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] >>>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 >>> >>>---------------------------------------------------------------------- >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject to >>copyright belonging to Time Warner Cable. This E-mail is intended solely >>for the use of the individual or entity to which it is addressed. If you >>are not the intended recipient of this E-mail, you are hereby notified >>that any dissemination, distribution, copying, or action taken in >>relation to the contents of and attachments to this E-mail is strictly >>prohibited and may be unlawful. If you have received this 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. ------------------------------ Message: 2 Date: Fri, 4 May 2012 20:20:24 -0400 From: Aldrin Isaac To: Lucy yong Cc: "l2vpn@ietf.org" , sajassi Subject: Re: Interest in IS-IS VPLS Message-ID: <03B0FD5F-D9F5-4C4E-A7FD-0A2C36A7B092@gmail.com> Content-Type: text/plain; charset=us-ascii Hi Lucy, Please see inline On May 4, 2012, at 11:07 AM, Lucy yong wrote: > Hi Isaac, > > Thank you for the reply. Please see inline. > > Regards, > Lucy > > -----Original Message----- > From: Aldrin Isaac [mailto:aldrin.isaac@gmail.com] > Sent: Thursday, May 03, 2012 10:50 PM > To: Lucy yong > Cc: sajassi; Giles Heron; Nabil Bitar; l2vpn@ietf.org > Subject: Re: Interest in IS-IS VPLS > ... > E-VPN also supports policy based-topologies versus simple point-to-point, flat or tree VLANs. It can support point-to-point, tree, mesh, one-way, or pretty much any other "complex" or overlapped topologies (depending on how you like to see it). An example is ability to natively recreate private vlan, community vlan topologies (which happen to be quite common in DC networks) and any number of combinations of these simultaneously to a single port. A BGP E-VPN VPN is also decoupled from the edge EVI/ESI such that it is not limited to a single tenant/vlan but can span tenants/vlans (l2 extranet) if so required. This is native to E-VPN. > [[LY]] Such policy based-topologies are useful for service provider network, but may too complex for intra DCs. One reason that customers often want to choose with L2VPN service is "it is simple". However, L3VPN have its applications although some operators often complain the complexities to configure these policies. Typical example is the a firewall only placed at a location. Could you share why operator want such policy based-topology for L2VPN? Policy-based topologies are generally complex when used to interconnect IP networks because there are generally multiple prefixes in a vrf, and often different prefixes need to be associated to different VPNs or routing behavior. In the DC, L2VPN role is to interconnect host ports so the policies for basic are very simple --- list of import route targets and list of export route targets where each import/export pair correspond to a VPN (tenant, service, ...). An example of how a DC operator might use this for example is to meet a requirement for private vlan and community vlans which are very common for DMZs. Hopefully you are familiar with these very common use cases. It is even possible to recreate more complex switch "features" like MVR (in addition to private VLANs which are also considered "features") using E-VPN. It took me three years to get the MVR feature into a particular vendor's switch to meet a business need. I'll sacrifice plug-and-play simplicity for busi ness agility. I'm sure my peers are with me on this one. If simple "plug-and-play" is important, one could imagine RRs sending out an "RR TLV" such that RRs in an IGP area auto-connect with each other and RR-clients connect to the closest RR based on SPF (some details like peer-group, etc would need to be factored in to make it more powerful). Other BGP/MPLS configuration is, IMHO, trivial unless you CHOOSE to use more advanced capabilities (i.e. not locked in). Maybe the reason why MPLS comes across as complex is because of how IETF deals with requirements lately by creating point solutions. E-VPN tries to put new capabilities on the table while trying not to take existing value off the table. There is no reason why a solution can't bring more value than what the standards body calls for. > E-VPN supports interconnecting end-stations or interconnecting L2 networks. Procedures to easily span STP based networks across an E-VPN network without loops comes with the base spec. Extensions to E-VPN, such as PBB-EVPN, simplify the fully functional spanning of non-EVPN networks across an E-VPN network. > [[LY]] current L2VPN support all these except active-active mode which causes the loop. Base E-VPN spec will natively deal with the STP case through an active/standby mode and BPDU-snooping -- detect root bridge and use that as ESI (ethernet segment id) to indicate unique STP network with active/standby bit set to ensure only one forwarding link among links with same ESI. Tags (vlans) can potentially each have a different active link within the member links of an ESI allowing for automatic tag(tenant)/vlan level load-balancing into an STP network. Edge networks that don't have mac-move issue will be able to take full advantage of active-active load-balancing without need for LAG/MLAG. > An SVI/IRB interface can also be a member of both an E-VPN EVI and an IP VRF allowing for easily bringing together virtual L2 and L3 topologies anywhere in the network without a physical port. > [[LY]] Could you please share how operator plan to use this? Which service will you sell to customer in this case? The service will be where a customer wants to communicate to a destination network that is not in his subnet. Operators most interested in EVPN already have IPVPN services on their network. This is the gateway point between the EVPN virtual networks and [existing] IPVPN virtual networks. No physical port required. > E-VPN builds on top of years of work in the IETF; traffic engineering, scaling with route reflectors and RT constrain, multicast via NG-MVPN, etc. > [[LY]] Agree. These are useful features for service provider network. However, these functions may not necessary within DC although they had been proved works well. I'm not sure how eventually re-inventing these capabilities (yes it will happen) on behalf of a new protocol will be better than simply leveraging proven technology. Vendors don't need to implement every MPLS RFC ever written to be able to implement the basic E-VPN. > Can also use IP for transport tunnel. But my understanding is that popular merchant silicon has support for MPLS push/pop/swap these days (?). This was captured by EVPN at it's inception, which is why the PE is referred to as MES (MPLS-enabled switch) in E-VPN. > [[LY]] Yes, current draft aims on MPLS solution only. But it states the potential to extend to the use of IP tunnel. > The way I see it, a major reason why STP-based LANS are fickle and don't scale well is on account of insufficient decoupling of core from edge created by requirement for plug-and-play and how that played out over time. Conversely the reason (among other things) why IP networks are more stable is because they are not inherently plug-and-play, and with MPLS/BGP allows excellent decoupling of core and edge. I don't know enough about TRILL or PBB to comment on those -- I just know that I'm not interested for enough good reasons. E-VPN enables a dynamic edge over a stable decoupled core while giving each operator room for service differentiation. It is especially interesting to operators that have invested in MPLS technology and operations. I can find a lot of folks that understand BGP/MPLS IPVPN and in short order have them know the ins and outs of basic E-VPN. It's quite hard for me to find non-vendor folk who really actually understand the other technologies used to spa n Ethernet aside from basic STP. > [[LY]] Thank you to share this in the mailing list. > > This is an operator perspective. > [[LY]] This is great! > > > On May 3, 2012, at 4:31 PM, Lucy yong wrote: > >> Hi Ali, >> >> >> "5. Ethernet VPN (E-VPN) - An enhanced Layer-2 service that >> emulates an Ethernet (V)LAN across a PSN. E-VPN supports >> load-sharing across multiple connections from a Layer-2 site >> to an L2VPN service. E-VPN is primarily targeted to support >> large-scale L2VPNs with resiliency requirements not satisfied >> by other L2VPN solutions" >> >> [[LY]] IMO, E-VPN enhancement is to support multi-homing with active-active mode. Load-sharing across multiple connections from a layer-2 site is desired when this mode is used. Current VPLS can provide resiliency requirement when the multi-homing site configured with active-standby mode. >> >> Regards, >> Lucy >> >> Cheers, >> Ali >> > ------------------------------ _______________________________________________ L2vpn mailing list L2vpn@ietf.org https://www.ietf.org/mailman/listinfo/l2vpn End of L2vpn Digest, Vol 96, Issue 18 ************************************* From lizho.jin@gmail.com Sun May 6 03:22: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 013DA21F84A7 for ; Sun, 6 May 2012 03:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.38 X-Spam-Level: X-Spam-Status: No, score=-3.38 tagged_above=-999 required=5 tests=[AWL=0.218, 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 MWSyLglfTCxb for ; Sun, 6 May 2012 03:22:15 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 975CB21F84A0 for ; Sun, 6 May 2012 03:22:15 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so7922782obb.31 for ; Sun, 06 May 2012 03:22:15 -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=eOMwzX/8sUeWO+WZR3o4y9kTU9OAvw2kA0lbl9v1v18=; b=XI6mmT+7ymz8pexEBsMl54z2U0XZ/kusPeSOH4WTvpynfTdKosLjvUCoFH3NktcXKv jDHR+/z5zk/GyEATQJHSWRXCnPnndBOwRtbGpcFFgwPzaROidnqBj4O0HsqX4JHQ0S/O sB6WCA9TbPIeqYbb9m4STlevwID8+79/k8G/r+y63/7paKOgGKizzb/O7UV1JPOiPUAp AQkR8YbPtOxfw5rAP2rh2JYq6dC3rx6ONgHyjgdyot0TRf4YEN6d1l4RQ4Wlg0ddANPf dp8jOtIuryJDUOTS/iINOnequTJzGJ7S2/rf5W4/JUp1qXmKPXAgKAFVHIzh66WMHPkc vY+Q== MIME-Version: 1.0 Received: by 10.50.17.134 with SMTP id o6mr6357740igd.28.1336299734939; Sun, 06 May 2012 03:22:14 -0700 (PDT) Received: by 10.50.8.100 with HTTP; Sun, 6 May 2012 03:22:14 -0700 (PDT) Date: Sun, 6 May 2012 18:22:14 +0800 Message-ID: Subject: RE: Discussion on E-Tree and H-VPLS From: Lizhong Jin To: yuqun.cao@gmail.com Content-Type: multipart/alternative; boundary=14dae934049903b87504bf5b8764 Cc: l2vpn@ietf.org, jiangyuanlong@huawei.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, 06 May 2012 10:22:17 -0000 --14dae934049903b87504bf5b8764 Content-Type: text/plain; charset=ISO-8859-1 Hi Sam, See inline below. Thanks Lizhong ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 24 Apr 2012 11:51:26 +0800 > From: "Sam Cao" > To: "'Jiangyuanlong'" > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > Message-ID: > Content-Type: text/plain; charset="GB2312" > > 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. > [Lizhong] agree with the above analysis. And we did not say it is a technical problem, but it is an operational problem again. > > 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. > [Lizhong] not fully understand. Do you mean, when VPWS accessing for H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf PW) for each AC access? > 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 > > > > --14dae934049903b87504bf5b8764 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Sam,
See inline below.

Thanks
Lizhong

----------------------------------------------------------------------
<= br>Message: 1
Date: Tue, 24 Apr 2012 11:51:26 +0800
From: "Sam Cao" <yuqun.cao@gmail.com>
To: "'Jiangyuanlong'= ;" <j= iangyuanlong@huawei.com>
Cc: l2vpn@ietf.org<= br> Subject: RE: Discussion on E-Tree and H-VPLS
Message-ID: <DDFE90371E3= C40D988E43EB0DA2FCB78@R01842>
Content-Type: text/plain; =A0 =A0 =A0 c= harset=3D"GB2312"

Yuanlong,

Ok. Go on H-VPLS discus= sion 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 La= yer 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 networ= k. We
can hold the opposite opinions, but this is really requirements fr= om
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
b= etween PE-r AND PE1-rs) Root or Leaf. As you know, we can not appoint onPE-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 app= oint
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= . This
is my question: For VPWS access, we should configure Root/Leaf fo= r Spoke PW;
for VPLS access, we CAN NOT configure Root/Leaf for Spoke PW.
[Lizhong] agree with the above analysis. And we did not say it is a= technical problem, but it is an operational problem again.

Multi-PW has no problem on this: Configure Root or Leaf on PE1-rs in th= e 2
cases since it uses different PATH, not inferring context in frame.<= br>
[Lizhong] not fully understand. Do you mean, =A0when V= PWS accessing for H-VPLS, the PE-r is also necessary to configure two PWs (= root and leaf PW) for each AC access?


Thanks,

Sam

-----Original Message-----
From: Jiangyuanlong= [mailto:jian= gyuanlong@huawei.com]
Sent: Monday, April 23, 2012 7:23 PM
To: Sa= m Cao
Cc: l2vpn@ietf.org<= br> Subject: Discussion on E-Tree and H-VPLS

Sam,

Please see my c= omments in line. I also change the title to reflect the
topic.

Re= gards
Yuanlong

-----Original Message-----
From: Sam Cao [mailt= o: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 rea= lly
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? =A0At least it is correct = in
RFC 4762.
[JY] why divide the remote access to VPWS access and VPL= S access?

But, if remote is VPWS access (Fig. 3), PE-rs SHOULD confi= gure 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 a= nother
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 b= ridging
functions. I think this case is provided in RFC4762 just to be compatiblewith some legacy routers.


Ok, problem came up for me. For spok= e 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<= br>is enough; why spoke-PW has different configuration in same VPLS instanc= e on
same PE? I am confused although I know why we should configure in t= hat way.

I prefer not to configure AC type on PE-rs since we can take it as
&= quot;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
i= tself.

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: L2vp= n Digest, Vol 95, Issue 58

Hi Sam,

If E-Tree service is provi= ded 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 theMTU-s or PE-r. I don't quite understand why you need to "take VP= WS 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
Yuanlo= ng

Date: Sun, 22 Apr 2012 22:03:52 +0800
From: "Sam Cao"= ; <yuqun.cao@gm= ail.com>
To: "'Jiangyuanlong'" <jiangyuanlong@huawei.com>
Cc: l2vpn@ietf.org
Subje= ct: RE: The status of the approaches to the E-Tree solution?
Message-ID: <962A848896EF4678B17D76C826A7EAEF@v2comsam>
Content-Ty= pe: text/plain; =A0 =A0 =A0 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 itemsover 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 firs= t 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 unde= rstand 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) = =A0Encapsulation 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 mo= de works.

Regards,

Yuqun (Sam) Cao
E-mail: Yuqun.cao@gmail.com


--14dae934049903b87504bf5b8764-- From lizho.jin@gmail.com Sun May 6 03:26: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 6032721F84B6 for ; Sun, 6 May 2012 03:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.407 X-Spam-Level: X-Spam-Status: No, score=-3.407 tagged_above=-999 required=5 tests=[AWL=0.191, 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 U8nokOtmg8wF for ; Sun, 6 May 2012 03:25:59 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D164B21F84AA for ; Sun, 6 May 2012 03:25:59 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so7927450obb.31 for ; Sun, 06 May 2012 03:25:59 -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=JlURAXvQ9p3+GDajyZCTmJXpLsQV3kU5oKEBnhfvSxM=; b=u3woKivkoAAFkvJEOatKb9vJ/y1xZ6c0WPZdD5bfyAs/SB7XR8X2MmaRvTaarfLxUc +0QFCVJnntBvOs0zKy1Bgup8/UhDAibDWqLnrPu/nJczPO3BXyS/0urRNAsUyW7U8MQm nqBcKVndJAUPABO8+ZYbdSASnhuN6Hc93oY6qBoone05K0QXOIJu4nx387kxpjiHi9Dz K+cJN18vwGoBpmFf8440d1pyP11uIRgxrBNTMqPdoNu7rTfHav/XdcOC5LUplGnAbF2n XKnbZ9+eATx5wRomCnmWDGwcbhokdvkaADq8UOzF9QDjAnotd97q5k7VnWLBCkqaaEZY oAUA== MIME-Version: 1.0 Received: by 10.42.159.9 with SMTP id j9mr3735367icx.5.1336299959194; Sun, 06 May 2012 03:25:59 -0700 (PDT) Received: by 10.50.8.100 with HTTP; Sun, 6 May 2012 03:25:59 -0700 (PDT) Date: Sun, 6 May 2012 18:25:59 +0800 Message-ID: Subject: RE: Discussion on E-Tree and H-VPLS From: Lizhong Jin To: yuqun.cao@gmail.com Content-Type: multipart/alternative; boundary=90e6ba6e842c61926504bf5b945a Cc: l2vpn@ietf.org, jiangyuanlong@huawei.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, 06 May 2012 10:26:00 -0000 --90e6ba6e842c61926504bf5b945a Content-Type: text/plain; charset=ISO-8859-1 > > > ------------------------------ > > Date: Tue, 24 Apr 2012 11:59:33 +0800 > From: "Sam Cao" > To: "'Alexander Vainshtein'" , > "'Jiangyuanlong'" > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > Message-ID: > Content-Type: text/plain; charset="GB2312" > > 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. > [Lizhong] no, the CW approach is OK. The PE-r with VPWS could support CW, and add leaf/root indication in the packet. Thanks Lizhong > 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, > > ------------------------------ --90e6ba6e842c61926504bf5b945a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

------------------------------

Date: Tue, 24 Apr 2012 11:59:33 +0800
From: "Sam Cao" <yuqun.= cao@gmail.com>
To: "'Alexander Vainshtein'" <Alexander.Vainshtein@ecitele.com>,
=A0 =A0 =A0 =A0"'Jiangyuanlong'" <jiangyuanlong@huawei.com>
Cc: l2vpn@ietf.org
Subject: RE: Discussion on E-Tree and H-VPLS
Message-ID: <F2158A3367414E3E82DE340F17186FE7@R01842>
Content-Type: text/plain; =A0 =A0 =A0 charset=3D"GB2312"

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.
[Lizhong= ] =A0no, the CW approach is OK. The PE-r with VPWS could support CW, and ad= d leaf/root indication in the packet.

Thanks
Lizhong


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,

------------------------------
--90e6ba6e842c61926504bf5b945a-- From jiangyuanlong@huawei.com Sun May 6 19:09: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 D56FA21F854A for ; Sun, 6 May 2012 19:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.168 X-Spam-Level: X-Spam-Status: No, score=-2.168 tagged_above=-999 required=5 tests=[AWL=-0.169, 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 uB5AbWHluaJx for ; Sun, 6 May 2012 19:09:58 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1253121F84D5 for ; Sun, 6 May 2012 19:09:58 -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 AFW61566; Sun, 06 May 2012 22:09:57 -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; Sun, 6 May 2012 19:07:11 -0700 Received: from SZXEML432-HUB.china.huawei.com (10.72.61.60) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 6 May 2012 19:07:12 -0700 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.183]) by SZXEML432-HUB.china.huawei.com ([10.72.61.60]) with mapi id 14.01.0323.003; Mon, 7 May 2012 10:07:01 +0800 From: Jiangyuanlong To: "Rogers, Josh" , Daniel Cohn , "Fedyk, Donald (Don)" , "Henderickx, Wim (Wim)" , 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: AQHNI1NEA18PKDoBDEy6zAcXiVu2LpasuNMAgAYGiYCAAAzygIAAAjQAgAAAAYCAAASFAIAAAOoAgAAYGACAAAPTgIACzjKAgABsbmCAABSDMIAAJEvQgADhaeD//53EgIAAk10ggAA/vACAASTWUIAAOyKAgAR+CPA= Date: Mon, 7 May 2012 02:07:00 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D4106B5@szxeml546-mbx.china.huawei.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA560F0@SZXEML508-MBX.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.40.73] Content-Type: text/plain; charset="iso-8859-2" 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, 07 May 2012 02:10:00 -0000 Could you or any other co-authors of 2PW give some more hints so that it ca= n be better understood?=20 In draft-ram-l2vpn-etree-multiple-pw-01, I can only find a single sentence = most to the point: "An egress PE SHALL NOT deliver a frame originated at a leaf AC to another leaf AC." But it seems there is not a description of "traffic is split/separated (by = psuedowire) on the ingress PE" at all. On the contrary, in draft-jiang-l2vpn-vpls-pe-etree-05, Section 5.3.3 detai= ls the scenario and forwarding plane how the leaf traffic is seperated and = filtered on the ingress PE, and Section 6 details the specific supports in = the control plane. Thanks Yuanlong -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com]=20 Sent: Friday, May 04, 2012 8:27 PM To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim);= Lucy yong Cc: l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? [JY2] if the egress PE is attached with pure leafs, 2VLAN approach can also separate the leaf traffic in the ingress PE and filter it there (already detailed in the Optimization Mode in the I-D); if the egress PE is attached with pure roots or with both roots and leafs, it seems all traffic must be transported to the egress PE and be filtered there, I see no difference in behaviour for these solutions. Or did I miss something? The point is with the multi-PW method the traffic is split/separated (by psuedowire) on the ingress PE, rather than the egress. The distinction is 2VLAN will 'classify' the frame on the ingress PE, so that the egress PE knows how to forward it to the appropriate AC's. Both methods have inefficiencies (one duplicates traffic for transport, while the other transports where it doesn't need to go). I like the idea of classify and forwarding on the ingress PE, rather than marking it on the ingress, and deciding on the egress. -Josh On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: >Josh, thank you for the comments, please see my further comments with >[JY2]. > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Thursday, May 03, 2012 11:27 PM >To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >(Wim); Lucy yong >Cc: l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >requirements from MEF, it has nothing to do with the solutions. Could you >give a hint on how you can provision this service E-NNI otherwise? BTW, if >configuring or signalling two PWs is not a problem, why configuring or >signalling two VLANs will become a problem? After all, more nodes may need >to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >2VLAN (only T-PEs). > > >There is no other way (if both MPLS domains are part of the same ETREE, >rather than doing something more like H-VPLS, where one domain has point >to points to the other domain which handles the ETREE instance) if you are >using an ENNI. The other method, (not mentioned earlier) is tying the two >MPLS domains together via labeled unicast (much preferred over E-NNI in my >opinion) > >Configuring two VLAN's isn't really a 'problem' any more than two PW's. I >wasn't saying that configuring two VLAN's was difficult, I was objecting >to the statement that configuring two PW's is difficult. > >[JY2] Thanks, I see your point. I take the example of 2PW configuration >just to show that using fixed global values to simplify configuration >makes no sense. Personally I also don't think configuration is a problem >for both solutions. > >I find the differences between these two methods rather slight. The >'tie-breaker' for me is by placing the forwarding decision on the ingress >PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >more control over where the traffic goes, and in my mind it provides a >cleaner destination between customer traffic and forwarding plane. I'm >accustomed to looking at a psuedowire and knowing where its going, with >the 2vlan method, I can see the psuedowire, but must go to the egress PE >to see if it will be dropped there, or forwarded to one or more AC's. > >[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >also separate the leaf traffic in the ingress PE and filter it there >(already detailed in the Optimization Mode in the I-D); if the egress PE >is attached with pure roots or with both roots and leafs, it seems all >traffic must be transported to the egress PE and be filtered there, I see >no difference in behaviour for these solutions. Or did I miss something? > >Again, the difference here is slight, and I would honestly be happy to see >either of them come to fruition. Please don't infer that I think the >2vlan method is 'bad' or has intrinsic problems, because I don't believe >that. I just prefer the multi-PW method. > > >-Josh > > >On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: > >>Josh, please see my comments in line. >> >>Thanks >>Yuanlong >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Thursday, May 03, 2012 10:51 AM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>Yuanlong, >> >>Or better yet, include in the draft a 'standard' value for root sourced >>VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You would als= o >>have to require the the implementation NOT use global VLAN's, however >>(since each instance would be using the same values). In this way, no >>signaling or manual configuration is required for remote PE's to know how >>to classify traffic. >>[JY] Indeed, we discussed this possibility during the f2f meeting in >>Paris. But, there are some restrictions as you mentioned, and >>furthermore: >>1) Some vendors already used S-VLAN to distinguish their VSIs in the PE; >>2) Forwarding plane of a PE needs to be revised to be aware of this VLAN >>ID. >>Therefore, this 'standard value' approach seems more disruptive compared >>with the other means and not a good candidate option. >> >>Regarding switching PE's=A9 Multi-PW means more than one PW, yes. I don= 't >>see this as a real problem. In general, design should try and avoid >>using >>S-PE's, but if you must, its going to mean extra work, no matter how you >>look at it. Two PW's for each Etree being switched instead of one is not >>alarming or concerning to me. On the other hand, if you use a dot1q >>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's an >>two egress VLAN's if you want the Etree to be handled on both sides (and >>if you use the 'standard' VID's as I mentioned above, you'd have to do >>mapping to non-standard and back) >>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>requirements from MEF, it has nothing to do with the solutions. Could you >>give a hint on how you can provision this service E-NNI otherwise? BTW, >>if configuring or signalling two PWs is not a problem, why configuring or >>signalling two VLANs will become a problem? After all, more nodes may >>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>with 2VLAN (only T-PEs). >> >>In general, I still prefer multi-PW, primarily because I prefer the >>separation of the traffic in the network's forwarding plane, rather than >>shipping it everywhere and deciding whether to forward to the AC when it >>gets to the egress PE. I'm having a hard time putting my finger exactly >>on what it is, or articulating the idea, but it seems that by having the >>traffic placed into two psuedowires, I have more flexibility and ease of >>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>PW's could really change that perception. >>[JY] Are you saying that we need to develop a totally new forwarding >>plane rather than using the Ethernet forwarding plane as described in the >>existing work? >> >>I hope we can move forward with one of these soon, >>[JY] me too. >> >>Josh >> >> >>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >> >>>Daniel, >>> >>>Not aware that we had a discussion on this before, but IMHO the >>>allocation of internal S-VLAN can be automatic, and manuel configuration >>>of this mapping may not be needed at all. For example, an S-VLAN >>>allocation module in the management plane in a PE can do this kind of >>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>way from a free S-VLAN ID pool. Once the interal S-VLANs are allocated, >>>the mapping is determined and no other configuration is needed. >>> >>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>allocate >>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to allocate >>>two S-VLANs in the VPLS domain. >>> >>>On the other hand, for the multi-PW approach, two PWs need to be >>>configured for a E-Tree service. When MS-PW is used in the network, for >>>every S-PE, we need to configure two ingress PW segments and two egress >>>PW segments. In this case, I don't think we need to use fixed PW labels >>>across the network for fear of configuration complexity. >>> >>>Regards, >>>Yuanlong >>> >>>-----Original Message----- >>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>Sent: Wednesday, May 02, 2012 8:01 PM >>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>yong; >>>josh.rogers@twcable.com >>>Cc: l2vpn@ietf.org >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Inline. >>> >>>-----Original Message----- >>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>Sent: Wednesday, May 02, 2012 12:30 PM >>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>josh.rogers@twcable.com >>>Cc: l2vpn@ietf.org >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Hi Daniel, Please see my comments in line. >>> >>> >>>-----Original Message----- >>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>Sent: Wednesday, May 02, 2012 3:55 PM >>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>yong; josh.rogers@twcable.com >>>Cc: l2vpn@ietf.org >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Hi Yuanlong, >>> >>>The problem is not with the total number of S-VLAN IDs, I agree that >>>normally there won't be more than 2047. The problem is that if you don't >>>support all VLAN IDs, you need S-VLAN space coordination with the >>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to 2047". >>>Which won't always be in line with an existing deployment. >>>[JY] This is not the case. If the total number is no more than 2047, it >>>surely can be supported. The S-VLAN space of user domain is totally >>>different from the S-VLAN in the provider domain and they can be >>>overlapped, I don't see why we need S-VLAN space coordination between >>>them. >>> >>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>fixed, and therefore the IEEE S-VID that can be supported is also fixed. >>> >>>Of course you can configure the mapping in each PE according to operator >>>requirements but as we discussed before this increases complexity. >>> >>>Relying on PBB-VPLS imposes additional limitations on backward >>>compatibility. >>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>think they may well need MAC-in-MAC in their networks for the >>>scalability issue. As you know, only PBB VPLS can provide both. >>> >>>Daniel >>> >>>-----Original Message----- >>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>Sent: Wednesday, May 02, 2012 5:07 AM >>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>josh.rogers@twcable.com >>>Cc: l2vpn@ietf.org >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Hi Daniel, >>> >>>As you can see, both cases are discussed in the I-D. >>> >>>With regard to case 1) (that is, S-VLAN translation), since the access >>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>they need to be configured on a PE anyway, and as the past emails by >>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>mapping. >>> >>>With regard to S-VID space reduction, the constraint is valid only when >>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>typical and with no such limits as we already discussed in the f2f >>>meeting. >>> >>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>described (not sure this is a valid use case in real life), PBB-VPLS can >>>still be used. >>> >>>Regards, >>>Yuanlong >>> >>>-----Original Message----- >>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>Sent: Monday, April 30, 2012 10:34 PM >>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>Jiangyuanlong; josh.rogers@twcable.com >>>Cc: l2vpn@ietf.org >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>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] >>>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 >>> >>>---------------------------------------------------------------------- >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject to >>copyright belonging to Time Warner Cable. This E-mail is intended solely >>for the use of the individual or entity to which it is addressed. If you >>are not the intended recipient of this E-mail, you are hereby notified >>that any dissemination, distribution, copying, or action taken in >>relation to the contents of and attachments to this E-mail is strictly >>prohibited and may be unlawful. If you have received this 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 jiangyuanlong@huawei.com Sun May 6 21:03: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 B86CC21F84AA for ; Sun, 6 May 2012 21:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.138, 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 TzWT7QoBMOO9 for ; Sun, 6 May 2012 21:02:59 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id E8D5921F8468 for ; Sun, 6 May 2012 21:02:58 -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 AFW67590; Mon, 07 May 2012 00:02:58 -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; Sun, 6 May 2012 20:59:18 -0700 Received: from SZXEML431-HUB.china.huawei.com (10.72.61.39) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 6 May 2012 20:59:17 -0700 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.183]) by szxeml431-hub.china.huawei.com ([10.72.61.39]) with mapi id 14.01.0323.003; Mon, 7 May 2012 11:59:06 +0800 From: Jiangyuanlong To: Sam Cao , "l2vpn@ietf.org" Subject: Comparisons of Multi-PW and Dual-VLAN Thread-Topic: Comparisons of Multi-PW and Dual-VLAN Thread-Index: AQHNLAW/f1uy11Y42EGjttBEb/uKSQ== Date: Mon, 7 May 2012 03:59:06 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D4106FE@szxeml546-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.70.40.73] 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, 07 May 2012 04:03:00 -0000 Sam, please see my comments in line. I changed the Subject to reflect the t= opic. Regards Yuanlong -----Original Message----- From: Sam Cao [mailto:yuqun.cao@gmail.com]=20 Sent: Saturday, May 05, 2012 10:09 AM To: l2vpn@ietf.org Cc: Lucy yong; 'Rogers, Josh'; Jiangyuanlong; 'Alexander Vainshtein'; 'Dani= el Cohn' Subject: RE: L2vpn Digest, Vol 96, Issue 15 Lucy/Yuanlong, I agree that we can not say which approach is better simply, but I really agree with Josh's comments. Multi-PW is easy to implement E-Tree. First of all, we discussed 2 approaches for a long time and many rounds, an= d for me, there are no pending issues on Multi-PW till now or co-authors of multi-PW have given reasonable reply to L2VPN members' questions, but there are still pending issues for Dual-VLAN. Please trace the mailing list. [JY] Do you have any solution for the PW OAM issue? It was raised in the IE= TF 83rd meeting and included in the minutes. Second, Sasha has his concern in NP, or forwarding performance. Compared to current VPLS, Multi-PW has a little effect on forwarding performance since it reuse PW label as AC indicator; Dual-VLAN will have higher side effect o= n forwarding performance because it SHOULD use additional indicator. Is there one prototype for Dual-VLAN? BTW, there is no reply on chip limit. [JY] During the exchange of emails, it turned out that CW or 2PW based appr= oach is highly dependent on the specific implementation of devices. I faile= d to understand your assumption that "Multi-PW has a little effect on forwa= rding performance since it reuse PW label as AC indicator; Dual-VLAN will h= ave higher side effect on forwarding performance because it SHOULD use addi= tional indicator." Are you referring to the Ethernet forwarding plane of a = VSI or something else? Otherwise, what the side effect of VLAN to Ethernet = forwarding plane? What you mean by chip limit? BTW, I think not only a prot= otype, but also field deployments is the goal of a valid solution. Third, the difference between Multi-PW and dual-VLAN is, transport ingress traffic in one "LSP" or 2 "LSP". Multi-PW classifies and transforms ingress traffic into right "path", and egress just pop-out PW label and forward the frame to ACs. Dual-VLAN has more work on ingress PE or egress PE.=20 [JY] Interesting. Setting up 2 PWs between a pair of PEs does not guarantee= these PWs are tunnelled in separate LSPs. BTW, 2 LSPs or 2 PWs will pose g= reater challenge to the E-Tree OAMs, so I will rather consider it a disadva= ntage. Moreover, with regard to the new work on E-Tree, 2PW needs: 1. An extra layer of abstraction is needed for E-Tree PWs, i.e., a logical = bridge interface is introduced on the VSI for 2 PWs, let us assume, PW-R fo= r root traffic and PW-L for leaf traffic, and the logical bridge interface = is called LBI. Thus: MAC learning and forwarding will be performed over AC, PW and LBI in parall= el in a VSI. Broadcasting or multicasting over LBI and then over both PW-R and PW-L must= be provided. 2. Mapping of AC's E-Tree attribute <--> VSI internal R/L bit <--> PW-R/PW-= L, and the R/L bit needs to be internally coded. 3. Split horizon must be applied over AC groups, PW groups, and PW + LBI gr= oups, thus we will introduce more complexity in configuration of split hori= zon groups. Is this really simpler compared with 2VLAN (after all, the latter only need= s to add or translate a VLAN)? Fourth, maybe Giles has figured this out, Dual-VLAN has capacity limit. Onl= y 4094 VLAN ID are available, so only 2K E-Tree instances can be supported on one PE for Dual-VLAN approach. There is no such limit for Multi-PW approach= , [JY] That is the case only when a global VLAN space is used. In IEEE, the s= ame discussions also happened before. But with VLAN translation and multipl= e VLAN spaces, Dual-VLAN approach is quite scalable, thus it was adopted in= IEEE. Finally, in this thread we don't make agreement on VLAN ID allocation. We also have questions on VLAN ID negotiation among PEs (signaling protocol). Yuanlong wishes to update, but there is no update till now. [JY] I don't think this WG has any agreements on any E-Tree solution yet... For me, why IEEE uses VLAN ID to identify AC type? IEEE has no LABEL :), an= d it has label, it also wish to use label to identify AC types. I think that both solutions need much time to be perfect. Mutli-PW has less extension work to do. But now we are focusing on technical details and can not move forward :). =20 [JY] I see no reason to associate a PW with a AC in VPLS (unlike VPWS, for = VPLS, there are VSI modules which still work like a bridge module, and ther= e even may be multiple bridge modules in a PE), and PW label only applies o= n the Pseudo-wire layer facing the core side.=20 I agree with you that both solutions need time to be perfect, but at this s= tage, 2VLAN is more mature both in data plane and control plane. The compar= ison is meaningful only when they are at the same level of maturity. =20 Thanks, Sam From josh.rogers@twcable.com Sun May 6 21:09: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 439D621F84B4 for ; Sun, 6 May 2012 21:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.438 X-Spam-Level: X-Spam-Status: No, score=-0.438 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 2B9Od-CuqyyR for ; Sun, 6 May 2012 21:09:11 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id EAFD821F84AA for ; Sun, 6 May 2012 21:09:10 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.75,540,1330923600"; d="scan'208";a="377384681" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 07 May 2012 00:08:39 -0400 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.36]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Mon, 7 May 2012 00:09:09 -0400 From: "Rogers, Josh" To: Jiangyuanlong , Daniel Cohn , "Fedyk, Donald (Don)" , "Henderickx, Wim (Wim)" , Lucy yong Date: Mon, 7 May 2012 00:09: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: Ac0sBya8BEsrdPEHTkKFl4pixaTrrQ== Message-ID: In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D4106B5@szxeml546-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" 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, 07 May 2012 04:09:13 -0000 So, if you can imagine three PE's, PE1, PE2 and PE3. PE1 has a root AC, R1 and a leaf AC, L1. PE2 also has a root AC, R2, and a leaf AC, L2. PE3 has a leaf AC, L3. Consider an unknown unicast frame from the leaf site L1, and also another unknown unicast frame from R1 entering. With the 2VLAN method (to my best understanding): - frame from L1 enters PE1, goes into a PW to PE2 and a PW to PE3, arrives at PE2 which decides that it should be flooded out all Root AC's, based on the S-tag. It also arrives at PE3, where it is dropped because there are no root AC's. - frame from R1 enters PE1, goes into a PW to PE2 and a PW to PE3, arrives at PE2 which decides that it should be flooded out all AC's, based on S-tag. It also arrives at PE3 where it is forwarded to all root AC's. With Multi-PW method: - frame from L1 enters PE1, which decides to forward the frame out the 'root' PW to PE2, which in turn floods out all Root AC's, based on arriving PW type. Frame is NOT sent to PE3, since there is no PW built to the PE which has no root AC's. - frame from R1 enters PE1, which decides to flood out both 'root' PW and 'leaf' PW to PE2, which in turn floods out the same AC types, based on arriving PW type. It also arrives at PE3 where it is forwarded to all root AC's. I suppose optimization could be done on the ingress PE to decide that there is no need to 'flood' root-sourced frames to two PW's that have the same egress PE, but instead to only forward to the 'root' type PW, when both exist, because we know that the egress PE will flood frames from root-sourced PW's out both leaf and root AC's. In this example, the same frame from R1 is duplicated on the PE1-PE2 path (if no optimization is done.), where it would not be with the 2VLAN method. With 2VLAN, ethernet type PW's cannot be used (must be vlan type PW's, otherwise how would we classify source AC-type?), which means there is overhead on EVERY frame to add the s-tag for the sole purpose of classifying the frame. If optimization is done, then each ingress PE knows what types of AC's are on each egress PE, and only forwards the appropriate frame, if no optimization then it is dropped at the egress PE. In short, both are either not 100% inefficient, or are additionally complex due to 'optimization'. I may have gotten my details off on the optimization piece of the 2VLAN method, please correct me if I didn't get the details 100% correct. -Josh On 5/6/12 9:07 PM, "Jiangyuanlong" wrote: >Could you or any other co-authors of 2PW give some more hints so that it >can be better understood? > >In draft-ram-l2vpn-etree-multiple-pw-01, I can only find a single >sentence most to the point: > "An egress PE SHALL NOT deliver a frame originated at a leaf AC to > another leaf AC." > >But it seems there is not a description of "traffic is split/separated >(by psuedowire) on the ingress PE" at all. > >On the contrary, in draft-jiang-l2vpn-vpls-pe-etree-05, Section 5.3.3 >details the scenario and forwarding plane how the leaf traffic is >seperated and filtered on the ingress PE, and Section 6 details the >specific supports in the control plane. > >Thanks >Yuanlong > > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Friday, May 04, 2012 8:27 PM >To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >(Wim); Lucy yong >Cc: l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >also separate the leaf traffic in the ingress PE and filter it there >(already detailed in the Optimization Mode in the I-D); if the egress PE >is attached with pure roots or with both roots and leafs, it seems all >traffic must be transported to the egress PE and be filtered there, I see >no difference in behaviour for these solutions. Or did I miss something? > > >The point is with the multi-PW method the traffic is split/separated (by >psuedowire) on the ingress PE, rather than the egress. The distinction is >2VLAN will 'classify' the frame on the ingress PE, so that the egress PE >knows how to forward it to the appropriate AC's. > >Both methods have inefficiencies (one duplicates traffic for transport, >while the other transports where it doesn't need to go). I like the idea >of classify and forwarding on the ingress PE, rather than marking it on >the ingress, and deciding on the egress. > >-Josh > > > >On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: > >>Josh, thank you for the comments, please see my further comments with >>[JY2]. >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Thursday, May 03, 2012 11:27 PM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>requirements from MEF, it has nothing to do with the solutions. Could you >>give a hint on how you can provision this service E-NNI otherwise? BTW, >>if >>configuring or signalling two PWs is not a problem, why configuring or >>signalling two VLANs will become a problem? After all, more nodes may >>need >>to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >>2VLAN (only T-PEs). >> >> >>There is no other way (if both MPLS domains are part of the same ETREE, >>rather than doing something more like H-VPLS, where one domain has point >>to points to the other domain which handles the ETREE instance) if you >>are >>using an ENNI. The other method, (not mentioned earlier) is tying the >>two >>MPLS domains together via labeled unicast (much preferred over E-NNI in >>my >>opinion) >> >>Configuring two VLAN's isn't really a 'problem' any more than two PW's. >>I >>wasn't saying that configuring two VLAN's was difficult, I was objecting >>to the statement that configuring two PW's is difficult. >> >>[JY2] Thanks, I see your point. I take the example of 2PW configuration >>just to show that using fixed global values to simplify configuration >>makes no sense. Personally I also don't think configuration is a problem >>for both solutions. >> >>I find the differences between these two methods rather slight. The >>'tie-breaker' for me is by placing the forwarding decision on the ingress >>PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >>more control over where the traffic goes, and in my mind it provides a >>cleaner destination between customer traffic and forwarding plane. I'm >>accustomed to looking at a psuedowire and knowing where its going, with >>the 2vlan method, I can see the psuedowire, but must go to the egress PE >>to see if it will be dropped there, or forwarded to one or more AC's. >> >>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>also separate the leaf traffic in the ingress PE and filter it there >>(already detailed in the Optimization Mode in the I-D); if the egress PE >>is attached with pure roots or with both roots and leafs, it seems all >>traffic must be transported to the egress PE and be filtered there, I see >>no difference in behaviour for these solutions. Or did I miss something? >> >>Again, the difference here is slight, and I would honestly be happy to >>see >>either of them come to fruition. Please don't infer that I think the >>2vlan method is 'bad' or has intrinsic problems, because I don't believe >>that. I just prefer the multi-PW method. >> >> >>-Josh >> >> >>On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: >> >>>Josh, please see my comments in line. >>> >>>Thanks >>>Yuanlong >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Thursday, May 03, 2012 10:51 AM >>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>(Wim); Lucy yong >>>Cc: l2vpn@ietf.org >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Yuanlong, >>> >>>Or better yet, include in the draft a 'standard' value for root sourced >>>VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You would al= so >>>have to require the the implementation NOT use global VLAN's, however >>>(since each instance would be using the same values). In this way, no >>>signaling or manual configuration is required for remote PE's to know >>>how >>>to classify traffic. >>>[JY] Indeed, we discussed this possibility during the f2f meeting in >>>Paris. But, there are some restrictions as you mentioned, and >>>furthermore: >>>1) Some vendors already used S-VLAN to distinguish their VSIs in the PE; >>>2) Forwarding plane of a PE needs to be revised to be aware of this VLAN >>>ID. >>>Therefore, this 'standard value' approach seems more disruptive compared >>>with the other means and not a good candidate option. >>> >>>Regarding switching PE's=A9 Multi-PW means more than one PW, yes. I >>>don't >>>see this as a real problem. In general, design should try and avoid >>>using >>>S-PE's, but if you must, its going to mean extra work, no matter how you >>>look at it. Two PW's for each Etree being switched instead of one is >>>not >>>alarming or concerning to me. On the other hand, if you use a dot1q >>>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's >>>an >>>two egress VLAN's if you want the Etree to be handled on both sides (and >>>if you use the 'standard' VID's as I mentioned above, you'd have to do >>>mapping to non-standard and back) >>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>requirements from MEF, it has nothing to do with the solutions. Could >>>you >>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>if configuring or signalling two PWs is not a problem, why configuring >>>or >>>signalling two VLANs will become a problem? After all, more nodes may >>>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>>with 2VLAN (only T-PEs). >>> >>>In general, I still prefer multi-PW, primarily because I prefer the >>>separation of the traffic in the network's forwarding plane, rather than >>>shipping it everywhere and deciding whether to forward to the AC when it >>>gets to the egress PE. I'm having a hard time putting my finger exactly >>>on what it is, or articulating the idea, but it seems that by having the >>>traffic placed into two psuedowires, I have more flexibility and ease of >>>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>>PW's could really change that perception. >>>[JY] Are you saying that we need to develop a totally new forwarding >>>plane rather than using the Ethernet forwarding plane as described in >>>the >>>existing work? >>> >>>I hope we can move forward with one of these soon, >>>[JY] me too. >>> >>>Josh >>> >>> >>>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >>> >>>>Daniel, >>>> >>>>Not aware that we had a discussion on this before, but IMHO the >>>>allocation of internal S-VLAN can be automatic, and manuel >>>>configuration >>>>of this mapping may not be needed at all. For example, an S-VLAN >>>>allocation module in the management plane in a PE can do this kind of >>>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>>way from a free S-VLAN ID pool. Once the interal S-VLANs are allocated, >>>>the mapping is determined and no other configuration is needed. >>>> >>>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>>allocate >>>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to allocate >>>>two S-VLANs in the VPLS domain. >>>> >>>>On the other hand, for the multi-PW approach, two PWs need to be >>>>configured for a E-Tree service. When MS-PW is used in the network, for >>>>every S-PE, we need to configure two ingress PW segments and two egress >>>>PW segments. In this case, I don't think we need to use fixed PW labels >>>>across the network for fear of configuration complexity. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 8:01 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Inline. >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 12:30 PM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, Please see my comments in line. >>>> >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 3:55 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Yuanlong, >>>> >>>>The problem is not with the total number of S-VLAN IDs, I agree that >>>>normally there won't be more than 2047. The problem is that if you >>>>don't >>>>support all VLAN IDs, you need S-VLAN space coordination with the >>>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to >>>>2047". >>>>Which won't always be in line with an existing deployment. >>>>[JY] This is not the case. If the total number is no more than 2047, it >>>>surely can be supported. The S-VLAN space of user domain is totally >>>>different from the S-VLAN in the provider domain and they can be >>>>overlapped, I don't see why we need S-VLAN space coordination between >>>>them. >>>> >>>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>>fixed, and therefore the IEEE S-VID that can be supported is also >>>>fixed. >>>> >>>>Of course you can configure the mapping in each PE according to >>>>operator >>>>requirements but as we discussed before this increases complexity. >>>> >>>>Relying on PBB-VPLS imposes additional limitations on backward >>>>compatibility. >>>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>>think they may well need MAC-in-MAC in their networks for the >>>>scalability issue. As you know, only PBB VPLS can provide both. >>>> >>>>Daniel >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 5:07 AM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, >>>> >>>>As you can see, both cases are discussed in the I-D. >>>> >>>>With regard to case 1) (that is, S-VLAN translation), since the access >>>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>>they need to be configured on a PE anyway, and as the past emails by >>>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>>mapping. >>>> >>>>With regard to S-VID space reduction, the constraint is valid only when >>>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>>typical and with no such limits as we already discussed in the f2f >>>>meeting. >>>> >>>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>>described (not sure this is a valid use case in real life), PBB-VPLS >>>>can >>>>still be used. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Monday, April 30, 2012 10:34 PM >>>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>Jiangyuanlong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>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] >>>>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 >>>> >>>>---------------------------------------------------------------------- >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to >>>copyright belonging to Time Warner Cable. This E-mail is intended solely >>>for the use of the individual or entity to which it is addressed. If you >>>are not the intended recipient of this E-mail, you are hereby notified >>>that any dissemination, distribution, copying, or action taken in >>>relation to the contents of and attachments to this E-mail is strictly >>>prohibited and may be unlawful. If you have received this 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 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 Sun May 6 23:36: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 E0C3A21F84B8 for ; Sun, 6 May 2012 23:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.167 X-Spam-Level: X-Spam-Status: No, score=-2.167 tagged_above=-999 required=5 tests=[AWL=-0.167, 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 RWDGlkAimfUT for ; Sun, 6 May 2012 23:36:58 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id BE0B121F84AE for ; Sun, 6 May 2012 23:36:57 -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 AFW75706; Mon, 07 May 2012 02:36:56 -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; Sun, 6 May 2012 23:34:10 -0700 Received: from SZXEML440-HUB.china.huawei.com (10.72.61.75) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 6 May 2012 23:34:11 -0700 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.183]) by SZXEML440-HUB.china.huawei.com ([10.72.61.75]) with mapi id 14.01.0323.003; Mon, 7 May 2012 14:34:00 +0800 From: Jiangyuanlong To: "Rogers, Josh" , Daniel Cohn , "Fedyk, Donald (Don)" , "Henderickx, Wim (Wim)" , 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: AQHNI1NEA18PKDoBDEy6zAcXiVu2LpasuNMAgAYGiYCAAAzygIAAAjQAgAAAAYCAAASFAIAAAOoAgAAYGACAAAPTgIACzjKAgABsbmCAABSDMIAAJEvQgADhaeD//53EgIAAk10ggAA/vACAASTWUIAAOyKAgAR+CPD//633gIAApnLQ Date: Mon, 7 May 2012 06:34:00 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410770@szxeml546-mbx.china.huawei.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D4106B5@szxeml546-mbx.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.40.73] Content-Type: text/plain; charset="iso-8859-2" 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, 07 May 2012 06:37:00 -0000 -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com]=20 Sent: Monday, May 07, 2012 12:09 PM To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim);= Lucy yong Cc: l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? So, if you can imagine three PE's, PE1, PE2 and PE3. PE1 has a root AC, R1 and a leaf AC, L1. PE2 also has a root AC, R2, and a leaf AC, L2. PE3 has a leaf AC, L3. Consider an unknown unicast frame from the leaf site L1, and also another unknown unicast frame from R1 entering. With the 2VLAN method (to my best understanding): - frame from L1 enters PE1, goes into a PW to PE2 and a PW to PE3, arrives at PE2 which decides that it should be flooded out all Root AC's, based on the S-tag. It also arrives at PE3, where it is dropped because there are no root AC's. [JY] Since PE3 is a leaf-only node, the PW from PE1 to PE3 will work in Opt= imized-Mode. According to Section 5.3.3 of draft-jiang-l2vpn-vpls-pe-etree-= 05, it will be dropped before arriving at this PW. Therefore, this frame wi= ll not arrive at PE3. - frame from R1 enters PE1, goes into a PW to PE2 and a PW to PE3, arrives at PE2 which decides that it should be flooded out all AC's, based on S-tag. It also arrives at PE3 where it is forwarded to all root AC's. With Multi-PW method: - frame from L1 enters PE1, which decides to forward the frame out the 'root' PW to PE2, which in turn floods out all Root AC's, based on arriving PW type. Frame is NOT sent to PE3, since there is no PW built to the PE which has no root AC's. [JY] According to my understanding of the following description in draft-ra= m-l2vpn-etree-multiple-pw-01: "It should be noted that in a full-mesh VPLS (as opposed to H-VPLS), the following VSI pair types do not require two interconnecting PWs: Root-only VSI <-> any VSI: only root PW required Leaf-only VSI <-> leaf-only VSI: no PWs required" There should be 2 PWs be set up between PE1 and PE3, since this is a case o= f "Root & Leaf mixed VSI <-> leaf-only VSI" and not listed in the none-two-= interconnecting-PWs criteria. Therefore, this frame will be sent to PE3 tw= ice (one on root PW, another on leaf PW) IMO. Of course, the other authors = of draft-ram-l2vpn-etree-multiple-pw-01 may have more to say on this point. - frame from R1 enters PE1, which decides to flood out both 'root' PW and 'leaf' PW to PE2, which in turn floods out the same AC types, based on arriving PW type. It also arrives at PE3 where it is forwarded to all root AC's. [JY] It contradicts your first statement that "there is no PW built to the = PE which has no root AC's".=20 I suppose optimization could be done on the ingress PE to decide that there is no need to 'flood' root-sourced frames to two PW's that have the same egress PE, but instead to only forward to the 'root' type PW, when both exist, because we know that the egress PE will flood frames from root-sourced PW's out both leaf and root AC's. In this example, the same frame from R1 is duplicated on the PE1-PE2 path (if no optimization is done.), where it would not be with the 2VLAN method. With 2VLAN, ethernet type PW's cannot be used (must be vlan type PW's, otherwise how would we classify source AC-type?), which means there is overhead on EVERY frame to add the s-tag for the sole purpose of classifying the frame. If optimization is done, then each ingress PE knows what types of AC's are on each egress PE, and only forwards the appropriate frame, if no optimization then it is dropped at the egress PE. In short, both are either not 100% inefficient, or are additionally complex due to 'optimization'. I may have gotten my details off on the optimization piece of the 2VLAN method, please correct me if I didn't get the details 100% correct. -Josh On 5/6/12 9:07 PM, "Jiangyuanlong" wrote: >Could you or any other co-authors of 2PW give some more hints so that it >can be better understood? > >In draft-ram-l2vpn-etree-multiple-pw-01, I can only find a single >sentence most to the point: > "An egress PE SHALL NOT deliver a frame originated at a leaf AC to > another leaf AC." > >But it seems there is not a description of "traffic is split/separated >(by psuedowire) on the ingress PE" at all. > >On the contrary, in draft-jiang-l2vpn-vpls-pe-etree-05, Section 5.3.3 >details the scenario and forwarding plane how the leaf traffic is >seperated and filtered on the ingress PE, and Section 6 details the >specific supports in the control plane. > >Thanks >Yuanlong > > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Friday, May 04, 2012 8:27 PM >To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >(Wim); Lucy yong >Cc: l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >also separate the leaf traffic in the ingress PE and filter it there >(already detailed in the Optimization Mode in the I-D); if the egress PE >is attached with pure roots or with both roots and leafs, it seems all >traffic must be transported to the egress PE and be filtered there, I see >no difference in behaviour for these solutions. Or did I miss something? > > >The point is with the multi-PW method the traffic is split/separated (by >psuedowire) on the ingress PE, rather than the egress. The distinction is >2VLAN will 'classify' the frame on the ingress PE, so that the egress PE >knows how to forward it to the appropriate AC's. > >Both methods have inefficiencies (one duplicates traffic for transport, >while the other transports where it doesn't need to go). I like the idea >of classify and forwarding on the ingress PE, rather than marking it on >the ingress, and deciding on the egress. > >-Josh > > > >On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: > >>Josh, thank you for the comments, please see my further comments with >>[JY2]. >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Thursday, May 03, 2012 11:27 PM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>requirements from MEF, it has nothing to do with the solutions. Could you >>give a hint on how you can provision this service E-NNI otherwise? BTW, >>if >>configuring or signalling two PWs is not a problem, why configuring or >>signalling two VLANs will become a problem? After all, more nodes may >>need >>to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >>2VLAN (only T-PEs). >> >> >>There is no other way (if both MPLS domains are part of the same ETREE, >>rather than doing something more like H-VPLS, where one domain has point >>to points to the other domain which handles the ETREE instance) if you >>are >>using an ENNI. The other method, (not mentioned earlier) is tying the >>two >>MPLS domains together via labeled unicast (much preferred over E-NNI in >>my >>opinion) >> >>Configuring two VLAN's isn't really a 'problem' any more than two PW's. >>I >>wasn't saying that configuring two VLAN's was difficult, I was objecting >>to the statement that configuring two PW's is difficult. >> >>[JY2] Thanks, I see your point. I take the example of 2PW configuration >>just to show that using fixed global values to simplify configuration >>makes no sense. Personally I also don't think configuration is a problem >>for both solutions. >> >>I find the differences between these two methods rather slight. The >>'tie-breaker' for me is by placing the forwarding decision on the ingress >>PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >>more control over where the traffic goes, and in my mind it provides a >>cleaner destination between customer traffic and forwarding plane. I'm >>accustomed to looking at a psuedowire and knowing where its going, with >>the 2vlan method, I can see the psuedowire, but must go to the egress PE >>to see if it will be dropped there, or forwarded to one or more AC's. >> >>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>also separate the leaf traffic in the ingress PE and filter it there >>(already detailed in the Optimization Mode in the I-D); if the egress PE >>is attached with pure roots or with both roots and leafs, it seems all >>traffic must be transported to the egress PE and be filtered there, I see >>no difference in behaviour for these solutions. Or did I miss something? >> >>Again, the difference here is slight, and I would honestly be happy to >>see >>either of them come to fruition. Please don't infer that I think the >>2vlan method is 'bad' or has intrinsic problems, because I don't believe >>that. I just prefer the multi-PW method. >> >> >>-Josh >> >> >>On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: >> >>>Josh, please see my comments in line. >>> >>>Thanks >>>Yuanlong >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Thursday, May 03, 2012 10:51 AM >>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>(Wim); Lucy yong >>>Cc: l2vpn@ietf.org >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Yuanlong, >>> >>>Or better yet, include in the draft a 'standard' value for root sourced >>>VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You would al= so >>>have to require the the implementation NOT use global VLAN's, however >>>(since each instance would be using the same values). In this way, no >>>signaling or manual configuration is required for remote PE's to know >>>how >>>to classify traffic. >>>[JY] Indeed, we discussed this possibility during the f2f meeting in >>>Paris. But, there are some restrictions as you mentioned, and >>>furthermore: >>>1) Some vendors already used S-VLAN to distinguish their VSIs in the PE; >>>2) Forwarding plane of a PE needs to be revised to be aware of this VLAN >>>ID. >>>Therefore, this 'standard value' approach seems more disruptive compared >>>with the other means and not a good candidate option. >>> >>>Regarding switching PE's=A9 Multi-PW means more than one PW, yes. I >>>don't >>>see this as a real problem. In general, design should try and avoid >>>using >>>S-PE's, but if you must, its going to mean extra work, no matter how you >>>look at it. Two PW's for each Etree being switched instead of one is >>>not >>>alarming or concerning to me. On the other hand, if you use a dot1q >>>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's >>>an >>>two egress VLAN's if you want the Etree to be handled on both sides (and >>>if you use the 'standard' VID's as I mentioned above, you'd have to do >>>mapping to non-standard and back) >>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>requirements from MEF, it has nothing to do with the solutions. Could >>>you >>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>if configuring or signalling two PWs is not a problem, why configuring >>>or >>>signalling two VLANs will become a problem? After all, more nodes may >>>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>>with 2VLAN (only T-PEs). >>> >>>In general, I still prefer multi-PW, primarily because I prefer the >>>separation of the traffic in the network's forwarding plane, rather than >>>shipping it everywhere and deciding whether to forward to the AC when it >>>gets to the egress PE. I'm having a hard time putting my finger exactly >>>on what it is, or articulating the idea, but it seems that by having the >>>traffic placed into two psuedowires, I have more flexibility and ease of >>>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>>PW's could really change that perception. >>>[JY] Are you saying that we need to develop a totally new forwarding >>>plane rather than using the Ethernet forwarding plane as described in >>>the >>>existing work? >>> >>>I hope we can move forward with one of these soon, >>>[JY] me too. >>> >>>Josh >>> >>> >>>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >>> >>>>Daniel, >>>> >>>>Not aware that we had a discussion on this before, but IMHO the >>>>allocation of internal S-VLAN can be automatic, and manuel >>>>configuration >>>>of this mapping may not be needed at all. For example, an S-VLAN >>>>allocation module in the management plane in a PE can do this kind of >>>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>>way from a free S-VLAN ID pool. Once the interal S-VLANs are allocated, >>>>the mapping is determined and no other configuration is needed. >>>> >>>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>>allocate >>>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to allocate >>>>two S-VLANs in the VPLS domain. >>>> >>>>On the other hand, for the multi-PW approach, two PWs need to be >>>>configured for a E-Tree service. When MS-PW is used in the network, for >>>>every S-PE, we need to configure two ingress PW segments and two egress >>>>PW segments. In this case, I don't think we need to use fixed PW labels >>>>across the network for fear of configuration complexity. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 8:01 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Inline. >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 12:30 PM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, Please see my comments in line. >>>> >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 3:55 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Yuanlong, >>>> >>>>The problem is not with the total number of S-VLAN IDs, I agree that >>>>normally there won't be more than 2047. The problem is that if you >>>>don't >>>>support all VLAN IDs, you need S-VLAN space coordination with the >>>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to >>>>2047". >>>>Which won't always be in line with an existing deployment. >>>>[JY] This is not the case. If the total number is no more than 2047, it >>>>surely can be supported. The S-VLAN space of user domain is totally >>>>different from the S-VLAN in the provider domain and they can be >>>>overlapped, I don't see why we need S-VLAN space coordination between >>>>them. >>>> >>>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>>fixed, and therefore the IEEE S-VID that can be supported is also >>>>fixed. >>>> >>>>Of course you can configure the mapping in each PE according to >>>>operator >>>>requirements but as we discussed before this increases complexity. >>>> >>>>Relying on PBB-VPLS imposes additional limitations on backward >>>>compatibility. >>>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>>think they may well need MAC-in-MAC in their networks for the >>>>scalability issue. As you know, only PBB VPLS can provide both. >>>> >>>>Daniel >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 5:07 AM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, >>>> >>>>As you can see, both cases are discussed in the I-D. >>>> >>>>With regard to case 1) (that is, S-VLAN translation), since the access >>>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>>they need to be configured on a PE anyway, and as the past emails by >>>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>>mapping. >>>> >>>>With regard to S-VID space reduction, the constraint is valid only when >>>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>>typical and with no such limits as we already discussed in the f2f >>>>meeting. >>>> >>>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>>described (not sure this is a valid use case in real life), PBB-VPLS >>>>can >>>>still be used. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Monday, April 30, 2012 10:34 PM >>>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>Jiangyuanlong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>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] >>>>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 >>>> >>>>---------------------------------------------------------------------- >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to >>>copyright belonging to Time Warner Cable. This E-mail is intended solely >>>for the use of the individual or entity to which it is addressed. If you >>>are not the intended recipient of this E-mail, you are hereby notified >>>that any dissemination, distribution, copying, or action taken in >>>relation to the contents of and attachments to this E-mail is strictly >>>prohibited and may be unlawful. If you have received this 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 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 Mon May 7 00:08: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 4B2B421F84EE for ; Mon, 7 May 2012 00:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.243 X-Spam-Level: X-Spam-Status: No, score=-2.243 tagged_above=-999 required=5 tests=[AWL=-0.244, 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 sVxzeTSG3iYq for ; Mon, 7 May 2012 00:08:43 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id 66CF221F84DA for ; Mon, 7 May 2012 00:08:41 -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="iso-8859-2" Content-Transfer-Encoding: quoted-printable Subject: RE: The status of the approaches to the E-Tree solution? Date: Mon, 7 May 2012 10:10:36 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780C8C7@tlvmail1> In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410770@szxeml546-mbx.china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: AQHNI1NEA18PKDoBDEy6zAcXiVu2LpasuNMAgAYGiYCAAAzygIAAAjQAgAAAAYCAAASFAIAAAOoAgAAYGACAAAPTgIACzjKAgABsbmCAABSDMIAAJEvQgADhaeD//53EgIAAk10ggAA/vACAASTWUIAAOyKAgAR+CPD//633gIAApnLQgAAMX9A= References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D4106B5@szxeml546-mbx.china.huawei.com> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410770@szxeml546-mbx.china.huawei.com> From: "Daniel Cohn" To: "Jiangyuanlong" , "Rogers, Josh" , "Fedyk, Donald (Don)" , "Henderickx, Wim (Wim)" , "Lucy yong" 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, 07 May 2012 07:08:45 -0000 It seems to be that the optimization required to avoid unnecessary = transmission of leaf-only traffic over the network is significantly more = complex in the 2-VLAN solution, as you need the data plane to maintain = per-PW "leaf-onlyness" information (whether a specific PW leads to a = leaf-only PE or not) to decide when to drop these frames, whereas in the = multi-PW solution this is handled solely by the control plane (by = avoiding the setup of a PW in this scenario). DC -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Monday, May 07, 2012 9:34 AM To: Rogers, Josh; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim = (Wim); Lucy yong Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com]=20 Sent: Monday, May 07, 2012 12:09 PM To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim = (Wim); Lucy yong Cc: l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? So, if you can imagine three PE's, PE1, PE2 and PE3. PE1 has a root AC, R1 and a leaf AC, L1. PE2 also has a root AC, R2, and a leaf AC, L2. = PE3 has a leaf AC, L3. Consider an unknown unicast frame from the leaf site L1, and also = another unknown unicast frame from R1 entering. With the 2VLAN method (to my best understanding): - frame from L1 enters PE1, goes into a PW to PE2 and a PW to PE3, arrives at PE2 which decides that it should be flooded out all Root = AC's, based on the S-tag. It also arrives at PE3, where it is dropped because there are no root AC's. [JY] Since PE3 is a leaf-only node, the PW from PE1 to PE3 will work in = Optimized-Mode. According to Section 5.3.3 of = draft-jiang-l2vpn-vpls-pe-etree-05, it will be dropped before arriving = at this PW. Therefore, this frame will not arrive at PE3. - frame from R1 enters PE1, goes into a PW to PE2 and a PW to PE3, arrives at PE2 which decides that it should be flooded out all AC's, = based on S-tag. It also arrives at PE3 where it is forwarded to all root = AC's. With Multi-PW method: - frame from L1 enters PE1, which decides to forward the frame out the 'root' PW to PE2, which in turn floods out all Root AC's, based on arriving PW type. Frame is NOT sent to PE3, since there is no PW built = to the PE which has no root AC's. [JY] According to my understanding of the following description in = draft-ram-l2vpn-etree-multiple-pw-01: "It should be noted that in a full-mesh VPLS (as opposed to H-VPLS), the following VSI pair types do not require two interconnecting PWs: Root-only VSI <-> any VSI: only root PW required Leaf-only VSI <-> leaf-only VSI: no PWs required" There should be 2 PWs be set up between PE1 and PE3, since this is a = case of "Root & Leaf mixed VSI <-> leaf-only VSI" and not listed in the = none-two- interconnecting-PWs criteria. Therefore, this frame will be = sent to PE3 twice (one on root PW, another on leaf PW) IMO. Of course, = the other authors of draft-ram-l2vpn-etree-multiple-pw-01 may have more = to say on this point. - frame from R1 enters PE1, which decides to flood out both 'root' PW and 'leaf' PW to PE2, which in turn floods out the same AC types, based = on arriving PW type. It also arrives at PE3 where it is forwarded to all root AC's. [JY] It contradicts your first statement that "there is no PW built to = the PE which has no root AC's".=20 I suppose optimization could be done on the ingress PE to decide that there is no need to 'flood' root-sourced frames to two PW's that have = the same egress PE, but instead to only forward to the 'root' type PW, when both exist, because we know that the egress PE will flood frames from root-sourced PW's out both leaf and root AC's. In this example, the same frame from R1 is duplicated on the PE1-PE2 = path (if no optimization is done.), where it would not be with the 2VLAN = method. With 2VLAN, ethernet type PW's cannot be used (must be vlan type PW's, otherwise how would we classify source AC-type?), which means there is overhead on EVERY frame to add the s-tag for the sole purpose of classifying the frame. If optimization is done, then each ingress PE knows what types of AC's are on each egress PE, and only forwards the appropriate frame, if no optimization then it is dropped at the egress = PE. In short, both are either not 100% inefficient, or are additionally complex due to 'optimization'. I may have gotten my details off on the optimization piece of the 2VLAN method, please correct me if I didn't get the details 100% correct. -Josh On 5/6/12 9:07 PM, "Jiangyuanlong" wrote: >Could you or any other co-authors of 2PW give some more hints so that = it >can be better understood? > >In draft-ram-l2vpn-etree-multiple-pw-01, I can only find a single >sentence most to the point: > "An egress PE SHALL NOT deliver a frame originated at a leaf AC to > another leaf AC." > >But it seems there is not a description of "traffic is split/separated >(by psuedowire) on the ingress PE" at all. > >On the contrary, in draft-jiang-l2vpn-vpls-pe-etree-05, Section 5.3.3 >details the scenario and forwarding plane how the leaf traffic is >seperated and filtered on the ingress PE, and Section 6 details the >specific supports in the control plane. > >Thanks >Yuanlong > > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Friday, May 04, 2012 8:27 PM >To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >(Wim); Lucy yong >Cc: l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >also separate the leaf traffic in the ingress PE and filter it there >(already detailed in the Optimization Mode in the I-D); if the egress = PE >is attached with pure roots or with both roots and leafs, it seems all >traffic must be transported to the egress PE and be filtered there, I = see >no difference in behaviour for these solutions. Or did I miss = something? > > >The point is with the multi-PW method the traffic is split/separated = (by >psuedowire) on the ingress PE, rather than the egress. The distinction = is >2VLAN will 'classify' the frame on the ingress PE, so that the egress = PE >knows how to forward it to the appropriate AC's. > >Both methods have inefficiencies (one duplicates traffic for transport, >while the other transports where it doesn't need to go). I like the = idea >of classify and forwarding on the ingress PE, rather than marking it on >the ingress, and deciding on the egress. > >-Josh > > > >On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: > >>Josh, thank you for the comments, please see my further comments with >>[JY2]. >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Thursday, May 03, 2012 11:27 PM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>requirements from MEF, it has nothing to do with the solutions. Could = you >>give a hint on how you can provision this service E-NNI otherwise? = BTW, >>if >>configuring or signalling two PWs is not a problem, why configuring or >>signalling two VLANs will become a problem? After all, more nodes may >>need >>to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >>2VLAN (only T-PEs). >> >> >>There is no other way (if both MPLS domains are part of the same = ETREE, >>rather than doing something more like H-VPLS, where one domain has = point >>to points to the other domain which handles the ETREE instance) if you >>are >>using an ENNI. The other method, (not mentioned earlier) is tying the >>two >>MPLS domains together via labeled unicast (much preferred over E-NNI = in >>my >>opinion) >> >>Configuring two VLAN's isn't really a 'problem' any more than two = PW's. >>I >>wasn't saying that configuring two VLAN's was difficult, I was = objecting >>to the statement that configuring two PW's is difficult. >> >>[JY2] Thanks, I see your point. I take the example of 2PW = configuration >>just to show that using fixed global values to simplify configuration >>makes no sense. Personally I also don't think configuration is a = problem >>for both solutions. >> >>I find the differences between these two methods rather slight. The >>'tie-breaker' for me is by placing the forwarding decision on the = ingress >>PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you = get >>more control over where the traffic goes, and in my mind it provides a >>cleaner destination between customer traffic and forwarding plane. = I'm >>accustomed to looking at a psuedowire and knowing where its going, = with >>the 2vlan method, I can see the psuedowire, but must go to the egress = PE >>to see if it will be dropped there, or forwarded to one or more AC's. >> >>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>also separate the leaf traffic in the ingress PE and filter it there >>(already detailed in the Optimization Mode in the I-D); if the egress = PE >>is attached with pure roots or with both roots and leafs, it seems all >>traffic must be transported to the egress PE and be filtered there, I = see >>no difference in behaviour for these solutions. Or did I miss = something? >> >>Again, the difference here is slight, and I would honestly be happy to >>see >>either of them come to fruition. Please don't infer that I think the >>2vlan method is 'bad' or has intrinsic problems, because I don't = believe >>that. I just prefer the multi-PW method. >> >> >>-Josh >> >> >>On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: >> >>>Josh, please see my comments in line. >>> >>>Thanks >>>Yuanlong >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Thursday, May 03, 2012 10:51 AM >>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>(Wim); Lucy yong >>>Cc: l2vpn@ietf.org >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Yuanlong, >>> >>>Or better yet, include in the draft a 'standard' value for root = sourced >>>VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You would = also >>>have to require the the implementation NOT use global VLAN's, however >>>(since each instance would be using the same values). In this way, = no >>>signaling or manual configuration is required for remote PE's to know >>>how >>>to classify traffic. >>>[JY] Indeed, we discussed this possibility during the f2f meeting in >>>Paris. But, there are some restrictions as you mentioned, and >>>furthermore: >>>1) Some vendors already used S-VLAN to distinguish their VSIs in the = PE; >>>2) Forwarding plane of a PE needs to be revised to be aware of this = VLAN >>>ID. >>>Therefore, this 'standard value' approach seems more disruptive = compared >>>with the other means and not a good candidate option. >>> >>>Regarding switching PE's=A9 Multi-PW means more than one PW, yes. I >>>don't >>>see this as a real problem. In general, design should try and avoid >>>using >>>S-PE's, but if you must, its going to mean extra work, no matter how = you >>>look at it. Two PW's for each Etree being switched instead of one is >>>not >>>alarming or concerning to me. On the other hand, if you use a dot1q >>>(E-NNI) between MPLS domains, you have to deal with two ingress = VLAN's >>>an >>>two egress VLAN's if you want the Etree to be handled on both sides = (and >>>if you use the 'standard' VID's as I mentioned above, you'd have to = do >>>mapping to non-standard and back) >>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the = service >>>requirements from MEF, it has nothing to do with the solutions. Could >>>you >>>give a hint on how you can provision this service E-NNI otherwise? = BTW, >>>if configuring or signalling two PWs is not a problem, why = configuring >>>or >>>signalling two VLANs will become a problem? After all, more nodes may >>>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>>with 2VLAN (only T-PEs). >>> >>>In general, I still prefer multi-PW, primarily because I prefer the >>>separation of the traffic in the network's forwarding plane, rather = than >>>shipping it everywhere and deciding whether to forward to the AC when = it >>>gets to the egress PE. I'm having a hard time putting my finger = exactly >>>on what it is, or articulating the idea, but it seems that by having = the >>>traffic placed into two psuedowires, I have more flexibility and ease = of >>>configuration when it comes to E-NNI's, service multiplexed UNI's, = and >>>H-VPLS (both psuedowire based and vlan based). Of course my 'ease = of >>>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup = of >>>PW's could really change that perception. >>>[JY] Are you saying that we need to develop a totally new forwarding >>>plane rather than using the Ethernet forwarding plane as described in >>>the >>>existing work? >>> >>>I hope we can move forward with one of these soon, >>>[JY] me too. >>> >>>Josh >>> >>> >>>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >>> >>>>Daniel, >>>> >>>>Not aware that we had a discussion on this before, but IMHO the >>>>allocation of internal S-VLAN can be automatic, and manuel >>>>configuration >>>>of this mapping may not be needed at all. For example, an S-VLAN >>>>allocation module in the management plane in a PE can do this kind = of >>>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>>single external S-VLAN ID) in a topdown, bottom-up, or just any = random >>>>way from a free S-VLAN ID pool. Once the interal S-VLANs are = allocated, >>>>the mapping is determined and no other configuration is needed. >>>> >>>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>>allocate >>>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to = allocate >>>>two S-VLANs in the VPLS domain. >>>> >>>>On the other hand, for the multi-PW approach, two PWs need to be >>>>configured for a E-Tree service. When MS-PW is used in the network, = for >>>>every S-PE, we need to configure two ingress PW segments and two = egress >>>>PW segments. In this case, I don't think we need to use fixed PW = labels >>>>across the network for fear of configuration complexity. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 8:01 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Inline. >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 12:30 PM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy = yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, Please see my comments in line. >>>> >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 3:55 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Yuanlong, >>>> >>>>The problem is not with the total number of S-VLAN IDs, I agree that >>>>normally there won't be more than 2047. The problem is that if you >>>>don't >>>>support all VLAN IDs, you need S-VLAN space coordination with the >>>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to >>>>2047". >>>>Which won't always be in line with an existing deployment. >>>>[JY] This is not the case. If the total number is no more than 2047, = it >>>>surely can be supported. The S-VLAN space of user domain is totally >>>>different from the S-VLAN in the provider domain and they can be >>>>overlapped, I don't see why we need S-VLAN space coordination = between >>>>them. >>>> >>>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>>fixed, and therefore the IEEE S-VID that can be supported is also >>>>fixed. >>>> >>>>Of course you can configure the mapping in each PE according to >>>>operator >>>>requirements but as we discussed before this increases complexity. >>>> >>>>Relying on PBB-VPLS imposes additional limitations on backward >>>>compatibility. >>>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, = I >>>>think they may well need MAC-in-MAC in their networks for the >>>>scalability issue. As you know, only PBB VPLS can provide both. >>>> >>>>Daniel >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 5:07 AM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy = yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, >>>> >>>>As you can see, both cases are discussed in the I-D. >>>> >>>>With regard to case 1) (that is, S-VLAN translation), since the = access >>>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>>they need to be configured on a PE anyway, and as the past emails by >>>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by = 1:1 >>>>mapping. >>>> >>>>With regard to S-VID space reduction, the constraint is valid only = when >>>>a global VLAN space is used per PE, in fact, multi-VLAN space is = more >>>>typical and with no such limits as we already discussed in the f2f >>>>meeting. >>>> >>>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>>described (not sure this is a valid use case in real life), PBB-VPLS >>>>can >>>>still be used. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Monday, April 30, 2012 10:34 PM >>>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>Jiangyuanlong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>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] >>>>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 >>>> >>>>---------------------------------------------------------------------= - >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or = subject >>>to >>>copyright belonging to Time Warner Cable. This E-mail is intended = solely >>>for the use of the individual or entity to which it is addressed. If = you >>>are not the intended recipient of this E-mail, you are hereby = notified >>>that any dissemination, distribution, copying, or action taken in >>>relation to the contents of and attachments to this E-mail is = strictly >>>prohibited and may be unlawful. If you have received this 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 and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = 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 Mon May 7 01:08: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 D16B521F8527 for ; Mon, 7 May 2012 01:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[AWL=-0.162, 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 FjAQyTMurAk3 for ; Mon, 7 May 2012 01:08:24 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9C46F21F8512 for ; Mon, 7 May 2012 01:08:24 -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 AFO81716; Mon, 07 May 2012 04:08:24 -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, 7 May 2012 01:05:42 -0700 Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 7 May 2012 01:05:41 -0700 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.183]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.01.0323.003; Mon, 7 May 2012 16:05:30 +0800 From: Jiangyuanlong To: Daniel Cohn , "Rogers, Josh" , "Fedyk, Donald (Don)" , "Henderickx, Wim (Wim)" , 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: AQHNI1NEA18PKDoBDEy6zAcXiVu2LpasuNMAgAYGiYCAAAzygIAAAjQAgAAAAYCAAASFAIAAAOoAgAAYGACAAAPTgIACzjKAgABsbmCAABSDMIAAJEvQgADhaeD//53EgIAAk10ggAA/vACAASTWUIAAOyKAgAR+CPD//633gIAApnLQgAAMX9CAABMbsA== Date: Mon, 7 May 2012 08:05:30 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D41079C@szxeml546-mbx.china.huawei.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D4106B5@szxeml546-mbx.china.huawei.com> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410770@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780C8C7@tlvmail1> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA08130780C8C7@tlvmail1> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.40.73] Content-Type: text/plain; charset="iso-8859-2" 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, 07 May 2012 08:08:27 -0000 Interesting observation. Could you explain a bit more how to avoid setup of= a PW in this scenario? Or could you just point to the exact sentences in y= our I-D?=20 -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Monday, May 07, 2012 3:11 PM To: Jiangyuanlong; Rogers, Josh; Fedyk, Donald (Don); Henderickx, Wim (Wim)= ; Lucy yong Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? It seems to be that the optimization required to avoid unnecessary transmis= sion of leaf-only traffic over the network is significantly more complex in= the 2-VLAN solution, as you need the data plane to maintain per-PW "leaf-o= nlyness" information (whether a specific PW leads to a leaf-only PE or not)= to decide when to drop these frames, whereas in the multi-PW solution this= is handled solely by the control plane (by avoiding the setup of a PW in t= his scenario). DC -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Monday, May 07, 2012 9:34 AM To: Rogers, Josh; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); = Lucy yong Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com]=20 Sent: Monday, May 07, 2012 12:09 PM To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim);= Lucy yong Cc: l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? So, if you can imagine three PE's, PE1, PE2 and PE3. PE1 has a root AC, R1 and a leaf AC, L1. PE2 also has a root AC, R2, and a leaf AC, L2. PE3 has a leaf AC, L3. Consider an unknown unicast frame from the leaf site L1, and also another unknown unicast frame from R1 entering. With the 2VLAN method (to my best understanding): - frame from L1 enters PE1, goes into a PW to PE2 and a PW to PE3, arrives at PE2 which decides that it should be flooded out all Root AC's, based on the S-tag. It also arrives at PE3, where it is dropped because there are no root AC's. [JY] Since PE3 is a leaf-only node, the PW from PE1 to PE3 will work in Opt= imized-Mode. According to Section 5.3.3 of draft-jiang-l2vpn-vpls-pe-etree-= 05, it will be dropped before arriving at this PW. Therefore, this frame wi= ll not arrive at PE3. - frame from R1 enters PE1, goes into a PW to PE2 and a PW to PE3, arrives at PE2 which decides that it should be flooded out all AC's, based on S-tag. It also arrives at PE3 where it is forwarded to all root AC's. With Multi-PW method: - frame from L1 enters PE1, which decides to forward the frame out the 'root' PW to PE2, which in turn floods out all Root AC's, based on arriving PW type. Frame is NOT sent to PE3, since there is no PW built to the PE which has no root AC's. [JY] According to my understanding of the following description in draft-ra= m-l2vpn-etree-multiple-pw-01: "It should be noted that in a full-mesh VPLS (as opposed to H-VPLS), the following VSI pair types do not require two interconnecting PWs: Root-only VSI <-> any VSI: only root PW required Leaf-only VSI <-> leaf-only VSI: no PWs required" There should be 2 PWs be set up between PE1 and PE3, since this is a case o= f "Root & Leaf mixed VSI <-> leaf-only VSI" and not listed in the none-two-= interconnecting-PWs criteria. Therefore, this frame will be sent to PE3 tw= ice (one on root PW, another on leaf PW) IMO. Of course, the other authors = of draft-ram-l2vpn-etree-multiple-pw-01 may have more to say on this point. - frame from R1 enters PE1, which decides to flood out both 'root' PW and 'leaf' PW to PE2, which in turn floods out the same AC types, based on arriving PW type. It also arrives at PE3 where it is forwarded to all root AC's. [JY] It contradicts your first statement that "there is no PW built to the = PE which has no root AC's".=20 I suppose optimization could be done on the ingress PE to decide that there is no need to 'flood' root-sourced frames to two PW's that have the same egress PE, but instead to only forward to the 'root' type PW, when both exist, because we know that the egress PE will flood frames from root-sourced PW's out both leaf and root AC's. In this example, the same frame from R1 is duplicated on the PE1-PE2 path (if no optimization is done.), where it would not be with the 2VLAN method. With 2VLAN, ethernet type PW's cannot be used (must be vlan type PW's, otherwise how would we classify source AC-type?), which means there is overhead on EVERY frame to add the s-tag for the sole purpose of classifying the frame. If optimization is done, then each ingress PE knows what types of AC's are on each egress PE, and only forwards the appropriate frame, if no optimization then it is dropped at the egress PE. In short, both are either not 100% inefficient, or are additionally complex due to 'optimization'. I may have gotten my details off on the optimization piece of the 2VLAN method, please correct me if I didn't get the details 100% correct. -Josh On 5/6/12 9:07 PM, "Jiangyuanlong" wrote: >Could you or any other co-authors of 2PW give some more hints so that it >can be better understood? > >In draft-ram-l2vpn-etree-multiple-pw-01, I can only find a single >sentence most to the point: > "An egress PE SHALL NOT deliver a frame originated at a leaf AC to > another leaf AC." > >But it seems there is not a description of "traffic is split/separated >(by psuedowire) on the ingress PE" at all. > >On the contrary, in draft-jiang-l2vpn-vpls-pe-etree-05, Section 5.3.3 >details the scenario and forwarding plane how the leaf traffic is >seperated and filtered on the ingress PE, and Section 6 details the >specific supports in the control plane. > >Thanks >Yuanlong > > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Friday, May 04, 2012 8:27 PM >To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >(Wim); Lucy yong >Cc: l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >also separate the leaf traffic in the ingress PE and filter it there >(already detailed in the Optimization Mode in the I-D); if the egress PE >is attached with pure roots or with both roots and leafs, it seems all >traffic must be transported to the egress PE and be filtered there, I see >no difference in behaviour for these solutions. Or did I miss something? > > >The point is with the multi-PW method the traffic is split/separated (by >psuedowire) on the ingress PE, rather than the egress. The distinction is >2VLAN will 'classify' the frame on the ingress PE, so that the egress PE >knows how to forward it to the appropriate AC's. > >Both methods have inefficiencies (one duplicates traffic for transport, >while the other transports where it doesn't need to go). I like the idea >of classify and forwarding on the ingress PE, rather than marking it on >the ingress, and deciding on the egress. > >-Josh > > > >On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: > >>Josh, thank you for the comments, please see my further comments with >>[JY2]. >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Thursday, May 03, 2012 11:27 PM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>requirements from MEF, it has nothing to do with the solutions. Could you >>give a hint on how you can provision this service E-NNI otherwise? BTW, >>if >>configuring or signalling two PWs is not a problem, why configuring or >>signalling two VLANs will become a problem? After all, more nodes may >>need >>to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >>2VLAN (only T-PEs). >> >> >>There is no other way (if both MPLS domains are part of the same ETREE, >>rather than doing something more like H-VPLS, where one domain has point >>to points to the other domain which handles the ETREE instance) if you >>are >>using an ENNI. The other method, (not mentioned earlier) is tying the >>two >>MPLS domains together via labeled unicast (much preferred over E-NNI in >>my >>opinion) >> >>Configuring two VLAN's isn't really a 'problem' any more than two PW's. >>I >>wasn't saying that configuring two VLAN's was difficult, I was objecting >>to the statement that configuring two PW's is difficult. >> >>[JY2] Thanks, I see your point. I take the example of 2PW configuration >>just to show that using fixed global values to simplify configuration >>makes no sense. Personally I also don't think configuration is a problem >>for both solutions. >> >>I find the differences between these two methods rather slight. The >>'tie-breaker' for me is by placing the forwarding decision on the ingress >>PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >>more control over where the traffic goes, and in my mind it provides a >>cleaner destination between customer traffic and forwarding plane. I'm >>accustomed to looking at a psuedowire and knowing where its going, with >>the 2vlan method, I can see the psuedowire, but must go to the egress PE >>to see if it will be dropped there, or forwarded to one or more AC's. >> >>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>also separate the leaf traffic in the ingress PE and filter it there >>(already detailed in the Optimization Mode in the I-D); if the egress PE >>is attached with pure roots or with both roots and leafs, it seems all >>traffic must be transported to the egress PE and be filtered there, I see >>no difference in behaviour for these solutions. Or did I miss something? >> >>Again, the difference here is slight, and I would honestly be happy to >>see >>either of them come to fruition. Please don't infer that I think the >>2vlan method is 'bad' or has intrinsic problems, because I don't believe >>that. I just prefer the multi-PW method. >> >> >>-Josh >> >> >>On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: >> >>>Josh, please see my comments in line. >>> >>>Thanks >>>Yuanlong >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Thursday, May 03, 2012 10:51 AM >>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>(Wim); Lucy yong >>>Cc: l2vpn@ietf.org >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Yuanlong, >>> >>>Or better yet, include in the draft a 'standard' value for root sourced >>>VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You would al= so >>>have to require the the implementation NOT use global VLAN's, however >>>(since each instance would be using the same values). In this way, no >>>signaling or manual configuration is required for remote PE's to know >>>how >>>to classify traffic. >>>[JY] Indeed, we discussed this possibility during the f2f meeting in >>>Paris. But, there are some restrictions as you mentioned, and >>>furthermore: >>>1) Some vendors already used S-VLAN to distinguish their VSIs in the PE; >>>2) Forwarding plane of a PE needs to be revised to be aware of this VLAN >>>ID. >>>Therefore, this 'standard value' approach seems more disruptive compared >>>with the other means and not a good candidate option. >>> >>>Regarding switching PE's=A9 Multi-PW means more than one PW, yes. I >>>don't >>>see this as a real problem. In general, design should try and avoid >>>using >>>S-PE's, but if you must, its going to mean extra work, no matter how you >>>look at it. Two PW's for each Etree being switched instead of one is >>>not >>>alarming or concerning to me. On the other hand, if you use a dot1q >>>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's >>>an >>>two egress VLAN's if you want the Etree to be handled on both sides (and >>>if you use the 'standard' VID's as I mentioned above, you'd have to do >>>mapping to non-standard and back) >>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>requirements from MEF, it has nothing to do with the solutions. Could >>>you >>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>if configuring or signalling two PWs is not a problem, why configuring >>>or >>>signalling two VLANs will become a problem? After all, more nodes may >>>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>>with 2VLAN (only T-PEs). >>> >>>In general, I still prefer multi-PW, primarily because I prefer the >>>separation of the traffic in the network's forwarding plane, rather than >>>shipping it everywhere and deciding whether to forward to the AC when it >>>gets to the egress PE. I'm having a hard time putting my finger exactly >>>on what it is, or articulating the idea, but it seems that by having the >>>traffic placed into two psuedowires, I have more flexibility and ease of >>>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>>PW's could really change that perception. >>>[JY] Are you saying that we need to develop a totally new forwarding >>>plane rather than using the Ethernet forwarding plane as described in >>>the >>>existing work? >>> >>>I hope we can move forward with one of these soon, >>>[JY] me too. >>> >>>Josh >>> >>> >>>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >>> >>>>Daniel, >>>> >>>>Not aware that we had a discussion on this before, but IMHO the >>>>allocation of internal S-VLAN can be automatic, and manuel >>>>configuration >>>>of this mapping may not be needed at all. For example, an S-VLAN >>>>allocation module in the management plane in a PE can do this kind of >>>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>>way from a free S-VLAN ID pool. Once the interal S-VLANs are allocated, >>>>the mapping is determined and no other configuration is needed. >>>> >>>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>>allocate >>>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to allocate >>>>two S-VLANs in the VPLS domain. >>>> >>>>On the other hand, for the multi-PW approach, two PWs need to be >>>>configured for a E-Tree service. When MS-PW is used in the network, for >>>>every S-PE, we need to configure two ingress PW segments and two egress >>>>PW segments. In this case, I don't think we need to use fixed PW labels >>>>across the network for fear of configuration complexity. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 8:01 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Inline. >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 12:30 PM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, Please see my comments in line. >>>> >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 3:55 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Yuanlong, >>>> >>>>The problem is not with the total number of S-VLAN IDs, I agree that >>>>normally there won't be more than 2047. The problem is that if you >>>>don't >>>>support all VLAN IDs, you need S-VLAN space coordination with the >>>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to >>>>2047". >>>>Which won't always be in line with an existing deployment. >>>>[JY] This is not the case. If the total number is no more than 2047, it >>>>surely can be supported. The S-VLAN space of user domain is totally >>>>different from the S-VLAN in the provider domain and they can be >>>>overlapped, I don't see why we need S-VLAN space coordination between >>>>them. >>>> >>>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>>fixed, and therefore the IEEE S-VID that can be supported is also >>>>fixed. >>>> >>>>Of course you can configure the mapping in each PE according to >>>>operator >>>>requirements but as we discussed before this increases complexity. >>>> >>>>Relying on PBB-VPLS imposes additional limitations on backward >>>>compatibility. >>>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>>think they may well need MAC-in-MAC in their networks for the >>>>scalability issue. As you know, only PBB VPLS can provide both. >>>> >>>>Daniel >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 5:07 AM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, >>>> >>>>As you can see, both cases are discussed in the I-D. >>>> >>>>With regard to case 1) (that is, S-VLAN translation), since the access >>>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>>they need to be configured on a PE anyway, and as the past emails by >>>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>>mapping. >>>> >>>>With regard to S-VID space reduction, the constraint is valid only when >>>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>>typical and with no such limits as we already discussed in the f2f >>>>meeting. >>>> >>>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>>described (not sure this is a valid use case in real life), PBB-VPLS >>>>can >>>>still be used. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Monday, April 30, 2012 10:34 PM >>>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>Jiangyuanlong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>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] >>>>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 >>>> >>>>---------------------------------------------------------------------- >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to >>>copyright belonging to Time Warner Cable. This E-mail is intended solely >>>for the use of the individual or entity to which it is addressed. If you >>>are not the intended recipient of this E-mail, you are hereby notified >>>that any dissemination, distribution, copying, or action taken in >>>relation to the contents of and attachments to this E-mail is strictly >>>prohibited and may be unlawful. If you have received this 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 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 Mon May 7 01:17: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 8B33A21F852B for ; Mon, 7 May 2012 01:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.23 X-Spam-Level: X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[AWL=-0.231, 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 119CVh1josP0 for ; Mon, 7 May 2012 01:17:50 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id 5DED521F851B for ; Mon, 7 May 2012 01:17:49 -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="iso-8859-2" Content-Transfer-Encoding: quoted-printable Subject: RE: The status of the approaches to the E-Tree solution? Date: Mon, 7 May 2012 11:19:44 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780C8ED@tlvmail1> In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D41079C@szxeml546-mbx.china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: AQHNI1NEA18PKDoBDEy6zAcXiVu2LpasuNMAgAYGiYCAAAzygIAAAjQAgAAAAYCAAASFAIAAAOoAgAAYGACAAAPTgIACzjKAgABsbmCAABSDMIAAJEvQgADhaeD//53EgIAAk10ggAA/vACAASTWUIAAOyKAgAR+CPD//633gIAApnLQgAAMX9CAABMbsIAABKzA References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D4106B5@szxeml546-mbx.china.huawei.com> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410770@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780C8C7@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D41079C@szxeml546-mbx.china.huawei.com> From: "Daniel Cohn" To: "Jiangyuanlong" , "Rogers, Josh" , "Fedyk, Donald (Don)" , "Henderickx, Wim (Wim)" , "Lucy yong" 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, 07 May 2012 08:17:52 -0000 In LDP, where PWs are established by the operator, it's part of the = provisioning process. Section 6.2 provides guidelines, as follows: It should be noted that in a full-mesh VPLS (as opposed to H-VPLS), the following VSI pair types do not require two interconnecting PWs: Root-only VSI <-> any VSI: only root PW required Leaf-only VSI <-> leaf-only VSI: no PWs required Where root-only VSI is a VSI where all ACs are of the root type, and leaf-only VSI is one where all ACs are of the leaf type. Typically the NMS takes care of PW setup in LDP-VPLS so this would be = part of the NMS logic. In BGP, this can be part of the PW signaling logic following leaf-only = signaling in the control flags (see sections 7.3 and 7.4). As you can = see this was not defined in this version but it's a simple extension of = the same logic that avoid PW setup between leaf-only PEs. Regards, Daniel -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Monday, May 07, 2012 11:06 AM To: Daniel Cohn; Rogers, Josh; Fedyk, Donald (Don); Henderickx, Wim = (Wim); Lucy yong Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Interesting observation. Could you explain a bit more how to avoid setup = of a PW in this scenario? Or could you just point to the exact sentences = in your I-D?=20 -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Monday, May 07, 2012 3:11 PM To: Jiangyuanlong; Rogers, Josh; Fedyk, Donald (Don); Henderickx, Wim = (Wim); Lucy yong Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? It seems to be that the optimization required to avoid unnecessary = transmission of leaf-only traffic over the network is significantly more = complex in the 2-VLAN solution, as you need the data plane to maintain = per-PW "leaf-onlyness" information (whether a specific PW leads to a = leaf-only PE or not) to decide when to drop these frames, whereas in the = multi-PW solution this is handled solely by the control plane (by = avoiding the setup of a PW in this scenario). DC -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Monday, May 07, 2012 9:34 AM To: Rogers, Josh; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim = (Wim); Lucy yong Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com]=20 Sent: Monday, May 07, 2012 12:09 PM To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim = (Wim); Lucy yong Cc: l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? So, if you can imagine three PE's, PE1, PE2 and PE3. PE1 has a root AC, R1 and a leaf AC, L1. PE2 also has a root AC, R2, and a leaf AC, L2. = PE3 has a leaf AC, L3. Consider an unknown unicast frame from the leaf site L1, and also = another unknown unicast frame from R1 entering. With the 2VLAN method (to my best understanding): - frame from L1 enters PE1, goes into a PW to PE2 and a PW to PE3, arrives at PE2 which decides that it should be flooded out all Root = AC's, based on the S-tag. It also arrives at PE3, where it is dropped because there are no root AC's. [JY] Since PE3 is a leaf-only node, the PW from PE1 to PE3 will work in = Optimized-Mode. According to Section 5.3.3 of = draft-jiang-l2vpn-vpls-pe-etree-05, it will be dropped before arriving = at this PW. Therefore, this frame will not arrive at PE3. - frame from R1 enters PE1, goes into a PW to PE2 and a PW to PE3, arrives at PE2 which decides that it should be flooded out all AC's, = based on S-tag. It also arrives at PE3 where it is forwarded to all root = AC's. With Multi-PW method: - frame from L1 enters PE1, which decides to forward the frame out the 'root' PW to PE2, which in turn floods out all Root AC's, based on arriving PW type. Frame is NOT sent to PE3, since there is no PW built = to the PE which has no root AC's. [JY] According to my understanding of the following description in = draft-ram-l2vpn-etree-multiple-pw-01: "It should be noted that in a full-mesh VPLS (as opposed to H-VPLS), the following VSI pair types do not require two interconnecting PWs: Root-only VSI <-> any VSI: only root PW required Leaf-only VSI <-> leaf-only VSI: no PWs required" There should be 2 PWs be set up between PE1 and PE3, since this is a = case of "Root & Leaf mixed VSI <-> leaf-only VSI" and not listed in the = none-two- interconnecting-PWs criteria. Therefore, this frame will be = sent to PE3 twice (one on root PW, another on leaf PW) IMO. Of course, = the other authors of draft-ram-l2vpn-etree-multiple-pw-01 may have more = to say on this point. - frame from R1 enters PE1, which decides to flood out both 'root' PW and 'leaf' PW to PE2, which in turn floods out the same AC types, based = on arriving PW type. It also arrives at PE3 where it is forwarded to all root AC's. [JY] It contradicts your first statement that "there is no PW built to = the PE which has no root AC's".=20 I suppose optimization could be done on the ingress PE to decide that there is no need to 'flood' root-sourced frames to two PW's that have = the same egress PE, but instead to only forward to the 'root' type PW, when both exist, because we know that the egress PE will flood frames from root-sourced PW's out both leaf and root AC's. In this example, the same frame from R1 is duplicated on the PE1-PE2 = path (if no optimization is done.), where it would not be with the 2VLAN = method. With 2VLAN, ethernet type PW's cannot be used (must be vlan type PW's, otherwise how would we classify source AC-type?), which means there is overhead on EVERY frame to add the s-tag for the sole purpose of classifying the frame. If optimization is done, then each ingress PE knows what types of AC's are on each egress PE, and only forwards the appropriate frame, if no optimization then it is dropped at the egress = PE. In short, both are either not 100% inefficient, or are additionally complex due to 'optimization'. I may have gotten my details off on the optimization piece of the 2VLAN method, please correct me if I didn't get the details 100% correct. -Josh On 5/6/12 9:07 PM, "Jiangyuanlong" wrote: >Could you or any other co-authors of 2PW give some more hints so that = it >can be better understood? > >In draft-ram-l2vpn-etree-multiple-pw-01, I can only find a single >sentence most to the point: > "An egress PE SHALL NOT deliver a frame originated at a leaf AC to > another leaf AC." > >But it seems there is not a description of "traffic is split/separated >(by psuedowire) on the ingress PE" at all. > >On the contrary, in draft-jiang-l2vpn-vpls-pe-etree-05, Section 5.3.3 >details the scenario and forwarding plane how the leaf traffic is >seperated and filtered on the ingress PE, and Section 6 details the >specific supports in the control plane. > >Thanks >Yuanlong > > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Friday, May 04, 2012 8:27 PM >To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >(Wim); Lucy yong >Cc: l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >also separate the leaf traffic in the ingress PE and filter it there >(already detailed in the Optimization Mode in the I-D); if the egress = PE >is attached with pure roots or with both roots and leafs, it seems all >traffic must be transported to the egress PE and be filtered there, I = see >no difference in behaviour for these solutions. Or did I miss = something? > > >The point is with the multi-PW method the traffic is split/separated = (by >psuedowire) on the ingress PE, rather than the egress. The distinction = is >2VLAN will 'classify' the frame on the ingress PE, so that the egress = PE >knows how to forward it to the appropriate AC's. > >Both methods have inefficiencies (one duplicates traffic for transport, >while the other transports where it doesn't need to go). I like the = idea >of classify and forwarding on the ingress PE, rather than marking it on >the ingress, and deciding on the egress. > >-Josh > > > >On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: > >>Josh, thank you for the comments, please see my further comments with >>[JY2]. >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Thursday, May 03, 2012 11:27 PM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>requirements from MEF, it has nothing to do with the solutions. Could = you >>give a hint on how you can provision this service E-NNI otherwise? = BTW, >>if >>configuring or signalling two PWs is not a problem, why configuring or >>signalling two VLANs will become a problem? After all, more nodes may >>need >>to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >>2VLAN (only T-PEs). >> >> >>There is no other way (if both MPLS domains are part of the same = ETREE, >>rather than doing something more like H-VPLS, where one domain has = point >>to points to the other domain which handles the ETREE instance) if you >>are >>using an ENNI. The other method, (not mentioned earlier) is tying the >>two >>MPLS domains together via labeled unicast (much preferred over E-NNI = in >>my >>opinion) >> >>Configuring two VLAN's isn't really a 'problem' any more than two = PW's. >>I >>wasn't saying that configuring two VLAN's was difficult, I was = objecting >>to the statement that configuring two PW's is difficult. >> >>[JY2] Thanks, I see your point. I take the example of 2PW = configuration >>just to show that using fixed global values to simplify configuration >>makes no sense. Personally I also don't think configuration is a = problem >>for both solutions. >> >>I find the differences between these two methods rather slight. The >>'tie-breaker' for me is by placing the forwarding decision on the = ingress >>PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you = get >>more control over where the traffic goes, and in my mind it provides a >>cleaner destination between customer traffic and forwarding plane. = I'm >>accustomed to looking at a psuedowire and knowing where its going, = with >>the 2vlan method, I can see the psuedowire, but must go to the egress = PE >>to see if it will be dropped there, or forwarded to one or more AC's. >> >>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>also separate the leaf traffic in the ingress PE and filter it there >>(already detailed in the Optimization Mode in the I-D); if the egress = PE >>is attached with pure roots or with both roots and leafs, it seems all >>traffic must be transported to the egress PE and be filtered there, I = see >>no difference in behaviour for these solutions. Or did I miss = something? >> >>Again, the difference here is slight, and I would honestly be happy to >>see >>either of them come to fruition. Please don't infer that I think the >>2vlan method is 'bad' or has intrinsic problems, because I don't = believe >>that. I just prefer the multi-PW method. >> >> >>-Josh >> >> >>On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: >> >>>Josh, please see my comments in line. >>> >>>Thanks >>>Yuanlong >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Thursday, May 03, 2012 10:51 AM >>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>(Wim); Lucy yong >>>Cc: l2vpn@ietf.org >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Yuanlong, >>> >>>Or better yet, include in the draft a 'standard' value for root = sourced >>>VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You would = also >>>have to require the the implementation NOT use global VLAN's, however >>>(since each instance would be using the same values). In this way, = no >>>signaling or manual configuration is required for remote PE's to know >>>how >>>to classify traffic. >>>[JY] Indeed, we discussed this possibility during the f2f meeting in >>>Paris. But, there are some restrictions as you mentioned, and >>>furthermore: >>>1) Some vendors already used S-VLAN to distinguish their VSIs in the = PE; >>>2) Forwarding plane of a PE needs to be revised to be aware of this = VLAN >>>ID. >>>Therefore, this 'standard value' approach seems more disruptive = compared >>>with the other means and not a good candidate option. >>> >>>Regarding switching PE's=A9 Multi-PW means more than one PW, yes. I >>>don't >>>see this as a real problem. In general, design should try and avoid >>>using >>>S-PE's, but if you must, its going to mean extra work, no matter how = you >>>look at it. Two PW's for each Etree being switched instead of one is >>>not >>>alarming or concerning to me. On the other hand, if you use a dot1q >>>(E-NNI) between MPLS domains, you have to deal with two ingress = VLAN's >>>an >>>two egress VLAN's if you want the Etree to be handled on both sides = (and >>>if you use the 'standard' VID's as I mentioned above, you'd have to = do >>>mapping to non-standard and back) >>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the = service >>>requirements from MEF, it has nothing to do with the solutions. Could >>>you >>>give a hint on how you can provision this service E-NNI otherwise? = BTW, >>>if configuring or signalling two PWs is not a problem, why = configuring >>>or >>>signalling two VLANs will become a problem? After all, more nodes may >>>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>>with 2VLAN (only T-PEs). >>> >>>In general, I still prefer multi-PW, primarily because I prefer the >>>separation of the traffic in the network's forwarding plane, rather = than >>>shipping it everywhere and deciding whether to forward to the AC when = it >>>gets to the egress PE. I'm having a hard time putting my finger = exactly >>>on what it is, or articulating the idea, but it seems that by having = the >>>traffic placed into two psuedowires, I have more flexibility and ease = of >>>configuration when it comes to E-NNI's, service multiplexed UNI's, = and >>>H-VPLS (both psuedowire based and vlan based). Of course my 'ease = of >>>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup = of >>>PW's could really change that perception. >>>[JY] Are you saying that we need to develop a totally new forwarding >>>plane rather than using the Ethernet forwarding plane as described in >>>the >>>existing work? >>> >>>I hope we can move forward with one of these soon, >>>[JY] me too. >>> >>>Josh >>> >>> >>>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >>> >>>>Daniel, >>>> >>>>Not aware that we had a discussion on this before, but IMHO the >>>>allocation of internal S-VLAN can be automatic, and manuel >>>>configuration >>>>of this mapping may not be needed at all. For example, an S-VLAN >>>>allocation module in the management plane in a PE can do this kind = of >>>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>>single external S-VLAN ID) in a topdown, bottom-up, or just any = random >>>>way from a free S-VLAN ID pool. Once the interal S-VLANs are = allocated, >>>>the mapping is determined and no other configuration is needed. >>>> >>>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>>allocate >>>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to = allocate >>>>two S-VLANs in the VPLS domain. >>>> >>>>On the other hand, for the multi-PW approach, two PWs need to be >>>>configured for a E-Tree service. When MS-PW is used in the network, = for >>>>every S-PE, we need to configure two ingress PW segments and two = egress >>>>PW segments. In this case, I don't think we need to use fixed PW = labels >>>>across the network for fear of configuration complexity. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 8:01 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Inline. >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 12:30 PM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy = yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, Please see my comments in line. >>>> >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 3:55 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Yuanlong, >>>> >>>>The problem is not with the total number of S-VLAN IDs, I agree that >>>>normally there won't be more than 2047. The problem is that if you >>>>don't >>>>support all VLAN IDs, you need S-VLAN space coordination with the >>>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to >>>>2047". >>>>Which won't always be in line with an existing deployment. >>>>[JY] This is not the case. If the total number is no more than 2047, = it >>>>surely can be supported. The S-VLAN space of user domain is totally >>>>different from the S-VLAN in the provider domain and they can be >>>>overlapped, I don't see why we need S-VLAN space coordination = between >>>>them. >>>> >>>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>>fixed, and therefore the IEEE S-VID that can be supported is also >>>>fixed. >>>> >>>>Of course you can configure the mapping in each PE according to >>>>operator >>>>requirements but as we discussed before this increases complexity. >>>> >>>>Relying on PBB-VPLS imposes additional limitations on backward >>>>compatibility. >>>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, = I >>>>think they may well need MAC-in-MAC in their networks for the >>>>scalability issue. As you know, only PBB VPLS can provide both. >>>> >>>>Daniel >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 5:07 AM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy = yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, >>>> >>>>As you can see, both cases are discussed in the I-D. >>>> >>>>With regard to case 1) (that is, S-VLAN translation), since the = access >>>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>>they need to be configured on a PE anyway, and as the past emails by >>>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by = 1:1 >>>>mapping. >>>> >>>>With regard to S-VID space reduction, the constraint is valid only = when >>>>a global VLAN space is used per PE, in fact, multi-VLAN space is = more >>>>typical and with no such limits as we already discussed in the f2f >>>>meeting. >>>> >>>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>>described (not sure this is a valid use case in real life), PBB-VPLS >>>>can >>>>still be used. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Monday, April 30, 2012 10:34 PM >>>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>Jiangyuanlong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>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] >>>>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 >>>> >>>>---------------------------------------------------------------------= - >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or = subject >>>to >>>copyright belonging to Time Warner Cable. This E-mail is intended = solely >>>for the use of the individual or entity to which it is addressed. If = you >>>are not the intended recipient of this E-mail, you are hereby = notified >>>that any dissemination, distribution, copying, or action taken in >>>relation to the contents of and attachments to this E-mail is = strictly >>>prohibited and may be unlawful. If you have received this 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 and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = 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 Mon May 7 01:34: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 7E88221F8474 for ; Mon, 7 May 2012 01:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.155 X-Spam-Level: X-Spam-Status: No, score=-2.155 tagged_above=-999 required=5 tests=[AWL=-0.156, 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 75Vvs-ADBOux for ; Mon, 7 May 2012 01:34:00 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1391721F8470 for ; Mon, 7 May 2012 01:34: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 AFO83222; Mon, 07 May 2012 04:33:59 -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; Mon, 7 May 2012 01:31:36 -0700 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 7 May 2012 01:31:37 -0700 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.183]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0323.003; Mon, 7 May 2012 16:31:23 +0800 From: Jiangyuanlong To: Daniel Cohn , "Rogers, Josh" , "Fedyk, Donald (Don)" , "Henderickx, Wim (Wim)" , 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: AQHNI1NEA18PKDoBDEy6zAcXiVu2LpasuNMAgAYGiYCAAAzygIAAAjQAgAAAAYCAAASFAIAAAOoAgAAYGACAAAPTgIACzjKAgABsbmCAABSDMIAAJEvQgADhaeD//53EgIAAk10ggAA/vACAASTWUIAAOyKAgAR+CPD//633gIAApnLQgAAMX9CAABMbsIAABKzAgAABg5A= Date: Mon, 7 May 2012 08:31:23 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D4107B9@szxeml546-mbx.china.huawei.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D4106B5@szxeml546-mbx.china.huawei.com> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410770@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780C8C7@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D41079C@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780C8ED@tlvmail1> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA08130780C8ED@tlvmail1> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.40.73] Content-Type: text/plain; charset="iso-8859-2" 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, 07 May 2012 08:34:02 -0000 It seems you had overlooked my replies to Josh. Actually, the case of PE1-P= E3 as Josh described is "Root & Leaf mixed VSI <-> leaf-only VSI" and not l= isted in your guidelines. But even if the guideline is complemented with this case, and no PW is set = up between PE1 and PE3 as you said, how can you send root traffic (R1) from= PE1 to PE3? And how can you send the leaf traffic (L3) from PE3 to PE1? -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Monday, May 07, 2012 4:20 PM To: Jiangyuanlong; Rogers, Josh; Fedyk, Donald (Don); Henderickx, Wim (Wim)= ; Lucy yong Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? In LDP, where PWs are established by the operator, it's part of the provisi= oning process. Section 6.2 provides guidelines, as follows: It should be noted that in a full-mesh VPLS (as opposed to H-VPLS), the following VSI pair types do not require two interconnecting PWs: Root-only VSI <-> any VSI: only root PW required Leaf-only VSI <-> leaf-only VSI: no PWs required Where root-only VSI is a VSI where all ACs are of the root type, and leaf-only VSI is one where all ACs are of the leaf type. Typically the NMS takes care of PW setup in LDP-VPLS so this would be part = of the NMS logic. In BGP, this can be part of the PW signaling logic following leaf-only sign= aling in the control flags (see sections 7.3 and 7.4). As you can see this = was not defined in this version but it's a simple extension of the same log= ic that avoid PW setup between leaf-only PEs. Regards, Daniel -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Monday, May 07, 2012 11:06 AM To: Daniel Cohn; Rogers, Josh; Fedyk, Donald (Don); Henderickx, Wim (Wim); = Lucy yong Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Interesting observation. Could you explain a bit more how to avoid setup of= a PW in this scenario? Or could you just point to the exact sentences in y= our I-D?=20 -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Monday, May 07, 2012 3:11 PM To: Jiangyuanlong; Rogers, Josh; Fedyk, Donald (Don); Henderickx, Wim (Wim)= ; Lucy yong Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? It seems to be that the optimization required to avoid unnecessary transmis= sion of leaf-only traffic over the network is significantly more complex in= the 2-VLAN solution, as you need the data plane to maintain per-PW "leaf-o= nlyness" information (whether a specific PW leads to a leaf-only PE or not)= to decide when to drop these frames, whereas in the multi-PW solution this= is handled solely by the control plane (by avoiding the setup of a PW in t= his scenario). DC -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Monday, May 07, 2012 9:34 AM To: Rogers, Josh; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); = Lucy yong Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com]=20 Sent: Monday, May 07, 2012 12:09 PM To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim);= Lucy yong Cc: l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? So, if you can imagine three PE's, PE1, PE2 and PE3. PE1 has a root AC, R1 and a leaf AC, L1. PE2 also has a root AC, R2, and a leaf AC, L2. PE3 has a leaf AC, L3. Consider an unknown unicast frame from the leaf site L1, and also another unknown unicast frame from R1 entering. With the 2VLAN method (to my best understanding): - frame from L1 enters PE1, goes into a PW to PE2 and a PW to PE3, arrives at PE2 which decides that it should be flooded out all Root AC's, based on the S-tag. It also arrives at PE3, where it is dropped because there are no root AC's. [JY] Since PE3 is a leaf-only node, the PW from PE1 to PE3 will work in Opt= imized-Mode. According to Section 5.3.3 of draft-jiang-l2vpn-vpls-pe-etree-= 05, it will be dropped before arriving at this PW. Therefore, this frame wi= ll not arrive at PE3. - frame from R1 enters PE1, goes into a PW to PE2 and a PW to PE3, arrives at PE2 which decides that it should be flooded out all AC's, based on S-tag. It also arrives at PE3 where it is forwarded to all root AC's. With Multi-PW method: - frame from L1 enters PE1, which decides to forward the frame out the 'root' PW to PE2, which in turn floods out all Root AC's, based on arriving PW type. Frame is NOT sent to PE3, since there is no PW built to the PE which has no root AC's. [JY] According to my understanding of the following description in draft-ra= m-l2vpn-etree-multiple-pw-01: "It should be noted that in a full-mesh VPLS (as opposed to H-VPLS), the following VSI pair types do not require two interconnecting PWs: Root-only VSI <-> any VSI: only root PW required Leaf-only VSI <-> leaf-only VSI: no PWs required" There should be 2 PWs be set up between PE1 and PE3, since this is a case o= f "Root & Leaf mixed VSI <-> leaf-only VSI" and not listed in the none-two-= interconnecting-PWs criteria. Therefore, this frame will be sent to PE3 tw= ice (one on root PW, another on leaf PW) IMO. Of course, the other authors = of draft-ram-l2vpn-etree-multiple-pw-01 may have more to say on this point. - frame from R1 enters PE1, which decides to flood out both 'root' PW and 'leaf' PW to PE2, which in turn floods out the same AC types, based on arriving PW type. It also arrives at PE3 where it is forwarded to all root AC's. [JY] It contradicts your first statement that "there is no PW built to the = PE which has no root AC's".=20 I suppose optimization could be done on the ingress PE to decide that there is no need to 'flood' root-sourced frames to two PW's that have the same egress PE, but instead to only forward to the 'root' type PW, when both exist, because we know that the egress PE will flood frames from root-sourced PW's out both leaf and root AC's. In this example, the same frame from R1 is duplicated on the PE1-PE2 path (if no optimization is done.), where it would not be with the 2VLAN method. With 2VLAN, ethernet type PW's cannot be used (must be vlan type PW's, otherwise how would we classify source AC-type?), which means there is overhead on EVERY frame to add the s-tag for the sole purpose of classifying the frame. If optimization is done, then each ingress PE knows what types of AC's are on each egress PE, and only forwards the appropriate frame, if no optimization then it is dropped at the egress PE. In short, both are either not 100% inefficient, or are additionally complex due to 'optimization'. I may have gotten my details off on the optimization piece of the 2VLAN method, please correct me if I didn't get the details 100% correct. -Josh On 5/6/12 9:07 PM, "Jiangyuanlong" wrote: >Could you or any other co-authors of 2PW give some more hints so that it >can be better understood? > >In draft-ram-l2vpn-etree-multiple-pw-01, I can only find a single >sentence most to the point: > "An egress PE SHALL NOT deliver a frame originated at a leaf AC to > another leaf AC." > >But it seems there is not a description of "traffic is split/separated >(by psuedowire) on the ingress PE" at all. > >On the contrary, in draft-jiang-l2vpn-vpls-pe-etree-05, Section 5.3.3 >details the scenario and forwarding plane how the leaf traffic is >seperated and filtered on the ingress PE, and Section 6 details the >specific supports in the control plane. > >Thanks >Yuanlong > > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Friday, May 04, 2012 8:27 PM >To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >(Wim); Lucy yong >Cc: l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >also separate the leaf traffic in the ingress PE and filter it there >(already detailed in the Optimization Mode in the I-D); if the egress PE >is attached with pure roots or with both roots and leafs, it seems all >traffic must be transported to the egress PE and be filtered there, I see >no difference in behaviour for these solutions. Or did I miss something? > > >The point is with the multi-PW method the traffic is split/separated (by >psuedowire) on the ingress PE, rather than the egress. The distinction is >2VLAN will 'classify' the frame on the ingress PE, so that the egress PE >knows how to forward it to the appropriate AC's. > >Both methods have inefficiencies (one duplicates traffic for transport, >while the other transports where it doesn't need to go). I like the idea >of classify and forwarding on the ingress PE, rather than marking it on >the ingress, and deciding on the egress. > >-Josh > > > >On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: > >>Josh, thank you for the comments, please see my further comments with >>[JY2]. >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Thursday, May 03, 2012 11:27 PM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>requirements from MEF, it has nothing to do with the solutions. Could you >>give a hint on how you can provision this service E-NNI otherwise? BTW, >>if >>configuring or signalling two PWs is not a problem, why configuring or >>signalling two VLANs will become a problem? After all, more nodes may >>need >>to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >>2VLAN (only T-PEs). >> >> >>There is no other way (if both MPLS domains are part of the same ETREE, >>rather than doing something more like H-VPLS, where one domain has point >>to points to the other domain which handles the ETREE instance) if you >>are >>using an ENNI. The other method, (not mentioned earlier) is tying the >>two >>MPLS domains together via labeled unicast (much preferred over E-NNI in >>my >>opinion) >> >>Configuring two VLAN's isn't really a 'problem' any more than two PW's. >>I >>wasn't saying that configuring two VLAN's was difficult, I was objecting >>to the statement that configuring two PW's is difficult. >> >>[JY2] Thanks, I see your point. I take the example of 2PW configuration >>just to show that using fixed global values to simplify configuration >>makes no sense. Personally I also don't think configuration is a problem >>for both solutions. >> >>I find the differences between these two methods rather slight. The >>'tie-breaker' for me is by placing the forwarding decision on the ingress >>PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >>more control over where the traffic goes, and in my mind it provides a >>cleaner destination between customer traffic and forwarding plane. I'm >>accustomed to looking at a psuedowire and knowing where its going, with >>the 2vlan method, I can see the psuedowire, but must go to the egress PE >>to see if it will be dropped there, or forwarded to one or more AC's. >> >>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>also separate the leaf traffic in the ingress PE and filter it there >>(already detailed in the Optimization Mode in the I-D); if the egress PE >>is attached with pure roots or with both roots and leafs, it seems all >>traffic must be transported to the egress PE and be filtered there, I see >>no difference in behaviour for these solutions. Or did I miss something? >> >>Again, the difference here is slight, and I would honestly be happy to >>see >>either of them come to fruition. Please don't infer that I think the >>2vlan method is 'bad' or has intrinsic problems, because I don't believe >>that. I just prefer the multi-PW method. >> >> >>-Josh >> >> >>On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: >> >>>Josh, please see my comments in line. >>> >>>Thanks >>>Yuanlong >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Thursday, May 03, 2012 10:51 AM >>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>(Wim); Lucy yong >>>Cc: l2vpn@ietf.org >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Yuanlong, >>> >>>Or better yet, include in the draft a 'standard' value for root sourced >>>VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You would al= so >>>have to require the the implementation NOT use global VLAN's, however >>>(since each instance would be using the same values). In this way, no >>>signaling or manual configuration is required for remote PE's to know >>>how >>>to classify traffic. >>>[JY] Indeed, we discussed this possibility during the f2f meeting in >>>Paris. But, there are some restrictions as you mentioned, and >>>furthermore: >>>1) Some vendors already used S-VLAN to distinguish their VSIs in the PE; >>>2) Forwarding plane of a PE needs to be revised to be aware of this VLAN >>>ID. >>>Therefore, this 'standard value' approach seems more disruptive compared >>>with the other means and not a good candidate option. >>> >>>Regarding switching PE's=A9 Multi-PW means more than one PW, yes. I >>>don't >>>see this as a real problem. In general, design should try and avoid >>>using >>>S-PE's, but if you must, its going to mean extra work, no matter how you >>>look at it. Two PW's for each Etree being switched instead of one is >>>not >>>alarming or concerning to me. On the other hand, if you use a dot1q >>>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's >>>an >>>two egress VLAN's if you want the Etree to be handled on both sides (and >>>if you use the 'standard' VID's as I mentioned above, you'd have to do >>>mapping to non-standard and back) >>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>requirements from MEF, it has nothing to do with the solutions. Could >>>you >>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>if configuring or signalling two PWs is not a problem, why configuring >>>or >>>signalling two VLANs will become a problem? After all, more nodes may >>>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>>with 2VLAN (only T-PEs). >>> >>>In general, I still prefer multi-PW, primarily because I prefer the >>>separation of the traffic in the network's forwarding plane, rather than >>>shipping it everywhere and deciding whether to forward to the AC when it >>>gets to the egress PE. I'm having a hard time putting my finger exactly >>>on what it is, or articulating the idea, but it seems that by having the >>>traffic placed into two psuedowires, I have more flexibility and ease of >>>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>>PW's could really change that perception. >>>[JY] Are you saying that we need to develop a totally new forwarding >>>plane rather than using the Ethernet forwarding plane as described in >>>the >>>existing work? >>> >>>I hope we can move forward with one of these soon, >>>[JY] me too. >>> >>>Josh >>> >>> >>>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >>> >>>>Daniel, >>>> >>>>Not aware that we had a discussion on this before, but IMHO the >>>>allocation of internal S-VLAN can be automatic, and manuel >>>>configuration >>>>of this mapping may not be needed at all. For example, an S-VLAN >>>>allocation module in the management plane in a PE can do this kind of >>>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>>way from a free S-VLAN ID pool. Once the interal S-VLANs are allocated, >>>>the mapping is determined and no other configuration is needed. >>>> >>>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>>allocate >>>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to allocate >>>>two S-VLANs in the VPLS domain. >>>> >>>>On the other hand, for the multi-PW approach, two PWs need to be >>>>configured for a E-Tree service. When MS-PW is used in the network, for >>>>every S-PE, we need to configure two ingress PW segments and two egress >>>>PW segments. In this case, I don't think we need to use fixed PW labels >>>>across the network for fear of configuration complexity. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 8:01 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Inline. >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 12:30 PM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, Please see my comments in line. >>>> >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 3:55 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Yuanlong, >>>> >>>>The problem is not with the total number of S-VLAN IDs, I agree that >>>>normally there won't be more than 2047. The problem is that if you >>>>don't >>>>support all VLAN IDs, you need S-VLAN space coordination with the >>>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to >>>>2047". >>>>Which won't always be in line with an existing deployment. >>>>[JY] This is not the case. If the total number is no more than 2047, it >>>>surely can be supported. The S-VLAN space of user domain is totally >>>>different from the S-VLAN in the provider domain and they can be >>>>overlapped, I don't see why we need S-VLAN space coordination between >>>>them. >>>> >>>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>>fixed, and therefore the IEEE S-VID that can be supported is also >>>>fixed. >>>> >>>>Of course you can configure the mapping in each PE according to >>>>operator >>>>requirements but as we discussed before this increases complexity. >>>> >>>>Relying on PBB-VPLS imposes additional limitations on backward >>>>compatibility. >>>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>>think they may well need MAC-in-MAC in their networks for the >>>>scalability issue. As you know, only PBB VPLS can provide both. >>>> >>>>Daniel >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 5:07 AM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, >>>> >>>>As you can see, both cases are discussed in the I-D. >>>> >>>>With regard to case 1) (that is, S-VLAN translation), since the access >>>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>>they need to be configured on a PE anyway, and as the past emails by >>>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>>mapping. >>>> >>>>With regard to S-VID space reduction, the constraint is valid only when >>>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>>typical and with no such limits as we already discussed in the f2f >>>>meeting. >>>> >>>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>>described (not sure this is a valid use case in real life), PBB-VPLS >>>>can >>>>still be used. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Monday, April 30, 2012 10:34 PM >>>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>Jiangyuanlong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>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] >>>>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 >>>> >>>>---------------------------------------------------------------------- >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to >>>copyright belonging to Time Warner Cable. This E-mail is intended solely >>>for the use of the individual or entity to which it is addressed. If you >>>are not the intended recipient of this E-mail, you are hereby notified >>>that any dissemination, distribution, copying, or action taken in >>>relation to the contents of and attachments to this E-mail is strictly >>>prohibited and may be unlawful. If you have received this 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 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 May 7 08:21: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 E8D4121F848B for ; Mon, 7 May 2012 08:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.253 X-Spam-Level: X-Spam-Status: No, score=-2.253 tagged_above=-999 required=5 tests=[AWL=-0.254, 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 HbtAL7+F+urz for ; Mon, 7 May 2012 08:21:10 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id D86B321F8471 for ; Mon, 7 May 2012 08:21:09 -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 AFX07703; Mon, 07 May 2012 11:21:09 -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, 7 May 2012 08:19:21 -0700 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.003; Mon, 7 May 2012 08:19:04 -0700 From: Lucy yong To: Aldrin Isaac Subject: RE: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0oo3KJO48LuIhSPkS8Et2e3RTHugARqg4SAAf687wAETa4GgAG6vgwADqVW84AgltJsA== Date: Mon, 7 May 2012 15:19:04 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D330F0566@dfweml506-mbx> References: <2691CE0099834E4A9C5044EEC662BB9D330E8F11@dfweml505-mbx> <2E819CEF-4A49-439B-86DF-C17503A75398@gmail.com> <2691CE0099834E4A9C5044EEC662BB9D330E918C@dfweml505-mbx> <03B0FD5F-D9F5-4C4E-A7FD-0A2C36A7B092@gmail.com> In-Reply-To: <03B0FD5F-D9F5-4C4E-A7FD-0A2C36A7B092@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.149.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l2vpn@ietf.org" , sajassi 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, 07 May 2012 15:21:11 -0000 Hi Aldrin, Thank you very for sharing your insight. It is great and very helpful. It i= s fine to add new service features on existing services. In fact, that is w= hat we are working on in IETF. =20 >From customer perspective, E-VPN supports all existing VPLS capability and = add active-active mode and some policy based-topology control. It is useful= extension. SPT based LAN is the history technology. LAG, MSTP, TRILL, SPB = etc are all the replacement solutions.=20 One thing that I am not clear from your reply is that the policy for L2VPN = is to be against VLAN or MAC? The latter will be very complex and not scale. The former will have some ad= ditional challenges and complex because VLAN ID may not be global based ID = like IP addresses and L2VPN forwarding is based on MAC address while policy= control is based on VLAN. Do I understand this right? IMO: simplification is also important work for IETF and benefit to business= es as silicon technology improving. Without it, we have some limited room f= or adding new useful features and the system will be overly complex so nobo= dy can afford operating it. This does not say E-VPN. Thanks again. Lucy -----Original Message----- From: Aldrin Isaac [mailto:aldrin.isaac@gmail.com]=20 Sent: Friday, May 04, 2012 7:20 PM To: Lucy yong Cc: sajassi; Giles Heron; Nabil Bitar; l2vpn@ietf.org Subject: Re: Interest in IS-IS VPLS Hi Lucy, Please see inline On May 4, 2012, at 11:07 AM, Lucy yong wrote: > Hi Isaac, >=20 > Thank you for the reply. Please see inline. >=20 > Regards, > Lucy >=20 > -----Original Message----- > From: Aldrin Isaac [mailto:aldrin.isaac@gmail.com]=20 > Sent: Thursday, May 03, 2012 10:50 PM > To: Lucy yong > Cc: sajassi; Giles Heron; Nabil Bitar; l2vpn@ietf.org > Subject: Re: Interest in IS-IS VPLS >=20 ...=20 > E-VPN also supports policy based-topologies versus simple point-to-point,= flat or tree VLANs. It can support point-to-point, tree, mesh, one-way, o= r pretty much any other "complex" or overlapped topologies (depending on ho= w you like to see it). An example is ability to natively recreate private = vlan, community vlan topologies (which happen to be quite common in DC netw= orks) and any number of combinations of these simultaneously to a single po= rt. A BGP E-VPN VPN is also decoupled from the edge EVI/ESI such that it i= s not limited to a single tenant/vlan but can span tenants/vlans (l2 extran= et) if so required. This is native to E-VPN. > [[LY]] Such policy based-topologies are useful for service provider netwo= rk, but may too complex for intra DCs. One reason that customers often want= to choose with L2VPN service is "it is simple". However, L3VPN have its ap= plications although some operators often complain the complexities to confi= gure these policies. Typical example is the a firewall only placed at a loc= ation. Could you share why operator want such policy based-topology for L2V= PN? Policy-based topologies are generally complex when used to interconnect IP = networks because there are generally multiple prefixes in a vrf, and often = different prefixes need to be associated to different VPNs or routing behav= ior. In the DC, L2VPN role is to interconnect host ports so the policies f= or basic are very simple --- list of import route targets and list of expor= t route targets where each import/export pair correspond to a VPN (tenant, = service, ...). An example of how a DC operator might use this for example = is to meet a requirement for private vlan and community vlans which are ver= y common for DMZs. Hopefully you are familiar with these very common use c= ases. It is even possible to recreate more complex switch "features" like = MVR (in addition to private VLANs which are also considered "features") usi= ng E-VPN. It took me three years to get the MVR feature into a particular = vendor's switch to meet a business need. I'll sacrifice plug-and-play simp= licity for business agility. I'm sure my peers are with me on this one. If simple "plug-and-play" is important, one could imagine RRs sending out a= n "RR TLV" such that RRs in an IGP area auto-connect with each other and RR= -clients connect to the closest RR based on SPF (some details like peer-gro= up, etc would need to be factored in to make it more powerful). Other BGP/= MPLS configuration is, IMHO, trivial unless you CHOOSE to use more advanced= capabilities (i.e. not locked in). =20 Maybe the reason why MPLS comes across as complex is because of how IETF de= als with requirements lately by creating point solutions. E-VPN tries to p= ut new capabilities on the table while trying not to take existing value of= f the table. There is no reason why a solution can't bring more value than= what the standards body calls for. > E-VPN supports interconnecting end-stations or interconnecting L2 network= s. Procedures to easily span STP based networks across an E-VPN network wi= thout loops comes with the base spec. Extensions to E-VPN, such as PBB-EVP= N, simplify the fully functional spanning of non-EVPN networks across an E-= VPN network. > [[LY]] current L2VPN support all these except active-active mode which ca= uses the loop. Base E-VPN spec will natively deal with the STP case through an active/stan= dby mode and BPDU-snooping -- detect root bridge and use that as ESI (ether= net segment id) to indicate unique STP network with active/standby bit set = to ensure only one forwarding link among links with same ESI. Tags (vlans)= can potentially each have a different active link within the member links = of an ESI allowing for automatic tag(tenant)/vlan level load-balancing into= an STP network. Edge networks that don't have mac-move issue will be able= to take full advantage of active-active load-balancing without need for LA= G/MLAG. > An SVI/IRB interface can also be a member of both an E-VPN EVI and an IP = VRF allowing for easily bringing together virtual L2 and L3 topologies anyw= here in the network without a physical port. > [[LY]] Could you please share how operator plan to use this? Which servic= e will you sell to customer in this case? The service will be where a customer wants to communicate to a destination = network that is not in his subnet. Operators most interested in EVPN alrea= dy have IPVPN services on their network. This is the gateway point between= the EVPN virtual networks and [existing] IPVPN virtual networks. No physi= cal port required. > E-VPN builds on top of years of work in the IETF; traffic engineering, sc= aling with route reflectors and RT constrain, multicast via NG-MVPN, etc. > [[LY]] Agree. These are useful features for service provider network. How= ever, these functions may not necessary within DC although they had been pr= oved works well.=20 I'm not sure how eventually re-inventing these capabilities (yes it will ha= ppen) on behalf of a new protocol will be better than simply leveraging pro= ven technology. Vendors don't need to implement every MPLS RFC ever writte= n to be able to implement the basic E-VPN. > Can also use IP for transport tunnel. But my understanding is that popul= ar merchant silicon has support for MPLS push/pop/swap these days (?). Thi= s was captured by EVPN at it's inception, which is why the PE is referred t= o as MES (MPLS-enabled switch) in E-VPN. > [[LY]] Yes, current draft aims on MPLS solution only. But it states the p= otential to extend to the use of IP tunnel.=20 > The way I see it, a major reason why STP-based LANS are fickle and don't = scale well is on account of insufficient decoupling of core from edge creat= ed by requirement for plug-and-play and how that played out over time. Con= versely the reason (among other things) why IP networks are more stable is = because they are not inherently plug-and-play, and with MPLS/BGP allows exc= ellent decoupling of core and edge. I don't know enough about TRILL or PBB= to comment on those -- I just know that I'm not interested for enough good= reasons. E-VPN enables a dynamic edge over a stable decoupled core while = giving each operator room for service differentiation. It is especially in= teresting to operators that have invested in MPLS technology and operations= . I can find a lot of folks that understand BGP/MPLS IPVPN and in short or= der have them know the ins and outs of basic E-VPN. It's quite hard for me= to find non-vendor folk who really actually understand the other technolog= ies used to span Ethernet aside from basic STP.=20 > [[LY]] Thank you to share this in the mailing list.=20 >=20 > This is an operator perspective. > [[LY]] This is great! >=20 >=20 > On May 3, 2012, at 4:31 PM, Lucy yong wrote: >=20 >> Hi Ali, >>=20 >>=20 >> "5. Ethernet VPN (E-VPN) - An enhanced Layer-2 service that >> emulates an Ethernet (V)LAN across a PSN. E-VPN supports >> load-sharing across multiple connections from a Layer-2 site >> to an L2VPN service. E-VPN is primarily targeted to support >> large-scale L2VPNs with resiliency requirements not satisfied >> by other L2VPN solutions" >>=20 >> [[LY]] IMO, E-VPN enhancement is to support multi-homing with active-act= ive mode. Load-sharing across multiple connections from a layer-2 site is d= esired when this mode is used. Current VPLS can provide resiliency requirem= ent when the multi-homing site configured with active-standby mode. >>=20 >> Regards, >> Lucy >>=20 >> Cheers, >> Ali =20 >>=20 >=20 From ju1738@att.com Mon May 7 08:27: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 F358521F863B for ; Mon, 7 May 2012 08:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fg9stRnikyli for ; Mon, 7 May 2012 08:26:59 -0700 (PDT) Received: from nbfkord-smmo08.seg.att.com (nbfkord-smmo08.seg.att.com [209.65.160.95]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4E221F85D6 for ; Mon, 7 May 2012 08:26:52 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo08.seg.att.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.11.0-8) with ESMTP id cb9e7af4.5c399940.2366535.00-594.6483743.nbfkord-smmo08.seg.att.com (envelope-from ); Mon, 07 May 2012 15:26:52 +0000 (UTC) X-MXL-Hash: 4fa7e9bc1b6bcb69-a6597722b9eae0921289063cbd2183139ef104fa Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id ca9e7af4.0.2366472.00-420.6483551.nbfkord-smmo08.seg.att.com (envelope-from ); Mon, 07 May 2012 15:26:36 +0000 (UTC) X-MXL-Hash: 4fa7e9ac2534dfc9-c9238eab5aba43b767115aae80ad33d750017d36 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q47FQY2O011284; Mon, 7 May 2012 11:26:35 -0400 Received: from sflint03.pst.cso.att.com (sflint03.pst.cso.att.com [144.154.234.230]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q47FQPYE010987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 May 2012 11:26:28 -0400 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (misout7msghub9d.itservices.sbc.com [144.151.223.93]) by sflint03.pst.cso.att.com (RSA Interceptor); Mon, 7 May 2012 11:25:33 -0400 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([169.254.1.36]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.01.0355.002; Mon, 7 May 2012 11:25:33 -0400 From: "UTTARO, JAMES" To: "'Lucy yong'" , Aldrin Isaac Subject: RE: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0oo3KJO48LuIhSPkS8Et2e3RTHugARqg4SAAf687wAETa4GgAG6vgwADqVW84AgltJsAABx/sQ Date: Mon, 7 May 2012 15:25:33 +0000 Message-ID: References: <2691CE0099834E4A9C5044EEC662BB9D330E8F11@dfweml505-mbx> <2E819CEF-4A49-439B-86DF-C17503A75398@gmail.com> <2691CE0099834E4A9C5044EEC662BB9D330E918C@dfweml505-mbx> <03B0FD5F-D9F5-4C4E-A7FD-0A2C36A7B092@gmail.com> <2691CE0099834E4A9C5044EEC662BB9D330F0566@dfweml506-mbx> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D330F0566@dfweml506-mbx> 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="us-ascii" Content-Transfer-Encoding: quoted-printable 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.146] X-AnalysisOut: [v=1.0 c=1 a=g8Qva45Ca7EA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHo] X-AnalysisOut: [wA:10 a=kj9zAlcOel0A:10 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a=48] X-AnalysisOut: [vgC7mUAAAA:8 a=pGLkceISAAAA:8 a=qWAv7dLUj2B0GE1jYSwA:9 a=r] X-AnalysisOut: [aey3IH-Mk9hXaU_OS4A:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 ] X-AnalysisOut: [a=MSl-tDqOz04A:10 a=4zsLB58wCipz7x5_:21 a=ob-VofHOn00tOlpP] X-AnalysisOut: [:21] Cc: "l2vpn@ietf.org" , sajassi 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, 07 May 2012 15:27:02 -0000 Lucy, Comments In-Line.. Jim Uttaro -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of L= ucy yong Sent: Monday, May 07, 2012 11:19 AM To: Aldrin Isaac Cc: l2vpn@ietf.org; sajassi Subject: RE: Interest in IS-IS VPLS Hi Aldrin, Thank you very for sharing your insight. It is great and very helpful. It i= s fine to add new service features on existing services. In fact, that is w= hat we are working on in IETF. =20 >From customer perspective, E-VPN supports all existing VPLS capability and = add active-active mode and some policy based-topology control. It is useful= extension. SPT based LAN is the history technology. LAG, MSTP, TRILL, SPB = etc are all the replacement solutions.=20 One thing that I am not clear from your reply is that the policy for L2VPN = is to be against VLAN or MAC? The latter will be very complex and not scale. [Jim U>] In what ways is it too complex? In what ways does it not scale? The former will have some additional challenges and complex because VLAN I= D may not be global based ID like IP addresses and L2VPN forwarding is base= d on MAC address while policy control is based on VLAN. Do I understand thi= s right? IMO: simplification is also important work for IETF and benefit to business= es as silicon technology improving. Without it, we have some limited room f= or adding new useful features and the system will be overly complex so nobo= dy can afford operating it. This does not say E-VPN. Thanks again. Lucy -----Original Message----- From: Aldrin Isaac [mailto:aldrin.isaac@gmail.com]=20 Sent: Friday, May 04, 2012 7:20 PM To: Lucy yong Cc: sajassi; Giles Heron; Nabil Bitar; l2vpn@ietf.org Subject: Re: Interest in IS-IS VPLS Hi Lucy, Please see inline On May 4, 2012, at 11:07 AM, Lucy yong wrote: > Hi Isaac, >=20 > Thank you for the reply. Please see inline. >=20 > Regards, > Lucy >=20 > -----Original Message----- > From: Aldrin Isaac [mailto:aldrin.isaac@gmail.com]=20 > Sent: Thursday, May 03, 2012 10:50 PM > To: Lucy yong > Cc: sajassi; Giles Heron; Nabil Bitar; l2vpn@ietf.org > Subject: Re: Interest in IS-IS VPLS >=20 ...=20 > E-VPN also supports policy based-topologies versus simple point-to-point,= flat or tree VLANs. It can support point-to-point, tree, mesh, one-way, o= r pretty much any other "complex" or overlapped topologies (depending on ho= w you like to see it). An example is ability to natively recreate private = vlan, community vlan topologies (which happen to be quite common in DC netw= orks) and any number of combinations of these simultaneously to a single po= rt. A BGP E-VPN VPN is also decoupled from the edge EVI/ESI such that it i= s not limited to a single tenant/vlan but can span tenants/vlans (l2 extran= et) if so required. This is native to E-VPN. > [[LY]] Such policy based-topologies are useful for service provider netwo= rk, but may too complex for intra DCs. One reason that customers often want= to choose with L2VPN service is "it is simple". However, L3VPN have its ap= plications although some operators often complain the complexities to confi= gure these policies. Typical example is the a firewall only placed at a loc= ation. Could you share why operator want such policy based-topology for L2V= PN? Policy-based topologies are generally complex when used to interconnect IP = networks because there are generally multiple prefixes in a vrf, and often = different prefixes need to be associated to different VPNs or routing behav= ior. In the DC, L2VPN role is to interconnect host ports so the policies f= or basic are very simple --- list of import route targets and list of expor= t route targets where each import/export pair correspond to a VPN (tenant, = service, ...). An example of how a DC operator might use this for example = is to meet a requirement for private vlan and community vlans which are ver= y common for DMZs. Hopefully you are familiar with these very common use c= ases. It is even possible to recreate more complex switch "features" like = MVR (in addition to private VLANs which are also considered "features") usi= ng E-VPN. It took me three years to get the MVR feature into a particular = vendor's switch to meet a business need. I'll sacrifice plug-and-play simp= licity for business agility. I'm sure my peers are with me on this one. If simple "plug-and-play" is important, one could imagine RRs sending out a= n "RR TLV" such that RRs in an IGP area auto-connect with each other and RR= -clients connect to the closest RR based on SPF (some details like peer-gro= up, etc would need to be factored in to make it more powerful). Other BGP/= MPLS configuration is, IMHO, trivial unless you CHOOSE to use more advanced= capabilities (i.e. not locked in). =20 Maybe the reason why MPLS comes across as complex is because of how IETF de= als with requirements lately by creating point solutions. E-VPN tries to p= ut new capabilities on the table while trying not to take existing value of= f the table. There is no reason why a solution can't bring more value than= what the standards body calls for. > E-VPN supports interconnecting end-stations or interconnecting L2 network= s. Procedures to easily span STP based networks across an E-VPN network wi= thout loops comes with the base spec. Extensions to E-VPN, such as PBB-EVP= N, simplify the fully functional spanning of non-EVPN networks across an E-= VPN network. > [[LY]] current L2VPN support all these except active-active mode which ca= uses the loop. Base E-VPN spec will natively deal with the STP case through an active/stan= dby mode and BPDU-snooping -- detect root bridge and use that as ESI (ether= net segment id) to indicate unique STP network with active/standby bit set = to ensure only one forwarding link among links with same ESI. Tags (vlans)= can potentially each have a different active link within the member links = of an ESI allowing for automatic tag(tenant)/vlan level load-balancing into= an STP network. Edge networks that don't have mac-move issue will be able= to take full advantage of active-active load-balancing without need for LA= G/MLAG. > An SVI/IRB interface can also be a member of both an E-VPN EVI and an IP = VRF allowing for easily bringing together virtual L2 and L3 topologies anyw= here in the network without a physical port. > [[LY]] Could you please share how operator plan to use this? Which servic= e will you sell to customer in this case? The service will be where a customer wants to communicate to a destination = network that is not in his subnet. Operators most interested in EVPN alrea= dy have IPVPN services on their network. This is the gateway point between= the EVPN virtual networks and [existing] IPVPN virtual networks. No physi= cal port required. > E-VPN builds on top of years of work in the IETF; traffic engineering, sc= aling with route reflectors and RT constrain, multicast via NG-MVPN, etc. > [[LY]] Agree. These are useful features for service provider network. How= ever, these functions may not necessary within DC although they had been pr= oved works well.=20 I'm not sure how eventually re-inventing these capabilities (yes it will ha= ppen) on behalf of a new protocol will be better than simply leveraging pro= ven technology. Vendors don't need to implement every MPLS RFC ever writte= n to be able to implement the basic E-VPN. > Can also use IP for transport tunnel. But my understanding is that popul= ar merchant silicon has support for MPLS push/pop/swap these days (?). Thi= s was captured by EVPN at it's inception, which is why the PE is referred t= o as MES (MPLS-enabled switch) in E-VPN. > [[LY]] Yes, current draft aims on MPLS solution only. But it states the p= otential to extend to the use of IP tunnel.=20 > The way I see it, a major reason why STP-based LANS are fickle and don't = scale well is on account of insufficient decoupling of core from edge creat= ed by requirement for plug-and-play and how that played out over time. Con= versely the reason (among other things) why IP networks are more stable is = because they are not inherently plug-and-play, and with MPLS/BGP allows exc= ellent decoupling of core and edge. I don't know enough about TRILL or PBB= to comment on those -- I just know that I'm not interested for enough good= reasons. E-VPN enables a dynamic edge over a stable decoupled core while = giving each operator room for service differentiation. It is especially in= teresting to operators that have invested in MPLS technology and operations= . I can find a lot of folks that understand BGP/MPLS IPVPN and in short or= der have them know the ins and outs of basic E-VPN. It's quite hard for me= to find non-vendor folk who really actually understand the other technolog= ies used to span Ethernet aside from basic STP.=20 > [[LY]] Thank you to share this in the mailing list.=20 >=20 > This is an operator perspective. > [[LY]] This is great! >=20 >=20 > On May 3, 2012, at 4:31 PM, Lucy yong wrote: >=20 >> Hi Ali, >>=20 >>=20 >> "5. Ethernet VPN (E-VPN) - An enhanced Layer-2 service that >> emulates an Ethernet (V)LAN across a PSN. E-VPN supports >> load-sharing across multiple connections from a Layer-2 site >> to an L2VPN service. E-VPN is primarily targeted to support >> large-scale L2VPNs with resiliency requirements not satisfied >> by other L2VPN solutions" >>=20 >> [[LY]] IMO, E-VPN enhancement is to support multi-homing with active-act= ive mode. Load-sharing across multiple connections from a layer-2 site is d= esired when this mode is used. Current VPLS can provide resiliency requirem= ent when the multi-homing site configured with active-standby mode. >>=20 >> Regards, >> Lucy >>=20 >> Cheers, >> Ali =20 >>=20 >=20 From lucy.yong@huawei.com Mon May 7 08:40: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 5EC4721F85E1 for ; Mon, 7 May 2012 08:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.246 X-Spam-Level: X-Spam-Status: No, score=-2.246 tagged_above=-999 required=5 tests=[AWL=-0.247, 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 04C9wPZi4s7T for ; Mon, 7 May 2012 08:40:07 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 92E9621F862A for ; Mon, 7 May 2012 08:40:07 -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 AFX08861; Mon, 07 May 2012 11:40:06 -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, 7 May 2012 08:38:05 -0700 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Mon, 7 May 2012 08:38:00 -0700 From: Lucy yong To: "UTTARO, JAMES" , Aldrin Isaac Subject: RE: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0oo3KJO48LuIhSPkS8Et2e3RTHugARqg4SAAf687wAETa4GgAG6vgwADqVW84AgltJsAABx/sQAAAw3pA= Date: Mon, 7 May 2012 15:38:00 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D330F05A5@dfweml506-mbx> References: <2691CE0099834E4A9C5044EEC662BB9D330E8F11@dfweml505-mbx> <2E819CEF-4A49-439B-86DF-C17503A75398@gmail.com> <2691CE0099834E4A9C5044EEC662BB9D330E918C@dfweml505-mbx> <03B0FD5F-D9F5-4C4E-A7FD-0A2C36A7B092@gmail.com> <2691CE0099834E4A9C5044EEC662BB9D330F0566@dfweml506-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.149.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l2vpn@ietf.org" , sajassi 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, 07 May 2012 15:40:17 -0000 Hi James, One thing that I am not clear from your reply is that the policy for L2VPN = is to be against VLAN or MAC? The latter will be very complex and not scale. [Jim U>] In what ways is it too complex? In what ways does it not scale? IMO: MAC address can't be summarized. Policy per individual MAC address wil= l not scale. Host MAC may be from physical address or assigned to VM random= ly not like IP address administrated, which makes policy setting BIG burden= . I like to see operator insight on this. Do you plan to set the policy aga= inst MAC or VLAN? Thanks, Lucy -----Original Message----- From: UTTARO, JAMES [mailto:ju1738@att.com]=20 Sent: Monday, May 07, 2012 10:26 AM To: Lucy yong; Aldrin Isaac Cc: l2vpn@ietf.org; sajassi Subject: RE: Interest in IS-IS VPLS Lucy, Comments In-Line.. Jim Uttaro -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of L= ucy yong Sent: Monday, May 07, 2012 11:19 AM To: Aldrin Isaac Cc: l2vpn@ietf.org; sajassi Subject: RE: Interest in IS-IS VPLS Hi Aldrin, Thank you very for sharing your insight. It is great and very helpful. It i= s fine to add new service features on existing services. In fact, that is w= hat we are working on in IETF. =20 >From customer perspective, E-VPN supports all existing VPLS capability and = add active-active mode and some policy based-topology control. It is useful= extension. SPT based LAN is the history technology. LAG, MSTP, TRILL, SPB = etc are all the replacement solutions.=20 One thing that I am not clear from your reply is that the policy for L2VPN = is to be against VLAN or MAC? The latter will be very complex and not scale. [Jim U>] In what ways is it too complex? In what ways does it not scale? The former will have some additional challenges and complex because VLAN I= D may not be global based ID like IP addresses and L2VPN forwarding is base= d on MAC address while policy control is based on VLAN. Do I understand thi= s right? IMO: simplification is also important work for IETF and benefit to business= es as silicon technology improving. Without it, we have some limited room f= or adding new useful features and the system will be overly complex so nobo= dy can afford operating it. This does not say E-VPN. Thanks again. Lucy -----Original Message----- From: Aldrin Isaac [mailto:aldrin.isaac@gmail.com]=20 Sent: Friday, May 04, 2012 7:20 PM To: Lucy yong Cc: sajassi; Giles Heron; Nabil Bitar; l2vpn@ietf.org Subject: Re: Interest in IS-IS VPLS Hi Lucy, Please see inline On May 4, 2012, at 11:07 AM, Lucy yong wrote: > Hi Isaac, >=20 > Thank you for the reply. Please see inline. >=20 > Regards, > Lucy >=20 > -----Original Message----- > From: Aldrin Isaac [mailto:aldrin.isaac@gmail.com]=20 > Sent: Thursday, May 03, 2012 10:50 PM > To: Lucy yong > Cc: sajassi; Giles Heron; Nabil Bitar; l2vpn@ietf.org > Subject: Re: Interest in IS-IS VPLS >=20 ...=20 > E-VPN also supports policy based-topologies versus simple point-to-point,= flat or tree VLANs. It can support point-to-point, tree, mesh, one-way, o= r pretty much any other "complex" or overlapped topologies (depending on ho= w you like to see it). An example is ability to natively recreate private = vlan, community vlan topologies (which happen to be quite common in DC netw= orks) and any number of combinations of these simultaneously to a single po= rt. A BGP E-VPN VPN is also decoupled from the edge EVI/ESI such that it i= s not limited to a single tenant/vlan but can span tenants/vlans (l2 extran= et) if so required. This is native to E-VPN. > [[LY]] Such policy based-topologies are useful for service provider netwo= rk, but may too complex for intra DCs. One reason that customers often want= to choose with L2VPN service is "it is simple". However, L3VPN have its ap= plications although some operators often complain the complexities to confi= gure these policies. Typical example is the a firewall only placed at a loc= ation. Could you share why operator want such policy based-topology for L2V= PN? Policy-based topologies are generally complex when used to interconnect IP = networks because there are generally multiple prefixes in a vrf, and often = different prefixes need to be associated to different VPNs or routing behav= ior. In the DC, L2VPN role is to interconnect host ports so the policies f= or basic are very simple --- list of import route targets and list of expor= t route targets where each import/export pair correspond to a VPN (tenant, = service, ...). An example of how a DC operator might use this for example = is to meet a requirement for private vlan and community vlans which are ver= y common for DMZs. Hopefully you are familiar with these very common use c= ases. It is even possible to recreate more complex switch "features" like = MVR (in addition to private VLANs which are also considered "features") usi= ng E-VPN. It took me three years to get the MVR feature into a particular = vendor's switch to meet a business need. I'll sacrifice plug-and-play simp= licity for business agility. I'm sure my peers are with me on this one. If simple "plug-and-play" is important, one could imagine RRs sending out a= n "RR TLV" such that RRs in an IGP area auto-connect with each other and RR= -clients connect to the closest RR based on SPF (some details like peer-gro= up, etc would need to be factored in to make it more powerful). Other BGP/= MPLS configuration is, IMHO, trivial unless you CHOOSE to use more advanced= capabilities (i.e. not locked in). =20 Maybe the reason why MPLS comes across as complex is because of how IETF de= als with requirements lately by creating point solutions. E-VPN tries to p= ut new capabilities on the table while trying not to take existing value of= f the table. There is no reason why a solution can't bring more value than= what the standards body calls for. > E-VPN supports interconnecting end-stations or interconnecting L2 network= s. Procedures to easily span STP based networks across an E-VPN network wi= thout loops comes with the base spec. Extensions to E-VPN, such as PBB-EVP= N, simplify the fully functional spanning of non-EVPN networks across an E-= VPN network. > [[LY]] current L2VPN support all these except active-active mode which ca= uses the loop. Base E-VPN spec will natively deal with the STP case through an active/stan= dby mode and BPDU-snooping -- detect root bridge and use that as ESI (ether= net segment id) to indicate unique STP network with active/standby bit set = to ensure only one forwarding link among links with same ESI. Tags (vlans)= can potentially each have a different active link within the member links = of an ESI allowing for automatic tag(tenant)/vlan level load-balancing into= an STP network. Edge networks that don't have mac-move issue will be able= to take full advantage of active-active load-balancing without need for LA= G/MLAG. > An SVI/IRB interface can also be a member of both an E-VPN EVI and an IP = VRF allowing for easily bringing together virtual L2 and L3 topologies anyw= here in the network without a physical port. > [[LY]] Could you please share how operator plan to use this? Which servic= e will you sell to customer in this case? The service will be where a customer wants to communicate to a destination = network that is not in his subnet. Operators most interested in EVPN alrea= dy have IPVPN services on their network. This is the gateway point between= the EVPN virtual networks and [existing] IPVPN virtual networks. No physi= cal port required. > E-VPN builds on top of years of work in the IETF; traffic engineering, sc= aling with route reflectors and RT constrain, multicast via NG-MVPN, etc. > [[LY]] Agree. These are useful features for service provider network. How= ever, these functions may not necessary within DC although they had been pr= oved works well.=20 I'm not sure how eventually re-inventing these capabilities (yes it will ha= ppen) on behalf of a new protocol will be better than simply leveraging pro= ven technology. Vendors don't need to implement every MPLS RFC ever writte= n to be able to implement the basic E-VPN. > Can also use IP for transport tunnel. But my understanding is that popul= ar merchant silicon has support for MPLS push/pop/swap these days (?). Thi= s was captured by EVPN at it's inception, which is why the PE is referred t= o as MES (MPLS-enabled switch) in E-VPN. > [[LY]] Yes, current draft aims on MPLS solution only. But it states the p= otential to extend to the use of IP tunnel.=20 > The way I see it, a major reason why STP-based LANS are fickle and don't = scale well is on account of insufficient decoupling of core from edge creat= ed by requirement for plug-and-play and how that played out over time. Con= versely the reason (among other things) why IP networks are more stable is = because they are not inherently plug-and-play, and with MPLS/BGP allows exc= ellent decoupling of core and edge. I don't know enough about TRILL or PBB= to comment on those -- I just know that I'm not interested for enough good= reasons. E-VPN enables a dynamic edge over a stable decoupled core while = giving each operator room for service differentiation. It is especially in= teresting to operators that have invested in MPLS technology and operations= . I can find a lot of folks that understand BGP/MPLS IPVPN and in short or= der have them know the ins and outs of basic E-VPN. It's quite hard for me= to find non-vendor folk who really actually understand the other technolog= ies used to span Ethernet aside from basic STP.=20 > [[LY]] Thank you to share this in the mailing list.=20 >=20 > This is an operator perspective. > [[LY]] This is great! >=20 >=20 > On May 3, 2012, at 4:31 PM, Lucy yong wrote: >=20 >> Hi Ali, >>=20 >>=20 >> "5. Ethernet VPN (E-VPN) - An enhanced Layer-2 service that >> emulates an Ethernet (V)LAN across a PSN. E-VPN supports >> load-sharing across multiple connections from a Layer-2 site >> to an L2VPN service. E-VPN is primarily targeted to support >> large-scale L2VPNs with resiliency requirements not satisfied >> by other L2VPN solutions" >>=20 >> [[LY]] IMO, E-VPN enhancement is to support multi-homing with active-act= ive mode. Load-sharing across multiple connections from a layer-2 site is d= esired when this mode is used. Current VPLS can provide resiliency requirem= ent when the multi-homing site configured with active-standby mode. >>=20 >> Regards, >> Lucy >>=20 >> Cheers, >> Ali =20 >>=20 >=20 From josh.rogers@twcable.com Mon May 7 09:36: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 EC95F21F8664 for ; Mon, 7 May 2012 09:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.458 X-Spam-Level: X-Spam-Status: No, score=-0.458 tagged_above=-999 required=5 tests=[AWL=0.405, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 RAOs6FMShdUp for ; Mon, 7 May 2012 09:36:41 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9DC21F85F2 for ; Mon, 7 May 2012 09:36:38 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.75,544,1330923600"; d="scan'208";a="377629389" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 07 May 2012 12:35:52 -0400 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.36]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Mon, 7 May 2012 12:36:23 -0400 From: "Rogers, Josh" To: Jiangyuanlong , Daniel Cohn , "Fedyk, Donald (Don)" , "Henderickx, Wim (Wim)" , Lucy yong Date: Mon, 7 May 2012 12:36: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: Ac0sb4n9vM/mB8nMRl67lYXlSymIsA== Message-ID: In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410770@szxeml546-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" 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, 07 May 2012 16:36:44 -0000 Comment Inline: On 5/7/12 1:34 AM, "Jiangyuanlong" wrote: > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Monday, May 07, 2012 12:09 PM >To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >(Wim); Lucy yong >Cc: l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >So, if you can imagine three PE's, PE1, PE2 and PE3. PE1 has a root AC, >R1 and a leaf AC, L1. PE2 also has a root AC, R2, and a leaf AC, L2. PE3 >has a leaf AC, L3. > >Consider an unknown unicast frame from the leaf site L1, and also another >unknown unicast frame from R1 entering. > >With the 2VLAN method (to my best understanding): > - frame from L1 enters PE1, goes into a PW to PE2 and a PW to PE3, >arrives at PE2 which decides that it should be flooded out all Root AC's, >based on the S-tag. It also arrives at PE3, where it is dropped because >there are no root AC's. > >[JY] Since PE3 is a leaf-only node, the PW from PE1 to PE3 will work in >Optimized-Mode. According to Section 5.3.3 of >draft-jiang-l2vpn-vpls-pe-etree-05, it will be dropped before arriving at >this PW. Therefore, this frame will not arrive at PE3. [JR] Correct, in my example I was assuming no optimization. See my later comment about adding complexity for the sake of optimization (which is not a problem, just an observation, the same observation holds true for multi-PW method.) > > - frame from R1 enters PE1, goes into a PW to PE2 and a PW to PE3, >arrives at PE2 which decides that it should be flooded out all AC's, based >on S-tag. It also arrives at PE3 where it is forwarded to all root AC's. > >With Multi-PW method: > - frame from L1 enters PE1, which decides to forward the frame out the >'root' PW to PE2, which in turn floods out all Root AC's, based on >arriving PW type. Frame is NOT sent to PE3, since there is no PW built to >the PE which has no root AC's. > >[JY] According to my understanding of the following description in >draft-ram-l2vpn-etree-multiple-pw-01: > "It should be noted that in a full-mesh VPLS (as opposed to H-VPLS), > the following VSI pair types do not require two interconnecting PWs: > Root-only VSI <-> any VSI: only root PW required > Leaf-only VSI <-> leaf-only VSI: no PWs required" >There should be 2 PWs be set up between PE1 and PE3, since this is a case >of "Root & Leaf mixed VSI <-> leaf-only VSI" and not listed in the >none-two- interconnecting-PWs criteria. Therefore, this frame will be >sent to PE3 twice (one on root PW, another on leaf PW) IMO. Of course, >the other authors of draft-ram-l2vpn-etree-multiple-pw-01 may have more >to say on this point. [JR] Remember that PW's are unidirectional, we should consider setup in each direction independently: root-only -> any VSI =3D one PW Leaf-only -> root-only =3D one PW Leaf-only -> Leaf-only =3D Zero PW Leaf-only -> mixed =3D one PW Mixed -> root-only =3D one PW Mixed -> leaf-only =3D one PW Mixed -> mixed =3D two PW In our example, PE1 to PE3 would be mixed to leaf-only (one PW) in one direction, and leaf-only to mixed (one PW) in the other, so I was mistaken in my original depiction, and you are correct, it should be only one PW. It would just be the mixed -> mixed where broadcast would be duplicated. Also consider this list of scenarios, the only times that we have to deviate from the typical 'any to any' VPLS is in the Leaf-only to Leaf-only, and Mixed to Mixed PW's. All others are a single PW. [/JR] > > - frame from R1 enters PE1, which decides to flood out both 'root' PW >and 'leaf' PW to PE2, which in turn floods out the same AC types, based on >arriving PW type. It also arrives at PE3 where it is forwarded to all >root AC's. > >[JY] It contradicts your first statement that "there is no PW built to >the PE which has no root AC's". [JR] Sorry, I got confused on my only topology and was thinking PE3 was root-only. Frame would arrive at PE3 (on the root-sourced PW) where it would forward to all AC's. Sorry I botched the explanation, I hope the idea was not lost in the confusion. > >I suppose optimization could be done on the ingress PE to decide that >there is no need to 'flood' root-sourced frames to two PW's that have the >same egress PE, but instead to only forward to the 'root' type PW, when >both exist, because we know that the egress PE will flood frames from >root-sourced PW's out both leaf and root AC's. > >In this example, the same frame from R1 is duplicated on the PE1-PE2 path >(if no optimization is done.), where it would not be with the 2VLAN >method. > >With 2VLAN, ethernet type PW's cannot be used (must be vlan type PW's, >otherwise how would we classify source AC-type?), which means there is >overhead on EVERY frame to add the s-tag for the sole purpose of >classifying the frame. If optimization is done, then each ingress PE >knows what types of AC's are on each egress PE, and only forwards the >appropriate frame, if no optimization then it is dropped at the egress PE. > >In short, both are either not 100% inefficient, or are additionally >complex due to 'optimization'. > >I may have gotten my details off on the optimization piece of the 2VLAN >method, please correct me if I didn't get the details 100% correct. > > >-Josh > > > >On 5/6/12 9:07 PM, "Jiangyuanlong" wrote: > >>Could you or any other co-authors of 2PW give some more hints so that it >>can be better understood? >> >>In draft-ram-l2vpn-etree-multiple-pw-01, I can only find a single >>sentence most to the point: >> "An egress PE SHALL NOT deliver a frame originated at a leaf AC to >> another leaf AC." >> >>But it seems there is not a description of "traffic is split/separated >>(by psuedowire) on the ingress PE" at all. >> >>On the contrary, in draft-jiang-l2vpn-vpls-pe-etree-05, Section 5.3.3 >>details the scenario and forwarding plane how the leaf traffic is >>seperated and filtered on the ingress PE, and Section 6 details the >>specific supports in the control plane. >> >>Thanks >>Yuanlong >> >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Friday, May 04, 2012 8:27 PM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>also separate the leaf traffic in the ingress PE and filter it there >>(already detailed in the Optimization Mode in the I-D); if the egress PE >>is attached with pure roots or with both roots and leafs, it seems all >>traffic must be transported to the egress PE and be filtered there, I see >>no difference in behaviour for these solutions. Or did I miss something? >> >> >>The point is with the multi-PW method the traffic is split/separated (by >>psuedowire) on the ingress PE, rather than the egress. The distinction >>is >>2VLAN will 'classify' the frame on the ingress PE, so that the egress PE >>knows how to forward it to the appropriate AC's. >> >>Both methods have inefficiencies (one duplicates traffic for transport, >>while the other transports where it doesn't need to go). I like the idea >>of classify and forwarding on the ingress PE, rather than marking it on >>the ingress, and deciding on the egress. >> >>-Josh >> >> >> >>On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: >> >>>Josh, thank you for the comments, please see my further comments with >>>[JY2]. >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Thursday, May 03, 2012 11:27 PM >>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>(Wim); Lucy yong >>>Cc: l2vpn@ietf.org >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>requirements from MEF, it has nothing to do with the solutions. Could >>>you >>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>if >>>configuring or signalling two PWs is not a problem, why configuring or >>>signalling two VLANs will become a problem? After all, more nodes may >>>need >>>to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >>>2VLAN (only T-PEs). >>> >>> >>>There is no other way (if both MPLS domains are part of the same ETREE, >>>rather than doing something more like H-VPLS, where one domain has point >>>to points to the other domain which handles the ETREE instance) if you >>>are >>>using an ENNI. The other method, (not mentioned earlier) is tying the >>>two >>>MPLS domains together via labeled unicast (much preferred over E-NNI in >>>my >>>opinion) >>> >>>Configuring two VLAN's isn't really a 'problem' any more than two PW's. >>>I >>>wasn't saying that configuring two VLAN's was difficult, I was objecting >>>to the statement that configuring two PW's is difficult. >>> >>>[JY2] Thanks, I see your point. I take the example of 2PW configuration >>>just to show that using fixed global values to simplify configuration >>>makes no sense. Personally I also don't think configuration is a problem >>>for both solutions. >>> >>>I find the differences between these two methods rather slight. The >>>'tie-breaker' for me is by placing the forwarding decision on the >>>ingress >>>PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >>>more control over where the traffic goes, and in my mind it provides a >>>cleaner destination between customer traffic and forwarding plane. I'm >>>accustomed to looking at a psuedowire and knowing where its going, with >>>the 2vlan method, I can see the psuedowire, but must go to the egress PE >>>to see if it will be dropped there, or forwarded to one or more AC's. >>> >>>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>>also separate the leaf traffic in the ingress PE and filter it there >>>(already detailed in the Optimization Mode in the I-D); if the egress PE >>>is attached with pure roots or with both roots and leafs, it seems all >>>traffic must be transported to the egress PE and be filtered there, I >>>see >>>no difference in behaviour for these solutions. Or did I miss something? >>> >>>Again, the difference here is slight, and I would honestly be happy to >>>see >>>either of them come to fruition. Please don't infer that I think the >>>2vlan method is 'bad' or has intrinsic problems, because I don't believe >>>that. I just prefer the multi-PW method. >>> >>> >>>-Josh >>> >>> >>>On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: >>> >>>>Josh, please see my comments in line. >>>> >>>>Thanks >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>>Sent: Thursday, May 03, 2012 10:51 AM >>>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>>(Wim); Lucy yong >>>>Cc: l2vpn@ietf.org >>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>> >>>>Yuanlong, >>>> >>>>Or better yet, include in the draft a 'standard' value for root sourced >>>>VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You would a= lso >>>>have to require the the implementation NOT use global VLAN's, however >>>>(since each instance would be using the same values). In this way, no >>>>signaling or manual configuration is required for remote PE's to know >>>>how >>>>to classify traffic. >>>>[JY] Indeed, we discussed this possibility during the f2f meeting in >>>>Paris. But, there are some restrictions as you mentioned, and >>>>furthermore: >>>>1) Some vendors already used S-VLAN to distinguish their VSIs in the >>>>PE; >>>>2) Forwarding plane of a PE needs to be revised to be aware of this >>>>VLAN >>>>ID. >>>>Therefore, this 'standard value' approach seems more disruptive >>>>compared >>>>with the other means and not a good candidate option. >>>> >>>>Regarding switching PE's=A9 Multi-PW means more than one PW, yes. I >>>>don't >>>>see this as a real problem. In general, design should try and avoid >>>>using >>>>S-PE's, but if you must, its going to mean extra work, no matter how >>>>you >>>>look at it. Two PW's for each Etree being switched instead of one is >>>>not >>>>alarming or concerning to me. On the other hand, if you use a dot1q >>>>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's >>>>an >>>>two egress VLAN's if you want the Etree to be handled on both sides >>>>(and >>>>if you use the 'standard' VID's as I mentioned above, you'd have to do >>>>mapping to non-standard and back) >>>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>>requirements from MEF, it has nothing to do with the solutions. Could >>>>you >>>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>>if configuring or signalling two PWs is not a problem, why configuring >>>>or >>>>signalling two VLANs will become a problem? After all, more nodes may >>>>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>>>with 2VLAN (only T-PEs). >>>> >>>>In general, I still prefer multi-PW, primarily because I prefer the >>>>separation of the traffic in the network's forwarding plane, rather >>>>than >>>>shipping it everywhere and deciding whether to forward to the AC when >>>>it >>>>gets to the egress PE. I'm having a hard time putting my finger >>>>exactly >>>>on what it is, or articulating the idea, but it seems that by having >>>>the >>>>traffic placed into two psuedowires, I have more flexibility and ease >>>>of >>>>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>>>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>>>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>>>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>>>PW's could really change that perception. >>>>[JY] Are you saying that we need to develop a totally new forwarding >>>>plane rather than using the Ethernet forwarding plane as described in >>>>the >>>>existing work? >>>> >>>>I hope we can move forward with one of these soon, >>>>[JY] me too. >>>> >>>>Josh >>>> >>>> >>>>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >>>> >>>>>Daniel, >>>>> >>>>>Not aware that we had a discussion on this before, but IMHO the >>>>>allocation of internal S-VLAN can be automatic, and manuel >>>>>configuration >>>>>of this mapping may not be needed at all. For example, an S-VLAN >>>>>allocation module in the management plane in a PE can do this kind of >>>>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>>>way from a free S-VLAN ID pool. Once the interal S-VLANs are >>>>>allocated, >>>>>the mapping is determined and no other configuration is needed. >>>>> >>>>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>>>allocate >>>>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to >>>>>allocate >>>>>two S-VLANs in the VPLS domain. >>>>> >>>>>On the other hand, for the multi-PW approach, two PWs need to be >>>>>configured for a E-Tree service. When MS-PW is used in the network, >>>>>for >>>>>every S-PE, we need to configure two ingress PW segments and two >>>>>egress >>>>>PW segments. In this case, I don't think we need to use fixed PW >>>>>labels >>>>>across the network for fear of configuration complexity. >>>>> >>>>>Regards, >>>>>Yuanlong >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>Sent: Wednesday, May 02, 2012 8:01 PM >>>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; >>>>>josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Inline. >>>>> >>>>>-----Original Message----- >>>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>>Sent: Wednesday, May 02, 2012 12:30 PM >>>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; >>>>>josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Hi Daniel, Please see my comments in line. >>>>> >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>Sent: Wednesday, May 02, 2012 3:55 PM >>>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Hi Yuanlong, >>>>> >>>>>The problem is not with the total number of S-VLAN IDs, I agree that >>>>>normally there won't be more than 2047. The problem is that if you >>>>>don't >>>>>support all VLAN IDs, you need S-VLAN space coordination with the >>>>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to >>>>>2047". >>>>>Which won't always be in line with an existing deployment. >>>>>[JY] This is not the case. If the total number is no more than 2047, >>>>>it >>>>>surely can be supported. The S-VLAN space of user domain is totally >>>>>different from the S-VLAN in the provider domain and they can be >>>>>overlapped, I don't see why we need S-VLAN space coordination between >>>>>them. >>>>> >>>>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>>>fixed, and therefore the IEEE S-VID that can be supported is also >>>>>fixed. >>>>> >>>>>Of course you can configure the mapping in each PE according to >>>>>operator >>>>>requirements but as we discussed before this increases complexity. >>>>> >>>>>Relying on PBB-VPLS imposes additional limitations on backward >>>>>compatibility. >>>>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>>>think they may well need MAC-in-MAC in their networks for the >>>>>scalability issue. As you know, only PBB VPLS can provide both. >>>>> >>>>>Daniel >>>>> >>>>>-----Original Message----- >>>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>>Sent: Wednesday, May 02, 2012 5:07 AM >>>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; >>>>>josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Hi Daniel, >>>>> >>>>>As you can see, both cases are discussed in the I-D. >>>>> >>>>>With regard to case 1) (that is, S-VLAN translation), since the access >>>>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>>>they need to be configured on a PE anyway, and as the past emails by >>>>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>>>mapping. >>>>> >>>>>With regard to S-VID space reduction, the constraint is valid only >>>>>when >>>>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>>>typical and with no such limits as we already discussed in the f2f >>>>>meeting. >>>>> >>>>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>>>described (not sure this is a valid use case in real life), PBB-VPLS >>>>>can >>>>>still be used. >>>>> >>>>>Regards, >>>>>Yuanlong >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>Sent: Monday, April 30, 2012 10:34 PM >>>>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>>Jiangyuanlong; josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>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] >>>>>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 >>>>> >>>>>---------------------------------------------------------------------- >>>> >>>> >>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>proprietary information, which is privileged, confidential, or subject >>>>to >>>>copyright belonging to Time Warner Cable. This E-mail is intended >>>>solely >>>>for the use of the individual or entity to which it is addressed. If >>>>you >>>>are not the intended recipient of this E-mail, you are hereby notified >>>>that any dissemination, distribution, copying, or action taken in >>>>relation to the contents of and attachments to this E-mail is strictly >>>>prohibited and may be unlawful. If you have received this 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 and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use of the individual or entity to which it is addressed. If you >are not the intended recipient of this E-mail, you are hereby notified >that any dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this 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 Mon May 7 12:30: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 8DA2421F8683 for ; Mon, 7 May 2012 12:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=-0.240, 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 wjsKksYcgcch for ; Mon, 7 May 2012 12:30:42 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 76CF721F865F for ; Mon, 7 May 2012 12:30:39 -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 AFP24674; Mon, 07 May 2012 15:30:39 -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; Mon, 7 May 2012 12:29:11 -0700 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.003; Mon, 7 May 2012 12:29:03 -0700 From: Lucy yong To: "Rogers, Josh" , Jiangyuanlong , Daniel Cohn , "Fedyk, Donald (Don)" , "Henderickx, Wim (Wim)" 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/4Txq0Y50G6N17p5Mncd5asuNMAgAYGiYCAAAzygIAAAjQAgAAAAYCAAASFAIAAAOoAgAAYGACAAAPTgIACzjKAgABsbmCAABSDMIAAJEvQgADhaeD//53EgIAAk10ggAE7MQCAAKXoAIAAuhCAgAQJ4ACAACIfgIAAKHsAgACoTAD//458gA== Date: Mon, 7 May 2012 19:29:03 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D330F06DD@dfweml506-mbx> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410770@szxeml546-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.149.150] Content-Type: text/plain; charset="iso-8859-2" 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, 07 May 2012 19:30:45 -0000 Josh, Thank you to provide the following needed PW for multi-PW solution. The lef= t side of "=3D" sign represent PE->PE and the right side is needed PW. We a= re on the same table now. In addition, I add Dual VLAN for comparison. Multi-PW Dual-VLAN Root-only -> any VSI =3D one PE one PW Leaf-only -> root-only =3D one PW one PW and one leaf S-VLAN Leaf-only -> Leaf-only =3D Zero PW Zero PW Leaf-only -> mixed =3D one PW one PW and one leaf S-VLAN Mixed -> root-only =3D one PW one PW=20 Mixed -> leaf-only =3D one PW one PW and one root S-VLAN Mixed -> mixed =3D two PW one PW and one root S-VLAN an= d one leaf VLAN Both methods let ingress PE marking and filtering all known unicast packets= in mixed->mixed case. In the case, only a broadcast packet at mixed PE nee= ds to be forwarded to another mixed PE with the mark, but the packet is sen= t once and no need to duplicate. VPLS requires PW associating with a VSI not an AC. Regards, Lucy -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com]=20 Sent: Monday, May 07, 2012 11:36 AM To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim);= Lucy yong Cc: l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? Comment Inline: On 5/7/12 1:34 AM, "Jiangyuanlong" wrote: > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Monday, May 07, 2012 12:09 PM >To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >(Wim); Lucy yong >Cc: l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >So, if you can imagine three PE's, PE1, PE2 and PE3. PE1 has a root AC, >R1 and a leaf AC, L1. PE2 also has a root AC, R2, and a leaf AC, L2. PE3 >has a leaf AC, L3. > >Consider an unknown unicast frame from the leaf site L1, and also another >unknown unicast frame from R1 entering. > >With the 2VLAN method (to my best understanding): > - frame from L1 enters PE1, goes into a PW to PE2 and a PW to PE3, >arrives at PE2 which decides that it should be flooded out all Root AC's, >based on the S-tag. It also arrives at PE3, where it is dropped because >there are no root AC's. > >[JY] Since PE3 is a leaf-only node, the PW from PE1 to PE3 will work in >Optimized-Mode. According to Section 5.3.3 of >draft-jiang-l2vpn-vpls-pe-etree-05, it will be dropped before arriving at >this PW. Therefore, this frame will not arrive at PE3. [JR] Correct, in my example I was assuming no optimization. See my later comment about adding complexity for the sake of optimization (which is not a problem, just an observation, the same observation holds true for multi-PW method.) > > - frame from R1 enters PE1, goes into a PW to PE2 and a PW to PE3, >arrives at PE2 which decides that it should be flooded out all AC's, based >on S-tag. It also arrives at PE3 where it is forwarded to all root AC's. > >With Multi-PW method: > - frame from L1 enters PE1, which decides to forward the frame out the >'root' PW to PE2, which in turn floods out all Root AC's, based on >arriving PW type. Frame is NOT sent to PE3, since there is no PW built to >the PE which has no root AC's. > >[JY] According to my understanding of the following description in >draft-ram-l2vpn-etree-multiple-pw-01: > "It should be noted that in a full-mesh VPLS (as opposed to H-VPLS), > the following VSI pair types do not require two interconnecting PWs: > Root-only VSI <-> any VSI: only root PW required > Leaf-only VSI <-> leaf-only VSI: no PWs required" >There should be 2 PWs be set up between PE1 and PE3, since this is a case >of "Root & Leaf mixed VSI <-> leaf-only VSI" and not listed in the >none-two- interconnecting-PWs criteria. Therefore, this frame will be >sent to PE3 twice (one on root PW, another on leaf PW) IMO. Of course, >the other authors of draft-ram-l2vpn-etree-multiple-pw-01 may have more >to say on this point. [JR] Remember that PW's are unidirectional, we should consider setup in each direction independently: root-only -> any VSI =3D one PW Leaf-only -> root-only =3D one PW Leaf-only -> Leaf-only =3D Zero PW Leaf-only -> mixed =3D one PW Mixed -> root-only =3D one PW Mixed -> leaf-only =3D one PW Mixed -> mixed =3D two PW In our example, PE1 to PE3 would be mixed to leaf-only (one PW) in one direction, and leaf-only to mixed (one PW) in the other, so I was mistaken in my original depiction, and you are correct, it should be only one PW. It would just be the mixed -> mixed where broadcast would be duplicated. Also consider this list of scenarios, the only times that we have to deviate from the typical 'any to any' VPLS is in the Leaf-only to Leaf-only, and Mixed to Mixed PW's. All others are a single PW. [/JR] > > - frame from R1 enters PE1, which decides to flood out both 'root' PW >and 'leaf' PW to PE2, which in turn floods out the same AC types, based on >arriving PW type. It also arrives at PE3 where it is forwarded to all >root AC's. > >[JY] It contradicts your first statement that "there is no PW built to >the PE which has no root AC's". [JR] Sorry, I got confused on my only topology and was thinking PE3 was root-only. Frame would arrive at PE3 (on the root-sourced PW) where it would forward to all AC's. Sorry I botched the explanation, I hope the idea was not lost in the confusion. > >I suppose optimization could be done on the ingress PE to decide that >there is no need to 'flood' root-sourced frames to two PW's that have the >same egress PE, but instead to only forward to the 'root' type PW, when >both exist, because we know that the egress PE will flood frames from >root-sourced PW's out both leaf and root AC's. > >In this example, the same frame from R1 is duplicated on the PE1-PE2 path >(if no optimization is done.), where it would not be with the 2VLAN >method. > >With 2VLAN, ethernet type PW's cannot be used (must be vlan type PW's, >otherwise how would we classify source AC-type?), which means there is >overhead on EVERY frame to add the s-tag for the sole purpose of >classifying the frame. If optimization is done, then each ingress PE >knows what types of AC's are on each egress PE, and only forwards the >appropriate frame, if no optimization then it is dropped at the egress PE. > >In short, both are either not 100% inefficient, or are additionally >complex due to 'optimization'. > >I may have gotten my details off on the optimization piece of the 2VLAN >method, please correct me if I didn't get the details 100% correct. > > >-Josh > > > >On 5/6/12 9:07 PM, "Jiangyuanlong" wrote: > >>Could you or any other co-authors of 2PW give some more hints so that it >>can be better understood? >> >>In draft-ram-l2vpn-etree-multiple-pw-01, I can only find a single >>sentence most to the point: >> "An egress PE SHALL NOT deliver a frame originated at a leaf AC to >> another leaf AC." >> >>But it seems there is not a description of "traffic is split/separated >>(by psuedowire) on the ingress PE" at all. >> >>On the contrary, in draft-jiang-l2vpn-vpls-pe-etree-05, Section 5.3.3 >>details the scenario and forwarding plane how the leaf traffic is >>seperated and filtered on the ingress PE, and Section 6 details the >>specific supports in the control plane. >> >>Thanks >>Yuanlong >> >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Friday, May 04, 2012 8:27 PM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>also separate the leaf traffic in the ingress PE and filter it there >>(already detailed in the Optimization Mode in the I-D); if the egress PE >>is attached with pure roots or with both roots and leafs, it seems all >>traffic must be transported to the egress PE and be filtered there, I see >>no difference in behaviour for these solutions. Or did I miss something? >> >> >>The point is with the multi-PW method the traffic is split/separated (by >>psuedowire) on the ingress PE, rather than the egress. The distinction >>is >>2VLAN will 'classify' the frame on the ingress PE, so that the egress PE >>knows how to forward it to the appropriate AC's. >> >>Both methods have inefficiencies (one duplicates traffic for transport, >>while the other transports where it doesn't need to go). I like the idea >>of classify and forwarding on the ingress PE, rather than marking it on >>the ingress, and deciding on the egress. >> >>-Josh >> >> >> >>On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: >> >>>Josh, thank you for the comments, please see my further comments with >>>[JY2]. >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Thursday, May 03, 2012 11:27 PM >>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>(Wim); Lucy yong >>>Cc: l2vpn@ietf.org >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>requirements from MEF, it has nothing to do with the solutions. Could >>>you >>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>if >>>configuring or signalling two PWs is not a problem, why configuring or >>>signalling two VLANs will become a problem? After all, more nodes may >>>need >>>to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >>>2VLAN (only T-PEs). >>> >>> >>>There is no other way (if both MPLS domains are part of the same ETREE, >>>rather than doing something more like H-VPLS, where one domain has point >>>to points to the other domain which handles the ETREE instance) if you >>>are >>>using an ENNI. The other method, (not mentioned earlier) is tying the >>>two >>>MPLS domains together via labeled unicast (much preferred over E-NNI in >>>my >>>opinion) >>> >>>Configuring two VLAN's isn't really a 'problem' any more than two PW's. >>>I >>>wasn't saying that configuring two VLAN's was difficult, I was objecting >>>to the statement that configuring two PW's is difficult. >>> >>>[JY2] Thanks, I see your point. I take the example of 2PW configuration >>>just to show that using fixed global values to simplify configuration >>>makes no sense. Personally I also don't think configuration is a problem >>>for both solutions. >>> >>>I find the differences between these two methods rather slight. The >>>'tie-breaker' for me is by placing the forwarding decision on the >>>ingress >>>PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >>>more control over where the traffic goes, and in my mind it provides a >>>cleaner destination between customer traffic and forwarding plane. I'm >>>accustomed to looking at a psuedowire and knowing where its going, with >>>the 2vlan method, I can see the psuedowire, but must go to the egress PE >>>to see if it will be dropped there, or forwarded to one or more AC's. >>> >>>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>>also separate the leaf traffic in the ingress PE and filter it there >>>(already detailed in the Optimization Mode in the I-D); if the egress PE >>>is attached with pure roots or with both roots and leafs, it seems all >>>traffic must be transported to the egress PE and be filtered there, I >>>see >>>no difference in behaviour for these solutions. Or did I miss something? >>> >>>Again, the difference here is slight, and I would honestly be happy to >>>see >>>either of them come to fruition. Please don't infer that I think the >>>2vlan method is 'bad' or has intrinsic problems, because I don't believe >>>that. I just prefer the multi-PW method. >>> >>> >>>-Josh >>> >>> >>>On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: >>> >>>>Josh, please see my comments in line. >>>> >>>>Thanks >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>>Sent: Thursday, May 03, 2012 10:51 AM >>>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>>(Wim); Lucy yong >>>>Cc: l2vpn@ietf.org >>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>> >>>>Yuanlong, >>>> >>>>Or better yet, include in the draft a 'standard' value for root sourced >>>>VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You would a= lso >>>>have to require the the implementation NOT use global VLAN's, however >>>>(since each instance would be using the same values). In this way, no >>>>signaling or manual configuration is required for remote PE's to know >>>>how >>>>to classify traffic. >>>>[JY] Indeed, we discussed this possibility during the f2f meeting in >>>>Paris. But, there are some restrictions as you mentioned, and >>>>furthermore: >>>>1) Some vendors already used S-VLAN to distinguish their VSIs in the >>>>PE; >>>>2) Forwarding plane of a PE needs to be revised to be aware of this >>>>VLAN >>>>ID. >>>>Therefore, this 'standard value' approach seems more disruptive >>>>compared >>>>with the other means and not a good candidate option. >>>> >>>>Regarding switching PE's=A9 Multi-PW means more than one PW, yes. I >>>>don't >>>>see this as a real problem. In general, design should try and avoid >>>>using >>>>S-PE's, but if you must, its going to mean extra work, no matter how >>>>you >>>>look at it. Two PW's for each Etree being switched instead of one is >>>>not >>>>alarming or concerning to me. On the other hand, if you use a dot1q >>>>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's >>>>an >>>>two egress VLAN's if you want the Etree to be handled on both sides >>>>(and >>>>if you use the 'standard' VID's as I mentioned above, you'd have to do >>>>mapping to non-standard and back) >>>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>>requirements from MEF, it has nothing to do with the solutions. Could >>>>you >>>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>>if configuring or signalling two PWs is not a problem, why configuring >>>>or >>>>signalling two VLANs will become a problem? After all, more nodes may >>>>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>>>with 2VLAN (only T-PEs). >>>> >>>>In general, I still prefer multi-PW, primarily because I prefer the >>>>separation of the traffic in the network's forwarding plane, rather >>>>than >>>>shipping it everywhere and deciding whether to forward to the AC when >>>>it >>>>gets to the egress PE. I'm having a hard time putting my finger >>>>exactly >>>>on what it is, or articulating the idea, but it seems that by having >>>>the >>>>traffic placed into two psuedowires, I have more flexibility and ease >>>>of >>>>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>>>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>>>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>>>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>>>PW's could really change that perception. >>>>[JY] Are you saying that we need to develop a totally new forwarding >>>>plane rather than using the Ethernet forwarding plane as described in >>>>the >>>>existing work? >>>> >>>>I hope we can move forward with one of these soon, >>>>[JY] me too. >>>> >>>>Josh >>>> >>>> >>>>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >>>> >>>>>Daniel, >>>>> >>>>>Not aware that we had a discussion on this before, but IMHO the >>>>>allocation of internal S-VLAN can be automatic, and manuel >>>>>configuration >>>>>of this mapping may not be needed at all. For example, an S-VLAN >>>>>allocation module in the management plane in a PE can do this kind of >>>>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>>>way from a free S-VLAN ID pool. Once the interal S-VLANs are >>>>>allocated, >>>>>the mapping is determined and no other configuration is needed. >>>>> >>>>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>>>allocate >>>>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to >>>>>allocate >>>>>two S-VLANs in the VPLS domain. >>>>> >>>>>On the other hand, for the multi-PW approach, two PWs need to be >>>>>configured for a E-Tree service. When MS-PW is used in the network, >>>>>for >>>>>every S-PE, we need to configure two ingress PW segments and two >>>>>egress >>>>>PW segments. In this case, I don't think we need to use fixed PW >>>>>labels >>>>>across the network for fear of configuration complexity. >>>>> >>>>>Regards, >>>>>Yuanlong >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>Sent: Wednesday, May 02, 2012 8:01 PM >>>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; >>>>>josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Inline. >>>>> >>>>>-----Original Message----- >>>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>>Sent: Wednesday, May 02, 2012 12:30 PM >>>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; >>>>>josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Hi Daniel, Please see my comments in line. >>>>> >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>Sent: Wednesday, May 02, 2012 3:55 PM >>>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Hi Yuanlong, >>>>> >>>>>The problem is not with the total number of S-VLAN IDs, I agree that >>>>>normally there won't be more than 2047. The problem is that if you >>>>>don't >>>>>support all VLAN IDs, you need S-VLAN space coordination with the >>>>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to >>>>>2047". >>>>>Which won't always be in line with an existing deployment. >>>>>[JY] This is not the case. If the total number is no more than 2047, >>>>>it >>>>>surely can be supported. The S-VLAN space of user domain is totally >>>>>different from the S-VLAN in the provider domain and they can be >>>>>overlapped, I don't see why we need S-VLAN space coordination between >>>>>them. >>>>> >>>>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>>>fixed, and therefore the IEEE S-VID that can be supported is also >>>>>fixed. >>>>> >>>>>Of course you can configure the mapping in each PE according to >>>>>operator >>>>>requirements but as we discussed before this increases complexity. >>>>> >>>>>Relying on PBB-VPLS imposes additional limitations on backward >>>>>compatibility. >>>>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>>>think they may well need MAC-in-MAC in their networks for the >>>>>scalability issue. As you know, only PBB VPLS can provide both. >>>>> >>>>>Daniel >>>>> >>>>>-----Original Message----- >>>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>>Sent: Wednesday, May 02, 2012 5:07 AM >>>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; >>>>>josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Hi Daniel, >>>>> >>>>>As you can see, both cases are discussed in the I-D. >>>>> >>>>>With regard to case 1) (that is, S-VLAN translation), since the access >>>>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>>>they need to be configured on a PE anyway, and as the past emails by >>>>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>>>mapping. >>>>> >>>>>With regard to S-VID space reduction, the constraint is valid only >>>>>when >>>>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>>>typical and with no such limits as we already discussed in the f2f >>>>>meeting. >>>>> >>>>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>>>described (not sure this is a valid use case in real life), PBB-VPLS >>>>>can >>>>>still be used. >>>>> >>>>>Regards, >>>>>Yuanlong >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>Sent: Monday, April 30, 2012 10:34 PM >>>>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>>Jiangyuanlong; josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>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] >>>>>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 >>>>> >>>>>---------------------------------------------------------------------- >>>> >>>> >>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>proprietary information, which is privileged, confidential, or subject >>>>to >>>>copyright belonging to Time Warner Cable. This E-mail is intended >>>>solely >>>>for the use of the individual or entity to which it is addressed. If >>>>you >>>>are not the intended recipient of this E-mail, you are hereby notified >>>>that any dissemination, distribution, copying, or action taken in >>>>relation to the contents of and attachments to this E-mail is strictly >>>>prohibited and may be unlawful. If you have received this 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 and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use of the individual or entity to which it is addressed. If you >are not the intended recipient of this E-mail, you are hereby notified >that any dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this 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 Mon May 7 13:00: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 559E521F86D0 for ; Mon, 7 May 2012 13:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.232 X-Spam-Level: X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[AWL=-0.233, 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 QSwXn0sp8xrS for ; Mon, 7 May 2012 13:00:38 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id D32CF21F86CE for ; Mon, 7 May 2012 13:00: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 AFX24751; Mon, 07 May 2012 16:00:37 -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, 7 May 2012 12:58:12 -0700 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Mon, 7 May 2012 12:58:06 -0700 From: Lucy yong To: Sam Cao , "l2vpn@ietf.org" Subject: RE: L2vpn Digest, Vol 96, Issue 15 Thread-Topic: L2vpn Digest, Vol 96, Issue 15 Thread-Index: Ac0qAqy9LTtQ75h0R2+YJ9mGFYIsPwAWFG9QAIs2guA= Date: Mon, 7 May 2012 19:58:06 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D330F0740@dfweml506-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.149.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Jiangyuanlong 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, 07 May 2012 20:00:41 -0000 Sam, I conquer Yuanlong's reply on this. Please see inline. Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of S= am Cao Sent: Friday, May 04, 2012 9:09 PM To: l2vpn@ietf.org Cc: Jiangyuanlong Subject: RE: L2vpn Digest, Vol 96, Issue 15 Lucy/Yuanlong, I agree that we can not say which approach is better simply, but I really agree with Josh's comments. Multi-PW is easy to implement E-Tree. [[LY]] I don't get impression Josh state this. First of all, we discussed 2 approaches for a long time and many rounds, an= d for me, there are no pending issues on Multi-PW till now or co-authors of multi-PW have given reasonable reply to L2VPN members' questions, but there are still pending issues for Dual-VLAN. Please trace the mailing list. [[LY]] I interpret this as people want to spend time to finalize dual VLAN = solution. Multi-PW has some operation impact. How do operator to maintain t= his service and be able to trouble shooting. How do you expect traceroute w= ork when using two PWs for one VPN? How do you expect PE report when there = is an error on one of two PWs? Do you have one FEC or two FEC for a E-Tree = in control plane? Second, Sasha has his concern in NP, or forwarding performance. Compared to current VPLS, Multi-PW has a little effect on forwarding performance since it reuse PW label as AC indicator; Dual-VLAN will have higher side effect o= n forwarding performance because it SHOULD use additional indicator. Is there one prototype for Dual-VLAN? BTW, there is no reply on chip limit. [[LY]] in VPLS, PW label is used as VSI indicator, not AC. I disagree your = statement here. Third, the difference between Multi-PW and dual-VLAN is, transport ingress traffic in one "LSP" or 2 "LSP". Multi-PW classifies and transforms ingress traffic into right "path", and egress just pop-out PW label and forward the frame to ACs. Dual-VLAN has more work on ingress PE or egress PE. [[LY]] Don't understand the first part. When egress pop-out PW label, it fi= nd corresponding VSI first, then perform MAC lookup associated to all ACs. = We can't assume there is one AC. =20 Fourth, maybe Giles has figured this out, Dual-VLAN has capacity limit. Onl= y 4094 VLAN ID are available, so only 2K E-Tree instances can be supported on one PE for Dual-VLAN approach. There is no such limit for Multi-PW approach= , [[LY]] If 4K VLAN ID is not an issue for VPLS, it is not an issue for E-Tre= e.=20 Finally, in this thread we don't make agreement on VLAN ID allocation. We also have questions on VLAN ID negotiation among PEs (signaling protocol). Yuanlong wishes to update, but there is no update till now. [[LY]] This should not be the reason to judge on the solution. For me, why IEEE uses VLAN ID to identify AC type? IEEE has no LABEL :), an= d it has label, it also wish to use label to identify AC types. I think that both solutions need much time to be perfect. Mutli-PW has less extension work to do. But now we are focusing on technical details and can not move forward :). =20 [[LY]] VPN label is used for identify the VPN. It already has the purpose. = Overloading with other meaning has high potential causing a problem. Hope y= ou can investigate it more. Since you are very in favor of multi-pw solutio= n, it is not proper for you to come out the conclusion which is better, bec= ause it is very biased. You are welcome to help on completing either soluti= on. Regards, Lucy Lucy Thanks, Sam -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of l2vpn-request@ietf.org Sent: Friday, May 04, 2012 10:31 PM To: l2vpn@ietf.org Subject: L2vpn Digest, Vol 96, Issue 15 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) 2. Re: The status of the approaches to the E-Tree solution? (Rogers, Josh) ---------------------------------------------------------------------- Message: 1 Date: Fri, 4 May 2012 14:16:36 +0000 From: Lucy yong To: "Rogers, Josh" , Jiangyuanlong , Daniel Cohn , "Fedyk, Donald (Don)" , "Henderickx, Wim (Wim)" Cc: "l2vpn@ietf.org" Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: <2691CE0099834E4A9C5044EEC662BB9D330E9114@dfweml505-mbx> Content-Type: text/plain; charset=3D"iso-8859-2" Josh, You simply say that you don't like IEEE Tree solution. IEEE Tree solution i= s for ingress port to mark and for egress port to filter. Regards, Lucy -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com]=20 Sent: Friday, May 04, 2012 7:27 AM To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong Cc: l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? [JY2] if the egress PE is attached with pure leafs, 2VLAN approach can also separate the leaf traffic in the ingress PE and filter it there (already detailed in the Optimization Mode in the I-D); if the egress PE is attached with pure roots or with both roots and leafs, it seems all traffic must be transported to the egress PE and be filtered there, I see no difference in behaviour for these solutions. Or did I miss something? The point is with the multi-PW method the traffic is split/separated (by psuedowire) on the ingress PE, rather than the egress. The distinction is 2VLAN will 'classify' the frame on the ingress PE, so that the egress PE knows how to forward it to the appropriate AC's. Both methods have inefficiencies (one duplicates traffic for transport, while the other transports where it doesn't need to go). I like the idea of classify and forwarding on the ingress PE, rather than marking it on the ingress, and deciding on the egress. -Josh On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: >Josh, thank you for the comments, please see my further comments with >[JY2]. > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Thursday, May 03, 2012 11:27 PM >To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >(Wim); Lucy yong >Cc: l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >requirements from MEF, it has nothing to do with the solutions. Could you >give a hint on how you can provision this service E-NNI otherwise? BTW, if >configuring or signalling two PWs is not a problem, why configuring or >signalling two VLANs will become a problem? After all, more nodes may need >to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >2VLAN (only T-PEs). > > >There is no other way (if both MPLS domains are part of the same ETREE, >rather than doing something more like H-VPLS, where one domain has point >to points to the other domain which handles the ETREE instance) if you are >using an ENNI. The other method, (not mentioned earlier) is tying the two >MPLS domains together via labeled unicast (much preferred over E-NNI in my >opinion) > >Configuring two VLAN's isn't really a 'problem' any more than two PW's. I >wasn't saying that configuring two VLAN's was difficult, I was objecting >to the statement that configuring two PW's is difficult. > >[JY2] Thanks, I see your point. I take the example of 2PW configuration >just to show that using fixed global values to simplify configuration >makes no sense. Personally I also don't think configuration is a problem >for both solutions. > >I find the differences between these two methods rather slight. The >'tie-breaker' for me is by placing the forwarding decision on the ingress >PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >more control over where the traffic goes, and in my mind it provides a >cleaner destination between customer traffic and forwarding plane. I'm >accustomed to looking at a psuedowire and knowing where its going, with >the 2vlan method, I can see the psuedowire, but must go to the egress PE >to see if it will be dropped there, or forwarded to one or more AC's. > >[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >also separate the leaf traffic in the ingress PE and filter it there >(already detailed in the Optimization Mode in the I-D); if the egress PE >is attached with pure roots or with both roots and leafs, it seems all >traffic must be transported to the egress PE and be filtered there, I see >no difference in behaviour for these solutions. Or did I miss something? > >Again, the difference here is slight, and I would honestly be happy to see >either of them come to fruition. Please don't infer that I think the >2vlan method is 'bad' or has intrinsic problems, because I don't believe >that. I just prefer the multi-PW method. > > >-Josh > > >On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: > >>Josh, please see my comments in line. >> >>Thanks >>Yuanlong >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Thursday, May 03, 2012 10:51 AM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>Yuanlong, >> >>Or better yet, include in the draft a 'standard' value for root sourced >>VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You would als= o >>have to require the the implementation NOT use global VLAN's, however >>(since each instance would be using the same values). In this way, no >>signaling or manual configuration is required for remote PE's to know how >>to classify traffic. >>[JY] Indeed, we discussed this possibility during the f2f meeting in >>Paris. But, there are some restrictions as you mentioned, and >>furthermore: >>1) Some vendors already used S-VLAN to distinguish their VSIs in the PE; >>2) Forwarding plane of a PE needs to be revised to be aware of this VLAN >>ID. >>Therefore, this 'standard value' approach seems more disruptive compared >>with the other means and not a good candidate option. >> >>Regarding switching PE's? Multi-PW means more than one PW, yes. I don't >>see this as a real problem. In general, design should try and avoid >>using >>S-PE's, but if you must, its going to mean extra work, no matter how you >>look at it. Two PW's for each Etree being switched instead of one is not >>alarming or concerning to me. On the other hand, if you use a dot1q >>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's an >>two egress VLAN's if you want the Etree to be handled on both sides (and >>if you use the 'standard' VID's as I mentioned above, you'd have to do >>mapping to non-standard and back) >>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>requirements from MEF, it has nothing to do with the solutions. Could you >>give a hint on how you can provision this service E-NNI otherwise? BTW, >>if configuring or signalling two PWs is not a problem, why configuring or >>signalling two VLANs will become a problem? After all, more nodes may >>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>with 2VLAN (only T-PEs). >> >>In general, I still prefer multi-PW, primarily because I prefer the >>separation of the traffic in the network's forwarding plane, rather than >>shipping it everywhere and deciding whether to forward to the AC when it >>gets to the egress PE. I'm having a hard time putting my finger exactly >>on what it is, or articulating the idea, but it seems that by having the >>traffic placed into two psuedowires, I have more flexibility and ease of >>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>PW's could really change that perception. >>[JY] Are you saying that we need to develop a totally new forwarding >>plane rather than using the Ethernet forwarding plane as described in the >>existing work? >> >>I hope we can move forward with one of these soon, >>[JY] me too. >> >>Josh >> >> >>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >> >>>Daniel, >>> >>>Not aware that we had a discussion on this before, but IMHO the >>>allocation of internal S-VLAN can be automatic, and manuel configuration >>>of this mapping may not be needed at all. For example, an S-VLAN >>>allocation module in the management plane in a PE can do this kind of >>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>way from a free S-VLAN ID pool. Once the interal S-VLANs are allocated, >>>the mapping is determined and no other configuration is needed. >>> >>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>allocate >>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to allocate >>>two S-VLANs in the VPLS domain. >>> >>>On the other hand, for the multi-PW approach, two PWs need to be >>>configured for a E-Tree service. When MS-PW is used in the network, for >>>every S-PE, we need to configure two ingress PW segments and two egress >>>PW segments. In this case, I don't think we need to use fixed PW labels >>>across the network for fear of configuration complexity. >>> >>>Regards, >>>Yuanlong >>> >>>-----Original Message----- >>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>Sent: Wednesday, May 02, 2012 8:01 PM >>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>yong; >>>josh.rogers@twcable.com >>>Cc: l2vpn@ietf.org >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Inline. >>> >>>-----Original Message----- >>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>Sent: Wednesday, May 02, 2012 12:30 PM >>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>josh.rogers@twcable.com >>>Cc: l2vpn@ietf.org >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Hi Daniel, Please see my comments in line. >>> >>> >>>-----Original Message----- >>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>Sent: Wednesday, May 02, 2012 3:55 PM >>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>yong; josh.rogers@twcable.com >>>Cc: l2vpn@ietf.org >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Hi Yuanlong, >>> >>>The problem is not with the total number of S-VLAN IDs, I agree that >>>normally there won't be more than 2047. The problem is that if you don't >>>support all VLAN IDs, you need S-VLAN space coordination with the >>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to 2047". >>>Which won't always be in line with an existing deployment. >>>[JY] This is not the case. If the total number is no more than 2047, it >>>surely can be supported. The S-VLAN space of user domain is totally >>>different from the S-VLAN in the provider domain and they can be >>>overlapped, I don't see why we need S-VLAN space coordination between >>>them. >>> >>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>fixed, and therefore the IEEE S-VID that can be supported is also fixed. >>> >>>Of course you can configure the mapping in each PE according to operator >>>requirements but as we discussed before this increases complexity. >>> >>>Relying on PBB-VPLS imposes additional limitations on backward >>>compatibility. >>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>think they may well need MAC-in-MAC in their networks for the >>>scalability issue. As you know, only PBB VPLS can provide both. >>> >>>Daniel >>> >>>-----Original Message----- >>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>Sent: Wednesday, May 02, 2012 5:07 AM >>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>josh.rogers@twcable.com >>>Cc: l2vpn@ietf.org >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Hi Daniel, >>> >>>As you can see, both cases are discussed in the I-D. >>> >>>With regard to case 1) (that is, S-VLAN translation), since the access >>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>they need to be configured on a PE anyway, and as the past emails by >>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>mapping. >>> >>>With regard to S-VID space reduction, the constraint is valid only when >>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>typical and with no such limits as we already discussed in the f2f >>>meeting. >>> >>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>described (not sure this is a valid use case in real life), PBB-VPLS can >>>still be used. >>> >>>Regards, >>>Yuanlong >>> >>>-----Original Message----- >>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>Sent: Monday, April 30, 2012 10:34 PM >>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>Jiangyuanlong; josh.rogers@twcable.com >>>Cc: l2vpn@ietf.org >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>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] >>>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 >>> >>>---------------------------------------------------------------------- >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject to >>copyright belonging to Time Warner Cable. This E-mail is intended solely >>for the use of the individual or entity to which it is addressed. If you >>are not the intended recipient of this E-mail, you are hereby notified >>that any dissemination, distribution, copying, or action taken in >>relation to the contents of and attachments to this E-mail is strictly >>prohibited and may be unlawful. If you have received this 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. ------------------------------ Message: 2 Date: Fri, 4 May 2012 10:30:38 -0400 From: "Rogers, Josh" To: Lucy yong , Jiangyuanlong , Daniel Cohn , "Fedyk, Donald (Don)" , "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"iso-8859-2" To be more accurate, I like it less than the multi-PW solution. I'd be happy to use the 2VLAN solution in the real world, if it was ratified as the standard. On 5/4/12 9:16 AM, "Lucy yong" wrote: >Josh, > >You simply say that you don't like IEEE Tree solution. IEEE Tree solution >is for ingress port to mark and for egress port to filter. > >Regards, >Lucy > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Friday, May 04, 2012 7:27 AM >To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >(Wim); Lucy yong >Cc: l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >also separate the leaf traffic in the ingress PE and filter it there >(already detailed in the Optimization Mode in the I-D); if the egress PE >is attached with pure roots or with both roots and leafs, it seems all >traffic must be transported to the egress PE and be filtered there, I see >no difference in behaviour for these solutions. Or did I miss something? > > >The point is with the multi-PW method the traffic is split/separated (by >psuedowire) on the ingress PE, rather than the egress. The distinction is >2VLAN will 'classify' the frame on the ingress PE, so that the egress PE >knows how to forward it to the appropriate AC's. > >Both methods have inefficiencies (one duplicates traffic for transport, >while the other transports where it doesn't need to go). I like the idea >of classify and forwarding on the ingress PE, rather than marking it on >the ingress, and deciding on the egress. > >-Josh > > > >On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: > >>Josh, thank you for the comments, please see my further comments with >>[JY2]. >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Thursday, May 03, 2012 11:27 PM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>requirements from MEF, it has nothing to do with the solutions. Could you >>give a hint on how you can provision this service E-NNI otherwise? BTW, >>if >>configuring or signalling two PWs is not a problem, why configuring or >>signalling two VLANs will become a problem? After all, more nodes may >>need >>to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >>2VLAN (only T-PEs). >> >> >>There is no other way (if both MPLS domains are part of the same ETREE, >>rather than doing something more like H-VPLS, where one domain has point >>to points to the other domain which handles the ETREE instance) if you >>are >>using an ENNI. The other method, (not mentioned earlier) is tying the >>two >>MPLS domains together via labeled unicast (much preferred over E-NNI in >>my >>opinion) >> >>Configuring two VLAN's isn't really a 'problem' any more than two PW's. >>I >>wasn't saying that configuring two VLAN's was difficult, I was objecting >>to the statement that configuring two PW's is difficult. >> >>[JY2] Thanks, I see your point. I take the example of 2PW configuration >>just to show that using fixed global values to simplify configuration >>makes no sense. Personally I also don't think configuration is a problem >>for both solutions. >> >>I find the differences between these two methods rather slight. The >>'tie-breaker' for me is by placing the forwarding decision on the ingress >>PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >>more control over where the traffic goes, and in my mind it provides a >>cleaner destination between customer traffic and forwarding plane. I'm >>accustomed to looking at a psuedowire and knowing where its going, with >>the 2vlan method, I can see the psuedowire, but must go to the egress PE >>to see if it will be dropped there, or forwarded to one or more AC's. >> >>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>also separate the leaf traffic in the ingress PE and filter it there >>(already detailed in the Optimization Mode in the I-D); if the egress PE >>is attached with pure roots or with both roots and leafs, it seems all >>traffic must be transported to the egress PE and be filtered there, I see >>no difference in behaviour for these solutions. Or did I miss something? >> >>Again, the difference here is slight, and I would honestly be happy to >>see >>either of them come to fruition. Please don't infer that I think the >>2vlan method is 'bad' or has intrinsic problems, because I don't believe >>that. I just prefer the multi-PW method. >> >> >>-Josh >> >> >>On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: >> >>>Josh, please see my comments in line. >>> >>>Thanks >>>Yuanlong >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Thursday, May 03, 2012 10:51 AM >>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>(Wim); Lucy yong >>>Cc: l2vpn@ietf.org >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Yuanlong, >>> >>>Or better yet, include in the draft a 'standard' value for root sourced >>>VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You would al= so >>>have to require the the implementation NOT use global VLAN's, however >>>(since each instance would be using the same values). In this way, no >>>signaling or manual configuration is required for remote PE's to know >>>how >>>to classify traffic. >>>[JY] Indeed, we discussed this possibility during the f2f meeting in >>>Paris. But, there are some restrictions as you mentioned, and >>>furthermore: >>>1) Some vendors already used S-VLAN to distinguish their VSIs in the PE; >>>2) Forwarding plane of a PE needs to be revised to be aware of this VLAN >>>ID. >>>Therefore, this 'standard value' approach seems more disruptive compared >>>with the other means and not a good candidate option. >>> >>>Regarding switching PE's? Multi-PW means more than one PW, yes. I >>>don't >>>see this as a real problem. In general, design should try and avoid >>>using >>>S-PE's, but if you must, its going to mean extra work, no matter how you >>>look at it. Two PW's for each Etree being switched instead of one is >>>not >>>alarming or concerning to me. On the other hand, if you use a dot1q >>>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's >>>an >>>two egress VLAN's if you want the Etree to be handled on both sides (and >>>if you use the 'standard' VID's as I mentioned above, you'd have to do >>>mapping to non-standard and back) >>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>requirements from MEF, it has nothing to do with the solutions. Could >>>you >>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>if configuring or signalling two PWs is not a problem, why configuring >>>or >>>signalling two VLANs will become a problem? After all, more nodes may >>>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>>with 2VLAN (only T-PEs). >>> >>>In general, I still prefer multi-PW, primarily because I prefer the >>>separation of the traffic in the network's forwarding plane, rather than >>>shipping it everywhere and deciding whether to forward to the AC when it >>>gets to the egress PE. I'm having a hard time putting my finger exactly >>>on what it is, or articulating the idea, but it seems that by having the >>>traffic placed into two psuedowires, I have more flexibility and ease of >>>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>>PW's could really change that perception. >>>[JY] Are you saying that we need to develop a totally new forwarding >>>plane rather than using the Ethernet forwarding plane as described in >>>the >>>existing work? >>> >>>I hope we can move forward with one of these soon, >>>[JY] me too. >>> >>>Josh >>> >>> >>>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >>> >>>>Daniel, >>>> >>>>Not aware that we had a discussion on this before, but IMHO the >>>>allocation of internal S-VLAN can be automatic, and manuel >>>>configuration >>>>of this mapping may not be needed at all. For example, an S-VLAN >>>>allocation module in the management plane in a PE can do this kind of >>>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>>way from a free S-VLAN ID pool. Once the interal S-VLANs are allocated, >>>>the mapping is determined and no other configuration is needed. >>>> >>>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>>allocate >>>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to allocate >>>>two S-VLANs in the VPLS domain. >>>> >>>>On the other hand, for the multi-PW approach, two PWs need to be >>>>configured for a E-Tree service. When MS-PW is used in the network, for >>>>every S-PE, we need to configure two ingress PW segments and two egress >>>>PW segments. In this case, I don't think we need to use fixed PW labels >>>>across the network for fear of configuration complexity. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 8:01 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Inline. >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 12:30 PM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, Please see my comments in line. >>>> >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 3:55 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Yuanlong, >>>> >>>>The problem is not with the total number of S-VLAN IDs, I agree that >>>>normally there won't be more than 2047. The problem is that if you >>>>don't >>>>support all VLAN IDs, you need S-VLAN space coordination with the >>>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to >>>>2047". >>>>Which won't always be in line with an existing deployment. >>>>[JY] This is not the case. If the total number is no more than 2047, it >>>>surely can be supported. The S-VLAN space of user domain is totally >>>>different from the S-VLAN in the provider domain and they can be >>>>overlapped, I don't see why we need S-VLAN space coordination between >>>>them. >>>> >>>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>>fixed, and therefore the IEEE S-VID that can be supported is also >>>>fixed. >>>> >>>>Of course you can configure the mapping in each PE according to >>>>operator >>>>requirements but as we discussed before this increases complexity. >>>> >>>>Relying on PBB-VPLS imposes additional limitations on backward >>>>compatibility. >>>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>>think they may well need MAC-in-MAC in their networks for the >>>>scalability issue. As you know, only PBB VPLS can provide both. >>>> >>>>Daniel >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 5:07 AM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, >>>> >>>>As you can see, both cases are discussed in the I-D. >>>> >>>>With regard to case 1) (that is, S-VLAN translation), since the access >>>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>>they need to be configured on a PE anyway, and as the past emails by >>>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>>mapping. >>>> >>>>With regard to S-VID space reduction, the constraint is valid only when >>>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>>typical and with no such limits as we already discussed in the f2f >>>>meeting. >>>> >>>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>>described (not sure this is a valid use case in real life), PBB-VPLS >>>>can >>>>still be used. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Monday, April 30, 2012 10:34 PM >>>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>Jiangyuanlong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>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] >>>>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 >>>> >>>>---------------------------------------------------------------------- >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to >>>copyright belonging to Time Warner Cable. This E-mail is intended solely >>>for the use of the individual or entity to which it is addressed. If you >>>are not the intended recipient of this E-mail, you are hereby notified >>>that any dissemination, distribution, copying, or action taken in >>>relation to the contents of and attachments to this E-mail is strictly >>>prohibited and may be unlawful. If you have received this 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 and any of its attachments may contain 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. ------------------------------ _______________________________________________ L2vpn mailing list L2vpn@ietf.org https://www.ietf.org/mailman/listinfo/l2vpn End of L2vpn Digest, Vol 96, Issue 15 ************************************* From lucy.yong@huawei.com Mon May 7 13:28: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 8A6E221F8668 for ; Mon, 7 May 2012 13:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=-0.227, 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 0LpYN3ytKTDl for ; Mon, 7 May 2012 13:28:56 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id F3E1D21F865D for ; Mon, 7 May 2012 13:28:55 -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 AFP28183; Mon, 07 May 2012 16:28:55 -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, 7 May 2012 13:27:05 -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, 7 May 2012 13:26:55 -0700 From: Lucy yong To: Lucy yong , Sam Cao , "l2vpn@ietf.org" Subject: RE: L2vpn Digest, Vol 96, Issue 15 Thread-Topic: L2vpn Digest, Vol 96, Issue 15 Thread-Index: Ac0qAqy9LTtQ75h0R2+YJ9mGFYIsPwAWFG9QAIs2guAAAeJ+0A== Date: Mon, 7 May 2012 20:26:55 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D330F57E4@dfweml505-mbx> References: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.149.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Jiangyuanlong 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, 07 May 2012 20:28:59 -0000 Sorry, I mean to say "concur", not "conquer" in previous mail. They sounds = same but completely different meanings. Lucy -----Original Message----- From: Lucy yong=20 Sent: Monday, May 07, 2012 2:58 PM To: 'Sam Cao'; l2vpn@ietf.org Cc: Jiangyuanlong Subject: RE: L2vpn Digest, Vol 96, Issue 15 Sam, I conquer Yuanlong's reply on this. Please see inline. Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of S= am Cao Sent: Friday, May 04, 2012 9:09 PM To: l2vpn@ietf.org Cc: Jiangyuanlong Subject: RE: L2vpn Digest, Vol 96, Issue 15 Lucy/Yuanlong, I agree that we can not say which approach is better simply, but I really agree with Josh's comments. Multi-PW is easy to implement E-Tree. [[LY]] I don't get impression Josh state this. First of all, we discussed 2 approaches for a long time and many rounds, an= d for me, there are no pending issues on Multi-PW till now or co-authors of multi-PW have given reasonable reply to L2VPN members' questions, but there are still pending issues for Dual-VLAN. Please trace the mailing list. [[LY]] I interpret this as people want to spend time to finalize dual VLAN = solution. Multi-PW has some operation impact. How do operator to maintain t= his service and be able to trouble shooting. How do you expect traceroute w= ork when using two PWs for one VPN? How do you expect PE report when there = is an error on one of two PWs? Do you have one FEC or two FEC for a E-Tree = in control plane? Second, Sasha has his concern in NP, or forwarding performance. Compared to current VPLS, Multi-PW has a little effect on forwarding performance since it reuse PW label as AC indicator; Dual-VLAN will have higher side effect o= n forwarding performance because it SHOULD use additional indicator. Is there one prototype for Dual-VLAN? BTW, there is no reply on chip limit. [[LY]] in VPLS, PW label is used as VSI indicator, not AC. I disagree your = statement here. Third, the difference between Multi-PW and dual-VLAN is, transport ingress traffic in one "LSP" or 2 "LSP". Multi-PW classifies and transforms ingress traffic into right "path", and egress just pop-out PW label and forward the frame to ACs. Dual-VLAN has more work on ingress PE or egress PE. [[LY]] Don't understand the first part. When egress pop-out PW label, it fi= nd corresponding VSI first, then perform MAC lookup associated to all ACs. = We can't assume there is one AC. =20 Fourth, maybe Giles has figured this out, Dual-VLAN has capacity limit. Onl= y 4094 VLAN ID are available, so only 2K E-Tree instances can be supported on one PE for Dual-VLAN approach. There is no such limit for Multi-PW approach= , [[LY]] If 4K VLAN ID is not an issue for VPLS, it is not an issue for E-Tre= e.=20 Finally, in this thread we don't make agreement on VLAN ID allocation. We also have questions on VLAN ID negotiation among PEs (signaling protocol). Yuanlong wishes to update, but there is no update till now. [[LY]] This should not be the reason to judge on the solution. For me, why IEEE uses VLAN ID to identify AC type? IEEE has no LABEL :), an= d it has label, it also wish to use label to identify AC types. I think that both solutions need much time to be perfect. Mutli-PW has less extension work to do. But now we are focusing on technical details and can not move forward :). =20 [[LY]] VPN label is used for identify the VPN. It already has the purpose. = Overloading with other meaning has high potential causing a problem. Hope y= ou can investigate it more. Since you are very in favor of multi-pw solutio= n, it is not proper for you to come out the conclusion which is better, bec= ause it is very biased. You are welcome to help on completing either soluti= on. Regards, Lucy Lucy Thanks, Sam -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of l2vpn-request@ietf.org Sent: Friday, May 04, 2012 10:31 PM To: l2vpn@ietf.org Subject: L2vpn Digest, Vol 96, Issue 15 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) 2. Re: The status of the approaches to the E-Tree solution? (Rogers, Josh) ---------------------------------------------------------------------- Message: 1 Date: Fri, 4 May 2012 14:16:36 +0000 From: Lucy yong To: "Rogers, Josh" , Jiangyuanlong , Daniel Cohn , "Fedyk, Donald (Don)" , "Henderickx, Wim (Wim)" Cc: "l2vpn@ietf.org" Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: <2691CE0099834E4A9C5044EEC662BB9D330E9114@dfweml505-mbx> Content-Type: text/plain; charset=3D"iso-8859-2" Josh, You simply say that you don't like IEEE Tree solution. IEEE Tree solution i= s for ingress port to mark and for egress port to filter. Regards, Lucy -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com]=20 Sent: Friday, May 04, 2012 7:27 AM To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong Cc: l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? [JY2] if the egress PE is attached with pure leafs, 2VLAN approach can also separate the leaf traffic in the ingress PE and filter it there (already detailed in the Optimization Mode in the I-D); if the egress PE is attached with pure roots or with both roots and leafs, it seems all traffic must be transported to the egress PE and be filtered there, I see no difference in behaviour for these solutions. Or did I miss something? The point is with the multi-PW method the traffic is split/separated (by psuedowire) on the ingress PE, rather than the egress. The distinction is 2VLAN will 'classify' the frame on the ingress PE, so that the egress PE knows how to forward it to the appropriate AC's. Both methods have inefficiencies (one duplicates traffic for transport, while the other transports where it doesn't need to go). I like the idea of classify and forwarding on the ingress PE, rather than marking it on the ingress, and deciding on the egress. -Josh On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: >Josh, thank you for the comments, please see my further comments with >[JY2]. > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Thursday, May 03, 2012 11:27 PM >To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >(Wim); Lucy yong >Cc: l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >requirements from MEF, it has nothing to do with the solutions. Could you >give a hint on how you can provision this service E-NNI otherwise? BTW, if >configuring or signalling two PWs is not a problem, why configuring or >signalling two VLANs will become a problem? After all, more nodes may need >to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >2VLAN (only T-PEs). > > >There is no other way (if both MPLS domains are part of the same ETREE, >rather than doing something more like H-VPLS, where one domain has point >to points to the other domain which handles the ETREE instance) if you are >using an ENNI. The other method, (not mentioned earlier) is tying the two >MPLS domains together via labeled unicast (much preferred over E-NNI in my >opinion) > >Configuring two VLAN's isn't really a 'problem' any more than two PW's. I >wasn't saying that configuring two VLAN's was difficult, I was objecting >to the statement that configuring two PW's is difficult. > >[JY2] Thanks, I see your point. I take the example of 2PW configuration >just to show that using fixed global values to simplify configuration >makes no sense. Personally I also don't think configuration is a problem >for both solutions. > >I find the differences between these two methods rather slight. The >'tie-breaker' for me is by placing the forwarding decision on the ingress >PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >more control over where the traffic goes, and in my mind it provides a >cleaner destination between customer traffic and forwarding plane. I'm >accustomed to looking at a psuedowire and knowing where its going, with >the 2vlan method, I can see the psuedowire, but must go to the egress PE >to see if it will be dropped there, or forwarded to one or more AC's. > >[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >also separate the leaf traffic in the ingress PE and filter it there >(already detailed in the Optimization Mode in the I-D); if the egress PE >is attached with pure roots or with both roots and leafs, it seems all >traffic must be transported to the egress PE and be filtered there, I see >no difference in behaviour for these solutions. Or did I miss something? > >Again, the difference here is slight, and I would honestly be happy to see >either of them come to fruition. Please don't infer that I think the >2vlan method is 'bad' or has intrinsic problems, because I don't believe >that. I just prefer the multi-PW method. > > >-Josh > > >On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: > >>Josh, please see my comments in line. >> >>Thanks >>Yuanlong >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Thursday, May 03, 2012 10:51 AM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>Yuanlong, >> >>Or better yet, include in the draft a 'standard' value for root sourced >>VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You would als= o >>have to require the the implementation NOT use global VLAN's, however >>(since each instance would be using the same values). In this way, no >>signaling or manual configuration is required for remote PE's to know how >>to classify traffic. >>[JY] Indeed, we discussed this possibility during the f2f meeting in >>Paris. But, there are some restrictions as you mentioned, and >>furthermore: >>1) Some vendors already used S-VLAN to distinguish their VSIs in the PE; >>2) Forwarding plane of a PE needs to be revised to be aware of this VLAN >>ID. >>Therefore, this 'standard value' approach seems more disruptive compared >>with the other means and not a good candidate option. >> >>Regarding switching PE's? Multi-PW means more than one PW, yes. I don't >>see this as a real problem. In general, design should try and avoid >>using >>S-PE's, but if you must, its going to mean extra work, no matter how you >>look at it. Two PW's for each Etree being switched instead of one is not >>alarming or concerning to me. On the other hand, if you use a dot1q >>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's an >>two egress VLAN's if you want the Etree to be handled on both sides (and >>if you use the 'standard' VID's as I mentioned above, you'd have to do >>mapping to non-standard and back) >>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>requirements from MEF, it has nothing to do with the solutions. Could you >>give a hint on how you can provision this service E-NNI otherwise? BTW, >>if configuring or signalling two PWs is not a problem, why configuring or >>signalling two VLANs will become a problem? After all, more nodes may >>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>with 2VLAN (only T-PEs). >> >>In general, I still prefer multi-PW, primarily because I prefer the >>separation of the traffic in the network's forwarding plane, rather than >>shipping it everywhere and deciding whether to forward to the AC when it >>gets to the egress PE. I'm having a hard time putting my finger exactly >>on what it is, or articulating the idea, but it seems that by having the >>traffic placed into two psuedowires, I have more flexibility and ease of >>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>PW's could really change that perception. >>[JY] Are you saying that we need to develop a totally new forwarding >>plane rather than using the Ethernet forwarding plane as described in the >>existing work? >> >>I hope we can move forward with one of these soon, >>[JY] me too. >> >>Josh >> >> >>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >> >>>Daniel, >>> >>>Not aware that we had a discussion on this before, but IMHO the >>>allocation of internal S-VLAN can be automatic, and manuel configuration >>>of this mapping may not be needed at all. For example, an S-VLAN >>>allocation module in the management plane in a PE can do this kind of >>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>way from a free S-VLAN ID pool. Once the interal S-VLANs are allocated, >>>the mapping is determined and no other configuration is needed. >>> >>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>allocate >>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to allocate >>>two S-VLANs in the VPLS domain. >>> >>>On the other hand, for the multi-PW approach, two PWs need to be >>>configured for a E-Tree service. When MS-PW is used in the network, for >>>every S-PE, we need to configure two ingress PW segments and two egress >>>PW segments. In this case, I don't think we need to use fixed PW labels >>>across the network for fear of configuration complexity. >>> >>>Regards, >>>Yuanlong >>> >>>-----Original Message----- >>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>Sent: Wednesday, May 02, 2012 8:01 PM >>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>yong; >>>josh.rogers@twcable.com >>>Cc: l2vpn@ietf.org >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Inline. >>> >>>-----Original Message----- >>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>Sent: Wednesday, May 02, 2012 12:30 PM >>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>josh.rogers@twcable.com >>>Cc: l2vpn@ietf.org >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Hi Daniel, Please see my comments in line. >>> >>> >>>-----Original Message----- >>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>Sent: Wednesday, May 02, 2012 3:55 PM >>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>yong; josh.rogers@twcable.com >>>Cc: l2vpn@ietf.org >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Hi Yuanlong, >>> >>>The problem is not with the total number of S-VLAN IDs, I agree that >>>normally there won't be more than 2047. The problem is that if you don't >>>support all VLAN IDs, you need S-VLAN space coordination with the >>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to 2047". >>>Which won't always be in line with an existing deployment. >>>[JY] This is not the case. If the total number is no more than 2047, it >>>surely can be supported. The S-VLAN space of user domain is totally >>>different from the S-VLAN in the provider domain and they can be >>>overlapped, I don't see why we need S-VLAN space coordination between >>>them. >>> >>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>fixed, and therefore the IEEE S-VID that can be supported is also fixed. >>> >>>Of course you can configure the mapping in each PE according to operator >>>requirements but as we discussed before this increases complexity. >>> >>>Relying on PBB-VPLS imposes additional limitations on backward >>>compatibility. >>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>think they may well need MAC-in-MAC in their networks for the >>>scalability issue. As you know, only PBB VPLS can provide both. >>> >>>Daniel >>> >>>-----Original Message----- >>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>Sent: Wednesday, May 02, 2012 5:07 AM >>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>josh.rogers@twcable.com >>>Cc: l2vpn@ietf.org >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Hi Daniel, >>> >>>As you can see, both cases are discussed in the I-D. >>> >>>With regard to case 1) (that is, S-VLAN translation), since the access >>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>they need to be configured on a PE anyway, and as the past emails by >>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>mapping. >>> >>>With regard to S-VID space reduction, the constraint is valid only when >>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>typical and with no such limits as we already discussed in the f2f >>>meeting. >>> >>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>described (not sure this is a valid use case in real life), PBB-VPLS can >>>still be used. >>> >>>Regards, >>>Yuanlong >>> >>>-----Original Message----- >>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>Sent: Monday, April 30, 2012 10:34 PM >>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>Jiangyuanlong; josh.rogers@twcable.com >>>Cc: l2vpn@ietf.org >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>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] >>>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 >>> >>>---------------------------------------------------------------------- >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject to >>copyright belonging to Time Warner Cable. This E-mail is intended solely >>for the use of the individual or entity to which it is addressed. If you >>are not the intended recipient of this E-mail, you are hereby notified >>that any dissemination, distribution, copying, or action taken in >>relation to the contents of and attachments to this E-mail is strictly >>prohibited and may be unlawful. If you have received this 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. ------------------------------ Message: 2 Date: Fri, 4 May 2012 10:30:38 -0400 From: "Rogers, Josh" To: Lucy yong , Jiangyuanlong , Daniel Cohn , "Fedyk, Donald (Don)" , "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"iso-8859-2" To be more accurate, I like it less than the multi-PW solution. I'd be happy to use the 2VLAN solution in the real world, if it was ratified as the standard. On 5/4/12 9:16 AM, "Lucy yong" wrote: >Josh, > >You simply say that you don't like IEEE Tree solution. IEEE Tree solution >is for ingress port to mark and for egress port to filter. > >Regards, >Lucy > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Friday, May 04, 2012 7:27 AM >To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >(Wim); Lucy yong >Cc: l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >also separate the leaf traffic in the ingress PE and filter it there >(already detailed in the Optimization Mode in the I-D); if the egress PE >is attached with pure roots or with both roots and leafs, it seems all >traffic must be transported to the egress PE and be filtered there, I see >no difference in behaviour for these solutions. Or did I miss something? > > >The point is with the multi-PW method the traffic is split/separated (by >psuedowire) on the ingress PE, rather than the egress. The distinction is >2VLAN will 'classify' the frame on the ingress PE, so that the egress PE >knows how to forward it to the appropriate AC's. > >Both methods have inefficiencies (one duplicates traffic for transport, >while the other transports where it doesn't need to go). I like the idea >of classify and forwarding on the ingress PE, rather than marking it on >the ingress, and deciding on the egress. > >-Josh > > > >On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: > >>Josh, thank you for the comments, please see my further comments with >>[JY2]. >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Thursday, May 03, 2012 11:27 PM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>requirements from MEF, it has nothing to do with the solutions. Could you >>give a hint on how you can provision this service E-NNI otherwise? BTW, >>if >>configuring or signalling two PWs is not a problem, why configuring or >>signalling two VLANs will become a problem? After all, more nodes may >>need >>to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >>2VLAN (only T-PEs). >> >> >>There is no other way (if both MPLS domains are part of the same ETREE, >>rather than doing something more like H-VPLS, where one domain has point >>to points to the other domain which handles the ETREE instance) if you >>are >>using an ENNI. The other method, (not mentioned earlier) is tying the >>two >>MPLS domains together via labeled unicast (much preferred over E-NNI in >>my >>opinion) >> >>Configuring two VLAN's isn't really a 'problem' any more than two PW's. >>I >>wasn't saying that configuring two VLAN's was difficult, I was objecting >>to the statement that configuring two PW's is difficult. >> >>[JY2] Thanks, I see your point. I take the example of 2PW configuration >>just to show that using fixed global values to simplify configuration >>makes no sense. Personally I also don't think configuration is a problem >>for both solutions. >> >>I find the differences between these two methods rather slight. The >>'tie-breaker' for me is by placing the forwarding decision on the ingress >>PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >>more control over where the traffic goes, and in my mind it provides a >>cleaner destination between customer traffic and forwarding plane. I'm >>accustomed to looking at a psuedowire and knowing where its going, with >>the 2vlan method, I can see the psuedowire, but must go to the egress PE >>to see if it will be dropped there, or forwarded to one or more AC's. >> >>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>also separate the leaf traffic in the ingress PE and filter it there >>(already detailed in the Optimization Mode in the I-D); if the egress PE >>is attached with pure roots or with both roots and leafs, it seems all >>traffic must be transported to the egress PE and be filtered there, I see >>no difference in behaviour for these solutions. Or did I miss something? >> >>Again, the difference here is slight, and I would honestly be happy to >>see >>either of them come to fruition. Please don't infer that I think the >>2vlan method is 'bad' or has intrinsic problems, because I don't believe >>that. I just prefer the multi-PW method. >> >> >>-Josh >> >> >>On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: >> >>>Josh, please see my comments in line. >>> >>>Thanks >>>Yuanlong >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Thursday, May 03, 2012 10:51 AM >>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>(Wim); Lucy yong >>>Cc: l2vpn@ietf.org >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Yuanlong, >>> >>>Or better yet, include in the draft a 'standard' value for root sourced >>>VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You would al= so >>>have to require the the implementation NOT use global VLAN's, however >>>(since each instance would be using the same values). In this way, no >>>signaling or manual configuration is required for remote PE's to know >>>how >>>to classify traffic. >>>[JY] Indeed, we discussed this possibility during the f2f meeting in >>>Paris. But, there are some restrictions as you mentioned, and >>>furthermore: >>>1) Some vendors already used S-VLAN to distinguish their VSIs in the PE; >>>2) Forwarding plane of a PE needs to be revised to be aware of this VLAN >>>ID. >>>Therefore, this 'standard value' approach seems more disruptive compared >>>with the other means and not a good candidate option. >>> >>>Regarding switching PE's? Multi-PW means more than one PW, yes. I >>>don't >>>see this as a real problem. In general, design should try and avoid >>>using >>>S-PE's, but if you must, its going to mean extra work, no matter how you >>>look at it. Two PW's for each Etree being switched instead of one is >>>not >>>alarming or concerning to me. On the other hand, if you use a dot1q >>>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's >>>an >>>two egress VLAN's if you want the Etree to be handled on both sides (and >>>if you use the 'standard' VID's as I mentioned above, you'd have to do >>>mapping to non-standard and back) >>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>requirements from MEF, it has nothing to do with the solutions. Could >>>you >>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>if configuring or signalling two PWs is not a problem, why configuring >>>or >>>signalling two VLANs will become a problem? After all, more nodes may >>>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>>with 2VLAN (only T-PEs). >>> >>>In general, I still prefer multi-PW, primarily because I prefer the >>>separation of the traffic in the network's forwarding plane, rather than >>>shipping it everywhere and deciding whether to forward to the AC when it >>>gets to the egress PE. I'm having a hard time putting my finger exactly >>>on what it is, or articulating the idea, but it seems that by having the >>>traffic placed into two psuedowires, I have more flexibility and ease of >>>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>>PW's could really change that perception. >>>[JY] Are you saying that we need to develop a totally new forwarding >>>plane rather than using the Ethernet forwarding plane as described in >>>the >>>existing work? >>> >>>I hope we can move forward with one of these soon, >>>[JY] me too. >>> >>>Josh >>> >>> >>>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >>> >>>>Daniel, >>>> >>>>Not aware that we had a discussion on this before, but IMHO the >>>>allocation of internal S-VLAN can be automatic, and manuel >>>>configuration >>>>of this mapping may not be needed at all. For example, an S-VLAN >>>>allocation module in the management plane in a PE can do this kind of >>>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>>way from a free S-VLAN ID pool. Once the interal S-VLANs are allocated, >>>>the mapping is determined and no other configuration is needed. >>>> >>>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>>allocate >>>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to allocate >>>>two S-VLANs in the VPLS domain. >>>> >>>>On the other hand, for the multi-PW approach, two PWs need to be >>>>configured for a E-Tree service. When MS-PW is used in the network, for >>>>every S-PE, we need to configure two ingress PW segments and two egress >>>>PW segments. In this case, I don't think we need to use fixed PW labels >>>>across the network for fear of configuration complexity. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 8:01 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Inline. >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 12:30 PM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, Please see my comments in line. >>>> >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 3:55 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Yuanlong, >>>> >>>>The problem is not with the total number of S-VLAN IDs, I agree that >>>>normally there won't be more than 2047. The problem is that if you >>>>don't >>>>support all VLAN IDs, you need S-VLAN space coordination with the >>>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to >>>>2047". >>>>Which won't always be in line with an existing deployment. >>>>[JY] This is not the case. If the total number is no more than 2047, it >>>>surely can be supported. The S-VLAN space of user domain is totally >>>>different from the S-VLAN in the provider domain and they can be >>>>overlapped, I don't see why we need S-VLAN space coordination between >>>>them. >>>> >>>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>>fixed, and therefore the IEEE S-VID that can be supported is also >>>>fixed. >>>> >>>>Of course you can configure the mapping in each PE according to >>>>operator >>>>requirements but as we discussed before this increases complexity. >>>> >>>>Relying on PBB-VPLS imposes additional limitations on backward >>>>compatibility. >>>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>>think they may well need MAC-in-MAC in their networks for the >>>>scalability issue. As you know, only PBB VPLS can provide both. >>>> >>>>Daniel >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 5:07 AM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, >>>> >>>>As you can see, both cases are discussed in the I-D. >>>> >>>>With regard to case 1) (that is, S-VLAN translation), since the access >>>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>>they need to be configured on a PE anyway, and as the past emails by >>>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>>mapping. >>>> >>>>With regard to S-VID space reduction, the constraint is valid only when >>>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>>typical and with no such limits as we already discussed in the f2f >>>>meeting. >>>> >>>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>>described (not sure this is a valid use case in real life), PBB-VPLS >>>>can >>>>still be used. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Monday, April 30, 2012 10:34 PM >>>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>Jiangyuanlong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>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] >>>>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 >>>> >>>>---------------------------------------------------------------------- >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to >>>copyright belonging to Time Warner Cable. This E-mail is intended solely >>>for the use of the individual or entity to which it is addressed. If you >>>are not the intended recipient of this E-mail, you are hereby notified >>>that any dissemination, distribution, copying, or action taken in >>>relation to the contents of and attachments to this E-mail is strictly >>>prohibited and may be unlawful. If you have received this 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 and any of its attachments may contain 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. ------------------------------ _______________________________________________ L2vpn mailing list L2vpn@ietf.org https://www.ietf.org/mailman/listinfo/l2vpn End of L2vpn Digest, Vol 96, Issue 15 ************************************* From josh.rogers@twcable.com Mon May 7 14:22: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 38A6921F86DE for ; Mon, 7 May 2012 14:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.023 X-Spam-Level: X-Spam-Status: No, score=0.023 tagged_above=-999 required=5 tests=[AWL=-0.114, 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 yHdF43tMmkRU for ; Mon, 7 May 2012 14:22:01 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7BAC621F86CA for ; Mon, 7 May 2012 14:22:01 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.75,546,1330923600"; d="scan'208";a="361170830" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 07 May 2012 17:20:43 -0400 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.36]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Mon, 7 May 2012 17:22:00 -0400 From: "Rogers, Josh" To: Lucy yong , Sam Cao , "l2vpn@ietf.org" Date: Mon, 7 May 2012 17:21:57 -0400 Subject: Re: L2vpn Digest, Vol 96, Issue 15 Thread-Topic: L2vpn Digest, Vol 96, Issue 15 Thread-Index: Ac0sl3BPTsy8rmZ9Qwu92fZcvZ3VKg== Message-ID: In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D330F0740@dfweml506-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: Jiangyuanlong 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, 07 May 2012 21:22:05 -0000 Comments inline (and s/conquer/concur/) On 5/7/12 2:58 PM, "Lucy yong" wrote: >Sam, > >I concur with Yuanlong's reply on this. Please see inline. > >Lucy > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >Sam Cao >Sent: Friday, May 04, 2012 9:09 PM >To: l2vpn@ietf.org >Cc: Jiangyuanlong >Subject: RE: L2vpn Digest, Vol 96, Issue 15 > >Lucy/Yuanlong, > >I agree that we can not say which approach is better simply, but I really >agree with Josh's comments. Multi-PW is easy to implement E-Tree. >[[LY]] I don't get impression Josh state this. > >First of all, we discussed 2 approaches for a long time and many rounds, >and >for me, there are no pending issues on Multi-PW till now or co-authors of >multi-PW have given reasonable reply to L2VPN members' questions, but >there >are still pending issues for Dual-VLAN. Please trace the mailing list. >[[LY]] I interpret this as people want to spend time to finalize dual >VLAN solution. Multi-PW has some operation impact. How do operator to >maintain this service and be able to trouble shooting. How do you expect >traceroute work when using two PWs for one VPN? How do you expect PE >report when there is an error on one of two PWs? Do you have one FEC or >two FEC for a E-Tree in control plane? [JR] I don't see this any more of a problem than troubleshooting one. If LDP is used, a simple mols traceroute shows the path that ALL PW's to that PE take, regardless of which service (this VPLS or another VPLS instance). If RSVP is used, there should be a route-object that shows me the path, and allows me to troubleshoot. Additionally, if I wanted to have traffic engineering that impacted root-sourced and leaf-sourced traffic differently, I can do that with multi-PW, where I could not (save for ingress/egress) with the 2VLAN approach. PE should report signaling on second PW same as it does for the 100th PW between PE's. Again, I don't see the problem you are alluding to. > >Second, Sasha has his concern in NP, or forwarding performance. Compared >to >current VPLS, Multi-PW has a little effect on forwarding performance since >it reuse PW label as AC indicator; Dual-VLAN will have higher side effect >on >forwarding performance because it SHOULD use additional indicator. Is >there >one prototype for Dual-VLAN? BTW, there is no reply on chip limit. >[[LY]] in VPLS, PW label is used as VSI indicator, not AC. I disagree >your statement here. > >Third, the difference between Multi-PW and dual-VLAN is, transport ingress >traffic in one "LSP" or 2 "LSP". Multi-PW classifies and transforms >ingress >traffic into right "path", and egress just pop-out PW label and forward >the >frame to ACs. Dual-VLAN has more work on ingress PE or egress PE. >[[LY]] Don't understand the first part. When egress pop-out PW label, it >find corresponding VSI first, then perform MAC lookup associated to all >ACs. We can't assume there is one AC. > >Fourth, maybe Giles has figured this out, Dual-VLAN has capacity limit. >Only >4094 VLAN ID are available, so only 2K E-Tree instances can be supported >on >one PE for Dual-VLAN approach. There is no such limit for Multi-PW >approach, >[[LY]] If 4K VLAN ID is not an issue for VPLS, it is not an issue for >E-Tree. > >Finally, in this thread we don't make agreement on VLAN ID allocation. We >also have questions on VLAN ID negotiation among PEs (signaling protocol). >Yuanlong wishes to update, but there is no update till now. >[[LY]] This should not be the reason to judge on the solution. [JR] I tend to agree. > >For me, why IEEE uses VLAN ID to identify AC type? IEEE has no LABEL :), >and >it has label, it also wish to use label to identify AC types. I think that >both solutions need much time to be perfect. Mutli-PW has less extension >work to do. But now we are focusing on technical details and can not move >forward :). >[[LY]] VPN label is used for identify the VPN. It already has the >purpose. Overloading with other meaning has high potential causing a >problem. Hope you can investigate it more. Since you are very in favor of >multi-pw solution, it is not proper for you to come out the conclusion >which is better, because it is very biased. You are welcome to help on >completing either solution. [JR] this is humorous to me, because at one time, VLAN-ID was used to identify a single broadcast domain, and then later asymmetrical VID's were used to limit communication between endpoints of a broadcast domain (effectively creating two one-way broadcast domains, very similar to what we're accomplishing with ETREE). This should not be the reason to judge on the solution. > >Regards, >Lucy > >Lucy > >Thanks, > >Sam > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >l2vpn-request@ietf.org >Sent: Friday, May 04, 2012 10:31 PM >To: l2vpn@ietf.org >Subject: L2vpn Digest, Vol 96, Issue 15 > >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) > 2. Re: The status of the approaches to the E-Tree solution? > (Rogers, Josh) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Fri, 4 May 2012 14:16:36 +0000 >From: Lucy yong >To: "Rogers, Josh" , Jiangyuanlong > , Daniel Cohn , >"Fedyk, > Donald (Don)" , "Henderickx, Wim > (Wim)" >Cc: "l2vpn@ietf.org" >Subject: RE: The status of the approaches to the E-Tree solution? >Message-ID: <2691CE0099834E4A9C5044EEC662BB9D330E9114@dfweml505-mbx> >Content-Type: text/plain; charset=3D"iso-8859-2" > >Josh, > >You simply say that you don't like IEEE Tree solution. IEEE Tree solution >is >for ingress port to mark and for egress port to filter. > >Regards, >Lucy > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Friday, May 04, 2012 7:27 AM >To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >(Wim); >Lucy yong >Cc: l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >also separate the leaf traffic in the ingress PE and filter it there >(already detailed in the Optimization Mode in the I-D); if the egress PE >is attached with pure roots or with both roots and leafs, it seems all >traffic must be transported to the egress PE and be filtered there, I see >no difference in behaviour for these solutions. Or did I miss something? > > >The point is with the multi-PW method the traffic is split/separated (by >psuedowire) on the ingress PE, rather than the egress. The distinction is >2VLAN will 'classify' the frame on the ingress PE, so that the egress PE >knows how to forward it to the appropriate AC's. > >Both methods have inefficiencies (one duplicates traffic for transport, >while the other transports where it doesn't need to go). I like the idea >of classify and forwarding on the ingress PE, rather than marking it on >the ingress, and deciding on the egress. > >-Josh > > > >On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: > >>Josh, thank you for the comments, please see my further comments with >>[JY2]. >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Thursday, May 03, 2012 11:27 PM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>requirements from MEF, it has nothing to do with the solutions. Could you >>give a hint on how you can provision this service E-NNI otherwise? BTW, >>if >>configuring or signalling two PWs is not a problem, why configuring or >>signalling two VLANs will become a problem? After all, more nodes may >>need >>to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >>2VLAN (only T-PEs). >> >> >>There is no other way (if both MPLS domains are part of the same ETREE, >>rather than doing something more like H-VPLS, where one domain has point >>to points to the other domain which handles the ETREE instance) if you >>are >>using an ENNI. The other method, (not mentioned earlier) is tying the >>two >>MPLS domains together via labeled unicast (much preferred over E-NNI in >>my >>opinion) >> >>Configuring two VLAN's isn't really a 'problem' any more than two PW's. >>I >>wasn't saying that configuring two VLAN's was difficult, I was objecting >>to the statement that configuring two PW's is difficult. >> >>[JY2] Thanks, I see your point. I take the example of 2PW configuration >>just to show that using fixed global values to simplify configuration >>makes no sense. Personally I also don't think configuration is a problem >>for both solutions. >> >>I find the differences between these two methods rather slight. The >>'tie-breaker' for me is by placing the forwarding decision on the ingress >>PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >>more control over where the traffic goes, and in my mind it provides a >>cleaner destination between customer traffic and forwarding plane. I'm >>accustomed to looking at a psuedowire and knowing where its going, with >>the 2vlan method, I can see the psuedowire, but must go to the egress PE >>to see if it will be dropped there, or forwarded to one or more AC's. >> >>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>also separate the leaf traffic in the ingress PE and filter it there >>(already detailed in the Optimization Mode in the I-D); if the egress PE >>is attached with pure roots or with both roots and leafs, it seems all >>traffic must be transported to the egress PE and be filtered there, I see >>no difference in behaviour for these solutions. Or did I miss something? >> >>Again, the difference here is slight, and I would honestly be happy to >>see >>either of them come to fruition. Please don't infer that I think the >>2vlan method is 'bad' or has intrinsic problems, because I don't believe >>that. I just prefer the multi-PW method. >> >> >>-Josh >> >> >>On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: >> >>>Josh, please see my comments in line. >>> >>>Thanks >>>Yuanlong >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Thursday, May 03, 2012 10:51 AM >>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>(Wim); Lucy yong >>>Cc: l2vpn@ietf.org >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Yuanlong, >>> >>>Or better yet, include in the draft a 'standard' value for root sourced >>>VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You would al= so >>>have to require the the implementation NOT use global VLAN's, however >>>(since each instance would be using the same values). In this way, no >>>signaling or manual configuration is required for remote PE's to know >>>how >>>to classify traffic. >>>[JY] Indeed, we discussed this possibility during the f2f meeting in >>>Paris. But, there are some restrictions as you mentioned, and >>>furthermore: >>>1) Some vendors already used S-VLAN to distinguish their VSIs in the PE; >>>2) Forwarding plane of a PE needs to be revised to be aware of this VLAN >>>ID. >>>Therefore, this 'standard value' approach seems more disruptive compared >>>with the other means and not a good candidate option. >>> >>>Regarding switching PE's? Multi-PW means more than one PW, yes. I >>>don't >>>see this as a real problem. In general, design should try and avoid >>>using >>>S-PE's, but if you must, its going to mean extra work, no matter how you >>>look at it. Two PW's for each Etree being switched instead of one is >>>not >>>alarming or concerning to me. On the other hand, if you use a dot1q >>>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's >>>an >>>two egress VLAN's if you want the Etree to be handled on both sides (and >>>if you use the 'standard' VID's as I mentioned above, you'd have to do >>>mapping to non-standard and back) >>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>requirements from MEF, it has nothing to do with the solutions. Could >>>you >>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>if configuring or signalling two PWs is not a problem, why configuring >>>or >>>signalling two VLANs will become a problem? After all, more nodes may >>>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>>with 2VLAN (only T-PEs). >>> >>>In general, I still prefer multi-PW, primarily because I prefer the >>>separation of the traffic in the network's forwarding plane, rather than >>>shipping it everywhere and deciding whether to forward to the AC when it >>>gets to the egress PE. I'm having a hard time putting my finger exactly >>>on what it is, or articulating the idea, but it seems that by having the >>>traffic placed into two psuedowires, I have more flexibility and ease of >>>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>>PW's could really change that perception. >>>[JY] Are you saying that we need to develop a totally new forwarding >>>plane rather than using the Ethernet forwarding plane as described in >>>the >>>existing work? >>> >>>I hope we can move forward with one of these soon, >>>[JY] me too. >>> >>>Josh >>> >>> >>>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >>> >>>>Daniel, >>>> >>>>Not aware that we had a discussion on this before, but IMHO the >>>>allocation of internal S-VLAN can be automatic, and manuel >>>>configuration >>>>of this mapping may not be needed at all. For example, an S-VLAN >>>>allocation module in the management plane in a PE can do this kind of >>>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>>way from a free S-VLAN ID pool. Once the interal S-VLANs are allocated, >>>>the mapping is determined and no other configuration is needed. >>>> >>>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>>allocate >>>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to allocate >>>>two S-VLANs in the VPLS domain. >>>> >>>>On the other hand, for the multi-PW approach, two PWs need to be >>>>configured for a E-Tree service. When MS-PW is used in the network, for >>>>every S-PE, we need to configure two ingress PW segments and two egress >>>>PW segments. In this case, I don't think we need to use fixed PW labels >>>>across the network for fear of configuration complexity. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 8:01 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Inline. >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 12:30 PM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, Please see my comments in line. >>>> >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 3:55 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Yuanlong, >>>> >>>>The problem is not with the total number of S-VLAN IDs, I agree that >>>>normally there won't be more than 2047. The problem is that if you >>>>don't >>>>support all VLAN IDs, you need S-VLAN space coordination with the >>>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to >>>>2047". >>>>Which won't always be in line with an existing deployment. >>>>[JY] This is not the case. If the total number is no more than 2047, it >>>>surely can be supported. The S-VLAN space of user domain is totally >>>>different from the S-VLAN in the provider domain and they can be >>>>overlapped, I don't see why we need S-VLAN space coordination between >>>>them. >>>> >>>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>>fixed, and therefore the IEEE S-VID that can be supported is also >>>>fixed. >>>> >>>>Of course you can configure the mapping in each PE according to >>>>operator >>>>requirements but as we discussed before this increases complexity. >>>> >>>>Relying on PBB-VPLS imposes additional limitations on backward >>>>compatibility. >>>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>>think they may well need MAC-in-MAC in their networks for the >>>>scalability issue. As you know, only PBB VPLS can provide both. >>>> >>>>Daniel >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 5:07 AM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, >>>> >>>>As you can see, both cases are discussed in the I-D. >>>> >>>>With regard to case 1) (that is, S-VLAN translation), since the access >>>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>>they need to be configured on a PE anyway, and as the past emails by >>>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>>mapping. >>>> >>>>With regard to S-VID space reduction, the constraint is valid only when >>>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>>typical and with no such limits as we already discussed in the f2f >>>>meeting. >>>> >>>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>>described (not sure this is a valid use case in real life), PBB-VPLS >>>>can >>>>still be used. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Monday, April 30, 2012 10:34 PM >>>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>Jiangyuanlong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>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] >>>>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 >>>> >>>>---------------------------------------------------------------------- >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to >>>copyright belonging to Time Warner Cable. This E-mail is intended solely >>>for the use of the individual or entity to which it is addressed. If you >>>are not the intended recipient of this E-mail, you are hereby notified >>>that any dissemination, distribution, copying, or action taken in >>>relation to the contents of and attachments to this E-mail is strictly >>>prohibited and may be unlawful. If you have received this 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. > > >------------------------------ > >Message: 2 >Date: Fri, 4 May 2012 10:30:38 -0400 >From: "Rogers, Josh" >To: Lucy yong , Jiangyuanlong > , Daniel Cohn , >"Fedyk, > Donald (Don)" , "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"iso-8859-2" > >To be more accurate, I like it less than the multi-PW solution. I'd be >happy to use the 2VLAN solution in the real world, if it was ratified as >the standard. > > > >On 5/4/12 9:16 AM, "Lucy yong" wrote: > >>Josh, >> >>You simply say that you don't like IEEE Tree solution. IEEE Tree solution >>is for ingress port to mark and for egress port to filter. >> >>Regards, >>Lucy >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Friday, May 04, 2012 7:27 AM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>also separate the leaf traffic in the ingress PE and filter it there >>(already detailed in the Optimization Mode in the I-D); if the egress PE >>is attached with pure roots or with both roots and leafs, it seems all >>traffic must be transported to the egress PE and be filtered there, I see >>no difference in behaviour for these solutions. Or did I miss something? >> >> >>The point is with the multi-PW method the traffic is split/separated (by >>psuedowire) on the ingress PE, rather than the egress. The distinction >>is >>2VLAN will 'classify' the frame on the ingress PE, so that the egress PE >>knows how to forward it to the appropriate AC's. >> >>Both methods have inefficiencies (one duplicates traffic for transport, >>while the other transports where it doesn't need to go). I like the idea >>of classify and forwarding on the ingress PE, rather than marking it on >>the ingress, and deciding on the egress. >> >>-Josh >> >> >> >>On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: >> >>>Josh, thank you for the comments, please see my further comments with >>>[JY2]. >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Thursday, May 03, 2012 11:27 PM >>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>(Wim); Lucy yong >>>Cc: l2vpn@ietf.org >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>requirements from MEF, it has nothing to do with the solutions. Could >>>you >>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>if >>>configuring or signalling two PWs is not a problem, why configuring or >>>signalling two VLANs will become a problem? After all, more nodes may >>>need >>>to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >>>2VLAN (only T-PEs). >>> >>> >>>There is no other way (if both MPLS domains are part of the same ETREE, >>>rather than doing something more like H-VPLS, where one domain has point >>>to points to the other domain which handles the ETREE instance) if you >>>are >>>using an ENNI. The other method, (not mentioned earlier) is tying the >>>two >>>MPLS domains together via labeled unicast (much preferred over E-NNI in >>>my >>>opinion) >>> >>>Configuring two VLAN's isn't really a 'problem' any more than two PW's. >>>I >>>wasn't saying that configuring two VLAN's was difficult, I was objecting >>>to the statement that configuring two PW's is difficult. >>> >>>[JY2] Thanks, I see your point. I take the example of 2PW configuration >>>just to show that using fixed global values to simplify configuration >>>makes no sense. Personally I also don't think configuration is a problem >>>for both solutions. >>> >>>I find the differences between these two methods rather slight. The >>>'tie-breaker' for me is by placing the forwarding decision on the >>>ingress >>>PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >>>more control over where the traffic goes, and in my mind it provides a >>>cleaner destination between customer traffic and forwarding plane. I'm >>>accustomed to looking at a psuedowire and knowing where its going, with >>>the 2vlan method, I can see the psuedowire, but must go to the egress PE >>>to see if it will be dropped there, or forwarded to one or more AC's. >>> >>>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>>also separate the leaf traffic in the ingress PE and filter it there >>>(already detailed in the Optimization Mode in the I-D); if the egress PE >>>is attached with pure roots or with both roots and leafs, it seems all >>>traffic must be transported to the egress PE and be filtered there, I >>>see >>>no difference in behaviour for these solutions. Or did I miss something? >>> >>>Again, the difference here is slight, and I would honestly be happy to >>>see >>>either of them come to fruition. Please don't infer that I think the >>>2vlan method is 'bad' or has intrinsic problems, because I don't believe >>>that. I just prefer the multi-PW method. >>> >>> >>>-Josh >>> >>> >>>On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: >>> >>>>Josh, please see my comments in line. >>>> >>>>Thanks >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>>Sent: Thursday, May 03, 2012 10:51 AM >>>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>>(Wim); Lucy yong >>>>Cc: l2vpn@ietf.org >>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>> >>>>Yuanlong, >>>> >>>>Or better yet, include in the draft a 'standard' value for root sourced >>>>VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You would a= lso >>>>have to require the the implementation NOT use global VLAN's, however >>>>(since each instance would be using the same values). In this way, no >>>>signaling or manual configuration is required for remote PE's to know >>>>how >>>>to classify traffic. >>>>[JY] Indeed, we discussed this possibility during the f2f meeting in >>>>Paris. But, there are some restrictions as you mentioned, and >>>>furthermore: >>>>1) Some vendors already used S-VLAN to distinguish their VSIs in the >>>>PE; >>>>2) Forwarding plane of a PE needs to be revised to be aware of this >>>>VLAN >>>>ID. >>>>Therefore, this 'standard value' approach seems more disruptive >>>>compared >>>>with the other means and not a good candidate option. >>>> >>>>Regarding switching PE's? Multi-PW means more than one PW, yes. I >>>>don't >>>>see this as a real problem. In general, design should try and avoid >>>>using >>>>S-PE's, but if you must, its going to mean extra work, no matter how >>>>you >>>>look at it. Two PW's for each Etree being switched instead of one is >>>>not >>>>alarming or concerning to me. On the other hand, if you use a dot1q >>>>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's >>>>an >>>>two egress VLAN's if you want the Etree to be handled on both sides >>>>(and >>>>if you use the 'standard' VID's as I mentioned above, you'd have to do >>>>mapping to non-standard and back) >>>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>>requirements from MEF, it has nothing to do with the solutions. Could >>>>you >>>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>>if configuring or signalling two PWs is not a problem, why configuring >>>>or >>>>signalling two VLANs will become a problem? After all, more nodes may >>>>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>>>with 2VLAN (only T-PEs). >>>> >>>>In general, I still prefer multi-PW, primarily because I prefer the >>>>separation of the traffic in the network's forwarding plane, rather >>>>than >>>>shipping it everywhere and deciding whether to forward to the AC when >>>>it >>>>gets to the egress PE. I'm having a hard time putting my finger >>>>exactly >>>>on what it is, or articulating the idea, but it seems that by having >>>>the >>>>traffic placed into two psuedowires, I have more flexibility and ease >>>>of >>>>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>>>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>>>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>>>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>>>PW's could really change that perception. >>>>[JY] Are you saying that we need to develop a totally new forwarding >>>>plane rather than using the Ethernet forwarding plane as described in >>>>the >>>>existing work? >>>> >>>>I hope we can move forward with one of these soon, >>>>[JY] me too. >>>> >>>>Josh >>>> >>>> >>>>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >>>> >>>>>Daniel, >>>>> >>>>>Not aware that we had a discussion on this before, but IMHO the >>>>>allocation of internal S-VLAN can be automatic, and manuel >>>>>configuration >>>>>of this mapping may not be needed at all. For example, an S-VLAN >>>>>allocation module in the management plane in a PE can do this kind of >>>>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>>>way from a free S-VLAN ID pool. Once the interal S-VLANs are >>>>>allocated, >>>>>the mapping is determined and no other configuration is needed. >>>>> >>>>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>>>allocate >>>>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to >>>>>allocate >>>>>two S-VLANs in the VPLS domain. >>>>> >>>>>On the other hand, for the multi-PW approach, two PWs need to be >>>>>configured for a E-Tree service. When MS-PW is used in the network, >>>>>for >>>>>every S-PE, we need to configure two ingress PW segments and two >>>>>egress >>>>>PW segments. In this case, I don't think we need to use fixed PW >>>>>labels >>>>>across the network for fear of configuration complexity. >>>>> >>>>>Regards, >>>>>Yuanlong >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>Sent: Wednesday, May 02, 2012 8:01 PM >>>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; >>>>>josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Inline. >>>>> >>>>>-----Original Message----- >>>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>>Sent: Wednesday, May 02, 2012 12:30 PM >>>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; >>>>>josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Hi Daniel, Please see my comments in line. >>>>> >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>Sent: Wednesday, May 02, 2012 3:55 PM >>>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Hi Yuanlong, >>>>> >>>>>The problem is not with the total number of S-VLAN IDs, I agree that >>>>>normally there won't be more than 2047. The problem is that if you >>>>>don't >>>>>support all VLAN IDs, you need S-VLAN space coordination with the >>>>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to >>>>>2047". >>>>>Which won't always be in line with an existing deployment. >>>>>[JY] This is not the case. If the total number is no more than 2047, >>>>>it >>>>>surely can be supported. The S-VLAN space of user domain is totally >>>>>different from the S-VLAN in the provider domain and they can be >>>>>overlapped, I don't see why we need S-VLAN space coordination between >>>>>them. >>>>> >>>>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>>>fixed, and therefore the IEEE S-VID that can be supported is also >>>>>fixed. >>>>> >>>>>Of course you can configure the mapping in each PE according to >>>>>operator >>>>>requirements but as we discussed before this increases complexity. >>>>> >>>>>Relying on PBB-VPLS imposes additional limitations on backward >>>>>compatibility. >>>>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>>>think they may well need MAC-in-MAC in their networks for the >>>>>scalability issue. As you know, only PBB VPLS can provide both. >>>>> >>>>>Daniel >>>>> >>>>>-----Original Message----- >>>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>>Sent: Wednesday, May 02, 2012 5:07 AM >>>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; >>>>>josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Hi Daniel, >>>>> >>>>>As you can see, both cases are discussed in the I-D. >>>>> >>>>>With regard to case 1) (that is, S-VLAN translation), since the access >>>>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>>>they need to be configured on a PE anyway, and as the past emails by >>>>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>>>mapping. >>>>> >>>>>With regard to S-VID space reduction, the constraint is valid only >>>>>when >>>>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>>>typical and with no such limits as we already discussed in the f2f >>>>>meeting. >>>>> >>>>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>>>described (not sure this is a valid use case in real life), PBB-VPLS >>>>>can >>>>>still be used. >>>>> >>>>>Regards, >>>>>Yuanlong >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>Sent: Monday, April 30, 2012 10:34 PM >>>>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>>Jiangyuanlong; josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>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] >>>>>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 >>>>> >>>>>---------------------------------------------------------------------- >>>> >>>> >>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>proprietary information, which is privileged, confidential, or subject >>>>to >>>>copyright belonging to Time Warner Cable. This E-mail is intended >>>>solely >>>>for the use of the individual or entity to which it is addressed. If >>>>you >>>>are not the intended recipient of this E-mail, you are hereby notified >>>>that any dissemination, distribution, copying, or action taken in >>>>relation to the contents of and attachments to this E-mail is strictly >>>>prohibited and may be unlawful. If you have received this 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 and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for >the use of the individual or entity to which it is addressed. If you are >not >the intended recipient of this E-mail, you are hereby notified that any >dissemination, distribution, copying, or action taken in relation to the >contents of and attachments to this E-mail is strictly prohibited and may >be >unlawful. If you have received this 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 96, Issue 15 >************************************* > 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 Mon May 7 14:26: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 6D0D021F86F8 for ; Mon, 7 May 2012 14:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.472 X-Spam-Level: X-Spam-Status: No, score=-0.472 tagged_above=-999 required=5 tests=[AWL=0.391, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 RcxIJgln8A0a for ; Mon, 7 May 2012 14:26:17 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id CA62921F869D for ; Mon, 7 May 2012 14:26:16 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.75,546,1330923600"; d="scan'208";a="377813139" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 07 May 2012 17:25:44 -0400 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.36]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Mon, 7 May 2012 17:26:15 -0400 From: "Rogers, Josh" To: Lucy yong , Jiangyuanlong , Daniel Cohn , "Fedyk, Donald (Don)" , "Henderickx, Wim (Wim)" Date: Mon, 7 May 2012 17:26: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: Ac0smAiBU2vqIdLRQP2Oo1A0Q0UEhQ== Message-ID: In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D330F06DD@dfweml506-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 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, 07 May 2012 21:26:19 -0000 Lucy, you are correct here. Some of what I stated in my email last night was incorrect, due to late-night confusion on my part. In a mixed to mixed transmission of broadcast, depending on the source AC, the packet will only be placed on one PW (a very important detail I overlooked), so there is no duplication. With 2VLAN, there is no considerable difference, the frame will be tagged with the appropriate S-Tag based on the source AC type, and forwarded across the PW once. I apologize for the confusion I created, thank you for clearing it up. Regarding the statement of VPLS requiring PW associating with VSI, not an AC, I agree that is the current application of VPLS, and is fundamentally what is wrong with VPLS. By associating with an AC instead, we are afforded the flexibility to do more interesting things... Like ETREE. -Josh On 5/7/12 2:29 PM, "Lucy yong" wrote: >Josh, > >Thank you to provide the following needed PW for multi-PW solution. The >left side of "=3D" sign represent PE->PE and the right side is needed PW. >We are on the same table now. In addition, I add Dual VLAN for comparison. > >Multi-PW Dual-VLAN >Root-only -> any VSI =3D one PE one PW >Leaf-only -> root-only =3D one PW one PW and one leaf S-VLAN >Leaf-only -> Leaf-only =3D Zero PW Zero PW >Leaf-only -> mixed =3D one PW one PW and one leaf S-VLAN >Mixed -> root-only =3D one PW one PW >Mixed -> leaf-only =3D one PW one PW and one root S-VLAN >Mixed -> mixed =3D two PW one PW and one root S-VLAN >and one leaf VLAN > >Both methods let ingress PE marking and filtering all known unicast >packets in mixed->mixed case. In the case, only a broadcast packet at >mixed PE needs to be forwarded to another mixed PE with the mark, but the >packet is sent once and no need to duplicate. > >VPLS requires PW associating with a VSI not an AC. > >Regards, >Lucy >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Monday, May 07, 2012 11:36 AM >To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >(Wim); Lucy yong >Cc: l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >Comment Inline: > >On 5/7/12 1:34 AM, "Jiangyuanlong" wrote: > >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Monday, May 07, 2012 12:09 PM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>So, if you can imagine three PE's, PE1, PE2 and PE3. PE1 has a root AC, >>R1 and a leaf AC, L1. PE2 also has a root AC, R2, and a leaf AC, L2. >>PE3 >>has a leaf AC, L3. >> >>Consider an unknown unicast frame from the leaf site L1, and also another >>unknown unicast frame from R1 entering. >> >>With the 2VLAN method (to my best understanding): >> - frame from L1 enters PE1, goes into a PW to PE2 and a PW to PE3, >>arrives at PE2 which decides that it should be flooded out all Root AC's, >>based on the S-tag. It also arrives at PE3, where it is dropped because >>there are no root AC's. >> >>[JY] Since PE3 is a leaf-only node, the PW from PE1 to PE3 will work in >>Optimized-Mode. According to Section 5.3.3 of >>draft-jiang-l2vpn-vpls-pe-etree-05, it will be dropped before arriving at >>this PW. Therefore, this frame will not arrive at PE3. >[JR] Correct, in my example I was assuming no optimization. See my later >comment about adding complexity for the sake of optimization (which is not >a problem, just an observation, the same observation holds true for >multi-PW method.) >> >> - frame from R1 enters PE1, goes into a PW to PE2 and a PW to PE3, >>arrives at PE2 which decides that it should be flooded out all AC's, >>based >>on S-tag. It also arrives at PE3 where it is forwarded to all root AC's. >> >>With Multi-PW method: >> - frame from L1 enters PE1, which decides to forward the frame out the >>'root' PW to PE2, which in turn floods out all Root AC's, based on >>arriving PW type. Frame is NOT sent to PE3, since there is no PW built >>to >>the PE which has no root AC's. >> >>[JY] According to my understanding of the following description in >>draft-ram-l2vpn-etree-multiple-pw-01: >> "It should be noted that in a full-mesh VPLS (as opposed to H-VPLS), >> the following VSI pair types do not require two interconnecting PWs: >> Root-only VSI <-> any VSI: only root PW required >> Leaf-only VSI <-> leaf-only VSI: no PWs required" >>There should be 2 PWs be set up between PE1 and PE3, since this is a case >>of "Root & Leaf mixed VSI <-> leaf-only VSI" and not listed in the >>none-two- interconnecting-PWs criteria. Therefore, this frame will be >>sent to PE3 twice (one on root PW, another on leaf PW) IMO. Of course, >>the other authors of draft-ram-l2vpn-etree-multiple-pw-01 may have more >>to say on this point. >[JR] Remember that PW's are unidirectional, we should consider setup in >each direction independently: > >root-only -> any VSI =3D one PW >Leaf-only -> root-only =3D one PW >Leaf-only -> Leaf-only =3D Zero PW >Leaf-only -> mixed =3D one PW >Mixed -> root-only =3D one PW >Mixed -> leaf-only =3D one PW >Mixed -> mixed =3D two PW > >In our example, PE1 to PE3 would be mixed to leaf-only (one PW) in one >direction, and leaf-only to mixed (one PW) in the other, so I was mistaken >in my original depiction, and you are correct, it should be only one PW. >It would just be the mixed -> mixed where broadcast would be duplicated. >Also consider this list of scenarios, the only times that we have to >deviate from the typical 'any to any' VPLS is in the Leaf-only to >Leaf-only, and Mixed to Mixed PW's. All others are a single PW. >[/JR] > >> >> - frame from R1 enters PE1, which decides to flood out both 'root' PW >>and 'leaf' PW to PE2, which in turn floods out the same AC types, based >>on >>arriving PW type. It also arrives at PE3 where it is forwarded to all >>root AC's. >> >>[JY] It contradicts your first statement that "there is no PW built to >>the PE which has no root AC's". >[JR] Sorry, I got confused on my only topology and was thinking PE3 was >root-only. Frame would arrive at PE3 (on the root-sourced PW) where it >would forward to all AC's. Sorry I botched the explanation, I hope the >idea was not lost in the confusion. > > >> >>I suppose optimization could be done on the ingress PE to decide that >>there is no need to 'flood' root-sourced frames to two PW's that have the >>same egress PE, but instead to only forward to the 'root' type PW, when >>both exist, because we know that the egress PE will flood frames from >>root-sourced PW's out both leaf and root AC's. >> >>In this example, the same frame from R1 is duplicated on the PE1-PE2 path >>(if no optimization is done.), where it would not be with the 2VLAN >>method. >> >>With 2VLAN, ethernet type PW's cannot be used (must be vlan type PW's, >>otherwise how would we classify source AC-type?), which means there is >>overhead on EVERY frame to add the s-tag for the sole purpose of >>classifying the frame. If optimization is done, then each ingress PE >>knows what types of AC's are on each egress PE, and only forwards the >>appropriate frame, if no optimization then it is dropped at the egress >>PE. >> >>In short, both are either not 100% inefficient, or are additionally >>complex due to 'optimization'. >> >>I may have gotten my details off on the optimization piece of the 2VLAN >>method, please correct me if I didn't get the details 100% correct. >> >> >>-Josh >> >> >> >>On 5/6/12 9:07 PM, "Jiangyuanlong" wrote: >> >>>Could you or any other co-authors of 2PW give some more hints so that it >>>can be better understood? >>> >>>In draft-ram-l2vpn-etree-multiple-pw-01, I can only find a single >>>sentence most to the point: >>> "An egress PE SHALL NOT deliver a frame originated at a leaf AC to >>> another leaf AC." >>> >>>But it seems there is not a description of "traffic is split/separated >>>(by psuedowire) on the ingress PE" at all. >>> >>>On the contrary, in draft-jiang-l2vpn-vpls-pe-etree-05, Section 5.3.3 >>>details the scenario and forwarding plane how the leaf traffic is >>>seperated and filtered on the ingress PE, and Section 6 details the >>>specific supports in the control plane. >>> >>>Thanks >>>Yuanlong >>> >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Friday, May 04, 2012 8:27 PM >>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>(Wim); Lucy yong >>>Cc: l2vpn@ietf.org >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>>also separate the leaf traffic in the ingress PE and filter it there >>>(already detailed in the Optimization Mode in the I-D); if the egress PE >>>is attached with pure roots or with both roots and leafs, it seems all >>>traffic must be transported to the egress PE and be filtered there, I >>>see >>>no difference in behaviour for these solutions. Or did I miss something? >>> >>> >>>The point is with the multi-PW method the traffic is split/separated (by >>>psuedowire) on the ingress PE, rather than the egress. The distinction >>>is >>>2VLAN will 'classify' the frame on the ingress PE, so that the egress PE >>>knows how to forward it to the appropriate AC's. >>> >>>Both methods have inefficiencies (one duplicates traffic for transport, >>>while the other transports where it doesn't need to go). I like the >>>idea >>>of classify and forwarding on the ingress PE, rather than marking it on >>>the ingress, and deciding on the egress. >>> >>>-Josh >>> >>> >>> >>>On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: >>> >>>>Josh, thank you for the comments, please see my further comments with >>>>[JY2]. >>>> >>>>-----Original Message----- >>>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>>Sent: Thursday, May 03, 2012 11:27 PM >>>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>>(Wim); Lucy yong >>>>Cc: l2vpn@ietf.org >>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>> >>>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>>requirements from MEF, it has nothing to do with the solutions. Could >>>>you >>>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>>if >>>>configuring or signalling two PWs is not a problem, why configuring or >>>>signalling two VLANs will become a problem? After all, more nodes may >>>>need >>>>to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >>>>2VLAN (only T-PEs). >>>> >>>> >>>>There is no other way (if both MPLS domains are part of the same ETREE, >>>>rather than doing something more like H-VPLS, where one domain has >>>>point >>>>to points to the other domain which handles the ETREE instance) if you >>>>are >>>>using an ENNI. The other method, (not mentioned earlier) is tying the >>>>two >>>>MPLS domains together via labeled unicast (much preferred over E-NNI in >>>>my >>>>opinion) >>>> >>>>Configuring two VLAN's isn't really a 'problem' any more than two PW's. >>>>I >>>>wasn't saying that configuring two VLAN's was difficult, I was >>>>objecting >>>>to the statement that configuring two PW's is difficult. >>>> >>>>[JY2] Thanks, I see your point. I take the example of 2PW configuration >>>>just to show that using fixed global values to simplify configuration >>>>makes no sense. Personally I also don't think configuration is a >>>>problem >>>>for both solutions. >>>> >>>>I find the differences between these two methods rather slight. The >>>>'tie-breaker' for me is by placing the forwarding decision on the >>>>ingress >>>>PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you >>>>get >>>>more control over where the traffic goes, and in my mind it provides a >>>>cleaner destination between customer traffic and forwarding plane. I'm >>>>accustomed to looking at a psuedowire and knowing where its going, with >>>>the 2vlan method, I can see the psuedowire, but must go to the egress >>>>PE >>>>to see if it will be dropped there, or forwarded to one or more AC's. >>>> >>>>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>>>also separate the leaf traffic in the ingress PE and filter it there >>>>(already detailed in the Optimization Mode in the I-D); if the egress >>>>PE >>>>is attached with pure roots or with both roots and leafs, it seems all >>>>traffic must be transported to the egress PE and be filtered there, I >>>>see >>>>no difference in behaviour for these solutions. Or did I miss >>>>something? >>>> >>>>Again, the difference here is slight, and I would honestly be happy to >>>>see >>>>either of them come to fruition. Please don't infer that I think the >>>>2vlan method is 'bad' or has intrinsic problems, because I don't >>>>believe >>>>that. I just prefer the multi-PW method. >>>> >>>> >>>>-Josh >>>> >>>> >>>>On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: >>>> >>>>>Josh, please see my comments in line. >>>>> >>>>>Thanks >>>>>Yuanlong >>>>> >>>>>-----Original Message----- >>>>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>>>Sent: Thursday, May 03, 2012 10:51 AM >>>>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>>>(Wim); Lucy yong >>>>>Cc: l2vpn@ietf.org >>>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>>> >>>>>Yuanlong, >>>>> >>>>>Or better yet, include in the draft a 'standard' value for root >>>>>sourced >>>>>VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You would = also >>>>>have to require the the implementation NOT use global VLAN's, however >>>>>(since each instance would be using the same values). In this way, no >>>>>signaling or manual configuration is required for remote PE's to know >>>>>how >>>>>to classify traffic. >>>>>[JY] Indeed, we discussed this possibility during the f2f meeting in >>>>>Paris. But, there are some restrictions as you mentioned, and >>>>>furthermore: >>>>>1) Some vendors already used S-VLAN to distinguish their VSIs in the >>>>>PE; >>>>>2) Forwarding plane of a PE needs to be revised to be aware of this >>>>>VLAN >>>>>ID. >>>>>Therefore, this 'standard value' approach seems more disruptive >>>>>compared >>>>>with the other means and not a good candidate option. >>>>> >>>>>Regarding switching PE's=A9 Multi-PW means more than one PW, yes. I >>>>>don't >>>>>see this as a real problem. In general, design should try and avoid >>>>>using >>>>>S-PE's, but if you must, its going to mean extra work, no matter how >>>>>you >>>>>look at it. Two PW's for each Etree being switched instead of one is >>>>>not >>>>>alarming or concerning to me. On the other hand, if you use a dot1q >>>>>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's >>>>>an >>>>>two egress VLAN's if you want the Etree to be handled on both sides >>>>>(and >>>>>if you use the 'standard' VID's as I mentioned above, you'd have to do >>>>>mapping to non-standard and back) >>>>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>>>requirements from MEF, it has nothing to do with the solutions. Could >>>>>you >>>>>give a hint on how you can provision this service E-NNI otherwise? >>>>>BTW, >>>>>if configuring or signalling two PWs is not a problem, why configuring >>>>>or >>>>>signalling two VLANs will become a problem? After all, more nodes may >>>>>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>>>>with 2VLAN (only T-PEs). >>>>> >>>>>In general, I still prefer multi-PW, primarily because I prefer the >>>>>separation of the traffic in the network's forwarding plane, rather >>>>>than >>>>>shipping it everywhere and deciding whether to forward to the AC when >>>>>it >>>>>gets to the egress PE. I'm having a hard time putting my finger >>>>>exactly >>>>>on what it is, or articulating the idea, but it seems that by having >>>>>the >>>>>traffic placed into two psuedowires, I have more flexibility and ease >>>>>of >>>>>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>>>>H-VPLS (both psuedowire based and vlan based). Of course my 'ease >>>>>of >>>>>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>>>>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>>>>PW's could really change that perception. >>>>>[JY] Are you saying that we need to develop a totally new forwarding >>>>>plane rather than using the Ethernet forwarding plane as described in >>>>>the >>>>>existing work? >>>>> >>>>>I hope we can move forward with one of these soon, >>>>>[JY] me too. >>>>> >>>>>Josh >>>>> >>>>> >>>>>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >>>>> >>>>>>Daniel, >>>>>> >>>>>>Not aware that we had a discussion on this before, but IMHO the >>>>>>allocation of internal S-VLAN can be automatic, and manuel >>>>>>configuration >>>>>>of this mapping may not be needed at all. For example, an S-VLAN >>>>>>allocation module in the management plane in a PE can do this kind of >>>>>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>>>>single external S-VLAN ID) in a topdown, bottom-up, or just any >>>>>>random >>>>>>way from a free S-VLAN ID pool. Once the interal S-VLANs are >>>>>>allocated, >>>>>>the mapping is determined and no other configuration is needed. >>>>>> >>>>>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>>>>allocate >>>>>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to >>>>>>allocate >>>>>>two S-VLANs in the VPLS domain. >>>>>> >>>>>>On the other hand, for the multi-PW approach, two PWs need to be >>>>>>configured for a E-Tree service. When MS-PW is used in the network, >>>>>>for >>>>>>every S-PE, we need to configure two ingress PW segments and two >>>>>>egress >>>>>>PW segments. In this case, I don't think we need to use fixed PW >>>>>>labels >>>>>>across the network for fear of configuration complexity. >>>>>> >>>>>>Regards, >>>>>>Yuanlong >>>>>> >>>>>>-----Original Message----- >>>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>>Sent: Wednesday, May 02, 2012 8:01 PM >>>>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>>yong; >>>>>>josh.rogers@twcable.com >>>>>>Cc: l2vpn@ietf.org >>>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>>> >>>>>>Inline. >>>>>> >>>>>>-----Original Message----- >>>>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>>>Sent: Wednesday, May 02, 2012 12:30 PM >>>>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>>yong; >>>>>>josh.rogers@twcable.com >>>>>>Cc: l2vpn@ietf.org >>>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>>> >>>>>>Hi Daniel, Please see my comments in line. >>>>>> >>>>>> >>>>>>-----Original Message----- >>>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>>Sent: Wednesday, May 02, 2012 3:55 PM >>>>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>>yong; josh.rogers@twcable.com >>>>>>Cc: l2vpn@ietf.org >>>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>>> >>>>>>Hi Yuanlong, >>>>>> >>>>>>The problem is not with the total number of S-VLAN IDs, I agree that >>>>>>normally there won't be more than 2047. The problem is that if you >>>>>>don't >>>>>>support all VLAN IDs, you need S-VLAN space coordination with the >>>>>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to >>>>>>2047". >>>>>>Which won't always be in line with an existing deployment. >>>>>>[JY] This is not the case. If the total number is no more than 2047, >>>>>>it >>>>>>surely can be supported. The S-VLAN space of user domain is totally >>>>>>different from the S-VLAN in the provider domain and they can be >>>>>>overlapped, I don't see why we need S-VLAN space coordination between >>>>>>them. >>>>>> >>>>>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>>>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>>>>fixed, and therefore the IEEE S-VID that can be supported is also >>>>>>fixed. >>>>>> >>>>>>Of course you can configure the mapping in each PE according to >>>>>>operator >>>>>>requirements but as we discussed before this increases complexity. >>>>>> >>>>>>Relying on PBB-VPLS imposes additional limitations on backward >>>>>>compatibility. >>>>>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>>>>think they may well need MAC-in-MAC in their networks for the >>>>>>scalability issue. As you know, only PBB VPLS can provide both. >>>>>> >>>>>>Daniel >>>>>> >>>>>>-----Original Message----- >>>>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>>>Sent: Wednesday, May 02, 2012 5:07 AM >>>>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>>yong; >>>>>>josh.rogers@twcable.com >>>>>>Cc: l2vpn@ietf.org >>>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>>> >>>>>>Hi Daniel, >>>>>> >>>>>>As you can see, both cases are discussed in the I-D. >>>>>> >>>>>>With regard to case 1) (that is, S-VLAN translation), since the >>>>>>access >>>>>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>>>>they need to be configured on a PE anyway, and as the past emails by >>>>>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by >>>>>>1:1 >>>>>>mapping. >>>>>> >>>>>>With regard to S-VID space reduction, the constraint is valid only >>>>>>when >>>>>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>>>>typical and with no such limits as we already discussed in the f2f >>>>>>meeting. >>>>>> >>>>>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>>>>described (not sure this is a valid use case in real life), PBB-VPLS >>>>>>can >>>>>>still be used. >>>>>> >>>>>>Regards, >>>>>>Yuanlong >>>>>> >>>>>>-----Original Message----- >>>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>>Sent: Monday, April 30, 2012 10:34 PM >>>>>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>>>Jiangyuanlong; josh.rogers@twcable.com >>>>>>Cc: l2vpn@ietf.org >>>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>>> >>>>>>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] >>>>>>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 >>>>>> >>>>>>--------------------------------------------------------------------- >>>>>>- >>>>> >>>>> >>>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>>proprietary information, which is privileged, confidential, or subject >>>>>to >>>>>copyright belonging to Time Warner Cable. This E-mail is intended >>>>>solely >>>>>for the use of the individual or entity to which it is addressed. If >>>>>you >>>>>are not the intended recipient of this E-mail, you are hereby notified >>>>>that any dissemination, distribution, copying, or action taken in >>>>>relation to the contents of and attachments to this E-mail is strictly >>>>>prohibited and may be unlawful. If you have received this 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 and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject to >>copyright belonging to Time Warner Cable. This E-mail is intended solely >>for the use of the individual or entity to which it is addressed. If you >>are not the intended recipient of this E-mail, you are hereby notified >>that any dissemination, distribution, copying, or action taken in >>relation to the contents of and attachments to this E-mail is strictly >>prohibited and may be unlawful. If you have received this 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 linda.dunbar@huawei.com Mon May 7 14:31: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 743549E8002 for ; Mon, 7 May 2012 14:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.924 X-Spam-Level: X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=0.075, 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 3hh2LHdNzA9c for ; Mon, 7 May 2012 14:31:04 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8629E8001 for ; Mon, 7 May 2012 14:31:04 -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 AFP31375; Mon, 07 May 2012 17:31:04 -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, 7 May 2012 14:29:15 -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, 7 May 2012 14:29:09 -0700 From: Linda Dunbar To: Aldrin Isaac , Lucy yong Subject: RE: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: AQHNKJ3mO48LuIhSPkS8Et2e3RTHupa3awKA//+BFwCAAUwRAIAAibWAgAA5z4CAAHp5AIAAvVcAgACaWQCABBCQcA== Date: Mon, 7 May 2012 21:29:08 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F633918DFE@dfweml505-mbx> References: <2691CE0099834E4A9C5044EEC662BB9D330E8F11@dfweml505-mbx> <2E819CEF-4A49-439B-86DF-C17503A75398@gmail.com> <2691CE0099834E4A9C5044EEC662BB9D330E918C@dfweml505-mbx> <03B0FD5F-D9F5-4C4E-A7FD-0A2C36A7B092@gmail.com> In-Reply-To: <03B0FD5F-D9F5-4C4E-A7FD-0A2C36A7B092@gmail.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.216] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l2vpn@ietf.org" , sajassi 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, 07 May 2012 21:31:05 -0000 Adrin,=20 You mentioned that " private vlan and community vlans which are very common= for DMZs in Data Center".=20 I can totally understand why "private vlan" being used. But what scenario w= ill you need "community vlans" but can't be simply achieved by traditional = VLANs?=20 Thanks, Linda=20 > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Aldrin Isaac > Sent: Friday, May 04, 2012 7:20 PM > To: Lucy yong > Cc: l2vpn@ietf.org; sajassi > Subject: Re: Interest in IS-IS VPLS >=20 > Hi Lucy, >=20 > Please see inline >=20 > On May 4, 2012, at 11:07 AM, Lucy yong wrote: >=20 > > Hi Isaac, > > > > Thank you for the reply. Please see inline. > > > > Regards, > > Lucy > > > > -----Original Message----- > > From: Aldrin Isaac [mailto:aldrin.isaac@gmail.com] > > Sent: Thursday, May 03, 2012 10:50 PM > > To: Lucy yong > > Cc: sajassi; Giles Heron; Nabil Bitar; l2vpn@ietf.org > > Subject: Re: Interest in IS-IS VPLS > > >=20 > ... >=20 > > E-VPN also supports policy based-topologies versus simple point-to- > point, flat or tree VLANs. It can support point-to-point, tree, mesh, > one-way, or pretty much any other "complex" or overlapped topologies > (depending on how you like to see it). An example is ability to > natively recreate private vlan, community vlan topologies (which happen > to be quite common in DC networks) and any number of combinations of > these simultaneously to a single port. A BGP E-VPN VPN is also > decoupled from the edge EVI/ESI such that it is not limited to a single > tenant/vlan but can span tenants/vlans (l2 extranet) if so required. > This is native to E-VPN. > > [[LY]] Such policy based-topologies are useful for service provider > network, but may too complex for intra DCs. One reason that customers > often want to choose with L2VPN service is "it is simple". However, > L3VPN have its applications although some operators often complain the > complexities to configure these policies. Typical example is the a > firewall only placed at a location. Could you share why operator want > such policy based-topology for L2VPN? >=20 > Policy-based topologies are generally complex when used to interconnect > IP networks because there are generally multiple prefixes in a vrf, and > often different prefixes need to be associated to different VPNs or > routing behavior. In the DC, L2VPN role is to interconnect host ports > so the policies for basic are very simple --- list of import route > targets and list of export route targets where each import/export pair > correspond to a VPN (tenant, service, ...). An example of how a DC > operator might use this for example is to meet a requirement for > private vlan and community vlans which are very common for DMZs. > Hopefully you are familiar with these very common use cases. It is > even possible to recreate more complex switch "features" like MVR (in > addition to private VLANs which are also considered "features") using > E-VPN. It took me three years to get the MVR feature into a particular > vendor's switch to meet a business need. I'll sacrifice plug-and-play > simplicity for business agility. I'm sure my peers are with me on this > one. >=20 > If simple "plug-and-play" is important, one could imagine RRs sending > out an "RR TLV" such that RRs in an IGP area auto-connect with each > other and RR-clients connect to the closest RR based on SPF (some > details like peer-group, etc would need to be factored in to make it > more powerful). Other BGP/MPLS configuration is, IMHO, trivial unless > you CHOOSE to use more advanced capabilities (i.e. not locked in). >=20 > Maybe the reason why MPLS comes across as complex is because of how > IETF deals with requirements lately by creating point solutions. E-VPN > tries to put new capabilities on the table while trying not to take > existing value off the table. There is no reason why a solution can't > bring more value than what the standards body calls for. >=20 > > E-VPN supports interconnecting end-stations or interconnecting L2 > networks. Procedures to easily span STP based networks across an E-VPN > network without loops comes with the base spec. Extensions to E-VPN, > such as PBB-EVPN, simplify the fully functional spanning of non-EVPN > networks across an E-VPN network. > > [[LY]] current L2VPN support all these except active-active mode > which causes the loop. >=20 > Base E-VPN spec will natively deal with the STP case through an > active/standby mode and BPDU-snooping -- detect root bridge and use > that as ESI (ethernet segment id) to indicate unique STP network with > active/standby bit set to ensure only one forwarding link among links > with same ESI. Tags (vlans) can potentially each have a different > active link within the member links of an ESI allowing for automatic > tag(tenant)/vlan level load-balancing into an STP network. Edge > networks that don't have mac-move issue will be able to take full > advantage of active-active load-balancing without need for LAG/MLAG. >=20 > > An SVI/IRB interface can also be a member of both an E-VPN EVI and an > IP VRF allowing for easily bringing together virtual L2 and L3 > topologies anywhere in the network without a physical port. > > [[LY]] Could you please share how operator plan to use this? Which > service will you sell to customer in this case? >=20 > The service will be where a customer wants to communicate to a > destination network that is not in his subnet. Operators most > interested in EVPN already have IPVPN services on their network. This > is the gateway point between the EVPN virtual networks and [existing] > IPVPN virtual networks. No physical port required. >=20 > > E-VPN builds on top of years of work in the IETF; traffic engineering, > scaling with route reflectors and RT constrain, multicast via NG-MVPN, > etc. > > [[LY]] Agree. These are useful features for service provider network. > However, these functions may not necessary within DC although they had > been proved works well. >=20 > I'm not sure how eventually re-inventing these capabilities (yes it > will happen) on behalf of a new protocol will be better than simply > leveraging proven technology. Vendors don't need to implement every > MPLS RFC ever written to be able to implement the basic E-VPN. >=20 > > Can also use IP for transport tunnel. But my understanding is that > popular merchant silicon has support for MPLS push/pop/swap these days > (?). This was captured by EVPN at it's inception, which is why the PE > is referred to as MES (MPLS-enabled switch) in E-VPN. > > [[LY]] Yes, current draft aims on MPLS solution only. But it states > the potential to extend to the use of IP tunnel. > > The way I see it, a major reason why STP-based LANS are fickle and > don't scale well is on account of insufficient decoupling of core from > edge created by requirement for plug-and-play and how that played out > over time. Conversely the reason (among other things) why IP networks > are more stable is because they are not inherently plug-and-play, and > with MPLS/BGP allows excellent decoupling of core and edge. I don't > know enough about TRILL or PBB to comment on those -- I just know that > I'm not interested for enough good reasons. E-VPN enables a dynamic > edge over a stable decoupled core while giving each operator room for > service differentiation. It is especially interesting to operators > that have invested in MPLS technology and operations. I can find a lot > of folks that understand BGP/MPLS IPVPN and in short order have them > know the ins and outs of basic E-VPN. It's quite hard for me to find > non-vendor folk who really actually understand the other technologies > used to span Ethernet aside from basic STP. >=20 > > [[LY]] Thank you to share this in the mailing list. > > > > This is an operator perspective. > > [[LY]] This is great! > > > > > > On May 3, 2012, at 4:31 PM, Lucy yong wrote: > > > >> Hi Ali, > >> > >> > >> "5. Ethernet VPN (E-VPN) - An enhanced Layer-2 service that > >> emulates an Ethernet (V)LAN across a PSN. E-VPN supports > >> load-sharing across multiple connections from a Layer-2 site > >> to an L2VPN service. E-VPN is primarily targeted to support > >> large-scale L2VPNs with resiliency requirements not satisfied > >> by other L2VPN solutions" > >> > >> [[LY]] IMO, E-VPN enhancement is to support multi-homing with > active-active mode. Load-sharing across multiple connections from a > layer-2 site is desired when this mode is used. Current VPLS can > provide resiliency requirement when the multi-homing site configured > with active-standby mode. > >> > >> Regards, > >> Lucy > >> > >> Cheers, > >> Ali > >> > > From lucy.yong@huawei.com Mon May 7 15:39: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 1A5A721F86E0 for ; Mon, 7 May 2012 15:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.22 X-Spam-Level: X-Spam-Status: No, score=-2.22 tagged_above=-999 required=5 tests=[AWL=-0.221, 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 tc5wrxFoFPaY for ; Mon, 7 May 2012 15:38:59 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id AA18421F86D1 for ; Mon, 7 May 2012 15:38: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 AFP35085; Mon, 07 May 2012 18:38:58 -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, 7 May 2012 15:37:01 -0700 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Mon, 7 May 2012 15:36:51 -0700 From: Lucy yong To: "Rogers, Josh" , Sam Cao , "l2vpn@ietf.org" Subject: RE: L2vpn Digest, Vol 96, Issue 15 Thread-Topic: L2vpn Digest, Vol 96, Issue 15 Thread-Index: Ac0qAqy9LTtQ75h0R2+YJ9mGFYIsPwAWFG9QAIs2guAAEpCagAAMiahQ Date: Mon, 7 May 2012 22:36:50 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D3310422D@dfweml506-mbx> References: <2691CE0099834E4A9C5044EEC662BB9D330F0740@dfweml506-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.149.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Jiangyuanlong 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, 07 May 2012 22:39:02 -0000 Josh, Snip.. Additionally, if I wanted to have traffic engineering that impacted root-sourced and leaf-sourced traffic differently, I can do that with multi-PW, where I could not (save for ingress/egress) with the 2VLAN approach. PE should report signaling on second PW same as it does for the 100th PW between PE's. Again, I don't see the problem you are alluding to. [[LY]] You can use QoS to achieve that too. MEF discuss about this a lot. = The trade-off in the use of different transport pipes is that you lose the = ability to share the BW. However, you can argue to use over-subscription. B= ut it makes operation more complex. After a long debate, MEF decide to use = one transport pipe for both root and leaf traffic. this is humorous to me, because at one time, VLAN-ID was used to identify a single broadcast domain, and then later asymmetrical VID's were used to limit communication between endpoints of a broadcast domain (effectively creating two one-way broadcast domains, very similar to what we're accomplishing with ETREE). This should not be the reason to judge on the solution. [[LY]] This is because applications become more complex. There are private = LAN, community LAN, group LAN, etc. Thanks, Lucy > >Regards, >Lucy > >Lucy > >Thanks, > >Sam > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >l2vpn-request@ietf.org >Sent: Friday, May 04, 2012 10:31 PM >To: l2vpn@ietf.org >Subject: L2vpn Digest, Vol 96, Issue 15 > >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) > 2. Re: The status of the approaches to the E-Tree solution? > (Rogers, Josh) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Fri, 4 May 2012 14:16:36 +0000 >From: Lucy yong >To: "Rogers, Josh" , Jiangyuanlong > , Daniel Cohn , >"Fedyk, > Donald (Don)" , "Henderickx, Wim > (Wim)" >Cc: "l2vpn@ietf.org" >Subject: RE: The status of the approaches to the E-Tree solution? >Message-ID: <2691CE0099834E4A9C5044EEC662BB9D330E9114@dfweml505-mbx> >Content-Type: text/plain; charset=3D"iso-8859-2" > >Josh, > >You simply say that you don't like IEEE Tree solution. IEEE Tree solution >is >for ingress port to mark and for egress port to filter. > >Regards, >Lucy > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Friday, May 04, 2012 7:27 AM >To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >(Wim); >Lucy yong >Cc: l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >also separate the leaf traffic in the ingress PE and filter it there >(already detailed in the Optimization Mode in the I-D); if the egress PE >is attached with pure roots or with both roots and leafs, it seems all >traffic must be transported to the egress PE and be filtered there, I see >no difference in behaviour for these solutions. Or did I miss something? > > >The point is with the multi-PW method the traffic is split/separated (by >psuedowire) on the ingress PE, rather than the egress. The distinction is >2VLAN will 'classify' the frame on the ingress PE, so that the egress PE >knows how to forward it to the appropriate AC's. > >Both methods have inefficiencies (one duplicates traffic for transport, >while the other transports where it doesn't need to go). I like the idea >of classify and forwarding on the ingress PE, rather than marking it on >the ingress, and deciding on the egress. > >-Josh > > > >On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: > >>Josh, thank you for the comments, please see my further comments with >>[JY2]. >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Thursday, May 03, 2012 11:27 PM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>requirements from MEF, it has nothing to do with the solutions. Could you >>give a hint on how you can provision this service E-NNI otherwise? BTW, >>if >>configuring or signalling two PWs is not a problem, why configuring or >>signalling two VLANs will become a problem? After all, more nodes may >>need >>to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >>2VLAN (only T-PEs). >> >> >>There is no other way (if both MPLS domains are part of the same ETREE, >>rather than doing something more like H-VPLS, where one domain has point >>to points to the other domain which handles the ETREE instance) if you >>are >>using an ENNI. The other method, (not mentioned earlier) is tying the >>two >>MPLS domains together via labeled unicast (much preferred over E-NNI in >>my >>opinion) >> >>Configuring two VLAN's isn't really a 'problem' any more than two PW's. >>I >>wasn't saying that configuring two VLAN's was difficult, I was objecting >>to the statement that configuring two PW's is difficult. >> >>[JY2] Thanks, I see your point. I take the example of 2PW configuration >>just to show that using fixed global values to simplify configuration >>makes no sense. Personally I also don't think configuration is a problem >>for both solutions. >> >>I find the differences between these two methods rather slight. The >>'tie-breaker' for me is by placing the forwarding decision on the ingress >>PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >>more control over where the traffic goes, and in my mind it provides a >>cleaner destination between customer traffic and forwarding plane. I'm >>accustomed to looking at a psuedowire and knowing where its going, with >>the 2vlan method, I can see the psuedowire, but must go to the egress PE >>to see if it will be dropped there, or forwarded to one or more AC's. >> >>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>also separate the leaf traffic in the ingress PE and filter it there >>(already detailed in the Optimization Mode in the I-D); if the egress PE >>is attached with pure roots or with both roots and leafs, it seems all >>traffic must be transported to the egress PE and be filtered there, I see >>no difference in behaviour for these solutions. Or did I miss something? >> >>Again, the difference here is slight, and I would honestly be happy to >>see >>either of them come to fruition. Please don't infer that I think the >>2vlan method is 'bad' or has intrinsic problems, because I don't believe >>that. I just prefer the multi-PW method. >> >> >>-Josh >> >> >>On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: >> >>>Josh, please see my comments in line. >>> >>>Thanks >>>Yuanlong >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Thursday, May 03, 2012 10:51 AM >>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>(Wim); Lucy yong >>>Cc: l2vpn@ietf.org >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Yuanlong, >>> >>>Or better yet, include in the draft a 'standard' value for root sourced >>>VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You would al= so >>>have to require the the implementation NOT use global VLAN's, however >>>(since each instance would be using the same values). In this way, no >>>signaling or manual configuration is required for remote PE's to know >>>how >>>to classify traffic. >>>[JY] Indeed, we discussed this possibility during the f2f meeting in >>>Paris. But, there are some restrictions as you mentioned, and >>>furthermore: >>>1) Some vendors already used S-VLAN to distinguish their VSIs in the PE; >>>2) Forwarding plane of a PE needs to be revised to be aware of this VLAN >>>ID. >>>Therefore, this 'standard value' approach seems more disruptive compared >>>with the other means and not a good candidate option. >>> >>>Regarding switching PE's? Multi-PW means more than one PW, yes. I >>>don't >>>see this as a real problem. In general, design should try and avoid >>>using >>>S-PE's, but if you must, its going to mean extra work, no matter how you >>>look at it. Two PW's for each Etree being switched instead of one is >>>not >>>alarming or concerning to me. On the other hand, if you use a dot1q >>>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's >>>an >>>two egress VLAN's if you want the Etree to be handled on both sides (and >>>if you use the 'standard' VID's as I mentioned above, you'd have to do >>>mapping to non-standard and back) >>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>requirements from MEF, it has nothing to do with the solutions. Could >>>you >>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>if configuring or signalling two PWs is not a problem, why configuring >>>or >>>signalling two VLANs will become a problem? After all, more nodes may >>>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>>with 2VLAN (only T-PEs). >>> >>>In general, I still prefer multi-PW, primarily because I prefer the >>>separation of the traffic in the network's forwarding plane, rather than >>>shipping it everywhere and deciding whether to forward to the AC when it >>>gets to the egress PE. I'm having a hard time putting my finger exactly >>>on what it is, or articulating the idea, but it seems that by having the >>>traffic placed into two psuedowires, I have more flexibility and ease of >>>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>>PW's could really change that perception. >>>[JY] Are you saying that we need to develop a totally new forwarding >>>plane rather than using the Ethernet forwarding plane as described in >>>the >>>existing work? >>> >>>I hope we can move forward with one of these soon, >>>[JY] me too. >>> >>>Josh >>> >>> >>>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >>> >>>>Daniel, >>>> >>>>Not aware that we had a discussion on this before, but IMHO the >>>>allocation of internal S-VLAN can be automatic, and manuel >>>>configuration >>>>of this mapping may not be needed at all. For example, an S-VLAN >>>>allocation module in the management plane in a PE can do this kind of >>>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>>way from a free S-VLAN ID pool. Once the interal S-VLANs are allocated, >>>>the mapping is determined and no other configuration is needed. >>>> >>>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>>allocate >>>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to allocate >>>>two S-VLANs in the VPLS domain. >>>> >>>>On the other hand, for the multi-PW approach, two PWs need to be >>>>configured for a E-Tree service. When MS-PW is used in the network, for >>>>every S-PE, we need to configure two ingress PW segments and two egress >>>>PW segments. In this case, I don't think we need to use fixed PW labels >>>>across the network for fear of configuration complexity. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 8:01 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Inline. >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 12:30 PM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, Please see my comments in line. >>>> >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 3:55 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Yuanlong, >>>> >>>>The problem is not with the total number of S-VLAN IDs, I agree that >>>>normally there won't be more than 2047. The problem is that if you >>>>don't >>>>support all VLAN IDs, you need S-VLAN space coordination with the >>>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to >>>>2047". >>>>Which won't always be in line with an existing deployment. >>>>[JY] This is not the case. If the total number is no more than 2047, it >>>>surely can be supported. The S-VLAN space of user domain is totally >>>>different from the S-VLAN in the provider domain and they can be >>>>overlapped, I don't see why we need S-VLAN space coordination between >>>>them. >>>> >>>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>>fixed, and therefore the IEEE S-VID that can be supported is also >>>>fixed. >>>> >>>>Of course you can configure the mapping in each PE according to >>>>operator >>>>requirements but as we discussed before this increases complexity. >>>> >>>>Relying on PBB-VPLS imposes additional limitations on backward >>>>compatibility. >>>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>>think they may well need MAC-in-MAC in their networks for the >>>>scalability issue. As you know, only PBB VPLS can provide both. >>>> >>>>Daniel >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 5:07 AM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, >>>> >>>>As you can see, both cases are discussed in the I-D. >>>> >>>>With regard to case 1) (that is, S-VLAN translation), since the access >>>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>>they need to be configured on a PE anyway, and as the past emails by >>>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>>mapping. >>>> >>>>With regard to S-VID space reduction, the constraint is valid only when >>>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>>typical and with no such limits as we already discussed in the f2f >>>>meeting. >>>> >>>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>>described (not sure this is a valid use case in real life), PBB-VPLS >>>>can >>>>still be used. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Monday, April 30, 2012 10:34 PM >>>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>Jiangyuanlong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>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] >>>>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 >>>> >>>>---------------------------------------------------------------------- >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to >>>copyright belonging to Time Warner Cable. This E-mail is intended solely >>>for the use of the individual or entity to which it is addressed. If you >>>are not the intended recipient of this E-mail, you are hereby notified >>>that any dissemination, distribution, copying, or action taken in >>>relation to the contents of and attachments to this E-mail is strictly >>>prohibited and may be unlawful. If you have received this 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. > > >------------------------------ > >Message: 2 >Date: Fri, 4 May 2012 10:30:38 -0400 >From: "Rogers, Josh" >To: Lucy yong , Jiangyuanlong > , Daniel Cohn , >"Fedyk, > Donald (Don)" , "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"iso-8859-2" > >To be more accurate, I like it less than the multi-PW solution. I'd be >happy to use the 2VLAN solution in the real world, if it was ratified as >the standard. > > > >On 5/4/12 9:16 AM, "Lucy yong" wrote: > >>Josh, >> >>You simply say that you don't like IEEE Tree solution. IEEE Tree solution >>is for ingress port to mark and for egress port to filter. >> >>Regards, >>Lucy >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Friday, May 04, 2012 7:27 AM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>also separate the leaf traffic in the ingress PE and filter it there >>(already detailed in the Optimization Mode in the I-D); if the egress PE >>is attached with pure roots or with both roots and leafs, it seems all >>traffic must be transported to the egress PE and be filtered there, I see >>no difference in behaviour for these solutions. Or did I miss something? >> >> >>The point is with the multi-PW method the traffic is split/separated (by >>psuedowire) on the ingress PE, rather than the egress. The distinction >>is >>2VLAN will 'classify' the frame on the ingress PE, so that the egress PE >>knows how to forward it to the appropriate AC's. >> >>Both methods have inefficiencies (one duplicates traffic for transport, >>while the other transports where it doesn't need to go). I like the idea >>of classify and forwarding on the ingress PE, rather than marking it on >>the ingress, and deciding on the egress. >> >>-Josh >> >> >> >>On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: >> >>>Josh, thank you for the comments, please see my further comments with >>>[JY2]. >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Thursday, May 03, 2012 11:27 PM >>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>(Wim); Lucy yong >>>Cc: l2vpn@ietf.org >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>requirements from MEF, it has nothing to do with the solutions. Could >>>you >>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>if >>>configuring or signalling two PWs is not a problem, why configuring or >>>signalling two VLANs will become a problem? After all, more nodes may >>>need >>>to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >>>2VLAN (only T-PEs). >>> >>> >>>There is no other way (if both MPLS domains are part of the same ETREE, >>>rather than doing something more like H-VPLS, where one domain has point >>>to points to the other domain which handles the ETREE instance) if you >>>are >>>using an ENNI. The other method, (not mentioned earlier) is tying the >>>two >>>MPLS domains together via labeled unicast (much preferred over E-NNI in >>>my >>>opinion) >>> >>>Configuring two VLAN's isn't really a 'problem' any more than two PW's. >>>I >>>wasn't saying that configuring two VLAN's was difficult, I was objecting >>>to the statement that configuring two PW's is difficult. >>> >>>[JY2] Thanks, I see your point. I take the example of 2PW configuration >>>just to show that using fixed global values to simplify configuration >>>makes no sense. Personally I also don't think configuration is a problem >>>for both solutions. >>> >>>I find the differences between these two methods rather slight. The >>>'tie-breaker' for me is by placing the forwarding decision on the >>>ingress >>>PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >>>more control over where the traffic goes, and in my mind it provides a >>>cleaner destination between customer traffic and forwarding plane. I'm >>>accustomed to looking at a psuedowire and knowing where its going, with >>>the 2vlan method, I can see the psuedowire, but must go to the egress PE >>>to see if it will be dropped there, or forwarded to one or more AC's. >>> >>>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>>also separate the leaf traffic in the ingress PE and filter it there >>>(already detailed in the Optimization Mode in the I-D); if the egress PE >>>is attached with pure roots or with both roots and leafs, it seems all >>>traffic must be transported to the egress PE and be filtered there, I >>>see >>>no difference in behaviour for these solutions. Or did I miss something? >>> >>>Again, the difference here is slight, and I would honestly be happy to >>>see >>>either of them come to fruition. Please don't infer that I think the >>>2vlan method is 'bad' or has intrinsic problems, because I don't believe >>>that. I just prefer the multi-PW method. >>> >>> >>>-Josh >>> >>> >>>On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: >>> >>>>Josh, please see my comments in line. >>>> >>>>Thanks >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>>Sent: Thursday, May 03, 2012 10:51 AM >>>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>>(Wim); Lucy yong >>>>Cc: l2vpn@ietf.org >>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>> >>>>Yuanlong, >>>> >>>>Or better yet, include in the draft a 'standard' value for root sourced >>>>VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You would a= lso >>>>have to require the the implementation NOT use global VLAN's, however >>>>(since each instance would be using the same values). In this way, no >>>>signaling or manual configuration is required for remote PE's to know >>>>how >>>>to classify traffic. >>>>[JY] Indeed, we discussed this possibility during the f2f meeting in >>>>Paris. But, there are some restrictions as you mentioned, and >>>>furthermore: >>>>1) Some vendors already used S-VLAN to distinguish their VSIs in the >>>>PE; >>>>2) Forwarding plane of a PE needs to be revised to be aware of this >>>>VLAN >>>>ID. >>>>Therefore, this 'standard value' approach seems more disruptive >>>>compared >>>>with the other means and not a good candidate option. >>>> >>>>Regarding switching PE's? Multi-PW means more than one PW, yes. I >>>>don't >>>>see this as a real problem. In general, design should try and avoid >>>>using >>>>S-PE's, but if you must, its going to mean extra work, no matter how >>>>you >>>>look at it. Two PW's for each Etree being switched instead of one is >>>>not >>>>alarming or concerning to me. On the other hand, if you use a dot1q >>>>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's >>>>an >>>>two egress VLAN's if you want the Etree to be handled on both sides >>>>(and >>>>if you use the 'standard' VID's as I mentioned above, you'd have to do >>>>mapping to non-standard and back) >>>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>>requirements from MEF, it has nothing to do with the solutions. Could >>>>you >>>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>>if configuring or signalling two PWs is not a problem, why configuring >>>>or >>>>signalling two VLANs will become a problem? After all, more nodes may >>>>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>>>with 2VLAN (only T-PEs). >>>> >>>>In general, I still prefer multi-PW, primarily because I prefer the >>>>separation of the traffic in the network's forwarding plane, rather >>>>than >>>>shipping it everywhere and deciding whether to forward to the AC when >>>>it >>>>gets to the egress PE. I'm having a hard time putting my finger >>>>exactly >>>>on what it is, or articulating the idea, but it seems that by having >>>>the >>>>traffic placed into two psuedowires, I have more flexibility and ease >>>>of >>>>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>>>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>>>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>>>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>>>PW's could really change that perception. >>>>[JY] Are you saying that we need to develop a totally new forwarding >>>>plane rather than using the Ethernet forwarding plane as described in >>>>the >>>>existing work? >>>> >>>>I hope we can move forward with one of these soon, >>>>[JY] me too. >>>> >>>>Josh >>>> >>>> >>>>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >>>> >>>>>Daniel, >>>>> >>>>>Not aware that we had a discussion on this before, but IMHO the >>>>>allocation of internal S-VLAN can be automatic, and manuel >>>>>configuration >>>>>of this mapping may not be needed at all. For example, an S-VLAN >>>>>allocation module in the management plane in a PE can do this kind of >>>>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>>>way from a free S-VLAN ID pool. Once the interal S-VLANs are >>>>>allocated, >>>>>the mapping is determined and no other configuration is needed. >>>>> >>>>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>>>allocate >>>>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to >>>>>allocate >>>>>two S-VLANs in the VPLS domain. >>>>> >>>>>On the other hand, for the multi-PW approach, two PWs need to be >>>>>configured for a E-Tree service. When MS-PW is used in the network, >>>>>for >>>>>every S-PE, we need to configure two ingress PW segments and two >>>>>egress >>>>>PW segments. In this case, I don't think we need to use fixed PW >>>>>labels >>>>>across the network for fear of configuration complexity. >>>>> >>>>>Regards, >>>>>Yuanlong >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>Sent: Wednesday, May 02, 2012 8:01 PM >>>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; >>>>>josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Inline. >>>>> >>>>>-----Original Message----- >>>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>>Sent: Wednesday, May 02, 2012 12:30 PM >>>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; >>>>>josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Hi Daniel, Please see my comments in line. >>>>> >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>Sent: Wednesday, May 02, 2012 3:55 PM >>>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Hi Yuanlong, >>>>> >>>>>The problem is not with the total number of S-VLAN IDs, I agree that >>>>>normally there won't be more than 2047. The problem is that if you >>>>>don't >>>>>support all VLAN IDs, you need S-VLAN space coordination with the >>>>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to >>>>>2047". >>>>>Which won't always be in line with an existing deployment. >>>>>[JY] This is not the case. If the total number is no more than 2047, >>>>>it >>>>>surely can be supported. The S-VLAN space of user domain is totally >>>>>different from the S-VLAN in the provider domain and they can be >>>>>overlapped, I don't see why we need S-VLAN space coordination between >>>>>them. >>>>> >>>>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>>>fixed, and therefore the IEEE S-VID that can be supported is also >>>>>fixed. >>>>> >>>>>Of course you can configure the mapping in each PE according to >>>>>operator >>>>>requirements but as we discussed before this increases complexity. >>>>> >>>>>Relying on PBB-VPLS imposes additional limitations on backward >>>>>compatibility. >>>>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>>>think they may well need MAC-in-MAC in their networks for the >>>>>scalability issue. As you know, only PBB VPLS can provide both. >>>>> >>>>>Daniel >>>>> >>>>>-----Original Message----- >>>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>>Sent: Wednesday, May 02, 2012 5:07 AM >>>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; >>>>>josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Hi Daniel, >>>>> >>>>>As you can see, both cases are discussed in the I-D. >>>>> >>>>>With regard to case 1) (that is, S-VLAN translation), since the access >>>>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>>>they need to be configured on a PE anyway, and as the past emails by >>>>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>>>mapping. >>>>> >>>>>With regard to S-VID space reduction, the constraint is valid only >>>>>when >>>>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>>>typical and with no such limits as we already discussed in the f2f >>>>>meeting. >>>>> >>>>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>>>described (not sure this is a valid use case in real life), PBB-VPLS >>>>>can >>>>>still be used. >>>>> >>>>>Regards, >>>>>Yuanlong >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>Sent: Monday, April 30, 2012 10:34 PM >>>>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>>Jiangyuanlong; josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>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] >>>>>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 >>>>> >>>>>---------------------------------------------------------------------- >>>> >>>> >>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>proprietary information, which is privileged, confidential, or subject >>>>to >>>>copyright belonging to Time Warner Cable. This E-mail is intended >>>>solely >>>>for the use of the individual or entity to which it is addressed. If >>>>you >>>>are not the intended recipient of this E-mail, you are hereby notified >>>>that any dissemination, distribution, copying, or action taken in >>>>relation to the contents of and attachments to this E-mail is strictly >>>>prohibited and may be unlawful. If you have received this 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 and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for >the use of the individual or entity to which it is addressed. If you are >not >the intended recipient of this E-mail, you are hereby notified that any >dissemination, distribution, copying, or action taken in relation to the >contents of and attachments to this E-mail is strictly prohibited and may >be >unlawful. If you have received this 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 96, Issue 15 >************************************* > 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 Mon May 7 15: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 25C3211E8074 for ; Mon, 7 May 2012 15:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.488 X-Spam-Level: X-Spam-Status: No, score=-0.488 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 jAQNz5jxFDOp for ; Mon, 7 May 2012 15:49:01 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2AA21F864E for ; Mon, 7 May 2012 15:49:01 -0700 (PDT) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.75,546,1330923600"; d="scan'208";a="377844752" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 07 May 2012 18:48:28 -0400 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.36]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Mon, 7 May 2012 18:49:00 -0400 From: "Rogers, Josh" To: Lucy yong , Sam Cao , "l2vpn@ietf.org" Date: Mon, 7 May 2012 18:48:57 -0400 Subject: Re: L2vpn Digest, Vol 96, Issue 15 Thread-Topic: L2vpn Digest, Vol 96, Issue 15 Thread-Index: Ac0so5eW804cn/LZRiGy3QPPJOpmgw== Message-ID: In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D3310422D@dfweml506-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: Jiangyuanlong 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, 07 May 2012 22:49:05 -0000 [[LY]] You can use QoS to achieve that too. MEF discuss about this a lot. The trade-off in the use of different transport pipes is that you lose the ability to share the BW. However, you can argue to use over-subscription. But it makes operation more complex. After a long debate, MEF decide to use one transport pipe for both root and leaf traffic. I could also argue to use aggregate policing. Regardless, I don't think this additional ability to traffic engineer by transport pipes is a worthy note in this discussion. At the end of the day, the application need is to have additional granularity with forwarding traffic between AC's in a VPLS, based on the source and destination AC. ETREE requires only two AC types, which both methods meet, and I still think both are valid solutions (even though I prefer one over the other.) -Josh On 5/7/12 5:36 PM, "Lucy yong" wrote: >Josh, > >Snip.. > >Additionally, if I wanted to have traffic >engineering that impacted root-sourced and leaf-sourced traffic >differently, I can do that with multi-PW, where I could not (save for >ingress/egress) with the 2VLAN approach. PE should report signaling on >second PW same as it does for the 100th PW between PE's. Again, I don't >see the problem you are alluding to. > >[[LY]] You can use QoS to achieve that too. MEF discuss about this a >lot. The trade-off in the use of different transport pipes is that you >lose the ability to share the BW. However, you can argue to use >over-subscription. But it makes operation more complex. After a long >debate, MEF decide to use one transport pipe for both root and leaf >traffic. > >this is humorous to me, because at one time, VLAN-ID was used to >identify a single broadcast domain, and then later asymmetrical VID's were >used to limit communication between endpoints of a broadcast domain >(effectively creating two one-way broadcast domains, very similar to what >we're accomplishing with ETREE). This should not be the reason to judge >on the solution. > >[[LY]] This is because applications become more complex. There are >private LAN, community LAN, group LAN, etc. > >Thanks, >Lucy > >> >>Regards, >>Lucy >> >>Lucy >> >>Thanks, >> >>Sam >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >>l2vpn-request@ietf.org >>Sent: Friday, May 04, 2012 10:31 PM >>To: l2vpn@ietf.org >>Subject: L2vpn Digest, Vol 96, Issue 15 >> >>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) >> 2. Re: The status of the approaches to the E-Tree solution? >> (Rogers, Josh) >> >> >>---------------------------------------------------------------------- >> >>Message: 1 >>Date: Fri, 4 May 2012 14:16:36 +0000 >>From: Lucy yong >>To: "Rogers, Josh" , Jiangyuanlong >> , Daniel Cohn , >>"Fedyk, >> Donald (Don)" , "Henderickx, Wim >> (Wim)" >>Cc: "l2vpn@ietf.org" >>Subject: RE: The status of the approaches to the E-Tree solution? >>Message-ID: <2691CE0099834E4A9C5044EEC662BB9D330E9114@dfweml505-mbx> >>Content-Type: text/plain; charset=3D"iso-8859-2" >> >>Josh, >> >>You simply say that you don't like IEEE Tree solution. IEEE Tree solution >>is >>for ingress port to mark and for egress port to filter. >> >>Regards, >>Lucy >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Friday, May 04, 2012 7:27 AM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); >>Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>also separate the leaf traffic in the ingress PE and filter it there >>(already detailed in the Optimization Mode in the I-D); if the egress PE >>is attached with pure roots or with both roots and leafs, it seems all >>traffic must be transported to the egress PE and be filtered there, I see >>no difference in behaviour for these solutions. Or did I miss something? >> >> >>The point is with the multi-PW method the traffic is split/separated (by >>psuedowire) on the ingress PE, rather than the egress. The distinction >>is >>2VLAN will 'classify' the frame on the ingress PE, so that the egress PE >>knows how to forward it to the appropriate AC's. >> >>Both methods have inefficiencies (one duplicates traffic for transport, >>while the other transports where it doesn't need to go). I like the idea >>of classify and forwarding on the ingress PE, rather than marking it on >>the ingress, and deciding on the egress. >> >>-Josh >> >> >> >>On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: >> >>>Josh, thank you for the comments, please see my further comments with >>>[JY2]. >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Thursday, May 03, 2012 11:27 PM >>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>(Wim); Lucy yong >>>Cc: l2vpn@ietf.org >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>requirements from MEF, it has nothing to do with the solutions. Could >>>you >>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>if >>>configuring or signalling two PWs is not a problem, why configuring or >>>signalling two VLANs will become a problem? After all, more nodes may >>>need >>>to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >>>2VLAN (only T-PEs). >>> >>> >>>There is no other way (if both MPLS domains are part of the same ETREE, >>>rather than doing something more like H-VPLS, where one domain has point >>>to points to the other domain which handles the ETREE instance) if you >>>are >>>using an ENNI. The other method, (not mentioned earlier) is tying the >>>two >>>MPLS domains together via labeled unicast (much preferred over E-NNI in >>>my >>>opinion) >>> >>>Configuring two VLAN's isn't really a 'problem' any more than two PW's. >>>I >>>wasn't saying that configuring two VLAN's was difficult, I was objecting >>>to the statement that configuring two PW's is difficult. >>> >>>[JY2] Thanks, I see your point. I take the example of 2PW configuration >>>just to show that using fixed global values to simplify configuration >>>makes no sense. Personally I also don't think configuration is a problem >>>for both solutions. >>> >>>I find the differences between these two methods rather slight. The >>>'tie-breaker' for me is by placing the forwarding decision on the >>>ingress >>>PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >>>more control over where the traffic goes, and in my mind it provides a >>>cleaner destination between customer traffic and forwarding plane. I'm >>>accustomed to looking at a psuedowire and knowing where its going, with >>>the 2vlan method, I can see the psuedowire, but must go to the egress PE >>>to see if it will be dropped there, or forwarded to one or more AC's. >>> >>>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>>also separate the leaf traffic in the ingress PE and filter it there >>>(already detailed in the Optimization Mode in the I-D); if the egress PE >>>is attached with pure roots or with both roots and leafs, it seems all >>>traffic must be transported to the egress PE and be filtered there, I >>>see >>>no difference in behaviour for these solutions. Or did I miss something? >>> >>>Again, the difference here is slight, and I would honestly be happy to >>>see >>>either of them come to fruition. Please don't infer that I think the >>>2vlan method is 'bad' or has intrinsic problems, because I don't believe >>>that. I just prefer the multi-PW method. >>> >>> >>>-Josh >>> >>> >>>On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: >>> >>>>Josh, please see my comments in line. >>>> >>>>Thanks >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>>Sent: Thursday, May 03, 2012 10:51 AM >>>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>>(Wim); Lucy yong >>>>Cc: l2vpn@ietf.org >>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>> >>>>Yuanlong, >>>> >>>>Or better yet, include in the draft a 'standard' value for root sourced >>>>VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You would a= lso >>>>have to require the the implementation NOT use global VLAN's, however >>>>(since each instance would be using the same values). In this way, no >>>>signaling or manual configuration is required for remote PE's to know >>>>how >>>>to classify traffic. >>>>[JY] Indeed, we discussed this possibility during the f2f meeting in >>>>Paris. But, there are some restrictions as you mentioned, and >>>>furthermore: >>>>1) Some vendors already used S-VLAN to distinguish their VSIs in the >>>>PE; >>>>2) Forwarding plane of a PE needs to be revised to be aware of this >>>>VLAN >>>>ID. >>>>Therefore, this 'standard value' approach seems more disruptive >>>>compared >>>>with the other means and not a good candidate option. >>>> >>>>Regarding switching PE's? Multi-PW means more than one PW, yes. I >>>>don't >>>>see this as a real problem. In general, design should try and avoid >>>>using >>>>S-PE's, but if you must, its going to mean extra work, no matter how >>>>you >>>>look at it. Two PW's for each Etree being switched instead of one is >>>>not >>>>alarming or concerning to me. On the other hand, if you use a dot1q >>>>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's >>>>an >>>>two egress VLAN's if you want the Etree to be handled on both sides >>>>(and >>>>if you use the 'standard' VID's as I mentioned above, you'd have to do >>>>mapping to non-standard and back) >>>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>>requirements from MEF, it has nothing to do with the solutions. Could >>>>you >>>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>>if configuring or signalling two PWs is not a problem, why configuring >>>>or >>>>signalling two VLANs will become a problem? After all, more nodes may >>>>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>>>with 2VLAN (only T-PEs). >>>> >>>>In general, I still prefer multi-PW, primarily because I prefer the >>>>separation of the traffic in the network's forwarding plane, rather >>>>than >>>>shipping it everywhere and deciding whether to forward to the AC when >>>>it >>>>gets to the egress PE. I'm having a hard time putting my finger >>>>exactly >>>>on what it is, or articulating the idea, but it seems that by having >>>>the >>>>traffic placed into two psuedowires, I have more flexibility and ease >>>>of >>>>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>>>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>>>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>>>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>>>PW's could really change that perception. >>>>[JY] Are you saying that we need to develop a totally new forwarding >>>>plane rather than using the Ethernet forwarding plane as described in >>>>the >>>>existing work? >>>> >>>>I hope we can move forward with one of these soon, >>>>[JY] me too. >>>> >>>>Josh >>>> >>>> >>>>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >>>> >>>>>Daniel, >>>>> >>>>>Not aware that we had a discussion on this before, but IMHO the >>>>>allocation of internal S-VLAN can be automatic, and manuel >>>>>configuration >>>>>of this mapping may not be needed at all. For example, an S-VLAN >>>>>allocation module in the management plane in a PE can do this kind of >>>>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>>>way from a free S-VLAN ID pool. Once the interal S-VLANs are >>>>>allocated, >>>>>the mapping is determined and no other configuration is needed. >>>>> >>>>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>>>allocate >>>>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to >>>>>allocate >>>>>two S-VLANs in the VPLS domain. >>>>> >>>>>On the other hand, for the multi-PW approach, two PWs need to be >>>>>configured for a E-Tree service. When MS-PW is used in the network, >>>>>for >>>>>every S-PE, we need to configure two ingress PW segments and two >>>>>egress >>>>>PW segments. In this case, I don't think we need to use fixed PW >>>>>labels >>>>>across the network for fear of configuration complexity. >>>>> >>>>>Regards, >>>>>Yuanlong >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>Sent: Wednesday, May 02, 2012 8:01 PM >>>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; >>>>>josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Inline. >>>>> >>>>>-----Original Message----- >>>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>>Sent: Wednesday, May 02, 2012 12:30 PM >>>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; >>>>>josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Hi Daniel, Please see my comments in line. >>>>> >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>Sent: Wednesday, May 02, 2012 3:55 PM >>>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Hi Yuanlong, >>>>> >>>>>The problem is not with the total number of S-VLAN IDs, I agree that >>>>>normally there won't be more than 2047. The problem is that if you >>>>>don't >>>>>support all VLAN IDs, you need S-VLAN space coordination with the >>>>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to >>>>>2047". >>>>>Which won't always be in line with an existing deployment. >>>>>[JY] This is not the case. If the total number is no more than 2047, >>>>>it >>>>>surely can be supported. The S-VLAN space of user domain is totally >>>>>different from the S-VLAN in the provider domain and they can be >>>>>overlapped, I don't see why we need S-VLAN space coordination between >>>>>them. >>>>> >>>>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>>>fixed, and therefore the IEEE S-VID that can be supported is also >>>>>fixed. >>>>> >>>>>Of course you can configure the mapping in each PE according to >>>>>operator >>>>>requirements but as we discussed before this increases complexity. >>>>> >>>>>Relying on PBB-VPLS imposes additional limitations on backward >>>>>compatibility. >>>>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>>>think they may well need MAC-in-MAC in their networks for the >>>>>scalability issue. As you know, only PBB VPLS can provide both. >>>>> >>>>>Daniel >>>>> >>>>>-----Original Message----- >>>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>>Sent: Wednesday, May 02, 2012 5:07 AM >>>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; >>>>>josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Hi Daniel, >>>>> >>>>>As you can see, both cases are discussed in the I-D. >>>>> >>>>>With regard to case 1) (that is, S-VLAN translation), since the access >>>>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>>>they need to be configured on a PE anyway, and as the past emails by >>>>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>>>mapping. >>>>> >>>>>With regard to S-VID space reduction, the constraint is valid only >>>>>when >>>>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>>>typical and with no such limits as we already discussed in the f2f >>>>>meeting. >>>>> >>>>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>>>described (not sure this is a valid use case in real life), PBB-VPLS >>>>>can >>>>>still be used. >>>>> >>>>>Regards, >>>>>Yuanlong >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>Sent: Monday, April 30, 2012 10:34 PM >>>>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>>Jiangyuanlong; josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>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] >>>>>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 >>>>> >>>>>---------------------------------------------------------------------- >>>> >>>> >>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>proprietary information, which is privileged, confidential, or subject >>>>to >>>>copyright belonging to Time Warner Cable. This E-mail is intended >>>>solely >>>>for the use of the individual or entity to which it is addressed. If >>>>you >>>>are not the intended recipient of this E-mail, you are hereby notified >>>>that any dissemination, distribution, copying, or action taken in >>>>relation to the contents of and attachments to this E-mail is strictly >>>>prohibited and may be unlawful. If you have received this 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. >> >> >>------------------------------ >> >>Message: 2 >>Date: Fri, 4 May 2012 10:30:38 -0400 >>From: "Rogers, Josh" >>To: Lucy yong , Jiangyuanlong >> , Daniel Cohn , >>"Fedyk, >> Donald (Don)" , "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"iso-8859-2" >> >>To be more accurate, I like it less than the multi-PW solution. I'd be >>happy to use the 2VLAN solution in the real world, if it was ratified as >>the standard. >> >> >> >>On 5/4/12 9:16 AM, "Lucy yong" wrote: >> >>>Josh, >>> >>>You simply say that you don't like IEEE Tree solution. IEEE Tree >>>solution >>>is for ingress port to mark and for egress port to filter. >>> >>>Regards, >>>Lucy >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Friday, May 04, 2012 7:27 AM >>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>(Wim); Lucy yong >>>Cc: l2vpn@ietf.org >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>>also separate the leaf traffic in the ingress PE and filter it there >>>(already detailed in the Optimization Mode in the I-D); if the egress PE >>>is attached with pure roots or with both roots and leafs, it seems all >>>traffic must be transported to the egress PE and be filtered there, I >>>see >>>no difference in behaviour for these solutions. Or did I miss something? >>> >>> >>>The point is with the multi-PW method the traffic is split/separated (by >>>psuedowire) on the ingress PE, rather than the egress. The distinction >>>is >>>2VLAN will 'classify' the frame on the ingress PE, so that the egress PE >>>knows how to forward it to the appropriate AC's. >>> >>>Both methods have inefficiencies (one duplicates traffic for transport, >>>while the other transports where it doesn't need to go). I like the >>>idea >>>of classify and forwarding on the ingress PE, rather than marking it on >>>the ingress, and deciding on the egress. >>> >>>-Josh >>> >>> >>> >>>On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: >>> >>>>Josh, thank you for the comments, please see my further comments with >>>>[JY2]. >>>> >>>>-----Original Message----- >>>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>>Sent: Thursday, May 03, 2012 11:27 PM >>>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>>(Wim); Lucy yong >>>>Cc: l2vpn@ietf.org >>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>> >>>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>>requirements from MEF, it has nothing to do with the solutions. Could >>>>you >>>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>>if >>>>configuring or signalling two PWs is not a problem, why configuring or >>>>signalling two VLANs will become a problem? After all, more nodes may >>>>need >>>>to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >>>>2VLAN (only T-PEs). >>>> >>>> >>>>There is no other way (if both MPLS domains are part of the same ETREE, >>>>rather than doing something more like H-VPLS, where one domain has >>>>point >>>>to points to the other domain which handles the ETREE instance) if you >>>>are >>>>using an ENNI. The other method, (not mentioned earlier) is tying the >>>>two >>>>MPLS domains together via labeled unicast (much preferred over E-NNI in >>>>my >>>>opinion) >>>> >>>>Configuring two VLAN's isn't really a 'problem' any more than two PW's. >>>>I >>>>wasn't saying that configuring two VLAN's was difficult, I was >>>>objecting >>>>to the statement that configuring two PW's is difficult. >>>> >>>>[JY2] Thanks, I see your point. I take the example of 2PW configuration >>>>just to show that using fixed global values to simplify configuration >>>>makes no sense. Personally I also don't think configuration is a >>>>problem >>>>for both solutions. >>>> >>>>I find the differences between these two methods rather slight. The >>>>'tie-breaker' for me is by placing the forwarding decision on the >>>>ingress >>>>PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you >>>>get >>>>more control over where the traffic goes, and in my mind it provides a >>>>cleaner destination between customer traffic and forwarding plane. I'm >>>>accustomed to looking at a psuedowire and knowing where its going, with >>>>the 2vlan method, I can see the psuedowire, but must go to the egress >>>>PE >>>>to see if it will be dropped there, or forwarded to one or more AC's. >>>> >>>>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>>>also separate the leaf traffic in the ingress PE and filter it there >>>>(already detailed in the Optimization Mode in the I-D); if the egress >>>>PE >>>>is attached with pure roots or with both roots and leafs, it seems all >>>>traffic must be transported to the egress PE and be filtered there, I >>>>see >>>>no difference in behaviour for these solutions. Or did I miss >>>>something? >>>> >>>>Again, the difference here is slight, and I would honestly be happy to >>>>see >>>>either of them come to fruition. Please don't infer that I think the >>>>2vlan method is 'bad' or has intrinsic problems, because I don't >>>>believe >>>>that. I just prefer the multi-PW method. >>>> >>>> >>>>-Josh >>>> >>>> >>>>On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: >>>> >>>>>Josh, please see my comments in line. >>>>> >>>>>Thanks >>>>>Yuanlong >>>>> >>>>>-----Original Message----- >>>>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>>>Sent: Thursday, May 03, 2012 10:51 AM >>>>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>>>(Wim); Lucy yong >>>>>Cc: l2vpn@ietf.org >>>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>>> >>>>>Yuanlong, >>>>> >>>>>Or better yet, include in the draft a 'standard' value for root >>>>>sourced >>>>>VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You would = also >>>>>have to require the the implementation NOT use global VLAN's, however >>>>>(since each instance would be using the same values). In this way, no >>>>>signaling or manual configuration is required for remote PE's to know >>>>>how >>>>>to classify traffic. >>>>>[JY] Indeed, we discussed this possibility during the f2f meeting in >>>>>Paris. But, there are some restrictions as you mentioned, and >>>>>furthermore: >>>>>1) Some vendors already used S-VLAN to distinguish their VSIs in the >>>>>PE; >>>>>2) Forwarding plane of a PE needs to be revised to be aware of this >>>>>VLAN >>>>>ID. >>>>>Therefore, this 'standard value' approach seems more disruptive >>>>>compared >>>>>with the other means and not a good candidate option. >>>>> >>>>>Regarding switching PE's? Multi-PW means more than one PW, yes. I >>>>>don't >>>>>see this as a real problem. In general, design should try and avoid >>>>>using >>>>>S-PE's, but if you must, its going to mean extra work, no matter how >>>>>you >>>>>look at it. Two PW's for each Etree being switched instead of one is >>>>>not >>>>>alarming or concerning to me. On the other hand, if you use a dot1q >>>>>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's >>>>>an >>>>>two egress VLAN's if you want the Etree to be handled on both sides >>>>>(and >>>>>if you use the 'standard' VID's as I mentioned above, you'd have to do >>>>>mapping to non-standard and back) >>>>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>>>requirements from MEF, it has nothing to do with the solutions. Could >>>>>you >>>>>give a hint on how you can provision this service E-NNI otherwise? >>>>>BTW, >>>>>if configuring or signalling two PWs is not a problem, why configuring >>>>>or >>>>>signalling two VLANs will become a problem? After all, more nodes may >>>>>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>>>>with 2VLAN (only T-PEs). >>>>> >>>>>In general, I still prefer multi-PW, primarily because I prefer the >>>>>separation of the traffic in the network's forwarding plane, rather >>>>>than >>>>>shipping it everywhere and deciding whether to forward to the AC when >>>>>it >>>>>gets to the egress PE. I'm having a hard time putting my finger >>>>>exactly >>>>>on what it is, or articulating the idea, but it seems that by having >>>>>the >>>>>traffic placed into two psuedowires, I have more flexibility and ease >>>>>of >>>>>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>>>>H-VPLS (both psuedowire based and vlan based). Of course my 'ease >>>>>of >>>>>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>>>>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>>>>PW's could really change that perception. >>>>>[JY] Are you saying that we need to develop a totally new forwarding >>>>>plane rather than using the Ethernet forwarding plane as described in >>>>>the >>>>>existing work? >>>>> >>>>>I hope we can move forward with one of these soon, >>>>>[JY] me too. >>>>> >>>>>Josh >>>>> >>>>> >>>>>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >>>>> >>>>>>Daniel, >>>>>> >>>>>>Not aware that we had a discussion on this before, but IMHO the >>>>>>allocation of internal S-VLAN can be automatic, and manuel >>>>>>configuration >>>>>>of this mapping may not be needed at all. For example, an S-VLAN >>>>>>allocation module in the management plane in a PE can do this kind of >>>>>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>>>>single external S-VLAN ID) in a topdown, bottom-up, or just any >>>>>>random >>>>>>way from a free S-VLAN ID pool. Once the interal S-VLANs are >>>>>>allocated, >>>>>>the mapping is determined and no other configuration is needed. >>>>>> >>>>>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>>>>allocate >>>>>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to >>>>>>allocate >>>>>>two S-VLANs in the VPLS domain. >>>>>> >>>>>>On the other hand, for the multi-PW approach, two PWs need to be >>>>>>configured for a E-Tree service. When MS-PW is used in the network, >>>>>>for >>>>>>every S-PE, we need to configure two ingress PW segments and two >>>>>>egress >>>>>>PW segments. In this case, I don't think we need to use fixed PW >>>>>>labels >>>>>>across the network for fear of configuration complexity. >>>>>> >>>>>>Regards, >>>>>>Yuanlong >>>>>> >>>>>>-----Original Message----- >>>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>>Sent: Wednesday, May 02, 2012 8:01 PM >>>>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>>yong; >>>>>>josh.rogers@twcable.com >>>>>>Cc: l2vpn@ietf.org >>>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>>> >>>>>>Inline. >>>>>> >>>>>>-----Original Message----- >>>>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>>>Sent: Wednesday, May 02, 2012 12:30 PM >>>>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>>yong; >>>>>>josh.rogers@twcable.com >>>>>>Cc: l2vpn@ietf.org >>>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>>> >>>>>>Hi Daniel, Please see my comments in line. >>>>>> >>>>>> >>>>>>-----Original Message----- >>>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>>Sent: Wednesday, May 02, 2012 3:55 PM >>>>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>>yong; josh.rogers@twcable.com >>>>>>Cc: l2vpn@ietf.org >>>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>>> >>>>>>Hi Yuanlong, >>>>>> >>>>>>The problem is not with the total number of S-VLAN IDs, I agree that >>>>>>normally there won't be more than 2047. The problem is that if you >>>>>>don't >>>>>>support all VLAN IDs, you need S-VLAN space coordination with the >>>>>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to >>>>>>2047". >>>>>>Which won't always be in line with an existing deployment. >>>>>>[JY] This is not the case. If the total number is no more than 2047, >>>>>>it >>>>>>surely can be supported. The S-VLAN space of user domain is totally >>>>>>different from the S-VLAN in the provider domain and they can be >>>>>>overlapped, I don't see why we need S-VLAN space coordination between >>>>>>them. >>>>>> >>>>>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>>>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>>>>fixed, and therefore the IEEE S-VID that can be supported is also >>>>>>fixed. >>>>>> >>>>>>Of course you can configure the mapping in each PE according to >>>>>>operator >>>>>>requirements but as we discussed before this increases complexity. >>>>>> >>>>>>Relying on PBB-VPLS imposes additional limitations on backward >>>>>>compatibility. >>>>>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>>>>think they may well need MAC-in-MAC in their networks for the >>>>>>scalability issue. As you know, only PBB VPLS can provide both. >>>>>> >>>>>>Daniel >>>>>> >>>>>>-----Original Message----- >>>>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>>>Sent: Wednesday, May 02, 2012 5:07 AM >>>>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>>yong; >>>>>>josh.rogers@twcable.com >>>>>>Cc: l2vpn@ietf.org >>>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>>> >>>>>>Hi Daniel, >>>>>> >>>>>>As you can see, both cases are discussed in the I-D. >>>>>> >>>>>>With regard to case 1) (that is, S-VLAN translation), since the >>>>>>access >>>>>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>>>>they need to be configured on a PE anyway, and as the past emails by >>>>>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by >>>>>>1:1 >>>>>>mapping. >>>>>> >>>>>>With regard to S-VID space reduction, the constraint is valid only >>>>>>when >>>>>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>>>>typical and with no such limits as we already discussed in the f2f >>>>>>meeting. >>>>>> >>>>>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>>>>described (not sure this is a valid use case in real life), PBB-VPLS >>>>>>can >>>>>>still be used. >>>>>> >>>>>>Regards, >>>>>>Yuanlong >>>>>> >>>>>>-----Original Message----- >>>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>>Sent: Monday, April 30, 2012 10:34 PM >>>>>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>>>Jiangyuanlong; josh.rogers@twcable.com >>>>>>Cc: l2vpn@ietf.org >>>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>>> >>>>>>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] >>>>>>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 >>>>>> >>>>>>--------------------------------------------------------------------- >>>>>>- >>>>> >>>>> >>>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>>proprietary information, which is privileged, confidential, or subject >>>>>to >>>>>copyright belonging to Time Warner Cable. This E-mail is intended >>>>>solely >>>>>for the use of the individual or entity to which it is addressed. If >>>>>you >>>>>are not the intended recipient of this E-mail, you are hereby notified >>>>>that any dissemination, distribution, copying, or action taken in >>>>>relation to the contents of and attachments to this E-mail is strictly >>>>>prohibited and may be unlawful. If you have received this 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 and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject to >>copyright belonging to Time Warner Cable. This E-mail is intended solely >>for >>the use of the individual or entity to which it is addressed. If you are >>not >>the intended recipient of this E-mail, you are hereby notified that any >>dissemination, distribution, copying, or action taken in relation to the >>contents of and attachments to this E-mail is strictly prohibited and may >>be >>unlawful. If you have received this 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 96, Issue 15 >>************************************* >> > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use of the individual or entity to which it is addressed. If you >are not the intended recipient of this E-mail, you are hereby notified >that any dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this 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 xuxiaohu@huawei.com Mon May 7 20:21: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 59CE721F84F8; Mon, 7 May 2012 20:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.549 X-Spam-Level: X-Spam-Status: No, score=-0.549 tagged_above=-999 required=5 tests=[AWL=1.450, 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 ddT4F0qlYrle; Mon, 7 May 2012 20:21:56 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id A541A21F84CD; Mon, 7 May 2012 20:21: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 AFP49141; Mon, 07 May 2012 23:21:53 -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, 7 May 2012 20:20:37 -0700 Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 7 May 2012 20:20:39 -0700 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.182]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.01.0323.003; Tue, 8 May 2012 11:20:36 +0800 From: Xuxiaohu To: "l2vpn@ietf.org" , "l3vpn@ietf.org" , "nvo3@ietf.org" Subject: Facilitating the load-balancing of L2VPN/L3VPN traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version Notification for draft-xu-mpls-in-udp-00.txt Thread-Topic: Facilitating the load-balancing of L2VPN/L3VPN traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version Notification for draft-xu-mpls-in-udp-00.txt Thread-Index: AQHNJOUqEV0uAsQuJk6ASHAvdqt8upavh4QAgA+/yUA= Date: Tue, 8 May 2012 03:20:36 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02F20BF9@szxeml525-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.99] Content-Type: text/plain; charset="utf-8" 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: Tue, 08 May 2012 03:21:57 -0000 SGkgYWxsLA0KDQpUaGlzIHRvcGljIG1heSBiZSBpbnRlcmVzdGluZyB0byBMMlZQTiwgTDNWUE4g YW5kIGV2ZW4gTlZvMyBmb2xrcy4gDQoNCkFueSBjb21tZW50cyBhcmUgd2VsY29tZS4NCg0KQmVz dCByZWdhcmRzLA0KWGlhb2h1LyBNYXJzaGFsbC9MdWN5DQoNCj4gLS0tLS3pgq7ku7bljp/ku7Yt LS0tLQ0KPiDlj5Hku7bkuro6IFh1eGlhb2h1DQo+IOWPkemAgeaXtumXtDogMjAxMuW5tDTmnIgy OOaXpSAxMDo1NQ0KPiDmlLbku7bkuro6ICdtcGxzQGlldGYub3JnJw0KPiDmioTpgIE6ICdtYXJz aGFsbC5ldWJhbmtzQGdtYWlsLmNvbSc7IEx1Y3kgeW9uZw0KPiDkuLvpopg6IGZ3ZDogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC14dS1tcGxzLWluLXVkcC0wMC50eHQNCj4gDQo+ IEhpIGFsbCwNCj4gDQo+IEVxdWFsIENvc3QgTXVsdGktUGF0aCAoRUNNUCkgYW5kIExpbmsgQWdn cmVnYXRpb24gR3JvdXAgKExBRykgYXJlIHdpZGVseSB1c2VkDQo+IGluIHRoZSBjb3JlIG9mIElQ LWVuYWJsZWQgUGFja2V0IFN3aXRjaCBOZXR3b3JrcyAoUFNOKSBmb3IgbG9hZC1iYWxhbmNpbmcN Cj4gcHVycG9zZXMuIE1vc3QgY29yZSByb3V0ZXJzIChpLmUuLCBQIHJvdXRlcnMpIGluIHRoZSBJ UC1lbmFibGVkIFBTTiBhcmUgY2FwYWJsZSBvZg0KPiBsb2FkLWJhbGFuY2luZyBJUCB0cmFmZmlj IGZsb3dzIGFjcm9zcyBFQ01QIHBhdGhzIGFuZC9vciBMQUcgYmFzZWQgb24gdGhlIGhhc2gNCj4g b2YgdGhlIGZpdmUtdHVwbGUgb2YgICBVRFAvVENQIHBhY2tldHMgKGkuZS4sIHNvdXJjZSBJUCBh ZGRyZXNzLCBkZXN0aW5hdGlvbiBJUA0KPiBhZGRyZXNzLCBzb3VyY2UgcG9ydCwgZGVzdGluYXRp b24gcG9ydCwgYW5kIHByb3RvY29sKSBvciBzb21lIGZpZWxkcyBpbiB0aGUgSVANCj4gaGVhZGVy IG9mIG5vbi1VRFAvVENQIHBhY2tldHMgKGUuZy4sIHNvdXJjZSBJUCBhZGRyZXNzLCBkZXN0aW5h dGlvbiBJUCBhZGRyZXNzKS4NCj4gDQo+IEhvd2V2ZXIsIHdpdGggZXhpc3RpbmcgSVAtYmFzZWQg ZW5jYXBzdWxhdGlvbiBtZXRob2RzIGFzIGRlZmluZWQgaW4gW1JGQzQwMjNdDQo+IHN1Y2ggYXMg TVBMUy1pbi1JUCBhbmQgTVBMUy1pbi1HUkUsIGRpc3RpbmN0IGN1c3RvbWVyIHRyYWZmaWMgZmxv d3Mgb2YgdmFyaW91cw0KPiBNUExTIGFwcGxpY2F0aW9ucyAoZS5nLiwgTVBMUy1iYXNlZCBMMlZQ TiBvciBMM1ZQTikgYmV0d2VlbiBhIGdpdmVuIFBFIHBhaXINCj4gd291bGQgYmUgZW5jYXBzdWxh dGVkIHdpdGggdGhlIHNhbWUgSVAgb3IgR1JFIHR1bm5lbCBoZWFkZXIgcHJpb3IgdG8gdHJhdmVy c2luZw0KPiB0aGUgY29yZS4gU2luY2UgdGhlIGVuY2Fwc3VsYXRpbmcgdHJhZmZpYyBpcyBuZWl0 aGVyIFRDUCBub3IgVURQIHRyYWZmaWMsIGNvcmUNCj4gcm91dGVycyBjb3VsZCBvbmx5IHBlcmZv cm0gaGFzaCBjYWxjdWxhdGlvbiBvbiB0aGUgZmllbGRzIGluIHRoZSBJUCBoZWFkZXIgb2YgSVAg b3INCj4gR1JFIHR1bm5lbHMuIEFzIGEgcmVzdWx0LCBjb3JlIHJvdXRlcnMgY291bGQgbm90IGFj aGlldmUgYW4gZWZmZWN0aXZlDQo+IGxvYWQtYmFsYW5jaW5nIGZvciB0aGVzZSB0cmFmZmljIGZs b3dzIGluIHRoZSBuZXR3b3JrIGR1ZSB0byB0aGUgbGFjayBvZiBhZGVxdWF0ZQ0KPiBlbnRyb3B5 IGluZm9ybWF0aW9uLg0KPiANCj4gVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgb25lIGFkZGl0aW9u YWwgSVAtYmFzZWQgZW5jYXBzdWxhdGlvbiB0ZWNobm9sb2d5IGZvcg0KPiBNUExTIHBhY2tldHMg cmVmZXJyZWQgdG8gYXMgTVBMUy1pbi1VRFAsIHdoaWNoIGlzIGludGVuZGVkIHRvIGZhY2lsaXRh dGUNCj4gbG9hZC1iYWxhbmNpbmcgdGhlIHRyYWZmaWMgb2YgdmFyaW91cyBNUExTIGFwcGxpY2F0 aW9ucyBzdWNoIGFzIE1QTFMtYmFzZWQgTDJWUE4NCj4gYW5kIEwzVlBOIGluIHRoZSBjb3JlIG9m IElQLWVuYWJsZWQgUFNOLg0KPiANCj4gQW55IGNvbW1lbnRzIGFyZSB3ZWxjb21lLg0KPiANCj4g QmVzdCByZWdhcmRzLA0KPiBYaWFvaHUNCj4gDQo+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4g 5Y+R5Lu25Lq6OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmddDQo+IOWPkemAgeaXtumXtDogMjAxMuW5tDTmnIgyOOaXpSAxMDoxOA0KPiDm lLbku7bkuro6IFh1eGlhb2h1DQo+IOaKhOmAgTogTHVjeSB5b25nOyBtYXJzaGFsbC5ldWJhbmtz QGdtYWlsLmNvbQ0KPiDkuLvpopg6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQt eHUtbXBscy1pbi11ZHAtMDAudHh0DQo+IA0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQt eHUtbXBscy1pbi11ZHAtMDAudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseQ0KPiBzdWJtaXR0ZWQg YnkgWGlhb2h1IFh1IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCj4gDQo+IEZp bGVuYW1lOgkgZHJhZnQteHUtbXBscy1pbi11ZHANCj4gUmV2aXNpb246CSAwMA0KPiBUaXRsZToJ CSBFbmNhcHN1bGF0aW5nIE1QTFMgaW4gVURQDQo+IENyZWF0aW9uIGRhdGU6CSAyMDEyLTA0LTI4 DQo+IFdHIElEOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiBOdW1iZXIgb2YgcGFnZXM6IDcN Cj4gDQo+IEFic3RyYWN0Og0KPiAgICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBvbmUgYWRkaXRp b25hbCBJUC1iYXNlZCBlbmNhcHN1bGF0aW9uDQo+ICAgIHRlY2hub2xvZ3kgZm9yIE1QTFMgcGFj a2V0cyByZWZlcnJlZCB0byBhcyBNUExTLWluLVVEUCwgd2hpY2ggaXMNCj4gICAgaW50ZW5kZWQg dG8gZmFjaWxpdGF0ZSBsb2FkLWJhbGFuY2luZyB0aGUgdHJhZmZpYyBvZiB2YXJpb3VzIE1QTFMN Cj4gICAgYXBwbGljYXRpb25zIHN1Y2ggYXMgTVBMUy1iYXNlZCBMMlZQTiBhbmQgTDNWUE4gaW4g dGhlIGNvcmUgb2YgSVAtDQo+ICAgIGVuYWJsZWQgcGFja2V0IHN3aXRjaCBuZXR3b3Jrcy4NCj4g DQo+IA0KPiANCj4gDQo+IA0KPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0K From jiangyuanlong@huawei.com Mon May 7 20:32: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 278B521F8543 for ; Mon, 7 May 2012 20:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[AWL=-0.151, 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 VQyTS9v+MRSs for ; Mon, 7 May 2012 20:32:06 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id AB7A021F84EA for ; Mon, 7 May 2012 20:32:06 -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 AFP49780; Mon, 07 May 2012 23:32:06 -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; Mon, 7 May 2012 20:29:36 -0700 Received: from SZXEML431-HUB.china.huawei.com (10.72.61.39) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 7 May 2012 20:29:37 -0700 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.183]) by szxeml431-hub.china.huawei.com ([10.72.61.39]) with mapi id 14.01.0323.003; Tue, 8 May 2012 11:29:27 +0800 From: Jiangyuanlong To: "Rogers, Josh" , Lucy yong , Daniel Cohn , "Fedyk, Donald (Don)" , "Henderickx, Wim (Wim)" 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: AQHNI1NEA18PKDoBDEy6zAcXiVu2LpasuNMAgAYGiYCAAAzygIAAAjQAgAAAAYCAAASFAIAAAOoAgAAYGACAAAPTgIACzjKAgABsbmCAABSDMIAAJEvQgADhaeD//53EgIAAk10ggAA/vACAASTWUIAAOyKAgAR+CPD//633gIAApnLQgAAqVQCAADBAgIAAILyAgADaSNA= Date: Tue, 8 May 2012 03:29:27 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410A86@szxeml546-mbx.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D330F06DD@dfweml506-mbx> 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.73] Content-Type: text/plain; charset="iso-8859-2" 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, 08 May 2012 03:32:09 -0000 Hi Josh,=20 Correcting "fundamentally what is wrong with VPLS" is out scope of the curr= ent L2VPN charter, so let us discuss it no more. But to support the scenario as you detailed (take P1-PE3 as an example) wit= h just one PW as you proposed: Leaf-only -> mixed =3D one PW Mixed -> leaf-only =3D one PW According to draft-ram-l2vpn-etree-multiple-pw-01: "Signaling of root and l= eaf PWs is required only when two PWs are used for interconnecting between = pair of VSIs", so the PW would be just an traditional PW, but how can PE1 k= now that the only PW from PE3 is carrying leaf traffic? Therefore, it seems inevitably 2PW approach needs to associate root/leaf at= tributes with every PW and store these attributes per PW in the forwarding = plane so that the root/leaf traffic can be forwarded or dropped accordingly= . Thus it seems you need to change the control plane and data plane for 2PW t= o support this scenario. Regards, Yuanlong -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com]=20 Sent: Tuesday, May 08, 2012 5:26 AM To: Lucy yong; Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx,= Wim (Wim) Cc: l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? Lucy, you are correct here. Some of what I stated in my email last night was incorrect, due to late-night confusion on my part. In a mixed to mixed transmission of broadcast, depending on the source AC, the packet will only be placed on one PW (a very important detail I overlooked), so there is no duplication. With 2VLAN, there is no considerable difference, the frame will be tagged with the appropriate S-Tag based on the source AC type, and forwarded across the PW once. I apologize for the confusion I created, thank you for clearing it up. Regarding the statement of VPLS requiring PW associating with VSI, not an AC, I agree that is the current application of VPLS, and is fundamentally what is wrong with VPLS. By associating with an AC instead, we are afforded the flexibility to do more interesting things... Like ETREE. -Josh On 5/7/12 2:29 PM, "Lucy yong" wrote: >Josh, > >Thank you to provide the following needed PW for multi-PW solution. The >left side of "=3D" sign represent PE->PE and the right side is needed PW. >We are on the same table now. In addition, I add Dual VLAN for comparison. > >Multi-PW Dual-VLAN >Root-only -> any VSI =3D one PE one PW >Leaf-only -> root-only =3D one PW one PW and one leaf S-VLAN >Leaf-only -> Leaf-only =3D Zero PW Zero PW >Leaf-only -> mixed =3D one PW one PW and one leaf S-VLAN >Mixed -> root-only =3D one PW one PW >Mixed -> leaf-only =3D one PW one PW and one root S-VLAN >Mixed -> mixed =3D two PW one PW and one root S-VLAN >and one leaf VLAN > >Both methods let ingress PE marking and filtering all known unicast >packets in mixed->mixed case. In the case, only a broadcast packet at >mixed PE needs to be forwarded to another mixed PE with the mark, but the >packet is sent once and no need to duplicate. > >VPLS requires PW associating with a VSI not an AC. > >Regards, >Lucy >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Monday, May 07, 2012 11:36 AM >To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >(Wim); Lucy yong >Cc: l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >Comment Inline: > >On 5/7/12 1:34 AM, "Jiangyuanlong" wrote: > >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Monday, May 07, 2012 12:09 PM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>So, if you can imagine three PE's, PE1, PE2 and PE3. PE1 has a root AC, >>R1 and a leaf AC, L1. PE2 also has a root AC, R2, and a leaf AC, L2. >>PE3 >>has a leaf AC, L3. >> >>Consider an unknown unicast frame from the leaf site L1, and also another >>unknown unicast frame from R1 entering. >> >>With the 2VLAN method (to my best understanding): >> - frame from L1 enters PE1, goes into a PW to PE2 and a PW to PE3, >>arrives at PE2 which decides that it should be flooded out all Root AC's, >>based on the S-tag. It also arrives at PE3, where it is dropped because >>there are no root AC's. >> >>[JY] Since PE3 is a leaf-only node, the PW from PE1 to PE3 will work in >>Optimized-Mode. According to Section 5.3.3 of >>draft-jiang-l2vpn-vpls-pe-etree-05, it will be dropped before arriving at >>this PW. Therefore, this frame will not arrive at PE3. >[JR] Correct, in my example I was assuming no optimization. See my later >comment about adding complexity for the sake of optimization (which is not >a problem, just an observation, the same observation holds true for >multi-PW method.) >> >> - frame from R1 enters PE1, goes into a PW to PE2 and a PW to PE3, >>arrives at PE2 which decides that it should be flooded out all AC's, >>based >>on S-tag. It also arrives at PE3 where it is forwarded to all root AC's. >> >>With Multi-PW method: >> - frame from L1 enters PE1, which decides to forward the frame out the >>'root' PW to PE2, which in turn floods out all Root AC's, based on >>arriving PW type. Frame is NOT sent to PE3, since there is no PW built >>to >>the PE which has no root AC's. >> >>[JY] According to my understanding of the following description in >>draft-ram-l2vpn-etree-multiple-pw-01: >> "It should be noted that in a full-mesh VPLS (as opposed to H-VPLS), >> the following VSI pair types do not require two interconnecting PWs: >> Root-only VSI <-> any VSI: only root PW required >> Leaf-only VSI <-> leaf-only VSI: no PWs required" >>There should be 2 PWs be set up between PE1 and PE3, since this is a case >>of "Root & Leaf mixed VSI <-> leaf-only VSI" and not listed in the >>none-two- interconnecting-PWs criteria. Therefore, this frame will be >>sent to PE3 twice (one on root PW, another on leaf PW) IMO. Of course, >>the other authors of draft-ram-l2vpn-etree-multiple-pw-01 may have more >>to say on this point. >[JR] Remember that PW's are unidirectional, we should consider setup in >each direction independently: > >root-only -> any VSI =3D one PW >Leaf-only -> root-only =3D one PW >Leaf-only -> Leaf-only =3D Zero PW >Leaf-only -> mixed =3D one PW >Mixed -> root-only =3D one PW >Mixed -> leaf-only =3D one PW >Mixed -> mixed =3D two PW > >In our example, PE1 to PE3 would be mixed to leaf-only (one PW) in one >direction, and leaf-only to mixed (one PW) in the other, so I was mistaken >in my original depiction, and you are correct, it should be only one PW. >It would just be the mixed -> mixed where broadcast would be duplicated. >Also consider this list of scenarios, the only times that we have to >deviate from the typical 'any to any' VPLS is in the Leaf-only to >Leaf-only, and Mixed to Mixed PW's. All others are a single PW. >[/JR] > >> >> - frame from R1 enters PE1, which decides to flood out both 'root' PW >>and 'leaf' PW to PE2, which in turn floods out the same AC types, based >>on >>arriving PW type. It also arrives at PE3 where it is forwarded to all >>root AC's. >> >>[JY] It contradicts your first statement that "there is no PW built to >>the PE which has no root AC's". >[JR] Sorry, I got confused on my only topology and was thinking PE3 was >root-only. Frame would arrive at PE3 (on the root-sourced PW) where it >would forward to all AC's. Sorry I botched the explanation, I hope the >idea was not lost in the confusion. > > >> >>I suppose optimization could be done on the ingress PE to decide that >>there is no need to 'flood' root-sourced frames to two PW's that have the >>same egress PE, but instead to only forward to the 'root' type PW, when >>both exist, because we know that the egress PE will flood frames from >>root-sourced PW's out both leaf and root AC's. >> >>In this example, the same frame from R1 is duplicated on the PE1-PE2 path >>(if no optimization is done.), where it would not be with the 2VLAN >>method. >> >>With 2VLAN, ethernet type PW's cannot be used (must be vlan type PW's, >>otherwise how would we classify source AC-type?), which means there is >>overhead on EVERY frame to add the s-tag for the sole purpose of >>classifying the frame. If optimization is done, then each ingress PE >>knows what types of AC's are on each egress PE, and only forwards the >>appropriate frame, if no optimization then it is dropped at the egress >>PE. >> >>In short, both are either not 100% inefficient, or are additionally >>complex due to 'optimization'. >> >>I may have gotten my details off on the optimization piece of the 2VLAN >>method, please correct me if I didn't get the details 100% correct. >> >> >>-Josh >> >> >> >>On 5/6/12 9:07 PM, "Jiangyuanlong" wrote: >> >>>Could you or any other co-authors of 2PW give some more hints so that it >>>can be better understood? >>> >>>In draft-ram-l2vpn-etree-multiple-pw-01, I can only find a single >>>sentence most to the point: >>> "An egress PE SHALL NOT deliver a frame originated at a leaf AC to >>> another leaf AC." >>> >>>But it seems there is not a description of "traffic is split/separated >>>(by psuedowire) on the ingress PE" at all. >>> >>>On the contrary, in draft-jiang-l2vpn-vpls-pe-etree-05, Section 5.3.3 >>>details the scenario and forwarding plane how the leaf traffic is >>>seperated and filtered on the ingress PE, and Section 6 details the >>>specific supports in the control plane. >>> >>>Thanks >>>Yuanlong >>> >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Friday, May 04, 2012 8:27 PM >>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>(Wim); Lucy yong >>>Cc: l2vpn@ietf.org >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>>also separate the leaf traffic in the ingress PE and filter it there >>>(already detailed in the Optimization Mode in the I-D); if the egress PE >>>is attached with pure roots or with both roots and leafs, it seems all >>>traffic must be transported to the egress PE and be filtered there, I >>>see >>>no difference in behaviour for these solutions. Or did I miss something? >>> >>> >>>The point is with the multi-PW method the traffic is split/separated (by >>>psuedowire) on the ingress PE, rather than the egress. The distinction >>>is >>>2VLAN will 'classify' the frame on the ingress PE, so that the egress PE >>>knows how to forward it to the appropriate AC's. >>> >>>Both methods have inefficiencies (one duplicates traffic for transport, >>>while the other transports where it doesn't need to go). I like the >>>idea >>>of classify and forwarding on the ingress PE, rather than marking it on >>>the ingress, and deciding on the egress. >>> >>>-Josh >>> >>> >>> >>>On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: >>> >>>>Josh, thank you for the comments, please see my further comments with >>>>[JY2]. >>>> >>>>-----Original Message----- >>>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>>Sent: Thursday, May 03, 2012 11:27 PM >>>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>>(Wim); Lucy yong >>>>Cc: l2vpn@ietf.org >>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>> >>>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>>requirements from MEF, it has nothing to do with the solutions. Could >>>>you >>>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>>if >>>>configuring or signalling two PWs is not a problem, why configuring or >>>>signalling two VLANs will become a problem? After all, more nodes may >>>>need >>>>to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >>>>2VLAN (only T-PEs). >>>> >>>> >>>>There is no other way (if both MPLS domains are part of the same ETREE, >>>>rather than doing something more like H-VPLS, where one domain has >>>>point >>>>to points to the other domain which handles the ETREE instance) if you >>>>are >>>>using an ENNI. The other method, (not mentioned earlier) is tying the >>>>two >>>>MPLS domains together via labeled unicast (much preferred over E-NNI in >>>>my >>>>opinion) >>>> >>>>Configuring two VLAN's isn't really a 'problem' any more than two PW's. >>>>I >>>>wasn't saying that configuring two VLAN's was difficult, I was >>>>objecting >>>>to the statement that configuring two PW's is difficult. >>>> >>>>[JY2] Thanks, I see your point. I take the example of 2PW configuration >>>>just to show that using fixed global values to simplify configuration >>>>makes no sense. Personally I also don't think configuration is a >>>>problem >>>>for both solutions. >>>> >>>>I find the differences between these two methods rather slight. The >>>>'tie-breaker' for me is by placing the forwarding decision on the >>>>ingress >>>>PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you >>>>get >>>>more control over where the traffic goes, and in my mind it provides a >>>>cleaner destination between customer traffic and forwarding plane. I'm >>>>accustomed to looking at a psuedowire and knowing where its going, with >>>>the 2vlan method, I can see the psuedowire, but must go to the egress >>>>PE >>>>to see if it will be dropped there, or forwarded to one or more AC's. >>>> >>>>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>>>also separate the leaf traffic in the ingress PE and filter it there >>>>(already detailed in the Optimization Mode in the I-D); if the egress >>>>PE >>>>is attached with pure roots or with both roots and leafs, it seems all >>>>traffic must be transported to the egress PE and be filtered there, I >>>>see >>>>no difference in behaviour for these solutions. Or did I miss >>>>something? >>>> >>>>Again, the difference here is slight, and I would honestly be happy to >>>>see >>>>either of them come to fruition. Please don't infer that I think the >>>>2vlan method is 'bad' or has intrinsic problems, because I don't >>>>believe >>>>that. I just prefer the multi-PW method. >>>> >>>> >>>>-Josh >>>> >>>> >>>>On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: >>>> >>>>>Josh, please see my comments in line. >>>>> >>>>>Thanks >>>>>Yuanlong >>>>> >>>>>-----Original Message----- >>>>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>>>Sent: Thursday, May 03, 2012 10:51 AM >>>>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>>>(Wim); Lucy yong >>>>>Cc: l2vpn@ietf.org >>>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>>> >>>>>Yuanlong, >>>>> >>>>>Or better yet, include in the draft a 'standard' value for root >>>>>sourced >>>>>VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You would = also >>>>>have to require the the implementation NOT use global VLAN's, however >>>>>(since each instance would be using the same values). In this way, no >>>>>signaling or manual configuration is required for remote PE's to know >>>>>how >>>>>to classify traffic. >>>>>[JY] Indeed, we discussed this possibility during the f2f meeting in >>>>>Paris. But, there are some restrictions as you mentioned, and >>>>>furthermore: >>>>>1) Some vendors already used S-VLAN to distinguish their VSIs in the >>>>>PE; >>>>>2) Forwarding plane of a PE needs to be revised to be aware of this >>>>>VLAN >>>>>ID. >>>>>Therefore, this 'standard value' approach seems more disruptive >>>>>compared >>>>>with the other means and not a good candidate option. >>>>> >>>>>Regarding switching PE's=A9 Multi-PW means more than one PW, yes. I >>>>>don't >>>>>see this as a real problem. In general, design should try and avoid >>>>>using >>>>>S-PE's, but if you must, its going to mean extra work, no matter how >>>>>you >>>>>look at it. Two PW's for each Etree being switched instead of one is >>>>>not >>>>>alarming or concerning to me. On the other hand, if you use a dot1q >>>>>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's >>>>>an >>>>>two egress VLAN's if you want the Etree to be handled on both sides >>>>>(and >>>>>if you use the 'standard' VID's as I mentioned above, you'd have to do >>>>>mapping to non-standard and back) >>>>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>>>requirements from MEF, it has nothing to do with the solutions. Could >>>>>you >>>>>give a hint on how you can provision this service E-NNI otherwise? >>>>>BTW, >>>>>if configuring or signalling two PWs is not a problem, why configuring >>>>>or >>>>>signalling two VLANs will become a problem? After all, more nodes may >>>>>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>>>>with 2VLAN (only T-PEs). >>>>> >>>>>In general, I still prefer multi-PW, primarily because I prefer the >>>>>separation of the traffic in the network's forwarding plane, rather >>>>>than >>>>>shipping it everywhere and deciding whether to forward to the AC when >>>>>it >>>>>gets to the egress PE. I'm having a hard time putting my finger >>>>>exactly >>>>>on what it is, or articulating the idea, but it seems that by having >>>>>the >>>>>traffic placed into two psuedowires, I have more flexibility and ease >>>>>of >>>>>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>>>>H-VPLS (both psuedowire based and vlan based). Of course my 'ease >>>>>of >>>>>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>>>>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>>>>PW's could really change that perception. >>>>>[JY] Are you saying that we need to develop a totally new forwarding >>>>>plane rather than using the Ethernet forwarding plane as described in >>>>>the >>>>>existing work? >>>>> >>>>>I hope we can move forward with one of these soon, >>>>>[JY] me too. >>>>> >>>>>Josh >>>>> >>>>> >>>>>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >>>>> >>>>>>Daniel, >>>>>> >>>>>>Not aware that we had a discussion on this before, but IMHO the >>>>>>allocation of internal S-VLAN can be automatic, and manuel >>>>>>configuration >>>>>>of this mapping may not be needed at all. For example, an S-VLAN >>>>>>allocation module in the management plane in a PE can do this kind of >>>>>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>>>>single external S-VLAN ID) in a topdown, bottom-up, or just any >>>>>>random >>>>>>way from a free S-VLAN ID pool. Once the interal S-VLANs are >>>>>>allocated, >>>>>>the mapping is determined and no other configuration is needed. >>>>>> >>>>>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>>>>allocate >>>>>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to >>>>>>allocate >>>>>>two S-VLANs in the VPLS domain. >>>>>> >>>>>>On the other hand, for the multi-PW approach, two PWs need to be >>>>>>configured for a E-Tree service. When MS-PW is used in the network, >>>>>>for >>>>>>every S-PE, we need to configure two ingress PW segments and two >>>>>>egress >>>>>>PW segments. In this case, I don't think we need to use fixed PW >>>>>>labels >>>>>>across the network for fear of configuration complexity. >>>>>> >>>>>>Regards, >>>>>>Yuanlong >>>>>> >>>>>>-----Original Message----- >>>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>>Sent: Wednesday, May 02, 2012 8:01 PM >>>>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>>yong; >>>>>>josh.rogers@twcable.com >>>>>>Cc: l2vpn@ietf.org >>>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>>> >>>>>>Inline. >>>>>> >>>>>>-----Original Message----- >>>>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>>>Sent: Wednesday, May 02, 2012 12:30 PM >>>>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>>yong; >>>>>>josh.rogers@twcable.com >>>>>>Cc: l2vpn@ietf.org >>>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>>> >>>>>>Hi Daniel, Please see my comments in line. >>>>>> >>>>>> >>>>>>-----Original Message----- >>>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>>Sent: Wednesday, May 02, 2012 3:55 PM >>>>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>>yong; josh.rogers@twcable.com >>>>>>Cc: l2vpn@ietf.org >>>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>>> >>>>>>Hi Yuanlong, >>>>>> >>>>>>The problem is not with the total number of S-VLAN IDs, I agree that >>>>>>normally there won't be more than 2047. The problem is that if you >>>>>>don't >>>>>>support all VLAN IDs, you need S-VLAN space coordination with the >>>>>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to >>>>>>2047". >>>>>>Which won't always be in line with an existing deployment. >>>>>>[JY] This is not the case. If the total number is no more than 2047, >>>>>>it >>>>>>surely can be supported. The S-VLAN space of user domain is totally >>>>>>different from the S-VLAN in the provider domain and they can be >>>>>>overlapped, I don't see why we need S-VLAN space coordination between >>>>>>them. >>>>>> >>>>>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>>>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>>>>fixed, and therefore the IEEE S-VID that can be supported is also >>>>>>fixed. >>>>>> >>>>>>Of course you can configure the mapping in each PE according to >>>>>>operator >>>>>>requirements but as we discussed before this increases complexity. >>>>>> >>>>>>Relying on PBB-VPLS imposes additional limitations on backward >>>>>>compatibility. >>>>>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>>>>think they may well need MAC-in-MAC in their networks for the >>>>>>scalability issue. As you know, only PBB VPLS can provide both. >>>>>> >>>>>>Daniel >>>>>> >>>>>>-----Original Message----- >>>>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>>>Sent: Wednesday, May 02, 2012 5:07 AM >>>>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>>yong; >>>>>>josh.rogers@twcable.com >>>>>>Cc: l2vpn@ietf.org >>>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>>> >>>>>>Hi Daniel, >>>>>> >>>>>>As you can see, both cases are discussed in the I-D. >>>>>> >>>>>>With regard to case 1) (that is, S-VLAN translation), since the >>>>>>access >>>>>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>>>>they need to be configured on a PE anyway, and as the past emails by >>>>>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by >>>>>>1:1 >>>>>>mapping. >>>>>> >>>>>>With regard to S-VID space reduction, the constraint is valid only >>>>>>when >>>>>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>>>>typical and with no such limits as we already discussed in the f2f >>>>>>meeting. >>>>>> >>>>>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>>>>described (not sure this is a valid use case in real life), PBB-VPLS >>>>>>can >>>>>>still be used. >>>>>> >>>>>>Regards, >>>>>>Yuanlong >>>>>> >>>>>>-----Original Message----- >>>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>>Sent: Monday, April 30, 2012 10:34 PM >>>>>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>>>Jiangyuanlong; josh.rogers@twcable.com >>>>>>Cc: l2vpn@ietf.org >>>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>>> >>>>>>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] >>>>>>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 >>>>>> >>>>>>--------------------------------------------------------------------- >>>>>>- >>>>> >>>>> >>>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>>proprietary information, which is privileged, confidential, or subject >>>>>to >>>>>copyright belonging to Time Warner Cable. This E-mail is intended >>>>>solely >>>>>for the use of the individual or entity to which it is addressed. If >>>>>you >>>>>are not the intended recipient of this E-mail, you are hereby notified >>>>>that any dissemination, distribution, copying, or action taken in >>>>>relation to the contents of and attachments to this E-mail is strictly >>>>>prohibited and may be unlawful. If you have received this 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 and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject to >>copyright belonging to Time Warner Cable. This E-mail is intended solely >>for the use of the individual or entity to which it is addressed. If you >>are not the intended recipient of this E-mail, you are hereby notified >>that any dissemination, distribution, copying, or action taken in >>relation to the contents of and attachments to this E-mail is strictly >>prohibited and may be unlawful. If you have received this 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 aldrin.isaac@gmail.com Mon May 7 20:59: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 A79A721F8476 for ; Mon, 7 May 2012 20:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s+H0GJt2yTD1 for ; Mon, 7 May 2012 20:59:49 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 62B6021F842C for ; Mon, 7 May 2012 20:59:49 -0700 (PDT) Received: by qadz3 with SMTP id z3so186393qad.10 for ; Mon, 07 May 2012 20:59:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=xRr4D3NBttzYi29RKK5xSN8M301DZ5AljlcrRyQWHlM=; b=r1Kyvkx6onLeVvBmTmFBYJNkcGxC351idyQKEg8No7L9al65fhP4QmWk+d+gyW1rma xLJUbHKSQ8PM9XZSIbQveu0oDYmyM88s3hULioe+AWdsKtJ/YzFX0N97MxLdZkg7xDAJ /hixmMPW+LZf13aqvHpQj9PhnXMi17o5U0ZPzt84SfdWoBZov/xYprZ3mRCWwSryOpJs WY9YDJ7yRHWsbkra854uzGQlHb26HxGAoeA2tzGB5Q9u8EnSVaX0KRS88AjUte+ch4g5 OzMq07AbY0L/ywVjIn1rc8CDR6xsnx5xSUoGWVh776xxStro4FKyrU8TQFWGTdskaY6D LpUA== Received: by 10.229.69.80 with SMTP id y16mr8442303qci.153.1336449588848; Mon, 07 May 2012 20:59:48 -0700 (PDT) Received: from mymac.home (ool-435396f4.dyn.optonline.net. [67.83.150.244]) by mx.google.com with ESMTPS id dv1sm1778035qab.22.2012.05.07.20.59.46 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 May 2012 20:59:47 -0700 (PDT) Subject: Re: Interest in IS-IS VPLS Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Aldrin Isaac In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D330F0566@dfweml506-mbx> Date: Mon, 7 May 2012 23:59:45 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2691CE0099834E4A9C5044EEC662BB9D330E8F11@dfweml505-mbx> <2E819CEF-4A49-439B-86DF-C17503A75398@gmail.com> <2691CE0099834E4A9C5044EEC662BB9D330E918C@dfweml505-mbx> <03B0FD5F-D9F5-4C4E-A7FD-0A2C36A7B092@gmail.com> <2691CE0099834E4A9C5044EEC662BB9D330F0566@dfweml506-mbx> To: Lucy yong X-Mailer: Apple Mail (2.1257) Cc: "l2vpn@ietf.org" , sajassi 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, 08 May 2012 03:59:50 -0000 Hi Lucy, see in line. On May 7, 2012, at 11:19 AM, Lucy yong wrote: > Hi Aldrin, >=20 > Thank you very for sharing your insight. It is great and very helpful. = It is fine to add new service features on existing services. In fact, = that is what we are working on in IETF. =20 >=20 > =46rom customer perspective, E-VPN supports all existing VPLS = capability and add active-active mode and some policy based-topology = control. It is useful extension. SPT based LAN is the history = technology. LAG, MSTP, TRILL, SPB etc are all the replacement solutions.=20= >=20 > One thing that I am not clear from your reply is that the policy for = L2VPN is to be against VLAN or MAC? > The latter will be very complex and not scale. The former will have = some additional challenges and complex because VLAN ID may not be global = based ID like IP addresses and L2VPN forwarding is based on MAC address = while policy control is based on VLAN. Do I understand this right? Policy is applied to the EVI (VRF) table which applies to all route = types in the table. An EVI can have a single link or be shared by = multiple links. The tag with which a packet arrives into the network = does not have to be the tag with which it leaves the network. I.e. = destination tag and ingress tag are decoupled in EVPN. > IMO: simplification is also important work for IETF and benefit to = businesses as silicon technology improving. Without it, we have some = limited room for adding new useful features and the system will be = overly complex so nobody can afford operating it. This does not say = E-VPN. For operators who want simplicity, they can get this easily by moving = compute/storage to hypervisors and buying an overlay solution -- it's = available today commercial or free. It's the cheapest and easiest to = implement out of the box with little to no knowledge of networking = protocols. I'm observing sysadmin and security guys set this up today = (literally). > Thanks again. >=20 > Lucy >=20 >=20 >=20 >=20 > -----Original Message----- > From: Aldrin Isaac [mailto:aldrin.isaac@gmail.com]=20 > Sent: Friday, May 04, 2012 7:20 PM > To: Lucy yong > Cc: sajassi; Giles Heron; Nabil Bitar; l2vpn@ietf.org > Subject: Re: Interest in IS-IS VPLS >=20 > Hi Lucy, >=20 > Please see inline >=20 > On May 4, 2012, at 11:07 AM, Lucy yong wrote: >=20 >> Hi Isaac, >>=20 >> Thank you for the reply. Please see inline. >>=20 >> Regards, >> Lucy >>=20 >> -----Original Message----- >> From: Aldrin Isaac [mailto:aldrin.isaac@gmail.com]=20 >> Sent: Thursday, May 03, 2012 10:50 PM >> To: Lucy yong >> Cc: sajassi; Giles Heron; Nabil Bitar; l2vpn@ietf.org >> Subject: Re: Interest in IS-IS VPLS >>=20 >=20 > ...=20 >=20 >> E-VPN also supports policy based-topologies versus simple = point-to-point, flat or tree VLANs. It can support point-to-point, = tree, mesh, one-way, or pretty much any other "complex" or overlapped = topologies (depending on how you like to see it). An example is ability = to natively recreate private vlan, community vlan topologies (which = happen to be quite common in DC networks) and any number of combinations = of these simultaneously to a single port. A BGP E-VPN VPN is also = decoupled from the edge EVI/ESI such that it is not limited to a single = tenant/vlan but can span tenants/vlans (l2 extranet) if so required. = This is native to E-VPN. >> [[LY]] Such policy based-topologies are useful for service provider = network, but may too complex for intra DCs. One reason that customers = often want to choose with L2VPN service is "it is simple". However, = L3VPN have its applications although some operators often complain the = complexities to configure these policies. Typical example is the a = firewall only placed at a location. Could you share why operator want = such policy based-topology for L2VPN? >=20 > Policy-based topologies are generally complex when used to = interconnect IP networks because there are generally multiple prefixes = in a vrf, and often different prefixes need to be associated to = different VPNs or routing behavior. In the DC, L2VPN role is to = interconnect host ports so the policies for basic are very simple --- = list of import route targets and list of export route targets where each = import/export pair correspond to a VPN (tenant, service, ...). An = example of how a DC operator might use this for example is to meet a = requirement for private vlan and community vlans which are very common = for DMZs. Hopefully you are familiar with these very common use cases. = It is even possible to recreate more complex switch "features" like MVR = (in addition to private VLANs which are also considered "features") = using E-VPN. It took me three years to get the MVR feature into a = particular vendor's switch to meet a business need. I'll sacrifice = plug-and-play simplicity for business agility. I'm sure my peers are = with me on this one. >=20 > If simple "plug-and-play" is important, one could imagine RRs sending = out an "RR TLV" such that RRs in an IGP area auto-connect with each = other and RR-clients connect to the closest RR based on SPF (some = details like peer-group, etc would need to be factored in to make it = more powerful). Other BGP/MPLS configuration is, IMHO, trivial unless = you CHOOSE to use more advanced capabilities (i.e. not locked in). =20 >=20 > Maybe the reason why MPLS comes across as complex is because of how = IETF deals with requirements lately by creating point solutions. E-VPN = tries to put new capabilities on the table while trying not to take = existing value off the table. There is no reason why a solution can't = bring more value than what the standards body calls for. >=20 >> E-VPN supports interconnecting end-stations or interconnecting L2 = networks. Procedures to easily span STP based networks across an E-VPN = network without loops comes with the base spec. Extensions to E-VPN, = such as PBB-EVPN, simplify the fully functional spanning of non-EVPN = networks across an E-VPN network. >> [[LY]] current L2VPN support all these except active-active mode = which causes the loop. >=20 > Base E-VPN spec will natively deal with the STP case through an = active/standby mode and BPDU-snooping -- detect root bridge and use that = as ESI (ethernet segment id) to indicate unique STP network with = active/standby bit set to ensure only one forwarding link among links = with same ESI. Tags (vlans) can potentially each have a different = active link within the member links of an ESI allowing for automatic = tag(tenant)/vlan level load-balancing into an STP network. Edge = networks that don't have mac-move issue will be able to take full = advantage of active-active load-balancing without need for LAG/MLAG. >=20 >> An SVI/IRB interface can also be a member of both an E-VPN EVI and an = IP VRF allowing for easily bringing together virtual L2 and L3 = topologies anywhere in the network without a physical port. >> [[LY]] Could you please share how operator plan to use this? Which = service will you sell to customer in this case? >=20 > The service will be where a customer wants to communicate to a = destination network that is not in his subnet. Operators most = interested in EVPN already have IPVPN services on their network. This = is the gateway point between the EVPN virtual networks and [existing] = IPVPN virtual networks. No physical port required. >=20 >> E-VPN builds on top of years of work in the IETF; traffic = engineering, scaling with route reflectors and RT constrain, multicast = via NG-MVPN, etc. >> [[LY]] Agree. These are useful features for service provider network. = However, these functions may not necessary within DC although they had = been proved works well.=20 >=20 > I'm not sure how eventually re-inventing these capabilities (yes it = will happen) on behalf of a new protocol will be better than simply = leveraging proven technology. Vendors don't need to implement every = MPLS RFC ever written to be able to implement the basic E-VPN. >=20 >> Can also use IP for transport tunnel. But my understanding is that = popular merchant silicon has support for MPLS push/pop/swap these days = (?). This was captured by EVPN at it's inception, which is why the PE = is referred to as MES (MPLS-enabled switch) in E-VPN. >> [[LY]] Yes, current draft aims on MPLS solution only. But it states = the potential to extend to the use of IP tunnel.=20 >> The way I see it, a major reason why STP-based LANS are fickle and = don't scale well is on account of insufficient decoupling of core from = edge created by requirement for plug-and-play and how that played out = over time. Conversely the reason (among other things) why IP networks = are more stable is because they are not inherently plug-and-play, and = with MPLS/BGP allows excellent decoupling of core and edge. I don't = know enough about TRILL or PBB to comment on those -- I just know that = I'm not interested for enough good reasons. E-VPN enables a dynamic = edge over a stable decoupled core while giving each operator room for = service differentiation. It is especially interesting to operators that = have invested in MPLS technology and operations. I can find a lot of = folks that understand BGP/MPLS IPVPN and in short order have them know = the ins and outs of basic E-VPN. It's quite hard for me to find = non-vendor folk who really actually understand the other technologies = used to span Ethernet aside from basic STP.=20 >=20 >> [[LY]] Thank you to share this in the mailing list.=20 >>=20 >> This is an operator perspective. >> [[LY]] This is great! >>=20 >>=20 >> On May 3, 2012, at 4:31 PM, Lucy yong wrote: >>=20 >>> Hi Ali, >>>=20 >>>=20 >>> "5. Ethernet VPN (E-VPN) - An enhanced Layer-2 service that >>> emulates an Ethernet (V)LAN across a PSN. E-VPN supports >>> load-sharing across multiple connections from a Layer-2 site >>> to an L2VPN service. E-VPN is primarily targeted to support >>> large-scale L2VPNs with resiliency requirements not satisfied >>> by other L2VPN solutions" >>>=20 >>> [[LY]] IMO, E-VPN enhancement is to support multi-homing with = active-active mode. Load-sharing across multiple connections from a = layer-2 site is desired when this mode is used. Current VPLS can provide = resiliency requirement when the multi-homing site configured with = active-standby mode. >>>=20 >>> Regards, >>> Lucy >>>=20 >>> Cheers, >>> Ali =20 >>>=20 >>=20 >=20 From aldrin.isaac@gmail.com Mon May 7 21:04: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 C64A421F849A for ; Mon, 7 May 2012 21:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eiI9NEPDt-iq for ; Mon, 7 May 2012 21:04:37 -0700 (PDT) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by ietfa.amsl.com (Postfix) with ESMTP id 7970921F84CD for ; Mon, 7 May 2012 21:04:37 -0700 (PDT) Received: by qabj40 with SMTP id j40so223128qab.15 for ; Mon, 07 May 2012 21:04:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=+KZg0MvlTafhadmHo1uaB0tv5TeVT0bRyMriVa3aN1U=; b=VfPXK4xYyE82qqwdnJYmqcZQ+i43LcikPeMWGTICkSeIF2MH5jDXYg+fReQcrnXXPv GLlVBeh2e8udVSW5CAkr9YnkIRhjwd+AK++0M/ijYX6xzbCJ8qohb2p0rgz41G1iLSMQ gf8MMRmLC54J4OAPXnfGu5kn+USNy8IHfrrks9CFXGqCYEQ1V3SG83tqMpKSorkh425q TNUzEvo3b4Q4Aq225ziu4MOkpT3+1kL15X9IxAxDUa+FtWFQEqbG1gOrTlS6uzk8hiH+ DitHX2De9aMKJzvJN58YLJomG9ZCtEICW0tkpPzvhbnjJdOrVIo0OWk+ETgHHr0nB85i RIcg== Received: by 10.224.182.75 with SMTP id cb11mr19742320qab.26.1336449877035; Mon, 07 May 2012 21:04:37 -0700 (PDT) Received: from mymac.home (ool-435396f4.dyn.optonline.net. [67.83.150.244]) by mx.google.com with ESMTPS id s20sm1806178qap.16.2012.05.07.21.04.35 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 May 2012 21:04:36 -0700 (PDT) Subject: Re: Interest in IS-IS VPLS Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Aldrin Isaac In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F633918DFE@dfweml505-mbx> Date: Tue, 8 May 2012 00:04:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2691CE0099834E4A9C5044EEC662BB9D330E8F11@dfweml505-mbx> <2E819CEF-4A49-439B-86DF-C17503A75398@gmail.com> <2691CE0099834E4A9C5044EEC662BB9D330E918C@dfweml505-mbx> <03B0FD5F-D9F5-4C4E-A7FD-0A2C36A7B092@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F633918DFE@dfweml505-mbx> To: Linda Dunbar X-Mailer: Apple Mail (2.1257) Cc: "l2vpn@ietf.org" , sajassi 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, 08 May 2012 04:04:38 -0000 Linda, Let me give a simple example. If you have a DMZ with a public /24 = address and you want to share that DMZ (one pair of firewalls to the = Internet) with multiple different classes of applications that you want = to keep isolated from each other. Within each class the computers can = communicate with each other and out to the Internet, but computers that = are of different classes cannot communicate with one another. -- aldrin On May 7, 2012, at 5:29 PM, Linda Dunbar wrote: > Adrin,=20 >=20 > You mentioned that " private vlan and community vlans which are very = common for DMZs in Data Center".=20 >=20 > I can totally understand why "private vlan" being used. But what = scenario will you need "community vlans" but can't be simply achieved by = traditional VLANs?=20 >=20 > Thanks, Linda=20 >=20 >=20 >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On = Behalf >> Of Aldrin Isaac >> Sent: Friday, May 04, 2012 7:20 PM >> To: Lucy yong >> Cc: l2vpn@ietf.org; sajassi >> Subject: Re: Interest in IS-IS VPLS >>=20 >> Hi Lucy, >>=20 >> Please see inline >>=20 >> On May 4, 2012, at 11:07 AM, Lucy yong wrote: >>=20 >>> Hi Isaac, >>>=20 >>> Thank you for the reply. Please see inline. >>>=20 >>> Regards, >>> Lucy >>>=20 >>> -----Original Message----- >>> From: Aldrin Isaac [mailto:aldrin.isaac@gmail.com] >>> Sent: Thursday, May 03, 2012 10:50 PM >>> To: Lucy yong >>> Cc: sajassi; Giles Heron; Nabil Bitar; l2vpn@ietf.org >>> Subject: Re: Interest in IS-IS VPLS >>>=20 >>=20 >> ... >>=20 >>> E-VPN also supports policy based-topologies versus simple point-to- >> point, flat or tree VLANs. It can support point-to-point, tree, = mesh, >> one-way, or pretty much any other "complex" or overlapped topologies >> (depending on how you like to see it). An example is ability to >> natively recreate private vlan, community vlan topologies (which = happen >> to be quite common in DC networks) and any number of combinations of >> these simultaneously to a single port. A BGP E-VPN VPN is also >> decoupled from the edge EVI/ESI such that it is not limited to a = single >> tenant/vlan but can span tenants/vlans (l2 extranet) if so required. >> This is native to E-VPN. >>> [[LY]] Such policy based-topologies are useful for service provider >> network, but may too complex for intra DCs. One reason that customers >> often want to choose with L2VPN service is "it is simple". However, >> L3VPN have its applications although some operators often complain = the >> complexities to configure these policies. Typical example is the a >> firewall only placed at a location. Could you share why operator want >> such policy based-topology for L2VPN? >>=20 >> Policy-based topologies are generally complex when used to = interconnect >> IP networks because there are generally multiple prefixes in a vrf, = and >> often different prefixes need to be associated to different VPNs or >> routing behavior. In the DC, L2VPN role is to interconnect host = ports >> so the policies for basic are very simple --- list of import route >> targets and list of export route targets where each import/export = pair >> correspond to a VPN (tenant, service, ...). An example of how a DC >> operator might use this for example is to meet a requirement for >> private vlan and community vlans which are very common for DMZs. >> Hopefully you are familiar with these very common use cases. It is >> even possible to recreate more complex switch "features" like MVR (in >> addition to private VLANs which are also considered "features") using >> E-VPN. It took me three years to get the MVR feature into a = particular >> vendor's switch to meet a business need. I'll sacrifice = plug-and-play >> simplicity for business agility. I'm sure my peers are with me on = this >> one. >>=20 >> If simple "plug-and-play" is important, one could imagine RRs sending >> out an "RR TLV" such that RRs in an IGP area auto-connect with each >> other and RR-clients connect to the closest RR based on SPF (some >> details like peer-group, etc would need to be factored in to make it >> more powerful). Other BGP/MPLS configuration is, IMHO, trivial = unless >> you CHOOSE to use more advanced capabilities (i.e. not locked in). >>=20 >> Maybe the reason why MPLS comes across as complex is because of how >> IETF deals with requirements lately by creating point solutions. = E-VPN >> tries to put new capabilities on the table while trying not to take >> existing value off the table. There is no reason why a solution = can't >> bring more value than what the standards body calls for. >>=20 >>> E-VPN supports interconnecting end-stations or interconnecting L2 >> networks. Procedures to easily span STP based networks across an = E-VPN >> network without loops comes with the base spec. Extensions to E-VPN, >> such as PBB-EVPN, simplify the fully functional spanning of non-EVPN >> networks across an E-VPN network. >>> [[LY]] current L2VPN support all these except active-active mode >> which causes the loop. >>=20 >> Base E-VPN spec will natively deal with the STP case through an >> active/standby mode and BPDU-snooping -- detect root bridge and use >> that as ESI (ethernet segment id) to indicate unique STP network with >> active/standby bit set to ensure only one forwarding link among links >> with same ESI. Tags (vlans) can potentially each have a different >> active link within the member links of an ESI allowing for automatic >> tag(tenant)/vlan level load-balancing into an STP network. Edge >> networks that don't have mac-move issue will be able to take full >> advantage of active-active load-balancing without need for LAG/MLAG. >>=20 >>> An SVI/IRB interface can also be a member of both an E-VPN EVI and = an >> IP VRF allowing for easily bringing together virtual L2 and L3 >> topologies anywhere in the network without a physical port. >>> [[LY]] Could you please share how operator plan to use this? Which >> service will you sell to customer in this case? >>=20 >> The service will be where a customer wants to communicate to a >> destination network that is not in his subnet. Operators most >> interested in EVPN already have IPVPN services on their network. = This >> is the gateway point between the EVPN virtual networks and [existing] >> IPVPN virtual networks. No physical port required. >>=20 >>> E-VPN builds on top of years of work in the IETF; traffic = engineering, >> scaling with route reflectors and RT constrain, multicast via = NG-MVPN, >> etc. >>> [[LY]] Agree. These are useful features for service provider = network. >> However, these functions may not necessary within DC although they = had >> been proved works well. >>=20 >> I'm not sure how eventually re-inventing these capabilities (yes it >> will happen) on behalf of a new protocol will be better than simply >> leveraging proven technology. Vendors don't need to implement every >> MPLS RFC ever written to be able to implement the basic E-VPN. >>=20 >>> Can also use IP for transport tunnel. But my understanding is that >> popular merchant silicon has support for MPLS push/pop/swap these = days >> (?). This was captured by EVPN at it's inception, which is why the = PE >> is referred to as MES (MPLS-enabled switch) in E-VPN. >>> [[LY]] Yes, current draft aims on MPLS solution only. But it states >> the potential to extend to the use of IP tunnel. >>> The way I see it, a major reason why STP-based LANS are fickle and >> don't scale well is on account of insufficient decoupling of core = from >> edge created by requirement for plug-and-play and how that played out >> over time. Conversely the reason (among other things) why IP = networks >> are more stable is because they are not inherently plug-and-play, and >> with MPLS/BGP allows excellent decoupling of core and edge. I don't >> know enough about TRILL or PBB to comment on those -- I just know = that >> I'm not interested for enough good reasons. E-VPN enables a dynamic >> edge over a stable decoupled core while giving each operator room for >> service differentiation. It is especially interesting to operators >> that have invested in MPLS technology and operations. I can find a = lot >> of folks that understand BGP/MPLS IPVPN and in short order have them >> know the ins and outs of basic E-VPN. It's quite hard for me to find >> non-vendor folk who really actually understand the other technologies >> used to span Ethernet aside from basic STP. >>=20 >>> [[LY]] Thank you to share this in the mailing list. >>>=20 >>> This is an operator perspective. >>> [[LY]] This is great! >>>=20 >>>=20 >>> On May 3, 2012, at 4:31 PM, Lucy yong wrote: >>>=20 >>>> Hi Ali, >>>>=20 >>>>=20 >>>> "5. Ethernet VPN (E-VPN) - An enhanced Layer-2 service that >>>> emulates an Ethernet (V)LAN across a PSN. E-VPN supports >>>> load-sharing across multiple connections from a Layer-2 site >>>> to an L2VPN service. E-VPN is primarily targeted to support >>>> large-scale L2VPNs with resiliency requirements not satisfied >>>> by other L2VPN solutions" >>>>=20 >>>> [[LY]] IMO, E-VPN enhancement is to support multi-homing with >> active-active mode. Load-sharing across multiple connections from a >> layer-2 site is desired when this mode is used. Current VPLS can >> provide resiliency requirement when the multi-homing site configured >> with active-standby mode. >>>>=20 >>>> Regards, >>>> Lucy >>>>=20 >>>> Cheers, >>>> Ali >>>>=20 >>>=20 >=20 From jiangyuanlong@huawei.com Mon May 7 21:07: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 8E36021F84B9 for ; Mon, 7 May 2012 21:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.145 X-Spam-Level: X-Spam-Status: No, score=-2.145 tagged_above=-999 required=5 tests=[AWL=-0.146, 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 CV3UhpIqH-40 for ; Mon, 7 May 2012 21:07:40 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id D4D8021F84C9 for ; Mon, 7 May 2012 21:07:39 -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 AFP51922; Tue, 08 May 2012 00:07:39 -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, 7 May 2012 21:04:39 -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, 7 May 2012 21:04:41 -0700 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.183]) by szxeml436-hub.china.huawei.com ([10.72.61.64]) with mapi id 14.01.0323.003; Tue, 8 May 2012 12:04:29 +0800 From: Jiangyuanlong To: "Rogers, Josh" , Lucy yong , Sam Cao , "l2vpn@ietf.org" Subject: RE: L2vpn Digest, Vol 96, Issue 15 Thread-Topic: L2vpn Digest, Vol 96, Issue 15 Thread-Index: AQHNKgNyPxr7nh+DX0S+AUfrSOoOpZa57ewAgARPYACAABdtgIAA8VnQ Date: Tue, 8 May 2012 04:04:27 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410ABC@szxeml546-mbx.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D330F0740@dfweml506-mbx> 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.73] 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: Tue, 08 May 2012 04:07:43 -0000 Josh,=20 Just some comments on this part: [JR] I don't see this any more of a problem than troubleshooting one. If LDP is used, a simple mols traceroute shows the path that ALL PW's to that PE take, regardless of which service (this VPLS or another VPLS instance). If RSVP is used, there should be a route-object that shows me the path, and allows me to troubleshoot. Additionally, if I wanted to have traffic engineering that impacted root-sourced and leaf-sourced traffic differently, I can do that with multi-PW, where I could not (save for ingress/egress) with the 2VLAN approach. PE should report signaling on second PW same as it does for the 100th PW between PE's. Again, I don't see the problem you are alluding to. I suppose you are referring to LSP Ping on the LSP layer, yes, it can overs= ee all the PWs in this LSP. If both root and leaf PW are in the same LSP, i= t can work. But there may well be multiple LSPs between a pair of PEs, and = root/leaf PW may be transported on different LSPs. Another difficulty is, i= f ECMP is deployed and PW label as a bottom label is used for hashing, the = OAM message may be load balanced on different paths. With regard to TE, you could use DS-TE, just as Lucy said, two PW do not gu= arantee they are traffic engineered. Thanks Yuanlong -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com]=20 Sent: Tuesday, May 08, 2012 5:22 AM To: Lucy yong; Sam Cao; l2vpn@ietf.org Cc: Jiangyuanlong Subject: Re: L2vpn Digest, Vol 96, Issue 15 Comments inline (and s/conquer/concur/) On 5/7/12 2:58 PM, "Lucy yong" wrote: >Sam, > >I concur with Yuanlong's reply on this. Please see inline. > >Lucy > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >Sam Cao >Sent: Friday, May 04, 2012 9:09 PM >To: l2vpn@ietf.org >Cc: Jiangyuanlong >Subject: RE: L2vpn Digest, Vol 96, Issue 15 > >Lucy/Yuanlong, > >I agree that we can not say which approach is better simply, but I really >agree with Josh's comments. Multi-PW is easy to implement E-Tree. >[[LY]] I don't get impression Josh state this. > >First of all, we discussed 2 approaches for a long time and many rounds, >and >for me, there are no pending issues on Multi-PW till now or co-authors of >multi-PW have given reasonable reply to L2VPN members' questions, but >there >are still pending issues for Dual-VLAN. Please trace the mailing list. >[[LY]] I interpret this as people want to spend time to finalize dual >VLAN solution. Multi-PW has some operation impact. How do operator to >maintain this service and be able to trouble shooting. How do you expect >traceroute work when using two PWs for one VPN? How do you expect PE >report when there is an error on one of two PWs? Do you have one FEC or >two FEC for a E-Tree in control plane? [JR] I don't see this any more of a problem than troubleshooting one. If LDP is used, a simple mols traceroute shows the path that ALL PW's to that PE take, regardless of which service (this VPLS or another VPLS instance). If RSVP is used, there should be a route-object that shows me the path, and allows me to troubleshoot. Additionally, if I wanted to have traffic engineering that impacted root-sourced and leaf-sourced traffic differently, I can do that with multi-PW, where I could not (save for ingress/egress) with the 2VLAN approach. PE should report signaling on second PW same as it does for the 100th PW between PE's. Again, I don't see the problem you are alluding to. > >Second, Sasha has his concern in NP, or forwarding performance. Compared >to >current VPLS, Multi-PW has a little effect on forwarding performance since >it reuse PW label as AC indicator; Dual-VLAN will have higher side effect >on >forwarding performance because it SHOULD use additional indicator. Is >there >one prototype for Dual-VLAN? BTW, there is no reply on chip limit. >[[LY]] in VPLS, PW label is used as VSI indicator, not AC. I disagree >your statement here. > >Third, the difference between Multi-PW and dual-VLAN is, transport ingress >traffic in one "LSP" or 2 "LSP". Multi-PW classifies and transforms >ingress >traffic into right "path", and egress just pop-out PW label and forward >the >frame to ACs. Dual-VLAN has more work on ingress PE or egress PE. >[[LY]] Don't understand the first part. When egress pop-out PW label, it >find corresponding VSI first, then perform MAC lookup associated to all >ACs. We can't assume there is one AC. > >Fourth, maybe Giles has figured this out, Dual-VLAN has capacity limit. >Only >4094 VLAN ID are available, so only 2K E-Tree instances can be supported >on >one PE for Dual-VLAN approach. There is no such limit for Multi-PW >approach, >[[LY]] If 4K VLAN ID is not an issue for VPLS, it is not an issue for >E-Tree. > >Finally, in this thread we don't make agreement on VLAN ID allocation. We >also have questions on VLAN ID negotiation among PEs (signaling protocol). >Yuanlong wishes to update, but there is no update till now. >[[LY]] This should not be the reason to judge on the solution. [JR] I tend to agree. > >For me, why IEEE uses VLAN ID to identify AC type? IEEE has no LABEL :), >and >it has label, it also wish to use label to identify AC types. I think that >both solutions need much time to be perfect. Mutli-PW has less extension >work to do. But now we are focusing on technical details and can not move >forward :). >[[LY]] VPN label is used for identify the VPN. It already has the >purpose. Overloading with other meaning has high potential causing a >problem. Hope you can investigate it more. Since you are very in favor of >multi-pw solution, it is not proper for you to come out the conclusion >which is better, because it is very biased. You are welcome to help on >completing either solution. [JR] this is humorous to me, because at one time, VLAN-ID was used to identify a single broadcast domain, and then later asymmetrical VID's were used to limit communication between endpoints of a broadcast domain (effectively creating two one-way broadcast domains, very similar to what we're accomplishing with ETREE). This should not be the reason to judge on the solution. > >Regards, >Lucy > >Lucy > >Thanks, > >Sam > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >l2vpn-request@ietf.org >Sent: Friday, May 04, 2012 10:31 PM >To: l2vpn@ietf.org >Subject: L2vpn Digest, Vol 96, Issue 15 > >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) > 2. Re: The status of the approaches to the E-Tree solution? > (Rogers, Josh) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Fri, 4 May 2012 14:16:36 +0000 >From: Lucy yong >To: "Rogers, Josh" , Jiangyuanlong > , Daniel Cohn , >"Fedyk, > Donald (Don)" , "Henderickx, Wim > (Wim)" >Cc: "l2vpn@ietf.org" >Subject: RE: The status of the approaches to the E-Tree solution? >Message-ID: <2691CE0099834E4A9C5044EEC662BB9D330E9114@dfweml505-mbx> >Content-Type: text/plain; charset=3D"iso-8859-2" > >Josh, > >You simply say that you don't like IEEE Tree solution. IEEE Tree solution >is >for ingress port to mark and for egress port to filter. > >Regards, >Lucy > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Friday, May 04, 2012 7:27 AM >To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >(Wim); >Lucy yong >Cc: l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >also separate the leaf traffic in the ingress PE and filter it there >(already detailed in the Optimization Mode in the I-D); if the egress PE >is attached with pure roots or with both roots and leafs, it seems all >traffic must be transported to the egress PE and be filtered there, I see >no difference in behaviour for these solutions. Or did I miss something? > > >The point is with the multi-PW method the traffic is split/separated (by >psuedowire) on the ingress PE, rather than the egress. The distinction is >2VLAN will 'classify' the frame on the ingress PE, so that the egress PE >knows how to forward it to the appropriate AC's. > >Both methods have inefficiencies (one duplicates traffic for transport, >while the other transports where it doesn't need to go). I like the idea >of classify and forwarding on the ingress PE, rather than marking it on >the ingress, and deciding on the egress. > >-Josh > > > >On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: > >>Josh, thank you for the comments, please see my further comments with >>[JY2]. >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Thursday, May 03, 2012 11:27 PM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>requirements from MEF, it has nothing to do with the solutions. Could you >>give a hint on how you can provision this service E-NNI otherwise? BTW, >>if >>configuring or signalling two PWs is not a problem, why configuring or >>signalling two VLANs will become a problem? After all, more nodes may >>need >>to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >>2VLAN (only T-PEs). >> >> >>There is no other way (if both MPLS domains are part of the same ETREE, >>rather than doing something more like H-VPLS, where one domain has point >>to points to the other domain which handles the ETREE instance) if you >>are >>using an ENNI. The other method, (not mentioned earlier) is tying the >>two >>MPLS domains together via labeled unicast (much preferred over E-NNI in >>my >>opinion) >> >>Configuring two VLAN's isn't really a 'problem' any more than two PW's. >>I >>wasn't saying that configuring two VLAN's was difficult, I was objecting >>to the statement that configuring two PW's is difficult. >> >>[JY2] Thanks, I see your point. I take the example of 2PW configuration >>just to show that using fixed global values to simplify configuration >>makes no sense. Personally I also don't think configuration is a problem >>for both solutions. >> >>I find the differences between these two methods rather slight. The >>'tie-breaker' for me is by placing the forwarding decision on the ingress >>PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >>more control over where the traffic goes, and in my mind it provides a >>cleaner destination between customer traffic and forwarding plane. I'm >>accustomed to looking at a psuedowire and knowing where its going, with >>the 2vlan method, I can see the psuedowire, but must go to the egress PE >>to see if it will be dropped there, or forwarded to one or more AC's. >> >>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>also separate the leaf traffic in the ingress PE and filter it there >>(already detailed in the Optimization Mode in the I-D); if the egress PE >>is attached with pure roots or with both roots and leafs, it seems all >>traffic must be transported to the egress PE and be filtered there, I see >>no difference in behaviour for these solutions. Or did I miss something? >> >>Again, the difference here is slight, and I would honestly be happy to >>see >>either of them come to fruition. Please don't infer that I think the >>2vlan method is 'bad' or has intrinsic problems, because I don't believe >>that. I just prefer the multi-PW method. >> >> >>-Josh >> >> >>On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: >> >>>Josh, please see my comments in line. >>> >>>Thanks >>>Yuanlong >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Thursday, May 03, 2012 10:51 AM >>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>(Wim); Lucy yong >>>Cc: l2vpn@ietf.org >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Yuanlong, >>> >>>Or better yet, include in the draft a 'standard' value for root sourced >>>VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You would al= so >>>have to require the the implementation NOT use global VLAN's, however >>>(since each instance would be using the same values). In this way, no >>>signaling or manual configuration is required for remote PE's to know >>>how >>>to classify traffic. >>>[JY] Indeed, we discussed this possibility during the f2f meeting in >>>Paris. But, there are some restrictions as you mentioned, and >>>furthermore: >>>1) Some vendors already used S-VLAN to distinguish their VSIs in the PE; >>>2) Forwarding plane of a PE needs to be revised to be aware of this VLAN >>>ID. >>>Therefore, this 'standard value' approach seems more disruptive compared >>>with the other means and not a good candidate option. >>> >>>Regarding switching PE's? Multi-PW means more than one PW, yes. I >>>don't >>>see this as a real problem. In general, design should try and avoid >>>using >>>S-PE's, but if you must, its going to mean extra work, no matter how you >>>look at it. Two PW's for each Etree being switched instead of one is >>>not >>>alarming or concerning to me. On the other hand, if you use a dot1q >>>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's >>>an >>>two egress VLAN's if you want the Etree to be handled on both sides (and >>>if you use the 'standard' VID's as I mentioned above, you'd have to do >>>mapping to non-standard and back) >>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>requirements from MEF, it has nothing to do with the solutions. Could >>>you >>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>if configuring or signalling two PWs is not a problem, why configuring >>>or >>>signalling two VLANs will become a problem? After all, more nodes may >>>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>>with 2VLAN (only T-PEs). >>> >>>In general, I still prefer multi-PW, primarily because I prefer the >>>separation of the traffic in the network's forwarding plane, rather than >>>shipping it everywhere and deciding whether to forward to the AC when it >>>gets to the egress PE. I'm having a hard time putting my finger exactly >>>on what it is, or articulating the idea, but it seems that by having the >>>traffic placed into two psuedowires, I have more flexibility and ease of >>>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>>PW's could really change that perception. >>>[JY] Are you saying that we need to develop a totally new forwarding >>>plane rather than using the Ethernet forwarding plane as described in >>>the >>>existing work? >>> >>>I hope we can move forward with one of these soon, >>>[JY] me too. >>> >>>Josh >>> >>> >>>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >>> >>>>Daniel, >>>> >>>>Not aware that we had a discussion on this before, but IMHO the >>>>allocation of internal S-VLAN can be automatic, and manuel >>>>configuration >>>>of this mapping may not be needed at all. For example, an S-VLAN >>>>allocation module in the management plane in a PE can do this kind of >>>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>>way from a free S-VLAN ID pool. Once the interal S-VLANs are allocated, >>>>the mapping is determined and no other configuration is needed. >>>> >>>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>>allocate >>>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to allocate >>>>two S-VLANs in the VPLS domain. >>>> >>>>On the other hand, for the multi-PW approach, two PWs need to be >>>>configured for a E-Tree service. When MS-PW is used in the network, for >>>>every S-PE, we need to configure two ingress PW segments and two egress >>>>PW segments. In this case, I don't think we need to use fixed PW labels >>>>across the network for fear of configuration complexity. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 8:01 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Inline. >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 12:30 PM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, Please see my comments in line. >>>> >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 3:55 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Yuanlong, >>>> >>>>The problem is not with the total number of S-VLAN IDs, I agree that >>>>normally there won't be more than 2047. The problem is that if you >>>>don't >>>>support all VLAN IDs, you need S-VLAN space coordination with the >>>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to >>>>2047". >>>>Which won't always be in line with an existing deployment. >>>>[JY] This is not the case. If the total number is no more than 2047, it >>>>surely can be supported. The S-VLAN space of user domain is totally >>>>different from the S-VLAN in the provider domain and they can be >>>>overlapped, I don't see why we need S-VLAN space coordination between >>>>them. >>>> >>>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>>fixed, and therefore the IEEE S-VID that can be supported is also >>>>fixed. >>>> >>>>Of course you can configure the mapping in each PE according to >>>>operator >>>>requirements but as we discussed before this increases complexity. >>>> >>>>Relying on PBB-VPLS imposes additional limitations on backward >>>>compatibility. >>>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>>think they may well need MAC-in-MAC in their networks for the >>>>scalability issue. As you know, only PBB VPLS can provide both. >>>> >>>>Daniel >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 5:07 AM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, >>>> >>>>As you can see, both cases are discussed in the I-D. >>>> >>>>With regard to case 1) (that is, S-VLAN translation), since the access >>>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>>they need to be configured on a PE anyway, and as the past emails by >>>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>>mapping. >>>> >>>>With regard to S-VID space reduction, the constraint is valid only when >>>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>>typical and with no such limits as we already discussed in the f2f >>>>meeting. >>>> >>>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>>described (not sure this is a valid use case in real life), PBB-VPLS >>>>can >>>>still be used. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Monday, April 30, 2012 10:34 PM >>>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>Jiangyuanlong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>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] >>>>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 >>>> >>>>---------------------------------------------------------------------- >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to >>>copyright belonging to Time Warner Cable. This E-mail is intended solely >>>for the use of the individual or entity to which it is addressed. If you >>>are not the intended recipient of this E-mail, you are hereby notified >>>that any dissemination, distribution, copying, or action taken in >>>relation to the contents of and attachments to this E-mail is strictly >>>prohibited and may be unlawful. If you have received this 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. > > >------------------------------ > >Message: 2 >Date: Fri, 4 May 2012 10:30:38 -0400 >From: "Rogers, Josh" >To: Lucy yong , Jiangyuanlong > , Daniel Cohn , >"Fedyk, > Donald (Don)" , "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"iso-8859-2" > >To be more accurate, I like it less than the multi-PW solution. I'd be >happy to use the 2VLAN solution in the real world, if it was ratified as >the standard. > > > >On 5/4/12 9:16 AM, "Lucy yong" wrote: > >>Josh, >> >>You simply say that you don't like IEEE Tree solution. IEEE Tree solution >>is for ingress port to mark and for egress port to filter. >> >>Regards, >>Lucy >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Friday, May 04, 2012 7:27 AM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>also separate the leaf traffic in the ingress PE and filter it there >>(already detailed in the Optimization Mode in the I-D); if the egress PE >>is attached with pure roots or with both roots and leafs, it seems all >>traffic must be transported to the egress PE and be filtered there, I see >>no difference in behaviour for these solutions. Or did I miss something? >> >> >>The point is with the multi-PW method the traffic is split/separated (by >>psuedowire) on the ingress PE, rather than the egress. The distinction >>is >>2VLAN will 'classify' the frame on the ingress PE, so that the egress PE >>knows how to forward it to the appropriate AC's. >> >>Both methods have inefficiencies (one duplicates traffic for transport, >>while the other transports where it doesn't need to go). I like the idea >>of classify and forwarding on the ingress PE, rather than marking it on >>the ingress, and deciding on the egress. >> >>-Josh >> >> >> >>On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: >> >>>Josh, thank you for the comments, please see my further comments with >>>[JY2]. >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Thursday, May 03, 2012 11:27 PM >>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>(Wim); Lucy yong >>>Cc: l2vpn@ietf.org >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>requirements from MEF, it has nothing to do with the solutions. Could >>>you >>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>if >>>configuring or signalling two PWs is not a problem, why configuring or >>>signalling two VLANs will become a problem? After all, more nodes may >>>need >>>to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >>>2VLAN (only T-PEs). >>> >>> >>>There is no other way (if both MPLS domains are part of the same ETREE, >>>rather than doing something more like H-VPLS, where one domain has point >>>to points to the other domain which handles the ETREE instance) if you >>>are >>>using an ENNI. The other method, (not mentioned earlier) is tying the >>>two >>>MPLS domains together via labeled unicast (much preferred over E-NNI in >>>my >>>opinion) >>> >>>Configuring two VLAN's isn't really a 'problem' any more than two PW's. >>>I >>>wasn't saying that configuring two VLAN's was difficult, I was objecting >>>to the statement that configuring two PW's is difficult. >>> >>>[JY2] Thanks, I see your point. I take the example of 2PW configuration >>>just to show that using fixed global values to simplify configuration >>>makes no sense. Personally I also don't think configuration is a problem >>>for both solutions. >>> >>>I find the differences between these two methods rather slight. The >>>'tie-breaker' for me is by placing the forwarding decision on the >>>ingress >>>PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >>>more control over where the traffic goes, and in my mind it provides a >>>cleaner destination between customer traffic and forwarding plane. I'm >>>accustomed to looking at a psuedowire and knowing where its going, with >>>the 2vlan method, I can see the psuedowire, but must go to the egress PE >>>to see if it will be dropped there, or forwarded to one or more AC's. >>> >>>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>>also separate the leaf traffic in the ingress PE and filter it there >>>(already detailed in the Optimization Mode in the I-D); if the egress PE >>>is attached with pure roots or with both roots and leafs, it seems all >>>traffic must be transported to the egress PE and be filtered there, I >>>see >>>no difference in behaviour for these solutions. Or did I miss something? >>> >>>Again, the difference here is slight, and I would honestly be happy to >>>see >>>either of them come to fruition. Please don't infer that I think the >>>2vlan method is 'bad' or has intrinsic problems, because I don't believe >>>that. I just prefer the multi-PW method. >>> >>> >>>-Josh >>> >>> >>>On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: >>> >>>>Josh, please see my comments in line. >>>> >>>>Thanks >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>>Sent: Thursday, May 03, 2012 10:51 AM >>>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>>(Wim); Lucy yong >>>>Cc: l2vpn@ietf.org >>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>> >>>>Yuanlong, >>>> >>>>Or better yet, include in the draft a 'standard' value for root sourced >>>>VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You would a= lso >>>>have to require the the implementation NOT use global VLAN's, however >>>>(since each instance would be using the same values). In this way, no >>>>signaling or manual configuration is required for remote PE's to know >>>>how >>>>to classify traffic. >>>>[JY] Indeed, we discussed this possibility during the f2f meeting in >>>>Paris. But, there are some restrictions as you mentioned, and >>>>furthermore: >>>>1) Some vendors already used S-VLAN to distinguish their VSIs in the >>>>PE; >>>>2) Forwarding plane of a PE needs to be revised to be aware of this >>>>VLAN >>>>ID. >>>>Therefore, this 'standard value' approach seems more disruptive >>>>compared >>>>with the other means and not a good candidate option. >>>> >>>>Regarding switching PE's? Multi-PW means more than one PW, yes. I >>>>don't >>>>see this as a real problem. In general, design should try and avoid >>>>using >>>>S-PE's, but if you must, its going to mean extra work, no matter how >>>>you >>>>look at it. Two PW's for each Etree being switched instead of one is >>>>not >>>>alarming or concerning to me. On the other hand, if you use a dot1q >>>>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's >>>>an >>>>two egress VLAN's if you want the Etree to be handled on both sides >>>>(and >>>>if you use the 'standard' VID's as I mentioned above, you'd have to do >>>>mapping to non-standard and back) >>>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>>requirements from MEF, it has nothing to do with the solutions. Could >>>>you >>>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>>if configuring or signalling two PWs is not a problem, why configuring >>>>or >>>>signalling two VLANs will become a problem? After all, more nodes may >>>>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>>>with 2VLAN (only T-PEs). >>>> >>>>In general, I still prefer multi-PW, primarily because I prefer the >>>>separation of the traffic in the network's forwarding plane, rather >>>>than >>>>shipping it everywhere and deciding whether to forward to the AC when >>>>it >>>>gets to the egress PE. I'm having a hard time putting my finger >>>>exactly >>>>on what it is, or articulating the idea, but it seems that by having >>>>the >>>>traffic placed into two psuedowires, I have more flexibility and ease >>>>of >>>>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>>>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>>>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>>>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>>>PW's could really change that perception. >>>>[JY] Are you saying that we need to develop a totally new forwarding >>>>plane rather than using the Ethernet forwarding plane as described in >>>>the >>>>existing work? >>>> >>>>I hope we can move forward with one of these soon, >>>>[JY] me too. >>>> >>>>Josh >>>> >>>> >>>>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >>>> >>>>>Daniel, >>>>> >>>>>Not aware that we had a discussion on this before, but IMHO the >>>>>allocation of internal S-VLAN can be automatic, and manuel >>>>>configuration >>>>>of this mapping may not be needed at all. For example, an S-VLAN >>>>>allocation module in the management plane in a PE can do this kind of >>>>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>>>way from a free S-VLAN ID pool. Once the interal S-VLANs are >>>>>allocated, >>>>>the mapping is determined and no other configuration is needed. >>>>> >>>>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>>>allocate >>>>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to >>>>>allocate >>>>>two S-VLANs in the VPLS domain. >>>>> >>>>>On the other hand, for the multi-PW approach, two PWs need to be >>>>>configured for a E-Tree service. When MS-PW is used in the network, >>>>>for >>>>>every S-PE, we need to configure two ingress PW segments and two >>>>>egress >>>>>PW segments. In this case, I don't think we need to use fixed PW >>>>>labels >>>>>across the network for fear of configuration complexity. >>>>> >>>>>Regards, >>>>>Yuanlong >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>Sent: Wednesday, May 02, 2012 8:01 PM >>>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; >>>>>josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Inline. >>>>> >>>>>-----Original Message----- >>>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>>Sent: Wednesday, May 02, 2012 12:30 PM >>>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; >>>>>josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Hi Daniel, Please see my comments in line. >>>>> >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>Sent: Wednesday, May 02, 2012 3:55 PM >>>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Hi Yuanlong, >>>>> >>>>>The problem is not with the total number of S-VLAN IDs, I agree that >>>>>normally there won't be more than 2047. The problem is that if you >>>>>don't >>>>>support all VLAN IDs, you need S-VLAN space coordination with the >>>>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to >>>>>2047". >>>>>Which won't always be in line with an existing deployment. >>>>>[JY] This is not the case. If the total number is no more than 2047, >>>>>it >>>>>surely can be supported. The S-VLAN space of user domain is totally >>>>>different from the S-VLAN in the provider domain and they can be >>>>>overlapped, I don't see why we need S-VLAN space coordination between >>>>>them. >>>>> >>>>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>>>fixed, and therefore the IEEE S-VID that can be supported is also >>>>>fixed. >>>>> >>>>>Of course you can configure the mapping in each PE according to >>>>>operator >>>>>requirements but as we discussed before this increases complexity. >>>>> >>>>>Relying on PBB-VPLS imposes additional limitations on backward >>>>>compatibility. >>>>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>>>think they may well need MAC-in-MAC in their networks for the >>>>>scalability issue. As you know, only PBB VPLS can provide both. >>>>> >>>>>Daniel >>>>> >>>>>-----Original Message----- >>>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>>Sent: Wednesday, May 02, 2012 5:07 AM >>>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; >>>>>josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Hi Daniel, >>>>> >>>>>As you can see, both cases are discussed in the I-D. >>>>> >>>>>With regard to case 1) (that is, S-VLAN translation), since the access >>>>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>>>they need to be configured on a PE anyway, and as the past emails by >>>>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>>>mapping. >>>>> >>>>>With regard to S-VID space reduction, the constraint is valid only >>>>>when >>>>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>>>typical and with no such limits as we already discussed in the f2f >>>>>meeting. >>>>> >>>>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>>>described (not sure this is a valid use case in real life), PBB-VPLS >>>>>can >>>>>still be used. >>>>> >>>>>Regards, >>>>>Yuanlong >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>Sent: Monday, April 30, 2012 10:34 PM >>>>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>>Jiangyuanlong; josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>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] >>>>>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 >>>>> >>>>>---------------------------------------------------------------------- >>>> >>>> >>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>proprietary information, which is privileged, confidential, or subject >>>>to >>>>copyright belonging to Time Warner Cable. This E-mail is intended >>>>solely >>>>for the use of the individual or entity to which it is addressed. If >>>>you >>>>are not the intended recipient of this E-mail, you are hereby notified >>>>that any dissemination, distribution, copying, or action taken in >>>>relation to the contents of and attachments to this E-mail is strictly >>>>prohibited and may be unlawful. If you have received this 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 and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for >the use of the individual or entity to which it is addressed. If you are >not >the intended recipient of this E-mail, you are hereby notified that any >dissemination, distribution, copying, or action taken in relation to the >contents of and attachments to this E-mail is strictly prohibited and may >be >unlawful. If you have received this 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 96, Issue 15 >************************************* > 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 Tue May 8 01:26: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 C627821F84DD for ; Tue, 8 May 2012 01:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[AWL=-0.220, 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 gSVT9iYgMHb2 for ; Tue, 8 May 2012 01:26:02 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id 03C3521F84D6 for ; Tue, 8 May 2012 01:26:00 -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: L2vpn Digest, Vol 96, Issue 15 Date: Tue, 8 May 2012 11:27:53 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780CA64@tlvmail1> In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410ABC@szxeml546-mbx.china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: L2vpn Digest, Vol 96, Issue 15 Thread-Index: AQHNKgNyPxr7nh+DX0S+AUfrSOoOpZa57ewAgARPYACAABdtgIAA8VnQgABOaUA= References: <2691CE0099834E4A9C5044EEC662BB9D330F0740@dfweml506-mbx> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410ABC@szxeml546-mbx.china.huawei.com> From: "Daniel Cohn" To: "Jiangyuanlong" , "Rogers, Josh" , "Lucy yong" , "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: Tue, 08 May 2012 08:26:05 -0000 Yuanlong, isn't this orthogonal to the issues we are discussing? I mean, there are different mechanisms to troubleshoot PWs, all of which are applicable to root/leaf PWs as to any other PWs. Or is there any specific limitation on root/leaf PW troubleshooting, compared to "regular" PWs used in VPLSs? Thanks, Daniel -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Jiangyuanlong Sent: Tuesday, May 08, 2012 7:04 AM To: Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 Josh,=20 Just some comments on this part: [JR] I don't see this any more of a problem than troubleshooting one. If LDP is used, a simple mols traceroute shows the path that ALL PW's to that PE take, regardless of which service (this VPLS or another VPLS instance). If RSVP is used, there should be a route-object that shows me the path, and allows me to troubleshoot. Additionally, if I wanted to have traffic engineering that impacted root-sourced and leaf-sourced traffic differently, I can do that with multi-PW, where I could not (save for ingress/egress) with the 2VLAN approach. PE should report signaling on second PW same as it does for the 100th PW between PE's. Again, I don't see the problem you are alluding to. I suppose you are referring to LSP Ping on the LSP layer, yes, it can oversee all the PWs in this LSP. If both root and leaf PW are in the same LSP, it can work. But there may well be multiple LSPs between a pair of PEs, and root/leaf PW may be transported on different LSPs. Another difficulty is, if ECMP is deployed and PW label as a bottom label is used for hashing, the OAM message may be load balanced on different paths. With regard to TE, you could use DS-TE, just as Lucy said, two PW do not guarantee they are traffic engineered. Thanks Yuanlong -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com]=20 Sent: Tuesday, May 08, 2012 5:22 AM To: Lucy yong; Sam Cao; l2vpn@ietf.org Cc: Jiangyuanlong Subject: Re: L2vpn Digest, Vol 96, Issue 15 Comments inline (and s/conquer/concur/) On 5/7/12 2:58 PM, "Lucy yong" wrote: >Sam, > >I concur with Yuanlong's reply on this. Please see inline. > >Lucy > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >Sam Cao >Sent: Friday, May 04, 2012 9:09 PM >To: l2vpn@ietf.org >Cc: Jiangyuanlong >Subject: RE: L2vpn Digest, Vol 96, Issue 15 > >Lucy/Yuanlong, > >I agree that we can not say which approach is better simply, but I really >agree with Josh's comments. Multi-PW is easy to implement E-Tree. >[[LY]] I don't get impression Josh state this. > >First of all, we discussed 2 approaches for a long time and many rounds, >and >for me, there are no pending issues on Multi-PW till now or co-authors of >multi-PW have given reasonable reply to L2VPN members' questions, but >there >are still pending issues for Dual-VLAN. Please trace the mailing list. >[[LY]] I interpret this as people want to spend time to finalize dual >VLAN solution. Multi-PW has some operation impact. How do operator to >maintain this service and be able to trouble shooting. How do you expect >traceroute work when using two PWs for one VPN? How do you expect PE >report when there is an error on one of two PWs? Do you have one FEC or >two FEC for a E-Tree in control plane? [JR] I don't see this any more of a problem than troubleshooting one. If LDP is used, a simple mols traceroute shows the path that ALL PW's to that PE take, regardless of which service (this VPLS or another VPLS instance). If RSVP is used, there should be a route-object that shows me the path, and allows me to troubleshoot. Additionally, if I wanted to have traffic engineering that impacted root-sourced and leaf-sourced traffic differently, I can do that with multi-PW, where I could not (save for ingress/egress) with the 2VLAN approach. PE should report signaling on second PW same as it does for the 100th PW between PE's. Again, I don't see the problem you are alluding to. > >Second, Sasha has his concern in NP, or forwarding performance. Compared >to >current VPLS, Multi-PW has a little effect on forwarding performance since >it reuse PW label as AC indicator; Dual-VLAN will have higher side effect >on >forwarding performance because it SHOULD use additional indicator. Is >there >one prototype for Dual-VLAN? BTW, there is no reply on chip limit. >[[LY]] in VPLS, PW label is used as VSI indicator, not AC. I disagree >your statement here. > >Third, the difference between Multi-PW and dual-VLAN is, transport ingress >traffic in one "LSP" or 2 "LSP". Multi-PW classifies and transforms >ingress >traffic into right "path", and egress just pop-out PW label and forward >the >frame to ACs. Dual-VLAN has more work on ingress PE or egress PE. >[[LY]] Don't understand the first part. When egress pop-out PW label, it >find corresponding VSI first, then perform MAC lookup associated to all >ACs. We can't assume there is one AC. > >Fourth, maybe Giles has figured this out, Dual-VLAN has capacity limit. >Only >4094 VLAN ID are available, so only 2K E-Tree instances can be supported >on >one PE for Dual-VLAN approach. There is no such limit for Multi-PW >approach, >[[LY]] If 4K VLAN ID is not an issue for VPLS, it is not an issue for >E-Tree. > >Finally, in this thread we don't make agreement on VLAN ID allocation. We >also have questions on VLAN ID negotiation among PEs (signaling protocol). >Yuanlong wishes to update, but there is no update till now. >[[LY]] This should not be the reason to judge on the solution. [JR] I tend to agree. > >For me, why IEEE uses VLAN ID to identify AC type? IEEE has no LABEL :), >and >it has label, it also wish to use label to identify AC types. I think that >both solutions need much time to be perfect. Mutli-PW has less extension >work to do. But now we are focusing on technical details and can not move >forward :). >[[LY]] VPN label is used for identify the VPN. It already has the >purpose. Overloading with other meaning has high potential causing a >problem. Hope you can investigate it more. Since you are very in favor of >multi-pw solution, it is not proper for you to come out the conclusion >which is better, because it is very biased. You are welcome to help on >completing either solution. [JR] this is humorous to me, because at one time, VLAN-ID was used to identify a single broadcast domain, and then later asymmetrical VID's were used to limit communication between endpoints of a broadcast domain (effectively creating two one-way broadcast domains, very similar to what we're accomplishing with ETREE). This should not be the reason to judge on the solution. > >Regards, >Lucy > >Lucy > >Thanks, > >Sam > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >l2vpn-request@ietf.org >Sent: Friday, May 04, 2012 10:31 PM >To: l2vpn@ietf.org >Subject: L2vpn Digest, Vol 96, Issue 15 > >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) > 2. Re: The status of the approaches to the E-Tree solution? > (Rogers, Josh) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Fri, 4 May 2012 14:16:36 +0000 >From: Lucy yong >To: "Rogers, Josh" , Jiangyuanlong > , Daniel Cohn , >"Fedyk, > Donald (Don)" , "Henderickx, Wim > (Wim)" >Cc: "l2vpn@ietf.org" >Subject: RE: The status of the approaches to the E-Tree solution? >Message-ID: <2691CE0099834E4A9C5044EEC662BB9D330E9114@dfweml505-mbx> >Content-Type: text/plain; charset=3D"iso-8859-2" > >Josh, > >You simply say that you don't like IEEE Tree solution. IEEE Tree solution >is >for ingress port to mark and for egress port to filter. > >Regards, >Lucy > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Friday, May 04, 2012 7:27 AM >To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >(Wim); >Lucy yong >Cc: l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >also separate the leaf traffic in the ingress PE and filter it there >(already detailed in the Optimization Mode in the I-D); if the egress PE >is attached with pure roots or with both roots and leafs, it seems all >traffic must be transported to the egress PE and be filtered there, I see >no difference in behaviour for these solutions. Or did I miss something? > > >The point is with the multi-PW method the traffic is split/separated (by >psuedowire) on the ingress PE, rather than the egress. The distinction is >2VLAN will 'classify' the frame on the ingress PE, so that the egress PE >knows how to forward it to the appropriate AC's. > >Both methods have inefficiencies (one duplicates traffic for transport, >while the other transports where it doesn't need to go). I like the idea >of classify and forwarding on the ingress PE, rather than marking it on >the ingress, and deciding on the egress. > >-Josh > > > >On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: > >>Josh, thank you for the comments, please see my further comments with >>[JY2]. >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Thursday, May 03, 2012 11:27 PM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>requirements from MEF, it has nothing to do with the solutions. Could you >>give a hint on how you can provision this service E-NNI otherwise? BTW, >>if >>configuring or signalling two PWs is not a problem, why configuring or >>signalling two VLANs will become a problem? After all, more nodes may >>need >>to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >>2VLAN (only T-PEs). >> >> >>There is no other way (if both MPLS domains are part of the same ETREE, >>rather than doing something more like H-VPLS, where one domain has point >>to points to the other domain which handles the ETREE instance) if you >>are >>using an ENNI. The other method, (not mentioned earlier) is tying the >>two >>MPLS domains together via labeled unicast (much preferred over E-NNI in >>my >>opinion) >> >>Configuring two VLAN's isn't really a 'problem' any more than two PW's. >>I >>wasn't saying that configuring two VLAN's was difficult, I was objecting >>to the statement that configuring two PW's is difficult. >> >>[JY2] Thanks, I see your point. I take the example of 2PW configuration >>just to show that using fixed global values to simplify configuration >>makes no sense. Personally I also don't think configuration is a problem >>for both solutions. >> >>I find the differences between these two methods rather slight. The >>'tie-breaker' for me is by placing the forwarding decision on the ingress >>PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >>more control over where the traffic goes, and in my mind it provides a >>cleaner destination between customer traffic and forwarding plane. I'm >>accustomed to looking at a psuedowire and knowing where its going, with >>the 2vlan method, I can see the psuedowire, but must go to the egress PE >>to see if it will be dropped there, or forwarded to one or more AC's. >> >>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>also separate the leaf traffic in the ingress PE and filter it there >>(already detailed in the Optimization Mode in the I-D); if the egress PE >>is attached with pure roots or with both roots and leafs, it seems all >>traffic must be transported to the egress PE and be filtered there, I see >>no difference in behaviour for these solutions. Or did I miss something? >> >>Again, the difference here is slight, and I would honestly be happy to >>see >>either of them come to fruition. Please don't infer that I think the >>2vlan method is 'bad' or has intrinsic problems, because I don't believe >>that. I just prefer the multi-PW method. >> >> >>-Josh >> >> >>On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: >> >>>Josh, please see my comments in line. >>> >>>Thanks >>>Yuanlong >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Thursday, May 03, 2012 10:51 AM >>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>(Wim); Lucy yong >>>Cc: l2vpn@ietf.org >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Yuanlong, >>> >>>Or better yet, include in the draft a 'standard' value for root sourced >>>VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You would also >>>have to require the the implementation NOT use global VLAN's, however >>>(since each instance would be using the same values). In this way, no >>>signaling or manual configuration is required for remote PE's to know >>>how >>>to classify traffic. >>>[JY] Indeed, we discussed this possibility during the f2f meeting in >>>Paris. But, there are some restrictions as you mentioned, and >>>furthermore: >>>1) Some vendors already used S-VLAN to distinguish their VSIs in the PE; >>>2) Forwarding plane of a PE needs to be revised to be aware of this VLAN >>>ID. >>>Therefore, this 'standard value' approach seems more disruptive compared >>>with the other means and not a good candidate option. >>> >>>Regarding switching PE's? Multi-PW means more than one PW, yes. I >>>don't >>>see this as a real problem. In general, design should try and avoid >>>using >>>S-PE's, but if you must, its going to mean extra work, no matter how you >>>look at it. Two PW's for each Etree being switched instead of one is >>>not >>>alarming or concerning to me. On the other hand, if you use a dot1q >>>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's >>>an >>>two egress VLAN's if you want the Etree to be handled on both sides (and >>>if you use the 'standard' VID's as I mentioned above, you'd have to do >>>mapping to non-standard and back) >>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>requirements from MEF, it has nothing to do with the solutions. Could >>>you >>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>if configuring or signalling two PWs is not a problem, why configuring >>>or >>>signalling two VLANs will become a problem? After all, more nodes may >>>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>>with 2VLAN (only T-PEs). >>> >>>In general, I still prefer multi-PW, primarily because I prefer the >>>separation of the traffic in the network's forwarding plane, rather than >>>shipping it everywhere and deciding whether to forward to the AC when it >>>gets to the egress PE. I'm having a hard time putting my finger exactly >>>on what it is, or articulating the idea, but it seems that by having the >>>traffic placed into two psuedowires, I have more flexibility and ease of >>>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>>PW's could really change that perception. >>>[JY] Are you saying that we need to develop a totally new forwarding >>>plane rather than using the Ethernet forwarding plane as described in >>>the >>>existing work? >>> >>>I hope we can move forward with one of these soon, >>>[JY] me too. >>> >>>Josh >>> >>> >>>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >>> >>>>Daniel, >>>> >>>>Not aware that we had a discussion on this before, but IMHO the >>>>allocation of internal S-VLAN can be automatic, and manuel >>>>configuration >>>>of this mapping may not be needed at all. For example, an S-VLAN >>>>allocation module in the management plane in a PE can do this kind of >>>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>>way from a free S-VLAN ID pool. Once the interal S-VLANs are allocated, >>>>the mapping is determined and no other configuration is needed. >>>> >>>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>>allocate >>>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to allocate >>>>two S-VLANs in the VPLS domain. >>>> >>>>On the other hand, for the multi-PW approach, two PWs need to be >>>>configured for a E-Tree service. When MS-PW is used in the network, for >>>>every S-PE, we need to configure two ingress PW segments and two egress >>>>PW segments. In this case, I don't think we need to use fixed PW labels >>>>across the network for fear of configuration complexity. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 8:01 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Inline. >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 12:30 PM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, Please see my comments in line. >>>> >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 3:55 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Yuanlong, >>>> >>>>The problem is not with the total number of S-VLAN IDs, I agree that >>>>normally there won't be more than 2047. The problem is that if you >>>>don't >>>>support all VLAN IDs, you need S-VLAN space coordination with the >>>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to >>>>2047". >>>>Which won't always be in line with an existing deployment. >>>>[JY] This is not the case. If the total number is no more than 2047, it >>>>surely can be supported. The S-VLAN space of user domain is totally >>>>different from the S-VLAN in the provider domain and they can be >>>>overlapped, I don't see why we need S-VLAN space coordination between >>>>them. >>>> >>>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>>fixed, and therefore the IEEE S-VID that can be supported is also >>>>fixed. >>>> >>>>Of course you can configure the mapping in each PE according to >>>>operator >>>>requirements but as we discussed before this increases complexity. >>>> >>>>Relying on PBB-VPLS imposes additional limitations on backward >>>>compatibility. >>>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>>think they may well need MAC-in-MAC in their networks for the >>>>scalability issue. As you know, only PBB VPLS can provide both. >>>> >>>>Daniel >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 5:07 AM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, >>>> >>>>As you can see, both cases are discussed in the I-D. >>>> >>>>With regard to case 1) (that is, S-VLAN translation), since the access >>>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>>they need to be configured on a PE anyway, and as the past emails by >>>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>>mapping. >>>> >>>>With regard to S-VID space reduction, the constraint is valid only when >>>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>>typical and with no such limits as we already discussed in the f2f >>>>meeting. >>>> >>>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>>described (not sure this is a valid use case in real life), PBB-VPLS >>>>can >>>>still be used. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Monday, April 30, 2012 10:34 PM >>>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>Jiangyuanlong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>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] >>>>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 >>>> >>>>-------------------------------------------------------------------- -- >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to >>>copyright belonging to Time Warner Cable. This E-mail is intended solely >>>for the use of the individual or entity to which it is addressed. If you >>>are not the intended recipient of this E-mail, you are hereby notified >>>that any dissemination, distribution, copying, or action taken in >>>relation to the contents of and attachments to this E-mail is strictly >>>prohibited and may be unlawful. If you have received this 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. > > >------------------------------ > >Message: 2 >Date: Fri, 4 May 2012 10:30:38 -0400 >From: "Rogers, Josh" >To: Lucy yong , Jiangyuanlong > , Daniel Cohn , >"Fedyk, > Donald (Don)" , "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"iso-8859-2" > >To be more accurate, I like it less than the multi-PW solution. I'd be >happy to use the 2VLAN solution in the real world, if it was ratified as >the standard. > > > >On 5/4/12 9:16 AM, "Lucy yong" wrote: > >>Josh, >> >>You simply say that you don't like IEEE Tree solution. IEEE Tree solution >>is for ingress port to mark and for egress port to filter. >> >>Regards, >>Lucy >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Friday, May 04, 2012 7:27 AM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>also separate the leaf traffic in the ingress PE and filter it there >>(already detailed in the Optimization Mode in the I-D); if the egress PE >>is attached with pure roots or with both roots and leafs, it seems all >>traffic must be transported to the egress PE and be filtered there, I see >>no difference in behaviour for these solutions. Or did I miss something? >> >> >>The point is with the multi-PW method the traffic is split/separated (by >>psuedowire) on the ingress PE, rather than the egress. The distinction >>is >>2VLAN will 'classify' the frame on the ingress PE, so that the egress PE >>knows how to forward it to the appropriate AC's. >> >>Both methods have inefficiencies (one duplicates traffic for transport, >>while the other transports where it doesn't need to go). I like the idea >>of classify and forwarding on the ingress PE, rather than marking it on >>the ingress, and deciding on the egress. >> >>-Josh >> >> >> >>On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: >> >>>Josh, thank you for the comments, please see my further comments with >>>[JY2]. >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Thursday, May 03, 2012 11:27 PM >>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>(Wim); Lucy yong >>>Cc: l2vpn@ietf.org >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>requirements from MEF, it has nothing to do with the solutions. Could >>>you >>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>if >>>configuring or signalling two PWs is not a problem, why configuring or >>>signalling two VLANs will become a problem? After all, more nodes may >>>need >>>to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >>>2VLAN (only T-PEs). >>> >>> >>>There is no other way (if both MPLS domains are part of the same ETREE, >>>rather than doing something more like H-VPLS, where one domain has point >>>to points to the other domain which handles the ETREE instance) if you >>>are >>>using an ENNI. The other method, (not mentioned earlier) is tying the >>>two >>>MPLS domains together via labeled unicast (much preferred over E-NNI in >>>my >>>opinion) >>> >>>Configuring two VLAN's isn't really a 'problem' any more than two PW's. >>>I >>>wasn't saying that configuring two VLAN's was difficult, I was objecting >>>to the statement that configuring two PW's is difficult. >>> >>>[JY2] Thanks, I see your point. I take the example of 2PW configuration >>>just to show that using fixed global values to simplify configuration >>>makes no sense. Personally I also don't think configuration is a problem >>>for both solutions. >>> >>>I find the differences between these two methods rather slight. The >>>'tie-breaker' for me is by placing the forwarding decision on the >>>ingress >>>PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >>>more control over where the traffic goes, and in my mind it provides a >>>cleaner destination between customer traffic and forwarding plane. I'm >>>accustomed to looking at a psuedowire and knowing where its going, with >>>the 2vlan method, I can see the psuedowire, but must go to the egress PE >>>to see if it will be dropped there, or forwarded to one or more AC's. >>> >>>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>>also separate the leaf traffic in the ingress PE and filter it there >>>(already detailed in the Optimization Mode in the I-D); if the egress PE >>>is attached with pure roots or with both roots and leafs, it seems all >>>traffic must be transported to the egress PE and be filtered there, I >>>see >>>no difference in behaviour for these solutions. Or did I miss something? >>> >>>Again, the difference here is slight, and I would honestly be happy to >>>see >>>either of them come to fruition. Please don't infer that I think the >>>2vlan method is 'bad' or has intrinsic problems, because I don't believe >>>that. I just prefer the multi-PW method. >>> >>> >>>-Josh >>> >>> >>>On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: >>> >>>>Josh, please see my comments in line. >>>> >>>>Thanks >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>>Sent: Thursday, May 03, 2012 10:51 AM >>>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>>(Wim); Lucy yong >>>>Cc: l2vpn@ietf.org >>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>> >>>>Yuanlong, >>>> >>>>Or better yet, include in the draft a 'standard' value for root sourced >>>>VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You = would also >>>>have to require the the implementation NOT use global VLAN's, however >>>>(since each instance would be using the same values). In this way, no >>>>signaling or manual configuration is required for remote PE's to know >>>>how >>>>to classify traffic. >>>>[JY] Indeed, we discussed this possibility during the f2f meeting in >>>>Paris. But, there are some restrictions as you mentioned, and >>>>furthermore: >>>>1) Some vendors already used S-VLAN to distinguish their VSIs in the >>>>PE; >>>>2) Forwarding plane of a PE needs to be revised to be aware of this >>>>VLAN >>>>ID. >>>>Therefore, this 'standard value' approach seems more disruptive >>>>compared >>>>with the other means and not a good candidate option. >>>> >>>>Regarding switching PE's? Multi-PW means more than one PW, yes. I >>>>don't >>>>see this as a real problem. In general, design should try and avoid >>>>using >>>>S-PE's, but if you must, its going to mean extra work, no matter how >>>>you >>>>look at it. Two PW's for each Etree being switched instead of one is >>>>not >>>>alarming or concerning to me. On the other hand, if you use a dot1q >>>>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's >>>>an >>>>two egress VLAN's if you want the Etree to be handled on both sides >>>>(and >>>>if you use the 'standard' VID's as I mentioned above, you'd have to do >>>>mapping to non-standard and back) >>>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>>requirements from MEF, it has nothing to do with the solutions. Could >>>>you >>>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>>if configuring or signalling two PWs is not a problem, why configuring >>>>or >>>>signalling two VLANs will become a problem? After all, more nodes may >>>>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>>>with 2VLAN (only T-PEs). >>>> >>>>In general, I still prefer multi-PW, primarily because I prefer the >>>>separation of the traffic in the network's forwarding plane, rather >>>>than >>>>shipping it everywhere and deciding whether to forward to the AC when >>>>it >>>>gets to the egress PE. I'm having a hard time putting my finger >>>>exactly >>>>on what it is, or articulating the idea, but it seems that by having >>>>the >>>>traffic placed into two psuedowires, I have more flexibility and ease >>>>of >>>>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>>>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>>>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>>>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>>>PW's could really change that perception. >>>>[JY] Are you saying that we need to develop a totally new forwarding >>>>plane rather than using the Ethernet forwarding plane as described in >>>>the >>>>existing work? >>>> >>>>I hope we can move forward with one of these soon, >>>>[JY] me too. >>>> >>>>Josh >>>> >>>> >>>>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >>>> >>>>>Daniel, >>>>> >>>>>Not aware that we had a discussion on this before, but IMHO the >>>>>allocation of internal S-VLAN can be automatic, and manuel >>>>>configuration >>>>>of this mapping may not be needed at all. For example, an S-VLAN >>>>>allocation module in the management plane in a PE can do this kind of >>>>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>>>way from a free S-VLAN ID pool. Once the interal S-VLANs are >>>>>allocated, >>>>>the mapping is determined and no other configuration is needed. >>>>> >>>>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>>>allocate >>>>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to >>>>>allocate >>>>>two S-VLANs in the VPLS domain. >>>>> >>>>>On the other hand, for the multi-PW approach, two PWs need to be >>>>>configured for a E-Tree service. When MS-PW is used in the network, >>>>>for >>>>>every S-PE, we need to configure two ingress PW segments and two >>>>>egress >>>>>PW segments. In this case, I don't think we need to use fixed PW >>>>>labels >>>>>across the network for fear of configuration complexity. >>>>> >>>>>Regards, >>>>>Yuanlong >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>Sent: Wednesday, May 02, 2012 8:01 PM >>>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; >>>>>josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Inline. >>>>> >>>>>-----Original Message----- >>>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>>Sent: Wednesday, May 02, 2012 12:30 PM >>>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; >>>>>josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Hi Daniel, Please see my comments in line. >>>>> >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>Sent: Wednesday, May 02, 2012 3:55 PM >>>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Hi Yuanlong, >>>>> >>>>>The problem is not with the total number of S-VLAN IDs, I agree that >>>>>normally there won't be more than 2047. The problem is that if you >>>>>don't >>>>>support all VLAN IDs, you need S-VLAN space coordination with the >>>>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to >>>>>2047". >>>>>Which won't always be in line with an existing deployment. >>>>>[JY] This is not the case. If the total number is no more than 2047, >>>>>it >>>>>surely can be supported. The S-VLAN space of user domain is totally >>>>>different from the S-VLAN in the provider domain and they can be >>>>>overlapped, I don't see why we need S-VLAN space coordination between >>>>>them. >>>>> >>>>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>>>fixed, and therefore the IEEE S-VID that can be supported is also >>>>>fixed. >>>>> >>>>>Of course you can configure the mapping in each PE according to >>>>>operator >>>>>requirements but as we discussed before this increases complexity. >>>>> >>>>>Relying on PBB-VPLS imposes additional limitations on backward >>>>>compatibility. >>>>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>>>think they may well need MAC-in-MAC in their networks for the >>>>>scalability issue. As you know, only PBB VPLS can provide both. >>>>> >>>>>Daniel >>>>> >>>>>-----Original Message----- >>>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>>Sent: Wednesday, May 02, 2012 5:07 AM >>>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; >>>>>josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Hi Daniel, >>>>> >>>>>As you can see, both cases are discussed in the I-D. >>>>> >>>>>With regard to case 1) (that is, S-VLAN translation), since the access >>>>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>>>they need to be configured on a PE anyway, and as the past emails by >>>>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>>>mapping. >>>>> >>>>>With regard to S-VID space reduction, the constraint is valid only >>>>>when >>>>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>>>typical and with no such limits as we already discussed in the f2f >>>>>meeting. >>>>> >>>>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>>>described (not sure this is a valid use case in real life), PBB-VPLS >>>>>can >>>>>still be used. >>>>> >>>>>Regards, >>>>>Yuanlong >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>Sent: Monday, April 30, 2012 10:34 PM >>>>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>>Jiangyuanlong; josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>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] >>>>>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 >>>>> >>>>>------------------------------------------------------------------- --- >>>> >>>> >>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>proprietary information, which is privileged, confidential, or subject >>>>to >>>>copyright belonging to Time Warner Cable. This E-mail is intended >>>>solely >>>>for the use of the individual or entity to which it is addressed. If >>>>you >>>>are not the intended recipient of this E-mail, you are hereby notified >>>>that any dissemination, distribution, copying, or action taken in >>>>relation to the contents of and attachments to this E-mail is strictly >>>>prohibited and may be unlawful. If you have received this 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 and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for >the use of the individual or entity to which it is addressed. If you are >not >the intended recipient of this E-mail, you are hereby notified that any >dissemination, distribution, copying, or action taken in relation to the >contents of and attachments to this E-mail is strictly prohibited and may >be >unlawful. If you have received this 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 96, Issue 15 >************************************* > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this 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 May 8 01:45: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 13CD721F85C4 for ; Tue, 8 May 2012 01:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.14 X-Spam-Level: X-Spam-Status: No, score=-2.14 tagged_above=-999 required=5 tests=[AWL=-0.141, 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 kgHYrj-zkhRf for ; Tue, 8 May 2012 01:45:27 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9511921F85C2 for ; Tue, 8 May 2012 01:45: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 AFP67981; Tue, 08 May 2012 04:45:26 -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, 8 May 2012 01:42:39 -0700 Received: from SZXEML439-HUB.china.huawei.com (10.72.61.74) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 8 May 2012 01:42:42 -0700 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.183]) by szxeml439-hub.china.huawei.com ([10.72.61.74]) with mapi id 14.01.0323.003; Tue, 8 May 2012 16:42:29 +0800 From: Jiangyuanlong To: Daniel Cohn , "Rogers, Josh" , Lucy yong , Sam Cao , "l2vpn@ietf.org" Subject: RE: L2vpn Digest, Vol 96, Issue 15 Thread-Topic: L2vpn Digest, Vol 96, Issue 15 Thread-Index: AQHNKgNyPxr7nh+DX0S+AUfrSOoOpZa57ewAgARPYACAABdtgIAA8VnQgABOaUCAAAEZoA== Date: Tue, 8 May 2012 08:42:28 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410B5D@szxeml546-mbx.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D330F0740@dfweml506-mbx> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410ABC@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CA64@tlvmail1> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA08130780CA64@tlvmail1> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.40.73] 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: Tue, 08 May 2012 08:45:31 -0000 I don't think so. There may be different layers of OAM applicable to a serv= ice. Such as LSP layer, PW layer, and service layer. Now you cannot use a single LSP OAM to monitor the server layer of the E-Tr= ee service (as 2 LSP may be involved). And the service layer of OAM for E-Tree may be distributed to different LSP= paths. -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Tuesday, May 08, 2012 4:28 PM To: Jiangyuanlong; Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 Yuanlong, isn't this orthogonal to the issues we are discussing? I mean, there are different mechanisms to troubleshoot PWs, all of which are applicable to root/leaf PWs as to any other PWs. Or is there any specific limitation on root/leaf PW troubleshooting, compared to "regular" PWs used in VPLSs? Thanks, Daniel -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Jiangyuanlong Sent: Tuesday, May 08, 2012 7:04 AM To: Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 Josh,=20 Just some comments on this part: [JR] I don't see this any more of a problem than troubleshooting one. If LDP is used, a simple mols traceroute shows the path that ALL PW's to that PE take, regardless of which service (this VPLS or another VPLS instance). If RSVP is used, there should be a route-object that shows me the path, and allows me to troubleshoot. Additionally, if I wanted to have traffic engineering that impacted root-sourced and leaf-sourced traffic differently, I can do that with multi-PW, where I could not (save for ingress/egress) with the 2VLAN approach. PE should report signaling on second PW same as it does for the 100th PW between PE's. Again, I don't see the problem you are alluding to. I suppose you are referring to LSP Ping on the LSP layer, yes, it can oversee all the PWs in this LSP. If both root and leaf PW are in the same LSP, it can work. But there may well be multiple LSPs between a pair of PEs, and root/leaf PW may be transported on different LSPs. Another difficulty is, if ECMP is deployed and PW label as a bottom label is used for hashing, the OAM message may be load balanced on different paths. With regard to TE, you could use DS-TE, just as Lucy said, two PW do not guarantee they are traffic engineered. Thanks Yuanlong -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com]=20 Sent: Tuesday, May 08, 2012 5:22 AM To: Lucy yong; Sam Cao; l2vpn@ietf.org Cc: Jiangyuanlong Subject: Re: L2vpn Digest, Vol 96, Issue 15 Comments inline (and s/conquer/concur/) On 5/7/12 2:58 PM, "Lucy yong" wrote: >Sam, > >I concur with Yuanlong's reply on this. Please see inline. > >Lucy > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >Sam Cao >Sent: Friday, May 04, 2012 9:09 PM >To: l2vpn@ietf.org >Cc: Jiangyuanlong >Subject: RE: L2vpn Digest, Vol 96, Issue 15 > >Lucy/Yuanlong, > >I agree that we can not say which approach is better simply, but I really >agree with Josh's comments. Multi-PW is easy to implement E-Tree. >[[LY]] I don't get impression Josh state this. > >First of all, we discussed 2 approaches for a long time and many rounds, >and >for me, there are no pending issues on Multi-PW till now or co-authors of >multi-PW have given reasonable reply to L2VPN members' questions, but >there >are still pending issues for Dual-VLAN. Please trace the mailing list. >[[LY]] I interpret this as people want to spend time to finalize dual >VLAN solution. Multi-PW has some operation impact. How do operator to >maintain this service and be able to trouble shooting. How do you expect >traceroute work when using two PWs for one VPN? How do you expect PE >report when there is an error on one of two PWs? Do you have one FEC or >two FEC for a E-Tree in control plane? [JR] I don't see this any more of a problem than troubleshooting one. If LDP is used, a simple mols traceroute shows the path that ALL PW's to that PE take, regardless of which service (this VPLS or another VPLS instance). If RSVP is used, there should be a route-object that shows me the path, and allows me to troubleshoot. Additionally, if I wanted to have traffic engineering that impacted root-sourced and leaf-sourced traffic differently, I can do that with multi-PW, where I could not (save for ingress/egress) with the 2VLAN approach. PE should report signaling on second PW same as it does for the 100th PW between PE's. Again, I don't see the problem you are alluding to. > >Second, Sasha has his concern in NP, or forwarding performance. Compared >to >current VPLS, Multi-PW has a little effect on forwarding performance since >it reuse PW label as AC indicator; Dual-VLAN will have higher side effect >on >forwarding performance because it SHOULD use additional indicator. Is >there >one prototype for Dual-VLAN? BTW, there is no reply on chip limit. >[[LY]] in VPLS, PW label is used as VSI indicator, not AC. I disagree >your statement here. > >Third, the difference between Multi-PW and dual-VLAN is, transport ingress >traffic in one "LSP" or 2 "LSP". Multi-PW classifies and transforms >ingress >traffic into right "path", and egress just pop-out PW label and forward >the >frame to ACs. Dual-VLAN has more work on ingress PE or egress PE. >[[LY]] Don't understand the first part. When egress pop-out PW label, it >find corresponding VSI first, then perform MAC lookup associated to all >ACs. We can't assume there is one AC. > >Fourth, maybe Giles has figured this out, Dual-VLAN has capacity limit. >Only >4094 VLAN ID are available, so only 2K E-Tree instances can be supported >on >one PE for Dual-VLAN approach. There is no such limit for Multi-PW >approach, >[[LY]] If 4K VLAN ID is not an issue for VPLS, it is not an issue for >E-Tree. > >Finally, in this thread we don't make agreement on VLAN ID allocation. We >also have questions on VLAN ID negotiation among PEs (signaling protocol). >Yuanlong wishes to update, but there is no update till now. >[[LY]] This should not be the reason to judge on the solution. [JR] I tend to agree. > >For me, why IEEE uses VLAN ID to identify AC type? IEEE has no LABEL :), >and >it has label, it also wish to use label to identify AC types. I think that >both solutions need much time to be perfect. Mutli-PW has less extension >work to do. But now we are focusing on technical details and can not move >forward :). >[[LY]] VPN label is used for identify the VPN. It already has the >purpose. Overloading with other meaning has high potential causing a >problem. Hope you can investigate it more. Since you are very in favor of >multi-pw solution, it is not proper for you to come out the conclusion >which is better, because it is very biased. You are welcome to help on >completing either solution. [JR] this is humorous to me, because at one time, VLAN-ID was used to identify a single broadcast domain, and then later asymmetrical VID's were used to limit communication between endpoints of a broadcast domain (effectively creating two one-way broadcast domains, very similar to what we're accomplishing with ETREE). This should not be the reason to judge on the solution. > >Regards, >Lucy > >Lucy > >Thanks, > >Sam > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >l2vpn-request@ietf.org >Sent: Friday, May 04, 2012 10:31 PM >To: l2vpn@ietf.org >Subject: L2vpn Digest, Vol 96, Issue 15 > >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) > 2. Re: The status of the approaches to the E-Tree solution? > (Rogers, Josh) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Fri, 4 May 2012 14:16:36 +0000 >From: Lucy yong >To: "Rogers, Josh" , Jiangyuanlong > , Daniel Cohn , >"Fedyk, > Donald (Don)" , "Henderickx, Wim > (Wim)" >Cc: "l2vpn@ietf.org" >Subject: RE: The status of the approaches to the E-Tree solution? >Message-ID: <2691CE0099834E4A9C5044EEC662BB9D330E9114@dfweml505-mbx> >Content-Type: text/plain; charset=3D"iso-8859-2" > >Josh, > >You simply say that you don't like IEEE Tree solution. IEEE Tree solution >is >for ingress port to mark and for egress port to filter. > >Regards, >Lucy > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Friday, May 04, 2012 7:27 AM >To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >(Wim); >Lucy yong >Cc: l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >also separate the leaf traffic in the ingress PE and filter it there >(already detailed in the Optimization Mode in the I-D); if the egress PE >is attached with pure roots or with both roots and leafs, it seems all >traffic must be transported to the egress PE and be filtered there, I see >no difference in behaviour for these solutions. Or did I miss something? > > >The point is with the multi-PW method the traffic is split/separated (by >psuedowire) on the ingress PE, rather than the egress. The distinction is >2VLAN will 'classify' the frame on the ingress PE, so that the egress PE >knows how to forward it to the appropriate AC's. > >Both methods have inefficiencies (one duplicates traffic for transport, >while the other transports where it doesn't need to go). I like the idea >of classify and forwarding on the ingress PE, rather than marking it on >the ingress, and deciding on the egress. > >-Josh > > > >On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: > >>Josh, thank you for the comments, please see my further comments with >>[JY2]. >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Thursday, May 03, 2012 11:27 PM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>requirements from MEF, it has nothing to do with the solutions. Could you >>give a hint on how you can provision this service E-NNI otherwise? BTW, >>if >>configuring or signalling two PWs is not a problem, why configuring or >>signalling two VLANs will become a problem? After all, more nodes may >>need >>to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >>2VLAN (only T-PEs). >> >> >>There is no other way (if both MPLS domains are part of the same ETREE, >>rather than doing something more like H-VPLS, where one domain has point >>to points to the other domain which handles the ETREE instance) if you >>are >>using an ENNI. The other method, (not mentioned earlier) is tying the >>two >>MPLS domains together via labeled unicast (much preferred over E-NNI in >>my >>opinion) >> >>Configuring two VLAN's isn't really a 'problem' any more than two PW's. >>I >>wasn't saying that configuring two VLAN's was difficult, I was objecting >>to the statement that configuring two PW's is difficult. >> >>[JY2] Thanks, I see your point. I take the example of 2PW configuration >>just to show that using fixed global values to simplify configuration >>makes no sense. Personally I also don't think configuration is a problem >>for both solutions. >> >>I find the differences between these two methods rather slight. The >>'tie-breaker' for me is by placing the forwarding decision on the ingress >>PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >>more control over where the traffic goes, and in my mind it provides a >>cleaner destination between customer traffic and forwarding plane. I'm >>accustomed to looking at a psuedowire and knowing where its going, with >>the 2vlan method, I can see the psuedowire, but must go to the egress PE >>to see if it will be dropped there, or forwarded to one or more AC's. >> >>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>also separate the leaf traffic in the ingress PE and filter it there >>(already detailed in the Optimization Mode in the I-D); if the egress PE >>is attached with pure roots or with both roots and leafs, it seems all >>traffic must be transported to the egress PE and be filtered there, I see >>no difference in behaviour for these solutions. Or did I miss something? >> >>Again, the difference here is slight, and I would honestly be happy to >>see >>either of them come to fruition. Please don't infer that I think the >>2vlan method is 'bad' or has intrinsic problems, because I don't believe >>that. I just prefer the multi-PW method. >> >> >>-Josh >> >> >>On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: >> >>>Josh, please see my comments in line. >>> >>>Thanks >>>Yuanlong >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Thursday, May 03, 2012 10:51 AM >>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>(Wim); Lucy yong >>>Cc: l2vpn@ietf.org >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Yuanlong, >>> >>>Or better yet, include in the draft a 'standard' value for root sourced >>>VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You would also >>>have to require the the implementation NOT use global VLAN's, however >>>(since each instance would be using the same values). In this way, no >>>signaling or manual configuration is required for remote PE's to know >>>how >>>to classify traffic. >>>[JY] Indeed, we discussed this possibility during the f2f meeting in >>>Paris. But, there are some restrictions as you mentioned, and >>>furthermore: >>>1) Some vendors already used S-VLAN to distinguish their VSIs in the PE; >>>2) Forwarding plane of a PE needs to be revised to be aware of this VLAN >>>ID. >>>Therefore, this 'standard value' approach seems more disruptive compared >>>with the other means and not a good candidate option. >>> >>>Regarding switching PE's? Multi-PW means more than one PW, yes. I >>>don't >>>see this as a real problem. In general, design should try and avoid >>>using >>>S-PE's, but if you must, its going to mean extra work, no matter how you >>>look at it. Two PW's for each Etree being switched instead of one is >>>not >>>alarming or concerning to me. On the other hand, if you use a dot1q >>>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's >>>an >>>two egress VLAN's if you want the Etree to be handled on both sides (and >>>if you use the 'standard' VID's as I mentioned above, you'd have to do >>>mapping to non-standard and back) >>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>requirements from MEF, it has nothing to do with the solutions. Could >>>you >>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>if configuring or signalling two PWs is not a problem, why configuring >>>or >>>signalling two VLANs will become a problem? After all, more nodes may >>>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>>with 2VLAN (only T-PEs). >>> >>>In general, I still prefer multi-PW, primarily because I prefer the >>>separation of the traffic in the network's forwarding plane, rather than >>>shipping it everywhere and deciding whether to forward to the AC when it >>>gets to the egress PE. I'm having a hard time putting my finger exactly >>>on what it is, or articulating the idea, but it seems that by having the >>>traffic placed into two psuedowires, I have more flexibility and ease of >>>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>>PW's could really change that perception. >>>[JY] Are you saying that we need to develop a totally new forwarding >>>plane rather than using the Ethernet forwarding plane as described in >>>the >>>existing work? >>> >>>I hope we can move forward with one of these soon, >>>[JY] me too. >>> >>>Josh >>> >>> >>>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >>> >>>>Daniel, >>>> >>>>Not aware that we had a discussion on this before, but IMHO the >>>>allocation of internal S-VLAN can be automatic, and manuel >>>>configuration >>>>of this mapping may not be needed at all. For example, an S-VLAN >>>>allocation module in the management plane in a PE can do this kind of >>>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>>way from a free S-VLAN ID pool. Once the interal S-VLANs are allocated, >>>>the mapping is determined and no other configuration is needed. >>>> >>>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>>allocate >>>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to allocate >>>>two S-VLANs in the VPLS domain. >>>> >>>>On the other hand, for the multi-PW approach, two PWs need to be >>>>configured for a E-Tree service. When MS-PW is used in the network, for >>>>every S-PE, we need to configure two ingress PW segments and two egress >>>>PW segments. In this case, I don't think we need to use fixed PW labels >>>>across the network for fear of configuration complexity. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 8:01 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Inline. >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 12:30 PM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, Please see my comments in line. >>>> >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 3:55 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Yuanlong, >>>> >>>>The problem is not with the total number of S-VLAN IDs, I agree that >>>>normally there won't be more than 2047. The problem is that if you >>>>don't >>>>support all VLAN IDs, you need S-VLAN space coordination with the >>>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to >>>>2047". >>>>Which won't always be in line with an existing deployment. >>>>[JY] This is not the case. If the total number is no more than 2047, it >>>>surely can be supported. The S-VLAN space of user domain is totally >>>>different from the S-VLAN in the provider domain and they can be >>>>overlapped, I don't see why we need S-VLAN space coordination between >>>>them. >>>> >>>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>>fixed, and therefore the IEEE S-VID that can be supported is also >>>>fixed. >>>> >>>>Of course you can configure the mapping in each PE according to >>>>operator >>>>requirements but as we discussed before this increases complexity. >>>> >>>>Relying on PBB-VPLS imposes additional limitations on backward >>>>compatibility. >>>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>>think they may well need MAC-in-MAC in their networks for the >>>>scalability issue. As you know, only PBB VPLS can provide both. >>>> >>>>Daniel >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 5:07 AM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, >>>> >>>>As you can see, both cases are discussed in the I-D. >>>> >>>>With regard to case 1) (that is, S-VLAN translation), since the access >>>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>>they need to be configured on a PE anyway, and as the past emails by >>>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>>mapping. >>>> >>>>With regard to S-VID space reduction, the constraint is valid only when >>>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>>typical and with no such limits as we already discussed in the f2f >>>>meeting. >>>> >>>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>>described (not sure this is a valid use case in real life), PBB-VPLS >>>>can >>>>still be used. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Monday, April 30, 2012 10:34 PM >>>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>Jiangyuanlong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>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] >>>>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 >>>> >>>>-------------------------------------------------------------------- -- >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to >>>copyright belonging to Time Warner Cable. This E-mail is intended solely >>>for the use of the individual or entity to which it is addressed. If you >>>are not the intended recipient of this E-mail, you are hereby notified >>>that any dissemination, distribution, copying, or action taken in >>>relation to the contents of and attachments to this E-mail is strictly >>>prohibited and may be unlawful. If you have received this 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. > > >------------------------------ > >Message: 2 >Date: Fri, 4 May 2012 10:30:38 -0400 >From: "Rogers, Josh" >To: Lucy yong , Jiangyuanlong > , Daniel Cohn , >"Fedyk, > Donald (Don)" , "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"iso-8859-2" > >To be more accurate, I like it less than the multi-PW solution. I'd be >happy to use the 2VLAN solution in the real world, if it was ratified as >the standard. > > > >On 5/4/12 9:16 AM, "Lucy yong" wrote: > >>Josh, >> >>You simply say that you don't like IEEE Tree solution. IEEE Tree solution >>is for ingress port to mark and for egress port to filter. >> >>Regards, >>Lucy >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Friday, May 04, 2012 7:27 AM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>also separate the leaf traffic in the ingress PE and filter it there >>(already detailed in the Optimization Mode in the I-D); if the egress PE >>is attached with pure roots or with both roots and leafs, it seems all >>traffic must be transported to the egress PE and be filtered there, I see >>no difference in behaviour for these solutions. Or did I miss something? >> >> >>The point is with the multi-PW method the traffic is split/separated (by >>psuedowire) on the ingress PE, rather than the egress. The distinction >>is >>2VLAN will 'classify' the frame on the ingress PE, so that the egress PE >>knows how to forward it to the appropriate AC's. >> >>Both methods have inefficiencies (one duplicates traffic for transport, >>while the other transports where it doesn't need to go). I like the idea >>of classify and forwarding on the ingress PE, rather than marking it on >>the ingress, and deciding on the egress. >> >>-Josh >> >> >> >>On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: >> >>>Josh, thank you for the comments, please see my further comments with >>>[JY2]. >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Thursday, May 03, 2012 11:27 PM >>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>(Wim); Lucy yong >>>Cc: l2vpn@ietf.org >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>requirements from MEF, it has nothing to do with the solutions. Could >>>you >>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>if >>>configuring or signalling two PWs is not a problem, why configuring or >>>signalling two VLANs will become a problem? After all, more nodes may >>>need >>>to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >>>2VLAN (only T-PEs). >>> >>> >>>There is no other way (if both MPLS domains are part of the same ETREE, >>>rather than doing something more like H-VPLS, where one domain has point >>>to points to the other domain which handles the ETREE instance) if you >>>are >>>using an ENNI. The other method, (not mentioned earlier) is tying the >>>two >>>MPLS domains together via labeled unicast (much preferred over E-NNI in >>>my >>>opinion) >>> >>>Configuring two VLAN's isn't really a 'problem' any more than two PW's. >>>I >>>wasn't saying that configuring two VLAN's was difficult, I was objecting >>>to the statement that configuring two PW's is difficult. >>> >>>[JY2] Thanks, I see your point. I take the example of 2PW configuration >>>just to show that using fixed global values to simplify configuration >>>makes no sense. Personally I also don't think configuration is a problem >>>for both solutions. >>> >>>I find the differences between these two methods rather slight. The >>>'tie-breaker' for me is by placing the forwarding decision on the >>>ingress >>>PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >>>more control over where the traffic goes, and in my mind it provides a >>>cleaner destination between customer traffic and forwarding plane. I'm >>>accustomed to looking at a psuedowire and knowing where its going, with >>>the 2vlan method, I can see the psuedowire, but must go to the egress PE >>>to see if it will be dropped there, or forwarded to one or more AC's. >>> >>>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>>also separate the leaf traffic in the ingress PE and filter it there >>>(already detailed in the Optimization Mode in the I-D); if the egress PE >>>is attached with pure roots or with both roots and leafs, it seems all >>>traffic must be transported to the egress PE and be filtered there, I >>>see >>>no difference in behaviour for these solutions. Or did I miss something? >>> >>>Again, the difference here is slight, and I would honestly be happy to >>>see >>>either of them come to fruition. Please don't infer that I think the >>>2vlan method is 'bad' or has intrinsic problems, because I don't believe >>>that. I just prefer the multi-PW method. >>> >>> >>>-Josh >>> >>> >>>On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: >>> >>>>Josh, please see my comments in line. >>>> >>>>Thanks >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>>Sent: Thursday, May 03, 2012 10:51 AM >>>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>>(Wim); Lucy yong >>>>Cc: l2vpn@ietf.org >>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>> >>>>Yuanlong, >>>> >>>>Or better yet, include in the draft a 'standard' value for root sourced >>>>VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You would also >>>>have to require the the implementation NOT use global VLAN's, however >>>>(since each instance would be using the same values). In this way, no >>>>signaling or manual configuration is required for remote PE's to know >>>>how >>>>to classify traffic. >>>>[JY] Indeed, we discussed this possibility during the f2f meeting in >>>>Paris. But, there are some restrictions as you mentioned, and >>>>furthermore: >>>>1) Some vendors already used S-VLAN to distinguish their VSIs in the >>>>PE; >>>>2) Forwarding plane of a PE needs to be revised to be aware of this >>>>VLAN >>>>ID. >>>>Therefore, this 'standard value' approach seems more disruptive >>>>compared >>>>with the other means and not a good candidate option. >>>> >>>>Regarding switching PE's? Multi-PW means more than one PW, yes. I >>>>don't >>>>see this as a real problem. In general, design should try and avoid >>>>using >>>>S-PE's, but if you must, its going to mean extra work, no matter how >>>>you >>>>look at it. Two PW's for each Etree being switched instead of one is >>>>not >>>>alarming or concerning to me. On the other hand, if you use a dot1q >>>>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's >>>>an >>>>two egress VLAN's if you want the Etree to be handled on both sides >>>>(and >>>>if you use the 'standard' VID's as I mentioned above, you'd have to do >>>>mapping to non-standard and back) >>>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>>requirements from MEF, it has nothing to do with the solutions. Could >>>>you >>>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>>if configuring or signalling two PWs is not a problem, why configuring >>>>or >>>>signalling two VLANs will become a problem? After all, more nodes may >>>>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>>>with 2VLAN (only T-PEs). >>>> >>>>In general, I still prefer multi-PW, primarily because I prefer the >>>>separation of the traffic in the network's forwarding plane, rather >>>>than >>>>shipping it everywhere and deciding whether to forward to the AC when >>>>it >>>>gets to the egress PE. I'm having a hard time putting my finger >>>>exactly >>>>on what it is, or articulating the idea, but it seems that by having >>>>the >>>>traffic placed into two psuedowires, I have more flexibility and ease >>>>of >>>>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>>>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>>>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>>>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>>>PW's could really change that perception. >>>>[JY] Are you saying that we need to develop a totally new forwarding >>>>plane rather than using the Ethernet forwarding plane as described in >>>>the >>>>existing work? >>>> >>>>I hope we can move forward with one of these soon, >>>>[JY] me too. >>>> >>>>Josh >>>> >>>> >>>>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >>>> >>>>>Daniel, >>>>> >>>>>Not aware that we had a discussion on this before, but IMHO the >>>>>allocation of internal S-VLAN can be automatic, and manuel >>>>>configuration >>>>>of this mapping may not be needed at all. For example, an S-VLAN >>>>>allocation module in the management plane in a PE can do this kind of >>>>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>>>way from a free S-VLAN ID pool. Once the interal S-VLANs are >>>>>allocated, >>>>>the mapping is determined and no other configuration is needed. >>>>> >>>>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>>>allocate >>>>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to >>>>>allocate >>>>>two S-VLANs in the VPLS domain. >>>>> >>>>>On the other hand, for the multi-PW approach, two PWs need to be >>>>>configured for a E-Tree service. When MS-PW is used in the network, >>>>>for >>>>>every S-PE, we need to configure two ingress PW segments and two >>>>>egress >>>>>PW segments. In this case, I don't think we need to use fixed PW >>>>>labels >>>>>across the network for fear of configuration complexity. >>>>> >>>>>Regards, >>>>>Yuanlong >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>Sent: Wednesday, May 02, 2012 8:01 PM >>>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; >>>>>josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Inline. >>>>> >>>>>-----Original Message----- >>>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>>Sent: Wednesday, May 02, 2012 12:30 PM >>>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; >>>>>josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Hi Daniel, Please see my comments in line. >>>>> >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>Sent: Wednesday, May 02, 2012 3:55 PM >>>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Hi Yuanlong, >>>>> >>>>>The problem is not with the total number of S-VLAN IDs, I agree that >>>>>normally there won't be more than 2047. The problem is that if you >>>>>don't >>>>>support all VLAN IDs, you need S-VLAN space coordination with the >>>>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to >>>>>2047". >>>>>Which won't always be in line with an existing deployment. >>>>>[JY] This is not the case. If the total number is no more than 2047, >>>>>it >>>>>surely can be supported. The S-VLAN space of user domain is totally >>>>>different from the S-VLAN in the provider domain and they can be >>>>>overlapped, I don't see why we need S-VLAN space coordination between >>>>>them. >>>>> >>>>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>>>fixed, and therefore the IEEE S-VID that can be supported is also >>>>>fixed. >>>>> >>>>>Of course you can configure the mapping in each PE according to >>>>>operator >>>>>requirements but as we discussed before this increases complexity. >>>>> >>>>>Relying on PBB-VPLS imposes additional limitations on backward >>>>>compatibility. >>>>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>>>think they may well need MAC-in-MAC in their networks for the >>>>>scalability issue. As you know, only PBB VPLS can provide both. >>>>> >>>>>Daniel >>>>> >>>>>-----Original Message----- >>>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>>Sent: Wednesday, May 02, 2012 5:07 AM >>>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; >>>>>josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Hi Daniel, >>>>> >>>>>As you can see, both cases are discussed in the I-D. >>>>> >>>>>With regard to case 1) (that is, S-VLAN translation), since the access >>>>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>>>they need to be configured on a PE anyway, and as the past emails by >>>>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>>>mapping. >>>>> >>>>>With regard to S-VID space reduction, the constraint is valid only >>>>>when >>>>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>>>typical and with no such limits as we already discussed in the f2f >>>>>meeting. >>>>> >>>>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>>>described (not sure this is a valid use case in real life), PBB-VPLS >>>>>can >>>>>still be used. >>>>> >>>>>Regards, >>>>>Yuanlong >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>Sent: Monday, April 30, 2012 10:34 PM >>>>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>>Jiangyuanlong; josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>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] >>>>>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 >>>>> >>>>>------------------------------------------------------------------- --- >>>> >>>> >>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>proprietary information, which is privileged, confidential, or subject >>>>to >>>>copyright belonging to Time Warner Cable. This E-mail is intended >>>>solely >>>>for the use of the individual or entity to which it is addressed. If >>>>you >>>>are not the intended recipient of this E-mail, you are hereby notified >>>>that any dissemination, distribution, copying, or action taken in >>>>relation to the contents of and attachments to this E-mail is strictly >>>>prohibited and may be unlawful. If you have received this 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 and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for >the use of the individual or entity to which it is addressed. If you are >not >the intended recipient of this E-mail, you are hereby notified that any >dissemination, distribution, copying, or action taken in relation to the >contents of and attachments to this E-mail is strictly prohibited and may >be >unlawful. If you have received this 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 96, Issue 15 >************************************* > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this 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 DanielC@orckit.com Tue May 8 01:47: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 8269C21F85C4 for ; Tue, 8 May 2012 01:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.208 X-Spam-Level: X-Spam-Status: No, score=-2.208 tagged_above=-999 required=5 tests=[AWL=-0.209, 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 pEdMRhQfbZ4S for ; Tue, 8 May 2012 01:47:29 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id D23FF21F85C2 for ; Tue, 8 May 2012 01:47: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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: L2vpn Digest, Vol 96, Issue 15 Date: Tue, 8 May 2012 11:49:22 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780CA6E@tlvmail1> In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410B5D@szxeml546-mbx.china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: L2vpn Digest, Vol 96, Issue 15 Thread-Index: AQHNKgNyPxr7nh+DX0S+AUfrSOoOpZa57ewAgARPYACAABdtgIAA8VnQgABOaUCAAAEZoIAABFOg References: <2691CE0099834E4A9C5044EEC662BB9D330F0740@dfweml506-mbx> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410ABC@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CA64@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410B5D@szxeml546-mbx.china.huawei.com> From: "Daniel Cohn" To: "Jiangyuanlong" , "Rogers, Josh" , "Lucy yong" , "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: Tue, 08 May 2012 08:47:32 -0000 Inline -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Tuesday, May 08, 2012 11:42 AM To: Daniel Cohn; Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 I don't think so. There may be different layers of OAM applicable to a service. Such as LSP layer, PW layer, and service layer. [DC] Agreed Now you cannot use a single LSP OAM to monitor the server layer of the E-Tree service (as 2 LSP may be involved). And the service layer of OAM for E-Tree may be distributed to different LSP paths. [DC] For E-Tree service OAM, you would perform OAM actions from MEPs associated to root or leaf ACs, so the E-OAM frames would naturally follow the root or leaf pseudowires and the LSPs that transport them. I don't see a limitation here. -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Tuesday, May 08, 2012 4:28 PM To: Jiangyuanlong; Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 Yuanlong, isn't this orthogonal to the issues we are discussing? I mean, there are different mechanisms to troubleshoot PWs, all of which are applicable to root/leaf PWs as to any other PWs. Or is there any specific limitation on root/leaf PW troubleshooting, compared to "regular" PWs used in VPLSs? Thanks, Daniel -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Jiangyuanlong Sent: Tuesday, May 08, 2012 7:04 AM To: Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 Josh,=20 Just some comments on this part: [JR] I don't see this any more of a problem than troubleshooting one. If LDP is used, a simple mols traceroute shows the path that ALL PW's to that PE take, regardless of which service (this VPLS or another VPLS instance). If RSVP is used, there should be a route-object that shows me the path, and allows me to troubleshoot. Additionally, if I wanted to have traffic engineering that impacted root-sourced and leaf-sourced traffic differently, I can do that with multi-PW, where I could not (save for ingress/egress) with the 2VLAN approach. PE should report signaling on second PW same as it does for the 100th PW between PE's. Again, I don't see the problem you are alluding to. I suppose you are referring to LSP Ping on the LSP layer, yes, it can oversee all the PWs in this LSP. If both root and leaf PW are in the same LSP, it can work. But there may well be multiple LSPs between a pair of PEs, and root/leaf PW may be transported on different LSPs. Another difficulty is, if ECMP is deployed and PW label as a bottom label is used for hashing, the OAM message may be load balanced on different paths. With regard to TE, you could use DS-TE, just as Lucy said, two PW do not guarantee they are traffic engineered. Thanks Yuanlong -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com]=20 Sent: Tuesday, May 08, 2012 5:22 AM To: Lucy yong; Sam Cao; l2vpn@ietf.org Cc: Jiangyuanlong Subject: Re: L2vpn Digest, Vol 96, Issue 15 Comments inline (and s/conquer/concur/) On 5/7/12 2:58 PM, "Lucy yong" wrote: >Sam, > >I concur with Yuanlong's reply on this. Please see inline. > >Lucy > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >Sam Cao >Sent: Friday, May 04, 2012 9:09 PM >To: l2vpn@ietf.org >Cc: Jiangyuanlong >Subject: RE: L2vpn Digest, Vol 96, Issue 15 > >Lucy/Yuanlong, > >I agree that we can not say which approach is better simply, but I really >agree with Josh's comments. Multi-PW is easy to implement E-Tree. >[[LY]] I don't get impression Josh state this. > >First of all, we discussed 2 approaches for a long time and many rounds, >and >for me, there are no pending issues on Multi-PW till now or co-authors of >multi-PW have given reasonable reply to L2VPN members' questions, but >there >are still pending issues for Dual-VLAN. Please trace the mailing list. >[[LY]] I interpret this as people want to spend time to finalize dual >VLAN solution. Multi-PW has some operation impact. How do operator to >maintain this service and be able to trouble shooting. How do you expect >traceroute work when using two PWs for one VPN? How do you expect PE >report when there is an error on one of two PWs? Do you have one FEC or >two FEC for a E-Tree in control plane? [JR] I don't see this any more of a problem than troubleshooting one. If LDP is used, a simple mols traceroute shows the path that ALL PW's to that PE take, regardless of which service (this VPLS or another VPLS instance). If RSVP is used, there should be a route-object that shows me the path, and allows me to troubleshoot. Additionally, if I wanted to have traffic engineering that impacted root-sourced and leaf-sourced traffic differently, I can do that with multi-PW, where I could not (save for ingress/egress) with the 2VLAN approach. PE should report signaling on second PW same as it does for the 100th PW between PE's. Again, I don't see the problem you are alluding to. > >Second, Sasha has his concern in NP, or forwarding performance. Compared >to >current VPLS, Multi-PW has a little effect on forwarding performance since >it reuse PW label as AC indicator; Dual-VLAN will have higher side effect >on >forwarding performance because it SHOULD use additional indicator. Is >there >one prototype for Dual-VLAN? BTW, there is no reply on chip limit. >[[LY]] in VPLS, PW label is used as VSI indicator, not AC. I disagree >your statement here. > >Third, the difference between Multi-PW and dual-VLAN is, transport ingress >traffic in one "LSP" or 2 "LSP". Multi-PW classifies and transforms >ingress >traffic into right "path", and egress just pop-out PW label and forward >the >frame to ACs. Dual-VLAN has more work on ingress PE or egress PE. >[[LY]] Don't understand the first part. When egress pop-out PW label, it >find corresponding VSI first, then perform MAC lookup associated to all >ACs. We can't assume there is one AC. > >Fourth, maybe Giles has figured this out, Dual-VLAN has capacity limit. >Only >4094 VLAN ID are available, so only 2K E-Tree instances can be supported >on >one PE for Dual-VLAN approach. There is no such limit for Multi-PW >approach, >[[LY]] If 4K VLAN ID is not an issue for VPLS, it is not an issue for >E-Tree. > >Finally, in this thread we don't make agreement on VLAN ID allocation. We >also have questions on VLAN ID negotiation among PEs (signaling protocol). >Yuanlong wishes to update, but there is no update till now. >[[LY]] This should not be the reason to judge on the solution. [JR] I tend to agree. > >For me, why IEEE uses VLAN ID to identify AC type? IEEE has no LABEL :), >and >it has label, it also wish to use label to identify AC types. I think that >both solutions need much time to be perfect. Mutli-PW has less extension >work to do. But now we are focusing on technical details and can not move >forward :). >[[LY]] VPN label is used for identify the VPN. It already has the >purpose. Overloading with other meaning has high potential causing a >problem. Hope you can investigate it more. Since you are very in favor of >multi-pw solution, it is not proper for you to come out the conclusion >which is better, because it is very biased. You are welcome to help on >completing either solution. [JR] this is humorous to me, because at one time, VLAN-ID was used to identify a single broadcast domain, and then later asymmetrical VID's were used to limit communication between endpoints of a broadcast domain (effectively creating two one-way broadcast domains, very similar to what we're accomplishing with ETREE). This should not be the reason to judge on the solution. > >Regards, >Lucy > >Lucy > >Thanks, > >Sam > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >l2vpn-request@ietf.org >Sent: Friday, May 04, 2012 10:31 PM >To: l2vpn@ietf.org >Subject: L2vpn Digest, Vol 96, Issue 15 > >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) > 2. Re: The status of the approaches to the E-Tree solution? > (Rogers, Josh) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Fri, 4 May 2012 14:16:36 +0000 >From: Lucy yong >To: "Rogers, Josh" , Jiangyuanlong > , Daniel Cohn , >"Fedyk, > Donald (Don)" , "Henderickx, Wim > (Wim)" >Cc: "l2vpn@ietf.org" >Subject: RE: The status of the approaches to the E-Tree solution? >Message-ID: <2691CE0099834E4A9C5044EEC662BB9D330E9114@dfweml505-mbx> >Content-Type: text/plain; charset=3D"iso-8859-2" > >Josh, > >You simply say that you don't like IEEE Tree solution. IEEE Tree solution >is >for ingress port to mark and for egress port to filter. > >Regards, >Lucy > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Friday, May 04, 2012 7:27 AM >To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >(Wim); >Lucy yong >Cc: l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >also separate the leaf traffic in the ingress PE and filter it there >(already detailed in the Optimization Mode in the I-D); if the egress PE >is attached with pure roots or with both roots and leafs, it seems all >traffic must be transported to the egress PE and be filtered there, I see >no difference in behaviour for these solutions. Or did I miss something? > > >The point is with the multi-PW method the traffic is split/separated (by >psuedowire) on the ingress PE, rather than the egress. The distinction is >2VLAN will 'classify' the frame on the ingress PE, so that the egress PE >knows how to forward it to the appropriate AC's. > >Both methods have inefficiencies (one duplicates traffic for transport, >while the other transports where it doesn't need to go). I like the idea >of classify and forwarding on the ingress PE, rather than marking it on >the ingress, and deciding on the egress. > >-Josh > > > >On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: > >>Josh, thank you for the comments, please see my further comments with >>[JY2]. >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Thursday, May 03, 2012 11:27 PM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>requirements from MEF, it has nothing to do with the solutions. Could you >>give a hint on how you can provision this service E-NNI otherwise? BTW, >>if >>configuring or signalling two PWs is not a problem, why configuring or >>signalling two VLANs will become a problem? After all, more nodes may >>need >>to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >>2VLAN (only T-PEs). >> >> >>There is no other way (if both MPLS domains are part of the same ETREE, >>rather than doing something more like H-VPLS, where one domain has point >>to points to the other domain which handles the ETREE instance) if you >>are >>using an ENNI. The other method, (not mentioned earlier) is tying the >>two >>MPLS domains together via labeled unicast (much preferred over E-NNI in >>my >>opinion) >> >>Configuring two VLAN's isn't really a 'problem' any more than two PW's. >>I >>wasn't saying that configuring two VLAN's was difficult, I was objecting >>to the statement that configuring two PW's is difficult. >> >>[JY2] Thanks, I see your point. I take the example of 2PW configuration >>just to show that using fixed global values to simplify configuration >>makes no sense. Personally I also don't think configuration is a problem >>for both solutions. >> >>I find the differences between these two methods rather slight. The >>'tie-breaker' for me is by placing the forwarding decision on the ingress >>PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >>more control over where the traffic goes, and in my mind it provides a >>cleaner destination between customer traffic and forwarding plane. I'm >>accustomed to looking at a psuedowire and knowing where its going, with >>the 2vlan method, I can see the psuedowire, but must go to the egress PE >>to see if it will be dropped there, or forwarded to one or more AC's. >> >>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>also separate the leaf traffic in the ingress PE and filter it there >>(already detailed in the Optimization Mode in the I-D); if the egress PE >>is attached with pure roots or with both roots and leafs, it seems all >>traffic must be transported to the egress PE and be filtered there, I see >>no difference in behaviour for these solutions. Or did I miss something? >> >>Again, the difference here is slight, and I would honestly be happy to >>see >>either of them come to fruition. Please don't infer that I think the >>2vlan method is 'bad' or has intrinsic problems, because I don't believe >>that. I just prefer the multi-PW method. >> >> >>-Josh >> >> >>On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: >> >>>Josh, please see my comments in line. >>> >>>Thanks >>>Yuanlong >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Thursday, May 03, 2012 10:51 AM >>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>(Wim); Lucy yong >>>Cc: l2vpn@ietf.org >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Yuanlong, >>> >>>Or better yet, include in the draft a 'standard' value for root sourced >>>VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You would also >>>have to require the the implementation NOT use global VLAN's, however >>>(since each instance would be using the same values). In this way, no >>>signaling or manual configuration is required for remote PE's to know >>>how >>>to classify traffic. >>>[JY] Indeed, we discussed this possibility during the f2f meeting in >>>Paris. But, there are some restrictions as you mentioned, and >>>furthermore: >>>1) Some vendors already used S-VLAN to distinguish their VSIs in the PE; >>>2) Forwarding plane of a PE needs to be revised to be aware of this VLAN >>>ID. >>>Therefore, this 'standard value' approach seems more disruptive compared >>>with the other means and not a good candidate option. >>> >>>Regarding switching PE's? Multi-PW means more than one PW, yes. I >>>don't >>>see this as a real problem. In general, design should try and avoid >>>using >>>S-PE's, but if you must, its going to mean extra work, no matter how you >>>look at it. Two PW's for each Etree being switched instead of one is >>>not >>>alarming or concerning to me. On the other hand, if you use a dot1q >>>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's >>>an >>>two egress VLAN's if you want the Etree to be handled on both sides (and >>>if you use the 'standard' VID's as I mentioned above, you'd have to do >>>mapping to non-standard and back) >>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>requirements from MEF, it has nothing to do with the solutions. Could >>>you >>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>if configuring or signalling two PWs is not a problem, why configuring >>>or >>>signalling two VLANs will become a problem? After all, more nodes may >>>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>>with 2VLAN (only T-PEs). >>> >>>In general, I still prefer multi-PW, primarily because I prefer the >>>separation of the traffic in the network's forwarding plane, rather than >>>shipping it everywhere and deciding whether to forward to the AC when it >>>gets to the egress PE. I'm having a hard time putting my finger exactly >>>on what it is, or articulating the idea, but it seems that by having the >>>traffic placed into two psuedowires, I have more flexibility and ease of >>>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>>PW's could really change that perception. >>>[JY] Are you saying that we need to develop a totally new forwarding >>>plane rather than using the Ethernet forwarding plane as described in >>>the >>>existing work? >>> >>>I hope we can move forward with one of these soon, >>>[JY] me too. >>> >>>Josh >>> >>> >>>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >>> >>>>Daniel, >>>> >>>>Not aware that we had a discussion on this before, but IMHO the >>>>allocation of internal S-VLAN can be automatic, and manuel >>>>configuration >>>>of this mapping may not be needed at all. For example, an S-VLAN >>>>allocation module in the management plane in a PE can do this kind of >>>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>>way from a free S-VLAN ID pool. Once the interal S-VLANs are allocated, >>>>the mapping is determined and no other configuration is needed. >>>> >>>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>>allocate >>>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to allocate >>>>two S-VLANs in the VPLS domain. >>>> >>>>On the other hand, for the multi-PW approach, two PWs need to be >>>>configured for a E-Tree service. When MS-PW is used in the network, for >>>>every S-PE, we need to configure two ingress PW segments and two egress >>>>PW segments. In this case, I don't think we need to use fixed PW labels >>>>across the network for fear of configuration complexity. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 8:01 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Inline. >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 12:30 PM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, Please see my comments in line. >>>> >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 3:55 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Yuanlong, >>>> >>>>The problem is not with the total number of S-VLAN IDs, I agree that >>>>normally there won't be more than 2047. The problem is that if you >>>>don't >>>>support all VLAN IDs, you need S-VLAN space coordination with the >>>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to >>>>2047". >>>>Which won't always be in line with an existing deployment. >>>>[JY] This is not the case. If the total number is no more than 2047, it >>>>surely can be supported. The S-VLAN space of user domain is totally >>>>different from the S-VLAN in the provider domain and they can be >>>>overlapped, I don't see why we need S-VLAN space coordination between >>>>them. >>>> >>>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>>fixed, and therefore the IEEE S-VID that can be supported is also >>>>fixed. >>>> >>>>Of course you can configure the mapping in each PE according to >>>>operator >>>>requirements but as we discussed before this increases complexity. >>>> >>>>Relying on PBB-VPLS imposes additional limitations on backward >>>>compatibility. >>>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>>think they may well need MAC-in-MAC in their networks for the >>>>scalability issue. As you know, only PBB VPLS can provide both. >>>> >>>>Daniel >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 5:07 AM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, >>>> >>>>As you can see, both cases are discussed in the I-D. >>>> >>>>With regard to case 1) (that is, S-VLAN translation), since the access >>>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>>they need to be configured on a PE anyway, and as the past emails by >>>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>>mapping. >>>> >>>>With regard to S-VID space reduction, the constraint is valid only when >>>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>>typical and with no such limits as we already discussed in the f2f >>>>meeting. >>>> >>>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>>described (not sure this is a valid use case in real life), PBB-VPLS >>>>can >>>>still be used. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Monday, April 30, 2012 10:34 PM >>>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>Jiangyuanlong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>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] >>>>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 >>>> >>>>-------------------------------------------------------------------- -- >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to >>>copyright belonging to Time Warner Cable. This E-mail is intended solely >>>for the use of the individual or entity to which it is addressed. If you >>>are not the intended recipient of this E-mail, you are hereby notified >>>that any dissemination, distribution, copying, or action taken in >>>relation to the contents of and attachments to this E-mail is strictly >>>prohibited and may be unlawful. If you have received this 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. > > >------------------------------ > >Message: 2 >Date: Fri, 4 May 2012 10:30:38 -0400 >From: "Rogers, Josh" >To: Lucy yong , Jiangyuanlong > , Daniel Cohn , >"Fedyk, > Donald (Don)" , "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"iso-8859-2" > >To be more accurate, I like it less than the multi-PW solution. I'd be >happy to use the 2VLAN solution in the real world, if it was ratified as >the standard. > > > >On 5/4/12 9:16 AM, "Lucy yong" wrote: > >>Josh, >> >>You simply say that you don't like IEEE Tree solution. IEEE Tree solution >>is for ingress port to mark and for egress port to filter. >> >>Regards, >>Lucy >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Friday, May 04, 2012 7:27 AM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>also separate the leaf traffic in the ingress PE and filter it there >>(already detailed in the Optimization Mode in the I-D); if the egress PE >>is attached with pure roots or with both roots and leafs, it seems all >>traffic must be transported to the egress PE and be filtered there, I see >>no difference in behaviour for these solutions. Or did I miss something? >> >> >>The point is with the multi-PW method the traffic is split/separated (by >>psuedowire) on the ingress PE, rather than the egress. The distinction >>is >>2VLAN will 'classify' the frame on the ingress PE, so that the egress PE >>knows how to forward it to the appropriate AC's. >> >>Both methods have inefficiencies (one duplicates traffic for transport, >>while the other transports where it doesn't need to go). I like the idea >>of classify and forwarding on the ingress PE, rather than marking it on >>the ingress, and deciding on the egress. >> >>-Josh >> >> >> >>On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: >> >>>Josh, thank you for the comments, please see my further comments with >>>[JY2]. >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Thursday, May 03, 2012 11:27 PM >>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>(Wim); Lucy yong >>>Cc: l2vpn@ietf.org >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>requirements from MEF, it has nothing to do with the solutions. Could >>>you >>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>if >>>configuring or signalling two PWs is not a problem, why configuring or >>>signalling two VLANs will become a problem? After all, more nodes may >>>need >>>to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >>>2VLAN (only T-PEs). >>> >>> >>>There is no other way (if both MPLS domains are part of the same ETREE, >>>rather than doing something more like H-VPLS, where one domain has point >>>to points to the other domain which handles the ETREE instance) if you >>>are >>>using an ENNI. The other method, (not mentioned earlier) is tying the >>>two >>>MPLS domains together via labeled unicast (much preferred over E-NNI in >>>my >>>opinion) >>> >>>Configuring two VLAN's isn't really a 'problem' any more than two PW's. >>>I >>>wasn't saying that configuring two VLAN's was difficult, I was objecting >>>to the statement that configuring two PW's is difficult. >>> >>>[JY2] Thanks, I see your point. I take the example of 2PW configuration >>>just to show that using fixed global values to simplify configuration >>>makes no sense. Personally I also don't think configuration is a problem >>>for both solutions. >>> >>>I find the differences between these two methods rather slight. The >>>'tie-breaker' for me is by placing the forwarding decision on the >>>ingress >>>PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >>>more control over where the traffic goes, and in my mind it provides a >>>cleaner destination between customer traffic and forwarding plane. I'm >>>accustomed to looking at a psuedowire and knowing where its going, with >>>the 2vlan method, I can see the psuedowire, but must go to the egress PE >>>to see if it will be dropped there, or forwarded to one or more AC's. >>> >>>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>>also separate the leaf traffic in the ingress PE and filter it there >>>(already detailed in the Optimization Mode in the I-D); if the egress PE >>>is attached with pure roots or with both roots and leafs, it seems all >>>traffic must be transported to the egress PE and be filtered there, I >>>see >>>no difference in behaviour for these solutions. Or did I miss something? >>> >>>Again, the difference here is slight, and I would honestly be happy to >>>see >>>either of them come to fruition. Please don't infer that I think the >>>2vlan method is 'bad' or has intrinsic problems, because I don't believe >>>that. I just prefer the multi-PW method. >>> >>> >>>-Josh >>> >>> >>>On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: >>> >>>>Josh, please see my comments in line. >>>> >>>>Thanks >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>>Sent: Thursday, May 03, 2012 10:51 AM >>>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>>(Wim); Lucy yong >>>>Cc: l2vpn@ietf.org >>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>> >>>>Yuanlong, >>>> >>>>Or better yet, include in the draft a 'standard' value for root sourced >>>>VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You = would also >>>>have to require the the implementation NOT use global VLAN's, however >>>>(since each instance would be using the same values). In this way, no >>>>signaling or manual configuration is required for remote PE's to know >>>>how >>>>to classify traffic. >>>>[JY] Indeed, we discussed this possibility during the f2f meeting in >>>>Paris. But, there are some restrictions as you mentioned, and >>>>furthermore: >>>>1) Some vendors already used S-VLAN to distinguish their VSIs in the >>>>PE; >>>>2) Forwarding plane of a PE needs to be revised to be aware of this >>>>VLAN >>>>ID. >>>>Therefore, this 'standard value' approach seems more disruptive >>>>compared >>>>with the other means and not a good candidate option. >>>> >>>>Regarding switching PE's? Multi-PW means more than one PW, yes. I >>>>don't >>>>see this as a real problem. In general, design should try and avoid >>>>using >>>>S-PE's, but if you must, its going to mean extra work, no matter how >>>>you >>>>look at it. Two PW's for each Etree being switched instead of one is >>>>not >>>>alarming or concerning to me. On the other hand, if you use a dot1q >>>>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's >>>>an >>>>two egress VLAN's if you want the Etree to be handled on both sides >>>>(and >>>>if you use the 'standard' VID's as I mentioned above, you'd have to do >>>>mapping to non-standard and back) >>>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>>requirements from MEF, it has nothing to do with the solutions. Could >>>>you >>>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>>if configuring or signalling two PWs is not a problem, why configuring >>>>or >>>>signalling two VLANs will become a problem? After all, more nodes may >>>>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>>>with 2VLAN (only T-PEs). >>>> >>>>In general, I still prefer multi-PW, primarily because I prefer the >>>>separation of the traffic in the network's forwarding plane, rather >>>>than >>>>shipping it everywhere and deciding whether to forward to the AC when >>>>it >>>>gets to the egress PE. I'm having a hard time putting my finger >>>>exactly >>>>on what it is, or articulating the idea, but it seems that by having >>>>the >>>>traffic placed into two psuedowires, I have more flexibility and ease >>>>of >>>>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>>>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>>>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>>>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>>>PW's could really change that perception. >>>>[JY] Are you saying that we need to develop a totally new forwarding >>>>plane rather than using the Ethernet forwarding plane as described in >>>>the >>>>existing work? >>>> >>>>I hope we can move forward with one of these soon, >>>>[JY] me too. >>>> >>>>Josh >>>> >>>> >>>>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >>>> >>>>>Daniel, >>>>> >>>>>Not aware that we had a discussion on this before, but IMHO the >>>>>allocation of internal S-VLAN can be automatic, and manuel >>>>>configuration >>>>>of this mapping may not be needed at all. For example, an S-VLAN >>>>>allocation module in the management plane in a PE can do this kind of >>>>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>>>way from a free S-VLAN ID pool. Once the interal S-VLANs are >>>>>allocated, >>>>>the mapping is determined and no other configuration is needed. >>>>> >>>>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>>>allocate >>>>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to >>>>>allocate >>>>>two S-VLANs in the VPLS domain. >>>>> >>>>>On the other hand, for the multi-PW approach, two PWs need to be >>>>>configured for a E-Tree service. When MS-PW is used in the network, >>>>>for >>>>>every S-PE, we need to configure two ingress PW segments and two >>>>>egress >>>>>PW segments. In this case, I don't think we need to use fixed PW >>>>>labels >>>>>across the network for fear of configuration complexity. >>>>> >>>>>Regards, >>>>>Yuanlong >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>Sent: Wednesday, May 02, 2012 8:01 PM >>>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; >>>>>josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Inline. >>>>> >>>>>-----Original Message----- >>>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>>Sent: Wednesday, May 02, 2012 12:30 PM >>>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; >>>>>josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Hi Daniel, Please see my comments in line. >>>>> >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>Sent: Wednesday, May 02, 2012 3:55 PM >>>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Hi Yuanlong, >>>>> >>>>>The problem is not with the total number of S-VLAN IDs, I agree that >>>>>normally there won't be more than 2047. The problem is that if you >>>>>don't >>>>>support all VLAN IDs, you need S-VLAN space coordination with the >>>>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to >>>>>2047". >>>>>Which won't always be in line with an existing deployment. >>>>>[JY] This is not the case. If the total number is no more than 2047, >>>>>it >>>>>surely can be supported. The S-VLAN space of user domain is totally >>>>>different from the S-VLAN in the provider domain and they can be >>>>>overlapped, I don't see why we need S-VLAN space coordination between >>>>>them. >>>>> >>>>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>>>fixed, and therefore the IEEE S-VID that can be supported is also >>>>>fixed. >>>>> >>>>>Of course you can configure the mapping in each PE according to >>>>>operator >>>>>requirements but as we discussed before this increases complexity. >>>>> >>>>>Relying on PBB-VPLS imposes additional limitations on backward >>>>>compatibility. >>>>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>>>think they may well need MAC-in-MAC in their networks for the >>>>>scalability issue. As you know, only PBB VPLS can provide both. >>>>> >>>>>Daniel >>>>> >>>>>-----Original Message----- >>>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>>Sent: Wednesday, May 02, 2012 5:07 AM >>>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; >>>>>josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Hi Daniel, >>>>> >>>>>As you can see, both cases are discussed in the I-D. >>>>> >>>>>With regard to case 1) (that is, S-VLAN translation), since the access >>>>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>>>they need to be configured on a PE anyway, and as the past emails by >>>>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>>>mapping. >>>>> >>>>>With regard to S-VID space reduction, the constraint is valid only >>>>>when >>>>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>>>typical and with no such limits as we already discussed in the f2f >>>>>meeting. >>>>> >>>>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>>>described (not sure this is a valid use case in real life), PBB-VPLS >>>>>can >>>>>still be used. >>>>> >>>>>Regards, >>>>>Yuanlong >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>Sent: Monday, April 30, 2012 10:34 PM >>>>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>>Jiangyuanlong; josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>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] >>>>>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 >>>>> >>>>>------------------------------------------------------------------- --- >>>> >>>> >>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>proprietary information, which is privileged, confidential, or subject >>>>to >>>>copyright belonging to Time Warner Cable. This E-mail is intended >>>>solely >>>>for the use of the individual or entity to which it is addressed. If >>>>you >>>>are not the intended recipient of this E-mail, you are hereby notified >>>>that any dissemination, distribution, copying, or action taken in >>>>relation to the contents of and attachments to this E-mail is strictly >>>>prohibited and may be unlawful. If you have received this 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 and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for >the use of the individual or entity to which it is addressed. If you are >not >the intended recipient of this E-mail, you are hereby notified that any >dissemination, distribution, copying, or action taken in relation to the >contents of and attachments to this E-mail is strictly prohibited and may >be >unlawful. If you have received this 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 96, Issue 15 >************************************* > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this 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 May 8 05:20: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 436D421F8541 for ; Tue, 8 May 2012 05:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.136 X-Spam-Level: X-Spam-Status: No, score=-2.136 tagged_above=-999 required=5 tests=[AWL=-0.137, 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 0RVuZ9M3+aPO for ; Tue, 8 May 2012 05:20:30 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 54C0721F84B6 for ; Tue, 8 May 2012 05:20:30 -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 AFX78321; Tue, 08 May 2012 08:20:30 -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; Tue, 8 May 2012 05:18:29 -0700 Received: from SZXEML426-HUB.china.huawei.com (10.72.61.34) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 8 May 2012 05:18:32 -0700 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.183]) by szxeml426-hub.china.huawei.com ([10.72.61.34]) with mapi id 14.01.0323.003; Tue, 8 May 2012 20:18:22 +0800 From: Jiangyuanlong To: Daniel Cohn , "Rogers, Josh" , Lucy yong , Sam Cao , "l2vpn@ietf.org" Subject: RE: L2vpn Digest, Vol 96, Issue 15 Thread-Topic: L2vpn Digest, Vol 96, Issue 15 Thread-Index: AQHNKgNyPxr7nh+DX0S+AUfrSOoOpZa57ewAgARPYACAABdtgIAA8VnQgABOaUCAAAEZoIAABFOggAAHB2A= Date: Tue, 8 May 2012 12:18:21 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410BBC@szxeml546-mbx.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D330F0740@dfweml506-mbx> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410ABC@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CA64@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410B5D@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CA6E@tlvmail1> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA08130780CA6E@tlvmail1> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.40.73] 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: Tue, 08 May 2012 12:20:34 -0000 Inline -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Tuesday, May 08, 2012 11:42 AM To: Daniel Cohn; Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 I don't think so. There may be different layers of OAM applicable to a service. Such as LSP layer, PW layer, and service layer. [DC] Agreed Now you cannot use a single LSP OAM to monitor the server layer of the E-Tree service (as 2 LSP may be involved). And the service layer of OAM for E-Tree may be distributed to different LSP paths. [DC] For E-Tree service OAM, you would perform OAM actions from MEPs associated to root or leaf ACs, so the E-OAM frames would naturally follow the root or leaf pseudowires and the LSPs that transport them. I don't see a limitation here. [JY] Now you need to monitor two LSPs and/or two PWs between mixed PEs for = this E-Tree. Besides the UP MEPs (associated with access port) as you mentioned, DOWN ME= Ps may also be needed (facing core) where both root and leaf traffic cross,= not sure how you will configure OAM for them. Regards, Yuanlong -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Tuesday, May 08, 2012 4:28 PM To: Jiangyuanlong; Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 Yuanlong, isn't this orthogonal to the issues we are discussing? I mean, there are different mechanisms to troubleshoot PWs, all of which are applicable to root/leaf PWs as to any other PWs. Or is there any specific limitation on root/leaf PW troubleshooting, compared to "regular" PWs used in VPLSs? Thanks, Daniel -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Jiangyuanlong Sent: Tuesday, May 08, 2012 7:04 AM To: Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 Josh,=20 Just some comments on this part: [JR] I don't see this any more of a problem than troubleshooting one. If LDP is used, a simple mols traceroute shows the path that ALL PW's to that PE take, regardless of which service (this VPLS or another VPLS instance). If RSVP is used, there should be a route-object that shows me the path, and allows me to troubleshoot. Additionally, if I wanted to have traffic engineering that impacted root-sourced and leaf-sourced traffic differently, I can do that with multi-PW, where I could not (save for ingress/egress) with the 2VLAN approach. PE should report signaling on second PW same as it does for the 100th PW between PE's. Again, I don't see the problem you are alluding to. I suppose you are referring to LSP Ping on the LSP layer, yes, it can oversee all the PWs in this LSP. If both root and leaf PW are in the same LSP, it can work. But there may well be multiple LSPs between a pair of PEs, and root/leaf PW may be transported on different LSPs. Another difficulty is, if ECMP is deployed and PW label as a bottom label is used for hashing, the OAM message may be load balanced on different paths. With regard to TE, you could use DS-TE, just as Lucy said, two PW do not guarantee they are traffic engineered. Thanks Yuanlong -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com]=20 Sent: Tuesday, May 08, 2012 5:22 AM To: Lucy yong; Sam Cao; l2vpn@ietf.org Cc: Jiangyuanlong Subject: Re: L2vpn Digest, Vol 96, Issue 15 Comments inline (and s/conquer/concur/) On 5/7/12 2:58 PM, "Lucy yong" wrote: >Sam, > >I concur with Yuanlong's reply on this. Please see inline. > >Lucy > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >Sam Cao >Sent: Friday, May 04, 2012 9:09 PM >To: l2vpn@ietf.org >Cc: Jiangyuanlong >Subject: RE: L2vpn Digest, Vol 96, Issue 15 > >Lucy/Yuanlong, > >I agree that we can not say which approach is better simply, but I really >agree with Josh's comments. Multi-PW is easy to implement E-Tree. >[[LY]] I don't get impression Josh state this. > >First of all, we discussed 2 approaches for a long time and many rounds, >and >for me, there are no pending issues on Multi-PW till now or co-authors of >multi-PW have given reasonable reply to L2VPN members' questions, but >there >are still pending issues for Dual-VLAN. Please trace the mailing list. >[[LY]] I interpret this as people want to spend time to finalize dual >VLAN solution. Multi-PW has some operation impact. How do operator to >maintain this service and be able to trouble shooting. How do you expect >traceroute work when using two PWs for one VPN? How do you expect PE >report when there is an error on one of two PWs? Do you have one FEC or >two FEC for a E-Tree in control plane? [JR] I don't see this any more of a problem than troubleshooting one. If LDP is used, a simple mols traceroute shows the path that ALL PW's to that PE take, regardless of which service (this VPLS or another VPLS instance). If RSVP is used, there should be a route-object that shows me the path, and allows me to troubleshoot. Additionally, if I wanted to have traffic engineering that impacted root-sourced and leaf-sourced traffic differently, I can do that with multi-PW, where I could not (save for ingress/egress) with the 2VLAN approach. PE should report signaling on second PW same as it does for the 100th PW between PE's. Again, I don't see the problem you are alluding to. > >Second, Sasha has his concern in NP, or forwarding performance. Compared >to >current VPLS, Multi-PW has a little effect on forwarding performance since >it reuse PW label as AC indicator; Dual-VLAN will have higher side effect >on >forwarding performance because it SHOULD use additional indicator. Is >there >one prototype for Dual-VLAN? BTW, there is no reply on chip limit. >[[LY]] in VPLS, PW label is used as VSI indicator, not AC. I disagree >your statement here. > >Third, the difference between Multi-PW and dual-VLAN is, transport ingress >traffic in one "LSP" or 2 "LSP". Multi-PW classifies and transforms >ingress >traffic into right "path", and egress just pop-out PW label and forward >the >frame to ACs. Dual-VLAN has more work on ingress PE or egress PE. >[[LY]] Don't understand the first part. When egress pop-out PW label, it >find corresponding VSI first, then perform MAC lookup associated to all >ACs. We can't assume there is one AC. > >Fourth, maybe Giles has figured this out, Dual-VLAN has capacity limit. >Only >4094 VLAN ID are available, so only 2K E-Tree instances can be supported >on >one PE for Dual-VLAN approach. There is no such limit for Multi-PW >approach, >[[LY]] If 4K VLAN ID is not an issue for VPLS, it is not an issue for >E-Tree. > >Finally, in this thread we don't make agreement on VLAN ID allocation. We >also have questions on VLAN ID negotiation among PEs (signaling protocol). >Yuanlong wishes to update, but there is no update till now. >[[LY]] This should not be the reason to judge on the solution. [JR] I tend to agree. > >For me, why IEEE uses VLAN ID to identify AC type? IEEE has no LABEL :), >and >it has label, it also wish to use label to identify AC types. I think that >both solutions need much time to be perfect. Mutli-PW has less extension >work to do. But now we are focusing on technical details and can not move >forward :). >[[LY]] VPN label is used for identify the VPN. It already has the >purpose. Overloading with other meaning has high potential causing a >problem. Hope you can investigate it more. Since you are very in favor of >multi-pw solution, it is not proper for you to come out the conclusion >which is better, because it is very biased. You are welcome to help on >completing either solution. [JR] this is humorous to me, because at one time, VLAN-ID was used to identify a single broadcast domain, and then later asymmetrical VID's were used to limit communication between endpoints of a broadcast domain (effectively creating two one-way broadcast domains, very similar to what we're accomplishing with ETREE). This should not be the reason to judge on the solution. > >Regards, >Lucy > >Lucy > >Thanks, > >Sam > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >l2vpn-request@ietf.org >Sent: Friday, May 04, 2012 10:31 PM >To: l2vpn@ietf.org >Subject: L2vpn Digest, Vol 96, Issue 15 > >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) > 2. Re: The status of the approaches to the E-Tree solution? > (Rogers, Josh) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Fri, 4 May 2012 14:16:36 +0000 >From: Lucy yong >To: "Rogers, Josh" , Jiangyuanlong > , Daniel Cohn , >"Fedyk, > Donald (Don)" , "Henderickx, Wim > (Wim)" >Cc: "l2vpn@ietf.org" >Subject: RE: The status of the approaches to the E-Tree solution? >Message-ID: <2691CE0099834E4A9C5044EEC662BB9D330E9114@dfweml505-mbx> >Content-Type: text/plain; charset=3D"iso-8859-2" > >Josh, > >You simply say that you don't like IEEE Tree solution. IEEE Tree solution >is >for ingress port to mark and for egress port to filter. > >Regards, >Lucy > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Friday, May 04, 2012 7:27 AM >To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >(Wim); >Lucy yong >Cc: l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >also separate the leaf traffic in the ingress PE and filter it there >(already detailed in the Optimization Mode in the I-D); if the egress PE >is attached with pure roots or with both roots and leafs, it seems all >traffic must be transported to the egress PE and be filtered there, I see >no difference in behaviour for these solutions. Or did I miss something? > > >The point is with the multi-PW method the traffic is split/separated (by >psuedowire) on the ingress PE, rather than the egress. The distinction is >2VLAN will 'classify' the frame on the ingress PE, so that the egress PE >knows how to forward it to the appropriate AC's. > >Both methods have inefficiencies (one duplicates traffic for transport, >while the other transports where it doesn't need to go). I like the idea >of classify and forwarding on the ingress PE, rather than marking it on >the ingress, and deciding on the egress. > >-Josh > > > >On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: > >>Josh, thank you for the comments, please see my further comments with >>[JY2]. >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Thursday, May 03, 2012 11:27 PM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>requirements from MEF, it has nothing to do with the solutions. Could you >>give a hint on how you can provision this service E-NNI otherwise? BTW, >>if >>configuring or signalling two PWs is not a problem, why configuring or >>signalling two VLANs will become a problem? After all, more nodes may >>need >>to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >>2VLAN (only T-PEs). >> >> >>There is no other way (if both MPLS domains are part of the same ETREE, >>rather than doing something more like H-VPLS, where one domain has point >>to points to the other domain which handles the ETREE instance) if you >>are >>using an ENNI. The other method, (not mentioned earlier) is tying the >>two >>MPLS domains together via labeled unicast (much preferred over E-NNI in >>my >>opinion) >> >>Configuring two VLAN's isn't really a 'problem' any more than two PW's. >>I >>wasn't saying that configuring two VLAN's was difficult, I was objecting >>to the statement that configuring two PW's is difficult. >> >>[JY2] Thanks, I see your point. I take the example of 2PW configuration >>just to show that using fixed global values to simplify configuration >>makes no sense. Personally I also don't think configuration is a problem >>for both solutions. >> >>I find the differences between these two methods rather slight. The >>'tie-breaker' for me is by placing the forwarding decision on the ingress >>PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >>more control over where the traffic goes, and in my mind it provides a >>cleaner destination between customer traffic and forwarding plane. I'm >>accustomed to looking at a psuedowire and knowing where its going, with >>the 2vlan method, I can see the psuedowire, but must go to the egress PE >>to see if it will be dropped there, or forwarded to one or more AC's. >> >>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>also separate the leaf traffic in the ingress PE and filter it there >>(already detailed in the Optimization Mode in the I-D); if the egress PE >>is attached with pure roots or with both roots and leafs, it seems all >>traffic must be transported to the egress PE and be filtered there, I see >>no difference in behaviour for these solutions. Or did I miss something? >> >>Again, the difference here is slight, and I would honestly be happy to >>see >>either of them come to fruition. Please don't infer that I think the >>2vlan method is 'bad' or has intrinsic problems, because I don't believe >>that. I just prefer the multi-PW method. >> >> >>-Josh >> >> >>On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: >> >>>Josh, please see my comments in line. >>> >>>Thanks >>>Yuanlong >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Thursday, May 03, 2012 10:51 AM >>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>(Wim); Lucy yong >>>Cc: l2vpn@ietf.org >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Yuanlong, >>> >>>Or better yet, include in the draft a 'standard' value for root sourced >>>VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You would also >>>have to require the the implementation NOT use global VLAN's, however >>>(since each instance would be using the same values). In this way, no >>>signaling or manual configuration is required for remote PE's to know >>>how >>>to classify traffic. >>>[JY] Indeed, we discussed this possibility during the f2f meeting in >>>Paris. But, there are some restrictions as you mentioned, and >>>furthermore: >>>1) Some vendors already used S-VLAN to distinguish their VSIs in the PE; >>>2) Forwarding plane of a PE needs to be revised to be aware of this VLAN >>>ID. >>>Therefore, this 'standard value' approach seems more disruptive compared >>>with the other means and not a good candidate option. >>> >>>Regarding switching PE's? Multi-PW means more than one PW, yes. I >>>don't >>>see this as a real problem. In general, design should try and avoid >>>using >>>S-PE's, but if you must, its going to mean extra work, no matter how you >>>look at it. Two PW's for each Etree being switched instead of one is >>>not >>>alarming or concerning to me. On the other hand, if you use a dot1q >>>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's >>>an >>>two egress VLAN's if you want the Etree to be handled on both sides (and >>>if you use the 'standard' VID's as I mentioned above, you'd have to do >>>mapping to non-standard and back) >>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>requirements from MEF, it has nothing to do with the solutions. Could >>>you >>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>if configuring or signalling two PWs is not a problem, why configuring >>>or >>>signalling two VLANs will become a problem? After all, more nodes may >>>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>>with 2VLAN (only T-PEs). >>> >>>In general, I still prefer multi-PW, primarily because I prefer the >>>separation of the traffic in the network's forwarding plane, rather than >>>shipping it everywhere and deciding whether to forward to the AC when it >>>gets to the egress PE. I'm having a hard time putting my finger exactly >>>on what it is, or articulating the idea, but it seems that by having the >>>traffic placed into two psuedowires, I have more flexibility and ease of >>>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>>PW's could really change that perception. >>>[JY] Are you saying that we need to develop a totally new forwarding >>>plane rather than using the Ethernet forwarding plane as described in >>>the >>>existing work? >>> >>>I hope we can move forward with one of these soon, >>>[JY] me too. >>> >>>Josh >>> >>> >>>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >>> >>>>Daniel, >>>> >>>>Not aware that we had a discussion on this before, but IMHO the >>>>allocation of internal S-VLAN can be automatic, and manuel >>>>configuration >>>>of this mapping may not be needed at all. For example, an S-VLAN >>>>allocation module in the management plane in a PE can do this kind of >>>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>>way from a free S-VLAN ID pool. Once the interal S-VLANs are allocated, >>>>the mapping is determined and no other configuration is needed. >>>> >>>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>>allocate >>>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to allocate >>>>two S-VLANs in the VPLS domain. >>>> >>>>On the other hand, for the multi-PW approach, two PWs need to be >>>>configured for a E-Tree service. When MS-PW is used in the network, for >>>>every S-PE, we need to configure two ingress PW segments and two egress >>>>PW segments. In this case, I don't think we need to use fixed PW labels >>>>across the network for fear of configuration complexity. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 8:01 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Inline. >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 12:30 PM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, Please see my comments in line. >>>> >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 3:55 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Yuanlong, >>>> >>>>The problem is not with the total number of S-VLAN IDs, I agree that >>>>normally there won't be more than 2047. The problem is that if you >>>>don't >>>>support all VLAN IDs, you need S-VLAN space coordination with the >>>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to >>>>2047". >>>>Which won't always be in line with an existing deployment. >>>>[JY] This is not the case. If the total number is no more than 2047, it >>>>surely can be supported. The S-VLAN space of user domain is totally >>>>different from the S-VLAN in the provider domain and they can be >>>>overlapped, I don't see why we need S-VLAN space coordination between >>>>them. >>>> >>>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>>fixed, and therefore the IEEE S-VID that can be supported is also >>>>fixed. >>>> >>>>Of course you can configure the mapping in each PE according to >>>>operator >>>>requirements but as we discussed before this increases complexity. >>>> >>>>Relying on PBB-VPLS imposes additional limitations on backward >>>>compatibility. >>>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>>think they may well need MAC-in-MAC in their networks for the >>>>scalability issue. As you know, only PBB VPLS can provide both. >>>> >>>>Daniel >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 5:07 AM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, >>>> >>>>As you can see, both cases are discussed in the I-D. >>>> >>>>With regard to case 1) (that is, S-VLAN translation), since the access >>>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>>they need to be configured on a PE anyway, and as the past emails by >>>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>>mapping. >>>> >>>>With regard to S-VID space reduction, the constraint is valid only when >>>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>>typical and with no such limits as we already discussed in the f2f >>>>meeting. >>>> >>>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>>described (not sure this is a valid use case in real life), PBB-VPLS >>>>can >>>>still be used. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Monday, April 30, 2012 10:34 PM >>>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>Jiangyuanlong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>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] >>>>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 >>>> >>>>-------------------------------------------------------------------- -- >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to >>>copyright belonging to Time Warner Cable. This E-mail is intended solely >>>for the use of the individual or entity to which it is addressed. If you >>>are not the intended recipient of this E-mail, you are hereby notified >>>that any dissemination, distribution, copying, or action taken in >>>relation to the contents of and attachments to this E-mail is strictly >>>prohibited and may be unlawful. If you have received this 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. > > >------------------------------ > >Message: 2 >Date: Fri, 4 May 2012 10:30:38 -0400 >From: "Rogers, Josh" >To: Lucy yong , Jiangyuanlong > , Daniel Cohn , >"Fedyk, > Donald (Don)" , "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"iso-8859-2" > >To be more accurate, I like it less than the multi-PW solution. I'd be >happy to use the 2VLAN solution in the real world, if it was ratified as >the standard. > > > >On 5/4/12 9:16 AM, "Lucy yong" wrote: > >>Josh, >> >>You simply say that you don't like IEEE Tree solution. IEEE Tree solution >>is for ingress port to mark and for egress port to filter. >> >>Regards, >>Lucy >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Friday, May 04, 2012 7:27 AM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>also separate the leaf traffic in the ingress PE and filter it there >>(already detailed in the Optimization Mode in the I-D); if the egress PE >>is attached with pure roots or with both roots and leafs, it seems all >>traffic must be transported to the egress PE and be filtered there, I see >>no difference in behaviour for these solutions. Or did I miss something? >> >> >>The point is with the multi-PW method the traffic is split/separated (by >>psuedowire) on the ingress PE, rather than the egress. The distinction >>is >>2VLAN will 'classify' the frame on the ingress PE, so that the egress PE >>knows how to forward it to the appropriate AC's. >> >>Both methods have inefficiencies (one duplicates traffic for transport, >>while the other transports where it doesn't need to go). I like the idea >>of classify and forwarding on the ingress PE, rather than marking it on >>the ingress, and deciding on the egress. >> >>-Josh >> >> >> >>On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: >> >>>Josh, thank you for the comments, please see my further comments with >>>[JY2]. >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Thursday, May 03, 2012 11:27 PM >>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>(Wim); Lucy yong >>>Cc: l2vpn@ietf.org >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>requirements from MEF, it has nothing to do with the solutions. Could >>>you >>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>if >>>configuring or signalling two PWs is not a problem, why configuring or >>>signalling two VLANs will become a problem? After all, more nodes may >>>need >>>to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >>>2VLAN (only T-PEs). >>> >>> >>>There is no other way (if both MPLS domains are part of the same ETREE, >>>rather than doing something more like H-VPLS, where one domain has point >>>to points to the other domain which handles the ETREE instance) if you >>>are >>>using an ENNI. The other method, (not mentioned earlier) is tying the >>>two >>>MPLS domains together via labeled unicast (much preferred over E-NNI in >>>my >>>opinion) >>> >>>Configuring two VLAN's isn't really a 'problem' any more than two PW's. >>>I >>>wasn't saying that configuring two VLAN's was difficult, I was objecting >>>to the statement that configuring two PW's is difficult. >>> >>>[JY2] Thanks, I see your point. I take the example of 2PW configuration >>>just to show that using fixed global values to simplify configuration >>>makes no sense. Personally I also don't think configuration is a problem >>>for both solutions. >>> >>>I find the differences between these two methods rather slight. The >>>'tie-breaker' for me is by placing the forwarding decision on the >>>ingress >>>PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >>>more control over where the traffic goes, and in my mind it provides a >>>cleaner destination between customer traffic and forwarding plane. I'm >>>accustomed to looking at a psuedowire and knowing where its going, with >>>the 2vlan method, I can see the psuedowire, but must go to the egress PE >>>to see if it will be dropped there, or forwarded to one or more AC's. >>> >>>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>>also separate the leaf traffic in the ingress PE and filter it there >>>(already detailed in the Optimization Mode in the I-D); if the egress PE >>>is attached with pure roots or with both roots and leafs, it seems all >>>traffic must be transported to the egress PE and be filtered there, I >>>see >>>no difference in behaviour for these solutions. Or did I miss something? >>> >>>Again, the difference here is slight, and I would honestly be happy to >>>see >>>either of them come to fruition. Please don't infer that I think the >>>2vlan method is 'bad' or has intrinsic problems, because I don't believe >>>that. I just prefer the multi-PW method. >>> >>> >>>-Josh >>> >>> >>>On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: >>> >>>>Josh, please see my comments in line. >>>> >>>>Thanks >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>>Sent: Thursday, May 03, 2012 10:51 AM >>>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>>(Wim); Lucy yong >>>>Cc: l2vpn@ietf.org >>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>> >>>>Yuanlong, >>>> >>>>Or better yet, include in the draft a 'standard' value for root sourced >>>>VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You would also >>>>have to require the the implementation NOT use global VLAN's, however >>>>(since each instance would be using the same values). In this way, no >>>>signaling or manual configuration is required for remote PE's to know >>>>how >>>>to classify traffic. >>>>[JY] Indeed, we discussed this possibility during the f2f meeting in >>>>Paris. But, there are some restrictions as you mentioned, and >>>>furthermore: >>>>1) Some vendors already used S-VLAN to distinguish their VSIs in the >>>>PE; >>>>2) Forwarding plane of a PE needs to be revised to be aware of this >>>>VLAN >>>>ID. >>>>Therefore, this 'standard value' approach seems more disruptive >>>>compared >>>>with the other means and not a good candidate option. >>>> >>>>Regarding switching PE's? Multi-PW means more than one PW, yes. I >>>>don't >>>>see this as a real problem. In general, design should try and avoid >>>>using >>>>S-PE's, but if you must, its going to mean extra work, no matter how >>>>you >>>>look at it. Two PW's for each Etree being switched instead of one is >>>>not >>>>alarming or concerning to me. On the other hand, if you use a dot1q >>>>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's >>>>an >>>>two egress VLAN's if you want the Etree to be handled on both sides >>>>(and >>>>if you use the 'standard' VID's as I mentioned above, you'd have to do >>>>mapping to non-standard and back) >>>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>>requirements from MEF, it has nothing to do with the solutions. Could >>>>you >>>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>>if configuring or signalling two PWs is not a problem, why configuring >>>>or >>>>signalling two VLANs will become a problem? After all, more nodes may >>>>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>>>with 2VLAN (only T-PEs). >>>> >>>>In general, I still prefer multi-PW, primarily because I prefer the >>>>separation of the traffic in the network's forwarding plane, rather >>>>than >>>>shipping it everywhere and deciding whether to forward to the AC when >>>>it >>>>gets to the egress PE. I'm having a hard time putting my finger >>>>exactly >>>>on what it is, or articulating the idea, but it seems that by having >>>>the >>>>traffic placed into two psuedowires, I have more flexibility and ease >>>>of >>>>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>>>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>>>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>>>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>>>PW's could really change that perception. >>>>[JY] Are you saying that we need to develop a totally new forwarding >>>>plane rather than using the Ethernet forwarding plane as described in >>>>the >>>>existing work? >>>> >>>>I hope we can move forward with one of these soon, >>>>[JY] me too. >>>> >>>>Josh >>>> >>>> >>>>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >>>> >>>>>Daniel, >>>>> >>>>>Not aware that we had a discussion on this before, but IMHO the >>>>>allocation of internal S-VLAN can be automatic, and manuel >>>>>configuration >>>>>of this mapping may not be needed at all. For example, an S-VLAN >>>>>allocation module in the management plane in a PE can do this kind of >>>>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>>>way from a free S-VLAN ID pool. Once the interal S-VLANs are >>>>>allocated, >>>>>the mapping is determined and no other configuration is needed. >>>>> >>>>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>>>allocate >>>>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to >>>>>allocate >>>>>two S-VLANs in the VPLS domain. >>>>> >>>>>On the other hand, for the multi-PW approach, two PWs need to be >>>>>configured for a E-Tree service. When MS-PW is used in the network, >>>>>for >>>>>every S-PE, we need to configure two ingress PW segments and two >>>>>egress >>>>>PW segments. In this case, I don't think we need to use fixed PW >>>>>labels >>>>>across the network for fear of configuration complexity. >>>>> >>>>>Regards, >>>>>Yuanlong >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>Sent: Wednesday, May 02, 2012 8:01 PM >>>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; >>>>>josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Inline. >>>>> >>>>>-----Original Message----- >>>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>>Sent: Wednesday, May 02, 2012 12:30 PM >>>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; >>>>>josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Hi Daniel, Please see my comments in line. >>>>> >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>Sent: Wednesday, May 02, 2012 3:55 PM >>>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Hi Yuanlong, >>>>> >>>>>The problem is not with the total number of S-VLAN IDs, I agree that >>>>>normally there won't be more than 2047. The problem is that if you >>>>>don't >>>>>support all VLAN IDs, you need S-VLAN space coordination with the >>>>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to >>>>>2047". >>>>>Which won't always be in line with an existing deployment. >>>>>[JY] This is not the case. If the total number is no more than 2047, >>>>>it >>>>>surely can be supported. The S-VLAN space of user domain is totally >>>>>different from the S-VLAN in the provider domain and they can be >>>>>overlapped, I don't see why we need S-VLAN space coordination between >>>>>them. >>>>> >>>>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>>>fixed, and therefore the IEEE S-VID that can be supported is also >>>>>fixed. >>>>> >>>>>Of course you can configure the mapping in each PE according to >>>>>operator >>>>>requirements but as we discussed before this increases complexity. >>>>> >>>>>Relying on PBB-VPLS imposes additional limitations on backward >>>>>compatibility. >>>>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>>>think they may well need MAC-in-MAC in their networks for the >>>>>scalability issue. As you know, only PBB VPLS can provide both. >>>>> >>>>>Daniel >>>>> >>>>>-----Original Message----- >>>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>>Sent: Wednesday, May 02, 2012 5:07 AM >>>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; >>>>>josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Hi Daniel, >>>>> >>>>>As you can see, both cases are discussed in the I-D. >>>>> >>>>>With regard to case 1) (that is, S-VLAN translation), since the access >>>>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>>>they need to be configured on a PE anyway, and as the past emails by >>>>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>>>mapping. >>>>> >>>>>With regard to S-VID space reduction, the constraint is valid only >>>>>when >>>>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>>>typical and with no such limits as we already discussed in the f2f >>>>>meeting. >>>>> >>>>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>>>described (not sure this is a valid use case in real life), PBB-VPLS >>>>>can >>>>>still be used. >>>>> >>>>>Regards, >>>>>Yuanlong >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>Sent: Monday, April 30, 2012 10:34 PM >>>>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>>Jiangyuanlong; josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>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] >>>>>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 >>>>> >>>>>------------------------------------------------------------------- --- >>>> >>>> >>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>proprietary information, which is privileged, confidential, or subject >>>>to >>>>copyright belonging to Time Warner Cable. This E-mail is intended >>>>solely >>>>for the use of the individual or entity to which it is addressed. If >>>>you >>>>are not the intended recipient of this E-mail, you are hereby notified >>>>that any dissemination, distribution, copying, or action taken in >>>>relation to the contents of and attachments to this E-mail is strictly >>>>prohibited and may be unlawful. If you have received this 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 and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for >the use of the individual or entity to which it is addressed. If you are >not >the intended recipient of this E-mail, you are hereby notified that any >dissemination, distribution, copying, or action taken in relation to the >contents of and attachments to this E-mail is strictly prohibited and may >be >unlawful. If you have received this 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 96, Issue 15 >************************************* > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this 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 DanielC@orckit.com Tue May 8 06:20: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 7860C21F8555 for ; Tue, 8 May 2012 06:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, 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 ogdxOdBi1LQg for ; Tue, 8 May 2012 06:20:47 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id 7B03721F854F for ; Tue, 8 May 2012 06:20:45 -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: L2vpn Digest, Vol 96, Issue 15 Date: Tue, 8 May 2012 16:22:38 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780CB22@tlvmail1> In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410BBC@szxeml546-mbx.china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: L2vpn Digest, Vol 96, Issue 15 Thread-Index: AQHNKgNyPxr7nh+DX0S+AUfrSOoOpZa57ewAgARPYACAABdtgIAA8VnQgABOaUCAAAEZoIAABFOggAAHB2CAAEStQA== References: <2691CE0099834E4A9C5044EEC662BB9D330F0740@dfweml506-mbx> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410ABC@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CA64@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410B5D@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CA6E@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410BBC@szxeml546-mbx.china.huawei.com> From: "Daniel Cohn" To: "Jiangyuanlong" , "Rogers, Josh" , "Lucy yong" , "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: Tue, 08 May 2012 13:20:50 -0000 Yuanlong, where in RFC 6136 (or anywhere else) do you see a requirement for down MEPs in a PE? As I see it, down MEPs in a PE should be MPLS MEPs and not E-OAM MEPs, since the core cannot always be assumed to be Ethernet.=20 Daniel -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Tuesday, May 08, 2012 3:18 PM To: Daniel Cohn; Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 Inline -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Tuesday, May 08, 2012 11:42 AM To: Daniel Cohn; Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 I don't think so. There may be different layers of OAM applicable to a service. Such as LSP layer, PW layer, and service layer. [DC] Agreed Now you cannot use a single LSP OAM to monitor the server layer of the E-Tree service (as 2 LSP may be involved). And the service layer of OAM for E-Tree may be distributed to different LSP paths. [DC] For E-Tree service OAM, you would perform OAM actions from MEPs associated to root or leaf ACs, so the E-OAM frames would naturally follow the root or leaf pseudowires and the LSPs that transport them. I don't see a limitation here. [JY] Now you need to monitor two LSPs and/or two PWs between mixed PEs for this E-Tree. Besides the UP MEPs (associated with access port) as you mentioned, DOWN MEPs may also be needed (facing core) where both root and leaf traffic cross, not sure how you will configure OAM for them. Regards, Yuanlong -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Tuesday, May 08, 2012 4:28 PM To: Jiangyuanlong; Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 Yuanlong, isn't this orthogonal to the issues we are discussing? I mean, there are different mechanisms to troubleshoot PWs, all of which are applicable to root/leaf PWs as to any other PWs. Or is there any specific limitation on root/leaf PW troubleshooting, compared to "regular" PWs used in VPLSs? Thanks, Daniel -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Jiangyuanlong Sent: Tuesday, May 08, 2012 7:04 AM To: Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 Josh,=20 Just some comments on this part: [JR] I don't see this any more of a problem than troubleshooting one. If LDP is used, a simple mols traceroute shows the path that ALL PW's to that PE take, regardless of which service (this VPLS or another VPLS instance). If RSVP is used, there should be a route-object that shows me the path, and allows me to troubleshoot. Additionally, if I wanted to have traffic engineering that impacted root-sourced and leaf-sourced traffic differently, I can do that with multi-PW, where I could not (save for ingress/egress) with the 2VLAN approach. PE should report signaling on second PW same as it does for the 100th PW between PE's. Again, I don't see the problem you are alluding to. I suppose you are referring to LSP Ping on the LSP layer, yes, it can oversee all the PWs in this LSP. If both root and leaf PW are in the same LSP, it can work. But there may well be multiple LSPs between a pair of PEs, and root/leaf PW may be transported on different LSPs. Another difficulty is, if ECMP is deployed and PW label as a bottom label is used for hashing, the OAM message may be load balanced on different paths. With regard to TE, you could use DS-TE, just as Lucy said, two PW do not guarantee they are traffic engineered. Thanks Yuanlong -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com]=20 Sent: Tuesday, May 08, 2012 5:22 AM To: Lucy yong; Sam Cao; l2vpn@ietf.org Cc: Jiangyuanlong Subject: Re: L2vpn Digest, Vol 96, Issue 15 Comments inline (and s/conquer/concur/) On 5/7/12 2:58 PM, "Lucy yong" wrote: >Sam, > >I concur with Yuanlong's reply on this. Please see inline. > >Lucy > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >Sam Cao >Sent: Friday, May 04, 2012 9:09 PM >To: l2vpn@ietf.org >Cc: Jiangyuanlong >Subject: RE: L2vpn Digest, Vol 96, Issue 15 > >Lucy/Yuanlong, > >I agree that we can not say which approach is better simply, but I really >agree with Josh's comments. Multi-PW is easy to implement E-Tree. >[[LY]] I don't get impression Josh state this. > >First of all, we discussed 2 approaches for a long time and many rounds, >and >for me, there are no pending issues on Multi-PW till now or co-authors of >multi-PW have given reasonable reply to L2VPN members' questions, but >there >are still pending issues for Dual-VLAN. Please trace the mailing list. >[[LY]] I interpret this as people want to spend time to finalize dual >VLAN solution. Multi-PW has some operation impact. How do operator to >maintain this service and be able to trouble shooting. How do you expect >traceroute work when using two PWs for one VPN? How do you expect PE >report when there is an error on one of two PWs? Do you have one FEC or >two FEC for a E-Tree in control plane? [JR] I don't see this any more of a problem than troubleshooting one. If LDP is used, a simple mols traceroute shows the path that ALL PW's to that PE take, regardless of which service (this VPLS or another VPLS instance). If RSVP is used, there should be a route-object that shows me the path, and allows me to troubleshoot. Additionally, if I wanted to have traffic engineering that impacted root-sourced and leaf-sourced traffic differently, I can do that with multi-PW, where I could not (save for ingress/egress) with the 2VLAN approach. PE should report signaling on second PW same as it does for the 100th PW between PE's. Again, I don't see the problem you are alluding to. > >Second, Sasha has his concern in NP, or forwarding performance. Compared >to >current VPLS, Multi-PW has a little effect on forwarding performance since >it reuse PW label as AC indicator; Dual-VLAN will have higher side effect >on >forwarding performance because it SHOULD use additional indicator. Is >there >one prototype for Dual-VLAN? BTW, there is no reply on chip limit. >[[LY]] in VPLS, PW label is used as VSI indicator, not AC. I disagree >your statement here. > >Third, the difference between Multi-PW and dual-VLAN is, transport ingress >traffic in one "LSP" or 2 "LSP". Multi-PW classifies and transforms >ingress >traffic into right "path", and egress just pop-out PW label and forward >the >frame to ACs. Dual-VLAN has more work on ingress PE or egress PE. >[[LY]] Don't understand the first part. When egress pop-out PW label, it >find corresponding VSI first, then perform MAC lookup associated to all >ACs. We can't assume there is one AC. > >Fourth, maybe Giles has figured this out, Dual-VLAN has capacity limit. >Only >4094 VLAN ID are available, so only 2K E-Tree instances can be supported >on >one PE for Dual-VLAN approach. There is no such limit for Multi-PW >approach, >[[LY]] If 4K VLAN ID is not an issue for VPLS, it is not an issue for >E-Tree. > >Finally, in this thread we don't make agreement on VLAN ID allocation. We >also have questions on VLAN ID negotiation among PEs (signaling protocol). >Yuanlong wishes to update, but there is no update till now. >[[LY]] This should not be the reason to judge on the solution. [JR] I tend to agree. > >For me, why IEEE uses VLAN ID to identify AC type? IEEE has no LABEL :), >and >it has label, it also wish to use label to identify AC types. I think that >both solutions need much time to be perfect. Mutli-PW has less extension >work to do. But now we are focusing on technical details and can not move >forward :). >[[LY]] VPN label is used for identify the VPN. It already has the >purpose. Overloading with other meaning has high potential causing a >problem. Hope you can investigate it more. Since you are very in favor of >multi-pw solution, it is not proper for you to come out the conclusion >which is better, because it is very biased. You are welcome to help on >completing either solution. [JR] this is humorous to me, because at one time, VLAN-ID was used to identify a single broadcast domain, and then later asymmetrical VID's were used to limit communication between endpoints of a broadcast domain (effectively creating two one-way broadcast domains, very similar to what we're accomplishing with ETREE). This should not be the reason to judge on the solution. > >Regards, >Lucy > >Lucy > >Thanks, > >Sam > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >l2vpn-request@ietf.org >Sent: Friday, May 04, 2012 10:31 PM >To: l2vpn@ietf.org >Subject: L2vpn Digest, Vol 96, Issue 15 > >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) > 2. Re: The status of the approaches to the E-Tree solution? > (Rogers, Josh) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Fri, 4 May 2012 14:16:36 +0000 >From: Lucy yong >To: "Rogers, Josh" , Jiangyuanlong > , Daniel Cohn , >"Fedyk, > Donald (Don)" , "Henderickx, Wim > (Wim)" >Cc: "l2vpn@ietf.org" >Subject: RE: The status of the approaches to the E-Tree solution? >Message-ID: <2691CE0099834E4A9C5044EEC662BB9D330E9114@dfweml505-mbx> >Content-Type: text/plain; charset=3D"iso-8859-2" > >Josh, > >You simply say that you don't like IEEE Tree solution. IEEE Tree solution >is >for ingress port to mark and for egress port to filter. > >Regards, >Lucy > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Friday, May 04, 2012 7:27 AM >To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >(Wim); >Lucy yong >Cc: l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >also separate the leaf traffic in the ingress PE and filter it there >(already detailed in the Optimization Mode in the I-D); if the egress PE >is attached with pure roots or with both roots and leafs, it seems all >traffic must be transported to the egress PE and be filtered there, I see >no difference in behaviour for these solutions. Or did I miss something? > > >The point is with the multi-PW method the traffic is split/separated (by >psuedowire) on the ingress PE, rather than the egress. The distinction is >2VLAN will 'classify' the frame on the ingress PE, so that the egress PE >knows how to forward it to the appropriate AC's. > >Both methods have inefficiencies (one duplicates traffic for transport, >while the other transports where it doesn't need to go). I like the idea >of classify and forwarding on the ingress PE, rather than marking it on >the ingress, and deciding on the egress. > >-Josh > > > >On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: > >>Josh, thank you for the comments, please see my further comments with >>[JY2]. >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Thursday, May 03, 2012 11:27 PM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>requirements from MEF, it has nothing to do with the solutions. Could you >>give a hint on how you can provision this service E-NNI otherwise? BTW, >>if >>configuring or signalling two PWs is not a problem, why configuring or >>signalling two VLANs will become a problem? After all, more nodes may >>need >>to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >>2VLAN (only T-PEs). >> >> >>There is no other way (if both MPLS domains are part of the same ETREE, >>rather than doing something more like H-VPLS, where one domain has point >>to points to the other domain which handles the ETREE instance) if you >>are >>using an ENNI. The other method, (not mentioned earlier) is tying the >>two >>MPLS domains together via labeled unicast (much preferred over E-NNI in >>my >>opinion) >> >>Configuring two VLAN's isn't really a 'problem' any more than two PW's. >>I >>wasn't saying that configuring two VLAN's was difficult, I was objecting >>to the statement that configuring two PW's is difficult. >> >>[JY2] Thanks, I see your point. I take the example of 2PW configuration >>just to show that using fixed global values to simplify configuration >>makes no sense. Personally I also don't think configuration is a problem >>for both solutions. >> >>I find the differences between these two methods rather slight. The >>'tie-breaker' for me is by placing the forwarding decision on the ingress >>PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >>more control over where the traffic goes, and in my mind it provides a >>cleaner destination between customer traffic and forwarding plane. I'm >>accustomed to looking at a psuedowire and knowing where its going, with >>the 2vlan method, I can see the psuedowire, but must go to the egress PE >>to see if it will be dropped there, or forwarded to one or more AC's. >> >>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>also separate the leaf traffic in the ingress PE and filter it there >>(already detailed in the Optimization Mode in the I-D); if the egress PE >>is attached with pure roots or with both roots and leafs, it seems all >>traffic must be transported to the egress PE and be filtered there, I see >>no difference in behaviour for these solutions. Or did I miss something? >> >>Again, the difference here is slight, and I would honestly be happy to >>see >>either of them come to fruition. Please don't infer that I think the >>2vlan method is 'bad' or has intrinsic problems, because I don't believe >>that. I just prefer the multi-PW method. >> >> >>-Josh >> >> >>On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: >> >>>Josh, please see my comments in line. >>> >>>Thanks >>>Yuanlong >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Thursday, May 03, 2012 10:51 AM >>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>(Wim); Lucy yong >>>Cc: l2vpn@ietf.org >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Yuanlong, >>> >>>Or better yet, include in the draft a 'standard' value for root sourced >>>VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You would also >>>have to require the the implementation NOT use global VLAN's, however >>>(since each instance would be using the same values). In this way, no >>>signaling or manual configuration is required for remote PE's to know >>>how >>>to classify traffic. >>>[JY] Indeed, we discussed this possibility during the f2f meeting in >>>Paris. But, there are some restrictions as you mentioned, and >>>furthermore: >>>1) Some vendors already used S-VLAN to distinguish their VSIs in the PE; >>>2) Forwarding plane of a PE needs to be revised to be aware of this VLAN >>>ID. >>>Therefore, this 'standard value' approach seems more disruptive compared >>>with the other means and not a good candidate option. >>> >>>Regarding switching PE's? Multi-PW means more than one PW, yes. I >>>don't >>>see this as a real problem. In general, design should try and avoid >>>using >>>S-PE's, but if you must, its going to mean extra work, no matter how you >>>look at it. Two PW's for each Etree being switched instead of one is >>>not >>>alarming or concerning to me. On the other hand, if you use a dot1q >>>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's >>>an >>>two egress VLAN's if you want the Etree to be handled on both sides (and >>>if you use the 'standard' VID's as I mentioned above, you'd have to do >>>mapping to non-standard and back) >>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>requirements from MEF, it has nothing to do with the solutions. Could >>>you >>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>if configuring or signalling two PWs is not a problem, why configuring >>>or >>>signalling two VLANs will become a problem? After all, more nodes may >>>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>>with 2VLAN (only T-PEs). >>> >>>In general, I still prefer multi-PW, primarily because I prefer the >>>separation of the traffic in the network's forwarding plane, rather than >>>shipping it everywhere and deciding whether to forward to the AC when it >>>gets to the egress PE. I'm having a hard time putting my finger exactly >>>on what it is, or articulating the idea, but it seems that by having the >>>traffic placed into two psuedowires, I have more flexibility and ease of >>>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>>PW's could really change that perception. >>>[JY] Are you saying that we need to develop a totally new forwarding >>>plane rather than using the Ethernet forwarding plane as described in >>>the >>>existing work? >>> >>>I hope we can move forward with one of these soon, >>>[JY] me too. >>> >>>Josh >>> >>> >>>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >>> >>>>Daniel, >>>> >>>>Not aware that we had a discussion on this before, but IMHO the >>>>allocation of internal S-VLAN can be automatic, and manuel >>>>configuration >>>>of this mapping may not be needed at all. For example, an S-VLAN >>>>allocation module in the management plane in a PE can do this kind of >>>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>>way from a free S-VLAN ID pool. Once the interal S-VLANs are allocated, >>>>the mapping is determined and no other configuration is needed. >>>> >>>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>>allocate >>>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to allocate >>>>two S-VLANs in the VPLS domain. >>>> >>>>On the other hand, for the multi-PW approach, two PWs need to be >>>>configured for a E-Tree service. When MS-PW is used in the network, for >>>>every S-PE, we need to configure two ingress PW segments and two egress >>>>PW segments. In this case, I don't think we need to use fixed PW labels >>>>across the network for fear of configuration complexity. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 8:01 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Inline. >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 12:30 PM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, Please see my comments in line. >>>> >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 3:55 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Yuanlong, >>>> >>>>The problem is not with the total number of S-VLAN IDs, I agree that >>>>normally there won't be more than 2047. The problem is that if you >>>>don't >>>>support all VLAN IDs, you need S-VLAN space coordination with the >>>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to >>>>2047". >>>>Which won't always be in line with an existing deployment. >>>>[JY] This is not the case. If the total number is no more than 2047, it >>>>surely can be supported. The S-VLAN space of user domain is totally >>>>different from the S-VLAN in the provider domain and they can be >>>>overlapped, I don't see why we need S-VLAN space coordination between >>>>them. >>>> >>>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>>fixed, and therefore the IEEE S-VID that can be supported is also >>>>fixed. >>>> >>>>Of course you can configure the mapping in each PE according to >>>>operator >>>>requirements but as we discussed before this increases complexity. >>>> >>>>Relying on PBB-VPLS imposes additional limitations on backward >>>>compatibility. >>>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>>think they may well need MAC-in-MAC in their networks for the >>>>scalability issue. As you know, only PBB VPLS can provide both. >>>> >>>>Daniel >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 5:07 AM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, >>>> >>>>As you can see, both cases are discussed in the I-D. >>>> >>>>With regard to case 1) (that is, S-VLAN translation), since the access >>>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>>they need to be configured on a PE anyway, and as the past emails by >>>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>>mapping. >>>> >>>>With regard to S-VID space reduction, the constraint is valid only when >>>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>>typical and with no such limits as we already discussed in the f2f >>>>meeting. >>>> >>>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>>described (not sure this is a valid use case in real life), PBB-VPLS >>>>can >>>>still be used. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Monday, April 30, 2012 10:34 PM >>>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>Jiangyuanlong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>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] >>>>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 >>>> >>>>-------------------------------------------------------------------- -- >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to >>>copyright belonging to Time Warner Cable. This E-mail is intended solely >>>for the use of the individual or entity to which it is addressed. If you >>>are not the intended recipient of this E-mail, you are hereby notified >>>that any dissemination, distribution, copying, or action taken in >>>relation to the contents of and attachments to this E-mail is strictly >>>prohibited and may be unlawful. If you have received this 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. > > >------------------------------ > >Message: 2 >Date: Fri, 4 May 2012 10:30:38 -0400 >From: "Rogers, Josh" >To: Lucy yong , Jiangyuanlong > , Daniel Cohn , >"Fedyk, > Donald (Don)" , "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"iso-8859-2" > >To be more accurate, I like it less than the multi-PW solution. I'd be >happy to use the 2VLAN solution in the real world, if it was ratified as >the standard. > > > >On 5/4/12 9:16 AM, "Lucy yong" wrote: > >>Josh, >> >>You simply say that you don't like IEEE Tree solution. IEEE Tree solution >>is for ingress port to mark and for egress port to filter. >> >>Regards, >>Lucy >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Friday, May 04, 2012 7:27 AM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>also separate the leaf traffic in the ingress PE and filter it there >>(already detailed in the Optimization Mode in the I-D); if the egress PE >>is attached with pure roots or with both roots and leafs, it seems all >>traffic must be transported to the egress PE and be filtered there, I see >>no difference in behaviour for these solutions. Or did I miss something? >> >> >>The point is with the multi-PW method the traffic is split/separated (by >>psuedowire) on the ingress PE, rather than the egress. The distinction >>is >>2VLAN will 'classify' the frame on the ingress PE, so that the egress PE >>knows how to forward it to the appropriate AC's. >> >>Both methods have inefficiencies (one duplicates traffic for transport, >>while the other transports where it doesn't need to go). I like the idea >>of classify and forwarding on the ingress PE, rather than marking it on >>the ingress, and deciding on the egress. >> >>-Josh >> >> >> >>On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: >> >>>Josh, thank you for the comments, please see my further comments with >>>[JY2]. >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Thursday, May 03, 2012 11:27 PM >>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>(Wim); Lucy yong >>>Cc: l2vpn@ietf.org >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>requirements from MEF, it has nothing to do with the solutions. Could >>>you >>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>if >>>configuring or signalling two PWs is not a problem, why configuring or >>>signalling two VLANs will become a problem? After all, more nodes may >>>need >>>to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >>>2VLAN (only T-PEs). >>> >>> >>>There is no other way (if both MPLS domains are part of the same ETREE, >>>rather than doing something more like H-VPLS, where one domain has point >>>to points to the other domain which handles the ETREE instance) if you >>>are >>>using an ENNI. The other method, (not mentioned earlier) is tying the >>>two >>>MPLS domains together via labeled unicast (much preferred over E-NNI in >>>my >>>opinion) >>> >>>Configuring two VLAN's isn't really a 'problem' any more than two PW's. >>>I >>>wasn't saying that configuring two VLAN's was difficult, I was objecting >>>to the statement that configuring two PW's is difficult. >>> >>>[JY2] Thanks, I see your point. I take the example of 2PW configuration >>>just to show that using fixed global values to simplify configuration >>>makes no sense. Personally I also don't think configuration is a problem >>>for both solutions. >>> >>>I find the differences between these two methods rather slight. The >>>'tie-breaker' for me is by placing the forwarding decision on the >>>ingress >>>PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >>>more control over where the traffic goes, and in my mind it provides a >>>cleaner destination between customer traffic and forwarding plane. I'm >>>accustomed to looking at a psuedowire and knowing where its going, with >>>the 2vlan method, I can see the psuedowire, but must go to the egress PE >>>to see if it will be dropped there, or forwarded to one or more AC's. >>> >>>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>>also separate the leaf traffic in the ingress PE and filter it there >>>(already detailed in the Optimization Mode in the I-D); if the egress PE >>>is attached with pure roots or with both roots and leafs, it seems all >>>traffic must be transported to the egress PE and be filtered there, I >>>see >>>no difference in behaviour for these solutions. Or did I miss something? >>> >>>Again, the difference here is slight, and I would honestly be happy to >>>see >>>either of them come to fruition. Please don't infer that I think the >>>2vlan method is 'bad' or has intrinsic problems, because I don't believe >>>that. I just prefer the multi-PW method. >>> >>> >>>-Josh >>> >>> >>>On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: >>> >>>>Josh, please see my comments in line. >>>> >>>>Thanks >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>>Sent: Thursday, May 03, 2012 10:51 AM >>>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>>(Wim); Lucy yong >>>>Cc: l2vpn@ietf.org >>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>> >>>>Yuanlong, >>>> >>>>Or better yet, include in the draft a 'standard' value for root sourced >>>>VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You = would also >>>>have to require the the implementation NOT use global VLAN's, however >>>>(since each instance would be using the same values). In this way, no >>>>signaling or manual configuration is required for remote PE's to know >>>>how >>>>to classify traffic. >>>>[JY] Indeed, we discussed this possibility during the f2f meeting in >>>>Paris. But, there are some restrictions as you mentioned, and >>>>furthermore: >>>>1) Some vendors already used S-VLAN to distinguish their VSIs in the >>>>PE; >>>>2) Forwarding plane of a PE needs to be revised to be aware of this >>>>VLAN >>>>ID. >>>>Therefore, this 'standard value' approach seems more disruptive >>>>compared >>>>with the other means and not a good candidate option. >>>> >>>>Regarding switching PE's? Multi-PW means more than one PW, yes. I >>>>don't >>>>see this as a real problem. In general, design should try and avoid >>>>using >>>>S-PE's, but if you must, its going to mean extra work, no matter how >>>>you >>>>look at it. Two PW's for each Etree being switched instead of one is >>>>not >>>>alarming or concerning to me. On the other hand, if you use a dot1q >>>>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's >>>>an >>>>two egress VLAN's if you want the Etree to be handled on both sides >>>>(and >>>>if you use the 'standard' VID's as I mentioned above, you'd have to do >>>>mapping to non-standard and back) >>>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>>requirements from MEF, it has nothing to do with the solutions. Could >>>>you >>>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>>if configuring or signalling two PWs is not a problem, why configuring >>>>or >>>>signalling two VLANs will become a problem? After all, more nodes may >>>>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>>>with 2VLAN (only T-PEs). >>>> >>>>In general, I still prefer multi-PW, primarily because I prefer the >>>>separation of the traffic in the network's forwarding plane, rather >>>>than >>>>shipping it everywhere and deciding whether to forward to the AC when >>>>it >>>>gets to the egress PE. I'm having a hard time putting my finger >>>>exactly >>>>on what it is, or articulating the idea, but it seems that by having >>>>the >>>>traffic placed into two psuedowires, I have more flexibility and ease >>>>of >>>>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>>>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>>>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>>>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>>>PW's could really change that perception. >>>>[JY] Are you saying that we need to develop a totally new forwarding >>>>plane rather than using the Ethernet forwarding plane as described in >>>>the >>>>existing work? >>>> >>>>I hope we can move forward with one of these soon, >>>>[JY] me too. >>>> >>>>Josh >>>> >>>> >>>>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >>>> >>>>>Daniel, >>>>> >>>>>Not aware that we had a discussion on this before, but IMHO the >>>>>allocation of internal S-VLAN can be automatic, and manuel >>>>>configuration >>>>>of this mapping may not be needed at all. For example, an S-VLAN >>>>>allocation module in the management plane in a PE can do this kind of >>>>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>>>way from a free S-VLAN ID pool. Once the interal S-VLANs are >>>>>allocated, >>>>>the mapping is determined and no other configuration is needed. >>>>> >>>>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>>>allocate >>>>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to >>>>>allocate >>>>>two S-VLANs in the VPLS domain. >>>>> >>>>>On the other hand, for the multi-PW approach, two PWs need to be >>>>>configured for a E-Tree service. When MS-PW is used in the network, >>>>>for >>>>>every S-PE, we need to configure two ingress PW segments and two >>>>>egress >>>>>PW segments. In this case, I don't think we need to use fixed PW >>>>>labels >>>>>across the network for fear of configuration complexity. >>>>> >>>>>Regards, >>>>>Yuanlong >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>Sent: Wednesday, May 02, 2012 8:01 PM >>>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; >>>>>josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Inline. >>>>> >>>>>-----Original Message----- >>>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>>Sent: Wednesday, May 02, 2012 12:30 PM >>>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; >>>>>josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Hi Daniel, Please see my comments in line. >>>>> >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>Sent: Wednesday, May 02, 2012 3:55 PM >>>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Hi Yuanlong, >>>>> >>>>>The problem is not with the total number of S-VLAN IDs, I agree that >>>>>normally there won't be more than 2047. The problem is that if you >>>>>don't >>>>>support all VLAN IDs, you need S-VLAN space coordination with the >>>>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to >>>>>2047". >>>>>Which won't always be in line with an existing deployment. >>>>>[JY] This is not the case. If the total number is no more than 2047, >>>>>it >>>>>surely can be supported. The S-VLAN space of user domain is totally >>>>>different from the S-VLAN in the provider domain and they can be >>>>>overlapped, I don't see why we need S-VLAN space coordination between >>>>>them. >>>>> >>>>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>>>fixed, and therefore the IEEE S-VID that can be supported is also >>>>>fixed. >>>>> >>>>>Of course you can configure the mapping in each PE according to >>>>>operator >>>>>requirements but as we discussed before this increases complexity. >>>>> >>>>>Relying on PBB-VPLS imposes additional limitations on backward >>>>>compatibility. >>>>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>>>think they may well need MAC-in-MAC in their networks for the >>>>>scalability issue. As you know, only PBB VPLS can provide both. >>>>> >>>>>Daniel >>>>> >>>>>-----Original Message----- >>>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>>Sent: Wednesday, May 02, 2012 5:07 AM >>>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; >>>>>josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Hi Daniel, >>>>> >>>>>As you can see, both cases are discussed in the I-D. >>>>> >>>>>With regard to case 1) (that is, S-VLAN translation), since the access >>>>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>>>they need to be configured on a PE anyway, and as the past emails by >>>>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>>>mapping. >>>>> >>>>>With regard to S-VID space reduction, the constraint is valid only >>>>>when >>>>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>>>typical and with no such limits as we already discussed in the f2f >>>>>meeting. >>>>> >>>>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>>>described (not sure this is a valid use case in real life), PBB-VPLS >>>>>can >>>>>still be used. >>>>> >>>>>Regards, >>>>>Yuanlong >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>Sent: Monday, April 30, 2012 10:34 PM >>>>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>>Jiangyuanlong; josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>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] >>>>>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 >>>>> >>>>>------------------------------------------------------------------- --- >>>> >>>> >>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>proprietary information, which is privileged, confidential, or subject >>>>to >>>>copyright belonging to Time Warner Cable. This E-mail is intended >>>>solely >>>>for the use of the individual or entity to which it is addressed. If >>>>you >>>>are not the intended recipient of this E-mail, you are hereby notified >>>>that any dissemination, distribution, copying, or action taken in >>>>relation to the contents of and attachments to this E-mail is strictly >>>>prohibited and may be unlawful. If you have received this 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 and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for >the use of the individual or entity to which it is addressed. If you are >not >the intended recipient of this E-mail, you are hereby notified that any >dissemination, distribution, copying, or action taken in relation to the >contents of and attachments to this E-mail is strictly prohibited and may >be >unlawful. If you have received this 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 96, Issue 15 >************************************* > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this 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 May 8 06:24: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 A8B7821F8496 for ; Tue, 8 May 2012 06:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.132 X-Spam-Level: X-Spam-Status: No, score=-2.132 tagged_above=-999 required=5 tests=[AWL=-0.133, 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 fRaPMKHAWZQ1 for ; Tue, 8 May 2012 06:24:50 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id CB2D821F848F for ; Tue, 8 May 2012 06:24:49 -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 AFX82416; Tue, 08 May 2012 09:24:49 -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; Tue, 8 May 2012 06:22:43 -0700 Received: from SZXEML434-HUB.china.huawei.com (10.72.61.62) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 8 May 2012 06:22:46 -0700 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.183]) by szxeml434-hub.china.huawei.com ([10.72.61.62]) with mapi id 14.01.0323.003; Tue, 8 May 2012 21:22:34 +0800 From: Jiangyuanlong To: Daniel Cohn , "Rogers, Josh" , Lucy yong , Sam Cao , "l2vpn@ietf.org" Subject: RE: L2vpn Digest, Vol 96, Issue 15 Thread-Topic: L2vpn Digest, Vol 96, Issue 15 Thread-Index: AQHNKgNyPxr7nh+DX0S+AUfrSOoOpZa57ewAgARPYACAABdtgIAA8VnQgABOaUCAAAEZoIAABFOggABM/3A= Date: Tue, 8 May 2012 13:22:33 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410BFF@szxeml546-mbx.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D330F0740@dfweml506-mbx> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410ABC@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CA64@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410B5D@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CA6E@tlvmail1> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA08130780CA6E@tlvmail1> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.40.73] 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: Tue, 08 May 2012 13:24:53 -0000 Daniel, RFC 6136 provides the VPLS OAM reqs and framework, and Sec. 10.1. gives the= typical VPLS OAM Operational Scenarios: --- --- / \ ------ ------- ---- / \ | A CE-- / \ / \ / \ --CE A | \ / \ / \ / \ / \ / \ / --- --UPE NPE NPE UPE-- --- \ / \ / \ / \ / \ / \ / ------ ------- ---- Customer OAM Domain (C) MEP---MIP--------------------------------MIP---MEP Service Provider (SP) OAM Domain (D) MEP--------MIP-----------MIP-------MEP SP OAM SP OAM SP OAM (D1) MEP-MIP--MEP|MEP-------MEP|MEP-----MEP domain domain domain Operator Operator Operator (E) MEP-MIP--MEP|MEP-------MEP|MEP-----MEP OAM domain OAM domain OAM domain MPLS OAM MPLS OAM (F) MEP--MIP-----MEP--MIP--MEP domain domain Figure 10: VPLS OAM Domains, MEPs, and MIPs It seems OAM configurations in Scenario D1) and E) for 2PW approach will be= much complicated and error prone, since E-Tree OAM now needs to interwork = with one of these two PWs' OAM (maybe both, I am afraid). For scenario F),= the concatanation of two MPLS OAM also needs to be very careful as 4 PWs a= nd 3 types (i.e, root/leaf/normal) may be involved there. Regards, Yuanlong -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Tuesday, May 08, 2012 4:49 PM To: Jiangyuanlong; Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 Inline -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Tuesday, May 08, 2012 11:42 AM To: Daniel Cohn; Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 I don't think so. There may be different layers of OAM applicable to a service. Such as LSP layer, PW layer, and service layer. [DC] Agreed Now you cannot use a single LSP OAM to monitor the server layer of the E-Tree service (as 2 LSP may be involved). And the service layer of OAM for E-Tree may be distributed to different LSP paths. [DC] For E-Tree service OAM, you would perform OAM actions from MEPs associated to root or leaf ACs, so the E-OAM frames would naturally follow the root or leaf pseudowires and the LSPs that transport them. I don't see a limitation here. -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Tuesday, May 08, 2012 4:28 PM To: Jiangyuanlong; Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 Yuanlong, isn't this orthogonal to the issues we are discussing? I mean, there are different mechanisms to troubleshoot PWs, all of which are applicable to root/leaf PWs as to any other PWs. Or is there any specific limitation on root/leaf PW troubleshooting, compared to "regular" PWs used in VPLSs? Thanks, Daniel -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Jiangyuanlong Sent: Tuesday, May 08, 2012 7:04 AM To: Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 Josh,=20 Just some comments on this part: [JR] I don't see this any more of a problem than troubleshooting one. If LDP is used, a simple mols traceroute shows the path that ALL PW's to that PE take, regardless of which service (this VPLS or another VPLS instance). If RSVP is used, there should be a route-object that shows me the path, and allows me to troubleshoot. Additionally, if I wanted to have traffic engineering that impacted root-sourced and leaf-sourced traffic differently, I can do that with multi-PW, where I could not (save for ingress/egress) with the 2VLAN approach. PE should report signaling on second PW same as it does for the 100th PW between PE's. Again, I don't see the problem you are alluding to. I suppose you are referring to LSP Ping on the LSP layer, yes, it can oversee all the PWs in this LSP. If both root and leaf PW are in the same LSP, it can work. But there may well be multiple LSPs between a pair of PEs, and root/leaf PW may be transported on different LSPs. Another difficulty is, if ECMP is deployed and PW label as a bottom label is used for hashing, the OAM message may be load balanced on different paths. With regard to TE, you could use DS-TE, just as Lucy said, two PW do not guarantee they are traffic engineered. Thanks Yuanlong -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com]=20 Sent: Tuesday, May 08, 2012 5:22 AM To: Lucy yong; Sam Cao; l2vpn@ietf.org Cc: Jiangyuanlong Subject: Re: L2vpn Digest, Vol 96, Issue 15 Comments inline (and s/conquer/concur/) On 5/7/12 2:58 PM, "Lucy yong" wrote: >Sam, > >I concur with Yuanlong's reply on this. Please see inline. > >Lucy > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >Sam Cao >Sent: Friday, May 04, 2012 9:09 PM >To: l2vpn@ietf.org >Cc: Jiangyuanlong >Subject: RE: L2vpn Digest, Vol 96, Issue 15 > >Lucy/Yuanlong, > >I agree that we can not say which approach is better simply, but I really >agree with Josh's comments. Multi-PW is easy to implement E-Tree. >[[LY]] I don't get impression Josh state this. > >First of all, we discussed 2 approaches for a long time and many rounds, >and >for me, there are no pending issues on Multi-PW till now or co-authors of >multi-PW have given reasonable reply to L2VPN members' questions, but >there >are still pending issues for Dual-VLAN. Please trace the mailing list. >[[LY]] I interpret this as people want to spend time to finalize dual >VLAN solution. Multi-PW has some operation impact. How do operator to >maintain this service and be able to trouble shooting. How do you expect >traceroute work when using two PWs for one VPN? How do you expect PE >report when there is an error on one of two PWs? Do you have one FEC or >two FEC for a E-Tree in control plane? [JR] I don't see this any more of a problem than troubleshooting one. If LDP is used, a simple mols traceroute shows the path that ALL PW's to that PE take, regardless of which service (this VPLS or another VPLS instance). If RSVP is used, there should be a route-object that shows me the path, and allows me to troubleshoot. Additionally, if I wanted to have traffic engineering that impacted root-sourced and leaf-sourced traffic differently, I can do that with multi-PW, where I could not (save for ingress/egress) with the 2VLAN approach. PE should report signaling on second PW same as it does for the 100th PW between PE's. Again, I don't see the problem you are alluding to. > >Second, Sasha has his concern in NP, or forwarding performance. Compared >to >current VPLS, Multi-PW has a little effect on forwarding performance since >it reuse PW label as AC indicator; Dual-VLAN will have higher side effect >on >forwarding performance because it SHOULD use additional indicator. Is >there >one prototype for Dual-VLAN? BTW, there is no reply on chip limit. >[[LY]] in VPLS, PW label is used as VSI indicator, not AC. I disagree >your statement here. > >Third, the difference between Multi-PW and dual-VLAN is, transport ingress >traffic in one "LSP" or 2 "LSP". Multi-PW classifies and transforms >ingress >traffic into right "path", and egress just pop-out PW label and forward >the >frame to ACs. Dual-VLAN has more work on ingress PE or egress PE. >[[LY]] Don't understand the first part. When egress pop-out PW label, it >find corresponding VSI first, then perform MAC lookup associated to all >ACs. We can't assume there is one AC. > >Fourth, maybe Giles has figured this out, Dual-VLAN has capacity limit. >Only >4094 VLAN ID are available, so only 2K E-Tree instances can be supported >on >one PE for Dual-VLAN approach. There is no such limit for Multi-PW >approach, >[[LY]] If 4K VLAN ID is not an issue for VPLS, it is not an issue for >E-Tree. > >Finally, in this thread we don't make agreement on VLAN ID allocation. We >also have questions on VLAN ID negotiation among PEs (signaling protocol). >Yuanlong wishes to update, but there is no update till now. >[[LY]] This should not be the reason to judge on the solution. [JR] I tend to agree. > >For me, why IEEE uses VLAN ID to identify AC type? IEEE has no LABEL :), >and >it has label, it also wish to use label to identify AC types. I think that >both solutions need much time to be perfect. Mutli-PW has less extension >work to do. But now we are focusing on technical details and can not move >forward :). >[[LY]] VPN label is used for identify the VPN. It already has the >purpose. Overloading with other meaning has high potential causing a >problem. Hope you can investigate it more. Since you are very in favor of >multi-pw solution, it is not proper for you to come out the conclusion >which is better, because it is very biased. You are welcome to help on >completing either solution. [JR] this is humorous to me, because at one time, VLAN-ID was used to identify a single broadcast domain, and then later asymmetrical VID's were used to limit communication between endpoints of a broadcast domain (effectively creating two one-way broadcast domains, very similar to what we're accomplishing with ETREE). This should not be the reason to judge on the solution. > >Regards, >Lucy > >Lucy > >Thanks, > >Sam > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >l2vpn-request@ietf.org >Sent: Friday, May 04, 2012 10:31 PM >To: l2vpn@ietf.org >Subject: L2vpn Digest, Vol 96, Issue 15 > >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) > 2. Re: The status of the approaches to the E-Tree solution? > (Rogers, Josh) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Fri, 4 May 2012 14:16:36 +0000 >From: Lucy yong >To: "Rogers, Josh" , Jiangyuanlong > , Daniel Cohn , >"Fedyk, > Donald (Don)" , "Henderickx, Wim > (Wim)" >Cc: "l2vpn@ietf.org" >Subject: RE: The status of the approaches to the E-Tree solution? >Message-ID: <2691CE0099834E4A9C5044EEC662BB9D330E9114@dfweml505-mbx> >Content-Type: text/plain; charset=3D"iso-8859-2" > >Josh, > >You simply say that you don't like IEEE Tree solution. IEEE Tree solution >is >for ingress port to mark and for egress port to filter. > >Regards, >Lucy > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Friday, May 04, 2012 7:27 AM >To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >(Wim); >Lucy yong >Cc: l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >also separate the leaf traffic in the ingress PE and filter it there >(already detailed in the Optimization Mode in the I-D); if the egress PE >is attached with pure roots or with both roots and leafs, it seems all >traffic must be transported to the egress PE and be filtered there, I see >no difference in behaviour for these solutions. Or did I miss something? > > >The point is with the multi-PW method the traffic is split/separated (by >psuedowire) on the ingress PE, rather than the egress. The distinction is >2VLAN will 'classify' the frame on the ingress PE, so that the egress PE >knows how to forward it to the appropriate AC's. > >Both methods have inefficiencies (one duplicates traffic for transport, >while the other transports where it doesn't need to go). I like the idea >of classify and forwarding on the ingress PE, rather than marking it on >the ingress, and deciding on the egress. > >-Josh > > > >On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: > >>Josh, thank you for the comments, please see my further comments with >>[JY2]. >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Thursday, May 03, 2012 11:27 PM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>requirements from MEF, it has nothing to do with the solutions. Could you >>give a hint on how you can provision this service E-NNI otherwise? BTW, >>if >>configuring or signalling two PWs is not a problem, why configuring or >>signalling two VLANs will become a problem? After all, more nodes may >>need >>to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >>2VLAN (only T-PEs). >> >> >>There is no other way (if both MPLS domains are part of the same ETREE, >>rather than doing something more like H-VPLS, where one domain has point >>to points to the other domain which handles the ETREE instance) if you >>are >>using an ENNI. The other method, (not mentioned earlier) is tying the >>two >>MPLS domains together via labeled unicast (much preferred over E-NNI in >>my >>opinion) >> >>Configuring two VLAN's isn't really a 'problem' any more than two PW's. >>I >>wasn't saying that configuring two VLAN's was difficult, I was objecting >>to the statement that configuring two PW's is difficult. >> >>[JY2] Thanks, I see your point. I take the example of 2PW configuration >>just to show that using fixed global values to simplify configuration >>makes no sense. Personally I also don't think configuration is a problem >>for both solutions. >> >>I find the differences between these two methods rather slight. The >>'tie-breaker' for me is by placing the forwarding decision on the ingress >>PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >>more control over where the traffic goes, and in my mind it provides a >>cleaner destination between customer traffic and forwarding plane. I'm >>accustomed to looking at a psuedowire and knowing where its going, with >>the 2vlan method, I can see the psuedowire, but must go to the egress PE >>to see if it will be dropped there, or forwarded to one or more AC's. >> >>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>also separate the leaf traffic in the ingress PE and filter it there >>(already detailed in the Optimization Mode in the I-D); if the egress PE >>is attached with pure roots or with both roots and leafs, it seems all >>traffic must be transported to the egress PE and be filtered there, I see >>no difference in behaviour for these solutions. Or did I miss something? >> >>Again, the difference here is slight, and I would honestly be happy to >>see >>either of them come to fruition. Please don't infer that I think the >>2vlan method is 'bad' or has intrinsic problems, because I don't believe >>that. I just prefer the multi-PW method. >> >> >>-Josh >> >> >>On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: >> >>>Josh, please see my comments in line. >>> >>>Thanks >>>Yuanlong >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Thursday, May 03, 2012 10:51 AM >>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>(Wim); Lucy yong >>>Cc: l2vpn@ietf.org >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Yuanlong, >>> >>>Or better yet, include in the draft a 'standard' value for root sourced >>>VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You would also >>>have to require the the implementation NOT use global VLAN's, however >>>(since each instance would be using the same values). In this way, no >>>signaling or manual configuration is required for remote PE's to know >>>how >>>to classify traffic. >>>[JY] Indeed, we discussed this possibility during the f2f meeting in >>>Paris. But, there are some restrictions as you mentioned, and >>>furthermore: >>>1) Some vendors already used S-VLAN to distinguish their VSIs in the PE; >>>2) Forwarding plane of a PE needs to be revised to be aware of this VLAN >>>ID. >>>Therefore, this 'standard value' approach seems more disruptive compared >>>with the other means and not a good candidate option. >>> >>>Regarding switching PE's? Multi-PW means more than one PW, yes. I >>>don't >>>see this as a real problem. In general, design should try and avoid >>>using >>>S-PE's, but if you must, its going to mean extra work, no matter how you >>>look at it. Two PW's for each Etree being switched instead of one is >>>not >>>alarming or concerning to me. On the other hand, if you use a dot1q >>>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's >>>an >>>two egress VLAN's if you want the Etree to be handled on both sides (and >>>if you use the 'standard' VID's as I mentioned above, you'd have to do >>>mapping to non-standard and back) >>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>requirements from MEF, it has nothing to do with the solutions. Could >>>you >>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>if configuring or signalling two PWs is not a problem, why configuring >>>or >>>signalling two VLANs will become a problem? After all, more nodes may >>>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>>with 2VLAN (only T-PEs). >>> >>>In general, I still prefer multi-PW, primarily because I prefer the >>>separation of the traffic in the network's forwarding plane, rather than >>>shipping it everywhere and deciding whether to forward to the AC when it >>>gets to the egress PE. I'm having a hard time putting my finger exactly >>>on what it is, or articulating the idea, but it seems that by having the >>>traffic placed into two psuedowires, I have more flexibility and ease of >>>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>>PW's could really change that perception. >>>[JY] Are you saying that we need to develop a totally new forwarding >>>plane rather than using the Ethernet forwarding plane as described in >>>the >>>existing work? >>> >>>I hope we can move forward with one of these soon, >>>[JY] me too. >>> >>>Josh >>> >>> >>>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >>> >>>>Daniel, >>>> >>>>Not aware that we had a discussion on this before, but IMHO the >>>>allocation of internal S-VLAN can be automatic, and manuel >>>>configuration >>>>of this mapping may not be needed at all. For example, an S-VLAN >>>>allocation module in the management plane in a PE can do this kind of >>>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>>way from a free S-VLAN ID pool. Once the interal S-VLANs are allocated, >>>>the mapping is determined and no other configuration is needed. >>>> >>>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>>allocate >>>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to allocate >>>>two S-VLANs in the VPLS domain. >>>> >>>>On the other hand, for the multi-PW approach, two PWs need to be >>>>configured for a E-Tree service. When MS-PW is used in the network, for >>>>every S-PE, we need to configure two ingress PW segments and two egress >>>>PW segments. In this case, I don't think we need to use fixed PW labels >>>>across the network for fear of configuration complexity. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 8:01 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Inline. >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 12:30 PM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, Please see my comments in line. >>>> >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 3:55 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Yuanlong, >>>> >>>>The problem is not with the total number of S-VLAN IDs, I agree that >>>>normally there won't be more than 2047. The problem is that if you >>>>don't >>>>support all VLAN IDs, you need S-VLAN space coordination with the >>>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to >>>>2047". >>>>Which won't always be in line with an existing deployment. >>>>[JY] This is not the case. If the total number is no more than 2047, it >>>>surely can be supported. The S-VLAN space of user domain is totally >>>>different from the S-VLAN in the provider domain and they can be >>>>overlapped, I don't see why we need S-VLAN space coordination between >>>>them. >>>> >>>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>>fixed, and therefore the IEEE S-VID that can be supported is also >>>>fixed. >>>> >>>>Of course you can configure the mapping in each PE according to >>>>operator >>>>requirements but as we discussed before this increases complexity. >>>> >>>>Relying on PBB-VPLS imposes additional limitations on backward >>>>compatibility. >>>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>>think they may well need MAC-in-MAC in their networks for the >>>>scalability issue. As you know, only PBB VPLS can provide both. >>>> >>>>Daniel >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 5:07 AM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, >>>> >>>>As you can see, both cases are discussed in the I-D. >>>> >>>>With regard to case 1) (that is, S-VLAN translation), since the access >>>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>>they need to be configured on a PE anyway, and as the past emails by >>>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>>mapping. >>>> >>>>With regard to S-VID space reduction, the constraint is valid only when >>>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>>typical and with no such limits as we already discussed in the f2f >>>>meeting. >>>> >>>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>>described (not sure this is a valid use case in real life), PBB-VPLS >>>>can >>>>still be used. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Monday, April 30, 2012 10:34 PM >>>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>Jiangyuanlong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>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] >>>>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 >>>> >>>>-------------------------------------------------------------------- -- >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to >>>copyright belonging to Time Warner Cable. This E-mail is intended solely >>>for the use of the individual or entity to which it is addressed. If you >>>are not the intended recipient of this E-mail, you are hereby notified >>>that any dissemination, distribution, copying, or action taken in >>>relation to the contents of and attachments to this E-mail is strictly >>>prohibited and may be unlawful. If you have received this 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. > > >------------------------------ > >Message: 2 >Date: Fri, 4 May 2012 10:30:38 -0400 >From: "Rogers, Josh" >To: Lucy yong , Jiangyuanlong > , Daniel Cohn , >"Fedyk, > Donald (Don)" , "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"iso-8859-2" > >To be more accurate, I like it less than the multi-PW solution. I'd be >happy to use the 2VLAN solution in the real world, if it was ratified as >the standard. > > > >On 5/4/12 9:16 AM, "Lucy yong" wrote: > >>Josh, >> >>You simply say that you don't like IEEE Tree solution. IEEE Tree solution >>is for ingress port to mark and for egress port to filter. >> >>Regards, >>Lucy >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Friday, May 04, 2012 7:27 AM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>also separate the leaf traffic in the ingress PE and filter it there >>(already detailed in the Optimization Mode in the I-D); if the egress PE >>is attached with pure roots or with both roots and leafs, it seems all >>traffic must be transported to the egress PE and be filtered there, I see >>no difference in behaviour for these solutions. Or did I miss something? >> >> >>The point is with the multi-PW method the traffic is split/separated (by >>psuedowire) on the ingress PE, rather than the egress. The distinction >>is >>2VLAN will 'classify' the frame on the ingress PE, so that the egress PE >>knows how to forward it to the appropriate AC's. >> >>Both methods have inefficiencies (one duplicates traffic for transport, >>while the other transports where it doesn't need to go). I like the idea >>of classify and forwarding on the ingress PE, rather than marking it on >>the ingress, and deciding on the egress. >> >>-Josh >> >> >> >>On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: >> >>>Josh, thank you for the comments, please see my further comments with >>>[JY2]. >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Thursday, May 03, 2012 11:27 PM >>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>(Wim); Lucy yong >>>Cc: l2vpn@ietf.org >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>requirements from MEF, it has nothing to do with the solutions. Could >>>you >>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>if >>>configuring or signalling two PWs is not a problem, why configuring or >>>signalling two VLANs will become a problem? After all, more nodes may >>>need >>>to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >>>2VLAN (only T-PEs). >>> >>> >>>There is no other way (if both MPLS domains are part of the same ETREE, >>>rather than doing something more like H-VPLS, where one domain has point >>>to points to the other domain which handles the ETREE instance) if you >>>are >>>using an ENNI. The other method, (not mentioned earlier) is tying the >>>two >>>MPLS domains together via labeled unicast (much preferred over E-NNI in >>>my >>>opinion) >>> >>>Configuring two VLAN's isn't really a 'problem' any more than two PW's. >>>I >>>wasn't saying that configuring two VLAN's was difficult, I was objecting >>>to the statement that configuring two PW's is difficult. >>> >>>[JY2] Thanks, I see your point. I take the example of 2PW configuration >>>just to show that using fixed global values to simplify configuration >>>makes no sense. Personally I also don't think configuration is a problem >>>for both solutions. >>> >>>I find the differences between these two methods rather slight. The >>>'tie-breaker' for me is by placing the forwarding decision on the >>>ingress >>>PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >>>more control over where the traffic goes, and in my mind it provides a >>>cleaner destination between customer traffic and forwarding plane. I'm >>>accustomed to looking at a psuedowire and knowing where its going, with >>>the 2vlan method, I can see the psuedowire, but must go to the egress PE >>>to see if it will be dropped there, or forwarded to one or more AC's. >>> >>>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>>also separate the leaf traffic in the ingress PE and filter it there >>>(already detailed in the Optimization Mode in the I-D); if the egress PE >>>is attached with pure roots or with both roots and leafs, it seems all >>>traffic must be transported to the egress PE and be filtered there, I >>>see >>>no difference in behaviour for these solutions. Or did I miss something? >>> >>>Again, the difference here is slight, and I would honestly be happy to >>>see >>>either of them come to fruition. Please don't infer that I think the >>>2vlan method is 'bad' or has intrinsic problems, because I don't believe >>>that. I just prefer the multi-PW method. >>> >>> >>>-Josh >>> >>> >>>On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: >>> >>>>Josh, please see my comments in line. >>>> >>>>Thanks >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>>Sent: Thursday, May 03, 2012 10:51 AM >>>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>>(Wim); Lucy yong >>>>Cc: l2vpn@ietf.org >>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>> >>>>Yuanlong, >>>> >>>>Or better yet, include in the draft a 'standard' value for root sourced >>>>VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You would also >>>>have to require the the implementation NOT use global VLAN's, however >>>>(since each instance would be using the same values). In this way, no >>>>signaling or manual configuration is required for remote PE's to know >>>>how >>>>to classify traffic. >>>>[JY] Indeed, we discussed this possibility during the f2f meeting in >>>>Paris. But, there are some restrictions as you mentioned, and >>>>furthermore: >>>>1) Some vendors already used S-VLAN to distinguish their VSIs in the >>>>PE; >>>>2) Forwarding plane of a PE needs to be revised to be aware of this >>>>VLAN >>>>ID. >>>>Therefore, this 'standard value' approach seems more disruptive >>>>compared >>>>with the other means and not a good candidate option. >>>> >>>>Regarding switching PE's? Multi-PW means more than one PW, yes. I >>>>don't >>>>see this as a real problem. In general, design should try and avoid >>>>using >>>>S-PE's, but if you must, its going to mean extra work, no matter how >>>>you >>>>look at it. Two PW's for each Etree being switched instead of one is >>>>not >>>>alarming or concerning to me. On the other hand, if you use a dot1q >>>>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's >>>>an >>>>two egress VLAN's if you want the Etree to be handled on both sides >>>>(and >>>>if you use the 'standard' VID's as I mentioned above, you'd have to do >>>>mapping to non-standard and back) >>>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>>requirements from MEF, it has nothing to do with the solutions. Could >>>>you >>>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>>if configuring or signalling two PWs is not a problem, why configuring >>>>or >>>>signalling two VLANs will become a problem? After all, more nodes may >>>>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>>>with 2VLAN (only T-PEs). >>>> >>>>In general, I still prefer multi-PW, primarily because I prefer the >>>>separation of the traffic in the network's forwarding plane, rather >>>>than >>>>shipping it everywhere and deciding whether to forward to the AC when >>>>it >>>>gets to the egress PE. I'm having a hard time putting my finger >>>>exactly >>>>on what it is, or articulating the idea, but it seems that by having >>>>the >>>>traffic placed into two psuedowires, I have more flexibility and ease >>>>of >>>>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>>>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>>>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>>>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>>>PW's could really change that perception. >>>>[JY] Are you saying that we need to develop a totally new forwarding >>>>plane rather than using the Ethernet forwarding plane as described in >>>>the >>>>existing work? >>>> >>>>I hope we can move forward with one of these soon, >>>>[JY] me too. >>>> >>>>Josh >>>> >>>> >>>>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >>>> >>>>>Daniel, >>>>> >>>>>Not aware that we had a discussion on this before, but IMHO the >>>>>allocation of internal S-VLAN can be automatic, and manuel >>>>>configuration >>>>>of this mapping may not be needed at all. For example, an S-VLAN >>>>>allocation module in the management plane in a PE can do this kind of >>>>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>>>way from a free S-VLAN ID pool. Once the interal S-VLANs are >>>>>allocated, >>>>>the mapping is determined and no other configuration is needed. >>>>> >>>>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>>>allocate >>>>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to >>>>>allocate >>>>>two S-VLANs in the VPLS domain. >>>>> >>>>>On the other hand, for the multi-PW approach, two PWs need to be >>>>>configured for a E-Tree service. When MS-PW is used in the network, >>>>>for >>>>>every S-PE, we need to configure two ingress PW segments and two >>>>>egress >>>>>PW segments. In this case, I don't think we need to use fixed PW >>>>>labels >>>>>across the network for fear of configuration complexity. >>>>> >>>>>Regards, >>>>>Yuanlong >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>Sent: Wednesday, May 02, 2012 8:01 PM >>>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; >>>>>josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Inline. >>>>> >>>>>-----Original Message----- >>>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>>Sent: Wednesday, May 02, 2012 12:30 PM >>>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; >>>>>josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Hi Daniel, Please see my comments in line. >>>>> >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>Sent: Wednesday, May 02, 2012 3:55 PM >>>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Hi Yuanlong, >>>>> >>>>>The problem is not with the total number of S-VLAN IDs, I agree that >>>>>normally there won't be more than 2047. The problem is that if you >>>>>don't >>>>>support all VLAN IDs, you need S-VLAN space coordination with the >>>>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to >>>>>2047". >>>>>Which won't always be in line with an existing deployment. >>>>>[JY] This is not the case. If the total number is no more than 2047, >>>>>it >>>>>surely can be supported. The S-VLAN space of user domain is totally >>>>>different from the S-VLAN in the provider domain and they can be >>>>>overlapped, I don't see why we need S-VLAN space coordination between >>>>>them. >>>>> >>>>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>>>fixed, and therefore the IEEE S-VID that can be supported is also >>>>>fixed. >>>>> >>>>>Of course you can configure the mapping in each PE according to >>>>>operator >>>>>requirements but as we discussed before this increases complexity. >>>>> >>>>>Relying on PBB-VPLS imposes additional limitations on backward >>>>>compatibility. >>>>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>>>think they may well need MAC-in-MAC in their networks for the >>>>>scalability issue. As you know, only PBB VPLS can provide both. >>>>> >>>>>Daniel >>>>> >>>>>-----Original Message----- >>>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>>Sent: Wednesday, May 02, 2012 5:07 AM >>>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; >>>>>josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Hi Daniel, >>>>> >>>>>As you can see, both cases are discussed in the I-D. >>>>> >>>>>With regard to case 1) (that is, S-VLAN translation), since the access >>>>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>>>they need to be configured on a PE anyway, and as the past emails by >>>>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>>>mapping. >>>>> >>>>>With regard to S-VID space reduction, the constraint is valid only >>>>>when >>>>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>>>typical and with no such limits as we already discussed in the f2f >>>>>meeting. >>>>> >>>>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>>>described (not sure this is a valid use case in real life), PBB-VPLS >>>>>can >>>>>still be used. >>>>> >>>>>Regards, >>>>>Yuanlong >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>Sent: Monday, April 30, 2012 10:34 PM >>>>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>>Jiangyuanlong; josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>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] >>>>>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 >>>>> >>>>>------------------------------------------------------------------- --- >>>> >>>> >>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>proprietary information, which is privileged, confidential, or subject >>>>to >>>>copyright belonging to Time Warner Cable. This E-mail is intended >>>>solely >>>>for the use of the individual or entity to which it is addressed. If >>>>you >>>>are not the intended recipient of this E-mail, you are hereby notified >>>>that any dissemination, distribution, copying, or action taken in >>>>relation to the contents of and attachments to this E-mail is strictly >>>>prohibited and may be unlawful. If you have received this 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 and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for >the use of the individual or entity to which it is addressed. If you are >not >the intended recipient of this E-mail, you are hereby notified that any >dissemination, distribution, copying, or action taken in relation to the >contents of and attachments to this E-mail is strictly prohibited and may >be >unlawful. If you have received this 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 96, Issue 15 >************************************* > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this 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 DanielC@orckit.com Tue May 8 06:27: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 7F7BE21F8547 for ; Tue, 8 May 2012 06:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=-0.191, 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 cxATw5Y8uYgX for ; Tue, 8 May 2012 06:27:33 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id B833B21F848F for ; Tue, 8 May 2012 06:27:31 -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: L2vpn Digest, Vol 96, Issue 15 Date: Tue, 8 May 2012 16:29:26 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780CB27@tlvmail1> In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410BFF@szxeml546-mbx.china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: L2vpn Digest, Vol 96, Issue 15 Thread-Index: AQHNKgNyPxr7nh+DX0S+AUfrSOoOpZa57ewAgARPYACAABdtgIAA8VnQgABOaUCAAAEZoIAABFOggABM/3CAAAFowA== References: <2691CE0099834E4A9C5044EEC662BB9D330F0740@dfweml506-mbx> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410ABC@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CA64@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410B5D@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CA6E@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410BFF@szxeml546-mbx.china.huawei.com> From: "Daniel Cohn" To: "Jiangyuanlong" , "Rogers, Josh" , "Lucy yong" , "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: Tue, 08 May 2012 13:27:36 -0000 Yuanlong, I don't see the additional complexity. Existing PW maintenance processes at the operator can take care of the additional root/leaf PWs exactly like they do today. Only they will have some more PWs to maintain (not twice as much, since most PEs are typically leaf-only and therefore have only a root PW per E-Tree instance) And service maintenance processes should be extended to maintain root and leaf services using E-OAM, both for the 2-VLAN and multi-PW solutions. DC -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Tuesday, May 08, 2012 4:23 PM To: Daniel Cohn; Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 Daniel, RFC 6136 provides the VPLS OAM reqs and framework, and Sec. 10.1. gives the typical VPLS OAM Operational Scenarios: --- --- / \ ------ ------- ---- / \ | A CE-- / \ / \ / \ --CE A | \ / \ / \ / \ / \ / \ / --- --UPE NPE NPE UPE-- --- \ / \ / \ / \ / \ / \ / ------ ------- ---- Customer OAM Domain (C) MEP---MIP--------------------------------MIP---MEP Service Provider (SP) OAM Domain (D) MEP--------MIP-----------MIP-------MEP SP OAM SP OAM SP OAM (D1) MEP-MIP--MEP|MEP-------MEP|MEP-----MEP domain domain domain Operator Operator Operator (E) MEP-MIP--MEP|MEP-------MEP|MEP-----MEP OAM domain OAM domain OAM domain MPLS OAM MPLS OAM (F) MEP--MIP-----MEP--MIP--MEP domain domain Figure 10: VPLS OAM Domains, MEPs, and MIPs It seems OAM configurations in Scenario D1) and E) for 2PW approach will be much complicated and error prone, since E-Tree OAM now needs to interwork with one of these two PWs' OAM (maybe both, I am afraid). For scenario F), the concatanation of two MPLS OAM also needs to be very careful as 4 PWs and 3 types (i.e, root/leaf/normal) may be involved there. Regards, Yuanlong -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Tuesday, May 08, 2012 4:49 PM To: Jiangyuanlong; Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 Inline -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Tuesday, May 08, 2012 11:42 AM To: Daniel Cohn; Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 I don't think so. There may be different layers of OAM applicable to a service. Such as LSP layer, PW layer, and service layer. [DC] Agreed Now you cannot use a single LSP OAM to monitor the server layer of the E-Tree service (as 2 LSP may be involved). And the service layer of OAM for E-Tree may be distributed to different LSP paths. [DC] For E-Tree service OAM, you would perform OAM actions from MEPs associated to root or leaf ACs, so the E-OAM frames would naturally follow the root or leaf pseudowires and the LSPs that transport them. I don't see a limitation here. -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Tuesday, May 08, 2012 4:28 PM To: Jiangyuanlong; Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 Yuanlong, isn't this orthogonal to the issues we are discussing? I mean, there are different mechanisms to troubleshoot PWs, all of which are applicable to root/leaf PWs as to any other PWs. Or is there any specific limitation on root/leaf PW troubleshooting, compared to "regular" PWs used in VPLSs? Thanks, Daniel -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Jiangyuanlong Sent: Tuesday, May 08, 2012 7:04 AM To: Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 Josh,=20 Just some comments on this part: [JR] I don't see this any more of a problem than troubleshooting one. If LDP is used, a simple mols traceroute shows the path that ALL PW's to that PE take, regardless of which service (this VPLS or another VPLS instance). If RSVP is used, there should be a route-object that shows me the path, and allows me to troubleshoot. Additionally, if I wanted to have traffic engineering that impacted root-sourced and leaf-sourced traffic differently, I can do that with multi-PW, where I could not (save for ingress/egress) with the 2VLAN approach. PE should report signaling on second PW same as it does for the 100th PW between PE's. Again, I don't see the problem you are alluding to. I suppose you are referring to LSP Ping on the LSP layer, yes, it can oversee all the PWs in this LSP. If both root and leaf PW are in the same LSP, it can work. But there may well be multiple LSPs between a pair of PEs, and root/leaf PW may be transported on different LSPs. Another difficulty is, if ECMP is deployed and PW label as a bottom label is used for hashing, the OAM message may be load balanced on different paths. With regard to TE, you could use DS-TE, just as Lucy said, two PW do not guarantee they are traffic engineered. Thanks Yuanlong -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com]=20 Sent: Tuesday, May 08, 2012 5:22 AM To: Lucy yong; Sam Cao; l2vpn@ietf.org Cc: Jiangyuanlong Subject: Re: L2vpn Digest, Vol 96, Issue 15 Comments inline (and s/conquer/concur/) On 5/7/12 2:58 PM, "Lucy yong" wrote: >Sam, > >I concur with Yuanlong's reply on this. Please see inline. > >Lucy > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >Sam Cao >Sent: Friday, May 04, 2012 9:09 PM >To: l2vpn@ietf.org >Cc: Jiangyuanlong >Subject: RE: L2vpn Digest, Vol 96, Issue 15 > >Lucy/Yuanlong, > >I agree that we can not say which approach is better simply, but I really >agree with Josh's comments. Multi-PW is easy to implement E-Tree. >[[LY]] I don't get impression Josh state this. > >First of all, we discussed 2 approaches for a long time and many rounds, >and >for me, there are no pending issues on Multi-PW till now or co-authors of >multi-PW have given reasonable reply to L2VPN members' questions, but >there >are still pending issues for Dual-VLAN. Please trace the mailing list. >[[LY]] I interpret this as people want to spend time to finalize dual >VLAN solution. Multi-PW has some operation impact. How do operator to >maintain this service and be able to trouble shooting. How do you expect >traceroute work when using two PWs for one VPN? How do you expect PE >report when there is an error on one of two PWs? Do you have one FEC or >two FEC for a E-Tree in control plane? [JR] I don't see this any more of a problem than troubleshooting one. If LDP is used, a simple mols traceroute shows the path that ALL PW's to that PE take, regardless of which service (this VPLS or another VPLS instance). If RSVP is used, there should be a route-object that shows me the path, and allows me to troubleshoot. Additionally, if I wanted to have traffic engineering that impacted root-sourced and leaf-sourced traffic differently, I can do that with multi-PW, where I could not (save for ingress/egress) with the 2VLAN approach. PE should report signaling on second PW same as it does for the 100th PW between PE's. Again, I don't see the problem you are alluding to. > >Second, Sasha has his concern in NP, or forwarding performance. Compared >to >current VPLS, Multi-PW has a little effect on forwarding performance since >it reuse PW label as AC indicator; Dual-VLAN will have higher side effect >on >forwarding performance because it SHOULD use additional indicator. Is >there >one prototype for Dual-VLAN? BTW, there is no reply on chip limit. >[[LY]] in VPLS, PW label is used as VSI indicator, not AC. I disagree >your statement here. > >Third, the difference between Multi-PW and dual-VLAN is, transport ingress >traffic in one "LSP" or 2 "LSP". Multi-PW classifies and transforms >ingress >traffic into right "path", and egress just pop-out PW label and forward >the >frame to ACs. Dual-VLAN has more work on ingress PE or egress PE. >[[LY]] Don't understand the first part. When egress pop-out PW label, it >find corresponding VSI first, then perform MAC lookup associated to all >ACs. We can't assume there is one AC. > >Fourth, maybe Giles has figured this out, Dual-VLAN has capacity limit. >Only >4094 VLAN ID are available, so only 2K E-Tree instances can be supported >on >one PE for Dual-VLAN approach. There is no such limit for Multi-PW >approach, >[[LY]] If 4K VLAN ID is not an issue for VPLS, it is not an issue for >E-Tree. > >Finally, in this thread we don't make agreement on VLAN ID allocation. We >also have questions on VLAN ID negotiation among PEs (signaling protocol). >Yuanlong wishes to update, but there is no update till now. >[[LY]] This should not be the reason to judge on the solution. [JR] I tend to agree. > >For me, why IEEE uses VLAN ID to identify AC type? IEEE has no LABEL :), >and >it has label, it also wish to use label to identify AC types. I think that >both solutions need much time to be perfect. Mutli-PW has less extension >work to do. But now we are focusing on technical details and can not move >forward :). >[[LY]] VPN label is used for identify the VPN. It already has the >purpose. Overloading with other meaning has high potential causing a >problem. Hope you can investigate it more. Since you are very in favor of >multi-pw solution, it is not proper for you to come out the conclusion >which is better, because it is very biased. You are welcome to help on >completing either solution. [JR] this is humorous to me, because at one time, VLAN-ID was used to identify a single broadcast domain, and then later asymmetrical VID's were used to limit communication between endpoints of a broadcast domain (effectively creating two one-way broadcast domains, very similar to what we're accomplishing with ETREE). This should not be the reason to judge on the solution. > >Regards, >Lucy > >Lucy > >Thanks, > >Sam > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >l2vpn-request@ietf.org >Sent: Friday, May 04, 2012 10:31 PM >To: l2vpn@ietf.org >Subject: L2vpn Digest, Vol 96, Issue 15 > >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) > 2. Re: The status of the approaches to the E-Tree solution? > (Rogers, Josh) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Fri, 4 May 2012 14:16:36 +0000 >From: Lucy yong >To: "Rogers, Josh" , Jiangyuanlong > , Daniel Cohn , >"Fedyk, > Donald (Don)" , "Henderickx, Wim > (Wim)" >Cc: "l2vpn@ietf.org" >Subject: RE: The status of the approaches to the E-Tree solution? >Message-ID: <2691CE0099834E4A9C5044EEC662BB9D330E9114@dfweml505-mbx> >Content-Type: text/plain; charset=3D"iso-8859-2" > >Josh, > >You simply say that you don't like IEEE Tree solution. IEEE Tree solution >is >for ingress port to mark and for egress port to filter. > >Regards, >Lucy > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Friday, May 04, 2012 7:27 AM >To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >(Wim); >Lucy yong >Cc: l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >also separate the leaf traffic in the ingress PE and filter it there >(already detailed in the Optimization Mode in the I-D); if the egress PE >is attached with pure roots or with both roots and leafs, it seems all >traffic must be transported to the egress PE and be filtered there, I see >no difference in behaviour for these solutions. Or did I miss something? > > >The point is with the multi-PW method the traffic is split/separated (by >psuedowire) on the ingress PE, rather than the egress. The distinction is >2VLAN will 'classify' the frame on the ingress PE, so that the egress PE >knows how to forward it to the appropriate AC's. > >Both methods have inefficiencies (one duplicates traffic for transport, >while the other transports where it doesn't need to go). I like the idea >of classify and forwarding on the ingress PE, rather than marking it on >the ingress, and deciding on the egress. > >-Josh > > > >On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: > >>Josh, thank you for the comments, please see my further comments with >>[JY2]. >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Thursday, May 03, 2012 11:27 PM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>requirements from MEF, it has nothing to do with the solutions. Could you >>give a hint on how you can provision this service E-NNI otherwise? BTW, >>if >>configuring or signalling two PWs is not a problem, why configuring or >>signalling two VLANs will become a problem? After all, more nodes may >>need >>to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >>2VLAN (only T-PEs). >> >> >>There is no other way (if both MPLS domains are part of the same ETREE, >>rather than doing something more like H-VPLS, where one domain has point >>to points to the other domain which handles the ETREE instance) if you >>are >>using an ENNI. The other method, (not mentioned earlier) is tying the >>two >>MPLS domains together via labeled unicast (much preferred over E-NNI in >>my >>opinion) >> >>Configuring two VLAN's isn't really a 'problem' any more than two PW's. >>I >>wasn't saying that configuring two VLAN's was difficult, I was objecting >>to the statement that configuring two PW's is difficult. >> >>[JY2] Thanks, I see your point. I take the example of 2PW configuration >>just to show that using fixed global values to simplify configuration >>makes no sense. Personally I also don't think configuration is a problem >>for both solutions. >> >>I find the differences between these two methods rather slight. The >>'tie-breaker' for me is by placing the forwarding decision on the ingress >>PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >>more control over where the traffic goes, and in my mind it provides a >>cleaner destination between customer traffic and forwarding plane. I'm >>accustomed to looking at a psuedowire and knowing where its going, with >>the 2vlan method, I can see the psuedowire, but must go to the egress PE >>to see if it will be dropped there, or forwarded to one or more AC's. >> >>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>also separate the leaf traffic in the ingress PE and filter it there >>(already detailed in the Optimization Mode in the I-D); if the egress PE >>is attached with pure roots or with both roots and leafs, it seems all >>traffic must be transported to the egress PE and be filtered there, I see >>no difference in behaviour for these solutions. Or did I miss something? >> >>Again, the difference here is slight, and I would honestly be happy to >>see >>either of them come to fruition. Please don't infer that I think the >>2vlan method is 'bad' or has intrinsic problems, because I don't believe >>that. I just prefer the multi-PW method. >> >> >>-Josh >> >> >>On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: >> >>>Josh, please see my comments in line. >>> >>>Thanks >>>Yuanlong >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Thursday, May 03, 2012 10:51 AM >>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>(Wim); Lucy yong >>>Cc: l2vpn@ietf.org >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Yuanlong, >>> >>>Or better yet, include in the draft a 'standard' value for root sourced >>>VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You would also >>>have to require the the implementation NOT use global VLAN's, however >>>(since each instance would be using the same values). In this way, no >>>signaling or manual configuration is required for remote PE's to know >>>how >>>to classify traffic. >>>[JY] Indeed, we discussed this possibility during the f2f meeting in >>>Paris. But, there are some restrictions as you mentioned, and >>>furthermore: >>>1) Some vendors already used S-VLAN to distinguish their VSIs in the PE; >>>2) Forwarding plane of a PE needs to be revised to be aware of this VLAN >>>ID. >>>Therefore, this 'standard value' approach seems more disruptive compared >>>with the other means and not a good candidate option. >>> >>>Regarding switching PE's? Multi-PW means more than one PW, yes. I >>>don't >>>see this as a real problem. In general, design should try and avoid >>>using >>>S-PE's, but if you must, its going to mean extra work, no matter how you >>>look at it. Two PW's for each Etree being switched instead of one is >>>not >>>alarming or concerning to me. On the other hand, if you use a dot1q >>>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's >>>an >>>two egress VLAN's if you want the Etree to be handled on both sides (and >>>if you use the 'standard' VID's as I mentioned above, you'd have to do >>>mapping to non-standard and back) >>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>requirements from MEF, it has nothing to do with the solutions. Could >>>you >>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>if configuring or signalling two PWs is not a problem, why configuring >>>or >>>signalling two VLANs will become a problem? After all, more nodes may >>>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>>with 2VLAN (only T-PEs). >>> >>>In general, I still prefer multi-PW, primarily because I prefer the >>>separation of the traffic in the network's forwarding plane, rather than >>>shipping it everywhere and deciding whether to forward to the AC when it >>>gets to the egress PE. I'm having a hard time putting my finger exactly >>>on what it is, or articulating the idea, but it seems that by having the >>>traffic placed into two psuedowires, I have more flexibility and ease of >>>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>>PW's could really change that perception. >>>[JY] Are you saying that we need to develop a totally new forwarding >>>plane rather than using the Ethernet forwarding plane as described in >>>the >>>existing work? >>> >>>I hope we can move forward with one of these soon, >>>[JY] me too. >>> >>>Josh >>> >>> >>>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >>> >>>>Daniel, >>>> >>>>Not aware that we had a discussion on this before, but IMHO the >>>>allocation of internal S-VLAN can be automatic, and manuel >>>>configuration >>>>of this mapping may not be needed at all. For example, an S-VLAN >>>>allocation module in the management plane in a PE can do this kind of >>>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>>way from a free S-VLAN ID pool. Once the interal S-VLANs are allocated, >>>>the mapping is determined and no other configuration is needed. >>>> >>>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>>allocate >>>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to allocate >>>>two S-VLANs in the VPLS domain. >>>> >>>>On the other hand, for the multi-PW approach, two PWs need to be >>>>configured for a E-Tree service. When MS-PW is used in the network, for >>>>every S-PE, we need to configure two ingress PW segments and two egress >>>>PW segments. In this case, I don't think we need to use fixed PW labels >>>>across the network for fear of configuration complexity. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 8:01 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Inline. >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 12:30 PM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, Please see my comments in line. >>>> >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 3:55 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Yuanlong, >>>> >>>>The problem is not with the total number of S-VLAN IDs, I agree that >>>>normally there won't be more than 2047. The problem is that if you >>>>don't >>>>support all VLAN IDs, you need S-VLAN space coordination with the >>>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to >>>>2047". >>>>Which won't always be in line with an existing deployment. >>>>[JY] This is not the case. If the total number is no more than 2047, it >>>>surely can be supported. The S-VLAN space of user domain is totally >>>>different from the S-VLAN in the provider domain and they can be >>>>overlapped, I don't see why we need S-VLAN space coordination between >>>>them. >>>> >>>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>>fixed, and therefore the IEEE S-VID that can be supported is also >>>>fixed. >>>> >>>>Of course you can configure the mapping in each PE according to >>>>operator >>>>requirements but as we discussed before this increases complexity. >>>> >>>>Relying on PBB-VPLS imposes additional limitations on backward >>>>compatibility. >>>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>>think they may well need MAC-in-MAC in their networks for the >>>>scalability issue. As you know, only PBB VPLS can provide both. >>>> >>>>Daniel >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 5:07 AM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, >>>> >>>>As you can see, both cases are discussed in the I-D. >>>> >>>>With regard to case 1) (that is, S-VLAN translation), since the access >>>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>>they need to be configured on a PE anyway, and as the past emails by >>>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>>mapping. >>>> >>>>With regard to S-VID space reduction, the constraint is valid only when >>>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>>typical and with no such limits as we already discussed in the f2f >>>>meeting. >>>> >>>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>>described (not sure this is a valid use case in real life), PBB-VPLS >>>>can >>>>still be used. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Monday, April 30, 2012 10:34 PM >>>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>Jiangyuanlong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>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] >>>>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 >>>> >>>>-------------------------------------------------------------------- -- >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to >>>copyright belonging to Time Warner Cable. This E-mail is intended solely >>>for the use of the individual or entity to which it is addressed. If you >>>are not the intended recipient of this E-mail, you are hereby notified >>>that any dissemination, distribution, copying, or action taken in >>>relation to the contents of and attachments to this E-mail is strictly >>>prohibited and may be unlawful. If you have received this 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. > > >------------------------------ > >Message: 2 >Date: Fri, 4 May 2012 10:30:38 -0400 >From: "Rogers, Josh" >To: Lucy yong , Jiangyuanlong > , Daniel Cohn , >"Fedyk, > Donald (Don)" , "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"iso-8859-2" > >To be more accurate, I like it less than the multi-PW solution. I'd be >happy to use the 2VLAN solution in the real world, if it was ratified as >the standard. > > > >On 5/4/12 9:16 AM, "Lucy yong" wrote: > >>Josh, >> >>You simply say that you don't like IEEE Tree solution. IEEE Tree solution >>is for ingress port to mark and for egress port to filter. >> >>Regards, >>Lucy >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Friday, May 04, 2012 7:27 AM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>also separate the leaf traffic in the ingress PE and filter it there >>(already detailed in the Optimization Mode in the I-D); if the egress PE >>is attached with pure roots or with both roots and leafs, it seems all >>traffic must be transported to the egress PE and be filtered there, I see >>no difference in behaviour for these solutions. Or did I miss something? >> >> >>The point is with the multi-PW method the traffic is split/separated (by >>psuedowire) on the ingress PE, rather than the egress. The distinction >>is >>2VLAN will 'classify' the frame on the ingress PE, so that the egress PE >>knows how to forward it to the appropriate AC's. >> >>Both methods have inefficiencies (one duplicates traffic for transport, >>while the other transports where it doesn't need to go). I like the idea >>of classify and forwarding on the ingress PE, rather than marking it on >>the ingress, and deciding on the egress. >> >>-Josh >> >> >> >>On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: >> >>>Josh, thank you for the comments, please see my further comments with >>>[JY2]. >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Thursday, May 03, 2012 11:27 PM >>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>(Wim); Lucy yong >>>Cc: l2vpn@ietf.org >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>requirements from MEF, it has nothing to do with the solutions. Could >>>you >>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>if >>>configuring or signalling two PWs is not a problem, why configuring or >>>signalling two VLANs will become a problem? After all, more nodes may >>>need >>>to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >>>2VLAN (only T-PEs). >>> >>> >>>There is no other way (if both MPLS domains are part of the same ETREE, >>>rather than doing something more like H-VPLS, where one domain has point >>>to points to the other domain which handles the ETREE instance) if you >>>are >>>using an ENNI. The other method, (not mentioned earlier) is tying the >>>two >>>MPLS domains together via labeled unicast (much preferred over E-NNI in >>>my >>>opinion) >>> >>>Configuring two VLAN's isn't really a 'problem' any more than two PW's. >>>I >>>wasn't saying that configuring two VLAN's was difficult, I was objecting >>>to the statement that configuring two PW's is difficult. >>> >>>[JY2] Thanks, I see your point. I take the example of 2PW configuration >>>just to show that using fixed global values to simplify configuration >>>makes no sense. Personally I also don't think configuration is a problem >>>for both solutions. >>> >>>I find the differences between these two methods rather slight. The >>>'tie-breaker' for me is by placing the forwarding decision on the >>>ingress >>>PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >>>more control over where the traffic goes, and in my mind it provides a >>>cleaner destination between customer traffic and forwarding plane. I'm >>>accustomed to looking at a psuedowire and knowing where its going, with >>>the 2vlan method, I can see the psuedowire, but must go to the egress PE >>>to see if it will be dropped there, or forwarded to one or more AC's. >>> >>>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>>also separate the leaf traffic in the ingress PE and filter it there >>>(already detailed in the Optimization Mode in the I-D); if the egress PE >>>is attached with pure roots or with both roots and leafs, it seems all >>>traffic must be transported to the egress PE and be filtered there, I >>>see >>>no difference in behaviour for these solutions. Or did I miss something? >>> >>>Again, the difference here is slight, and I would honestly be happy to >>>see >>>either of them come to fruition. Please don't infer that I think the >>>2vlan method is 'bad' or has intrinsic problems, because I don't believe >>>that. I just prefer the multi-PW method. >>> >>> >>>-Josh >>> >>> >>>On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: >>> >>>>Josh, please see my comments in line. >>>> >>>>Thanks >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>>Sent: Thursday, May 03, 2012 10:51 AM >>>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>>(Wim); Lucy yong >>>>Cc: l2vpn@ietf.org >>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>> >>>>Yuanlong, >>>> >>>>Or better yet, include in the draft a 'standard' value for root sourced >>>>VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You = would also >>>>have to require the the implementation NOT use global VLAN's, however >>>>(since each instance would be using the same values). In this way, no >>>>signaling or manual configuration is required for remote PE's to know >>>>how >>>>to classify traffic. >>>>[JY] Indeed, we discussed this possibility during the f2f meeting in >>>>Paris. But, there are some restrictions as you mentioned, and >>>>furthermore: >>>>1) Some vendors already used S-VLAN to distinguish their VSIs in the >>>>PE; >>>>2) Forwarding plane of a PE needs to be revised to be aware of this >>>>VLAN >>>>ID. >>>>Therefore, this 'standard value' approach seems more disruptive >>>>compared >>>>with the other means and not a good candidate option. >>>> >>>>Regarding switching PE's? Multi-PW means more than one PW, yes. I >>>>don't >>>>see this as a real problem. In general, design should try and avoid >>>>using >>>>S-PE's, but if you must, its going to mean extra work, no matter how >>>>you >>>>look at it. Two PW's for each Etree being switched instead of one is >>>>not >>>>alarming or concerning to me. On the other hand, if you use a dot1q >>>>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's >>>>an >>>>two egress VLAN's if you want the Etree to be handled on both sides >>>>(and >>>>if you use the 'standard' VID's as I mentioned above, you'd have to do >>>>mapping to non-standard and back) >>>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>>requirements from MEF, it has nothing to do with the solutions. Could >>>>you >>>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>>if configuring or signalling two PWs is not a problem, why configuring >>>>or >>>>signalling two VLANs will become a problem? After all, more nodes may >>>>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>>>with 2VLAN (only T-PEs). >>>> >>>>In general, I still prefer multi-PW, primarily because I prefer the >>>>separation of the traffic in the network's forwarding plane, rather >>>>than >>>>shipping it everywhere and deciding whether to forward to the AC when >>>>it >>>>gets to the egress PE. I'm having a hard time putting my finger >>>>exactly >>>>on what it is, or articulating the idea, but it seems that by having >>>>the >>>>traffic placed into two psuedowires, I have more flexibility and ease >>>>of >>>>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>>>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>>>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>>>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>>>PW's could really change that perception. >>>>[JY] Are you saying that we need to develop a totally new forwarding >>>>plane rather than using the Ethernet forwarding plane as described in >>>>the >>>>existing work? >>>> >>>>I hope we can move forward with one of these soon, >>>>[JY] me too. >>>> >>>>Josh >>>> >>>> >>>>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >>>> >>>>>Daniel, >>>>> >>>>>Not aware that we had a discussion on this before, but IMHO the >>>>>allocation of internal S-VLAN can be automatic, and manuel >>>>>configuration >>>>>of this mapping may not be needed at all. For example, an S-VLAN >>>>>allocation module in the management plane in a PE can do this kind of >>>>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>>>way from a free S-VLAN ID pool. Once the interal S-VLANs are >>>>>allocated, >>>>>the mapping is determined and no other configuration is needed. >>>>> >>>>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>>>allocate >>>>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to >>>>>allocate >>>>>two S-VLANs in the VPLS domain. >>>>> >>>>>On the other hand, for the multi-PW approach, two PWs need to be >>>>>configured for a E-Tree service. When MS-PW is used in the network, >>>>>for >>>>>every S-PE, we need to configure two ingress PW segments and two >>>>>egress >>>>>PW segments. In this case, I don't think we need to use fixed PW >>>>>labels >>>>>across the network for fear of configuration complexity. >>>>> >>>>>Regards, >>>>>Yuanlong >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>Sent: Wednesday, May 02, 2012 8:01 PM >>>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; >>>>>josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Inline. >>>>> >>>>>-----Original Message----- >>>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>>Sent: Wednesday, May 02, 2012 12:30 PM >>>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; >>>>>josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Hi Daniel, Please see my comments in line. >>>>> >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>Sent: Wednesday, May 02, 2012 3:55 PM >>>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Hi Yuanlong, >>>>> >>>>>The problem is not with the total number of S-VLAN IDs, I agree that >>>>>normally there won't be more than 2047. The problem is that if you >>>>>don't >>>>>support all VLAN IDs, you need S-VLAN space coordination with the >>>>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to >>>>>2047". >>>>>Which won't always be in line with an existing deployment. >>>>>[JY] This is not the case. If the total number is no more than 2047, >>>>>it >>>>>surely can be supported. The S-VLAN space of user domain is totally >>>>>different from the S-VLAN in the provider domain and they can be >>>>>overlapped, I don't see why we need S-VLAN space coordination between >>>>>them. >>>>> >>>>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>>>fixed, and therefore the IEEE S-VID that can be supported is also >>>>>fixed. >>>>> >>>>>Of course you can configure the mapping in each PE according to >>>>>operator >>>>>requirements but as we discussed before this increases complexity. >>>>> >>>>>Relying on PBB-VPLS imposes additional limitations on backward >>>>>compatibility. >>>>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>>>think they may well need MAC-in-MAC in their networks for the >>>>>scalability issue. As you know, only PBB VPLS can provide both. >>>>> >>>>>Daniel >>>>> >>>>>-----Original Message----- >>>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>>Sent: Wednesday, May 02, 2012 5:07 AM >>>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; >>>>>josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Hi Daniel, >>>>> >>>>>As you can see, both cases are discussed in the I-D. >>>>> >>>>>With regard to case 1) (that is, S-VLAN translation), since the access >>>>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>>>they need to be configured on a PE anyway, and as the past emails by >>>>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>>>mapping. >>>>> >>>>>With regard to S-VID space reduction, the constraint is valid only >>>>>when >>>>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>>>typical and with no such limits as we already discussed in the f2f >>>>>meeting. >>>>> >>>>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>>>described (not sure this is a valid use case in real life), PBB-VPLS >>>>>can >>>>>still be used. >>>>> >>>>>Regards, >>>>>Yuanlong >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>Sent: Monday, April 30, 2012 10:34 PM >>>>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>>Jiangyuanlong; josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>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] >>>>>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 >>>>> >>>>>------------------------------------------------------------------- --- >>>> >>>> >>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>proprietary information, which is privileged, confidential, or subject >>>>to >>>>copyright belonging to Time Warner Cable. This E-mail is intended >>>>solely >>>>for the use of the individual or entity to which it is addressed. If >>>>you >>>>are not the intended recipient of this E-mail, you are hereby notified >>>>that any dissemination, distribution, copying, or action taken in >>>>relation to the contents of and attachments to this E-mail is strictly >>>>prohibited and may be unlawful. If you have received this 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 and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for >the use of the individual or entity to which it is addressed. If you are >not >the intended recipient of this E-mail, you are hereby notified that any >dissemination, distribution, copying, or action taken in relation to the >contents of and attachments to this E-mail is strictly prohibited and may >be >unlawful. If you have received this 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 96, Issue 15 >************************************* > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this 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 May 8 06:31: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 F092021F84DC for ; Tue, 8 May 2012 06:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.128 X-Spam-Level: X-Spam-Status: No, score=-2.128 tagged_above=-999 required=5 tests=[AWL=-0.129, 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 eDRYNROFNAbB for ; Tue, 8 May 2012 06:31:41 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6B25121F8499 for ; Tue, 8 May 2012 06:31:38 -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 AFP85249; Tue, 08 May 2012 09:31:38 -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; Tue, 8 May 2012 06:29:06 -0700 Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 8 May 2012 06:29:04 -0700 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.183]) by szxeml418-hub.china.huawei.com ([10.82.67.157]) with mapi id 14.01.0323.003; Tue, 8 May 2012 21:28:54 +0800 From: Jiangyuanlong To: Daniel Cohn , "Rogers, Josh" , Lucy yong , Sam Cao , "l2vpn@ietf.org" Subject: RE: L2vpn Digest, Vol 96, Issue 15 Thread-Topic: L2vpn Digest, Vol 96, Issue 15 Thread-Index: AQHNKgNyPxr7nh+DX0S+AUfrSOoOpZa57ewAgARPYACAABdtgIAA8VnQgABOaUCAAAEZoIAABFOggAAHB2CAAEStQIAAAgNg Date: Tue, 8 May 2012 13:28:53 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410C42@szxeml546-mbx.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D330F0740@dfweml506-mbx> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410ABC@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CA64@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410B5D@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CA6E@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410BBC@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CB22@tlvmail1> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA08130780CB22@tlvmail1> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.40.73] 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: Tue, 08 May 2012 13:31:45 -0000 RFC 6136 explicitly calls out IEEE Std. 802.1ag-2007.=20 Please also refer to Fig.10 of RFC 6136 and Section 10.1: "Inside the network operator OAM domain, [IEEE802.1ag] and [Y.1731] Ethernet OAM mechanisms can also be applied across MEs in (E) in Figure 10 to meet the functional requirements identified in Section 7." Regards Yuanlong -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Tuesday, May 08, 2012 9:23 PM To: Jiangyuanlong; Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 Yuanlong, where in RFC 6136 (or anywhere else) do you see a requirement for down MEPs in a PE? As I see it, down MEPs in a PE should be MPLS MEPs and not E-OAM MEPs, since the core cannot always be assumed to be Ethernet.=20 Daniel -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Tuesday, May 08, 2012 3:18 PM To: Daniel Cohn; Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 Inline -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Tuesday, May 08, 2012 11:42 AM To: Daniel Cohn; Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 I don't think so. There may be different layers of OAM applicable to a service. Such as LSP layer, PW layer, and service layer. [DC] Agreed Now you cannot use a single LSP OAM to monitor the server layer of the E-Tree service (as 2 LSP may be involved). And the service layer of OAM for E-Tree may be distributed to different LSP paths. [DC] For E-Tree service OAM, you would perform OAM actions from MEPs associated to root or leaf ACs, so the E-OAM frames would naturally follow the root or leaf pseudowires and the LSPs that transport them. I don't see a limitation here. [JY] Now you need to monitor two LSPs and/or two PWs between mixed PEs for this E-Tree. Besides the UP MEPs (associated with access port) as you mentioned, DOWN MEPs may also be needed (facing core) where both root and leaf traffic cross, not sure how you will configure OAM for them. Regards, Yuanlong -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Tuesday, May 08, 2012 4:28 PM To: Jiangyuanlong; Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 Yuanlong, isn't this orthogonal to the issues we are discussing? I mean, there are different mechanisms to troubleshoot PWs, all of which are applicable to root/leaf PWs as to any other PWs. Or is there any specific limitation on root/leaf PW troubleshooting, compared to "regular" PWs used in VPLSs? Thanks, Daniel -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Jiangyuanlong Sent: Tuesday, May 08, 2012 7:04 AM To: Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 Josh,=20 Just some comments on this part: [JR] I don't see this any more of a problem than troubleshooting one. If LDP is used, a simple mols traceroute shows the path that ALL PW's to that PE take, regardless of which service (this VPLS or another VPLS instance). If RSVP is used, there should be a route-object that shows me the path, and allows me to troubleshoot. Additionally, if I wanted to have traffic engineering that impacted root-sourced and leaf-sourced traffic differently, I can do that with multi-PW, where I could not (save for ingress/egress) with the 2VLAN approach. PE should report signaling on second PW same as it does for the 100th PW between PE's. Again, I don't see the problem you are alluding to. I suppose you are referring to LSP Ping on the LSP layer, yes, it can oversee all the PWs in this LSP. If both root and leaf PW are in the same LSP, it can work. But there may well be multiple LSPs between a pair of PEs, and root/leaf PW may be transported on different LSPs. Another difficulty is, if ECMP is deployed and PW label as a bottom label is used for hashing, the OAM message may be load balanced on different paths. With regard to TE, you could use DS-TE, just as Lucy said, two PW do not guarantee they are traffic engineered. Thanks Yuanlong -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com]=20 Sent: Tuesday, May 08, 2012 5:22 AM To: Lucy yong; Sam Cao; l2vpn@ietf.org Cc: Jiangyuanlong Subject: Re: L2vpn Digest, Vol 96, Issue 15 Comments inline (and s/conquer/concur/) On 5/7/12 2:58 PM, "Lucy yong" wrote: >Sam, > >I concur with Yuanlong's reply on this. Please see inline. > >Lucy > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >Sam Cao >Sent: Friday, May 04, 2012 9:09 PM >To: l2vpn@ietf.org >Cc: Jiangyuanlong >Subject: RE: L2vpn Digest, Vol 96, Issue 15 > >Lucy/Yuanlong, > >I agree that we can not say which approach is better simply, but I really >agree with Josh's comments. Multi-PW is easy to implement E-Tree. >[[LY]] I don't get impression Josh state this. > >First of all, we discussed 2 approaches for a long time and many rounds, >and >for me, there are no pending issues on Multi-PW till now or co-authors of >multi-PW have given reasonable reply to L2VPN members' questions, but >there >are still pending issues for Dual-VLAN. Please trace the mailing list. >[[LY]] I interpret this as people want to spend time to finalize dual >VLAN solution. Multi-PW has some operation impact. How do operator to >maintain this service and be able to trouble shooting. How do you expect >traceroute work when using two PWs for one VPN? How do you expect PE >report when there is an error on one of two PWs? Do you have one FEC or >two FEC for a E-Tree in control plane? [JR] I don't see this any more of a problem than troubleshooting one. If LDP is used, a simple mols traceroute shows the path that ALL PW's to that PE take, regardless of which service (this VPLS or another VPLS instance). If RSVP is used, there should be a route-object that shows me the path, and allows me to troubleshoot. Additionally, if I wanted to have traffic engineering that impacted root-sourced and leaf-sourced traffic differently, I can do that with multi-PW, where I could not (save for ingress/egress) with the 2VLAN approach. PE should report signaling on second PW same as it does for the 100th PW between PE's. Again, I don't see the problem you are alluding to. > >Second, Sasha has his concern in NP, or forwarding performance. Compared >to >current VPLS, Multi-PW has a little effect on forwarding performance since >it reuse PW label as AC indicator; Dual-VLAN will have higher side effect >on >forwarding performance because it SHOULD use additional indicator. Is >there >one prototype for Dual-VLAN? BTW, there is no reply on chip limit. >[[LY]] in VPLS, PW label is used as VSI indicator, not AC. I disagree >your statement here. > >Third, the difference between Multi-PW and dual-VLAN is, transport ingress >traffic in one "LSP" or 2 "LSP". Multi-PW classifies and transforms >ingress >traffic into right "path", and egress just pop-out PW label and forward >the >frame to ACs. Dual-VLAN has more work on ingress PE or egress PE. >[[LY]] Don't understand the first part. When egress pop-out PW label, it >find corresponding VSI first, then perform MAC lookup associated to all >ACs. We can't assume there is one AC. > >Fourth, maybe Giles has figured this out, Dual-VLAN has capacity limit. >Only >4094 VLAN ID are available, so only 2K E-Tree instances can be supported >on >one PE for Dual-VLAN approach. There is no such limit for Multi-PW >approach, >[[LY]] If 4K VLAN ID is not an issue for VPLS, it is not an issue for >E-Tree. > >Finally, in this thread we don't make agreement on VLAN ID allocation. We >also have questions on VLAN ID negotiation among PEs (signaling protocol). >Yuanlong wishes to update, but there is no update till now. >[[LY]] This should not be the reason to judge on the solution. [JR] I tend to agree. > >For me, why IEEE uses VLAN ID to identify AC type? IEEE has no LABEL :), >and >it has label, it also wish to use label to identify AC types. I think that >both solutions need much time to be perfect. Mutli-PW has less extension >work to do. But now we are focusing on technical details and can not move >forward :). >[[LY]] VPN label is used for identify the VPN. It already has the >purpose. Overloading with other meaning has high potential causing a >problem. Hope you can investigate it more. Since you are very in favor of >multi-pw solution, it is not proper for you to come out the conclusion >which is better, because it is very biased. You are welcome to help on >completing either solution. [JR] this is humorous to me, because at one time, VLAN-ID was used to identify a single broadcast domain, and then later asymmetrical VID's were used to limit communication between endpoints of a broadcast domain (effectively creating two one-way broadcast domains, very similar to what we're accomplishing with ETREE). This should not be the reason to judge on the solution. > >Regards, >Lucy > >Lucy > >Thanks, > >Sam > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >l2vpn-request@ietf.org >Sent: Friday, May 04, 2012 10:31 PM >To: l2vpn@ietf.org >Subject: L2vpn Digest, Vol 96, Issue 15 > >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) > 2. Re: The status of the approaches to the E-Tree solution? > (Rogers, Josh) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Fri, 4 May 2012 14:16:36 +0000 >From: Lucy yong >To: "Rogers, Josh" , Jiangyuanlong > , Daniel Cohn , >"Fedyk, > Donald (Don)" , "Henderickx, Wim > (Wim)" >Cc: "l2vpn@ietf.org" >Subject: RE: The status of the approaches to the E-Tree solution? >Message-ID: <2691CE0099834E4A9C5044EEC662BB9D330E9114@dfweml505-mbx> >Content-Type: text/plain; charset=3D"iso-8859-2" > >Josh, > >You simply say that you don't like IEEE Tree solution. IEEE Tree solution >is >for ingress port to mark and for egress port to filter. > >Regards, >Lucy > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Friday, May 04, 2012 7:27 AM >To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >(Wim); >Lucy yong >Cc: l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >also separate the leaf traffic in the ingress PE and filter it there >(already detailed in the Optimization Mode in the I-D); if the egress PE >is attached with pure roots or with both roots and leafs, it seems all >traffic must be transported to the egress PE and be filtered there, I see >no difference in behaviour for these solutions. Or did I miss something? > > >The point is with the multi-PW method the traffic is split/separated (by >psuedowire) on the ingress PE, rather than the egress. The distinction is >2VLAN will 'classify' the frame on the ingress PE, so that the egress PE >knows how to forward it to the appropriate AC's. > >Both methods have inefficiencies (one duplicates traffic for transport, >while the other transports where it doesn't need to go). I like the idea >of classify and forwarding on the ingress PE, rather than marking it on >the ingress, and deciding on the egress. > >-Josh > > > >On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: > >>Josh, thank you for the comments, please see my further comments with >>[JY2]. >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Thursday, May 03, 2012 11:27 PM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>requirements from MEF, it has nothing to do with the solutions. Could you >>give a hint on how you can provision this service E-NNI otherwise? BTW, >>if >>configuring or signalling two PWs is not a problem, why configuring or >>signalling two VLANs will become a problem? After all, more nodes may >>need >>to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >>2VLAN (only T-PEs). >> >> >>There is no other way (if both MPLS domains are part of the same ETREE, >>rather than doing something more like H-VPLS, where one domain has point >>to points to the other domain which handles the ETREE instance) if you >>are >>using an ENNI. The other method, (not mentioned earlier) is tying the >>two >>MPLS domains together via labeled unicast (much preferred over E-NNI in >>my >>opinion) >> >>Configuring two VLAN's isn't really a 'problem' any more than two PW's. >>I >>wasn't saying that configuring two VLAN's was difficult, I was objecting >>to the statement that configuring two PW's is difficult. >> >>[JY2] Thanks, I see your point. I take the example of 2PW configuration >>just to show that using fixed global values to simplify configuration >>makes no sense. Personally I also don't think configuration is a problem >>for both solutions. >> >>I find the differences between these two methods rather slight. The >>'tie-breaker' for me is by placing the forwarding decision on the ingress >>PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >>more control over where the traffic goes, and in my mind it provides a >>cleaner destination between customer traffic and forwarding plane. I'm >>accustomed to looking at a psuedowire and knowing where its going, with >>the 2vlan method, I can see the psuedowire, but must go to the egress PE >>to see if it will be dropped there, or forwarded to one or more AC's. >> >>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>also separate the leaf traffic in the ingress PE and filter it there >>(already detailed in the Optimization Mode in the I-D); if the egress PE >>is attached with pure roots or with both roots and leafs, it seems all >>traffic must be transported to the egress PE and be filtered there, I see >>no difference in behaviour for these solutions. Or did I miss something? >> >>Again, the difference here is slight, and I would honestly be happy to >>see >>either of them come to fruition. Please don't infer that I think the >>2vlan method is 'bad' or has intrinsic problems, because I don't believe >>that. I just prefer the multi-PW method. >> >> >>-Josh >> >> >>On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: >> >>>Josh, please see my comments in line. >>> >>>Thanks >>>Yuanlong >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Thursday, May 03, 2012 10:51 AM >>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>(Wim); Lucy yong >>>Cc: l2vpn@ietf.org >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Yuanlong, >>> >>>Or better yet, include in the draft a 'standard' value for root sourced >>>VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You would also >>>have to require the the implementation NOT use global VLAN's, however >>>(since each instance would be using the same values). In this way, no >>>signaling or manual configuration is required for remote PE's to know >>>how >>>to classify traffic. >>>[JY] Indeed, we discussed this possibility during the f2f meeting in >>>Paris. But, there are some restrictions as you mentioned, and >>>furthermore: >>>1) Some vendors already used S-VLAN to distinguish their VSIs in the PE; >>>2) Forwarding plane of a PE needs to be revised to be aware of this VLAN >>>ID. >>>Therefore, this 'standard value' approach seems more disruptive compared >>>with the other means and not a good candidate option. >>> >>>Regarding switching PE's? Multi-PW means more than one PW, yes. I >>>don't >>>see this as a real problem. In general, design should try and avoid >>>using >>>S-PE's, but if you must, its going to mean extra work, no matter how you >>>look at it. Two PW's for each Etree being switched instead of one is >>>not >>>alarming or concerning to me. On the other hand, if you use a dot1q >>>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's >>>an >>>two egress VLAN's if you want the Etree to be handled on both sides (and >>>if you use the 'standard' VID's as I mentioned above, you'd have to do >>>mapping to non-standard and back) >>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>requirements from MEF, it has nothing to do with the solutions. Could >>>you >>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>if configuring or signalling two PWs is not a problem, why configuring >>>or >>>signalling two VLANs will become a problem? After all, more nodes may >>>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>>with 2VLAN (only T-PEs). >>> >>>In general, I still prefer multi-PW, primarily because I prefer the >>>separation of the traffic in the network's forwarding plane, rather than >>>shipping it everywhere and deciding whether to forward to the AC when it >>>gets to the egress PE. I'm having a hard time putting my finger exactly >>>on what it is, or articulating the idea, but it seems that by having the >>>traffic placed into two psuedowires, I have more flexibility and ease of >>>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>>PW's could really change that perception. >>>[JY] Are you saying that we need to develop a totally new forwarding >>>plane rather than using the Ethernet forwarding plane as described in >>>the >>>existing work? >>> >>>I hope we can move forward with one of these soon, >>>[JY] me too. >>> >>>Josh >>> >>> >>>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >>> >>>>Daniel, >>>> >>>>Not aware that we had a discussion on this before, but IMHO the >>>>allocation of internal S-VLAN can be automatic, and manuel >>>>configuration >>>>of this mapping may not be needed at all. For example, an S-VLAN >>>>allocation module in the management plane in a PE can do this kind of >>>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>>way from a free S-VLAN ID pool. Once the interal S-VLANs are allocated, >>>>the mapping is determined and no other configuration is needed. >>>> >>>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>>allocate >>>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to allocate >>>>two S-VLANs in the VPLS domain. >>>> >>>>On the other hand, for the multi-PW approach, two PWs need to be >>>>configured for a E-Tree service. When MS-PW is used in the network, for >>>>every S-PE, we need to configure two ingress PW segments and two egress >>>>PW segments. In this case, I don't think we need to use fixed PW labels >>>>across the network for fear of configuration complexity. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 8:01 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Inline. >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 12:30 PM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, Please see my comments in line. >>>> >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 3:55 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Yuanlong, >>>> >>>>The problem is not with the total number of S-VLAN IDs, I agree that >>>>normally there won't be more than 2047. The problem is that if you >>>>don't >>>>support all VLAN IDs, you need S-VLAN space coordination with the >>>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to >>>>2047". >>>>Which won't always be in line with an existing deployment. >>>>[JY] This is not the case. If the total number is no more than 2047, it >>>>surely can be supported. The S-VLAN space of user domain is totally >>>>different from the S-VLAN in the provider domain and they can be >>>>overlapped, I don't see why we need S-VLAN space coordination between >>>>them. >>>> >>>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>>fixed, and therefore the IEEE S-VID that can be supported is also >>>>fixed. >>>> >>>>Of course you can configure the mapping in each PE according to >>>>operator >>>>requirements but as we discussed before this increases complexity. >>>> >>>>Relying on PBB-VPLS imposes additional limitations on backward >>>>compatibility. >>>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>>think they may well need MAC-in-MAC in their networks for the >>>>scalability issue. As you know, only PBB VPLS can provide both. >>>> >>>>Daniel >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 5:07 AM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, >>>> >>>>As you can see, both cases are discussed in the I-D. >>>> >>>>With regard to case 1) (that is, S-VLAN translation), since the access >>>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>>they need to be configured on a PE anyway, and as the past emails by >>>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>>mapping. >>>> >>>>With regard to S-VID space reduction, the constraint is valid only when >>>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>>typical and with no such limits as we already discussed in the f2f >>>>meeting. >>>> >>>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>>described (not sure this is a valid use case in real life), PBB-VPLS >>>>can >>>>still be used. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Monday, April 30, 2012 10:34 PM >>>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>Jiangyuanlong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>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] >>>>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 >>>> >>>>-------------------------------------------------------------------- -- >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to >>>copyright belonging to Time Warner Cable. This E-mail is intended solely >>>for the use of the individual or entity to which it is addressed. If you >>>are not the intended recipient of this E-mail, you are hereby notified >>>that any dissemination, distribution, copying, or action taken in >>>relation to the contents of and attachments to this E-mail is strictly >>>prohibited and may be unlawful. If you have received this 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. > > >------------------------------ > >Message: 2 >Date: Fri, 4 May 2012 10:30:38 -0400 >From: "Rogers, Josh" >To: Lucy yong , Jiangyuanlong > , Daniel Cohn , >"Fedyk, > Donald (Don)" , "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"iso-8859-2" > >To be more accurate, I like it less than the multi-PW solution. I'd be >happy to use the 2VLAN solution in the real world, if it was ratified as >the standard. > > > >On 5/4/12 9:16 AM, "Lucy yong" wrote: > >>Josh, >> >>You simply say that you don't like IEEE Tree solution. IEEE Tree solution >>is for ingress port to mark and for egress port to filter. >> >>Regards, >>Lucy >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Friday, May 04, 2012 7:27 AM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>also separate the leaf traffic in the ingress PE and filter it there >>(already detailed in the Optimization Mode in the I-D); if the egress PE >>is attached with pure roots or with both roots and leafs, it seems all >>traffic must be transported to the egress PE and be filtered there, I see >>no difference in behaviour for these solutions. Or did I miss something? >> >> >>The point is with the multi-PW method the traffic is split/separated (by >>psuedowire) on the ingress PE, rather than the egress. The distinction >>is >>2VLAN will 'classify' the frame on the ingress PE, so that the egress PE >>knows how to forward it to the appropriate AC's. >> >>Both methods have inefficiencies (one duplicates traffic for transport, >>while the other transports where it doesn't need to go). I like the idea >>of classify and forwarding on the ingress PE, rather than marking it on >>the ingress, and deciding on the egress. >> >>-Josh >> >> >> >>On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: >> >>>Josh, thank you for the comments, please see my further comments with >>>[JY2]. >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Thursday, May 03, 2012 11:27 PM >>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>(Wim); Lucy yong >>>Cc: l2vpn@ietf.org >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>requirements from MEF, it has nothing to do with the solutions. Could >>>you >>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>if >>>configuring or signalling two PWs is not a problem, why configuring or >>>signalling two VLANs will become a problem? After all, more nodes may >>>need >>>to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >>>2VLAN (only T-PEs). >>> >>> >>>There is no other way (if both MPLS domains are part of the same ETREE, >>>rather than doing something more like H-VPLS, where one domain has point >>>to points to the other domain which handles the ETREE instance) if you >>>are >>>using an ENNI. The other method, (not mentioned earlier) is tying the >>>two >>>MPLS domains together via labeled unicast (much preferred over E-NNI in >>>my >>>opinion) >>> >>>Configuring two VLAN's isn't really a 'problem' any more than two PW's. >>>I >>>wasn't saying that configuring two VLAN's was difficult, I was objecting >>>to the statement that configuring two PW's is difficult. >>> >>>[JY2] Thanks, I see your point. I take the example of 2PW configuration >>>just to show that using fixed global values to simplify configuration >>>makes no sense. Personally I also don't think configuration is a problem >>>for both solutions. >>> >>>I find the differences between these two methods rather slight. The >>>'tie-breaker' for me is by placing the forwarding decision on the >>>ingress >>>PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >>>more control over where the traffic goes, and in my mind it provides a >>>cleaner destination between customer traffic and forwarding plane. I'm >>>accustomed to looking at a psuedowire and knowing where its going, with >>>the 2vlan method, I can see the psuedowire, but must go to the egress PE >>>to see if it will be dropped there, or forwarded to one or more AC's. >>> >>>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>>also separate the leaf traffic in the ingress PE and filter it there >>>(already detailed in the Optimization Mode in the I-D); if the egress PE >>>is attached with pure roots or with both roots and leafs, it seems all >>>traffic must be transported to the egress PE and be filtered there, I >>>see >>>no difference in behaviour for these solutions. Or did I miss something? >>> >>>Again, the difference here is slight, and I would honestly be happy to >>>see >>>either of them come to fruition. Please don't infer that I think the >>>2vlan method is 'bad' or has intrinsic problems, because I don't believe >>>that. I just prefer the multi-PW method. >>> >>> >>>-Josh >>> >>> >>>On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: >>> >>>>Josh, please see my comments in line. >>>> >>>>Thanks >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>>Sent: Thursday, May 03, 2012 10:51 AM >>>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>>(Wim); Lucy yong >>>>Cc: l2vpn@ietf.org >>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>> >>>>Yuanlong, >>>> >>>>Or better yet, include in the draft a 'standard' value for root sourced >>>>VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You would also >>>>have to require the the implementation NOT use global VLAN's, however >>>>(since each instance would be using the same values). In this way, no >>>>signaling or manual configuration is required for remote PE's to know >>>>how >>>>to classify traffic. >>>>[JY] Indeed, we discussed this possibility during the f2f meeting in >>>>Paris. But, there are some restrictions as you mentioned, and >>>>furthermore: >>>>1) Some vendors already used S-VLAN to distinguish their VSIs in the >>>>PE; >>>>2) Forwarding plane of a PE needs to be revised to be aware of this >>>>VLAN >>>>ID. >>>>Therefore, this 'standard value' approach seems more disruptive >>>>compared >>>>with the other means and not a good candidate option. >>>> >>>>Regarding switching PE's? Multi-PW means more than one PW, yes. I >>>>don't >>>>see this as a real problem. In general, design should try and avoid >>>>using >>>>S-PE's, but if you must, its going to mean extra work, no matter how >>>>you >>>>look at it. Two PW's for each Etree being switched instead of one is >>>>not >>>>alarming or concerning to me. On the other hand, if you use a dot1q >>>>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's >>>>an >>>>two egress VLAN's if you want the Etree to be handled on both sides >>>>(and >>>>if you use the 'standard' VID's as I mentioned above, you'd have to do >>>>mapping to non-standard and back) >>>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>>requirements from MEF, it has nothing to do with the solutions. Could >>>>you >>>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>>if configuring or signalling two PWs is not a problem, why configuring >>>>or >>>>signalling two VLANs will become a problem? After all, more nodes may >>>>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>>>with 2VLAN (only T-PEs). >>>> >>>>In general, I still prefer multi-PW, primarily because I prefer the >>>>separation of the traffic in the network's forwarding plane, rather >>>>than >>>>shipping it everywhere and deciding whether to forward to the AC when >>>>it >>>>gets to the egress PE. I'm having a hard time putting my finger >>>>exactly >>>>on what it is, or articulating the idea, but it seems that by having >>>>the >>>>traffic placed into two psuedowires, I have more flexibility and ease >>>>of >>>>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>>>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>>>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>>>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>>>PW's could really change that perception. >>>>[JY] Are you saying that we need to develop a totally new forwarding >>>>plane rather than using the Ethernet forwarding plane as described in >>>>the >>>>existing work? >>>> >>>>I hope we can move forward with one of these soon, >>>>[JY] me too. >>>> >>>>Josh >>>> >>>> >>>>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >>>> >>>>>Daniel, >>>>> >>>>>Not aware that we had a discussion on this before, but IMHO the >>>>>allocation of internal S-VLAN can be automatic, and manuel >>>>>configuration >>>>>of this mapping may not be needed at all. For example, an S-VLAN >>>>>allocation module in the management plane in a PE can do this kind of >>>>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>>>way from a free S-VLAN ID pool. Once the interal S-VLANs are >>>>>allocated, >>>>>the mapping is determined and no other configuration is needed. >>>>> >>>>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>>>allocate >>>>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to >>>>>allocate >>>>>two S-VLANs in the VPLS domain. >>>>> >>>>>On the other hand, for the multi-PW approach, two PWs need to be >>>>>configured for a E-Tree service. When MS-PW is used in the network, >>>>>for >>>>>every S-PE, we need to configure two ingress PW segments and two >>>>>egress >>>>>PW segments. In this case, I don't think we need to use fixed PW >>>>>labels >>>>>across the network for fear of configuration complexity. >>>>> >>>>>Regards, >>>>>Yuanlong >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>Sent: Wednesday, May 02, 2012 8:01 PM >>>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; >>>>>josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Inline. >>>>> >>>>>-----Original Message----- >>>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>>Sent: Wednesday, May 02, 2012 12:30 PM >>>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; >>>>>josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Hi Daniel, Please see my comments in line. >>>>> >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>Sent: Wednesday, May 02, 2012 3:55 PM >>>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Hi Yuanlong, >>>>> >>>>>The problem is not with the total number of S-VLAN IDs, I agree that >>>>>normally there won't be more than 2047. The problem is that if you >>>>>don't >>>>>support all VLAN IDs, you need S-VLAN space coordination with the >>>>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to >>>>>2047". >>>>>Which won't always be in line with an existing deployment. >>>>>[JY] This is not the case. If the total number is no more than 2047, >>>>>it >>>>>surely can be supported. The S-VLAN space of user domain is totally >>>>>different from the S-VLAN in the provider domain and they can be >>>>>overlapped, I don't see why we need S-VLAN space coordination between >>>>>them. >>>>> >>>>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>>>fixed, and therefore the IEEE S-VID that can be supported is also >>>>>fixed. >>>>> >>>>>Of course you can configure the mapping in each PE according to >>>>>operator >>>>>requirements but as we discussed before this increases complexity. >>>>> >>>>>Relying on PBB-VPLS imposes additional limitations on backward >>>>>compatibility. >>>>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>>>think they may well need MAC-in-MAC in their networks for the >>>>>scalability issue. As you know, only PBB VPLS can provide both. >>>>> >>>>>Daniel >>>>> >>>>>-----Original Message----- >>>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>>Sent: Wednesday, May 02, 2012 5:07 AM >>>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; >>>>>josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Hi Daniel, >>>>> >>>>>As you can see, both cases are discussed in the I-D. >>>>> >>>>>With regard to case 1) (that is, S-VLAN translation), since the access >>>>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>>>they need to be configured on a PE anyway, and as the past emails by >>>>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>>>mapping. >>>>> >>>>>With regard to S-VID space reduction, the constraint is valid only >>>>>when >>>>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>>>typical and with no such limits as we already discussed in the f2f >>>>>meeting. >>>>> >>>>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>>>described (not sure this is a valid use case in real life), PBB-VPLS >>>>>can >>>>>still be used. >>>>> >>>>>Regards, >>>>>Yuanlong >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>Sent: Monday, April 30, 2012 10:34 PM >>>>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>>Jiangyuanlong; josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>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] >>>>>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 >>>>> >>>>>------------------------------------------------------------------- --- >>>> >>>> >>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>proprietary information, which is privileged, confidential, or subject >>>>to >>>>copyright belonging to Time Warner Cable. This E-mail is intended >>>>solely >>>>for the use of the individual or entity to which it is addressed. If >>>>you >>>>are not the intended recipient of this E-mail, you are hereby notified >>>>that any dissemination, distribution, copying, or action taken in >>>>relation to the contents of and attachments to this E-mail is strictly >>>>prohibited and may be unlawful. If you have received this 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 and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for >the use of the individual or entity to which it is addressed. If you are >not >the intended recipient of this E-mail, you are hereby notified that any >dissemination, distribution, copying, or action taken in relation to the >contents of and attachments to this E-mail is strictly prohibited and may >be >unlawful. If you have received this 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 96, Issue 15 >************************************* > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this 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 May 8 06:40: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 EE1AE21F847F for ; Tue, 8 May 2012 06:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.125 X-Spam-Level: X-Spam-Status: No, score=-2.125 tagged_above=-999 required=5 tests=[AWL=-0.126, 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 lAK6FN0fkRiJ for ; Tue, 8 May 2012 06:40:13 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC2021F84C3 for ; Tue, 8 May 2012 06:40:13 -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 AFP85790; Tue, 08 May 2012 09:40:12 -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; Tue, 8 May 2012 06:37:48 -0700 Received: from SZXEML437-HUB.china.huawei.com (10.72.61.72) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 8 May 2012 06:37:47 -0700 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.183]) by szxeml437-hub.china.huawei.com ([10.72.61.72]) with mapi id 14.01.0323.003; Tue, 8 May 2012 21:37:35 +0800 From: Jiangyuanlong To: Daniel Cohn , "Rogers, Josh" , Lucy yong , Sam Cao , "l2vpn@ietf.org" Subject: RE: L2vpn Digest, Vol 96, Issue 15 Thread-Topic: L2vpn Digest, Vol 96, Issue 15 Thread-Index: AQHNKgNyPxr7nh+DX0S+AUfrSOoOpZa57ewAgARPYACAABdtgIAA8VnQgABOaUCAAAEZoIAABFOggABM/3CAAAFowIAAAXRw Date: Tue, 8 May 2012 13:37:35 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410C62@szxeml546-mbx.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D330F0740@dfweml506-mbx> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410ABC@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CA64@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410B5D@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CA6E@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410BFF@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CB27@tlvmail1> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA08130780CB27@tlvmail1> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.40.73] 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: Tue, 08 May 2012 13:40:18 -0000 Except PW numbers, now PW attributes also needs to be considered: root, lea= f or normal. Can the root or leaf PW be connected to the normal PW? Or just connect root= to root, and leaf to leaf? Without signalling, this will pose a great challenge to configure the OAM c= orrectly. -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Tuesday, May 08, 2012 9:29 PM To: Jiangyuanlong; Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 Yuanlong, I don't see the additional complexity. Existing PW maintenance processes at the operator can take care of the additional root/leaf PWs exactly like they do today. Only they will have some more PWs to maintain (not twice as much, since most PEs are typically leaf-only and therefore have only a root PW per E-Tree instance) And service maintenance processes should be extended to maintain root and leaf services using E-OAM, both for the 2-VLAN and multi-PW solutions. DC -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Tuesday, May 08, 2012 4:23 PM To: Daniel Cohn; Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 Daniel, RFC 6136 provides the VPLS OAM reqs and framework, and Sec. 10.1. gives the typical VPLS OAM Operational Scenarios: --- --- / \ ------ ------- ---- / \ | A CE-- / \ / \ / \ --CE A | \ / \ / \ / \ / \ / \ / --- --UPE NPE NPE UPE-- --- \ / \ / \ / \ / \ / \ / ------ ------- ---- Customer OAM Domain (C) MEP---MIP--------------------------------MIP---MEP Service Provider (SP) OAM Domain (D) MEP--------MIP-----------MIP-------MEP SP OAM SP OAM SP OAM (D1) MEP-MIP--MEP|MEP-------MEP|MEP-----MEP domain domain domain Operator Operator Operator (E) MEP-MIP--MEP|MEP-------MEP|MEP-----MEP OAM domain OAM domain OAM domain MPLS OAM MPLS OAM (F) MEP--MIP-----MEP--MIP--MEP domain domain Figure 10: VPLS OAM Domains, MEPs, and MIPs It seems OAM configurations in Scenario D1) and E) for 2PW approach will be much complicated and error prone, since E-Tree OAM now needs to interwork with one of these two PWs' OAM (maybe both, I am afraid). For scenario F), the concatanation of two MPLS OAM also needs to be very careful as 4 PWs and 3 types (i.e, root/leaf/normal) may be involved there. Regards, Yuanlong -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Tuesday, May 08, 2012 4:49 PM To: Jiangyuanlong; Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 Inline -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Tuesday, May 08, 2012 11:42 AM To: Daniel Cohn; Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 I don't think so. There may be different layers of OAM applicable to a service. Such as LSP layer, PW layer, and service layer. [DC] Agreed Now you cannot use a single LSP OAM to monitor the server layer of the E-Tree service (as 2 LSP may be involved). And the service layer of OAM for E-Tree may be distributed to different LSP paths. [DC] For E-Tree service OAM, you would perform OAM actions from MEPs associated to root or leaf ACs, so the E-OAM frames would naturally follow the root or leaf pseudowires and the LSPs that transport them. I don't see a limitation here. -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Tuesday, May 08, 2012 4:28 PM To: Jiangyuanlong; Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 Yuanlong, isn't this orthogonal to the issues we are discussing? I mean, there are different mechanisms to troubleshoot PWs, all of which are applicable to root/leaf PWs as to any other PWs. Or is there any specific limitation on root/leaf PW troubleshooting, compared to "regular" PWs used in VPLSs? Thanks, Daniel -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Jiangyuanlong Sent: Tuesday, May 08, 2012 7:04 AM To: Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 Josh,=20 Just some comments on this part: [JR] I don't see this any more of a problem than troubleshooting one. If LDP is used, a simple mols traceroute shows the path that ALL PW's to that PE take, regardless of which service (this VPLS or another VPLS instance). If RSVP is used, there should be a route-object that shows me the path, and allows me to troubleshoot. Additionally, if I wanted to have traffic engineering that impacted root-sourced and leaf-sourced traffic differently, I can do that with multi-PW, where I could not (save for ingress/egress) with the 2VLAN approach. PE should report signaling on second PW same as it does for the 100th PW between PE's. Again, I don't see the problem you are alluding to. I suppose you are referring to LSP Ping on the LSP layer, yes, it can oversee all the PWs in this LSP. If both root and leaf PW are in the same LSP, it can work. But there may well be multiple LSPs between a pair of PEs, and root/leaf PW may be transported on different LSPs. Another difficulty is, if ECMP is deployed and PW label as a bottom label is used for hashing, the OAM message may be load balanced on different paths. With regard to TE, you could use DS-TE, just as Lucy said, two PW do not guarantee they are traffic engineered. Thanks Yuanlong -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com]=20 Sent: Tuesday, May 08, 2012 5:22 AM To: Lucy yong; Sam Cao; l2vpn@ietf.org Cc: Jiangyuanlong Subject: Re: L2vpn Digest, Vol 96, Issue 15 Comments inline (and s/conquer/concur/) On 5/7/12 2:58 PM, "Lucy yong" wrote: >Sam, > >I concur with Yuanlong's reply on this. Please see inline. > >Lucy > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >Sam Cao >Sent: Friday, May 04, 2012 9:09 PM >To: l2vpn@ietf.org >Cc: Jiangyuanlong >Subject: RE: L2vpn Digest, Vol 96, Issue 15 > >Lucy/Yuanlong, > >I agree that we can not say which approach is better simply, but I really >agree with Josh's comments. Multi-PW is easy to implement E-Tree. >[[LY]] I don't get impression Josh state this. > >First of all, we discussed 2 approaches for a long time and many rounds, >and >for me, there are no pending issues on Multi-PW till now or co-authors of >multi-PW have given reasonable reply to L2VPN members' questions, but >there >are still pending issues for Dual-VLAN. Please trace the mailing list. >[[LY]] I interpret this as people want to spend time to finalize dual >VLAN solution. Multi-PW has some operation impact. How do operator to >maintain this service and be able to trouble shooting. How do you expect >traceroute work when using two PWs for one VPN? How do you expect PE >report when there is an error on one of two PWs? Do you have one FEC or >two FEC for a E-Tree in control plane? [JR] I don't see this any more of a problem than troubleshooting one. If LDP is used, a simple mols traceroute shows the path that ALL PW's to that PE take, regardless of which service (this VPLS or another VPLS instance). If RSVP is used, there should be a route-object that shows me the path, and allows me to troubleshoot. Additionally, if I wanted to have traffic engineering that impacted root-sourced and leaf-sourced traffic differently, I can do that with multi-PW, where I could not (save for ingress/egress) with the 2VLAN approach. PE should report signaling on second PW same as it does for the 100th PW between PE's. Again, I don't see the problem you are alluding to. > >Second, Sasha has his concern in NP, or forwarding performance. Compared >to >current VPLS, Multi-PW has a little effect on forwarding performance since >it reuse PW label as AC indicator; Dual-VLAN will have higher side effect >on >forwarding performance because it SHOULD use additional indicator. Is >there >one prototype for Dual-VLAN? BTW, there is no reply on chip limit. >[[LY]] in VPLS, PW label is used as VSI indicator, not AC. I disagree >your statement here. > >Third, the difference between Multi-PW and dual-VLAN is, transport ingress >traffic in one "LSP" or 2 "LSP". Multi-PW classifies and transforms >ingress >traffic into right "path", and egress just pop-out PW label and forward >the >frame to ACs. Dual-VLAN has more work on ingress PE or egress PE. >[[LY]] Don't understand the first part. When egress pop-out PW label, it >find corresponding VSI first, then perform MAC lookup associated to all >ACs. We can't assume there is one AC. > >Fourth, maybe Giles has figured this out, Dual-VLAN has capacity limit. >Only >4094 VLAN ID are available, so only 2K E-Tree instances can be supported >on >one PE for Dual-VLAN approach. There is no such limit for Multi-PW >approach, >[[LY]] If 4K VLAN ID is not an issue for VPLS, it is not an issue for >E-Tree. > >Finally, in this thread we don't make agreement on VLAN ID allocation. We >also have questions on VLAN ID negotiation among PEs (signaling protocol). >Yuanlong wishes to update, but there is no update till now. >[[LY]] This should not be the reason to judge on the solution. [JR] I tend to agree. > >For me, why IEEE uses VLAN ID to identify AC type? IEEE has no LABEL :), >and >it has label, it also wish to use label to identify AC types. I think that >both solutions need much time to be perfect. Mutli-PW has less extension >work to do. But now we are focusing on technical details and can not move >forward :). >[[LY]] VPN label is used for identify the VPN. It already has the >purpose. Overloading with other meaning has high potential causing a >problem. Hope you can investigate it more. Since you are very in favor of >multi-pw solution, it is not proper for you to come out the conclusion >which is better, because it is very biased. You are welcome to help on >completing either solution. [JR] this is humorous to me, because at one time, VLAN-ID was used to identify a single broadcast domain, and then later asymmetrical VID's were used to limit communication between endpoints of a broadcast domain (effectively creating two one-way broadcast domains, very similar to what we're accomplishing with ETREE). This should not be the reason to judge on the solution. > >Regards, >Lucy > >Lucy > >Thanks, > >Sam > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >l2vpn-request@ietf.org >Sent: Friday, May 04, 2012 10:31 PM >To: l2vpn@ietf.org >Subject: L2vpn Digest, Vol 96, Issue 15 > >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) > 2. Re: The status of the approaches to the E-Tree solution? > (Rogers, Josh) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Fri, 4 May 2012 14:16:36 +0000 >From: Lucy yong >To: "Rogers, Josh" , Jiangyuanlong > , Daniel Cohn , >"Fedyk, > Donald (Don)" , "Henderickx, Wim > (Wim)" >Cc: "l2vpn@ietf.org" >Subject: RE: The status of the approaches to the E-Tree solution? >Message-ID: <2691CE0099834E4A9C5044EEC662BB9D330E9114@dfweml505-mbx> >Content-Type: text/plain; charset=3D"iso-8859-2" > >Josh, > >You simply say that you don't like IEEE Tree solution. IEEE Tree solution >is >for ingress port to mark and for egress port to filter. > >Regards, >Lucy > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Friday, May 04, 2012 7:27 AM >To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >(Wim); >Lucy yong >Cc: l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >also separate the leaf traffic in the ingress PE and filter it there >(already detailed in the Optimization Mode in the I-D); if the egress PE >is attached with pure roots or with both roots and leafs, it seems all >traffic must be transported to the egress PE and be filtered there, I see >no difference in behaviour for these solutions. Or did I miss something? > > >The point is with the multi-PW method the traffic is split/separated (by >psuedowire) on the ingress PE, rather than the egress. The distinction is >2VLAN will 'classify' the frame on the ingress PE, so that the egress PE >knows how to forward it to the appropriate AC's. > >Both methods have inefficiencies (one duplicates traffic for transport, >while the other transports where it doesn't need to go). I like the idea >of classify and forwarding on the ingress PE, rather than marking it on >the ingress, and deciding on the egress. > >-Josh > > > >On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: > >>Josh, thank you for the comments, please see my further comments with >>[JY2]. >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Thursday, May 03, 2012 11:27 PM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>requirements from MEF, it has nothing to do with the solutions. Could you >>give a hint on how you can provision this service E-NNI otherwise? BTW, >>if >>configuring or signalling two PWs is not a problem, why configuring or >>signalling two VLANs will become a problem? After all, more nodes may >>need >>to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >>2VLAN (only T-PEs). >> >> >>There is no other way (if both MPLS domains are part of the same ETREE, >>rather than doing something more like H-VPLS, where one domain has point >>to points to the other domain which handles the ETREE instance) if you >>are >>using an ENNI. The other method, (not mentioned earlier) is tying the >>two >>MPLS domains together via labeled unicast (much preferred over E-NNI in >>my >>opinion) >> >>Configuring two VLAN's isn't really a 'problem' any more than two PW's. >>I >>wasn't saying that configuring two VLAN's was difficult, I was objecting >>to the statement that configuring two PW's is difficult. >> >>[JY2] Thanks, I see your point. I take the example of 2PW configuration >>just to show that using fixed global values to simplify configuration >>makes no sense. Personally I also don't think configuration is a problem >>for both solutions. >> >>I find the differences between these two methods rather slight. The >>'tie-breaker' for me is by placing the forwarding decision on the ingress >>PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >>more control over where the traffic goes, and in my mind it provides a >>cleaner destination between customer traffic and forwarding plane. I'm >>accustomed to looking at a psuedowire and knowing where its going, with >>the 2vlan method, I can see the psuedowire, but must go to the egress PE >>to see if it will be dropped there, or forwarded to one or more AC's. >> >>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>also separate the leaf traffic in the ingress PE and filter it there >>(already detailed in the Optimization Mode in the I-D); if the egress PE >>is attached with pure roots or with both roots and leafs, it seems all >>traffic must be transported to the egress PE and be filtered there, I see >>no difference in behaviour for these solutions. Or did I miss something? >> >>Again, the difference here is slight, and I would honestly be happy to >>see >>either of them come to fruition. Please don't infer that I think the >>2vlan method is 'bad' or has intrinsic problems, because I don't believe >>that. I just prefer the multi-PW method. >> >> >>-Josh >> >> >>On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: >> >>>Josh, please see my comments in line. >>> >>>Thanks >>>Yuanlong >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Thursday, May 03, 2012 10:51 AM >>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>(Wim); Lucy yong >>>Cc: l2vpn@ietf.org >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Yuanlong, >>> >>>Or better yet, include in the draft a 'standard' value for root sourced >>>VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You would also >>>have to require the the implementation NOT use global VLAN's, however >>>(since each instance would be using the same values). In this way, no >>>signaling or manual configuration is required for remote PE's to know >>>how >>>to classify traffic. >>>[JY] Indeed, we discussed this possibility during the f2f meeting in >>>Paris. But, there are some restrictions as you mentioned, and >>>furthermore: >>>1) Some vendors already used S-VLAN to distinguish their VSIs in the PE; >>>2) Forwarding plane of a PE needs to be revised to be aware of this VLAN >>>ID. >>>Therefore, this 'standard value' approach seems more disruptive compared >>>with the other means and not a good candidate option. >>> >>>Regarding switching PE's? Multi-PW means more than one PW, yes. I >>>don't >>>see this as a real problem. In general, design should try and avoid >>>using >>>S-PE's, but if you must, its going to mean extra work, no matter how you >>>look at it. Two PW's for each Etree being switched instead of one is >>>not >>>alarming or concerning to me. On the other hand, if you use a dot1q >>>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's >>>an >>>two egress VLAN's if you want the Etree to be handled on both sides (and >>>if you use the 'standard' VID's as I mentioned above, you'd have to do >>>mapping to non-standard and back) >>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>requirements from MEF, it has nothing to do with the solutions. Could >>>you >>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>if configuring or signalling two PWs is not a problem, why configuring >>>or >>>signalling two VLANs will become a problem? After all, more nodes may >>>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>>with 2VLAN (only T-PEs). >>> >>>In general, I still prefer multi-PW, primarily because I prefer the >>>separation of the traffic in the network's forwarding plane, rather than >>>shipping it everywhere and deciding whether to forward to the AC when it >>>gets to the egress PE. I'm having a hard time putting my finger exactly >>>on what it is, or articulating the idea, but it seems that by having the >>>traffic placed into two psuedowires, I have more flexibility and ease of >>>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>>PW's could really change that perception. >>>[JY] Are you saying that we need to develop a totally new forwarding >>>plane rather than using the Ethernet forwarding plane as described in >>>the >>>existing work? >>> >>>I hope we can move forward with one of these soon, >>>[JY] me too. >>> >>>Josh >>> >>> >>>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >>> >>>>Daniel, >>>> >>>>Not aware that we had a discussion on this before, but IMHO the >>>>allocation of internal S-VLAN can be automatic, and manuel >>>>configuration >>>>of this mapping may not be needed at all. For example, an S-VLAN >>>>allocation module in the management plane in a PE can do this kind of >>>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>>way from a free S-VLAN ID pool. Once the interal S-VLANs are allocated, >>>>the mapping is determined and no other configuration is needed. >>>> >>>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>>allocate >>>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to allocate >>>>two S-VLANs in the VPLS domain. >>>> >>>>On the other hand, for the multi-PW approach, two PWs need to be >>>>configured for a E-Tree service. When MS-PW is used in the network, for >>>>every S-PE, we need to configure two ingress PW segments and two egress >>>>PW segments. In this case, I don't think we need to use fixed PW labels >>>>across the network for fear of configuration complexity. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 8:01 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Inline. >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 12:30 PM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, Please see my comments in line. >>>> >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 3:55 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Yuanlong, >>>> >>>>The problem is not with the total number of S-VLAN IDs, I agree that >>>>normally there won't be more than 2047. The problem is that if you >>>>don't >>>>support all VLAN IDs, you need S-VLAN space coordination with the >>>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to >>>>2047". >>>>Which won't always be in line with an existing deployment. >>>>[JY] This is not the case. If the total number is no more than 2047, it >>>>surely can be supported. The S-VLAN space of user domain is totally >>>>different from the S-VLAN in the provider domain and they can be >>>>overlapped, I don't see why we need S-VLAN space coordination between >>>>them. >>>> >>>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>>fixed, and therefore the IEEE S-VID that can be supported is also >>>>fixed. >>>> >>>>Of course you can configure the mapping in each PE according to >>>>operator >>>>requirements but as we discussed before this increases complexity. >>>> >>>>Relying on PBB-VPLS imposes additional limitations on backward >>>>compatibility. >>>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>>think they may well need MAC-in-MAC in their networks for the >>>>scalability issue. As you know, only PBB VPLS can provide both. >>>> >>>>Daniel >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 5:07 AM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, >>>> >>>>As you can see, both cases are discussed in the I-D. >>>> >>>>With regard to case 1) (that is, S-VLAN translation), since the access >>>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>>they need to be configured on a PE anyway, and as the past emails by >>>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>>mapping. >>>> >>>>With regard to S-VID space reduction, the constraint is valid only when >>>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>>typical and with no such limits as we already discussed in the f2f >>>>meeting. >>>> >>>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>>described (not sure this is a valid use case in real life), PBB-VPLS >>>>can >>>>still be used. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Monday, April 30, 2012 10:34 PM >>>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>Jiangyuanlong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>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] >>>>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 >>>> >>>>-------------------------------------------------------------------- -- >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to >>>copyright belonging to Time Warner Cable. This E-mail is intended solely >>>for the use of the individual or entity to which it is addressed. If you >>>are not the intended recipient of this E-mail, you are hereby notified >>>that any dissemination, distribution, copying, or action taken in >>>relation to the contents of and attachments to this E-mail is strictly >>>prohibited and may be unlawful. If you have received this 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. > > >------------------------------ > >Message: 2 >Date: Fri, 4 May 2012 10:30:38 -0400 >From: "Rogers, Josh" >To: Lucy yong , Jiangyuanlong > , Daniel Cohn , >"Fedyk, > Donald (Don)" , "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"iso-8859-2" > >To be more accurate, I like it less than the multi-PW solution. I'd be >happy to use the 2VLAN solution in the real world, if it was ratified as >the standard. > > > >On 5/4/12 9:16 AM, "Lucy yong" wrote: > >>Josh, >> >>You simply say that you don't like IEEE Tree solution. IEEE Tree solution >>is for ingress port to mark and for egress port to filter. >> >>Regards, >>Lucy >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Friday, May 04, 2012 7:27 AM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>also separate the leaf traffic in the ingress PE and filter it there >>(already detailed in the Optimization Mode in the I-D); if the egress PE >>is attached with pure roots or with both roots and leafs, it seems all >>traffic must be transported to the egress PE and be filtered there, I see >>no difference in behaviour for these solutions. Or did I miss something? >> >> >>The point is with the multi-PW method the traffic is split/separated (by >>psuedowire) on the ingress PE, rather than the egress. The distinction >>is >>2VLAN will 'classify' the frame on the ingress PE, so that the egress PE >>knows how to forward it to the appropriate AC's. >> >>Both methods have inefficiencies (one duplicates traffic for transport, >>while the other transports where it doesn't need to go). I like the idea >>of classify and forwarding on the ingress PE, rather than marking it on >>the ingress, and deciding on the egress. >> >>-Josh >> >> >> >>On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: >> >>>Josh, thank you for the comments, please see my further comments with >>>[JY2]. >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Thursday, May 03, 2012 11:27 PM >>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>(Wim); Lucy yong >>>Cc: l2vpn@ietf.org >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>requirements from MEF, it has nothing to do with the solutions. Could >>>you >>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>if >>>configuring or signalling two PWs is not a problem, why configuring or >>>signalling two VLANs will become a problem? After all, more nodes may >>>need >>>to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >>>2VLAN (only T-PEs). >>> >>> >>>There is no other way (if both MPLS domains are part of the same ETREE, >>>rather than doing something more like H-VPLS, where one domain has point >>>to points to the other domain which handles the ETREE instance) if you >>>are >>>using an ENNI. The other method, (not mentioned earlier) is tying the >>>two >>>MPLS domains together via labeled unicast (much preferred over E-NNI in >>>my >>>opinion) >>> >>>Configuring two VLAN's isn't really a 'problem' any more than two PW's. >>>I >>>wasn't saying that configuring two VLAN's was difficult, I was objecting >>>to the statement that configuring two PW's is difficult. >>> >>>[JY2] Thanks, I see your point. I take the example of 2PW configuration >>>just to show that using fixed global values to simplify configuration >>>makes no sense. Personally I also don't think configuration is a problem >>>for both solutions. >>> >>>I find the differences between these two methods rather slight. The >>>'tie-breaker' for me is by placing the forwarding decision on the >>>ingress >>>PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >>>more control over where the traffic goes, and in my mind it provides a >>>cleaner destination between customer traffic and forwarding plane. I'm >>>accustomed to looking at a psuedowire and knowing where its going, with >>>the 2vlan method, I can see the psuedowire, but must go to the egress PE >>>to see if it will be dropped there, or forwarded to one or more AC's. >>> >>>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>>also separate the leaf traffic in the ingress PE and filter it there >>>(already detailed in the Optimization Mode in the I-D); if the egress PE >>>is attached with pure roots or with both roots and leafs, it seems all >>>traffic must be transported to the egress PE and be filtered there, I >>>see >>>no difference in behaviour for these solutions. Or did I miss something? >>> >>>Again, the difference here is slight, and I would honestly be happy to >>>see >>>either of them come to fruition. Please don't infer that I think the >>>2vlan method is 'bad' or has intrinsic problems, because I don't believe >>>that. I just prefer the multi-PW method. >>> >>> >>>-Josh >>> >>> >>>On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: >>> >>>>Josh, please see my comments in line. >>>> >>>>Thanks >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>>Sent: Thursday, May 03, 2012 10:51 AM >>>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>>(Wim); Lucy yong >>>>Cc: l2vpn@ietf.org >>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>> >>>>Yuanlong, >>>> >>>>Or better yet, include in the draft a 'standard' value for root sourced >>>>VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You would also >>>>have to require the the implementation NOT use global VLAN's, however >>>>(since each instance would be using the same values). In this way, no >>>>signaling or manual configuration is required for remote PE's to know >>>>how >>>>to classify traffic. >>>>[JY] Indeed, we discussed this possibility during the f2f meeting in >>>>Paris. But, there are some restrictions as you mentioned, and >>>>furthermore: >>>>1) Some vendors already used S-VLAN to distinguish their VSIs in the >>>>PE; >>>>2) Forwarding plane of a PE needs to be revised to be aware of this >>>>VLAN >>>>ID. >>>>Therefore, this 'standard value' approach seems more disruptive >>>>compared >>>>with the other means and not a good candidate option. >>>> >>>>Regarding switching PE's? Multi-PW means more than one PW, yes. I >>>>don't >>>>see this as a real problem. In general, design should try and avoid >>>>using >>>>S-PE's, but if you must, its going to mean extra work, no matter how >>>>you >>>>look at it. Two PW's for each Etree being switched instead of one is >>>>not >>>>alarming or concerning to me. On the other hand, if you use a dot1q >>>>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's >>>>an >>>>two egress VLAN's if you want the Etree to be handled on both sides >>>>(and >>>>if you use the 'standard' VID's as I mentioned above, you'd have to do >>>>mapping to non-standard and back) >>>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>>requirements from MEF, it has nothing to do with the solutions. Could >>>>you >>>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>>if configuring or signalling two PWs is not a problem, why configuring >>>>or >>>>signalling two VLANs will become a problem? After all, more nodes may >>>>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>>>with 2VLAN (only T-PEs). >>>> >>>>In general, I still prefer multi-PW, primarily because I prefer the >>>>separation of the traffic in the network's forwarding plane, rather >>>>than >>>>shipping it everywhere and deciding whether to forward to the AC when >>>>it >>>>gets to the egress PE. I'm having a hard time putting my finger >>>>exactly >>>>on what it is, or articulating the idea, but it seems that by having >>>>the >>>>traffic placed into two psuedowires, I have more flexibility and ease >>>>of >>>>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>>>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>>>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>>>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>>>PW's could really change that perception. >>>>[JY] Are you saying that we need to develop a totally new forwarding >>>>plane rather than using the Ethernet forwarding plane as described in >>>>the >>>>existing work? >>>> >>>>I hope we can move forward with one of these soon, >>>>[JY] me too. >>>> >>>>Josh >>>> >>>> >>>>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >>>> >>>>>Daniel, >>>>> >>>>>Not aware that we had a discussion on this before, but IMHO the >>>>>allocation of internal S-VLAN can be automatic, and manuel >>>>>configuration >>>>>of this mapping may not be needed at all. For example, an S-VLAN >>>>>allocation module in the management plane in a PE can do this kind of >>>>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>>>way from a free S-VLAN ID pool. Once the interal S-VLANs are >>>>>allocated, >>>>>the mapping is determined and no other configuration is needed. >>>>> >>>>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>>>allocate >>>>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to >>>>>allocate >>>>>two S-VLANs in the VPLS domain. >>>>> >>>>>On the other hand, for the multi-PW approach, two PWs need to be >>>>>configured for a E-Tree service. When MS-PW is used in the network, >>>>>for >>>>>every S-PE, we need to configure two ingress PW segments and two >>>>>egress >>>>>PW segments. In this case, I don't think we need to use fixed PW >>>>>labels >>>>>across the network for fear of configuration complexity. >>>>> >>>>>Regards, >>>>>Yuanlong >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>Sent: Wednesday, May 02, 2012 8:01 PM >>>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; >>>>>josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Inline. >>>>> >>>>>-----Original Message----- >>>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>>Sent: Wednesday, May 02, 2012 12:30 PM >>>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; >>>>>josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Hi Daniel, Please see my comments in line. >>>>> >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>Sent: Wednesday, May 02, 2012 3:55 PM >>>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Hi Yuanlong, >>>>> >>>>>The problem is not with the total number of S-VLAN IDs, I agree that >>>>>normally there won't be more than 2047. The problem is that if you >>>>>don't >>>>>support all VLAN IDs, you need S-VLAN space coordination with the >>>>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to >>>>>2047". >>>>>Which won't always be in line with an existing deployment. >>>>>[JY] This is not the case. If the total number is no more than 2047, >>>>>it >>>>>surely can be supported. The S-VLAN space of user domain is totally >>>>>different from the S-VLAN in the provider domain and they can be >>>>>overlapped, I don't see why we need S-VLAN space coordination between >>>>>them. >>>>> >>>>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>>>fixed, and therefore the IEEE S-VID that can be supported is also >>>>>fixed. >>>>> >>>>>Of course you can configure the mapping in each PE according to >>>>>operator >>>>>requirements but as we discussed before this increases complexity. >>>>> >>>>>Relying on PBB-VPLS imposes additional limitations on backward >>>>>compatibility. >>>>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>>>think they may well need MAC-in-MAC in their networks for the >>>>>scalability issue. As you know, only PBB VPLS can provide both. >>>>> >>>>>Daniel >>>>> >>>>>-----Original Message----- >>>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>>Sent: Wednesday, May 02, 2012 5:07 AM >>>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; >>>>>josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Hi Daniel, >>>>> >>>>>As you can see, both cases are discussed in the I-D. >>>>> >>>>>With regard to case 1) (that is, S-VLAN translation), since the access >>>>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>>>they need to be configured on a PE anyway, and as the past emails by >>>>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>>>mapping. >>>>> >>>>>With regard to S-VID space reduction, the constraint is valid only >>>>>when >>>>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>>>typical and with no such limits as we already discussed in the f2f >>>>>meeting. >>>>> >>>>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>>>described (not sure this is a valid use case in real life), PBB-VPLS >>>>>can >>>>>still be used. >>>>> >>>>>Regards, >>>>>Yuanlong >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>Sent: Monday, April 30, 2012 10:34 PM >>>>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>>Jiangyuanlong; josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>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] >>>>>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 >>>>> >>>>>------------------------------------------------------------------- --- >>>> >>>> >>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>proprietary information, which is privileged, confidential, or subject >>>>to >>>>copyright belonging to Time Warner Cable. This E-mail is intended >>>>solely >>>>for the use of the individual or entity to which it is addressed. If >>>>you >>>>are not the intended recipient of this E-mail, you are hereby notified >>>>that any dissemination, distribution, copying, or action taken in >>>>relation to the contents of and attachments to this E-mail is strictly >>>>prohibited and may be unlawful. If you have received this 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 and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for >the use of the individual or entity to which it is addressed. If you are >not >the intended recipient of this E-mail, you are hereby notified that any >dissemination, distribution, copying, or action taken in relation to the >contents of and attachments to this E-mail is strictly prohibited and may >be >unlawful. If you have received this 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 96, Issue 15 >************************************* > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this 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 DanielC@orckit.com Tue May 8 06:57: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 DDD0321F85A3 for ; Tue, 8 May 2012 06:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.182 X-Spam-Level: X-Spam-Status: No, score=-2.182 tagged_above=-999 required=5 tests=[AWL=-0.183, 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 WQsVe0kdeIA1 for ; Tue, 8 May 2012 06:57:23 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7D721F8562 for ; Tue, 8 May 2012 06:57:21 -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: L2vpn Digest, Vol 96, Issue 15 Date: Tue, 8 May 2012 16:59:16 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780CB39@tlvmail1> In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410C62@szxeml546-mbx.china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: L2vpn Digest, Vol 96, Issue 15 Thread-Index: AQHNKgNyPxr7nh+DX0S+AUfrSOoOpZa57ewAgARPYACAABdtgIAA8VnQgABOaUCAAAEZoIAABFOggABM/3CAAAFowIAAAXRwgAAHZSA= References: <2691CE0099834E4A9C5044EEC662BB9D330F0740@dfweml506-mbx> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410ABC@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CA64@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410B5D@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CA6E@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410BFF@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CB27@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410C62@szxeml546-mbx.china.huawei.com> From: "Daniel Cohn" To: "Jiangyuanlong" , "Rogers, Josh" , "Lucy yong" , "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: Tue, 08 May 2012 13:57:27 -0000 >From the PW maintenance point of view, all PWs are the same. There is no difference in the maintenance operations for root/leaf/normal PW. Root/leaf is signaled in LDP so mismatch can be detected and notified to operator. DC -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Tuesday, May 08, 2012 4:38 PM To: Daniel Cohn; Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 Except PW numbers, now PW attributes also needs to be considered: root, leaf or normal. Can the root or leaf PW be connected to the normal PW? Or just connect root to root, and leaf to leaf? Without signalling, this will pose a great challenge to configure the OAM correctly. -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Tuesday, May 08, 2012 9:29 PM To: Jiangyuanlong; Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 Yuanlong, I don't see the additional complexity. Existing PW maintenance processes at the operator can take care of the additional root/leaf PWs exactly like they do today. Only they will have some more PWs to maintain (not twice as much, since most PEs are typically leaf-only and therefore have only a root PW per E-Tree instance) And service maintenance processes should be extended to maintain root and leaf services using E-OAM, both for the 2-VLAN and multi-PW solutions. DC -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Tuesday, May 08, 2012 4:23 PM To: Daniel Cohn; Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 Daniel, RFC 6136 provides the VPLS OAM reqs and framework, and Sec. 10.1. gives the typical VPLS OAM Operational Scenarios: --- --- / \ ------ ------- ---- / \ | A CE-- / \ / \ / \ --CE A | \ / \ / \ / \ / \ / \ / --- --UPE NPE NPE UPE-- --- \ / \ / \ / \ / \ / \ / ------ ------- ---- Customer OAM Domain (C) MEP---MIP--------------------------------MIP---MEP Service Provider (SP) OAM Domain (D) MEP--------MIP-----------MIP-------MEP SP OAM SP OAM SP OAM (D1) MEP-MIP--MEP|MEP-------MEP|MEP-----MEP domain domain domain Operator Operator Operator (E) MEP-MIP--MEP|MEP-------MEP|MEP-----MEP OAM domain OAM domain OAM domain MPLS OAM MPLS OAM (F) MEP--MIP-----MEP--MIP--MEP domain domain Figure 10: VPLS OAM Domains, MEPs, and MIPs It seems OAM configurations in Scenario D1) and E) for 2PW approach will be much complicated and error prone, since E-Tree OAM now needs to interwork with one of these two PWs' OAM (maybe both, I am afraid). For scenario F), the concatanation of two MPLS OAM also needs to be very careful as 4 PWs and 3 types (i.e, root/leaf/normal) may be involved there. Regards, Yuanlong -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Tuesday, May 08, 2012 4:49 PM To: Jiangyuanlong; Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 Inline -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Tuesday, May 08, 2012 11:42 AM To: Daniel Cohn; Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 I don't think so. There may be different layers of OAM applicable to a service. Such as LSP layer, PW layer, and service layer. [DC] Agreed Now you cannot use a single LSP OAM to monitor the server layer of the E-Tree service (as 2 LSP may be involved). And the service layer of OAM for E-Tree may be distributed to different LSP paths. [DC] For E-Tree service OAM, you would perform OAM actions from MEPs associated to root or leaf ACs, so the E-OAM frames would naturally follow the root or leaf pseudowires and the LSPs that transport them. I don't see a limitation here. -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Tuesday, May 08, 2012 4:28 PM To: Jiangyuanlong; Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 Yuanlong, isn't this orthogonal to the issues we are discussing? I mean, there are different mechanisms to troubleshoot PWs, all of which are applicable to root/leaf PWs as to any other PWs. Or is there any specific limitation on root/leaf PW troubleshooting, compared to "regular" PWs used in VPLSs? Thanks, Daniel -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Jiangyuanlong Sent: Tuesday, May 08, 2012 7:04 AM To: Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 Josh,=20 Just some comments on this part: [JR] I don't see this any more of a problem than troubleshooting one. If LDP is used, a simple mols traceroute shows the path that ALL PW's to that PE take, regardless of which service (this VPLS or another VPLS instance). If RSVP is used, there should be a route-object that shows me the path, and allows me to troubleshoot. Additionally, if I wanted to have traffic engineering that impacted root-sourced and leaf-sourced traffic differently, I can do that with multi-PW, where I could not (save for ingress/egress) with the 2VLAN approach. PE should report signaling on second PW same as it does for the 100th PW between PE's. Again, I don't see the problem you are alluding to. I suppose you are referring to LSP Ping on the LSP layer, yes, it can oversee all the PWs in this LSP. If both root and leaf PW are in the same LSP, it can work. But there may well be multiple LSPs between a pair of PEs, and root/leaf PW may be transported on different LSPs. Another difficulty is, if ECMP is deployed and PW label as a bottom label is used for hashing, the OAM message may be load balanced on different paths. With regard to TE, you could use DS-TE, just as Lucy said, two PW do not guarantee they are traffic engineered. Thanks Yuanlong -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com]=20 Sent: Tuesday, May 08, 2012 5:22 AM To: Lucy yong; Sam Cao; l2vpn@ietf.org Cc: Jiangyuanlong Subject: Re: L2vpn Digest, Vol 96, Issue 15 Comments inline (and s/conquer/concur/) On 5/7/12 2:58 PM, "Lucy yong" wrote: >Sam, > >I concur with Yuanlong's reply on this. Please see inline. > >Lucy > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >Sam Cao >Sent: Friday, May 04, 2012 9:09 PM >To: l2vpn@ietf.org >Cc: Jiangyuanlong >Subject: RE: L2vpn Digest, Vol 96, Issue 15 > >Lucy/Yuanlong, > >I agree that we can not say which approach is better simply, but I really >agree with Josh's comments. Multi-PW is easy to implement E-Tree. >[[LY]] I don't get impression Josh state this. > >First of all, we discussed 2 approaches for a long time and many rounds, >and >for me, there are no pending issues on Multi-PW till now or co-authors of >multi-PW have given reasonable reply to L2VPN members' questions, but >there >are still pending issues for Dual-VLAN. Please trace the mailing list. >[[LY]] I interpret this as people want to spend time to finalize dual >VLAN solution. Multi-PW has some operation impact. How do operator to >maintain this service and be able to trouble shooting. How do you expect >traceroute work when using two PWs for one VPN? How do you expect PE >report when there is an error on one of two PWs? Do you have one FEC or >two FEC for a E-Tree in control plane? [JR] I don't see this any more of a problem than troubleshooting one. If LDP is used, a simple mols traceroute shows the path that ALL PW's to that PE take, regardless of which service (this VPLS or another VPLS instance). If RSVP is used, there should be a route-object that shows me the path, and allows me to troubleshoot. Additionally, if I wanted to have traffic engineering that impacted root-sourced and leaf-sourced traffic differently, I can do that with multi-PW, where I could not (save for ingress/egress) with the 2VLAN approach. PE should report signaling on second PW same as it does for the 100th PW between PE's. Again, I don't see the problem you are alluding to. > >Second, Sasha has his concern in NP, or forwarding performance. Compared >to >current VPLS, Multi-PW has a little effect on forwarding performance since >it reuse PW label as AC indicator; Dual-VLAN will have higher side effect >on >forwarding performance because it SHOULD use additional indicator. Is >there >one prototype for Dual-VLAN? BTW, there is no reply on chip limit. >[[LY]] in VPLS, PW label is used as VSI indicator, not AC. I disagree >your statement here. > >Third, the difference between Multi-PW and dual-VLAN is, transport ingress >traffic in one "LSP" or 2 "LSP". Multi-PW classifies and transforms >ingress >traffic into right "path", and egress just pop-out PW label and forward >the >frame to ACs. Dual-VLAN has more work on ingress PE or egress PE. >[[LY]] Don't understand the first part. When egress pop-out PW label, it >find corresponding VSI first, then perform MAC lookup associated to all >ACs. We can't assume there is one AC. > >Fourth, maybe Giles has figured this out, Dual-VLAN has capacity limit. >Only >4094 VLAN ID are available, so only 2K E-Tree instances can be supported >on >one PE for Dual-VLAN approach. There is no such limit for Multi-PW >approach, >[[LY]] If 4K VLAN ID is not an issue for VPLS, it is not an issue for >E-Tree. > >Finally, in this thread we don't make agreement on VLAN ID allocation. We >also have questions on VLAN ID negotiation among PEs (signaling protocol). >Yuanlong wishes to update, but there is no update till now. >[[LY]] This should not be the reason to judge on the solution. [JR] I tend to agree. > >For me, why IEEE uses VLAN ID to identify AC type? IEEE has no LABEL :), >and >it has label, it also wish to use label to identify AC types. I think that >both solutions need much time to be perfect. Mutli-PW has less extension >work to do. But now we are focusing on technical details and can not move >forward :). >[[LY]] VPN label is used for identify the VPN. It already has the >purpose. Overloading with other meaning has high potential causing a >problem. Hope you can investigate it more. Since you are very in favor of >multi-pw solution, it is not proper for you to come out the conclusion >which is better, because it is very biased. You are welcome to help on >completing either solution. [JR] this is humorous to me, because at one time, VLAN-ID was used to identify a single broadcast domain, and then later asymmetrical VID's were used to limit communication between endpoints of a broadcast domain (effectively creating two one-way broadcast domains, very similar to what we're accomplishing with ETREE). This should not be the reason to judge on the solution. > >Regards, >Lucy > >Lucy > >Thanks, > >Sam > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >l2vpn-request@ietf.org >Sent: Friday, May 04, 2012 10:31 PM >To: l2vpn@ietf.org >Subject: L2vpn Digest, Vol 96, Issue 15 > >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) > 2. Re: The status of the approaches to the E-Tree solution? > (Rogers, Josh) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Fri, 4 May 2012 14:16:36 +0000 >From: Lucy yong >To: "Rogers, Josh" , Jiangyuanlong > , Daniel Cohn , >"Fedyk, > Donald (Don)" , "Henderickx, Wim > (Wim)" >Cc: "l2vpn@ietf.org" >Subject: RE: The status of the approaches to the E-Tree solution? >Message-ID: <2691CE0099834E4A9C5044EEC662BB9D330E9114@dfweml505-mbx> >Content-Type: text/plain; charset=3D"iso-8859-2" > >Josh, > >You simply say that you don't like IEEE Tree solution. IEEE Tree solution >is >for ingress port to mark and for egress port to filter. > >Regards, >Lucy > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Friday, May 04, 2012 7:27 AM >To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >(Wim); >Lucy yong >Cc: l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >also separate the leaf traffic in the ingress PE and filter it there >(already detailed in the Optimization Mode in the I-D); if the egress PE >is attached with pure roots or with both roots and leafs, it seems all >traffic must be transported to the egress PE and be filtered there, I see >no difference in behaviour for these solutions. Or did I miss something? > > >The point is with the multi-PW method the traffic is split/separated (by >psuedowire) on the ingress PE, rather than the egress. The distinction is >2VLAN will 'classify' the frame on the ingress PE, so that the egress PE >knows how to forward it to the appropriate AC's. > >Both methods have inefficiencies (one duplicates traffic for transport, >while the other transports where it doesn't need to go). I like the idea >of classify and forwarding on the ingress PE, rather than marking it on >the ingress, and deciding on the egress. > >-Josh > > > >On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: > >>Josh, thank you for the comments, please see my further comments with >>[JY2]. >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Thursday, May 03, 2012 11:27 PM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>requirements from MEF, it has nothing to do with the solutions. Could you >>give a hint on how you can provision this service E-NNI otherwise? BTW, >>if >>configuring or signalling two PWs is not a problem, why configuring or >>signalling two VLANs will become a problem? After all, more nodes may >>need >>to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >>2VLAN (only T-PEs). >> >> >>There is no other way (if both MPLS domains are part of the same ETREE, >>rather than doing something more like H-VPLS, where one domain has point >>to points to the other domain which handles the ETREE instance) if you >>are >>using an ENNI. The other method, (not mentioned earlier) is tying the >>two >>MPLS domains together via labeled unicast (much preferred over E-NNI in >>my >>opinion) >> >>Configuring two VLAN's isn't really a 'problem' any more than two PW's. >>I >>wasn't saying that configuring two VLAN's was difficult, I was objecting >>to the statement that configuring two PW's is difficult. >> >>[JY2] Thanks, I see your point. I take the example of 2PW configuration >>just to show that using fixed global values to simplify configuration >>makes no sense. Personally I also don't think configuration is a problem >>for both solutions. >> >>I find the differences between these two methods rather slight. The >>'tie-breaker' for me is by placing the forwarding decision on the ingress >>PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >>more control over where the traffic goes, and in my mind it provides a >>cleaner destination between customer traffic and forwarding plane. I'm >>accustomed to looking at a psuedowire and knowing where its going, with >>the 2vlan method, I can see the psuedowire, but must go to the egress PE >>to see if it will be dropped there, or forwarded to one or more AC's. >> >>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>also separate the leaf traffic in the ingress PE and filter it there >>(already detailed in the Optimization Mode in the I-D); if the egress PE >>is attached with pure roots or with both roots and leafs, it seems all >>traffic must be transported to the egress PE and be filtered there, I see >>no difference in behaviour for these solutions. Or did I miss something? >> >>Again, the difference here is slight, and I would honestly be happy to >>see >>either of them come to fruition. Please don't infer that I think the >>2vlan method is 'bad' or has intrinsic problems, because I don't believe >>that. I just prefer the multi-PW method. >> >> >>-Josh >> >> >>On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: >> >>>Josh, please see my comments in line. >>> >>>Thanks >>>Yuanlong >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Thursday, May 03, 2012 10:51 AM >>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>(Wim); Lucy yong >>>Cc: l2vpn@ietf.org >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Yuanlong, >>> >>>Or better yet, include in the draft a 'standard' value for root sourced >>>VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You would also >>>have to require the the implementation NOT use global VLAN's, however >>>(since each instance would be using the same values). In this way, no >>>signaling or manual configuration is required for remote PE's to know >>>how >>>to classify traffic. >>>[JY] Indeed, we discussed this possibility during the f2f meeting in >>>Paris. But, there are some restrictions as you mentioned, and >>>furthermore: >>>1) Some vendors already used S-VLAN to distinguish their VSIs in the PE; >>>2) Forwarding plane of a PE needs to be revised to be aware of this VLAN >>>ID. >>>Therefore, this 'standard value' approach seems more disruptive compared >>>with the other means and not a good candidate option. >>> >>>Regarding switching PE's? Multi-PW means more than one PW, yes. I >>>don't >>>see this as a real problem. In general, design should try and avoid >>>using >>>S-PE's, but if you must, its going to mean extra work, no matter how you >>>look at it. Two PW's for each Etree being switched instead of one is >>>not >>>alarming or concerning to me. On the other hand, if you use a dot1q >>>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's >>>an >>>two egress VLAN's if you want the Etree to be handled on both sides (and >>>if you use the 'standard' VID's as I mentioned above, you'd have to do >>>mapping to non-standard and back) >>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>requirements from MEF, it has nothing to do with the solutions. Could >>>you >>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>if configuring or signalling two PWs is not a problem, why configuring >>>or >>>signalling two VLANs will become a problem? After all, more nodes may >>>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>>with 2VLAN (only T-PEs). >>> >>>In general, I still prefer multi-PW, primarily because I prefer the >>>separation of the traffic in the network's forwarding plane, rather than >>>shipping it everywhere and deciding whether to forward to the AC when it >>>gets to the egress PE. I'm having a hard time putting my finger exactly >>>on what it is, or articulating the idea, but it seems that by having the >>>traffic placed into two psuedowires, I have more flexibility and ease of >>>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>>PW's could really change that perception. >>>[JY] Are you saying that we need to develop a totally new forwarding >>>plane rather than using the Ethernet forwarding plane as described in >>>the >>>existing work? >>> >>>I hope we can move forward with one of these soon, >>>[JY] me too. >>> >>>Josh >>> >>> >>>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >>> >>>>Daniel, >>>> >>>>Not aware that we had a discussion on this before, but IMHO the >>>>allocation of internal S-VLAN can be automatic, and manuel >>>>configuration >>>>of this mapping may not be needed at all. For example, an S-VLAN >>>>allocation module in the management plane in a PE can do this kind of >>>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>>way from a free S-VLAN ID pool. Once the interal S-VLANs are allocated, >>>>the mapping is determined and no other configuration is needed. >>>> >>>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>>allocate >>>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to allocate >>>>two S-VLANs in the VPLS domain. >>>> >>>>On the other hand, for the multi-PW approach, two PWs need to be >>>>configured for a E-Tree service. When MS-PW is used in the network, for >>>>every S-PE, we need to configure two ingress PW segments and two egress >>>>PW segments. In this case, I don't think we need to use fixed PW labels >>>>across the network for fear of configuration complexity. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 8:01 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Inline. >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 12:30 PM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, Please see my comments in line. >>>> >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 3:55 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Yuanlong, >>>> >>>>The problem is not with the total number of S-VLAN IDs, I agree that >>>>normally there won't be more than 2047. The problem is that if you >>>>don't >>>>support all VLAN IDs, you need S-VLAN space coordination with the >>>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to >>>>2047". >>>>Which won't always be in line with an existing deployment. >>>>[JY] This is not the case. If the total number is no more than 2047, it >>>>surely can be supported. The S-VLAN space of user domain is totally >>>>different from the S-VLAN in the provider domain and they can be >>>>overlapped, I don't see why we need S-VLAN space coordination between >>>>them. >>>> >>>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>>fixed, and therefore the IEEE S-VID that can be supported is also >>>>fixed. >>>> >>>>Of course you can configure the mapping in each PE according to >>>>operator >>>>requirements but as we discussed before this increases complexity. >>>> >>>>Relying on PBB-VPLS imposes additional limitations on backward >>>>compatibility. >>>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>>think they may well need MAC-in-MAC in their networks for the >>>>scalability issue. As you know, only PBB VPLS can provide both. >>>> >>>>Daniel >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 5:07 AM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, >>>> >>>>As you can see, both cases are discussed in the I-D. >>>> >>>>With regard to case 1) (that is, S-VLAN translation), since the access >>>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>>they need to be configured on a PE anyway, and as the past emails by >>>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>>mapping. >>>> >>>>With regard to S-VID space reduction, the constraint is valid only when >>>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>>typical and with no such limits as we already discussed in the f2f >>>>meeting. >>>> >>>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>>described (not sure this is a valid use case in real life), PBB-VPLS >>>>can >>>>still be used. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Monday, April 30, 2012 10:34 PM >>>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>Jiangyuanlong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>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] >>>>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 >>>> >>>>-------------------------------------------------------------------- -- >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to >>>copyright belonging to Time Warner Cable. This E-mail is intended solely >>>for the use of the individual or entity to which it is addressed. If you >>>are not the intended recipient of this E-mail, you are hereby notified >>>that any dissemination, distribution, copying, or action taken in >>>relation to the contents of and attachments to this E-mail is strictly >>>prohibited and may be unlawful. If you have received this 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. > > >------------------------------ > >Message: 2 >Date: Fri, 4 May 2012 10:30:38 -0400 >From: "Rogers, Josh" >To: Lucy yong , Jiangyuanlong > , Daniel Cohn , >"Fedyk, > Donald (Don)" , "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"iso-8859-2" > >To be more accurate, I like it less than the multi-PW solution. I'd be >happy to use the 2VLAN solution in the real world, if it was ratified as >the standard. > > > >On 5/4/12 9:16 AM, "Lucy yong" wrote: > >>Josh, >> >>You simply say that you don't like IEEE Tree solution. IEEE Tree solution >>is for ingress port to mark and for egress port to filter. >> >>Regards, >>Lucy >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Friday, May 04, 2012 7:27 AM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>also separate the leaf traffic in the ingress PE and filter it there >>(already detailed in the Optimization Mode in the I-D); if the egress PE >>is attached with pure roots or with both roots and leafs, it seems all >>traffic must be transported to the egress PE and be filtered there, I see >>no difference in behaviour for these solutions. Or did I miss something? >> >> >>The point is with the multi-PW method the traffic is split/separated (by >>psuedowire) on the ingress PE, rather than the egress. The distinction >>is >>2VLAN will 'classify' the frame on the ingress PE, so that the egress PE >>knows how to forward it to the appropriate AC's. >> >>Both methods have inefficiencies (one duplicates traffic for transport, >>while the other transports where it doesn't need to go). I like the idea >>of classify and forwarding on the ingress PE, rather than marking it on >>the ingress, and deciding on the egress. >> >>-Josh >> >> >> >>On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: >> >>>Josh, thank you for the comments, please see my further comments with >>>[JY2]. >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Thursday, May 03, 2012 11:27 PM >>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>(Wim); Lucy yong >>>Cc: l2vpn@ietf.org >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>requirements from MEF, it has nothing to do with the solutions. Could >>>you >>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>if >>>configuring or signalling two PWs is not a problem, why configuring or >>>signalling two VLANs will become a problem? After all, more nodes may >>>need >>>to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >>>2VLAN (only T-PEs). >>> >>> >>>There is no other way (if both MPLS domains are part of the same ETREE, >>>rather than doing something more like H-VPLS, where one domain has point >>>to points to the other domain which handles the ETREE instance) if you >>>are >>>using an ENNI. The other method, (not mentioned earlier) is tying the >>>two >>>MPLS domains together via labeled unicast (much preferred over E-NNI in >>>my >>>opinion) >>> >>>Configuring two VLAN's isn't really a 'problem' any more than two PW's. >>>I >>>wasn't saying that configuring two VLAN's was difficult, I was objecting >>>to the statement that configuring two PW's is difficult. >>> >>>[JY2] Thanks, I see your point. I take the example of 2PW configuration >>>just to show that using fixed global values to simplify configuration >>>makes no sense. Personally I also don't think configuration is a problem >>>for both solutions. >>> >>>I find the differences between these two methods rather slight. The >>>'tie-breaker' for me is by placing the forwarding decision on the >>>ingress >>>PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >>>more control over where the traffic goes, and in my mind it provides a >>>cleaner destination between customer traffic and forwarding plane. I'm >>>accustomed to looking at a psuedowire and knowing where its going, with >>>the 2vlan method, I can see the psuedowire, but must go to the egress PE >>>to see if it will be dropped there, or forwarded to one or more AC's. >>> >>>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>>also separate the leaf traffic in the ingress PE and filter it there >>>(already detailed in the Optimization Mode in the I-D); if the egress PE >>>is attached with pure roots or with both roots and leafs, it seems all >>>traffic must be transported to the egress PE and be filtered there, I >>>see >>>no difference in behaviour for these solutions. Or did I miss something? >>> >>>Again, the difference here is slight, and I would honestly be happy to >>>see >>>either of them come to fruition. Please don't infer that I think the >>>2vlan method is 'bad' or has intrinsic problems, because I don't believe >>>that. I just prefer the multi-PW method. >>> >>> >>>-Josh >>> >>> >>>On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: >>> >>>>Josh, please see my comments in line. >>>> >>>>Thanks >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>>Sent: Thursday, May 03, 2012 10:51 AM >>>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>>(Wim); Lucy yong >>>>Cc: l2vpn@ietf.org >>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>> >>>>Yuanlong, >>>> >>>>Or better yet, include in the draft a 'standard' value for root sourced >>>>VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You = would also >>>>have to require the the implementation NOT use global VLAN's, however >>>>(since each instance would be using the same values). In this way, no >>>>signaling or manual configuration is required for remote PE's to know >>>>how >>>>to classify traffic. >>>>[JY] Indeed, we discussed this possibility during the f2f meeting in >>>>Paris. But, there are some restrictions as you mentioned, and >>>>furthermore: >>>>1) Some vendors already used S-VLAN to distinguish their VSIs in the >>>>PE; >>>>2) Forwarding plane of a PE needs to be revised to be aware of this >>>>VLAN >>>>ID. >>>>Therefore, this 'standard value' approach seems more disruptive >>>>compared >>>>with the other means and not a good candidate option. >>>> >>>>Regarding switching PE's? Multi-PW means more than one PW, yes. I >>>>don't >>>>see this as a real problem. In general, design should try and avoid >>>>using >>>>S-PE's, but if you must, its going to mean extra work, no matter how >>>>you >>>>look at it. Two PW's for each Etree being switched instead of one is >>>>not >>>>alarming or concerning to me. On the other hand, if you use a dot1q >>>>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's >>>>an >>>>two egress VLAN's if you want the Etree to be handled on both sides >>>>(and >>>>if you use the 'standard' VID's as I mentioned above, you'd have to do >>>>mapping to non-standard and back) >>>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>>requirements from MEF, it has nothing to do with the solutions. Could >>>>you >>>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>>if configuring or signalling two PWs is not a problem, why configuring >>>>or >>>>signalling two VLANs will become a problem? After all, more nodes may >>>>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>>>with 2VLAN (only T-PEs). >>>> >>>>In general, I still prefer multi-PW, primarily because I prefer the >>>>separation of the traffic in the network's forwarding plane, rather >>>>than >>>>shipping it everywhere and deciding whether to forward to the AC when >>>>it >>>>gets to the egress PE. I'm having a hard time putting my finger >>>>exactly >>>>on what it is, or articulating the idea, but it seems that by having >>>>the >>>>traffic placed into two psuedowires, I have more flexibility and ease >>>>of >>>>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>>>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>>>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>>>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>>>PW's could really change that perception. >>>>[JY] Are you saying that we need to develop a totally new forwarding >>>>plane rather than using the Ethernet forwarding plane as described in >>>>the >>>>existing work? >>>> >>>>I hope we can move forward with one of these soon, >>>>[JY] me too. >>>> >>>>Josh >>>> >>>> >>>>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >>>> >>>>>Daniel, >>>>> >>>>>Not aware that we had a discussion on this before, but IMHO the >>>>>allocation of internal S-VLAN can be automatic, and manuel >>>>>configuration >>>>>of this mapping may not be needed at all. For example, an S-VLAN >>>>>allocation module in the management plane in a PE can do this kind of >>>>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>>>way from a free S-VLAN ID pool. Once the interal S-VLANs are >>>>>allocated, >>>>>the mapping is determined and no other configuration is needed. >>>>> >>>>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>>>allocate >>>>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to >>>>>allocate >>>>>two S-VLANs in the VPLS domain. >>>>> >>>>>On the other hand, for the multi-PW approach, two PWs need to be >>>>>configured for a E-Tree service. When MS-PW is used in the network, >>>>>for >>>>>every S-PE, we need to configure two ingress PW segments and two >>>>>egress >>>>>PW segments. In this case, I don't think we need to use fixed PW >>>>>labels >>>>>across the network for fear of configuration complexity. >>>>> >>>>>Regards, >>>>>Yuanlong >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>Sent: Wednesday, May 02, 2012 8:01 PM >>>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; >>>>>josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Inline. >>>>> >>>>>-----Original Message----- >>>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>>Sent: Wednesday, May 02, 2012 12:30 PM >>>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; >>>>>josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Hi Daniel, Please see my comments in line. >>>>> >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>Sent: Wednesday, May 02, 2012 3:55 PM >>>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Hi Yuanlong, >>>>> >>>>>The problem is not with the total number of S-VLAN IDs, I agree that >>>>>normally there won't be more than 2047. The problem is that if you >>>>>don't >>>>>support all VLAN IDs, you need S-VLAN space coordination with the >>>>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to >>>>>2047". >>>>>Which won't always be in line with an existing deployment. >>>>>[JY] This is not the case. If the total number is no more than 2047, >>>>>it >>>>>surely can be supported. The S-VLAN space of user domain is totally >>>>>different from the S-VLAN in the provider domain and they can be >>>>>overlapped, I don't see why we need S-VLAN space coordination between >>>>>them. >>>>> >>>>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>>>fixed, and therefore the IEEE S-VID that can be supported is also >>>>>fixed. >>>>> >>>>>Of course you can configure the mapping in each PE according to >>>>>operator >>>>>requirements but as we discussed before this increases complexity. >>>>> >>>>>Relying on PBB-VPLS imposes additional limitations on backward >>>>>compatibility. >>>>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>>>think they may well need MAC-in-MAC in their networks for the >>>>>scalability issue. As you know, only PBB VPLS can provide both. >>>>> >>>>>Daniel >>>>> >>>>>-----Original Message----- >>>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>>Sent: Wednesday, May 02, 2012 5:07 AM >>>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>>yong; >>>>>josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Hi Daniel, >>>>> >>>>>As you can see, both cases are discussed in the I-D. >>>>> >>>>>With regard to case 1) (that is, S-VLAN translation), since the access >>>>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>>>they need to be configured on a PE anyway, and as the past emails by >>>>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>>>mapping. >>>>> >>>>>With regard to S-VID space reduction, the constraint is valid only >>>>>when >>>>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>>>typical and with no such limits as we already discussed in the f2f >>>>>meeting. >>>>> >>>>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>>>described (not sure this is a valid use case in real life), PBB-VPLS >>>>>can >>>>>still be used. >>>>> >>>>>Regards, >>>>>Yuanlong >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>>Sent: Monday, April 30, 2012 10:34 PM >>>>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>>Jiangyuanlong; josh.rogers@twcable.com >>>>>Cc: l2vpn@ietf.org >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>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] >>>>>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 >>>>> >>>>>------------------------------------------------------------------- --- >>>> >>>> >>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>proprietary information, which is privileged, confidential, or subject >>>>to >>>>copyright belonging to Time Warner Cable. This E-mail is intended >>>>solely >>>>for the use of the individual or entity to which it is addressed. If >>>>you >>>>are not the intended recipient of this E-mail, you are hereby notified >>>>that any dissemination, distribution, copying, or action taken in >>>>relation to the contents of and attachments to this E-mail is strictly >>>>prohibited and may be unlawful. If you have received this 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 and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for >the use of the individual or entity to which it is addressed. If you are >not >the intended recipient of this E-mail, you are hereby notified that any >dissemination, distribution, copying, or action taken in relation to the >contents of and attachments to this E-mail is strictly prohibited and may >be >unlawful. If you have received this 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 96, Issue 15 >************************************* > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this 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 Tue May 8 07:45: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 15F3121F8606 for ; Tue, 8 May 2012 07:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.214 X-Spam-Level: X-Spam-Status: No, score=-2.214 tagged_above=-999 required=5 tests=[AWL=-0.215, 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 aZxSSGQk5Kus for ; Tue, 8 May 2012 07:45:37 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 306A421F8607 for ; Tue, 8 May 2012 07:45:36 -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 AFP90390; Tue, 08 May 2012 10:45:33 -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; Tue, 8 May 2012 07:43:53 -0700 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.003; Tue, 8 May 2012 07:43:47 -0700 From: Lucy yong To: Aldrin Isaac Subject: RE: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0oo3KJO48LuIhSPkS8Et2e3RTHugARqg4SAAf687wAETa4GgAG6vgwADqVW84AgltJsAAq11+AAAemMbA= Date: Tue, 8 May 2012 14:43:47 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D3310541C@dfweml506-mbx> References: <2691CE0099834E4A9C5044EEC662BB9D330E8F11@dfweml505-mbx> <2E819CEF-4A49-439B-86DF-C17503A75398@gmail.com> <2691CE0099834E4A9C5044EEC662BB9D330E918C@dfweml505-mbx> <03B0FD5F-D9F5-4C4E-A7FD-0A2C36A7B092@gmail.com> <2691CE0099834E4A9C5044EEC662BB9D330F0566@dfweml506-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.152.253] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l2vpn@ietf.org" , sajassi 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, 08 May 2012 14:45:38 -0000 Hi Aldrin, I got it. Thanks a lot. Interconnecting private LANs and Community LAN is the application for E-Tre= e, where private LAN set as leaf AC and Community LAN set as root AC. Of co= urse, policy based-topology can support other more sophisticated scenarios. Lucy -----Original Message----- From: Aldrin Isaac [mailto:aldrin.isaac@gmail.com]=20 Sent: Monday, May 07, 2012 11:00 PM To: Lucy yong Cc: sajassi; Giles Heron; Nabil Bitar; l2vpn@ietf.org Subject: Re: Interest in IS-IS VPLS Hi Lucy, see in line. On May 7, 2012, at 11:19 AM, Lucy yong wrote: > Hi Aldrin, >=20 > Thank you very for sharing your insight. It is great and very helpful. It= is fine to add new service features on existing services. In fact, that is= what we are working on in IETF. =20 >=20 > From customer perspective, E-VPN supports all existing VPLS capability an= d add active-active mode and some policy based-topology control. It is usef= ul extension. SPT based LAN is the history technology. LAG, MSTP, TRILL, SP= B etc are all the replacement solutions.=20 >=20 > One thing that I am not clear from your reply is that the policy for L2VP= N is to be against VLAN or MAC? > The latter will be very complex and not scale. The former will have some = additional challenges and complex because VLAN ID may not be global based I= D like IP addresses and L2VPN forwarding is based on MAC address while poli= cy control is based on VLAN. Do I understand this right? Policy is applied to the EVI (VRF) table which applies to all route types i= n the table. An EVI can have a single link or be shared by multiple links.= The tag with which a packet arrives into the network does not have to be = the tag with which it leaves the network. I.e. destination tag and ingress= tag are decoupled in EVPN. > IMO: simplification is also important work for IETF and benefit to busine= sses as silicon technology improving. Without it, we have some limited room= for adding new useful features and the system will be overly complex so no= body can afford operating it. This does not say E-VPN. For operators who want simplicity, they can get this easily by moving compu= te/storage to hypervisors and buying an overlay solution -- it's available = today commercial or free. It's the cheapest and easiest to implement out o= f the box with little to no knowledge of networking protocols. I'm observi= ng sysadmin and security guys set this up today (literally). > Thanks again. >=20 > Lucy >=20 >=20 >=20 >=20 > -----Original Message----- > From: Aldrin Isaac [mailto:aldrin.isaac@gmail.com]=20 > Sent: Friday, May 04, 2012 7:20 PM > To: Lucy yong > Cc: sajassi; Giles Heron; Nabil Bitar; l2vpn@ietf.org > Subject: Re: Interest in IS-IS VPLS >=20 > Hi Lucy, >=20 > Please see inline >=20 > On May 4, 2012, at 11:07 AM, Lucy yong wrote: >=20 >> Hi Isaac, >>=20 >> Thank you for the reply. Please see inline. >>=20 >> Regards, >> Lucy >>=20 >> -----Original Message----- >> From: Aldrin Isaac [mailto:aldrin.isaac@gmail.com]=20 >> Sent: Thursday, May 03, 2012 10:50 PM >> To: Lucy yong >> Cc: sajassi; Giles Heron; Nabil Bitar; l2vpn@ietf.org >> Subject: Re: Interest in IS-IS VPLS >>=20 >=20 > ...=20 >=20 >> E-VPN also supports policy based-topologies versus simple point-to-point= , flat or tree VLANs. It can support point-to-point, tree, mesh, one-way, = or pretty much any other "complex" or overlapped topologies (depending on h= ow you like to see it). An example is ability to natively recreate private= vlan, community vlan topologies (which happen to be quite common in DC net= works) and any number of combinations of these simultaneously to a single p= ort. A BGP E-VPN VPN is also decoupled from the edge EVI/ESI such that it = is not limited to a single tenant/vlan but can span tenants/vlans (l2 extra= net) if so required. This is native to E-VPN. >> [[LY]] Such policy based-topologies are useful for service provider netw= ork, but may too complex for intra DCs. One reason that customers often wan= t to choose with L2VPN service is "it is simple". However, L3VPN have its a= pplications although some operators often complain the complexities to conf= igure these policies. Typical example is the a firewall only placed at a lo= cation. Could you share why operator want such policy based-topology for L2= VPN? >=20 > Policy-based topologies are generally complex when used to interconnect I= P networks because there are generally multiple prefixes in a vrf, and ofte= n different prefixes need to be associated to different VPNs or routing beh= avior. In the DC, L2VPN role is to interconnect host ports so the policies= for basic are very simple --- list of import route targets and list of exp= ort route targets where each import/export pair correspond to a VPN (tenant= , service, ...). An example of how a DC operator might use this for exampl= e is to meet a requirement for private vlan and community vlans which are v= ery common for DMZs. Hopefully you are familiar with these very common use= cases. It is even possible to recreate more complex switch "features" lik= e MVR (in addition to private VLANs which are also considered "features") u= sing E-VPN. It took me three years to get the MVR feature into a particula= r vendor's switch to meet a business need. I'll sacrifice plug-and-play si= mplicity for business agility. I'm sure my peers are with me on this one. >=20 > If simple "plug-and-play" is important, one could imagine RRs sending out= an "RR TLV" such that RRs in an IGP area auto-connect with each other and = RR-clients connect to the closest RR based on SPF (some details like peer-g= roup, etc would need to be factored in to make it more powerful). Other BG= P/MPLS configuration is, IMHO, trivial unless you CHOOSE to use more advanc= ed capabilities (i.e. not locked in). =20 >=20 > Maybe the reason why MPLS comes across as complex is because of how IETF = deals with requirements lately by creating point solutions. E-VPN tries to= put new capabilities on the table while trying not to take existing value = off the table. There is no reason why a solution can't bring more value th= an what the standards body calls for. >=20 >> E-VPN supports interconnecting end-stations or interconnecting L2 networ= ks. Procedures to easily span STP based networks across an E-VPN network w= ithout loops comes with the base spec. Extensions to E-VPN, such as PBB-EV= PN, simplify the fully functional spanning of non-EVPN networks across an E= -VPN network. >> [[LY]] current L2VPN support all these except active-active mode which c= auses the loop. >=20 > Base E-VPN spec will natively deal with the STP case through an active/st= andby mode and BPDU-snooping -- detect root bridge and use that as ESI (eth= ernet segment id) to indicate unique STP network with active/standby bit se= t to ensure only one forwarding link among links with same ESI. Tags (vlan= s) can potentially each have a different active link within the member link= s of an ESI allowing for automatic tag(tenant)/vlan level load-balancing in= to an STP network. Edge networks that don't have mac-move issue will be ab= le to take full advantage of active-active load-balancing without need for = LAG/MLAG. >=20 >> An SVI/IRB interface can also be a member of both an E-VPN EVI and an IP= VRF allowing for easily bringing together virtual L2 and L3 topologies any= where in the network without a physical port. >> [[LY]] Could you please share how operator plan to use this? Which servi= ce will you sell to customer in this case? >=20 > The service will be where a customer wants to communicate to a destinatio= n network that is not in his subnet. Operators most interested in EVPN alr= eady have IPVPN services on their network. This is the gateway point betwe= en the EVPN virtual networks and [existing] IPVPN virtual networks. No phy= sical port required. >=20 >> E-VPN builds on top of years of work in the IETF; traffic engineering, s= caling with route reflectors and RT constrain, multicast via NG-MVPN, etc. >> [[LY]] Agree. These are useful features for service provider network. Ho= wever, these functions may not necessary within DC although they had been p= roved works well.=20 >=20 > I'm not sure how eventually re-inventing these capabilities (yes it will = happen) on behalf of a new protocol will be better than simply leveraging p= roven technology. Vendors don't need to implement every MPLS RFC ever writ= ten to be able to implement the basic E-VPN. >=20 >> Can also use IP for transport tunnel. But my understanding is that popu= lar merchant silicon has support for MPLS push/pop/swap these days (?). Th= is was captured by EVPN at it's inception, which is why the PE is referred = to as MES (MPLS-enabled switch) in E-VPN. >> [[LY]] Yes, current draft aims on MPLS solution only. But it states the = potential to extend to the use of IP tunnel.=20 >> The way I see it, a major reason why STP-based LANS are fickle and don't= scale well is on account of insufficient decoupling of core from edge crea= ted by requirement for plug-and-play and how that played out over time. Co= nversely the reason (among other things) why IP networks are more stable is= because they are not inherently plug-and-play, and with MPLS/BGP allows ex= cellent decoupling of core and edge. I don't know enough about TRILL or PB= B to comment on those -- I just know that I'm not interested for enough goo= d reasons. E-VPN enables a dynamic edge over a stable decoupled core while= giving each operator room for service differentiation. It is especially i= nteresting to operators that have invested in MPLS technology and operation= s. I can find a lot of folks that understand BGP/MPLS IPVPN and in short o= rder have them know the ins and outs of basic E-VPN. It's quite hard for m= e to find non-vendor folk who really actually understand the other technolo= gies used to span Ethernet aside from basic STP.=20 >=20 >> [[LY]] Thank you to share this in the mailing list.=20 >>=20 >> This is an operator perspective. >> [[LY]] This is great! >>=20 >>=20 >> On May 3, 2012, at 4:31 PM, Lucy yong wrote: >>=20 >>> Hi Ali, >>>=20 >>>=20 >>> "5. Ethernet VPN (E-VPN) - An enhanced Layer-2 service that >>> emulates an Ethernet (V)LAN across a PSN. E-VPN supports >>> load-sharing across multiple connections from a Layer-2 site >>> to an L2VPN service. E-VPN is primarily targeted to support >>> large-scale L2VPNs with resiliency requirements not satisfied >>> by other L2VPN solutions" >>>=20 >>> [[LY]] IMO, E-VPN enhancement is to support multi-homing with active-ac= tive mode. Load-sharing across multiple connections from a layer-2 site is = desired when this mode is used. Current VPLS can provide resiliency require= ment when the multi-homing site configured with active-standby mode. >>>=20 >>> Regards, >>> Lucy >>>=20 >>> Cheers, >>> Ali =20 >>>=20 >>=20 >=20 From linda.dunbar@huawei.com Tue May 8 07:56: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 895CC21F865B for ; Tue, 8 May 2012 07:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[AWL=0.067, 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 FMIQSTnYjTnW for ; Tue, 8 May 2012 07:56:53 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id E64F521F8648 for ; Tue, 8 May 2012 07:56:48 -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 AFX88937; Tue, 08 May 2012 10:56:48 -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; Tue, 8 May 2012 07:54:49 -0700 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.003; Tue, 8 May 2012 07:54:45 -0700 From: Linda Dunbar To: Aldrin Isaac Subject: RE: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: AQHNKJ3mO48LuIhSPkS8Et2e3RTHupa3awKA//+BFwCAAUwRAIAAibWAgAA5z4CAAHp5AIAAvVcAgACaWQCABBCQcIAA5RAAgAA+2iA= Date: Tue, 8 May 2012 14:54:44 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F63392BC4F@dfweml506-mbx> References: <2691CE0099834E4A9C5044EEC662BB9D330E8F11@dfweml505-mbx> <2E819CEF-4A49-439B-86DF-C17503A75398@gmail.com> <2691CE0099834E4A9C5044EEC662BB9D330E918C@dfweml505-mbx> <03B0FD5F-D9F5-4C4E-A7FD-0A2C36A7B092@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F633918DFE@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.192.11.156] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l2vpn@ietf.org" , sajassi 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, 08 May 2012 14:56:54 -0000 Isaac,=20 I thought that is why "Private VLAN" is introduced.=20 You can put the pair of firewalls in "private VLAN" and create a group of r= egular VLANs (with each VLAN mapped to /xx, and xx >24).=20 This group of VLANs can access the "private VLAN". Is it correct? Thanks for the example. Linda > -----Original Message----- > From: Aldrin Isaac [mailto:aldrin.isaac@gmail.com] > Sent: Monday, May 07, 2012 11:05 PM > To: Linda Dunbar > Cc: Lucy yong; l2vpn@ietf.org; sajassi > Subject: Re: Interest in IS-IS VPLS >=20 > Linda, >=20 > Let me give a simple example. If you have a DMZ with a public /24 > address and you want to share that DMZ (one pair of firewalls to the > Internet) with multiple different classes of applications that you want > to keep isolated from each other. Within each class the computers can > communicate with each other and out to the Internet, but computers that > are of different classes cannot communicate with one another. >=20 > -- aldrin >=20 >=20 > On May 7, 2012, at 5:29 PM, Linda Dunbar wrote: >=20 > > Adrin, > > > > You mentioned that " private vlan and community vlans which are very > common for DMZs in Data Center". > > > > I can totally understand why "private vlan" being used. But what > scenario will you need "community vlans" but can't be simply achieved > by traditional VLANs? > > > > Thanks, Linda > > > > > >> -----Original Message----- > >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > Behalf > >> Of Aldrin Isaac > >> Sent: Friday, May 04, 2012 7:20 PM > >> To: Lucy yong > >> Cc: l2vpn@ietf.org; sajassi > >> Subject: Re: Interest in IS-IS VPLS > >> > >> Hi Lucy, > >> > >> Please see inline > >> > >> On May 4, 2012, at 11:07 AM, Lucy yong wrote: > >> > >>> Hi Isaac, > >>> > >>> Thank you for the reply. Please see inline. > >>> > >>> Regards, > >>> Lucy > >>> > >>> -----Original Message----- > >>> From: Aldrin Isaac [mailto:aldrin.isaac@gmail.com] > >>> Sent: Thursday, May 03, 2012 10:50 PM > >>> To: Lucy yong > >>> Cc: sajassi; Giles Heron; Nabil Bitar; l2vpn@ietf.org > >>> Subject: Re: Interest in IS-IS VPLS > >>> > >> > >> ... > >> > >>> E-VPN also supports policy based-topologies versus simple point-to- > >> point, flat or tree VLANs. It can support point-to-point, tree, > mesh, > >> one-way, or pretty much any other "complex" or overlapped topologies > >> (depending on how you like to see it). An example is ability to > >> natively recreate private vlan, community vlan topologies (which > happen > >> to be quite common in DC networks) and any number of combinations of > >> these simultaneously to a single port. A BGP E-VPN VPN is also > >> decoupled from the edge EVI/ESI such that it is not limited to a > single > >> tenant/vlan but can span tenants/vlans (l2 extranet) if so required. > >> This is native to E-VPN. > >>> [[LY]] Such policy based-topologies are useful for service provider > >> network, but may too complex for intra DCs. One reason that > customers > >> often want to choose with L2VPN service is "it is simple". However, > >> L3VPN have its applications although some operators often complain > the > >> complexities to configure these policies. Typical example is the a > >> firewall only placed at a location. Could you share why operator > want > >> such policy based-topology for L2VPN? > >> > >> Policy-based topologies are generally complex when used to > interconnect > >> IP networks because there are generally multiple prefixes in a vrf, > and > >> often different prefixes need to be associated to different VPNs or > >> routing behavior. In the DC, L2VPN role is to interconnect host > ports > >> so the policies for basic are very simple --- list of import route > >> targets and list of export route targets where each import/export > pair > >> correspond to a VPN (tenant, service, ...). An example of how a DC > >> operator might use this for example is to meet a requirement for > >> private vlan and community vlans which are very common for DMZs. > >> Hopefully you are familiar with these very common use cases. It is > >> even possible to recreate more complex switch "features" like MVR > (in > >> addition to private VLANs which are also considered "features") > using > >> E-VPN. It took me three years to get the MVR feature into a > particular > >> vendor's switch to meet a business need. I'll sacrifice plug-and- > play > >> simplicity for business agility. I'm sure my peers are with me on > this > >> one. > >> > >> If simple "plug-and-play" is important, one could imagine RRs > sending > >> out an "RR TLV" such that RRs in an IGP area auto-connect with each > >> other and RR-clients connect to the closest RR based on SPF (some > >> details like peer-group, etc would need to be factored in to make it > >> more powerful). Other BGP/MPLS configuration is, IMHO, trivial > unless > >> you CHOOSE to use more advanced capabilities (i.e. not locked in). > >> > >> Maybe the reason why MPLS comes across as complex is because of how > >> IETF deals with requirements lately by creating point solutions. E- > VPN > >> tries to put new capabilities on the table while trying not to take > >> existing value off the table. There is no reason why a solution > can't > >> bring more value than what the standards body calls for. > >> > >>> E-VPN supports interconnecting end-stations or interconnecting L2 > >> networks. Procedures to easily span STP based networks across an E- > VPN > >> network without loops comes with the base spec. Extensions to E-VPN, > >> such as PBB-EVPN, simplify the fully functional spanning of non-EVPN > >> networks across an E-VPN network. > >>> [[LY]] current L2VPN support all these except active-active mode > >> which causes the loop. > >> > >> Base E-VPN spec will natively deal with the STP case through an > >> active/standby mode and BPDU-snooping -- detect root bridge and use > >> that as ESI (ethernet segment id) to indicate unique STP network > with > >> active/standby bit set to ensure only one forwarding link among > links > >> with same ESI. Tags (vlans) can potentially each have a different > >> active link within the member links of an ESI allowing for automatic > >> tag(tenant)/vlan level load-balancing into an STP network. Edge > >> networks that don't have mac-move issue will be able to take full > >> advantage of active-active load-balancing without need for LAG/MLAG. > >> > >>> An SVI/IRB interface can also be a member of both an E-VPN EVI and > an > >> IP VRF allowing for easily bringing together virtual L2 and L3 > >> topologies anywhere in the network without a physical port. > >>> [[LY]] Could you please share how operator plan to use this? Which > >> service will you sell to customer in this case? > >> > >> The service will be where a customer wants to communicate to a > >> destination network that is not in his subnet. Operators most > >> interested in EVPN already have IPVPN services on their network. > This > >> is the gateway point between the EVPN virtual networks and [existing] > >> IPVPN virtual networks. No physical port required. > >> > >>> E-VPN builds on top of years of work in the IETF; traffic > engineering, > >> scaling with route reflectors and RT constrain, multicast via NG- > MVPN, > >> etc. > >>> [[LY]] Agree. These are useful features for service provider > network. > >> However, these functions may not necessary within DC although they > had > >> been proved works well. > >> > >> I'm not sure how eventually re-inventing these capabilities (yes it > >> will happen) on behalf of a new protocol will be better than simply > >> leveraging proven technology. Vendors don't need to implement every > >> MPLS RFC ever written to be able to implement the basic E-VPN. > >> > >>> Can also use IP for transport tunnel. But my understanding is that > >> popular merchant silicon has support for MPLS push/pop/swap these > days > >> (?). This was captured by EVPN at it's inception, which is why the > PE > >> is referred to as MES (MPLS-enabled switch) in E-VPN. > >>> [[LY]] Yes, current draft aims on MPLS solution only. But it states > >> the potential to extend to the use of IP tunnel. > >>> The way I see it, a major reason why STP-based LANS are fickle and > >> don't scale well is on account of insufficient decoupling of core > from > >> edge created by requirement for plug-and-play and how that played > out > >> over time. Conversely the reason (among other things) why IP > networks > >> are more stable is because they are not inherently plug-and-play, > and > >> with MPLS/BGP allows excellent decoupling of core and edge. I don't > >> know enough about TRILL or PBB to comment on those -- I just know > that > >> I'm not interested for enough good reasons. E-VPN enables a dynamic > >> edge over a stable decoupled core while giving each operator room > for > >> service differentiation. It is especially interesting to operators > >> that have invested in MPLS technology and operations. I can find a > lot > >> of folks that understand BGP/MPLS IPVPN and in short order have them > >> know the ins and outs of basic E-VPN. It's quite hard for me to > find > >> non-vendor folk who really actually understand the other > technologies > >> used to span Ethernet aside from basic STP. > >> > >>> [[LY]] Thank you to share this in the mailing list. > >>> > >>> This is an operator perspective. > >>> [[LY]] This is great! > >>> > >>> > >>> On May 3, 2012, at 4:31 PM, Lucy yong wrote: > >>> > >>>> Hi Ali, > >>>> > >>>> > >>>> "5. Ethernet VPN (E-VPN) - An enhanced Layer-2 service that > >>>> emulates an Ethernet (V)LAN across a PSN. E-VPN supports > >>>> load-sharing across multiple connections from a Layer-2 site > >>>> to an L2VPN service. E-VPN is primarily targeted to support > >>>> large-scale L2VPNs with resiliency requirements not satisfied > >>>> by other L2VPN solutions" > >>>> > >>>> [[LY]] IMO, E-VPN enhancement is to support multi-homing with > >> active-active mode. Load-sharing across multiple connections from a > >> layer-2 site is desired when this mode is used. Current VPLS can > >> provide resiliency requirement when the multi-homing site configured > >> with active-standby mode. > >>>> > >>>> Regards, > >>>> Lucy > >>>> > >>>> Cheers, > >>>> Ali > >>>> > >>> > > From lucy.yong@huawei.com Tue May 8 08:24: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 E710711E808E for ; Tue, 8 May 2012 08:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.358 X-Spam-Level: X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cyBm1m3GrBwJ for ; Tue, 8 May 2012 08:23:59 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id BB1AA11E8087 for ; Tue, 8 May 2012 08:23:58 -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 AFP93027; Tue, 08 May 2012 11:23:58 -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; Tue, 8 May 2012 08:22:12 -0700 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Tue, 8 May 2012 08:22:12 -0700 From: Lucy yong To: "Bitar, Nabil N" , "l2vpn@ietf.org" Subject: =?iso-8859-1?Q?RE:_[l2vpn]_WG_Poll_for_adopting_the_draft_=B3A_Framework_?= =?iso-8859-1?Q?for_E-Tree_Service_over_MPLS_Network=B2_as_a_WG_document?= Thread-Topic: =?iso-8859-1?Q?[l2vpn]_WG_Poll_for_adopting_the_draft_=B3A_Framework_for_?= =?iso-8859-1?Q?E-Tree_Service_over_MPLS_Network=B2_as_a_WG_document?= Thread-Index: Acy7/US3MCOFeoXnR9q2KWn+2fX2gxxMQ7jQ Date: Tue, 8 May 2012 15:22:12 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D33105492@dfweml506-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.152.253] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D33105492dfweml506mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Giles Heron 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, 08 May 2012 15:24:00 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D33105492dfweml506mbx_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Support! From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of B= itar, Nabil N Sent: Friday, December 16, 2011 8:16 AM To: l2vpn@ietf.org Cc: Giles Heron Subject: [l2vpn] WG Poll for adopting the draft =B3A Framework for E-Tree S= ervice over MPLS Network=B2 as a WG document Hi, This is the start of a three-week working group poll for adopting the draft= "A Framework for E-Tree Service over MPLS Network" as an L2VPN WG document= . The draft can be found at http://tools.ietf.org/html/draft-key-l2vpn-etree-= frwk-06 . Please, review the draft and send any comments to the L2VPN working group e= mail list. This WG poll will close on Friday January 6, 2012. Regards, Nabil --_000_2691CE0099834E4A9C5044EEC662BB9D33105492dfweml506mbx_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Support!

 <= /p>

From: l2vpn-bo= unces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Bitar, Nabil N
Sent: Friday, December 16, 2011 8:16 AM
To: l2vpn@ietf.org
Cc: Giles Heron
Subject: [l2vpn] WG Poll for adopting the draft =B3A Framework for E= -Tree Service over MPLS Network=B2 as a WG document

 

Hi,

 

This is the start of a three-week working group poll for adopting = the draft “A Framework for E-Tree Service over MPLS Network” as= an L2VPN WG document. 

 

The draft can be found at http://tools.ietf.org/html/draft-key-l2vp= n-etree-frwk-06 .
 
Please, review the draft and send any comm= ents to the L2VPN working group email list. 

This WG poll will close on Friday January = 6, 2012.
 
Regards,
Nabil 

--_000_2691CE0099834E4A9C5044EEC662BB9D33105492dfweml506mbx_-- From lucy.yong@huawei.com Tue May 8 08:30: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 2C0D021F84EF for ; Tue, 8 May 2012 08:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.357 X-Spam-Level: X-Spam-Status: No, score=-2.357 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6L18YF68y8Zu for ; Tue, 8 May 2012 08:30:21 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id DC31221F84F3 for ; Tue, 8 May 2012 08:30:20 -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 AFX91156; Tue, 08 May 2012 11:30:19 -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; Tue, 8 May 2012 08:28:54 -0700 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.003; Tue, 8 May 2012 08:28:46 -0700 From: Lucy yong To: Lucy yong , "Bitar, Nabil N" , "l2vpn@ietf.org" Subject: =?iso-8859-1?Q?RE:_[l2vpn]_WG_Poll_for_adopting_the_draft_=B3A_Framework_?= =?iso-8859-1?Q?for_E-Tree_Service_over_MPLS_Network=B2_as_a_WG_document?= Thread-Topic: =?iso-8859-1?Q?[l2vpn]_WG_Poll_for_adopting_the_draft_=B3A_Framework_for_?= =?iso-8859-1?Q?E-Tree_Service_over_MPLS_Network=B2_as_a_WG_document?= Thread-Index: Acy7/US3MCOFeoXnR9q2KWn+2fX2gxxMQ7jQAAAxj7A= Date: Tue, 8 May 2012 15:28:46 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D331054A0@dfweml506-mbx> References: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.152.253] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D331054A0dfweml506mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Giles Heron 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, 08 May 2012 15:30:22 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D331054A0dfweml506mbx_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ignore this. Something mess up in my e-mail. But I do support this. Lucy From: Lucy yong Sent: Tuesday, May 08, 2012 10:22 AM To: 'Bitar, Nabil N'; l2vpn@ietf.org Cc: Giles Heron Subject: RE: [l2vpn] WG Poll for adopting the draft =B3A Framework for E-Tr= ee Service over MPLS Network=B2 as a WG document Support! From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of B= itar, Nabil N Sent: Friday, December 16, 2011 8:16 AM To: l2vpn@ietf.org Cc: Giles Heron Subject: [l2vpn] WG Poll for adopting the draft =B3A Framework for E-Tree S= ervice over MPLS Network=B2 as a WG document Hi, This is the start of a three-week working group poll for adopting the draft= "A Framework for E-Tree Service over MPLS Network" as an L2VPN WG document= . The draft can be found at http://tools.ietf.org/html/draft-key-l2vpn-etree-= frwk-06 . Please, review the draft and send any comments to the L2VPN working group e= mail list. This WG poll will close on Friday January 6, 2012. Regards, Nabil --_000_2691CE0099834E4A9C5044EEC662BB9D331054A0dfweml506mbx_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Ignore this. Something me= ss up in my e-mail.

 <= /p>

But I do support this.

Lucy

 <= /p>

From: Lucy yon= g
Sent: Tuesday, May 08, 2012 10:22 AM
To: 'Bitar, Nabil N'; l2vpn@ietf.org
Cc: Giles Heron
Subject: RE: [l2vpn] WG Poll for adopting the draft =B3A Framework f= or E-Tree Service over MPLS Network=B2 as a WG document

 

Support!

 <= /p>

From: l2vpn-bo= unces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Bitar, Nabil N
Sent: Friday, December 16, 2011 8:16 AM
To: l2vpn@ietf.org
Cc: Giles Heron
Subject: [l2vpn] WG Poll for adopting the draft =B3A Framework for E= -Tree Service over MPLS Network=B2 as a WG document

 

Hi,

 

This is the start of a three-week working group poll for adopting = the draft “A Framework for E-Tree Service over MPLS Network” as= an L2VPN WG document. 

 

The draft can be found at http://tools.ietf.org/html/draft-key-l2vp= n-etree-frwk-06 .
 
Please, review the draft and send any comm= ents to the L2VPN working group email list. 

This WG poll will close on Friday January = 6, 2012.
 
Regards,
Nabil 

--_000_2691CE0099834E4A9C5044EEC662BB9D331054A0dfweml506mbx_-- From giles.heron@gmail.com Tue May 8 12:05: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 9CDB721F859E for ; Tue, 8 May 2012 12:05:15 -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 NE-6B0YOjTdc for ; Tue, 8 May 2012 12:05:15 -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 C0F4B21F85AC for ; Tue, 8 May 2012 12:05:14 -0700 (PDT) Received: by werf13 with SMTP id f13so3763252wer.31 for ; Tue, 08 May 2012 12:05:14 -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=Mtf1wJ3zbXXpWxXMutSwmPMHEB3+BfIum+xaURznYIU=; b=jxdkrWBi6c3c59wgbkz+EM4L/iFzGltYX0kX0vq9JKxFqbzxYtaujFlJ5o8EsF/+YM UPicVX0Re7wRSAM9fay9yEdlY6//rXEiCAr/ON9lS2Ub1SkDUvUwGDr3h/NnFPGJlgRx iWxL1ww5QUkV7yyHFElEtMMEgCTa4odD5jxfOFU02TOb+VwygR41qDEfJo7NLs2fNTMC NZveHVzWTIxOgfZHrxdTPnbZ94+M88TnsNYyl36PvZ5Eag6XJ0EXlEczcm4NZyDFma56 RR/hjtckt+pntWkp1PAmxThJ5be7d4WeerdZroRoIYj6/lat3/KyFTRAKzA+Q29iXa1/ 1ldg== Received: by 10.216.134.145 with SMTP id s17mr4740525wei.22.1336503912945; Tue, 08 May 2012 12:05:12 -0700 (PDT) Received: from [10.55.85.88] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id f19sm528518wiw.11.2012.05.08.12.05.11 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 May 2012 12:05:12 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Tue, 08 May 2012 20:05:31 +0100 Subject: Static VPLS MAC withdrawal draft From: Giles Heron To: Message-ID: Thread-Topic: Static VPLS MAC withdrawal draft Thread-Index: Ac0tTYm5TIv9pECE0EWc8IlBO2eaCQ== 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: Tue, 08 May 2012 19:05:15 -0000 Hi everyone, The following draft was presented at IETF in Paris: http://tools.ietf.org/html/draft-boutros-l2vpn-mpls-tp-mac-wd-00 The authors have asked for it to be adopted as a WG draft, but at this stage the chairs' view is that it probably hasn't had enough sets of eyes on it. So this email is to request that those on the list take a read of the draft and send comments back to the list. Depending on the response we get we may then ask the WG if they feel happy adopting this as a WG draft. Nabil and Giles From aldrin.isaac@gmail.com Tue May 8 18:26: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 C232011E8074 for ; Tue, 8 May 2012 18:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.074 X-Spam-Level: X-Spam-Status: No, score=-3.074 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id roaU6bezGhB4 for ; Tue, 8 May 2012 18:26:58 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id A52CA9E800E for ; Tue, 8 May 2012 18:26:57 -0700 (PDT) Received: by qcsq13 with SMTP id q13so2423671qcs.31 for ; Tue, 08 May 2012 18:26:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=61H1MdSRrT6pFOcuXv2oBgaPF9SlEhjZMRVeXbsqZyg=; b=caJcm9My1/pJQ+dmR7JmRmN+ll1Jybn1DeZgTrSBsBsV0emgeoZOlor2LwO+or9NWm JlaX6NyM4SZe+sOdnnZ4hZNo7DuOXfNMz6rZUSl3iGXnhy3OBEkXQiWqm9Z3kOfFy4eO f0UfnP5KDLOUzta5eSwdEwQnGi50TT2jA3hKn9d5x+FGA+vO9iufcW7o0oNgJAMwUdRq +qBzAL5pGvXUs+jZ8ynQePL5DHmEzvUmh1sbGPw/ZiRgSOUMYGwBky8WeZseBhci7dcJ PXJg58vUy3XNshJTotykY7tAHQJ2QKC6s8+3TE9uZ8l+P7Gmsrb9sM2QxS0kiD2mE4lM Br7A== Received: by 10.229.8.7 with SMTP id f7mr10437177qcf.73.1336526817074; Tue, 08 May 2012 18:26:57 -0700 (PDT) Received: from mymac.home (ool-435396f4.dyn.optonline.net. [67.83.150.244]) by mx.google.com with ESMTPS id hs1sm7125413qab.21.2012.05.08.18.26.54 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 May 2012 18:26:55 -0700 (PDT) Subject: Re: Interest in IS-IS VPLS Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_40994609-D897-427C-A2E6-139B295F0B8B" From: Aldrin Isaac In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F63392BC4F@dfweml506-mbx> Date: Tue, 8 May 2012 21:26:53 -0400 Message-Id: <28DB68DC-32D3-43E5-A716-F4639EDAC133@gmail.com> References: <2691CE0099834E4A9C5044EEC662BB9D330E8F11@dfweml505-mbx> <2E819CEF-4A49-439B-86DF-C17503A75398@gmail.com> <2691CE0099834E4A9C5044EEC662BB9D330E918C@dfweml505-mbx> <03B0FD5F-D9F5-4C4E-A7FD-0A2C36A7B092@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F633918DFE@dfweml505-mbx> <4A95BA014132FF49AE685FAB4B9F17F63392BC4F@dfweml506-mbx> To: Linda Dunbar X-Mailer: Apple Mail (2.1257) Cc: "l2vpn@ietf.org" , sajassi 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, 09 May 2012 01:26:59 -0000 --Apple-Mail=_40994609-D897-427C-A2E6-139B295F0B8B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Linda, in my rush I didn't explain it properly. A better explanation = can be found here http://en.wikipedia.org/wiki/Private_VLAN. Best -- = aldrin On May 8, 2012, at 10:54 AM, Linda Dunbar wrote: > Isaac,=20 >=20 > I thought that is why "Private VLAN" is introduced.=20 > You can put the pair of firewalls in "private VLAN" and create a group = of regular VLANs (with each VLAN mapped to /xx, and xx >24).=20 > This group of VLANs can access the "private VLAN". Is it correct? >=20 > Thanks for the example. >=20 > Linda >=20 >> -----Original Message----- >> From: Aldrin Isaac [mailto:aldrin.isaac@gmail.com] >> Sent: Monday, May 07, 2012 11:05 PM >> To: Linda Dunbar >> Cc: Lucy yong; l2vpn@ietf.org; sajassi >> Subject: Re: Interest in IS-IS VPLS >>=20 >> Linda, >>=20 >> Let me give a simple example. If you have a DMZ with a public /24 >> address and you want to share that DMZ (one pair of firewalls to the >> Internet) with multiple different classes of applications that you = want >> to keep isolated from each other. Within each class the computers = can >> communicate with each other and out to the Internet, but computers = that >> are of different classes cannot communicate with one another. >>=20 >> -- aldrin >>=20 >>=20 >> On May 7, 2012, at 5:29 PM, Linda Dunbar wrote: >>=20 >>> Adrin, >>>=20 >>> You mentioned that " private vlan and community vlans which are very >> common for DMZs in Data Center". >>>=20 >>> I can totally understand why "private vlan" being used. But what >> scenario will you need "community vlans" but can't be simply achieved >> by traditional VLANs? >>>=20 >>> Thanks, Linda >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >> Behalf >>>> Of Aldrin Isaac >>>> Sent: Friday, May 04, 2012 7:20 PM >>>> To: Lucy yong >>>> Cc: l2vpn@ietf.org; sajassi >>>> Subject: Re: Interest in IS-IS VPLS >>>>=20 >>>> Hi Lucy, >>>>=20 >>>> Please see inline >>>>=20 >>>> On May 4, 2012, at 11:07 AM, Lucy yong wrote: >>>>=20 >>>>> Hi Isaac, >>>>>=20 >>>>> Thank you for the reply. Please see inline. >>>>>=20 >>>>> Regards, >>>>> Lucy >>>>>=20 >>>>> -----Original Message----- >>>>> From: Aldrin Isaac [mailto:aldrin.isaac@gmail.com] >>>>> Sent: Thursday, May 03, 2012 10:50 PM >>>>> To: Lucy yong >>>>> Cc: sajassi; Giles Heron; Nabil Bitar; l2vpn@ietf.org >>>>> Subject: Re: Interest in IS-IS VPLS >>>>>=20 >>>>=20 >>>> ... >>>>=20 >>>>> E-VPN also supports policy based-topologies versus simple = point-to- >>>> point, flat or tree VLANs. It can support point-to-point, tree, >> mesh, >>>> one-way, or pretty much any other "complex" or overlapped = topologies >>>> (depending on how you like to see it). An example is ability to >>>> natively recreate private vlan, community vlan topologies (which >> happen >>>> to be quite common in DC networks) and any number of combinations = of >>>> these simultaneously to a single port. A BGP E-VPN VPN is also >>>> decoupled from the edge EVI/ESI such that it is not limited to a >> single >>>> tenant/vlan but can span tenants/vlans (l2 extranet) if so = required. >>>> This is native to E-VPN. >>>>> [[LY]] Such policy based-topologies are useful for service = provider >>>> network, but may too complex for intra DCs. One reason that >> customers >>>> often want to choose with L2VPN service is "it is simple". However, >>>> L3VPN have its applications although some operators often complain >> the >>>> complexities to configure these policies. Typical example is the a >>>> firewall only placed at a location. Could you share why operator >> want >>>> such policy based-topology for L2VPN? >>>>=20 >>>> Policy-based topologies are generally complex when used to >> interconnect >>>> IP networks because there are generally multiple prefixes in a vrf, >> and >>>> often different prefixes need to be associated to different VPNs or >>>> routing behavior. In the DC, L2VPN role is to interconnect host >> ports >>>> so the policies for basic are very simple --- list of import route >>>> targets and list of export route targets where each import/export >> pair >>>> correspond to a VPN (tenant, service, ...). An example of how a DC >>>> operator might use this for example is to meet a requirement for >>>> private vlan and community vlans which are very common for DMZs. >>>> Hopefully you are familiar with these very common use cases. It is >>>> even possible to recreate more complex switch "features" like MVR >> (in >>>> addition to private VLANs which are also considered "features") >> using >>>> E-VPN. It took me three years to get the MVR feature into a >> particular >>>> vendor's switch to meet a business need. I'll sacrifice plug-and- >> play >>>> simplicity for business agility. I'm sure my peers are with me on >> this >>>> one. >>>>=20 >>>> If simple "plug-and-play" is important, one could imagine RRs >> sending >>>> out an "RR TLV" such that RRs in an IGP area auto-connect with each >>>> other and RR-clients connect to the closest RR based on SPF (some >>>> details like peer-group, etc would need to be factored in to make = it >>>> more powerful). Other BGP/MPLS configuration is, IMHO, trivial >> unless >>>> you CHOOSE to use more advanced capabilities (i.e. not locked in). >>>>=20 >>>> Maybe the reason why MPLS comes across as complex is because of how >>>> IETF deals with requirements lately by creating point solutions. = E- >> VPN >>>> tries to put new capabilities on the table while trying not to take >>>> existing value off the table. There is no reason why a solution >> can't >>>> bring more value than what the standards body calls for. >>>>=20 >>>>> E-VPN supports interconnecting end-stations or interconnecting L2 >>>> networks. Procedures to easily span STP based networks across an = E- >> VPN >>>> network without loops comes with the base spec. Extensions to = E-VPN, >>>> such as PBB-EVPN, simplify the fully functional spanning of = non-EVPN >>>> networks across an E-VPN network. >>>>> [[LY]] current L2VPN support all these except active-active mode >>>> which causes the loop. >>>>=20 >>>> Base E-VPN spec will natively deal with the STP case through an >>>> active/standby mode and BPDU-snooping -- detect root bridge and use >>>> that as ESI (ethernet segment id) to indicate unique STP network >> with >>>> active/standby bit set to ensure only one forwarding link among >> links >>>> with same ESI. Tags (vlans) can potentially each have a different >>>> active link within the member links of an ESI allowing for = automatic >>>> tag(tenant)/vlan level load-balancing into an STP network. Edge >>>> networks that don't have mac-move issue will be able to take full >>>> advantage of active-active load-balancing without need for = LAG/MLAG. >>>>=20 >>>>> An SVI/IRB interface can also be a member of both an E-VPN EVI and >> an >>>> IP VRF allowing for easily bringing together virtual L2 and L3 >>>> topologies anywhere in the network without a physical port. >>>>> [[LY]] Could you please share how operator plan to use this? Which >>>> service will you sell to customer in this case? >>>>=20 >>>> The service will be where a customer wants to communicate to a >>>> destination network that is not in his subnet. Operators most >>>> interested in EVPN already have IPVPN services on their network. >> This >>>> is the gateway point between the EVPN virtual networks and = [existing] >>>> IPVPN virtual networks. No physical port required. >>>>=20 >>>>> E-VPN builds on top of years of work in the IETF; traffic >> engineering, >>>> scaling with route reflectors and RT constrain, multicast via NG- >> MVPN, >>>> etc. >>>>> [[LY]] Agree. These are useful features for service provider >> network. >>>> However, these functions may not necessary within DC although they >> had >>>> been proved works well. >>>>=20 >>>> I'm not sure how eventually re-inventing these capabilities (yes it >>>> will happen) on behalf of a new protocol will be better than simply >>>> leveraging proven technology. Vendors don't need to implement = every >>>> MPLS RFC ever written to be able to implement the basic E-VPN. >>>>=20 >>>>> Can also use IP for transport tunnel. But my understanding is = that >>>> popular merchant silicon has support for MPLS push/pop/swap these >> days >>>> (?). This was captured by EVPN at it's inception, which is why the >> PE >>>> is referred to as MES (MPLS-enabled switch) in E-VPN. >>>>> [[LY]] Yes, current draft aims on MPLS solution only. But it = states >>>> the potential to extend to the use of IP tunnel. >>>>> The way I see it, a major reason why STP-based LANS are fickle and >>>> don't scale well is on account of insufficient decoupling of core >> from >>>> edge created by requirement for plug-and-play and how that played >> out >>>> over time. Conversely the reason (among other things) why IP >> networks >>>> are more stable is because they are not inherently plug-and-play, >> and >>>> with MPLS/BGP allows excellent decoupling of core and edge. I = don't >>>> know enough about TRILL or PBB to comment on those -- I just know >> that >>>> I'm not interested for enough good reasons. E-VPN enables a = dynamic >>>> edge over a stable decoupled core while giving each operator room >> for >>>> service differentiation. It is especially interesting to operators >>>> that have invested in MPLS technology and operations. I can find a >> lot >>>> of folks that understand BGP/MPLS IPVPN and in short order have = them >>>> know the ins and outs of basic E-VPN. It's quite hard for me to >> find >>>> non-vendor folk who really actually understand the other >> technologies >>>> used to span Ethernet aside from basic STP. >>>>=20 >>>>> [[LY]] Thank you to share this in the mailing list. >>>>>=20 >>>>> This is an operator perspective. >>>>> [[LY]] This is great! >>>>>=20 >>>>>=20 >>>>> On May 3, 2012, at 4:31 PM, Lucy yong wrote: >>>>>=20 >>>>>> Hi Ali, >>>>>>=20 >>>>>>=20 >>>>>> "5. Ethernet VPN (E-VPN) - An enhanced Layer-2 service that >>>>>> emulates an Ethernet (V)LAN across a PSN. E-VPN supports >>>>>> load-sharing across multiple connections from a Layer-2 site >>>>>> to an L2VPN service. E-VPN is primarily targeted to support >>>>>> large-scale L2VPNs with resiliency requirements not satisfied >>>>>> by other L2VPN solutions" >>>>>>=20 >>>>>> [[LY]] IMO, E-VPN enhancement is to support multi-homing with >>>> active-active mode. Load-sharing across multiple connections from a >>>> layer-2 site is desired when this mode is used. Current VPLS can >>>> provide resiliency requirement when the multi-homing site = configured >>>> with active-standby mode. >>>>>>=20 >>>>>> Regards, >>>>>> Lucy >>>>>>=20 >>>>>> Cheers, >>>>>> Ali >>>>>>=20 >>>>>=20 >>>=20 >=20 --Apple-Mail=_40994609-D897-427C-A2E6-139B295F0B8B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Linda, in my rush I didn't explain it properly.  A better = explanation can be found here http://en.wikipedia.org= /wiki/Private_VLAN.  Best -- = aldrin


On May 8, 2012, at = 10:54 AM, Linda Dunbar wrote:

Isaac, =

I thought that is why "Private VLAN" is introduced.
You can = put the pair of firewalls in "private VLAN" and create a group of = regular VLANs (with each VLAN mapped to /xx, and  xx >24). =
This group of VLANs can access the "private VLAN". Is it = correct?

Thanks for the example.

Linda

-----Original Message-----
From: Aldrin Isaac = [mailto:aldrin.isaac@gmail.com]
Sent: Monday, May 07, 2012 11:05 = PM
To: Linda = Dunbar
Cc: Lucy yong; l2vpn@ietf.org; = sajassi
Subject: Re: Interest = in IS-IS VPLS

Linda,

Let me give a = simple example.  If you have a DMZ with a public = /24
address and you want to = share that DMZ (one pair of firewalls to the
Internet) with multiple different classes of applications = that you want
to keep isolated = from each other.  Within each class the computers = can
communicate with each = other and out to the Internet, but computers = that
are of different classes = cannot communicate with one another.

-- = aldrin


On May 7, 2012, = at 5:29 PM, Linda Dunbar wrote:

Adrin,

You mentioned that " private = vlan and community vlans which are = very
common for = DMZs in Data Center".

I can totally understand why = "private vlan" being used. But = what
scenario = will you need "community vlans" but can't be simply = achieved
by traditional = VLANs?

Thanks, = Linda


-----Original = Message-----
From: = l2vpn-bounces@ietf.org = [mailto:l2vpn-bounces@ietf.org] = On
Behalf
Of Aldrin = Isaac
Sent: = Friday, May 04, 2012 7:20 = PM
To: = Lucy yong
Cc: l2vpn@ietf.org; = sajassi
Subject:= Re: Interest in IS-IS = VPLS

Hi = Lucy,

Please = see inline

On May = 4, 2012, at 11:07 AM, Lucy yong = wrote:

Hi = Isaac,

Thank you for the reply. Please = see = inline.

Regards,
Lucy
=

-----Original = Message-----
From: Aldrin Isaac = [mailto:aldrin.isaac@gmail.com]
=
Sent: = Thursday, May 03, 2012 10:50 = PM
To: Lucy = yong
Cc: sajassi; Giles Heron; Nabil = Bitar; l2vpn@ietf.org
Subject:= Re: Interest in IS-IS = VPLS


...

E-VPN also supports policy = based-topologies versus simple = point-to-
point, flat or tree VLANs.  It can support = point-to-point, = tree,
mesh,
one-way, or pretty much any = other "complex" or overlapped = topologies
(depending on how you like to see it).  An example is = ability to
natively= recreate private vlan, community vlan topologies = (which
happen
to be quite common in DC = networks) and any number of combinations = of
these = simultaneously to a single port.  A BGP E-VPN VPN is = also
decoupled from the edge EVI/ESI such that it is not = limited to a
single
tenant/vlan but can span = tenants/vlans (l2 extranet) if so = required.
This = is native to = E-VPN.
[[LY]] Such policy = based-topologies are useful for service = provider
network, but may too complex for intra DCs. One reason = that
customers
often = want to choose with L2VPN service is "it is simple". = However,
L3VPN = have its applications although some operators often = complain
the
complexities to configure these = policies. Typical example is the = a
firewall= only placed at a location. Could you share why = operator
want
such policy based-topology for = L2VPN?

Policy-based topologies are generally complex when used = to
interconnect
IP = networks because there are generally multiple prefixes in a = vrf,
and
often different prefixes need to = be associated to different VPNs = or
routing = behavior.  In the DC, L2VPN role is to interconnect = host
ports
so the policies for basic are = very simple --- list of import = route
targets = and list of export route targets where each = import/export
pair
correspond to a VPN (tenant, = service, ...).  An example of how a = DC
operator= might use this for example is to meet a requirement = for
private = vlan and community vlans which are very common for = DMZs.
Hopefully you are familiar with these very common use = cases.  It is
even = possible to recreate more complex switch "features" like = MVR
(in
addition to private VLANs which = are also considered = "features")
using
E-VPN.  It took me three = years to get the MVR feature into = a
particular
vendor's= switch to meet a business need.  I'll sacrifice = plug-and-
play
simplicity for business agility. =  I'm sure my peers are with me = on
this
one.

If = simple "plug-and-play" is important, one could imagine = RRs
sending
out an = "RR TLV" such that RRs in an IGP area auto-connect with = each
other = and RR-clients connect to the closest RR based on SPF = (some
details = like peer-group, etc would need to be factored in to make = it
more = powerful).  Other BGP/MPLS configuration is, IMHO, = trivial
unless
you CHOOSE to use more advanced = capabilities (i.e. not locked = in).

Maybe = the reason why MPLS comes across as complex is because of = how
IETF = deals with requirements lately by creating point solutions. =  E-
VPN
tries to put new capabilities on = the table while trying not to = take
existing= value off the table.  There is no reason why a = solution
can't
bring more value than what the = standards body calls = for.

E-VPN supports interconnecting = end-stations or interconnecting = L2
networks.  Procedures to easily span STP based = networks across an = E-
VPN
network without loops comes with = the base spec.  Extensions to = E-VPN,
such = as PBB-EVPN, simplify the fully functional spanning of = non-EVPN
networks= across an E-VPN = network.
[[LY]] current L2VPN support all = these except active-active = mode
which = causes the loop.

Base = E-VPN spec will natively deal with the STP case through = an
active/standby mode and BPDU-snooping -- detect root = bridge and use
that = as ESI (ethernet segment id) to indicate unique STP = network
with
active/standby bit set to ensure = only one forwarding link = among
links
with same ESI.  Tags = (vlans) can potentially each have a = different
active = link within the member links of an ESI allowing for = automatic
tag(tenant)/vlan level load-balancing into an STP network. =  Edge
networks= that don't have mac-move issue will be able to take = full
advantage of active-active load-balancing without need for = LAG/MLAG.

An SVI/IRB interface can also be = a member of both an E-VPN EVI = and
an
IP VRF allowing for easily = bringing together virtual L2 and = L3
topologies anywhere in the network without a physical = port.
[[LY]] Could you please share = how operator plan to use this? = Which
service = will you sell to customer in this = case?

The = service will be where a customer wants to communicate to = a
destination network that is not in his subnet. =  Operators = most
interested in EVPN already have IPVPN services on their = network.
This
is the gateway point between the = EVPN virtual networks and = [existing]
IPVPN = virtual networks.  No physical port = required.

E-VPN builds on top of years of = work in the IETF; = traffic
engineering,
scaling = with route reflectors and RT constrain, multicast via = NG-
MVPN,
etc.
[[LY]] Agree. These are useful = features for service = provider
network.
However,= these functions may not necessary within DC although = they
had
been proved works = well.

I'm = not sure how eventually re-inventing these capabilities (yes = it
will = happen) on behalf of a new protocol will be better than = simply
leveraging proven technology.  Vendors don't need to = implement every
MPLS = RFC ever written to be able to implement the basic = E-VPN.

Can also use IP for transport = tunnel.  But my understanding is = that
popular = merchant silicon has support for MPLS push/pop/swap = these
days
(?).  This was captured by = EVPN at it's inception, which is why = the
PE
is referred to as MES = (MPLS-enabled switch) in = E-VPN.
[[LY]] Yes, current draft aims = on MPLS solution only. But it = states
the = potential to extend to the use of IP = tunnel.
The way I see it, a major reason = why STP-based LANS are fickle = and
don't = scale well is on account of insufficient decoupling of = core
from
edge created by requirement for = plug-and-play and how that = played
out
over time.  Conversely the = reason (among other things) why = IP
networks
are = more stable is because they are not inherently = plug-and-play,
and
with MPLS/BGP allows excellent = decoupling of core and edge.  I = don't
know = enough about TRILL or PBB to comment on those -- I just = know
that
I'm not interested for enough = good reasons.  E-VPN enables a = dynamic
edge = over a stable decoupled core while giving each operator = room
for
service differentiation. =  It is especially interesting to = operators
that = have invested in MPLS technology and operations.  I can find = a
lot
of folks that understand = BGP/MPLS IPVPN and in short order have = them
know = the ins and outs of basic E-VPN.  It's quite hard for me = to
find
non-vendor folk who really = actually understand the = other
technologies
used = to span Ethernet aside from basic = STP.

[[LY]] Thank you to share this = in the mailing = list.

This is an operator = perspective.
[[LY]]  This is = great!


On May 3, 2012, at 4:31 PM, Lucy = yong = wrote:

Hi = Ali,
<= blockquote type=3D"cite">


"5. = Ethernet VPN (E-VPN) - An enhanced Layer-2 service = that
<= blockquote type=3D"cite">
emulates= an Ethernet (V)LAN across a PSN. E-VPN = supports
load-sharing across multiple connections from a Layer-2 = site
<= blockquote type=3D"cite">
to an = L2VPN service. E-VPN is primarily targeted to = support
large-scale L2VPNs with resiliency requirements not = satisfied
by = other L2VPN = solutions"

[[LY]] = IMO, E-VPN enhancement is to support multi-homing = with
<= blockquote type=3D"cite">
active-active mode. Load-sharing across multiple = connections from a
layer-2 = site is desired when this mode is used. Current VPLS = can
provide = resiliency requirement when the multi-homing site = configured
with = active-standby = mode.

Regards,
Lucy
=

Cheers,
Ali
<= /blockquote>




<= br>
= --Apple-Mail=_40994609-D897-427C-A2E6-139B295F0B8B-- From yuqun.cao@gmail.com Tue May 8 18:40: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 2546B11E8087 for ; Tue, 8 May 2012 18:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.032 X-Spam-Level: X-Spam-Status: No, score=-3.032 tagged_above=-999 required=5 tests=[AWL=0.567, 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 yDtD71bC7st8 for ; Tue, 8 May 2012 18:40: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 960F411E8080 for ; Tue, 8 May 2012 18:40:04 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so8866677pbc.31 for ; Tue, 08 May 2012 18:40:04 -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=p/gMCEXplvSTqP2rL1+JZWwHkc/1E4x20/T8OlEqeFg=; b=GzjtdO+ulgDqFvF1X7pkwrshiyHY8Oyl/5Vxjt1p6Bu10a/WUAjkOK43QpqNWBxfiB 60lKlb+aIdFbR61pHEK7NvwFrUvVq2MCJ9wfTS0rt5pHFKCZeWTz04dawByWwwwIf7pm P1ox+x0RE9smQOJ8pqGtf9+IHFURFOFDjQvlYKR+0iFd9b8ol5j/jys0V659r2v4ABJ3 eh8rp3gpjpT7IAbSoTkX0FynwYymkZZxO648i25ItEFxWir5Tp15THbO46+DUXqSBuup op5BXBIv/XYRCYiktM8I0jC3Y8L+ZxFfNcmO/QKrh4YnIHDiemdRjue88yO+wVhrH0F2 4a4A== Received: by 10.68.191.74 with SMTP id gw10mr3398025pbc.90.1336527604039; Tue, 08 May 2012 18:40:04 -0700 (PDT) Received: from R01842 ([110.90.119.113]) by mx.google.com with ESMTPS id xe1sm656182pbc.40.2012.05.08.18.39.59 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 May 2012 18:40:02 -0700 (PDT) From: "Sam Cao" To: References: Subject: RE: Discussion on E-Tree and H-VPLS Date: Wed, 9 May 2012 09:40:12 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-reply-to: Thread-index: Ac0runklF6VkjhlbSXuI0yRteo1ydwByMCCg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: lizhong.jin@zte.com.cn 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, 09 May 2012 01:40:06 -0000 Hi Lizhong=A3=AC Thank you very much for your comments. I updated the result on this question. [Lizhong] agree with the above analysis. And we did not say it is a technical problem, but it is an operational problem again. [Sam] I agree. Dual-VLAN does not make sense. I also discussed this with Giles and Yuanlong in another mail, and we reached agreement on this: = MTU should know the access mode, VPWS or VPLS, VPWS mode should configure = VLAN ID on MTU but VPLS mode can not. I thought this is NOT reasonable :), = but we can figure this out in draft. It seems ok. [Lizhong] not fully understand. Do you mean, when VPWS accessing for H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf = PW) for each AC access? [Sam] Yes. Thanks, Sam -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of l2vpn-request@ietf.org Sent: Monday, May 07, 2012 3:00 AM To: l2vpn@ietf.org Subject: L2vpn Digest, Vol 96, 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=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: Discussion on E-Tree and H-VPLS (Lizhong Jin) 2. RE: Discussion on E-Tree and H-VPLS (Lizhong Jin) ---------------------------------------------------------------------- Message: 1 Date: Sun, 6 May 2012 18:22:14 +0800 From: Lizhong Jin To: yuqun.cao@gmail.com Cc: l2vpn@ietf.org, jiangyuanlong@huawei.com Subject: RE: Discussion on E-Tree and H-VPLS Message-ID: = Content-Type: text/plain; charset=3D"iso-8859-1" Hi Sam, See inline below. Thanks Lizhong ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 24 Apr 2012 11:51:26 +0800 > From: "Sam Cao" > To: "'Jiangyuanlong'" > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > Message-ID: > Content-Type: text/plain; charset=3D"GB2312" > > 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. > [Lizhong] agree with the above analysis. And we did not say it is a technical problem, but it is an operational problem again. > > 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. > [Lizhong] not fully understand. Do you mean, when VPWS accessing for H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf = PW) for each AC access? > 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=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 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Sun, 6 May 2012 18:25:59 +0800 From: Lizhong Jin To: yuqun.cao@gmail.com Cc: l2vpn@ietf.org, jiangyuanlong@huawei.com Subject: RE: Discussion on E-Tree and H-VPLS Message-ID: = Content-Type: text/plain; charset=3D"iso-8859-1" > > > ------------------------------ > > Date: Tue, 24 Apr 2012 11:59:33 +0800 > From: "Sam Cao" > To: "'Alexander Vainshtein'" , > "'Jiangyuanlong'" > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > Message-ID: > Content-Type: text/plain; charset=3D"GB2312" > > 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. > [Lizhong] no, the CW approach is OK. The PE-r with VPWS could support = CW, and add leaf/root indication in the packet. Thanks Lizhong > 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, > > ------------------------------ -------------- 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 96, Issue 21 ************************************* From jiangyuanlong@huawei.com Tue May 8 19:29: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 1809011E808A for ; Tue, 8 May 2012 19:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.178, 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 4vcTgckaSueV for ; Tue, 8 May 2012 19:29:23 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 09AA211E8074 for ; Tue, 8 May 2012 19:29: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 AFY28019; Tue, 08 May 2012 22:29: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; Tue, 8 May 2012 19:26:42 -0700 Received: from SZXEML424-HUB.china.huawei.com (10.82.67.163) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 8 May 2012 19:26:46 -0700 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.183]) by szxeml424-hub.china.huawei.com ([10.82.67.163]) with mapi id 14.01.0323.003; Wed, 9 May 2012 10:26:34 +0800 From: Jiangyuanlong To: Daniel Cohn , "Rogers, Josh" , Lucy yong , Sam Cao , "l2vpn@ietf.org" Subject: OAM problem for 2PW Thread-Topic: OAM problem for 2PW Thread-Index: AQHNLYsnhlHlUXoGqke0wqq5OrlD9A== Date: Wed, 9 May 2012 02:26:34 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410E3C@szxeml546-mbx.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D330F0740@dfweml506-mbx> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410ABC@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CA64@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410B5D@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CA6E@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410BFF@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CB27@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410C62@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CB39@tlvmail1> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA08130780CB39@tlvmail1> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.40.73] 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, 09 May 2012 02:29:24 -0000 Daniel, I change the Subject to reflect the discussion. Let me give an example adapted simply from fig.10 of RFC 6136 to show what = is the problem for 2PW, assume both UPEs are mixed with root and leaf, and = we need to monitor the connectivity between L1 (leaf) and R1 (root). --- --- / \ ------ ------- ---- / \ |L1 CE-- / \ / \ / \ --CE R1| \ / \ / \ / \ / \ / \ / --- --UPE NPE NPE UPE-- --- \ / \ / \ / \ / \ / \ / ------ ------- ---- Customer OAM Domain (C) MEP---MIP--------------------------------MIP---MEP SP OAM SP OAM SP OAM (D1) MEP-MIP--MEP|MEP-------MEP|MEP-----MEP domain domain domain Operator Operator Operator (E) MEP-MIP--MEP|MEP-------MEP|MEP-----MEP OAM domain OAM domain OAM domain MPLS OAM MPLS OAM (F) MEP--MIP-----MEP--MIP--MEP domain domain If we find a problem in the Customer OAM domain for (L1-R1), and server lay= er need to be inverstigated further to locate the network problem. In the 2PW approach, we have 2 PWs (root PW and leaf PW) in every Operator = OAM domain and need to associate one (maybe both?) with this customer servi= ce. Just consider a single OAM domain: In the forward direction, the traffic is from leaf to root, it seems the le= af PW needs to be associated with this service. On the other hand, in the reverse direction, the traffic is from root to le= af, it seems the root PW needs to be associated with this service. But how can you configure a pair of MEPs across both root and leaf PWs? (I = believe both root and leaf PW have a pair of MEPs respectively) If multiple MPLS OAM domains are considered, things will become more intere= sting. Further comments are in line. Thanks, Yuanlong -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Tuesday, May 08, 2012 9:59 PM To: Jiangyuanlong; Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 >From the PW maintenance point of view, all PWs are the same. There is no difference in the maintenance operations for root/leaf/normal PW. [JY] it is true for a single PW in a single OAM domain, but when they are c= oupled to provide an end to end E-Tree service, things will be quite differ= ent as shown above. Root/leaf is signaled in LDP so mismatch can be detected and notified to operator. [JY] LDP seems work in a single OAM domain, and mismatch point is inter-OAM= -domain. Moreover, mismatch is supposed to be detected by OAM. Did I miss s= omething? DC -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Tuesday, May 08, 2012 4:38 PM To: Daniel Cohn; Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 Except PW numbers, now PW attributes also needs to be considered: root, leaf or normal. Can the root or leaf PW be connected to the normal PW? Or just connect root to root, and leaf to leaf? Without signalling, this will pose a great challenge to configure the OAM correctly. -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Tuesday, May 08, 2012 9:29 PM To: Jiangyuanlong; Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 Yuanlong, I don't see the additional complexity. Existing PW maintenance processes at the operator can take care of the additional root/leaf PWs exactly like they do today. Only they will have some more PWs to maintain (not twice as much, since most PEs are typically leaf-only and therefore have only a root PW per E-Tree instance) And service maintenance processes should be extended to maintain root and leaf services using E-OAM, both for the 2-VLAN and multi-PW solutions. DC -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Tuesday, May 08, 2012 4:23 PM To: Daniel Cohn; Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 Daniel, RFC 6136 provides the VPLS OAM reqs and framework, and Sec. 10.1. gives the typical VPLS OAM Operational Scenarios: --- --- / \ ------ ------- ---- / \ | A CE-- / \ / \ / \ --CE A | \ / \ / \ / \ / \ / \ / --- --UPE NPE NPE UPE-- --- \ / \ / \ / \ / \ / \ / ------ ------- ---- Customer OAM Domain (C) MEP---MIP--------------------------------MIP---MEP Service Provider (SP) OAM Domain (D) MEP--------MIP-----------MIP-------MEP SP OAM SP OAM SP OAM (D1) MEP-MIP--MEP|MEP-------MEP|MEP-----MEP domain domain domain Operator Operator Operator (E) MEP-MIP--MEP|MEP-------MEP|MEP-----MEP OAM domain OAM domain OAM domain MPLS OAM MPLS OAM (F) MEP--MIP-----MEP--MIP--MEP domain domain Figure 10: VPLS OAM Domains, MEPs, and MIPs It seems OAM configurations in Scenario D1) and E) for 2PW approach will be much complicated and error prone, since E-Tree OAM now needs to interwork with one of these two PWs' OAM (maybe both, I am afraid). For scenario F), the concatanation of two MPLS OAM also needs to be very careful as 4 PWs and 3 types (i.e, root/leaf/normal) may be involved there. Regards, Yuanlong -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Tuesday, May 08, 2012 4:49 PM To: Jiangyuanlong; Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 Inline -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Tuesday, May 08, 2012 11:42 AM To: Daniel Cohn; Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 I don't think so. There may be different layers of OAM applicable to a service. Such as LSP layer, PW layer, and service layer. [DC] Agreed Now you cannot use a single LSP OAM to monitor the server layer of the E-Tree service (as 2 LSP may be involved). And the service layer of OAM for E-Tree may be distributed to different LSP paths. [DC] For E-Tree service OAM, you would perform OAM actions from MEPs associated to root or leaf ACs, so the E-OAM frames would naturally follow the root or leaf pseudowires and the LSPs that transport them. I don't see a limitation here. -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Tuesday, May 08, 2012 4:28 PM To: Jiangyuanlong; Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 Yuanlong, isn't this orthogonal to the issues we are discussing? I mean, there are different mechanisms to troubleshoot PWs, all of which are applicable to root/leaf PWs as to any other PWs. Or is there any specific limitation on root/leaf PW troubleshooting, compared to "regular" PWs used in VPLSs? Thanks, Daniel -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Jiangyuanlong Sent: Tuesday, May 08, 2012 7:04 AM To: Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 Josh,=20 Just some comments on this part: [JR] I don't see this any more of a problem than troubleshooting one. If LDP is used, a simple mols traceroute shows the path that ALL PW's to that PE take, regardless of which service (this VPLS or another VPLS instance). If RSVP is used, there should be a route-object that shows me the path, and allows me to troubleshoot. Additionally, if I wanted to have traffic engineering that impacted root-sourced and leaf-sourced traffic differently, I can do that with multi-PW, where I could not (save for ingress/egress) with the 2VLAN approach. PE should report signaling on second PW same as it does for the 100th PW between PE's. Again, I don't see the problem you are alluding to. I suppose you are referring to LSP Ping on the LSP layer, yes, it can oversee all the PWs in this LSP. If both root and leaf PW are in the same LSP, it can work. But there may well be multiple LSPs between a pair of PEs, and root/leaf PW may be transported on different LSPs. Another difficulty is, if ECMP is deployed and PW label as a bottom label is used for hashing, the OAM message may be load balanced on different paths. With regard to TE, you could use DS-TE, just as Lucy said, two PW do not guarantee they are traffic engineered. Thanks Yuanlong ...snipped.... From yuqun.cao@gmail.com Tue May 8 19:39: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 682B921F8573 for ; Tue, 8 May 2012 19:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.76 X-Spam-Level: X-Spam-Status: No, score=-2.76 tagged_above=-999 required=5 tests=[AWL=0.239, 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 0pbPoKq+p5Vr for ; Tue, 8 May 2012 19:39: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 A375221F856F for ; Tue, 8 May 2012 19:39:13 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so8918211pbc.31 for ; Tue, 08 May 2012 19:39:13 -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=1+SJP4NWaYHDhyc1FGuTWweVC77/vaxhoBBHvNgaV9Q=; b=HUN5kgiRWfzoVZUgnXJ3Aj9KwmA7Lg/tN86kozxcVmnvkMdsBARoWb4a8oKe4tuhRh 33Zrql5DEXvcHJljLERBb+Bz3eiDMcihHP7QsepGKDX03nKFcCJ3taqoqdG1QHTS/KBN 3winJPK0AvtLW8neIApYtVtG7rAZNaW/00XL7QLn7jZ9JLYM8lOFlf7iXAg9srB977Rp srda80mGkTfHd4kU7MFG3C4V9z/ek+SXFOIB0NLv8Ijt5sHEf2mLeS6Y2RaRIr1Wvd4L DZpPYuShm+cpbYd894RslfA4r8p84BLFlZScbYiaqXE1z6AR8figHXB5F+o8GwG7BAHd DiNw== Received: by 10.68.219.162 with SMTP id pp2mr3872363pbc.85.1336531153175; Tue, 08 May 2012 19:39:13 -0700 (PDT) Received: from R01842 ([110.90.119.113]) by mx.google.com with ESMTPS id oj3sm4363715pbb.20.2012.05.08.19.39.03 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 May 2012 19:39:11 -0700 (PDT) From: "Sam Cao" To: References: Subject: RE: L2vpn Digest, Vol 96, Issue 23 Date: Wed, 9 May 2012 10:38:56 +0800 Message-ID: <264B3435378241FA9BE008620B246DEA@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: Ac0sG9fO5wFZkl6yQ82ZnsZQz9D4NABaYsTQ 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, 09 May 2012 02:39:17 -0000 Josh, Optimization on ingress PE is possible. Last week I thought this over and have a clear idea. We maybe discuss this in another mail, and if all agree, we can add this into new draft. As you know, Multi-PW negotiates AC type via signal protocol, so one PE can know AC types of its peer, and then we can solve the problem you raised. Thanks, Sam -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of l2vpn-request@ietf.org Sent: Monday, May 07, 2012 2:37 PM To: l2vpn@ietf.org Subject: L2vpn Digest, Vol 96, Issue 23 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? (Rogers, Josh) 2. RE: The status of the approaches to the E-Tree solution? (Jiangyuanlong) ---------------------------------------------------------------------- Message: 1 Date: Mon, 7 May 2012 00:09:07 -0400 From: "Rogers, Josh" To: Jiangyuanlong , Daniel Cohn , "Fedyk, Donald (Don)" , "Henderickx, Wim (Wim)" , Lucy yong Cc: "l2vpn@ietf.org" Subject: Re: The status of the approaches to the E-Tree solution? Message-ID: Content-Type: text/plain; charset="iso-8859-2" So, if you can imagine three PE's, PE1, PE2 and PE3. PE1 has a root AC, R1 and a leaf AC, L1. PE2 also has a root AC, R2, and a leaf AC, L2. PE3 has a leaf AC, L3. Consider an unknown unicast frame from the leaf site L1, and also another unknown unicast frame from R1 entering. With the 2VLAN method (to my best understanding): - frame from L1 enters PE1, goes into a PW to PE2 and a PW to PE3, arrives at PE2 which decides that it should be flooded out all Root AC's, based on the S-tag. It also arrives at PE3, where it is dropped because there are no root AC's. - frame from R1 enters PE1, goes into a PW to PE2 and a PW to PE3, arrives at PE2 which decides that it should be flooded out all AC's, based on S-tag. It also arrives at PE3 where it is forwarded to all root AC's. With Multi-PW method: - frame from L1 enters PE1, which decides to forward the frame out the 'root' PW to PE2, which in turn floods out all Root AC's, based on arriving PW type. Frame is NOT sent to PE3, since there is no PW built to the PE which has no root AC's. - frame from R1 enters PE1, which decides to flood out both 'root' PW and 'leaf' PW to PE2, which in turn floods out the same AC types, based on arriving PW type. It also arrives at PE3 where it is forwarded to all root AC's. I suppose optimization could be done on the ingress PE to decide that there is no need to 'flood' root-sourced frames to two PW's that have the same egress PE, but instead to only forward to the 'root' type PW, when both exist, because we know that the egress PE will flood frames from root-sourced PW's out both leaf and root AC's. In this example, the same frame from R1 is duplicated on the PE1-PE2 path (if no optimization is done.), where it would not be with the 2VLAN method. With 2VLAN, ethernet type PW's cannot be used (must be vlan type PW's, otherwise how would we classify source AC-type?), which means there is overhead on EVERY frame to add the s-tag for the sole purpose of classifying the frame. If optimization is done, then each ingress PE knows what types of AC's are on each egress PE, and only forwards the appropriate frame, if no optimization then it is dropped at the egress PE. In short, both are either not 100% inefficient, or are additionally complex due to 'optimization'. I may have gotten my details off on the optimization piece of the 2VLAN method, please correct me if I didn't get the details 100% correct. -Josh On 5/6/12 9:07 PM, "Jiangyuanlong" wrote: >Could you or any other co-authors of 2PW give some more hints so that it >can be better understood? > >In draft-ram-l2vpn-etree-multiple-pw-01, I can only find a single >sentence most to the point: > "An egress PE SHALL NOT deliver a frame originated at a leaf AC to > another leaf AC." > >But it seems there is not a description of "traffic is split/separated >(by psuedowire) on the ingress PE" at all. > >On the contrary, in draft-jiang-l2vpn-vpls-pe-etree-05, Section 5.3.3 >details the scenario and forwarding plane how the leaf traffic is >seperated and filtered on the ingress PE, and Section 6 details the >specific supports in the control plane. > >Thanks >Yuanlong > > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Friday, May 04, 2012 8:27 PM >To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >(Wim); Lucy yong >Cc: l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >also separate the leaf traffic in the ingress PE and filter it there >(already detailed in the Optimization Mode in the I-D); if the egress PE >is attached with pure roots or with both roots and leafs, it seems all >traffic must be transported to the egress PE and be filtered there, I see >no difference in behaviour for these solutions. Or did I miss something? > > >The point is with the multi-PW method the traffic is split/separated (by >psuedowire) on the ingress PE, rather than the egress. The distinction is >2VLAN will 'classify' the frame on the ingress PE, so that the egress PE >knows how to forward it to the appropriate AC's. > >Both methods have inefficiencies (one duplicates traffic for transport, >while the other transports where it doesn't need to go). I like the idea >of classify and forwarding on the ingress PE, rather than marking it on >the ingress, and deciding on the egress. > >-Josh > > > >On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: > >>Josh, thank you for the comments, please see my further comments with >>[JY2]. >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Thursday, May 03, 2012 11:27 PM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>requirements from MEF, it has nothing to do with the solutions. Could you >>give a hint on how you can provision this service E-NNI otherwise? BTW, >>if >>configuring or signalling two PWs is not a problem, why configuring or >>signalling two VLANs will become a problem? After all, more nodes may >>need >>to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >>2VLAN (only T-PEs). >> >> >>There is no other way (if both MPLS domains are part of the same ETREE, >>rather than doing something more like H-VPLS, where one domain has point >>to points to the other domain which handles the ETREE instance) if you >>are >>using an ENNI. The other method, (not mentioned earlier) is tying the >>two >>MPLS domains together via labeled unicast (much preferred over E-NNI in >>my >>opinion) >> >>Configuring two VLAN's isn't really a 'problem' any more than two PW's. >>I >>wasn't saying that configuring two VLAN's was difficult, I was objecting >>to the statement that configuring two PW's is difficult. >> >>[JY2] Thanks, I see your point. I take the example of 2PW configuration >>just to show that using fixed global values to simplify configuration >>makes no sense. Personally I also don't think configuration is a problem >>for both solutions. >> >>I find the differences between these two methods rather slight. The >>'tie-breaker' for me is by placing the forwarding decision on the ingress >>PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >>more control over where the traffic goes, and in my mind it provides a >>cleaner destination between customer traffic and forwarding plane. I'm >>accustomed to looking at a psuedowire and knowing where its going, with >>the 2vlan method, I can see the psuedowire, but must go to the egress PE >>to see if it will be dropped there, or forwarded to one or more AC's. >> >>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>also separate the leaf traffic in the ingress PE and filter it there >>(already detailed in the Optimization Mode in the I-D); if the egress PE >>is attached with pure roots or with both roots and leafs, it seems all >>traffic must be transported to the egress PE and be filtered there, I see >>no difference in behaviour for these solutions. Or did I miss something? >> >>Again, the difference here is slight, and I would honestly be happy to >>see >>either of them come to fruition. Please don't infer that I think the >>2vlan method is 'bad' or has intrinsic problems, because I don't believe >>that. I just prefer the multi-PW method. >> >> >>-Josh >> >> >>On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: >> >>>Josh, please see my comments in line. >>> >>>Thanks >>>Yuanlong >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Thursday, May 03, 2012 10:51 AM >>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>(Wim); Lucy yong >>>Cc: l2vpn@ietf.org >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Yuanlong, >>> >>>Or better yet, include in the draft a 'standard' value for root sourced >>>VID and leaf sourced VID. i.e., 4093=root, 4094=leaf. You would also >>>have to require the the implementation NOT use global VLAN's, however >>>(since each instance would be using the same values). In this way, no >>>signaling or manual configuration is required for remote PE's to know >>>how >>>to classify traffic. >>>[JY] Indeed, we discussed this possibility during the f2f meeting in >>>Paris. But, there are some restrictions as you mentioned, and >>>furthermore: >>>1) Some vendors already used S-VLAN to distinguish their VSIs in the PE; >>>2) Forwarding plane of a PE needs to be revised to be aware of this VLAN >>>ID. >>>Therefore, this 'standard value' approach seems more disruptive compared >>>with the other means and not a good candidate option. >>> >>>Regarding switching PE's? Multi-PW means more than one PW, yes. I >>>don't >>>see this as a real problem. In general, design should try and avoid >>>using >>>S-PE's, but if you must, its going to mean extra work, no matter how you >>>look at it. Two PW's for each Etree being switched instead of one is >>>not >>>alarming or concerning to me. On the other hand, if you use a dot1q >>>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's >>>an >>>two egress VLAN's if you want the Etree to be handled on both sides (and >>>if you use the 'standard' VID's as I mentioned above, you'd have to do >>>mapping to non-standard and back) >>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>requirements from MEF, it has nothing to do with the solutions. Could >>>you >>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>if configuring or signalling two PWs is not a problem, why configuring >>>or >>>signalling two VLANs will become a problem? After all, more nodes may >>>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>>with 2VLAN (only T-PEs). >>> >>>In general, I still prefer multi-PW, primarily because I prefer the >>>separation of the traffic in the network's forwarding plane, rather than >>>shipping it everywhere and deciding whether to forward to the AC when it >>>gets to the egress PE. I'm having a hard time putting my finger exactly >>>on what it is, or articulating the idea, but it seems that by having the >>>traffic placed into two psuedowires, I have more flexibility and ease of >>>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>>PW's could really change that perception. >>>[JY] Are you saying that we need to develop a totally new forwarding >>>plane rather than using the Ethernet forwarding plane as described in >>>the >>>existing work? >>> >>>I hope we can move forward with one of these soon, >>>[JY] me too. >>> >>>Josh >>> >>> >>>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >>> >>>>Daniel, >>>> >>>>Not aware that we had a discussion on this before, but IMHO the >>>>allocation of internal S-VLAN can be automatic, and manuel >>>>configuration >>>>of this mapping may not be needed at all. For example, an S-VLAN >>>>allocation module in the management plane in a PE can do this kind of >>>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>>way from a free S-VLAN ID pool. Once the interal S-VLANs are allocated, >>>>the mapping is determined and no other configuration is needed. >>>> >>>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>>allocate >>>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to allocate >>>>two S-VLANs in the VPLS domain. >>>> >>>>On the other hand, for the multi-PW approach, two PWs need to be >>>>configured for a E-Tree service. When MS-PW is used in the network, for >>>>every S-PE, we need to configure two ingress PW segments and two egress >>>>PW segments. In this case, I don't think we need to use fixed PW labels >>>>across the network for fear of configuration complexity. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 8:01 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Inline. >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 12:30 PM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, Please see my comments in line. >>>> >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 3:55 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Yuanlong, >>>> >>>>The problem is not with the total number of S-VLAN IDs, I agree that >>>>normally there won't be more than 2047. The problem is that if you >>>>don't >>>>support all VLAN IDs, you need S-VLAN space coordination with the >>>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to >>>>2047". >>>>Which won't always be in line with an existing deployment. >>>>[JY] This is not the case. If the total number is no more than 2047, it >>>>surely can be supported. The S-VLAN space of user domain is totally >>>>different from the S-VLAN in the provider domain and they can be >>>>overlapped, I don't see why we need S-VLAN space coordination between >>>>them. >>>> >>>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>>fixed, and therefore the IEEE S-VID that can be supported is also >>>>fixed. >>>> >>>>Of course you can configure the mapping in each PE according to >>>>operator >>>>requirements but as we discussed before this increases complexity. >>>> >>>>Relying on PBB-VPLS imposes additional limitations on backward >>>>compatibility. >>>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>>think they may well need MAC-in-MAC in their networks for the >>>>scalability issue. As you know, only PBB VPLS can provide both. >>>> >>>>Daniel >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 5:07 AM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, >>>> >>>>As you can see, both cases are discussed in the I-D. >>>> >>>>With regard to case 1) (that is, S-VLAN translation), since the access >>>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>>they need to be configured on a PE anyway, and as the past emails by >>>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>>mapping. >>>> >>>>With regard to S-VID space reduction, the constraint is valid only when >>>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>>typical and with no such limits as we already discussed in the f2f >>>>meeting. >>>> >>>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>>described (not sure this is a valid use case in real life), PBB-VPLS >>>>can >>>>still be used. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Monday, April 30, 2012 10:34 PM >>>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>Jiangyuanlong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>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] >>>>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 >>>> >>>>---------------------------------------------------------------------- >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to >>>copyright belonging to Time Warner Cable. This E-mail is intended solely >>>for the use of the individual or entity to which it is addressed. If you >>>are not the intended recipient of this E-mail, you are hereby notified >>>that any dissemination, distribution, copying, or action taken in >>>relation to the contents of and attachments to this E-mail is strictly >>>prohibited and may be unlawful. If you have received this 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 and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this 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: Mon, 7 May 2012 06:34:00 +0000 From: Jiangyuanlong To: "Rogers, Josh" , Daniel Cohn , "Fedyk, Donald (Don)" , "Henderickx, Wim (Wim)" , Lucy yong Cc: "l2vpn@ietf.org" Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410770@szxeml546-mbx.china.huawei.com> Content-Type: text/plain; charset="iso-8859-2" -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com] Sent: Monday, May 07, 2012 12:09 PM To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong Cc: l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? So, if you can imagine three PE's, PE1, PE2 and PE3. PE1 has a root AC, R1 and a leaf AC, L1. PE2 also has a root AC, R2, and a leaf AC, L2. PE3 has a leaf AC, L3. Consider an unknown unicast frame from the leaf site L1, and also another unknown unicast frame from R1 entering. With the 2VLAN method (to my best understanding): - frame from L1 enters PE1, goes into a PW to PE2 and a PW to PE3, arrives at PE2 which decides that it should be flooded out all Root AC's, based on the S-tag. It also arrives at PE3, where it is dropped because there are no root AC's. [JY] Since PE3 is a leaf-only node, the PW from PE1 to PE3 will work in Optimized-Mode. According to Section 5.3.3 of draft-jiang-l2vpn-vpls-pe-etree-05, it will be dropped before arriving at this PW. Therefore, this frame will not arrive at PE3. - frame from R1 enters PE1, goes into a PW to PE2 and a PW to PE3, arrives at PE2 which decides that it should be flooded out all AC's, based on S-tag. It also arrives at PE3 where it is forwarded to all root AC's. With Multi-PW method: - frame from L1 enters PE1, which decides to forward the frame out the 'root' PW to PE2, which in turn floods out all Root AC's, based on arriving PW type. Frame is NOT sent to PE3, since there is no PW built to the PE which has no root AC's. [JY] According to my understanding of the following description in draft-ram-l2vpn-etree-multiple-pw-01: "It should be noted that in a full-mesh VPLS (as opposed to H-VPLS), the following VSI pair types do not require two interconnecting PWs: Root-only VSI <-> any VSI: only root PW required Leaf-only VSI <-> leaf-only VSI: no PWs required" There should be 2 PWs be set up between PE1 and PE3, since this is a case of "Root & Leaf mixed VSI <-> leaf-only VSI" and not listed in the none-two- interconnecting-PWs criteria. Therefore, this frame will be sent to PE3 twice (one on root PW, another on leaf PW) IMO. Of course, the other authors of draft-ram-l2vpn-etree-multiple-pw-01 may have more to say on this point. - frame from R1 enters PE1, which decides to flood out both 'root' PW and 'leaf' PW to PE2, which in turn floods out the same AC types, based on arriving PW type. It also arrives at PE3 where it is forwarded to all root AC's. [JY] It contradicts your first statement that "there is no PW built to the PE which has no root AC's". I suppose optimization could be done on the ingress PE to decide that there is no need to 'flood' root-sourced frames to two PW's that have the same egress PE, but instead to only forward to the 'root' type PW, when both exist, because we know that the egress PE will flood frames from root-sourced PW's out both leaf and root AC's. In this example, the same frame from R1 is duplicated on the PE1-PE2 path (if no optimization is done.), where it would not be with the 2VLAN method. With 2VLAN, ethernet type PW's cannot be used (must be vlan type PW's, otherwise how would we classify source AC-type?), which means there is overhead on EVERY frame to add the s-tag for the sole purpose of classifying the frame. If optimization is done, then each ingress PE knows what types of AC's are on each egress PE, and only forwards the appropriate frame, if no optimization then it is dropped at the egress PE. In short, both are either not 100% inefficient, or are additionally complex due to 'optimization'. I may have gotten my details off on the optimization piece of the 2VLAN method, please correct me if I didn't get the details 100% correct. -Josh On 5/6/12 9:07 PM, "Jiangyuanlong" wrote: >Could you or any other co-authors of 2PW give some more hints so that it >can be better understood? > >In draft-ram-l2vpn-etree-multiple-pw-01, I can only find a single >sentence most to the point: > "An egress PE SHALL NOT deliver a frame originated at a leaf AC to > another leaf AC." > >But it seems there is not a description of "traffic is split/separated >(by psuedowire) on the ingress PE" at all. > >On the contrary, in draft-jiang-l2vpn-vpls-pe-etree-05, Section 5.3.3 >details the scenario and forwarding plane how the leaf traffic is >seperated and filtered on the ingress PE, and Section 6 details the >specific supports in the control plane. > >Thanks >Yuanlong > > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Friday, May 04, 2012 8:27 PM >To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >(Wim); Lucy yong >Cc: l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >also separate the leaf traffic in the ingress PE and filter it there >(already detailed in the Optimization Mode in the I-D); if the egress PE >is attached with pure roots or with both roots and leafs, it seems all >traffic must be transported to the egress PE and be filtered there, I see >no difference in behaviour for these solutions. Or did I miss something? > > >The point is with the multi-PW method the traffic is split/separated (by >psuedowire) on the ingress PE, rather than the egress. The distinction is >2VLAN will 'classify' the frame on the ingress PE, so that the egress PE >knows how to forward it to the appropriate AC's. > >Both methods have inefficiencies (one duplicates traffic for transport, >while the other transports where it doesn't need to go). I like the idea >of classify and forwarding on the ingress PE, rather than marking it on >the ingress, and deciding on the egress. > >-Josh > > > >On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: > >>Josh, thank you for the comments, please see my further comments with >>[JY2]. >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Thursday, May 03, 2012 11:27 PM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>requirements from MEF, it has nothing to do with the solutions. Could you >>give a hint on how you can provision this service E-NNI otherwise? BTW, >>if >>configuring or signalling two PWs is not a problem, why configuring or >>signalling two VLANs will become a problem? After all, more nodes may >>need >>to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >>2VLAN (only T-PEs). >> >> >>There is no other way (if both MPLS domains are part of the same ETREE, >>rather than doing something more like H-VPLS, where one domain has point >>to points to the other domain which handles the ETREE instance) if you >>are >>using an ENNI. The other method, (not mentioned earlier) is tying the >>two >>MPLS domains together via labeled unicast (much preferred over E-NNI in >>my >>opinion) >> >>Configuring two VLAN's isn't really a 'problem' any more than two PW's. >>I >>wasn't saying that configuring two VLAN's was difficult, I was objecting >>to the statement that configuring two PW's is difficult. >> >>[JY2] Thanks, I see your point. I take the example of 2PW configuration >>just to show that using fixed global values to simplify configuration >>makes no sense. Personally I also don't think configuration is a problem >>for both solutions. >> >>I find the differences between these two methods rather slight. The >>'tie-breaker' for me is by placing the forwarding decision on the ingress >>PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >>more control over where the traffic goes, and in my mind it provides a >>cleaner destination between customer traffic and forwarding plane. I'm >>accustomed to looking at a psuedowire and knowing where its going, with >>the 2vlan method, I can see the psuedowire, but must go to the egress PE >>to see if it will be dropped there, or forwarded to one or more AC's. >> >>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>also separate the leaf traffic in the ingress PE and filter it there >>(already detailed in the Optimization Mode in the I-D); if the egress PE >>is attached with pure roots or with both roots and leafs, it seems all >>traffic must be transported to the egress PE and be filtered there, I see >>no difference in behaviour for these solutions. Or did I miss something? >> >>Again, the difference here is slight, and I would honestly be happy to >>see >>either of them come to fruition. Please don't infer that I think the >>2vlan method is 'bad' or has intrinsic problems, because I don't believe >>that. I just prefer the multi-PW method. >> >> >>-Josh >> >> >>On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: >> >>>Josh, please see my comments in line. >>> >>>Thanks >>>Yuanlong >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Thursday, May 03, 2012 10:51 AM >>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>(Wim); Lucy yong >>>Cc: l2vpn@ietf.org >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Yuanlong, >>> >>>Or better yet, include in the draft a 'standard' value for root sourced >>>VID and leaf sourced VID. i.e., 4093=root, 4094=leaf. You would also >>>have to require the the implementation NOT use global VLAN's, however >>>(since each instance would be using the same values). In this way, no >>>signaling or manual configuration is required for remote PE's to know >>>how >>>to classify traffic. >>>[JY] Indeed, we discussed this possibility during the f2f meeting in >>>Paris. But, there are some restrictions as you mentioned, and >>>furthermore: >>>1) Some vendors already used S-VLAN to distinguish their VSIs in the PE; >>>2) Forwarding plane of a PE needs to be revised to be aware of this VLAN >>>ID. >>>Therefore, this 'standard value' approach seems more disruptive compared >>>with the other means and not a good candidate option. >>> >>>Regarding switching PE's? Multi-PW means more than one PW, yes. I >>>don't >>>see this as a real problem. In general, design should try and avoid >>>using >>>S-PE's, but if you must, its going to mean extra work, no matter how you >>>look at it. Two PW's for each Etree being switched instead of one is >>>not >>>alarming or concerning to me. On the other hand, if you use a dot1q >>>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's >>>an >>>two egress VLAN's if you want the Etree to be handled on both sides (and >>>if you use the 'standard' VID's as I mentioned above, you'd have to do >>>mapping to non-standard and back) >>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>requirements from MEF, it has nothing to do with the solutions. Could >>>you >>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>if configuring or signalling two PWs is not a problem, why configuring >>>or >>>signalling two VLANs will become a problem? After all, more nodes may >>>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>>with 2VLAN (only T-PEs). >>> >>>In general, I still prefer multi-PW, primarily because I prefer the >>>separation of the traffic in the network's forwarding plane, rather than >>>shipping it everywhere and deciding whether to forward to the AC when it >>>gets to the egress PE. I'm having a hard time putting my finger exactly >>>on what it is, or articulating the idea, but it seems that by having the >>>traffic placed into two psuedowires, I have more flexibility and ease of >>>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>>PW's could really change that perception. >>>[JY] Are you saying that we need to develop a totally new forwarding >>>plane rather than using the Ethernet forwarding plane as described in >>>the >>>existing work? >>> >>>I hope we can move forward with one of these soon, >>>[JY] me too. >>> >>>Josh >>> >>> >>>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >>> >>>>Daniel, >>>> >>>>Not aware that we had a discussion on this before, but IMHO the >>>>allocation of internal S-VLAN can be automatic, and manuel >>>>configuration >>>>of this mapping may not be needed at all. For example, an S-VLAN >>>>allocation module in the management plane in a PE can do this kind of >>>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>>way from a free S-VLAN ID pool. Once the interal S-VLANs are allocated, >>>>the mapping is determined and no other configuration is needed. >>>> >>>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>>allocate >>>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to allocate >>>>two S-VLANs in the VPLS domain. >>>> >>>>On the other hand, for the multi-PW approach, two PWs need to be >>>>configured for a E-Tree service. When MS-PW is used in the network, for >>>>every S-PE, we need to configure two ingress PW segments and two egress >>>>PW segments. In this case, I don't think we need to use fixed PW labels >>>>across the network for fear of configuration complexity. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 8:01 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Inline. >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 12:30 PM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, Please see my comments in line. >>>> >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 3:55 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Yuanlong, >>>> >>>>The problem is not with the total number of S-VLAN IDs, I agree that >>>>normally there won't be more than 2047. The problem is that if you >>>>don't >>>>support all VLAN IDs, you need S-VLAN space coordination with the >>>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to >>>>2047". >>>>Which won't always be in line with an existing deployment. >>>>[JY] This is not the case. If the total number is no more than 2047, it >>>>surely can be supported. The S-VLAN space of user domain is totally >>>>different from the S-VLAN in the provider domain and they can be >>>>overlapped, I don't see why we need S-VLAN space coordination between >>>>them. >>>> >>>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>>fixed, and therefore the IEEE S-VID that can be supported is also >>>>fixed. >>>> >>>>Of course you can configure the mapping in each PE according to >>>>operator >>>>requirements but as we discussed before this increases complexity. >>>> >>>>Relying on PBB-VPLS imposes additional limitations on backward >>>>compatibility. >>>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>>think they may well need MAC-in-MAC in their networks for the >>>>scalability issue. As you know, only PBB VPLS can provide both. >>>> >>>>Daniel >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 5:07 AM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, >>>> >>>>As you can see, both cases are discussed in the I-D. >>>> >>>>With regard to case 1) (that is, S-VLAN translation), since the access >>>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>>they need to be configured on a PE anyway, and as the past emails by >>>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>>mapping. >>>> >>>>With regard to S-VID space reduction, the constraint is valid only when >>>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>>typical and with no such limits as we already discussed in the f2f >>>>meeting. >>>> >>>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>>described (not sure this is a valid use case in real life), PBB-VPLS >>>>can >>>>still be used. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Monday, April 30, 2012 10:34 PM >>>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>Jiangyuanlong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>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] >>>>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 >>>> >>>>---------------------------------------------------------------------- >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to >>>copyright belonging to Time Warner Cable. This E-mail is intended solely >>>for the use of the individual or entity to which it is addressed. If you >>>are not the intended recipient of this E-mail, you are hereby notified >>>that any dissemination, distribution, copying, or action taken in >>>relation to the contents of and attachments to this E-mail is strictly >>>prohibited and may be unlawful. If you have received this 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 and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this 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 96, Issue 23 ************************************* From yuqun.cao@gmail.com Tue May 8 19:48: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 F416F11E8089 for ; Tue, 8 May 2012 19:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.772 X-Spam-Level: X-Spam-Status: No, score=-2.772 tagged_above=-999 required=5 tests=[AWL=0.227, 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 1Ml5Bz2B75rJ for ; Tue, 8 May 2012 19:48:07 -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 95CA411E8074 for ; Tue, 8 May 2012 19:48:07 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so8926302pbc.31 for ; Tue, 08 May 2012 19:48: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:content-transfer-encoding:x-mailer:in-reply-to :thread-index:x-mimeole; bh=wiBW1pBuRt9+lS3cZtz5/zKo6rIC45Atvawh+NhPfNY=; b=fQNIvTl6s4OQzvwYBfl09DtXij7FR/F/+D7SMEawQXbwkIBnTgyq8oa7DWdF/Xxujg +KsXw1BYHOyzZ+peLRq3pCmcMQDGjc7aIdj/5EaHr5v9aiaKuD8gRfssmq0BhXAeG7y5 U9EbHqzsIMhU4MhKY8Ncf1uYhfRrUzmbC1jPJ2GhkLR7b10sL51uMXnogIZQX1It9i+L nDhS6Iwvkx80qWnH60o6tbhDAJfFUIVYWkhGOEhomUDlnbuAKuAKrYjpTW2o9dYu4JkC K+Kp5kxUlDpLoeaYpA6LcZmk0Ppptdpgtq/IUYfZsAAIzqpDnk4xjauVdAte+0aH87Uc BeAg== Received: by 10.68.241.69 with SMTP id wg5mr1324870pbc.148.1336531687206; Tue, 08 May 2012 19:48:07 -0700 (PDT) Received: from R01842 ([110.90.119.113]) by mx.google.com with ESMTPS id oy8sm4367408pbc.52.2012.05.08.19.47.57 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 May 2012 19:48:05 -0700 (PDT) From: "Sam Cao" To: References: Subject: RE: L2vpn Digest, Vol 96, Issue 25 Date: Wed, 9 May 2012 10:47:51 +0800 Message-ID: <7349D272A36747F28E97683360B0A65C@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: Ac0sKJtVnHvogepGQq+mmCS0if66KQBZGxjw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: 'Jiangyuanlong' 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, 09 May 2012 02:48:10 -0000 Yuanlong, I have one clear idea on this, but I need time to discuss this with other co-authors on details first. This is not PW issue. If we add an attribute for the PW, and data plane can forward the frames from Leaf-Only AC to PW or drop it. We need a little extension to data plane. There is not much work to support this by NP, but I am not sure whether it is big work on chip or not. Thanks, Sam -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of l2vpn-request@ietf.org Sent: Monday, May 07, 2012 4:08 PM To: l2vpn@ietf.org Subject: L2vpn Digest, Vol 96, Issue 25 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? (Jiangyuanlong) ---------------------------------------------------------------------- Message: 1 Date: Mon, 7 May 2012 08:05:30 +0000 From: Jiangyuanlong To: Daniel Cohn , "Rogers, Josh" , "Fedyk, Donald (Don)" , "Henderickx, Wim (Wim)" , Lucy yong Cc: "l2vpn@ietf.org" Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D41079C@szxeml546-mbx.china.huawei.com> Content-Type: text/plain; charset="iso-8859-2" Interesting observation. Could you explain a bit more how to avoid setup of a PW in this scenario? Or could you just point to the exact sentences in your I-D? -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: Monday, May 07, 2012 3:11 PM To: Jiangyuanlong; Rogers, Josh; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? It seems to be that the optimization required to avoid unnecessary transmission of leaf-only traffic over the network is significantly more complex in the 2-VLAN solution, as you need the data plane to maintain per-PW "leaf-onlyness" information (whether a specific PW leads to a leaf-only PE or not) to decide when to drop these frames, whereas in the multi-PW solution this is handled solely by the control plane (by avoiding the setup of a PW in this scenario). DC -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] Sent: Monday, May 07, 2012 9:34 AM To: Rogers, Josh; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com] Sent: Monday, May 07, 2012 12:09 PM To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong Cc: l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? So, if you can imagine three PE's, PE1, PE2 and PE3. PE1 has a root AC, R1 and a leaf AC, L1. PE2 also has a root AC, R2, and a leaf AC, L2. PE3 has a leaf AC, L3. Consider an unknown unicast frame from the leaf site L1, and also another unknown unicast frame from R1 entering. With the 2VLAN method (to my best understanding): - frame from L1 enters PE1, goes into a PW to PE2 and a PW to PE3, arrives at PE2 which decides that it should be flooded out all Root AC's, based on the S-tag. It also arrives at PE3, where it is dropped because there are no root AC's. [JY] Since PE3 is a leaf-only node, the PW from PE1 to PE3 will work in Optimized-Mode. According to Section 5.3.3 of draft-jiang-l2vpn-vpls-pe-etree-05, it will be dropped before arriving at this PW. Therefore, this frame will not arrive at PE3. - frame from R1 enters PE1, goes into a PW to PE2 and a PW to PE3, arrives at PE2 which decides that it should be flooded out all AC's, based on S-tag. It also arrives at PE3 where it is forwarded to all root AC's. With Multi-PW method: - frame from L1 enters PE1, which decides to forward the frame out the 'root' PW to PE2, which in turn floods out all Root AC's, based on arriving PW type. Frame is NOT sent to PE3, since there is no PW built to the PE which has no root AC's. [JY] According to my understanding of the following description in draft-ram-l2vpn-etree-multiple-pw-01: "It should be noted that in a full-mesh VPLS (as opposed to H-VPLS), the following VSI pair types do not require two interconnecting PWs: Root-only VSI <-> any VSI: only root PW required Leaf-only VSI <-> leaf-only VSI: no PWs required" There should be 2 PWs be set up between PE1 and PE3, since this is a case of "Root & Leaf mixed VSI <-> leaf-only VSI" and not listed in the none-two- interconnecting-PWs criteria. Therefore, this frame will be sent to PE3 twice (one on root PW, another on leaf PW) IMO. Of course, the other authors of draft-ram-l2vpn-etree-multiple-pw-01 may have more to say on this point. - frame from R1 enters PE1, which decides to flood out both 'root' PW and 'leaf' PW to PE2, which in turn floods out the same AC types, based on arriving PW type. It also arrives at PE3 where it is forwarded to all root AC's. [JY] It contradicts your first statement that "there is no PW built to the PE which has no root AC's". I suppose optimization could be done on the ingress PE to decide that there is no need to 'flood' root-sourced frames to two PW's that have the same egress PE, but instead to only forward to the 'root' type PW, when both exist, because we know that the egress PE will flood frames from root-sourced PW's out both leaf and root AC's. In this example, the same frame from R1 is duplicated on the PE1-PE2 path (if no optimization is done.), where it would not be with the 2VLAN method. With 2VLAN, ethernet type PW's cannot be used (must be vlan type PW's, otherwise how would we classify source AC-type?), which means there is overhead on EVERY frame to add the s-tag for the sole purpose of classifying the frame. If optimization is done, then each ingress PE knows what types of AC's are on each egress PE, and only forwards the appropriate frame, if no optimization then it is dropped at the egress PE. In short, both are either not 100% inefficient, or are additionally complex due to 'optimization'. I may have gotten my details off on the optimization piece of the 2VLAN method, please correct me if I didn't get the details 100% correct. -Josh On 5/6/12 9:07 PM, "Jiangyuanlong" wrote: >Could you or any other co-authors of 2PW give some more hints so that it >can be better understood? > >In draft-ram-l2vpn-etree-multiple-pw-01, I can only find a single >sentence most to the point: > "An egress PE SHALL NOT deliver a frame originated at a leaf AC to > another leaf AC." > >But it seems there is not a description of "traffic is split/separated >(by psuedowire) on the ingress PE" at all. > >On the contrary, in draft-jiang-l2vpn-vpls-pe-etree-05, Section 5.3.3 >details the scenario and forwarding plane how the leaf traffic is >seperated and filtered on the ingress PE, and Section 6 details the >specific supports in the control plane. > >Thanks >Yuanlong > > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Friday, May 04, 2012 8:27 PM >To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >(Wim); Lucy yong >Cc: l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >also separate the leaf traffic in the ingress PE and filter it there >(already detailed in the Optimization Mode in the I-D); if the egress PE >is attached with pure roots or with both roots and leafs, it seems all >traffic must be transported to the egress PE and be filtered there, I see >no difference in behaviour for these solutions. Or did I miss something? > > >The point is with the multi-PW method the traffic is split/separated (by >psuedowire) on the ingress PE, rather than the egress. The distinction is >2VLAN will 'classify' the frame on the ingress PE, so that the egress PE >knows how to forward it to the appropriate AC's. > >Both methods have inefficiencies (one duplicates traffic for transport, >while the other transports where it doesn't need to go). I like the idea >of classify and forwarding on the ingress PE, rather than marking it on >the ingress, and deciding on the egress. > >-Josh > > > >On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: > >>Josh, thank you for the comments, please see my further comments with >>[JY2]. >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Thursday, May 03, 2012 11:27 PM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>requirements from MEF, it has nothing to do with the solutions. Could you >>give a hint on how you can provision this service E-NNI otherwise? BTW, >>if >>configuring or signalling two PWs is not a problem, why configuring or >>signalling two VLANs will become a problem? After all, more nodes may >>need >>to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >>2VLAN (only T-PEs). >> >> >>There is no other way (if both MPLS domains are part of the same ETREE, >>rather than doing something more like H-VPLS, where one domain has point >>to points to the other domain which handles the ETREE instance) if you >>are >>using an ENNI. The other method, (not mentioned earlier) is tying the >>two >>MPLS domains together via labeled unicast (much preferred over E-NNI in >>my >>opinion) >> >>Configuring two VLAN's isn't really a 'problem' any more than two PW's. >>I >>wasn't saying that configuring two VLAN's was difficult, I was objecting >>to the statement that configuring two PW's is difficult. >> >>[JY2] Thanks, I see your point. I take the example of 2PW configuration >>just to show that using fixed global values to simplify configuration >>makes no sense. Personally I also don't think configuration is a problem >>for both solutions. >> >>I find the differences between these two methods rather slight. The >>'tie-breaker' for me is by placing the forwarding decision on the ingress >>PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >>more control over where the traffic goes, and in my mind it provides a >>cleaner destination between customer traffic and forwarding plane. I'm >>accustomed to looking at a psuedowire and knowing where its going, with >>the 2vlan method, I can see the psuedowire, but must go to the egress PE >>to see if it will be dropped there, or forwarded to one or more AC's. >> >>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>also separate the leaf traffic in the ingress PE and filter it there >>(already detailed in the Optimization Mode in the I-D); if the egress PE >>is attached with pure roots or with both roots and leafs, it seems all >>traffic must be transported to the egress PE and be filtered there, I see >>no difference in behaviour for these solutions. Or did I miss something? >> >>Again, the difference here is slight, and I would honestly be happy to >>see >>either of them come to fruition. Please don't infer that I think the >>2vlan method is 'bad' or has intrinsic problems, because I don't believe >>that. I just prefer the multi-PW method. >> >> >>-Josh >> >> >>On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: >> >>>Josh, please see my comments in line. >>> >>>Thanks >>>Yuanlong >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Thursday, May 03, 2012 10:51 AM >>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>(Wim); Lucy yong >>>Cc: l2vpn@ietf.org >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Yuanlong, >>> >>>Or better yet, include in the draft a 'standard' value for root sourced >>>VID and leaf sourced VID. i.e., 4093=root, 4094=leaf. You would also >>>have to require the the implementation NOT use global VLAN's, however >>>(since each instance would be using the same values). In this way, no >>>signaling or manual configuration is required for remote PE's to know >>>how >>>to classify traffic. >>>[JY] Indeed, we discussed this possibility during the f2f meeting in >>>Paris. But, there are some restrictions as you mentioned, and >>>furthermore: >>>1) Some vendors already used S-VLAN to distinguish their VSIs in the PE; >>>2) Forwarding plane of a PE needs to be revised to be aware of this VLAN >>>ID. >>>Therefore, this 'standard value' approach seems more disruptive compared >>>with the other means and not a good candidate option. >>> >>>Regarding switching PE's? Multi-PW means more than one PW, yes. I >>>don't >>>see this as a real problem. In general, design should try and avoid >>>using >>>S-PE's, but if you must, its going to mean extra work, no matter how you >>>look at it. Two PW's for each Etree being switched instead of one is >>>not >>>alarming or concerning to me. On the other hand, if you use a dot1q >>>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's >>>an >>>two egress VLAN's if you want the Etree to be handled on both sides (and >>>if you use the 'standard' VID's as I mentioned above, you'd have to do >>>mapping to non-standard and back) >>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>requirements from MEF, it has nothing to do with the solutions. Could >>>you >>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>if configuring or signalling two PWs is not a problem, why configuring >>>or >>>signalling two VLANs will become a problem? After all, more nodes may >>>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>>with 2VLAN (only T-PEs). >>> >>>In general, I still prefer multi-PW, primarily because I prefer the >>>separation of the traffic in the network's forwarding plane, rather than >>>shipping it everywhere and deciding whether to forward to the AC when it >>>gets to the egress PE. I'm having a hard time putting my finger exactly >>>on what it is, or articulating the idea, but it seems that by having the >>>traffic placed into two psuedowires, I have more flexibility and ease of >>>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>>PW's could really change that perception. >>>[JY] Are you saying that we need to develop a totally new forwarding >>>plane rather than using the Ethernet forwarding plane as described in >>>the >>>existing work? >>> >>>I hope we can move forward with one of these soon, >>>[JY] me too. >>> >>>Josh >>> >>> >>>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >>> >>>>Daniel, >>>> >>>>Not aware that we had a discussion on this before, but IMHO the >>>>allocation of internal S-VLAN can be automatic, and manuel >>>>configuration >>>>of this mapping may not be needed at all. For example, an S-VLAN >>>>allocation module in the management plane in a PE can do this kind of >>>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>>way from a free S-VLAN ID pool. Once the interal S-VLANs are allocated, >>>>the mapping is determined and no other configuration is needed. >>>> >>>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>>allocate >>>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to allocate >>>>two S-VLANs in the VPLS domain. >>>> >>>>On the other hand, for the multi-PW approach, two PWs need to be >>>>configured for a E-Tree service. When MS-PW is used in the network, for >>>>every S-PE, we need to configure two ingress PW segments and two egress >>>>PW segments. In this case, I don't think we need to use fixed PW labels >>>>across the network for fear of configuration complexity. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 8:01 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Inline. >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 12:30 PM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, Please see my comments in line. >>>> >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 3:55 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Yuanlong, >>>> >>>>The problem is not with the total number of S-VLAN IDs, I agree that >>>>normally there won't be more than 2047. The problem is that if you >>>>don't >>>>support all VLAN IDs, you need S-VLAN space coordination with the >>>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to >>>>2047". >>>>Which won't always be in line with an existing deployment. >>>>[JY] This is not the case. If the total number is no more than 2047, it >>>>surely can be supported. The S-VLAN space of user domain is totally >>>>different from the S-VLAN in the provider domain and they can be >>>>overlapped, I don't see why we need S-VLAN space coordination between >>>>them. >>>> >>>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>>fixed, and therefore the IEEE S-VID that can be supported is also >>>>fixed. >>>> >>>>Of course you can configure the mapping in each PE according to >>>>operator >>>>requirements but as we discussed before this increases complexity. >>>> >>>>Relying on PBB-VPLS imposes additional limitations on backward >>>>compatibility. >>>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>>think they may well need MAC-in-MAC in their networks for the >>>>scalability issue. As you know, only PBB VPLS can provide both. >>>> >>>>Daniel >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 5:07 AM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, >>>> >>>>As you can see, both cases are discussed in the I-D. >>>> >>>>With regard to case 1) (that is, S-VLAN translation), since the access >>>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>>they need to be configured on a PE anyway, and as the past emails by >>>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>>mapping. >>>> >>>>With regard to S-VID space reduction, the constraint is valid only when >>>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>>typical and with no such limits as we already discussed in the f2f >>>>meeting. >>>> >>>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>>described (not sure this is a valid use case in real life), PBB-VPLS >>>>can >>>>still be used. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Monday, April 30, 2012 10:34 PM >>>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>Jiangyuanlong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>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] >>>>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 >>>> >>>>---------------------------------------------------------------------- >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to >>>copyright belonging to Time Warner Cable. This E-mail is intended solely >>>for the use of the individual or entity to which it is addressed. If you >>>are not the intended recipient of this E-mail, you are hereby notified >>>that any dissemination, distribution, copying, or action taken in >>>relation to the contents of and attachments to this E-mail is strictly >>>prohibited and may be unlawful. If you have received this 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 and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this 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 96, Issue 25 ************************************* From keshavaak@huawei.com Tue May 8 21:48: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 8122721F8533; Tue, 8 May 2012 21:48:48 -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, 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 gUDcJ0VeuB1V; Tue, 8 May 2012 21:48:47 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 82AE621F84DD; Tue, 8 May 2012 21:48: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 AFY35808; Wed, 09 May 2012 00:48:47 -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; Tue, 8 May 2012 21:45:40 -0700 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 8 May 2012 21:45:44 -0700 Received: from blrprnc03ns (10.18.96.92) by szxeml412-hub.china.huawei.com (10.82.67.91) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 9 May 2012 12:45:30 +0800 From: Keshav.A.K. To: 'Xuxiaohu' References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02F20BF9@szxeml525-mbs.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02F20BF9@szxeml525-mbs.china.huawei.com> Subject: RE: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version Notification for draft-xu-mpls-in-udp-00.txt Date: Wed, 9 May 2012 10:15:28 +0530 Organization: Htipl Message-ID: <005a01cd2d9e$900f0ac0$b02d2040$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AQHNJOUqEV0uAsQuJk6ASHAvdqt8upavh4QAgA+/yUCAAaQBsA== Content-Language: en-us X-Originating-IP: [10.18.96.92] X-CFilter-Loop: Reflected Cc: l2vpn@ietf.org, nvo3@ietf.org, l3vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: keshavaak@huawei.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 04:48:49 -0000 Hi, Yes, Major drawback of GRE kind of enacp, switch need to parse deeply into = GRE packets for applying policies related to load distribution Port = Channels that are used to aggregate the bandwidth of multiple physical = links into one logical link. =20 If switches were to try to distribute GRE flows between two VTEPs that = used a GRE encapsulation, all the traffic would be directed to use only = one link within these Port Channels. However Parsing all the way to UDP = (ex VxLan) source and destination port numbers, (may be configure the = switches to use 5-tuple) can spread each UDP flow out to a different = link of a Port Channel or ECMP route.=20 Regards, keshava -----Original Message----- From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf Of = Xuxiaohu Sent: Tuesday, May 08, 2012 8:51 AM To: l2vpn@ietf.org; l3vpn@ietf.org; nvo3@ietf.org Subject: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN traffic = over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version = Notification for draft-xu-mpls-in-udp-00.txt Hi all, This topic may be interesting to L2VPN, L3VPN and even NVo3 folks.=20 Any comments are welcome. Best regards, Xiaohu/ Marshall/Lucy > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: Xuxiaohu > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2012=E5=B9=B44=E6=9C=8828=E6=97=A5 10:55 > =E6=94=B6=E4=BB=B6=E4=BA=BA: 'mpls@ietf.org' > =E6=8A=84=E9=80=81: 'marshall.eubanks@gmail.com'; Lucy yong > =E4=B8=BB=E9=A2=98: fwd: New Version Notification for = draft-xu-mpls-in-udp-00.txt >=20 > Hi all, >=20 > Equal Cost Multi-Path (ECMP) and Link Aggregation Group (LAG) are = widely used > in the core of IP-enabled Packet Switch Networks (PSN) for = load-balancing > purposes. Most core routers (i.e., P routers) in the IP-enabled PSN = are capable of > load-balancing IP traffic flows across ECMP paths and/or LAG based on = the hash > of the five-tuple of UDP/TCP packets (i.e., source IP address, = destination IP > address, source port, destination port, and protocol) or some fields = in the IP > header of non-UDP/TCP packets (e.g., source IP address, destination IP = address). >=20 > However, with existing IP-based encapsulation methods as defined in = [RFC4023] > such as MPLS-in-IP and MPLS-in-GRE, distinct customer traffic flows of = various > MPLS applications (e.g., MPLS-based L2VPN or L3VPN) between a given PE = pair > would be encapsulated with the same IP or GRE tunnel header prior to = traversing > the core. Since the encapsulating traffic is neither TCP nor UDP = traffic, core > routers could only perform hash calculation on the fields in the IP = header of IP or > GRE tunnels. As a result, core routers could not achieve an effective > load-balancing for these traffic flows in the network due to the lack = of adequate > entropy information. >=20 > This document specifies one additional IP-based encapsulation = technology for > MPLS packets referred to as MPLS-in-UDP, which is intended to = facilitate > load-balancing the traffic of various MPLS applications such as = MPLS-based L2VPN > and L3VPN in the core of IP-enabled PSN. >=20 > Any comments are welcome. >=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: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org] > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2012=E5=B9=B44=E6=9C=8828=E6=97=A5 10:18 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Xuxiaohu > =E6=8A=84=E9=80=81: Lucy yong; marshall.eubanks@gmail.com > =E4=B8=BB=E9=A2=98: New Version Notification for = draft-xu-mpls-in-udp-00.txt >=20 > A new version of I-D, draft-xu-mpls-in-udp-00.txt has been = successfully > submitted by Xiaohu Xu and posted to the IETF repository. >=20 > Filename: draft-xu-mpls-in-udp > Revision: 00 > Title: Encapsulating MPLS in UDP > Creation date: 2012-04-28 > WG ID: Individual Submission > Number of pages: 7 >=20 > Abstract: > This document specifies one additional IP-based encapsulation > technology for MPLS packets referred to as MPLS-in-UDP, which is > intended to facilitate load-balancing the traffic of various MPLS > applications such as MPLS-based L2VPN and L3VPN in the core of IP- > enabled packet switch networks. >=20 >=20 >=20 >=20 >=20 > The IETF Secretariat _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 From Alexander.Vainshtein@ecitele.com Tue May 8 21:58: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 D18C021F8594 for ; Tue, 8 May 2012 21:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.102 X-Spam-Level: X-Spam-Status: No, score=-4.102 tagged_above=-999 required=5 tests=[AWL=1.100, 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 NHqZmwtCiCz4 for ; Tue, 8 May 2012 21:58:43 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.98]) by ietfa.amsl.com (Postfix) with ESMTP id C0AA521F855A for ; Tue, 8 May 2012 21:58:42 -0700 (PDT) Received: from [193.109.254.147:32135] by server-4.bemta-14.messagelabs.com id A6/33-11570-089F9AF4; Wed, 09 May 2012 04:58:40 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1336539519!5867518!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.5.7; banners=-,-,- Received: (qmail 3001 invoked from network); 9 May 2012 04:58:39 -0000 Received: from unknown (HELO FRIDLPPSB002.ECITELE.COM) (168.87.1.157) by server-5.tower-27.messagelabs.com with SMTP; 9 May 2012 04:58:39 -0000 X-AuditID: a8571402-b7f0e6d000005f9e-c5-4fa9f6ec96df Received: from FRIDWPPCH002.ecitele.com (fridwppch002.ecitele.com [10.1.16.53]) by FRIDLPPSB002.ECITELE.COM (Symantec Messaging Gateway) with SMTP id 60.62.24478.CE6F9AF4; Wed, 9 May 2012 06:47:40 +0200 (CEST) Received: from FRIDWPPMB001.ecitele.com ([169.254.3.187]) by FRIDWPPCH002.ecitele.com ([10.1.16.53]) with mapi id 14.01.0339.001; Wed, 9 May 2012 06:58:38 +0200 From: Alexander Vainshtein To: Sam Cao , "l2vpn@ietf.org" Subject: RE: Discussion on E-Tree and H-VPLS Thread-Topic: Discussion on E-Tree and H-VPLS Thread-Index: Ac0runklF6VkjhlbSXuI0yRteo1ydwByMCCgAAbn5ws= Date: Wed, 9 May 2012 04:58: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.2] Content-Type: text/plain; charset="iso-2022-jp" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2VTW0zTUBj2tGUUXKUOdMcpcalGjbI5VMw0jiAXAwlkBIkkPqh1O26VrVvW cZlPMzxoUIz4oHFE0bgQULxhiKhI5pQYiQY0EC8gMQ4eBIkmyi0GtV0FMfah+c75vu///nP6 l8RVXxUakuO9yMOzDkYRT8SDBRrd2EST2dD/K84YmQjHGjurfwLjhaoXigw8917gfWxuMDiN 5TZ3TBGF+F4/2MHyvMvLepHWigSLiSn0cOWsxcdoOauJSWW0bgdrQU7Ee00M63Yj3sqkx2v/ e3aIMo7XIt7isnK8zcTk7TbrjMa0bbpUJr3YzglapHOynEPrRILA2pBW3JH65q0HbuD25p5u 4P5QWjnWHyb8wL+nGsSRkN4Cbx6riZXxUtgzeFNRDeJJFd0LYO3wMSAvggA+n6qLqhS0CbZc e6+QcBKdDb83hGIkjNNpsKM1gEk4kU6BVQ9fYbJGB3sbbwEZb4ddj4JRL0GvhqP99YSEKboA tt8bjtZR0SysfRqM4jh6K7xydDKaC8TuJruaMTlLDd8N1WNy1zQMtnfjMl4CP0V+xsh4JbzT GvnT20bYXttFyHgDbLg8isu5i+Gz80OErF8GHzW+IU4DdWBeRGCePTDPHphnvwSIqwDuKsrL zi8s3J1pMGzS52TlFefk5+izzAUtQJyYxpIkrA1UvU0NA5oEjJKqbG4yq2LYcsHnDINlJMYs oVTfxa1FB11Wn50V7Ps9ZQ4khAEkcSaJCqwVOcrK+o4gj2uWMoqXWItrFlpc0jf27t9sMPyz YNTUvqJ0s4q2iYNXipAbeWatK0iSgVTPlFh1sQfZUOUhzuH9S2NknJSsFJOPShpKcLNOgbPJ fBfYQJ4eb+sD5MwP8a0ieBePNGqqSZLSktRexs9VGwFq8cSJVFhileI4ztUZESMwMeLs42iE +HvMURo/yP4yPl38+smawaIWpZCcc9KecbKkO3bd52/Gi+tCM1N2XycXGrQNHBTGH5Yc7lyO rxRW3XGXpZyqt4Ynj6fp9S9H7744rNe1j/nb7p940/u45uJr/8DHdN31muS+LTFn6iJt05mU KSHSESpP0e0sCFXcViZcCO+5f+7Wg6xWW8UAQwh2NnU97hHY3zOk37cDBAAA Cc: "lizhong.jin@zte.com.cn" 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, 09 May 2012 04:58:45 -0000 Sam, Lizhong and all, You've written that in the two-PW solution combined with H-VPLS the PE-r mus= t set up two PWs with each MTU-s. If this is the case, what kind of forwarding logic should be used to prevent= sending a BUM frame received from a root-PW to a given MTU-S: - back to the same MTU-S on the corresponding leaf-PW? - twice (to both root-PW and Leaf-PW) to another MTU-s? And, BTW, how is the= PW selected in this case? I am aware of a technique of multiple split horizon groups in PE-r which cou= ld be possibly used for this purpose. However, since these groups have to be= represented explicitly in the data plane, their potential number is limited= by the forwarding HW. Other methods could be probably used for the same pur= pose, but they would probably subject to similar HW-based limitations. I suspect that with the dual-PW approach, the HW would pose an implicit limi= t, say, on a number of MTU-s that can be connected to the same PE-r and that= this limit could be quite low in most cases. Based on this I suspect that the H-VPLS issue as a critical drawback of the= dual-PW approach to E-Tree. My 2c, Sasha ________________________________________ From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Sam Cao [= yuqun.cao@gmail.com] Sent: Wednesday, May 09, 2012 3:40 AM To: l2vpn@ietf.org Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Hi Lizhong=1B$B!$=1B(B Thank you very much for your comments. I updated the result on this question. [Lizhong] agree with the above analysis. And we did not say it is a technical problem, but it is an operational problem again. [Sam] I agree. Dual-VLAN does not make sense. I also discussed this with Giles and Yuanlong in another mail, and we reached agreement on this: MTU should know the access mode, VPWS or VPLS, VPWS mode should configure VLAN ID on MTU but VPLS mode can not. I thought this is NOT reasonable :), but we can figure this out in draft. It seems ok. [Lizhong] not fully understand. Do you mean, when VPWS accessing for H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf PW) for each AC access? [Sam] Yes. Thanks, Sam -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of l2vpn-request@ietf.org Sent: Monday, May 07, 2012 3:00 AM To: l2vpn@ietf.org Subject: L2vpn Digest, Vol 96, 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: Discussion on E-Tree and H-VPLS (Lizhong Jin) 2. RE: Discussion on E-Tree and H-VPLS (Lizhong Jin) ---------------------------------------------------------------------- Message: 1 Date: Sun, 6 May 2012 18:22:14 +0800 From: Lizhong Jin To: yuqun.cao@gmail.com Cc: l2vpn@ietf.org, jiangyuanlong@huawei.com Subject: RE: Discussion on E-Tree and H-VPLS Message-ID: Content-Type: text/plain; charset=3D"iso-8859-1" Hi Sam, See inline below. Thanks Lizhong ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 24 Apr 2012 11:51:26 +0800 > From: "Sam Cao" > To: "'Jiangyuanlong'" > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > Message-ID: > Content-Type: text/plain; charset=3D"GB2312" > > 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. > [Lizhong] agree with the above analysis. And we did not say it is a technical problem, but it is an operational problem again. > > 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. > [Lizhong] not fully understand. Do you mean, when VPWS accessing for H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf PW) for each AC access? > 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=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 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Sun, 6 May 2012 18:25:59 +0800 From: Lizhong Jin To: yuqun.cao@gmail.com Cc: l2vpn@ietf.org, jiangyuanlong@huawei.com Subject: RE: Discussion on E-Tree and H-VPLS Message-ID: Content-Type: text/plain; charset=3D"iso-8859-1" > > > ------------------------------ > > Date: Tue, 24 Apr 2012 11:59:33 +0800 > From: "Sam Cao" > To: "'Alexander Vainshtein'" , > "'Jiangyuanlong'" > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > Message-ID: > Content-Type: text/plain; charset=3D"GB2312" > > 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. > [Lizhong] no, the CW approach is OK. The PE-r with VPWS could support CW, and add leaf/root indication in the packet. Thanks Lizhong > 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, > > ------------------------------ -------------- 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 96, Issue 21 ************************************* 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 Tue May 8 23:14: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 133EE21F85D9 for ; Tue, 8 May 2012 23:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 cPcnP0ZfyzV2 for ; Tue, 8 May 2012 23:14:49 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id 1672821F8559 for ; Tue, 8 May 2012 23:14:43 -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="ISO-2022-JP" Content-Transfer-Encoding: 7bit Subject: RE: Discussion on E-Tree and H-VPLS Date: Wed, 9 May 2012 09:16:36 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780CBA6@tlvmail1> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Discussion on E-Tree and H-VPLS Thread-Index: Ac0runklF6VkjhlbSXuI0yRteo1ydwByMCCgAAbn5wsAAujfYA== References: , From: "Daniel Cohn" To: "Alexander Vainshtein" , "Sam Cao" , Cc: lizhong.jin@zte.com.cn 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, 09 May 2012 06:14:51 -0000 Hi Sasha, It's actually very simple. A frame that originated in a root AC is always transmitted only in root PW, no matter what the frame type (known/unknown unicast or broadcast). This is how the frame source information is propagated across the VPLS. So in the H-VPLS example, the PE-r will never forward a frame received over a root PW on any leaf PW, only on root PWs (toward the core or toward other spokes). Hope this clarifies it, regards, Daniel -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Alexander Vainshtein Sent: Wednesday, May 09, 2012 7:59 AM To: Sam Cao; l2vpn@ietf.org Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Sam, Lizhong and all, You've written that in the two-PW solution combined with H-VPLS the PE-r must set up two PWs with each MTU-s. If this is the case, what kind of forwarding logic should be used to prevent sending a BUM frame received from a root-PW to a given MTU-S: - back to the same MTU-S on the corresponding leaf-PW? - twice (to both root-PW and Leaf-PW) to another MTU-s? And, BTW, how is the PW selected in this case? I am aware of a technique of multiple split horizon groups in PE-r which could be possibly used for this purpose. However, since these groups have to be represented explicitly in the data plane, their potential number is limited by the forwarding HW. Other methods could be probably used for the same purpose, but they would probably subject to similar HW-based limitations. I suspect that with the dual-PW approach, the HW would pose an implicit limit, say, on a number of MTU-s that can be connected to the same PE-r and that this limit could be quite low in most cases. Based on this I suspect that the H-VPLS issue as a critical drawback of the dual-PW approach to E-Tree. My 2c, Sasha ________________________________________ From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Sam Cao [yuqun.cao@gmail.com] Sent: Wednesday, May 09, 2012 3:40 AM To: l2vpn@ietf.org Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Hi Lizhong$B!$(J Thank you very much for your comments. I updated the result on this question. [Lizhong] agree with the above analysis. And we did not say it is a technical problem, but it is an operational problem again. [Sam] I agree. Dual-VLAN does not make sense. I also discussed this with Giles and Yuanlong in another mail, and we reached agreement on this: MTU should know the access mode, VPWS or VPLS, VPWS mode should configure VLAN ID on MTU but VPLS mode can not. I thought this is NOT reasonable :), but we can figure this out in draft. It seems ok. [Lizhong] not fully understand. Do you mean, when VPWS accessing for H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf PW) for each AC access? [Sam] Yes. Thanks, Sam -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of l2vpn-request@ietf.org Sent: Monday, May 07, 2012 3:00 AM To: l2vpn@ietf.org Subject: L2vpn Digest, Vol 96, 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: Discussion on E-Tree and H-VPLS (Lizhong Jin) 2. RE: Discussion on E-Tree and H-VPLS (Lizhong Jin) ---------------------------------------------------------------------- Message: 1 Date: Sun, 6 May 2012 18:22:14 +0800 From: Lizhong Jin To: yuqun.cao@gmail.com Cc: l2vpn@ietf.org, jiangyuanlong@huawei.com Subject: RE: Discussion on E-Tree and H-VPLS Message-ID: Content-Type: text/plain; charset="iso-8859-1" Hi Sam, See inline below. Thanks Lizhong ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 24 Apr 2012 11:51:26 +0800 > From: "Sam Cao" > To: "'Jiangyuanlong'" > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > Message-ID: > Content-Type: text/plain; charset="GB2312" > > 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. > [Lizhong] agree with the above analysis. And we did not say it is a technical problem, but it is an operational problem again. > > 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. > [Lizhong] not fully understand. Do you mean, when VPWS accessing for H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf PW) for each AC access? > 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 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Sun, 6 May 2012 18:25:59 +0800 From: Lizhong Jin To: yuqun.cao@gmail.com Cc: l2vpn@ietf.org, jiangyuanlong@huawei.com Subject: RE: Discussion on E-Tree and H-VPLS Message-ID: Content-Type: text/plain; charset="iso-8859-1" > > > ------------------------------ > > Date: Tue, 24 Apr 2012 11:59:33 +0800 > From: "Sam Cao" > To: "'Alexander Vainshtein'" , > "'Jiangyuanlong'" > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > Message-ID: > Content-Type: text/plain; charset="GB2312" > > 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. > [Lizhong] no, the CW approach is OK. The PE-r with VPWS could support CW, and add leaf/root indication in the packet. Thanks Lizhong > 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, > > ------------------------------ -------------- 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 96, Issue 21 ************************************* 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 robert@raszuk.net Wed May 9 00:33: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 CFEF021F849A for ; Wed, 9 May 2012 00:33:22 -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 1wV2Hg+fgGL5 for ; Wed, 9 May 2012 00:33:22 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 630C421F848F for ; Wed, 9 May 2012 00:33:22 -0700 (PDT) Received: (qmail 8435 invoked by uid 399); 9 May 2012 07:26:41 -0000 Received: from unknown (HELO ?192.168.1.58?) (pbs:m42@mojaklasa.info@178.43.237.61) by mail1310.opentransfer.com with ESMTPM; 9 May 2012 07:26:41 -0000 X-Originating-IP: 178.43.237.61 Message-ID: <4FAA1C30.6090303@raszuk.net> Date: Wed, 09 May 2012 09:26:40 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: keshavaak@huawei.com Subject: Re: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version Notification for draft-xu-mpls-in-udp-00.txt References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02F20BF9@szxeml525-mbs.china.huawei.com> <005a01cd2d9e$900f0ac0$b02d2040$@com> In-Reply-To: <005a01cd2d9e$900f0ac0$b02d2040$@com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org, nvo3@ietf.org, l3vpn@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, 09 May 2012 07:33:22 -0000 > If switches were to try to distribute GRE flows between two VTEPs > that used a GRE encapsulation, all the traffic would be directed to > use only one link within these Port Channels. Not true. GRE encapsulation is not mandated to use the same src/dst addresses for all flows between given two end points. You do not need to parse deep into packet to enable good load balancing hash across parallel links when you use GRE as an encapsulation technology. And what is nice about IP encapsulation all GRE src/dst addresses can be naturally aggregated so from IGP point of view they still look like a single prefix. Regards, R. From jiangyuanlong@huawei.com Wed May 9 01:43:14 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C123221F8598 for ; Wed, 9 May 2012 01:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.173, 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 mqQ0EBjokzya for ; Wed, 9 May 2012 01:43:14 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 21C5621F856F for ; Wed, 9 May 2012 01:43:14 -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 AFZ04468; Wed, 09 May 2012 04:43:13 -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, 9 May 2012 01:39:27 -0700 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 9 May 2012 01:39:31 -0700 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.183]) by szxeml402-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Wed, 9 May 2012 16:39:26 +0800 From: Jiangyuanlong To: Sam Cao , "l2vpn@ietf.org" Subject: RE: L2vpn Digest, Vol 96, Issue 25 Thread-Topic: L2vpn Digest, Vol 96, Issue 25 Thread-Index: AQHNLCii0Beh+qpyY0qwt+0y+3u4XZbAPdKAgADnRoA= Date: Wed, 9 May 2012 08:39:26 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410F66@szxeml546-mbx.china.huawei.com> References: <7349D272A36747F28E97683360B0A65C@R01842> In-Reply-To: <7349D272A36747F28E97683360B0A65C@R01842> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.40.73] 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, 09 May 2012 08:43:14 -0000 Great, let's discuss it when it is ready. Maybe you also need some more work on the control plane. Regards, Yuanlong -----Original Message----- From: Sam Cao [mailto:yuqun.cao@gmail.com]=20 Sent: Wednesday, May 09, 2012 10:48 AM To: l2vpn@ietf.org Cc: Jiangyuanlong; 'Rogers, Josh'; 'Daniel Cohn' Subject: RE: L2vpn Digest, Vol 96, Issue 25 Yuanlong, I have one clear idea on this, but I need time to discuss this with other co-authors on details first. This is not PW issue. If we add an attribute for the PW, and data plane can forward the frames from Leaf-Only AC to PW o= r drop it. We need a little extension to data plane. There is not much work t= o support this by NP, but I am not sure whether it is big work on chip or not= . Thanks, Sam From stbryant@cisco.com Wed May 9 02:53: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 75D4D21F85C7; Wed, 9 May 2012 02:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.496 X-Spam-Level: X-Spam-Status: No, score=-110.496 tagged_above=-999 required=5 tests=[AWL=0.103, 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 C7chbzw0dWQg; Wed, 9 May 2012 02:53:37 -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 1151621F85C6; Wed, 9 May 2012 02:53:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=1044; q=dns/txt; s=iport; t=1336557217; x=1337766817; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=RySI63kL+6vvAvYlVrjxgjC37AIHAkxRWCAgYf0ysgM=; b=iVMxlGlSVESd4GsLdLRTA9zAQjLw/b08f9mJnLcO7QxU/8t0TA8dvnei msObWRlYVjNrM5z1eA8PgzdDdjHj9bqw/A7NdegJjlSiGaIElwpW+gcPI T8YbHj+uqngH6tP839FBhfcy3NyJdh4fEg8RrYm0zGY0LeQRCgEn4JzaD g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAD89qk+Q/khL/2dsb2JhbABEr3ODW4EHggwBAQEEEgECIz8BARALGAkWBAsJAwIBAgFFEwEHAQEeh2ybIINFEJxYiwyCbIMmBJV9jliBAmeCag X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="137418558" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 09 May 2012 09:53:36 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q499rXvL005956; Wed, 9 May 2012 09:53:36 GMT Received: from stbryant-mac2.local (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q499rUpk002845; Wed, 9 May 2012 10:53:30 +0100 (BST) Message-ID: <4FAA3E9A.7050602@cisco.com> Date: Wed, 09 May 2012 10:53:30 +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: robert@raszuk.net Subject: Re: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version Notification for draft-xu-mpls-in-udp-00.txt References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02F20BF9@szxeml525-mbs.china.huawei.com> <005a01cd2d9e$900f0ac0$b02d2040$@com> <4FAA1C30.6090303@raszuk.net> In-Reply-To: <4FAA1C30.6090303@raszuk.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org, nvo3@ietf.org, l3vpn@ietf.org 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: Wed, 09 May 2012 09:53:38 -0000 On 09/05/2012 08:26, Robert Raszuk wrote: > >> If switches were to try to distribute GRE flows between two VTEPs >> that used a GRE encapsulation, all the traffic would be directed to >> use only one link within these Port Channels. > > Not true. GRE encapsulation is not mandated to use the same src/dst > addresses for all flows between given two end points. > > You do not need to parse deep into packet to enable good load > balancing hash across parallel links when you use GRE as an > encapsulation technology. > > And what is nice about IP encapsulation all GRE src/dst addresses can > be naturally aggregated so from IGP point of view they still look like > a single prefix. > > Regards, > R. Robert I think that this needs some serious study rather than assertion, because it is not at all obvious what the LB properties of either method will be in a DC. In the case of the use of multiple GRE addresses there are operational and route scaling issues that also need to be considered. Stewart From ipepelnjak@gmail.com Wed May 9 03:00: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 2692521F85AF; Wed, 9 May 2012 03:00:25 -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 H144RF1Blfdx; Wed, 9 May 2012 03:00:22 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDFF21F85C7; Wed, 9 May 2012 03:00:12 -0700 (PDT) Received: by bkty8 with SMTP id y8so94375bkt.31 for ; Wed, 09 May 2012 03:00:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=7vJMTQyy+Tn2LbrP6uyGGWz2efkeoTVgX+fC78T53GI=; b=ltAwfyVfPXAkZa+we8Z8P2agi6oOMSbd6oN4Afdli04Ng12iVJ+ozwoQoF5erkviC3 NnT6FoBdy4ZxkUxSUN623AOXak8ea6KnB1tPZxUg7Jya1RUm7wtuz4ZecLnSJYqfhgyW l6MmhNKnZ5uW9gvicRG08yTnAbpoICU0Bv6bCBU2UVf9boWAu51sq/+zqLivS+4Myfw2 UeFiAUrUhTvenAA28lOg0OtmioJpSSs8OLRgmcdNYaexG01T16XYz04+yd1RNwg/jPgH 5GxbZpVFnWww3ugRppI30gxQLKqoelhnZyxW5fPC6XQOPgacMOcXEn4R7ElAGjMSzd1K TDMw== Received: by 10.204.152.22 with SMTP id e22mr8345278bkw.8.1336557612236; Wed, 09 May 2012 03:00:12 -0700 (PDT) Received: from PIPINB2009 (BSN-176-186-117.dial-up.dsl.siol.net. [95.176.186.117]) by mx.google.com with ESMTPS id z17sm3774165bkw.12.2012.05.09.03.00.09 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 09 May 2012 03:00:10 -0700 (PDT) From: "Ivan Pepelnjak" To: , References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02F20BF9@szxeml525-mbs.china.huawei.com> <005a01cd2d9e$900f0ac0$b02d2040$@com> <4FAA1C30.6090303@raszuk.net> In-Reply-To: <4FAA1C30.6090303@raszuk.net> Subject: RE: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version Notification for draft-xu-mpls-in-udp-00.txt Date: Wed, 9 May 2012 12:00:08 +0200 Message-ID: <00fe01cd2dca$85427060$8fc75120$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0ttRd8cVAO+AypQ7+tvdE9Kv4cWwAFOKmA Content-Language: sl X-Mailman-Approved-At: Wed, 09 May 2012 03:02:25 -0700 Cc: l2vpn@ietf.org, nvo3@ietf.org, l3vpn@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, 09 May 2012 10:00:25 -0000 > > If switches were to try to distribute GRE flows between two VTEPs > > that used a GRE encapsulation, all the traffic would be directed to > > use only one link within these Port Channels. >=20 > Not true. GRE encapsulation is not mandated to use the same src/dst > addresses for all flows between given two end points. True, but then you need a mechanism to discover all the available = endpoints, whereas with single VTEP per host you can use existing = mechanisms (either learning from source IP address or next-hop = distribution with BGP-like protocols). > You do not need to parse deep into packet to enable good load = balancing > hash across parallel links when you use GRE as an encapsulation > technology. True, but many existing DC switches that do IP-based load balancing have = no problems load-balancing on UDP 5-tuple. I am positive there's = equipment out there that can do load balancing on GRE keys (or some = other part of GRE header), I just haven't encountered it yet (or = realized it does that), so please fix my ignorance. > And what is nice about IP encapsulation all GRE src/dst addresses can = be > naturally aggregated so from IGP point of view they still look like a > single prefix. ... and you need a new endpoint prefix (or set-of-addresses) discovery = mechanism. Ivan From robert@raszuk.net Wed May 9 04:01: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 5EBEC21F85AF for ; Wed, 9 May 2012 04:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.742 X-Spam-Level: X-Spam-Status: No, score=-1.742 tagged_above=-999 required=5 tests=[AWL=-0.786, BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WvcwkQBP5OP for ; Wed, 9 May 2012 04:01:26 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 6091A21F8552 for ; Wed, 9 May 2012 04:01:26 -0700 (PDT) Received: (qmail 31241 invoked by uid 399); 9 May 2012 11:01:25 -0000 Received: from unknown (HELO ?192.168.1.91?) (pbs:robert@raszuk.net@83.31.229.80) by mail1310.opentransfer.com with ESMTPM; 9 May 2012 11:01:25 -0000 X-Originating-IP: 83.31.229.80 Message-ID: <4FAA4E84.4090803@raszuk.net> Date: Wed, 09 May 2012 13:01:24 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Ivan Pepelnjak Subject: Re: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version Notification for draft-xu-mpls-in-udp-00.txt References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02F20BF9@szxeml525-mbs.china.huawei.com> <005a01cd2d9e$900f0ac0$b02d2040$@com> <4FAA1C30.6090303@raszuk.net> <00fe01cd2dca$85427060$8fc75120$@com> In-Reply-To: <00fe01cd2dca$85427060$8fc75120$@com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org, nvo3@ietf.org, l3vpn@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, 09 May 2012 11:01:27 -0000 Hi Ivan, > True, but then you need a mechanism to discover all the available > endpoints, whereas with single VTEP per host you can use existing > mechanisms (either learning from source IP address or next-hop > distribution with BGP-like protocols). True. I see few options: - Signal different next hops in BGP for the application which runs across - Treat next hop in BGP as prefix indicator not as host route. In particular next hop resolves in IGP to a prefix which in turn could be used as set of GRE destination addresses - Signal such range explicitly. I think there will be a draft coming up on just that soon. > True, but many existing DC switches that do IP-based load balancing > have no problems load-balancing on UDP 5-tuple. I am positive > there's equipment out there that can do load balancing on GRE keys > (or some other part of GRE header), I just haven't encountered it yet > (or realized it does that), so please fix my ignorance. Indeed. In that case we have nothing to worry about. I think this thread was just about the case where the above does not apply. In fact if we all agree that devices can build hash looking deeper and that those which can not are just a corner case that would be great. Problem solved :) >> And what is nice about IP encapsulation all GRE src/dst addresses >> can be naturally aggregated so from IGP point of view they still >> look like a single prefix. > > ... and you need a new endpoint prefix (or set-of-addresses) > discovery mechanism. I don't need nothing on top on what I need today. I need to advertise reachability to end point prefix anyway. The difference is that I advertise for example /28 rather then /32. Hi Stewart, > I think that this needs some serious study rather than assertion, > because it is not at all obvious what the LB properties of either > method will be in a DC. The claim was much more general and my reply did not actually narrowed it to DC env. I was more talking about WAN. > In the case of the use of multiple GRE addresses there are > operational and route scaling issues that also need to be considered. I do not see any. Smart networking OS of ingress and egress point can do such encapsulation without any operational overhead. Please think in terms of mGRE. Route scaling issues do not apply. You do not need to inject more then one prefix in any case. Regards, R. From jiangyuanlong@huawei.com Wed May 9 05:01: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 210D321F8494 for ; Wed, 9 May 2012 05:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.13 X-Spam-Level: X-Spam-Status: No, score=-2.13 tagged_above=-999 required=5 tests=[AWL=-0.131, 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 1wTsnz3EWFbB for ; Wed, 9 May 2012 05:01:10 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0E74B21F8493 for ; Wed, 9 May 2012 05:01:10 -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 AFZ15659; Wed, 09 May 2012 08:01:09 -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, 9 May 2012 04:58:57 -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, 9 May 2012 04:58:45 -0700 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.183]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.01.0323.003; Wed, 9 May 2012 19:58:38 +0800 From: Jiangyuanlong To: Sam Cao , "lizhong.jin@zte.com.cn" Subject: RE: Discussion on E-Tree and H-VPLS Thread-Topic: Discussion on E-Tree and H-VPLS Thread-Index: AQHNLdsMt9oBFJa+tkmHXU/YlipjPg== Date: Wed, 9 May 2012 11:58:37 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D41101A@szxeml546-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.70.40.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Wed, 09 May 2012 05:12:37 -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: Wed, 09 May 2012 12:01:15 -0000 Hi Sam, Your statements are misleading at best IMHO, but let us go over the origina= l question from YOU to see what problem is behind. You believe it make no sense that: >>For VPWS access, we should configure Root/Leaf for Spoke PW; >>for VPLS access, we CAN NOT configure Root/Leaf for Spoke PW. Not so correct, speaking more exactly, the dual-VLAN will: In the 1st case, each root/leaf AC (attached to a PE-r) has a corresponding= Spoke PW connecting to the PE-rs, so we configure the Root/Leaf attribute = for the Spoke PW on the PE-rs; In the 2nd case, all root/leaf AC (attached to a MTU-s) share a single Spok= e PW connecting to the PE-rs, so we configure the Root/Leaf attribute for t= he AC on the MTU-s. We exchanged several emails on this topic and reached no agreement on what = you said, just simply take a snip from the email (thank Giles): " On 24/04/2012 10:25, "Sam Cao" wrote: > Giles, > > Configure Root/Leaf on MTU-s and have the MTU-s add the root/Leaf=20 > VLAN. It is correct and reasonable for Fig. 3. We can not configure it=20 > on PE1-rs anymore. Right. =20 > In Fig. 4, shall we configure on PE-r? It seems not reasonable since=20 > on PE-r, it is VPWS. So in Fig. 4, we will have to configure on=20 > PE1-rs. PE1-rs has different behavior in the 2 cases. This does not make = sense for me :). For PE-r each spoke is root or leaf. It can't be both. And yes, it's VPWS= not VPLS. So it makes more sense to configure on the PE-rs. Quite possib= ly the VPWS would be untagged in that instance... " Therefore, the fact is, two of us thought it make sense, and the third rega= rded it as non sense^&^ Let us go over your conclusion again: >> 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. It seems you prefer to configuring root/leaf attribute for Spoke PW on PE-r= s in both cases. >From the previous email to Lizhong, you agreed that in the 1st use case, co= nfiguration of root/leaf attribute for the ACs is further needed on the PE-= r, and I believe in the 2nd use case, configuration of root/leaf attribute for= the ACs is also needed on the MTU-s (otherwise, how can the 2PW use differ= ent PATH?), so that 2 PWs can be set up to carry the E-Tree traffic. Now we can compare the Dual-VLAN with 2PW approach to see what is different= : In the 1st case, both configure the Root/Leaf attribute for the Spoke PW on= the PE-rs; and 2PW will further configure the Root/Leaf attribute for the = AC on the PE-r. In the 2nd case, both configure the Root/Leaf attribute for the AC on the M= TU-s, and 2PW will further configure the Root/Leaf attribute for the Spoke = PW on the PE-rs. In both cases, configuration for Dual-VLAN is simpler, so, does a more comp= lex configuration really make more sense to you? Regards, Yuanlong ---------------------------------------------------------------------- Date: Wed, 9 May 2012 09:40:12 +0800 From: "Sam Cao" To: Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Message-ID: Content-Type: text/plain; charset=3D"gb2312" Hi Lizhong? Thank you very much for your comments. I updated the result on this question. [Lizhong] agree with the above analysis. And we did not say it is a technical problem, but it is an operational problem again. [Sam] I agree. Dual-VLAN does not make sense. I also discussed this with Giles and Yuanlong in another mail, and we reached agreement on this: MTU should know the access mode, VPWS or VPLS, VPWS mode should configure VLAN ID on MTU but VPLS mode can not. I thought this is NOT reasonable :), but w= e can figure this out in draft. It seems ok. [Lizhong] not fully understand. Do you mean, when VPWS accessing for H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf PW) for each AC access? [Sam] Yes. Thanks, Sam -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of l2vpn-request@ietf.org Sent: Monday, May 07, 2012 3:00 AM To: l2vpn@ietf.org Subject: L2vpn Digest, Vol 96, 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=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: Discussion on E-Tree and H-VPLS (Lizhong Jin) 2. RE: Discussion on E-Tree and H-VPLS (Lizhong Jin) ---------------------------------------------------------------------- Message: 1 Date: Sun, 6 May 2012 18:22:14 +0800 From: Lizhong Jin To: yuqun.cao@gmail.com Cc: l2vpn@ietf.org, jiangyuanlong@huawei.com Subject: RE: Discussion on E-Tree and H-VPLS Message-ID: Content-Type: text/plain; charset=3D"iso-8859-1" Hi Sam, See inline below. Thanks Lizhong ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 24 Apr 2012 11:51:26 +0800 > From: "Sam Cao" > To: "'Jiangyuanlong'" > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > Message-ID: > Content-Type: text/plain; charset=3D"GB2312" > > 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 t= o > 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. > [Lizhong] agree with the above analysis. And we did not say it is a technical problem, but it is an operational problem again. > > 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. > [Lizhong] not fully understand. Do you mean, when VPWS accessing for H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf PW) for each AC access? > 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 reall= y > 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 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 bridgin= g > 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 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. > > 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 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. > > 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=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 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). > > 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 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Sun, 6 May 2012 18:25:59 +0800 From: Lizhong Jin To: yuqun.cao@gmail.com Cc: l2vpn@ietf.org, jiangyuanlong@huawei.com Subject: RE: Discussion on E-Tree and H-VPLS Message-ID: Content-Type: text/plain; charset=3D"iso-8859-1" > > > ------------------------------ > > Date: Tue, 24 Apr 2012 11:59:33 +0800 > From: "Sam Cao" > To: "'Alexander Vainshtein'" , > "'Jiangyuanlong'" > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > Message-ID: > Content-Type: text/plain; charset=3D"GB2312" > > 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. > [Lizhong] no, the CW approach is OK. The PE-r with VPWS could support CW, and add leaf/root indication in the packet. Thanks Lizhong > 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, > > ------------------------------ -------------- 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 96, Issue 21 ************************************* ------------------------------ Message: 2 Date: Wed, 9 May 2012 02:26:34 +0000 From: Jiangyuanlong To: Daniel Cohn , "Rogers, Josh" , Lucy yong , Sam Cao , "l2vpn@ietf.org" Subject: OAM problem for 2PW Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410E3C@szxeml546-mbx.china.huawei.com> =09 Content-Type: text/plain; charset=3D"us-ascii" Daniel, I change the Subject to reflect the discussion. Let me give an example adapted simply from fig.10 of RFC 6136 to show what = is the problem for 2PW, assume both UPEs are mixed with root and leaf, and = we need to monitor the connectivity between L1 (leaf) and R1 (root). --- --- / \ ------ ------- ---- / \ |L1 CE-- / \ / \ / \ --CE R1| \ / \ / \ / \ / \ / \ / --- --UPE NPE NPE UPE-- --- \ / \ / \ / \ / \ / \ / ------ ------- ---- Customer OAM Domain (C) MEP---MIP--------------------------------MIP---MEP SP OAM SP OAM SP OAM (D1) MEP-MIP--MEP|MEP-------MEP|MEP-----MEP domain domain domain Operator Operator Operator (E) MEP-MIP--MEP|MEP-------MEP|MEP-----MEP OAM domain OAM domain OAM domain MPLS OAM MPLS OAM (F) MEP--MIP-----MEP--MIP--MEP domain domain If we find a problem in the Customer OAM domain for (L1-R1), and server lay= er need to be inverstigated further to locate the network problem. In the 2PW approach, we have 2 PWs (root PW and leaf PW) in every Operator = OAM domain and need to associate one (maybe both?) with this customer servi= ce. Just consider a single OAM domain: In the forward direction, the traffic is from leaf to root, it seems the le= af PW needs to be associated with this service. On the other hand, in the reverse direction, the traffic is from root to le= af, it seems the root PW needs to be associated with this service. But how can you configure a pair of MEPs across both root and leaf PWs? (I = believe both root and leaf PW have a pair of MEPs respectively) If multiple MPLS OAM domains are considered, things will become more intere= sting. Further comments are in line. Thanks, Yuanlong -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Tuesday, May 08, 2012 9:59 PM To: Jiangyuanlong; Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 ------------------------------ Message: 3 Message-ID: difference in the maintenance operations for root/leaf/normal PW. [JY] it is true for a single PW in a single OAM domain, but when they are c= =3D oupled to provide an end to end E-Tree service, things will be quite differ= =3D ent as shown above. Root/leaf is signaled in LDP so mismatch can be detected and notified to operator. [JY] LDP seems work in a single OAM domain, and mismatch point is inter-OAM= =3D -domain. Moreover, mismatch is supposed to be detected by OAM. Did I miss s= =3D omething? DC -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=3D20 Sent: Tuesday, May 08, 2012 4:38 PM To: Daniel Cohn; Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 Except PW numbers, now PW attributes also needs to be considered: root, leaf or normal. Can the root or leaf PW be connected to the normal PW? Or just connect root to root, and leaf to leaf? Without signalling, this will pose a great challenge to configure the OAM correctly. -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=3D20 Sent: Tuesday, May 08, 2012 9:29 PM To: Jiangyuanlong; Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 Yuanlong, I don't see the additional complexity. Existing PW maintenance processes at the operator can take care of the additional root/leaf PWs exactly like they do today. Only they will have some more PWs to maintain (not twice as much, since most PEs are typically leaf-only and therefore have only a root PW per E-Tree instance) And service maintenance processes should be extended to maintain root and leaf services using E-OAM, both for the 2-VLAN and multi-PW solutions. DC -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=3D20 Sent: Tuesday, May 08, 2012 4:23 PM To: Daniel Cohn; Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 Daniel, RFC 6136 provides the VPLS OAM reqs and framework, and Sec. 10.1. gives the typical VPLS OAM Operational Scenarios: --- --- / \ ------ ------- ---- / \ | A CE-- / \ / \ / \ --CE A | \ / \ / \ / \ / \ / \ / --- --UPE NPE NPE UPE-- --- \ / \ / \ / \ / \ / \ / ------ ------- ---- Customer OAM Domain (C) MEP---MIP--------------------------------MIP---MEP Service Provider (SP) OAM Domain (D) MEP--------MIP-----------MIP-------MEP SP OAM SP OAM SP OAM (D1) MEP-MIP--MEP|MEP-------MEP|MEP-----MEP domain domain domain Operator Operator Operator (E) MEP-MIP--MEP|MEP-------MEP|MEP-----MEP OAM domain OAM domain OAM domain MPLS OAM MPLS OAM (F) MEP--MIP-----MEP--MIP--MEP domain domain Figure 10: VPLS OAM Domains, MEPs, and MIPs It seems OAM configurations in Scenario D1) and E) for 2PW approach will be much complicated and error prone, since E-Tree OAM now needs to interwork with one of these two PWs' OAM (maybe both, I am afraid). For scenario F), the concatanation of two MPLS OAM also needs to be very careful as 4 PWs and 3 types (i.e, root/leaf/normal) may be involved there. Regards, Yuanlong -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=3D20 Sent: Tuesday, May 08, 2012 4:49 PM To: Jiangyuanlong; Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 Inline -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=3D20 Sent: Tuesday, May 08, 2012 11:42 AM To: Daniel Cohn; Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 I don't think so. There may be different layers of OAM applicable to a service. Such as LSP layer, PW layer, and service layer. [DC] Agreed Now you cannot use a single LSP OAM to monitor the server layer of the E-Tree service (as 2 LSP may be involved). And the service layer of OAM for E-Tree may be distributed to different LSP paths. [DC] For E-Tree service OAM, you would perform OAM actions from MEPs associated to root or leaf ACs, so the E-OAM frames would naturally follow the root or leaf pseudowires and the LSPs that transport them. I don't see a limitation here. -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=3D20 Sent: Tuesday, May 08, 2012 4:28 PM To: Jiangyuanlong; Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 Yuanlong, isn't this orthogonal to the issues we are discussing? I mean, there are different mechanisms to troubleshoot PWs, all of which are applicable to root/leaf PWs as to any other PWs. Or is there any specific limitation on root/leaf PW troubleshooting, compared to "regular" PWs used in VPLSs? Thanks, Daniel -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Jiangyuanlong Sent: Tuesday, May 08, 2012 7:04 AM To: Rogers, Josh; Lucy yong; Sam Cao; l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 96, Issue 15 Josh,=3D20 Just some comments on this part: [JR] I don't see this any more of a problem than troubleshooting one. If LDP is used, a simple mols traceroute shows the path that ALL PW's to that PE take, regardless of which service (this VPLS or another VPLS instance). If RSVP is used, there should be a route-object that shows me the path, and allows me to troubleshoot. Additionally, if I wanted to have traffic engineering that impacted root-sourced and leaf-sourced traffic differently, I can do that with multi-PW, where I could not (save for ingress/egress) with the 2VLAN approach. PE should report signaling on second PW same as it does for the 100th PW between PE's. Again, I don't see the problem you are alluding to. I suppose you are referring to LSP Ping on the LSP layer, yes, it can oversee all the PWs in this LSP. If both root and leaf PW are in the same LSP, it can work. But there may well be multiple LSPs between a pair of PEs, and root/leaf PW may be transported on different LSPs. Another difficulty is, if ECMP is deployed and PW label as a bottom label is used for hashing, the OAM message may be load balanced on different paths. With regard to TE, you could use DS-TE, just as Lucy said, two PW do not guarantee they are traffic engineered. Thanks Yuanlong ...snipped.... ------------------------------ Message: 4 Date: Wed, 9 May 2012 10:38:56 +0800 From: "Sam Cao" To: Subject: RE: L2vpn Digest, Vol 96, Issue 23 Message-ID: <264B3435378241FA9BE008620B246DEA@R01842> Content-Type: text/plain; charset=3D"gb2312" Josh, Optimization on ingress PE is possible. Last week I thought this over and have a clear idea. We maybe discuss this in another mail, and if all agree, we can add this into new draft. As you know, Multi-PW negotiates AC type vi= a signal protocol, so one PE can know AC types of its peer, and then we can solve the problem you raised. Thanks, Sam -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of l2vpn-request@ietf.org Sent: Monday, May 07, 2012 2:37 PM To: l2vpn@ietf.org Subject: L2vpn Digest, Vol 96, Issue 23 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? (Rogers, Josh) 2. RE: The status of the approaches to the E-Tree solution? (Jiangyuanlong) ---------------------------------------------------------------------- Message: 1 Date: Mon, 7 May 2012 00:09:07 -0400 From: "Rogers, Josh" To: Jiangyuanlong , Daniel Cohn , "Fedyk, Donald (Don)" , "Henderickx, Wim (Wim)" , Lucy yong Cc: "l2vpn@ietf.org" Subject: Re: The status of the approaches to the E-Tree solution? Message-ID: Content-Type: text/plain; charset=3D"iso-8859-2" So, if you can imagine three PE's, PE1, PE2 and PE3. PE1 has a root AC, R1 and a leaf AC, L1. PE2 also has a root AC, R2, and a leaf AC, L2. PE3 has a leaf AC, L3. Consider an unknown unicast frame from the leaf site L1, and also another unknown unicast frame from R1 entering. With the 2VLAN method (to my best understanding): - frame from L1 enters PE1, goes into a PW to PE2 and a PW to PE3, arrives at PE2 which decides that it should be flooded out all Root AC's, based on the S-tag. It also arrives at PE3, where it is dropped because there are no root AC's. - frame from R1 enters PE1, goes into a PW to PE2 and a PW to PE3, arrives at PE2 which decides that it should be flooded out all AC's, based on S-tag. It also arrives at PE3 where it is forwarded to all root AC's. With Multi-PW method: - frame from L1 enters PE1, which decides to forward the frame out the 'root' PW to PE2, which in turn floods out all Root AC's, based on arriving PW type. Frame is NOT sent to PE3, since there is no PW built to the PE which has no root AC's. - frame from R1 enters PE1, which decides to flood out both 'root' PW and 'leaf' PW to PE2, which in turn floods out the same AC types, based on arriving PW type. It also arrives at PE3 where it is forwarded to all root AC's. I suppose optimization could be done on the ingress PE to decide that there is no need to 'flood' root-sourced frames to two PW's that have the same egress PE, but instead to only forward to the 'root' type PW, when both exist, because we know that the egress PE will flood frames from root-sourced PW's out both leaf and root AC's. In this example, the same frame from R1 is duplicated on the PE1-PE2 path (if no optimization is done.), where it would not be with the 2VLAN method. With 2VLAN, ethernet type PW's cannot be used (must be vlan type PW's, otherwise how would we classify source AC-type?), which means there is overhead on EVERY frame to add the s-tag for the sole purpose of classifying the frame. If optimization is done, then each ingress PE knows what types of AC's are on each egress PE, and only forwards the appropriate frame, if no optimization then it is dropped at the egress PE. In short, both are either not 100% inefficient, or are additionally complex due to 'optimization'. I may have gotten my details off on the optimization piece of the 2VLAN method, please correct me if I didn't get the details 100% correct. -Josh On 5/6/12 9:07 PM, "Jiangyuanlong" wrote: >Could you or any other co-authors of 2PW give some more hints so that it >can be better understood? > >In draft-ram-l2vpn-etree-multiple-pw-01, I can only find a single >sentence most to the point: > "An egress PE SHALL NOT deliver a frame originated at a leaf AC to > another leaf AC." > >But it seems there is not a description of "traffic is split/separated >(by psuedowire) on the ingress PE" at all. > >On the contrary, in draft-jiang-l2vpn-vpls-pe-etree-05, Section 5.3.3 >details the scenario and forwarding plane how the leaf traffic is >seperated and filtered on the ingress PE, and Section 6 details the >specific supports in the control plane. > >Thanks >Yuanlong > > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Friday, May 04, 2012 8:27 PM >To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >(Wim); Lucy yong >Cc: l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >also separate the leaf traffic in the ingress PE and filter it there >(already detailed in the Optimization Mode in the I-D); if the egress PE >is attached with pure roots or with both roots and leafs, it seems all >traffic must be transported to the egress PE and be filtered there, I see >no difference in behaviour for these solutions. Or did I miss something? > > >The point is with the multi-PW method the traffic is split/separated (by >psuedowire) on the ingress PE, rather than the egress. The distinction is >2VLAN will 'classify' the frame on the ingress PE, so that the egress PE >knows how to forward it to the appropriate AC's. > >Both methods have inefficiencies (one duplicates traffic for transport, >while the other transports where it doesn't need to go). I like the idea >of classify and forwarding on the ingress PE, rather than marking it on >the ingress, and deciding on the egress. > >-Josh > > > >On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: > >>Josh, thank you for the comments, please see my further comments with >>[JY2]. >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Thursday, May 03, 2012 11:27 PM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>requirements from MEF, it has nothing to do with the solutions. Could you >>give a hint on how you can provision this service E-NNI otherwise? BTW, >>if >>configuring or signalling two PWs is not a problem, why configuring or >>signalling two VLANs will become a problem? After all, more nodes may >>need >>to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >>2VLAN (only T-PEs). >> >> >>There is no other way (if both MPLS domains are part of the same ETREE, >>rather than doing something more like H-VPLS, where one domain has point >>to points to the other domain which handles the ETREE instance) if you >>are >>using an ENNI. The other method, (not mentioned earlier) is tying the >>two >>MPLS domains together via labeled unicast (much preferred over E-NNI in >>my >>opinion) >> >>Configuring two VLAN's isn't really a 'problem' any more than two PW's. >>I >>wasn't saying that configuring two VLAN's was difficult, I was objecting >>to the statement that configuring two PW's is difficult. >> >>[JY2] Thanks, I see your point. I take the example of 2PW configuration >>just to show that using fixed global values to simplify configuration >>makes no sense. Personally I also don't think configuration is a problem >>for both solutions. >> >>I find the differences between these two methods rather slight. The >>'tie-breaker' for me is by placing the forwarding decision on the ingress >>PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >>more control over where the traffic goes, and in my mind it provides a >>cleaner destination between customer traffic and forwarding plane. I'm >>accustomed to looking at a psuedowire and knowing where its going, with >>the 2vlan method, I can see the psuedowire, but must go to the egress PE >>to see if it will be dropped there, or forwarded to one or more AC's. >> >>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>also separate the leaf traffic in the ingress PE and filter it there >>(already detailed in the Optimization Mode in the I-D); if the egress PE >>is attached with pure roots or with both roots and leafs, it seems all >>traffic must be transported to the egress PE and be filtered there, I see >>no difference in behaviour for these solutions. Or did I miss something? >> >>Again, the difference here is slight, and I would honestly be happy to >>see >>either of them come to fruition. Please don't infer that I think the >>2vlan method is 'bad' or has intrinsic problems, because I don't believe >>that. I just prefer the multi-PW method. >> >> >>-Josh >> >> >>On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: >> >>>Josh, please see my comments in line. >>> >>>Thanks >>>Yuanlong >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Thursday, May 03, 2012 10:51 AM >>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>(Wim); Lucy yong >>>Cc: l2vpn@ietf.org >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Yuanlong, >>> >>>Or better yet, include in the draft a 'standard' value for root sourced >>>VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You would al= so >>>have to require the the implementation NOT use global VLAN's, however >>>(since each instance would be using the same values). In this way, no >>>signaling or manual configuration is required for remote PE's to know >>>how >>>to classify traffic. >>>[JY] Indeed, we discussed this possibility during the f2f meeting in >>>Paris. But, there are some restrictions as you mentioned, and >>>furthermore: >>>1) Some vendors already used S-VLAN to distinguish their VSIs in the PE; >>>2) Forwarding plane of a PE needs to be revised to be aware of this VLAN >>>ID. >>>Therefore, this 'standard value' approach seems more disruptive compared >>>with the other means and not a good candidate option. >>> >>>Regarding switching PE's? Multi-PW means more than one PW, yes. I >>>don't >>>see this as a real problem. In general, design should try and avoid >>>using >>>S-PE's, but if you must, its going to mean extra work, no matter how you >>>look at it. Two PW's for each Etree being switched instead of one is >>>not >>>alarming or concerning to me. On the other hand, if you use a dot1q >>>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's >>>an >>>two egress VLAN's if you want the Etree to be handled on both sides (and >>>if you use the 'standard' VID's as I mentioned above, you'd have to do >>>mapping to non-standard and back) >>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>requirements from MEF, it has nothing to do with the solutions. Could >>>you >>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>if configuring or signalling two PWs is not a problem, why configuring >>>or >>>signalling two VLANs will become a problem? After all, more nodes may >>>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>>with 2VLAN (only T-PEs). >>> >>>In general, I still prefer multi-PW, primarily because I prefer the >>>separation of the traffic in the network's forwarding plane, rather than >>>shipping it everywhere and deciding whether to forward to the AC when it >>>gets to the egress PE. I'm having a hard time putting my finger exactly >>>on what it is, or articulating the idea, but it seems that by having the >>>traffic placed into two psuedowires, I have more flexibility and ease of >>>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>>PW's could really change that perception. >>>[JY] Are you saying that we need to develop a totally new forwarding >>>plane rather than using the Ethernet forwarding plane as described in >>>the >>>existing work? >>> >>>I hope we can move forward with one of these soon, >>>[JY] me too. >>> >>>Josh >>> >>> >>>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >>> >>>>Daniel, >>>> >>>>Not aware that we had a discussion on this before, but IMHO the >>>>allocation of internal S-VLAN can be automatic, and manuel >>>>configuration >>>>of this mapping may not be needed at all. For example, an S-VLAN >>>>allocation module in the management plane in a PE can do this kind of >>>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>>way from a free S-VLAN ID pool. Once the interal S-VLANs are allocated, >>>>the mapping is determined and no other configuration is needed. >>>> >>>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>>allocate >>>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to allocate >>>>two S-VLANs in the VPLS domain. >>>> >>>>On the other hand, for the multi-PW approach, two PWs need to be >>>>configured for a E-Tree service. When MS-PW is used in the network, for >>>>every S-PE, we need to configure two ingress PW segments and two egress >>>>PW segments. In this case, I don't think we need to use fixed PW labels >>>>across the network for fear of configuration complexity. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 8:01 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Inline. >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 12:30 PM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, Please see my comments in line. >>>> >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 3:55 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Yuanlong, >>>> >>>>The problem is not with the total number of S-VLAN IDs, I agree that >>>>normally there won't be more than 2047. The problem is that if you >>>>don't >>>>support all VLAN IDs, you need S-VLAN space coordination with the >>>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to >>>>2047". >>>>Which won't always be in line with an existing deployment. >>>>[JY] This is not the case. If the total number is no more than 2047, it >>>>surely can be supported. The S-VLAN space of user domain is totally >>>>different from the S-VLAN in the provider domain and they can be >>>>overlapped, I don't see why we need S-VLAN space coordination between >>>>them. >>>> >>>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>>fixed, and therefore the IEEE S-VID that can be supported is also >>>>fixed. >>>> >>>>Of course you can configure the mapping in each PE according to >>>>operator >>>>requirements but as we discussed before this increases complexity. >>>> >>>>Relying on PBB-VPLS imposes additional limitations on backward >>>>compatibility. >>>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>>think they may well need MAC-in-MAC in their networks for the >>>>scalability issue. As you know, only PBB VPLS can provide both. >>>> >>>>Daniel >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 5:07 AM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, >>>> >>>>As you can see, both cases are discussed in the I-D. >>>> >>>>With regard to case 1) (that is, S-VLAN translation), since the access >>>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>>they need to be configured on a PE anyway, and as the past emails by >>>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>>mapping. >>>> >>>>With regard to S-VID space reduction, the constraint is valid only when >>>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>>typical and with no such limits as we already discussed in the f2f >>>>meeting. >>>> >>>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>>described (not sure this is a valid use case in real life), PBB-VPLS >>>>can >>>>still be used. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Monday, April 30, 2012 10:34 PM >>>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>Jiangyuanlong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>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] >>>>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 >>>> >>>>---------------------------------------------------------------------- >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to >>>copyright belonging to Time Warner Cable. This E-mail is intended solely >>>for the use of the individual or entity to which it is addressed. If you >>>are not the intended recipient of this E-mail, you are hereby notified >>>that any dissemination, distribution, copying, or action taken in >>>relation to the contents of and attachments to this E-mail is strictly >>>prohibited and may be unlawful. If you have received this 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 and any of its attachments may contain 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. ------------------------------ Message: 2 Date: Mon, 7 May 2012 06:34:00 +0000 From: Jiangyuanlong To: "Rogers, Josh" , Daniel Cohn , "Fedyk, Donald (Don)" , "Henderickx, Wim (Wim)" , Lucy yong Cc: "l2vpn@ietf.org" Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: =09 <3B0A1BED22CAD649A1B3E97BE5DDD68B1D410770@szxeml546-mbx.china.huawei.com> =09 Content-Type: text/plain; charset=3D"iso-8859-2" -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com]=20 Sent: Monday, May 07, 2012 12:09 PM To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong Cc: l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? So, if you can imagine three PE's, PE1, PE2 and PE3. PE1 has a root AC, R1 and a leaf AC, L1. PE2 also has a root AC, R2, and a leaf AC, L2. PE3 has a leaf AC, L3. Consider an unknown unicast frame from the leaf site L1, and also another unknown unicast frame from R1 entering. With the 2VLAN method (to my best understanding): - frame from L1 enters PE1, goes into a PW to PE2 and a PW to PE3, arrives at PE2 which decides that it should be flooded out all Root AC's, based on the S-tag. It also arrives at PE3, where it is dropped because there are no root AC's. [JY] Since PE3 is a leaf-only node, the PW from PE1 to PE3 will work in Optimized-Mode. According to Section 5.3.3 of draft-jiang-l2vpn-vpls-pe-etree-05, it will be dropped before arriving at this PW. Therefore, this frame will not arrive at PE3. - frame from R1 enters PE1, goes into a PW to PE2 and a PW to PE3, arrives at PE2 which decides that it should be flooded out all AC's, based on S-tag. It also arrives at PE3 where it is forwarded to all root AC's. With Multi-PW method: - frame from L1 enters PE1, which decides to forward the frame out the 'root' PW to PE2, which in turn floods out all Root AC's, based on arriving PW type. Frame is NOT sent to PE3, since there is no PW built to the PE which has no root AC's. [JY] According to my understanding of the following description in draft-ram-l2vpn-etree-multiple-pw-01: "It should be noted that in a full-mesh VPLS (as opposed to H-VPLS), the following VSI pair types do not require two interconnecting PWs: Root-only VSI <-> any VSI: only root PW required Leaf-only VSI <-> leaf-only VSI: no PWs required" There should be 2 PWs be set up between PE1 and PE3, since this is a case o= f "Root & Leaf mixed VSI <-> leaf-only VSI" and not listed in the none-two- interconnecting-PWs criteria. Therefore, this frame will be sent to PE3 twice (one on root PW, another on leaf PW) IMO. Of course, the other author= s of draft-ram-l2vpn-etree-multiple-pw-01 may have more to say on this point. - frame from R1 enters PE1, which decides to flood out both 'root' PW and 'leaf' PW to PE2, which in turn floods out the same AC types, based on arriving PW type. It also arrives at PE3 where it is forwarded to all root AC's. [JY] It contradicts your first statement that "there is no PW built to the PE which has no root AC's".=20 I suppose optimization could be done on the ingress PE to decide that there is no need to 'flood' root-sourced frames to two PW's that have the same egress PE, but instead to only forward to the 'root' type PW, when both exist, because we know that the egress PE will flood frames from root-sourced PW's out both leaf and root AC's. In this example, the same frame from R1 is duplicated on the PE1-PE2 path (if no optimization is done.), where it would not be with the 2VLAN method. With 2VLAN, ethernet type PW's cannot be used (must be vlan type PW's, otherwise how would we classify source AC-type?), which means there is overhead on EVERY frame to add the s-tag for the sole purpose of classifying the frame. If optimization is done, then each ingress PE knows what types of AC's are on each egress PE, and only forwards the appropriate frame, if no optimization then it is dropped at the egress PE. In short, both are either not 100% inefficient, or are additionally complex due to 'optimization'. I may have gotten my details off on the optimization piece of the 2VLAN method, please correct me if I didn't get the details 100% correct. -Josh On 5/6/12 9:07 PM, "Jiangyuanlong" wrote: >Could you or any other co-authors of 2PW give some more hints so that it >can be better understood? > >In draft-ram-l2vpn-etree-multiple-pw-01, I can only find a single >sentence most to the point: > "An egress PE SHALL NOT deliver a frame originated at a leaf AC to > another leaf AC." > >But it seems there is not a description of "traffic is split/separated >(by psuedowire) on the ingress PE" at all. > >On the contrary, in draft-jiang-l2vpn-vpls-pe-etree-05, Section 5.3.3 >details the scenario and forwarding plane how the leaf traffic is >seperated and filtered on the ingress PE, and Section 6 details the >specific supports in the control plane. > >Thanks >Yuanlong > > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Friday, May 04, 2012 8:27 PM >To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >(Wim); Lucy yong >Cc: l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >also separate the leaf traffic in the ingress PE and filter it there >(already detailed in the Optimization Mode in the I-D); if the egress PE >is attached with pure roots or with both roots and leafs, it seems all >traffic must be transported to the egress PE and be filtered there, I see >no difference in behaviour for these solutions. Or did I miss something? > > >The point is with the multi-PW method the traffic is split/separated (by >psuedowire) on the ingress PE, rather than the egress. The distinction is >2VLAN will 'classify' the frame on the ingress PE, so that the egress PE >knows how to forward it to the appropriate AC's. > >Both methods have inefficiencies (one duplicates traffic for transport, >while the other transports where it doesn't need to go). I like the idea >of classify and forwarding on the ingress PE, rather than marking it on >the ingress, and deciding on the egress. > >-Josh > > > >On 5/3/12 8:20 PM, "Jiangyuanlong" wrote: > >>Josh, thank you for the comments, please see my further comments with >>[JY2]. >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Thursday, May 03, 2012 11:27 PM >>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>(Wim); Lucy yong >>Cc: l2vpn@ietf.org >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>requirements from MEF, it has nothing to do with the solutions. Could you >>give a hint on how you can provision this service E-NNI otherwise? BTW, >>if >>configuring or signalling two PWs is not a problem, why configuring or >>signalling two VLANs will become a problem? After all, more nodes may >>need >>to be configured or signalled for 2PW (T-PEs and S-PEs) compared with >>2VLAN (only T-PEs). >> >> >>There is no other way (if both MPLS domains are part of the same ETREE, >>rather than doing something more like H-VPLS, where one domain has point >>to points to the other domain which handles the ETREE instance) if you >>are >>using an ENNI. The other method, (not mentioned earlier) is tying the >>two >>MPLS domains together via labeled unicast (much preferred over E-NNI in >>my >>opinion) >> >>Configuring two VLAN's isn't really a 'problem' any more than two PW's. >>I >>wasn't saying that configuring two VLAN's was difficult, I was objecting >>to the statement that configuring two PW's is difficult. >> >>[JY2] Thanks, I see your point. I take the example of 2PW configuration >>just to show that using fixed global values to simplify configuration >>makes no sense. Personally I also don't think configuration is a problem >>for both solutions. >> >>I find the differences between these two methods rather slight. The >>'tie-breaker' for me is by placing the forwarding decision on the ingress >>PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get >>more control over where the traffic goes, and in my mind it provides a >>cleaner destination between customer traffic and forwarding plane. I'm >>accustomed to looking at a psuedowire and knowing where its going, with >>the 2vlan method, I can see the psuedowire, but must go to the egress PE >>to see if it will be dropped there, or forwarded to one or more AC's. >> >>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can >>also separate the leaf traffic in the ingress PE and filter it there >>(already detailed in the Optimization Mode in the I-D); if the egress PE >>is attached with pure roots or with both roots and leafs, it seems all >>traffic must be transported to the egress PE and be filtered there, I see >>no difference in behaviour for these solutions. Or did I miss something? >> >>Again, the difference here is slight, and I would honestly be happy to >>see >>either of them come to fruition. Please don't infer that I think the >>2vlan method is 'bad' or has intrinsic problems, because I don't believe >>that. I just prefer the multi-PW method. >> >> >>-Josh >> >> >>On 5/3/12 12:07 AM, "Jiangyuanlong" wrote: >> >>>Josh, please see my comments in line. >>> >>>Thanks >>>Yuanlong >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Thursday, May 03, 2012 10:51 AM >>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim >>>(Wim); Lucy yong >>>Cc: l2vpn@ietf.org >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Yuanlong, >>> >>>Or better yet, include in the draft a 'standard' value for root sourced >>>VID and leaf sourced VID. i.e., 4093=3Droot, 4094=3Dleaf. You would al= so >>>have to require the the implementation NOT use global VLAN's, however >>>(since each instance would be using the same values). In this way, no >>>signaling or manual configuration is required for remote PE's to know >>>how >>>to classify traffic. >>>[JY] Indeed, we discussed this possibility during the f2f meeting in >>>Paris. But, there are some restrictions as you mentioned, and >>>furthermore: >>>1) Some vendors already used S-VLAN to distinguish their VSIs in the PE; >>>2) Forwarding plane of a PE needs to be revised to be aware of this VLAN >>>ID. >>>Therefore, this 'standard value' approach seems more disruptive compared >>>with the other means and not a good candidate option. >>> >>>Regarding switching PE's? Multi-PW means more than one PW, yes. I >>>don't >>>see this as a real problem. In general, design should try and avoid >>>using >>>S-PE's, but if you must, its going to mean extra work, no matter how you >>>look at it. Two PW's for each Etree being switched instead of one is >>>not >>>alarming or concerning to me. On the other hand, if you use a dot1q >>>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's >>>an >>>two egress VLAN's if you want the Etree to be handled on both sides (and >>>if you use the 'standard' VID's as I mentioned above, you'd have to do >>>mapping to non-standard and back) >>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service >>>requirements from MEF, it has nothing to do with the solutions. Could >>>you >>>give a hint on how you can provision this service E-NNI otherwise? BTW, >>>if configuring or signalling two PWs is not a problem, why configuring >>>or >>>signalling two VLANs will become a problem? After all, more nodes may >>>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared >>>with 2VLAN (only T-PEs). >>> >>>In general, I still prefer multi-PW, primarily because I prefer the >>>separation of the traffic in the network's forwarding plane, rather than >>>shipping it everywhere and deciding whether to forward to the AC when it >>>gets to the egress PE. I'm having a hard time putting my finger exactly >>>on what it is, or articulating the idea, but it seems that by having the >>>traffic placed into two psuedowires, I have more flexibility and ease of >>>configuration when it comes to E-NNI's, service multiplexed UNI's, and >>>H-VPLS (both psuedowire based and vlan based). Of course my 'ease of >>>configuration' statement assumes BGP-VPLS, as was pointed out earlier >>>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of >>>PW's could really change that perception. >>>[JY] Are you saying that we need to develop a totally new forwarding >>>plane rather than using the Ethernet forwarding plane as described in >>>the >>>existing work? >>> >>>I hope we can move forward with one of these soon, >>>[JY] me too. >>> >>>Josh >>> >>> >>>On 5/2/12 9:30 PM, "Jiangyuanlong" wrote: >>> >>>>Daniel, >>>> >>>>Not aware that we had a discussion on this before, but IMHO the >>>>allocation of internal S-VLAN can be automatic, and manuel >>>>configuration >>>>of this mapping may not be needed at all. For example, an S-VLAN >>>>allocation module in the management plane in a PE can do this kind of >>>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a >>>>single external S-VLAN ID) in a topdown, bottom-up, or just any random >>>>way from a free S-VLAN ID pool. Once the interal S-VLANs are allocated, >>>>the mapping is determined and no other configuration is needed. >>>> >>>>The only difference from RFC 6246 is, for E-LAN, we only need to >>>>allocate >>>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to allocate >>>>two S-VLANs in the VPLS domain. >>>> >>>>On the other hand, for the multi-PW approach, two PWs need to be >>>>configured for a E-Tree service. When MS-PW is used in the network, for >>>>every S-PE, we need to configure two ingress PW segments and two egress >>>>PW segments. In this case, I don't think we need to use fixed PW labels >>>>across the network for fear of configuration complexity. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 8:01 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Inline. >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 12:30 PM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, Please see my comments in line. >>>> >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Wednesday, May 02, 2012 3:55 PM >>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy >>>>yong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Yuanlong, >>>> >>>>The problem is not with the total number of S-VLAN IDs, I agree that >>>>normally there won't be more than 2047. The problem is that if you >>>>don't >>>>support all VLAN IDs, you need S-VLAN space coordination with the >>>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to >>>>2047". >>>>Which won't always be in line with an existing deployment. >>>>[JY] This is not the case. If the total number is no more than 2047, it >>>>surely can be supported. The S-VLAN space of user domain is totally >>>>different from the S-VLAN in the provider domain and they can be >>>>overlapped, I don't see why we need S-VLAN space coordination between >>>>them. >>>> >>>>[DC] If we use global S-VIDs in the VPLS (to simply mapping >>>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be >>>>fixed, and therefore the IEEE S-VID that can be supported is also >>>>fixed. >>>> >>>>Of course you can configure the mapping in each PE according to >>>>operator >>>>requirements but as we discussed before this increases complexity. >>>> >>>>Relying on PBB-VPLS imposes additional limitations on backward >>>>compatibility. >>>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I >>>>think they may well need MAC-in-MAC in their networks for the >>>>scalability issue. As you know, only PBB VPLS can provide both. >>>> >>>>Daniel >>>> >>>>-----Original Message----- >>>>From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >>>>Sent: Wednesday, May 02, 2012 5:07 AM >>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Hi Daniel, >>>> >>>>As you can see, both cases are discussed in the I-D. >>>> >>>>With regard to case 1) (that is, S-VLAN translation), since the access >>>>VLAN and the E-Tree attributes (root/leaf) are services' attributes, >>>>they need to be configured on a PE anyway, and as the past emails by >>>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1 >>>>mapping. >>>> >>>>With regard to S-VID space reduction, the constraint is valid only when >>>>a global VLAN space is used per PE, in fact, multi-VLAN space is more >>>>typical and with no such limits as we already discussed in the f2f >>>>meeting. >>>> >>>>Even if there are 4094 S-VLANs in a single E-Tree access as you >>>>described (not sure this is a valid use case in real life), PBB-VPLS >>>>can >>>>still be used. >>>> >>>>Regards, >>>>Yuanlong >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>>Sent: Monday, April 30, 2012 10:34 PM >>>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong; >>>>Jiangyuanlong; josh.rogers@twcable.com >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>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] >>>>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 >>>> >>>>---------------------------------------------------------------------- >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to >>>copyright belonging to Time Warner Cable. This E-mail is intended solely >>>for the use of the individual or entity to which it is addressed. If you >>>are not the intended recipient of this E-mail, you are hereby notified >>>that any dissemination, distribution, copying, or action taken in >>>relation to the contents of and attachments to this E-mail is strictly >>>prohibited and may be unlawful. If you have received this 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 and any of its attachments may contain 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. ------------------------------ _______________________________________________ L2vpn mailing list L2vpn@ietf.org https://www.ietf.org/mailman/listinfo/l2vpn End of L2vpn Digest, Vol 96, Issue 23 ************************************* ------------------------------ _______________________________________________ L2vpn mailing list L2vpn@ietf.org https://www.ietf.org/mailman/listinfo/l2vpn End of L2vpn Digest, Vol 96, Issue 52 ************************************* From jiangyuanlong@huawei.com Wed May 9 05:33: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 346C921F856A for ; Wed, 9 May 2012 05:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[AWL=0.172, 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 ENt76a8RDV1n for ; Wed, 9 May 2012 05:33:28 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6C321F84FC for ; Wed, 9 May 2012 05:33:28 -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 AFZ17383; Wed, 09 May 2012 08:33:28 -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, 9 May 2012 05:30:52 -0700 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 9 May 2012 05:30:55 -0700 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.183]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Wed, 9 May 2012 20:30:44 +0800 From: Jiangyuanlong To: Jiangyuanlong , Sam Cao , "lizhong.jin@zte.com.cn" Subject: RE: Discussion on E-Tree and H-VPLS Thread-Topic: Discussion on E-Tree and H-VPLS Thread-Index: AQHNLd+J+NpjYPphoEGHmHDj8AOcJg== Date: Wed, 9 May 2012 12:30:43 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D41103E@szxeml546-mbx.china.huawei.com> References: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.40.73] 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, 09 May 2012 12:33:29 -0000 Seems too big to be received, snipped and send again. Sorry for the inconve= nience. -----Original Message----- From: Jiangyuanlong=20 Sent: Wednesday, May 09, 2012 7:59 PM To: 'Sam Cao'; 'lizhong.jin@zte.com.cn' Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Sam, Your statements are misleading at best IMHO, but let us go over the origina= l question from YOU to see what problem is behind. You believe it make no sense that: >>For VPWS access, we should configure Root/Leaf for Spoke PW; >>for VPLS access, we CAN NOT configure Root/Leaf for Spoke PW. Not so correct, speaking more exactly, the dual-VLAN will: In the 1st case, each root/leaf AC (attached to a PE-r) has a corresponding= Spoke PW connecting to the PE-rs, so we configure the Root/Leaf attribute = for the Spoke PW on the PE-rs; In the 2nd case, all root/leaf AC (attached to a MTU-s) share a single Spok= e PW connecting to the PE-rs, so we configure the Root/Leaf attribute for t= he AC on the MTU-s. We exchanged several emails on this topic and reached no agreement on what = you said, just simply take a snip from the email (thank Giles): " On 24/04/2012 10:25, "Sam Cao" wrote: > Giles, > > Configure Root/Leaf on MTU-s and have the MTU-s add the root/Leaf=20 > VLAN. It is correct and reasonable for Fig. 3. We can not configure it=20 > on PE1-rs anymore. Right. =20 > In Fig. 4, shall we configure on PE-r? It seems not reasonable since=20 > on PE-r, it is VPWS. So in Fig. 4, we will have to configure on=20 > PE1-rs. PE1-rs has different behavior in the 2 cases. This does not make = sense for me :). For PE-r each spoke is root or leaf. It can't be both. And yes, it's VPWS= not VPLS. So it makes more sense to configure on the PE-rs. Quite possib= ly the VPWS would be untagged in that instance... " Therefore, the fact is, two of us thought it make sense, and the third rega= rded it as non sense^&^ Let us go over your conclusion again: >> 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. It seems you prefer to configuring root/leaf attribute for Spoke PW on PE-r= s in both cases. >From the previous email to Lizhong, you agreed that in the 1st use case, co= nfiguration of root/leaf attribute for the ACs is further needed on the PE-= r, and I believe in the 2nd use case, configuration of root/leaf attribute for= the ACs is also needed on the MTU-s (otherwise, how can the 2PW use differ= ent PATH?), so that 2 PWs can be set up to carry the E-Tree traffic. Now we can compare the Dual-VLAN with 2PW approach to see what is different= : In the 1st case, both configure the Root/Leaf attribute for the Spoke PW on= the PE-rs; and 2PW will further configure the Root/Leaf attribute for the = AC on the PE-r. In the 2nd case, both configure the Root/Leaf attribute for the AC on the M= TU-s, and 2PW will further configure the Root/Leaf attribute for the Spoke = PW on the PE-rs. In both cases, configuration for Dual-VLAN is simpler, so, does a more comp= lex configuration really make more sense to you? Regards, Yuanlong ---------------------------------------------------------------------- Date: Wed, 9 May 2012 09:40:12 +0800 From: "Sam Cao" To: Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Message-ID: Content-Type: text/plain; charset=3D"gb2312" Hi Lizhong? Thank you very much for your comments. I updated the result on this question. [Lizhong] agree with the above analysis. And we did not say it is a technical problem, but it is an operational problem again. [Sam] I agree. Dual-VLAN does not make sense. I also discussed this with Giles and Yuanlong in another mail, and we reached agreement on this: MTU should know the access mode, VPWS or VPLS, VPWS mode should configure VLAN ID on MTU but VPLS mode can not. I thought this is NOT reasonable :), but w= e can figure this out in draft. It seems ok. [Lizhong] not fully understand. Do you mean, when VPWS accessing for H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf PW) for each AC access? [Sam] Yes. Thanks, Sam ----snipped------ From giles.heron@gmail.com Wed May 9 05: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 6122921F84FC for ; Wed, 9 May 2012 05:33:49 -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 zeRulr0-jtIQ for ; Wed, 9 May 2012 05:33:48 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id A2A8021F85B7 for ; Wed, 9 May 2012 05:33:48 -0700 (PDT) Received: by wibhr2 with SMTP id hr2so314974wib.13 for ; Wed, 09 May 2012 05:33:47 -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=dHhrmPyjcwbGo2Gc+2XK4zk+G+YEiFxsE3TpJ4H6OHE=; b=W9ooW6OSrkKhlJNJfwiPwZkySMolGhlYbiXP4hLtuKGDhRC7wLDaja/qcodp2UBMJ/ AZHoomjD0MJhPuF9caacrqZtAjXWlTWZdoWBZ3Bw0HCqWNgzpVyOLKq3+fgHM8cgqaK7 zbPPzbCqkXzcN891H9q8MncOB8tBNNx1BaXd5sC+2yC2OC3k+deA42OP4FtPHSBR85Mq ofy0C7HLy32KsvXrcoOr5Q6phLA2onqb+HO0luAGoZwWHjaTYKJuc6exilTa69M0T7mu /gK+2LIOR3GGoruMOLGRcSY9+FbC4Ozi0OwsdPxLogJUltyNxI0XHjKmYx7ozL5Z8Dzf Zh6Q== Received: by 10.180.83.72 with SMTP id o8mr54433911wiy.5.1336566827902; Wed, 09 May 2012 05:33:47 -0700 (PDT) Received: from [10.147.67.199] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id fn2sm9248637wib.0.2012.05.09.05.33.43 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 09 May 2012 05:33:47 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 09 May 2012 13:34:16 +0100 Subject: PBB E-VPN and TRILL From: Giles Heron To: Message-ID: Thread-Topic: PBB E-VPN and TRILL Thread-Index: Ac0t4AvyMdWKxMA3AUSUMcn62xbEYQ== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "Ali Sajassi \(sajassi\)" , Stewart Bryant 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, 09 May 2012 12:33:49 -0000 Ali presented the PBB-EVPN draft at IETF83 in Paris: http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-01 This has since been updated: http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-02 During our discussions Ali mentioned that the authors would like the TRILL section of the draft to be separated out into a separate draft. In response Stewart questioned whether interconnecting TRILL islands is in-scope for L2VPN. Stewart, Nabil and I have just been discussing these issues. Whilst TRILL interconnect is not explicitly in-charter for L2VPN it would appear to be implicitly in-charter - our decision to standardise solutions for PBB VPLS and PBB E-VPN probably sets a precedent (since PBB is also unmentioned by the charter). On this basis we would like to ask the WG the following three questions: 1) is the WG happy for us to pursue interconnection of TRILL islands over L2VPN? 2) is the WG happy for the authors to split the TRILL section of the PBB E-VPN draft into a separate draft? 3) is the WG happy for the TRILL draft to be a WG doc? Please respond by May 22nd if you are unhappy with any of these 3 actions (I'll take no response to mean the WG is in agreement with us proceeding...) Giles From yuqun.cao@gmail.com Wed May 9 07:36: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 AD44B21F8453 for ; Wed, 9 May 2012 07:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.879 X-Spam-Level: X-Spam-Status: No, score=-2.879 tagged_above=-999 required=5 tests=[AWL=0.720, 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 jN5YsrMRJPRC for ; Wed, 9 May 2012 07:36:14 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 56B2621F8443 for ; Wed, 9 May 2012 07:36:14 -0700 (PDT) Received: by dacx6 with SMTP id x6so411693dac.31 for ; Wed, 09 May 2012 07:36:14 -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=O4RN2P2Not7mm1jeymhYQMkcGyO6ejfX/Hlh7nyx2VA=; b=ngTMN4srBGJKRrU5wWefZa33+67kj/NGoIvmzKbU1VDCP6A4icySMceRuELPmphSYx oZJ+9cqYZnLq9FBoi8qOqsQK3vM7NiXNTm41GAnlZAHWl8CggJlRR//blldA4i2avB6M EzG2jWIgdxFzN1Jpzf0Ur5h99Re+3UGvgnpkSDR39MXVvJXmxQh9T4okxkF4BQ3T6h+w vWRQl6uvosfb6eEEhM38xPNJFciC9VmzSXTrMBQlFp2uQO0832FFpi3hxzcgfGeQdlED MEgyvA7aNpGyGaJyKszfeUmuYC7eAbxcfWRDokV5ud2wb6MJ+hVdrhe5tBjyARF9sYgN dlhA== Received: by 10.68.129.98 with SMTP id nv2mr9539606pbb.140.1336574173908; Wed, 09 May 2012 07:36:13 -0700 (PDT) Received: from v2comsam ([36.248.0.44]) by mx.google.com with ESMTPS id iu6sm6291805pbc.33.2012.05.09.07.36.08 (version=SSLv3 cipher=OTHER); Wed, 09 May 2012 07:36:12 -0700 (PDT) From: "Sam Cao" To: "'Rogers, Josh'" , "'Lucy yong'" , References: <2691CE0099834E4A9C5044EEC662BB9D330F0740@dfweml506-mbx> Subject: RE: L2vpn Digest, Vol 96, Issue 15 Date: Wed, 9 May 2012 22:36:15 +0800 Message-ID: <9B621211971C4C3AA39BBF435FC4718F@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: Ac0sl3BPTsy8rmZ9Qwu92fZcvZ3VKgBU0AGA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: 'Jiangyuanlong' 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, 09 May 2012 14:36:15 -0000 Lucy, Josh, Thank you very much for your insight comments. Sorry for late reply for busy day job :). I picked your comments below and see my comments inline. >[[LY]] I interpret this as people want to spend time to finalize dual >VLAN solution. Multi-PW has some operation impact. How do operator to >maintain this service and be able to trouble shooting. How do you expect >traceroute work when using two PWs for one VPN? How do you expect PE >report when there is an error on one of two PWs? Do you have one FEC or >two FEC for a E-Tree in control plane? [JR] I don't see this any more of a problem than troubleshooting one. If LDP is used, a simple mols traceroute shows the path that ALL PW's to that PE take, regardless of which service (this VPLS or another VPLS instance). If RSVP is used, there should be a route-object that shows me the path, and allows me to troubleshoot. Additionally, if I wanted to have traffic engineering that impacted root-sourced and leaf-sourced traffic differently, I can do that with multi-PW, where I could not (save for ingress/egress) with the 2VLAN approach. PE should report signaling on second PW same as it does for the 100th PW between PE's. Again, I don't see the problem you are alluding to. [Sam] Lucy, I agree with your comments, and both approaches need time to finalize. I answered to your questions one by one, and wish this is clear. First, there is no problem on traceroute or trouble-shooting or LSP ping. Josh has given some insight comments, and yes, we have 2 PWs, but we just repeat the OAM work twice, and there is no difference. If there is an error on one of 2 PWs, ok, OAM just report the error on the corresponding PW. For example, if Leaf PW has an error, OAM detects Leaf PW error. Finally, in control plane we don't introduce new FEC. Only one FEC for an E-Tree instance, FEC 128 or FEC 129. >[[LY]] in VPLS, PW label is used as VSI indicator, not AC. I disagree >your statement here. [Sam] Lucy, first of all, PW label is NOT used as VSI indicator. In RFC 4762, "In a VPLS, we use a VCID to identify an emulated LAN segment (from RFC 4762)", and VPLS identifier is not carried in frame; in RFC 4761, Route Target is used as VPLS identifier. PW label (ILM) can be taken as PW identifier. What I mean is, one frame from Root AC on PE 1 to PE 2, for example, Dual-VLAN will add 2 identifiers in the frame, Root-VLAN ID to identifier the frame from Root; PW label means which PW will carry the frame. But for Multi-PW, we only need one PW label, and it is enough. >[[LY]] Don't understand the first part. When egress pop-out PW label, it >find corresponding VSI first, then perform MAC lookup associated to all >ACs. We can't assume there is one AC. [Sam] Same description as above. Dual-VLAN uses one PW to carry frames from Root-AC or Leaf-AC, but Multi-PW uses one to carry frames from Root and one carry frames from Leaf. MAC lookup is basic bridge function and both should use this. We can ignore this first. Multi-PW popped the PW label out, then do MAC lookup; But dual-VLAN popped the PW label out, it should check VLAN identifier, and then do MAC lookup. If we implement it in NP, obviously it will cost more time and decrease forwarding performance. >[[LY]] If 4K VLAN ID is not an issue for VPLS, it is not an issue for >E-Tree. [Sam] If we use tagged mode, yes, I agree with your idea. But if we use raw mode, generally Multi-PW can supports more, but IMO Dual-VLAN can not. This is my point. >[[LY]] This should not be the reason to judge on the solution. [JR] I tend to agree. [Sam] I don't make myself understood. If I don't know the VLAN ID allocation solution, I will have no correct comments on it. Yes, I agree this is not the reason to judge on the solution. >[[LY]] VPN label is used for identify the VPN. It already has the >purpose. Overloading with other meaning has high potential causing a >problem. Hope you can investigate it more. Since you are very in favor of >multi-pw solution, it is not proper for you to come out the conclusion >which is better, because it is very biased. You are welcome to help on >completing either solution. [JR] this is humorous to me, because at one time, VLAN-ID was used to identify a single broadcast domain, and then later asymmetrical VID's were used to limit communication between endpoints of a broadcast domain (effectively creating two one-way broadcast domains, very similar to what we're accomplishing with ETREE). This should not be the reason to judge on the solution. [Sam] Same as above. PW label identify the PW. For example, we can use label 2000 to identify Root PW, label 2001 to identify Leaf PW. This does not identify E-Tree, although the 2 PWs belong to one E-Tree instance. Wish this is clear. Again thank you for your time, Regards, Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com] Sent: Tuesday, May 08, 2012 5:22 AM To: Lucy yong; Sam Cao; l2vpn@ietf.org Cc: Jiangyuanlong Subject: Re: L2vpn Digest, Vol 96, Issue 15 Comments inline (and s/conquer/concur/) On 5/7/12 2:58 PM, "Lucy yong" wrote: >Sam, > >I concur with Yuanlong's reply on this. Please see inline. > >Lucy > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >Sam Cao >Sent: Friday, May 04, 2012 9:09 PM >To: l2vpn@ietf.org >Cc: Jiangyuanlong >Subject: RE: L2vpn Digest, Vol 96, Issue 15 > >Lucy/Yuanlong, > >I agree that we can not say which approach is better simply, but I really >agree with Josh's comments. Multi-PW is easy to implement E-Tree. >[[LY]] I don't get impression Josh state this. > >First of all, we discussed 2 approaches for a long time and many rounds, >and >for me, there are no pending issues on Multi-PW till now or co-authors of >multi-PW have given reasonable reply to L2VPN members' questions, but >there >are still pending issues for Dual-VLAN. Please trace the mailing list. >[[LY]] I interpret this as people want to spend time to finalize dual >VLAN solution. Multi-PW has some operation impact. How do operator to >maintain this service and be able to trouble shooting. How do you expect >traceroute work when using two PWs for one VPN? How do you expect PE >report when there is an error on one of two PWs? Do you have one FEC or >two FEC for a E-Tree in control plane? [JR] I don't see this any more of a problem than troubleshooting one. If LDP is used, a simple mols traceroute shows the path that ALL PW's to that PE take, regardless of which service (this VPLS or another VPLS instance). If RSVP is used, there should be a route-object that shows me the path, and allows me to troubleshoot. Additionally, if I wanted to have traffic engineering that impacted root-sourced and leaf-sourced traffic differently, I can do that with multi-PW, where I could not (save for ingress/egress) with the 2VLAN approach. PE should report signaling on second PW same as it does for the 100th PW between PE's. Again, I don't see the problem you are alluding to. > >Second, Sasha has his concern in NP, or forwarding performance. Compared >to >current VPLS, Multi-PW has a little effect on forwarding performance since >it reuse PW label as AC indicator; Dual-VLAN will have higher side effect >on >forwarding performance because it SHOULD use additional indicator. Is >there >one prototype for Dual-VLAN? BTW, there is no reply on chip limit. >[[LY]] in VPLS, PW label is used as VSI indicator, not AC. I disagree >your statement here. > >Third, the difference between Multi-PW and dual-VLAN is, transport ingress >traffic in one "LSP" or 2 "LSP". Multi-PW classifies and transforms >ingress >traffic into right "path", and egress just pop-out PW label and forward >the >frame to ACs. Dual-VLAN has more work on ingress PE or egress PE. >[[LY]] Don't understand the first part. When egress pop-out PW label, it >find corresponding VSI first, then perform MAC lookup associated to all >ACs. We can't assume there is one AC. > >Fourth, maybe Giles has figured this out, Dual-VLAN has capacity limit. >Only >4094 VLAN ID are available, so only 2K E-Tree instances can be supported >on >one PE for Dual-VLAN approach. There is no such limit for Multi-PW >approach, >[[LY]] If 4K VLAN ID is not an issue for VPLS, it is not an issue for >E-Tree. > >Finally, in this thread we don't make agreement on VLAN ID allocation. We >also have questions on VLAN ID negotiation among PEs (signaling protocol). >Yuanlong wishes to update, but there is no update till now. >[[LY]] This should not be the reason to judge on the solution. [JR] I tend to agree. > >For me, why IEEE uses VLAN ID to identify AC type? IEEE has no LABEL :), >and >it has label, it also wish to use label to identify AC types. I think that >both solutions need much time to be perfect. Mutli-PW has less extension >work to do. But now we are focusing on technical details and can not move >forward :). >[[LY]] VPN label is used for identify the VPN. It already has the >purpose. Overloading with other meaning has high potential causing a >problem. Hope you can investigate it more. Since you are very in favor of >multi-pw solution, it is not proper for you to come out the conclusion >which is better, because it is very biased. You are welcome to help on >completing either solution. [JR] this is humorous to me, because at one time, VLAN-ID was used to identify a single broadcast domain, and then later asymmetrical VID's were used to limit communication between endpoints of a broadcast domain (effectively creating two one-way broadcast domains, very similar to what we're accomplishing with ETREE). This should not be the reason to judge on the solution. > >Regards, >Lucy > >Lucy > >Thanks, > >Sam From Peter.AshwoodSmith@huawei.com Wed May 9 08:03: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 0E2B011E80AC; Wed, 9 May 2012 08:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[AWL=0.252, 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 aA8lgfwK5xpZ; Wed, 9 May 2012 08:03:27 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA9F11E80A6; Wed, 9 May 2012 08:03:27 -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 AFS27230; Wed, 09 May 2012 11:03:27 -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, 9 May 2012 08:01:49 -0700 Received: from dfweml513-mbx.china.huawei.com ([169.254.3.80]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Wed, 9 May 2012 08:01:40 -0700 From: AshwoodsmithPeter To: Ivan Pepelnjak , "robert@raszuk.net" , Keshava A K Subject: RE: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version Notification for draft-xu-mpls-in-udp-00.txt Thread-Topic: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version Notification for draft-xu-mpls-in-udp-00.txt Thread-Index: AQHNLcqXfj/Tzug0EkWlFGBxSRM3MJbBe4rg Date: Wed, 9 May 2012 15:01:39 +0000 Message-ID: <7AE6A4247B044C4ABE0A5B6BF427F8E2012DD790@dfweml513-mbx.china.huawei.com> In-Reply-To: <00fe01cd2dca$85427060$8fc75120$@com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.60.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l2vpn@ietf.org" , "nvo3@ietf.org" , "l3vpn@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, 09 May 2012 15:03:33 -0000 > True, but many existing DC switches that do IP-based load balancing have > no problems load-balancing on UDP 5-tuple. I am positive there's equipmen= t > out there that can do load balancing on GRE keys (or some other part of= =20 > GRE header), I just haven't encountered it yet (or realized it does that)= , > so please fix my ignorance. .. > Ivan Hey Ivan, Looking at the specs of one of the most popular chips there are generic CAM= rules that allow you to override some of the 'default' hash behaviors. So = I suspect you could program a number of CAM rules that match the NVGRE Ethe= rtype and the inner src/dst IP low bits to give you the hash index .. but o= f course you'd burn CAM quite quicky but that's probably better than trying= to use more src/dst Ips to get the entropy. Realistically we can have LAG groups with many 10/40G links that need to be= spread over. Especially between a monster core router and a monster core s= witch. So using a couple of extra IP addresses per hypervisor is not going = to be adequate. I.e. does not provide enough entropy for such a wide LAG. S= o in that case and the vanilla ECMP case you'd probably be able to trade CA= M space v.s. entropy but that's not a cheap solution. Peter From lucy.yong@huawei.com Wed May 9 15: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 8D26D11E80ED for ; Wed, 9 May 2012 15:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 Sw2E0clfD1J0 for ; Wed, 9 May 2012 15:38:00 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0F47311E80E1 for ; Wed, 9 May 2012 15:38:00 -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 AGA06663; Wed, 09 May 2012 18:37:59 -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, 9 May 2012 15:34:18 -0700 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Wed, 9 May 2012 15:34:20 -0700 From: Lucy yong To: Giles Heron , "l2vpn@ietf.org" Subject: RE: PBB E-VPN and TRILL Thread-Topic: PBB E-VPN and TRILL Thread-Index: Ac0t4AvyMdWKxMA3AUSUMcn62xbEYQAUlQpw Date: Wed, 9 May 2012 22:34:20 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D33107C62@dfweml506-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.147.14] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "Ali Sajassi \(sajassi\)" , Stewart Bryant 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, 09 May 2012 22:38:00 -0000 Here is my input. 1) is the WG happy for us to pursue interconnection of TRILL islands over L2VPN? [[LY]] Yes. 2) is the WG happy for the authors to split the TRILL section of the PBB E-VPN draft into a separate draft? [[LY]] Yes. So we can also consider other L2VPN solution for TRILL islands = interconnection. We should consider PBB/SPB island interconnection as well. 3) is the WG happy for the TRILL draft to be a WG doc? [[LY]] Not for TRILL technology related drafts, they belong to TRILL WG. If= the draft is about interconnecting TRILL island by using L2VPN, then yes. Regards, Lucy From xuxiaohu@huawei.com Wed May 9 18:32: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 223F411E80E3 for ; Wed, 9 May 2012 18:32:21 -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=[AWL=-0.566, 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 itXL1TsdCeCN for ; Wed, 9 May 2012 18:32:20 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id A094311E80E1 for ; Wed, 9 May 2012 18:32:20 -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 AFT16277; Wed, 09 May 2012 21:32:20 -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, 9 May 2012 18:29:24 -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; Wed, 9 May 2012 18:29:17 -0700 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.182]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0323.003; Thu, 10 May 2012 09:28:33 +0800 From: Xuxiaohu To: Lucy yong , Giles Heron , "l2vpn@ietf.org" Subject: re: PBB E-VPN and TRILL Thread-Topic: PBB E-VPN and TRILL Thread-Index: Ac0t4AvyMdWKxMA3AUSUMcn62xbEYQAUlQpwAAYpKcA= Date: Thu, 10 May 2012 01:28:32 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02F2101E@szxeml525-mbs.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D33107C62@dfweml506-mbx> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D33107C62@dfweml506-mbx> 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 Cc: "Ali Sajassi \(sajassi\)" , Stewart Bryant 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, 10 May 2012 01:32:21 -0000 DQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6IGwydnBuLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnXSC0+rHtIEx1Y3kNCj4geW9uZw0KPiC3osvN yrG85DogMjAxMsTqNdTCMTDI1SA2OjM0DQo+IMrVvP7IyzogR2lsZXMgSGVyb247IGwydnBuQGll dGYub3JnDQo+ILOty806IEFsaSBTYWphc3NpIChzYWphc3NpKTsgU3Rld2FydCBCcnlhbnQNCj4g 1vfM4jogUkU6IFBCQiBFLVZQTiBhbmQgVFJJTEwNCj4gDQo+IEhlcmUgaXMgbXkgaW5wdXQuDQo+ IA0KPiAxKSBpcyB0aGUgV0cgaGFwcHkgZm9yIHVzIHRvIHB1cnN1ZSBpbnRlcmNvbm5lY3Rpb24g b2YgVFJJTEwgaXNsYW5kcyBvdmVyDQo+IEwyVlBOPw0KPiBbW0xZXV0gWWVzLg0KPiANCj4gMikg aXMgdGhlIFdHIGhhcHB5IGZvciB0aGUgYXV0aG9ycyB0byBzcGxpdCB0aGUgVFJJTEwgc2VjdGlv biBvZiB0aGUgUEJCDQo+IEUtVlBOIGRyYWZ0IGludG8gYSBzZXBhcmF0ZSBkcmFmdD8NCj4gW1tM WV1dIFllcy4gU28gd2UgY2FuIGFsc28gY29uc2lkZXIgb3RoZXIgTDJWUE4gc29sdXRpb24gZm9y IFRSSUxMIGlzbGFuZHMNCj4gaW50ZXJjb25uZWN0aW9uLiBXZSBzaG91bGQgY29uc2lkZXIgUEJC L1NQQiBpc2xhbmQgaW50ZXJjb25uZWN0aW9uIGFzIHdlbGwuDQo+IA0KPiAzKSBpcyB0aGUgV0cg aGFwcHkgZm9yIHRoZSBUUklMTCBkcmFmdCB0byBiZSBhIFdHIGRvYz8NCj4gW1tMWV1dIE5vdCBm b3IgVFJJTEwgdGVjaG5vbG9neSByZWxhdGVkIGRyYWZ0cywgdGhleSBiZWxvbmcgdG8gVFJJTEwg V0cuIElmIHRoZQ0KPiBkcmFmdCBpcyBhYm91dCBpbnRlcmNvbm5lY3RpbmcgVFJJTEwgaXNsYW5k IGJ5IHVzaW5nIEwyVlBOLCB0aGVuIHllcy4NCg0KKzEuICBCYXNlZCBvbiB0aGUgYXNzdW1wdGlv biB0aGF0IEwyIGluIHRoZSBjb250ZXh0IG9mIEwyVlBOIG1lYW5zIE1BQywgcmF0aGVyIHRoYW4g VFJJTEwgbmlja25hbWUsIHRoZSBkcmFmdCBhYm91dCBUUklMTCtQQkItRVZQTiBtYXkgYmVsb25n IHRvIGEgdG8tYmUtZm9ybWVkIFdHIGNhbGxlZCBUUklMTC1WUE4gb3IgdGhlIGV4aXN0aW5nIFRS SUxMIFdHIGlmIGl0J3MgdG8gYmUgcmVjaGFydGVyZWQgc28gYXMgdG8gaW5jbHVkZSB0aGF0IHdv cmsuDQoNClhpYW9odQ0KDQo+IFJlZ2FyZHMsDQo+IEx1Y3kNCj4gDQo+IA0KDQo= From yuqun.cao@gmail.com Wed May 9 22:08: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 E474E21F851B for ; Wed, 9 May 2012 22:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.082 X-Spam-Level: X-Spam-Status: No, score=-3.082 tagged_above=-999 required=5 tests=[AWL=0.517, 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 jIEWITwOYppA for ; Wed, 9 May 2012 22:08:44 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 38BC721F8518 for ; Wed, 9 May 2012 22:08:44 -0700 (PDT) Received: by dacx6 with SMTP id x6so1270664dac.31 for ; Wed, 09 May 2012 22:08:44 -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=QgUxcCvnx2QZxIDSsmR4GsMx5WXTQm/OhA4AM1dWs5Q=; b=0v/RPDyPnzD3gGskC0LUhBWHWvHoF1IgioLAv9B+SCX1nXtlLpqHtGubZSliBQk3Jn 9crWmRDMd76nXlaakaMnR0PJrRQaNjOYD5Vo19fPmXGexZkHv5yLfcMxbvE34ZhUxGaz usy8ZmT4EN3FLMKoAbZn6EQ66Okf7oV+sC/GGH0lgsB7rSt8olM3EJq5BIsv7CK1/9F+ 68zcUQjtOkZhUpaQ7LH/htQS58VUhk2NZQfwJvFl/zfoDYs2yPOn8buAq4i1ABB668Di SiHCE5Xy+8ZL3T8K2d3zq5RPXuZTEe0WsJm9bGYKTi7/8zjxi4XyDV530VQZLDokPAJS Un0g== Received: by 10.68.203.66 with SMTP id ko2mr16729097pbc.84.1336626523507; Wed, 09 May 2012 22:08:43 -0700 (PDT) Received: from R01842 ([110.90.119.113]) by mx.google.com with ESMTPS id uz10sm2188124pbc.17.2012.05.09.22.08.25 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 09 May 2012 22:08:42 -0700 (PDT) From: "Sam Cao" To: References: Subject: RE: L2vpn Digest, Vol 96, Issue 56 Date: Thu, 10 May 2012 13:08:36 +0800 Message-ID: <541719B277144ACB8945B9059D03C19B@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: Ac0uFfaYfl6huDgbTWem6MR5E9lyRQAVHfbw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: 'Jiangyuanlong' 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, 10 May 2012 05:08:47 -0000 Yuanlong, Please check the mail list :). Giles gave his comments on this, too, and finally we can ignore this and don't go on discussion. We need to forward to key items, then we can move forward, .. Thanks, Sam -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of l2vpn-request@ietf.org Sent: Thursday, May 10, 2012 3:00 AM To: l2vpn@ietf.org Subject: L2vpn Digest, Vol 96, Issue 56 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: Discussion on E-Tree and H-VPLS (Jiangyuanlong) 2. (no subject) 3. PBB E-VPN and TRILL (Giles Heron) 4. RE: L2vpn Digest, Vol 96, Issue 15 (Sam Cao) 5. RE: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version Notification for draft-xu-mpls-in-udp-00.txt (AshwoodsmithPeter) ---------------------------------------------------------------------- Message: 1 Date: Wed, 9 May 2012 12:30:43 +0000 From: Jiangyuanlong To: Jiangyuanlong , Sam Cao , "lizhong.jin@zte.com.cn" Cc: "l2vpn@ietf.org" Subject: RE: Discussion on E-Tree and H-VPLS Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D41103E@szxeml546-mbx.china.huawei.com> Content-Type: text/plain; charset="us-ascii" Seems too big to be received, snipped and send again. Sorry for the inconvenience. -----Original Message----- From: Jiangyuanlong Sent: Wednesday, May 09, 2012 7:59 PM To: 'Sam Cao'; 'lizhong.jin@zte.com.cn' Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Sam, Your statements are misleading at best IMHO, but let us go over the original question from YOU to see what problem is behind. You believe it make no sense that: >>For VPWS access, we should configure Root/Leaf for Spoke PW; >>for VPLS access, we CAN NOT configure Root/Leaf for Spoke PW. Not so correct, speaking more exactly, the dual-VLAN will: In the 1st case, each root/leaf AC (attached to a PE-r) has a corresponding Spoke PW connecting to the PE-rs, so we configure the Root/Leaf attribute for the Spoke PW on the PE-rs; In the 2nd case, all root/leaf AC (attached to a MTU-s) share a single Spoke PW connecting to the PE-rs, so we configure the Root/Leaf attribute for the AC on the MTU-s. We exchanged several emails on this topic and reached no agreement on what you said, just simply take a snip from the email (thank Giles): " On 24/04/2012 10:25, "Sam Cao" wrote: > Giles, > > Configure Root/Leaf on MTU-s and have the MTU-s add the root/Leaf > VLAN. It is correct and reasonable for Fig. 3. We can not configure it > on PE1-rs anymore. Right. > In Fig. 4, shall we configure on PE-r? It seems not reasonable since > on PE-r, it is VPWS. So in Fig. 4, we will have to configure on > PE1-rs. PE1-rs has different behavior in the 2 cases. This does not make sense for me :). For PE-r each spoke is root or leaf. It can't be both. And yes, it's VPWS not VPLS. So it makes more sense to configure on the PE-rs. Quite possibly the VPWS would be untagged in that instance... " Therefore, the fact is, two of us thought it make sense, and the third regarded it as non sense^&^ Let us go over your conclusion again: >> 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. It seems you prefer to configuring root/leaf attribute for Spoke PW on PE-rs in both cases. ------------------------------ Message: 2 Message-ID: nfiguration of root/leaf attribute for the ACs is further needed on the PE-= r, and I believe in the 2nd use case, configuration of root/leaf attribute for= the ACs is also needed on the MTU-s (otherwise, how can the 2PW use differ= ent PATH?), so that 2 PWs can be set up to carry the E-Tree traffic. Now we can compare the Dual-VLAN with 2PW approach to see what is different= : In the 1st case, both configure the Root/Leaf attribute for the Spoke PW on= the PE-rs; and 2PW will further configure the Root/Leaf attribute for the = AC on the PE-r. In the 2nd case, both configure the Root/Leaf attribute for the AC on the M= TU-s, and 2PW will further configure the Root/Leaf attribute for the Spoke = PW on the PE-rs. In both cases, configuration for Dual-VLAN is simpler, so, does a more comp= lex configuration really make more sense to you? Regards, Yuanlong ---------------------------------------------------------------------- Date: Wed, 9 May 2012 09:40:12 +0800 From: "Sam Cao" To: Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Message-ID: Content-Type: text/plain; charset=3D"gb2312" Hi Lizhong? Thank you very much for your comments. I updated the result on this question. [Lizhong] agree with the above analysis. And we did not say it is a technical problem, but it is an operational problem again. [Sam] I agree. Dual-VLAN does not make sense. I also discussed this with Giles and Yuanlong in another mail, and we reached agreement on this: MTU should know the access mode, VPWS or VPLS, VPWS mode should configure VLAN ID on MTU but VPLS mode can not. I thought this is NOT reasonable :), but w= e can figure this out in draft. It seems ok. [Lizhong] not fully understand. Do you mean, when VPWS accessing for H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf PW) for each AC access? [Sam] Yes. Thanks, Sam ----snipped------ ------------------------------ Message: 3 Date: Wed, 09 May 2012 13:34:16 +0100 From: Giles Heron To: Cc: "Ali Sajassi \(sajassi\)" , Stewart Bryant Subject: PBB E-VPN and TRILL Message-ID: Content-Type: text/plain; charset="US-ASCII" Ali presented the PBB-EVPN draft at IETF83 in Paris: http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-01 This has since been updated: http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-02 During our discussions Ali mentioned that the authors would like the TRILL section of the draft to be separated out into a separate draft. In response Stewart questioned whether interconnecting TRILL islands is in-scope for L2VPN. Stewart, Nabil and I have just been discussing these issues. Whilst TRILL interconnect is not explicitly in-charter for L2VPN it would appear to be implicitly in-charter - our decision to standardise solutions for PBB VPLS and PBB E-VPN probably sets a precedent (since PBB is also unmentioned by the charter). On this basis we would like to ask the WG the following three questions: 1) is the WG happy for us to pursue interconnection of TRILL islands over L2VPN? 2) is the WG happy for the authors to split the TRILL section of the PBB E-VPN draft into a separate draft? 3) is the WG happy for the TRILL draft to be a WG doc? Please respond by May 22nd if you are unhappy with any of these 3 actions (I'll take no response to mean the WG is in agreement with us proceeding...) Giles ------------------------------ Message: 4 Date: Wed, 9 May 2012 22:36:15 +0800 From: "Sam Cao" To: "'Rogers, Josh'" , "'Lucy yong'" , Cc: 'Jiangyuanlong' Subject: RE: L2vpn Digest, Vol 96, Issue 15 Message-ID: <9B621211971C4C3AA39BBF435FC4718F@v2comsam> Content-Type: text/plain; charset="us-ascii" Lucy, Josh, Thank you very much for your insight comments. Sorry for late reply for busy day job :). I picked your comments below and see my comments inline. >[[LY]] I interpret this as people want to spend time to finalize dual >VLAN solution. Multi-PW has some operation impact. How do operator to >maintain this service and be able to trouble shooting. How do you expect >traceroute work when using two PWs for one VPN? How do you expect PE >report when there is an error on one of two PWs? Do you have one FEC or >two FEC for a E-Tree in control plane? [JR] I don't see this any more of a problem than troubleshooting one. If LDP is used, a simple mols traceroute shows the path that ALL PW's to that PE take, regardless of which service (this VPLS or another VPLS instance). If RSVP is used, there should be a route-object that shows me the path, and allows me to troubleshoot. Additionally, if I wanted to have traffic engineering that impacted root-sourced and leaf-sourced traffic differently, I can do that with multi-PW, where I could not (save for ingress/egress) with the 2VLAN approach. PE should report signaling on second PW same as it does for the 100th PW between PE's. Again, I don't see the problem you are alluding to. [Sam] Lucy, I agree with your comments, and both approaches need time to finalize. I answered to your questions one by one, and wish this is clear. First, there is no problem on traceroute or trouble-shooting or LSP ping. Josh has given some insight comments, and yes, we have 2 PWs, but we just repeat the OAM work twice, and there is no difference. If there is an error on one of 2 PWs, ok, OAM just report the error on the corresponding PW. For example, if Leaf PW has an error, OAM detects Leaf PW error. Finally, in control plane we don't introduce new FEC. Only one FEC for an E-Tree instance, FEC 128 or FEC 129. >[[LY]] in VPLS, PW label is used as VSI indicator, not AC. I disagree >your statement here. [Sam] Lucy, first of all, PW label is NOT used as VSI indicator. In RFC 4762, "In a VPLS, we use a VCID to identify an emulated LAN segment (from RFC 4762)", and VPLS identifier is not carried in frame; in RFC 4761, Route Target is used as VPLS identifier. PW label (ILM) can be taken as PW identifier. What I mean is, one frame from Root AC on PE 1 to PE 2, for example, Dual-VLAN will add 2 identifiers in the frame, Root-VLAN ID to identifier the frame from Root; PW label means which PW will carry the frame. But for Multi-PW, we only need one PW label, and it is enough. >[[LY]] Don't understand the first part. When egress pop-out PW label, it >find corresponding VSI first, then perform MAC lookup associated to all >ACs. We can't assume there is one AC. [Sam] Same description as above. Dual-VLAN uses one PW to carry frames from Root-AC or Leaf-AC, but Multi-PW uses one to carry frames from Root and one carry frames from Leaf. MAC lookup is basic bridge function and both should use this. We can ignore this first. Multi-PW popped the PW label out, then do MAC lookup; But dual-VLAN popped the PW label out, it should check VLAN identifier, and then do MAC lookup. If we implement it in NP, obviously it will cost more time and decrease forwarding performance. >[[LY]] If 4K VLAN ID is not an issue for VPLS, it is not an issue for >E-Tree. [Sam] If we use tagged mode, yes, I agree with your idea. But if we use raw mode, generally Multi-PW can supports more, but IMO Dual-VLAN can not. This is my point. >[[LY]] This should not be the reason to judge on the solution. [JR] I tend to agree. [Sam] I don't make myself understood. If I don't know the VLAN ID allocation solution, I will have no correct comments on it. Yes, I agree this is not the reason to judge on the solution. >[[LY]] VPN label is used for identify the VPN. It already has the >purpose. Overloading with other meaning has high potential causing a >problem. Hope you can investigate it more. Since you are very in favor of >multi-pw solution, it is not proper for you to come out the conclusion >which is better, because it is very biased. You are welcome to help on >completing either solution. [JR] this is humorous to me, because at one time, VLAN-ID was used to identify a single broadcast domain, and then later asymmetrical VID's were used to limit communication between endpoints of a broadcast domain (effectively creating two one-way broadcast domains, very similar to what we're accomplishing with ETREE). This should not be the reason to judge on the solution. [Sam] Same as above. PW label identify the PW. For example, we can use label 2000 to identify Root PW, label 2001 to identify Leaf PW. This does not identify E-Tree, although the 2 PWs belong to one E-Tree instance. Wish this is clear. Again thank you for your time, Regards, Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com] Sent: Tuesday, May 08, 2012 5:22 AM To: Lucy yong; Sam Cao; l2vpn@ietf.org Cc: Jiangyuanlong Subject: Re: L2vpn Digest, Vol 96, Issue 15 Comments inline (and s/conquer/concur/) On 5/7/12 2:58 PM, "Lucy yong" wrote: >Sam, > >I concur with Yuanlong's reply on this. Please see inline. > >Lucy > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >Sam Cao >Sent: Friday, May 04, 2012 9:09 PM >To: l2vpn@ietf.org >Cc: Jiangyuanlong >Subject: RE: L2vpn Digest, Vol 96, Issue 15 > >Lucy/Yuanlong, > >I agree that we can not say which approach is better simply, but I really >agree with Josh's comments. Multi-PW is easy to implement E-Tree. >[[LY]] I don't get impression Josh state this. > >First of all, we discussed 2 approaches for a long time and many rounds, >and >for me, there are no pending issues on Multi-PW till now or co-authors of >multi-PW have given reasonable reply to L2VPN members' questions, but >there >are still pending issues for Dual-VLAN. Please trace the mailing list. >[[LY]] I interpret this as people want to spend time to finalize dual >VLAN solution. Multi-PW has some operation impact. How do operator to >maintain this service and be able to trouble shooting. How do you expect >traceroute work when using two PWs for one VPN? How do you expect PE >report when there is an error on one of two PWs? Do you have one FEC or >two FEC for a E-Tree in control plane? [JR] I don't see this any more of a problem than troubleshooting one. If LDP is used, a simple mols traceroute shows the path that ALL PW's to that PE take, regardless of which service (this VPLS or another VPLS instance). If RSVP is used, there should be a route-object that shows me the path, and allows me to troubleshoot. Additionally, if I wanted to have traffic engineering that impacted root-sourced and leaf-sourced traffic differently, I can do that with multi-PW, where I could not (save for ingress/egress) with the 2VLAN approach. PE should report signaling on second PW same as it does for the 100th PW between PE's. Again, I don't see the problem you are alluding to. > >Second, Sasha has his concern in NP, or forwarding performance. Compared >to >current VPLS, Multi-PW has a little effect on forwarding performance since >it reuse PW label as AC indicator; Dual-VLAN will have higher side effect >on >forwarding performance because it SHOULD use additional indicator. Is >there >one prototype for Dual-VLAN? BTW, there is no reply on chip limit. >[[LY]] in VPLS, PW label is used as VSI indicator, not AC. I disagree >your statement here. > >Third, the difference between Multi-PW and dual-VLAN is, transport ingress >traffic in one "LSP" or 2 "LSP". Multi-PW classifies and transforms >ingress >traffic into right "path", and egress just pop-out PW label and forward >the >frame to ACs. Dual-VLAN has more work on ingress PE or egress PE. >[[LY]] Don't understand the first part. When egress pop-out PW label, it >find corresponding VSI first, then perform MAC lookup associated to all >ACs. We can't assume there is one AC. > >Fourth, maybe Giles has figured this out, Dual-VLAN has capacity limit. >Only >4094 VLAN ID are available, so only 2K E-Tree instances can be supported >on >one PE for Dual-VLAN approach. There is no such limit for Multi-PW >approach, >[[LY]] If 4K VLAN ID is not an issue for VPLS, it is not an issue for >E-Tree. > >Finally, in this thread we don't make agreement on VLAN ID allocation. We >also have questions on VLAN ID negotiation among PEs (signaling protocol). >Yuanlong wishes to update, but there is no update till now. >[[LY]] This should not be the reason to judge on the solution. [JR] I tend to agree. > >For me, why IEEE uses VLAN ID to identify AC type? IEEE has no LABEL :), >and >it has label, it also wish to use label to identify AC types. I think that >both solutions need much time to be perfect. Mutli-PW has less extension >work to do. But now we are focusing on technical details and can not move >forward :). >[[LY]] VPN label is used for identify the VPN. It already has the >purpose. Overloading with other meaning has high potential causing a >problem. Hope you can investigate it more. Since you are very in favor of >multi-pw solution, it is not proper for you to come out the conclusion >which is better, because it is very biased. You are welcome to help on >completing either solution. [JR] this is humorous to me, because at one time, VLAN-ID was used to identify a single broadcast domain, and then later asymmetrical VID's were used to limit communication between endpoints of a broadcast domain (effectively creating two one-way broadcast domains, very similar to what we're accomplishing with ETREE). This should not be the reason to judge on the solution. > >Regards, >Lucy > >Lucy > >Thanks, > >Sam ------------------------------ Message: 5 Date: Wed, 9 May 2012 15:01:39 +0000 From: AshwoodsmithPeter To: Ivan Pepelnjak , "robert@raszuk.net" , Keshava A K Cc: "l2vpn@ietf.org" , "nvo3@ietf.org" , "l3vpn@ietf.org" Subject: RE: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version Notification for draft-xu-mpls-in-udp-00.txt Message-ID: <7AE6A4247B044C4ABE0A5B6BF427F8E2012DD790@dfweml513-mbx.china.huawei.com> Content-Type: text/plain; charset="us-ascii" > True, but many existing DC switches that do IP-based load balancing have > no problems load-balancing on UDP 5-tuple. I am positive there's equipment > out there that can do load balancing on GRE keys (or some other part of > GRE header), I just haven't encountered it yet (or realized it does that), > so please fix my ignorance. .. > Ivan Hey Ivan, Looking at the specs of one of the most popular chips there are generic CAM rules that allow you to override some of the 'default' hash behaviors. So I suspect you could program a number of CAM rules that match the NVGRE Ethertype and the inner src/dst IP low bits to give you the hash index .. but of course you'd burn CAM quite quicky but that's probably better than trying to use more src/dst Ips to get the entropy. Realistically we can have LAG groups with many 10/40G links that need to be spread over. Especially between a monster core router and a monster core switch. So using a couple of extra IP addresses per hypervisor is not going to be adequate. I.e. does not provide enough entropy for such a wide LAG. So in that case and the vanilla ECMP case you'd probably be able to trade CAM space v.s. entropy but that's not a cheap solution. Peter ------------------------------ _______________________________________________ L2vpn mailing list L2vpn@ietf.org https://www.ietf.org/mailman/listinfo/l2vpn End of L2vpn Digest, Vol 96, Issue 56 ************************************* From sajassi@cisco.com Wed May 9 23:21: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 D7C1121F85BB for ; Wed, 9 May 2012 23:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.267 X-Spam-Level: X-Spam-Status: No, score=-10.267 tagged_above=-999 required=5 tests=[AWL=0.332, 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 Ac-UwV9Qwanp for ; Wed, 9 May 2012 23:21:00 -0700 (PDT) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 04BFE21F85B5 for ; Wed, 9 May 2012 23:20:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sajassi@cisco.com; l=490; q=dns/txt; s=iport; t=1336630860; x=1337840460; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=XZcBk2h2Q/83qOo2bEkQVISo8VMhHR+0zjzMELqU8ME=; b=ZJatFCOemTL2gC5HxFpYwCr8gHizoeC6Ld1gEBTzY5urlKhSW2sQsmeO btKl+cId1+FKbpXz1RN1m9RmsaQ0e2oYZUM9gWwG4gtEIz2QId5R2TOVL 21zCiqdetbwTYSo0cCHBddsNTgMcGqHEx7oSdG20vPrhhLDBy0mABEJ5r Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EAH5dq09Io8UY/2dsb2JhbABEtECCDAEBAQMBEgEnAgE8BQ0BCIEdAQEEAQ0nh2cEAZsToBqRNgSIZI0ZjleBaYMJ X-IronPort-AV: E=Sophos;i="4.75,563,1330905600"; d="scan'208";a="11856382" Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 10 May 2012 06:20:58 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q4A6KNUa025872; Thu, 10 May 2012 06:20:55 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); Wed, 9 May 2012 23:20:40 -0700 Received: from 10.21.95.254 ([10.21.95.254]) by xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) with Microsoft Exchange Server HTTP-DAV ; Thu, 10 May 2012 06:20:39 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 09 May 2012 23:20:40 -0700 Subject: Re: PBB E-VPN and TRILL From: Ali Sajassi To: Giles Heron , Message-ID: Thread-Topic: PBB E-VPN and TRILL Thread-Index: Ac0t4AvyMdWKxMA3AUSUMcn62xbEYQAlPlwW In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 10 May 2012 06:20:40.0907 (UTC) FILETIME=[05ECD1B0:01CD2E75] Cc: Stewart Bryant 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, 10 May 2012 06:21:04 -0000 > > 1) is the WG happy for us to pursue interconnection of TRILL islands over > L2VPN? Yes. > > 2) is the WG happy for the authors to split the TRILL section of the PBB > E-VPN draft into a separate draft? > Yes. > 3) is the WG happy for the TRILL draft to be a WG doc? > Yes. > Please respond by May 22nd if you are unhappy with any of these 3 actions > (I'll take no response to mean the WG is in agreement with us proceeding...) > > Giles > > From sboutros@cisco.com Wed May 9 23:43: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 BEFBE21F8570 for ; Wed, 9 May 2012 23:43:28 -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=[AWL=0.000, 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 lvL4yjo7peGv for ; Wed, 9 May 2012 23:43:27 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id BC40821F852E for ; Wed, 9 May 2012 23:43:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sboutros@cisco.com; l=1509; q=dns/txt; s=iport; t=1336632206; x=1337841806; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=v4DcuDTGywk+aY3v6P1he9pDNXFPrGSA4TtFsD45AKs=; b=gCUs/TRT22HXee6K7MyKx8gRQttLf87hvt8XpCm0fl8weU1xyq9L9ttQ tYL6L5WVkyjzSnURenI1qEntGEHvEQj1OSpTfs+UHy5+c2L4gVif4mfKG JT0DVM8/u+UquUkVJPmk0typUJuzV4vvDogRlJCg2tzni4xaOFpVJFLtK U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFdjq0+tJV2c/2dsb2JhbABEsziBB4IMAQEBAwESASc/BQsLRlcGLgeHZwULmwKgGYsNhUZjBIhkjRmBEY1GgWmDCQ X-IronPort-AV: E=Sophos;i="4.75,563,1330905600"; d="scan'208";a="81940954" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 10 May 2012 06:43:25 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id q4A6hPYG030603; Thu, 10 May 2012 06:43:25 GMT Received: from xfe-rcd-301.cisco.com ([72.163.63.12]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 May 2012 01:43:25 -0500 Received: from rtp-vpn5-1152.cisco.com ([10.82.236.132]) by xfe-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 May 2012 01:43:21 -0500 Subject: Re: PBB E-VPN and TRILL Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Sami Boutros In-Reply-To: Date: Wed, 9 May 2012 23:43:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Giles Heron X-Mailer: Apple Mail (2.1251.1) X-OriginalArrivalTime: 10 May 2012 06:43:21.0887 (UTC) FILETIME=[3121E2F0:01CD2E78] Cc: l2vpn@ietf.org, "Ali Sajassi \(sajassi\)" , Stewart Bryant 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, 10 May 2012 06:43:28 -0000 On May 9, 2012, at 5:34 AM, Giles Heron wrote: > Ali presented the PBB-EVPN draft at IETF83 in Paris: >=20 > http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-01 >=20 > This has since been updated: >=20 > http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-02 >=20 > During our discussions Ali mentioned that the authors would like the = TRILL > section of the draft to be separated out into a separate draft. In = response > Stewart questioned whether interconnecting TRILL islands is in-scope = for > L2VPN. >=20 > Stewart, Nabil and I have just been discussing these issues. Whilst = TRILL > interconnect is not explicitly in-charter for L2VPN it would appear to = be > implicitly in-charter - our decision to standardise solutions for PBB = VPLS > and PBB E-VPN probably sets a precedent (since PBB is also unmentioned = by > the charter). >=20 > On this basis we would like to ask the WG the following three = questions: >=20 > 1) is the WG happy for us to pursue interconnection of TRILL islands = over > L2VPN? >=20 Sami: Yes. > 2) is the WG happy for the authors to split the TRILL section of the = PBB > E-VPN draft into a separate draft? >=20 Sami: Yes. > 3) is the WG happy for the TRILL draft to be a WG doc? >=20 Sami: Yes. Thanks, Sami > Please respond by May 22nd if you are unhappy with any of these 3 = actions > (I'll take no response to mean the WG is in agreement with us = proceeding...) >=20 > Giles >=20 >=20 From zhangmingui@huawei.com Thu May 10 00:51: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 AB67E21F85DF for ; Thu, 10 May 2012 00:51:04 -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=[AWL=0.000, 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 SEqEUi6TtvjJ for ; Thu, 10 May 2012 00:51:04 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE4321F85DD for ; Thu, 10 May 2012 00:51:02 -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 AGA36228; Thu, 10 May 2012 03:51:02 -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, 10 May 2012 00:48:29 -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; Thu, 10 May 2012 00:48:27 -0700 Received: from SZXEML507-MBS.china.huawei.com ([169.254.7.245]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0323.003; Thu, 10 May 2012 15:48:24 +0800 From: Mingui Zhang To: Giles Heron , "l2vpn@ietf.org" Subject: RE: PBB E-VPN and TRILL Thread-Topic: PBB E-VPN and TRILL Thread-Index: Ac0t4AvyMdWKxMA3AUSUMcn62xbEYQAaYQqQ Date: Thu, 10 May 2012 07:48:22 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E728CD73DE@SZXEML507-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.108.4.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "Ali Sajassi \(sajassi\)" , Stewart Bryant 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, 10 May 2012 07:51:04 -0000 We may further separate the interconnection into two parts: communication p= art and TRILL part. The communication part answers what information should = be exchanged among MESes and what is the encapsulation format when TRILL da= ta is tunneled through evpn. While the TRILL part tell us how MESes (or Bor= der RBridges) participate in TRILL. IMO, the TRILL part should be conducted= in TRILL WG, since it's highly tied up to TRILL.=20 The interaction between these two parts can be handled through liaison. Aft= er some liaisons, we might find it is necessary to modify the communication= part due to the TRILL part. For example, I concern about the interested VL= ANs information propagated in LSPs in TRILL. Without this information, how = can an RBridge in VLAN-x build the entries in its multicast FIB for remote = RBridges in VLAN-x but in a different island?=20 I am OK with the three actions if its scope is limited to the communication= part. My 2 cents, Mingui > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf= Of > Giles Heron > Sent: Wednesday, May 09, 2012 8:34 PM > To: l2vpn@ietf.org > Cc: Ali Sajassi (sajassi); Stewart Bryant > Subject: PBB E-VPN and TRILL >=20 > Ali presented the PBB-EVPN draft at IETF83 in Paris: >=20 > http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-01 >=20 > This has since been updated: >=20 > http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-02 >=20 > During our discussions Ali mentioned that the authors would like the T= RILL > section of the draft to be separated out into a separate draft. In re= sponse > Stewart questioned whether interconnecting TRILL islands is in-scope f= or > L2VPN. >=20 > Stewart, Nabil and I have just been discussing these issues. Whilst T= RILL > interconnect is not explicitly in-charter for L2VPN it would appear to= be > implicitly in-charter - our decision to standardise solutions for PBB = VPLS > and PBB E-VPN probably sets a precedent (since PBB is also unmentioned= by > the charter). >=20 > On this basis we would like to ask the WG the following three question= s: >=20 > 1) is the WG happy for us to pursue interconnection of TRILL islands o= ver > L2VPN? >=20 > 2) is the WG happy for the authors to split the TRILL section of the P= BB > E-VPN draft into a separate draft? >=20 > 3) is the WG happy for the TRILL draft to be a WG doc? >=20 > Please respond by May 22nd if you are unhappy with any of these 3 acti= ons > (I'll take no response to mean the WG is in agreement with us proceedi= ng...) >=20 > Giles >=20 From balajivenkat@force10networks.com Thu May 10 00:34: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 AB8B321F8577 for ; Thu, 10 May 2012 00:34:03 -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 XdG6W78w-8NZ for ; Thu, 10 May 2012 00:34:03 -0700 (PDT) Received: from mx.force10networks.com (maa.force10networks.com [59.163.202.254]) by ietfa.amsl.com (Postfix) with ESMTP id A785221F8523 for ; Thu, 10 May 2012 00:34:02 -0700 (PDT) Received: from EXCH-CLUSTER-11.force10networks.com ([10.16.127.21]) by exch7-maa-fe.force10networks.com ([10.16.126.10]) with mapi; Thu, 10 May 2012 13:04:00 +0530 From: Balaji Venkat Venkataswami To: "giles.heron@gmail.com" , "l2vpn@ietf.org" Date: Thu, 10 May 2012 13:03:58 +0530 Subject: PBB E-VPN and TRILL Thread-Topic: PBB E-VPN and TRILL Thread-Index: Ac0t4AvyMdWKxMA3AUSUMcn62xbEYQAmBZ9AAAGW1qA= Message-ID: <5EC91DDA759C324DB62C5A5F7B4922193CC839078C@EXCH-CLUSTER-11.force10networks.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: Thu, 10 May 2012 01:04:16 -0700 Cc: "sajassi@cisco.com" , "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, 10 May 2012 07:34:03 -0000 Hi Giles, I totally agree on this point. We have a solution that was presented to the= TRILL working group as well on the interconnection of TRILL islands. We would lik= e to=20 concur with this and request for entering our draft as well into the soluti= on space. The URL for the TRILL draft is as follows. http://tools.ietf.org/html/draft-balaji-trill-over-ip-multi-level-05 thanks and regards, balaji venkat Sent: Wednesday, May 09, 2012 6:04 PM=09 To: l2vpn@ietf.org Cc: Ali Sajassi (sajassi); Stewart Bryant Subject: PBB E-VPN and TRILL Ali presented the PBB-EVPN draft at IETF83 in Paris: http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-01 This has since been updated: http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-02 During our discussions Ali mentioned that the authors would like the TRILL = section of the draft to be separated out into a separate draft. In respons= e Stewart questioned whether interconnecting TRILL islands is in-scope for = L2VPN. Stewart, Nabil and I have just been discussing these issues. Whilst TRILL = interconnect is not explicitly in-charter for L2VPN it would appear to be i= mplicitly in-charter - our decision to standardise solutions for PBB VPLS a= nd PBB E-VPN probably sets a precedent (since PBB is also unmentioned by th= e charter). On this basis we would like to ask the WG the following three questions: 1) is the WG happy for us to pursue interconnection of TRILL islands over L= 2VPN? 2) is the WG happy for the authors to split the TRILL section of the PBB E-= VPN draft into a separate draft? 3) is the WG happy for the TRILL draft to be a WG doc? Please respond by May 22nd if you are unhappy with any of these 3 actions (= I'll take no response to mean the WG is in agreement with us proceeding...) Giles From jdrake@juniper.net Thu May 10 05:06: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 CC31521F8644 for ; Thu, 10 May 2012 05:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.469 X-Spam-Level: X-Spam-Status: No, score=-6.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 1tQoKq+NvTDV for ; Thu, 10 May 2012 05:06:24 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 1222421F8642 for ; Thu, 10 May 2012 05:06:24 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKT6uvPkiWVmOTK4IbxU7UDaBmFynd64x4@postini.com; Thu, 10 May 2012 05:06:24 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Thu, 10 May 2012 05:06:04 -0700 From: John E Drake To: Giles Heron , "l2vpn@ietf.org" Date: Thu, 10 May 2012 05:06:02 -0700 Subject: RE: PBB E-VPN and TRILL Thread-Topic: PBB E-VPN and TRILL Thread-Index: Ac0t4AvyMdWKxMA3AUSUMcn62xbEYQAxRBqw Message-ID: <5E893DB832F57341992548CDBB333163A577CAAEC7@EMBX01-HQ.jnpr.net> 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 Cc: "Ali Sajassi \(sajassi\)" , Stewart Bryant 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, 10 May 2012 12:06:25 -0000 Inline Sent from my iPhone >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >Of Giles Heron >Sent: Wednesday, May 09, 2012 5:34 AM >To: l2vpn@ietf.org >Cc: Ali Sajassi (sajassi); Stewart Bryant >Subject: PBB E-VPN and TRILL > >Ali presented the PBB-EVPN draft at IETF83 in Paris: > >http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-01 > >This has since been updated: > >http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-02 > >During our discussions Ali mentioned that the authors would like the >TRILL section of the draft to be separated out into a separate draft. >In response Stewart questioned whether interconnecting TRILL islands is >in-scope for L2VPN. > >Stewart, Nabil and I have just been discussing these issues. Whilst >TRILL interconnect is not explicitly in-charter for L2VPN it would >appear to be implicitly in-charter - our decision to standardise >solutions for PBB VPLS and PBB E-VPN probably sets a precedent (since >PBB is also unmentioned by the charter). > >On this basis we would like to ask the WG the following three questions: > >1) is the WG happy for us to pursue interconnection of TRILL islands >over L2VPN? JD: Yes > >2) is the WG happy for the authors to split the TRILL section of the PBB >E-VPN draft into a separate draft? JD: Yes > >3) is the WG happy for the TRILL draft to be a WG doc? JD: Yes > >Please respond by May 22nd if you are unhappy with any of these 3 >actions (I'll take no response to mean the WG is in agreement with us >proceeding...) > >Giles > From Alexander.Vainshtein@ecitele.com Thu May 10 07:11: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 1718E21F865F for ; Thu, 10 May 2012 07:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.531 X-Spam-Level: X-Spam-Status: No, score=-4.531 tagged_above=-999 required=5 tests=[AWL=0.671, 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 LyzdcGHUzeqp for ; Thu, 10 May 2012 07:11: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 0666321F865A for ; Thu, 10 May 2012 07:11:26 -0700 (PDT) Received: from [85.158.143.99:64581] by server-1.bemta-4.messagelabs.com id C5/A7-20925-E8CCBAF4; Thu, 10 May 2012 14:11:26 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1336659081!20349993!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.5.10; banners=-,-,- Received: (qmail 21197 invoked from network); 10 May 2012 14:11:21 -0000 Received: from unknown (HELO fridlppsb001.ecitele.com) (168.87.1.157) by server-6.tower-216.messagelabs.com with SMTP; 10 May 2012 14:11:21 -0000 X-AuditID: a8571401-b7f8d6d0000035b0-1a-4fabcd113218 Received: from FRIDWPPCH002.ecitele.com (fridwppch002.ecitele.com [10.1.16.53]) by fridlppsb001.ecitele.com (Symantec Messaging Gateway) with SMTP id CF.93.13744.11DCBAF4; Thu, 10 May 2012 16:13:38 +0200 (CEST) Received: from FRIDWPPMB001.ecitele.com ([169.254.3.187]) by FRIDWPPCH002.ecitele.com ([10.1.16.53]) with mapi id 14.01.0339.001; Thu, 10 May 2012 16:11:20 +0200 From: Alexander Vainshtein To: "msiva@cisco.com" , "Sami Boutros (sboutros@cisco.com)" , "nmcgill@cisco.com" Subject: RE: Static VPLS MAC withdrawal draft Thread-Topic: Static VPLS MAC withdrawal draft Thread-Index: Ac0tTYm5TIv9pECE0EWc8IlBO2eaCQBZSqlwAAD+M1A= Date: Thu, 10 May 2012 14:11:19 +0000 Message-ID: References: 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: H4sIAAAAAAAAA2VSa0gUURj17syO4+bEtG3udemxDVhQraxkuT1WCiJUiJUeSP7Rafa6O7U7 O+2sov1JJcqkKMOsNrE0tdTKjKDUIlM0ssxeRGVJaC/NikQqkaIZx8zo/jr3O+d8j3s/EtP3 ECaSFwLIL7AehtDhOhBisui76hzW9hs629v248DW/6011Pag7zZm6/30Q2PrKB4Ga7QJxWMN 2oTG4KvQhMrKUU0ylpoLVrOC4AuwAWR2IomzM8l+Povlchgz77QzMYxZ9LAc8iIhYGdYUUSC k4nXmf87q2UZL5iRwPmcvOCyM4mbHBabbdkKSwwTv9nNS2Zk8bK8x+xFksS6kFmOKBMIzvSL mPte5yNCrJqd/exnBZ4LKiIKQRgJ6Vi4b2RMo+II+KC3nigEOlJPPwHwW2/LxKUKwNHKekxR EbQdXq57NU4Y6AMAlh89LxMkidFJcPRjuqKZSVtg96HnhIINdDQcay8BKl4J3+V1ahWM01Gw caRrPE7RG2Bzae94F3p6KTw5UowrGMgdfe88Px7HaCN88ebURKc0rLzejal4Fhzo/6VV8VyY X/MkVNUvgaebhwkVL4bV5R8xtdYMeOfEG1zVR8Jb557hh0FEcEqJ4BR7cIo9OMV+GuC1wJjh 552iKG2zWmOiEccHkAdFcz7vZSCvy7kUA7gG+g5GtwKaBEw41ZJX69Br2Swpx9sKIkkNM4ta frvOoZ++zefMcbOSO82f6UFSK4Akxhio0mMyRznZnF3I7/tD2eR3K8JM0zif8q2BtKVW6z8X xkjVb4x36GmXvGs7EBKR/491NkkykBq6K2ed4UculJ3BewJ/aQ0ZplQOlyvfUjSUJLJeiXep fCeINBmpaoWgFcKdKUx6B4FRnm8m1aOw4fK+TboG5YQaOWFJW42SUN7/ScqUCxIXFnk/2MWw Jm3U45fY59f9Z5kfKYRDggVXrxz+8p7bObClu6MtpGGgpyUx68WyeR3rtp9Zu7zwUtn26rxU d/aq/W0FDfPbIx9uLV9QnPDzQ1FP5u6bDVxcis9Tj6+9FBLIS6poukA8XbyXHLofa4jrYufg ZYnG/D1f849EjWRsWs/gkpuNWYT5JfY3TpEyiO4DAAA= 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, 10 May 2012 14:11:28 -0000 Resending with less addressees... Regards, Sasha > -----Original Message----- > From: Alexander Vainshtein > Sent: Thursday, May 10, 2012 5:08 PM > To: 'msiva@cisco.com:'; Sami Boutros (sboutros@cisco.com); > 'nmcgill@cisco.com' > Cc: l2vpn@ietf.org; 'Giles Heron'; Rotem Cohen; Andrew Sergeev; Mishael > Wexler; Gideon Agmon > Subject: RE: Static VPLS MAC withdrawal draft > > Hi all, > I've read the draft in question and I would like to clarify several issues= that > look either undefined or ambiguous to me. > > 1. To the best of my understanding, the draft requires each PE participati= ng > in a given VPLS instance to set up two counters for each static PW > connecting it to a peer PE device in this VPLS instance: one for static MA= C > withdrawal messages it is going to send and another - for static MAC > withdrawal messages it receives. Is this understanding correct? > > 2. Assuming a positive answer to the previous questions, how are these > counters initialized? The draft seems to be moot on this point. The more > interesting question is, of course, about initialization of the counter of > received static MAC withdrawal messages, since, with static PWs, generally > speaking, there is no synchronization between setting up one of its end > points and setting up another one. > > 3. The draft specifies that: > - The transmitter sends the MAC withdrawal message with the same > sequence number until it receives an ACK for it (Section 4.1.1) > - The receiver, after having acknowledged a MAC withdrawal > message, ignores refresh messages with the same sequence number > (Section 4.1.2) > What is supposed to happen in the following scenario: > - Transmitter finds out that some MACs have to be withdrawn (e.g., > because the AC from which they have been learned fails) > and sends a MAC withdrawal message to its peers with sequence > number N > - Immediately after that (i.e., before it receives an ACK for this > message) it finds out that yet another set of MAC addresses has to be > withdrawn > - Retransmission timer expires without ACK received. > > 4. Suppose that only one end point of a static PW between a given pair of > peers has been set up. In this case transmitting the static MAC withdrawal > messages via such a PW is possible, but ACKs will never be received. Shoul= d > retransmission of these messages go on "ad infinitum"? > > 5. The draft does not specify any default value for the retransmit time. > > 6. A nit: Heading of Section 4 is followed by headings for Sections 4.1.1= and > 4.1.2 without any heading for 4.1. > > Hopefully these questions will be useful. > > Regards, > Sasha > > > -----Original Message----- > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > > Of Giles Heron > > Sent: Tuesday, May 08, 2012 10:06 PM > > To: l2vpn@ietf.org > > Subject: Static VPLS MAC withdrawal draft > > > > Hi everyone, > > > > The following draft was presented at IETF in Paris: > > > > http://tools.ietf.org/html/draft-boutros-l2vpn-mpls-tp-mac-wd-00 > > > > The authors have asked for it to be adopted as a WG draft, but at this s= tage > > the chairs' view is that it probably hasn't had enough sets of eyes on i= t. > > > > So this email is to request that those on the list take a read of the dr= aft > > and send comments back to the list. Depending on the response we get > we > > may > > then ask the WG if they feel happy adopting this as a WG draft. > > > > Nabil and 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 lucy.yong@huawei.com Thu May 10 07: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 B1DCC21F86A4 for ; Thu, 10 May 2012 07:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 qOLsGG6crAMp for ; Thu, 10 May 2012 07:38:55 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 01FB921F8636 for ; Thu, 10 May 2012 07:38:54 -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 AGA61176; Thu, 10 May 2012 10:38:54 -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; Thu, 10 May 2012 07:35:47 -0700 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Thu, 10 May 2012 07:35:48 -0700 From: Lucy yong To: Balaji Venkat Venkataswami , "giles.heron@gmail.com" , "l2vpn@ietf.org" Subject: RE: PBB E-VPN and TRILL Thread-Topic: PBB E-VPN and TRILL Thread-Index: Ac0t4AvyMdWKxMA3AUSUMcn62xbEYQAmBZ9AAAGW1qAADswyEA== Date: Thu, 10 May 2012 14:35:48 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D33107E1C@dfweml506-mbx> References: <5EC91DDA759C324DB62C5A5F7B4922193CC839078C@EXCH-CLUSTER-11.force10networks.com> In-Reply-To: <5EC91DDA759C324DB62C5A5F7B4922193CC839078C@EXCH-CLUSTER-11.force10networks.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.136.151] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "sajassi@cisco.com" , "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, 10 May 2012 14:38:55 -0000 There is another draft to be considered. http://tools.ietf.org/html/draft-yong-trill-trill-o-mpls-01.txt Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of B= alaji Venkat Venkataswami Sent: Thursday, May 10, 2012 2:34 AM To: giles.heron@gmail.com; l2vpn@ietf.org Cc: sajassi@cisco.com; stbryant@cisco.com Subject: PBB E-VPN and TRILL Hi Giles, I totally agree on this point. We have a solution that was presented to the= TRILL working group as well on the interconnection of TRILL islands. We would lik= e to=20 concur with this and request for entering our draft as well into the soluti= on space. The URL for the TRILL draft is as follows. http://tools.ietf.org/html/draft-balaji-trill-over-ip-multi-level-05 thanks and regards, balaji venkat Sent: Wednesday, May 09, 2012 6:04 PM=09 To: l2vpn@ietf.org Cc: Ali Sajassi (sajassi); Stewart Bryant Subject: PBB E-VPN and TRILL Ali presented the PBB-EVPN draft at IETF83 in Paris: http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-01 This has since been updated: http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-02 During our discussions Ali mentioned that the authors would like the TRILL = section of the draft to be separated out into a separate draft. In respons= e Stewart questioned whether interconnecting TRILL islands is in-scope for = L2VPN. Stewart, Nabil and I have just been discussing these issues. Whilst TRILL = interconnect is not explicitly in-charter for L2VPN it would appear to be i= mplicitly in-charter - our decision to standardise solutions for PBB VPLS a= nd PBB E-VPN probably sets a precedent (since PBB is also unmentioned by th= e charter). On this basis we would like to ask the WG the following three questions: 1) is the WG happy for us to pursue interconnection of TRILL islands over L= 2VPN? 2) is the WG happy for the authors to split the TRILL section of the PBB E-= VPN draft into a separate draft? 3) is the WG happy for the TRILL draft to be a WG doc? Please respond by May 22nd if you are unhappy with any of these 3 actions (= I'll take no response to mean the WG is in agreement with us proceeding...) Giles From sboutros@cisco.com Thu May 10 08:35: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 AC63E21F86DF for ; Thu, 10 May 2012 08:35:01 -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=[AWL=0.000, 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 sl9DhXkwgmjX for ; Thu, 10 May 2012 08:35:00 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id A128221F86C5 for ; Thu, 10 May 2012 08:35:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sboutros@cisco.com; l=4994; q=dns/txt; s=iport; t=1336664100; x=1337873700; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=uyzlr4SSFoX1agaBw4ye/tkwxAU9gLK9mseTXcY9eXc=; b=ekRhsdUOPOFUIUVk1UXA1cy5ojhZMfOFg7Zj4cf8fPIS8ZN1FNf/6cHF fbnHHB9Wnj6v0KGhtPenIgcss6HJhXcXHGtAQKAnHlc9gpffPV63/R/0M 9m7vkMZcGiKO6ViXCcmKgVSUZDeQCNvgDQKbr9wsdHO6A/Ak5dsXx7k8H o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAMffq0+tJXG8/2dsb2JhbABEtBKBB4IVAQEBAwESASc6BQwECxEEAQEoB0YJCAYTIodnBQubIKAdixIZhS1jBIhkjRmBEY1GgWmDCYE/ X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="82087627" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 10 May 2012 15:34:45 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q4AFYeTe002562; Thu, 10 May 2012 15:34:44 GMT Received: from xfe-rcd-301.cisco.com ([72.163.63.12]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 May 2012 10:34:42 -0500 Received: from rtp-vpn4-3.cisco.com ([10.82.208.3]) by xfe-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 May 2012 10:34:41 -0500 Subject: Re: Static VPLS MAC withdrawal draft Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Sami Boutros In-Reply-To: Date: Thu, 10 May 2012 08:34:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <32B4F6D6-CB5A-4DE9-8A14-B04B175BC30E@cisco.com> References: To: Alexander Vainshtein X-Mailer: Apple Mail (2.1251.1) X-OriginalArrivalTime: 10 May 2012 15:34:41.0801 (UTC) FILETIME=[6B0AB790:01CD2EC2] Cc: "l2vpn@ietf.org" , "msiva@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, 10 May 2012 15:35:01 -0000 Hi Saha, Thanks for your comments, Please see responses inline.. >=20 >=20 >> -----Original Message----- >> From: Alexander Vainshtein >> Sent: Thursday, May 10, 2012 5:08 PM >> To: 'msiva@cisco.com:'; Sami Boutros (sboutros@cisco.com); >> 'nmcgill@cisco.com' >> Cc: l2vpn@ietf.org; 'Giles Heron'; Rotem Cohen; Andrew Sergeev; = Mishael >> Wexler; Gideon Agmon >> Subject: RE: Static VPLS MAC withdrawal draft >>=20 >> Hi all, >> I've read the draft in question and I would like to clarify several = issues that >> look either undefined or ambiguous to me. >>=20 >> 1. To the best of my understanding, the draft requires each PE = participating >> in a given VPLS instance to set up two counters for each static PW >> connecting it to a peer PE device in this VPLS instance: one for = static MAC >> withdrawal messages it is going to send and another - for static MAC >> withdrawal messages it receives. Is this understanding correct? >>=20 Sami: This is correct. >> 2. Assuming a positive answer to the previous questions, how are = these >> counters initialized? The draft seems to be moot on this point. Sami: This is what the draft has for setting up the sequence # in = section 3. Only half of the sequence number space is used. Modular arithmetic is used to detect wrapping of sequence number. When sequence number wraps (i.e., when it becomes 0), all MAC addresses are flushed and the sequence number is reset. Sami: Can you please explain what's vague in the above? >> The more >> interesting question is, of course, about initialization of the = counter of >> received static MAC withdrawal messages, since, with static PWs, = generally >> speaking, there is no synchronization between setting up one of its = end >> points and setting up another one. Sami: Initially the rx sequence # can be assumed to be 0. >>=20 >> 3. The draft specifies that: >> - The transmitter sends the MAC withdrawal message with the same >> sequence number until it receives an ACK for it (Section 4.1.1) >> - The receiver, after having acknowledged a MAC withdrawal >> message, ignores refresh messages with the same sequence number >> (Section 4.1.2) >> What is supposed to happen in the following scenario: >> - Transmitter finds out that some MACs have to be withdrawn = (e.g., >> because the AC from which they have been learned fails) >> and sends a MAC withdrawal message to its peers with sequence >> number N >> - Immediately after that (i.e., before it receives an ACK for = this >> message) it finds out that yet another set of MAC addresses has to be >> withdrawn >> - Retransmission timer expires without ACK received. >>=20 Sami: A new sequence # will be transmitted that will include both sets = of MAC addresses=20 Sami: that need to be flushed, and the transmitter will wait for an ack = for this new sequence #. Sami: We can add this to the draft.=20 >> 4. Suppose that only one end point of a static PW between a given = pair of >> peers has been set up. In this case transmitting the static MAC = withdrawal >> messages via such a PW is possible, but ACKs will never be received. = Should >> retransmission of these messages go on "ad infinitum"? >>=20 Sami: Yes, this will be the case, the mechanism will be no different = then the static PW status one for this case.=20 >> 5. The draft does not specify any default value for the retransmit = time. >>=20 Sami: Sure will add. >> 6. A nit: Heading of Section 4 is followed by headings for Sections = 4.1.1 and >> 4.1.2 without any heading for 4.1. >>=20 Sami: Sure will fix. >> Hopefully these questions will be useful. >>=20 Thanks, Sami >> Regards, >> Sasha >>=20 >>> -----Original Message----- >>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On = Behalf >>> Of Giles Heron >>> Sent: Tuesday, May 08, 2012 10:06 PM >>> To: l2vpn@ietf.org >>> Subject: Static VPLS MAC withdrawal draft >>>=20 >>> Hi everyone, >>>=20 >>> The following draft was presented at IETF in Paris: >>>=20 >>> http://tools.ietf.org/html/draft-boutros-l2vpn-mpls-tp-mac-wd-00 >>>=20 >>> The authors have asked for it to be adopted as a WG draft, but at = this stage >>> the chairs' view is that it probably hasn't had enough sets of eyes = on it. >>>=20 >>> So this email is to request that those on the list take a read of = the draft >>> and send comments back to the list. Depending on the response we = get >> we >>> may >>> then ask the WG if they feel happy adopting this as a WG draft. >>>=20 >>> Nabil and Giles >>>=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 dcai@cisco.com Thu May 10 09:02: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 DE18B21F86C5 for ; Thu, 10 May 2012 09:02:21 -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 JCAqCx0QrmL0 for ; Thu, 10 May 2012 09:02:21 -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 4944921F86A4 for ; Thu, 10 May 2012 09:02:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dcai@cisco.com; l=1545; q=dns/txt; s=iport; t=1336665741; x=1337875341; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=LO7CGaxqnTJ88CpU1uMh2J2XXQo7nplhVGN0jzsLmrg=; b=kF/sv64ucgkFIY+Gt8E+7iiVd54AT8YBf5kRJDW7cyYPtVTZthUbQmMn 7q58KG2AwWAqHZV0i72ZHN+uLaiHre6t5DJftmiFTB29QghO7tbci98ih ZHx5IfPc5+ut1aO5CAxcFSKD0wSG31exvNCYpCvrnMyB5rvQuugUd7s2h c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMTjq0+rRDoJ/2dsb2JhbABEtBKBB4IVAQEBBBIBHQo/DAQCAQgRBAEBCwYXAQYBRQkIAQEEARIIEweHawELmyKgH4sShUZjBIhkjiqNRoFpgwk X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="41165498" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 10 May 2012 16:02:21 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q4AG2Kxd026551; Thu, 10 May 2012 16:02:21 GMT Received: from xmb-sjc-237.amer.cisco.com ([128.107.191.123]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 May 2012 09:02:20 -0700 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: PBB E-VPN and TRILL Date: Thu, 10 May 2012 09:02:20 -0700 Message-ID: <9F6983FDF628744193C9268DB08B97B704F0D05E@xmb-sjc-237.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PBB E-VPN and TRILL thread-index: Ac0t4AvyMdWKxMA3AUSUMcn62xbEYQA5jKpg References: From: "Dennis Cai (dcai)" To: "Giles Heron" , X-OriginalArrivalTime: 10 May 2012 16:02:20.0737 (UTC) FILETIME=[47D84310:01CD2EC6] Cc: "Ali Sajassi \(sajassi\)" , "Stewart Bryant \(stbryant\)" 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, 10 May 2012 16:02:22 -0000 Yes Yes Yes -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Giles Heron Sent: Wednesday, May 09, 2012 5:34 AM To: l2vpn@ietf.org Cc: Ali Sajassi (sajassi); Stewart Bryant (stbryant) Subject: PBB E-VPN and TRILL Ali presented the PBB-EVPN draft at IETF83 in Paris: http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-01 This has since been updated: http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-02 During our discussions Ali mentioned that the authors would like the TRILL section of the draft to be separated out into a separate draft. In response Stewart questioned whether interconnecting TRILL islands is in-scope for L2VPN. Stewart, Nabil and I have just been discussing these issues. Whilst TRILL interconnect is not explicitly in-charter for L2VPN it would appear to be implicitly in-charter - our decision to standardise solutions for PBB VPLS and PBB E-VPN probably sets a precedent (since PBB is also unmentioned by the charter). On this basis we would like to ask the WG the following three questions: 1) is the WG happy for us to pursue interconnection of TRILL islands over L2VPN? 2) is the WG happy for the authors to split the TRILL section of the PBB E-VPN draft into a separate draft? 3) is the WG happy for the TRILL draft to be a WG doc? Please respond by May 22nd if you are unhappy with any of these 3 actions (I'll take no response to mean the WG is in agreement with us proceeding...) Giles From saalvare@cisco.com Thu May 10 09:26: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 2B11321F8702 for ; Thu, 10 May 2012 09:26:20 -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 Sw6guQZAmcGe for ; Thu, 10 May 2012 09:26:19 -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 488D321F859B for ; Thu, 10 May 2012 09:26:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=saalvare@cisco.com; l=1674; q=dns/txt; s=iport; t=1336667171; x=1337876771; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=9xt2blRY2FkxhnQovwk4TG43+ySSXYrbadsHlgIyrUo=; b=UsqfwgV09+LcvvFNpfnTg8jG+BUOa38bZ6ZM+j35qvL23b3WSfhXeCom kT9QrLshVRikO/i98PT2SH39vINLAd80ykgjPYgdD2mygCrfcDnwpjv7u kCOMOLMmCG0m3IJ+MrXAT+lgYN/zqLQTBf6ixfkZlHpqWOEIbaxbDTqjh 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALHrq0+rRDoI/2dsb2JhbABEtBKBB4IVAQEBBBIBHQo/DAQCAQgRBAEBCwYXAQYBRQkIAQEEARIIEweHawELmymgJosShUZjBIhkjiqNRoFpgwk X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="44190694" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 10 May 2012 16:26:03 +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 q4AGQ2l3006132; Thu, 10 May 2012 16:26:02 GMT Received: from xmb-sjc-22b.amer.cisco.com ([128.107.191.112]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 May 2012 09:26:02 -0700 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: PBB E-VPN and TRILL Date: Thu, 10 May 2012 09:25:57 -0700 Message-ID: <96327EF53EF71A48806DE2DFC034D57F115A1644@xmb-sjc-22b.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PBB E-VPN and TRILL Thread-Index: Ac0t4AvyMdWKxMA3AUSUMcn62xbEYQA6Xpwg References: From: "Santiago Alvarez (saalvare)" To: "Giles Heron" , X-OriginalArrivalTime: 10 May 2012 16:26:02.0625 (UTC) FILETIME=[975B2710:01CD2EC9] Cc: "Ali Sajassi \(sajassi\)" , "Stewart Bryant \(stbryant\)" 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, 10 May 2012 16:26:20 -0000 Yes to all three. SA -- > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of > Giles Heron > Sent: Wednesday, May 09, 2012 5:34 AM > To: l2vpn@ietf.org > Cc: Ali Sajassi (sajassi); Stewart Bryant (stbryant) > Subject: PBB E-VPN and TRILL >=20 > Ali presented the PBB-EVPN draft at IETF83 in Paris: >=20 > http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-01 >=20 > This has since been updated: >=20 > http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-02 >=20 > During our discussions Ali mentioned that the authors would like the TRILL > section of the draft to be separated out into a separate draft. In response > Stewart questioned whether interconnecting TRILL islands is in-scope for > L2VPN. >=20 > Stewart, Nabil and I have just been discussing these issues. Whilst TRILL > interconnect is not explicitly in-charter for L2VPN it would appear to be > implicitly in-charter - our decision to standardise solutions for PBB VPLS > and PBB E-VPN probably sets a precedent (since PBB is also unmentioned by > the charter). >=20 > On this basis we would like to ask the WG the following three questions: >=20 > 1) is the WG happy for us to pursue interconnection of TRILL islands over > L2VPN? >=20 > 2) is the WG happy for the authors to split the TRILL section of the PBB E- > VPN draft into a separate draft? >=20 > 3) is the WG happy for the TRILL draft to be a WG doc? >=20 > Please respond by May 22nd if you are unhappy with any of these 3 actions > (I'll take no response to mean the WG is in agreement with us proceeding...) >=20 > Giles >=20 From wim.henderickx@alcatel-lucent.com Thu May 10 09:27: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 34E8E21F86F8 for ; Thu, 10 May 2012 09:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.971 X-Spam-Level: X-Spam-Status: No, score=-9.971 tagged_above=-999 required=5 tests=[AWL=0.278, 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 5sC40mYkyT7Y for ; Thu, 10 May 2012 09:27:10 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 664F221F86C7 for ; Thu, 10 May 2012 09:27:10 -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 q4AGR53O027837 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 10 May 2012 18:27:06 +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; Thu, 10 May 2012 18:27:05 +0200 From: "Henderickx, Wim (Wim)" To: "Santiago Alvarez (saalvare)" , Giles Heron , "l2vpn@ietf.org" Date: Thu, 10 May 2012 18:27:04 +0200 Subject: RE: PBB E-VPN and TRILL Thread-Topic: PBB E-VPN and TRILL Thread-Index: Ac0t4AvyMdWKxMA3AUSUMcn62xbEYQA6XpwgAAAL5rA= Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D6702DE0CC36F@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <96327EF53EF71A48806DE2DFC034D57F115A1644@xmb-sjc-22b.amer.cisco.com> In-Reply-To: <96327EF53EF71A48806DE2DFC034D57F115A1644@xmb-sjc-22b.amer.cisco.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "Ali Sajassi \(sajassi\)" , "Stewart Bryant \(stbryant\)" 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, 10 May 2012 16:27:11 -0000 Same, yes to all 3 -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of S= antiago Alvarez (saalvare) Sent: donderdag 10 mei 2012 18:26 To: Giles Heron; l2vpn@ietf.org Cc: Ali Sajassi (sajassi); Stewart Bryant (stbryant) Subject: RE: PBB E-VPN and TRILL Yes to all three. SA -- > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of > Giles Heron > Sent: Wednesday, May 09, 2012 5:34 AM > To: l2vpn@ietf.org > Cc: Ali Sajassi (sajassi); Stewart Bryant (stbryant) > Subject: PBB E-VPN and TRILL >=20 > Ali presented the PBB-EVPN draft at IETF83 in Paris: >=20 > http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-01 >=20 > This has since been updated: >=20 > http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-02 >=20 > During our discussions Ali mentioned that the authors would like the TRILL > section of the draft to be separated out into a separate draft. In response > Stewart questioned whether interconnecting TRILL islands is in-scope for > L2VPN. >=20 > Stewart, Nabil and I have just been discussing these issues. Whilst TRILL > interconnect is not explicitly in-charter for L2VPN it would appear to be > implicitly in-charter - our decision to standardise solutions for PBB VPLS > and PBB E-VPN probably sets a precedent (since PBB is also unmentioned by > the charter). >=20 > On this basis we would like to ask the WG the following three questions: >=20 > 1) is the WG happy for us to pursue interconnection of TRILL islands over > L2VPN? >=20 > 2) is the WG happy for the authors to split the TRILL section of the PBB E- > VPN draft into a separate draft? >=20 > 3) is the WG happy for the TRILL draft to be a WG doc? >=20 > Please respond by May 22nd if you are unhappy with any of these 3 actions > (I'll take no response to mean the WG is in agreement with us proceeding...) >=20 > Giles >=20 From prvs=04773fefff=hshah@ciena.com Thu May 10 09:38: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 639D121F8645 for ; Thu, 10 May 2012 09:38:19 -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=[AWL=0.000, 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 XsgFZ46-lPfI for ; Thu, 10 May 2012 09:38:18 -0700 (PDT) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) by ietfa.amsl.com (Postfix) with ESMTP id CF33021F84FD for ; Thu, 10 May 2012 09:38:18 -0700 (PDT) Received: from pps.filterd (m0000419 [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.14.4/8.14.4) with SMTP id q4AGY53R014678; Thu, 10 May 2012 12:38:13 -0400 Received: from mdwexght02.ciena.com (LIN1-118-36-29.ciena.com [63.118.36.29]) by mx0a-00103a01.pphosted.com with ESMTP id 14rhacr0ha-3 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 10 May 2012 12:38:13 -0400 Received: from MDWEXGMB02.ciena.com ([::1]) by MDWEXGHT02.ciena.com ([::1]) with mapi; Thu, 10 May 2012 12:38:10 -0400 From: "Shah, Himanshu" To: "Henderickx, Wim (Wim)" , "Santiago Alvarez (saalvare)" , Giles Heron , "l2vpn@ietf.org" Date: Thu, 10 May 2012 12:38:09 -0400 Subject: RE: PBB E-VPN and TRILL Thread-Topic: PBB E-VPN and TRILL Thread-Index: Ac0t4AvyMdWKxMA3AUSUMcn62xbEYQA6XpwgAAAL5rAAAAZYEA== Message-ID: References: <96327EF53EF71A48806DE2DFC034D57F115A1644@xmb-sjc-22b.amer.cisco.com> <14C7F4F06DB5814AB0DE29716C4F6D6702DE0CC36F@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D6702DE0CC36F@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 x-tm-as-product-ver: SMEX-10.0.0.1412-6.800.1017-18898.000 x-tm-as-result: No--34.313200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7580, 1.0.260, 0.0.0000 definitions=2012-05-10_06:2012-05-10, 2012-05-10, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1205100162 Cc: "Ali Sajassi \(sajassi\)" , "Stewart Bryant \(stbryant\)" 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, 10 May 2012 16:38:19 -0000 Yes to first 2. As for 3rd, before we induct the stated draft as WG doc, we should consider= other two proposals mentioned in the mailing list, as part of due diligence. This is the only f= air way, and in fact, consideration to responses to third question be postponed until other propo= sals have been given chance to be reviewed at the WG, IMO. /himanshu -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of H= enderickx, Wim (Wim) Sent: Thursday, May 10, 2012 12:27 PM To: Santiago Alvarez (saalvare); Giles Heron; l2vpn@ietf.org Cc: Ali Sajassi (sajassi); Stewart Bryant (stbryant) Subject: RE: PBB E-VPN and TRILL Same, yes to all 3 -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of S= antiago Alvarez (saalvare) Sent: donderdag 10 mei 2012 18:26 To: Giles Heron; l2vpn@ietf.org Cc: Ali Sajassi (sajassi); Stewart Bryant (stbryant) Subject: RE: PBB E-VPN and TRILL Yes to all three. SA -- > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of > Giles Heron > Sent: Wednesday, May 09, 2012 5:34 AM > To: l2vpn@ietf.org > Cc: Ali Sajassi (sajassi); Stewart Bryant (stbryant) > Subject: PBB E-VPN and TRILL >=20 > Ali presented the PBB-EVPN draft at IETF83 in Paris: >=20 > http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-01 >=20 > This has since been updated: >=20 > http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-02 >=20 > During our discussions Ali mentioned that the authors would like the TRILL > section of the draft to be separated out into a separate draft. In response > Stewart questioned whether interconnecting TRILL islands is in-scope for > L2VPN. >=20 > Stewart, Nabil and I have just been discussing these issues. Whilst TRILL > interconnect is not explicitly in-charter for L2VPN it would appear to be > implicitly in-charter - our decision to standardise solutions for PBB VPLS > and PBB E-VPN probably sets a precedent (since PBB is also unmentioned by > the charter). >=20 > On this basis we would like to ask the WG the following three questions: >=20 > 1) is the WG happy for us to pursue interconnection of TRILL islands over > L2VPN? >=20 > 2) is the WG happy for the authors to split the TRILL section of the PBB E- > VPN draft into a separate draft? >=20 > 3) is the WG happy for the TRILL draft to be a WG doc? >=20 > Please respond by May 22nd if you are unhappy with any of these 3 actions > (I'll take no response to mean the WG is in agreement with us proceeding...) >=20 > Giles >=20 From sajassi@cisco.com Thu May 10 09:46: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 AD82621F86FA for ; Thu, 10 May 2012 09:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.3 X-Spam-Level: X-Spam-Status: No, score=-10.3 tagged_above=-999 required=5 tests=[AWL=0.299, 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 YhrTqgO2xJ3M for ; Thu, 10 May 2012 09:46:51 -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 E7A9B21F86F8 for ; Thu, 10 May 2012 09:46:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sajassi@cisco.com; l=3188; q=dns/txt; s=iport; t=1336668411; x=1337878011; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=uI1vlW+hdvD/sLq2xbnJHIBDvGqrE+10DwXwjTHrYXA=; b=HCIPzXdxDRmUx79bVVQ8J5sV/AQeDHf2a1EKK+jN7nxwFyM/ZUy0XJrs BraX1jGflFPeU1MABH56856qzwNEbH8Qg0LuXvzkR5TNyHOQH6tAg6Vse Q4ba4s0P8s+k2KhXSTO1uZKYVidiDnARKDJbbpVOOYgAg56YXMw5pB4TK s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALXwq0+rRDoG/2dsb2JhbABEtBKBB4IVAQEBAwESAScCATELBQcGAQgRBAEBKE0JCAEBBAENBRsHh2cEAQubJaAmixKGKQSIZI0ZgRGNRoFpgwk X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="44193407" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 10 May 2012 16:46:50 +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 q4AGkoe9007480; Thu, 10 May 2012 16:46:50 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); Thu, 10 May 2012 09:46:50 -0700 Received: from 10.128.2.64 ([10.128.2.64]) by xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) with Microsoft Exchange Server HTTP-DAV ; Thu, 10 May 2012 16:46:50 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Thu, 10 May 2012 09:46:49 -0700 Subject: Re: PBB E-VPN and TRILL From: Ali Sajassi To: "Shah, Himanshu" , "Henderickx, Wim (Wim)" , "Santiago Alvarez (saalvare)" , Giles Heron , "l2vpn@ietf.org" Message-ID: Thread-Topic: PBB E-VPN and TRILL Thread-Index: Ac0t4AvyMdWKxMA3AUSUMcn62xbEYQA6XpwgAAAL5rAAAAZYEAAAq7mv In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 10 May 2012 16:46:50.0564 (UTC) FILETIME=[7F2F8840:01CD2ECC] Cc: "Stewart Bryant \(stbryant\)" 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, 10 May 2012 16:46:51 -0000 Himanshu, PBB-EVPN is already a WG draft! And the TRILL portion of it has been presented to L2VPN WG and has been in discussions for quite some time. All we are doing is separating SPB/PBB from TRILL - nothing new is getting added. Whereas, the other drafts are all new and they came about during last IETF meeting. -Ali On 5/10/12 9:38 AM, "Shah, Himanshu" wrote: > Yes to first 2. > > As for 3rd, before we induct the stated draft as WG doc, we should consider > other two proposals > mentioned in the mailing list, as part of due diligence. This is the only fair > way, and in fact, > consideration to responses to third question be postponed until other > proposals have been given > chance to be reviewed at the WG, IMO. > > /himanshu > > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of > Henderickx, Wim (Wim) > Sent: Thursday, May 10, 2012 12:27 PM > To: Santiago Alvarez (saalvare); Giles Heron; l2vpn@ietf.org > Cc: Ali Sajassi (sajassi); Stewart Bryant (stbryant) > Subject: RE: PBB E-VPN and TRILL > > Same, yes to all 3 > > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of > Santiago Alvarez (saalvare) > Sent: donderdag 10 mei 2012 18:26 > To: Giles Heron; l2vpn@ietf.org > Cc: Ali Sajassi (sajassi); Stewart Bryant (stbryant) > Subject: RE: PBB E-VPN and TRILL > > Yes to all three. > > SA > -- > >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of >> Giles Heron >> Sent: Wednesday, May 09, 2012 5:34 AM >> To: l2vpn@ietf.org >> Cc: Ali Sajassi (sajassi); Stewart Bryant (stbryant) >> Subject: PBB E-VPN and TRILL >> >> Ali presented the PBB-EVPN draft at IETF83 in Paris: >> >> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-01 >> >> This has since been updated: >> >> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-02 >> >> During our discussions Ali mentioned that the authors would like the > TRILL >> section of the draft to be separated out into a separate draft. In > response >> Stewart questioned whether interconnecting TRILL islands is in-scope > for >> L2VPN. >> >> Stewart, Nabil and I have just been discussing these issues. Whilst > TRILL >> interconnect is not explicitly in-charter for L2VPN it would appear to > be >> implicitly in-charter - our decision to standardise solutions for PBB > VPLS >> and PBB E-VPN probably sets a precedent (since PBB is also unmentioned > by >> the charter). >> >> On this basis we would like to ask the WG the following three > questions: >> >> 1) is the WG happy for us to pursue interconnection of TRILL islands > over >> L2VPN? >> >> 2) is the WG happy for the authors to split the TRILL section of the > PBB E- >> VPN draft into a separate draft? >> >> 3) is the WG happy for the TRILL draft to be a WG doc? >> >> Please respond by May 22nd if you are unhappy with any of these 3 > actions >> (I'll take no response to mean the WG is in agreement with us > proceeding...) >> >> Giles >> > From prvs=04773fefff=hshah@ciena.com Thu May 10 10:03: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 C3E7121F85BB for ; Thu, 10 May 2012 10:03:40 -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=[AWL=0.000, 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 juMMaberRJDR for ; Thu, 10 May 2012 10:03:40 -0700 (PDT) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE2421F8592 for ; Thu, 10 May 2012 10:03:39 -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 q4AGxVeP012245; Thu, 10 May 2012 13:03:37 -0400 Received: from mdwexght02.ciena.com (LIN1-118-36-29.ciena.com [63.118.36.29]) by mx0b-00103a01.pphosted.com with ESMTP id 14rgcvr9f6-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 10 May 2012 13:03:37 -0400 Received: from MDWEXGMB02.ciena.com ([::1]) by MDWEXGHT02.ciena.com ([::1]) with mapi; Thu, 10 May 2012 13:03:37 -0400 From: "Shah, Himanshu" To: Ali Sajassi , "Henderickx, Wim (Wim)" , "Santiago Alvarez (saalvare)" , Giles Heron , "l2vpn@ietf.org" Date: Thu, 10 May 2012 13:03:36 -0400 Subject: RE: PBB E-VPN and TRILL Thread-Topic: PBB E-VPN and TRILL Thread-Index: Ac0t4AvyMdWKxMA3AUSUMcn62xbEYQA6XpwgAAAL5rAAAAZYEAAAq7mvAABE8iA= Message-ID: References: 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-18898.000 x-tm-as-result: No--38.546400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7580, 1.0.260, 0.0.0000 definitions=2012-05-10_06:2012-05-10, 2012-05-10, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1205100170 Cc: "Stewart Bryant \(stbryant\)" 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, 10 May 2012 17:03:40 -0000 Hi Ali - Correct.=20 But within the context of previous two, which questions whether to=20 consider interconnecting TRILL islands via L2VPN as part of WG charter, I t= hink you would agree that once TRILL portion is split from your base document,=20 it might be worth to check if other proposals has merits. Saying differently, if your split TRILL doc becomes WG doc at the same time= we include this work in the charter, other proposals would have no chance to b= e even considered..:-( IMHO - himanshu -----Original Message----- From: Ali Sajassi [mailto:sajassi@cisco.com]=20 Sent: Thursday, May 10, 2012 12:47 PM To: Shah, Himanshu; Henderickx, Wim (Wim); Santiago Alvarez (saalvare); Gil= es Heron; l2vpn@ietf.org Cc: Stewart Bryant (stbryant) Subject: Re: PBB E-VPN and TRILL Himanshu, PBB-EVPN is already a WG draft! And the TRILL portion of it has been presented to L2VPN WG and has been in discussions for quite some time. All we are doing is separating SPB/PBB from TRILL - nothing new is getting added. Whereas, the other drafts are all new and they came about during las= t IETF meeting. -Ali On 5/10/12 9:38 AM, "Shah, Himanshu" wrote: > Yes to first 2. >=20 > As for 3rd, before we induct the stated draft as WG doc, we should consid= er > other two proposals > mentioned in the mailing list, as part of due diligence. This is the only= fair > way, and in fact, > consideration to responses to third question be postponed until other > proposals have been given > chance to be reviewed at the WG, IMO. >=20 > /himanshu >=20 > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of > Henderickx, Wim (Wim) > Sent: Thursday, May 10, 2012 12:27 PM > To: Santiago Alvarez (saalvare); Giles Heron; l2vpn@ietf.org > Cc: Ali Sajassi (sajassi); Stewart Bryant (stbryant) > Subject: RE: PBB E-VPN and TRILL >=20 > Same, yes to all 3 >=20 > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of > Santiago Alvarez (saalvare) > Sent: donderdag 10 mei 2012 18:26 > To: Giles Heron; l2vpn@ietf.org > Cc: Ali Sajassi (sajassi); Stewart Bryant (stbryant) > Subject: RE: PBB E-VPN and TRILL >=20 > Yes to all three. >=20 > SA > -- >=20 >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of >> Giles Heron >> Sent: Wednesday, May 09, 2012 5:34 AM >> To: l2vpn@ietf.org >> Cc: Ali Sajassi (sajassi); Stewart Bryant (stbryant) >> Subject: PBB E-VPN and TRILL >>=20 >> Ali presented the PBB-EVPN draft at IETF83 in Paris: >>=20 >> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-01 >>=20 >> This has since been updated: >>=20 >> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-02 >>=20 >> During our discussions Ali mentioned that the authors would like the > TRILL >> section of the draft to be separated out into a separate draft. In > response >> Stewart questioned whether interconnecting TRILL islands is in-scope > for >> L2VPN. >>=20 >> Stewart, Nabil and I have just been discussing these issues. Whilst > TRILL >> interconnect is not explicitly in-charter for L2VPN it would appear to > be >> implicitly in-charter - our decision to standardise solutions for PBB > VPLS >> and PBB E-VPN probably sets a precedent (since PBB is also unmentioned > by >> the charter). >>=20 >> On this basis we would like to ask the WG the following three > questions: >>=20 >> 1) is the WG happy for us to pursue interconnection of TRILL islands > over >> L2VPN? >>=20 >> 2) is the WG happy for the authors to split the TRILL section of the > PBB E- >> VPN draft into a separate draft? >>=20 >> 3) is the WG happy for the TRILL draft to be a WG doc? >>=20 >> Please respond by May 22nd if you are unhappy with any of these 3 > actions >> (I'll take no response to mean the WG is in agreement with us > proceeding...) >>=20 >> Giles >>=20 >=20 From sajassi@cisco.com Thu May 10 10:28: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 6076911E8095 for ; Thu, 10 May 2012 10:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.327 X-Spam-Level: X-Spam-Status: No, score=-10.327 tagged_above=-999 required=5 tests=[AWL=0.272, 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 VFZK61k7lryd for ; Thu, 10 May 2012 10:28:27 -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 3D5CE11E808D for ; Thu, 10 May 2012 10:28:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sajassi@cisco.com; l=4394; q=dns/txt; s=iport; t=1336670907; x=1337880507; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=AZDtbxNtjmni3QvWfspc89LjFy/YCm+1p2a9xgfUzpQ=; b=O0axagJw4bzmYEDcyemBP4GGQ7Cv7mWaaIbQNtFnWC7L4vGKtfRkXw0F iuiWqhgYIProjLT2xmDuwDX0J0gAfZF7EX5VuO5wqH6VMdmRF5UQ/H50O ds64ERgMP9daCPlu1Kl4z6LHetQa9Jh1067CWhMrVdTGlKTVsqSE7IPn9 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKP5q0+rRDoH/2dsb2JhbABEtBOBB4IVAQEBAwESAScCATELBQcGAQgRBAEBASdNCQgCBAENBRsHh2cEAQubL6AjixKGKQSIZI0ZgRGNRoFpgwk X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="41716860" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 10 May 2012 17:28:27 +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 q4AHSP99008385; Thu, 10 May 2012 17:28: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); Thu, 10 May 2012 10:28:24 -0700 Received: from 10.128.2.64 ([10.128.2.64]) by xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) with Microsoft Exchange Server HTTP-DAV ; Thu, 10 May 2012 17:28:24 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Thu, 10 May 2012 10:28:23 -0700 Subject: Re: PBB E-VPN and TRILL From: Ali Sajassi To: "Shah, Himanshu" , "Henderickx, Wim (Wim)" , "Santiago Alvarez (saalvare)" , Giles Heron , "l2vpn@ietf.org" Message-ID: Thread-Topic: PBB E-VPN and TRILL Thread-Index: Ac0t4AvyMdWKxMA3AUSUMcn62xbEYQA6XpwgAAAL5rAAAAZYEAAAq7mvAABE8iAAAS6xNQ== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 10 May 2012 17:28:24.0941 (UTC) FILETIME=[4DF341D0:01CD2ED2] Cc: "Stewart Bryant \(stbryant\)" 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, 10 May 2012 17:28:28 -0000 Hi Himanshu, I think every draft should be evaluated based on its own merits and if it is warranted there can be several drafts on this space. Cheers, Ali On 5/10/12 10:03 AM, "Shah, Himanshu" wrote: > Hi Ali - > > Correct. > > But within the context of previous two, which questions whether to > consider interconnecting TRILL islands via L2VPN as part of WG charter, I > think you > would agree that once TRILL portion is split from your base document, > it might be worth to check if other proposals has merits. > > Saying differently, if your split TRILL doc becomes WG doc at the same time we > include this work in the charter, other proposals would have no chance to be > even considered..:-( > > IMHO - himanshu > > > -----Original Message----- > From: Ali Sajassi [mailto:sajassi@cisco.com] > Sent: Thursday, May 10, 2012 12:47 PM > To: Shah, Himanshu; Henderickx, Wim (Wim); Santiago Alvarez (saalvare); Giles > Heron; l2vpn@ietf.org > Cc: Stewart Bryant (stbryant) > Subject: Re: PBB E-VPN and TRILL > > Himanshu, > > PBB-EVPN is already a WG draft! And the TRILL portion of it has been > presented to L2VPN WG and has been in discussions for quite some time. All > we are doing is separating SPB/PBB from TRILL - nothing new is getting > added. Whereas, the other drafts are all new and they came about during last > IETF meeting. > > -Ali > > > On 5/10/12 9:38 AM, "Shah, Himanshu" wrote: > >> Yes to first 2. >> >> As for 3rd, before we induct the stated draft as WG doc, we should consider >> other two proposals >> mentioned in the mailing list, as part of due diligence. This is the only >> fair >> way, and in fact, >> consideration to responses to third question be postponed until other >> proposals have been given >> chance to be reviewed at the WG, IMO. >> >> /himanshu >> >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >> Henderickx, Wim (Wim) >> Sent: Thursday, May 10, 2012 12:27 PM >> To: Santiago Alvarez (saalvare); Giles Heron; l2vpn@ietf.org >> Cc: Ali Sajassi (sajassi); Stewart Bryant (stbryant) >> Subject: RE: PBB E-VPN and TRILL >> >> Same, yes to all 3 >> >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >> Santiago Alvarez (saalvare) >> Sent: donderdag 10 mei 2012 18:26 >> To: Giles Heron; l2vpn@ietf.org >> Cc: Ali Sajassi (sajassi); Stewart Bryant (stbryant) >> Subject: RE: PBB E-VPN and TRILL >> >> Yes to all three. >> >> SA >> -- >> >>> -----Original Message----- >>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >> Of >>> Giles Heron >>> Sent: Wednesday, May 09, 2012 5:34 AM >>> To: l2vpn@ietf.org >>> Cc: Ali Sajassi (sajassi); Stewart Bryant (stbryant) >>> Subject: PBB E-VPN and TRILL >>> >>> Ali presented the PBB-EVPN draft at IETF83 in Paris: >>> >>> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-01 >>> >>> This has since been updated: >>> >>> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-02 >>> >>> During our discussions Ali mentioned that the authors would like the >> TRILL >>> section of the draft to be separated out into a separate draft. In >> response >>> Stewart questioned whether interconnecting TRILL islands is in-scope >> for >>> L2VPN. >>> >>> Stewart, Nabil and I have just been discussing these issues. Whilst >> TRILL >>> interconnect is not explicitly in-charter for L2VPN it would appear to >> be >>> implicitly in-charter - our decision to standardise solutions for PBB >> VPLS >>> and PBB E-VPN probably sets a precedent (since PBB is also unmentioned >> by >>> the charter). >>> >>> On this basis we would like to ask the WG the following three >> questions: >>> >>> 1) is the WG happy for us to pursue interconnection of TRILL islands >> over >>> L2VPN? >>> >>> 2) is the WG happy for the authors to split the TRILL section of the >> PBB E- >>> VPN draft into a separate draft? >>> >>> 3) is the WG happy for the TRILL draft to be a WG doc? >>> >>> Please respond by May 22nd if you are unhappy with any of these 3 >> actions >>> (I'll take no response to mean the WG is in agreement with us >> proceeding...) >>> >>> Giles >>> >> > From aldrin.ietf@gmail.com Thu May 10 10:30: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 690AE11E8096 for ; Thu, 10 May 2012 10:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.45 X-Spam-Level: X-Spam-Status: No, score=-3.45 tagged_above=-999 required=5 tests=[AWL=0.148, 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 DukoBUFU0aql for ; Thu, 10 May 2012 10:30:41 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC6011E808F for ; Thu, 10 May 2012 10:30:41 -0700 (PDT) Received: by dacx6 with SMTP id x6so2096858dac.31 for ; Thu, 10 May 2012 10:30:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=mZd7I5zgSt/ktczEMWsV0VUedFD4VLAwf5/CyLIDgkQ=; b=mjvZgP1O5laAXtfYL/b4zhjQSYRi2nkAAozfyTTB+c0gfHvMUSl4fmoFiNbB5wXL+B dgkQiUJGgv2w8wZ3RPBdmgS7nYQZIjOgwqoSJhGO9gAj+tgzma1Au1syOokmNeVCB4YU 4BFryH0zE994g2d0VHxJONaGMXP/thfSRBsEzKrGW+pvpq3EkLPbT8XkGwGEBuD8ANLs fPRro2yqgAYYq1r0b4N/KVStlo3FTV01MNiqlegOlQ8Cc3dg2yce1iwUPNiYn5kQ8+Wq ECiBAxHQ/GE7X+iKkflmwSsTsHPrbEGpblu4J2IjqBMP3FRDMSYw3pyy7CPM80l7aqAS Q2hA== Received: by 10.68.134.8 with SMTP id pg8mr844314pbb.152.1336671040872; Thu, 10 May 2012 10:30:40 -0700 (PDT) Received: from [192.168.1.2] (c-107-3-156-34.hsd1.ca.comcast.net. [107.3.156.34]) by mx.google.com with ESMTPS id oj3sm10094181pbb.20.2012.05.10.10.30.38 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 10 May 2012 10:30:39 -0700 (PDT) Subject: Re: PBB E-VPN and TRILL Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_1482A130-D139-47A7-8EA6-9CCBFCDC2F14" From: Sam Aldrin In-Reply-To: Date: Thu, 10 May 2012 10:30:37 -0700 Message-Id: <079D49EE-4277-4A4D-AC71-D5F0C41CAF05@gmail.com> References: To: "Shah, Himanshu" X-Mailer: Apple Mail (2.1257) Cc: "l2vpn@ietf.org" , Ali Sajassi , "Stewart Bryant \(stbryant\)" 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, 10 May 2012 17:30:42 -0000 --Apple-Mail=_1482A130-D139-47A7-8EA6-9CCBFCDC2F14 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Giles, Nabil and Stewart, I have couple of questions regarding the questions you posted. Please see inline with %SAM. -sam Ali presented the PBB-EVPN draft at IETF83 in Paris: http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-01 This has since been updated: http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-02 During our discussions Ali mentioned that the authors would like the = TRILL section of the draft to be separated out into a separate draft. In = response Stewart questioned whether interconnecting TRILL islands is in-scope for L2VPN. Stewart, Nabil and I have just been discussing these issues. Whilst = TRILL interconnect is not explicitly in-charter for L2VPN it would appear to = be implicitly in-charter - our decision to standardise solutions for PBB = VPLS and PBB E-VPN probably sets a precedent (since PBB is also unmentioned = by the charter). On this basis we would like to ask the WG the following three questions: 1) is the WG happy for us to pursue interconnection of TRILL islands = over L2VPN? %SAM - Connecting TRILL islands is not necessary L2 all the time. It = could be IP or MPLS or something else. So, if the L2 WG charter includes = connecting TRILL islands, and should be dealt in L2 WG, where should = interconnecting TRILL islands over IP etc should be handled? Also, if = the interconnection doesn't involve any L2VPN enhancements, but purely = TRILL enhancements, should it still be in L2VPN WG scope?=20 2) is the WG happy for the authors to split the TRILL section of the PBB E-VPN draft into a separate draft? %SAM - Yes. 3) is the WG happy for the TRILL draft to be a WG doc? %SAM - I do not think, split document should be WG doc automatically. = Both L2VPN and TRILL WG should be requested for adoption. Without the = document out there, how can we consider a document to be WG document? Please respond by May 22nd if you are unhappy with any of these 3 = actions (I'll take no response to mean the WG is in agreement with us = proceeding...) Giles --Apple-Mail=_1482A130-D139-47A7-8EA6-9CCBFCDC2F14 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Ali presented the PBB-EVPN draft at = IETF83 in Paris: http://to= ols.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-01 This has since been updated: http://to= ols.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-02 During our discussions Ali mentioned that the authors would like the = TRILL section of the draft to be separated out into a separate draft. In = response Stewart questioned whether interconnecting TRILL islands is in-scope for L2VPN. Stewart, Nabil and I have just been discussing these issues. Whilst = TRILL interconnect is not explicitly in-charter for L2VPN it would appear to = be implicitly in-charter - our decision to standardise solutions for PBB = VPLS and PBB E-VPN probably sets a precedent (since PBB is also unmentioned = by the charter). On this basis we would like to ask the WG the following three questions: 1) is the WG happy for us to pursue interconnection of TRILL islands = over L2VPN?
%SAM - =
Connecting TRILL islands is not necessary L2 all the time. It could be =
IP or MPLS or something else. So, if the L2 WG charter includes =
connecting TRILL islands, and should be dealt in L2 WG, where should =
interconnecting TRILL islands over IP etc should be handled? Also, if =
the interconnection doesn't involve any L2VPN enhancements, but purely =
TRILL enhancements, should it still be in L2VPN WG scope? 
2) is the WG happy for the authors to =
split the TRILL section of the PBB
E-VPN draft into a separate draft?
%SAM - Yes.

3) is the WG happy for the TRILL draft to be a WG doc?
%SAM - I do not think, split document =
should be WG doc automatically. Both L2VPN and TRILL WG should be =
requested for adoption. Without the document out there, how can we =
consider a document to be WG document?
Please respond by May 22nd if you are unhappy with any of these 3 =
actions
(I'll take no response to mean the WG is in agreement with us =
proceeding...)

Giles

= --Apple-Mail=_1482A130-D139-47A7-8EA6-9CCBFCDC2F14-- From prvs=04773fefff=hshah@ciena.com Thu May 10 10:45: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 B32F911E8094 for ; Thu, 10 May 2012 10:45:37 -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=[AWL=0.000, 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 VpzXjjitH2CL for ; Thu, 10 May 2012 10:45:33 -0700 (PDT) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6B311E808E for ; Thu, 10 May 2012 10:45:33 -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 q4AHjQjS007641; Thu, 10 May 2012 13:45:30 -0400 Received: from mdwexght02.ciena.com (LIN1-118-36-29.ciena.com [63.118.36.29]) by mx0b-00103a01.pphosted.com with ESMTP id 14rgcvrf4e-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 10 May 2012 13:45:30 -0400 Received: from MDWEXGMB02.ciena.com ([::1]) by MDWEXGHT02.ciena.com ([::1]) with mapi; Thu, 10 May 2012 13:45:30 -0400 From: "Shah, Himanshu" To: Ali Sajassi , "Henderickx, Wim (Wim)" , "Santiago Alvarez (saalvare)" , Giles Heron , "l2vpn@ietf.org" Date: Thu, 10 May 2012 13:45:28 -0400 Subject: RE: PBB E-VPN and TRILL Thread-Topic: PBB E-VPN and TRILL Thread-Index: Ac0t4AvyMdWKxMA3AUSUMcn62xbEYQA6XpwgAAAL5rAAAAZYEAAAq7mvAABE8iAAAS6xNQAAEcqw Message-ID: References: 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-18898.000 x-tm-as-result: No--44.772000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7580, 1.0.260, 0.0.0000 definitions=2012-05-10_06:2012-05-10, 2012-05-10, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1205100185 Cc: "Stewart Bryant \(stbryant\)" 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, 10 May 2012 17:45:37 -0000 I think you are partially agreeing with me :-) We only need to give a chance for other docs to stand on its own merit. Based on my understanding, all the proposals are considered BEFORE one is picked (with or without consolidation) for WG doc. Thanks, himanshu -----Original Message----- From: Ali Sajassi [mailto:sajassi@cisco.com]=20 Sent: Thursday, May 10, 2012 1:28 PM To: Shah, Himanshu; Henderickx, Wim (Wim); Santiago Alvarez (saalvare); Gil= es Heron; l2vpn@ietf.org Cc: Stewart Bryant (stbryant) Subject: Re: PBB E-VPN and TRILL Hi Himanshu, I think every draft should be evaluated based on its own merits and if it i= s warranted there can be several drafts on this space. Cheers, Ali=20 On 5/10/12 10:03 AM, "Shah, Himanshu" wrote: > Hi Ali - >=20 > Correct.=20 >=20 > But within the context of previous two, which questions whether to > consider interconnecting TRILL islands via L2VPN as part of WG charter, I > think you > would agree that once TRILL portion is split from your base document, > it might be worth to check if other proposals has merits. >=20 > Saying differently, if your split TRILL doc becomes WG doc at the same ti= me we > include this work in the charter, other proposals would have no chance to= be > even considered..:-( >=20 > IMHO - himanshu >=20 >=20 > -----Original Message----- > From: Ali Sajassi [mailto:sajassi@cisco.com] > Sent: Thursday, May 10, 2012 12:47 PM > To: Shah, Himanshu; Henderickx, Wim (Wim); Santiago Alvarez (saalvare); G= iles > Heron; l2vpn@ietf.org > Cc: Stewart Bryant (stbryant) > Subject: Re: PBB E-VPN and TRILL >=20 > Himanshu, >=20 > PBB-EVPN is already a WG draft! And the TRILL portion of it has been > presented to L2VPN WG and has been in discussions for quite some time. Al= l > we are doing is separating SPB/PBB from TRILL - nothing new is getting > added. Whereas, the other drafts are all new and they came about during l= ast > IETF meeting. >=20 > -Ali >=20 >=20 > On 5/10/12 9:38 AM, "Shah, Himanshu" wrote: >=20 >> Yes to first 2. >>=20 >> As for 3rd, before we induct the stated draft as WG doc, we should consi= der >> other two proposals >> mentioned in the mailing list, as part of due diligence. This is the onl= y >> fair >> way, and in fact, >> consideration to responses to third question be postponed until other >> proposals have been given >> chance to be reviewed at the WG, IMO. >>=20 >> /himanshu >>=20 >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf O= f >> Henderickx, Wim (Wim) >> Sent: Thursday, May 10, 2012 12:27 PM >> To: Santiago Alvarez (saalvare); Giles Heron; l2vpn@ietf.org >> Cc: Ali Sajassi (sajassi); Stewart Bryant (stbryant) >> Subject: RE: PBB E-VPN and TRILL >>=20 >> Same, yes to all 3 >>=20 >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf O= f >> Santiago Alvarez (saalvare) >> Sent: donderdag 10 mei 2012 18:26 >> To: Giles Heron; l2vpn@ietf.org >> Cc: Ali Sajassi (sajassi); Stewart Bryant (stbryant) >> Subject: RE: PBB E-VPN and TRILL >>=20 >> Yes to all three. >>=20 >> SA >> -- >>=20 >>> -----Original Message----- >>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >> Of >>> Giles Heron >>> Sent: Wednesday, May 09, 2012 5:34 AM >>> To: l2vpn@ietf.org >>> Cc: Ali Sajassi (sajassi); Stewart Bryant (stbryant) >>> Subject: PBB E-VPN and TRILL >>>=20 >>> Ali presented the PBB-EVPN draft at IETF83 in Paris: >>>=20 >>> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-01 >>>=20 >>> This has since been updated: >>>=20 >>> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-02 >>>=20 >>> During our discussions Ali mentioned that the authors would like the >> TRILL >>> section of the draft to be separated out into a separate draft. In >> response >>> Stewart questioned whether interconnecting TRILL islands is in-scope >> for >>> L2VPN. >>>=20 >>> Stewart, Nabil and I have just been discussing these issues. Whilst >> TRILL >>> interconnect is not explicitly in-charter for L2VPN it would appear to >> be >>> implicitly in-charter - our decision to standardise solutions for PBB >> VPLS >>> and PBB E-VPN probably sets a precedent (since PBB is also unmentioned >> by >>> the charter). >>>=20 >>> On this basis we would like to ask the WG the following three >> questions: >>>=20 >>> 1) is the WG happy for us to pursue interconnection of TRILL islands >> over >>> L2VPN? >>>=20 >>> 2) is the WG happy for the authors to split the TRILL section of the >> PBB E- >>> VPN draft into a separate draft? >>>=20 >>> 3) is the WG happy for the TRILL draft to be a WG doc? >>>=20 >>> Please respond by May 22nd if you are unhappy with any of these 3 >> actions >>> (I'll take no response to mean the WG is in agreement with us >> proceeding...) >>>=20 >>> Giles >>>=20 >>=20 >=20 From sajassi@cisco.com Thu May 10 10: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 ADFC721F85FF for ; Thu, 10 May 2012 10:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.35 X-Spam-Level: X-Spam-Status: No, score=-10.35 tagged_above=-999 required=5 tests=[AWL=0.249, 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 wRVXMnpALhEZ for ; Thu, 10 May 2012 10:52:45 -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 2383421F85FD for ; Thu, 10 May 2012 10:52:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sajassi@cisco.com; l=5138; q=dns/txt; s=iport; t=1336672365; x=1337881965; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=/i/r2GZTtKWDvMnVlHi6X7jUYfEIc3vSFLWbHCVhF3g=; b=WJaXM89ntbGwepxlK59E/xmgIbIbsiFVPu5zbAaoraCQ2HOhgy5NIcf/ 3VAr1x+GaT3R9D8+cW39pPsDUrgJ6i6F/DhyG4aaFxTebLGNZWTn+I4LH srS2BuIxxWhn/sHl6eCJHrJUGluCpTQVAOIKBwsmKhOYNQ88SkQncf+M7 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOH/q0+rRDoH/2dsb2JhbABEtBSBB4IVAQEBAwESAScCATELDAYBCBEEAQEBJ00JCAIEAQ0FGweHZwQBC5szoCGLEoYpBIhkjRmBEY1GgWmDCQ X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="44294755" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 10 May 2012 17:52:44 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q4AHqiGD032706; Thu, 10 May 2012 17:52:44 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, 10 May 2012 10:52:44 -0700 Received: from 10.128.2.64 ([10.128.2.64]) by xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) with Microsoft Exchange Server HTTP-DAV ; Thu, 10 May 2012 17:52:44 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Thu, 10 May 2012 10:52:43 -0700 Subject: Re: PBB E-VPN and TRILL From: Ali Sajassi To: "Shah, Himanshu" , "Henderickx, Wim (Wim)" , "Santiago Alvarez (saalvare)" , Giles Heron , "l2vpn@ietf.org" Message-ID: Thread-Topic: PBB E-VPN and TRILL Thread-Index: Ac0t4AvyMdWKxMA3AUSUMcn62xbEYQA6XpwgAAAL5rAAAAZYEAAAq7mvAABE8iAAAS6xNQAAEcqwAADHxHE= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 10 May 2012 17:52:44.0636 (UTC) FILETIME=[B3FF09C0:01CD2ED5] Cc: "Stewart Bryant \(stbryant\)" 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, 10 May 2012 17:52:46 -0000 > > Based on my understanding, all the proposals are considered BEFORE > one is picked (with or without consolidation) for WG doc. One proposal is already part of WG draft. Would you please read the draft and then comment. Cheers, Ali > > Thanks, > himanshu > > > -----Original Message----- > From: Ali Sajassi [mailto:sajassi@cisco.com] > Sent: Thursday, May 10, 2012 1:28 PM > To: Shah, Himanshu; Henderickx, Wim (Wim); Santiago Alvarez (saalvare); Giles > Heron; l2vpn@ietf.org > Cc: Stewart Bryant (stbryant) > Subject: Re: PBB E-VPN and TRILL > > Hi Himanshu, > > I think every draft should be evaluated based on its own merits and if it is > warranted there can be several drafts on this space. > > Cheers, > Ali > > > On 5/10/12 10:03 AM, "Shah, Himanshu" wrote: > >> Hi Ali - >> >> Correct. >> >> But within the context of previous two, which questions whether to >> consider interconnecting TRILL islands via L2VPN as part of WG charter, I >> think you >> would agree that once TRILL portion is split from your base document, >> it might be worth to check if other proposals has merits. >> >> Saying differently, if your split TRILL doc becomes WG doc at the same time >> we >> include this work in the charter, other proposals would have no chance to be >> even considered..:-( >> >> IMHO - himanshu >> >> >> -----Original Message----- >> From: Ali Sajassi [mailto:sajassi@cisco.com] >> Sent: Thursday, May 10, 2012 12:47 PM >> To: Shah, Himanshu; Henderickx, Wim (Wim); Santiago Alvarez (saalvare); Giles >> Heron; l2vpn@ietf.org >> Cc: Stewart Bryant (stbryant) >> Subject: Re: PBB E-VPN and TRILL >> >> Himanshu, >> >> PBB-EVPN is already a WG draft! And the TRILL portion of it has been >> presented to L2VPN WG and has been in discussions for quite some time. All >> we are doing is separating SPB/PBB from TRILL - nothing new is getting >> added. Whereas, the other drafts are all new and they came about during last >> IETF meeting. >> >> -Ali >> >> >> On 5/10/12 9:38 AM, "Shah, Himanshu" wrote: >> >>> Yes to first 2. >>> >>> As for 3rd, before we induct the stated draft as WG doc, we should consider >>> other two proposals >>> mentioned in the mailing list, as part of due diligence. This is the only >>> fair >>> way, and in fact, >>> consideration to responses to third question be postponed until other >>> proposals have been given >>> chance to be reviewed at the WG, IMO. >>> >>> /himanshu >>> >>> -----Original Message----- >>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >>> Henderickx, Wim (Wim) >>> Sent: Thursday, May 10, 2012 12:27 PM >>> To: Santiago Alvarez (saalvare); Giles Heron; l2vpn@ietf.org >>> Cc: Ali Sajassi (sajassi); Stewart Bryant (stbryant) >>> Subject: RE: PBB E-VPN and TRILL >>> >>> Same, yes to all 3 >>> >>> -----Original Message----- >>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >>> Santiago Alvarez (saalvare) >>> Sent: donderdag 10 mei 2012 18:26 >>> To: Giles Heron; l2vpn@ietf.org >>> Cc: Ali Sajassi (sajassi); Stewart Bryant (stbryant) >>> Subject: RE: PBB E-VPN and TRILL >>> >>> Yes to all three. >>> >>> SA >>> -- >>> >>>> -----Original Message----- >>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>> Of >>>> Giles Heron >>>> Sent: Wednesday, May 09, 2012 5:34 AM >>>> To: l2vpn@ietf.org >>>> Cc: Ali Sajassi (sajassi); Stewart Bryant (stbryant) >>>> Subject: PBB E-VPN and TRILL >>>> >>>> Ali presented the PBB-EVPN draft at IETF83 in Paris: >>>> >>>> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-01 >>>> >>>> This has since been updated: >>>> >>>> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-02 >>>> >>>> During our discussions Ali mentioned that the authors would like the >>> TRILL >>>> section of the draft to be separated out into a separate draft. In >>> response >>>> Stewart questioned whether interconnecting TRILL islands is in-scope >>> for >>>> L2VPN. >>>> >>>> Stewart, Nabil and I have just been discussing these issues. Whilst >>> TRILL >>>> interconnect is not explicitly in-charter for L2VPN it would appear to >>> be >>>> implicitly in-charter - our decision to standardise solutions for PBB >>> VPLS >>>> and PBB E-VPN probably sets a precedent (since PBB is also unmentioned >>> by >>>> the charter). >>>> >>>> On this basis we would like to ask the WG the following three >>> questions: >>>> >>>> 1) is the WG happy for us to pursue interconnection of TRILL islands >>> over >>>> L2VPN? >>>> >>>> 2) is the WG happy for the authors to split the TRILL section of the >>> PBB E- >>>> VPN draft into a separate draft? >>>> >>>> 3) is the WG happy for the TRILL draft to be a WG doc? >>>> >>>> Please respond by May 22nd if you are unhappy with any of these 3 >>> actions >>>> (I'll take no response to mean the WG is in agreement with us >>> proceeding...) >>>> >>>> Giles >>>> >>> >> > From d3e3e3@gmail.com Thu May 10 10:57: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 7E8C321F8594 for ; Thu, 10 May 2012 10:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.698 X-Spam-Level: X-Spam-Status: No, score=-103.698 tagged_above=-999 required=5 tests=[AWL=-0.099, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNeOAYuYbwRV for ; Thu, 10 May 2012 10:57:19 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF6C21F8507 for ; Thu, 10 May 2012 10:57:19 -0700 (PDT) Received: by wibhr2 with SMTP id hr2so743267wib.13 for ; Thu, 10 May 2012 10:57:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=yihMCkIGj3BksMneVUYlEPIWBHrC17zs1yrI9ROkLbs=; b=PoGyLQMNkm4DQfdG0ksuQGbRR8+ejGUeiU9xZMRLjUm3pn1515lWftO7eEb9jPVzv6 /g+8zztRmGM1PPvtdZH/8YnaFX1zuQX1g2M11nR9jk5qFwtq5cQGJH0Vr+QLCUxvwXmD Ttd0z5/5TgGTZUzP1XWE4rHNy41yUgCmKuzJvgWlpt1hvj4WUylLraUz7tr87+mXKwdc AOUqBg8Tf7ZSmF3LlSx+JqfH+dVKLrELq0aerRquvJ0M6EVYwa67MPLZJhhw2la2hH8Q l6QkScytXSQ7X64Fun6NXwTO+sr4JVgyUuMa6XN6ifoYJrrJsejOX8/B4pzsDbtIoTTg pAdQ== Received: by 10.50.159.164 with SMTP id xd4mr4745822igb.13.1336672637251; Thu, 10 May 2012 10:57:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.59.201 with HTTP; Thu, 10 May 2012 10:56:56 -0700 (PDT) In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D33107E1C@dfweml506-mbx> References: <5EC91DDA759C324DB62C5A5F7B4922193CC839078C@EXCH-CLUSTER-11.force10networks.com> <2691CE0099834E4A9C5044EEC662BB9D33107E1C@dfweml506-mbx> From: Donald Eastlake Date: Thu, 10 May 2012 13:56:56 -0400 Message-ID: Subject: Re: PBB E-VPN and TRILL To: "l2vpn@ietf.org" , Lucy yong Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "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, 10 May 2012 17:57:20 -0000 On Thu, May 10, 2012 at 10:35 AM, Lucy yong wrote: > There is another draft to be considered. > > http://tools.ietf.org/html/draft-yong-trill-trill-o-mpls-01.txt There are a number of drafts but I think it is useful to make a distinction between drafts that provide full connectivity between TRILL switches (RBridges), so that they merge into a single TRILL campus, and drafts that provide for data plane connectivity but limited control plane connectivity for fault isolation, etc. TRILL switches are routers. Like IP routers they logically strip the link envelope from TRILL frames they receive and add a new, possible different technology, link envelope on TRILL frames they send. Just as it is possible to have an IP routed region where none of the connections between IP routers is Ethernet but could be, for example, PPP, it is possible to have a TRILL campus where none of the connections between the RBridges is Ethernet but they are all some other technology X, such as PPP. So, drafts that are "TRILL over X" that are talking about full TRILL data and control plan connectivity don't really seem to me to have much to do with L2VPN. Such drafts should be done in either the TRILL WG or in the WG that does technology X. It seems to me that L2VPN has to do with method that provide limited data plane interconnection for better fault isolation. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com > Lucy > > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of= Balaji Venkat Venkataswami > Sent: Thursday, May 10, 2012 2:34 AM > To: giles.heron@gmail.com; l2vpn@ietf.org > Cc: sajassi@cisco.com; stbryant@cisco.com > Subject: PBB E-VPN and TRILL > > Hi =A0Giles, > > I totally agree on this point. We have a solution that was presented to t= he TRILL > working group as well on the interconnection of TRILL islands. We would l= ike to > concur with this and request for entering our draft as well into the solu= tion space. > > The URL for the TRILL draft is as follows. > http://tools.ietf.org/html/draft-balaji-trill-over-ip-multi-level-05 > > > thanks and regards, > balaji venkat > > Sent: Wednesday, May 09, 2012 6:04 PM > To: l2vpn@ietf.org > Cc: Ali Sajassi (sajassi); Stewart Bryant > Subject: PBB E-VPN and TRILL > > Ali presented the PBB-EVPN draft at IETF83 in Paris: > > http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-01 > > This has since been updated: > > http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-02 > > During our discussions Ali mentioned that the authors would like the TRIL= L section of the draft to be separated out into a separate draft. =A0In res= ponse Stewart questioned whether interconnecting TRILL islands is in-scope = for L2VPN. > > Stewart, Nabil and I have just been discussing these issues. =A0Whilst TR= ILL interconnect is not explicitly in-charter for L2VPN it would appear to = be implicitly in-charter - our decision to standardise solutions for PBB VP= LS and PBB E-VPN probably sets a precedent (since PBB is also unmentioned b= y the charter). > > On this basis we would like to ask the WG the following three questions: > > 1) is the WG happy for us to pursue interconnection of TRILL islands over= L2VPN? > > 2) is the WG happy for the authors to split the TRILL section of the PBB = E-VPN draft into a separate draft? > > 3) is the WG happy for the TRILL draft to be a WG doc? > > Please respond by May 22nd if you are unhappy with any of these 3 actions= (I'll take no response to mean the WG is in agreement with us proceeding..= .) > > Giles > > From prvs=04773fefff=hshah@ciena.com Thu May 10 10:59: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 5125911E8096 for ; Thu, 10 May 2012 10:59:45 -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=[AWL=0.000, 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 vnYQHRYQsGxx for ; Thu, 10 May 2012 10:59:44 -0700 (PDT) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) by ietfa.amsl.com (Postfix) with ESMTP id 6040211E8094 for ; Thu, 10 May 2012 10:59:44 -0700 (PDT) Received: from pps.filterd (m0000419 [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.14.4/8.14.4) with SMTP id q4AHsws2029164; Thu, 10 May 2012 13:59:40 -0400 Received: from mdwexght01.ciena.com (LIN1-118-36-28.ciena.com [63.118.36.28]) by mx0a-00103a01.pphosted.com with ESMTP id 14rhacrbbv-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 10 May 2012 13:59:40 -0400 Received: from MDWEXGMB02.ciena.com ([::1]) by MDWEXGHT01.ciena.com ([::1]) with mapi; Thu, 10 May 2012 13:59:35 -0400 From: "Shah, Himanshu" To: Ali Sajassi , "Henderickx, Wim (Wim)" , "Santiago Alvarez (saalvare)" , Giles Heron , "l2vpn@ietf.org" Date: Thu, 10 May 2012 13:59:32 -0400 Subject: RE: PBB E-VPN and TRILL Thread-Topic: PBB E-VPN and TRILL Thread-Index: Ac0t4AvyMdWKxMA3AUSUMcn62xbEYQA6XpwgAAAL5rAAAAZYEAAAq7mvAABE8iAAAS6xNQAAEcqwAADHxHEAABYqEA== Message-ID: References: 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-18898.000 x-tm-as-result: No--43.336400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7580, 1.0.260, 0.0.0000 definitions=2012-05-10_06:2012-05-10, 2012-05-10, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1205100189 Cc: "Stewart Bryant \(stbryant\)" 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, 10 May 2012 17:59:45 -0000 Followings are the questions... 2) is the WG happy for the authors to split the TRILL section of the PBB E-= VPN draft into a separate draft? 3) is the WG happy for the TRILL draft to be a WG doc? I think we are discussing splitting the trill section as a separate draft a= nd making it a WG doc. What am I missing? /himanshu -----Original Message----- From: Ali Sajassi [mailto:sajassi@cisco.com]=20 Sent: Thursday, May 10, 2012 1:53 PM To: Shah, Himanshu; Henderickx, Wim (Wim); Santiago Alvarez (saalvare); Gil= es Heron; l2vpn@ietf.org Cc: Stewart Bryant (stbryant) Subject: Re: PBB E-VPN and TRILL >=20 > Based on my understanding, all the proposals are considered BEFORE > one is picked (with or without consolidation) for WG doc. One proposal is already part of WG draft. Would you please read the draft and then comment. Cheers, Ali >=20 > Thanks, > himanshu >=20 >=20 > -----Original Message----- > From: Ali Sajassi [mailto:sajassi@cisco.com] > Sent: Thursday, May 10, 2012 1:28 PM > To: Shah, Himanshu; Henderickx, Wim (Wim); Santiago Alvarez (saalvare); G= iles > Heron; l2vpn@ietf.org > Cc: Stewart Bryant (stbryant) > Subject: Re: PBB E-VPN and TRILL >=20 > Hi Himanshu, >=20 > I think every draft should be evaluated based on its own merits and if it= is > warranted there can be several drafts on this space. >=20 > Cheers, > Ali=20 >=20 >=20 > On 5/10/12 10:03 AM, "Shah, Himanshu" wrote: >=20 >> Hi Ali - >>=20 >> Correct.=20 >>=20 >> But within the context of previous two, which questions whether to >> consider interconnecting TRILL islands via L2VPN as part of WG charter, = I >> think you >> would agree that once TRILL portion is split from your base document, >> it might be worth to check if other proposals has merits. >>=20 >> Saying differently, if your split TRILL doc becomes WG doc at the same t= ime >> we >> include this work in the charter, other proposals would have no chance t= o be >> even considered..:-( >>=20 >> IMHO - himanshu >>=20 >>=20 >> -----Original Message----- >> From: Ali Sajassi [mailto:sajassi@cisco.com] >> Sent: Thursday, May 10, 2012 12:47 PM >> To: Shah, Himanshu; Henderickx, Wim (Wim); Santiago Alvarez (saalvare); = Giles >> Heron; l2vpn@ietf.org >> Cc: Stewart Bryant (stbryant) >> Subject: Re: PBB E-VPN and TRILL >>=20 >> Himanshu, >>=20 >> PBB-EVPN is already a WG draft! And the TRILL portion of it has been >> presented to L2VPN WG and has been in discussions for quite some time. A= ll >> we are doing is separating SPB/PBB from TRILL - nothing new is getting >> added. Whereas, the other drafts are all new and they came about during = last >> IETF meeting. >>=20 >> -Ali >>=20 >>=20 >> On 5/10/12 9:38 AM, "Shah, Himanshu" wrote: >>=20 >>> Yes to first 2. >>>=20 >>> As for 3rd, before we induct the stated draft as WG doc, we should cons= ider >>> other two proposals >>> mentioned in the mailing list, as part of due diligence. This is the on= ly >>> fair >>> way, and in fact, >>> consideration to responses to third question be postponed until other >>> proposals have been given >>> chance to be reviewed at the WG, IMO. >>>=20 >>> /himanshu >>>=20 >>> -----Original Message----- >>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of >>> Henderickx, Wim (Wim) >>> Sent: Thursday, May 10, 2012 12:27 PM >>> To: Santiago Alvarez (saalvare); Giles Heron; l2vpn@ietf.org >>> Cc: Ali Sajassi (sajassi); Stewart Bryant (stbryant) >>> Subject: RE: PBB E-VPN and TRILL >>>=20 >>> Same, yes to all 3 >>>=20 >>> -----Original Message----- >>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of >>> Santiago Alvarez (saalvare) >>> Sent: donderdag 10 mei 2012 18:26 >>> To: Giles Heron; l2vpn@ietf.org >>> Cc: Ali Sajassi (sajassi); Stewart Bryant (stbryant) >>> Subject: RE: PBB E-VPN and TRILL >>>=20 >>> Yes to all three. >>>=20 >>> SA >>> -- >>>=20 >>>> -----Original Message----- >>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>> Of >>>> Giles Heron >>>> Sent: Wednesday, May 09, 2012 5:34 AM >>>> To: l2vpn@ietf.org >>>> Cc: Ali Sajassi (sajassi); Stewart Bryant (stbryant) >>>> Subject: PBB E-VPN and TRILL >>>>=20 >>>> Ali presented the PBB-EVPN draft at IETF83 in Paris: >>>>=20 >>>> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-01 >>>>=20 >>>> This has since been updated: >>>>=20 >>>> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-02 >>>>=20 >>>> During our discussions Ali mentioned that the authors would like the >>> TRILL >>>> section of the draft to be separated out into a separate draft. In >>> response >>>> Stewart questioned whether interconnecting TRILL islands is in-scope >>> for >>>> L2VPN. >>>>=20 >>>> Stewart, Nabil and I have just been discussing these issues. Whilst >>> TRILL >>>> interconnect is not explicitly in-charter for L2VPN it would appear to >>> be >>>> implicitly in-charter - our decision to standardise solutions for PBB >>> VPLS >>>> and PBB E-VPN probably sets a precedent (since PBB is also unmentioned >>> by >>>> the charter). >>>>=20 >>>> On this basis we would like to ask the WG the following three >>> questions: >>>>=20 >>>> 1) is the WG happy for us to pursue interconnection of TRILL islands >>> over >>>> L2VPN? >>>>=20 >>>> 2) is the WG happy for the authors to split the TRILL section of the >>> PBB E- >>>> VPN draft into a separate draft? >>>>=20 >>>> 3) is the WG happy for the TRILL draft to be a WG doc? >>>>=20 >>>> Please respond by May 22nd if you are unhappy with any of these 3 >>> actions >>>> (I'll take no response to mean the WG is in agreement with us >>> proceeding...) >>>>=20 >>>> Giles >>>>=20 >>>=20 >>=20 >=20 From sajassi@cisco.com Thu May 10 11:06: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 9E7D221F86D7 for ; Thu, 10 May 2012 11:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.369 X-Spam-Level: X-Spam-Status: No, score=-10.369 tagged_above=-999 required=5 tests=[AWL=0.230, 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 6J470BIY8u2D for ; Thu, 10 May 2012 11:06:15 -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 8C21221F86C6 for ; Thu, 10 May 2012 11:06:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sajassi@cisco.com; l=6250; q=dns/txt; s=iport; t=1336673175; x=1337882775; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=BE14oQq1qlVt4wBwJRPtpPneHs/i3QnLZ7akqn/GYsI=; b=VOxgCT43f7EAJQq+AieOXd4RBnYCtzT79zbqscVQ3bmY/n5vnut5Npzu O3d+nxx+BqD4rjFLUDtFOcZwcat7WE1ZQ5zH5BPiFeVJ/9PcLT/2yAw+7 8WBusSlSxB5MusbMhh9E2aAhDtVeyM9cCTaSezpsmPTc0ASSmr3BZJIKM 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACMDrE+rRDoJ/2dsb2JhbABEtBSBB4IVAQEBAwESAScCATELBQcGAQgRBAEBASdNCQgCBAENBRsHh2cEAQubN6AjixKGKQSIZI0ZgRGNRoFpgwk X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="41182474" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 10 May 2012 18:06:14 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q4AI6EoS021760; Thu, 10 May 2012 18:06:14 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); Thu, 10 May 2012 11:06:14 -0700 Received: from 10.128.2.64 ([10.128.2.64]) by xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) with Microsoft Exchange Server HTTP-DAV ; Thu, 10 May 2012 18:06:13 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Thu, 10 May 2012 11:06:13 -0700 Subject: Re: PBB E-VPN and TRILL From: Ali Sajassi To: "Shah, Himanshu" , "Henderickx, Wim (Wim)" , "Santiago Alvarez (saalvare)" , Giles Heron , "l2vpn@ietf.org" Message-ID: Thread-Topic: PBB E-VPN and TRILL Thread-Index: Ac0t4AvyMdWKxMA3AUSUMcn62xbEYQA6XpwgAAAL5rAAAAZYEAAAq7mvAABE8iAAAS6xNQAAEcqwAADHxHEAABYqEAAAYoks In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 10 May 2012 18:06:14.0175 (UTC) FILETIME=[9684E2F0:01CD2ED7] Cc: "Stewart Bryant \(stbryant\)" 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, 10 May 2012 18:06:16 -0000 On 5/10/12 10:59 AM, "Shah, Himanshu" wrote: > Followings are the questions... > > 2) is the WG happy for the authors to split the TRILL section of the PBB E-VPN > draft into a separate draft? > > 3) is the WG happy for the TRILL draft to be a WG doc? > > I think we are discussing splitting the trill section as a separate draft and > making it a WG doc. > > What am I missing? > Just maybe the fact that the portion that we are talking about is already part of PBB-EVPN WG draft and has been reviewed and discussed at several IETF meetings :-) Cheers, Ali > /himanshu > > -----Original Message----- > From: Ali Sajassi [mailto:sajassi@cisco.com] > Sent: Thursday, May 10, 2012 1:53 PM > To: Shah, Himanshu; Henderickx, Wim (Wim); Santiago Alvarez (saalvare); Giles > Heron; l2vpn@ietf.org > Cc: Stewart Bryant (stbryant) > Subject: Re: PBB E-VPN and TRILL > > >> >> Based on my understanding, all the proposals are considered BEFORE >> one is picked (with or without consolidation) for WG doc. > > One proposal is already part of WG draft. Would you please read the draft > and then comment. > > Cheers, > Ali > >> >> Thanks, >> himanshu >> >> >> -----Original Message----- >> From: Ali Sajassi [mailto:sajassi@cisco.com] >> Sent: Thursday, May 10, 2012 1:28 PM >> To: Shah, Himanshu; Henderickx, Wim (Wim); Santiago Alvarez (saalvare); Giles >> Heron; l2vpn@ietf.org >> Cc: Stewart Bryant (stbryant) >> Subject: Re: PBB E-VPN and TRILL >> >> Hi Himanshu, >> >> I think every draft should be evaluated based on its own merits and if it is >> warranted there can be several drafts on this space. >> >> Cheers, >> Ali >> >> >> On 5/10/12 10:03 AM, "Shah, Himanshu" wrote: >> >>> Hi Ali - >>> >>> Correct. >>> >>> But within the context of previous two, which questions whether to >>> consider interconnecting TRILL islands via L2VPN as part of WG charter, I >>> think you >>> would agree that once TRILL portion is split from your base document, >>> it might be worth to check if other proposals has merits. >>> >>> Saying differently, if your split TRILL doc becomes WG doc at the same time >>> we >>> include this work in the charter, other proposals would have no chance to be >>> even considered..:-( >>> >>> IMHO - himanshu >>> >>> >>> -----Original Message----- >>> From: Ali Sajassi [mailto:sajassi@cisco.com] >>> Sent: Thursday, May 10, 2012 12:47 PM >>> To: Shah, Himanshu; Henderickx, Wim (Wim); Santiago Alvarez (saalvare); >>> Giles >>> Heron; l2vpn@ietf.org >>> Cc: Stewart Bryant (stbryant) >>> Subject: Re: PBB E-VPN and TRILL >>> >>> Himanshu, >>> >>> PBB-EVPN is already a WG draft! And the TRILL portion of it has been >>> presented to L2VPN WG and has been in discussions for quite some time. All >>> we are doing is separating SPB/PBB from TRILL - nothing new is getting >>> added. Whereas, the other drafts are all new and they came about during last >>> IETF meeting. >>> >>> -Ali >>> >>> >>> On 5/10/12 9:38 AM, "Shah, Himanshu" wrote: >>> >>>> Yes to first 2. >>>> >>>> As for 3rd, before we induct the stated draft as WG doc, we should consider >>>> other two proposals >>>> mentioned in the mailing list, as part of due diligence. This is the only >>>> fair >>>> way, and in fact, >>>> consideration to responses to third question be postponed until other >>>> proposals have been given >>>> chance to be reviewed at the WG, IMO. >>>> >>>> /himanshu >>>> >>>> -----Original Message----- >>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >>>> Henderickx, Wim (Wim) >>>> Sent: Thursday, May 10, 2012 12:27 PM >>>> To: Santiago Alvarez (saalvare); Giles Heron; l2vpn@ietf.org >>>> Cc: Ali Sajassi (sajassi); Stewart Bryant (stbryant) >>>> Subject: RE: PBB E-VPN and TRILL >>>> >>>> Same, yes to all 3 >>>> >>>> -----Original Message----- >>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >>>> Santiago Alvarez (saalvare) >>>> Sent: donderdag 10 mei 2012 18:26 >>>> To: Giles Heron; l2vpn@ietf.org >>>> Cc: Ali Sajassi (sajassi); Stewart Bryant (stbryant) >>>> Subject: RE: PBB E-VPN and TRILL >>>> >>>> Yes to all three. >>>> >>>> SA >>>> -- >>>> >>>>> -----Original Message----- >>>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>>> Of >>>>> Giles Heron >>>>> Sent: Wednesday, May 09, 2012 5:34 AM >>>>> To: l2vpn@ietf.org >>>>> Cc: Ali Sajassi (sajassi); Stewart Bryant (stbryant) >>>>> Subject: PBB E-VPN and TRILL >>>>> >>>>> Ali presented the PBB-EVPN draft at IETF83 in Paris: >>>>> >>>>> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-01 >>>>> >>>>> This has since been updated: >>>>> >>>>> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-02 >>>>> >>>>> During our discussions Ali mentioned that the authors would like the >>>> TRILL >>>>> section of the draft to be separated out into a separate draft. In >>>> response >>>>> Stewart questioned whether interconnecting TRILL islands is in-scope >>>> for >>>>> L2VPN. >>>>> >>>>> Stewart, Nabil and I have just been discussing these issues. Whilst >>>> TRILL >>>>> interconnect is not explicitly in-charter for L2VPN it would appear to >>>> be >>>>> implicitly in-charter - our decision to standardise solutions for PBB >>>> VPLS >>>>> and PBB E-VPN probably sets a precedent (since PBB is also unmentioned >>>> by >>>>> the charter). >>>>> >>>>> On this basis we would like to ask the WG the following three >>>> questions: >>>>> >>>>> 1) is the WG happy for us to pursue interconnection of TRILL islands >>>> over >>>>> L2VPN? >>>>> >>>>> 2) is the WG happy for the authors to split the TRILL section of the >>>> PBB E- >>>>> VPN draft into a separate draft? >>>>> >>>>> 3) is the WG happy for the TRILL draft to be a WG doc? >>>>> >>>>> Please respond by May 22nd if you are unhappy with any of these 3 >>>> actions >>>>> (I'll take no response to mean the WG is in agreement with us >>>> proceeding...) >>>>> >>>>> Giles >>>>> >>>> >>> >> > From aldrin.ietf@gmail.com Thu May 10 11: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 312C021F85C0 for ; Thu, 10 May 2012 11:12:54 -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 du971YCa-HM5 for ; Thu, 10 May 2012 11:12:53 -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 710BE21F85B1 for ; Thu, 10 May 2012 11:12:53 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so2330187pbc.31 for ; Thu, 10 May 2012 11:12:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=+9FCtfftfPDlw20Fz/ejX3k6SZ5VNVfJVm++jBBPWD8=; b=evPMI5fldyIkFO+O8FCHeuIPGMAzJTcqcyDTzW61gjqxKgJgY2X1aPvuwVNr4Ov6VW JH4f3WO74+GMGrNvOefwDEhW4rrmIM4jCiXUPHTV429Y1ztUARUhtd5ZDWv87S3K3Nex rBvrdN3eerRZSX4YrvOI8UhJCGTOjo5Eqq68rsKi+h4Z6Juiz37+gwPks8XA+TqQuqnZ SEAW81Fs2//+7lmNFae4xqCL5kPEGVefCsvJdHZMRRtlyTopztMP8SAu92W2Sb/giXOh YBeNdXVO7SJRbWG+aB3mVlbv1Pp2vmU6SJkNiqspDZAk4KRpT4YovlbDTzl46yAYjkTN MIuQ== Received: by 10.68.212.100 with SMTP id nj4mr13039150pbc.125.1336673573048; Thu, 10 May 2012 11:12:53 -0700 (PDT) Received: from [10.126.108.72] (mobile-166-205-136-203.mycingular.net. [166.205.136.203]) by mx.google.com with ESMTPS id pd9sm1297667pbc.26.2012.05.10.11.12.49 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 10 May 2012 11:12:50 -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: <909C073D-3F16-4B2E-A772-E250E1914777@gmail.com> X-Mailer: iPhone Mail (9B206) From: Sam Aldrin Subject: Re: PBB E-VPN and TRILL Date: Thu, 10 May 2012 11:12:43 -0700 To: "Shah, Himanshu" Cc: "l2vpn@ietf.org" , Ali Sajassi , "Stewart Bryant \(stbryant\)" 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, 10 May 2012 18:12:54 -0000 As I mentioned in my other email, the split document should be asked for WG a= doption. It may not be for pbb content but for the TRILL content it should b= e done. When the doc was adopted as WG doc, trill content was minimal. Sam Sent from my iPhone On May 10, 2012, at 10:59 AM, "Shah, Himanshu" wrote: > Followings are the questions... >=20 > 2) is the WG happy for the authors to split the TRILL section of the PBB E= -VPN draft into a separate draft? >=20 > 3) is the WG happy for the TRILL draft to be a WG doc? >=20 > I think we are discussing splitting the trill section as a separate draft a= nd making it a WG doc. >=20 > What am I missing? >=20 > /himanshu >=20 > -----Original Message----- > From: Ali Sajassi [mailto:sajassi@cisco.com]=20 > Sent: Thursday, May 10, 2012 1:53 PM > To: Shah, Himanshu; Henderickx, Wim (Wim); Santiago Alvarez (saalvare); Gi= les Heron; l2vpn@ietf.org > Cc: Stewart Bryant (stbryant) > Subject: Re: PBB E-VPN and TRILL >=20 >=20 >>=20 >> Based on my understanding, all the proposals are considered BEFORE >> one is picked (with or without consolidation) for WG doc. >=20 > One proposal is already part of WG draft. Would you please read the draft > and then comment. >=20 > Cheers, > Ali >=20 >>=20 >> Thanks, >> himanshu >>=20 >>=20 >> -----Original Message----- >> From: Ali Sajassi [mailto:sajassi@cisco.com] >> Sent: Thursday, May 10, 2012 1:28 PM >> To: Shah, Himanshu; Henderickx, Wim (Wim); Santiago Alvarez (saalvare); G= iles >> Heron; l2vpn@ietf.org >> Cc: Stewart Bryant (stbryant) >> Subject: Re: PBB E-VPN and TRILL >>=20 >> Hi Himanshu, >>=20 >> I think every draft should be evaluated based on its own merits and if it= is >> warranted there can be several drafts on this space. >>=20 >> Cheers, >> Ali=20 >>=20 >>=20 >> On 5/10/12 10:03 AM, "Shah, Himanshu" wrote: >>=20 >>> Hi Ali - >>>=20 >>> Correct.=20 >>>=20 >>> But within the context of previous two, which questions whether to >>> consider interconnecting TRILL islands via L2VPN as part of WG charter, I= >>> think you >>> would agree that once TRILL portion is split from your base document, >>> it might be worth to check if other proposals has merits. >>>=20 >>> Saying differently, if your split TRILL doc becomes WG doc at the same t= ime >>> we >>> include this work in the charter, other proposals would have no chance t= o be >>> even considered..:-( >>>=20 >>> IMHO - himanshu >>>=20 >>>=20 >>> -----Original Message----- >>> From: Ali Sajassi [mailto:sajassi@cisco.com] >>> Sent: Thursday, May 10, 2012 12:47 PM >>> To: Shah, Himanshu; Henderickx, Wim (Wim); Santiago Alvarez (saalvare); G= iles >>> Heron; l2vpn@ietf.org >>> Cc: Stewart Bryant (stbryant) >>> Subject: Re: PBB E-VPN and TRILL >>>=20 >>> Himanshu, >>>=20 >>> PBB-EVPN is already a WG draft! And the TRILL portion of it has been >>> presented to L2VPN WG and has been in discussions for quite some time. A= ll >>> we are doing is separating SPB/PBB from TRILL - nothing new is getting >>> added. Whereas, the other drafts are all new and they came about during l= ast >>> IETF meeting. >>>=20 >>> -Ali >>>=20 >>>=20 >>> On 5/10/12 9:38 AM, "Shah, Himanshu" wrote: >>>=20 >>>> Yes to first 2. >>>>=20 >>>> As for 3rd, before we induct the stated draft as WG doc, we should cons= ider >>>> other two proposals >>>> mentioned in the mailing list, as part of due diligence. This is the on= ly >>>> fair >>>> way, and in fact, >>>> consideration to responses to third question be postponed until other >>>> proposals have been given >>>> chance to be reviewed at the WG, IMO. >>>>=20 >>>> /himanshu >>>>=20 >>>> -----Original Message----- >>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf O= f >>>> Henderickx, Wim (Wim) >>>> Sent: Thursday, May 10, 2012 12:27 PM >>>> To: Santiago Alvarez (saalvare); Giles Heron; l2vpn@ietf.org >>>> Cc: Ali Sajassi (sajassi); Stewart Bryant (stbryant) >>>> Subject: RE: PBB E-VPN and TRILL >>>>=20 >>>> Same, yes to all 3 >>>>=20 >>>> -----Original Message----- >>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf O= f >>>> Santiago Alvarez (saalvare) >>>> Sent: donderdag 10 mei 2012 18:26 >>>> To: Giles Heron; l2vpn@ietf.org >>>> Cc: Ali Sajassi (sajassi); Stewart Bryant (stbryant) >>>> Subject: RE: PBB E-VPN and TRILL >>>>=20 >>>> Yes to all three. >>>>=20 >>>> SA >>>> -- >>>>=20 >>>>> -----Original Message----- >>>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf= >>>> Of >>>>> Giles Heron >>>>> Sent: Wednesday, May 09, 2012 5:34 AM >>>>> To: l2vpn@ietf.org >>>>> Cc: Ali Sajassi (sajassi); Stewart Bryant (stbryant) >>>>> Subject: PBB E-VPN and TRILL >>>>>=20 >>>>> Ali presented the PBB-EVPN draft at IETF83 in Paris: >>>>>=20 >>>>> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-01 >>>>>=20 >>>>> This has since been updated: >>>>>=20 >>>>> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-02 >>>>>=20 >>>>> During our discussions Ali mentioned that the authors would like the >>>> TRILL >>>>> section of the draft to be separated out into a separate draft. In >>>> response >>>>> Stewart questioned whether interconnecting TRILL islands is in-scope >>>> for >>>>> L2VPN. >>>>>=20 >>>>> Stewart, Nabil and I have just been discussing these issues. Whilst >>>> TRILL >>>>> interconnect is not explicitly in-charter for L2VPN it would appear to= >>>> be >>>>> implicitly in-charter - our decision to standardise solutions for PBB >>>> VPLS >>>>> and PBB E-VPN probably sets a precedent (since PBB is also unmentioned= >>>> by >>>>> the charter). >>>>>=20 >>>>> On this basis we would like to ask the WG the following three >>>> questions: >>>>>=20 >>>>> 1) is the WG happy for us to pursue interconnection of TRILL islands >>>> over >>>>> L2VPN? >>>>>=20 >>>>> 2) is the WG happy for the authors to split the TRILL section of the >>>> PBB E- >>>>> VPN draft into a separate draft? >>>>>=20 >>>>> 3) is the WG happy for the TRILL draft to be a WG doc? >>>>>=20 >>>>> Please respond by May 22nd if you are unhappy with any of these 3 >>>> actions >>>>> (I'll take no response to mean the WG is in agreement with us >>>> proceeding...) >>>>>=20 >>>>> Giles >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 From aldrin.ietf@gmail.com Thu May 10 11:18: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 958BC21F871A for ; Thu, 10 May 2012 11:18:17 -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 LPjUBvX76Icv for ; Thu, 10 May 2012 11:18:17 -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 0441521F870B for ; Thu, 10 May 2012 11:18:16 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so2335732pbc.31 for ; Thu, 10 May 2012 11:18:16 -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=64tvDHCaTGIDlC+FtK9yYevuU8nHETGBiDrphsKGa4s=; b=G1m0zskwTPUyAgLdLMkofwh5+5163puxwCVzyS6NfhY3q/7ZkmcFLa3Qko2r41S/RR X2rDCerYnzGneKdt8VVokOGNe7mj583GRSM1kPPyJRhk2ngJcyUVyCd321+dwYqkEXHt VpoBXyopxWOqXac/B3Wi9rUFl83DiDSyu9c1HltD2gGlc1rqckJJBn/2BcuFPmxGJP11 409jV+khb2tfsUgcMv2fpPi26cE32efedBZSTeJ/70E3VEFeVHto/fo3FFTW7UmCvPuA UjfiTn2mgAh1xlAAtiqxYLK//1DEo0s6y1p040S2U99irCpi4VhlB2EfxwTS2TTf0WlO tQXg== Received: by 10.68.217.67 with SMTP id ow3mr23219412pbc.16.1336673896342; Thu, 10 May 2012 11:18:16 -0700 (PDT) Received: from [10.126.108.72] (mobile-166-205-136-203.mycingular.net. [166.205.136.203]) by mx.google.com with ESMTPS id o9sm10176019pbe.60.2012.05.10.11.18.14 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 10 May 2012 11:18:15 -0700 (PDT) References: <5EC91DDA759C324DB62C5A5F7B4922193CC839078C@EXCH-CLUSTER-11.force10networks.com> <2691CE0099834E4A9C5044EEC662BB9D33107E1C@dfweml506-mbx> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <6DCF0C64-D831-449A-9D7D-71386A2B8FF1@gmail.com> X-Mailer: iPhone Mail (9B206) From: Sam Aldrin Subject: Re: PBB E-VPN and TRILL Date: Thu, 10 May 2012 11:18:11 -0700 To: Donald Eastlake Cc: "l2vpn@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, 10 May 2012 18:18:18 -0000 Donald,=20 At the WG session it was asked whether interconnecting TRILL was in TRILL ch= arter of not. The answer was no. So, will the charter be edited to reflect w= hat you are eluding to below? Sam Sent from my iPhone On May 10, 2012, at 10:56 AM, Donald Eastlake wrote: > On Thu, May 10, 2012 at 10:35 AM, Lucy yong wrote: >> There is another draft to be considered. >>=20 >> http://tools.ietf.org/html/draft-yong-trill-trill-o-mpls-01.txt >=20 > There are a number of drafts but I think it is useful to make a > distinction between drafts that provide full connectivity between > TRILL switches (RBridges), so that they merge into a single TRILL > campus, and drafts that provide for data plane connectivity but > limited control plane connectivity for fault isolation, etc. >=20 > TRILL switches are routers. Like IP routers they logically strip the > link envelope from TRILL frames they receive and add a new, possible > different technology, link envelope on TRILL frames they send. Just as > it is possible to have an IP routed region where none of the > connections between IP routers is Ethernet but could be, for example, > PPP, it is possible to have a TRILL campus where none of the > connections between the RBridges is Ethernet but they are all some > other technology X, such as PPP. So, drafts that are "TRILL over X" > that are talking about full TRILL data and control plan connectivity > don't really seem to me to have much to do with L2VPN. Such drafts > should be done in either the TRILL WG or in the WG that does > technology X. >=20 > It seems to me that L2VPN has to do with method that provide limited > data plane interconnection for better fault isolation. >=20 > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com >=20 >> Lucy >>=20 >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of= Balaji Venkat Venkataswami >> Sent: Thursday, May 10, 2012 2:34 AM >> To: giles.heron@gmail.com; l2vpn@ietf.org >> Cc: sajassi@cisco.com; stbryant@cisco.com >> Subject: PBB E-VPN and TRILL >>=20 >> Hi Giles, >>=20 >> I totally agree on this point. We have a solution that was presented to t= he TRILL >> working group as well on the interconnection of TRILL islands. We would l= ike to >> concur with this and request for entering our draft as well into the solu= tion space. >>=20 >> The URL for the TRILL draft is as follows. >> http://tools.ietf.org/html/draft-balaji-trill-over-ip-multi-level-05 >>=20 >>=20 >> thanks and regards, >> balaji venkat >>=20 >> Sent: Wednesday, May 09, 2012 6:04 PM >> To: l2vpn@ietf.org >> Cc: Ali Sajassi (sajassi); Stewart Bryant >> Subject: PBB E-VPN and TRILL >>=20 >> Ali presented the PBB-EVPN draft at IETF83 in Paris: >>=20 >> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-01 >>=20 >> This has since been updated: >>=20 >> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-02 >>=20 >> During our discussions Ali mentioned that the authors would like the TRIL= L section of the draft to be separated out into a separate draft. In respon= se Stewart questioned whether interconnecting TRILL islands is in-scope for L= 2VPN. >>=20 >> Stewart, Nabil and I have just been discussing these issues. Whilst TRIL= L interconnect is not explicitly in-charter for L2VPN it would appear to be i= mplicitly in-charter - our decision to standardise solutions for PBB VPLS an= d PBB E-VPN probably sets a precedent (since PBB is also unmentioned by the c= harter). >>=20 >> On this basis we would like to ask the WG the following three questions: >>=20 >> 1) is the WG happy for us to pursue interconnection of TRILL islands over= L2VPN? >>=20 >> 2) is the WG happy for the authors to split the TRILL section of the PBB E= -VPN draft into a separate draft? >>=20 >> 3) is the WG happy for the TRILL draft to be a WG doc? >>=20 >> Please respond by May 22nd if you are unhappy with any of these 3 actions= (I'll take no response to mean the WG is in agreement with us proceeding...= ) >>=20 >> Giles >>=20 >>=20 From jdrake@juniper.net Thu May 10 12:07: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 A6E7B21F85EA for ; Thu, 10 May 2012 12:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.472 X-Spam-Level: X-Spam-Status: No, score=-6.472 tagged_above=-999 required=5 tests=[AWL=0.127, 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 IlzNDQRyrYDY for ; Thu, 10 May 2012 12:07:20 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id EB99521F84A7 for ; Thu, 10 May 2012 12:07:17 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKT6wR3y44ziFh7NSPPMITVYFtdrT/Gndb@postini.com; Thu, 10 May 2012 12:07:18 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Thu, 10 May 2012 12:06:31 -0700 From: John E Drake To: Sam Aldrin , Donald Eastlake Date: Thu, 10 May 2012 12:06:30 -0700 Subject: RE: PBB E-VPN and TRILL Thread-Topic: PBB E-VPN and TRILL Thread-Index: Ac0u2UkXRThvMoBARretksms8Q2QKAABf7+A Message-ID: <5E893DB832F57341992548CDBB333163A577CAB2CF@EMBX01-HQ.jnpr.net> References: <5EC91DDA759C324DB62C5A5F7B4922193CC839078C@EXCH-CLUSTER-11.force10networks.com> <2691CE0099834E4A9C5044EEC662BB9D33107E1C@dfweml506-mbx> <6DCF0C64-D831-449A-9D7D-71386A2B8FF1@gmail.com> In-Reply-To: <6DCF0C64-D831-449A-9D7D-71386A2B8FF1@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" , "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, 10 May 2012 19:07:21 -0000 Sam, I think all that Donald is saying is that TRILL can use a multiplicity of t= runking technologies (from the current charter: "but also additional ways t= o extend and optimize TRILL for the properties of the networks on which it = is deployed."). Thanks, John =20 Sent from my iPhone >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >Of Sam Aldrin >Sent: Thursday, May 10, 2012 11:18 AM >To: Donald Eastlake >Cc: l2vpn@ietf.org; stbryant@cisco.com >Subject: Re: PBB E-VPN and TRILL > >Donald, > >At the WG session it was asked whether interconnecting TRILL was in >TRILL charter of not. The answer was no. So, will the charter be edited >to reflect what you are eluding to below? > >Sam > >Sent from my iPhone > >On May 10, 2012, at 10:56 AM, Donald Eastlake wrote: > >> On Thu, May 10, 2012 at 10:35 AM, Lucy yong >wrote: >>> There is another draft to be considered. >>> >>> http://tools.ietf.org/html/draft-yong-trill-trill-o-mpls-01.txt >> >> There are a number of drafts but I think it is useful to make a >> distinction between drafts that provide full connectivity between >> TRILL switches (RBridges), so that they merge into a single TRILL >> campus, and drafts that provide for data plane connectivity but >> limited control plane connectivity for fault isolation, etc. >> >> TRILL switches are routers. Like IP routers they logically strip the >> link envelope from TRILL frames they receive and add a new, possible >> different technology, link envelope on TRILL frames they send. Just as >> it is possible to have an IP routed region where none of the >> connections between IP routers is Ethernet but could be, for example, >> PPP, it is possible to have a TRILL campus where none of the >> connections between the RBridges is Ethernet but they are all some >> other technology X, such as PPP. So, drafts that are "TRILL over X" >> that are talking about full TRILL data and control plan connectivity >> don't really seem to me to have much to do with L2VPN. Such drafts >> should be done in either the TRILL WG or in the WG that does >> technology X. >> >> It seems to me that L2VPN has to do with method that provide limited >> data plane interconnection for better fault isolation. >> >> Thanks, >> Donald >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >> 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com >> >>> Lucy >>> >>> -----Original Message----- >>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >>> Behalf Of Balaji Venkat Venkataswami >>> Sent: Thursday, May 10, 2012 2:34 AM >>> To: giles.heron@gmail.com; l2vpn@ietf.org >>> Cc: sajassi@cisco.com; stbryant@cisco.com >>> Subject: PBB E-VPN and TRILL >>> >>> Hi Giles, >>> >>> I totally agree on this point. We have a solution that was presented >>> to the TRILL working group as well on the interconnection of TRILL >>> islands. We would like to concur with this and request for entering >our draft as well into the solution space. >>> >>> The URL for the TRILL draft is as follows. >>> http://tools.ietf.org/html/draft-balaji-trill-over-ip-multi-level-05 >>> >>> >>> thanks and regards, >>> balaji venkat >>> >>> Sent: Wednesday, May 09, 2012 6:04 PM >>> To: l2vpn@ietf.org >>> Cc: Ali Sajassi (sajassi); Stewart Bryant >>> Subject: PBB E-VPN and TRILL >>> >>> Ali presented the PBB-EVPN draft at IETF83 in Paris: >>> >>> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-01 >>> >>> This has since been updated: >>> >>> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-02 >>> >>> During our discussions Ali mentioned that the authors would like the >TRILL section of the draft to be separated out into a separate draft. >In response Stewart questioned whether interconnecting TRILL islands is >in-scope for L2VPN. >>> >>> Stewart, Nabil and I have just been discussing these issues. Whilst >TRILL interconnect is not explicitly in-charter for L2VPN it would >appear to be implicitly in-charter - our decision to standardise >solutions for PBB VPLS and PBB E-VPN probably sets a precedent (since >PBB is also unmentioned by the charter). >>> >>> On this basis we would like to ask the WG the following three >questions: >>> >>> 1) is the WG happy for us to pursue interconnection of TRILL islands >over L2VPN? >>> >>> 2) is the WG happy for the authors to split the TRILL section of the >PBB E-VPN draft into a separate draft? >>> >>> 3) is the WG happy for the TRILL draft to be a WG doc? >>> >>> Please respond by May 22nd if you are unhappy with any of these 3 >>> actions (I'll take no response to mean the WG is in agreement with us >>> proceeding...) >>> >>> Giles >>> >>> From aldrin.ietf@gmail.com Thu May 10 12:25: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 062F821F8603 for ; Thu, 10 May 2012 12:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.782 X-Spam-Level: X-Spam-Status: No, score=-2.782 tagged_above=-999 required=5 tests=[AWL=-0.579, 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 rvxS9RyscuPo for ; Thu, 10 May 2012 12:25:08 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBBE21F85D5 for ; Thu, 10 May 2012 12:25:04 -0700 (PDT) Received: by dacx6 with SMTP id x6so2221250dac.31 for ; Thu, 10 May 2012 12:25:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=GFYO/diOiR7+0tM+CKDUHTibb2iDD8/+AnNoOpwcCg4=; b=gYPF3/XPYyFcjzDC+esb18j1VLT3RSNG8OpIcVAh/OYuSXJtSBQfwtc3DxjdsSe4qU RF8SkKPGs9Ua3CRfcAvqjAMmvhCRbT2SX3R6r2B9Ks5CLhMpZnsYG/A/U+ztMhUSTj4Q MfrJLyMrq7e4j0Dh7yL7y6/4gzJJrBsDX0DKkIicsZqpgEz4jp9NHG6zSoXND1hZrgPr 5jMHIUo9czTwsPLrEMXh+5V+Dhoqv/+EfD5kNruNv8n7hmAKrrNnp2m2GV3/00NwRG8n FnPmvfX7TNf9RDbuAfnp5GL9hCwf8TnCCskLfj7hp10WPi3V2ubmgNfmqKY0K2DAB+Vi AmJg== Received: by 10.68.212.197 with SMTP id nm5mr23055312pbc.110.1336677903772; Thu, 10 May 2012 12:25:03 -0700 (PDT) Received: from [192.168.1.2] (c-107-3-156-34.hsd1.ca.comcast.net. [107.3.156.34]) by mx.google.com with ESMTPS id ix5sm4613835pbc.18.2012.05.10.12.25.01 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 10 May 2012 12:25:02 -0700 (PDT) Subject: Re: PBB E-VPN and TRILL Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Sam Aldrin In-Reply-To: <5E893DB832F57341992548CDBB333163A577CAB2CF@EMBX01-HQ.jnpr.net> Date: Thu, 10 May 2012 12:25:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8892F3A6-49FE-4BE3-A6D7-8ADC8001C95E@gmail.com> References: <5EC91DDA759C324DB62C5A5F7B4922193CC839078C@EXCH-CLUSTER-11.force10networks.com> <2691CE0099834E4A9C5044EEC662BB9D33107E1C@dfweml506-mbx> <6DCF0C64-D831-449A-9D7D-71386A2B8FF1@gmail.com> <5E893DB832F57341992548CDBB333163A577CAB2CF@EMBX01-HQ.jnpr.net> To: John E Drake X-Mailer: Apple Mail (2.1257) Cc: "l2vpn@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, 10 May 2012 19:25:09 -0000 Hi John, Thanks for the reply. The way I understood the below sentence from the charter, when I first = read, was that it includes extending TRILL by interconnecting TRILL = campuses or sites. But during last WG session, it wasn't so and was = contentious topic. As TRILL is L2 technology and interconnecting them = falls into L2VPN charter/territory. Which WG owns the charter for TRILL interconnect is not a major point, = IMO (others may differ) As long it is clear to the TRILL WG on where to publish the drafts = related to interconnect and get reviewed/adopted, it is good. As of now, = it is not clear. cheers -sam=20 On May 10, 2012, at 12:06 PM, John E Drake wrote: > Sam, >=20 > I think all that Donald is saying is that TRILL can use a multiplicity = of trunking technologies (from the current charter: "but also additional = ways to extend and optimize TRILL for the properties of the networks on = which it is deployed."). >=20 > Thanks, >=20 > John =20 >=20 > Sent from my iPhone >=20 >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On = Behalf >> Of Sam Aldrin >> Sent: Thursday, May 10, 2012 11:18 AM >> To: Donald Eastlake >> Cc: l2vpn@ietf.org; stbryant@cisco.com >> Subject: Re: PBB E-VPN and TRILL >>=20 >> Donald, >>=20 >> At the WG session it was asked whether interconnecting TRILL was in >> TRILL charter of not. The answer was no. So, will the charter be = edited >> to reflect what you are eluding to below? >>=20 >> Sam >>=20 >> Sent from my iPhone >>=20 >> On May 10, 2012, at 10:56 AM, Donald Eastlake = wrote: >>=20 >>> On Thu, May 10, 2012 at 10:35 AM, Lucy yong >> wrote: >>>> There is another draft to be considered. >>>>=20 >>>> http://tools.ietf.org/html/draft-yong-trill-trill-o-mpls-01.txt >>>=20 >>> There are a number of drafts but I think it is useful to make a >>> distinction between drafts that provide full connectivity between >>> TRILL switches (RBridges), so that they merge into a single TRILL >>> campus, and drafts that provide for data plane connectivity but >>> limited control plane connectivity for fault isolation, etc. >>>=20 >>> TRILL switches are routers. Like IP routers they logically strip the >>> link envelope from TRILL frames they receive and add a new, possible >>> different technology, link envelope on TRILL frames they send. Just = as >>> it is possible to have an IP routed region where none of the >>> connections between IP routers is Ethernet but could be, for = example, >>> PPP, it is possible to have a TRILL campus where none of the >>> connections between the RBridges is Ethernet but they are all some >>> other technology X, such as PPP. So, drafts that are "TRILL over X" >>> that are talking about full TRILL data and control plan connectivity >>> don't really seem to me to have much to do with L2VPN. Such drafts >>> should be done in either the TRILL WG or in the WG that does >>> technology X. >>>=20 >>> It seems to me that L2VPN has to do with method that provide limited >>> data plane interconnection for better fault isolation. >>>=20 >>> Thanks, >>> Donald >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >>> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >>> 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com >>>=20 >>>> Lucy >>>>=20 >>>> -----Original Message----- >>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >>>> Behalf Of Balaji Venkat Venkataswami >>>> Sent: Thursday, May 10, 2012 2:34 AM >>>> To: giles.heron@gmail.com; l2vpn@ietf.org >>>> Cc: sajassi@cisco.com; stbryant@cisco.com >>>> Subject: PBB E-VPN and TRILL >>>>=20 >>>> Hi Giles, >>>>=20 >>>> I totally agree on this point. We have a solution that was = presented >>>> to the TRILL working group as well on the interconnection of TRILL >>>> islands. We would like to concur with this and request for entering >> our draft as well into the solution space. >>>>=20 >>>> The URL for the TRILL draft is as follows. >>>> = http://tools.ietf.org/html/draft-balaji-trill-over-ip-multi-level-05 >>>>=20 >>>>=20 >>>> thanks and regards, >>>> balaji venkat >>>>=20 >>>> Sent: Wednesday, May 09, 2012 6:04 PM >>>> To: l2vpn@ietf.org >>>> Cc: Ali Sajassi (sajassi); Stewart Bryant >>>> Subject: PBB E-VPN and TRILL >>>>=20 >>>> Ali presented the PBB-EVPN draft at IETF83 in Paris: >>>>=20 >>>> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-01 >>>>=20 >>>> This has since been updated: >>>>=20 >>>> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-02 >>>>=20 >>>> During our discussions Ali mentioned that the authors would like = the >> TRILL section of the draft to be separated out into a separate draft. >> In response Stewart questioned whether interconnecting TRILL islands = is >> in-scope for L2VPN. >>>>=20 >>>> Stewart, Nabil and I have just been discussing these issues. = Whilst >> TRILL interconnect is not explicitly in-charter for L2VPN it would >> appear to be implicitly in-charter - our decision to standardise >> solutions for PBB VPLS and PBB E-VPN probably sets a precedent (since >> PBB is also unmentioned by the charter). >>>>=20 >>>> On this basis we would like to ask the WG the following three >> questions: >>>>=20 >>>> 1) is the WG happy for us to pursue interconnection of TRILL = islands >> over L2VPN? >>>>=20 >>>> 2) is the WG happy for the authors to split the TRILL section of = the >> PBB E-VPN draft into a separate draft? >>>>=20 >>>> 3) is the WG happy for the TRILL draft to be a WG doc? >>>>=20 >>>> Please respond by May 22nd if you are unhappy with any of these 3 >>>> actions (I'll take no response to mean the WG is in agreement with = us >>>> proceeding...) >>>>=20 >>>> Giles >>>>=20 >>>>=20 From d3e3e3@gmail.com Thu May 10 12:29: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 4BCCF21F86B5 for ; Thu, 10 May 2012 12:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.696 X-Spam-Level: X-Spam-Status: No, score=-103.696 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uFf6bSddpwl for ; Thu, 10 May 2012 12:29:02 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 47AA321F86B4 for ; Thu, 10 May 2012 12:29:02 -0700 (PDT) Received: by dacx6 with SMTP id x6so2225487dac.31 for ; Thu, 10 May 2012 12:29:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=/V1jsYjvyasMSY4M/6lTM/DG89lC/p1Uw4ZUR2Zkqq0=; b=bLSDKdvIif8AqcE0l78K7SiPhab4OzwXkmZm2AszkvpzkjSHn5HtAvJmfHLKPO+5Kh VgzuVMVWYrjaGHXRdMt54ldPk2FNUHygAt4pwnwnOBkUW7xAADOnsz0LQTbnRoORSxzE hqrbHseS03lzD2csk9LUlw6KOmym69tQ1S1SSigiKOIRefyFFClsj7+d+hHTTKSsRgJ7 BLPbOyq69Ehy/BAjXz/LQE342bjeMkjLpTLxCk/QuAZeUhpXwWSFenwgt/e9dodb/muF BXxtUscL4xcmkIVokgBiYS6eTdNA14aVI9vIEtNNUlQT3I7EhHssVHAJA0bTXV4vjK3h gTmA== Received: by 10.50.51.163 with SMTP id l3mr153724igo.3.1336678141586; Thu, 10 May 2012 12:29:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.59.201 with HTTP; Thu, 10 May 2012 12:28:41 -0700 (PDT) In-Reply-To: <6DCF0C64-D831-449A-9D7D-71386A2B8FF1@gmail.com> References: <5EC91DDA759C324DB62C5A5F7B4922193CC839078C@EXCH-CLUSTER-11.force10networks.com> <2691CE0099834E4A9C5044EEC662BB9D33107E1C@dfweml506-mbx> <6DCF0C64-D831-449A-9D7D-71386A2B8FF1@gmail.com> From: Donald Eastlake Date: Thu, 10 May 2012 15:28:41 -0400 Message-ID: Subject: Re: PBB E-VPN and TRILL To: Sam Aldrin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "l2vpn@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, 10 May 2012 19:29:03 -0000 Hi Sam, On Thu, May 10, 2012 at 2:18 PM, Sam Aldrin wrote: > Donald, > > At the WG session it was asked whether interconnecting TRILL was in TRILL= charter of not. The answer was no. So, will the charter be edited to refle= ct what you are eluding to below? I don't believe there is a charter change currently in the works. I believe the question was more like "interconnecting TRILL islands". I interpreted this to be the sort of limited interconnection, which allows the islands to continue as separate islands, that is in the current L2VPN draft. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com > Sam > > Sent from my iPhone > > On May 10, 2012, at 10:56 AM, Donald Eastlake wrote: > >> On Thu, May 10, 2012 at 10:35 AM, Lucy yong wrote= : >>> There is another draft to be considered. >>> >>> http://tools.ietf.org/html/draft-yong-trill-trill-o-mpls-01.txt >> >> There are a number of drafts but I think it is useful to make a >> distinction between drafts that provide full connectivity between >> TRILL switches (RBridges), so that they merge into a single TRILL >> campus, and drafts that provide for data plane connectivity but >> limited control plane connectivity for fault isolation, etc. >> >> TRILL switches are routers. Like IP routers they logically strip the >> link envelope from TRILL frames they receive and add a new, possible >> different technology, link envelope on TRILL frames they send. Just as >> it is possible to have an IP routed region where none of the >> connections between IP routers is Ethernet but could be, for example, >> PPP, it is possible to have a TRILL campus where none of the >> connections between the RBridges is Ethernet but they are all some >> other technology X, such as PPP. So, drafts that are "TRILL over X" >> that are talking about full TRILL data and control plan connectivity >> don't really seem to me to have much to do with L2VPN. Such drafts >> should be done in either the TRILL WG or in the WG that does >> technology X. >> >> It seems to me that L2VPN has to do with method that provide limited >> data plane interconnection for better fault isolation. >> >> Thanks, >> Donald >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >> =A0Donald E. Eastlake 3rd =A0 +1-508-333-2270 (cell) >> =A0155 Beaver Street, Milford, MA 01757 USA >> =A0d3e3e3@gmail.com >> >>> Lucy >>> >>> -----Original Message----- >>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of Balaji Venkat Venkataswami >>> Sent: Thursday, May 10, 2012 2:34 AM >>> To: giles.heron@gmail.com; l2vpn@ietf.org >>> Cc: sajassi@cisco.com; stbryant@cisco.com >>> Subject: PBB E-VPN and TRILL >>> >>> Hi =A0Giles, >>> >>> I totally agree on this point. We have a solution that was presented to= the TRILL >>> working group as well on the interconnection of TRILL islands. We would= like to >>> concur with this and request for entering our draft as well into the so= lution space. >>> >>> The URL for the TRILL draft is as follows. >>> http://tools.ietf.org/html/draft-balaji-trill-over-ip-multi-level-05 >>> >>> >>> thanks and regards, >>> balaji venkat >>> >>> Sent: Wednesday, May 09, 2012 6:04 PM >>> To: l2vpn@ietf.org >>> Cc: Ali Sajassi (sajassi); Stewart Bryant >>> Subject: PBB E-VPN and TRILL >>> >>> Ali presented the PBB-EVPN draft at IETF83 in Paris: >>> >>> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-01 >>> >>> This has since been updated: >>> >>> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-02 >>> >>> During our discussions Ali mentioned that the authors would like the TR= ILL section of the draft to be separated out into a separate draft. =A0In r= esponse Stewart questioned whether interconnecting TRILL islands is in-scop= e for L2VPN. >>> >>> Stewart, Nabil and I have just been discussing these issues. =A0Whilst = TRILL interconnect is not explicitly in-charter for L2VPN it would appear t= o be implicitly in-charter - our decision to standardise solutions for PBB = VPLS and PBB E-VPN probably sets a precedent (since PBB is also unmentioned= by the charter). >>> >>> On this basis we would like to ask the WG the following three questions= : >>> >>> 1) is the WG happy for us to pursue interconnection of TRILL islands ov= er L2VPN? >>> >>> 2) is the WG happy for the authors to split the TRILL section of the PB= B E-VPN draft into a separate draft? >>> >>> 3) is the WG happy for the TRILL draft to be a WG doc? >>> >>> Please respond by May 22nd if you are unhappy with any of these 3 actio= ns (I'll take no response to mean the WG is in agreement with us proceeding= ...) >>> >>> Giles >>> >>> From Alexander.Vainshtein@ecitele.com Thu May 10 12:34: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 4D7EF21F8594 for ; Thu, 10 May 2012 12:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.416 X-Spam-Level: X-Spam-Status: No, score=-4.416 tagged_above=-999 required=5 tests=[AWL=0.786, 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 Hsfr8zu3fJed for ; Thu, 10 May 2012 12:34:53 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.98]) by ietfa.amsl.com (Postfix) with ESMTP id CF1D521F8577 for ; Thu, 10 May 2012 12:34:52 -0700 (PDT) Received: from [193.109.254.147:52631] by server-1.bemta-14.messagelabs.com id 2E/94-29372-4581CAF4; Thu, 10 May 2012 19:34:44 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1336678484!1822441!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.5.10; banners=-,-,- Received: (qmail 29730 invoked from network); 10 May 2012 19:34:44 -0000 Received: from unknown (HELO fridlpvsb003.ecitele.com) (168.87.1.157) by server-15.tower-27.messagelabs.com with SMTP; 10 May 2012 19:34:44 -0000 X-AuditID: a8571403-b7fbc6d00000343d-66-4fac184c3788 Received: from FRGRWPVCH001.ecitele.com (frgrwpvch001.ecitele.com [10.1.18.35]) by fridlpvsb003.ecitele.com (Symantec Messaging Gateway) with SMTP id FC.24.13373.C481CAF4; Thu, 10 May 2012 21:34:36 +0200 (CEST) Received: from FRIDWPPMB001.ecitele.com ([169.254.3.187]) by FRGRWPVCH001.ecitele.com ([10.1.18.35]) with mapi id 14.01.0339.001; Thu, 10 May 2012 21:34:44 +0200 From: Alexander Vainshtein To: Sami Boutros Subject: RE: Static VPLS MAC withdrawal draft Thread-Topic: Static VPLS MAC withdrawal draft Thread-Index: Ac0tTYm5TIv9pECE0EWc8IlBO2eaCQBZSqlwAAD+M1D///XxgP//nZow Date: Thu, 10 May 2012 19:34:42 +0000 Message-ID: References: <32B4F6D6-CB5A-4DE9-8A14-B04B175BC30E@cisco.com> In-Reply-To: <32B4F6D6-CB5A-4DE9-8A14-B04B175BC30E@cisco.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: H4sIAAAAAAAAA2VTaUzTYBj2a7dRjmod4D4WkKYJXrg5RGONjBgPAh4ZHolKYrRsH1vj1s11 IpCYDP+oeCeIMjFMnQdCvBKNRv3hFAkkCh7xII4oYFQUYxCvYIgtRcTYX8/3Pc/7PO/bviVw 7VeNnuAFH/IKnJPRxKhiwBi9YRlssJgO1k5k3zQeAWzXt3AU29bZhLMdvT8w9l5lH5ivzq0c uKTOvR6IROWGQj+xfLzAD7I4QXD7OB+ibUi0mpl8L1/MWUsZmreZmQyG9jg5K3IhwWdmOI8H CTYmO4b+78mSZLxAI8HqtvGC3czkrbIYWHb2XEMGk73awYs0Mrg43km7kChydkRLN/IEgm3j edzxqnkA84RmlvgvpftBaHIFiCYgNQu23L+tVvAE2NZxQVMBYggt9QTARx9eq5XDKQDvRiqj ZJWGMsPL9RGNjBOoNPh6oBbIIpyqAbBpd/uQKJ4ywNb9L4ZFRjjQWAUUnAMP1b8d0qik4o6d wSFMUsth+N1FXEk7B+CXvR9xmYiW0t69PDZkBKT+vrc0YDLGKR1s767FlL4pGLrZiis4Eb7v GhyeJxU+/PxqWD8dBm/0aRScDk8f/4ArweNhc3W3StEnwdtnn6sOAF1gVERgVHlgVHlgVHkQ qKSmi7y8zekpFgtNpkwjsvI+5ERGq9t1GUjLc3ZNAn4N9O83hgFFACaOJHrrLVo1VyyWusIg icCYRPJmQoNFO7bQbSt1cKJjg3eLE4lhAAmcSSBrDkty0saVliGv+w/FSm/xIK6Ptbrlj+zb kGky/XNgdOSFldkWLWWXNm8TQh7k/VOaTBAMJJ/ppMTxXmRHJUW80/eXxohoOTlOSq6SNaTo 4Vwib1f4FpBGdN06/RRoVYJbQHoduU8WUbLIsUUY8ekBOmnWePK8zMZJmzji0COZY7L5nTrZ XPozRii9H+yIhWsLPzU2H29zJI8LllSJvx5vvdJYXlD3fA85KbxAmHFisUMg8JSCdcZD+df7 U/alXu2JzF+qPrp6RvUt1yKi/VTNZmovrU1ZcfJLyL/2cGdO4sz1c+bdWVH+K3NK366yjAf+ wdbWMVgwsWmqeWFd0ZKUtHWD25jHvZGn7JntedMYlejgMqbhXpH7DUlgp3IIBAAA Cc: "l2vpn@ietf.org" , "msiva@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, 10 May 2012 19:34:54 -0000 Sami, Lots of thanks for a prompt response. Please see additional comments/questions inline (marked [[Sasha]]). Regards, Sasha > -----Original Message----- > From: Sami Boutros [mailto:sboutros@cisco.com] > Sent: Thursday, May 10, 2012 6:35 PM > To: Alexander Vainshtein > Cc: msiva@cisco.com; nmcgill@cisco.com; l2vpn@ietf.org; Giles Heron > Subject: Re: Static VPLS MAC withdrawal draft > > Hi Saha, > > Thanks for your comments, Please see responses inline.. > > > > > > >> -----Original Message----- > >> From: Alexander Vainshtein > >> Sent: Thursday, May 10, 2012 5:08 PM > >> To: 'msiva@cisco.com:'; Sami Boutros (sboutros@cisco.com); > >> 'nmcgill@cisco.com' > >> Cc: l2vpn@ietf.org; 'Giles Heron'; Rotem Cohen; Andrew Sergeev; > Mishael > >> Wexler; Gideon Agmon > >> Subject: RE: Static VPLS MAC withdrawal draft > >> > >> Hi all, > >> I've read the draft in question and I would like to clarify several iss= ues > that > >> look either undefined or ambiguous to me. > >> > >> 1. To the best of my understanding, the draft requires each PE > participating > >> in a given VPLS instance to set up two counters for each static PW > >> connecting it to a peer PE device in this VPLS instance: one for static= MAC > >> withdrawal messages it is going to send and another - for static MAC > >> withdrawal messages it receives. Is this understanding correct? > >> > > Sami: This is correct. > > >> 2. Assuming a positive answer to the previous questions, how are these > >> counters initialized? The draft seems to be moot on this point. > > Sami: This is what the draft has for setting up the sequence # in section= 3. > Only half of the sequence number space is used. Modular arithmetic > is used to detect wrapping of sequence number. When sequence number > wraps (i.e., when it becomes 0), all MAC addresses are flushed and > the sequence number is reset. > Sami: Can you please explain what's vague in the above? [[[Sasha]]] This does not say too much about initialization (at least, not= to me). And it would be nice if the draft was more specific here. > > >> The more > >> interesting question is, of course, about initialization of the counter= of > >> received static MAC withdrawal messages, since, with static PWs, > generally > >> speaking, there is no synchronization between setting up one of its end > >> points and setting up another one. > > > Sami: Initially the rx sequence # can be assumed to be 0. [[[Sasha]]] But you've said that Rx number 0 results in flushing all MAC add= resses? > > >> > >> 3. The draft specifies that: > >> - The transmitter sends the MAC withdrawal message with the same > >> sequence number until it receives an ACK for it (Section 4.1.1) > >> - The receiver, after having acknowledged a MAC withdrawal > >> message, ignores refresh messages with the same sequence number > >> (Section 4.1.2) > >> What is supposed to happen in the following scenario: > >> - Transmitter finds out that some MACs have to be withdrawn (e.g., > >> because the AC from which they have been learned fails) > >> and sends a MAC withdrawal message to its peers with sequence > >> number N > >> - Immediately after that (i.e., before it receives an ACK for this > >> message) it finds out that yet another set of MAC addresses has to be > >> withdrawn > >> - Retransmission timer expires without ACK received. > >> > > Sami: A new sequence # will be transmitted that will include both sets of > MAC addresses > Sami: that need to be flushed, and the transmitter will wait for an ack fo= r > this new sequence #. > Sami: We can add this to the draft. [[[Sasha]]] First of all, I think something like that MUST be added to the d= raft. And I am not sure what you say is really OK: consider the case when ACK for= the first withdrawal message is received after the 2nd message has been sen= t. If one of the ACKed (and withdrawn) MAC addresses has been then re-learned t= hey will be flushed again... > > >> 4. Suppose that only one end point of a static PW between a given pair= of > >> peers has been set up. In this case transmitting the static MAC > withdrawal > >> messages via such a PW is possible, but ACKs will never be received. > Should > >> retransmission of these messages go on "ad infinitum"? > >> > > Sami: Yes, this will be the case, the mechanism will be no different then= the > static PW status one for this case. [[[Sasha]]] But ACK is not mandatory in the PW status message 9indeed, it is= not clear if it is ever needed). Here you may end with multiple retransmitting messages that are sent to a bl= ack hole. > > >> 5. The draft does not specify any default value for the retransmit time= . > >> > > Sami: Sure will add. > > >> 6. A nit: Heading of Section 4 is followed by headings for Sections 4.= 1.1 > and > >> 4.1.2 without any heading for 4.1. > >> > > Sami: Sure will fix. > > >> Hopefully these questions will be useful. > >> > > Thanks, > > Sami > > > >> Regards, > >> Sasha > >> > >>> -----Original Message----- > >>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > Behalf > >>> Of Giles Heron > >>> Sent: Tuesday, May 08, 2012 10:06 PM > >>> To: l2vpn@ietf.org > >>> Subject: Static VPLS MAC withdrawal draft > >>> > >>> Hi everyone, > >>> > >>> The following draft was presented at IETF in Paris: > >>> > >>> http://tools.ietf.org/html/draft-boutros-l2vpn-mpls-tp-mac-wd-00 > >>> > >>> The authors have asked for it to be adopted as a WG draft, but at this > stage > >>> the chairs' view is that it probably hasn't had enough sets of eyes on= it. > >>> > >>> So this email is to request that those on the list take a read of the= draft > >>> and send comments back to the list. Depending on the response we get > >> we > >>> may > >>> then ask the WG if they feel happy adopting this as a WG draft. > >>> > >>> Nabil and Giles > >>> > > > > > > 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 d3e3e3@gmail.com Thu May 10 12:38: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 E592821F84E7 for ; Thu, 10 May 2012 12:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.694 X-Spam-Level: X-Spam-Status: No, score=-103.694 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sK0fbRXK4j0 for ; Thu, 10 May 2012 12:38:32 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 011CC21F84E4 for ; Thu, 10 May 2012 12:38:31 -0700 (PDT) Received: by yhq56 with SMTP id 56so2270277yhq.31 for ; Thu, 10 May 2012 12:38:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=ngCIq3uKay80AGGeJ5GVTR4OKydcJ8tiAl3SeRLPbZ0=; b=phdCly0F6lY5rXntlHhfPM6j2xHxYIgBQZY/TVH1rPR/zDKFGAUBj12Ll+5ypxFroE y9Ov3sh0e+HI6HLPCobkh2hm/WzqkJ29sS/i2pAtdoP0wowPL2a+L7grtea0g/V4PAjn kWMIPF4TQ+NkLrzSmGjg+iC5vx7EiDz+py7OkLhFdErAL7joPYdkemz1FyNLc299yjiY DRJURVsZuRoCyAg2jExyV0D7/Ur8RpUTZ6VE2FVxQJvZuQvBJkRBk+wKBHtBJji9mpLl 3jJnxRWwo6kdjUK7TPunXiHLA49NaQDvEme0if3gFIsUVp13Edw0P+zKRbcpyIyudYLe yAjQ== Received: by 10.50.41.165 with SMTP id g5mr161162igl.13.1336678708278; Thu, 10 May 2012 12:38:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.59.201 with HTTP; Thu, 10 May 2012 12:38:08 -0700 (PDT) In-Reply-To: <8892F3A6-49FE-4BE3-A6D7-8ADC8001C95E@gmail.com> References: <5EC91DDA759C324DB62C5A5F7B4922193CC839078C@EXCH-CLUSTER-11.force10networks.com> <2691CE0099834E4A9C5044EEC662BB9D33107E1C@dfweml506-mbx> <6DCF0C64-D831-449A-9D7D-71386A2B8FF1@gmail.com> <5E893DB832F57341992548CDBB333163A577CAB2CF@EMBX01-HQ.jnpr.net> <8892F3A6-49FE-4BE3-A6D7-8ADC8001C95E@gmail.com> From: Donald Eastlake Date: Thu, 10 May 2012 15:38:08 -0400 Message-ID: Subject: Re: PBB E-VPN and TRILL To: Sam Aldrin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "l2vpn@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, 10 May 2012 19:38:33 -0000 On Thu, May 10, 2012 at 3:25 PM, Sam Aldrin wrote: > Hi John, > > Thanks for the reply. > > The way I understood the below sentence from the charter, when I first re= ad, was that it includes extending TRILL by interconnecting TRILL campuses = or sites. But during last WG session, it wasn't so and was contentious topi= c. As TRILL is L2 technology and interconnecting them falls into L2VPN char= ter/territory. I do not agree that TRILL is L2 technology. > Which WG owns the charter for TRILL interconnect is not a major point, IM= O (others may differ) > As long it is clear to the TRILL WG on where to publish the drafts relate= d to interconnect and get reviewed/adopted, it is good. As of now, it is no= t clear. So what was wrong with my statement that "TRILL over X" drafts should be in the TRILL WG or the X WG while it is OK for drafts that provide limited control plane interaction between TRILL islands, like the current L2VPN draft, to be in L2VPN? ("TRILL over X" drafts are drafts that pretty much just tell you how to encode any TRILL Data or TRILL Control packet over a technology X link, along with whatever security or other precautions you should take, so as to obtain full peering and cause the RBridges on that link, and any other fully connected RBridges, to be part of one unified TRILL campus.) Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com > cheers > -sam > On May 10, 2012, at 12:06 PM, John E Drake wrote: > >> Sam, >> >> I think all that Donald is saying is that TRILL can use a multiplicity o= f trunking technologies (from the current charter: "but also additional way= s to extend and optimize TRILL for the properties of the networks on which = it is deployed."). >> >> Thanks, >> >> John >> >> Sent from my iPhone >> >>> -----Original Message----- >>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>> Of Sam Aldrin >>> Sent: Thursday, May 10, 2012 11:18 AM >>> To: Donald Eastlake >>> Cc: l2vpn@ietf.org; stbryant@cisco.com >>> Subject: Re: PBB E-VPN and TRILL >>> >>> Donald, >>> >>> At the WG session it was asked whether interconnecting TRILL was in >>> TRILL charter of not. The answer was no. So, will the charter be edited >>> to reflect what you are eluding to below? >>> >>> Sam >>> >>> Sent from my iPhone >>> >>> On May 10, 2012, at 10:56 AM, Donald Eastlake wrote: >>> >>>> On Thu, May 10, 2012 at 10:35 AM, Lucy yong >>> wrote: >>>>> There is another draft to be considered. >>>>> >>>>> http://tools.ietf.org/html/draft-yong-trill-trill-o-mpls-01.txt >>>> >>>> There are a number of drafts but I think it is useful to make a >>>> distinction between drafts that provide full connectivity between >>>> TRILL switches (RBridges), so that they merge into a single TRILL >>>> campus, and drafts that provide for data plane connectivity but >>>> limited control plane connectivity for fault isolation, etc. >>>> >>>> TRILL switches are routers. Like IP routers they logically strip the >>>> link envelope from TRILL frames they receive and add a new, possible >>>> different technology, link envelope on TRILL frames they send. Just as >>>> it is possible to have an IP routed region where none of the >>>> connections between IP routers is Ethernet but could be, for example, >>>> PPP, it is possible to have a TRILL campus where none of the >>>> connections between the RBridges is Ethernet but they are all some >>>> other technology X, such as PPP. So, drafts that are "TRILL over X" >>>> that are talking about full TRILL data and control plan connectivity >>>> don't really seem to me to have much to do with L2VPN. Such drafts >>>> should be done in either the TRILL WG or in the WG that does >>>> technology X. >>>> >>>> It seems to me that L2VPN has to do with method that provide limited >>>> data plane interconnection for better fault isolation. >>>> >>>> Thanks, >>>> Donald >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >>>> Donald E. Eastlake 3rd =A0 +1-508-333-2270 (cell) >>>> 155 Beaver Street, Milford, MA 01757 USA =A0d3e3e3@gmail.com >>>> >>>>> Lucy >>>>> >>>>> -----Original Message----- >>>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >>>>> Behalf Of Balaji Venkat Venkataswami >>>>> Sent: Thursday, May 10, 2012 2:34 AM >>>>> To: giles.heron@gmail.com; l2vpn@ietf.org >>>>> Cc: sajassi@cisco.com; stbryant@cisco.com >>>>> Subject: PBB E-VPN and TRILL >>>>> >>>>> Hi =A0Giles, >>>>> >>>>> I totally agree on this point. We have a solution that was presented >>>>> to the TRILL working group as well on the interconnection of TRILL >>>>> islands. We would like to concur with this and request for entering >>> our draft as well into the solution space. >>>>> >>>>> The URL for the TRILL draft is as follows. >>>>> http://tools.ietf.org/html/draft-balaji-trill-over-ip-multi-level-05 >>>>> >>>>> >>>>> thanks and regards, >>>>> balaji venkat >>>>> >>>>> Sent: Wednesday, May 09, 2012 6:04 PM >>>>> To: l2vpn@ietf.org >>>>> Cc: Ali Sajassi (sajassi); Stewart Bryant >>>>> Subject: PBB E-VPN and TRILL >>>>> >>>>> Ali presented the PBB-EVPN draft at IETF83 in Paris: >>>>> >>>>> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-01 >>>>> >>>>> This has since been updated: >>>>> >>>>> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-02 >>>>> >>>>> During our discussions Ali mentioned that the authors would like the >>> TRILL section of the draft to be separated out into a separate draft. >>> In response Stewart questioned whether interconnecting TRILL islands is >>> in-scope for L2VPN. >>>>> >>>>> Stewart, Nabil and I have just been discussing these issues. =A0Whils= t >>> TRILL interconnect is not explicitly in-charter for L2VPN it would >>> appear to be implicitly in-charter - our decision to standardise >>> solutions for PBB VPLS and PBB E-VPN probably sets a precedent (since >>> PBB is also unmentioned by the charter). >>>>> >>>>> On this basis we would like to ask the WG the following three >>> questions: >>>>> >>>>> 1) is the WG happy for us to pursue interconnection of TRILL islands >>> over L2VPN? >>>>> >>>>> 2) is the WG happy for the authors to split the TRILL section of the >>> PBB E-VPN draft into a separate draft? >>>>> >>>>> 3) is the WG happy for the TRILL draft to be a WG doc? >>>>> >>>>> Please respond by May 22nd if you are unhappy with any of these 3 >>>>> actions (I'll take no response to mean the WG is in agreement with us >>>>> proceeding...) >>>>> >>>>> Giles >>>>> >>>>> > From sajassi@cisco.com Thu May 10 12:41: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 9591521F84B4 for ; Thu, 10 May 2012 12:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.386 X-Spam-Level: X-Spam-Status: No, score=-10.386 tagged_above=-999 required=5 tests=[AWL=0.213, 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 idDb+c3KDFBn for ; Thu, 10 May 2012 12:41:02 -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 C066B21F84E4 for ; Thu, 10 May 2012 12:41:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sajassi@cisco.com; l=6863; q=dns/txt; s=iport; t=1336678862; x=1337888462; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=cWu4UiM/zVlW9bdd/FKkebH306yotRfHwcCyAXeYTcY=; b=m2cZWE8CKdaoinbKKNY1oTHiW4VPvXN+8zYHJb6lxK47HudsMkBUU5rp QpYAFTaabLB4efEY6ldYbqPKL8gHg/v4ApLs3Z4yT2BFPuPTVEqUgSLnS 3Vl5q412cLWxlv1BZfiK1Y9K4OCDafDyAipdcLo1mQgZdRycy5D2nQSAb E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIAYrE+rRDoG/2dsb2JhbABEtB+BB4IVAQEBAwESAScCATELBQcGAQgRBAEBAScoJQkIAQEEDgUbB4deAwYEAQubOJY2DYlTiiVthh0EiGSNGYERiiyDGoFpgwmBPw X-IronPort-AV: E=Sophos;i="4.75,566,1330905600"; d="scan'208";a="44309350" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 10 May 2012 19:41:01 +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 q4AJf19u015439; Thu, 10 May 2012 19:41:01 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); Thu, 10 May 2012 12:41:01 -0700 Received: from 10.128.2.64 ([10.128.2.64]) by xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) with Microsoft Exchange Server HTTP-DAV ; Thu, 10 May 2012 19:41:00 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Thu, 10 May 2012 12:41:00 -0700 Subject: Re: PBB E-VPN and TRILL From: Ali Sajassi To: Sam Aldrin , "Shah, Himanshu" Message-ID: Thread-Topic: PBB E-VPN and TRILL Thread-Index: Ac0u5NOIg11LnDcCwESpygy9Pytz/w== In-Reply-To: <909C073D-3F16-4B2E-A772-E250E1914777@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 10 May 2012 19:41:01.0264 (UTC) FILETIME=[D449CD00:01CD2EE4] Cc: "l2vpn@ietf.org" , "Stewart Bryant \(stbryant\)" 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, 10 May 2012 19:41:03 -0000 When the doc was adopted as WG draft over 14 months ago, BGP route definition and procedures for TRILL DCI were already in place. It seems like we are having all these email exchanges for a name change of a WG doc !! -Ali On 5/10/12 11:12 AM, "Sam Aldrin" wrote: > As I mentioned in my other email, the split document should be asked for WG > adoption. It may not be for pbb content but for the TRILL content it should be > done. When the doc was adopted as WG doc, trill content was minimal. > > Sam > > Sent from my iPhone > > On May 10, 2012, at 10:59 AM, "Shah, Himanshu" wrote: > >> Followings are the questions... >> >> 2) is the WG happy for the authors to split the TRILL section of the PBB >> E-VPN draft into a separate draft? >> >> 3) is the WG happy for the TRILL draft to be a WG doc? >> >> I think we are discussing splitting the trill section as a separate draft and >> making it a WG doc. >> >> What am I missing? >> >> /himanshu >> >> -----Original Message----- >> From: Ali Sajassi [mailto:sajassi@cisco.com] >> Sent: Thursday, May 10, 2012 1:53 PM >> To: Shah, Himanshu; Henderickx, Wim (Wim); Santiago Alvarez (saalvare); Giles >> Heron; l2vpn@ietf.org >> Cc: Stewart Bryant (stbryant) >> Subject: Re: PBB E-VPN and TRILL >> >> >>> >>> Based on my understanding, all the proposals are considered BEFORE >>> one is picked (with or without consolidation) for WG doc. >> >> One proposal is already part of WG draft. Would you please read the draft >> and then comment. >> >> Cheers, >> Ali >> >>> >>> Thanks, >>> himanshu >>> >>> >>> -----Original Message----- >>> From: Ali Sajassi [mailto:sajassi@cisco.com] >>> Sent: Thursday, May 10, 2012 1:28 PM >>> To: Shah, Himanshu; Henderickx, Wim (Wim); Santiago Alvarez (saalvare); >>> Giles >>> Heron; l2vpn@ietf.org >>> Cc: Stewart Bryant (stbryant) >>> Subject: Re: PBB E-VPN and TRILL >>> >>> Hi Himanshu, >>> >>> I think every draft should be evaluated based on its own merits and if it is >>> warranted there can be several drafts on this space. >>> >>> Cheers, >>> Ali >>> >>> >>> On 5/10/12 10:03 AM, "Shah, Himanshu" wrote: >>> >>>> Hi Ali - >>>> >>>> Correct. >>>> >>>> But within the context of previous two, which questions whether to >>>> consider interconnecting TRILL islands via L2VPN as part of WG charter, I >>>> think you >>>> would agree that once TRILL portion is split from your base document, >>>> it might be worth to check if other proposals has merits. >>>> >>>> Saying differently, if your split TRILL doc becomes WG doc at the same time >>>> we >>>> include this work in the charter, other proposals would have no chance to >>>> be >>>> even considered..:-( >>>> >>>> IMHO - himanshu >>>> >>>> >>>> -----Original Message----- >>>> From: Ali Sajassi [mailto:sajassi@cisco.com] >>>> Sent: Thursday, May 10, 2012 12:47 PM >>>> To: Shah, Himanshu; Henderickx, Wim (Wim); Santiago Alvarez (saalvare); >>>> Giles >>>> Heron; l2vpn@ietf.org >>>> Cc: Stewart Bryant (stbryant) >>>> Subject: Re: PBB E-VPN and TRILL >>>> >>>> Himanshu, >>>> >>>> PBB-EVPN is already a WG draft! And the TRILL portion of it has been >>>> presented to L2VPN WG and has been in discussions for quite some time. All >>>> we are doing is separating SPB/PBB from TRILL - nothing new is getting >>>> added. Whereas, the other drafts are all new and they came about during >>>> last >>>> IETF meeting. >>>> >>>> -Ali >>>> >>>> >>>> On 5/10/12 9:38 AM, "Shah, Himanshu" wrote: >>>> >>>>> Yes to first 2. >>>>> >>>>> As for 3rd, before we induct the stated draft as WG doc, we should >>>>> consider >>>>> other two proposals >>>>> mentioned in the mailing list, as part of due diligence. This is the only >>>>> fair >>>>> way, and in fact, >>>>> consideration to responses to third question be postponed until other >>>>> proposals have been given >>>>> chance to be reviewed at the WG, IMO. >>>>> >>>>> /himanshu >>>>> >>>>> -----Original Message----- >>>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >>>>> Henderickx, Wim (Wim) >>>>> Sent: Thursday, May 10, 2012 12:27 PM >>>>> To: Santiago Alvarez (saalvare); Giles Heron; l2vpn@ietf.org >>>>> Cc: Ali Sajassi (sajassi); Stewart Bryant (stbryant) >>>>> Subject: RE: PBB E-VPN and TRILL >>>>> >>>>> Same, yes to all 3 >>>>> >>>>> -----Original Message----- >>>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >>>>> Santiago Alvarez (saalvare) >>>>> Sent: donderdag 10 mei 2012 18:26 >>>>> To: Giles Heron; l2vpn@ietf.org >>>>> Cc: Ali Sajassi (sajassi); Stewart Bryant (stbryant) >>>>> Subject: RE: PBB E-VPN and TRILL >>>>> >>>>> Yes to all three. >>>>> >>>>> SA >>>>> -- >>>>> >>>>>> -----Original Message----- >>>>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>>>> Of >>>>>> Giles Heron >>>>>> Sent: Wednesday, May 09, 2012 5:34 AM >>>>>> To: l2vpn@ietf.org >>>>>> Cc: Ali Sajassi (sajassi); Stewart Bryant (stbryant) >>>>>> Subject: PBB E-VPN and TRILL >>>>>> >>>>>> Ali presented the PBB-EVPN draft at IETF83 in Paris: >>>>>> >>>>>> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-01 >>>>>> >>>>>> This has since been updated: >>>>>> >>>>>> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-02 >>>>>> >>>>>> During our discussions Ali mentioned that the authors would like the >>>>> TRILL >>>>>> section of the draft to be separated out into a separate draft. In >>>>> response >>>>>> Stewart questioned whether interconnecting TRILL islands is in-scope >>>>> for >>>>>> L2VPN. >>>>>> >>>>>> Stewart, Nabil and I have just been discussing these issues. Whilst >>>>> TRILL >>>>>> interconnect is not explicitly in-charter for L2VPN it would appear to >>>>> be >>>>>> implicitly in-charter - our decision to standardise solutions for PBB >>>>> VPLS >>>>>> and PBB E-VPN probably sets a precedent (since PBB is also unmentioned >>>>> by >>>>>> the charter). >>>>>> >>>>>> On this basis we would like to ask the WG the following three >>>>> questions: >>>>>> >>>>>> 1) is the WG happy for us to pursue interconnection of TRILL islands >>>>> over >>>>>> L2VPN? >>>>>> >>>>>> 2) is the WG happy for the authors to split the TRILL section of the >>>>> PBB E- >>>>>> VPN draft into a separate draft? >>>>>> >>>>>> 3) is the WG happy for the TRILL draft to be a WG doc? >>>>>> >>>>>> Please respond by May 22nd if you are unhappy with any of these 3 >>>>> actions >>>>>> (I'll take no response to mean the WG is in agreement with us >>>>> proceeding...) >>>>>> >>>>>> Giles >>>>>> >>>>> >>>> >>> >> From aldrin.ietf@gmail.com Thu May 10 12:58: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 B2B5821F8693 for ; Thu, 10 May 2012 12:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.383 X-Spam-Level: X-Spam-Status: No, score=-3.383 tagged_above=-999 required=5 tests=[AWL=0.216, 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 hs9IDBLOc9GJ for ; Thu, 10 May 2012 12:58:01 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 133A521F8687 for ; Thu, 10 May 2012 12:58:00 -0700 (PDT) Received: by dacx6 with SMTP id x6so2257061dac.31 for ; Thu, 10 May 2012 12:57:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=4UspnOYRTT1N80UVk5087NFD5MFPEs2hhJ79POdWCYM=; b=fbX8Oq+FN4ESefqpuHOz+EYhj90teOVWHN4t1gM67BQe5Swbn/taCPj10mOgvD4vT2 wT3d7hA0cLdJEjLYiN8/3Aok94LgTmSyNvmPh5+n6AGRlgk7MhfztLeFref/eJlu9FpW xt2NT5Nqxder/UF8Om1p7czv5kk00lqxrLdPNNoloLmyFi75ZEPh3W+N346eiolWL6Ci CsWlz1BuUVr13RoTCO3aEZVLDcCRlmeUUkDitS8MirzTGZuuGG9F4mei48WEMhFOUeBC CxlPB4/HFgbUHOgQdpM0mndp6kx8v4oSHetjp2X0D43biIyqwoUxO+FHXkoiRAt6nKrV p1Tg== Received: by 10.68.135.161 with SMTP id pt1mr646211pbb.39.1336679878751; Thu, 10 May 2012 12:57:58 -0700 (PDT) Received: from [192.168.1.2] (c-107-3-156-34.hsd1.ca.comcast.net. [107.3.156.34]) by mx.google.com with ESMTPS id d2sm10390936pbw.39.2012.05.10.12.57.57 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 10 May 2012 12:57:57 -0700 (PDT) Subject: Re: PBB E-VPN and TRILL Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Sam Aldrin In-Reply-To: Date: Thu, 10 May 2012 12:57:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ali Sajassi X-Mailer: Apple Mail (2.1257) Cc: "l2vpn@ietf.org" , "Stewart Bryant \(stbryant\)" 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, 10 May 2012 19:58:02 -0000 I do not agree that It is just a name change of the document. As far as the content goes, there is lot more to just BGP route. All the content w.r.t unicast forwarding, multicast forwarding etc was = added recently. Atleast it was not present when the document was adopted = as WG one. So, without taking groups consensus for WG adoption is not right, IMO. = As the content is more TRILL specific, it should be polled within that = WG as well. -sam On May 10, 2012, at 12:41 PM, Ali Sajassi wrote: >=20 > When the doc was adopted as WG draft over 14 months ago, BGP route > definition and procedures for TRILL DCI were already in place. >=20 > It seems like we are having all these email exchanges for a name = change of a > WG doc !! >=20 > -Ali >=20 > On 5/10/12 11:12 AM, "Sam Aldrin" wrote: >=20 >> As I mentioned in my other email, the split document should be asked = for WG >> adoption. It may not be for pbb content but for the TRILL content it = should be >> done. When the doc was adopted as WG doc, trill content was minimal. >>=20 >> Sam >>=20 >> Sent from my iPhone >>=20 >> On May 10, 2012, at 10:59 AM, "Shah, Himanshu" = wrote: >>=20 >>> Followings are the questions... >>>=20 >>> 2) is the WG happy for the authors to split the TRILL section of the = PBB >>> E-VPN draft into a separate draft? >>>=20 >>> 3) is the WG happy for the TRILL draft to be a WG doc? >>>=20 >>> I think we are discussing splitting the trill section as a separate = draft and >>> making it a WG doc. >>>=20 >>> What am I missing? >>>=20 >>> /himanshu >>>=20 >>> -----Original Message----- >>> From: Ali Sajassi [mailto:sajassi@cisco.com] >>> Sent: Thursday, May 10, 2012 1:53 PM >>> To: Shah, Himanshu; Henderickx, Wim (Wim); Santiago Alvarez = (saalvare); Giles >>> Heron; l2vpn@ietf.org >>> Cc: Stewart Bryant (stbryant) >>> Subject: Re: PBB E-VPN and TRILL >>>=20 >>>=20 >>>>=20 >>>> Based on my understanding, all the proposals are considered BEFORE >>>> one is picked (with or without consolidation) for WG doc. >>>=20 >>> One proposal is already part of WG draft. Would you please read the = draft >>> and then comment. >>>=20 >>> Cheers, >>> Ali >>>=20 >>>>=20 >>>> Thanks, >>>> himanshu >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Ali Sajassi [mailto:sajassi@cisco.com] >>>> Sent: Thursday, May 10, 2012 1:28 PM >>>> To: Shah, Himanshu; Henderickx, Wim (Wim); Santiago Alvarez = (saalvare); >>>> Giles >>>> Heron; l2vpn@ietf.org >>>> Cc: Stewart Bryant (stbryant) >>>> Subject: Re: PBB E-VPN and TRILL >>>>=20 >>>> Hi Himanshu, >>>>=20 >>>> I think every draft should be evaluated based on its own merits and = if it is >>>> warranted there can be several drafts on this space. >>>>=20 >>>> Cheers, >>>> Ali=20 >>>>=20 >>>>=20 >>>> On 5/10/12 10:03 AM, "Shah, Himanshu" wrote: >>>>=20 >>>>> Hi Ali - >>>>>=20 >>>>> Correct.=20 >>>>>=20 >>>>> But within the context of previous two, which questions whether to >>>>> consider interconnecting TRILL islands via L2VPN as part of WG = charter, I >>>>> think you >>>>> would agree that once TRILL portion is split from your base = document, >>>>> it might be worth to check if other proposals has merits. >>>>>=20 >>>>> Saying differently, if your split TRILL doc becomes WG doc at the = same time >>>>> we >>>>> include this work in the charter, other proposals would have no = chance to >>>>> be >>>>> even considered..:-( >>>>>=20 >>>>> IMHO - himanshu >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: Ali Sajassi [mailto:sajassi@cisco.com] >>>>> Sent: Thursday, May 10, 2012 12:47 PM >>>>> To: Shah, Himanshu; Henderickx, Wim (Wim); Santiago Alvarez = (saalvare); >>>>> Giles >>>>> Heron; l2vpn@ietf.org >>>>> Cc: Stewart Bryant (stbryant) >>>>> Subject: Re: PBB E-VPN and TRILL >>>>>=20 >>>>> Himanshu, >>>>>=20 >>>>> PBB-EVPN is already a WG draft! And the TRILL portion of it has = been >>>>> presented to L2VPN WG and has been in discussions for quite some = time. All >>>>> we are doing is separating SPB/PBB from TRILL - nothing new is = getting >>>>> added. Whereas, the other drafts are all new and they came about = during >>>>> last >>>>> IETF meeting. >>>>>=20 >>>>> -Ali >>>>>=20 >>>>>=20 >>>>> On 5/10/12 9:38 AM, "Shah, Himanshu" wrote: >>>>>=20 >>>>>> Yes to first 2. >>>>>>=20 >>>>>> As for 3rd, before we induct the stated draft as WG doc, we = should >>>>>> consider >>>>>> other two proposals >>>>>> mentioned in the mailing list, as part of due diligence. This is = the only >>>>>> fair >>>>>> way, and in fact, >>>>>> consideration to responses to third question be postponed until = other >>>>>> proposals have been given >>>>>> chance to be reviewed at the WG, IMO. >>>>>>=20 >>>>>> /himanshu >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On = Behalf Of >>>>>> Henderickx, Wim (Wim) >>>>>> Sent: Thursday, May 10, 2012 12:27 PM >>>>>> To: Santiago Alvarez (saalvare); Giles Heron; l2vpn@ietf.org >>>>>> Cc: Ali Sajassi (sajassi); Stewart Bryant (stbryant) >>>>>> Subject: RE: PBB E-VPN and TRILL >>>>>>=20 >>>>>> Same, yes to all 3 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On = Behalf Of >>>>>> Santiago Alvarez (saalvare) >>>>>> Sent: donderdag 10 mei 2012 18:26 >>>>>> To: Giles Heron; l2vpn@ietf.org >>>>>> Cc: Ali Sajassi (sajassi); Stewart Bryant (stbryant) >>>>>> Subject: RE: PBB E-VPN and TRILL >>>>>>=20 >>>>>> Yes to all three. >>>>>>=20 >>>>>> SA >>>>>> -- >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On = Behalf >>>>>> Of >>>>>>> Giles Heron >>>>>>> Sent: Wednesday, May 09, 2012 5:34 AM >>>>>>> To: l2vpn@ietf.org >>>>>>> Cc: Ali Sajassi (sajassi); Stewart Bryant (stbryant) >>>>>>> Subject: PBB E-VPN and TRILL >>>>>>>=20 >>>>>>> Ali presented the PBB-EVPN draft at IETF83 in Paris: >>>>>>>=20 >>>>>>> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-01 >>>>>>>=20 >>>>>>> This has since been updated: >>>>>>>=20 >>>>>>> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-02 >>>>>>>=20 >>>>>>> During our discussions Ali mentioned that the authors would like = the >>>>>> TRILL >>>>>>> section of the draft to be separated out into a separate draft. = In >>>>>> response >>>>>>> Stewart questioned whether interconnecting TRILL islands is = in-scope >>>>>> for >>>>>>> L2VPN. >>>>>>>=20 >>>>>>> Stewart, Nabil and I have just been discussing these issues. = Whilst >>>>>> TRILL >>>>>>> interconnect is not explicitly in-charter for L2VPN it would = appear to >>>>>> be >>>>>>> implicitly in-charter - our decision to standardise solutions = for PBB >>>>>> VPLS >>>>>>> and PBB E-VPN probably sets a precedent (since PBB is also = unmentioned >>>>>> by >>>>>>> the charter). >>>>>>>=20 >>>>>>> On this basis we would like to ask the WG the following three >>>>>> questions: >>>>>>>=20 >>>>>>> 1) is the WG happy for us to pursue interconnection of TRILL = islands >>>>>> over >>>>>>> L2VPN? >>>>>>>=20 >>>>>>> 2) is the WG happy for the authors to split the TRILL section of = the >>>>>> PBB E- >>>>>>> VPN draft into a separate draft? >>>>>>>=20 >>>>>>> 3) is the WG happy for the TRILL draft to be a WG doc? >>>>>>>=20 >>>>>>> Please respond by May 22nd if you are unhappy with any of these = 3 >>>>>> actions >>>>>>> (I'll take no response to mean the WG is in agreement with us >>>>>> proceeding...) >>>>>>>=20 >>>>>>> Giles >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >=20 From jdrake@juniper.net Thu May 10 13:27: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 8156921F8621 for ; Thu, 10 May 2012 13:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.175 X-Spam-Level: X-Spam-Status: No, score=-6.175 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fms2sZo7QRGE for ; Thu, 10 May 2012 13:27:46 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id A72AD21F861D for ; Thu, 10 May 2012 13:27:45 -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 DSNKT6wkv+nDo53HukN3LRE/UU0Vz+0QqNFM@postini.com; Thu, 10 May 2012 13:27:46 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; Thu, 10 May 2012 13:27:38 -0700 From: John E Drake To: Donald Eastlake , Sam Aldrin Date: Thu, 10 May 2012 13:27:37 -0700 Subject: RE: PBB E-VPN and TRILL Thread-Topic: PBB E-VPN and TRILL Thread-Index: Ac0u5HwlSG7eQ7n+S12CdxQVt1eQ8gABd0dw Message-ID: <5E893DB832F57341992548CDBB333163A577CAB3DF@EMBX01-HQ.jnpr.net> References: <5EC91DDA759C324DB62C5A5F7B4922193CC839078C@EXCH-CLUSTER-11.force10networks.com> <2691CE0099834E4A9C5044EEC662BB9D33107E1C@dfweml506-mbx> <6DCF0C64-D831-449A-9D7D-71386A2B8FF1@gmail.com> <5E893DB832F57341992548CDBB333163A577CAB2CF@EMBX01-HQ.jnpr.net> <8892F3A6-49FE-4BE3-A6D7-8ADC8001C95E@gmail.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "l2vpn@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, 10 May 2012 20:27:47 -0000 Don, I was composing an email along the lines of yours, but then I realized that= there are some cases which break this distinction. Specifically, in L3VPN= when the interface between CE and PE is OSPF (V2 & v3), it is possible to = extend an OSPF area across an L3VPN; i.e., the L3VPN is providing 'trunkin= g' for a single OSPF network. The same, in principle, could be done for IS= -IS and TRILL. So, perhaps we should add a qualifier that X can include 'L2VPN' and 'L3VPN= '. Thanks, John Sent from my iPhone >-----Original Message----- >From: Donald Eastlake [mailto:d3e3e3@gmail.com] >Sent: Thursday, May 10, 2012 12:38 PM >To: Sam Aldrin >Cc: John E Drake; l2vpn@ietf.org; stbryant@cisco.com >Subject: Re: PBB E-VPN and TRILL > >On Thu, May 10, 2012 at 3:25 PM, Sam Aldrin >wrote: >> Hi John, >> >> Thanks for the reply. >> >> The way I understood the below sentence from the charter, when I first >read, was that it includes extending TRILL by interconnecting TRILL >campuses or sites. But during last WG session, it wasn't so and was >contentious topic. As TRILL is L2 technology and interconnecting them >falls into L2VPN charter/territory. > >I do not agree that TRILL is L2 technology. > >> Which WG owns the charter for TRILL interconnect is not a major point, >> IMO (others may differ) As long it is clear to the TRILL WG on where >to publish the drafts related to interconnect and get reviewed/adopted, >it is good. As of now, it is not clear. > >So what was wrong with my statement that "TRILL over X" drafts should be >in the TRILL WG or the X WG while it is OK for drafts that provide >limited control plane interaction between TRILL islands, like the >current L2VPN draft, to be in L2VPN? ("TRILL over X" drafts are drafts >that pretty much just tell you how to encode any TRILL Data or TRILL >Control packet over a technology X link, along with whatever security or >other precautions you should take, so as to obtain full peering and >cause the RBridges on that link, and any other fully connected RBridges, >to be part of one unified TRILL campus.) > >Thanks, >Donald >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >=A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) >=A0155 Beaver Street,=A0Milford, MA 01757 USA >=A0d3e3e3@gmail.com > >> cheers >> -sam >> On May 10, 2012, at 12:06 PM, John E Drake wrote: >> >>> Sam, >>> >>> I think all that Donald is saying is that TRILL can use a >multiplicity of trunking technologies (from the current charter: "but >also additional ways to extend and optimize TRILL for the properties of >the networks on which it is deployed."). >>> >>> Thanks, >>> >>> John >>> >>> Sent from my iPhone >>> >>>> -----Original Message----- >>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >>>> Behalf Of Sam Aldrin >>>> Sent: Thursday, May 10, 2012 11:18 AM >>>> To: Donald Eastlake >>>> Cc: l2vpn@ietf.org; stbryant@cisco.com >>>> Subject: Re: PBB E-VPN and TRILL >>>> >>>> Donald, >>>> >>>> At the WG session it was asked whether interconnecting TRILL was in >>>> TRILL charter of not. The answer was no. So, will the charter be >>>> edited to reflect what you are eluding to below? >>>> >>>> Sam >>>> >>>> Sent from my iPhone >>>> >>>> On May 10, 2012, at 10:56 AM, Donald Eastlake >wrote: >>>> >>>>> On Thu, May 10, 2012 at 10:35 AM, Lucy yong >>>> wrote: >>>>>> There is another draft to be considered. >>>>>> >>>>>> http://tools.ietf.org/html/draft-yong-trill-trill-o-mpls-01.txt >>>>> >>>>> There are a number of drafts but I think it is useful to make a >>>>> distinction between drafts that provide full connectivity between >>>>> TRILL switches (RBridges), so that they merge into a single TRILL >>>>> campus, and drafts that provide for data plane connectivity but >>>>> limited control plane connectivity for fault isolation, etc. >>>>> >>>>> TRILL switches are routers. Like IP routers they logically strip >>>>> the link envelope from TRILL frames they receive and add a new, >>>>> possible different technology, link envelope on TRILL frames they >>>>> send. Just as it is possible to have an IP routed region where none >>>>> of the connections between IP routers is Ethernet but could be, for >>>>> example, PPP, it is possible to have a TRILL campus where none of >>>>> the connections between the RBridges is Ethernet but they are all >>>>> some other technology X, such as PPP. So, drafts that are "TRILL >over X" >>>>> that are talking about full TRILL data and control plan >>>>> connectivity don't really seem to me to have much to do with L2VPN. >>>>> Such drafts should be done in either the TRILL WG or in the WG that >>>>> does technology X. >>>>> >>>>> It seems to me that L2VPN has to do with method that provide >>>>> limited data plane interconnection for better fault isolation. >>>>> >>>>> Thanks, >>>>> Donald >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >>>>> Donald E. Eastlake 3rd =A0 +1-508-333-2270 (cell) >>>>> 155 Beaver Street, Milford, MA 01757 USA =A0d3e3e3@gmail.com >>>>> >>>>>> Lucy >>>>>> >>>>>> -----Original Message----- >>>>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >>>>>> Behalf Of Balaji Venkat Venkataswami >>>>>> Sent: Thursday, May 10, 2012 2:34 AM >>>>>> To: giles.heron@gmail.com; l2vpn@ietf.org >>>>>> Cc: sajassi@cisco.com; stbryant@cisco.com >>>>>> Subject: PBB E-VPN and TRILL >>>>>> >>>>>> Hi =A0Giles, >>>>>> >>>>>> I totally agree on this point. We have a solution that was >>>>>> presented to the TRILL working group as well on the >>>>>> interconnection of TRILL islands. We would like to concur with >>>>>> this and request for entering >>>> our draft as well into the solution space. >>>>>> >>>>>> The URL for the TRILL draft is as follows. >>>>>> http://tools.ietf.org/html/draft-balaji-trill-over-ip-multi-level- >>>>>> 05 >>>>>> >>>>>> >>>>>> thanks and regards, >>>>>> balaji venkat >>>>>> >>>>>> Sent: Wednesday, May 09, 2012 6:04 PM >>>>>> To: l2vpn@ietf.org >>>>>> Cc: Ali Sajassi (sajassi); Stewart Bryant >>>>>> Subject: PBB E-VPN and TRILL >>>>>> >>>>>> Ali presented the PBB-EVPN draft at IETF83 in Paris: >>>>>> >>>>>> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-01 >>>>>> >>>>>> This has since been updated: >>>>>> >>>>>> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-02 >>>>>> >>>>>> During our discussions Ali mentioned that the authors would like >>>>>> the >>>> TRILL section of the draft to be separated out into a separate >draft. >>>> In response Stewart questioned whether interconnecting TRILL islands >>>> is in-scope for L2VPN. >>>>>> >>>>>> Stewart, Nabil and I have just been discussing these issues. >>>>>> Whilst >>>> TRILL interconnect is not explicitly in-charter for L2VPN it would >>>> appear to be implicitly in-charter - our decision to standardise >>>> solutions for PBB VPLS and PBB E-VPN probably sets a precedent >>>> (since PBB is also unmentioned by the charter). >>>>>> >>>>>> On this basis we would like to ask the WG the following three >>>> questions: >>>>>> >>>>>> 1) is the WG happy for us to pursue interconnection of TRILL >>>>>> islands >>>> over L2VPN? >>>>>> >>>>>> 2) is the WG happy for the authors to split the TRILL section of >>>>>> the >>>> PBB E-VPN draft into a separate draft? >>>>>> >>>>>> 3) is the WG happy for the TRILL draft to be a WG doc? >>>>>> >>>>>> Please respond by May 22nd if you are unhappy with any of these 3 >>>>>> actions (I'll take no response to mean the WG is in agreement with >>>>>> us >>>>>> proceeding...) >>>>>> >>>>>> Giles >>>>>> >>>>>> >> From aldrin.ietf@gmail.com Thu May 10 13:59: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 21B2521F84A0 for ; Thu, 10 May 2012 13:59: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 b8Rfh3ejGGHC for ; Thu, 10 May 2012 13:59:42 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 81B6921F849A for ; Thu, 10 May 2012 13:59:42 -0700 (PDT) Received: by dacx6 with SMTP id x6so2322486dac.31 for ; Thu, 10 May 2012 13:59:42 -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=G/SM6NyuKdZlWIJsw7+3gGVL7hya45UpdGezN/9maTI=; b=tLYb8AXSSA6ciPq2dQ2yh/qx4GrDPKAO23PdyLzdFWn9RNupOoS1+nOOSiy84IH3v8 eep4b6xUbGu5K+W0rMh6mQi4bxUhGGn6e/GtxxQScb4TZHde3cqUbfWzVXaRjpYfXMLN OMVXxZVvAdS8TDbLgHBodbwdiosyjCxrz0yD7FlfZXUyk7IAq3W8hhOwYmd1Unlfktgz 5Lu/0I7wl4kK7S5LXeJExpodP4sy89oNexsxT2g97XB7bTZXr7an2HJgHKD//CVPLkhI D0/Caheq5SRWs6PUSMPcYV4q9dNmTHw0RTP+FxLbQ3zC67p4E0Y4LkJIKUP/VK3gdIIu 7TTg== Received: by 10.68.216.225 with SMTP id ot1mr4015007pbc.46.1336683582181; Thu, 10 May 2012 13:59:42 -0700 (PDT) Received: from [192.168.255.176] ([12.207.18.42]) by mx.google.com with ESMTPS id oj3sm10535896pbb.20.2012.05.10.13.59.39 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 10 May 2012 13:59:41 -0700 (PDT) References: <5EC91DDA759C324DB62C5A5F7B4922193CC839078C@EXCH-CLUSTER-11.force10networks.com> <2691CE0099834E4A9C5044EEC662BB9D33107E1C@dfweml506-mbx> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (9B206) From: Sam Aldrin Subject: Re: PBB E-VPN and TRILL Date: Thu, 10 May 2012 13:59:37 -0700 To: Donald Eastlake Cc: "l2vpn@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, 10 May 2012 20:59:43 -0000 Donald, Comment inline. Sent from my iPad On May 10, 2012, at 10:56 AM, Donald Eastlake wrote: > On Thu, May 10, 2012 at 10:35 AM, Lucy yong wrote: >> There is another draft to be considered. >>=20 >> http://tools.ietf.org/html/draft-yong-trill-trill-o-mpls-01.txt >=20 > There are a number of drafts but I think it is useful to make a > distinction between drafts that provide full connectivity between > TRILL switches (RBridges), so that they merge into a single TRILL > campus, and drafts that provide for data plane connectivity but > limited control plane connectivity for fault isolation, etc. >=20 > TRILL switches are routers. Like IP routers they logically strip the > link envelope from TRILL frames they receive and add a new, possible > different technology, link envelope on TRILL frames they send. Just as > it is possible to have an IP routed region where none of the > connections between IP routers is Ethernet but could be, for example, > PPP, it is possible to have a TRILL campus where none of the > connections between the RBridges is Ethernet but they are all some > other technology X, such as PPP. So, drafts that are "TRILL over X" > that are talking about full TRILL data and control plan connectivity > don't really seem to me to have much to do with L2VPN. Such drafts > should be done in either the TRILL WG or in the WG that does > technology X. >=20 > It seems to me that L2VPN has to do with method that provide limited > data plane interconnection for better fault isolation. That is incorrect. The draft specifies interconnecting trill islands. But af= ter interconnection, it will be one big trill campus, where RBridges are apa= rt (which is your first case). Otherwise the concept of nickname uniqueness d= oesn't arise.=20 Sam >=20 > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com >=20 >> Lucy >>=20 >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of= Balaji Venkat Venkataswami >> Sent: Thursday, May 10, 2012 2:34 AM >> To: giles.heron@gmail.com; l2vpn@ietf.org >> Cc: sajassi@cisco.com; stbryant@cisco.com >> Subject: PBB E-VPN and TRILL >>=20 >> Hi Giles, >>=20 >> I totally agree on this point. We have a solution that was presented to t= he TRILL >> working group as well on the interconnection of TRILL islands. We would l= ike to >> concur with this and request for entering our draft as well into the solu= tion space. >>=20 >> The URL for the TRILL draft is as follows. >> http://tools.ietf.org/html/draft-balaji-trill-over-ip-multi-level-05 >>=20 >>=20 >> thanks and regards, >> balaji venkat >>=20 >> Sent: Wednesday, May 09, 2012 6:04 PM >> To: l2vpn@ietf.org >> Cc: Ali Sajassi (sajassi); Stewart Bryant >> Subject: PBB E-VPN and TRILL >>=20 >> Ali presented the PBB-EVPN draft at IETF83 in Paris: >>=20 >> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-01 >>=20 >> This has since been updated: >>=20 >> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-02 >>=20 >> During our discussions Ali mentioned that the authors would like the TRIL= L section of the draft to be separated out into a separate draft. In respon= se Stewart questioned whether interconnecting TRILL islands is in-scope for L= 2VPN. >>=20 >> Stewart, Nabil and I have just been discussing these issues. Whilst TRIL= L interconnect is not explicitly in-charter for L2VPN it would appear to be i= mplicitly in-charter - our decision to standardise solutions for PBB VPLS an= d PBB E-VPN probably sets a precedent (since PBB is also unmentioned by the c= harter). >>=20 >> On this basis we would like to ask the WG the following three questions: >>=20 >> 1) is the WG happy for us to pursue interconnection of TRILL islands over= L2VPN? >>=20 >> 2) is the WG happy for the authors to split the TRILL section of the PBB E= -VPN draft into a separate draft? >>=20 >> 3) is the WG happy for the TRILL draft to be a WG doc? >>=20 >> Please respond by May 22nd if you are unhappy with any of these 3 actions= (I'll take no response to mean the WG is in agreement with us proceeding...= ) >>=20 >> Giles >>=20 >>=20 From aldrin.ietf@gmail.com Thu May 10 14: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 4A46A21F85BE for ; Thu, 10 May 2012 14:04:33 -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 mEFcvKjL9q4v for ; Thu, 10 May 2012 14:04:32 -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 9FFF021F85AC for ; Thu, 10 May 2012 14:04:32 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so2514684pbc.31 for ; Thu, 10 May 2012 14:04:32 -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=bmSh4RtOXnF1Zwq+J5hqJObqR5VAZuerRea1QWXefHA=; b=qPgDtq18wS4M+YDgG1EYoHduiarhbcSvZvhhDAYX5l+9inLKdvsHT2qcS+wx8C8vLV EFPfuuce0edVDd+l3jErqAgx1z2OmqvfhvYEaxBmB3wVrHWWP9NK7Nvrd3UG0FsnyYkq XvvrdqeWf0fKaY6O+6wePpkcGOnsHEKXHUxCzLLmJsiHsdo6h0nUIY99YuJRY7cr0ozU gfOUG1JWodD8y960+KKR7KqnKi6JKRcBdG2esqHLnLzpAYD2jIcVVVkRGGY0cL3LYsR2 ZOO5IXOl4NnBG0dN8EUlEx3/AFpIQpJqRP6LcF8ZfCStwuiRR4oxRC1GqQtZe0UG93IY Gy7g== Received: by 10.68.201.198 with SMTP id kc6mr6662256pbc.112.1336683871867; Thu, 10 May 2012 14:04:31 -0700 (PDT) Received: from [192.168.255.176] ([12.207.18.42]) by mx.google.com with ESMTPS id oi3sm5261261pbb.0.2012.05.10.14.04.30 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 10 May 2012 14:04:30 -0700 (PDT) References: <5EC91DDA759C324DB62C5A5F7B4922193CC839078C@EXCH-CLUSTER-11.force10networks.com> <2691CE0099834E4A9C5044EEC662BB9D33107E1C@dfweml506-mbx> <6DCF0C64-D831-449A-9D7D-71386A2B8FF1@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: X-Mailer: iPad Mail (9B206) From: Sam Aldrin Subject: Re: PBB E-VPN and TRILL Date: Thu, 10 May 2012 14:04:27 -0700 To: Donald Eastlake Cc: "l2vpn@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, 10 May 2012 21:04:33 -0000 AFAIK, there's no TRILL interconnect draft which specifies (apologies in adv= ance if it already exists) which keeps islands separate after interconnectio= n. Each of them requires nickname uniqueness after interconnection because i= t will be one big trill cloud. As I said in my other response, same with pbb= -evpn draft as well. Sam Sent from my iPad On May 10, 2012, at 12:28 PM, Donald Eastlake wrote: > Hi Sam, >=20 > On Thu, May 10, 2012 at 2:18 PM, Sam Aldrin wrote:= >> Donald, >>=20 >=20 >> At the WG session it was asked whether interconnecting TRILL was in TRILL= charter of not. The answer was no. So, will the charter be edited to reflec= t what you are eluding to below? >=20 > I don't believe there is a charter change currently in the works. I > believe the question was more like "interconnecting TRILL islands". I > interpreted this to be the sort of limited interconnection, which > allows the islands to continue as separate islands, that is in the > current L2VPN draft. >=20 > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com >=20 >> Sam >>=20 >> Sent from my iPhone >>=20 >> On May 10, 2012, at 10:56 AM, Donald Eastlake wrote: >>=20 >>> On Thu, May 10, 2012 at 10:35 AM, Lucy yong wrote= : >>>> There is another draft to be considered. >>>>=20 >>>> http://tools.ietf.org/html/draft-yong-trill-trill-o-mpls-01.txt >>>=20 >>> There are a number of drafts but I think it is useful to make a >>> distinction between drafts that provide full connectivity between >>> TRILL switches (RBridges), so that they merge into a single TRILL >>> campus, and drafts that provide for data plane connectivity but >>> limited control plane connectivity for fault isolation, etc. >>>=20 >>> TRILL switches are routers. Like IP routers they logically strip the >>> link envelope from TRILL frames they receive and add a new, possible >>> different technology, link envelope on TRILL frames they send. Just as >>> it is possible to have an IP routed region where none of the >>> connections between IP routers is Ethernet but could be, for example, >>> PPP, it is possible to have a TRILL campus where none of the >>> connections between the RBridges is Ethernet but they are all some >>> other technology X, such as PPP. So, drafts that are "TRILL over X" >>> that are talking about full TRILL data and control plan connectivity >>> don't really seem to me to have much to do with L2VPN. Such drafts >>> should be done in either the TRILL WG or in the WG that does >>> technology X. >>>=20 >>> It seems to me that L2VPN has to do with method that provide limited >>> data plane interconnection for better fault isolation. >>>=20 >>> Thanks, >>> Donald >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >>> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >>> 155 Beaver Street, Milford, MA 01757 USA >>> d3e3e3@gmail.com >>>=20 >>>> Lucy >>>>=20 >>>> -----Original Message----- >>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf O= f Balaji Venkat Venkataswami >>>> Sent: Thursday, May 10, 2012 2:34 AM >>>> To: giles.heron@gmail.com; l2vpn@ietf.org >>>> Cc: sajassi@cisco.com; stbryant@cisco.com >>>> Subject: PBB E-VPN and TRILL >>>>=20 >>>> Hi Giles, >>>>=20 >>>> I totally agree on this point. We have a solution that was presented to= the TRILL >>>> working group as well on the interconnection of TRILL islands. We would= like to >>>> concur with this and request for entering our draft as well into the so= lution space. >>>>=20 >>>> The URL for the TRILL draft is as follows. >>>> http://tools.ietf.org/html/draft-balaji-trill-over-ip-multi-level-05 >>>>=20 >>>>=20 >>>> thanks and regards, >>>> balaji venkat >>>>=20 >>>> Sent: Wednesday, May 09, 2012 6:04 PM >>>> To: l2vpn@ietf.org >>>> Cc: Ali Sajassi (sajassi); Stewart Bryant >>>> Subject: PBB E-VPN and TRILL >>>>=20 >>>> Ali presented the PBB-EVPN draft at IETF83 in Paris: >>>>=20 >>>> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-01 >>>>=20 >>>> This has since been updated: >>>>=20 >>>> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-02 >>>>=20 >>>> During our discussions Ali mentioned that the authors would like the TR= ILL section of the draft to be separated out into a separate draft. In resp= onse Stewart questioned whether interconnecting TRILL islands is in-scope fo= r L2VPN. >>>>=20 >>>> Stewart, Nabil and I have just been discussing these issues. Whilst TR= ILL interconnect is not explicitly in-charter for L2VPN it would appear to b= e implicitly in-charter - our decision to standardise solutions for PBB VPLS= and PBB E-VPN probably sets a precedent (since PBB is also unmentioned by t= he charter). >>>>=20 >>>> On this basis we would like to ask the WG the following three questions= : >>>>=20 >>>> 1) is the WG happy for us to pursue interconnection of TRILL islands ov= er L2VPN? >>>>=20 >>>> 2) is the WG happy for the authors to split the TRILL section of the PB= B E-VPN draft into a separate draft? >>>>=20 >>>> 3) is the WG happy for the TRILL draft to be a WG doc? >>>>=20 >>>> Please respond by May 22nd if you are unhappy with any of these 3 actio= ns (I'll take no response to mean the WG is in agreement with us proceeding.= ..) >>>>=20 >>>> Giles >>>>=20 >>>>=20 From aldrin.ietf@gmail.com Thu May 10 14:14: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 B645911E80AC for ; Thu, 10 May 2012 14:14:26 -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 YXSf3KKbBQoV for ; Thu, 10 May 2012 14:14:25 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id C8E9921F85A5 for ; Thu, 10 May 2012 14:14:25 -0700 (PDT) Received: by dacx6 with SMTP id x6so2337974dac.31 for ; Thu, 10 May 2012 14:14:25 -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=uUi4WiTWnVvEv9tJ7LRjGgnmsrO2gqz9/hhl/hH0kU8=; b=w4IUsFBpXvECsW+GBVOrvYnCN+E18nwl35qSD8BnN7QRdj/BLoUXwHi9ht7dfD6WFW D3+HmxZb+Hs0ClJL720vPRicfnEkKetXk2w8/ep+32oRmVjGvk4knSq3F4ypY8wd01hN Ge7TV4pSHJBqVcpFIxxp83v65/WWUxWYY8S0evSezGAE8qzWJBdE8XebbTWlIeHEjCn2 r/huYkAJzHQs91iW/K8bHy8UfhOPkKTAG6x9ivJaUlrSOJjiUdQnWqDtD9fMZalQA/yy bKVBYylI6VXf5DgSk7uwV++RLy129ukjRRmrTBed3txLZ47+EeJMjUcoiCFfcf8gMegT b2Rw== Received: by 10.68.204.227 with SMTP id lb3mr24459268pbc.92.1336684465113; Thu, 10 May 2012 14:14:25 -0700 (PDT) Received: from [192.168.255.176] ([12.207.18.42]) by mx.google.com with ESMTPS id uu3sm10535819pbc.70.2012.05.10.14.14.23 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 10 May 2012 14:14:24 -0700 (PDT) References: <5EC91DDA759C324DB62C5A5F7B4922193CC839078C@EXCH-CLUSTER-11.force10networks.com> <2691CE0099834E4A9C5044EEC662BB9D33107E1C@dfweml506-mbx> <6DCF0C64-D831-449A-9D7D-71386A2B8FF1@gmail.com> <5E893DB832F57341992548CDBB333163A577CAB2CF@EMBX01-HQ.jnpr.net> <8892F3A6-49FE-4BE3-A6D7-8ADC8001C95E@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: <18D50DEC-2FEC-46EF-B0F8-8FB5822EDB51@gmail.com> X-Mailer: iPad Mail (9B206) From: Sam Aldrin Subject: Re: PBB E-VPN and TRILL Date: Thu, 10 May 2012 14:14:21 -0700 To: Donald Eastlake Cc: "l2vpn@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, 10 May 2012 21:14:26 -0000 Donald, =46rom what I remember, at the WG session, the question of Trill interconnec= t is part of the charter for trill WG session or not, arose. The answer was,= no, it was not part of the charter. (I do not see minutes to reference to, s= o basing it on my memory). We did not split hairs whether it is trill over x= or trill campus extension, at that time. If you say, interconnect of Trill(= ex: draft-aldrin-trill-data-center-interconnect) is ok to to be part of tr= ill WG or dependent underlying technology group, then I am fine. Just wanted= to get clarified. Sam Sent from my iPad On May 10, 2012, at 12:38 PM, Donald Eastlake wrote: > On Thu, May 10, 2012 at 3:25 PM, Sam Aldrin wrote:= >> Hi John, >>=20 >> Thanks for the reply. >>=20 >> The way I understood the below sentence from the charter, when I first re= ad, was that it includes extending TRILL by interconnecting TRILL campuses o= r sites. But during last WG session, it wasn't so and was contentious topic.= As TRILL is L2 technology and interconnecting them falls into L2VPN charter= /territory. >=20 > I do not agree that TRILL is L2 technology. >=20 >> Which WG owns the charter for TRILL interconnect is not a major point, IM= O (others may differ) >> As long it is clear to the TRILL WG on where to publish the drafts relate= d to interconnect and get reviewed/adopted, it is good. As of now, it is not= clear. >=20 > So what was wrong with my statement that "TRILL over X" drafts should > be in the TRILL WG or the X WG while it is OK for drafts that provide > limited control plane interaction between TRILL islands, like the > current L2VPN draft, to be in L2VPN? ("TRILL over X" drafts are drafts > that pretty much just tell you how to encode any TRILL Data or TRILL > Control packet over a technology X link, along with whatever security > or other precautions you should take, so as to obtain full peering and > cause the RBridges on that link, and any other fully connected > RBridges, to be part of one unified TRILL campus.) >=20 > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com >=20 >> cheers >> -sam >> On May 10, 2012, at 12:06 PM, John E Drake wrote: >>=20 >>> Sam, >>>=20 >>> I think all that Donald is saying is that TRILL can use a multiplicity o= f trunking technologies (from the current charter: "but also additional ways= to extend and optimize TRILL for the properties of the networks on which it= is deployed."). >>>=20 >>> Thanks, >>>=20 >>> John >>>=20 >>> Sent from my iPhone >>>=20 >>>> -----Original Message----- >>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>>> Of Sam Aldrin >>>> Sent: Thursday, May 10, 2012 11:18 AM >>>> To: Donald Eastlake >>>> Cc: l2vpn@ietf.org; stbryant@cisco.com >>>> Subject: Re: PBB E-VPN and TRILL >>>>=20 >>>> Donald, >>>>=20 >>>> At the WG session it was asked whether interconnecting TRILL was in >>>> TRILL charter of not. The answer was no. So, will the charter be edited= >>>> to reflect what you are eluding to below? >>>>=20 >>>> Sam >>>>=20 >>>> Sent from my iPhone >>>>=20 >>>> On May 10, 2012, at 10:56 AM, Donald Eastlake wrote:= >>>>=20 >>>>> On Thu, May 10, 2012 at 10:35 AM, Lucy yong >>>> wrote: >>>>>> There is another draft to be considered. >>>>>>=20 >>>>>> http://tools.ietf.org/html/draft-yong-trill-trill-o-mpls-01.txt >>>>>=20 >>>>> There are a number of drafts but I think it is useful to make a >>>>> distinction between drafts that provide full connectivity between >>>>> TRILL switches (RBridges), so that they merge into a single TRILL >>>>> campus, and drafts that provide for data plane connectivity but >>>>> limited control plane connectivity for fault isolation, etc. >>>>>=20 >>>>> TRILL switches are routers. Like IP routers they logically strip the >>>>> link envelope from TRILL frames they receive and add a new, possible >>>>> different technology, link envelope on TRILL frames they send. Just as= >>>>> it is possible to have an IP routed region where none of the >>>>> connections between IP routers is Ethernet but could be, for example, >>>>> PPP, it is possible to have a TRILL campus where none of the >>>>> connections between the RBridges is Ethernet but they are all some >>>>> other technology X, such as PPP. So, drafts that are "TRILL over X" >>>>> that are talking about full TRILL data and control plan connectivity >>>>> don't really seem to me to have much to do with L2VPN. Such drafts >>>>> should be done in either the TRILL WG or in the WG that does >>>>> technology X. >>>>>=20 >>>>> It seems to me that L2VPN has to do with method that provide limited >>>>> data plane interconnection for better fault isolation. >>>>>=20 >>>>> Thanks, >>>>> Donald >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >>>>> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >>>>> 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com >>>>>=20 >>>>>> Lucy >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >>>>>> Behalf Of Balaji Venkat Venkataswami >>>>>> Sent: Thursday, May 10, 2012 2:34 AM >>>>>> To: giles.heron@gmail.com; l2vpn@ietf.org >>>>>> Cc: sajassi@cisco.com; stbryant@cisco.com >>>>>> Subject: PBB E-VPN and TRILL >>>>>>=20 >>>>>> Hi Giles, >>>>>>=20 >>>>>> I totally agree on this point. We have a solution that was presented >>>>>> to the TRILL working group as well on the interconnection of TRILL >>>>>> islands. We would like to concur with this and request for entering >>>> our draft as well into the solution space. >>>>>>=20 >>>>>> The URL for the TRILL draft is as follows. >>>>>> http://tools.ietf.org/html/draft-balaji-trill-over-ip-multi-level-05 >>>>>>=20 >>>>>>=20 >>>>>> thanks and regards, >>>>>> balaji venkat >>>>>>=20 >>>>>> Sent: Wednesday, May 09, 2012 6:04 PM >>>>>> To: l2vpn@ietf.org >>>>>> Cc: Ali Sajassi (sajassi); Stewart Bryant >>>>>> Subject: PBB E-VPN and TRILL >>>>>>=20 >>>>>> Ali presented the PBB-EVPN draft at IETF83 in Paris: >>>>>>=20 >>>>>> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-01 >>>>>>=20 >>>>>> This has since been updated: >>>>>>=20 >>>>>> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-02 >>>>>>=20 >>>>>> During our discussions Ali mentioned that the authors would like the >>>> TRILL section of the draft to be separated out into a separate draft. >>>> In response Stewart questioned whether interconnecting TRILL islands is= >>>> in-scope for L2VPN. >>>>>>=20 >>>>>> Stewart, Nabil and I have just been discussing these issues. Whilst >>>> TRILL interconnect is not explicitly in-charter for L2VPN it would >>>> appear to be implicitly in-charter - our decision to standardise >>>> solutions for PBB VPLS and PBB E-VPN probably sets a precedent (since >>>> PBB is also unmentioned by the charter). >>>>>>=20 >>>>>> On this basis we would like to ask the WG the following three >>>> questions: >>>>>>=20 >>>>>> 1) is the WG happy for us to pursue interconnection of TRILL islands >>>> over L2VPN? >>>>>>=20 >>>>>> 2) is the WG happy for the authors to split the TRILL section of the >>>> PBB E-VPN draft into a separate draft? >>>>>>=20 >>>>>> 3) is the WG happy for the TRILL draft to be a WG doc? >>>>>>=20 >>>>>> Please respond by May 22nd if you are unhappy with any of these 3 >>>>>> actions (I'll take no response to mean the WG is in agreement with us= >>>>>> proceeding...) >>>>>>=20 >>>>>> Giles >>>>>>=20 >>>>>>=20 >>=20 From aldrin.ietf@gmail.com Thu May 10 14: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 C0A2111E8085 for ; Thu, 10 May 2012 14:49: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=[AWL=-0.000, 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 Ezm0iKicVqJ7 for ; Thu, 10 May 2012 14:49:03 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id CD8A111E8080 for ; Thu, 10 May 2012 14:49:03 -0700 (PDT) Received: by dacx6 with SMTP id x6so2367293dac.31 for ; Thu, 10 May 2012 14:49: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=R/cK4bt+j6BQswyCOPG3Ad6VPQ+XB6665gG4+jIVS+A=; b=x1ZNocBGqlfSHKv89kQQK1xpQ0sVMSKESjQ0hmGbYSNtx5MlAa2QFeWpojYXf4uDfL tl8gr2ymP2IP+U9gxyOFe1cxF6QlgGVeKT5VsFcuuegxot5Rc0kmoulEI+Xm9XnqgBz4 PzwHJDsndvavVJ7ljvfVlg2NhKNf4J/vCExujuXj2EWXtLobCKMOTigdLI9dEfliRkwU siFBM1JMD+w7ExOjkSun1ZeWiPAI6Vi+2dNioeFR6tH97YRhtwPeT2B8aSrVqW1C+1Dl /ZEBJNmjd/F4H7l7WeGezx5JRF09udOaPaLNRXSssQ5ZMY5PD34F2fQtvRHspOpGle/r obTA== Received: by 10.68.218.130 with SMTP id pg2mr7183239pbc.4.1336686543538; Thu, 10 May 2012 14:49:03 -0700 (PDT) Received: from [192.168.255.176] ([12.207.18.42]) by mx.google.com with ESMTPS id x1sm10624930pbp.50.2012.05.10.14.49.01 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 10 May 2012 14:49: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: X-Mailer: iPad Mail (9B206) From: Sam Aldrin Subject: Re: PBB E-VPN and TRILL Date: Thu, 10 May 2012 14:48:58 -0700 To: Sam Aldrin Cc: "l2vpn@ietf.org" , Ali Sajassi , "Stewart Bryant \(stbryant\)" 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, 10 May 2012 21:49:04 -0000 I withdraw my objection and support it to be a WG doc. Misunderstood that the new document will be under TRILL WG and objected for p= rocedural reasons. As the document is already under L2vPN and is a WG, split= ting into trill specific WG doc is fine as well. In fact I am in support of m= ost of the trill specific content, as it is the outcome of our offline discu= ssions for a while. Cheers Sam Sent from my iPad On May 10, 2012, at 12:57 PM, Sam Aldrin wrote: > I do not agree that It is just a name change of the document. >=20 > As far as the content goes, there is lot more to just BGP route. > All the content w.r.t unicast forwarding, multicast forwarding etc was add= ed recently. Atleast it was not present when the document was adopted as WG o= ne. >=20 > So, without taking groups consensus for WG adoption is not right, IMO. As t= he content is more TRILL specific, it should be polled within that WG as wel= l. >=20 > -sam > On May 10, 2012, at 12:41 PM, Ali Sajassi wrote: >=20 >>=20 >> When the doc was adopted as WG draft over 14 months ago, BGP route >> definition and procedures for TRILL DCI were already in place. >>=20 >> It seems like we are having all these email exchanges for a name change o= f a >> WG doc !! >>=20 >> -Ali >>=20 >> On 5/10/12 11:12 AM, "Sam Aldrin" wrote: >>=20 >>> As I mentioned in my other email, the split document should be asked for= WG >>> adoption. It may not be for pbb content but for the TRILL content it sho= uld be >>> done. When the doc was adopted as WG doc, trill content was minimal. >>>=20 >>> Sam >>>=20 >>> Sent from my iPhone >>>=20 >>> On May 10, 2012, at 10:59 AM, "Shah, Himanshu" wrote: >>>=20 >>>> Followings are the questions... >>>>=20 >>>> 2) is the WG happy for the authors to split the TRILL section of the PB= B >>>> E-VPN draft into a separate draft? >>>>=20 >>>> 3) is the WG happy for the TRILL draft to be a WG doc? >>>>=20 >>>> I think we are discussing splitting the trill section as a separate dra= ft and >>>> making it a WG doc. >>>>=20 >>>> What am I missing? >>>>=20 >>>> /himanshu >>>>=20 >>>> -----Original Message----- >>>> From: Ali Sajassi [mailto:sajassi@cisco.com] >>>> Sent: Thursday, May 10, 2012 1:53 PM >>>> To: Shah, Himanshu; Henderickx, Wim (Wim); Santiago Alvarez (saalvare);= Giles >>>> Heron; l2vpn@ietf.org >>>> Cc: Stewart Bryant (stbryant) >>>> Subject: Re: PBB E-VPN and TRILL >>>>=20 >>>>=20 >>>>>=20 >>>>> Based on my understanding, all the proposals are considered BEFORE >>>>> one is picked (with or without consolidation) for WG doc. >>>>=20 >>>> One proposal is already part of WG draft. Would you please read the dra= ft >>>> and then comment. >>>>=20 >>>> Cheers, >>>> Ali >>>>=20 >>>>>=20 >>>>> Thanks, >>>>> himanshu >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: Ali Sajassi [mailto:sajassi@cisco.com] >>>>> Sent: Thursday, May 10, 2012 1:28 PM >>>>> To: Shah, Himanshu; Henderickx, Wim (Wim); Santiago Alvarez (saalvare)= ; >>>>> Giles >>>>> Heron; l2vpn@ietf.org >>>>> Cc: Stewart Bryant (stbryant) >>>>> Subject: Re: PBB E-VPN and TRILL >>>>>=20 >>>>> Hi Himanshu, >>>>>=20 >>>>> I think every draft should be evaluated based on its own merits and if= it is >>>>> warranted there can be several drafts on this space. >>>>>=20 >>>>> Cheers, >>>>> Ali=20 >>>>>=20 >>>>>=20 >>>>> On 5/10/12 10:03 AM, "Shah, Himanshu" wrote: >>>>>=20 >>>>>> Hi Ali - >>>>>>=20 >>>>>> Correct.=20 >>>>>>=20 >>>>>> But within the context of previous two, which questions whether to >>>>>> consider interconnecting TRILL islands via L2VPN as part of WG charte= r, I >>>>>> think you >>>>>> would agree that once TRILL portion is split from your base document,= >>>>>> it might be worth to check if other proposals has merits. >>>>>>=20 >>>>>> Saying differently, if your split TRILL doc becomes WG doc at the sam= e time >>>>>> we >>>>>> include this work in the charter, other proposals would have no chanc= e to >>>>>> be >>>>>> even considered..:-( >>>>>>=20 >>>>>> IMHO - himanshu >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Ali Sajassi [mailto:sajassi@cisco.com] >>>>>> Sent: Thursday, May 10, 2012 12:47 PM >>>>>> To: Shah, Himanshu; Henderickx, Wim (Wim); Santiago Alvarez (saalvare= ); >>>>>> Giles >>>>>> Heron; l2vpn@ietf.org >>>>>> Cc: Stewart Bryant (stbryant) >>>>>> Subject: Re: PBB E-VPN and TRILL >>>>>>=20 >>>>>> Himanshu, >>>>>>=20 >>>>>> PBB-EVPN is already a WG draft! And the TRILL portion of it has been >>>>>> presented to L2VPN WG and has been in discussions for quite some time= . All >>>>>> we are doing is separating SPB/PBB from TRILL - nothing new is gettin= g >>>>>> added. Whereas, the other drafts are all new and they came about duri= ng >>>>>> last >>>>>> IETF meeting. >>>>>>=20 >>>>>> -Ali >>>>>>=20 >>>>>>=20 >>>>>> On 5/10/12 9:38 AM, "Shah, Himanshu" wrote: >>>>>>=20 >>>>>>> Yes to first 2. >>>>>>>=20 >>>>>>> As for 3rd, before we induct the stated draft as WG doc, we should >>>>>>> consider >>>>>>> other two proposals >>>>>>> mentioned in the mailing list, as part of due diligence. This is the= only >>>>>>> fair >>>>>>> way, and in fact, >>>>>>> consideration to responses to third question be postponed until othe= r >>>>>>> proposals have been given >>>>>>> chance to be reviewed at the WG, IMO. >>>>>>>=20 >>>>>>> /himanshu >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Beha= lf Of >>>>>>> Henderickx, Wim (Wim) >>>>>>> Sent: Thursday, May 10, 2012 12:27 PM >>>>>>> To: Santiago Alvarez (saalvare); Giles Heron; l2vpn@ietf.org >>>>>>> Cc: Ali Sajassi (sajassi); Stewart Bryant (stbryant) >>>>>>> Subject: RE: PBB E-VPN and TRILL >>>>>>>=20 >>>>>>> Same, yes to all 3 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Beha= lf Of >>>>>>> Santiago Alvarez (saalvare) >>>>>>> Sent: donderdag 10 mei 2012 18:26 >>>>>>> To: Giles Heron; l2vpn@ietf.org >>>>>>> Cc: Ali Sajassi (sajassi); Stewart Bryant (stbryant) >>>>>>> Subject: RE: PBB E-VPN and TRILL >>>>>>>=20 >>>>>>> Yes to all three. >>>>>>>=20 >>>>>>> SA >>>>>>> -- >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Beh= alf >>>>>>> Of >>>>>>>> Giles Heron >>>>>>>> Sent: Wednesday, May 09, 2012 5:34 AM >>>>>>>> To: l2vpn@ietf.org >>>>>>>> Cc: Ali Sajassi (sajassi); Stewart Bryant (stbryant) >>>>>>>> Subject: PBB E-VPN and TRILL >>>>>>>>=20 >>>>>>>> Ali presented the PBB-EVPN draft at IETF83 in Paris: >>>>>>>>=20 >>>>>>>> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-01 >>>>>>>>=20 >>>>>>>> This has since been updated: >>>>>>>>=20 >>>>>>>> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-02 >>>>>>>>=20 >>>>>>>> During our discussions Ali mentioned that the authors would like th= e >>>>>>> TRILL >>>>>>>> section of the draft to be separated out into a separate draft. In= >>>>>>> response >>>>>>>> Stewart questioned whether interconnecting TRILL islands is in-scop= e >>>>>>> for >>>>>>>> L2VPN. >>>>>>>>=20 >>>>>>>> Stewart, Nabil and I have just been discussing these issues. Whils= t >>>>>>> TRILL >>>>>>>> interconnect is not explicitly in-charter for L2VPN it would appear= to >>>>>>> be >>>>>>>> implicitly in-charter - our decision to standardise solutions for P= BB >>>>>>> VPLS >>>>>>>> and PBB E-VPN probably sets a precedent (since PBB is also unmentio= ned >>>>>>> by >>>>>>>> the charter). >>>>>>>>=20 >>>>>>>> On this basis we would like to ask the WG the following three >>>>>>> questions: >>>>>>>>=20 >>>>>>>> 1) is the WG happy for us to pursue interconnection of TRILL island= s >>>>>>> over >>>>>>>> L2VPN? >>>>>>>>=20 >>>>>>>> 2) is the WG happy for the authors to split the TRILL section of th= e >>>>>>> PBB E- >>>>>>>> VPN draft into a separate draft? >>>>>>>>=20 >>>>>>>> 3) is the WG happy for the TRILL draft to be a WG doc? >>>>>>>>=20 >>>>>>>> Please respond by May 22nd if you are unhappy with any of these 3 >>>>>>> actions >>>>>>>> (I'll take no response to mean the WG is in agreement with us >>>>>>> proceeding...) >>>>>>>>=20 >>>>>>>> Giles >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>=20 >=20 From d3e3e3@gmail.com Thu May 10 14:54: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 DEF1511E8079 for ; Thu, 10 May 2012 14:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.692 X-Spam-Level: X-Spam-Status: No, score=-103.692 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vveEY5Iiq+s4 for ; Thu, 10 May 2012 14:54:35 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1C38911E8080 for ; Thu, 10 May 2012 14:54:35 -0700 (PDT) Received: by yhq56 with SMTP id 56so2434385yhq.31 for ; Thu, 10 May 2012 14:54:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=LYFOXSLzR6VcfEoQXY+eTVft93k2DFHP/RrcCA4J0YU=; b=KGU/yrCURDiU9TS7Q1PA2knt/o2wnBkYSx1OtsslAQTUGEUp2/GknyMMmvB7bWPcnf jxqxsAGOvYssbjwoN5mKE6Q3TBoTDtJ0AbqW2oaHzUr+ILeImHBG22R5Js/DfowHTK+x wldyul+Y63dKuPFoALZGB028QiqI07GKvrwebFoczT5e36a7alLB0eUmbaDrMYjDW+71 UH9MKHglMS6jtZZMTYHhZGRwqN7Hsuzs76AvWso4oyFLBbbXraiNIxFucsPqyEsSnjcF CrOwdXI5QdY2Y7tzAlwGRtuo7FOP8yYuCldtYQMP9DDZFBTvla/peEBdEQm98+dkK8SJ jRmA== Received: by 10.50.41.165 with SMTP id g5mr392887igl.13.1336686874360; Thu, 10 May 2012 14:54:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.59.201 with HTTP; Thu, 10 May 2012 14:54:14 -0700 (PDT) In-Reply-To: References: <5EC91DDA759C324DB62C5A5F7B4922193CC839078C@EXCH-CLUSTER-11.force10networks.com> <2691CE0099834E4A9C5044EEC662BB9D33107E1C@dfweml506-mbx> From: Donald Eastlake Date: Thu, 10 May 2012 17:54:14 -0400 Message-ID: Subject: Re: PBB E-VPN and TRILL To: Sam Aldrin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "l2vpn@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, 10 May 2012 21:54:36 -0000 Hi Sam, On Thu, May 10, 2012 at 4:59 PM, Sam Aldrin wrote: > Donald, > > Comment inline. > > Sent from my iPad > > On May 10, 2012, at 10:56 AM, Donald Eastlake wrote: > >> ... >> >> It seems to me that L2VPN has to do with method that provide limited >> data plane interconnection for better fault isolation. Sorry, should say "control plane" immediately above. > That is incorrect. The draft specifies interconnecting trill islands. But= after interconnection, it will be one big trill campus, where RBridges are= apart (which is your first case). Otherwise the concept of nickname unique= ness doesn't arise. I don't see why you think control plane interconnection is binary. There is a spectrum of possible interconnection. A TRILL campus is defined in the current TRILL standard as a set of RBridges and the links between them, bounded by end stations and Layer 3 routers, over which the TRILL protocol runs. Such a set of RBridges share the same link state database. That's an awfully long way from a set of islands that are, for example statically configured as to what range of nickname each can use and, at the control level, mostly just exchange those ranges of nicknames. Just because it is a spectrum and you can find cases in the middle does not eliminate the utility of distinguishing between tightly coupled RBridges and more loosely coupled islands. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com > > Sam >> >> Thanks, >> Donald >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >> =A0Donald E. Eastlake 3rd =A0 +1-508-333-2270 (cell) >> =A0155 Beaver Street, Milford, MA 01757 USA >> =A0d3e3e3@gmail.com >> >>> Lucy >>> >>> -----Original Message----- >>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of Balaji Venkat Venkataswami >>> Sent: Thursday, May 10, 2012 2:34 AM >>> To: giles.heron@gmail.com; l2vpn@ietf.org >>> Cc: sajassi@cisco.com; stbryant@cisco.com >>> Subject: PBB E-VPN and TRILL >>> >>> Hi =A0Giles, >>> >>> I totally agree on this point. We have a solution that was presented to= the TRILL >>> working group as well on the interconnection of TRILL islands. We would= like to >>> concur with this and request for entering our draft as well into the so= lution space. >>> >>> The URL for the TRILL draft is as follows. >>> http://tools.ietf.org/html/draft-balaji-trill-over-ip-multi-level-05 >>> >>> >>> thanks and regards, >>> balaji venkat >>> >>> Sent: Wednesday, May 09, 2012 6:04 PM >>> To: l2vpn@ietf.org >>> Cc: Ali Sajassi (sajassi); Stewart Bryant >>> Subject: PBB E-VPN and TRILL >>> >>> Ali presented the PBB-EVPN draft at IETF83 in Paris: >>> >>> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-01 >>> >>> This has since been updated: >>> >>> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-02 >>> >>> During our discussions Ali mentioned that the authors would like the TR= ILL section of the draft to be separated out into a separate draft. =A0In r= esponse Stewart questioned whether interconnecting TRILL islands is in-scop= e for L2VPN. >>> >>> Stewart, Nabil and I have just been discussing these issues. =A0Whilst = TRILL interconnect is not explicitly in-charter for L2VPN it would appear t= o be implicitly in-charter - our decision to standardise solutions for PBB = VPLS and PBB E-VPN probably sets a precedent (since PBB is also unmentioned= by the charter). >>> >>> On this basis we would like to ask the WG the following three questions= : >>> >>> 1) is the WG happy for us to pursue interconnection of TRILL islands ov= er L2VPN? >>> >>> 2) is the WG happy for the authors to split the TRILL section of the PB= B E-VPN draft into a separate draft? >>> >>> 3) is the WG happy for the TRILL draft to be a WG doc? >>> >>> Please respond by May 22nd if you are unhappy with any of these 3 actio= ns (I'll take no response to mean the WG is in agreement with us proceeding= ...) >>> >>> Giles >>> >>> From aldrin.ietf@gmail.com Thu May 10 17:31: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 5DB6521F85A2 for ; Thu, 10 May 2012 17:31:55 -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 ep4l3EtmSau2 for ; Thu, 10 May 2012 17:31:54 -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 AEB1321F85A1 for ; Thu, 10 May 2012 17:31:54 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so2678705pbc.31 for ; Thu, 10 May 2012 17:31:54 -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=O5c9+8zyAZGX9r9/sAXSQF4aRsl8Bu/o9KdrUGcYs/s=; b=Kppf/R0oTVhzOEVE6JvrXIT5MpJi646z9U5OyBVCrasSJzFTkzYBTINFfkw+7jmqf4 NETpWwoF4tRE5Me6Mf2B02T8/2uacpjE9WPoMnKmmNjPuGuUTjQaOSmIGtY9NZaQIwAV moXEYGJvlUB/bdYVdVnCMVkxO66fXsHHQTZYcTW3MHwcBxl47UqGmOA4fdf7TasYjmxF Zw11DFQCqefodW0m2IyAFgHqPLBwNhN8MZotbQmxjDFdvv9tgKs1nJHK8ilUMMcMXC/p MlsXwTf91lhjSoWMBZMFg+5BukA94ec8AbokZRGJuLzInfLrBaBGhmGsM17KLirrx2HV Tr5Q== Received: by 10.68.202.130 with SMTP id ki2mr25478698pbc.52.1336696314193; Thu, 10 May 2012 17:31:54 -0700 (PDT) Received: from [192.168.255.176] ([12.207.18.42]) by mx.google.com with ESMTPS id oy8sm10980009pbc.52.2012.05.10.17.31.52 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 10 May 2012 17:31:53 -0700 (PDT) References: <5EC91DDA759C324DB62C5A5F7B4922193CC839078C@EXCH-CLUSTER-11.force10networks.com> <2691CE0099834E4A9C5044EEC662BB9D33107E1C@dfweml506-mbx> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (9B206) From: Sam Aldrin Subject: Re: PBB E-VPN and TRILL Date: Thu, 10 May 2012 17:31:50 -0700 To: Donald Eastlake Cc: "l2vpn@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, 11 May 2012 00:31:55 -0000 Hi Donald, See my replies inline. Sam Sent from my iPad On May 10, 2012, at 2:54 PM, Donald Eastlake wrote: > Hi Sam, >=20 > On Thu, May 10, 2012 at 4:59 PM, Sam Aldrin wrote:= >> Donald, >>=20 >> Comment inline. >>=20 >> Sent from my iPad >>=20 >> On May 10, 2012, at 10:56 AM, Donald Eastlake wrote: >>=20 >>> ... >>>=20 >>> It seems to me that L2VPN has to do with method that provide limited >>> data plane interconnection for better fault isolation. >=20 > Sorry, should say "control plane" immediately above. >=20 >> That is incorrect. The draft specifies interconnecting trill islands. But= after interconnection, it will be one big trill campus, where RBridges are a= part (which is your first case). Otherwise the concept of nickname uniquenes= s doesn't arise. >=20 > I don't see why you think control plane interconnection is binary. > There is a spectrum of possible interconnection. %sam- it is because you categorized drafts into two areas. One which expands= trill campus and another set to keep independent.=20 >=20 > A TRILL campus is defined in the current TRILL standard as a set of > RBridges and the links between them, bounded by end stations and Layer > 3 routers, over which the TRILL protocol runs. Such a set of RBridges > share the same link state database. That's an awfully long way from a > set of islands that are, for example statically configured as to what > range of nickname each can use and, at the control level, mostly just > exchange those ranges of nicknames. Just because it is a spectrum and > you can find cases in the middle does not eliminate the utility of > distinguishing between tightly coupled RBridges and more loosely > coupled islands. Spectrum type allocation is network design and trill doesn't specify or mand= ates any, from protocol perspective, right? If so, any solution being propos= ed need to consider that there could exist a trill islands which have nickna= me overlap. So, if they get interconnected, either they have to be resolved o= r maintained independently. So, the issue is not with how tight they are cou= pled, but rather how the end topology will be when they get interconnected. T= hat is what I was eluding to. Sam >=20 > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com >=20 >>=20 >> Sam >>>=20 >>> Thanks, >>> Donald >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >>> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >>> 155 Beaver Street, Milford, MA 01757 USA >>> d3e3e3@gmail.com >>>=20 >>>> Lucy >>>>=20 >>>> -----Original Message----- >>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf O= f Balaji Venkat Venkataswami >>>> Sent: Thursday, May 10, 2012 2:34 AM >>>> To: giles.heron@gmail.com; l2vpn@ietf.org >>>> Cc: sajassi@cisco.com; stbryant@cisco.com >>>> Subject: PBB E-VPN and TRILL >>>>=20 >>>> Hi Giles, >>>>=20 >>>> I totally agree on this point. We have a solution that was presented to= the TRILL >>>> working group as well on the interconnection of TRILL islands. We would= like to >>>> concur with this and request for entering our draft as well into the so= lution space. >>>>=20 >>>> The URL for the TRILL draft is as follows. >>>> http://tools.ietf.org/html/draft-balaji-trill-over-ip-multi-level-05 >>>>=20 >>>>=20 >>>> thanks and regards, >>>> balaji venkat >>>>=20 >>>> Sent: Wednesday, May 09, 2012 6:04 PM >>>> To: l2vpn@ietf.org >>>> Cc: Ali Sajassi (sajassi); Stewart Bryant >>>> Subject: PBB E-VPN and TRILL >>>>=20 >>>> Ali presented the PBB-EVPN draft at IETF83 in Paris: >>>>=20 >>>> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-01 >>>>=20 >>>> This has since been updated: >>>>=20 >>>> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-02 >>>>=20 >>>> During our discussions Ali mentioned that the authors would like the TR= ILL section of the draft to be separated out into a separate draft. In resp= onse Stewart questioned whether interconnecting TRILL islands is in-scope fo= r L2VPN. >>>>=20 >>>> Stewart, Nabil and I have just been discussing these issues. Whilst TR= ILL interconnect is not explicitly in-charter for L2VPN it would appear to b= e implicitly in-charter - our decision to standardise solutions for PBB VPLS= and PBB E-VPN probably sets a precedent (since PBB is also unmentioned by t= he charter). >>>>=20 >>>> On this basis we would like to ask the WG the following three questions= : >>>>=20 >>>> 1) is the WG happy for us to pursue interconnection of TRILL islands ov= er L2VPN? >>>>=20 >>>> 2) is the WG happy for the authors to split the TRILL section of the PB= B E-VPN draft into a separate draft? >>>>=20 >>>> 3) is the WG happy for the TRILL draft to be a WG doc? >>>>=20 >>>> Please respond by May 22nd if you are unhappy with any of these 3 actio= ns (I'll take no response to mean the WG is in agreement with us proceeding.= ..) >>>>=20 >>>> Giles >>>>=20 >>>>=20 From ssalam@cisco.com Thu May 10 17:45: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 8C87D21F8592 for ; Thu, 10 May 2012 17:45:15 -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 7xC6kVF3qhd7 for ; Thu, 10 May 2012 17:45:14 -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 AECF821F858F for ; Thu, 10 May 2012 17:45:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ssalam@cisco.com; l=1452; q=dns/txt; s=iport; t=1336697114; x=1337906714; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=YbpzNhF4NgPb5WsS/WjDexjldt9Jqzo28xy+mlL0pzU=; b=BSOrBaQFns7Pe5QlS6w7Qi/QLh2zERWpXwo6o+GUxQLXYd7ubmhbXfEZ amQVtBdDb2+3P8KCsRg5Za9d4Y7eLsIlmEgzuqkZwOGdjFoy/ai4UWFOE ABHKD6CNkLAbwUcEvx64QPDhxYG5HJqzM5T2+iBkCogy1R4ITpxVjxqTu Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuoHAPxfrE+rRDoJ/2dsb2JhbABEtB0CgQeCFQEBAQMBEgEnAgE8BQ0BCGc2AQEEAQ0FGweHXgMGBAELmyqWSA2JU4olhwoEiGSNGYERiiyDGieBQoMJ X-IronPort-AV: E=Sophos;i="4.75,567,1330905600"; d="scan'208";a="41235288" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 11 May 2012 00:45:14 +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 q4B0jEFd009236; Fri, 11 May 2012 00:45:14 GMT Received: from xmb-sjc-233.amer.cisco.com ([128.107.191.88]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 May 2012 17:45:14 -0700 Received: from 161.44.207.8 ([161.44.207.8]) by xmb-sjc-233.amer.cisco.com ([128.107.191.88]) with Microsoft Exchange Server HTTP-DAV ; Fri, 11 May 2012 00:45:13 +0000 User-Agent: Microsoft-Entourage/12.27.0.100910 Date: Thu, 10 May 2012 17:45:12 -0700 Subject: Re: PBB E-VPN and TRILL From: Samer Salam To: Giles Heron , Message-ID: Thread-Topic: PBB E-VPN and TRILL Thread-Index: Ac0t4AvyMdWKxMA3AUSUMcn62xbEYQBL0ahV In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 11 May 2012 00:45:14.0219 (UTC) FILETIME=[53E5B3B0:01CD2F0F] Cc: "Ali Sajassi \(sajassi\)" , Stewart Bryant 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, 11 May 2012 00:45:15 -0000 Yes, to all three questions. Regards, Samer On 12-05-09 5:34 AM, "Giles Heron" wrote: > Ali presented the PBB-EVPN draft at IETF83 in Paris: > > http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-01 > > This has since been updated: > > http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-02 > > During our discussions Ali mentioned that the authors would like the TRILL > section of the draft to be separated out into a separate draft. In response > Stewart questioned whether interconnecting TRILL islands is in-scope for > L2VPN. > > Stewart, Nabil and I have just been discussing these issues. Whilst TRILL > interconnect is not explicitly in-charter for L2VPN it would appear to be > implicitly in-charter - our decision to standardise solutions for PBB VPLS > and PBB E-VPN probably sets a precedent (since PBB is also unmentioned by > the charter). > > On this basis we would like to ask the WG the following three questions: > > 1) is the WG happy for us to pursue interconnection of TRILL islands over > L2VPN? > > 2) is the WG happy for the authors to split the TRILL section of the PBB > E-VPN draft into a separate draft? > > 3) is the WG happy for the TRILL draft to be a WG doc? > > Please respond by May 22nd if you are unhappy with any of these 3 actions > (I'll take no response to mean the WG is in agreement with us proceeding...) > > Giles > > From sboutros@cisco.com Thu May 10 18: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 4225821F85C3 for ; Thu, 10 May 2012 18:21:53 -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=[AWL=0.000, 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 3oaQQixDAAoa for ; Thu, 10 May 2012 18:21:52 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 17E1521F859F for ; Thu, 10 May 2012 18:21:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sboutros@cisco.com; l=7308; q=dns/txt; s=iport; t=1336699312; x=1337908912; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=wFye4OikOhog4L51Ylg70NfWJi3UYKgPcMENTkGdLFM=; b=UkHDkBtedaJrz/T3xCBlUlbdwii/RJMdc7PHR1k1FqP09pYS0SDLYagh +X/23ioRTnsm8nhn+Fny5vh30TiV7qB2PImlPPSglfHd0coNMIlAaV4QW N0ShZ1qBm871QPueGSoyS6paDmsNqmYDJPVfdUb8Y3dePCt1nUF7LXbap g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EACJprE+tJXHA/2dsb2JhbABEtB+BB4IVAQEBBBIBYQUMBAsRBAEBKAdGCQgGEyKHbAubJqArixIZhSFjBIhkjRmBEY1GgWmDCYE/ X-IronPort-AV: E=Sophos;i="4.75,567,1330905600"; d="scan'208";a="82261812" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 11 May 2012 01:21:51 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id q4B1LpSY029260; Fri, 11 May 2012 01:21:51 GMT Received: from xfe-rcd-201.cisco.com ([72.163.62.204]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 May 2012 20:21:51 -0500 Received: from rtp-vpn2-580.cisco.com ([10.82.242.68]) by xfe-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 May 2012 20:21:49 -0500 Subject: Re: Static VPLS MAC withdrawal draft Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Sami Boutros In-Reply-To: Date: Thu, 10 May 2012 18:21:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <78CE5EBC-3B62-4783-8F32-12B8C654F4CF@cisco.com> References: <32B4F6D6-CB5A-4DE9-8A14-B04B175BC30E@cisco.com> To: Alexander Vainshtein X-Mailer: Apple Mail (2.1251.1) X-OriginalArrivalTime: 11 May 2012 01:21:49.0290 (UTC) FILETIME=[7042F4A0:01CD2F14] Cc: "l2vpn@ietf.org" , "msiva@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, 11 May 2012 01:21:53 -0000 Hi Sasha, >>=20 >> Thanks for your comments, Please see responses inline.. >>=20 >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: Alexander Vainshtein >>>> Sent: Thursday, May 10, 2012 5:08 PM >>>> To: 'msiva@cisco.com:'; Sami Boutros (sboutros@cisco.com); >>>> 'nmcgill@cisco.com' >>>> Cc: l2vpn@ietf.org; 'Giles Heron'; Rotem Cohen; Andrew Sergeev; >> Mishael >>>> Wexler; Gideon Agmon >>>> Subject: RE: Static VPLS MAC withdrawal draft >>>>=20 >>>> Hi all, >>>> I've read the draft in question and I would like to clarify several = issues >> that >>>> look either undefined or ambiguous to me. >>>>=20 >>>> 1. To the best of my understanding, the draft requires each PE >> participating >>>> in a given VPLS instance to set up two counters for each static PW >>>> connecting it to a peer PE device in this VPLS instance: one for = static MAC >>>> withdrawal messages it is going to send and another - for static = MAC >>>> withdrawal messages it receives. Is this understanding correct? >>>>=20 >>=20 >> Sami: This is correct. >>=20 >>>> 2. Assuming a positive answer to the previous questions, how are = these >>>> counters initialized? The draft seems to be moot on this point. >>=20 >> Sami: This is what the draft has for setting up the sequence # in = section 3. >> Only half of the sequence number space is used. Modular arithmetic >> is used to detect wrapping of sequence number. When sequence number >> wraps (i.e., when it becomes 0), all MAC addresses are flushed and >> the sequence number is reset. >> Sami: Can you please explain what's vague in the above? > [[[Sasha]]] This does not say too much about initialization (at = least, not to me). > And it would be nice if the draft was more specific here. Sami: Agreed, we need to add the initialization value to the text. =20 >>=20 >>>> The more >>>> interesting question is, of course, about initialization of the = counter of >>>> received static MAC withdrawal messages, since, with static PWs, >> generally >>>> speaking, there is no synchronization between setting up one of its = end >>>> points and setting up another one. >>=20 >>=20 >> Sami: Initially the rx sequence # can be assumed to be 0. > [[[Sasha]]] But you've said that Rx number 0 results in flushing all = MAC addresses? Sami: Good point, but this is why the receiving PE should always flush = on receiving 0. Sami: The Transmitter PE would then increment the sequence # and = subsequent=20 Sami: Transmission will be higher than 0.=20 >>=20 >>>>=20 >>>> 3. The draft specifies that: >>>> - The transmitter sends the MAC withdrawal message with the same >>>> sequence number until it receives an ACK for it (Section 4.1.1) >>>> - The receiver, after having acknowledged a MAC withdrawal >>>> message, ignores refresh messages with the same sequence number >>>> (Section 4.1.2) >>>> What is supposed to happen in the following scenario: >>>> - Transmitter finds out that some MACs have to be withdrawn = (e.g., >>>> because the AC from which they have been learned fails) >>>> and sends a MAC withdrawal message to its peers with sequence >>>> number N >>>> - Immediately after that (i.e., before it receives an ACK for = this >>>> message) it finds out that yet another set of MAC addresses has to = be >>>> withdrawn >>>> - Retransmission timer expires without ACK received. >>>>=20 >>=20 >> Sami: A new sequence # will be transmitted that will include both = sets of >> MAC addresses >> Sami: that need to be flushed, and the transmitter will wait for an = ack for >> this new sequence #. >> Sami: We can add this to the draft. > [[[Sasha]]] First of all, I think something like that MUST be added to = the draft. > And I am not sure what you say is really OK: consider the case when = ACK for the first withdrawal message is received after the 2nd message = has been sent. > If one of the ACKed (and withdrawn) MAC addresses has been then = re-learned they will be flushed again=85 Sami: Yes, this will lead to deleting again, and then the macs will be = learnt again, keep in mind that we are talking about using a mac list = (not an empty mac list), and deleting 2 sets of macs and we didn't Sami: = get the ack for the 1st set in time before we ask to delete the 2nd set. = I would think this should be ok, however am open to better schemes. >>=20 >>>> 4. Suppose that only one end point of a static PW between a given = pair of >>>> peers has been set up. In this case transmitting the static MAC >> withdrawal >>>> messages via such a PW is possible, but ACKs will never be = received. >> Should >>>> retransmission of these messages go on "ad infinitum"? >>>>=20 >>=20 >> Sami: Yes, this will be the case, the mechanism will be no different = then the >> static PW status one for this case. > [[[Sasha]]] But ACK is not mandatory in the PW status message 9indeed, = it is not clear if it is ever needed). > Here you may end with multiple retransmitting messages that are sent = to a black hole. Sami: Wouldn't that be TRUE too for PW status messages? however is there = a scheme you have in mind to solve this? Thanks, Sami >>=20 >>>> 5. The draft does not specify any default value for the retransmit = time. >>>>=20 >>=20 >> Sami: Sure will add. >>=20 >>>> 6. A nit: Heading of Section 4 is followed by headings for = Sections 4.1.1 >> and >>>> 4.1.2 without any heading for 4.1. >>>>=20 >>=20 >> Sami: Sure will fix. >>=20 >>>> Hopefully these questions will be useful. >>>>=20 >>=20 >> Thanks, >>=20 >> Sami >>=20 >>=20 >>>> Regards, >>>> Sasha >>>>=20 >>>>> -----Original Message----- >>>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >> Behalf >>>>> Of Giles Heron >>>>> Sent: Tuesday, May 08, 2012 10:06 PM >>>>> To: l2vpn@ietf.org >>>>> Subject: Static VPLS MAC withdrawal draft >>>>>=20 >>>>> Hi everyone, >>>>>=20 >>>>> The following draft was presented at IETF in Paris: >>>>>=20 >>>>> http://tools.ietf.org/html/draft-boutros-l2vpn-mpls-tp-mac-wd-00 >>>>>=20 >>>>> The authors have asked for it to be adopted as a WG draft, but at = this >> stage >>>>> the chairs' view is that it probably hasn't had enough sets of = eyes on it. >>>>>=20 >>>>> So this email is to request that those on the list take a read of = the draft >>>>> and send comments back to the list. Depending on the response we = get >>>> we >>>>> may >>>>> then ask the WG if they feel happy adopting this as a WG draft. >>>>>=20 >>>>> Nabil and Giles >>>>>=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 >=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 shtsuchi@cisco.com Thu May 10 18:42: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 69BA721F847F for ; Thu, 10 May 2012 18:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.149 X-Spam-Level: X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=0.450, 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 suh1OCQgQ571 for ; Thu, 10 May 2012 18:42:22 -0700 (PDT) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9FD21F8478 for ; Thu, 10 May 2012 18:42:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shtsuchi@cisco.com; l=1422; q=dns/txt; s=iport; t=1336700542; x=1337910142; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=dHxICI43dYLHPEhBu3+sRntKyY3qejz5KnOLkDEVZyk=; b=g5kZKUK6hiTbCABaYVW9KEnSb6ySGnzc67ATEsmB9MGQ2qyvnrp2d3jO pDK6ujvlJ1ddh6zi5LK0blD6C8D1DQAbftThJhUy1b9NMurdD1X4XsO+L XR6AiuTvT7G9919Kod7MeZLh2ZJgOQzGlGREVPssP+w4KoXz9utiPf8Td k=; X-IronPort-AV: E=Sophos;i="4.75,567,1330905600"; d="scan'208";a="11917847" Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 11 May 2012 01:42:20 +0000 Received: from [10.71.44.89] (tky-shtsuchi-8918.cisco.com [10.71.44.89]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q4B1gIPb003001; Fri, 11 May 2012 01:42:19 GMT Message-ID: <4FAC6E78.2020908@cisco.com> Date: Fri, 11 May 2012 10:42:16 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: giles.heron@gmail.com Subject: Re: PBB E-VPN and TRILL References: In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org, sajassi@cisco.com, 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, 11 May 2012 01:42:23 -0000 1)Yes. 2)Yes. 3)Yes. Regards, -Shishio (2012/05/09 21:34), Giles Heron wrote: > Ali presented the PBB-EVPN draft at IETF83 in Paris: > > http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-01 > > This has since been updated: > > http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-02 > > During our discussions Ali mentioned that the authors would like the TRILL > section of the draft to be separated out into a separate draft. In response > Stewart questioned whether interconnecting TRILL islands is in-scope for > L2VPN. > > Stewart, Nabil and I have just been discussing these issues. Whilst TRILL > interconnect is not explicitly in-charter for L2VPN it would appear to be > implicitly in-charter - our decision to standardise solutions for PBB VPLS > and PBB E-VPN probably sets a precedent (since PBB is also unmentioned by > the charter). > > On this basis we would like to ask the WG the following three questions: > > 1) is the WG happy for us to pursue interconnection of TRILL islands over > L2VPN? > > 2) is the WG happy for the authors to split the TRILL section of the PBB > E-VPN draft into a separate draft? > > 3) is the WG happy for the TRILL draft to be a WG doc? > > Please respond by May 22nd if you are unhappy with any of these 3 actions > (I'll take no response to mean the WG is in agreement with us proceeding...) > > Giles > > > From xuxiaohu@huawei.com Thu May 10 19:01: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 83D2E21F85B8 for ; Thu, 10 May 2012 19:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.694 X-Spam-Level: * X-Spam-Status: No, score=1.694 tagged_above=-999 required=5 tests=[AWL=-0.849, BAYES_00=-2.599, CN_BODY_35=0.339, 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 vfFY42SD4WXN for ; Thu, 10 May 2012 19:01:56 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id DF1BD21F85B6 for ; Thu, 10 May 2012 19:01:55 -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 AGB00033; Thu, 10 May 2012 22:01:55 -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, 10 May 2012 19:00:36 -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; Thu, 10 May 2012 19:00:34 -0700 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.182]) by szxeml438-hub.china.huawei.com ([10.72.61.73]) with mapi id 14.01.0323.003; Fri, 11 May 2012 10:00:30 +0800 From: Xuxiaohu To: Donald Eastlake , Sam Aldrin Subject: re: PBB E-VPN and TRILL Thread-Topic: PBB E-VPN and TRILL Thread-Index: Ac0t4AvyMdWKxMA3AUSUMcn62xbEYQAmBZ9AAAGW1qAADswyEP//sxoAgAAF8ICAAA2AAIAABSsAgAADqwD//x3w0A== Date: Fri, 11 May 2012 02:00:30 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02F2150E@szxeml525-mbs.china.huawei.com> References: <5EC91DDA759C324DB62C5A5F7B4922193CC839078C@EXCH-CLUSTER-11.force10networks.com> <2691CE0099834E4A9C5044EEC662BB9D33107E1C@dfweml506-mbx> <6DCF0C64-D831-449A-9D7D-71386A2B8FF1@gmail.com> <5E893DB832F57341992548CDBB333163A577CAB2CF@EMBX01-HQ.jnpr.net> <8892F3A6-49FE-4BE3-A6D7-8ADC8001C95E@gmail.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="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l2vpn@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, 11 May 2012 02:01:56 -0000 DQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6IGwydnBuLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnXSC0+rHtIERvbmFsZA0KPiBFYXN0bGFrZQ0K PiC3osvNyrG85DogMjAxMsTqNdTCMTHI1SAzOjM4DQo+IMrVvP7IyzogU2FtIEFsZHJpbg0KPiCz rcvNOiBsMnZwbkBpZXRmLm9yZzsgc3RicnlhbnRAY2lzY28uY29tDQo+INb3zOI6IFJlOiBQQkIg RS1WUE4gYW5kIFRSSUxMDQo+IA0KPiBPbiBUaHUsIE1heSAxMCwgMjAxMiBhdCAzOjI1IFBNLCBT YW0gQWxkcmluIDxhbGRyaW4uaWV0ZkBnbWFpbC5jb20+IHdyb3RlOg0KPiA+IEhpIEpvaG4sDQo+ ID4NCj4gPiBUaGFua3MgZm9yIHRoZSByZXBseS4NCj4gPg0KPiA+IFRoZSB3YXkgSSB1bmRlcnN0 b29kIHRoZSBiZWxvdyBzZW50ZW5jZSBmcm9tIHRoZSBjaGFydGVyLCB3aGVuIEkgZmlyc3QgcmVh ZCwNCj4gd2FzIHRoYXQgaXQgaW5jbHVkZXMgZXh0ZW5kaW5nIFRSSUxMIGJ5IGludGVyY29ubmVj dGluZyBUUklMTCBjYW1wdXNlcyBvciBzaXRlcy4NCj4gQnV0IGR1cmluZyBsYXN0IFdHIHNlc3Np b24sIGl0IHdhc24ndCBzbyBhbmQgd2FzIGNvbnRlbnRpb3VzIHRvcGljLiBBcyBUUklMTCBpcyBM Mg0KPiB0ZWNobm9sb2d5IGFuZCBpbnRlcmNvbm5lY3RpbmcgdGhlbSBmYWxscyBpbnRvIEwyVlBO IGNoYXJ0ZXIvdGVycml0b3J5Lg0KPiANCj4gSSBkbyBub3QgYWdyZWUgdGhhdCBUUklMTCBpcyBM MiB0ZWNobm9sb2d5Lg0KDQpGdWxsIGFncmVlLiBUbyBzb21lIGV4dGVudCwgVFJJTEwgY2FuIGJl IGxvb2tlZCBhcyBJUHZ4IGluIHdoaWNoIHRoZSBhZGRyZXNzIGlzIHNob3J0ZXIgdGhhbiB0aGF0 IG9mIElQdjQgYW5kIHRoZSBvbmx5IGFwcGxpY2F0aW9uIG92ZXIgc3VjaCBJUHZ4IGlzIEwyVlBO IHNlcnZpY2VzIHRpbGwgbm93LiBNYXliZSBpdCBjb3VsZCBsYXRlciBiZSBleHRlbmRlZCB0byBz dXBwb3J0IEwzVlBOIHNlcnZpY2VzIGp1c3QgYXMgd2hhdCBTUEIgZGlkIChzZWUgaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdW5iZWhhZ2VuLXNwYmItaXAtaXB2cG4tMDApLiAgSWYg SSByZW1lbWJlcmVkIGNvcnJlY3RseSwgb25lIG9mIHRoZSBQQkItRVZQTiBjby1hdXRob3JzIGhh ZCBldmVyIGNsYWltZWQgdGhhdCAiVFJJTEwgaXMgYW4gSVAtYmFzZWQgc29sdXRpb24iIG9uIHRo ZSBMMlZQTiBzZXNzaW9uIG9mIElFVEY4MiAoc2VlIHRoZSBtZWV0aW5nIG1pbnV0ZXMgYXQgaHR0 cDovL3Rvb2xzLmlldGYub3JnL3dnL2wydnBuL21pbnV0ZXM/aXRlbT1taW51dGVzODIuaHRtbCAp Lg0KDQpJTUhPLCBpdCdzIGluY29ycmVjdCB0byBkZXRlcm1pbmUgd2hldGhlciBhIGdpdmVuIHVu ZGVybHlpbmcgdGVjaG5vbG9neSBpcyBMMiBvciBMMyBqdXN0IGFjY29yZGluZyB0byBpdHMgdXBw ZXIgYXBwbGljYXRpb25zLCBlc3BlY2lhbGx5IGp1c3QgYWNjb3JkaW5nIHRvIGl0cyBjdXJyZW50 IGFwcGxpY2F0aW9ucy4NCg0KSSBndWVzcyBub2JvZHkgd2lsbCBvYmplY3QgdGhhdCB0aGUgIkwy IiBpbiB0aGUgY29udGV4dCBvZiBMMlZQTiByZXByZXNlbnRzICJNQUMgb3IgRXRoZXJuZXQiLCBl c3BlY2lhbGx5IGFjY29yZGluZyB0byB0aGUgY3VycmVudCBMMlZQTiBjaGFydGVyLiBPbiBiYXNp cyBvZiB0aGlzIGNvbnNlbnN1cywgaWYgdGhlIHRyaWxsIGludGVyY29ubmVjdGlvbiBzb2x1dGlv biBpcyBqdXN0IHRvIHVzZSB0aGUgZXhpdGluZyBMMlZQTiB0ZWNobm9sb2dpZXMgdG8gaW50ZXJj b25uZWN0IHRyaWxsIFJCcyBsb2NhdGVkIGluIGRpZmZlcmVudCB0cmlsbCBpc2xhbmRzLCBqdXN0 IGxpa2UgdGhlIG1ldGhvZCBvZiB1c2luZyBMMlZQTiB0byBpbnRlcmNvbm5lY3QgbXVsdGlwbGUg SVAgcm91dGVycyBsb2NhdGVkIGluIGRpZmZlcmVudCBzaXRlcywgaXQgYmVsb25ncyB0byB0aGUg TDJWUE4gc2NvcGUgYW5kIGp1c3QgbmVlZHMgdG8gYmUgaW5mb3JtYXRpb25hbC4gQXMgZm9yIHRo ZSBtZXRob2QgZGVmaW5lZCBpbiB0aGUgZXhpc3RpbmcgUEJCLUVWUE4gZHJhZnQsIGlmIEkgdW5k ZXJzdG9vZCBpdCBjb3JyZWN0bHksIGl0IHVzZXMgQkdQIHRvIGFkdmVydGlzZSBUUklMTCBuaWNr bmFtZSByZWFjaGFiaWxpdHkgaW5mbyBiZXR3ZWVuIFBFIHJvdXRlcnMgYW5kIHVzZSBUUklMTCBu aWNrbmFtZXMsIHJhdGhlciB0aGFuIE1BQyBhZGRyZXNzZXMgZm9yIHJvdXRpbmcgYW5kIGZvcndh cmRpbmcgZGVjaXNpb24gb24gUEUgcm91dGVycy4gSGVuY2UgaXQgc2hvdWxkIG5vdCBiZWxvbmcg dG8gdGhlIEwyVlBOIHNjb3BlLiBCeSB0aGUgd2F5LCBJIGRpZG4ndCBzZWUgd2h5IFBCQiBpcyBt ZW50aW9uZWQgaGVyZSBzaW5jZSBQQkIgaXNuJ3QgdXNlZCBhdCBhbGwgaW4gdGhpcyBtZXRob2Qu IElNSE8sIG1heWJlIGl0IHdvdWxkIGJlIGJldHRlciB0byBzcGVjaWZ5IHRoYXQgbWV0aG9kIGlu IHRoZSBFLVZQTiBkcmFmdCBvciBtb3JlIGFjY3VyYXRlbHkgaW4gYSBzZXBhcmF0ZSBkcmFmdCB0 aXRsZWQgbGlrZSBUUklMTC1WUE4uDQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0K From lufang@cisco.com Thu May 10 19:05: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 3727711E8073 for ; Thu, 10 May 2012 19:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.419 X-Spam-Level: X-Spam-Status: No, score=-10.419 tagged_above=-999 required=5 tests=[AWL=0.180, 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 2nyQk9Es4FBV for ; Thu, 10 May 2012 19:05:04 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id C65C811E8072 for ; Thu, 10 May 2012 19:05:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=1528; q=dns/txt; s=iport; t=1336701904; x=1337911504; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=wi2APJ4v5eWxo5DbPYuZ3nMD69Of98KF25RTZTGw7UI=; b=LfOun8soz2E0QPq4ihUwXk951UKXsQO7Ees98WrJN0ICvtGe6Sahq3KU XmtdxaY9Gd11tvZeB0Zs2iKpKhQZeeIPVtIwtcMNZgKVYgSSaH62vgZU1 vYQI8JmPUH7kiGDSGapj62ytZljYRc2NjzKRNGgaaBm69xS0O/Ihxa81r s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANRyrE+tJV2a/2dsb2JhbABEtCGBB4IVAQEBAwESAR0KPwULAgEIGAoGGAYBIDYBAQQBEggTB4deAwYFC5sdlksNiVOKKYYoYwSIZI4qiiyDGoFpgwc X-IronPort-AV: E=Sophos;i="4.75,567,1330905600"; d="scan'208";a="82279127" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 11 May 2012 02:05:03 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q4B253B5026732; Fri, 11 May 2012 02:05:03 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 May 2012 21:05:03 -0500 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: PBB E-VPN and TRILL Date: Thu, 10 May 2012 21:04:57 -0500 Message-ID: <238542D917511A45B6B8AA806E875E2508A8A5E2@XMB-RCD-201.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PBB E-VPN and TRILL Thread-Index: Ac0t4AvyMdWKxMA3AUSUMcn62xbEYQBL0ahVAALCl1A= References: From: "Luyuan Fang (lufang)" To: "Giles Heron" , X-OriginalArrivalTime: 11 May 2012 02:05:03.0000 (UTC) FILETIME=[7A3BB180:01CD2F1A] Cc: "Ali Sajassi \(sajassi\)" , "Stewart Bryant \(stbryant\)" 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, 11 May 2012 02:05:05 -0000 Yes to all three. Luyuan > On 12-05-09 5:34 AM, "Giles Heron" wrote: >=20 > > Ali presented the PBB-EVPN draft at IETF83 in Paris: > > > > http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-01 > > > > This has since been updated: > > > > http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-02 > > > > During our discussions Ali mentioned that the authors would like the > TRILL > > section of the draft to be separated out into a separate draft. In > response > > Stewart questioned whether interconnecting TRILL islands is in-scope > for > > L2VPN. > > > > Stewart, Nabil and I have just been discussing these issues. Whilst > TRILL > > interconnect is not explicitly in-charter for L2VPN it would appear > to be > > implicitly in-charter - our decision to standardise solutions for PBB > VPLS > > and PBB E-VPN probably sets a precedent (since PBB is also > unmentioned by > > the charter). > > > > On this basis we would like to ask the WG the following three > questions: > > > > 1) is the WG happy for us to pursue interconnection of TRILL islands > over > > L2VPN? > > > > 2) is the WG happy for the authors to split the TRILL section of the > PBB > > E-VPN draft into a separate draft? > > > > 3) is the WG happy for the TRILL draft to be a WG doc? > > > > Please respond by May 22nd if you are unhappy with any of these 3 > actions > > (I'll take no response to mean the WG is in agreement with us > proceeding...) > > > > Giles > > > > From jiangyuanlong@huawei.com Thu May 10 19:05: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 22B9F11E8079 for ; Thu, 10 May 2012 19:05:52 -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.168, 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 FGQagsbAt4ol for ; Thu, 10 May 2012 19:05:51 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4861611E8072 for ; Thu, 10 May 2012 19:05: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 AGB00282; Thu, 10 May 2012 22:05:51 -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; Thu, 10 May 2012 19:03:09 -0700 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 10 May 2012 19:03:15 -0700 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.183]) by szxeml411-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Fri, 11 May 2012 10:03:11 +0800 From: Jiangyuanlong To: Daniel Cohn , Alexander Vainshtein , Sam Cao Subject: RE: Discussion on E-Tree and H-VPLS Thread-Topic: Discussion on E-Tree and H-VPLS Thread-Index: AQHNLxo31u2OjZw96UuBF9QPOwJXgw== Date: Fri, 11 May 2012 02:03:10 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D411694@szxeml546-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.70.40.73] 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: Fri, 11 May 2012 02:05:52 -0000 Hi Daniel and all, When you set up two PWs from the PE-rs to a PE-r for each of its AC, do you= mean that one PW is bidirectional root PW and the other is bidirectional l= eaf PW? My concern is: where should the leaf traffic be filtered, on the PE-rs or o= n the PE-r? If filtered on the PE-r, then lots of bandwidth will be wasted (for example= , if the PE-r is attached with 9 leafs, then the BUM traffic from one of it= s leafs will be multiplied by 8 times, and be forwarded by the PE-rs to the= same PE-r). If filtered on the PE-rs, not sure how you will design its forwarding plane= , can you give a hint? Thanks, Yuanlong ------------------------------ Date: Wed, 9 May 2012 09:16:36 +0300 From: "Daniel Cohn" To: "Alexander Vainshtein" , "Sam Cao" , Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780CBA6@tlvmail1> Content-Type: text/plain; charset=3D"ISO-2022-JP" Hi Sasha, It's actually very simple. A frame that originated in a root AC is always t= ransmitted only in root PW, no matter what the frame type (known/unknown un= icast or broadcast). This is how the frame source information is propagated= across the VPLS. So in the H-VPLS example, the PE-r will never forward a f= rame received over a root PW on any leaf PW, only on root PWs (toward the c= ore or toward other spokes). Hope this clarifies it, regards, Daniel -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of A= lexander Vainshtein Sent: Wednesday, May 09, 2012 7:59 AM To: Sam Cao; l2vpn@ietf.org Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Sam, Lizhong and all, You've written that in the two-PW solution combined with H-VPLS the PE-r mu= st set up two PWs with each MTU-s. If this is the case, what kind of forwarding logic should be used to preven= t sending a BUM frame received from a root-PW to a given MTU-S: - back to the same MTU-S on the corresponding leaf-PW? - twice (to both root-PW and Leaf-PW) to another MTU-s? And, BTW, how is th= e PW selected in this case? I am aware of a technique of multiple split horizon groups in PE-r which co= uld be possibly used for this purpose. However, since these groups have to = be represented explicitly in the data plane, their potential number is limi= ted by the forwarding HW. Other methods could be probably used for the same= purpose, but they would probably subject to similar HW-based limitations. I suspect that with the dual-PW approach, the HW would pose an implicit lim= it, say, on a number of MTU-s that can be connected to the same PE-r and th= at this limit could be quite low in most cases. Based on this I suspect that the H-VPLS issue as a critical drawback of the= dual-PW approach to E-Tree. My 2c, Sasha ________________________________________ From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Sam Cao = [yuqun.cao@gmail.com] Sent: Wednesday, May 09, 2012 3:40 AM To: l2vpn@ietf.org Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Hi Lizhong? Thank you very much for your comments. I updated the result on this questio= n. [Lizhong] agree with the above analysis. And we did not say it is a technic= al problem, but it is an operational problem again. [Sam] I agree. Dual-VLAN does not make sense. I also discussed this with Gi= les and Yuanlong in another mail, and we reached agreement on this: MTU sho= uld know the access mode, VPWS or VPLS, VPWS mode should configure VLAN ID = on MTU but VPLS mode can not. I thought this is NOT reasonable :), but we c= an figure this out in draft. It seems ok. [Lizhong] not fully understand. Do you mean, when VPWS accessing for H-VPL= S, the PE-r is also necessary to configure two PWs (root and leaf PW) for e= ach AC access? [Sam] Yes. Thanks, Sam =20 From xuxiaohu@huawei.com Thu May 10 19:10: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 D95A611E8073 for ; Thu, 10 May 2012 19:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.419 X-Spam-Level: * X-Spam-Status: No, score=1.419 tagged_above=-999 required=5 tests=[AWL=-0.524, 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 HraWHbGanEX6 for ; Thu, 10 May 2012 19:10:38 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id BBC9111E8072 for ; Thu, 10 May 2012 19:10:37 -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 AGB00595; Thu, 10 May 2012 22:10:33 -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; Thu, 10 May 2012 19:08:13 -0700 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 10 May 2012 19:08:10 -0700 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.182]) by szxeml405-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Fri, 11 May 2012 10:08:07 +0800 From: Xuxiaohu To: Ali Sajassi , Sam Aldrin , "Shah, Himanshu" Subject: re: PBB E-VPN and TRILL Thread-Topic: PBB E-VPN and TRILL Thread-Index: Ac0t4AvyMdWKxMA3AUSUMcn62xbEYQA6XpwgAAAL5rAAAAZYEAAAq7mvAABE8iAAAS6xNQAAEcqwAADHxHEAABYqEP//fsiAgAAYqwD//w8x0A== Date: Fri, 11 May 2012 02:08:07 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02F21525@szxeml525-mbs.china.huawei.com> References: <909C073D-3F16-4B2E-A772-E250E1914777@gmail.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="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l2vpn@ietf.org" , "Stewart Bryant \(stbryant\)" 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, 11 May 2012 02:10:39 -0000 DQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6IGwydnBuLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnXSC0+rHtIEFsaQ0KPiBTYWphc3NpDQo+ILei y83KsbzkOiAyMDEyxOo11MIxMcjVIDM6NDENCj4gytW8/sjLOiBTYW0gQWxkcmluOyBTaGFoLCBI aW1hbnNodQ0KPiCzrcvNOiBsMnZwbkBpZXRmLm9yZzsgU3Rld2FydCBCcnlhbnQgKHN0YnJ5YW50 KQ0KPiDW98ziOiBSZTogUEJCIEUtVlBOIGFuZCBUUklMTA0KPiANCj4gDQo+IFdoZW4gdGhlIGRv YyB3YXMgYWRvcHRlZCBhcyBXRyBkcmFmdCBvdmVyIDE0IG1vbnRocyBhZ28sIEJHUCByb3V0ZQ0K PiBkZWZpbml0aW9uIGFuZCBwcm9jZWR1cmVzIGZvciBUUklMTCBEQ0kgd2VyZSBhbHJlYWR5IGlu IHBsYWNlLg0KDQpNYXliZSBzZWxkb20gcGVvcGxlIGhhdmUgcGFpZCBhdHRlbnRpb25zIHRvIHRo YXQgcGFydCBhdCB0aGF0IHRpbWU6KSANCg0KTm93IHRoaXMgcXVlc3Rpb24gaGFzIGJlZW4gcmFp c2VkIGJ5IHRoZSBjby1jaGFpcnMgYW5kIGhhcyBvYnRhaW5lZCBtb3JlIGF0dGVudGlvbnMsIHdo ZXRoZXIgb3Igbm90IHRoaXMgdG8tYmUtc2VwYXJhdGVkIHBhcnQgYmVsb25ncyB0byBMMlZQTiBz aG91bGQgYmUgZXZhbHVhdGVkIHNlcmlvdXNseSBhdCB0aGlzIHRpbWUgSU1ITy4NCg0KWGlhb2h1 DQoNCj4gSXQgc2VlbXMgbGlrZSB3ZSBhcmUgaGF2aW5nIGFsbCB0aGVzZSBlbWFpbCBleGNoYW5n ZXMgZm9yIGEgbmFtZSBjaGFuZ2Ugb2YgYQ0KPiBXRyBkb2MgISENCj4gDQo+IC1BbGkNCj4gDQo+ IE9uIDUvMTAvMTIgMTE6MTIgQU0sICJTYW0gQWxkcmluIiA8YWxkcmluLmlldGZAZ21haWwuY29t PiB3cm90ZToNCj4gDQo+ID4gQXMgSSBtZW50aW9uZWQgaW4gbXkgb3RoZXIgZW1haWwsIHRoZSBz cGxpdCBkb2N1bWVudCBzaG91bGQgYmUgYXNrZWQgZm9yIFdHDQo+ID4gYWRvcHRpb24uIEl0IG1h eSBub3QgYmUgZm9yIHBiYiBjb250ZW50IGJ1dCBmb3IgdGhlIFRSSUxMIGNvbnRlbnQgaXQgc2hv dWxkIGJlDQo+ID4gZG9uZS4gV2hlbiB0aGUgZG9jIHdhcyBhZG9wdGVkIGFzIFdHIGRvYywgdHJp bGwgY29udGVudCB3YXMgbWluaW1hbC4NCj4gPg0KPiA+IFNhbQ0KPiA+DQo+ID4gU2VudCBmcm9t IG15IGlQaG9uZQ0KPiA+DQo+ID4gT24gTWF5IDEwLCAyMDEyLCBhdCAxMDo1OSBBTSwgIlNoYWgs IEhpbWFuc2h1IiA8aHNoYWhAY2llbmEuY29tPiB3cm90ZToNCj4gPg0KPiA+PiBGb2xsb3dpbmdz IGFyZSB0aGUgcXVlc3Rpb25zLi4uDQo+ID4+DQo+ID4+IDIpIGlzIHRoZSBXRyBoYXBweSBmb3Ig dGhlIGF1dGhvcnMgdG8gc3BsaXQgdGhlIFRSSUxMIHNlY3Rpb24gb2YgdGhlIFBCQg0KPiA+PiBF LVZQTiBkcmFmdCBpbnRvIGEgc2VwYXJhdGUgZHJhZnQ/DQo+ID4+DQo+ID4+IDMpIGlzIHRoZSBX RyBoYXBweSBmb3IgdGhlIFRSSUxMIGRyYWZ0IHRvIGJlIGEgV0cgZG9jPw0KPiA+Pg0KPiA+PiBJ IHRoaW5rIHdlIGFyZSBkaXNjdXNzaW5nIHNwbGl0dGluZyB0aGUgdHJpbGwgc2VjdGlvbiBhcyBh IHNlcGFyYXRlIGRyYWZ0IGFuZA0KPiA+PiBtYWtpbmcgaXQgYSBXRyBkb2MuDQo+ID4+DQo+ID4+ IFdoYXQgYW0gSSBtaXNzaW5nPw0KPiA+Pg0KPiA+PiAvaGltYW5zaHUNCj4gPj4NCj4gPj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogQWxpIFNhamFzc2kgW21haWx0bzpz YWphc3NpQGNpc2NvLmNvbV0NCj4gPj4gU2VudDogVGh1cnNkYXksIE1heSAxMCwgMjAxMiAxOjUz IFBNDQo+ID4+IFRvOiBTaGFoLCBIaW1hbnNodTsgSGVuZGVyaWNreCwgV2ltIChXaW0pOyBTYW50 aWFnbyBBbHZhcmV6IChzYWFsdmFyZSk7DQo+IEdpbGVzDQo+ID4+IEhlcm9uOyBsMnZwbkBpZXRm Lm9yZw0KPiA+PiBDYzogU3Rld2FydCBCcnlhbnQgKHN0YnJ5YW50KQ0KPiA+PiBTdWJqZWN0OiBS ZTogUEJCIEUtVlBOIGFuZCBUUklMTA0KPiA+Pg0KPiA+Pg0KPiA+Pj4NCj4gPj4+IEJhc2VkIG9u IG15IHVuZGVyc3RhbmRpbmcsIGFsbCB0aGUgcHJvcG9zYWxzIGFyZSBjb25zaWRlcmVkIEJFRk9S RQ0KPiA+Pj4gb25lIGlzIHBpY2tlZCAod2l0aCBvciB3aXRob3V0IGNvbnNvbGlkYXRpb24pIGZv ciBXRyBkb2MuDQo+ID4+DQo+ID4+IE9uZSBwcm9wb3NhbCBpcyBhbHJlYWR5IHBhcnQgb2YgV0cg ZHJhZnQuIFdvdWxkIHlvdSBwbGVhc2UgcmVhZCB0aGUgZHJhZnQNCj4gPj4gYW5kIHRoZW4gY29t bWVudC4NCj4gPj4NCj4gPj4gQ2hlZXJzLA0KPiA+PiBBbGkNCj4gPj4NCj4gPj4+DQo+ID4+PiBU aGFua3MsDQo+ID4+PiBoaW1hbnNodQ0KPiA+Pj4NCj4gPj4+DQo+ID4+PiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiA+Pj4gRnJvbTogQWxpIFNhamFzc2kgW21haWx0bzpzYWphc3NpQGNp c2NvLmNvbV0NCj4gPj4+IFNlbnQ6IFRodXJzZGF5LCBNYXkgMTAsIDIwMTIgMToyOCBQTQ0KPiA+ Pj4gVG86IFNoYWgsIEhpbWFuc2h1OyBIZW5kZXJpY2t4LCBXaW0gKFdpbSk7IFNhbnRpYWdvIEFs dmFyZXogKHNhYWx2YXJlKTsNCj4gPj4+IEdpbGVzDQo+ID4+PiBIZXJvbjsgbDJ2cG5AaWV0Zi5v cmcNCj4gPj4+IENjOiBTdGV3YXJ0IEJyeWFudCAoc3RicnlhbnQpDQo+ID4+PiBTdWJqZWN0OiBS ZTogUEJCIEUtVlBOIGFuZCBUUklMTA0KPiA+Pj4NCj4gPj4+IEhpIEhpbWFuc2h1LA0KPiA+Pj4N Cj4gPj4+IEkgdGhpbmsgZXZlcnkgZHJhZnQgc2hvdWxkIGJlIGV2YWx1YXRlZCBiYXNlZCBvbiBp dHMgb3duIG1lcml0cyBhbmQgaWYgaXQgaXMNCj4gPj4+IHdhcnJhbnRlZCB0aGVyZSBjYW4gYmUg c2V2ZXJhbCBkcmFmdHMgb24gdGhpcyBzcGFjZS4NCj4gPj4+DQo+ID4+PiBDaGVlcnMsDQo+ID4+ PiBBbGkNCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gT24gNS8xMC8xMiAxMDowMyBBTSwgIlNoYWgsIEhp bWFuc2h1IiA8aHNoYWhAY2llbmEuY29tPiB3cm90ZToNCj4gPj4+DQo+ID4+Pj4gSGkgQWxpIC0N Cj4gPj4+Pg0KPiA+Pj4+IENvcnJlY3QuDQo+ID4+Pj4NCj4gPj4+PiBCdXQgd2l0aGluIHRoZSBj b250ZXh0IG9mIHByZXZpb3VzIHR3bywgd2hpY2ggcXVlc3Rpb25zIHdoZXRoZXIgdG8NCj4gPj4+ PiBjb25zaWRlciBpbnRlcmNvbm5lY3RpbmcgVFJJTEwgaXNsYW5kcyB2aWEgTDJWUE4gYXMgcGFy dCBvZiBXRyBjaGFydGVyLCBJDQo+ID4+Pj4gdGhpbmsgeW91DQo+ID4+Pj4gd291bGQgYWdyZWUg dGhhdCBvbmNlIFRSSUxMIHBvcnRpb24gaXMgc3BsaXQgZnJvbSB5b3VyIGJhc2UgZG9jdW1lbnQs DQo+ID4+Pj4gaXQgbWlnaHQgYmUgd29ydGggdG8gY2hlY2sgaWYgb3RoZXIgcHJvcG9zYWxzIGhh cyBtZXJpdHMuDQo+ID4+Pj4NCj4gPj4+PiBTYXlpbmcgZGlmZmVyZW50bHksIGlmIHlvdXIgc3Bs aXQgVFJJTEwgZG9jIGJlY29tZXMgV0cgZG9jIGF0IHRoZSBzYW1lIHRpbWUNCj4gPj4+PiB3ZQ0K PiA+Pj4+IGluY2x1ZGUgdGhpcyB3b3JrIGluIHRoZSBjaGFydGVyLCBvdGhlciBwcm9wb3NhbHMg d291bGQgaGF2ZSBubyBjaGFuY2UgdG8NCj4gPj4+PiBiZQ0KPiA+Pj4+IGV2ZW4gY29uc2lkZXJl ZC4uOi0oDQo+ID4+Pj4NCj4gPj4+PiBJTUhPIC0gaGltYW5zaHUNCj4gPj4+Pg0KPiA+Pj4+DQo+ ID4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+PiBGcm9tOiBBbGkgU2FqYXNz aSBbbWFpbHRvOnNhamFzc2lAY2lzY28uY29tXQ0KPiA+Pj4+IFNlbnQ6IFRodXJzZGF5LCBNYXkg MTAsIDIwMTIgMTI6NDcgUE0NCj4gPj4+PiBUbzogU2hhaCwgSGltYW5zaHU7IEhlbmRlcmlja3gs IFdpbSAoV2ltKTsgU2FudGlhZ28gQWx2YXJleiAoc2FhbHZhcmUpOw0KPiA+Pj4+IEdpbGVzDQo+ ID4+Pj4gSGVyb247IGwydnBuQGlldGYub3JnDQo+ID4+Pj4gQ2M6IFN0ZXdhcnQgQnJ5YW50IChz dGJyeWFudCkNCj4gPj4+PiBTdWJqZWN0OiBSZTogUEJCIEUtVlBOIGFuZCBUUklMTA0KPiA+Pj4+ DQo+ID4+Pj4gSGltYW5zaHUsDQo+ID4+Pj4NCj4gPj4+PiBQQkItRVZQTiBpcyBhbHJlYWR5IGEg V0cgZHJhZnQhIEFuZCB0aGUgVFJJTEwgcG9ydGlvbiBvZiBpdCBoYXMgYmVlbg0KPiA+Pj4+IHBy ZXNlbnRlZCB0byBMMlZQTiBXRyBhbmQgaGFzIGJlZW4gaW4gZGlzY3Vzc2lvbnMgZm9yIHF1aXRl IHNvbWUgdGltZS4NCj4gQWxsDQo+ID4+Pj4gd2UgYXJlIGRvaW5nIGlzIHNlcGFyYXRpbmcgU1BC L1BCQiBmcm9tIFRSSUxMIC0gbm90aGluZyBuZXcgaXMgZ2V0dGluZw0KPiA+Pj4+IGFkZGVkLiBX aGVyZWFzLCB0aGUgb3RoZXIgZHJhZnRzIGFyZSBhbGwgbmV3IGFuZCB0aGV5IGNhbWUgYWJvdXQg ZHVyaW5nDQo+ID4+Pj4gbGFzdA0KPiA+Pj4+IElFVEYgbWVldGluZy4NCj4gPj4+Pg0KPiA+Pj4+ IC1BbGkNCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4gT24gNS8xMC8xMiA5OjM4IEFNLCAiU2hhaCwg SGltYW5zaHUiIDxoc2hhaEBjaWVuYS5jb20+IHdyb3RlOg0KPiA+Pj4+DQo+ID4+Pj4+IFllcyB0 byBmaXJzdCAyLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBBcyBmb3IgM3JkLCBiZWZvcmUgd2UgaW5kdWN0 IHRoZSBzdGF0ZWQgZHJhZnQgYXMgV0cgZG9jLCB3ZSBzaG91bGQNCj4gPj4+Pj4gY29uc2lkZXIN Cj4gPj4+Pj4gb3RoZXIgdHdvIHByb3Bvc2Fscw0KPiA+Pj4+PiBtZW50aW9uZWQgaW4gdGhlIG1h aWxpbmcgbGlzdCwgYXMgcGFydCBvZiBkdWUgZGlsaWdlbmNlLiBUaGlzIGlzIHRoZSBvbmx5DQo+ ID4+Pj4+IGZhaXINCj4gPj4+Pj4gd2F5LCBhbmQgaW4gZmFjdCwNCj4gPj4+Pj4gY29uc2lkZXJh dGlvbiB0byByZXNwb25zZXMgdG8gdGhpcmQgcXVlc3Rpb24gYmUgcG9zdHBvbmVkIHVudGlsIG90 aGVyDQo+ID4+Pj4+IHByb3Bvc2FscyBoYXZlIGJlZW4gZ2l2ZW4NCj4gPj4+Pj4gY2hhbmNlIHRv IGJlIHJldmlld2VkIGF0IHRoZSBXRywgSU1PLg0KPiA+Pj4+Pg0KPiA+Pj4+PiAvaGltYW5zaHUN Cj4gPj4+Pj4NCj4gPj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+Pj4gRnJv bTogbDJ2cG4tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZg0KPiBPZg0KPiA+Pj4+PiBIZW5kZXJpY2t4LCBXaW0gKFdpbSkNCj4gPj4+Pj4g U2VudDogVGh1cnNkYXksIE1heSAxMCwgMjAxMiAxMjoyNyBQTQ0KPiA+Pj4+PiBUbzogU2FudGlh Z28gQWx2YXJleiAoc2FhbHZhcmUpOyBHaWxlcyBIZXJvbjsgbDJ2cG5AaWV0Zi5vcmcNCj4gPj4+ Pj4gQ2M6IEFsaSBTYWphc3NpIChzYWphc3NpKTsgU3Rld2FydCBCcnlhbnQgKHN0YnJ5YW50KQ0K PiA+Pj4+PiBTdWJqZWN0OiBSRTogUEJCIEUtVlBOIGFuZCBUUklMTA0KPiA+Pj4+Pg0KPiA+Pj4+ PiBTYW1lLCB5ZXMgdG8gYWxsIDMNCj4gPj4+Pj4NCj4gPj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gPj4+Pj4gRnJvbTogbDJ2cG4tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwy dnBuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPiBPZg0KPiA+Pj4+PiBTYW50aWFnbyBB bHZhcmV6IChzYWFsdmFyZSkNCj4gPj4+Pj4gU2VudDogZG9uZGVyZGFnIDEwIG1laSAyMDEyIDE4 OjI2DQo+ID4+Pj4+IFRvOiBHaWxlcyBIZXJvbjsgbDJ2cG5AaWV0Zi5vcmcNCj4gPj4+Pj4gQ2M6 IEFsaSBTYWphc3NpIChzYWphc3NpKTsgU3Rld2FydCBCcnlhbnQgKHN0YnJ5YW50KQ0KPiA+Pj4+ PiBTdWJqZWN0OiBSRTogUEJCIEUtVlBOIGFuZCBUUklMTA0KPiA+Pj4+Pg0KPiA+Pj4+PiBZZXMg dG8gYWxsIHRocmVlLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBTQQ0KPiA+Pj4+PiAtLQ0KPiA+Pj4+Pg0K PiA+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+Pj4+IEZyb206IGwydnBu LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiBC ZWhhbGYNCj4gPj4+Pj4gT2YNCj4gPj4+Pj4+IEdpbGVzIEhlcm9uDQo+ID4+Pj4+PiBTZW50OiBX ZWRuZXNkYXksIE1heSAwOSwgMjAxMiA1OjM0IEFNDQo+ID4+Pj4+PiBUbzogbDJ2cG5AaWV0Zi5v cmcNCj4gPj4+Pj4+IENjOiBBbGkgU2FqYXNzaSAoc2FqYXNzaSk7IFN0ZXdhcnQgQnJ5YW50IChz dGJyeWFudCkNCj4gPj4+Pj4+IFN1YmplY3Q6IFBCQiBFLVZQTiBhbmQgVFJJTEwNCj4gPj4+Pj4+ DQo+ID4+Pj4+PiBBbGkgcHJlc2VudGVkIHRoZSBQQkItRVZQTiBkcmFmdCBhdCBJRVRGODMgaW4g UGFyaXM6DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1sMnZwbi1wYmItZXZwbi0wMQ0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IFRoaXMgaGFzIHNp bmNlIGJlZW4gdXBkYXRlZDoNCj4gPj4+Pj4+DQo+ID4+Pj4+PiBodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLWwydnBuLXBiYi1ldnBuLTAyDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4g RHVyaW5nIG91ciBkaXNjdXNzaW9ucyBBbGkgbWVudGlvbmVkIHRoYXQgdGhlIGF1dGhvcnMgd291 bGQgbGlrZSB0aGUNCj4gPj4+Pj4gVFJJTEwNCj4gPj4+Pj4+IHNlY3Rpb24gb2YgdGhlIGRyYWZ0 IHRvIGJlIHNlcGFyYXRlZCBvdXQgaW50byBhIHNlcGFyYXRlIGRyYWZ0LiAgSW4NCj4gPj4+Pj4g cmVzcG9uc2UNCj4gPj4+Pj4+IFN0ZXdhcnQgcXVlc3Rpb25lZCB3aGV0aGVyIGludGVyY29ubmVj dGluZyBUUklMTCBpc2xhbmRzIGlzIGluLXNjb3BlDQo+ID4+Pj4+IGZvcg0KPiA+Pj4+Pj4gTDJW UE4uDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gU3Rld2FydCwgTmFiaWwgYW5kIEkgaGF2ZSBqdXN0IGJl ZW4gZGlzY3Vzc2luZyB0aGVzZSBpc3N1ZXMuICBXaGlsc3QNCj4gPj4+Pj4gVFJJTEwNCj4gPj4+ Pj4+IGludGVyY29ubmVjdCBpcyBub3QgZXhwbGljaXRseSBpbi1jaGFydGVyIGZvciBMMlZQTiBp dCB3b3VsZCBhcHBlYXIgdG8NCj4gPj4+Pj4gYmUNCj4gPj4+Pj4+IGltcGxpY2l0bHkgaW4tY2hh cnRlciAtIG91ciBkZWNpc2lvbiB0byBzdGFuZGFyZGlzZSBzb2x1dGlvbnMgZm9yIFBCQg0KPiA+ Pj4+PiBWUExTDQo+ID4+Pj4+PiBhbmQgUEJCIEUtVlBOIHByb2JhYmx5IHNldHMgYSBwcmVjZWRl bnQgKHNpbmNlIFBCQiBpcyBhbHNvDQo+IHVubWVudGlvbmVkDQo+ID4+Pj4+IGJ5DQo+ID4+Pj4+ PiB0aGUgY2hhcnRlcikuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gT24gdGhpcyBiYXNpcyB3ZSB3b3Vs ZCBsaWtlIHRvIGFzayB0aGUgV0cgdGhlIGZvbGxvd2luZyB0aHJlZQ0KPiA+Pj4+PiBxdWVzdGlv bnM6DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gMSkgaXMgdGhlIFdHIGhhcHB5IGZvciB1cyB0byBwdXJz dWUgaW50ZXJjb25uZWN0aW9uIG9mIFRSSUxMIGlzbGFuZHMNCj4gPj4+Pj4gb3Zlcg0KPiA+Pj4+ Pj4gTDJWUE4/DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gMikgaXMgdGhlIFdHIGhhcHB5IGZvciB0aGUg YXV0aG9ycyB0byBzcGxpdCB0aGUgVFJJTEwgc2VjdGlvbiBvZiB0aGUNCj4gPj4+Pj4gUEJCIEUt DQo+ID4+Pj4+PiBWUE4gZHJhZnQgaW50byBhIHNlcGFyYXRlIGRyYWZ0Pw0KPiA+Pj4+Pj4NCj4g Pj4+Pj4+IDMpIGlzIHRoZSBXRyBoYXBweSBmb3IgdGhlIFRSSUxMIGRyYWZ0IHRvIGJlIGEgV0cg ZG9jPw0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IFBsZWFzZSByZXNwb25kIGJ5IE1heSAyMm5kIGlmIHlv dSBhcmUgdW5oYXBweSB3aXRoIGFueSBvZiB0aGVzZSAzDQo+ID4+Pj4+IGFjdGlvbnMNCj4gPj4+ Pj4+IChJJ2xsIHRha2Ugbm8gcmVzcG9uc2UgdG8gbWVhbiB0aGUgV0cgaXMgaW4gYWdyZWVtZW50 IHdpdGggdXMNCj4gPj4+Pj4gcHJvY2VlZGluZy4uLikNCj4gPj4+Pj4+DQo+ID4+Pj4+PiBHaWxl cw0KPiA+Pj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pg0KPiA+Pj4NCj4gPj4NCg0K From Alexander.Vainshtein@ecitele.com Thu May 10 22:11: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 3E1E021F8600 for ; Thu, 10 May 2012 22:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.573 X-Spam-Level: X-Spam-Status: No, score=-4.573 tagged_above=-999 required=5 tests=[AWL=0.629, 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 wQF6xkNAf2Lv for ; Thu, 10 May 2012 22:11:36 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.34]) by ietfa.amsl.com (Postfix) with ESMTP id 87B9E21F8609 for ; Thu, 10 May 2012 22:11:35 -0700 (PDT) Received: from [85.158.138.51:34501] by server-4.bemta-3.messagelabs.com id 05/3A-15341-68F9CAF4; Fri, 11 May 2012 05:11:34 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-14.tower-174.messagelabs.com!1336713093!20131571!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.5.7; banners=-,-,- Received: (qmail 4379 invoked from network); 11 May 2012 05:11:33 -0000 Received: from unknown (HELO fridlppsb001.ecitele.com) (168.87.1.157) by server-14.tower-174.messagelabs.com with SMTP; 11 May 2012 05:11:33 -0000 X-AuditID: a8571401-b7f8d6d0000035b0-d0-4faca0100260 Received: from FRIDWPPCH001.ecitele.com (fridwppch001.ecitele.com [10.1.16.52]) by fridlppsb001.ecitele.com (Symantec Messaging Gateway) with SMTP id 4E.D3.13744.010ACAF4; Fri, 11 May 2012 07:13:52 +0200 (CEST) Received: from FRIDWPPMB001.ecitele.com ([169.254.3.187]) by FRIDWPPCH001.ecitele.com ([10.1.16.52]) with mapi id 14.01.0339.001; Fri, 11 May 2012 07:11:32 +0200 From: Alexander Vainshtein To: Sami Boutros Subject: RE: Static VPLS MAC withdrawal draft Thread-Topic: Static VPLS MAC withdrawal draft Thread-Index: Ac0tTYm5TIv9pECE0EWc8IlBO2eaCQBZSqlwAAD+M1D///XxgP//nZowgAEGcYD//6hqsA== Date: Fri, 11 May 2012 05:11:31 +0000 Message-ID: References: <32B4F6D6-CB5A-4DE9-8A14-B04B175BC30E@cisco.com> <78CE5EBC-3B62-4783-8F32-12B8C654F4CF@cisco.com> In-Reply-To: <78CE5EBC-3B62-4783-8F32-12B8C654F4CF@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.35.6] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2VTa0hTURz33LvNu+Wt2zbbaWmNSxFkm5MeTHAW1QejYpFREIHdbaft0nZ3 2Z2ifVrfypLeD5fPtLKUTOuDvWlllmAWRKSgldrLMiqjB0J0DjMzup9+9/xe53/uuQyt/6wx M6IUQWFJCPAanUoHksxWrqbJZW+rneN41X4COAa/xZMdjwY6aEf/yA/Kce/IF7BcnXdkrEWd dyXWl5xXX/+TWk9viYIcQZJCESGCLF6keJz8+rBYJHhKeIvodfJZvEUOCB4URFLEyQuyjCQv n6uz/PfkYJkoWZDkCXlFyefkV+e7rA7HkmxrFp+70S8qFmQNCmLAEkSKIviQBa+QCSTvtgu0 /+Nhtzy6rrjiZpUmCoZySoGWgdxi+LjsA53AM+Cj/mZNKdAxeu4JgHVfuwAh9NxpAONXjQRr OCdsbezTEGzk5sGXY9WAGGiuAsCOvb3JhDBwVti9v2dcZINj7cewiMF4E7z1hiPLKuzta3mo Ipjl1sGqutLx4hoKDj78QRO9FpcNtemIBuDNfe9sogimORPsHaqmEpvmYP317vEBUuG7wV/q BE6Hh++WJSf0C2HNtS+aBM6AZ2rf04ne6fBB+ZAqoZ8Jbzc8Ux0Aptikitgke2ySPTbJXgNU 54Fpe1j0yrLittuzbMgjRlAA2TyhYCvAF6dhsxG0gYEyWxxwDOBTWGak0aVXC0VKSTAOZjIU n8rqKptc+qnukLfELyj+gnBhAClxABmaN7LFyzDHeoWSnSgc+kM58BkepM1TPCHygSMFi+z2 f154E9u8Idel53z41u1ASEbhP9Y0huEh21KFU6eHkQ8VbxcDkb80xWhJcwpulomGVWQhqIi+ BN8J5jGDN848BXqVFJKQ2cTeJSKOiPyF0kTOMDDhWQ3sVcKm4Fs4kTCMwykcfuzOORKO/4oJ yhwFsy6PxvK31hn7x4qydx23iZeoQ/ver90wO2ngudZvv1jYUJde3/3SPXxy31Jt0qzdbv/3 U6OBkWjl/OUrFmV8qjbcN9+Mbrp8tLqRbpy79GxuJ505pet196HHRl9qT0+telp7qNOwoCA7 Kb9j1Z6mlcXZvq9vqRcr0ihfeaYhbU2ph1cpfiFrAR1WhN+rp27wBAQAAA== Cc: "l2vpn@ietf.org" , "msiva@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, 11 May 2012 05:11:37 -0000 Sami, Lots of thanks for prompt responses. My general gut feeling is that the draft tries to compensate for lack of rel= iable delivery provided by TCP in the case of signaled PWs between the VPLS= peers, but leaves aside some other issues that stem from the static nature= of the PWs. These include at least the following: - Synchronized setup of the PW endpoints. Life would be simpler if the two= endpoints could guarantee that they have both come up and both deal with th= e same values of Rx and Tx sequence numbers (cross-matched). - Synchronized reset for the sequence numbers: consider the case when one of= the PEs undergoes restart in the middle of operation and starts with a new= pair of Rx and Tx numbers while its peers remain unaware of the fact. - Ordered (in addition to reliable) delivery of messages: consider the case= with two messages following each other (from my original example), but the= first one being lost. The 2nd one (including all MAC addresses from the 1st= one) is delivered and ACKed, then the 1st one is retransmitted and delivere= d... One thing that the draft does not mention is management of the list of MAC a= ddresses that should be withdrawn but have not be ACKed for withdrawal (an a= nalog o the TCP socket Tx buffer). Such a list is required per PW, and it wo= uld be nice to understand how it behaves. I must admit that I do not have a better scheme in mind at the moment (that= is, if you do not count using TCP as a valid better scheme :-). But using some non-TCP mechanism for synchronized, ordered and reliable deli= very (e.g., one used in OSPF?) may be worth consideration. IMHO and FWIW, if your colleagues and you prefer to keep it as simple as pos= sible, the draft should at least describe possible pitfalls and their conseq= uences (say in an Applicability section). Last but not least: I may be exceptionally dumb these days, but could you please clarify which "= half of the sequence number space" do you have in mind, and which modulo do= you use in the "modular arithmetic"? Regards, Sasha > -----Original Message----- > From: Sami Boutros [mailto:sboutros@cisco.com] > Sent: Friday, May 11, 2012 4:22 AM > To: Alexander Vainshtein > Cc: msiva@cisco.com; nmcgill@cisco.com; l2vpn@ietf.org; Giles Heron > Subject: Re: Static VPLS MAC withdrawal draft > > Hi Sasha, > > >> > >> Thanks for your comments, Please see responses inline.. > >> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Alexander Vainshtein > >>>> Sent: Thursday, May 10, 2012 5:08 PM > >>>> To: 'msiva@cisco.com:'; Sami Boutros (sboutros@cisco.com); > >>>> 'nmcgill@cisco.com' > >>>> Cc: l2vpn@ietf.org; 'Giles Heron'; Rotem Cohen; Andrew Sergeev; > >> Mishael > >>>> Wexler; Gideon Agmon > >>>> Subject: RE: Static VPLS MAC withdrawal draft > >>>> > >>>> Hi all, > >>>> I've read the draft in question and I would like to clarify several i= ssues > >> that > >>>> look either undefined or ambiguous to me. > >>>> > >>>> 1. To the best of my understanding, the draft requires each PE > >> participating > >>>> in a given VPLS instance to set up two counters for each static PW > >>>> connecting it to a peer PE device in this VPLS instance: one for stat= ic > MAC > >>>> withdrawal messages it is going to send and another - for static MAC > >>>> withdrawal messages it receives. Is this understanding correct? > >>>> > >> > >> Sami: This is correct. > >> > >>>> 2. Assuming a positive answer to the previous questions, how are > these > >>>> counters initialized? The draft seems to be moot on this point. > >> > >> Sami: This is what the draft has for setting up the sequence # in secti= on 3. > >> Only half of the sequence number space is used. Modular arithmetic > >> is used to detect wrapping of sequence number. When sequence > number > >> wraps (i.e., when it becomes 0), all MAC addresses are flushed and > >> the sequence number is reset. > >> Sami: Can you please explain what's vague in the above? > > [[[Sasha]]] This does not say too much about initialization (at least,= not to > me). > > And it would be nice if the draft was more specific here. > > Sami: Agreed, we need to add the initialization value to the text. > > >> > >>>> The more > >>>> interesting question is, of course, about initialization of the count= er of > >>>> received static MAC withdrawal messages, since, with static PWs, > >> generally > >>>> speaking, there is no synchronization between setting up one of its > end > >>>> points and setting up another one. > >> > >> > >> Sami: Initially the rx sequence # can be assumed to be 0. > > [[[Sasha]]] But you've said that Rx number 0 results in flushing all MAC > addresses? > > Sami: Good point, but this is why the receiving PE should always flush on > receiving 0. > Sami: The Transmitter PE would then increment the sequence # and > subsequent > Sami: Transmission will be higher than 0. > > >> > >>>> > >>>> 3. The draft specifies that: > >>>> - The transmitter sends the MAC withdrawal message with the same > >>>> sequence number until it receives an ACK for it (Section 4.1.1) > >>>> - The receiver, after having acknowledged a MAC withdrawal > >>>> message, ignores refresh messages with the same sequence number > >>>> (Section 4.1.2) > >>>> What is supposed to happen in the following scenario: > >>>> - Transmitter finds out that some MACs have to be withdrawn (e.g., > >>>> because the AC from which they have been learned fails) > >>>> and sends a MAC withdrawal message to its peers with sequence > >>>> number N > >>>> - Immediately after that (i.e., before it receives an ACK for this > >>>> message) it finds out that yet another set of MAC addresses has to be > >>>> withdrawn > >>>> - Retransmission timer expires without ACK received. > >>>> > >> > >> Sami: A new sequence # will be transmitted that will include both sets= of > >> MAC addresses > >> Sami: that need to be flushed, and the transmitter will wait for an ack= for > >> this new sequence #. > >> Sami: We can add this to the draft. > > [[[Sasha]]] First of all, I think something like that MUST be added to t= he > draft. > > And I am not sure what you say is really OK: consider the case when ACK > for the first withdrawal message is received after the 2nd message has bee= n > sent. > > If one of the ACKed (and withdrawn) MAC addresses has been then re- > learned they will be flushed again... > > Sami: Yes, this will lead to deleting again, and then the macs will be lea= rnt > again, keep in mind that we are talking about using a mac list (not an emp= ty > mac list), and deleting 2 sets of macs and we didn't Sami: get the ack for= the > 1st set in time before we ask to delete the 2nd set. I would think this sh= ould > be ok, however am open to better schemes. > > > >> > >>>> 4. Suppose that only one end point of a static PW between a given pai= r > of > >>>> peers has been set up. In this case transmitting the static MAC > >> withdrawal > >>>> messages via such a PW is possible, but ACKs will never be received. > >> Should > >>>> retransmission of these messages go on "ad infinitum"? > >>>> > >> > >> Sami: Yes, this will be the case, the mechanism will be no different th= en > the > >> static PW status one for this case. > > [[[Sasha]]] But ACK is not mandatory in the PW status message 9indeed, i= t > is not clear if it is ever needed). > > Here you may end with multiple retransmitting messages that are sent to > a black hole. > > Sami: Wouldn't that be TRUE too for PW status messages? however is there > a scheme you have in mind to solve this? > > > Thanks, > > Sami > >> > >>>> 5. The draft does not specify any default value for the retransmit ti= me. > >>>> > >> > >> Sami: Sure will add. > >> > >>>> 6. A nit: Heading of Section 4 is followed by headings for Sections= 4.1.1 > >> and > >>>> 4.1.2 without any heading for 4.1. > >>>> > >> > >> Sami: Sure will fix. > >> > >>>> Hopefully these questions will be useful. > >>>> > >> > >> Thanks, > >> > >> Sami > >> > >> > >>>> Regards, > >>>> Sasha > >>>> > >>>>> -----Original Message----- > >>>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > >> Behalf > >>>>> Of Giles Heron > >>>>> Sent: Tuesday, May 08, 2012 10:06 PM > >>>>> To: l2vpn@ietf.org > >>>>> Subject: Static VPLS MAC withdrawal draft > >>>>> > >>>>> Hi everyone, > >>>>> > >>>>> The following draft was presented at IETF in Paris: > >>>>> > >>>>> http://tools.ietf.org/html/draft-boutros-l2vpn-mpls-tp-mac-wd-00 > >>>>> > >>>>> The authors have asked for it to be adopted as a WG draft, but at th= is > >> stage > >>>>> the chairs' view is that it probably hasn't had enough sets of eyes= on > it. > >>>>> > >>>>> So this email is to request that those on the list take a read of th= e > draft > >>>>> and send comments back to the list. Depending on the response we > get > >>>> we > >>>>> may > >>>>> then ask the WG if they feel happy adopting this as a WG draft. > >>>>> > >>>>> Nabil and Giles > >>>>> > >>> > >>> > >>> 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 there= of. > >>> > > > > > > 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 balajivenkat299@gmail.com Fri May 11 00:08: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 CD22121F85B7 for ; Fri, 11 May 2012 00:08:46 -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 eKwMmklojEne for ; Fri, 11 May 2012 00:08:46 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5256721F8498 for ; Fri, 11 May 2012 00:08:46 -0700 (PDT) Received: by dacx6 with SMTP id x6so2852280dac.31 for ; Fri, 11 May 2012 00:08:46 -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:content-type; bh=a7YaCT52aGl0nBBHeg9+DRndFHZXDifwxhP7UeTilts=; b=hBvt8fgZL+0dEL0uQ7w7rF0KY3IVM2ItV0XNulUVDLEv13e2Z+id2GJDXiuAjkIbpA SYwpE6ZzNQTJ7/wXFYCTk6FmHzHNxBGWuyexUTwK1QivGgQLimMfWPCh6wWi9kYP1e/Y Jh83TqQOLYEi3dF4rB/oVXIQACw8R/hFPMxBG04fsQ0PS7P8lHMFwirbGgLTMIOBbGRT rDOKc33FAqQg1n+H9MunPHBiry3GqlCl84Bp1a5QPBagii30Opb0qvLyOY4fSHzoJDoX riYZhQBW2tijIG78+6G71mqIUOrTLLFQVq+cVh0pTtQ5AZTET8p9bORW36T5G7TSe2Jy sNzw== MIME-Version: 1.0 Received: by 10.68.189.71 with SMTP id gg7mr7453995pbc.65.1336720125727; Fri, 11 May 2012 00:08:45 -0700 (PDT) Received: by 10.68.31.10 with HTTP; Fri, 11 May 2012 00:08:45 -0700 (PDT) Date: Fri, 11 May 2012 12:38:45 +0530 Message-ID: Subject: Re: PBB E-VPN and TRILL From: Balaji venkat Venkataswami To: l2vpn@ietf.org Content-Type: multipart/alternative; boundary=e89a8ff1c88c4212d004bfbd68b4 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, 11 May 2012 07:08:46 -0000 --e89a8ff1c88c4212d004bfbd68b4 Content-Type: text/plain; charset=ISO-8859-1 Hi Sam, The draft that we published from DELL asserts non-uniqueness of nicknames amongst TRILL islands that are interconnected. thanks and regards, balaji venkat ------------------------------ Message: 3 Date: Thu, 10 May 2012 14:04:27 -0700 From: Sam Aldrin To: Donald Eastlake Cc: "l2vpn@ietf.org" , "stbryant@cisco.com" Subject: Re: PBB E-VPN and TRILL Message-ID: Content-Type: text/plain; charset=us-ascii AFAIK, there's no TRILL interconnect draft which specifies (apologies in advance if it already exists) which keeps islands separate after interconnection. Each of them requires nickname uniqueness after interconnection because it will be one big trill cloud. As I said in my other response, same with pbb-evpn draft as well. Sam Sent from my iPad --e89a8ff1c88c4212d004bfbd68b4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Sam,

The draft that we published from DELL asserts non-uniqueness o= f nicknames amongst TRILL islands that are interconnected.
thanks and regards,
balaji venkat
=
------------------------------

Message: 3
Date: Thu, 10 May 2012 1= 4:04:27 -0700
From: Sam Aldrin <aldrin.ietf@gmail.com>
To: Donald Eastlake <d3e3e3@gmail.com>
= Cc: "l2vpn@ietf.org= " <l2vpn= @ietf.org>, =A0"stbryant@cisco.com"
=A0 =A0 =A0 =A0<stbryant@cisco.com>
S= ubject: Re: PBB E-VPN and TRILL
Message-ID: <= ;DA7A8926-4EA4-4920-A6C8-57B997525372@gmail.com>
Content-Type: text/plain; =A0 =A0 =A0 charset=3Dus-ascii=

AFAIK, there's no TRILL interconnect dr= aft which specifies (apologies in advance if it already exists) which keeps= islands separate after interconnection. Each of them requires nickname uni= queness after interconnection because it will be one big trill cloud. As I = said in my other response, same with pbb-evpn draft as well.

Sam

Sent from m= y iPad
--e89a8ff1c88c4212d004bfbd68b4-- From xuxiaohu@huawei.com Fri May 11 01:59: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 C0F1B21F85A8; Fri, 11 May 2012 01:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.837 X-Spam-Level: X-Spam-Status: No, score=-0.837 tagged_above=-999 required=5 tests=[AWL=1.762, 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 S+0tAG6ZrZ4z; Fri, 11 May 2012 01:59:56 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id F13B421F85A2; Fri, 11 May 2012 01:59: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 AGC05597; Fri, 11 May 2012 04:59:55 -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, 11 May 2012 01:56:25 -0700 Received: from SZXEML439-HUB.china.huawei.com (10.72.61.74) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 11 May 2012 01:56:31 -0700 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.182]) by szxeml439-hub.china.huawei.com ([10.72.61.74]) with mapi id 14.01.0323.003; Fri, 11 May 2012 16:56:20 +0800 From: Xuxiaohu To: "robert@raszuk.net" , Ivan Pepelnjak Subject: re: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version Notification for draft-xu-mpls-in-udp-00.txt Thread-Topic: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version Notification for draft-xu-mpls-in-udp-00.txt Thread-Index: AQHNLdMWxh0NIaZEh0eGnDDg3V8uUpbESnjw Date: Fri, 11 May 2012 08:56:19 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02F215E6@szxeml525-mbs.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02F20BF9@szxeml525-mbs.china.huawei.com> <005a01cd2d9e$900f0ac0$b02d2040$@com> <4FAA1C30.6090303@raszuk.net> <00fe01cd2dca$85427060$8fc75120$@com> <4FAA4E84.4090803@raszuk.net> In-Reply-To: <4FAA4E84.4090803@raszuk.net> 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" , "l3vpn@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, 11 May 2012 08:59:58 -0000 DQo+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4g5Y+R5Lu25Lq6OiBSb2JlcnQgUmFzenVrIFtt YWlsdG86cm9iZXJ0QHJhc3p1ay5uZXRdDQo+IOWPkemAgeaXtumXtDogMjAxMuW5tDXmnIg55pel IDE5OjAxDQo+IOaUtuS7tuS6ujogSXZhbiBQZXBlbG5qYWsNCj4g5oqE6YCBOiBLZXNoYXZhIEEg SzsgbDJ2cG5AaWV0Zi5vcmc7IFh1eGlhb2h1OyBudm8zQGlldGYub3JnOyBsM3ZwbkBpZXRmLm9y Zw0KPiDkuLvpopg6IFJlOiBbbnZvM10gRmFjaWxpdGF0aW5nIHRoZSBsb2FkLWJhbGFuY2luZyBv ZiBMMlZQTi9MM1ZQTiB0cmFmZmljIG92ZXIgSVANCj4gUFNOIHVzaW5nIE1QTFMtaW4tVURQIGVu Y2Fwc3VsYXRpb24vLyBmd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4gZHJhZnQt eHUtbXBscy1pbi11ZHAtMDAudHh0DQo+IA0KPiBIaSBJdmFuLA0KPiANCj4gPiBUcnVlLCBidXQg dGhlbiB5b3UgbmVlZCBhIG1lY2hhbmlzbSB0byBkaXNjb3ZlciBhbGwgdGhlIGF2YWlsYWJsZQ0K PiA+IGVuZHBvaW50cywgd2hlcmVhcyB3aXRoIHNpbmdsZSBWVEVQIHBlciBob3N0IHlvdSBjYW4g dXNlIGV4aXN0aW5nDQo+ID4gbWVjaGFuaXNtcyAoZWl0aGVyIGxlYXJuaW5nIGZyb20gc291cmNl IElQIGFkZHJlc3Mgb3IgbmV4dC1ob3ANCj4gPiBkaXN0cmlidXRpb24gd2l0aCBCR1AtbGlrZSBw cm90b2NvbHMpLg0KPiANCj4gVHJ1ZS4NCj4gDQo+IEkgc2VlIGZldyBvcHRpb25zOg0KPiANCj4g LSBTaWduYWwgZGlmZmVyZW50IG5leHQgaG9wcyBpbiBCR1AgZm9yIHRoZSBhcHBsaWNhdGlvbiB3 aGljaCBydW5zIGFjcm9zcw0KPiANCj4gLSBUcmVhdCBuZXh0IGhvcCBpbiBCR1AgYXMgcHJlZml4 IGluZGljYXRvciBub3QgYXMgaG9zdCByb3V0ZS4gSW4NCj4gcGFydGljdWxhciBuZXh0IGhvcCBy ZXNvbHZlcyBpbiBJR1AgdG8gYSBwcmVmaXggd2hpY2ggaW4gdHVybiBjb3VsZCBiZQ0KPiB1c2Vk IGFzIHNldCBvZiBHUkUgZGVzdGluYXRpb24gYWRkcmVzc2VzDQo+IA0KPiAtIFNpZ25hbCBzdWNo IHJhbmdlIGV4cGxpY2l0bHkuIEkgdGhpbmsgdGhlcmUgd2lsbCBiZSBhIGRyYWZ0IGNvbWluZyB1 cA0KPiBvbiBqdXN0IHRoYXQgc29vbi4NCg0KSGkgYWxsLA0KDQpUaGUgZHJhZnQgdGhhdCBSb2Jl cnQgbWVudGlvbmVkIGlzIG5vdyBhdmFpbGFibGUgYXQgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQteHUtaWRyLXR1bm5lbC1hZGRyZXNzLXByZWZpeC0wMC4gIEFueSBjb21tZW50cyBh bmQgc3VnZ2VzdGlvbnMgYXJlIHdlbGNvbWUuDQoNCkJUVywgdGhhbmtzIFJvYmVydCBmb3IgeW91 ciBwcmUtYW5ub3VuY2VtZW50IG9mIHRoaXMgZHJhZnQgOykNCg0KQmVzdCByZWdhcmRzLA0KWGlh b2h1DQoNCg0K From balajivenkat299@gmail.com Fri May 11 05:43: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 00E5C21F85DB for ; Fri, 11 May 2012 05:43:31 -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 X9Nw-3HuzXfN for ; Fri, 11 May 2012 05:43:30 -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 2E91A21F85D5 for ; Fri, 11 May 2012 05:43:28 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so3409679pbc.31 for ; Fri, 11 May 2012 05:43:28 -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:content-type; bh=idryz9LNRFG1uKHqYcsSaCy7HUoHHstVUNRJk8rKcr8=; b=V2uYYE6KGqeGS7nNdwIF1z/SoywZPin5fagPy4rZD8EDe4rQUaL6+X0JJoxoGcs7OK /PDMLPJNqwUep8AO3U/nqjfSHvz9gGvTNHb8ZsAZu21xf81X2Fm10dcnzcHIV8SdwBvk KuZfF1hC6cRT11RbLmEfK/3wVroeUdNfyVCNGREfHhKYlrX5M1G1y5pu3dICe2GZcPYC nE3xKeS/hGpQm159RwMwLhghuWtgbzOfekkA4XNDZv5CGvjXq54BC8vigdjSD3H1j1+b iJj/B9PrevtzO7JJhYHB50OEYWeA1XpFWaoEA6G8W3wpTo1PzaaY4Bw/8yTnSTf+UBkA ZXmA== MIME-Version: 1.0 Received: by 10.68.194.227 with SMTP id hz3mr31872473pbc.23.1336740207411; Fri, 11 May 2012 05:43:27 -0700 (PDT) Received: by 10.68.31.10 with HTTP; Fri, 11 May 2012 05:43:27 -0700 (PDT) Date: Fri, 11 May 2012 18:13:27 +0530 Message-ID: Subject: Re: PBB E-VPN and trill From: Balaji venkat Venkataswami To: l2vpn@ietf.org Content-Type: multipart/alternative; boundary=047d7b10cb513840dd04bfc21592 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, 11 May 2012 12:43:31 -0000 --047d7b10cb513840dd04bfc21592 Content-Type: text/plain; charset=ISO-8859-1 Hi Sam, Sorry I didnt specify the link for the draft. The link to the draft is http://tools.ietf.org/html/draft-balaji-trill-over-ip-multi-level-05 thanks and regards, balaji venkat Date: Fri, 11 May 2012 12:38:45 +0530 From: Balaji venkat Venkataswami To: l2vpn@ietf.org Subject: Re: PBB E-VPN and TRILL Message-ID: Content-Type: text/plain; charset="iso-8859-1" Hi Sam, The draft that we published from DELL asserts non-uniqueness of nicknames amongst TRILL islands that are interconnected. thanks and regards, balaji venkat ------------------------------ Message: 3 Date: Thu, 10 May 2012 14:04:27 -0700 From: Sam Aldrin To: Donald Eastlake Cc: "l2vpn@ietf.org" , "stbryant@cisco.com" Subject: Re: PBB E-VPN and TRILL Message-ID: Content-Type: text/plain; charset=us-ascii AFAIK, there's no TRILL interconnect draft which specifies (apologies in advance if it already exists) which keeps islands separate after interconnection. Each of them requires nickname uniqueness after interconnection because it will be one big trill cloud. As I said in my other response, same with pbb-evpn draft as well. Sam --047d7b10cb513840dd04bfc21592 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Sam,

Sorry I didnt specify the link for the draft.=A0

The link to the draft is= =A0

thanks and regards,=
balaji venkat=

Date: Fri, 11 May 2012 12:38:= 45 +0530
From: Balaji venkat Venkataswami <<= /span>balajivenkat299@gm= ail.com>
To:=A0l2vpn@ietf= .org
Subject: Re: PBB E-VPN and TRILL
Message-ID:
=A0 =A0 =A0 =A0<= CAHF4apMwDbNhJ75DUMOCsyg5Qi-tO4dLEo1CDVg-3hRnt6U54g= @mail.gmail.com>
Content-Type: text/plain; charset=3D"iso-8859-1"

Hi Sam,

The draft that we published from DELL asserts non-uniqueness of nickna= mes
amongst TRILL islands that are interconnected.
=
thanks and regards,
balaj= i venkat

----------------------------= --

Message: 3
Date: Thu, 10 = May 2012 14:04:27 -0700
From: Sam Aldrin <aldrin.ietf@gmail.com>
To: Donald Eastlake <d3e3e3@gmail.com>
= Cc: "l2vpn@ietf.org= " <l2vpn= @ietf.org>, =A0"stbryant@cisco.com"
=A0 =A0 =A0 <stbryant@cisco.com>
Subj= ect: Re: PBB E-VPN and TRILL
Message-ID: <DA7A8926-4EA4-4920-A6C8-57B997525372@gmail.com>=
Content-Type: text/plain; =A0 =A0 =A0 charset=3Dus-ascii=

AFAIK, there's no TRILL interconnect dr= aft which specifies (apologies in
advance if it= already exists) which keeps islands separate after
interconnection. Each of them requires nickname uniqueness afte= r
interconnection because it will be one big tr= ill cloud. As I said in my
other response, same= with pbb-evpn draft as well.

Sam
--047d7b10cb513840dd04bfc21592-- From nmcgill@cisco.com Fri May 11 07: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 C071A21F86EE for ; Fri, 11 May 2012 07:24:43 -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 evbDLxU8bRJX for ; Fri, 11 May 2012 07:24:42 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 5F49921F86E4 for ; Fri, 11 May 2012 07:24:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=nmcgill@cisco.com; l=11521; q=dns/txt; s=iport; t=1336746282; x=1337955882; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=TIBDVvLkmJ+2n17W/0dTrJHNmnR9RwS0MPQX6/jT02w=; b=KoCO/Gv978++mclXFToxDW0Q1Tzz8Ln1xwN0WGLvUZirVlJhsdBd0+dc 6jd96Syv/IN+QGLW5MoGAB6exZIoPZcRT08tYpNCwCNTQj93iqGLKzTVc 6yNMvXsiZLoAN3KeSQG+O9MIOlUKGEzT7BDz7GZHYcQ5i3kFxAVYz7LTh 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EADUgrU+tJV2Z/2dsb2JhbABEtCWBB4IVAQEBAwESASc6BQUHBAsRBAEBKAdGCQgGExkJh2cEAQuacKACixcZhgQEiGSOKo1GgWmDCYE/ X-IronPort-AV: E=Sophos;i="4.75,571,1330905600"; d="scan'208";a="82421462" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 11 May 2012 14:24:41 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q4BEOfkd023492; Fri, 11 May 2012 14:24:41 GMT Received: from xmb-rcd-102.cisco.com ([72.163.62.144]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 May 2012 09:24:41 -0500 Received: from sjc-ads-1109 ([171.70.58.51]) by xmb-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 May 2012 09:24:41 -0500 Date: Fri, 11 May 2012 07:24:40 -0700 (PDT) From: Neil McGill To: Alexander Vainshtein Subject: RE: Static VPLS MAC withdrawal draft In-Reply-To: Message-ID: References: <32B4F6D6-CB5A-4DE9-8A14-B04B175BC30E@cisco.com> <78CE5EBC-3B62-4783-8F32-12B8C654F4CF@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 11 May 2012 14:24:41.0049 (UTC) FILETIME=[CD9C9490:01CD2F81] Cc: "l2vpn@ietf.org" , "msiva@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, 11 May 2012 14:24:43 -0000 On Fri, 11 May 2012, Alexander Vainshtein wrote: > Sami, > Lots of thanks for prompt responses. > > My general gut feeling is that the draft tries to compensate for lack of reliable delivery provided by TCP in the case of signaled PWs between the VPLS peers, but leaves aside some other issues that stem from the static nature of the PWs. These include at least the following: > > - Synchronized setup of the PW endpoints. Life would be simpler if the two endpoints could guarantee that they have both come up and both deal with the same values of Rx and Tx sequence numbers (cross-matched). > > - Synchronized reset for the sequence numbers: consider the case when one of the PEs undergoes restart in the middle of operation and starts with a new pair of Rx and Tx numbers while its peers remain unaware of the fact. > > - Ordered (in addition to reliable) delivery of messages: consider the case with two messages following each other (from my original example), but the first one being lost. The 2nd one (including all MAC addresses from the 1st one) is delivered and ACKed, then the 1st one is retransmitted and delivered... I'm concerned that if we are concatenating MAC addresses for the 2nd message then we are going to hit size limits and will need to deal with fragmentation. And we have the double flush potential too. A lot of this complexity could be avoided if we simply did a flush-all with no MACs. Are other vendors actually flushing MACs on a per basis ? At least until now all I've seen is flush-all behaviour. If we're going for 'as simple as possible' I'd opt to take out the option to flush individual MACs and go for 'flush all' If we are going to continue with per MAC flushing I do agree that we need a more reliable delivery. My preference is that we only ack what we have received and we transmit until acked. So if msg 1 is lost and msg 2 received then the peer will not ack both, but would continue to request msg 1; just like tcp/ospf/lap*/l2tpv3 would do. Thanks, Neil. > > One thing that the draft does not mention is management of the list of MAC addresses that should be withdrawn but have not be ACKed for withdrawal (an analog o the TCP socket Tx buffer). Such a list is required per PW, and it would be nice to understand how it behaves. > > I must admit that I do not have a better scheme in mind at the moment (that is, if you do not count using TCP as a valid better scheme :-). > But using some non-TCP mechanism for synchronized, ordered and reliable delivery (e.g., one used in OSPF?) may be worth consideration. > > IMHO and FWIW, if your colleagues and you prefer to keep it as simple as possible, the draft should at least describe possible pitfalls and their consequences (say in an Applicability section). > > Last but not least: > I may be exceptionally dumb these days, but could you please clarify which "half of the sequence number space" do you have in mind, and which modulo do you use in the "modular arithmetic"? > > Regards, > Sasha > > > -----Original Message----- > > From: Sami Boutros [mailto:sboutros@cisco.com] > > Sent: Friday, May 11, 2012 4:22 AM > > To: Alexander Vainshtein > > Cc: msiva@cisco.com; nmcgill@cisco.com; l2vpn@ietf.org; Giles Heron > > Subject: Re: Static VPLS MAC withdrawal draft > > > > Hi Sasha, > > > > >> > > >> Thanks for your comments, Please see responses inline.. > > >> > > >>> > > >>> > > >>>> -----Original Message----- > > >>>> From: Alexander Vainshtein > > >>>> Sent: Thursday, May 10, 2012 5:08 PM > > >>>> To: 'msiva@cisco.com:'; Sami Boutros (sboutros@cisco.com); > > >>>> 'nmcgill@cisco.com' > > >>>> Cc: l2vpn@ietf.org; 'Giles Heron'; Rotem Cohen; Andrew Sergeev; > > >> Mishael > > >>>> Wexler; Gideon Agmon > > >>>> Subject: RE: Static VPLS MAC withdrawal draft > > >>>> > > >>>> Hi all, > > >>>> I've read the draft in question and I would like to clarify several issues > > >> that > > >>>> look either undefined or ambiguous to me. > > >>>> > > >>>> 1. To the best of my understanding, the draft requires each PE > > >> participating > > >>>> in a given VPLS instance to set up two counters for each static PW > > >>>> connecting it to a peer PE device in this VPLS instance: one for static > > MAC > > >>>> withdrawal messages it is going to send and another - for static MAC > > >>>> withdrawal messages it receives. Is this understanding correct? > > >>>> > > >> > > >> Sami: This is correct. > > >> > > >>>> 2. Assuming a positive answer to the previous questions, how are > > these > > >>>> counters initialized? The draft seems to be moot on this point. > > >> > > >> Sami: This is what the draft has for setting up the sequence # in section 3. > > >> Only half of the sequence number space is used. Modular arithmetic > > >> is used to detect wrapping of sequence number. When sequence > > number > > >> wraps (i.e., when it becomes 0), all MAC addresses are flushed and > > >> the sequence number is reset. > > >> Sami: Can you please explain what's vague in the above? > > > [[[Sasha]]] This does not say too much about initialization (at least, not to > > me). > > > And it would be nice if the draft was more specific here. > > > > Sami: Agreed, we need to add the initialization value to the text. > > > > >> > > >>>> The more > > >>>> interesting question is, of course, about initialization of the counter of > > >>>> received static MAC withdrawal messages, since, with static PWs, > > >> generally > > >>>> speaking, there is no synchronization between setting up one of its > > end > > >>>> points and setting up another one. > > >> > > >> > > >> Sami: Initially the rx sequence # can be assumed to be 0. > > > [[[Sasha]]] But you've said that Rx number 0 results in flushing all MAC > > addresses? > > > > Sami: Good point, but this is why the receiving PE should always flush on > > receiving 0. > > Sami: The Transmitter PE would then increment the sequence # and > > subsequent > > Sami: Transmission will be higher than 0. > > > > >> > > >>>> > > >>>> 3. The draft specifies that: > > >>>> - The transmitter sends the MAC withdrawal message with the same > > >>>> sequence number until it receives an ACK for it (Section 4.1.1) > > >>>> - The receiver, after having acknowledged a MAC withdrawal > > >>>> message, ignores refresh messages with the same sequence number > > >>>> (Section 4.1.2) > > >>>> What is supposed to happen in the following scenario: > > >>>> - Transmitter finds out that some MACs have to be withdrawn (e.g., > > >>>> because the AC from which they have been learned fails) > > >>>> and sends a MAC withdrawal message to its peers with sequence > > >>>> number N > > >>>> - Immediately after that (i.e., before it receives an ACK for this > > >>>> message) it finds out that yet another set of MAC addresses has to be > > >>>> withdrawn > > >>>> - Retransmission timer expires without ACK received. > > >>>> > > >> > > >> Sami: A new sequence # will be transmitted that will include both sets of > > >> MAC addresses > > >> Sami: that need to be flushed, and the transmitter will wait for an ack for > > >> this new sequence #. > > >> Sami: We can add this to the draft. > > > [[[Sasha]]] First of all, I think something like that MUST be added to the > > draft. > > > And I am not sure what you say is really OK: consider the case when ACK > > for the first withdrawal message is received after the 2nd message has been > > sent. > > > If one of the ACKed (and withdrawn) MAC addresses has been then re- > > learned they will be flushed again... > > > > Sami: Yes, this will lead to deleting again, and then the macs will be learnt > > again, keep in mind that we are talking about using a mac list (not an empty > > mac list), and deleting 2 sets of macs and we didn't Sami: get the ack for the > > 1st set in time before we ask to delete the 2nd set. I would think this should > > be ok, however am open to better schemes. > > > > > > >> > > >>>> 4. Suppose that only one end point of a static PW between a given pair > > of > > >>>> peers has been set up. In this case transmitting the static MAC > > >> withdrawal > > >>>> messages via such a PW is possible, but ACKs will never be received. > > >> Should > > >>>> retransmission of these messages go on "ad infinitum"? > > >>>> > > >> > > >> Sami: Yes, this will be the case, the mechanism will be no different then > > the > > >> static PW status one for this case. > > > [[[Sasha]]] But ACK is not mandatory in the PW status message 9indeed, it > > is not clear if it is ever needed). > > > Here you may end with multiple retransmitting messages that are sent to > > a black hole. > > > > Sami: Wouldn't that be TRUE too for PW status messages? however is there > > a scheme you have in mind to solve this? > > > > > > Thanks, > > > > Sami > > >> > > >>>> 5. The draft does not specify any default value for the retransmit time. > > >>>> > > >> > > >> Sami: Sure will add. > > >> > > >>>> 6. A nit: Heading of Section 4 is followed by headings for Sections 4.1.1 > > >> and > > >>>> 4.1.2 without any heading for 4.1. > > >>>> > > >> > > >> Sami: Sure will fix. > > >> > > >>>> Hopefully these questions will be useful. > > >>>> > > >> > > >> Thanks, > > >> > > >> Sami > > >> > > >> > > >>>> Regards, > > >>>> Sasha > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > > >> Behalf > > >>>>> Of Giles Heron > > >>>>> Sent: Tuesday, May 08, 2012 10:06 PM > > >>>>> To: l2vpn@ietf.org > > >>>>> Subject: Static VPLS MAC withdrawal draft > > >>>>> > > >>>>> Hi everyone, > > >>>>> > > >>>>> The following draft was presented at IETF in Paris: > > >>>>> > > >>>>> http://tools.ietf.org/html/draft-boutros-l2vpn-mpls-tp-mac-wd-00 > > >>>>> > > >>>>> The authors have asked for it to be adopted as a WG draft, but at this > > >> stage > > >>>>> the chairs' view is that it probably hasn't had enough sets of eyes on > > it. > > >>>>> > > >>>>> So this email is to request that those on the list take a read of the > > draft > > >>>>> and send comments back to the list. Depending on the response we > > get > > >>>> we > > >>>>> may > > >>>>> then ask the WG if they feel happy adopting this as a WG draft. > > >>>>> > > >>>>> Nabil and Giles > > >>>>> > > >>> > > >>> > > >>> 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 lizho.jin@gmail.com Fri May 11 08:11: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 CD5E821F85C7 for ; Fri, 11 May 2012 08:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.429 X-Spam-Level: X-Spam-Status: No, score=-3.429 tagged_above=-999 required=5 tests=[AWL=0.169, 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 UQuHkJa8lIsD for ; Fri, 11 May 2012 08:11:14 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6CC21F8624 for ; Fri, 11 May 2012 08:11:14 -0700 (PDT) Received: by ggmi1 with SMTP id i1so2235096ggm.31 for ; Fri, 11 May 2012 08:11:13 -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=4ZpjfWeasUT7m4Gjb7ifUrGsSlvNO4J6nHuUNT4i6oc=; b=n1dtF8XpoKaJr2yxUEZcL9RFzwXf4OOBZo/hHHonfFUs5/jQCCO2dl38KShePCkUB5 tSSf72ogIjmSZddkvA/3qNxSmStjiLdrdhSIoNGT2Yh5aGxVU8E4peqR8c5nmVF4v3rK Cx3ifi3nGexzTx/66vEZ11WzHp73SOg6H2ej/OYvPvKOvUuHtQfRtAMIOcvQ+qWGN9SK GUZAV13m77ksbara3P364+ZCwMonjNE0kptl57cIDzznKx9iI338LgGP0Dz/HtxvmIjj eQu3Ucjyujeq4ZyrheutrVOyRK7N/ntk9tDOpzncCJOybW7JWyOorjw4bz6GYSDpo12Y kfYw== MIME-Version: 1.0 Received: by 10.42.159.9 with SMTP id j9mr4025420icx.5.1336749073715; Fri, 11 May 2012 08:11:13 -0700 (PDT) Received: by 10.50.8.100 with HTTP; Fri, 11 May 2012 08:11:13 -0700 (PDT) Date: Fri, 11 May 2012 23:11:13 +0800 Message-ID: Subject: Re: Static VPLS MAC withdrawal draft From: Lizhong Jin To: Sami Boutros , Giles Heron Content-Type: multipart/alternative; boundary=90e6ba6e842cb1506804bfc4252b 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, 11 May 2012 15:11:26 -0000 --90e6ba6e842cb1506804bfc4252b Content-Type: text/plain; charset=ISO-8859-1 Hi all, I read this draft, and it is useful to have such MAC withdraw mechanism. Besides the comments from Sasha, as for the default retransmission timer, it should be careful to have this. When the total retransmission time is larger than the MAC aging time, then it is not necessary to retransmit MAC-withdraw message. And in order to be more reliable, when transmission, three instances of the message in succession, separated with an appropriate delay is recommended. Lizhong > ---------------------------------------------------------------------- > > Date: Tue, 08 May 2012 20:05:31 +0100 > From: Giles Heron > To: > Subject: Static VPLS MAC withdrawal draft > Message-ID: > Content-Type: text/plain; charset="US-ASCII" > > Hi everyone, > > The following draft was presented at IETF in Paris: > > http://tools.ietf.org/html/draft-boutros-l2vpn-mpls-tp-mac-wd-00 > > The authors have asked for it to be adopted as a WG draft, but at this > stage > the chairs' view is that it probably hasn't had enough sets of eyes on it. > > So this email is to request that those on the list take a read of the draft > and send comments back to the list. Depending on the response we get we > may > then ask the WG if they feel happy adopting this as a WG draft. > > Nabil and Giles > > > > --90e6ba6e842cb1506804bfc4252b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,
I read this draft, and it is useful to have such MAC withdraw mechanis= m.
Besides the comments from Sasha, as for the default retransmission tim= er, it should be careful to have this.=A0When the total retransmission time= is larger than the MAC aging time, then it is not necessary to retransmit = MAC-withdraw message. And in order to be more reliable, when transmission, = three instances of the message in succession, separated=A0with=A0an=A0appro= priate=A0delay is recommended.
=A0
Lizhong
=A0
=A0
-------------------------------------= ---------------------------------

Date: Tue, 08 May 2012 20:05:31 +0= 100
From: Giles Heron <giles.heron@= gmail.com>
To: <l2vpn@ietf.o= rg>
Subject: Static VPLS MAC withdrawal draft
Message-ID: <= CBCF2D0B.1AAF5%gi= les.heron@gmail.com>
Content-Type: text/plain; =A0 =A0 =A0 charset=3D"US-ASCII"
Hi everyone,

The following draft was presented at IETF in Paris:
http://tools.ietf.org/html/draft-boutros-l2vpn-mpl= s-tp-mac-wd-00

The authors have asked for it to be adopted as a WG draft, but at this = stage
the chairs' view is that it probably hasn't had enough set= s of eyes on it.

So this email is to request that those on the list = take a read of the draft
and send comments back to the list. =A0Depending on the response we get we = may
then ask the WG if they feel happy adopting this as a WG draft.
<= br>Nabil and Giles



--90e6ba6e842cb1506804bfc4252b-- From luayjalil@gmail.com Fri May 11 19:51: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 7ADCD21F85E6 for ; Fri, 11 May 2012 19:51: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, 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 cg+CymJPXN4v for ; Fri, 11 May 2012 19:51:56 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 68A5C21F85E5 for ; Fri, 11 May 2012 19:51:56 -0700 (PDT) Received: by yenq13 with SMTP id q13so3912252yen.31 for ; Fri, 11 May 2012 19:51:56 -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=ZVKqLshvOMH/OxM0MpkTbL0ch2BByF+fm9XmBxJr7OM=; b=ybWqvKcoaCRmSK352fEWvjdPJVW5ElwsiVOUtK/q/XVySNF0iWhBJScJsw8CgE5Qhi pnVp8YOHOEBGrzFeVPRi00v20imP2LnpnUTFv56qF1oIEOuVvF+MZJ5dVNmequr51Qkn T8B9erG0rJLAygukDrrHgrPKW3kcLvdrtC4NUU3dZbA9uJtyLgtHUmlTsJjyr3fq5pkk CCXJPg4LXW+iWIEeyJINlM4XK6Dnni42t0T1BuFVLuAWizOpVdDImZ6raQam1jqlRZD4 DsDI0LHJNGWZbe9YRgwKV+EQVRE1t9tNM9NfuYdga8IDUX+RkJITbkiCnwu5kC7DvagT LJ9w== MIME-Version: 1.0 Received: by 10.50.88.225 with SMTP id bj1mr152859igb.42.1336791115833; Fri, 11 May 2012 19:51:55 -0700 (PDT) Received: by 10.231.206.4 with HTTP; Fri, 11 May 2012 19:51:51 -0700 (PDT) Received: by 10.231.206.4 with HTTP; Fri, 11 May 2012 19:51:51 -0700 (PDT) In-Reply-To: References: Date: Fri, 11 May 2012 21:51:51 -0500 Message-ID: Subject: Re: PBB E-VPN and TRILL From: Luay Jalil To: Giles Heron Content-Type: multipart/alternative; boundary=e89a8f234417991faf04bfcdefec Cc: l2vpn@ietf.org, "Ali Sajassi \(sajassi\)" , Stewart Bryant 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, 12 May 2012 02:51:57 -0000 --e89a8f234417991faf04bfcdefec Content-Type: text/plain; charset=ISO-8859-1 Yes to all 3 Regards, Luay On May 9, 2012 8:33 AM, "Giles Heron" wrote: > Ali presented the PBB-EVPN draft at IETF83 in Paris: > > http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-01 > > This has since been updated: > > http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-02 > > During our discussions Ali mentioned that the authors would like the TRILL > section of the draft to be separated out into a separate draft. In > response > Stewart questioned whether interconnecting TRILL islands is in-scope for > L2VPN. > > Stewart, Nabil and I have just been discussing these issues. Whilst TRILL > interconnect is not explicitly in-charter for L2VPN it would appear to be > implicitly in-charter - our decision to standardise solutions for PBB VPLS > and PBB E-VPN probably sets a precedent (since PBB is also unmentioned by > the charter). > > On this basis we would like to ask the WG the following three questions: > > 1) is the WG happy for us to pursue interconnection of TRILL islands over > L2VPN? > > 2) is the WG happy for the authors to split the TRILL section of the PBB > E-VPN draft into a separate draft? > > 3) is the WG happy for the TRILL draft to be a WG doc? > > Please respond by May 22nd if you are unhappy with any of these 3 actions > (I'll take no response to mean the WG is in agreement with us > proceeding...) > > Giles > > > --e89a8f234417991faf04bfcdefec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Yes to all 3

Regards,
Luay

On May 9, 2012 8:33 AM, "Giles Heron" = <giles.heron@gmail.com> = wrote:
Ali presented the PBB-EVPN draft at IETF83 in Paris:

http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-01

This has since been updated:

http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-02

During our discussions Ali mentioned that the authors would like the TRILL<= br> section of the draft to be separated out into a separate draft. =A0In respo= nse
Stewart questioned whether interconnecting TRILL islands is in-scope for L2VPN.

Stewart, Nabil and I have just been discussing these issues. =A0Whilst TRIL= L
interconnect is not explicitly in-charter for L2VPN it would appear to be implicitly in-charter - our decision to standardise solutions for PBB VPLS<= br> and PBB E-VPN probably sets a precedent (since PBB is also unmentioned by the charter).

On this basis we would like to ask the WG the following three questions:
1) is the WG happy for us to pursue interconnection of TRILL islands over L2VPN?

2) is the WG happy for the authors to split the TRILL section of the PBB E-VPN draft into a separate draft?

3) is the WG happy for the TRILL draft to be a WG doc?

Please respond by May 22nd if you are unhappy with any of these 3 actions (I'll take no response to mean the WG is in agreement with us proceedin= g...)

Giles


--e89a8f234417991faf04bfcdefec-- From yuqun.cao@gmail.com Sun May 13 05:11: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 F08F421F857D for ; Sun, 13 May 2012 05:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.934 X-Spam-Level: X-Spam-Status: No, score=-2.934 tagged_above=-999 required=5 tests=[AWL=0.665, 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 GP0UyNeu7HGS for ; Sun, 13 May 2012 05:11:48 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 43A7C21F84CD for ; Sun, 13 May 2012 05:11:48 -0700 (PDT) Received: by dacx6 with SMTP id x6so4988068dac.31 for ; Sun, 13 May 2012 05:11:48 -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 :x-mimeole:in-reply-to; bh=v53o8VmiPlYp5BIX6zqyCCVNegZFRTJ7LkJ/TZrUs38=; b=qSwGVLkEkVoAG6ZvEOUpS39qb2RWThH8tgk18BZw8qSOAk1m6z4qDU9bns3Lu0JVGk ps/VWB5tR/OCW3Su2irw5kf5AeCfUGAMkpY3Hs9wkVRW/rtNHDUy5AtFphCUwTkCi4kf IjTIZLfFp08vGzN7+Hq83Yi0syKUWJPlYJM/4XL4XJeIRhhwd1kM+eB6fj1pxwUZ5oSl L8eGZwpYAMKru3+EM5J+S63i1a7NpqqHI1axJJC9Tf0yg2OfRLqZEQ6VmnfNxA33Rf0T jypJNwuL2vCa5Tkbui/D8WcEgpcVP1dRa88iSd3A+ECo36RoOrKYgvDZVEbqc84pBBVn VyLg== Received: by 10.68.203.201 with SMTP id ks9mr11955648pbc.139.1336911107823; Sun, 13 May 2012 05:11:47 -0700 (PDT) Received: from v2comsam ([36.248.0.44]) by mx.google.com with ESMTPS id oz9sm18871167pbc.68.2012.05.13.05.11.41 (version=SSLv3 cipher=OTHER); Sun, 13 May 2012 05:11:46 -0700 (PDT) From: "Sam Cao" To: "'Jiangyuanlong'" , "'Daniel Cohn'" , "'Alexander Vainshtein'" References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D411694@szxeml546-mbx.china.huawei.com> Subject: RE: Discussion on E-Tree and H-VPLS Date: Sun, 13 May 2012 20:11:47 +0800 Message-ID: <9DD82042036148718A4568CD0EE548DA@v2comsam> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: AQHNLxo31u2OjZw96UuBF9QPOwJXg5bHo/aw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 In-reply-to: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D411694@szxeml546-mbx.china.huawei.com> 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, 13 May 2012 12:11:49 -0000 Hi Yuanlong, Any bridging capable box will filter the traffic, or say, on the PE-rs. Multi-PW approach will fully comply with RFC 4762, and please read RFC 4762 and multi-PW draft. Regards, Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] Sent: Friday, May 11, 2012 10:03 AM To: Daniel Cohn; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Daniel and all, When you set up two PWs from the PE-rs to a PE-r for each of its AC, do you mean that one PW is bidirectional root PW and the other is bidirectional leaf PW? My concern is: where should the leaf traffic be filtered, on the PE-rs or on the PE-r? If filtered on the PE-r, then lots of bandwidth will be wasted (for example, if the PE-r is attached with 9 leafs, then the BUM traffic from one of its leafs will be multiplied by 8 times, and be forwarded by the PE-rs to the same PE-r). If filtered on the PE-rs, not sure how you will design its forwarding plane, can you give a hint? Thanks, Yuanlong ------------------------------ Date: Wed, 9 May 2012 09:16:36 +0300 From: "Daniel Cohn" To: "Alexander Vainshtein" , "Sam Cao" , Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780CBA6@tlvmail1> Content-Type: text/plain; charset="ISO-2022-JP" Hi Sasha, It's actually very simple. A frame that originated in a root AC is always transmitted only in root PW, no matter what the frame type (known/unknown unicast or broadcast). This is how the frame source information is propagated across the VPLS. So in the H-VPLS example, the PE-r will never forward a frame received over a root PW on any leaf PW, only on root PWs (toward the core or toward other spokes). Hope this clarifies it, regards, Daniel -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Alexander Vainshtein Sent: Wednesday, May 09, 2012 7:59 AM To: Sam Cao; l2vpn@ietf.org Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Sam, Lizhong and all, You've written that in the two-PW solution combined with H-VPLS the PE-r must set up two PWs with each MTU-s. If this is the case, what kind of forwarding logic should be used to prevent sending a BUM frame received from a root-PW to a given MTU-S: - back to the same MTU-S on the corresponding leaf-PW? - twice (to both root-PW and Leaf-PW) to another MTU-s? And, BTW, how is the PW selected in this case? I am aware of a technique of multiple split horizon groups in PE-r which could be possibly used for this purpose. However, since these groups have to be represented explicitly in the data plane, their potential number is limited by the forwarding HW. Other methods could be probably used for the same purpose, but they would probably subject to similar HW-based limitations. I suspect that with the dual-PW approach, the HW would pose an implicit limit, say, on a number of MTU-s that can be connected to the same PE-r and that this limit could be quite low in most cases. Based on this I suspect that the H-VPLS issue as a critical drawback of the dual-PW approach to E-Tree. My 2c, Sasha ________________________________________ From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Sam Cao [yuqun.cao@gmail.com] Sent: Wednesday, May 09, 2012 3:40 AM To: l2vpn@ietf.org Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Hi Lizhong? Thank you very much for your comments. I updated the result on this question. [Lizhong] agree with the above analysis. And we did not say it is a technical problem, but it is an operational problem again. [Sam] I agree. Dual-VLAN does not make sense. I also discussed this with Giles and Yuanlong in another mail, and we reached agreement on this: MTU should know the access mode, VPWS or VPLS, VPWS mode should configure VLAN ID on MTU but VPLS mode can not. I thought this is NOT reasonable :), but we can figure this out in draft. It seems ok. [Lizhong] not fully understand. Do you mean, when VPWS accessing for H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf PW) for each AC access? [Sam] Yes. Thanks, Sam From jiangyuanlong@huawei.com Sun May 13 19:40: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 6D3B621F84F0 for ; Sun, 13 May 2012 19:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.607 X-Spam-Level: * X-Spam-Status: No, score=1.607 tagged_above=-999 required=5 tests=[AWL=-3.879, BAYES_00=-2.599, FRT_GUARANTEE1=4.533, FUZZY_GUARANTEE=1.252, MANGLED_GRNTEE=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYw7A+FdAXya for ; Sun, 13 May 2012 19:40:21 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id AD2C421F84E7 for ; Sun, 13 May 2012 19:40:21 -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 AFW74239; Sun, 13 May 2012 22:40: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; Sun, 13 May 2012 19:37:56 -0700 Received: from SZXEML439-HUB.china.huawei.com (10.72.61.74) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 13 May 2012 19:37:56 -0700 Received: from SZXEML546-MBS.china.huawei.com ([169.254.4.75]) by szxeml439-hub.china.huawei.com ([10.72.61.74]) with mapi id 14.01.0323.003; Mon, 14 May 2012 10:37:52 +0800 From: Jiangyuanlong To: Sam Cao , 'Daniel Cohn' , 'Alexander Vainshtein' Subject: RE: Discussion on E-Tree and H-VPLS Thread-Topic: Discussion on E-Tree and H-VPLS Thread-Index: AQHNLxo31u2OjZw96UuBF9QPOwJXg5bHo/awgADu9eA= Date: Mon, 14 May 2012 02:37:51 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D412E16@szxeml546-mbs.china.huawei.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D411694@szxeml546-mbx.china.huawei.com> <9DD82042036148718A4568CD0EE548DA@v2comsam> In-Reply-To: <9DD82042036148718A4568CD0EE548DA@v2comsam> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.40.73] 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, 14 May 2012 02:40:22 -0000 Sam, from the multi-PW draft, it seems only one PW is set up, but from the = emails, two PWs are set up. Thus I am not sure which approach is in your favor. RFC 4762 only needs one PW, and split horizon is used to guarrantee that le= af to leaf traffic is filtered, are you suggesting to use the same mechanis= m in 2PW? Thanks, Yuanlong -----Original Message----- From: Sam Cao [mailto:yuqun.cao@gmail.com]=20 Sent: Sunday, May 13, 2012 8:12 PM To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Yuanlong, Any bridging capable box will filter the traffic, or say, on the PE-rs. Multi-PW approach will fully comply with RFC 4762, and please read RFC 4762 and multi-PW draft. Regards, =20 Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com=20 =20 -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Friday, May 11, 2012 10:03 AM To: Daniel Cohn; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Daniel and all, When you set up two PWs from the PE-rs to a PE-r for each of its AC, do you mean that one PW is bidirectional root PW and the other is bidirectional leaf PW? My concern is: where should the leaf traffic be filtered, on the PE-rs or o= n the PE-r? If filtered on the PE-r, then lots of bandwidth will be wasted (for example= , if the PE-r is attached with 9 leafs, then the BUM traffic from one of its leafs will be multiplied by 8 times, and be forwarded by the PE-rs to the same PE-r). If filtered on the PE-rs, not sure how you will design its forwarding plane= , can you give a hint? Thanks, Yuanlong ------------------------------ Date: Wed, 9 May 2012 09:16:36 +0300 From: "Daniel Cohn" To: "Alexander Vainshtein" , "Sam Cao" , Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780CBA6@tlvmail1> Content-Type: text/plain; charset=3D"ISO-2022-JP" Hi Sasha, It's actually very simple. A frame that originated in a root AC is always transmitted only in root PW, no matter what the frame type (known/unknown unicast or broadcast). This is how the frame source information is propagated across the VPLS. So in the H-VPLS example, the PE-r will never forward a frame received over a root PW on any leaf PW, only on root PWs (toward the core or toward other spokes). Hope this clarifies it, regards, Daniel -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Alexander Vainshtein Sent: Wednesday, May 09, 2012 7:59 AM To: Sam Cao; l2vpn@ietf.org Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Sam, Lizhong and all, You've written that in the two-PW solution combined with H-VPLS the PE-r must set up two PWs with each MTU-s. If this is the case, what kind of forwarding logic should be used to preven= t sending a BUM frame received from a root-PW to a given MTU-S: - back to the same MTU-S on the corresponding leaf-PW? - twice (to both root-PW and Leaf-PW) to another MTU-s? And, BTW, how is th= e PW selected in this case? I am aware of a technique of multiple split horizon groups in PE-r which could be possibly used for this purpose. However, since these groups have t= o be represented explicitly in the data plane, their potential number is limited by the forwarding HW. Other methods could be probably used for the same purpose, but they would probably subject to similar HW-based limitations. I suspect that with the dual-PW approach, the HW would pose an implicit limit, say, on a number of MTU-s that can be connected to the same PE-r and that this limit could be quite low in most cases. Based on this I suspect that the H-VPLS issue as a critical drawback of the dual-PW approach to E-Tree. My 2c, Sasha ________________________________________ From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Sam Cao [yuqun.cao@gmail.com] Sent: Wednesday, May 09, 2012 3:40 AM To: l2vpn@ietf.org Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Hi Lizhong? Thank you very much for your comments. I updated the result on this question. [Lizhong] agree with the above analysis. And we did not say it is a technical problem, but it is an operational problem again. [Sam] I agree. Dual-VLAN does not make sense. I also discussed this with Giles and Yuanlong in another mail, and we reached agreement on this: MTU should know the access mode, VPWS or VPLS, VPWS mode should configure VLAN ID on MTU but VPLS mode can not. I thought this is NOT reasonable :), but w= e can figure this out in draft. It seems ok. [Lizhong] not fully understand. Do you mean, when VPWS accessing for H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf PW) for each AC access? [Sam] Yes. Thanks, Sam =20 From DanielC@orckit.com Mon May 14 00: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 40DF321F85A8 for ; Mon, 14 May 2012 00:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 r8E3aehLTwGS for ; Mon, 14 May 2012 00:34:08 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id F320C21F857D for ; Mon, 14 May 2012 00:33:53 -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: Discussion on E-Tree and H-VPLS Date: Mon, 14 May 2012 10:36:43 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780CF5C@tlvmail1> In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D411694@szxeml546-mbx.china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Discussion on E-Tree and H-VPLS Thread-Index: AQHNLxo31u2OjZw96UuBF9QPOwJXg5bHcLkA References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D411694@szxeml546-mbx.china.huawei.com> From: "Daniel Cohn" To: "Jiangyuanlong" , "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: Mon, 14 May 2012 07:34:09 -0000 Hi Yuanlong, As I see it, for the PE-r spoke (figure 4 in RFC 4762) we establish a single PW per AC - root PW for root AC and leaf PW for leaf AC. With local configuration at the PE-rs as part of the spoke PW provisioning. And the PE-rs will treat root/leaf spoke PWs exactly as it treat root/leaf ACs. So when leaf-originated BUM traffic arrives from the core (over a leaf PW), it will be forwarded over all root spoke PWs but not on the leaf spoke PWs.=20 The forwarding plane is exactly the same as described in the multi-PW draft, where spoke PWs are treated exactly like ACs. Regards, Daniel -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Friday, May 11, 2012 5:03 AM To: Daniel Cohn; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Daniel and all, When you set up two PWs from the PE-rs to a PE-r for each of its AC, do you mean that one PW is bidirectional root PW and the other is bidirectional leaf PW? My concern is: where should the leaf traffic be filtered, on the PE-rs or on the PE-r? If filtered on the PE-r, then lots of bandwidth will be wasted (for example, if the PE-r is attached with 9 leafs, then the BUM traffic from one of its leafs will be multiplied by 8 times, and be forwarded by the PE-rs to the same PE-r). If filtered on the PE-rs, not sure how you will design its forwarding plane, can you give a hint? Thanks, Yuanlong ------------------------------ Date: Wed, 9 May 2012 09:16:36 +0300 From: "Daniel Cohn" To: "Alexander Vainshtein" , "Sam Cao" , Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780CBA6@tlvmail1> Content-Type: text/plain; charset=3D"ISO-2022-JP" Hi Sasha, It's actually very simple. A frame that originated in a root AC is always transmitted only in root PW, no matter what the frame type (known/unknown unicast or broadcast). This is how the frame source information is propagated across the VPLS. So in the H-VPLS example, the PE-r will never forward a frame received over a root PW on any leaf PW, only on root PWs (toward the core or toward other spokes). Hope this clarifies it, regards, Daniel -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Alexander Vainshtein Sent: Wednesday, May 09, 2012 7:59 AM To: Sam Cao; l2vpn@ietf.org Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Sam, Lizhong and all, You've written that in the two-PW solution combined with H-VPLS the PE-r must set up two PWs with each MTU-s. If this is the case, what kind of forwarding logic should be used to prevent sending a BUM frame received from a root-PW to a given MTU-S: - back to the same MTU-S on the corresponding leaf-PW? - twice (to both root-PW and Leaf-PW) to another MTU-s? And, BTW, how is the PW selected in this case? I am aware of a technique of multiple split horizon groups in PE-r which could be possibly used for this purpose. However, since these groups have to be represented explicitly in the data plane, their potential number is limited by the forwarding HW. Other methods could be probably used for the same purpose, but they would probably subject to similar HW-based limitations. I suspect that with the dual-PW approach, the HW would pose an implicit limit, say, on a number of MTU-s that can be connected to the same PE-r and that this limit could be quite low in most cases. Based on this I suspect that the H-VPLS issue as a critical drawback of the dual-PW approach to E-Tree. My 2c, Sasha ________________________________________ From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Sam Cao [yuqun.cao@gmail.com] Sent: Wednesday, May 09, 2012 3:40 AM To: l2vpn@ietf.org Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Hi Lizhong? Thank you very much for your comments. I updated the result on this question. [Lizhong] agree with the above analysis. And we did not say it is a technical problem, but it is an operational problem again. [Sam] I agree. Dual-VLAN does not make sense. I also discussed this with Giles and Yuanlong in another mail, and we reached agreement on this: MTU should know the access mode, VPWS or VPLS, VPWS mode should configure VLAN ID on MTU but VPLS mode can not. I thought this is NOT reasonable :), but we can figure this out in draft. It seems ok. [Lizhong] not fully understand. Do you mean, when VPWS accessing for H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf PW) for each AC access? [Sam] Yes. Thanks, Sam =20 From jiangyuanlong@huawei.com Mon May 14 01:39: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 9F43621F85AE for ; Mon, 14 May 2012 01:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[AWL=0.254, 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 vkI1XVyAJG18 for ; Mon, 14 May 2012 01:39:14 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDDE21F859E for ; Mon, 14 May 2012 01:39:14 -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 AGD94599; Mon, 14 May 2012 04:39:14 -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; Mon, 14 May 2012 01:36:10 -0700 Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 14 May 2012 01:36:10 -0700 Received: from SZXEML546-MBS.china.huawei.com ([169.254.4.75]) by szxeml408-hub.china.huawei.com ([10.82.67.95]) with mapi id 14.01.0323.003; Mon, 14 May 2012 16:36:05 +0800 From: Jiangyuanlong To: Daniel Cohn , Alexander Vainshtein , Sam Cao Subject: RE: Discussion on E-Tree and H-VPLS Thread-Topic: Discussion on E-Tree and H-VPLS Thread-Index: AQHNLxo31u2OjZw96UuBF9QPOwJXg5bHcLkAgAGHLZA= Date: Mon, 14 May 2012 08:36:05 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D4130E1@szxeml546-mbs.china.huawei.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D411694@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF5C@tlvmail1> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA08130780CF5C@tlvmail1> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.40.73] 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, 14 May 2012 08:39:15 -0000 Daniel, please see my comments in line. -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Monday, May 14, 2012 3:37 PM To: Jiangyuanlong; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Yuanlong, As I see it, for the PE-r spoke (figure 4 in RFC 4762) we establish a single PW per AC - root PW for root AC and leaf PW for leaf AC. With local configuration at the PE-rs as part of the spoke PW provisioning. And the PE-rs will treat root/leaf spoke PWs exactly as it treat root/leaf ACs. So when leaf-originated BUM traffic arrives from the core (over a leaf PW), it will be forwarded over all root spoke PWs but not on the leaf spoke PWs.=20 [JY] So in the reverse direction, you need to transport both root and leaf = traffic from PE-rs over a root PW to PE-r, and transport root traffic over = a leaf PW. It seems against the definition of root PW and leaf PW in the mu= lti-PW draft. Don't this make the forwarding plane of PE-rs more complex?=20 The forwarding plane is exactly the same as described in the multi-PW draft, where spoke PWs are treated exactly like ACs. Regards, Daniel -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Friday, May 11, 2012 5:03 AM To: Daniel Cohn; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Daniel and all, When you set up two PWs from the PE-rs to a PE-r for each of its AC, do you mean that one PW is bidirectional root PW and the other is bidirectional leaf PW? My concern is: where should the leaf traffic be filtered, on the PE-rs or on the PE-r? If filtered on the PE-r, then lots of bandwidth will be wasted (for example, if the PE-r is attached with 9 leafs, then the BUM traffic from one of its leafs will be multiplied by 8 times, and be forwarded by the PE-rs to the same PE-r). If filtered on the PE-rs, not sure how you will design its forwarding plane, can you give a hint? Thanks, Yuanlong ------------------------------ Date: Wed, 9 May 2012 09:16:36 +0300 From: "Daniel Cohn" To: "Alexander Vainshtein" , "Sam Cao" , Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780CBA6@tlvmail1> Content-Type: text/plain; charset=3D"ISO-2022-JP" Hi Sasha, It's actually very simple. A frame that originated in a root AC is always transmitted only in root PW, no matter what the frame type (known/unknown unicast or broadcast). This is how the frame source information is propagated across the VPLS. So in the H-VPLS example, the PE-r will never forward a frame received over a root PW on any leaf PW, only on root PWs (toward the core or toward other spokes). Hope this clarifies it, regards, Daniel -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Alexander Vainshtein Sent: Wednesday, May 09, 2012 7:59 AM To: Sam Cao; l2vpn@ietf.org Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Sam, Lizhong and all, You've written that in the two-PW solution combined with H-VPLS the PE-r must set up two PWs with each MTU-s. If this is the case, what kind of forwarding logic should be used to prevent sending a BUM frame received from a root-PW to a given MTU-S: - back to the same MTU-S on the corresponding leaf-PW? - twice (to both root-PW and Leaf-PW) to another MTU-s? And, BTW, how is the PW selected in this case? I am aware of a technique of multiple split horizon groups in PE-r which could be possibly used for this purpose. However, since these groups have to be represented explicitly in the data plane, their potential number is limited by the forwarding HW. Other methods could be probably used for the same purpose, but they would probably subject to similar HW-based limitations. I suspect that with the dual-PW approach, the HW would pose an implicit limit, say, on a number of MTU-s that can be connected to the same PE-r and that this limit could be quite low in most cases. Based on this I suspect that the H-VPLS issue as a critical drawback of the dual-PW approach to E-Tree. My 2c, Sasha ________________________________________ From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Sam Cao [yuqun.cao@gmail.com] Sent: Wednesday, May 09, 2012 3:40 AM To: l2vpn@ietf.org Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Hi Lizhong? Thank you very much for your comments. I updated the result on this question. [Lizhong] agree with the above analysis. And we did not say it is a technical problem, but it is an operational problem again. [Sam] I agree. Dual-VLAN does not make sense. I also discussed this with Giles and Yuanlong in another mail, and we reached agreement on this: MTU should know the access mode, VPWS or VPLS, VPWS mode should configure VLAN ID on MTU but VPLS mode can not. I thought this is NOT reasonable :), but we can figure this out in draft. It seems ok. [Lizhong] not fully understand. Do you mean, when VPWS accessing for H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf PW) for each AC access? [Sam] Yes. Thanks, Sam =20 From DanielC@orckit.com Mon May 14 01: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 2CA7D21F8464 for ; Mon, 14 May 2012 01:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.115, 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 Pzyn8gyLShv1 for ; Mon, 14 May 2012 01:57:20 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id DBFD721F8456 for ; Mon, 14 May 2012 01:57:19 -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: Discussion on E-Tree and H-VPLS Date: Mon, 14 May 2012 12:00:09 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780CF8F@tlvmail1> In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D4130E1@szxeml546-mbs.china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Discussion on E-Tree and H-VPLS Thread-Index: AQHNLxo31u2OjZw96UuBF9QPOwJXg5bHcLkAgAGHLZCAAAmjYA== References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D411694@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF5C@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D4130E1@szxeml546-mbs.china.huawei.com> From: "Daniel Cohn" To: "Jiangyuanlong" , "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: Mon, 14 May 2012 08:57:21 -0000 Hi Yuanlong, Like I wrote below, root/leaf spoke PW behave like root/leaf AC, not like root/spoke "core PW". So no changes to forwarding plane once this is understood. DC -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Monday, May 14, 2012 11:36 AM To: Daniel Cohn; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Daniel, please see my comments in line. -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Monday, May 14, 2012 3:37 PM To: Jiangyuanlong; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Yuanlong, As I see it, for the PE-r spoke (figure 4 in RFC 4762) we establish a single PW per AC - root PW for root AC and leaf PW for leaf AC. With local configuration at the PE-rs as part of the spoke PW provisioning. And the PE-rs will treat root/leaf spoke PWs exactly as it treat root/leaf ACs. So when leaf-originated BUM traffic arrives from the core (over a leaf PW), it will be forwarded over all root spoke PWs but not on the leaf spoke PWs.=20 [JY] So in the reverse direction, you need to transport both root and leaf traffic from PE-rs over a root PW to PE-r, and transport root traffic over a leaf PW. It seems against the definition of root PW and leaf PW in the multi-PW draft. Don't this make the forwarding plane of PE-rs more complex?=20 The forwarding plane is exactly the same as described in the multi-PW draft, where spoke PWs are treated exactly like ACs. Regards, Daniel -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Friday, May 11, 2012 5:03 AM To: Daniel Cohn; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Daniel and all, When you set up two PWs from the PE-rs to a PE-r for each of its AC, do you mean that one PW is bidirectional root PW and the other is bidirectional leaf PW? My concern is: where should the leaf traffic be filtered, on the PE-rs or on the PE-r? If filtered on the PE-r, then lots of bandwidth will be wasted (for example, if the PE-r is attached with 9 leafs, then the BUM traffic from one of its leafs will be multiplied by 8 times, and be forwarded by the PE-rs to the same PE-r). If filtered on the PE-rs, not sure how you will design its forwarding plane, can you give a hint? Thanks, Yuanlong ------------------------------ Date: Wed, 9 May 2012 09:16:36 +0300 From: "Daniel Cohn" To: "Alexander Vainshtein" , "Sam Cao" , Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780CBA6@tlvmail1> Content-Type: text/plain; charset=3D"ISO-2022-JP" Hi Sasha, It's actually very simple. A frame that originated in a root AC is always transmitted only in root PW, no matter what the frame type (known/unknown unicast or broadcast). This is how the frame source information is propagated across the VPLS. So in the H-VPLS example, the PE-r will never forward a frame received over a root PW on any leaf PW, only on root PWs (toward the core or toward other spokes). Hope this clarifies it, regards, Daniel -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Alexander Vainshtein Sent: Wednesday, May 09, 2012 7:59 AM To: Sam Cao; l2vpn@ietf.org Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Sam, Lizhong and all, You've written that in the two-PW solution combined with H-VPLS the PE-r must set up two PWs with each MTU-s. If this is the case, what kind of forwarding logic should be used to prevent sending a BUM frame received from a root-PW to a given MTU-S: - back to the same MTU-S on the corresponding leaf-PW? - twice (to both root-PW and Leaf-PW) to another MTU-s? And, BTW, how is the PW selected in this case? I am aware of a technique of multiple split horizon groups in PE-r which could be possibly used for this purpose. However, since these groups have to be represented explicitly in the data plane, their potential number is limited by the forwarding HW. Other methods could be probably used for the same purpose, but they would probably subject to similar HW-based limitations. I suspect that with the dual-PW approach, the HW would pose an implicit limit, say, on a number of MTU-s that can be connected to the same PE-r and that this limit could be quite low in most cases. Based on this I suspect that the H-VPLS issue as a critical drawback of the dual-PW approach to E-Tree. My 2c, Sasha ________________________________________ From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Sam Cao [yuqun.cao@gmail.com] Sent: Wednesday, May 09, 2012 3:40 AM To: l2vpn@ietf.org Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Hi Lizhong? Thank you very much for your comments. I updated the result on this question. [Lizhong] agree with the above analysis. And we did not say it is a technical problem, but it is an operational problem again. [Sam] I agree. Dual-VLAN does not make sense. I also discussed this with Giles and Yuanlong in another mail, and we reached agreement on this: MTU should know the access mode, VPWS or VPLS, VPWS mode should configure VLAN ID on MTU but VPLS mode can not. I thought this is NOT reasonable :), but we can figure this out in draft. It seems ok. [Lizhong] not fully understand. Do you mean, when VPWS accessing for H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf PW) for each AC access? [Sam] Yes. Thanks, Sam =20 From jiangyuanlong@huawei.com Mon May 14 04:12: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 1F55421F8469 for ; Mon, 14 May 2012 04:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 I9D-ckdE6Mrv for ; Mon, 14 May 2012 04:12:33 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 22CDB21F8453 for ; Mon, 14 May 2012 04:12:33 -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 AFX07122; Mon, 14 May 2012 07:12:32 -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, 14 May 2012 04:10:00 -0700 Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 14 May 2012 04:09:58 -0700 Received: from SZXEML546-MBS.china.huawei.com ([169.254.4.75]) by szxeml418-hub.china.huawei.com ([10.82.67.157]) with mapi id 14.01.0323.003; Mon, 14 May 2012 19:09:52 +0800 From: Jiangyuanlong To: Daniel Cohn , Alexander Vainshtein , Sam Cao Subject: RE: Discussion on E-Tree and H-VPLS Thread-Topic: Discussion on E-Tree and H-VPLS Thread-Index: AQHNLxo31u2OjZw96UuBF9QPOwJXg5bHcLkAgAGHLZCAAAmjYIAAHGPg Date: Mon, 14 May 2012 11:09:51 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413216@szxeml546-mbs.china.huawei.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D411694@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF5C@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D4130E1@szxeml546-mbs.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF8F@tlvmail1> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA08130780CF8F@tlvmail1> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.40.73] 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, 14 May 2012 11:12:34 -0000 Hi Daniel, Fine, now it seems more in line with what we had proposed in 2VLAN: a spoke= PW behaves like root/leaf AC for a PE-r. But the same problem may also apply to the root/spoke "core PW" for Multi-P= W: According to Multi-PW, only one PW is required between two PEs except when = both PEs are mixed with root and leaf, so these PWs may be formed by combin= ations of the following unidirectional PW cases (extracted and adapted from= Josh's email): Root-only -> any VSI =3D one root PW Leaf-only -> root-only =3D one leaf PW Leaf-only -> mixed =3D one leaf PW=20 Mixed -> root-only =3D one (root+leaf) PW =20 Mixed -> leaf-only =3D one (root+leaf) PW =20 I have a concern that the forwarding plane of PE to implement this will be = very different from the traditional VPLS. Regards, Yuanlong -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Monday, May 14, 2012 5:00 PM To: Jiangyuanlong; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Yuanlong, Like I wrote below, root/leaf spoke PW behave like root/leaf AC, not like root/spoke "core PW". So no changes to forwarding plane once this is understood. DC -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Monday, May 14, 2012 11:36 AM To: Daniel Cohn; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Daniel, please see my comments in line. -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Monday, May 14, 2012 3:37 PM To: Jiangyuanlong; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Yuanlong, As I see it, for the PE-r spoke (figure 4 in RFC 4762) we establish a single PW per AC - root PW for root AC and leaf PW for leaf AC. With local configuration at the PE-rs as part of the spoke PW provisioning. And the PE-rs will treat root/leaf spoke PWs exactly as it treat root/leaf ACs. So when leaf-originated BUM traffic arrives from the core (over a leaf PW), it will be forwarded over all root spoke PWs but not on the leaf spoke PWs.=20 [JY] So in the reverse direction, you need to transport both root and leaf traffic from PE-rs over a root PW to PE-r, and transport root traffic over a leaf PW. It seems against the definition of root PW and leaf PW in the multi-PW draft. Don't this make the forwarding plane of PE-rs more complex?=20 The forwarding plane is exactly the same as described in the multi-PW draft, where spoke PWs are treated exactly like ACs. Regards, Daniel -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Friday, May 11, 2012 5:03 AM To: Daniel Cohn; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Daniel and all, When you set up two PWs from the PE-rs to a PE-r for each of its AC, do you mean that one PW is bidirectional root PW and the other is bidirectional leaf PW? My concern is: where should the leaf traffic be filtered, on the PE-rs or on the PE-r? If filtered on the PE-r, then lots of bandwidth will be wasted (for example, if the PE-r is attached with 9 leafs, then the BUM traffic from one of its leafs will be multiplied by 8 times, and be forwarded by the PE-rs to the same PE-r). If filtered on the PE-rs, not sure how you will design its forwarding plane, can you give a hint? Thanks, Yuanlong ------------------------------ Date: Wed, 9 May 2012 09:16:36 +0300 From: "Daniel Cohn" To: "Alexander Vainshtein" , "Sam Cao" , Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780CBA6@tlvmail1> Content-Type: text/plain; charset=3D"ISO-2022-JP" Hi Sasha, It's actually very simple. A frame that originated in a root AC is always transmitted only in root PW, no matter what the frame type (known/unknown unicast or broadcast). This is how the frame source information is propagated across the VPLS. So in the H-VPLS example, the PE-r will never forward a frame received over a root PW on any leaf PW, only on root PWs (toward the core or toward other spokes). Hope this clarifies it, regards, Daniel -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Alexander Vainshtein Sent: Wednesday, May 09, 2012 7:59 AM To: Sam Cao; l2vpn@ietf.org Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Sam, Lizhong and all, You've written that in the two-PW solution combined with H-VPLS the PE-r must set up two PWs with each MTU-s. If this is the case, what kind of forwarding logic should be used to prevent sending a BUM frame received from a root-PW to a given MTU-S: - back to the same MTU-S on the corresponding leaf-PW? - twice (to both root-PW and Leaf-PW) to another MTU-s? And, BTW, how is the PW selected in this case? I am aware of a technique of multiple split horizon groups in PE-r which could be possibly used for this purpose. However, since these groups have to be represented explicitly in the data plane, their potential number is limited by the forwarding HW. Other methods could be probably used for the same purpose, but they would probably subject to similar HW-based limitations. I suspect that with the dual-PW approach, the HW would pose an implicit limit, say, on a number of MTU-s that can be connected to the same PE-r and that this limit could be quite low in most cases. Based on this I suspect that the H-VPLS issue as a critical drawback of the dual-PW approach to E-Tree. My 2c, Sasha ________________________________________ From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Sam Cao [yuqun.cao@gmail.com] Sent: Wednesday, May 09, 2012 3:40 AM To: l2vpn@ietf.org Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Hi Lizhong? Thank you very much for your comments. I updated the result on this question. [Lizhong] agree with the above analysis. And we did not say it is a technical problem, but it is an operational problem again. [Sam] I agree. Dual-VLAN does not make sense. I also discussed this with Giles and Yuanlong in another mail, and we reached agreement on this: MTU should know the access mode, VPWS or VPLS, VPWS mode should configure VLAN ID on MTU but VPLS mode can not. I thought this is NOT reasonable :), but we can figure this out in draft. It seems ok. [Lizhong] not fully understand. Do you mean, when VPWS accessing for H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf PW) for each AC access? [Sam] Yes. Thanks, Sam =20 From yuqun.cao@gmail.com Mon May 14 05:32: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 9EA7321F8664 for ; Mon, 14 May 2012 05:32:17 -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 mgbCW7QsgTvx for ; Mon, 14 May 2012 05:32:16 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id B524321F8652 for ; Mon, 14 May 2012 05:32:16 -0700 (PDT) Received: by dacx6 with SMTP id x6so6056036dac.31 for ; Mon, 14 May 2012 05:32:16 -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=j2ZVNl4f7U6ZBtMxKUL6BjmaRFwyBu/JjRvqyFUekW0=; b=WdZFfJDK9nJ3AyBXWZUNZhn3vw8jka5vN1a0P0pt6w1eJVCYCWtXjKCVAwCimh6CRL EnQT+SzWKAgken2U5gN0veccd+41U56FeTKXMqYj8b1DlnaR1bLjYHpF4OzE7M+BG0l0 G9Cg1dSr2K2qbrvHBIW/S3h6TFjFlsf8s8arfTIwJyj80iAzR/zLPwjLUcGhmB2VumyH vTmyaXuueV2pqlowupMBMMg868JrNFGVoTHyXp7GUL8bBWOF14VCSr6JvCy0drxCwjvv fh9caxOFDlX/+TdtuPoxqkgC4TonYu1Cyn6GUssWiOi3TZe3/ixKzW0t5cCm/5e+PmK3 d11Q== Received: by 10.68.230.33 with SMTP id sv1mr7823058pbc.1.1336998736388; Mon, 14 May 2012 05:32:16 -0700 (PDT) Received: from v2comsam ([36.248.0.44]) by mx.google.com with ESMTPS id rt4sm22172042pbc.3.2012.05.14.05.31.30 (version=SSLv3 cipher=OTHER); Mon, 14 May 2012 05:32:14 -0700 (PDT) From: "Sam Cao" To: "'Jiangyuanlong'" , "'Daniel Cohn'" , "'Alexander Vainshtein'" References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D411694@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF5C@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D4130E1@szxeml546-mbs.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF8F@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413216@szxeml546-mbs.china.huawei.com> Subject: RE: Discussion on E-Tree and H-VPLS Date: Mon, 14 May 2012 20:31:05 +0800 Message-ID: <3F1F3739E2B04D399CC7D26CE934F91A@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: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413216@szxeml546-mbs.china.huawei.com> Thread-index: AQHNLxo31u2OjZw96UuBF9QPOwJXg5bHcLkAgAGHLZCAAAmjYIAAHGPggAAUqSA= 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, 14 May 2012 12:32:17 -0000 Hi Yuanlong, We have discussed this in another thread. In fact, Daniel or I have given the answers to the questions you raised here for several time :). If we do in this way, we will reach deadlock and can not move forward :). I try to explain it again. As you know, initial design we will setup 2 PWs all the time (if do in this way, I think that you have no question), but in most cases 2 PWs are not necessary. So in 01 version, we optimize it. "Root-only VSI <-> any VSI: only root PW required" "Leaf-only VSI <-> leaf-only VSI: no PWs required" In other cases 2 PWs are needed. If so, "Leaf-only -> root-only = one leaf PW" is not correct: On Leaf-only side, yes, one Leaf-only PW is created between Local Leaf type with remote Root type; on root-only side, one root-only PW is created. Maybe it is better to call this as compatible or mixed PW. So the left items you list are not correct for multi_PW solution. BTW, I guess you also care this case we also have discussed before: for example, if we configure one Leaf AC on root-only PE (then it will be root-leaf-mixed PE), we will teardown the compatible PW and re-setup PWs again with 01. Regards, Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] Sent: Monday, May 14, 2012 7:10 PM To: Daniel Cohn; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Daniel, Fine, now it seems more in line with what we had proposed in 2VLAN: a spoke PW behaves like root/leaf AC for a PE-r. But the same problem may also apply to the root/spoke "core PW" for Multi-PW: According to Multi-PW, only one PW is required between two PEs except when both PEs are mixed with root and leaf, so these PWs may be formed by combinations of the following unidirectional PW cases (extracted and adapted from Josh's email): Root-only -> any VSI = one root PW Leaf-only -> root-only = one leaf PW Leaf-only -> mixed = one leaf PW Mixed -> root-only = one (root+leaf) PW Mixed -> leaf-only = one (root+leaf) PW I have a concern that the forwarding plane of PE to implement this will be very different from the traditional VPLS. Regards, Yuanlong -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: Monday, May 14, 2012 5:00 PM To: Jiangyuanlong; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Yuanlong, Like I wrote below, root/leaf spoke PW behave like root/leaf AC, not like root/spoke "core PW". So no changes to forwarding plane once this is understood. DC -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] Sent: Monday, May 14, 2012 11:36 AM To: Daniel Cohn; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Daniel, please see my comments in line. -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: Monday, May 14, 2012 3:37 PM To: Jiangyuanlong; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Yuanlong, As I see it, for the PE-r spoke (figure 4 in RFC 4762) we establish a single PW per AC - root PW for root AC and leaf PW for leaf AC. With local configuration at the PE-rs as part of the spoke PW provisioning. And the PE-rs will treat root/leaf spoke PWs exactly as it treat root/leaf ACs. So when leaf-originated BUM traffic arrives from the core (over a leaf PW), it will be forwarded over all root spoke PWs but not on the leaf spoke PWs. [JY] So in the reverse direction, you need to transport both root and leaf traffic from PE-rs over a root PW to PE-r, and transport root traffic over a leaf PW. It seems against the definition of root PW and leaf PW in the multi-PW draft. Don't this make the forwarding plane of PE-rs more complex? The forwarding plane is exactly the same as described in the multi-PW draft, where spoke PWs are treated exactly like ACs. Regards, Daniel -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] Sent: Friday, May 11, 2012 5:03 AM To: Daniel Cohn; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Daniel and all, When you set up two PWs from the PE-rs to a PE-r for each of its AC, do you mean that one PW is bidirectional root PW and the other is bidirectional leaf PW? My concern is: where should the leaf traffic be filtered, on the PE-rs or on the PE-r? If filtered on the PE-r, then lots of bandwidth will be wasted (for example, if the PE-r is attached with 9 leafs, then the BUM traffic from one of its leafs will be multiplied by 8 times, and be forwarded by the PE-rs to the same PE-r). If filtered on the PE-rs, not sure how you will design its forwarding plane, can you give a hint? Thanks, Yuanlong ------------------------------ Date: Wed, 9 May 2012 09:16:36 +0300 From: "Daniel Cohn" To: "Alexander Vainshtein" , "Sam Cao" , Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780CBA6@tlvmail1> Content-Type: text/plain; charset="ISO-2022-JP" Hi Sasha, It's actually very simple. A frame that originated in a root AC is always transmitted only in root PW, no matter what the frame type (known/unknown unicast or broadcast). This is how the frame source information is propagated across the VPLS. So in the H-VPLS example, the PE-r will never forward a frame received over a root PW on any leaf PW, only on root PWs (toward the core or toward other spokes). Hope this clarifies it, regards, Daniel -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Alexander Vainshtein Sent: Wednesday, May 09, 2012 7:59 AM To: Sam Cao; l2vpn@ietf.org Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Sam, Lizhong and all, You've written that in the two-PW solution combined with H-VPLS the PE-r must set up two PWs with each MTU-s. If this is the case, what kind of forwarding logic should be used to prevent sending a BUM frame received from a root-PW to a given MTU-S: - back to the same MTU-S on the corresponding leaf-PW? - twice (to both root-PW and Leaf-PW) to another MTU-s? And, BTW, how is the PW selected in this case? I am aware of a technique of multiple split horizon groups in PE-r which could be possibly used for this purpose. However, since these groups have to be represented explicitly in the data plane, their potential number is limited by the forwarding HW. Other methods could be probably used for the same purpose, but they would probably subject to similar HW-based limitations. I suspect that with the dual-PW approach, the HW would pose an implicit limit, say, on a number of MTU-s that can be connected to the same PE-r and that this limit could be quite low in most cases. Based on this I suspect that the H-VPLS issue as a critical drawback of the dual-PW approach to E-Tree. My 2c, Sasha ________________________________________ From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Sam Cao [yuqun.cao@gmail.com] Sent: Wednesday, May 09, 2012 3:40 AM To: l2vpn@ietf.org Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Hi Lizhong? Thank you very much for your comments. I updated the result on this question. [Lizhong] agree with the above analysis. And we did not say it is a technical problem, but it is an operational problem again. [Sam] I agree. Dual-VLAN does not make sense. I also discussed this with Giles and Yuanlong in another mail, and we reached agreement on this: MTU should know the access mode, VPWS or VPLS, VPWS mode should configure VLAN ID on MTU but VPLS mode can not. I thought this is NOT reasonable :), but we can figure this out in draft. It seems ok. [Lizhong] not fully understand. Do you mean, when VPWS accessing for H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf PW) for each AC access? [Sam] Yes. Thanks, Sam From jiangyuanlong@huawei.com Mon May 14 19:30: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 2DB6821F88AA for ; Mon, 14 May 2012 19:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.356 X-Spam-Level: X-Spam-Status: No, score=-2.356 tagged_above=-999 required=5 tests=[AWL=0.243, 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 t56lH0AqaBJu for ; Mon, 14 May 2012 19:29:59 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1551921F86F7 for ; Mon, 14 May 2012 19:29:59 -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 AGE64092; Mon, 14 May 2012 22:29:58 -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, 14 May 2012 19:26:47 -0700 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 14 May 2012 19:26:48 -0700 Received: from SZXEML546-MBS.china.huawei.com ([169.254.4.75]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0323.003; Tue, 15 May 2012 10:26:46 +0800 From: Jiangyuanlong To: Sam Cao , 'Daniel Cohn' , 'Alexander Vainshtein' Subject: RE: Discussion on E-Tree and H-VPLS Thread-Topic: Discussion on E-Tree and H-VPLS Thread-Index: AQHNLxo31u2OjZw96UuBF9QPOwJXg5bHcLkAgAGHLZCAAAmjYIAAHGPggAAUqSCAAOHDIA== Date: Tue, 15 May 2012 02:26:45 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413694@szxeml546-mbs.china.huawei.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D411694@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF5C@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D4130E1@szxeml546-mbs.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF8F@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413216@szxeml546-mbs.china.huawei.com> <3F1F3739E2B04D399CC7D26CE934F91A@v2comsam> In-Reply-To: <3F1F3739E2B04D399CC7D26CE934F91A@v2comsam> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.40.73] 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, 15 May 2012 02:30:00 -0000 Please see my comments in line. -----Original Message----- From: Sam Cao [mailto:yuqun.cao@gmail.com]=20 Sent: Monday, May 14, 2012 8:31 PM To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Yuanlong, We have discussed this in another thread. In fact, Daniel or I have given the answers to the questions you raised here for several time :). If we do in this way, we will reach deadlock and can not move forward :). I try to explain it again. [JY] I will apologize if you had ever provided such answers before, and you= may just refer to the links rather than repeat the explanation. As you can see, I just try to understand the mechanism of 2PW and its impli= cations, but the I-D does not include enough information. As you know, initial design we will setup 2 PWs all the time (if do in this way, I think that you have no question),=20 [JY] I will be concerned with the operational complexity of this approach. but in most cases 2 PWs are not necessary. So in 01 version, we optimize it. "Root-only VSI <-> any VSI: only root PW required" "Leaf-only VSI <-> leaf-only VSI: no PWs required" In other cases 2 PWs are needed. If so, "Leaf-only -> root-only =3D one lea= f PW" is not correct: On Leaf-only side, yes, one Leaf-only PW is created between Local Leaf type with remote Root type; on root-only side, one root-only PW is created. Maybe it is better to call this as compatible or mixed PW. So the left items you list are not correct for multi_PW solution. [JY] This is something new, right? To be honest, I could not understand wha= t is your point: doesn't the mixed PW as you called also consist of one Lea= f-only PW in one direction and one root-only PW in the other direction? Fur= thermore, the case you took is also one case in your guideline "Root-only V= SI <-> any VSI: only root PW required", don't you think that only one root = PW is required following this guideline? Actually, I don't care much about what is the bidirectional PW or unidirect= ional PW called, but how can a VSI support such a mixed scenarios: traditio= nal VSI assumes only one PW is required for each peer VSI, and its MAC lean= ing is based on bidirectional PW. But for 2PW, there are bidirectional root= PW, bidirectional leaf PW, mixed PW, etc..., how to support these kinds of= PWs in the same VSI is my top concern. BTW, I guess you also care this case we also have discussed before: for example, if we configure one Leaf AC on root-only PE (then it will be root-leaf-mixed PE), we will teardown the compatible PW and re-setup PWs again with 01.=20 [JY] This was discussed in the emails indeed. Regards, =20 Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com=20 =20 -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Monday, May 14, 2012 7:10 PM To: Daniel Cohn; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Daniel, Fine, now it seems more in line with what we had proposed in 2VLAN: a spoke PW behaves like root/leaf AC for a PE-r. But the same problem may also apply to the root/spoke "core PW" for Multi-PW: According to Multi-PW, only one PW is required between two PEs except when both PEs are mixed with root and leaf, so these PWs may be formed by combinations of the following unidirectional PW cases (extracted and adapte= d from Josh's email): Root-only -> any VSI =3D one root PW Leaf-only -> root-only =3D one leaf PW Leaf-only -> mixed =3D one leaf PW=20 Mixed -> root-only =3D one (root+leaf) PW =20 Mixed -> leaf-only =3D one (root+leaf) PW =20 I have a concern that the forwarding plane of PE to implement this will be very different from the traditional VPLS. Regards, Yuanlong -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Monday, May 14, 2012 5:00 PM To: Jiangyuanlong; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Yuanlong, Like I wrote below, root/leaf spoke PW behave like root/leaf AC, not like root/spoke "core PW". So no changes to forwarding plane once this is understood. DC -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Monday, May 14, 2012 11:36 AM To: Daniel Cohn; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Daniel, please see my comments in line. -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Monday, May 14, 2012 3:37 PM To: Jiangyuanlong; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Yuanlong, As I see it, for the PE-r spoke (figure 4 in RFC 4762) we establish a single PW per AC - root PW for root AC and leaf PW for leaf AC. With local configuration at the PE-rs as part of the spoke PW provisioning. And the PE-rs will treat root/leaf spoke PWs exactly as it treat root/leaf ACs. So when leaf-originated BUM traffic arrives from the core (over a leaf PW), it will be forwarded over all root spoke PWs but not on the leaf spoke PWs.=20 [JY] So in the reverse direction, you need to transport both root and leaf traffic from PE-rs over a root PW to PE-r, and transport root traffic over a leaf PW. It seems against the definition of root PW and leaf PW in the multi-PW draft. Don't this make the forwarding plane of PE-rs more complex?=20 The forwarding plane is exactly the same as described in the multi-PW draft, where spoke PWs are treated exactly like ACs. Regards, Daniel -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Friday, May 11, 2012 5:03 AM To: Daniel Cohn; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Daniel and all, When you set up two PWs from the PE-rs to a PE-r for each of its AC, do you mean that one PW is bidirectional root PW and the other is bidirectional leaf PW? My concern is: where should the leaf traffic be filtered, on the PE-rs or on the PE-r? If filtered on the PE-r, then lots of bandwidth will be wasted (for example, if the PE-r is attached with 9 leafs, then the BUM traffic from one of its leafs will be multiplied by 8 times, and be forwarded by the PE-rs to the same PE-r). If filtered on the PE-rs, not sure how you will design its forwarding plane, can you give a hint? Thanks, Yuanlong ------------------------------ Date: Wed, 9 May 2012 09:16:36 +0300 From: "Daniel Cohn" To: "Alexander Vainshtein" , "Sam Cao" , Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780CBA6@tlvmail1> Content-Type: text/plain; charset=3D"ISO-2022-JP" Hi Sasha, It's actually very simple. A frame that originated in a root AC is always transmitted only in root PW, no matter what the frame type (known/unknown unicast or broadcast). This is how the frame source information is propagated across the VPLS. So in the H-VPLS example, the PE-r will never forward a frame received over a root PW on any leaf PW, only on root PWs (toward the core or toward other spokes). Hope this clarifies it, regards, Daniel -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Alexander Vainshtein Sent: Wednesday, May 09, 2012 7:59 AM To: Sam Cao; l2vpn@ietf.org Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Sam, Lizhong and all, You've written that in the two-PW solution combined with H-VPLS the PE-r must set up two PWs with each MTU-s. If this is the case, what kind of forwarding logic should be used to prevent sending a BUM frame received from a root-PW to a given MTU-S: - back to the same MTU-S on the corresponding leaf-PW? - twice (to both root-PW and Leaf-PW) to another MTU-s? And, BTW, how is the PW selected in this case? I am aware of a technique of multiple split horizon groups in PE-r which could be possibly used for this purpose. However, since these groups have to be represented explicitly in the data plane, their potential number is limited by the forwarding HW. Other methods could be probably used for the same purpose, but they would probably subject to similar HW-based limitations. I suspect that with the dual-PW approach, the HW would pose an implicit limit, say, on a number of MTU-s that can be connected to the same PE-r and that this limit could be quite low in most cases. Based on this I suspect that the H-VPLS issue as a critical drawback of the dual-PW approach to E-Tree. My 2c, Sasha ________________________________________ From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Sam Cao [yuqun.cao@gmail.com] Sent: Wednesday, May 09, 2012 3:40 AM To: l2vpn@ietf.org Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Hi Lizhong? Thank you very much for your comments. I updated the result on this question. [Lizhong] agree with the above analysis. And we did not say it is a technical problem, but it is an operational problem again. [Sam] I agree. Dual-VLAN does not make sense. I also discussed this with Giles and Yuanlong in another mail, and we reached agreement on this: MTU should know the access mode, VPWS or VPLS, VPWS mode should configure VLAN ID on MTU but VPLS mode can not. I thought this is NOT reasonable :), but we can figure this out in draft. It seems ok. [Lizhong] not fully understand. Do you mean, when VPWS accessing for H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf PW) for each AC access? [Sam] Yes. Thanks, Sam =20 From xuxiaohu@huawei.com Mon May 14 20:29: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 483779E800B; Mon, 14 May 2012 20:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.355 X-Spam-Level: * X-Spam-Status: No, score=1.355 tagged_above=-999 required=5 tests=[AWL=-0.588, 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 4Z-cL+83iYpg; Mon, 14 May 2012 20:29:03 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 76C3C9E8004; Mon, 14 May 2012 20:29:03 -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 AGE68409; Mon, 14 May 2012 23:29:03 -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, 14 May 2012 20:26:31 -0700 Received: from SZXEML440-HUB.china.huawei.com (10.72.61.75) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 14 May 2012 20:26:33 -0700 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.32]) by SZXEML440-HUB.china.huawei.com ([10.72.61.75]) with mapi id 14.01.0323.003; Tue, 15 May 2012 11:26:30 +0800 From: Xuxiaohu To: Joe Touch , "Tissa Senevirathne (tsenevir)" Subject: re: [trill] Should we make draft-mrw-trill-over-ip-01 a WG document? Thread-Topic: [trill] Should we make draft-mrw-trill-over-ip-01 a WG document? Thread-Index: Ac0v14OF2W91gDgpTRy9oRvF6ilJagB9fm5w//+AygCAAAVsgIAAFLEAgAAJvICAAAHZgP/+tqqA Date: Tue, 15 May 2012 03:26:30 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02F30AB3@szxeml525-mbs.china.huawei.com> References: <4FADB0E8.1090000@acm.org> <344037D7CFEFE84E97E9CC1F56C5F4A5011CAF33@xmb-sjc-214.amer.cisco.com> <4FB100EC.9090203@workingcode.com> <344037D7CFEFE84E97E9CC1F56C5F4A5011CAF43@xmb-sjc-214.amer.cisco.com> <4FB116D4.8060008@workingcode.com> <344037D7CFEFE84E97E9CC1F56C5F4A5011CAF89@xmb-sjc-214.amer.cisco.com> <4FB1208B.8070103@isi.edu> In-Reply-To: <4FB1208B.8070103@isi.edu> 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 Cc: "l2vpn@ietf.org" , Erik Nordmark , "trill@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, 15 May 2012 03:29:04 -0000 DQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6IHRyaWxsLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzp0cmlsbC1ib3VuY2VzQGlldGYub3JnXSC0+rHtIEpvZSBUb3VjaA0KPiC3osvNyrG8 5DogMjAxMsTqNdTCMTTI1SAyMzoxMQ0KPiDK1bz+yMs6IFRpc3NhIFNlbmV2aXJhdGhuZSAodHNl bmV2aXIpDQo+ILOty806IEVyaWsgTm9yZG1hcms7IHRyaWxsQGlldGYub3JnDQo+INb3zOI6IFJl OiBbdHJpbGxdIFNob3VsZCB3ZSBtYWtlIGRyYWZ0LW1ydy10cmlsbC1vdmVyLWlwLTAxIGEgV0cg ZG9jdW1lbnQ/DQo+IA0KPiBSZWdhcmRpbmcgdGhpcyBhcHByb2FjaCwgSSdtIGFsc28gd29uZGVy aW5nIHdoeSBUUklMTC1vdmVyLUlQPw0KPiANCj4gU2luY2UgVFJJTEwgaXMgb3ZlciBldGhlcm5l dCwgYW5kIGV0aGVybmV0IGlzIG92ZXIgSVAsIHdoeSBpcyBhIHNwZWNpZmljDQo+IHNvbHV0aW9u IGZvciBUUklMTCBvdmVyIElQIGV2ZW4gbmVlZGVkPyBTZWVtcyBsaWtlIGEgbG90IG9mIHBvdGVu dGlhbA0KPiBjb21wbGV4aXR5IHRvIHNhdmUgMTggYnl0ZXMuDQoNClRoZSBmb2xsb3dpbmcgaXMg cXVvdGVkIGZyb20gc2VjdGlvbiA5LjEgIlRSSUxMIE5pY2tuYW1lIEFkdmVydGlzZW1lbnQgUm91 dGUiIG9mIGRyYWZ0LWlldGYtbDJ2cG4tcGJiLWV2cG4tMDA6DQoNCiAgICJJdCBpcyB3b3J0aCBu b3RpbmcgaGVyZSB0aGF0IHdoaWxlIGl0IGlzIHBvc3NpYmxlIHRvIHRyYW5zcG9ydA0KICAgRXRo ZXJuZXQgZW5jYXBzdWxhdGVkIFRSSUxMIGZyYW1lcyBvdmVyIE1QTFMsIHRoYXQgYXBwcm9hY2gN CiAgIHVubmVjZXNzYXJpbHkgd2FzdGVzIDE2IGJ5dGVzIHBlciBwYWNrZXQuIFRoYXQgYXBwcm9h Y2ggZnVydGhlcg0KICAgcmVxdWlyZXMgZWl0aGVyIHRoZSB1c2Ugb2Ygd2VsbC1rbm93biBNQUMg YWRkcmVzc2VzIG9yIGhhdmluZyB0aGUNCiAgIE1FUyBub2RlcyBhZHZlcnRpc2UgaW4gQkdQIHRo ZWlyIGRldmljZSBNQUMgYWRkcmVzc2VzLCBpbiBvcmRlciB0bw0KICAgcmVzb2x2ZSB0aGUgVFJJ TEwgbmV4dC1ob3AgTDIgYWRqYWNlbmN5LiBUbyB0aGF0IGVuZCwgaXQgaXMgc2ltcGxlcg0KICAg YW5kIG1vcmUgZWZmaWNpZW50IHRvIHRyYW5zcG9ydCBUUklMTCBuYXRpdmVseSBvdmVyIE1QTFMg YW5kIHRoYXQgaXMNCiAgIHdoeSB3ZSBhcmUgZGVmaW5pbmcgdGhlIGFib3ZlIEJHUCByb3V0ZSBm b3IgVFJJTEwgTmlja25hbWUNCiAgIGFkdmVydGlzZW1lbnQuIg0KDQpJdCBzZWVtcyB0aGF0IHRo ZXJlIGlzIGEgc3Ryb25nIG1vdGl2YXRpb24gZm9yIFBCQi1FVlBOIGZvbGtzIHRvIHNhdmUgdGhh dCAxOCBieXRlcyB0b28uDQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0KDQo+IEpvZQ0KPiANCj4g T24gNS8xNC8yMDEyIDg6MDQgQU0sIFRpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2aXIpIHdyb3Rl Og0KPiA+IEhpIEphbWVzDQo+ID4NCj4gPiBJIHRoaW5rIHdlIGFyZSBhZ3JlZWluZyBvbiBsb3Rz IHBvaW50cyBleGNlcHQgb25lIGltcG9ydGFudCBwb2ludCBpLmUuDQo+ID4gU0hPVUxEIG9yIFNI T1VMRCBOT1QgbWFrZSBpbmRpdmlkdWFsIHN1Ym1pc3Npb25zIFdHIGRvY3Mgd2l0aG91dCBhDQo+ ID4gc3RyYXRlZ3kuDQo+ID4NCj4gPiBNeSBtYWluIG9iamVjdGlvbiBvZiBtYWtpbmcgaW5kaXZp ZHVhbCBzdWJtaXNzaW9ucyBXRyBkb2NzIHdpdGhvdXQgd2VsbA0KPiA+IHRob3VnaHQgdGhyb3Vn aCBzdHJhdGVneSBpcyBpdCB0YWtlcyBhd2F5IHRoZSBmb2N1cyBhbmQgY29uZnVzZSBXRywNCj4g PiBjdXN0b21lcnMgYW5kIGJ1cmRlbiB2ZW5kb3JzLiBBZGRpdGlvbmFsbHksIFRSSUxMIFdHIHNo b3VsZCBmb2N1cyBvbiB0aGUNCj4gPiBwcmlvcml0eSBpdGVtcyB0aGF0IHdhcyBhZ3JlZWQgaW4g VGFpcGVpLiBBZGRpbmcgYWRkaXRpb25hbCBXRyBkb2NzIGlzDQo+ID4gbm90IGhlbHBpbmcgYW55 d2F5cy4gSSBhbSBpbiB0aGUgb3BpbmlvbiB0aGF0IFdHIHNob3VsZCBpZGVudGlmeQ0KPiA+IHBy aW9yaXR5IFdvcmsgYXJlYXMsIHRoZW4gZm9ybSBzdHJhdGVneSBhcm91bmQgaXQsIGJyaW5nIHRv Z2V0aGVyDQo+ID4gZGlmZmVyZW50IGlkZWFzIHRvIGZvcm0gd2VsbCB0aG91Z2h0IHRocm91Z2gg c29sdXRpb25zLg0KPiA+DQo+ID4gU2Vjb25kbHksIGl0IHNlZW1zIHlvdSBhcmUgaW4gdGhlIG9w aW5pb24gdGhhdCB0byBnZXQgV0cgaW5wdXQgdGhlIGRyYWZ0DQo+ID4gbmVlZCB0byBiZSBXRyBk b2N1bWVudC4gSSBkaXNhZ3JlZSB3aXRoIHRoYXQuIEEgZHJhZnQgZG9lcyBub3QgbmVlZCB0bw0K PiA+IGJlIGluIFdHIHN0YXR1cyB0byBnZXQgV0cgZmVlZGJhY2suIEF1dGhvcnMgc2hvdWxkIHNv bGljaXQgZmVlZGJhY2sNCj4gPiB0aHJvdWdoIHRoZSBtYWlsaW5nIGxpc3QuIE1ha2luZyBhIFdH IHN0YXR1cyBpcyBub3QgZ29pbmcgdG8gY2hhbmdlDQo+ID4gdGhhdC4NCj4gPg0KPiA+DQo+ID4N Cj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IEphbWVzIENhcmxzb24g W21haWx0bzpjYXJsc29uakB3b3JraW5nY29kZS5jb21dDQo+ID4gU2VudDogTW9uZGF5LCBNYXkg MTQsIDIwMTIgNzozMCBBTQ0KPiA+IFRvOiBUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKQ0K PiA+IENjOiBFcmlrIE5vcmRtYXJrOyB0cmlsbEBpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJlOiBb dHJpbGxdIFNob3VsZCB3ZSBtYWtlIGRyYWZ0LW1ydy10cmlsbC1vdmVyLWlwLTAxIGEgV0cNCj4g PiBkb2N1bWVudD8NCj4gPg0KPiA+IFRpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2aXIpIHdyb3Rl Og0KPiA+PiBUaGF0IHNvdW5kcyBhIGJpdCBiYWNrd2FyZHMgdG8gbWUuDQo+ID4+DQo+ID4+IFtB bnN3ZXJdIERvaW5nIHNtYWxsIHBpZWNlbWVhbCB3b3JrLCBpcyBub3QgdGhlIHJpZ2h0IGFwcHJv YWNoLg0KPiA+DQo+ID4gV2UgbWlnaHQgYWdyZWUgb24gdGhhdCBwb2ludCwgYnV0IGl0J3Mgbm90 IHRoZSBxdWVzdGlvbiBhdCBoYW5kLiAgVGhlDQo+ID4gcXVlc3Rpb24gYXQgaGFuZCBpcyB3aGV0 aGVyIHRvIGFkb3B0IGEgZHJhZnQuDQo+ID4NCj4gPj4gVGhlIGRvY3VtZW50IGlzIGNsZWFybHkg aW4gc2NvcGUgb2YgdGhlIHdvcmtpbmcgZ3JvdXAsIGFuZCBJIGJlbGlldmUNCj4gPj4gdGhlIG9u bHkgb3RoZXIgcXVlc3Rpb24gcmVnYXJkaW5nIGFkb3B0aW9uIGlzIHdoZXRoZXIgdGhlIHdnIHdh bnRzDQo+ID4+IChhbmQgdGhlIGF1dGhvcnMgd2FudCkgdG8gc3RlZXIgdGhlIGRvY3VtZW50IGJ5 IHRoZSB3b3JraW5nIGdyb3VwDQo+ID4+IGNvbnNlbnN1cyBwcm9jZXNzLg0KPiA+Pg0KPiA+PiBb QW5zd2VyXSBHb29kIHBvaW50LCBJIHJlLXJlYWQgdGhlIGNoYXJ0ZXIgb25lIG1vcmUgdGltZSBh bmQgdGhlcmUgaXMNCj4gPj4gbm8gd2hlcmUgaXQgc2F5cyBUUklMTCBvdmVyIElQIG9yIG90aGVy IGVuY2Fwc3VsYXRpb24sIHNvIGl0IHNlZW1zIHRoZQ0KPiA+DQo+ID4+IGRvY3VtZW50IGlzIG5v dCBpbiBjaGFydGVyLiBQbGVhc2UgY291bGQgeW91IHBvaW50IHRvIHRoZSBXRywgd2hpY2gNCj4g Pj4gbGluZSBpdGVtIGluIGNoYXJ0ZXIgdGhhdCBxdWFsaWZpZXMgdGhpcyB3b3JrIHRvIGJlIGlu IHNjb3BlID8NCj4gPj4NCj4gPj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy93Zy90cmls bC9jaGFydGVyLw0KPiA+DQo+ID4gU3VyZToNCj4gPg0KPiA+IAkiVGhpcyBpbmNsdWRlcyBhIE1J QiBtb2R1bGUgYW5kDQo+ID4gb3RoZXIgcGllY2VzIG5lZWRlZCBmb3Igb3BlcmF0aW9ucywgYnV0 IGFsc28gYWRkaXRpb25hbCB3YXlzIHRvIGV4dGVuZA0KPiA+IGFuZCBvcHRpbWl6ZSBUUklMTCBm b3IgdGhlIHByb3BlcnRpZXMgb2YgdGhlIG5ldHdvcmtzIG9uIHdoaWNoIGl0IGlzDQo+ID4gZGVw bG95ZWQuIg0KPiA+DQo+ID4gVGhpcyBzZWVtcyB0byBtZSB0byBiZSBhbiBhZGRpdGlvbmFsIHdh eSB0byBleHRlbmQgVFJJTEwgZm9yIHRoZQ0KPiA+IHByb3BlcnR5IG9mIGEgbmV0d29yayAtLSBz cGVjaWZpY2FsbHksIGFuIElQIG5ldHdvcmsuDQo+ID4NCj4gPiBHcmFudGVkLCBJJ20gbm90IHRo cmlsbGVkIGFib3V0IHRoZSBpZGVhIG9mIGFkZGluZyBhIG5ldyBtZWFucyB0byByZWFjaA0KPiA+ IG11dHVhbCBlbmNhcHN1bGF0aW9uLiAgSSBhc3N1bWUgdGhlIGF1dGhvcnMgaGF2ZSBhIGdvb2Qg cmVhc29uIHRvIGRvDQo+ID4gdGhpcywgYW5kIGhhdmUgaW50ZXJlc3RpbmcgaWRlYXMgb24gaG93 IGFuZCB3aHkgaXQgc2hvdWxkIGJlIGRvbmUuICBUaGUNCj4gPiBpbXBvcnRhbnQgcG9pbnQgaXMg dGhhdCBJIHRoaW5rIHRoaXMgd29ya2luZyBncm91cCBpcyB0aGUgYmVzdCBwb3NzaWJsZQ0KPiA+ IGZvcnVtIHRvIGFpciB0aG9zZSBpZGVhcy4NCj4gPg0KPiA+PiBbQW5zd2VyXSBJRVRGIHRyYWRp dGlvbiBoYXMgYmVlbiB0byBzdGFydCB3aXRoIGEgcHJvYmxlbSBzcGFjZSBhbmQNCj4gPj4gY3Jl YXRlIGEgY29tbW9uIHNvbHV0aW9uIG5vdCBtYWtpbmcgZXZlcnkgZHJhZnQgdGhhdCBpcyBpbiBz Y29wZSBvZg0KPiA+PiBjaGFydGVyIGEgV0cgZG9jdW1lbnQuIFlvdXIgcG9pbnQgb24gInRvbyBt YW55IHNvbHV0aW9ucyIgZXhhY3RseSB0aGF0DQo+ID4NCj4gPj4gaXMgbXkgcG9pbnQgaGF2aW5n IHN1YnNldCBvZiBzb2x1dGlvbnMgZmluYWxseSBsZWFkcyB0byB0b28gbWFueSBzbWFsbA0KPiA+ DQo+ID4+IHBpZWNlcy4NCj4gPg0KPiA+IFNvbWUgZWZmb3J0cyBkbyBpbmRlZWQgZm9sbG93IHRo YXQgc2ltcGxlIGxpbmVhciBwYXRoIC0tIGlkZWEsIEJPRiwNCj4gPiBjaGFydGVyLCBXRywgcHVi bGljYXRpb24uICBCdXQgdGhhdCdzIGNlcnRhaW5seSBub3QgdGhlIG9ubHkgcGF0aCwgbm9yDQo+ ID4gcGVyaGFwcyBldmVuIHRoZSBtb3N0IGNvbW1vbi4gIEFkb3B0aW9uIGJ5IGFuIGV4aXN0aW5n IFdHIG9mIG5ldw0KPiA+IGluLXNjb3BlIGRvY3VtZW50cyBpcyBzb21ldGhpbmcgdGhhdCBJIHZp ZXcgYXMgY3J1Y2lhbGx5IGltcG9ydGFudCB0bw0KPiA+IGNvbnRpbnVlZCBXRyB2aWFiaWxpdHku ICBXaXRob3V0IGl0LCBwcm90b2NvbHMganVzdCBncm93IGxpa2Ugd2VlZHMgYXMNCj4gPiBuZXcg ZXh0ZW5zaW9ucyBhcmUgb3RoZXJ3aXNlIGRldmVsb3BlZCwgZGVwbG95ZWQsIGFuZCBkb2N1bWVu dGVkIHdpdGhvdXQNCj4gPiB0aGUgaGVscCBvZiBXRyBjb25zZW5zdXMgdXNpbmcgdGhlIGluZGl2 aWR1YWwtc3VibWlzc2lvbiBSRkMgcHVibGljYXRpb24NCj4gPiB0cmFjay4NCj4gPg0KPiA+IEZh aWxpbmcgdG8gYWRvcHQgZG9lcyBub3QgZm9yZWNsb3NlIHB1YmxpY2F0aW9uIG9mIGFuIFJGQyBk ZXNjcmliaW5nDQo+ID4gdGhpcyBleHRlbnNpb24sIG5vciBhbnkgb3RoZXIgd29yayBieSB0aGUg YXV0aG9ycy4gIEl0IHNpbXBseQ0KPiA+IGRpc2Nvbm5lY3RzIHRoZSBXRyBmcm9tIHRoZSBwcm9j ZXNzLg0KPiA+DQo+ID4gU2VuZGluZyBUUklMTCBvdmVyIElQIG9mZiB0byB0aGUgaW5kaXZpZHVh bC1zdWJtaXNzaW9uIHdvcmxkIHdpdGhvdXQgV0cNCj4gPiBpbnB1dCB3b3VsZCwgSSB0aGluaywg YmUgYSBwb29yIHJlc3VsdCBvZiB0aGlzIGV4ZXJjaXNlLiAgSSd2ZSBiZWVuDQo+ID4gdGhyb3Vn aCB0aGF0IHByb2JsZW0gYXMgUFBQRVhUIGNoYWlyLCBhbmQgaXQncyBubyBmdW4uDQo+ID4NCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gdHJpbGwg bWFpbGluZyBsaXN0DQo+IHRyaWxsQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vdHJpbGwNCg== From yuqun.cao@gmail.com Mon May 14 22:08: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 59BED9E8015 for ; Mon, 14 May 2012 22:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.105 X-Spam-Level: X-Spam-Status: No, score=-3.105 tagged_above=-999 required=5 tests=[AWL=0.494, 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 z5jfribQVBhO for ; Mon, 14 May 2012 22:08:41 -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 138869E8006 for ; Mon, 14 May 2012 22:08:41 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so7226295pbc.31 for ; Mon, 14 May 2012 22:08:40 -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=1HVMR7+o1WuyUqp3dafOaAoUtC7C4tSlxMGOZtu/MJM=; b=Fd6beHwn7TPBF6HYPxVIjCYyJgMOKkGF+yLfdw6fkEdnVfl83nd1LnBwP1laIIv35J BDqD0ONE0vWz4yQn8URSyHki/gx6f3y/5HP7qs427Oc2RP7egZOXwwZdQma2S1AwFwvp T6GmDaJb3iKvPhIL03nyZV8ms0B0bQnq/+f5AENhOp2HAvNB7KrwkGGN51IwtctU82CZ N+xgArNHDu9+YmH7BIapDwlsO4nN3jFUAsJgR0kyA1EoBzGeraile09O42+mqqpqUQ0C jxw2YgTDDSDBcWpwXHhjIr24JTldC7xqGwOodkfFZy3Lw7deWVuFXQPE58LPyyRTIBTh nHXQ== Received: by 10.68.194.227 with SMTP id hz3mr1784490pbc.23.1337058520687; Mon, 14 May 2012 22:08:40 -0700 (PDT) Received: from R01842 ([110.90.119.113]) by mx.google.com with ESMTPS id ka5sm653717pbb.37.2012.05.14.22.08.35 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 May 2012 22:08:39 -0700 (PDT) From: "Sam Cao" To: "'Jiangyuanlong'" , "'Daniel Cohn'" , "'Alexander Vainshtein'" References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D411694@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF5C@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D4130E1@szxeml546-mbs.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF8F@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413216@szxeml546-mbs.china.huawei.com> <3F1F3739E2B04D399CC7D26CE934F91A@v2comsam> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413694@szxeml546-mbs.china.huawei.com> Subject: RE: Discussion on E-Tree and H-VPLS Date: Tue, 15 May 2012 13:08:36 +0800 Message-ID: <7A564821DF1642E592E884D5C623772C@R01842> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413694@szxeml546-mbs.china.huawei.com> Thread-index: AQHNLxo31u2OjZw96UuBF9QPOwJXg5bHcLkAgAGHLZCAAAmjYIAAHGPggAAUqSCAAOHDIIAAM7tg 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, 15 May 2012 05:08:42 -0000 Hi Yuanlong, Good point. Thank you very much for your comments. Wish I can clarify it this time. [JY] This is something new, right? To be honest, I could not understand what is your point: doesn't the mixed PW as you called also consist of one Leaf-only PW in one direction and one root-only PW in the other direction? Furthermore, the case you took is also one case in your guideline "Root-only VSI <-> any VSI: only root PW required", don't you think that only one root PW is required following this guideline? [Sam] This may confuse this. This PW is only PW between the 2 PEs. Here we call it as Root-PW, but maybe compatible PW is good name for it. I clarify this below. Actually, I don't care much about what is the bidirectional PW or unidirectional PW called, but how can a VSI support such a mixed scenarios: traditional VSI assumes only one PW is required for each peer VSI, and its MAC leaning is based on bidirectional PW. But for 2PW, there are bidirectional root PW, bidirectional leaf PW, mixed PW, etc..., how to support these kinds of PWs in the same VSI is my top concern. [Sam] Before Paris meeting, Giles initiated discussions among all co-authors of E-Tree drafts. During that time some members raised PW operations and commented that there are seldom Root-Leaf-Mixed PEs in an E-Tree, so multi-PW-01 optimize PW setup. This is the history. Ok, we go on the case in your mail, where PE1 has one Root-only AC, AC1, and PE2 has one Leaf-only AC, AC2. In general we can setup 2 "unidirectional" PWs (bidirectional PW, but just carry unidirectional frames), Root-PW which carries frames originated from AC1 and Leaf-PW which carries frames originated from AC2. But only one PW also can work, just as some members commented. Ok, we setup one PW between PE1 and PE2, we can call this PW as compatible PW or something else. Frames originated from Root or leaf ACs will be carried via this PW. Its forwarding behavior is fully same as what traditional VPLS did, MAC learning on AC or PW in one E-Tree. Or say, if one PE has Root-only ACs, it will setup one PW with another PE, Root-only, Leaf-only or Root-Leaf-Mixed. If 2 PEs are root-Leaf-Mixed or other cases, then 2 PWs will be established. As you know, this can be done on control plane. Is this clear for you? Is this necessary to optimize PW setup in this case? Maybe we need to add one paragraph on forwarding behavior. Again thank you very much for your comments, Sam -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] Sent: Tuesday, May 15, 2012 10:27 AM To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Please see my comments in line. -----Original Message----- From: Sam Cao [mailto:yuqun.cao@gmail.com] Sent: Monday, May 14, 2012 8:31 PM To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Yuanlong, We have discussed this in another thread. In fact, Daniel or I have given the answers to the questions you raised here for several time :). If we do in this way, we will reach deadlock and can not move forward :). I try to explain it again. [JY] I will apologize if you had ever provided such answers before, and you may just refer to the links rather than repeat the explanation. As you can see, I just try to understand the mechanism of 2PW and its implications, but the I-D does not include enough information. As you know, initial design we will setup 2 PWs all the time (if do in this way, I think that you have no question), [JY] I will be concerned with the operational complexity of this approach. but in most cases 2 PWs are not necessary. So in 01 version, we optimize it. "Root-only VSI <-> any VSI: only root PW required" "Leaf-only VSI <-> leaf-only VSI: no PWs required" In other cases 2 PWs are needed. If so, "Leaf-only -> root-only = one leaf PW" is not correct: On Leaf-only side, yes, one Leaf-only PW is created between Local Leaf type with remote Root type; on root-only side, one root-only PW is created. Maybe it is better to call this as compatible or mixed PW. So the left items you list are not correct for multi_PW solution. [JY] This is something new, right? To be honest, I could not understand what is your point: doesn't the mixed PW as you called also consist of one Leaf-only PW in one direction and one root-only PW in the other direction? Furthermore, the case you took is also one case in your guideline "Root-only VSI <-> any VSI: only root PW required", don't you think that only one root PW is required following this guideline? Actually, I don't care much about what is the bidirectional PW or unidirectional PW called, but how can a VSI support such a mixed scenarios: traditional VSI assumes only one PW is required for each peer VSI, and its MAC leaning is based on bidirectional PW. But for 2PW, there are bidirectional root PW, bidirectional leaf PW, mixed PW, etc..., how to support these kinds of PWs in the same VSI is my top concern. BTW, I guess you also care this case we also have discussed before: for example, if we configure one Leaf AC on root-only PE (then it will be root-leaf-mixed PE), we will teardown the compatible PW and re-setup PWs again with 01. [JY] This was discussed in the emails indeed. Regards, Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] Sent: Monday, May 14, 2012 7:10 PM To: Daniel Cohn; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Daniel, Fine, now it seems more in line with what we had proposed in 2VLAN: a spoke PW behaves like root/leaf AC for a PE-r. But the same problem may also apply to the root/spoke "core PW" for Multi-PW: According to Multi-PW, only one PW is required between two PEs except when both PEs are mixed with root and leaf, so these PWs may be formed by combinations of the following unidirectional PW cases (extracted and adapted from Josh's email): Root-only -> any VSI = one root PW Leaf-only -> root-only = one leaf PW Leaf-only -> mixed = one leaf PW Mixed -> root-only = one (root+leaf) PW Mixed -> leaf-only = one (root+leaf) PW I have a concern that the forwarding plane of PE to implement this will be very different from the traditional VPLS. Regards, Yuanlong -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: Monday, May 14, 2012 5:00 PM To: Jiangyuanlong; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Yuanlong, Like I wrote below, root/leaf spoke PW behave like root/leaf AC, not like root/spoke "core PW". So no changes to forwarding plane once this is understood. DC -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] Sent: Monday, May 14, 2012 11:36 AM To: Daniel Cohn; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Daniel, please see my comments in line. -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: Monday, May 14, 2012 3:37 PM To: Jiangyuanlong; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Yuanlong, As I see it, for the PE-r spoke (figure 4 in RFC 4762) we establish a single PW per AC - root PW for root AC and leaf PW for leaf AC. With local configuration at the PE-rs as part of the spoke PW provisioning. And the PE-rs will treat root/leaf spoke PWs exactly as it treat root/leaf ACs. So when leaf-originated BUM traffic arrives from the core (over a leaf PW), it will be forwarded over all root spoke PWs but not on the leaf spoke PWs. [JY] So in the reverse direction, you need to transport both root and leaf traffic from PE-rs over a root PW to PE-r, and transport root traffic over a leaf PW. It seems against the definition of root PW and leaf PW in the multi-PW draft. Don't this make the forwarding plane of PE-rs more complex? The forwarding plane is exactly the same as described in the multi-PW draft, where spoke PWs are treated exactly like ACs. Regards, Daniel -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] Sent: Friday, May 11, 2012 5:03 AM To: Daniel Cohn; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Daniel and all, When you set up two PWs from the PE-rs to a PE-r for each of its AC, do you mean that one PW is bidirectional root PW and the other is bidirectional leaf PW? My concern is: where should the leaf traffic be filtered, on the PE-rs or on the PE-r? If filtered on the PE-r, then lots of bandwidth will be wasted (for example, if the PE-r is attached with 9 leafs, then the BUM traffic from one of its leafs will be multiplied by 8 times, and be forwarded by the PE-rs to the same PE-r). If filtered on the PE-rs, not sure how you will design its forwarding plane, can you give a hint? Thanks, Yuanlong ------------------------------ Date: Wed, 9 May 2012 09:16:36 +0300 From: "Daniel Cohn" To: "Alexander Vainshtein" , "Sam Cao" , Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780CBA6@tlvmail1> Content-Type: text/plain; charset="ISO-2022-JP" Hi Sasha, It's actually very simple. A frame that originated in a root AC is always transmitted only in root PW, no matter what the frame type (known/unknown unicast or broadcast). This is how the frame source information is propagated across the VPLS. So in the H-VPLS example, the PE-r will never forward a frame received over a root PW on any leaf PW, only on root PWs (toward the core or toward other spokes). Hope this clarifies it, regards, Daniel -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Alexander Vainshtein Sent: Wednesday, May 09, 2012 7:59 AM To: Sam Cao; l2vpn@ietf.org Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Sam, Lizhong and all, You've written that in the two-PW solution combined with H-VPLS the PE-r must set up two PWs with each MTU-s. If this is the case, what kind of forwarding logic should be used to prevent sending a BUM frame received from a root-PW to a given MTU-S: - back to the same MTU-S on the corresponding leaf-PW? - twice (to both root-PW and Leaf-PW) to another MTU-s? And, BTW, how is the PW selected in this case? I am aware of a technique of multiple split horizon groups in PE-r which could be possibly used for this purpose. However, since these groups have to be represented explicitly in the data plane, their potential number is limited by the forwarding HW. Other methods could be probably used for the same purpose, but they would probably subject to similar HW-based limitations. I suspect that with the dual-PW approach, the HW would pose an implicit limit, say, on a number of MTU-s that can be connected to the same PE-r and that this limit could be quite low in most cases. Based on this I suspect that the H-VPLS issue as a critical drawback of the dual-PW approach to E-Tree. My 2c, Sasha ________________________________________ From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Sam Cao [yuqun.cao@gmail.com] Sent: Wednesday, May 09, 2012 3:40 AM To: l2vpn@ietf.org Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Hi Lizhong? Thank you very much for your comments. I updated the result on this question. [Lizhong] agree with the above analysis. And we did not say it is a technical problem, but it is an operational problem again. [Sam] I agree. Dual-VLAN does not make sense. I also discussed this with Giles and Yuanlong in another mail, and we reached agreement on this: MTU should know the access mode, VPWS or VPLS, VPWS mode should configure VLAN ID on MTU but VPLS mode can not. I thought this is NOT reasonable :), but we can figure this out in draft. It seems ok. [Lizhong] not fully understand. Do you mean, when VPWS accessing for H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf PW) for each AC access? [Sam] Yes. Thanks, Sam From jiangyuanlong@huawei.com Tue May 15 00:36: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 6ED1721F889B for ; Tue, 15 May 2012 00:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[AWL=0.237, 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 A1OBw7fR1zMw for ; Tue, 15 May 2012 00:36:12 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5D021F88AD for ; Tue, 15 May 2012 00:36:12 -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 AGE84282; Tue, 15 May 2012 03:36:11 -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; Tue, 15 May 2012 00:32:27 -0700 Received: from SZXEML434-HUB.china.huawei.com (10.72.61.62) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 15 May 2012 00:32:26 -0700 Received: from SZXEML546-MBS.china.huawei.com ([169.254.4.75]) by szxeml434-hub.china.huawei.com ([10.72.61.62]) with mapi id 14.01.0323.003; Tue, 15 May 2012 15:32:19 +0800 From: Jiangyuanlong To: Sam Cao , 'Daniel Cohn' , 'Alexander Vainshtein' Subject: RE: Discussion on E-Tree and H-VPLS Thread-Topic: Discussion on E-Tree and H-VPLS Thread-Index: AQHNLxo31u2OjZw96UuBF9QPOwJXg5bHcLkAgAGHLZCAAAmjYIAAHGPggAAUqSCAAOHDIIAAM7tggAAlyMA= Date: Tue, 15 May 2012 07:32:19 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D41370E@szxeml546-mbs.china.huawei.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D411694@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF5C@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D4130E1@szxeml546-mbs.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF8F@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413216@szxeml546-mbs.china.huawei.com> <3F1F3739E2B04D399CC7D26CE934F91A@v2comsam> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413694@szxeml546-mbs.china.huawei.com> <7A564821DF1642E592E884D5C623772C@R01842> In-Reply-To: <7A564821DF1642E592E884D5C623772C@R01842> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.40.73] 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, 15 May 2012 07:36:13 -0000 Sam, Thanks, please see my further comments with [JY]. Ok, we go on the case in your mail, where PE1 has one Root-only AC, AC1, an= d PE2 has one Leaf-only AC, AC2. In general we can setup 2 "unidirectional" PWs (bidirectional PW, but just carry unidirectional frames), Root-PW which carries frames originated from AC1 and Leaf-PW which carries frames originated from AC2. But only one PW also can work, just as some members commented. Ok, we setup one PW between PE1 and PE2, we can call this PW as compatible PW or something else. Frames originated from Root or leaf ACs will be carried via this PW. Its forwarding behavior is fully same as what traditional VPLS did, MAC learning on AC or PW in one E-Tree. Or say, if on= e PE has Root-only ACs, it will setup one PW with another PE, Root-only, Leaf-only or Root-Leaf-Mixed. If 2 PEs are root-Leaf-Mixed or other cases, then 2 PWs will be established. As you know, this can be done on control plane.=20 [JY] Assume there are 2 other nodes PE3 & PE4 in this network scenario, and= both PE3 and PE4 have both root and leaf ACs, then there are compatible PW= s from PE3 which may carry both root and leaf traffic (to PE1), which may c= arry only root traffic (to PE2); and further there are root PW and leaf PW = to PE4. Thus, the VSI on PE3 has at least 4 different types of PW transmitt= ing behaviours with regard to the E-Tree traffic. In the reverse direction,= the VSI on PE3 further has at least 4 different types of PW receiving beha= viours. Not sure how you will accommodate for these PWs in both the data pl= ane and control plane. Regards, Yuanlong Is this clear for you? Is this necessary to optimize PW setup in this case?= =20 Maybe we need to add one paragraph on forwarding behavior.=20 Again thank you very much for your comments, Sam -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Tuesday, May 15, 2012 10:27 AM To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Please see my comments in line. -----Original Message----- From: Sam Cao [mailto:yuqun.cao@gmail.com]=20 Sent: Monday, May 14, 2012 8:31 PM To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Yuanlong, We have discussed this in another thread. In fact, Daniel or I have given the answers to the questions you raised here for several time :). If we do in this way, we will reach deadlock and can not move forward :). I try to explain it again. [JY] I will apologize if you had ever provided such answers before, and you may just refer to the links rather than repeat the explanation. As you can see, I just try to understand the mechanism of 2PW and its implications, but the I-D does not include enough information. As you know, initial design we will setup 2 PWs all the time (if do in this way, I think that you have no question),=20 [JY] I will be concerned with the operational complexity of this approach. but in most cases 2 PWs are not necessary. So in 01 version, we optimize it. "Root-only VSI <-> any VSI: only root PW required" "Leaf-only VSI <-> leaf-only VSI: no PWs required" In other cases 2 PWs are needed. If so, "Leaf-only -> root-only =3D one lea= f PW" is not correct: On Leaf-only side, yes, one Leaf-only PW is created between Local Leaf type with remote Root type; on root-only side, one root-only PW is created. Maybe it is better to call this as compatible or mixed PW. So the left items you list are not correct for multi_PW solution. [JY] This is something new, right? To be honest, I could not understand wha= t is your point: doesn't the mixed PW as you called also consist of one Leaf-only PW in one direction and one root-only PW in the other direction? Furthermore, the case you took is also one case in your guideline "Root-onl= y VSI <-> any VSI: only root PW required", don't you think that only one root PW is required following this guideline? Actually, I don't care much about what is the bidirectional PW or unidirectional PW called, but how can a VSI support such a mixed scenarios: traditional VSI assumes only one PW is required for each peer VSI, and its MAC leaning is based on bidirectional PW. But for 2PW, there are bidirectional root PW, bidirectional leaf PW, mixed PW, etc..., how to support these kinds of PWs in the same VSI is my top concern. BTW, I guess you also care this case we also have discussed before: for example, if we configure one Leaf AC on root-only PE (then it will be root-leaf-mixed PE), we will teardown the compatible PW and re-setup PWs again with 01.=20 [JY] This was discussed in the emails indeed. Regards, =20 Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com=20 =20 -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Monday, May 14, 2012 7:10 PM To: Daniel Cohn; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Daniel, Fine, now it seems more in line with what we had proposed in 2VLAN: a spoke PW behaves like root/leaf AC for a PE-r. But the same problem may also apply to the root/spoke "core PW" for Multi-PW: According to Multi-PW, only one PW is required between two PEs except when both PEs are mixed with root and leaf, so these PWs may be formed by combinations of the following unidirectional PW cases (extracted and adapte= d from Josh's email): Root-only -> any VSI =3D one root PW Leaf-only -> root-only =3D one leaf PW Leaf-only -> mixed =3D one leaf PW=20 Mixed -> root-only =3D one (root+leaf) PW =20 Mixed -> leaf-only =3D one (root+leaf) PW =20 I have a concern that the forwarding plane of PE to implement this will be very different from the traditional VPLS. Regards, Yuanlong -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Monday, May 14, 2012 5:00 PM To: Jiangyuanlong; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Yuanlong, Like I wrote below, root/leaf spoke PW behave like root/leaf AC, not like root/spoke "core PW". So no changes to forwarding plane once this is understood. DC -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Monday, May 14, 2012 11:36 AM To: Daniel Cohn; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Daniel, please see my comments in line. -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Monday, May 14, 2012 3:37 PM To: Jiangyuanlong; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Yuanlong, As I see it, for the PE-r spoke (figure 4 in RFC 4762) we establish a single PW per AC - root PW for root AC and leaf PW for leaf AC. With local configuration at the PE-rs as part of the spoke PW provisioning. And the PE-rs will treat root/leaf spoke PWs exactly as it treat root/leaf ACs. So when leaf-originated BUM traffic arrives from the core (over a leaf PW), it will be forwarded over all root spoke PWs but not on the leaf spoke PWs.=20 [JY] So in the reverse direction, you need to transport both root and leaf traffic from PE-rs over a root PW to PE-r, and transport root traffic over a leaf PW. It seems against the definition of root PW and leaf PW in the multi-PW draft. Don't this make the forwarding plane of PE-rs more complex?=20 The forwarding plane is exactly the same as described in the multi-PW draft, where spoke PWs are treated exactly like ACs. Regards, Daniel -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Friday, May 11, 2012 5:03 AM To: Daniel Cohn; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Daniel and all, When you set up two PWs from the PE-rs to a PE-r for each of its AC, do you mean that one PW is bidirectional root PW and the other is bidirectional leaf PW? My concern is: where should the leaf traffic be filtered, on the PE-rs or on the PE-r? If filtered on the PE-r, then lots of bandwidth will be wasted (for example, if the PE-r is attached with 9 leafs, then the BUM traffic from one of its leafs will be multiplied by 8 times, and be forwarded by the PE-rs to the same PE-r). If filtered on the PE-rs, not sure how you will design its forwarding plane, can you give a hint? Thanks, Yuanlong ------------------------------ Date: Wed, 9 May 2012 09:16:36 +0300 From: "Daniel Cohn" To: "Alexander Vainshtein" , "Sam Cao" , Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780CBA6@tlvmail1> Content-Type: text/plain; charset=3D"ISO-2022-JP" Hi Sasha, It's actually very simple. A frame that originated in a root AC is always transmitted only in root PW, no matter what the frame type (known/unknown unicast or broadcast). This is how the frame source information is propagated across the VPLS. So in the H-VPLS example, the PE-r will never forward a frame received over a root PW on any leaf PW, only on root PWs (toward the core or toward other spokes). Hope this clarifies it, regards, Daniel -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Alexander Vainshtein Sent: Wednesday, May 09, 2012 7:59 AM To: Sam Cao; l2vpn@ietf.org Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Sam, Lizhong and all, You've written that in the two-PW solution combined with H-VPLS the PE-r must set up two PWs with each MTU-s. If this is the case, what kind of forwarding logic should be used to prevent sending a BUM frame received from a root-PW to a given MTU-S: - back to the same MTU-S on the corresponding leaf-PW? - twice (to both root-PW and Leaf-PW) to another MTU-s? And, BTW, how is the PW selected in this case? I am aware of a technique of multiple split horizon groups in PE-r which could be possibly used for this purpose. However, since these groups have to be represented explicitly in the data plane, their potential number is limited by the forwarding HW. Other methods could be probably used for the same purpose, but they would probably subject to similar HW-based limitations. I suspect that with the dual-PW approach, the HW would pose an implicit limit, say, on a number of MTU-s that can be connected to the same PE-r and that this limit could be quite low in most cases. Based on this I suspect that the H-VPLS issue as a critical drawback of the dual-PW approach to E-Tree. My 2c, Sasha ________________________________________ From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Sam Cao [yuqun.cao@gmail.com] Sent: Wednesday, May 09, 2012 3:40 AM To: l2vpn@ietf.org Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Hi Lizhong? Thank you very much for your comments. I updated the result on this question. [Lizhong] agree with the above analysis. And we did not say it is a technical problem, but it is an operational problem again. [Sam] I agree. Dual-VLAN does not make sense. I also discussed this with Giles and Yuanlong in another mail, and we reached agreement on this: MTU should know the access mode, VPWS or VPLS, VPWS mode should configure VLAN ID on MTU but VPLS mode can not. I thought this is NOT reasonable :), but we can figure this out in draft. It seems ok. [Lizhong] not fully understand. Do you mean, when VPWS accessing for H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf PW) for each AC access? [Sam] Yes. Thanks, Sam =20 From yuqun.cao@gmail.com Tue May 15 03:14: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 96C1721F873D for ; Tue, 15 May 2012 03:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.825 X-Spam-Level: X-Spam-Status: No, score=-2.825 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, J_CHICKENPOX_23=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 MYr3+zh37Izy for ; Tue, 15 May 2012 03:14:31 -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 4356C21F873B for ; Tue, 15 May 2012 03:14:31 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so7562049pbc.31 for ; Tue, 15 May 2012 03:14:31 -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=3gPjKH9wGzsjeuiq9ywLbDslWMvHihjikh6LUso0ClI=; b=efbDNhlFNK2/lQzhRQm8ixVXSF96ThBPuG2BbSm7gJkieFWbPDnKG0EGvvyWnzsdWe CPKKHnp1w1UNBizCgL4TyYxzEqgN3bjStrDNZ0Lu1EnjLysc8R+/xPHehX/el+K5dd8k suujFte5SWh8IRInlwvR2p3wPE8em4BPkoM55Q9kWk/t2yOjQ617N3JSF+qQILflP9kH G1Vumns9bzRqppEGijp+yOoh2/TrZQaKEKKnNKM/J2FU2wdRYItE16k86iePHAvQyf56 xMVVKxINBVKrP+R1a8tFz44HRKDG+ybUiRiDBOheHFiWFs7f/MVoRDne6T1e03GgIcUQ QUbQ== Received: by 10.68.242.7 with SMTP id wm7mr3839434pbc.98.1337076870709; Tue, 15 May 2012 03:14:30 -0700 (PDT) Received: from R01842 ([110.90.119.113]) by mx.google.com with ESMTPS id pz3sm1432969pbc.16.2012.05.15.03.14.21 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 May 2012 03:14:29 -0700 (PDT) From: "Sam Cao" To: "'Jiangyuanlong'" , "'Daniel Cohn'" , "'Alexander Vainshtein'" References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D411694@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF5C@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D4130E1@szxeml546-mbs.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF8F@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413216@szxeml546-mbs.china.huawei.com> <3F1F3739E2B04D399CC7D26CE934F91A@v2comsam> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413694@szxeml546-mbs.china.huawei.com> <7A564821DF1642E592E884D5C623772C@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D41370E@szxeml546-mbs.china.huawei.com> Subject: RE: Discussion on E-Tree and H-VPLS Date: Tue, 15 May 2012 18:14:24 +0800 Message-ID: <400D5D93E6AA4075861CE09919D84747@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: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D41370E@szxeml546-mbs.china.huawei.com> Thread-Index: AQHNLxo31u2OjZw96UuBF9QPOwJXg5bHcLkAgAGHLZCAAAmjYIAAHGPggAAUqSCAAOHDIIAAM7tggAAlyMCAADHVIA== 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, 15 May 2012 10:14:32 -0000 Hi Yuanlong, Thank you very much for your comments. I draw the topology you gave, and 7 PWs will be established if we follow 01. Root AC ---- PE 1 ----- PW 1 -------- PE 2 ----- Leaf _AC | \ / || | \ /===PW 6,7=== || PW 2 -----PW 5------\ || | /----Root PW 3 --- \ || Root _AC ---- PE 3 PE 4 ------ Root AC | \ / | | ----Leaf PW 4----- | Leaf AC Leaf AC Yes, on PE 3 there are several PWs, but if you want to clarify it, there are only 3 types, one can carry frames originated from Root and Leaf AC(one endpoint of this PW should be Root-only, otherwise this is invalid), one only can carry frames from Root AC, and the last can carry frames from Leaf ACs. On second thoughts, we still can classify the PWs into 2 sets, one is Leaf set, and another is Root set, and the union of the sets Leaf and Root is the PW we called it as compatible PW (Maybe this is not correct, we can find one good term on this). So this optimization still follows the original design of Dual-PW approach, Leaf PW only carries frames from Leaf AC; Root-PW only carries frames from Root AC. Is it right? I don't know whether chip can support this forwarding behavior for compatible PW or not, but if we implement it in NP, it is nearly same as VPLS. The only difference is, setup 2 mappings, one between Leaf-ACs and Leaf-PWs, one between Root-ACs and Root-PWs. For traditional VPLS, there is only one mapping. Based on my understanding, all drafts should have similar mapping. Thanks, Sam -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] Sent: Tuesday, May 15, 2012 3:32 PM To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Sam, Thanks, please see my further comments with [JY]. Ok, we go on the case in your mail, where PE1 has one Root-only AC, AC1, and PE2 has one Leaf-only AC, AC2. In general we can setup 2 "unidirectional" PWs (bidirectional PW, but just carry unidirectional frames), Root-PW which carries frames originated from AC1 and Leaf-PW which carries frames originated from AC2. But only one PW also can work, just as some members commented. Ok, we setup one PW between PE1 and PE2, we can call this PW as compatible PW or something else. Frames originated from Root or leaf ACs will be carried via this PW. Its forwarding behavior is fully same as what traditional VPLS did, MAC learning on AC or PW in one E-Tree. Or say, if one PE has Root-only ACs, it will setup one PW with another PE, Root-only, Leaf-only or Root-Leaf-Mixed. If 2 PEs are root-Leaf-Mixed or other cases, then 2 PWs will be established. As you know, this can be done on control plane. [JY] Assume there are 2 other nodes PE3 & PE4 in this network scenario, and both PE3 and PE4 have both root and leaf ACs, then there are compatible PWs from PE3 which may carry both root and leaf traffic (to PE1), which may carry only root traffic (to PE2); and further there are root PW and leaf PW to PE4. Thus, the VSI on PE3 has at least 4 different types of PW transmitting behaviours with regard to the E-Tree traffic. In the reverse direction, the VSI on PE3 further has at least 4 different types of PW receiving behaviours. Not sure how you will accommodate for these PWs in both the data plane and control plane. Regards, Yuanlong Is this clear for you? Is this necessary to optimize PW setup in this case? Maybe we need to add one paragraph on forwarding behavior. Again thank you very much for your comments, Sam -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] Sent: Tuesday, May 15, 2012 10:27 AM To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Please see my comments in line. -----Original Message----- From: Sam Cao [mailto:yuqun.cao@gmail.com] Sent: Monday, May 14, 2012 8:31 PM To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Yuanlong, We have discussed this in another thread. In fact, Daniel or I have given the answers to the questions you raised here for several time :). If we do in this way, we will reach deadlock and can not move forward :). I try to explain it again. [JY] I will apologize if you had ever provided such answers before, and you may just refer to the links rather than repeat the explanation. As you can see, I just try to understand the mechanism of 2PW and its implications, but the I-D does not include enough information. As you know, initial design we will setup 2 PWs all the time (if do in this way, I think that you have no question), [JY] I will be concerned with the operational complexity of this approach. but in most cases 2 PWs are not necessary. So in 01 version, we optimize it. "Root-only VSI <-> any VSI: only root PW required" "Leaf-only VSI <-> leaf-only VSI: no PWs required" In other cases 2 PWs are needed. If so, "Leaf-only -> root-only = one leaf PW" is not correct: On Leaf-only side, yes, one Leaf-only PW is created between Local Leaf type with remote Root type; on root-only side, one root-only PW is created. Maybe it is better to call this as compatible or mixed PW. So the left items you list are not correct for multi_PW solution. [JY] This is something new, right? To be honest, I could not understand what is your point: doesn't the mixed PW as you called also consist of one Leaf-only PW in one direction and one root-only PW in the other direction? Furthermore, the case you took is also one case in your guideline "Root-only VSI <-> any VSI: only root PW required", don't you think that only one root PW is required following this guideline? Actually, I don't care much about what is the bidirectional PW or unidirectional PW called, but how can a VSI support such a mixed scenarios: traditional VSI assumes only one PW is required for each peer VSI, and its MAC leaning is based on bidirectional PW. But for 2PW, there are bidirectional root PW, bidirectional leaf PW, mixed PW, etc..., how to support these kinds of PWs in the same VSI is my top concern. BTW, I guess you also care this case we also have discussed before: for example, if we configure one Leaf AC on root-only PE (then it will be root-leaf-mixed PE), we will teardown the compatible PW and re-setup PWs again with 01. [JY] This was discussed in the emails indeed. Regards, Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] Sent: Monday, May 14, 2012 7:10 PM To: Daniel Cohn; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Daniel, Fine, now it seems more in line with what we had proposed in 2VLAN: a spoke PW behaves like root/leaf AC for a PE-r. But the same problem may also apply to the root/spoke "core PW" for Multi-PW: According to Multi-PW, only one PW is required between two PEs except when both PEs are mixed with root and leaf, so these PWs may be formed by combinations of the following unidirectional PW cases (extracted and adapted from Josh's email): Root-only -> any VSI = one root PW Leaf-only -> root-only = one leaf PW Leaf-only -> mixed = one leaf PW Mixed -> root-only = one (root+leaf) PW Mixed -> leaf-only = one (root+leaf) PW I have a concern that the forwarding plane of PE to implement this will be very different from the traditional VPLS. Regards, Yuanlong -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: Monday, May 14, 2012 5:00 PM To: Jiangyuanlong; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Yuanlong, Like I wrote below, root/leaf spoke PW behave like root/leaf AC, not like root/spoke "core PW". So no changes to forwarding plane once this is understood. DC -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] Sent: Monday, May 14, 2012 11:36 AM To: Daniel Cohn; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Daniel, please see my comments in line. -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: Monday, May 14, 2012 3:37 PM To: Jiangyuanlong; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Yuanlong, As I see it, for the PE-r spoke (figure 4 in RFC 4762) we establish a single PW per AC - root PW for root AC and leaf PW for leaf AC. With local configuration at the PE-rs as part of the spoke PW provisioning. And the PE-rs will treat root/leaf spoke PWs exactly as it treat root/leaf ACs. So when leaf-originated BUM traffic arrives from the core (over a leaf PW), it will be forwarded over all root spoke PWs but not on the leaf spoke PWs. [JY] So in the reverse direction, you need to transport both root and leaf traffic from PE-rs over a root PW to PE-r, and transport root traffic over a leaf PW. It seems against the definition of root PW and leaf PW in the multi-PW draft. Don't this make the forwarding plane of PE-rs more complex? The forwarding plane is exactly the same as described in the multi-PW draft, where spoke PWs are treated exactly like ACs. Regards, Daniel -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] Sent: Friday, May 11, 2012 5:03 AM To: Daniel Cohn; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Daniel and all, When you set up two PWs from the PE-rs to a PE-r for each of its AC, do you mean that one PW is bidirectional root PW and the other is bidirectional leaf PW? My concern is: where should the leaf traffic be filtered, on the PE-rs or on the PE-r? If filtered on the PE-r, then lots of bandwidth will be wasted (for example, if the PE-r is attached with 9 leafs, then the BUM traffic from one of its leafs will be multiplied by 8 times, and be forwarded by the PE-rs to the same PE-r). If filtered on the PE-rs, not sure how you will design its forwarding plane, can you give a hint? Thanks, Yuanlong ------------------------------ Date: Wed, 9 May 2012 09:16:36 +0300 From: "Daniel Cohn" To: "Alexander Vainshtein" , "Sam Cao" , Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780CBA6@tlvmail1> Content-Type: text/plain; charset="ISO-2022-JP" Hi Sasha, It's actually very simple. A frame that originated in a root AC is always transmitted only in root PW, no matter what the frame type (known/unknown unicast or broadcast). This is how the frame source information is propagated across the VPLS. So in the H-VPLS example, the PE-r will never forward a frame received over a root PW on any leaf PW, only on root PWs (toward the core or toward other spokes). Hope this clarifies it, regards, Daniel -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Alexander Vainshtein Sent: Wednesday, May 09, 2012 7:59 AM To: Sam Cao; l2vpn@ietf.org Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Sam, Lizhong and all, You've written that in the two-PW solution combined with H-VPLS the PE-r must set up two PWs with each MTU-s. If this is the case, what kind of forwarding logic should be used to prevent sending a BUM frame received from a root-PW to a given MTU-S: - back to the same MTU-S on the corresponding leaf-PW? - twice (to both root-PW and Leaf-PW) to another MTU-s? And, BTW, how is the PW selected in this case? I am aware of a technique of multiple split horizon groups in PE-r which could be possibly used for this purpose. However, since these groups have to be represented explicitly in the data plane, their potential number is limited by the forwarding HW. Other methods could be probably used for the same purpose, but they would probably subject to similar HW-based limitations. I suspect that with the dual-PW approach, the HW would pose an implicit limit, say, on a number of MTU-s that can be connected to the same PE-r and that this limit could be quite low in most cases. Based on this I suspect that the H-VPLS issue as a critical drawback of the dual-PW approach to E-Tree. My 2c, Sasha ________________________________________ From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Sam Cao [yuqun.cao@gmail.com] Sent: Wednesday, May 09, 2012 3:40 AM To: l2vpn@ietf.org Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Hi Lizhong? Thank you very much for your comments. I updated the result on this question. [Lizhong] agree with the above analysis. And we did not say it is a technical problem, but it is an operational problem again. [Sam] I agree. Dual-VLAN does not make sense. I also discussed this with Giles and Yuanlong in another mail, and we reached agreement on this: MTU should know the access mode, VPWS or VPLS, VPWS mode should configure VLAN ID on MTU but VPLS mode can not. I thought this is NOT reasonable :), but we can figure this out in draft. It seems ok. [Lizhong] not fully understand. Do you mean, when VPWS accessing for H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf PW) for each AC access? [Sam] Yes. Thanks, Sam From jiangyuanlong@huawei.com Tue May 15 04:05: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 944DF21F881F for ; Tue, 15 May 2012 04:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.067 X-Spam-Level: X-Spam-Status: No, score=-2.067 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, J_CHICKENPOX_23=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 xuSYEMXUErhC for ; Tue, 15 May 2012 04:05:46 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id D350821F8813 for ; Tue, 15 May 2012 04:05:45 -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 AFY01003; Tue, 15 May 2012 07:05:42 -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; Tue, 15 May 2012 04:03:32 -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; Tue, 15 May 2012 04:03:34 -0700 Received: from SZXEML546-MBS.china.huawei.com ([169.254.4.75]) by szxeml428-hub.china.huawei.com ([10.72.61.36]) with mapi id 14.01.0323.003; Tue, 15 May 2012 19:03:30 +0800 From: Jiangyuanlong To: Sam Cao , 'Daniel Cohn' , 'Alexander Vainshtein' Subject: RE: Discussion on E-Tree and H-VPLS Thread-Topic: Discussion on E-Tree and H-VPLS Thread-Index: AQHNLxo31u2OjZw96UuBF9QPOwJXg5bHcLkAgAGHLZCAAAmjYIAAHGPggAAUqSCAAOHDIIAAM7tggAAlyMCAADHVIIAAElJA Date: Tue, 15 May 2012 11:03:30 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413741@szxeml546-mbs.china.huawei.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D411694@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF5C@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D4130E1@szxeml546-mbs.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF8F@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413216@szxeml546-mbs.china.huawei.com> <3F1F3739E2B04D399CC7D26CE934F91A@v2comsam> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413694@szxeml546-mbs.china.huawei.com> <7A564821DF1642E592E884D5C623772C@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D41370E@szxeml546-mbs.china.huawei.com> <400D5D93E6AA4075861CE09919D84747@R01842> In-Reply-To: <400D5D93E6AA4075861CE09919D84747@R01842> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.40.73] 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, 15 May 2012 11:05:47 -0000 See my further comments in line. -----Original Message----- From: Sam Cao [mailto:yuqun.cao@gmail.com]=20 Sent: Tuesday, May 15, 2012 6:14 PM To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Yuanlong, Thank you very much for your comments. I draw the topology you gave, and 7 PWs will be established if we follow 01. Root AC ---- PE 1 ----- PW 1 -------- PE 2 ----- Leaf _AC | \ / || | \ /=3D=3D=3DPW 6,7=3D=3D=3D || PW 2 -----PW 5------\ || | /----Root PW 3 --- \ || Root _AC ---- PE 3 PE 4 ------ Root AC | \ / | | ----Leaf PW 4----- |=20 Leaf AC Leaf AC Yes, on PE 3 there are several PWs, but if you want to clarify it, there ar= e only 3 types, one can carry frames originated from Root and Leaf AC(one endpoint of this PW should be Root-only, otherwise this is invalid), one only can carry frames from Root AC, and the last can carry frames from Leaf ACs. On second thoughts, we still can classify the PWs into 2 sets, one is Leaf set, and another is Root set, and the union of the sets Leaf and Root is the PW we called it as compatible PW (Maybe this is not correct, we can find one good term on this).=20 So this optimization still follows the original design of Dual-PW approach, Leaf PW only carries frames from Leaf AC; Root-PW only carries frames from Root AC. Is it right? I don't know whether chip can support this forwarding behavior for compatible PW or not, but if we implement it in NP, it is nearly same as VPLS. The only difference is, setup 2 mappings, one between Leaf-ACs and Leaf-PWs, one between Root-ACs and Root-PWs. For traditional VPLS, there is only one mapping.=20 [JY] It seems you may need a 3rd mapping: from both root & leaf AC to a com= patible PW. BTW, for the forwarding and reverse direction, the mapping may be asymmetri= c for you compatible PW. Based on my understanding, all drafts should have similar mapping.=20 [JY] Dual-VLAN seems simpler here. Thanks, Sam -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Tuesday, May 15, 2012 3:32 PM To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Sam, Thanks, please see my further comments with [JY]. Ok, we go on the case in your mail, where PE1 has one Root-only AC, AC1, an= d PE2 has one Leaf-only AC, AC2. In general we can setup 2 "unidirectional" PWs (bidirectional PW, but just carry unidirectional frames), Root-PW which carries frames originated from AC1 and Leaf-PW which carries frames originated from AC2. But only one PW also can work, just as some members commented. Ok, we setup one PW between PE1 and PE2, we can call this PW as compatible PW or something else. Frames originated from Root or leaf ACs will be carried via this PW. Its forwarding behavior is fully same as what traditional VPLS did, MAC learning on AC or PW in one E-Tree. Or say, if on= e PE has Root-only ACs, it will setup one PW with another PE, Root-only, Leaf-only or Root-Leaf-Mixed. If 2 PEs are root-Leaf-Mixed or other cases, then 2 PWs will be established. As you know, this can be done on control plane.=20 [JY] Assume there are 2 other nodes PE3 & PE4 in this network scenario, and both PE3 and PE4 have both root and leaf ACs, then there are compatible PWs from PE3 which may carry both root and leaf traffic (to PE1), which may carry only root traffic (to PE2); and further there are root PW and leaf PW to PE4. Thus, the VSI on PE3 has at least 4 different types of PW transmitting behaviours with regard to the E-Tree traffic. In the reverse direction, the VSI on PE3 further has at least 4 different types of PW receiving behaviours. Not sure how you will accommodate for these PWs in both the data plane and control plane. Regards, Yuanlong Is this clear for you? Is this necessary to optimize PW setup in this case?= =20 Maybe we need to add one paragraph on forwarding behavior.=20 Again thank you very much for your comments, Sam -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Tuesday, May 15, 2012 10:27 AM To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Please see my comments in line. -----Original Message----- From: Sam Cao [mailto:yuqun.cao@gmail.com]=20 Sent: Monday, May 14, 2012 8:31 PM To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Yuanlong, We have discussed this in another thread. In fact, Daniel or I have given the answers to the questions you raised here for several time :). If we do in this way, we will reach deadlock and can not move forward :). I try to explain it again. [JY] I will apologize if you had ever provided such answers before, and you may just refer to the links rather than repeat the explanation. As you can see, I just try to understand the mechanism of 2PW and its implications, but the I-D does not include enough information. As you know, initial design we will setup 2 PWs all the time (if do in this way, I think that you have no question),=20 [JY] I will be concerned with the operational complexity of this approach. but in most cases 2 PWs are not necessary. So in 01 version, we optimize it. "Root-only VSI <-> any VSI: only root PW required" "Leaf-only VSI <-> leaf-only VSI: no PWs required" In other cases 2 PWs are needed. If so, "Leaf-only -> root-only =3D one lea= f PW" is not correct: On Leaf-only side, yes, one Leaf-only PW is created between Local Leaf type with remote Root type; on root-only side, one root-only PW is created. Maybe it is better to call this as compatible or mixed PW. So the left items you list are not correct for multi_PW solution. [JY] This is something new, right? To be honest, I could not understand wha= t is your point: doesn't the mixed PW as you called also consist of one Leaf-only PW in one direction and one root-only PW in the other direction? Furthermore, the case you took is also one case in your guideline "Root-onl= y VSI <-> any VSI: only root PW required", don't you think that only one root PW is required following this guideline? Actually, I don't care much about what is the bidirectional PW or unidirectional PW called, but how can a VSI support such a mixed scenarios: traditional VSI assumes only one PW is required for each peer VSI, and its MAC leaning is based on bidirectional PW. But for 2PW, there are bidirectional root PW, bidirectional leaf PW, mixed PW, etc..., how to support these kinds of PWs in the same VSI is my top concern. BTW, I guess you also care this case we also have discussed before: for example, if we configure one Leaf AC on root-only PE (then it will be root-leaf-mixed PE), we will teardown the compatible PW and re-setup PWs again with 01.=20 [JY] This was discussed in the emails indeed. Regards, =20 Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com=20 =20 -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Monday, May 14, 2012 7:10 PM To: Daniel Cohn; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Daniel, Fine, now it seems more in line with what we had proposed in 2VLAN: a spoke PW behaves like root/leaf AC for a PE-r. But the same problem may also apply to the root/spoke "core PW" for Multi-PW: According to Multi-PW, only one PW is required between two PEs except when both PEs are mixed with root and leaf, so these PWs may be formed by combinations of the following unidirectional PW cases (extracted and adapte= d from Josh's email): Root-only -> any VSI =3D one root PW Leaf-only -> root-only =3D one leaf PW Leaf-only -> mixed =3D one leaf PW=20 Mixed -> root-only =3D one (root+leaf) PW =20 Mixed -> leaf-only =3D one (root+leaf) PW =20 I have a concern that the forwarding plane of PE to implement this will be very different from the traditional VPLS. Regards, Yuanlong -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Monday, May 14, 2012 5:00 PM To: Jiangyuanlong; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Yuanlong, Like I wrote below, root/leaf spoke PW behave like root/leaf AC, not like root/spoke "core PW". So no changes to forwarding plane once this is understood. DC -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Monday, May 14, 2012 11:36 AM To: Daniel Cohn; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Daniel, please see my comments in line. -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Monday, May 14, 2012 3:37 PM To: Jiangyuanlong; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Yuanlong, As I see it, for the PE-r spoke (figure 4 in RFC 4762) we establish a single PW per AC - root PW for root AC and leaf PW for leaf AC. With local configuration at the PE-rs as part of the spoke PW provisioning. And the PE-rs will treat root/leaf spoke PWs exactly as it treat root/leaf ACs. So when leaf-originated BUM traffic arrives from the core (over a leaf PW), it will be forwarded over all root spoke PWs but not on the leaf spoke PWs.=20 [JY] So in the reverse direction, you need to transport both root and leaf traffic from PE-rs over a root PW to PE-r, and transport root traffic over a leaf PW. It seems against the definition of root PW and leaf PW in the multi-PW draft. Don't this make the forwarding plane of PE-rs more complex?=20 The forwarding plane is exactly the same as described in the multi-PW draft, where spoke PWs are treated exactly like ACs. Regards, Daniel -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Friday, May 11, 2012 5:03 AM To: Daniel Cohn; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Daniel and all, When you set up two PWs from the PE-rs to a PE-r for each of its AC, do you mean that one PW is bidirectional root PW and the other is bidirectional leaf PW? My concern is: where should the leaf traffic be filtered, on the PE-rs or on the PE-r? If filtered on the PE-r, then lots of bandwidth will be wasted (for example, if the PE-r is attached with 9 leafs, then the BUM traffic from one of its leafs will be multiplied by 8 times, and be forwarded by the PE-rs to the same PE-r). If filtered on the PE-rs, not sure how you will design its forwarding plane, can you give a hint? Thanks, Yuanlong ------------------------------ Date: Wed, 9 May 2012 09:16:36 +0300 From: "Daniel Cohn" To: "Alexander Vainshtein" , "Sam Cao" , Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780CBA6@tlvmail1> Content-Type: text/plain; charset=3D"ISO-2022-JP" Hi Sasha, It's actually very simple. A frame that originated in a root AC is always transmitted only in root PW, no matter what the frame type (known/unknown unicast or broadcast). This is how the frame source information is propagated across the VPLS. So in the H-VPLS example, the PE-r will never forward a frame received over a root PW on any leaf PW, only on root PWs (toward the core or toward other spokes). Hope this clarifies it, regards, Daniel -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Alexander Vainshtein Sent: Wednesday, May 09, 2012 7:59 AM To: Sam Cao; l2vpn@ietf.org Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Sam, Lizhong and all, You've written that in the two-PW solution combined with H-VPLS the PE-r must set up two PWs with each MTU-s. If this is the case, what kind of forwarding logic should be used to prevent sending a BUM frame received from a root-PW to a given MTU-S: - back to the same MTU-S on the corresponding leaf-PW? - twice (to both root-PW and Leaf-PW) to another MTU-s? And, BTW, how is the PW selected in this case? I am aware of a technique of multiple split horizon groups in PE-r which could be possibly used for this purpose. However, since these groups have to be represented explicitly in the data plane, their potential number is limited by the forwarding HW. Other methods could be probably used for the same purpose, but they would probably subject to similar HW-based limitations. I suspect that with the dual-PW approach, the HW would pose an implicit limit, say, on a number of MTU-s that can be connected to the same PE-r and that this limit could be quite low in most cases. Based on this I suspect that the H-VPLS issue as a critical drawback of the dual-PW approach to E-Tree. My 2c, Sasha ________________________________________ From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Sam Cao [yuqun.cao@gmail.com] Sent: Wednesday, May 09, 2012 3:40 AM To: l2vpn@ietf.org Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Hi Lizhong? Thank you very much for your comments. I updated the result on this question. [Lizhong] agree with the above analysis. And we did not say it is a technical problem, but it is an operational problem again. [Sam] I agree. Dual-VLAN does not make sense. I also discussed this with Giles and Yuanlong in another mail, and we reached agreement on this: MTU should know the access mode, VPWS or VPLS, VPWS mode should configure VLAN ID on MTU but VPLS mode can not. I thought this is NOT reasonable :), but we can figure this out in draft. It seems ok. [Lizhong] not fully understand. Do you mean, when VPWS accessing for H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf PW) for each AC access? [Sam] Yes. Thanks, Sam =20 From yuqun.cao@gmail.com Tue May 15 06:31: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 C099021F89A6 for ; Tue, 15 May 2012 06:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.723 X-Spam-Level: X-Spam-Status: No, score=-2.723 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, J_CHICKENPOX_23=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 nSG3W3Lgnfsi for ; Tue, 15 May 2012 06:31:58 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 49A7621F8941 for ; Tue, 15 May 2012 06:31:58 -0700 (PDT) Received: by dacx6 with SMTP id x6so7586543dac.31 for ; Tue, 15 May 2012 06:31: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:content-transfer-encoding:x-mailer:in-reply-to :thread-index:x-mimeole; bh=Q1SpTHC3XVKhysECWhx0hR0iyVNYUk0lF/Ug5ZfYhls=; b=zy8M3AQjhvaJthjytnSkoWUoMvJEGw5DiPjqCDrddyC2lYCbD19HDQX9eVHImmVdfn PDhRJH155Yf3uZMjrHeTHu+/ATEHQ3+Posp0PJb0GAt/qOs/BonNbw5Fpc0mZqay3hj6 8Uh7KjeCMVHFAKUvjl4Ujkz++3Ydg0aGX9Ef7SjAWrQ0Ip5WYbfPd/IsKsZ/MksQGHSi N6N/LhjV/oE2/m7WmWtnrAOV47nrKQZ7cJ64pycU8cYOusQ76ZBgrM4Cv/iCr4pCbvih CsCYfmq+w4Dtn+LHCQedfy9Tvz1R49iyWB0xhW4sbCIx/fy3Wf1uuR9BoBM03RCM261k bOvg== Received: by 10.68.220.97 with SMTP id pv1mr5410529pbc.158.1337088717808; Tue, 15 May 2012 06:31:57 -0700 (PDT) Received: from v2comsam ([36.248.0.44]) by mx.google.com with ESMTPS id pu9sm1887414pbc.36.2012.05.15.06.31.51 (version=SSLv3 cipher=OTHER); Tue, 15 May 2012 06:31:56 -0700 (PDT) From: "Sam Cao" To: "'Jiangyuanlong'" , "'Daniel Cohn'" , "'Alexander Vainshtein'" References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D411694@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF5C@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D4130E1@szxeml546-mbs.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF8F@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413216@szxeml546-mbs.china.huawei.com> <3F1F3739E2B04D399CC7D26CE934F91A@v2comsam> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413694@szxeml546-mbs.china.huawei.com> <7A564821DF1642E592E884D5C623772C@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D41370E@szxeml546-mbs.china.huawei.com> <400D5D93E6AA4075861CE09919D84747@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413741@szxeml546-mbs.china.huawei.com> Subject: RE: Discussion on forwarding performance Date: Tue, 15 May 2012 21:32:02 +0800 Message-ID: <7BDA456234D045E1BD42EA059A4E9579@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: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413741@szxeml546-mbs.china.huawei.com> Thread-index: AQHNLxo31u2OjZw96UuBF9QPOwJXg5bHcLkAgAGHLZCAAAmjYIAAHGPggAAUqSCAAOHDIIAAM7tggAAlyMCAADHVIIAAElJAgAAmSSA= 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, 15 May 2012 13:31:59 -0000 Hi Yuanlong, 3rd mapping will make data plane complex, I think. Anyway, we reached a consensus on Multi-PW implementation. If we use 3rd mapping, I agree with your opinion, maybe dual-VLAN seems simple, but 2 mapping is enough. Then we can focus on data plane performance. While stripe PW label out on egress PE, data-plane knows how to forward the frames from PW, to Root AC or Leaf AC or all. But if we use Dual-VLAN, after strip PW label out, data plane should strip VLAN-ID out and then does same forwarding work as Multi-PW does. The most important is, do one more operation while forwarding E-Tree frames. Obviously the forwarding performance of Dual-VLAN will be much lower than what of Multi-PW. Regards, Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] Sent: Tuesday, May 15, 2012 7:03 PM To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS See my further comments in line. -----Original Message----- From: Sam Cao [mailto:yuqun.cao@gmail.com] Sent: Tuesday, May 15, 2012 6:14 PM To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Yuanlong, Thank you very much for your comments. I draw the topology you gave, and 7 PWs will be established if we follow 01. Root AC ---- PE 1 ----- PW 1 -------- PE 2 ----- Leaf _AC | \ / || | \ /===PW 6,7=== || PW 2 -----PW 5------\ || | /----Root PW 3 --- \ || Root _AC ---- PE 3 PE 4 ------ Root AC | \ / | | ----Leaf PW 4----- | Leaf AC Leaf AC Yes, on PE 3 there are several PWs, but if you want to clarify it, there are only 3 types, one can carry frames originated from Root and Leaf AC(one endpoint of this PW should be Root-only, otherwise this is invalid), one only can carry frames from Root AC, and the last can carry frames from Leaf ACs. On second thoughts, we still can classify the PWs into 2 sets, one is Leaf set, and another is Root set, and the union of the sets Leaf and Root is the PW we called it as compatible PW (Maybe this is not correct, we can find one good term on this). So this optimization still follows the original design of Dual-PW approach, Leaf PW only carries frames from Leaf AC; Root-PW only carries frames from Root AC. Is it right? I don't know whether chip can support this forwarding behavior for compatible PW or not, but if we implement it in NP, it is nearly same as VPLS. The only difference is, setup 2 mappings, one between Leaf-ACs and Leaf-PWs, one between Root-ACs and Root-PWs. For traditional VPLS, there is only one mapping. [JY] It seems you may need a 3rd mapping: from both root & leaf AC to a compatible PW. BTW, for the forwarding and reverse direction, the mapping may be asymmetric for you compatible PW. Based on my understanding, all drafts should have similar mapping. [JY] Dual-VLAN seems simpler here. Thanks, Sam -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] Sent: Tuesday, May 15, 2012 3:32 PM To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Sam, Thanks, please see my further comments with [JY]. Ok, we go on the case in your mail, where PE1 has one Root-only AC, AC1, and PE2 has one Leaf-only AC, AC2. In general we can setup 2 "unidirectional" PWs (bidirectional PW, but just carry unidirectional frames), Root-PW which carries frames originated from AC1 and Leaf-PW which carries frames originated from AC2. But only one PW also can work, just as some members commented. Ok, we setup one PW between PE1 and PE2, we can call this PW as compatible PW or something else. Frames originated from Root or leaf ACs will be carried via this PW. Its forwarding behavior is fully same as what traditional VPLS did, MAC learning on AC or PW in one E-Tree. Or say, if one PE has Root-only ACs, it will setup one PW with another PE, Root-only, Leaf-only or Root-Leaf-Mixed. If 2 PEs are root-Leaf-Mixed or other cases, then 2 PWs will be established. As you know, this can be done on control plane. [JY] Assume there are 2 other nodes PE3 & PE4 in this network scenario, and both PE3 and PE4 have both root and leaf ACs, then there are compatible PWs from PE3 which may carry both root and leaf traffic (to PE1), which may carry only root traffic (to PE2); and further there are root PW and leaf PW to PE4. Thus, the VSI on PE3 has at least 4 different types of PW transmitting behaviours with regard to the E-Tree traffic. In the reverse direction, the VSI on PE3 further has at least 4 different types of PW receiving behaviours. Not sure how you will accommodate for these PWs in both the data plane and control plane. Regards, Yuanlong Is this clear for you? Is this necessary to optimize PW setup in this case? Maybe we need to add one paragraph on forwarding behavior. Again thank you very much for your comments, Sam -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] Sent: Tuesday, May 15, 2012 10:27 AM To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Please see my comments in line. -----Original Message----- From: Sam Cao [mailto:yuqun.cao@gmail.com] Sent: Monday, May 14, 2012 8:31 PM To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Yuanlong, We have discussed this in another thread. In fact, Daniel or I have given the answers to the questions you raised here for several time :). If we do in this way, we will reach deadlock and can not move forward :). I try to explain it again. [JY] I will apologize if you had ever provided such answers before, and you may just refer to the links rather than repeat the explanation. As you can see, I just try to understand the mechanism of 2PW and its implications, but the I-D does not include enough information. As you know, initial design we will setup 2 PWs all the time (if do in this way, I think that you have no question), [JY] I will be concerned with the operational complexity of this approach. but in most cases 2 PWs are not necessary. So in 01 version, we optimize it. "Root-only VSI <-> any VSI: only root PW required" "Leaf-only VSI <-> leaf-only VSI: no PWs required" In other cases 2 PWs are needed. If so, "Leaf-only -> root-only = one leaf PW" is not correct: On Leaf-only side, yes, one Leaf-only PW is created between Local Leaf type with remote Root type; on root-only side, one root-only PW is created. Maybe it is better to call this as compatible or mixed PW. So the left items you list are not correct for multi_PW solution. [JY] This is something new, right? To be honest, I could not understand what is your point: doesn't the mixed PW as you called also consist of one Leaf-only PW in one direction and one root-only PW in the other direction? Furthermore, the case you took is also one case in your guideline "Root-only VSI <-> any VSI: only root PW required", don't you think that only one root PW is required following this guideline? Actually, I don't care much about what is the bidirectional PW or unidirectional PW called, but how can a VSI support such a mixed scenarios: traditional VSI assumes only one PW is required for each peer VSI, and its MAC leaning is based on bidirectional PW. But for 2PW, there are bidirectional root PW, bidirectional leaf PW, mixed PW, etc..., how to support these kinds of PWs in the same VSI is my top concern. BTW, I guess you also care this case we also have discussed before: for example, if we configure one Leaf AC on root-only PE (then it will be root-leaf-mixed PE), we will teardown the compatible PW and re-setup PWs again with 01. [JY] This was discussed in the emails indeed. Regards, Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] Sent: Monday, May 14, 2012 7:10 PM To: Daniel Cohn; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Daniel, Fine, now it seems more in line with what we had proposed in 2VLAN: a spoke PW behaves like root/leaf AC for a PE-r. But the same problem may also apply to the root/spoke "core PW" for Multi-PW: According to Multi-PW, only one PW is required between two PEs except when both PEs are mixed with root and leaf, so these PWs may be formed by combinations of the following unidirectional PW cases (extracted and adapted from Josh's email): Root-only -> any VSI = one root PW Leaf-only -> root-only = one leaf PW Leaf-only -> mixed = one leaf PW Mixed -> root-only = one (root+leaf) PW Mixed -> leaf-only = one (root+leaf) PW I have a concern that the forwarding plane of PE to implement this will be very different from the traditional VPLS. Regards, Yuanlong -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: Monday, May 14, 2012 5:00 PM To: Jiangyuanlong; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Yuanlong, Like I wrote below, root/leaf spoke PW behave like root/leaf AC, not like root/spoke "core PW". So no changes to forwarding plane once this is understood. DC -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] Sent: Monday, May 14, 2012 11:36 AM To: Daniel Cohn; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Daniel, please see my comments in line. -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: Monday, May 14, 2012 3:37 PM To: Jiangyuanlong; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Yuanlong, As I see it, for the PE-r spoke (figure 4 in RFC 4762) we establish a single PW per AC - root PW for root AC and leaf PW for leaf AC. With local configuration at the PE-rs as part of the spoke PW provisioning. And the PE-rs will treat root/leaf spoke PWs exactly as it treat root/leaf ACs. So when leaf-originated BUM traffic arrives from the core (over a leaf PW), it will be forwarded over all root spoke PWs but not on the leaf spoke PWs. [JY] So in the reverse direction, you need to transport both root and leaf traffic from PE-rs over a root PW to PE-r, and transport root traffic over a leaf PW. It seems against the definition of root PW and leaf PW in the multi-PW draft. Don't this make the forwarding plane of PE-rs more complex? The forwarding plane is exactly the same as described in the multi-PW draft, where spoke PWs are treated exactly like ACs. Regards, Daniel -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] Sent: Friday, May 11, 2012 5:03 AM To: Daniel Cohn; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Daniel and all, When you set up two PWs from the PE-rs to a PE-r for each of its AC, do you mean that one PW is bidirectional root PW and the other is bidirectional leaf PW? My concern is: where should the leaf traffic be filtered, on the PE-rs or on the PE-r? If filtered on the PE-r, then lots of bandwidth will be wasted (for example, if the PE-r is attached with 9 leafs, then the BUM traffic from one of its leafs will be multiplied by 8 times, and be forwarded by the PE-rs to the same PE-r). If filtered on the PE-rs, not sure how you will design its forwarding plane, can you give a hint? Thanks, Yuanlong ------------------------------ Date: Wed, 9 May 2012 09:16:36 +0300 From: "Daniel Cohn" To: "Alexander Vainshtein" , "Sam Cao" , Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780CBA6@tlvmail1> Content-Type: text/plain; charset="ISO-2022-JP" Hi Sasha, It's actually very simple. A frame that originated in a root AC is always transmitted only in root PW, no matter what the frame type (known/unknown unicast or broadcast). This is how the frame source information is propagated across the VPLS. So in the H-VPLS example, the PE-r will never forward a frame received over a root PW on any leaf PW, only on root PWs (toward the core or toward other spokes). Hope this clarifies it, regards, Daniel -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Alexander Vainshtein Sent: Wednesday, May 09, 2012 7:59 AM To: Sam Cao; l2vpn@ietf.org Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Sam, Lizhong and all, You've written that in the two-PW solution combined with H-VPLS the PE-r must set up two PWs with each MTU-s. If this is the case, what kind of forwarding logic should be used to prevent sending a BUM frame received from a root-PW to a given MTU-S: - back to the same MTU-S on the corresponding leaf-PW? - twice (to both root-PW and Leaf-PW) to another MTU-s? And, BTW, how is the PW selected in this case? I am aware of a technique of multiple split horizon groups in PE-r which could be possibly used for this purpose. However, since these groups have to be represented explicitly in the data plane, their potential number is limited by the forwarding HW. Other methods could be probably used for the same purpose, but they would probably subject to similar HW-based limitations. I suspect that with the dual-PW approach, the HW would pose an implicit limit, say, on a number of MTU-s that can be connected to the same PE-r and that this limit could be quite low in most cases. Based on this I suspect that the H-VPLS issue as a critical drawback of the dual-PW approach to E-Tree. My 2c, Sasha ________________________________________ From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Sam Cao [yuqun.cao@gmail.com] Sent: Wednesday, May 09, 2012 3:40 AM To: l2vpn@ietf.org Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Hi Lizhong? Thank you very much for your comments. I updated the result on this question. [Lizhong] agree with the above analysis. And we did not say it is a technical problem, but it is an operational problem again. [Sam] I agree. Dual-VLAN does not make sense. I also discussed this with Giles and Yuanlong in another mail, and we reached agreement on this: MTU should know the access mode, VPWS or VPLS, VPWS mode should configure VLAN ID on MTU but VPLS mode can not. I thought this is NOT reasonable :), but we can figure this out in draft. It seems ok. [Lizhong] not fully understand. Do you mean, when VPWS accessing for H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf PW) for each AC access? [Sam] Yes. Thanks, Sam From lizho.jin@gmail.com Tue May 15 07: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 8702C21F8712 for ; Tue, 15 May 2012 07:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.445 X-Spam-Level: X-Spam-Status: No, score=-3.445 tagged_above=-999 required=5 tests=[AWL=0.153, 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 BGrdPuPXIezk for ; Tue, 15 May 2012 07:43:18 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 78C2321F87E0 for ; Tue, 15 May 2012 07:43:18 -0700 (PDT) Received: by ggnc4 with SMTP id c4so2877797ggn.31 for ; Tue, 15 May 2012 07:43:18 -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=rZgUN0FT/AMMXsP8xoBcUTD+xgMjbi7IMJsU+gj9D2g=; b=teBIDKYAmlqdPEg7ot8RdooXvCm5kqUOpIYjdQH73yi/PYNS6ICCw5YBOsyLRhvtWa oWIsgagIhKk5ufC/iWKvj/xNpIfHueiX2psVaGQvcArLu3rLWBtEA4O6ES7LhBckVk24 w9qzb+Oh3wryMGG8QPcyEE4wKHumWOpuVMAwVoQV/Ql5hZrtyxkL65KP85Tq0UGvgVQ8 0vK+uvbtvHT8dfJORZGpIpliN2enJh1vbXBwHg+JAHcuQk2kOpFUk1s6Sf78RZLvfhQQ 58PSFp7IlVm6kJXew/cwWS13to0BUp014N/uapA4mH4+lgqUwvzx5FICFoLf/8PvM6Tq 45iw== MIME-Version: 1.0 Received: by 10.50.156.229 with SMTP id wh5mr7381948igb.28.1337092997808; Tue, 15 May 2012 07:43:17 -0700 (PDT) Received: by 10.50.106.198 with HTTP; Tue, 15 May 2012 07:43:17 -0700 (PDT) Date: Tue, 15 May 2012 22:43:17 +0800 Message-ID: Subject: Re: PBB E-VPN and TRILL From: Lizhong Jin To: Giles Heron Content-Type: multipart/alternative; boundary=e89a8f2346a92a809504c01439e3 Cc: l2vpn@ietf.org, Ali Sajassi , "Stewart Bryant \(stbryant\)" 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, 15 May 2012 14:43:19 -0000 --e89a8f2346a92a809504c01439e3 Content-Type: text/plain; charset=ISO-8859-1 Yes to all three. Lizhong > ------------------------------ > > Message: 3 > Date: Wed, 09 May 2012 13:34:16 +0100 > From: Giles Heron > To: > Cc: "Ali Sajassi \(sajassi\)" , Stewart Bryant > > Subject: PBB E-VPN and TRILL > Message-ID: > Content-Type: text/plain; charset="US-ASCII" > > Ali presented the PBB-EVPN draft at IETF83 in Paris: > > http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-01 > > This has since been updated: > > http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-02 > > During our discussions Ali mentioned that the authors would like the TRILL > section of the draft to be separated out into a separate draft. In > response > Stewart questioned whether interconnecting TRILL islands is in-scope for > L2VPN. > > Stewart, Nabil and I have just been discussing these issues. Whilst TRILL > interconnect is not explicitly in-charter for L2VPN it would appear to be > implicitly in-charter - our decision to standardise solutions for PBB VPLS > and PBB E-VPN probably sets a precedent (since PBB is also unmentioned by > the charter). > > On this basis we would like to ask the WG the following three questions: > > 1) is the WG happy for us to pursue interconnection of TRILL islands over > L2VPN? > > 2) is the WG happy for the authors to split the TRILL section of the PBB > E-VPN draft into a separate draft? > > 3) is the WG happy for the TRILL draft to be a WG doc? > > Please respond by May 22nd if you are unhappy with any of these 3 actions > (I'll take no response to mean the WG is in agreement with us > proceeding...) > > Giles > > > > --e89a8f2346a92a809504c01439e3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yes to all three.
=A0
Lizhong
=A0
------------------------------
Message: 3
Date: Wed, 09 May 2012 13:34:16 +0100
From: Giles Heron &= lt;giles.heron@gmail.com> To: <l2vpn@ietf.org>
Cc: &qu= ot;Ali Sajassi \(sajassi\)" <s= ajassi@cisco.com>, =A0 =A0 =A0Stewart Bryant
=A0 =A0 =A0 =A0<<= a href=3D"mailto:stbryant@cisco.com">stbryant@cisco.com>
Subject: PBB E-VPN and TRILL
Message-ID: <CBD022D8.1AC48%giles.heron@gmail.com>=
Content-Type: text/plain; =A0 =A0 =A0 charset=3D"US-ASCII"
Ali presented the PBB-EVPN draft at IETF83 in Paris:

http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-01<= br>
This has since been updated:

http://tools.ietf.org= /html/draft-ietf-l2vpn-pbb-evpn-02

During our discussions Ali mentioned that the authors would like the TR= ILL
section of the draft to be separated out into a separate draft. =A0I= n response
Stewart questioned whether interconnecting TRILL islands is i= n-scope for
L2VPN.

Stewart, Nabil and I have just been discussing these issues. = =A0Whilst TRILL
interconnect is not explicitly in-charter for L2VPN it w= ould appear to be
implicitly in-charter - our decision to standardise so= lutions for PBB VPLS
and PBB E-VPN probably sets a precedent (since PBB is also unmentioned bythe charter).

On this basis we would like to ask the WG the follow= ing three questions:

1) is the WG happy for us to pursue interconnec= tion of TRILL islands over
L2VPN?

2) is the WG happy for the authors to split the TRILL section= of the PBB
E-VPN draft into a separate draft?

3) is the WG happy= for the TRILL draft to be a WG doc?

Please respond by May 22nd if y= ou are unhappy with any of these 3 actions
(I'll take no response to mean the WG is in agreement with us proceedin= g...)

Giles



--e89a8f2346a92a809504c01439e3-- From linda.dunbar@huawei.com Tue May 15 12:42: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 7491411E8087; Tue, 15 May 2012 12:42:12 -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=[AWL=0.396, 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 kSgbhejPeo7R; Tue, 15 May 2012 12:42:12 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id BDB1811E8089; Tue, 15 May 2012 12:42: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 AGF36179; Tue, 15 May 2012 15:42:11 -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; Tue, 15 May 2012 12:40:37 -0700 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.003; Tue, 15 May 2012 12:40:35 -0700 From: Linda Dunbar To: "robert@raszuk.net" , Keshava A K Subject: RE: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version Notification for draft-xu-mpls-in-udp-00.txt Thread-Topic: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version Notification for draft-xu-mpls-in-udp-00.txt Thread-Index: AQHNLbX6Q4MUsqOU70u/fPXTAOg5TZbLSJFA Date: Tue, 15 May 2012 19:40:34 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F633931E2C@dfweml506-mbx> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02F20BF9@szxeml525-mbs.china.huawei.com> <005a01cd2d9e$900f0ac0$b02d2040$@com> <4FAA1C30.6090303@raszuk.net> In-Reply-To: <4FAA1C30.6090303@raszuk.net> 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 Cc: "l2vpn@ietf.org" , "nvo3@ietf.org" , "l3vpn@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, 15 May 2012 19:42:12 -0000 Robert,=20 When GRE encapsulation uses different SRC/DST addresses for different flows= , it means that same OverlayBoundaryPoint needs multiple addresses. Does it= also mean an IP prefix can be given to a OverlayBoundaryPoint? I guess for= IPv6, there shouldn't be any issues, should it? (well I am not an IPv6 exp= ert).=20 Linda > -----Original Message----- > From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf Of > Robert Raszuk > Sent: Wednesday, May 09, 2012 2:27 AM > To: Keshava A K > Cc: l2vpn@ietf.org; Xuxiaohu; nvo3@ietf.org; l3vpn@ietf.org > Subject: Re: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN > traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version > Notification for draft-xu-mpls-in-udp-00.txt >=20 >=20 > > If switches were to try to distribute GRE flows between two VTEPs > > that used a GRE encapsulation, all the traffic would be directed to > > use only one link within these Port Channels. >=20 > Not true. GRE encapsulation is not mandated to use the same src/dst > addresses for all flows between given two end points. >=20 > You do not need to parse deep into packet to enable good load balancing > hash across parallel links when you use GRE as an encapsulation > technology. >=20 > And what is nice about IP encapsulation all GRE src/dst addresses can > be > naturally aggregated so from IGP point of view they still look like a > single prefix. >=20 > Regards, > R. > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 From florin.balus@alcatel-lucent.com Tue May 15 12:52: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 DECD011E8073 for ; Tue, 15 May 2012 12:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.274 X-Spam-Level: X-Spam-Status: No, score=-9.274 tagged_above=-999 required=5 tests=[AWL=0.725, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4rpWoUQAAVky for ; Tue, 15 May 2012 12:52:54 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 6056E21F8731 for ; Tue, 15 May 2012 12:52:54 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q4FJqebk014182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 May 2012 14:52:40 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q4FJqaL7014573 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 15 May 2012 14:52:37 -0500 Received: from USNAVSXCHMBSC3.ndc.alcatel-lucent.com ([135.3.39.144]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Tue, 15 May 2012 14:52:36 -0500 From: "Balus, Florin Stelian (Florin)" To: Sam Cao , "'Jiangyuanlong'" , "'Daniel Cohn'" , "'Alexander Vainshtein'" Date: Tue, 15 May 2012 14:52:35 -0500 Subject: RE: Discussion on forwarding performance Thread-Topic: Discussion on forwarding performance Thread-Index: AQHNLxo31u2OjZw96UuBF9QPOwJXg5bHcLkAgAGHLZCAAAmjYIAAHGPggAAUqSCAAOHDIIAAM7tggAAlyMCAADHVIIAAElJAgAAmSSCAAGzc8A== Message-ID: <2073A6C5467C99478898544C6EBA3F4602C1907568@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D411694@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF5C@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D4130E1@szxeml546-mbs.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF8F@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413216@szxeml546-mbs.china.huawei.com> <3F1F3739E2B04D399CC7D26CE934F91A@v2comsam> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413694@szxeml546-mbs.china.huawei.com> <7A564821DF1642E592E884D5C623772C@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D41370E@szxeml546-mbs.china.huawei.com> <400D5D93E6AA4075861CE09919D84747@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413741@szxeml546-mbs.china.huawei.com> <7BDA456234D045E1BD42EA059A4E9579@v2comsam> In-Reply-To: <7BDA456234D045E1BD42EA059A4E9579@v2comsam> 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.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 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, 15 May 2012 19:52:56 -0000 Sam, > Obviously the forwarding performance of Dual-VLAN will be much lower than= what of Multi-PW. Sorry I could not keep up with some of the threads on this subject but the = above statement caught my eyes. We have been doing all kind of egress opera= tions on VLANs in the egress PE for the last 8 years and I am not aware of = any "much lower" forwarding performance. As far as I know the chipsets used= in the PEs can do this processing no problem. Do you want to clarify which= kind of hardware may have problems? > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Sam Cao > Sent: Tuesday, May 15, 2012 6:32 AM > To: 'Jiangyuanlong'; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on forwarding performance > > Hi Yuanlong, > > 3rd mapping will make data plane complex, I think. Anyway, we reached a > consensus on Multi-PW implementation. > > If we use 3rd mapping, I agree with your opinion, maybe dual-VLAN seems > simple, but 2 mapping is enough. Then we can focus on data plane > performance. While stripe PW label out on egress PE, data-plane knows > how to forward the frames from PW, to Root AC or Leaf AC or all. But if > we use Dual-VLAN, after strip PW label out, data plane should strip > VLAN-ID out and then does same forwarding work as Multi-PW does. The > most important is, do one more operation while forwarding E-Tree > frames. Obviously the forwarding performance of Dual-VLAN will be much > lower than what of Multi-PW. > > Regards, > > Yuqun (Sam) Cao > E-mail: Yuqun.cao@gmail.com > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 7:03 PM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > See my further comments in line. > > -----Original Message----- > From: Sam Cao [mailto:yuqun.cao@gmail.com] > Sent: Tuesday, May 15, 2012 6:14 PM > To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > Thank you very much for your comments. I draw the topology you gave, > and 7 PWs will be established if we follow 01. > > Root AC ---- PE 1 ----- PW 1 -------- PE 2 ----- Leaf _AC > | \ / || > | \ /=3D=3D=3DPW 6,7=3D=3D=3D || > PW 2 -----PW 5------\ || > | /----Root PW 3 --- \ || > Root _AC ---- PE 3 PE 4 ------ Root AC > | \ / | > | ----Leaf PW 4----- | > Leaf AC Leaf AC > Yes, on PE 3 there are several PWs, but if you want to clarify it, > there are only 3 types, one can carry frames originated from Root and > Leaf AC(one endpoint of this PW should be Root-only, otherwise this is > invalid), one only can carry frames from Root AC, and the last can > carry frames from Leaf ACs. On second thoughts, we still can classify > the PWs into 2 sets, one is Leaf set, and another is Root set, and the > union of the sets Leaf and Root is the PW we called it as compatible PW > (Maybe this is not correct, we can find one good term on this). > > So this optimization still follows the original design of Dual-PW > approach, Leaf PW only carries frames from Leaf AC; Root-PW only > carries frames from Root AC. Is it right? > > I don't know whether chip can support this forwarding behavior for > compatible PW or not, but if we implement it in NP, it is nearly same > as VPLS. The only difference is, setup 2 mappings, one between Leaf-ACs > and Leaf-PWs, one between Root-ACs and Root-PWs. For traditional VPLS, > there is only one mapping. > > [JY] It seems you may need a 3rd mapping: from both root & leaf AC to a > compatible PW. > BTW, for the forwarding and reverse direction, the mapping may be > asymmetric for you compatible PW. > > Based on my understanding, all drafts should have similar mapping. > > [JY] Dual-VLAN seems simpler here. > > Thanks, > > Sam > > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 3:32 PM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Sam, > > Thanks, please see my further comments with [JY]. > > Ok, we go on the case in your mail, where PE1 has one Root-only AC, > AC1, and > PE2 has one Leaf-only AC, AC2. In general we can setup 2 > "unidirectional" > PWs (bidirectional PW, but just carry unidirectional frames), Root-PW > which carries frames originated from AC1 and Leaf-PW which carries > frames originated from AC2. But only one PW also can work, just as some > members commented. Ok, we setup one PW between PE1 and PE2, we can call > this PW as compatible PW or something else. Frames originated from Root > or leaf ACs will be carried via this PW. Its forwarding behavior is > fully same as what traditional VPLS did, MAC learning on AC or PW in > one E-Tree. Or say, if one PE has Root-only ACs, it will setup one PW > with another PE, Root-only, Leaf-only or Root-Leaf-Mixed. If 2 PEs are > root-Leaf-Mixed or other cases, then 2 PWs will be established. As you > know, this can be done on control plane. > > [JY] Assume there are 2 other nodes PE3 & PE4 in this network scenario, > and both PE3 and PE4 have both root and leaf ACs, then there are > compatible PWs from PE3 which may carry both root and leaf traffic (to > PE1), which may carry only root traffic (to PE2); and further there are > root PW and leaf PW to PE4. Thus, the VSI on PE3 has at least 4 > different types of PW transmitting behaviours with regard to the E-Tree > traffic. In the reverse direction, the VSI on PE3 further has at least > 4 different types of PW receiving behaviours. Not sure how you will > accommodate for these PWs in both the data plane and control plane. > > Regards, > Yuanlong > > Is this clear for you? Is this necessary to optimize PW setup in this > case? > > Maybe we need to add one paragraph on forwarding behavior. > > Again thank you very much for your comments, > > Sam > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 10:27 AM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Please see my comments in line. > > -----Original Message----- > From: Sam Cao [mailto:yuqun.cao@gmail.com] > Sent: Monday, May 14, 2012 8:31 PM > To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > We have discussed this in another thread. In fact, Daniel or I have > given the answers to the questions you raised here for several time :). > If we do in this way, we will reach deadlock and can not move forward > :). I try to explain it again. > > [JY] I will apologize if you had ever provided such answers before, and > you may just refer to the links rather than repeat the explanation. > As you can see, I just try to understand the mechanism of 2PW and its > implications, but the I-D does not include enough information. > > As you know, initial design we will setup 2 PWs all the time (if do in > this way, I think that you have no question), > > [JY] I will be concerned with the operational complexity of this > approach. > > but in most cases 2 PWs are not > necessary. So in 01 version, we optimize it. > > "Root-only VSI <-> any VSI: only root PW required" > "Leaf-only VSI <-> leaf-only VSI: no PWs required" > > In other cases 2 PWs are needed. If so, "Leaf-only -> root-only =3D one > leaf PW" is not correct: On Leaf-only side, yes, one Leaf-only PW is > created between Local Leaf type with remote Root type; on root-only > side, one root-only PW is created. Maybe it is better to call this as > compatible or mixed PW. So the left items you list are not correct for > multi_PW solution. > > [JY] This is something new, right? To be honest, I could not understand > what is your point: doesn't the mixed PW as you called also consist of > one Leaf-only PW in one direction and one root-only PW in the other > direction? > Furthermore, the case you took is also one case in your guideline > "Root-only VSI <-> any VSI: only root PW required", don't you think > that only one root PW is required following this guideline? > Actually, I don't care much about what is the bidirectional PW or > unidirectional PW called, but how can a VSI support such a mixed > scenarios: > traditional VSI assumes only one PW is required for each peer VSI, and > its MAC leaning is based on bidirectional PW. But for 2PW, there are > bidirectional root PW, bidirectional leaf PW, mixed PW, etc..., how to > support these kinds of PWs in the same VSI is my top concern. > > BTW, I guess you also care this case we also have discussed before: for > example, if we configure one Leaf AC on root-only PE (then it will be > root-leaf-mixed PE), we will teardown the compatible PW and re-setup > PWs again with 01. > [JY] This was discussed in the emails indeed. > > Regards, > > Yuqun (Sam) Cao > E-mail: Yuqun.cao@gmail.com > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Monday, May 14, 2012 7:10 PM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Daniel, > > Fine, now it seems more in line with what we had proposed in 2VLAN: a > spoke PW behaves like root/leaf AC for a PE-r. > > But the same problem may also apply to the root/spoke "core PW" for > Multi-PW: > According to Multi-PW, only one PW is required between two PEs except > when both PEs are mixed with root and leaf, so these PWs may be formed > by combinations of the following unidirectional PW cases (extracted and > adapted from Josh's email): > Root-only -> any VSI =3D one root PW > Leaf-only -> root-only =3D one leaf PW > Leaf-only -> mixed =3D one leaf PW > Mixed -> root-only =3D one (root+leaf) PW > Mixed -> leaf-only =3D one (root+leaf) PW > > I have a concern that the forwarding plane of PE to implement this will > be very different from the traditional VPLS. > > Regards, > Yuanlong > > -----Original Message----- > From: Daniel Cohn [mailto:DanielC@orckit.com] > Sent: Monday, May 14, 2012 5:00 PM > To: Jiangyuanlong; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > Like I wrote below, root/leaf spoke PW behave like root/leaf AC, not > like root/spoke "core PW". So no changes to forwarding plane once this > is understood. > > DC > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Monday, May 14, 2012 11:36 AM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Daniel, please see my comments in line. > > -----Original Message----- > From: Daniel Cohn [mailto:DanielC@orckit.com] > Sent: Monday, May 14, 2012 3:37 PM > To: Jiangyuanlong; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > As I see it, for the PE-r spoke (figure 4 in RFC 4762) we establish a > single PW per AC - root PW for root AC and leaf PW for leaf AC. With > local configuration at the PE-rs as part of the spoke PW provisioning. > And the PE-rs will treat root/leaf spoke PWs exactly as it treat > root/leaf ACs. So when leaf-originated BUM traffic arrives from the > core (over a leaf PW), it will be forwarded over all root spoke PWs but > not on the leaf spoke PWs. > > [JY] So in the reverse direction, you need to transport both root and > leaf traffic from PE-rs over a root PW to PE-r, and transport root > traffic over a leaf PW. It seems against the definition of root PW and > leaf PW in the multi-PW draft. Don't this make the forwarding plane of > PE-rs more complex? > > The forwarding plane is exactly the same as described in the multi-PW > draft, where spoke PWs are treated exactly like ACs. > > Regards, > > Daniel > > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Friday, May 11, 2012 5:03 AM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Daniel and all, > > When you set up two PWs from the PE-rs to a PE-r for each of its AC, do > you mean that one PW is bidirectional root PW and the other is > bidirectional leaf PW? > My concern is: where should the leaf traffic be filtered, on the PE-rs > or on the PE-r? > If filtered on the PE-r, then lots of bandwidth will be wasted (for > example, if the PE-r is attached with 9 leafs, then the BUM traffic > from one of its leafs will be multiplied by 8 times, and be forwarded > by the PE-rs to the same PE-r). > If filtered on the PE-rs, not sure how you will design its forwarding > plane, can you give a hint? > > Thanks, > Yuanlong > > ------------------------------ > Date: Wed, 9 May 2012 09:16:36 +0300 > From: "Daniel Cohn" > To: "Alexander Vainshtein" , "Sa= m > Cao" , > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780CBA6@tlvmail1> > Content-Type: text/plain; charset=3D"ISO-2022-JP" > > Hi Sasha, > > It's actually very simple. A frame that originated in a root AC is > always transmitted only in root PW, no matter what the frame type > (known/unknown unicast or broadcast). This is how the frame source > information is propagated across the VPLS. So in the H-VPLS example, > the PE-r will never forward a frame received over a root PW on any leaf > PW, only on root PWs (toward the core or toward other spokes). > > Hope this clarifies it, regards, > > Daniel > > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Alexander Vainshtein > Sent: Wednesday, May 09, 2012 7:59 AM > To: Sam Cao; l2vpn@ietf.org > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > > Sam, Lizhong and all, > You've written that in the two-PW solution combined with H-VPLS the PE- > r must set up two PWs with each MTU-s. > > If this is the case, what kind of forwarding logic should be used to > prevent sending a BUM frame received from a root-PW to a given MTU-S: > - back to the same MTU-S on the corresponding leaf-PW? > - twice (to both root-PW and Leaf-PW) to another MTU-s? And, BTW, how > is the PW selected in this case? > > I am aware of a technique of multiple split horizon groups in PE-r > which could be possibly used for this purpose. However, since these > groups have to be represented explicitly in the data plane, their > potential number is limited by the forwarding HW. Other methods could > be probably used for the same purpose, but they would probably subject > to similar HW-based limitations. > > I suspect that with the dual-PW approach, the HW would pose an implicit > limit, say, on a number of MTU-s that can be connected to the same PE-r > and that this limit could be quite low in most cases. > > Based on this I suspect that the H-VPLS issue as a critical drawback of > the dual-PW approach to E-Tree. > > My 2c, > Sasha > > > ________________________________________ > From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Sam > Cao [yuqun.cao@gmail.com] > Sent: Wednesday, May 09, 2012 3:40 AM > To: l2vpn@ietf.org > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Lizhong? > > Thank you very much for your comments. I updated the result on this > question. > > [Lizhong] agree with the above analysis. And we did not say it is a > technical problem, but it is an operational problem again. > [Sam] I agree. Dual-VLAN does not make sense. I also discussed this > with Giles and Yuanlong in another mail, and we reached agreement on > this: > MTU should know the access mode, VPWS or VPLS, VPWS mode should > configure VLAN ID on MTU but VPLS mode can not. I thought this is NOT > reasonable :), but we can figure this out in draft. It seems ok. > > [Lizhong] not fully understand. Do you mean, when VPWS accessing for > H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf > PW) for each AC access? > [Sam] Yes. > > Thanks, > > Sam > > > > From david.i.allan@ericsson.com Tue May 15 12:55: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 C1CCF11E80A0 for ; Tue, 15 May 2012 12:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=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 IylkFOJX6ZUJ for ; Tue, 15 May 2012 12:55:44 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 38A7A11E8073 for ; Tue, 15 May 2012 12:55:44 -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 q4FJtODV008720 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 May 2012 14:55:32 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.69]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Tue, 15 May 2012 15:55:29 -0400 From: David Allan I To: "Balus, Florin Stelian (Florin)" , Sam Cao , "'Jiangyuanlong'" , "'Daniel Cohn'" , "'Alexander Vainshtein'" Date: Tue, 15 May 2012 15:55:27 -0400 Subject: RE: Discussion on forwarding performance Thread-Topic: Discussion on forwarding performance Thread-Index: AQHNLxo31u2OjZw96UuBF9QPOwJXg5bHcLkAgAGHLZCAAAmjYIAAHGPggAAUqSCAAOHDIIAAM7tggAAlyMCAADHVIIAAElJAgAAmSSCAAGzc8IAABagA Message-ID: <60C093A41B5E45409A19D42CF7786DFD52328D98DF@EUSAACMS0703.eamcs.ericsson.se> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D411694@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF5C@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D4130E1@szxeml546-mbs.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF8F@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413216@szxeml546-mbs.china.huawei.com> <3F1F3739E2B04D399CC7D26CE934F91A@v2comsam> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413694@szxeml546-mbs.china.huawei.com> <7A564821DF1642E592E884D5C623772C@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D41370E@szxeml546-mbs.china.huawei.com> <400D5D93E6AA4075861CE09919D84747@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413741@szxeml546-mbs.china.huawei.com> <7BDA456234D045E1BD42EA059A4E9579@v2comsam> <2073A6C5467C99478898544C6EBA3F4602C1907568@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> In-Reply-To: <2073A6C5467C99478898544C6EBA3F4602C1907568@USNAVSXCHMBSC3.ndc.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: Tue, 15 May 2012 19:55:45 -0000 Florin: I agree. The statement, at least to me, is a non-sequitor... Cheers Dave -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of B= alus, Florin Stelian (Florin) Sent: Tuesday, May 15, 2012 12:53 PM To: Sam Cao; 'Jiangyuanlong'; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance Sam, > Obviously the forwarding performance of Dual-VLAN will be much lower than= what of Multi-PW. Sorry I could not keep up with some of the threads on this subject but the = above statement caught my eyes. We have been doing all kind of egress opera= tions on VLANs in the egress PE for the last 8 years and I am not aware of = any "much lower" forwarding performance. As far as I know the chipsets used= in the PEs can do this processing no problem. Do you want to clarify which= kind of hardware may have problems? > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Sam Cao > Sent: Tuesday, May 15, 2012 6:32 AM > To: 'Jiangyuanlong'; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on forwarding performance > > Hi Yuanlong, > > 3rd mapping will make data plane complex, I think. Anyway, we reached > a consensus on Multi-PW implementation. > > If we use 3rd mapping, I agree with your opinion, maybe dual-VLAN > seems simple, but 2 mapping is enough. Then we can focus on data plane > performance. While stripe PW label out on egress PE, data-plane knows > how to forward the frames from PW, to Root AC or Leaf AC or all. But > if we use Dual-VLAN, after strip PW label out, data plane should strip > VLAN-ID out and then does same forwarding work as Multi-PW does. The > most important is, do one more operation while forwarding E-Tree > frames. Obviously the forwarding performance of Dual-VLAN will be much > lower than what of Multi-PW. > > Regards, > > Yuqun (Sam) Cao > E-mail: Yuqun.cao@gmail.com > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 7:03 PM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > See my further comments in line. > > -----Original Message----- > From: Sam Cao [mailto:yuqun.cao@gmail.com] > Sent: Tuesday, May 15, 2012 6:14 PM > To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > Thank you very much for your comments. I draw the topology you gave, > and 7 PWs will be established if we follow 01. > > Root AC ---- PE 1 ----- PW 1 -------- PE 2 ----- Leaf _AC > | \ / || > | \ /=3D=3D=3DPW 6,7=3D=3D=3D || > PW 2 -----PW 5------\ || > | /----Root PW 3 --- \ || > Root _AC ---- PE 3 PE 4 ------ Root AC > | \ / | > | ----Leaf PW 4----- | > Leaf AC Leaf AC > Yes, on PE 3 there are several PWs, but if you want to clarify it, > there are only 3 types, one can carry frames originated from Root and > Leaf AC(one endpoint of this PW should be Root-only, otherwise this is > invalid), one only can carry frames from Root AC, and the last can > carry frames from Leaf ACs. On second thoughts, we still can classify > the PWs into 2 sets, one is Leaf set, and another is Root set, and the > union of the sets Leaf and Root is the PW we called it as compatible > PW (Maybe this is not correct, we can find one good term on this). > > So this optimization still follows the original design of Dual-PW > approach, Leaf PW only carries frames from Leaf AC; Root-PW only > carries frames from Root AC. Is it right? > > I don't know whether chip can support this forwarding behavior for > compatible PW or not, but if we implement it in NP, it is nearly same > as VPLS. The only difference is, setup 2 mappings, one between > Leaf-ACs and Leaf-PWs, one between Root-ACs and Root-PWs. For > traditional VPLS, there is only one mapping. > > [JY] It seems you may need a 3rd mapping: from both root & leaf AC to > a compatible PW. > BTW, for the forwarding and reverse direction, the mapping may be > asymmetric for you compatible PW. > > Based on my understanding, all drafts should have similar mapping. > > [JY] Dual-VLAN seems simpler here. > > Thanks, > > Sam > > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 3:32 PM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Sam, > > Thanks, please see my further comments with [JY]. > > Ok, we go on the case in your mail, where PE1 has one Root-only AC, > AC1, and > PE2 has one Leaf-only AC, AC2. In general we can setup 2 > "unidirectional" > PWs (bidirectional PW, but just carry unidirectional frames), Root-PW > which carries frames originated from AC1 and Leaf-PW which carries > frames originated from AC2. But only one PW also can work, just as > some members commented. Ok, we setup one PW between PE1 and PE2, we > can call this PW as compatible PW or something else. Frames originated > from Root or leaf ACs will be carried via this PW. Its forwarding > behavior is fully same as what traditional VPLS did, MAC learning on > AC or PW in one E-Tree. Or say, if one PE has Root-only ACs, it will > setup one PW with another PE, Root-only, Leaf-only or Root-Leaf-Mixed. > If 2 PEs are root-Leaf-Mixed or other cases, then 2 PWs will be > established. As you know, this can be done on control plane. > > [JY] Assume there are 2 other nodes PE3 & PE4 in this network > scenario, and both PE3 and PE4 have both root and leaf ACs, then there > are compatible PWs from PE3 which may carry both root and leaf traffic > (to PE1), which may carry only root traffic (to PE2); and further > there are root PW and leaf PW to PE4. Thus, the VSI on PE3 has at > least 4 different types of PW transmitting behaviours with regard to > the E-Tree traffic. In the reverse direction, the VSI on PE3 further > has at least > 4 different types of PW receiving behaviours. Not sure how you will > accommodate for these PWs in both the data plane and control plane. > > Regards, > Yuanlong > > Is this clear for you? Is this necessary to optimize PW setup in this > case? > > Maybe we need to add one paragraph on forwarding behavior. > > Again thank you very much for your comments, > > Sam > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 10:27 AM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Please see my comments in line. > > -----Original Message----- > From: Sam Cao [mailto:yuqun.cao@gmail.com] > Sent: Monday, May 14, 2012 8:31 PM > To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > We have discussed this in another thread. In fact, Daniel or I have > given the answers to the questions you raised here for several time :). > If we do in this way, we will reach deadlock and can not move forward > :). I try to explain it again. > > [JY] I will apologize if you had ever provided such answers before, > and you may just refer to the links rather than repeat the explanation. > As you can see, I just try to understand the mechanism of 2PW and its > implications, but the I-D does not include enough information. > > As you know, initial design we will setup 2 PWs all the time (if do in > this way, I think that you have no question), > > [JY] I will be concerned with the operational complexity of this > approach. > > but in most cases 2 PWs are not > necessary. So in 01 version, we optimize it. > > "Root-only VSI <-> any VSI: only root PW required" > "Leaf-only VSI <-> leaf-only VSI: no PWs required" > > In other cases 2 PWs are needed. If so, "Leaf-only -> root-only =3D one > leaf PW" is not correct: On Leaf-only side, yes, one Leaf-only PW is > created between Local Leaf type with remote Root type; on root-only > side, one root-only PW is created. Maybe it is better to call this as > compatible or mixed PW. So the left items you list are not correct for > multi_PW solution. > > [JY] This is something new, right? To be honest, I could not > understand what is your point: doesn't the mixed PW as you called also > consist of one Leaf-only PW in one direction and one root-only PW in > the other direction? > Furthermore, the case you took is also one case in your guideline > "Root-only VSI <-> any VSI: only root PW required", don't you think > that only one root PW is required following this guideline? > Actually, I don't care much about what is the bidirectional PW or > unidirectional PW called, but how can a VSI support such a mixed > scenarios: > traditional VSI assumes only one PW is required for each peer VSI, and > its MAC leaning is based on bidirectional PW. But for 2PW, there are > bidirectional root PW, bidirectional leaf PW, mixed PW, etc..., how to > support these kinds of PWs in the same VSI is my top concern. > > BTW, I guess you also care this case we also have discussed before: > for example, if we configure one Leaf AC on root-only PE (then it will > be root-leaf-mixed PE), we will teardown the compatible PW and > re-setup PWs again with 01. > [JY] This was discussed in the emails indeed. > > Regards, > > Yuqun (Sam) Cao > E-mail: Yuqun.cao@gmail.com > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Monday, May 14, 2012 7:10 PM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Daniel, > > Fine, now it seems more in line with what we had proposed in 2VLAN: a > spoke PW behaves like root/leaf AC for a PE-r. > > But the same problem may also apply to the root/spoke "core PW" for > Multi-PW: > According to Multi-PW, only one PW is required between two PEs except > when both PEs are mixed with root and leaf, so these PWs may be formed > by combinations of the following unidirectional PW cases (extracted > and adapted from Josh's email): > Root-only -> any VSI =3D one root PW > Leaf-only -> root-only =3D one leaf PW > Leaf-only -> mixed =3D one leaf PW > Mixed -> root-only =3D one (root+leaf) PW Mixed -> leaf-only =3D one > (root+leaf) PW > > I have a concern that the forwarding plane of PE to implement this > will be very different from the traditional VPLS. > > Regards, > Yuanlong > > -----Original Message----- > From: Daniel Cohn [mailto:DanielC@orckit.com] > Sent: Monday, May 14, 2012 5:00 PM > To: Jiangyuanlong; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > Like I wrote below, root/leaf spoke PW behave like root/leaf AC, not > like root/spoke "core PW". So no changes to forwarding plane once this > is understood. > > DC > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Monday, May 14, 2012 11:36 AM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Daniel, please see my comments in line. > > -----Original Message----- > From: Daniel Cohn [mailto:DanielC@orckit.com] > Sent: Monday, May 14, 2012 3:37 PM > To: Jiangyuanlong; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > As I see it, for the PE-r spoke (figure 4 in RFC 4762) we establish a > single PW per AC - root PW for root AC and leaf PW for leaf AC. With > local configuration at the PE-rs as part of the spoke PW provisioning. > And the PE-rs will treat root/leaf spoke PWs exactly as it treat > root/leaf ACs. So when leaf-originated BUM traffic arrives from the > core (over a leaf PW), it will be forwarded over all root spoke PWs > but not on the leaf spoke PWs. > > [JY] So in the reverse direction, you need to transport both root and > leaf traffic from PE-rs over a root PW to PE-r, and transport root > traffic over a leaf PW. It seems against the definition of root PW and > leaf PW in the multi-PW draft. Don't this make the forwarding plane of > PE-rs more complex? > > The forwarding plane is exactly the same as described in the multi-PW > draft, where spoke PWs are treated exactly like ACs. > > Regards, > > Daniel > > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Friday, May 11, 2012 5:03 AM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Daniel and all, > > When you set up two PWs from the PE-rs to a PE-r for each of its AC, > do you mean that one PW is bidirectional root PW and the other is > bidirectional leaf PW? > My concern is: where should the leaf traffic be filtered, on the PE-rs > or on the PE-r? > If filtered on the PE-r, then lots of bandwidth will be wasted (for > example, if the PE-r is attached with 9 leafs, then the BUM traffic > from one of its leafs will be multiplied by 8 times, and be forwarded > by the PE-rs to the same PE-r). > If filtered on the PE-rs, not sure how you will design its forwarding > plane, can you give a hint? > > Thanks, > Yuanlong > > ------------------------------ > Date: Wed, 9 May 2012 09:16:36 +0300 > From: "Daniel Cohn" > To: "Alexander Vainshtein" , "Sa= m > Cao" , > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780CBA6@tlvmail1> > Content-Type: text/plain; charset=3D"ISO-2022-JP" > > Hi Sasha, > > It's actually very simple. A frame that originated in a root AC is > always transmitted only in root PW, no matter what the frame type > (known/unknown unicast or broadcast). This is how the frame source > information is propagated across the VPLS. So in the H-VPLS example, > the PE-r will never forward a frame received over a root PW on any > leaf PW, only on root PWs (toward the core or toward other spokes). > > Hope this clarifies it, regards, > > Daniel > > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Alexander Vainshtein > Sent: Wednesday, May 09, 2012 7:59 AM > To: Sam Cao; l2vpn@ietf.org > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > > Sam, Lizhong and all, > You've written that in the two-PW solution combined with H-VPLS the > PE- r must set up two PWs with each MTU-s. > > If this is the case, what kind of forwarding logic should be used to > prevent sending a BUM frame received from a root-PW to a given MTU-S: > - back to the same MTU-S on the corresponding leaf-PW? > - twice (to both root-PW and Leaf-PW) to another MTU-s? And, BTW, how > is the PW selected in this case? > > I am aware of a technique of multiple split horizon groups in PE-r > which could be possibly used for this purpose. However, since these > groups have to be represented explicitly in the data plane, their > potential number is limited by the forwarding HW. Other methods could > be probably used for the same purpose, but they would probably subject > to similar HW-based limitations. > > I suspect that with the dual-PW approach, the HW would pose an > implicit limit, say, on a number of MTU-s that can be connected to the > same PE-r and that this limit could be quite low in most cases. > > Based on this I suspect that the H-VPLS issue as a critical drawback > of the dual-PW approach to E-Tree. > > My 2c, > Sasha > > > ________________________________________ > From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Sam > Cao [yuqun.cao@gmail.com] > Sent: Wednesday, May 09, 2012 3:40 AM > To: l2vpn@ietf.org > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Lizhong? > > Thank you very much for your comments. I updated the result on this > question. > > [Lizhong] agree with the above analysis. And we did not say it is a > technical problem, but it is an operational problem again. > [Sam] I agree. Dual-VLAN does not make sense. I also discussed this > with Giles and Yuanlong in another mail, and we reached agreement on > this: > MTU should know the access mode, VPWS or VPLS, VPWS mode should > configure VLAN ID on MTU but VPLS mode can not. I thought this is NOT > reasonable :), but we can figure this out in draft. It seems ok. > > [Lizhong] not fully understand. Do you mean, when VPWS accessing for > H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf > PW) for each AC access? > [Sam] Yes. > > Thanks, > > Sam > > > > From muraris@microsoft.com Tue May 15 13:13: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 9762921F885C; Tue, 15 May 2012 13:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.467 X-Spam-Level: X-Spam-Status: No, score=-100.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132, 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 XrVrok99iC2Z; Tue, 15 May 2012 13:13:03 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id 95BF921F881E; Tue, 15 May 2012 13:13:03 -0700 (PDT) Received: from mail141-ch1-R.bigfish.com (10.43.68.240) by CH1EHSOBE011.bigfish.com (10.43.70.61) with Microsoft SMTP Server id 14.1.225.23; Tue, 15 May 2012 20:12:57 +0000 Received: from mail141-ch1 (localhost [127.0.0.1]) by mail141-ch1-R.bigfish.com (Postfix) with ESMTP id 4BF6D3200FE; Tue, 15 May 2012 20:12:57 +0000 (UTC) X-SpamScore: -33 X-BigFish: VS-33(zf7Iz9371I542M1432Nzz1202hzz1033IL8275dhz2fh2a8h683h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail141-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=muraris@microsoft.com; helo=TK5EX14MLTC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail141-ch1 (localhost.localdomain [127.0.0.1]) by mail141-ch1 (MessageSwitch) id 1337112775815246_7542; Tue, 15 May 2012 20:12:55 +0000 (UTC) Received: from CH1EHSMHS012.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.227]) by mail141-ch1.bigfish.com (Postfix) with ESMTP id B6F7F3C014D; Tue, 15 May 2012 20:12:55 +0000 (UTC) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS012.bigfish.com (10.43.70.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 15 May 2012 20:12:55 +0000 Received: from tx2outboundpool.messaging.microsoft.com (157.54.51.81) by mail.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.2.298.5; Tue, 15 May 2012 20:12:41 +0000 Received: from mail177-tx2-R.bigfish.com (10.9.14.241) by TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id 14.1.225.23; Tue, 15 May 2012 20:12:26 +0000 Received: from mail177-tx2 (localhost [127.0.0.1]) by mail177-tx2-R.bigfish.com (Postfix) with ESMTP id 0C2DE42045D; Tue, 15 May 2012 20:12:26 +0000 (UTC) Received: from mail177-tx2 (localhost.localdomain [127.0.0.1]) by mail177-tx2 (MessageSwitch) id 1337112744249331_23986; Tue, 15 May 2012 20:12:24 +0000 (UTC) Received: from TX2EHSMHS005.bigfish.com (unknown [10.9.14.237]) by mail177-tx2.bigfish.com (Postfix) with ESMTP id 072F12A00CF; Tue, 15 May 2012 20:12:23 +0000 (UTC) Received: from CH1PRD0310HT002.namprd03.prod.outlook.com (157.56.244.37) by TX2EHSMHS005.bigfish.com (10.9.99.105) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 15 May 2012 20:12:20 +0000 Received: from CH1PRD0310MB369.namprd03.prod.outlook.com ([169.254.12.67]) by CH1PRD0310HT002.namprd03.prod.outlook.com ([10.255.137.37]) with mapi id 14.16.0152.000; Tue, 15 May 2012 20:12:25 +0000 From: Murari Sridharan To: Linda Dunbar , "robert@raszuk.net" , Keshava A K Subject: RE: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version Notification for draft-xu-mpls-in-udp-00.txt Thread-Topic: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version Notification for draft-xu-mpls-in-udp-00.txt Thread-Index: AQHNMtLmYF1pbLPmtkOp4kNlmD7fQ5bLRmMw Date: Tue, 15 May 2012 20:12:24 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02F20BF9@szxeml525-mbs.china.huawei.com> <005a01cd2d9e$900f0ac0$b02d2040$@com> <4FAA1C30.6090303@raszuk.net> <4A95BA014132FF49AE685FAB4B9F17F633931E2C@dfweml506-mbx> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F633931E2C@dfweml506-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.174.179] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: CH1PRD0310HT002.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%HUAWEI.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%RASZUK.NET$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14MLTC101.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC101.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Cc: "l2vpn@ietf.org" , "nvo3@ietf.org" , "l3vpn@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, 15 May 2012 20:13:04 -0000 Whichever entity assigns IP addresses to the host can assign one or many in= cluding 1:1 for every VM in that host. This isn't specific to IPv6 or IPv4.= =20 On a general note, devices/appliances etc that want to participate in NV03 = will likely want to understand specific tenant information to provide riche= r services. No matter what the encapsulation format is devices/appliances w= ill need to update if they want to do something interesting with the flow. = I have seen several threads where folks seem to have a "let's keep switch-E= CMP" view of the DC which I think is narrow.=20 Thanks Murari=20 -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of L= inda Dunbar Sent: Tuesday, May 15, 2012 12:41 PM To: robert@raszuk.net; Keshava A K Cc: l2vpn@ietf.org; nvo3@ietf.org; l3vpn@ietf.org Subject: RE: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN traffic = over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version Notification= for draft-xu-mpls-in-udp-00.txt Robert,=20 When GRE encapsulation uses different SRC/DST addresses for different flows= , it means that same OverlayBoundaryPoint needs multiple addresses. Does it= also mean an IP prefix can be given to a OverlayBoundaryPoint? I guess for= IPv6, there shouldn't be any issues, should it? (well I am not an IPv6 exp= ert).=20 Linda > -----Original Message----- > From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf=20 > Of Robert Raszuk > Sent: Wednesday, May 09, 2012 2:27 AM > To: Keshava A K > Cc: l2vpn@ietf.org; Xuxiaohu; nvo3@ietf.org; l3vpn@ietf.org > Subject: Re: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN=20 > traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version=20 > Notification for draft-xu-mpls-in-udp-00.txt >=20 >=20 > > If switches were to try to distribute GRE flows between two VTEPs=20 > > that used a GRE encapsulation, all the traffic would be directed to=20 > > use only one link within these Port Channels. >=20 > Not true. GRE encapsulation is not mandated to use the same src/dst=20 > addresses for all flows between given two end points. >=20 > You do not need to parse deep into packet to enable good load=20 > balancing hash across parallel links when you use GRE as an=20 > encapsulation technology. >=20 > And what is nice about IP encapsulation all GRE src/dst addresses can=20 > be naturally aggregated so from IGP point of view they still look like=20 > a single prefix. >=20 > Regards, > R. > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 From lucy.yong@huawei.com Tue May 15 13:16: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 F117121F8836 for ; Tue, 15 May 2012 13:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=-0.213, BAYES_00=-2.599, J_CHICKENPOX_23=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 N21Q5UQNk2wH for ; Tue, 15 May 2012 13:16:30 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id DEE7D21F887A for ; Tue, 15 May 2012 13:16:29 -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 AGF38379; Tue, 15 May 2012 16:16:29 -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, 15 May 2012 13:15:07 -0700 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Tue, 15 May 2012 13:15:02 -0700 From: Lucy yong To: David Allan I , "Balus, Florin Stelian (Florin)" , Sam Cao , Jiangyuanlong , 'Daniel Cohn' , 'Alexander Vainshtein' Subject: RE: Discussion on forwarding performance Thread-Topic: Discussion on forwarding performance Thread-Index: AQHNLxo31u2OjZw96UuBF9QPOwJXg5bHcLkAgAGHLZCAAAmjYIAAHGPggAAUqSCAAOHDIIAAM7tggAAlyMCAADHVIIAAElJAgAAmSSCAAGzc8IAABagAgAAFRDA= Date: Tue, 15 May 2012 20:15:02 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D33108DD9@dfweml506-mbx> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D411694@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF5C@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D4130E1@szxeml546-mbs.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF8F@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413216@szxeml546-mbs.china.huawei.com> <3F1F3739E2B04D399CC7D26CE934F91A@v2comsam> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413694@szxeml546-mbs.china.huawei.com> <7A564821DF1642E592E884D5C623772C@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D41370E@szxeml546-mbs.china.huawei.com> <400D5D93E6AA4075861CE09919D84747@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413741@szxeml546-mbs.china.huawei.com> <7BDA456234D045E1BD42EA059A4E9579@v2comsam> <2073A6C5467C99478898544C6EBA3F4602C1907568@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> <60C093A41B5E45409A19D42CF7786DFD52328D98DF@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD52328D98DF@EUSAACMS0703.eamcs.ericsson.se> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.145.95] 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, 15 May 2012 20:16:32 -0000 +1 We can't just make a conclusion from nowhere. Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= avid Allan I Sent: Tuesday, May 15, 2012 2:55 PM To: Balus, Florin Stelian (Florin); Sam Cao; Jiangyuanlong; 'Daniel Cohn'; = 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance Florin: I agree. The statement, at least to me, is a non-sequitor... Cheers Dave -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of B= alus, Florin Stelian (Florin) Sent: Tuesday, May 15, 2012 12:53 PM To: Sam Cao; 'Jiangyuanlong'; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance Sam, > Obviously the forwarding performance of Dual-VLAN will be much lower than= what of Multi-PW. Sorry I could not keep up with some of the threads on this subject but the = above statement caught my eyes. We have been doing all kind of egress opera= tions on VLANs in the egress PE for the last 8 years and I am not aware of = any "much lower" forwarding performance. As far as I know the chipsets used= in the PEs can do this processing no problem. Do you want to clarify which= kind of hardware may have problems? > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Sam Cao > Sent: Tuesday, May 15, 2012 6:32 AM > To: 'Jiangyuanlong'; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on forwarding performance > > Hi Yuanlong, > > 3rd mapping will make data plane complex, I think. Anyway, we reached > a consensus on Multi-PW implementation. > > If we use 3rd mapping, I agree with your opinion, maybe dual-VLAN > seems simple, but 2 mapping is enough. Then we can focus on data plane > performance. While stripe PW label out on egress PE, data-plane knows > how to forward the frames from PW, to Root AC or Leaf AC or all. But > if we use Dual-VLAN, after strip PW label out, data plane should strip > VLAN-ID out and then does same forwarding work as Multi-PW does. The > most important is, do one more operation while forwarding E-Tree > frames. Obviously the forwarding performance of Dual-VLAN will be much > lower than what of Multi-PW. > > Regards, > > Yuqun (Sam) Cao > E-mail: Yuqun.cao@gmail.com > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 7:03 PM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > See my further comments in line. > > -----Original Message----- > From: Sam Cao [mailto:yuqun.cao@gmail.com] > Sent: Tuesday, May 15, 2012 6:14 PM > To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > Thank you very much for your comments. I draw the topology you gave, > and 7 PWs will be established if we follow 01. > > Root AC ---- PE 1 ----- PW 1 -------- PE 2 ----- Leaf _AC > | \ / || > | \ /=3D=3D=3DPW 6,7=3D=3D=3D || > PW 2 -----PW 5------\ || > | /----Root PW 3 --- \ || > Root _AC ---- PE 3 PE 4 ------ Root AC > | \ / | > | ----Leaf PW 4----- | > Leaf AC Leaf AC > Yes, on PE 3 there are several PWs, but if you want to clarify it, > there are only 3 types, one can carry frames originated from Root and > Leaf AC(one endpoint of this PW should be Root-only, otherwise this is > invalid), one only can carry frames from Root AC, and the last can > carry frames from Leaf ACs. On second thoughts, we still can classify > the PWs into 2 sets, one is Leaf set, and another is Root set, and the > union of the sets Leaf and Root is the PW we called it as compatible > PW (Maybe this is not correct, we can find one good term on this). > > So this optimization still follows the original design of Dual-PW > approach, Leaf PW only carries frames from Leaf AC; Root-PW only > carries frames from Root AC. Is it right? > > I don't know whether chip can support this forwarding behavior for > compatible PW or not, but if we implement it in NP, it is nearly same > as VPLS. The only difference is, setup 2 mappings, one between > Leaf-ACs and Leaf-PWs, one between Root-ACs and Root-PWs. For > traditional VPLS, there is only one mapping. > > [JY] It seems you may need a 3rd mapping: from both root & leaf AC to > a compatible PW. > BTW, for the forwarding and reverse direction, the mapping may be > asymmetric for you compatible PW. > > Based on my understanding, all drafts should have similar mapping. > > [JY] Dual-VLAN seems simpler here. > > Thanks, > > Sam > > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 3:32 PM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Sam, > > Thanks, please see my further comments with [JY]. > > Ok, we go on the case in your mail, where PE1 has one Root-only AC, > AC1, and > PE2 has one Leaf-only AC, AC2. In general we can setup 2 > "unidirectional" > PWs (bidirectional PW, but just carry unidirectional frames), Root-PW > which carries frames originated from AC1 and Leaf-PW which carries > frames originated from AC2. But only one PW also can work, just as > some members commented. Ok, we setup one PW between PE1 and PE2, we > can call this PW as compatible PW or something else. Frames originated > from Root or leaf ACs will be carried via this PW. Its forwarding > behavior is fully same as what traditional VPLS did, MAC learning on > AC or PW in one E-Tree. Or say, if one PE has Root-only ACs, it will > setup one PW with another PE, Root-only, Leaf-only or Root-Leaf-Mixed. > If 2 PEs are root-Leaf-Mixed or other cases, then 2 PWs will be > established. As you know, this can be done on control plane. > > [JY] Assume there are 2 other nodes PE3 & PE4 in this network > scenario, and both PE3 and PE4 have both root and leaf ACs, then there > are compatible PWs from PE3 which may carry both root and leaf traffic > (to PE1), which may carry only root traffic (to PE2); and further > there are root PW and leaf PW to PE4. Thus, the VSI on PE3 has at > least 4 different types of PW transmitting behaviours with regard to > the E-Tree traffic. In the reverse direction, the VSI on PE3 further > has at least > 4 different types of PW receiving behaviours. Not sure how you will > accommodate for these PWs in both the data plane and control plane. > > Regards, > Yuanlong > > Is this clear for you? Is this necessary to optimize PW setup in this > case? > > Maybe we need to add one paragraph on forwarding behavior. > > Again thank you very much for your comments, > > Sam > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 10:27 AM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Please see my comments in line. > > -----Original Message----- > From: Sam Cao [mailto:yuqun.cao@gmail.com] > Sent: Monday, May 14, 2012 8:31 PM > To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > We have discussed this in another thread. In fact, Daniel or I have > given the answers to the questions you raised here for several time :). > If we do in this way, we will reach deadlock and can not move forward > :). I try to explain it again. > > [JY] I will apologize if you had ever provided such answers before, > and you may just refer to the links rather than repeat the explanation. > As you can see, I just try to understand the mechanism of 2PW and its > implications, but the I-D does not include enough information. > > As you know, initial design we will setup 2 PWs all the time (if do in > this way, I think that you have no question), > > [JY] I will be concerned with the operational complexity of this > approach. > > but in most cases 2 PWs are not > necessary. So in 01 version, we optimize it. > > "Root-only VSI <-> any VSI: only root PW required" > "Leaf-only VSI <-> leaf-only VSI: no PWs required" > > In other cases 2 PWs are needed. If so, "Leaf-only -> root-only =3D one > leaf PW" is not correct: On Leaf-only side, yes, one Leaf-only PW is > created between Local Leaf type with remote Root type; on root-only > side, one root-only PW is created. Maybe it is better to call this as > compatible or mixed PW. So the left items you list are not correct for > multi_PW solution. > > [JY] This is something new, right? To be honest, I could not > understand what is your point: doesn't the mixed PW as you called also > consist of one Leaf-only PW in one direction and one root-only PW in > the other direction? > Furthermore, the case you took is also one case in your guideline > "Root-only VSI <-> any VSI: only root PW required", don't you think > that only one root PW is required following this guideline? > Actually, I don't care much about what is the bidirectional PW or > unidirectional PW called, but how can a VSI support such a mixed > scenarios: > traditional VSI assumes only one PW is required for each peer VSI, and > its MAC leaning is based on bidirectional PW. But for 2PW, there are > bidirectional root PW, bidirectional leaf PW, mixed PW, etc..., how to > support these kinds of PWs in the same VSI is my top concern. > > BTW, I guess you also care this case we also have discussed before: > for example, if we configure one Leaf AC on root-only PE (then it will > be root-leaf-mixed PE), we will teardown the compatible PW and > re-setup PWs again with 01. > [JY] This was discussed in the emails indeed. > > Regards, > > Yuqun (Sam) Cao > E-mail: Yuqun.cao@gmail.com > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Monday, May 14, 2012 7:10 PM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Daniel, > > Fine, now it seems more in line with what we had proposed in 2VLAN: a > spoke PW behaves like root/leaf AC for a PE-r. > > But the same problem may also apply to the root/spoke "core PW" for > Multi-PW: > According to Multi-PW, only one PW is required between two PEs except > when both PEs are mixed with root and leaf, so these PWs may be formed > by combinations of the following unidirectional PW cases (extracted > and adapted from Josh's email): > Root-only -> any VSI =3D one root PW > Leaf-only -> root-only =3D one leaf PW > Leaf-only -> mixed =3D one leaf PW > Mixed -> root-only =3D one (root+leaf) PW Mixed -> leaf-only =3D one > (root+leaf) PW > > I have a concern that the forwarding plane of PE to implement this > will be very different from the traditional VPLS. > > Regards, > Yuanlong > > -----Original Message----- > From: Daniel Cohn [mailto:DanielC@orckit.com] > Sent: Monday, May 14, 2012 5:00 PM > To: Jiangyuanlong; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > Like I wrote below, root/leaf spoke PW behave like root/leaf AC, not > like root/spoke "core PW". So no changes to forwarding plane once this > is understood. > > DC > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Monday, May 14, 2012 11:36 AM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Daniel, please see my comments in line. > > -----Original Message----- > From: Daniel Cohn [mailto:DanielC@orckit.com] > Sent: Monday, May 14, 2012 3:37 PM > To: Jiangyuanlong; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > As I see it, for the PE-r spoke (figure 4 in RFC 4762) we establish a > single PW per AC - root PW for root AC and leaf PW for leaf AC. With > local configuration at the PE-rs as part of the spoke PW provisioning. > And the PE-rs will treat root/leaf spoke PWs exactly as it treat > root/leaf ACs. So when leaf-originated BUM traffic arrives from the > core (over a leaf PW), it will be forwarded over all root spoke PWs > but not on the leaf spoke PWs. > > [JY] So in the reverse direction, you need to transport both root and > leaf traffic from PE-rs over a root PW to PE-r, and transport root > traffic over a leaf PW. It seems against the definition of root PW and > leaf PW in the multi-PW draft. Don't this make the forwarding plane of > PE-rs more complex? > > The forwarding plane is exactly the same as described in the multi-PW > draft, where spoke PWs are treated exactly like ACs. > > Regards, > > Daniel > > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Friday, May 11, 2012 5:03 AM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Daniel and all, > > When you set up two PWs from the PE-rs to a PE-r for each of its AC, > do you mean that one PW is bidirectional root PW and the other is > bidirectional leaf PW? > My concern is: where should the leaf traffic be filtered, on the PE-rs > or on the PE-r? > If filtered on the PE-r, then lots of bandwidth will be wasted (for > example, if the PE-r is attached with 9 leafs, then the BUM traffic > from one of its leafs will be multiplied by 8 times, and be forwarded > by the PE-rs to the same PE-r). > If filtered on the PE-rs, not sure how you will design its forwarding > plane, can you give a hint? > > Thanks, > Yuanlong > > ------------------------------ > Date: Wed, 9 May 2012 09:16:36 +0300 > From: "Daniel Cohn" > To: "Alexander Vainshtein" , "Sa= m > Cao" , > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780CBA6@tlvmail1> > Content-Type: text/plain; charset=3D"ISO-2022-JP" > > Hi Sasha, > > It's actually very simple. A frame that originated in a root AC is > always transmitted only in root PW, no matter what the frame type > (known/unknown unicast or broadcast). This is how the frame source > information is propagated across the VPLS. So in the H-VPLS example, > the PE-r will never forward a frame received over a root PW on any > leaf PW, only on root PWs (toward the core or toward other spokes). > > Hope this clarifies it, regards, > > Daniel > > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Alexander Vainshtein > Sent: Wednesday, May 09, 2012 7:59 AM > To: Sam Cao; l2vpn@ietf.org > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > > Sam, Lizhong and all, > You've written that in the two-PW solution combined with H-VPLS the > PE- r must set up two PWs with each MTU-s. > > If this is the case, what kind of forwarding logic should be used to > prevent sending a BUM frame received from a root-PW to a given MTU-S: > - back to the same MTU-S on the corresponding leaf-PW? > - twice (to both root-PW and Leaf-PW) to another MTU-s? And, BTW, how > is the PW selected in this case? > > I am aware of a technique of multiple split horizon groups in PE-r > which could be possibly used for this purpose. However, since these > groups have to be represented explicitly in the data plane, their > potential number is limited by the forwarding HW. Other methods could > be probably used for the same purpose, but they would probably subject > to similar HW-based limitations. > > I suspect that with the dual-PW approach, the HW would pose an > implicit limit, say, on a number of MTU-s that can be connected to the > same PE-r and that this limit could be quite low in most cases. > > Based on this I suspect that the H-VPLS issue as a critical drawback > of the dual-PW approach to E-Tree. > > My 2c, > Sasha > > > ________________________________________ > From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Sam > Cao [yuqun.cao@gmail.com] > Sent: Wednesday, May 09, 2012 3:40 AM > To: l2vpn@ietf.org > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Lizhong? > > Thank you very much for your comments. I updated the result on this > question. > > [Lizhong] agree with the above analysis. And we did not say it is a > technical problem, but it is an operational problem again. > [Sam] I agree. Dual-VLAN does not make sense. I also discussed this > with Giles and Yuanlong in another mail, and we reached agreement on > this: > MTU should know the access mode, VPWS or VPLS, VPWS mode should > configure VLAN ID on MTU but VPLS mode can not. I thought this is NOT > reasonable :), but we can figure this out in draft. It seems ok. > > [Lizhong] not fully understand. Do you mean, when VPWS accessing for > H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf > PW) for each AC access? > [Sam] Yes. > > Thanks, > > Sam > > > > From muraris@microsoft.com Tue May 15 13:29: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 BF97321F88CB; Tue, 15 May 2012 13:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.467 X-Spam-Level: X-Spam-Status: No, score=-100.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132, 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 NWFzYSeY6SMB; Tue, 15 May 2012 13:29:38 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe006.messaging.microsoft.com [213.199.154.144]) by ietfa.amsl.com (Postfix) with ESMTP id B9AAE21F8881; Tue, 15 May 2012 13:29:37 -0700 (PDT) Received: from mail10-db3-R.bigfish.com (10.3.81.246) by DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id 14.1.225.23; Tue, 15 May 2012 20:29:31 +0000 Received: from mail10-db3 (localhost [127.0.0.1]) by mail10-db3-R.bigfish.com (Postfix) with ESMTP id 125031E069B; Tue, 15 May 2012 20:29:31 +0000 (UTC) X-SpamScore: -33 X-BigFish: VS-33(zf7Iz9371I542M1432Nzz1202hzz1033IL8275dhz2fh2a8h683h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail10-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=muraris@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail10-db3 (localhost.localdomain [127.0.0.1]) by mail10-db3 (MessageSwitch) id 1337113769862311_10849; Tue, 15 May 2012 20:29:29 +0000 (UTC) Received: from DB3EHSMHS010.bigfish.com (unknown [10.3.81.226]) by mail10-db3.bigfish.com (Postfix) with ESMTP id C424910009C; Tue, 15 May 2012 20:29:29 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS010.bigfish.com (10.3.87.110) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 15 May 2012 20:29:28 +0000 Received: from CH1EHSOBE007.bigfish.com (157.54.51.113) by mail.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.2.298.5; Tue, 15 May 2012 20:29:32 +0000 Received: from mail170-ch1-R.bigfish.com (10.43.68.229) by CH1EHSOBE007.bigfish.com (10.43.70.57) with Microsoft SMTP Server id 14.1.225.23; Tue, 15 May 2012 20:28:50 +0000 Received: from mail170-ch1 (localhost [127.0.0.1]) by mail170-ch1-R.bigfish.com (Postfix) with ESMTP id B9207460558; Tue, 15 May 2012 20:28:50 +0000 (UTC) Received: from mail170-ch1 (localhost.localdomain [127.0.0.1]) by mail170-ch1 (MessageSwitch) id 1337113728168910_21582; Tue, 15 May 2012 20:28:48 +0000 (UTC) Received: from CH1EHSMHS018.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.238]) by mail170-ch1.bigfish.com (Postfix) with ESMTP id 1A5631A007B; Tue, 15 May 2012 20:28:48 +0000 (UTC) Received: from CH1PRD0310HT001.namprd03.prod.outlook.com (157.56.244.37) by CH1EHSMHS018.bigfish.com (10.43.70.18) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 15 May 2012 20:28:45 +0000 Received: from CH1PRD0310MB369.namprd03.prod.outlook.com ([169.254.12.67]) by CH1PRD0310HT001.namprd03.prod.outlook.com ([10.255.137.36]) with mapi id 14.16.0152.000; Tue, 15 May 2012 20:28:41 +0000 From: Murari Sridharan To: Murari Sridharan , Linda Dunbar , "robert@raszuk.net" , Keshava A K Subject: RE: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version Notification for draft-xu-mpls-in-udp-00.txt Thread-Topic: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version Notification for draft-xu-mpls-in-udp-00.txt Thread-Index: AQHNMtdCPLEBmOsYn0i+Uw4Kb2QV0JbLTJ2g Date: Tue, 15 May 2012 20:28:40 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02F20BF9@szxeml525-mbs.china.huawei.com> <005a01cd2d9e$900f0ac0$b02d2040$@com> <4FAA1C30.6090303@raszuk.net> <4A95BA014132FF49AE685FAB4B9F17F633931E2C@dfweml506-mbx> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.174.179] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: CH1PRD0310HT001.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%HUAWEI.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%RASZUK.NET$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC101.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC101.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Cc: "l2vpn@ietf.org" , "nvo3@ietf.org" , "l3vpn@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, 15 May 2012 20:29:38 -0000 Linda, to clarify the address "assignment" could be setup as a SLAAC and ho= sts can generate address from a given prefix etc.=20 -----Original Message----- From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf Of Mur= ari Sridharan Sent: Tuesday, May 15, 2012 1:12 PM To: Linda Dunbar; robert@raszuk.net; Keshava A K Cc: l2vpn@ietf.org; nvo3@ietf.org; l3vpn@ietf.org Subject: Re: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN traffic = over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version Notification= for draft-xu-mpls-in-udp-00.txt Whichever entity assigns IP addresses to the host can assign one or many in= cluding 1:1 for every VM in that host. This isn't specific to IPv6 or IPv4.= =20 On a general note, devices/appliances etc that want to participate in NV03 = will likely want to understand specific tenant information to provide riche= r services. No matter what the encapsulation format is devices/appliances w= ill need to update if they want to do something interesting with the flow. = I have seen several threads where folks seem to have a "let's keep switch-E= CMP" view of the DC which I think is narrow.=20 Thanks Murari=20 -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of L= inda Dunbar Sent: Tuesday, May 15, 2012 12:41 PM To: robert@raszuk.net; Keshava A K Cc: l2vpn@ietf.org; nvo3@ietf.org; l3vpn@ietf.org Subject: RE: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN traffic = over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version Notification= for draft-xu-mpls-in-udp-00.txt Robert,=20 When GRE encapsulation uses different SRC/DST addresses for different flows= , it means that same OverlayBoundaryPoint needs multiple addresses. Does it= also mean an IP prefix can be given to a OverlayBoundaryPoint? I guess for= IPv6, there shouldn't be any issues, should it? (well I am not an IPv6 exp= ert).=20 Linda > -----Original Message----- > From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf=20 > Of Robert Raszuk > Sent: Wednesday, May 09, 2012 2:27 AM > To: Keshava A K > Cc: l2vpn@ietf.org; Xuxiaohu; nvo3@ietf.org; l3vpn@ietf.org > Subject: Re: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN=20 > traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version=20 > Notification for draft-xu-mpls-in-udp-00.txt >=20 >=20 > > If switches were to try to distribute GRE flows between two VTEPs=20 > > that used a GRE encapsulation, all the traffic would be directed to=20 > > use only one link within these Port Channels. >=20 > Not true. GRE encapsulation is not mandated to use the same src/dst=20 > addresses for all flows between given two end points. >=20 > You do not need to parse deep into packet to enable good load=20 > balancing hash across parallel links when you use GRE as an=20 > encapsulation technology. >=20 > And what is nice about IP encapsulation all GRE src/dst addresses can=20 > be naturally aggregated so from IGP point of view they still look like=20 > a single prefix. >=20 > Regards, > R. > _______________________________________________ > 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 Peter.AshwoodSmith@huawei.com Tue May 15 14:01: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 7161821F86DE; Tue, 15 May 2012 14:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.318 X-Spam-Level: X-Spam-Status: No, score=-2.318 tagged_above=-999 required=5 tests=[AWL=0.281, 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 IL7T-lLpx7rX; Tue, 15 May 2012 14:01:37 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6759A21F86D4; Tue, 15 May 2012 14:01:37 -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 AFY42614; Tue, 15 May 2012 17:01:37 -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, 15 May 2012 13:59:51 -0700 Received: from dfweml513-mbx.china.huawei.com ([169.254.3.80]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.003; Tue, 15 May 2012 13:59:48 -0700 From: AshwoodsmithPeter To: Murari Sridharan , Linda Dunbar , "robert@raszuk.net" , Keshava A K Subject: RE: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version Notification for draft-xu-mpls-in-udp-00.txt Thread-Topic: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version Notification for draft-xu-mpls-in-udp-00.txt Thread-Index: AQHNMtl/jjbYa2SmTkuxmfT+oj8NTJbLTe7Q Date: Tue, 15 May 2012 20:59:48 +0000 Message-ID: <7AE6A4247B044C4ABE0A5B6BF427F8E2012DE3C3@dfweml513-mbx.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.60.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l2vpn@ietf.org" , "nvo3@ietf.org" , "l3vpn@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, 15 May 2012 21:01:38 -0000 Linda, just to clarify, its not the ultimate host addresses (VM) that need = to be multiple, it's the Hyperisor/Vswitch that needs multiple IP addresses= . The hash is on this *outer* IP address and is of course limited because t= here are insufficient outer addresses for good entropy. You'd use a single IP address for the VM/host but then when encapsulating y= ou'd pick one of say 32 or more Vswitch addresses for your SA based on your= VM IPs and the UDP/TCP ports. Everywhere there was a dependency on /32 wou= ld have to be made flexible. Not sure if that's an issue but its possibly h= ard coded in some places. Routers ARP table for example?=20 The number of outer addresses you use dictates how much entropy you get whe= n you traverse a LAG which can have quite a few members, but 16 or 32 is li= kely not unreasonable. Also if you go through several hops, the number of b= its of entropy puts a strict upper bound on the total number of different p= aths you can exercise. So if you have 4 bits you can only exercise 16 uniqu= e paths *end to end*. Since the number of paths grows exponentially in the = path length a small number of bits does limit spead exponentially quickly. This 'trick' is only needed of course if the LAG or ECMP hardware does not = know to look at an NVGRE header or is not capable of generic hash extension= s which some ASICs now can do... (even if they don't support NVGRE terminat= ion/encapsulation) so its likely more a concern between DC's than inside th= e DC. Peter -----Original Message----- From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf Of Mur= ari Sridharan Sent: Tuesday, May 15, 2012 4:29 PM To: Murari Sridharan; Linda Dunbar; robert@raszuk.net; Keshava A K Cc: l2vpn@ietf.org; nvo3@ietf.org; l3vpn@ietf.org Subject: Re: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN traffic = over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version Notification= for draft-xu-mpls-in-udp-00.txt Linda, to clarify the address "assignment" could be setup as a SLAAC and ho= sts can generate address from a given prefix etc.=20 -----Original Message----- From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf Of Mur= ari Sridharan Sent: Tuesday, May 15, 2012 1:12 PM To: Linda Dunbar; robert@raszuk.net; Keshava A K Cc: l2vpn@ietf.org; nvo3@ietf.org; l3vpn@ietf.org Subject: Re: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN traffic = over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version Notification= for draft-xu-mpls-in-udp-00.txt Whichever entity assigns IP addresses to the host can assign one or many in= cluding 1:1 for every VM in that host. This isn't specific to IPv6 or IPv4.= =20 On a general note, devices/appliances etc that want to participate in NV03 = will likely want to understand specific tenant information to provide riche= r services. No matter what the encapsulation format is devices/appliances w= ill need to update if they want to do something interesting with the flow. = I have seen several threads where folks seem to have a "let's keep switch-E= CMP" view of the DC which I think is narrow.=20 Thanks Murari=20 -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of L= inda Dunbar Sent: Tuesday, May 15, 2012 12:41 PM To: robert@raszuk.net; Keshava A K Cc: l2vpn@ietf.org; nvo3@ietf.org; l3vpn@ietf.org Subject: RE: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN traffic = over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version Notification= for draft-xu-mpls-in-udp-00.txt Robert,=20 When GRE encapsulation uses different SRC/DST addresses for different flows= , it means that same OverlayBoundaryPoint needs multiple addresses. Does it= also mean an IP prefix can be given to a OverlayBoundaryPoint? I guess for= IPv6, there shouldn't be any issues, should it? (well I am not an IPv6 exp= ert).=20 Linda > -----Original Message----- > From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf=20 > Of Robert Raszuk > Sent: Wednesday, May 09, 2012 2:27 AM > To: Keshava A K > Cc: l2vpn@ietf.org; Xuxiaohu; nvo3@ietf.org; l3vpn@ietf.org > Subject: Re: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN=20 > traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version=20 > Notification for draft-xu-mpls-in-udp-00.txt >=20 >=20 > > If switches were to try to distribute GRE flows between two VTEPs=20 > > that used a GRE encapsulation, all the traffic would be directed to=20 > > use only one link within these Port Channels. >=20 > Not true. GRE encapsulation is not mandated to use the same src/dst=20 > addresses for all flows between given two end points. >=20 > You do not need to parse deep into packet to enable good load=20 > balancing hash across parallel links when you use GRE as an=20 > encapsulation technology. >=20 > And what is nice about IP encapsulation all GRE src/dst addresses can=20 > be naturally aggregated so from IGP point of view they still look like=20 > a single prefix. >=20 > Regards, > R. > _______________________________________________ > 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 yuqun.cao@gmail.com Tue May 15 19: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 4B13511E80AF for ; Tue, 15 May 2012 19:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.832 X-Spam-Level: X-Spam-Status: No, score=-2.832 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, J_CHICKENPOX_23=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 fm0I2KMPIoAc for ; Tue, 15 May 2012 19:09: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 9EC6111E8095 for ; Tue, 15 May 2012 19:09:17 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so414715pbc.31 for ; Tue, 15 May 2012 19:09:17 -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=Gi9kwfuo3fMRH7UYDIB2HWhiYiXJIPwUnaoAENVeli0=; b=bAZoqFTmqBPJdTHOUjQsrx2F2khEUBIDoYZWbz/ntZ+1/6p5voUdxdGqbKewrMv2y3 BUpeTfWCNldTF8qvTnSnhOhRYdA6sj3WHUGi94KMa52CevQueG6hVef+VZ9ykHPdoCN4 0Q2p2u842dHSM3CbwvTM3PHOvDDWK9O3k3WgGnDfOIocv+zkhC3DdoePOOPg7+E9sLFy QFMUWrkReP6MlwOJAYI5ZLdUzhtE4BhMPdzRNlu8l1/6wnm3b4g45oZSkmMFQMhOanac UHDPogK3W6vKY26giLvgy5w5zYFM8xWwTUHMwv1poD+YLVaq2wqGuRWOwPqeydAvoAvk joPQ== Received: by 10.68.239.231 with SMTP id vv7mr11308734pbc.104.1337134157310; Tue, 15 May 2012 19:09:17 -0700 (PDT) Received: from R01842 ([110.90.119.113]) by mx.google.com with ESMTPS id pj5sm3703019pbb.51.2012.05.15.19.09.06 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 May 2012 19:09:13 -0700 (PDT) From: "Sam Cao" To: "'Lucy yong'" , "'David Allan I'" , "'Balus, Florin Stelian \(Florin\)'" , "'Jiangyuanlong'" , "'Daniel Cohn'" , "'Alexander Vainshtein'" References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D411694@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF5C@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D4130E1@szxeml546-mbs.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF8F@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413216@szxeml546-mbs.china.huawei.com> <3F1F3739E2B04D399CC7D26CE934F91A@v2comsam> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413694@szxeml546-mbs.china.huawei.com> <7A564821DF1642E592E884D5C623772C@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D41370E@szxeml546-mbs.china.huawei.com> <400D5D93E6AA4075861CE09919D84747@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413741@szxeml546-mbs.china.huawei.com> <7BDA456234D045E1BD42EA059A4E9579@v2comsam> <2073A6C5467C99478898544C6EBA3F4602C1907568@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> <60C093A41B5E45409A19D42CF7786DFD52328D98DF@EUSAACMS0703.eamcs.ericsson.se> <2691CE0099834E4A9C5044EEC662BB9D33108DD9@dfweml506-m bx> Subject: RE: Discussion on forwarding performance Date: Wed, 16 May 2012 10:09:08 +0800 Message-ID: <1A7E043E03FF48A2B3E5ECCD4F124B4C@R01842> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <2691CE0099834E4A9C5044EEC662BB9D33108DD9@dfweml506-mbx> Thread-index: AQHNLxo31u2OjZw96UuBF9QPOwJXg5bHcLkAgAGHLZCAAAmjYIAAHGPggAAUqSCAAOHDIIAAM7tggAAlyMCAADHVIIAAElJAgAAmSSCAAGzc8IAABagAgAAFRDCAAFXG8A== 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: Wed, 16 May 2012 02:09:27 -0000 Lucy/David/Florin, Thank you very much for your comments. I can not give the accurate data to support my conclusion, and just conclude that if we implement it in NP module. Except for common operations of 2 approaches, Tunnel Label push/pop-out, MAC-based forwarding, and etc., Dual-VLAN needs one more VLAN push/pop-out operation while forwarding every frame. So compared with Multi-PW, it needs more resource and time for NP module if there are VSIs or PWs up limit to the capacity on one PE, and standing on software architect's side, the performance will be decreased by at least 20%, I guess. I implemented one prototype which has similar solution as current Multi-PW, and the performance will be decreased by 5%, compared with traditional VPLS. Daniel has experience on 2-PW deployment, maybe he can give accurate data on Multi-PW. Florin, do you mean that you have implemented E-Tree in MPLS network? If chipset can support this and we don't care NP or other solutions, yes, we can ignore any side effect on forwarding performance. Yes, it can support E-tree in IP (Ethernet) network, but I read some CHIP datasheets, after strip PW label out, chip can not handle 2 VLAN IDs at same time. Could you please give me some hints, say, which chip you used? Maybe if we raised only one issue in one mail, we can get more and insight comments :). I will raise another after we agree with this in the main :). Thanks, Sam -----Original Message----- From: Lucy yong [mailto:lucy.yong@huawei.com] Sent: Wednesday, May 16, 2012 4:15 AM To: David Allan I; Balus, Florin Stelian (Florin); Sam Cao; Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance +1 We can't just make a conclusion from nowhere. Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of David Allan I Sent: Tuesday, May 15, 2012 2:55 PM To: Balus, Florin Stelian (Florin); Sam Cao; Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance Florin: I agree. The statement, at least to me, is a non-sequitor... Cheers Dave -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Balus, Florin Stelian (Florin) Sent: Tuesday, May 15, 2012 12:53 PM To: Sam Cao; 'Jiangyuanlong'; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance Sam, > Obviously the forwarding performance of Dual-VLAN will be much lower than what of Multi-PW. Sorry I could not keep up with some of the threads on this subject but the above statement caught my eyes. We have been doing all kind of egress operations on VLANs in the egress PE for the last 8 years and I am not aware of any "much lower" forwarding performance. As far as I know the chipsets used in the PEs can do this processing no problem. Do you want to clarify which kind of hardware may have problems? > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Sam Cao > Sent: Tuesday, May 15, 2012 6:32 AM > To: 'Jiangyuanlong'; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on forwarding performance > > Hi Yuanlong, > > 3rd mapping will make data plane complex, I think. Anyway, we reached > a consensus on Multi-PW implementation. > > If we use 3rd mapping, I agree with your opinion, maybe dual-VLAN > seems simple, but 2 mapping is enough. Then we can focus on data plane > performance. While stripe PW label out on egress PE, data-plane knows > how to forward the frames from PW, to Root AC or Leaf AC or all. But > if we use Dual-VLAN, after strip PW label out, data plane should strip > VLAN-ID out and then does same forwarding work as Multi-PW does. The > most important is, do one more operation while forwarding E-Tree > frames. Obviously the forwarding performance of Dual-VLAN will be much > lower than what of Multi-PW. > > Regards, > > Yuqun (Sam) Cao > E-mail: Yuqun.cao@gmail.com > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 7:03 PM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > See my further comments in line. > > -----Original Message----- > From: Sam Cao [mailto:yuqun.cao@gmail.com] > Sent: Tuesday, May 15, 2012 6:14 PM > To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > Thank you very much for your comments. I draw the topology you gave, > and 7 PWs will be established if we follow 01. > > Root AC ---- PE 1 ----- PW 1 -------- PE 2 ----- Leaf _AC > | \ / || > | \ /===PW 6,7=== || > PW 2 -----PW 5------\ || > | /----Root PW 3 --- \ || > Root _AC ---- PE 3 PE 4 ------ Root AC > | \ / | > | ----Leaf PW 4----- | > Leaf AC Leaf AC > Yes, on PE 3 there are several PWs, but if you want to clarify it, > there are only 3 types, one can carry frames originated from Root and > Leaf AC(one endpoint of this PW should be Root-only, otherwise this is > invalid), one only can carry frames from Root AC, and the last can > carry frames from Leaf ACs. On second thoughts, we still can classify > the PWs into 2 sets, one is Leaf set, and another is Root set, and the > union of the sets Leaf and Root is the PW we called it as compatible > PW (Maybe this is not correct, we can find one good term on this). > > So this optimization still follows the original design of Dual-PW > approach, Leaf PW only carries frames from Leaf AC; Root-PW only > carries frames from Root AC. Is it right? > > I don't know whether chip can support this forwarding behavior for > compatible PW or not, but if we implement it in NP, it is nearly same > as VPLS. The only difference is, setup 2 mappings, one between > Leaf-ACs and Leaf-PWs, one between Root-ACs and Root-PWs. For > traditional VPLS, there is only one mapping. > > [JY] It seems you may need a 3rd mapping: from both root & leaf AC to > a compatible PW. > BTW, for the forwarding and reverse direction, the mapping may be > asymmetric for you compatible PW. > > Based on my understanding, all drafts should have similar mapping. > > [JY] Dual-VLAN seems simpler here. > > Thanks, > > Sam > > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 3:32 PM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Sam, > > Thanks, please see my further comments with [JY]. > > Ok, we go on the case in your mail, where PE1 has one Root-only AC, > AC1, and > PE2 has one Leaf-only AC, AC2. In general we can setup 2 > "unidirectional" > PWs (bidirectional PW, but just carry unidirectional frames), Root-PW > which carries frames originated from AC1 and Leaf-PW which carries > frames originated from AC2. But only one PW also can work, just as > some members commented. Ok, we setup one PW between PE1 and PE2, we > can call this PW as compatible PW or something else. Frames originated > from Root or leaf ACs will be carried via this PW. Its forwarding > behavior is fully same as what traditional VPLS did, MAC learning on > AC or PW in one E-Tree. Or say, if one PE has Root-only ACs, it will > setup one PW with another PE, Root-only, Leaf-only or Root-Leaf-Mixed. > If 2 PEs are root-Leaf-Mixed or other cases, then 2 PWs will be > established. As you know, this can be done on control plane. > > [JY] Assume there are 2 other nodes PE3 & PE4 in this network > scenario, and both PE3 and PE4 have both root and leaf ACs, then there > are compatible PWs from PE3 which may carry both root and leaf traffic > (to PE1), which may carry only root traffic (to PE2); and further > there are root PW and leaf PW to PE4. Thus, the VSI on PE3 has at > least 4 different types of PW transmitting behaviours with regard to > the E-Tree traffic. In the reverse direction, the VSI on PE3 further > has at least > 4 different types of PW receiving behaviours. Not sure how you will > accommodate for these PWs in both the data plane and control plane. > > Regards, > Yuanlong > > Is this clear for you? Is this necessary to optimize PW setup in this > case? > > Maybe we need to add one paragraph on forwarding behavior. > > Again thank you very much for your comments, > > Sam > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 10:27 AM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Please see my comments in line. > > -----Original Message----- > From: Sam Cao [mailto:yuqun.cao@gmail.com] > Sent: Monday, May 14, 2012 8:31 PM > To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > We have discussed this in another thread. In fact, Daniel or I have > given the answers to the questions you raised here for several time :). > If we do in this way, we will reach deadlock and can not move forward > :). I try to explain it again. > > [JY] I will apologize if you had ever provided such answers before, > and you may just refer to the links rather than repeat the explanation. > As you can see, I just try to understand the mechanism of 2PW and its > implications, but the I-D does not include enough information. > > As you know, initial design we will setup 2 PWs all the time (if do in > this way, I think that you have no question), > > [JY] I will be concerned with the operational complexity of this > approach. > > but in most cases 2 PWs are not > necessary. So in 01 version, we optimize it. > > "Root-only VSI <-> any VSI: only root PW required" > "Leaf-only VSI <-> leaf-only VSI: no PWs required" > > In other cases 2 PWs are needed. If so, "Leaf-only -> root-only = one > leaf PW" is not correct: On Leaf-only side, yes, one Leaf-only PW is > created between Local Leaf type with remote Root type; on root-only > side, one root-only PW is created. Maybe it is better to call this as > compatible or mixed PW. So the left items you list are not correct for > multi_PW solution. > > [JY] This is something new, right? To be honest, I could not > understand what is your point: doesn't the mixed PW as you called also > consist of one Leaf-only PW in one direction and one root-only PW in > the other direction? > Furthermore, the case you took is also one case in your guideline > "Root-only VSI <-> any VSI: only root PW required", don't you think > that only one root PW is required following this guideline? > Actually, I don't care much about what is the bidirectional PW or > unidirectional PW called, but how can a VSI support such a mixed > scenarios: > traditional VSI assumes only one PW is required for each peer VSI, and > its MAC leaning is based on bidirectional PW. But for 2PW, there are > bidirectional root PW, bidirectional leaf PW, mixed PW, etc..., how to > support these kinds of PWs in the same VSI is my top concern. > > BTW, I guess you also care this case we also have discussed before: > for example, if we configure one Leaf AC on root-only PE (then it will > be root-leaf-mixed PE), we will teardown the compatible PW and > re-setup PWs again with 01. > [JY] This was discussed in the emails indeed. > > Regards, > > Yuqun (Sam) Cao > E-mail: Yuqun.cao@gmail.com > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Monday, May 14, 2012 7:10 PM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Daniel, > > Fine, now it seems more in line with what we had proposed in 2VLAN: a > spoke PW behaves like root/leaf AC for a PE-r. > > But the same problem may also apply to the root/spoke "core PW" for > Multi-PW: > According to Multi-PW, only one PW is required between two PEs except > when both PEs are mixed with root and leaf, so these PWs may be formed > by combinations of the following unidirectional PW cases (extracted > and adapted from Josh's email): > Root-only -> any VSI = one root PW > Leaf-only -> root-only = one leaf PW > Leaf-only -> mixed = one leaf PW > Mixed -> root-only = one (root+leaf) PW Mixed -> leaf-only = one > (root+leaf) PW > > I have a concern that the forwarding plane of PE to implement this > will be very different from the traditional VPLS. > > Regards, > Yuanlong > > -----Original Message----- > From: Daniel Cohn [mailto:DanielC@orckit.com] > Sent: Monday, May 14, 2012 5:00 PM > To: Jiangyuanlong; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > Like I wrote below, root/leaf spoke PW behave like root/leaf AC, not > like root/spoke "core PW". So no changes to forwarding plane once this > is understood. > > DC > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Monday, May 14, 2012 11:36 AM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Daniel, please see my comments in line. > > -----Original Message----- > From: Daniel Cohn [mailto:DanielC@orckit.com] > Sent: Monday, May 14, 2012 3:37 PM > To: Jiangyuanlong; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > As I see it, for the PE-r spoke (figure 4 in RFC 4762) we establish a > single PW per AC - root PW for root AC and leaf PW for leaf AC. With > local configuration at the PE-rs as part of the spoke PW provisioning. > And the PE-rs will treat root/leaf spoke PWs exactly as it treat > root/leaf ACs. So when leaf-originated BUM traffic arrives from the > core (over a leaf PW), it will be forwarded over all root spoke PWs > but not on the leaf spoke PWs. > > [JY] So in the reverse direction, you need to transport both root and > leaf traffic from PE-rs over a root PW to PE-r, and transport root > traffic over a leaf PW. It seems against the definition of root PW and > leaf PW in the multi-PW draft. Don't this make the forwarding plane of > PE-rs more complex? > > The forwarding plane is exactly the same as described in the multi-PW > draft, where spoke PWs are treated exactly like ACs. > > Regards, > > Daniel > > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Friday, May 11, 2012 5:03 AM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Daniel and all, > > When you set up two PWs from the PE-rs to a PE-r for each of its AC, > do you mean that one PW is bidirectional root PW and the other is > bidirectional leaf PW? > My concern is: where should the leaf traffic be filtered, on the PE-rs > or on the PE-r? > If filtered on the PE-r, then lots of bandwidth will be wasted (for > example, if the PE-r is attached with 9 leafs, then the BUM traffic > from one of its leafs will be multiplied by 8 times, and be forwarded > by the PE-rs to the same PE-r). > If filtered on the PE-rs, not sure how you will design its forwarding > plane, can you give a hint? > > Thanks, > Yuanlong > > ------------------------------ > Date: Wed, 9 May 2012 09:16:36 +0300 > From: "Daniel Cohn" > To: "Alexander Vainshtein" , "Sam > Cao" , > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780CBA6@tlvmail1> > Content-Type: text/plain; charset="ISO-2022-JP" > > Hi Sasha, > > It's actually very simple. A frame that originated in a root AC is > always transmitted only in root PW, no matter what the frame type > (known/unknown unicast or broadcast). This is how the frame source > information is propagated across the VPLS. So in the H-VPLS example, > the PE-r will never forward a frame received over a root PW on any > leaf PW, only on root PWs (toward the core or toward other spokes). > > Hope this clarifies it, regards, > > Daniel > > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Alexander Vainshtein > Sent: Wednesday, May 09, 2012 7:59 AM > To: Sam Cao; l2vpn@ietf.org > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > > Sam, Lizhong and all, > You've written that in the two-PW solution combined with H-VPLS the > PE- r must set up two PWs with each MTU-s. > > If this is the case, what kind of forwarding logic should be used to > prevent sending a BUM frame received from a root-PW to a given MTU-S: > - back to the same MTU-S on the corresponding leaf-PW? > - twice (to both root-PW and Leaf-PW) to another MTU-s? And, BTW, how > is the PW selected in this case? > > I am aware of a technique of multiple split horizon groups in PE-r > which could be possibly used for this purpose. However, since these > groups have to be represented explicitly in the data plane, their > potential number is limited by the forwarding HW. Other methods could > be probably used for the same purpose, but they would probably subject > to similar HW-based limitations. > > I suspect that with the dual-PW approach, the HW would pose an > implicit limit, say, on a number of MTU-s that can be connected to the > same PE-r and that this limit could be quite low in most cases. > > Based on this I suspect that the H-VPLS issue as a critical drawback > of the dual-PW approach to E-Tree. > > My 2c, > Sasha > > > ________________________________________ > From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Sam > Cao [yuqun.cao@gmail.com] > Sent: Wednesday, May 09, 2012 3:40 AM > To: l2vpn@ietf.org > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Lizhong? > > Thank you very much for your comments. I updated the result on this > question. > > [Lizhong] agree with the above analysis. And we did not say it is a > technical problem, but it is an operational problem again. > [Sam] I agree. Dual-VLAN does not make sense. I also discussed this > with Giles and Yuanlong in another mail, and we reached agreement on > this: > MTU should know the access mode, VPWS or VPLS, VPWS mode should > configure VLAN ID on MTU but VPLS mode can not. I thought this is NOT > reasonable :), but we can figure this out in draft. It seems ok. > > [Lizhong] not fully understand. Do you mean, when VPWS accessing for > H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf > PW) for each AC access? > [Sam] Yes. > > Thanks, > > Sam > > > > From jiangyuanlong@huawei.com Tue May 15 19:18: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 9CD6521F8753 for ; Tue, 15 May 2012 19:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.065 X-Spam-Level: X-Spam-Status: No, score=-4.065 tagged_above=-999 required=5 tests=[AWL=1.934, BAYES_00=-2.599, J_CHICKENPOX_23=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 PSVBtJyJmuvb for ; Tue, 15 May 2012 19:18:58 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 18E1821F8749 for ; Tue, 15 May 2012 19:18:58 -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 AGF57654; Tue, 15 May 2012 22:18:57 -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; Tue, 15 May 2012 19:17:06 -0700 Received: from SZXEML431-HUB.china.huawei.com (10.72.61.39) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 15 May 2012 19:17:09 -0700 Received: from SZXEML546-MBS.china.huawei.com ([169.254.4.75]) by szxeml431-hub.china.huawei.com ([10.72.61.39]) with mapi id 14.01.0323.003; Wed, 16 May 2012 10:17:06 +0800 From: Jiangyuanlong To: Sam Cao , 'Daniel Cohn' , 'Alexander Vainshtein' Subject: RE: Discussion on forwarding performance Thread-Topic: Discussion on forwarding performance Thread-Index: AQHNMp8ego9/CtMoakapN2JoMtGUPZbLpm1g Date: Wed, 16 May 2012 02:17:04 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D41392A@szxeml546-mbs.china.huawei.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D411694@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF5C@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D4130E1@szxeml546-mbs.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF8F@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413216@szxeml546-mbs.china.huawei.com> <3F1F3739E2B04D399CC7D26CE934F91A@v2comsam> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413694@szxeml546-mbs.china.huawei.com> <7A564821DF1642E592E884D5C623772C@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D41370E@szxeml546-mbs.china.huawei.com> <400D5D93E6AA4075861CE09919D84747@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413741@szxeml546-mbs.china.huawei.com> <7BDA456234D045E1BD42EA059A4E9579@v2comsam> In-Reply-To: <7BDA456234D045E1BD42EA059A4E9579@v2comsam> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.40.73] 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, 16 May 2012 02:18:59 -0000 3rd mapping will make data plane complex, I think. Anyway, we reached a consensus on Multi-PW implementation.=20 If we use 3rd mapping, I agree with your opinion, maybe dual-VLAN seems simple, but 2 mapping is enough.=20 [JY] Can't see how 2 mapping is enough for 2PW, do you mean to use 2 PWs fo= r all the peer PEs? Then we can focus on data plane performance. While stripe PW label out on egress PE, data-plane knows how t= o forward the frames from PW, to Root AC or Leaf AC or all. But if we use Dual-VLAN, after strip PW label out, data plane should strip VLAN-ID out an= d then does same forwarding work as Multi-PW does.=20 [JY] We are running into the same cycle: forward implications for 2PW was a= lready covered in http://www.ietf.org/mail-archive/web/l2vpn/current/msg035= 13.html, no need to repeat it here. The most important is, do one more operation while forwarding E-Tree frames. Obviously the forwarding performance of Dual-VLAN will be much lower than what of Multi-PW. [JY] VLAN operation is generally available in VPLS already, does this state= ment also mean Multi-PW will have a much higher performance even compared w= ith VPLS itself? Regards, =20 Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com=20 =20 -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Tuesday, May 15, 2012 7:03 PM To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS See my further comments in line. -----Original Message----- From: Sam Cao [mailto:yuqun.cao@gmail.com]=20 Sent: Tuesday, May 15, 2012 6:14 PM To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Yuanlong, Thank you very much for your comments. I draw the topology you gave, and 7 PWs will be established if we follow 01. Root AC ---- PE 1 ----- PW 1 -------- PE 2 ----- Leaf _AC | \ / || | \ /=3D=3D=3DPW 6,7=3D=3D=3D || PW 2 -----PW 5------\ || | /----Root PW 3 --- \ || Root _AC ---- PE 3 PE 4 ------ Root AC | \ / | | ----Leaf PW 4----- |=20 Leaf AC Leaf AC Yes, on PE 3 there are several PWs, but if you want to clarify it, there ar= e only 3 types, one can carry frames originated from Root and Leaf AC(one endpoint of this PW should be Root-only, otherwise this is invalid), one only can carry frames from Root AC, and the last can carry frames from Leaf ACs. On second thoughts, we still can classify the PWs into 2 sets, one is Leaf set, and another is Root set, and the union of the sets Leaf and Root is the PW we called it as compatible PW (Maybe this is not correct, we can find one good term on this).=20 So this optimization still follows the original design of Dual-PW approach, Leaf PW only carries frames from Leaf AC; Root-PW only carries frames from Root AC. Is it right? I don't know whether chip can support this forwarding behavior for compatible PW or not, but if we implement it in NP, it is nearly same as VPLS. The only difference is, setup 2 mappings, one between Leaf-ACs and Leaf-PWs, one between Root-ACs and Root-PWs. For traditional VPLS, there is only one mapping.=20 [JY] It seems you may need a 3rd mapping: from both root & leaf AC to a compatible PW. BTW, for the forwarding and reverse direction, the mapping may be asymmetri= c for you compatible PW. Based on my understanding, all drafts should have similar mapping.=20 [JY] Dual-VLAN seems simpler here. Thanks, Sam -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Tuesday, May 15, 2012 3:32 PM To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Sam, Thanks, please see my further comments with [JY]. Ok, we go on the case in your mail, where PE1 has one Root-only AC, AC1, an= d PE2 has one Leaf-only AC, AC2. In general we can setup 2 "unidirectional" PWs (bidirectional PW, but just carry unidirectional frames), Root-PW which carries frames originated from AC1 and Leaf-PW which carries frames originated from AC2. But only one PW also can work, just as some members commented. Ok, we setup one PW between PE1 and PE2, we can call this PW as compatible PW or something else. Frames originated from Root or leaf ACs will be carried via this PW. Its forwarding behavior is fully same as what traditional VPLS did, MAC learning on AC or PW in one E-Tree. Or say, if on= e PE has Root-only ACs, it will setup one PW with another PE, Root-only, Leaf-only or Root-Leaf-Mixed. If 2 PEs are root-Leaf-Mixed or other cases, then 2 PWs will be established. As you know, this can be done on control plane.=20 [JY] Assume there are 2 other nodes PE3 & PE4 in this network scenario, and both PE3 and PE4 have both root and leaf ACs, then there are compatible PWs from PE3 which may carry both root and leaf traffic (to PE1), which may carry only root traffic (to PE2); and further there are root PW and leaf PW to PE4. Thus, the VSI on PE3 has at least 4 different types of PW transmitting behaviours with regard to the E-Tree traffic. In the reverse direction, the VSI on PE3 further has at least 4 different types of PW receiving behaviours. Not sure how you will accommodate for these PWs in both the data plane and control plane. Regards, Yuanlong Is this clear for you? Is this necessary to optimize PW setup in this case?= =20 Maybe we need to add one paragraph on forwarding behavior.=20 Again thank you very much for your comments, Sam -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Tuesday, May 15, 2012 10:27 AM To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Please see my comments in line. -----Original Message----- From: Sam Cao [mailto:yuqun.cao@gmail.com]=20 Sent: Monday, May 14, 2012 8:31 PM To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Yuanlong, We have discussed this in another thread. In fact, Daniel or I have given the answers to the questions you raised here for several time :). If we do in this way, we will reach deadlock and can not move forward :). I try to explain it again. [JY] I will apologize if you had ever provided such answers before, and you may just refer to the links rather than repeat the explanation. As you can see, I just try to understand the mechanism of 2PW and its implications, but the I-D does not include enough information. As you know, initial design we will setup 2 PWs all the time (if do in this way, I think that you have no question),=20 [JY] I will be concerned with the operational complexity of this approach. but in most cases 2 PWs are not necessary. So in 01 version, we optimize it. "Root-only VSI <-> any VSI: only root PW required" "Leaf-only VSI <-> leaf-only VSI: no PWs required" In other cases 2 PWs are needed. If so, "Leaf-only -> root-only =3D one lea= f PW" is not correct: On Leaf-only side, yes, one Leaf-only PW is created between Local Leaf type with remote Root type; on root-only side, one root-only PW is created. Maybe it is better to call this as compatible or mixed PW. So the left items you list are not correct for multi_PW solution. [JY] This is something new, right? To be honest, I could not understand wha= t is your point: doesn't the mixed PW as you called also consist of one Leaf-only PW in one direction and one root-only PW in the other direction? Furthermore, the case you took is also one case in your guideline "Root-onl= y VSI <-> any VSI: only root PW required", don't you think that only one root PW is required following this guideline? Actually, I don't care much about what is the bidirectional PW or unidirectional PW called, but how can a VSI support such a mixed scenarios: traditional VSI assumes only one PW is required for each peer VSI, and its MAC leaning is based on bidirectional PW. But for 2PW, there are bidirectional root PW, bidirectional leaf PW, mixed PW, etc..., how to support these kinds of PWs in the same VSI is my top concern. BTW, I guess you also care this case we also have discussed before: for example, if we configure one Leaf AC on root-only PE (then it will be root-leaf-mixed PE), we will teardown the compatible PW and re-setup PWs again with 01.=20 [JY] This was discussed in the emails indeed. Regards, =20 Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com=20 =20 -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Monday, May 14, 2012 7:10 PM To: Daniel Cohn; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Daniel, Fine, now it seems more in line with what we had proposed in 2VLAN: a spoke PW behaves like root/leaf AC for a PE-r. But the same problem may also apply to the root/spoke "core PW" for Multi-PW: According to Multi-PW, only one PW is required between two PEs except when both PEs are mixed with root and leaf, so these PWs may be formed by combinations of the following unidirectional PW cases (extracted and adapte= d from Josh's email): Root-only -> any VSI =3D one root PW Leaf-only -> root-only =3D one leaf PW Leaf-only -> mixed =3D one leaf PW=20 Mixed -> root-only =3D one (root+leaf) PW =20 Mixed -> leaf-only =3D one (root+leaf) PW =20 I have a concern that the forwarding plane of PE to implement this will be very different from the traditional VPLS. Regards, Yuanlong -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Monday, May 14, 2012 5:00 PM To: Jiangyuanlong; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Yuanlong, Like I wrote below, root/leaf spoke PW behave like root/leaf AC, not like root/spoke "core PW". So no changes to forwarding plane once this is understood. DC -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Monday, May 14, 2012 11:36 AM To: Daniel Cohn; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Daniel, please see my comments in line. -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Monday, May 14, 2012 3:37 PM To: Jiangyuanlong; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Yuanlong, As I see it, for the PE-r spoke (figure 4 in RFC 4762) we establish a single PW per AC - root PW for root AC and leaf PW for leaf AC. With local configuration at the PE-rs as part of the spoke PW provisioning. And the PE-rs will treat root/leaf spoke PWs exactly as it treat root/leaf ACs. So when leaf-originated BUM traffic arrives from the core (over a leaf PW), it will be forwarded over all root spoke PWs but not on the leaf spoke PWs.=20 [JY] So in the reverse direction, you need to transport both root and leaf traffic from PE-rs over a root PW to PE-r, and transport root traffic over a leaf PW. It seems against the definition of root PW and leaf PW in the multi-PW draft. Don't this make the forwarding plane of PE-rs more complex?=20 The forwarding plane is exactly the same as described in the multi-PW draft, where spoke PWs are treated exactly like ACs. Regards, Daniel -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Friday, May 11, 2012 5:03 AM To: Daniel Cohn; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Daniel and all, When you set up two PWs from the PE-rs to a PE-r for each of its AC, do you mean that one PW is bidirectional root PW and the other is bidirectional leaf PW? My concern is: where should the leaf traffic be filtered, on the PE-rs or on the PE-r? If filtered on the PE-r, then lots of bandwidth will be wasted (for example, if the PE-r is attached with 9 leafs, then the BUM traffic from one of its leafs will be multiplied by 8 times, and be forwarded by the PE-rs to the same PE-r). If filtered on the PE-rs, not sure how you will design its forwarding plane, can you give a hint? Thanks, Yuanlong ------------------------------ Date: Wed, 9 May 2012 09:16:36 +0300 From: "Daniel Cohn" To: "Alexander Vainshtein" , "Sam Cao" , Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780CBA6@tlvmail1> Content-Type: text/plain; charset=3D"ISO-2022-JP" Hi Sasha, It's actually very simple. A frame that originated in a root AC is always transmitted only in root PW, no matter what the frame type (known/unknown unicast or broadcast). This is how the frame source information is propagated across the VPLS. So in the H-VPLS example, the PE-r will never forward a frame received over a root PW on any leaf PW, only on root PWs (toward the core or toward other spokes). Hope this clarifies it, regards, Daniel -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Alexander Vainshtein Sent: Wednesday, May 09, 2012 7:59 AM To: Sam Cao; l2vpn@ietf.org Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Sam, Lizhong and all, You've written that in the two-PW solution combined with H-VPLS the PE-r must set up two PWs with each MTU-s. If this is the case, what kind of forwarding logic should be used to prevent sending a BUM frame received from a root-PW to a given MTU-S: - back to the same MTU-S on the corresponding leaf-PW? - twice (to both root-PW and Leaf-PW) to another MTU-s? And, BTW, how is the PW selected in this case? I am aware of a technique of multiple split horizon groups in PE-r which could be possibly used for this purpose. However, since these groups have to be represented explicitly in the data plane, their potential number is limited by the forwarding HW. Other methods could be probably used for the same purpose, but they would probably subject to similar HW-based limitations. I suspect that with the dual-PW approach, the HW would pose an implicit limit, say, on a number of MTU-s that can be connected to the same PE-r and that this limit could be quite low in most cases. Based on this I suspect that the H-VPLS issue as a critical drawback of the dual-PW approach to E-Tree. My 2c, Sasha ________________________________________ From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Sam Cao [yuqun.cao@gmail.com] Sent: Wednesday, May 09, 2012 3:40 AM To: l2vpn@ietf.org Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Hi Lizhong? Thank you very much for your comments. I updated the result on this question. [Lizhong] agree with the above analysis. And we did not say it is a technical problem, but it is an operational problem again. [Sam] I agree. Dual-VLAN does not make sense. I also discussed this with Giles and Yuanlong in another mail, and we reached agreement on this: MTU should know the access mode, VPWS or VPLS, VPWS mode should configure VLAN ID on MTU but VPLS mode can not. I thought this is NOT reasonable :), but we can figure this out in draft. It seems ok. [Lizhong] not fully understand. Do you mean, when VPWS accessing for H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf PW) for each AC access? [Sam] Yes. Thanks, Sam =20 From jiangyuanlong@huawei.com Tue May 15 19:47: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 28F2311E80CF for ; Tue, 15 May 2012 19:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.105 X-Spam-Level: X-Spam-Status: No, score=-4.105 tagged_above=-999 required=5 tests=[AWL=1.894, BAYES_00=-2.599, J_CHICKENPOX_23=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 zFmJo41t4M-x for ; Tue, 15 May 2012 19:47:53 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6597411E80BE for ; Tue, 15 May 2012 19:47: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 AFY61384; Tue, 15 May 2012 22:47:53 -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; Tue, 15 May 2012 19:45:47 -0700 Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 15 May 2012 19:45:50 -0700 Received: from SZXEML546-MBS.china.huawei.com ([169.254.4.75]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.003; Wed, 16 May 2012 10:45:41 +0800 From: Jiangyuanlong To: Sam Cao , Lucy yong , 'David Allan I' , "'Balus, Florin Stelian (Florin)'" , 'Daniel Cohn' , 'Alexander Vainshtein' Subject: RE: Discussion on forwarding performance Thread-Topic: Discussion on forwarding performance Thread-Index: AQHNMp8ego9/CtMoakapN2JoMtGUPZbKvTGAgAAAzYCAAAV4AIAAYvAAgACKNEA= Date: Wed, 16 May 2012 02:45:40 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D41394A@szxeml546-mbs.china.huawei.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D411694@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF5C@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D4130E1@szxeml546-mbs.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF8F@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413216@szxeml546-mbs.china.huawei.com> <3F1F3739E2B04D399CC7D26CE934F91A@v2comsam> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413694@szxeml546-mbs.china.huawei.com> <7A564821DF1642E592E884D5C623772C@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D41370E@szxeml546-mbs.china.huawei.com> <400D5D93E6AA4075861CE09919D84747@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413741@szxeml546-mbs.china.huawei.com> <7BDA456234D045E1BD42EA059A4E9579@v2comsam> <2073A6C5467C99478898544C6EBA3F4602C1907568@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> <60C093A41B5E45409A19D42CF7786DFD52328D98DF@EUSAACMS0703.eamcs.ericsson.se> <2691CE0099834E4A9C5044EEC662BB9D33108DD9@dfweml506- mbx> <1A7E043E03FF48A2B3E5ECCD4F124B4C@R01842> In-Reply-To: <1A7E043E03FF48A2B3E5ECCD4F124B4C@R01842> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.40.73] 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, 16 May 2012 02:47:55 -0000 See my comments in line. -----Original Message----- From: Sam Cao [mailto:yuqun.cao@gmail.com]=20 Sent: Wednesday, May 16, 2012 10:09 AM To: Lucy yong; 'David Allan I'; 'Balus, Florin Stelian (Florin)'; Jiangyuan= long; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance Lucy/David/Florin, Thank you very much for your comments.=20 I can not give the accurate data to support my conclusion, and just conclud= e that if we implement it in NP module. Except for common operations of 2 approaches, Tunnel Label push/pop-out, MAC-based forwarding, and etc., Dual-VLAN needs one more VLAN push/pop-out operation while forwarding every frame. So compared with Multi-PW, it needs more resource and time for NP module if there are VSIs or PWs up limit to the capacity on one PE, and standing on software architect's side, the performance will be decreased by at least 20%, I guess. I implemented one prototype which has similar solution as current Multi-PW, and the performance will be decreased by 5%, compared with traditional VPLS. Daniel has experience on 2-PW deployment, maybe he can give accurate data on Multi-PW. [JY] So you have no NP implementation either for Dual-VLAN or Multi-PW... b= ut why do you think the performance will be decreased by at least 20%? I also have some experiences in NP programming, it must be a big surprise t= hat one more VLAN push/pop-out operation will incur a penalty of performanc= e degradation of 20%.=20 Florin, do you mean that you have implemented E-Tree in MPLS network? If chipset can support this and we don't care NP or other solutions, yes, we can ignore any side effect on forwarding performance. Yes, it can support E-tree in IP (Ethernet) network, but I read some CHIP datasheets, after strip PW label out, chip can not handle 2 VLAN IDs at same time. Could you please give me some hints, say, which chip you used? [JY] the chip doesn't need to handle 2 VLAN IDs at same time, see the previ= ous msg: http://www.ietf.org/mail-archive/web/l2vpn/current/msg03392.html Maybe if we raised only one issue in one mail, we can get more and insight comments :). I will raise another after we agree with this in the main :).= =20 Thanks, Sam -----Original Message----- From: Lucy yong [mailto:lucy.yong@huawei.com]=20 Sent: Wednesday, May 16, 2012 4:15 AM To: David Allan I; Balus, Florin Stelian (Florin); Sam Cao; Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance +1 We can't just make a conclusion from nowhere. Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of David Allan I Sent: Tuesday, May 15, 2012 2:55 PM To: Balus, Florin Stelian (Florin); Sam Cao; Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance Florin: I agree. The statement, at least to me, is a non-sequitor... Cheers Dave -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Balus, Florin Stelian (Florin) Sent: Tuesday, May 15, 2012 12:53 PM To: Sam Cao; 'Jiangyuanlong'; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance Sam, > Obviously the forwarding performance of Dual-VLAN will be much lower than what of Multi-PW. Sorry I could not keep up with some of the threads on this subject but the above statement caught my eyes. We have been doing all kind of egress operations on VLANs in the egress PE for the last 8 years and I am not awar= e of any "much lower" forwarding performance. As far as I know the chipsets used in the PEs can do this processing no problem. Do you want to clarify which kind of hardware may have problems? > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Sam Cao > Sent: Tuesday, May 15, 2012 6:32 AM > To: 'Jiangyuanlong'; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on forwarding performance > > Hi Yuanlong, > > 3rd mapping will make data plane complex, I think. Anyway, we reached > a consensus on Multi-PW implementation. > > If we use 3rd mapping, I agree with your opinion, maybe dual-VLAN > seems simple, but 2 mapping is enough. Then we can focus on data plane > performance. While stripe PW label out on egress PE, data-plane knows > how to forward the frames from PW, to Root AC or Leaf AC or all. But > if we use Dual-VLAN, after strip PW label out, data plane should strip > VLAN-ID out and then does same forwarding work as Multi-PW does. The > most important is, do one more operation while forwarding E-Tree > frames. Obviously the forwarding performance of Dual-VLAN will be much > lower than what of Multi-PW. > > Regards, > > Yuqun (Sam) Cao > E-mail: Yuqun.cao@gmail.com > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 7:03 PM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > See my further comments in line. > > -----Original Message----- > From: Sam Cao [mailto:yuqun.cao@gmail.com] > Sent: Tuesday, May 15, 2012 6:14 PM > To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > Thank you very much for your comments. I draw the topology you gave, > and 7 PWs will be established if we follow 01. > > Root AC ---- PE 1 ----- PW 1 -------- PE 2 ----- Leaf _AC > | \ / || > | \ /=3D=3D=3DPW 6,7=3D=3D=3D || > PW 2 -----PW 5------\ || > | /----Root PW 3 --- \ || > Root _AC ---- PE 3 PE 4 ------ Root AC > | \ / | > | ----Leaf PW 4----- | > Leaf AC Leaf AC > Yes, on PE 3 there are several PWs, but if you want to clarify it, > there are only 3 types, one can carry frames originated from Root and > Leaf AC(one endpoint of this PW should be Root-only, otherwise this is > invalid), one only can carry frames from Root AC, and the last can > carry frames from Leaf ACs. On second thoughts, we still can classify > the PWs into 2 sets, one is Leaf set, and another is Root set, and the > union of the sets Leaf and Root is the PW we called it as compatible > PW (Maybe this is not correct, we can find one good term on this). > > So this optimization still follows the original design of Dual-PW > approach, Leaf PW only carries frames from Leaf AC; Root-PW only > carries frames from Root AC. Is it right? > > I don't know whether chip can support this forwarding behavior for > compatible PW or not, but if we implement it in NP, it is nearly same > as VPLS. The only difference is, setup 2 mappings, one between > Leaf-ACs and Leaf-PWs, one between Root-ACs and Root-PWs. For > traditional VPLS, there is only one mapping. > > [JY] It seems you may need a 3rd mapping: from both root & leaf AC to > a compatible PW. > BTW, for the forwarding and reverse direction, the mapping may be > asymmetric for you compatible PW. > > Based on my understanding, all drafts should have similar mapping. > > [JY] Dual-VLAN seems simpler here. > > Thanks, > > Sam > > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 3:32 PM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Sam, > > Thanks, please see my further comments with [JY]. > > Ok, we go on the case in your mail, where PE1 has one Root-only AC, > AC1, and > PE2 has one Leaf-only AC, AC2. In general we can setup 2 > "unidirectional" > PWs (bidirectional PW, but just carry unidirectional frames), Root-PW > which carries frames originated from AC1 and Leaf-PW which carries > frames originated from AC2. But only one PW also can work, just as > some members commented. Ok, we setup one PW between PE1 and PE2, we > can call this PW as compatible PW or something else. Frames originated > from Root or leaf ACs will be carried via this PW. Its forwarding > behavior is fully same as what traditional VPLS did, MAC learning on > AC or PW in one E-Tree. Or say, if one PE has Root-only ACs, it will > setup one PW with another PE, Root-only, Leaf-only or Root-Leaf-Mixed. > If 2 PEs are root-Leaf-Mixed or other cases, then 2 PWs will be > established. As you know, this can be done on control plane. > > [JY] Assume there are 2 other nodes PE3 & PE4 in this network > scenario, and both PE3 and PE4 have both root and leaf ACs, then there > are compatible PWs from PE3 which may carry both root and leaf traffic > (to PE1), which may carry only root traffic (to PE2); and further > there are root PW and leaf PW to PE4. Thus, the VSI on PE3 has at > least 4 different types of PW transmitting behaviours with regard to > the E-Tree traffic. In the reverse direction, the VSI on PE3 further > has at least > 4 different types of PW receiving behaviours. Not sure how you will > accommodate for these PWs in both the data plane and control plane. > > Regards, > Yuanlong > > Is this clear for you? Is this necessary to optimize PW setup in this > case? > > Maybe we need to add one paragraph on forwarding behavior. > > Again thank you very much for your comments, > > Sam > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 10:27 AM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Please see my comments in line. > > -----Original Message----- > From: Sam Cao [mailto:yuqun.cao@gmail.com] > Sent: Monday, May 14, 2012 8:31 PM > To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > We have discussed this in another thread. In fact, Daniel or I have > given the answers to the questions you raised here for several time :). > If we do in this way, we will reach deadlock and can not move forward > :). I try to explain it again. > > [JY] I will apologize if you had ever provided such answers before, > and you may just refer to the links rather than repeat the explanation. > As you can see, I just try to understand the mechanism of 2PW and its > implications, but the I-D does not include enough information. > > As you know, initial design we will setup 2 PWs all the time (if do in > this way, I think that you have no question), > > [JY] I will be concerned with the operational complexity of this > approach. > > but in most cases 2 PWs are not > necessary. So in 01 version, we optimize it. > > "Root-only VSI <-> any VSI: only root PW required" > "Leaf-only VSI <-> leaf-only VSI: no PWs required" > > In other cases 2 PWs are needed. If so, "Leaf-only -> root-only =3D one > leaf PW" is not correct: On Leaf-only side, yes, one Leaf-only PW is > created between Local Leaf type with remote Root type; on root-only > side, one root-only PW is created. Maybe it is better to call this as > compatible or mixed PW. So the left items you list are not correct for > multi_PW solution. > > [JY] This is something new, right? To be honest, I could not > understand what is your point: doesn't the mixed PW as you called also > consist of one Leaf-only PW in one direction and one root-only PW in > the other direction? > Furthermore, the case you took is also one case in your guideline > "Root-only VSI <-> any VSI: only root PW required", don't you think > that only one root PW is required following this guideline? > Actually, I don't care much about what is the bidirectional PW or > unidirectional PW called, but how can a VSI support such a mixed > scenarios: > traditional VSI assumes only one PW is required for each peer VSI, and > its MAC leaning is based on bidirectional PW. But for 2PW, there are > bidirectional root PW, bidirectional leaf PW, mixed PW, etc..., how to > support these kinds of PWs in the same VSI is my top concern. > > BTW, I guess you also care this case we also have discussed before: > for example, if we configure one Leaf AC on root-only PE (then it will > be root-leaf-mixed PE), we will teardown the compatible PW and > re-setup PWs again with 01. > [JY] This was discussed in the emails indeed. > > Regards, > > Yuqun (Sam) Cao > E-mail: Yuqun.cao@gmail.com > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Monday, May 14, 2012 7:10 PM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Daniel, > > Fine, now it seems more in line with what we had proposed in 2VLAN: a > spoke PW behaves like root/leaf AC for a PE-r. > > But the same problem may also apply to the root/spoke "core PW" for > Multi-PW: > According to Multi-PW, only one PW is required between two PEs except > when both PEs are mixed with root and leaf, so these PWs may be formed > by combinations of the following unidirectional PW cases (extracted > and adapted from Josh's email): > Root-only -> any VSI =3D one root PW > Leaf-only -> root-only =3D one leaf PW > Leaf-only -> mixed =3D one leaf PW > Mixed -> root-only =3D one (root+leaf) PW Mixed -> leaf-only =3D one > (root+leaf) PW > > I have a concern that the forwarding plane of PE to implement this > will be very different from the traditional VPLS. > > Regards, > Yuanlong > > -----Original Message----- > From: Daniel Cohn [mailto:DanielC@orckit.com] > Sent: Monday, May 14, 2012 5:00 PM > To: Jiangyuanlong; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > Like I wrote below, root/leaf spoke PW behave like root/leaf AC, not > like root/spoke "core PW". So no changes to forwarding plane once this > is understood. > > DC > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Monday, May 14, 2012 11:36 AM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Daniel, please see my comments in line. > > -----Original Message----- > From: Daniel Cohn [mailto:DanielC@orckit.com] > Sent: Monday, May 14, 2012 3:37 PM > To: Jiangyuanlong; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > As I see it, for the PE-r spoke (figure 4 in RFC 4762) we establish a > single PW per AC - root PW for root AC and leaf PW for leaf AC. With > local configuration at the PE-rs as part of the spoke PW provisioning. > And the PE-rs will treat root/leaf spoke PWs exactly as it treat > root/leaf ACs. So when leaf-originated BUM traffic arrives from the > core (over a leaf PW), it will be forwarded over all root spoke PWs > but not on the leaf spoke PWs. > > [JY] So in the reverse direction, you need to transport both root and > leaf traffic from PE-rs over a root PW to PE-r, and transport root > traffic over a leaf PW. It seems against the definition of root PW and > leaf PW in the multi-PW draft. Don't this make the forwarding plane of > PE-rs more complex? > > The forwarding plane is exactly the same as described in the multi-PW > draft, where spoke PWs are treated exactly like ACs. > > Regards, > > Daniel > > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Friday, May 11, 2012 5:03 AM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Daniel and all, > > When you set up two PWs from the PE-rs to a PE-r for each of its AC, > do you mean that one PW is bidirectional root PW and the other is > bidirectional leaf PW? > My concern is: where should the leaf traffic be filtered, on the PE-rs > or on the PE-r? > If filtered on the PE-r, then lots of bandwidth will be wasted (for > example, if the PE-r is attached with 9 leafs, then the BUM traffic > from one of its leafs will be multiplied by 8 times, and be forwarded > by the PE-rs to the same PE-r). > If filtered on the PE-rs, not sure how you will design its forwarding > plane, can you give a hint? > > Thanks, > Yuanlong > > ------------------------------ > Date: Wed, 9 May 2012 09:16:36 +0300 > From: "Daniel Cohn" > To: "Alexander Vainshtein" , "Sa= m > Cao" , > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780CBA6@tlvmail1> > Content-Type: text/plain; charset=3D"ISO-2022-JP" > > Hi Sasha, > > It's actually very simple. A frame that originated in a root AC is > always transmitted only in root PW, no matter what the frame type > (known/unknown unicast or broadcast). This is how the frame source > information is propagated across the VPLS. So in the H-VPLS example, > the PE-r will never forward a frame received over a root PW on any > leaf PW, only on root PWs (toward the core or toward other spokes). > > Hope this clarifies it, regards, > > Daniel > > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Alexander Vainshtein > Sent: Wednesday, May 09, 2012 7:59 AM > To: Sam Cao; l2vpn@ietf.org > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > > Sam, Lizhong and all, > You've written that in the two-PW solution combined with H-VPLS the > PE- r must set up two PWs with each MTU-s. > > If this is the case, what kind of forwarding logic should be used to > prevent sending a BUM frame received from a root-PW to a given MTU-S: > - back to the same MTU-S on the corresponding leaf-PW? > - twice (to both root-PW and Leaf-PW) to another MTU-s? And, BTW, how > is the PW selected in this case? > > I am aware of a technique of multiple split horizon groups in PE-r > which could be possibly used for this purpose. However, since these > groups have to be represented explicitly in the data plane, their > potential number is limited by the forwarding HW. Other methods could > be probably used for the same purpose, but they would probably subject > to similar HW-based limitations. > > I suspect that with the dual-PW approach, the HW would pose an > implicit limit, say, on a number of MTU-s that can be connected to the > same PE-r and that this limit could be quite low in most cases. > > Based on this I suspect that the H-VPLS issue as a critical drawback > of the dual-PW approach to E-Tree. > > My 2c, > Sasha > > > ________________________________________ > From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Sam > Cao [yuqun.cao@gmail.com] > Sent: Wednesday, May 09, 2012 3:40 AM > To: l2vpn@ietf.org > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Lizhong? > > Thank you very much for your comments. I updated the result on this > question. > > [Lizhong] agree with the above analysis. And we did not say it is a > technical problem, but it is an operational problem again. > [Sam] I agree. Dual-VLAN does not make sense. I also discussed this > with Giles and Yuanlong in another mail, and we reached agreement on > this: > MTU should know the access mode, VPWS or VPLS, VPWS mode should > configure VLAN ID on MTU but VPLS mode can not. I thought this is NOT > reasonable :), but we can figure this out in draft. It seems ok. > > [Lizhong] not fully understand. Do you mean, when VPWS accessing for > H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf > PW) for each AC access? > [Sam] Yes. > > Thanks, > > Sam > > > > From yuqun.cao@gmail.com Tue May 15 19:50: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 4612E11E80D0 for ; Tue, 15 May 2012 19:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.838 X-Spam-Level: X-Spam-Status: No, score=-2.838 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, J_CHICKENPOX_23=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 PDKJTdSkyoYu for ; Tue, 15 May 2012 19:50: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 CE13B11E80BE for ; Tue, 15 May 2012 19:50:09 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so452121pbc.31 for ; Tue, 15 May 2012 19:50:09 -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=7/VWuEeK3q/i1QJBupybrBlT8EpfXvnqOt9f/F/KdYI=; b=M/7RkC+qMnfAG6Ja2njW18Nbj51KSQPipwRu+btlCrnPOcMt9lij1lVzOHOZybu6o+ 5YiALvSykPKnT+bE/QoKT5zYFOrk31Qa11v2KxL9/QjxPKJfsqZSEACHLTsbsGeLZ5ir 4XoEn4KRlyO3VLHxyJb/3uVHksAxH+OjFr0Us2qht+iJSlRFbWymQ0ERqlipuEP8n2hm xM3pFYFbMdUjk6cZq8iAs7u6rzOuTlCoFhpAQ5QGETqKIz0JY9O7hoQEmra7MokMBq5n tjYxf5aa3Ih0jNHpTl1jiQ1XicIAu7FZkYbx54p4UsI4iIxvag1237jThxXblKkZ67Ot aDfQ== Received: by 10.68.138.161 with SMTP id qr1mr11684345pbb.37.1337136609595; Tue, 15 May 2012 19:50:09 -0700 (PDT) Received: from R01842 ([110.90.119.113]) by mx.google.com with ESMTPS id vc4sm3825788pbc.8.2012.05.15.19.50.04 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 May 2012 19:50:08 -0700 (PDT) From: "Sam Cao" To: "'Jiangyuanlong'" , "'Daniel Cohn'" , "'Alexander Vainshtein'" References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D411694@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF5C@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D4130E1@szxeml546-mbs.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF8F@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413216@szxeml546-mbs.china.huawei.com> <3F1F3739E2B04D399CC7D26CE934F91A@v2comsam> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413694@szxeml546-mbs.china.huawei.com> <7A564821DF1642E592E884D5C623772C@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D41370E@szxeml546-mbs.china.huawei.com> <400D5D93E6AA4075861CE09919D84747@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413741@szxeml546-mbs.china.huawei.com> <7BDA456234D045E1BD42EA059A4E9579@v2comsam> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D41392A@szxeml546-mbs.china.huawei.com> Subject: RE: Discussion on forwarding performance Date: Wed, 16 May 2012 10:49:51 +0800 Message-ID: <4BDAB74EAC0C49FEAD65A9575DB2E159@R01842> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D41392A@szxeml546-mbs.china.huawei.com> Thread-index: AQHNMp8ego9/CtMoakapN2JoMtGUPZbLpm1ggAAMumA= 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: Wed, 16 May 2012 02:50:11 -0000 Yes, Yuanlong. We have discussed this before, but I can not get clear conclusion till now. From that linkage I also can not find it. Compared to traditional VPLS, forwarding performance of all solutions will be decreased. If chip can fully support the solutions and we ignore other non-chip solution, we can ignore forwarding performance. But can we ignore it? I found your patent application on this, and think that we need to re-design VLAN Bridge you mentioned. VLAN Bridge can not support this inherently :). BTW, Yuanlong, is there any experimental data on forwarding performance? Thanks, Sam -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] Sent: Wednesday, May 16, 2012 10:17 AM To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance 3rd mapping will make data plane complex, I think. Anyway, we reached a consensus on Multi-PW implementation. If we use 3rd mapping, I agree with your opinion, maybe dual-VLAN seems simple, but 2 mapping is enough. [JY] Can't see how 2 mapping is enough for 2PW, do you mean to use 2 PWs for all the peer PEs? Then we can focus on data plane performance. While stripe PW label out on egress PE, data-plane knows how to forward the frames from PW, to Root AC or Leaf AC or all. But if we use Dual-VLAN, after strip PW label out, data plane should strip VLAN-ID out and then does same forwarding work as Multi-PW does. [JY] We are running into the same cycle: forward implications for 2PW was already covered in http://www.ietf.org/mail-archive/web/l2vpn/current/msg03513.html, no need to repeat it here. The most important is, do one more operation while forwarding E-Tree frames. Obviously the forwarding performance of Dual-VLAN will be much lower than what of Multi-PW. [JY] VLAN operation is generally available in VPLS already, does this statement also mean Multi-PW will have a much higher performance even compared with VPLS itself? Regards, Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] Sent: Tuesday, May 15, 2012 7:03 PM To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS See my further comments in line. -----Original Message----- From: Sam Cao [mailto:yuqun.cao@gmail.com] Sent: Tuesday, May 15, 2012 6:14 PM To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Yuanlong, Thank you very much for your comments. I draw the topology you gave, and 7 PWs will be established if we follow 01. Root AC ---- PE 1 ----- PW 1 -------- PE 2 ----- Leaf _AC | \ / || | \ /===PW 6,7=== || PW 2 -----PW 5------\ || | /----Root PW 3 --- \ || Root _AC ---- PE 3 PE 4 ------ Root AC | \ / | | ----Leaf PW 4----- | Leaf AC Leaf AC Yes, on PE 3 there are several PWs, but if you want to clarify it, there are only 3 types, one can carry frames originated from Root and Leaf AC(one endpoint of this PW should be Root-only, otherwise this is invalid), one only can carry frames from Root AC, and the last can carry frames from Leaf ACs. On second thoughts, we still can classify the PWs into 2 sets, one is Leaf set, and another is Root set, and the union of the sets Leaf and Root is the PW we called it as compatible PW (Maybe this is not correct, we can find one good term on this). So this optimization still follows the original design of Dual-PW approach, Leaf PW only carries frames from Leaf AC; Root-PW only carries frames from Root AC. Is it right? I don't know whether chip can support this forwarding behavior for compatible PW or not, but if we implement it in NP, it is nearly same as VPLS. The only difference is, setup 2 mappings, one between Leaf-ACs and Leaf-PWs, one between Root-ACs and Root-PWs. For traditional VPLS, there is only one mapping. [JY] It seems you may need a 3rd mapping: from both root & leaf AC to a compatible PW. BTW, for the forwarding and reverse direction, the mapping may be asymmetric for you compatible PW. Based on my understanding, all drafts should have similar mapping. [JY] Dual-VLAN seems simpler here. Thanks, Sam -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] Sent: Tuesday, May 15, 2012 3:32 PM To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Sam, Thanks, please see my further comments with [JY]. Ok, we go on the case in your mail, where PE1 has one Root-only AC, AC1, and PE2 has one Leaf-only AC, AC2. In general we can setup 2 "unidirectional" PWs (bidirectional PW, but just carry unidirectional frames), Root-PW which carries frames originated from AC1 and Leaf-PW which carries frames originated from AC2. But only one PW also can work, just as some members commented. Ok, we setup one PW between PE1 and PE2, we can call this PW as compatible PW or something else. Frames originated from Root or leaf ACs will be carried via this PW. Its forwarding behavior is fully same as what traditional VPLS did, MAC learning on AC or PW in one E-Tree. Or say, if one PE has Root-only ACs, it will setup one PW with another PE, Root-only, Leaf-only or Root-Leaf-Mixed. If 2 PEs are root-Leaf-Mixed or other cases, then 2 PWs will be established. As you know, this can be done on control plane. [JY] Assume there are 2 other nodes PE3 & PE4 in this network scenario, and both PE3 and PE4 have both root and leaf ACs, then there are compatible PWs from PE3 which may carry both root and leaf traffic (to PE1), which may carry only root traffic (to PE2); and further there are root PW and leaf PW to PE4. Thus, the VSI on PE3 has at least 4 different types of PW transmitting behaviours with regard to the E-Tree traffic. In the reverse direction, the VSI on PE3 further has at least 4 different types of PW receiving behaviours. Not sure how you will accommodate for these PWs in both the data plane and control plane. Regards, Yuanlong Is this clear for you? Is this necessary to optimize PW setup in this case? Maybe we need to add one paragraph on forwarding behavior. Again thank you very much for your comments, Sam -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] Sent: Tuesday, May 15, 2012 10:27 AM To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Please see my comments in line. -----Original Message----- From: Sam Cao [mailto:yuqun.cao@gmail.com] Sent: Monday, May 14, 2012 8:31 PM To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Yuanlong, We have discussed this in another thread. In fact, Daniel or I have given the answers to the questions you raised here for several time :). If we do in this way, we will reach deadlock and can not move forward :). I try to explain it again. [JY] I will apologize if you had ever provided such answers before, and you may just refer to the links rather than repeat the explanation. As you can see, I just try to understand the mechanism of 2PW and its implications, but the I-D does not include enough information. As you know, initial design we will setup 2 PWs all the time (if do in this way, I think that you have no question), [JY] I will be concerned with the operational complexity of this approach. but in most cases 2 PWs are not necessary. So in 01 version, we optimize it. "Root-only VSI <-> any VSI: only root PW required" "Leaf-only VSI <-> leaf-only VSI: no PWs required" In other cases 2 PWs are needed. If so, "Leaf-only -> root-only = one leaf PW" is not correct: On Leaf-only side, yes, one Leaf-only PW is created between Local Leaf type with remote Root type; on root-only side, one root-only PW is created. Maybe it is better to call this as compatible or mixed PW. So the left items you list are not correct for multi_PW solution. [JY] This is something new, right? To be honest, I could not understand what is your point: doesn't the mixed PW as you called also consist of one Leaf-only PW in one direction and one root-only PW in the other direction? Furthermore, the case you took is also one case in your guideline "Root-only VSI <-> any VSI: only root PW required", don't you think that only one root PW is required following this guideline? Actually, I don't care much about what is the bidirectional PW or unidirectional PW called, but how can a VSI support such a mixed scenarios: traditional VSI assumes only one PW is required for each peer VSI, and its MAC leaning is based on bidirectional PW. But for 2PW, there are bidirectional root PW, bidirectional leaf PW, mixed PW, etc..., how to support these kinds of PWs in the same VSI is my top concern. BTW, I guess you also care this case we also have discussed before: for example, if we configure one Leaf AC on root-only PE (then it will be root-leaf-mixed PE), we will teardown the compatible PW and re-setup PWs again with 01. [JY] This was discussed in the emails indeed. Regards, Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] Sent: Monday, May 14, 2012 7:10 PM To: Daniel Cohn; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Daniel, Fine, now it seems more in line with what we had proposed in 2VLAN: a spoke PW behaves like root/leaf AC for a PE-r. But the same problem may also apply to the root/spoke "core PW" for Multi-PW: According to Multi-PW, only one PW is required between two PEs except when both PEs are mixed with root and leaf, so these PWs may be formed by combinations of the following unidirectional PW cases (extracted and adapted from Josh's email): Root-only -> any VSI = one root PW Leaf-only -> root-only = one leaf PW Leaf-only -> mixed = one leaf PW Mixed -> root-only = one (root+leaf) PW Mixed -> leaf-only = one (root+leaf) PW I have a concern that the forwarding plane of PE to implement this will be very different from the traditional VPLS. Regards, Yuanlong -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: Monday, May 14, 2012 5:00 PM To: Jiangyuanlong; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Yuanlong, Like I wrote below, root/leaf spoke PW behave like root/leaf AC, not like root/spoke "core PW". So no changes to forwarding plane once this is understood. DC -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] Sent: Monday, May 14, 2012 11:36 AM To: Daniel Cohn; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Daniel, please see my comments in line. -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: Monday, May 14, 2012 3:37 PM To: Jiangyuanlong; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Yuanlong, As I see it, for the PE-r spoke (figure 4 in RFC 4762) we establish a single PW per AC - root PW for root AC and leaf PW for leaf AC. With local configuration at the PE-rs as part of the spoke PW provisioning. And the PE-rs will treat root/leaf spoke PWs exactly as it treat root/leaf ACs. So when leaf-originated BUM traffic arrives from the core (over a leaf PW), it will be forwarded over all root spoke PWs but not on the leaf spoke PWs. [JY] So in the reverse direction, you need to transport both root and leaf traffic from PE-rs over a root PW to PE-r, and transport root traffic over a leaf PW. It seems against the definition of root PW and leaf PW in the multi-PW draft. Don't this make the forwarding plane of PE-rs more complex? The forwarding plane is exactly the same as described in the multi-PW draft, where spoke PWs are treated exactly like ACs. Regards, Daniel -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] Sent: Friday, May 11, 2012 5:03 AM To: Daniel Cohn; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Daniel and all, When you set up two PWs from the PE-rs to a PE-r for each of its AC, do you mean that one PW is bidirectional root PW and the other is bidirectional leaf PW? My concern is: where should the leaf traffic be filtered, on the PE-rs or on the PE-r? If filtered on the PE-r, then lots of bandwidth will be wasted (for example, if the PE-r is attached with 9 leafs, then the BUM traffic from one of its leafs will be multiplied by 8 times, and be forwarded by the PE-rs to the same PE-r). If filtered on the PE-rs, not sure how you will design its forwarding plane, can you give a hint? Thanks, Yuanlong ------------------------------ Date: Wed, 9 May 2012 09:16:36 +0300 From: "Daniel Cohn" To: "Alexander Vainshtein" , "Sam Cao" , Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780CBA6@tlvmail1> Content-Type: text/plain; charset="ISO-2022-JP" Hi Sasha, It's actually very simple. A frame that originated in a root AC is always transmitted only in root PW, no matter what the frame type (known/unknown unicast or broadcast). This is how the frame source information is propagated across the VPLS. So in the H-VPLS example, the PE-r will never forward a frame received over a root PW on any leaf PW, only on root PWs (toward the core or toward other spokes). Hope this clarifies it, regards, Daniel -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Alexander Vainshtein Sent: Wednesday, May 09, 2012 7:59 AM To: Sam Cao; l2vpn@ietf.org Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Sam, Lizhong and all, You've written that in the two-PW solution combined with H-VPLS the PE-r must set up two PWs with each MTU-s. If this is the case, what kind of forwarding logic should be used to prevent sending a BUM frame received from a root-PW to a given MTU-S: - back to the same MTU-S on the corresponding leaf-PW? - twice (to both root-PW and Leaf-PW) to another MTU-s? And, BTW, how is the PW selected in this case? I am aware of a technique of multiple split horizon groups in PE-r which could be possibly used for this purpose. However, since these groups have to be represented explicitly in the data plane, their potential number is limited by the forwarding HW. Other methods could be probably used for the same purpose, but they would probably subject to similar HW-based limitations. I suspect that with the dual-PW approach, the HW would pose an implicit limit, say, on a number of MTU-s that can be connected to the same PE-r and that this limit could be quite low in most cases. Based on this I suspect that the H-VPLS issue as a critical drawback of the dual-PW approach to E-Tree. My 2c, Sasha ________________________________________ From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Sam Cao [yuqun.cao@gmail.com] Sent: Wednesday, May 09, 2012 3:40 AM To: l2vpn@ietf.org Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Hi Lizhong? Thank you very much for your comments. I updated the result on this question. [Lizhong] agree with the above analysis. And we did not say it is a technical problem, but it is an operational problem again. [Sam] I agree. Dual-VLAN does not make sense. I also discussed this with Giles and Yuanlong in another mail, and we reached agreement on this: MTU should know the access mode, VPWS or VPLS, VPWS mode should configure VLAN ID on MTU but VPLS mode can not. I thought this is NOT reasonable :), but we can figure this out in draft. It seems ok. [Lizhong] not fully understand. Do you mean, when VPWS accessing for H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf PW) for each AC access? [Sam] Yes. Thanks, Sam From loa@pi.nu Tue May 15 19:57: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 4BBD211E80CF for ; Tue, 15 May 2012 19:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BTz-WbmFvMQM for ; Tue, 15 May 2012 19:57:47 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF6C11E80C2 for ; Tue, 15 May 2012 19:57:44 -0700 (PDT) Received: from [192.168.1.101] (unknown [121.54.51.4]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 429EB2A8002; Wed, 16 May 2012 04:57:38 +0200 (CEST) Message-ID: <4FB317A8.6060104@pi.nu> Date: Wed, 16 May 2012 04:57:44 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Sam Cao Subject: Re: Discussion on forwarding performance References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D411694@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF5C@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D4130E1@szxeml546-mbs.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF8F@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413216@szxeml546-mbs.china.huawei.com> <3F1F3739E2B04D399CC7D26CE934F91A@v2comsam> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413694@szxeml546-mbs.china.huawei.com> <7A564821DF1642E592E884D5C623772C@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D41370E@szxeml546-mbs.china.huawei.com> <400D5D93E6AA4075861CE09919D84747@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413741@szxeml546-mbs.china.huawei.com> <7BDA456234D045E1BD42EA059A4E9579@v2comsam> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D41392A@szxeml546-mbs.china.huawei.com> <4BDAB74EAC0C49FEAD65A9575DB2E159@R01842> In-Reply-To: <4BDAB74EAC0C49FEAD65A9575DB2E159@R01842> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org, 'Jiangyuanlong' 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, 16 May 2012 02:57:48 -0000 Folks, an innocent question since I it is a long time since I worked with forwarding performance, I lost most of the interest when it was clear that whichever we used we could forward at wire speed. There has been other discussions around how many label look up certain hw can handle, but I thought we were past this point also. Would one extra label cause us to drop below wire speed in forwarding performance? Is this mostly a implementation complexity issue? /Loa On 2012-05-16 04:49, Sam Cao wrote: > Yes, Yuanlong. We have discussed this before, but I can not get clear > conclusion till now. From that linkage I also can not find it. > > Compared to traditional VPLS, forwarding performance of all solutions will > be decreased. If chip can fully support the solutions and we ignore other > non-chip solution, we can ignore forwarding performance. But can we ignore > it? > > I found your patent application on this, and think that we need to re-design > VLAN Bridge you mentioned. VLAN Bridge can not support this inherently :). > > BTW, Yuanlong, is there any experimental data on forwarding performance? > > Thanks, > > Sam > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Wednesday, May 16, 2012 10:17 AM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on forwarding performance > > 3rd mapping will make data plane complex, I think. Anyway, we reached a > consensus on Multi-PW implementation. > > If we use 3rd mapping, I agree with your opinion, maybe dual-VLAN seems > simple, but 2 mapping is enough. > > [JY] Can't see how 2 mapping is enough for 2PW, do you mean to use 2 PWs for > all the peer PEs? > > Then we can focus on data plane > performance. While stripe PW label out on egress PE, data-plane knows how to > forward the frames from PW, to Root AC or Leaf AC or all. But if we use > Dual-VLAN, after strip PW label out, data plane should strip VLAN-ID out and > then does same forwarding work as Multi-PW does. > > [JY] We are running into the same cycle: forward implications for 2PW was > already covered in > http://www.ietf.org/mail-archive/web/l2vpn/current/msg03513.html, no need to > repeat it here. > > The most important is, do > one more operation while forwarding E-Tree frames. Obviously the forwarding > performance of Dual-VLAN will be much lower than what of Multi-PW. > > [JY] VLAN operation is generally available in VPLS already, does this > statement also mean Multi-PW will have a much higher performance even > compared with VPLS itself? > > Regards, > > Yuqun (Sam) Cao > E-mail: Yuqun.cao@gmail.com > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 7:03 PM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > See my further comments in line. > > -----Original Message----- > From: Sam Cao [mailto:yuqun.cao@gmail.com] > Sent: Tuesday, May 15, 2012 6:14 PM > To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > Thank you very much for your comments. I draw the topology you gave, and 7 > PWs will be established if we follow 01. > > Root AC ---- PE 1 ----- PW 1 -------- PE 2 ----- Leaf _AC > | \ / || > | \ /===PW 6,7=== || > PW 2 -----PW 5------\ || > | /----Root PW 3 --- \ || > Root _AC ---- PE 3 PE 4 ------ Root AC > | \ / | > | ----Leaf PW 4----- | > Leaf AC Leaf AC > Yes, on PE 3 there are several PWs, but if you want to clarify it, there are > only 3 types, one can carry frames originated from Root and Leaf AC(one > endpoint of this PW should be Root-only, otherwise this is invalid), one > only can carry frames from Root AC, and the last can carry frames from Leaf > ACs. On second thoughts, we still can classify the PWs into 2 sets, one is > Leaf set, and another is Root set, and the union of the sets Leaf and Root > is the PW we called it as compatible PW (Maybe this is not correct, we can > find one good term on this). > > So this optimization still follows the original design of Dual-PW approach, > Leaf PW only carries frames from Leaf AC; Root-PW only carries frames from > Root AC. Is it right? > > I don't know whether chip can support this forwarding behavior for > compatible PW or not, but if we implement it in NP, it is nearly same as > VPLS. The only difference is, setup 2 mappings, one between Leaf-ACs and > Leaf-PWs, one between Root-ACs and Root-PWs. For traditional VPLS, there is > only one mapping. > > [JY] It seems you may need a 3rd mapping: from both root& leaf AC to a > compatible PW. > BTW, for the forwarding and reverse direction, the mapping may be asymmetric > for you compatible PW. > > Based on my understanding, all drafts should have similar mapping. > > [JY] Dual-VLAN seems simpler here. > > Thanks, > > Sam > > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 3:32 PM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Sam, > > Thanks, please see my further comments with [JY]. > > Ok, we go on the case in your mail, where PE1 has one Root-only AC, AC1, and > PE2 has one Leaf-only AC, AC2. In general we can setup 2 "unidirectional" > PWs (bidirectional PW, but just carry unidirectional frames), Root-PW which > carries frames originated from AC1 and Leaf-PW which carries frames > originated from AC2. But only one PW also can work, just as some members > commented. Ok, we setup one PW between PE1 and PE2, we can call this PW as > compatible PW or something else. Frames originated from Root or leaf ACs > will be carried via this PW. Its forwarding behavior is fully same as what > traditional VPLS did, MAC learning on AC or PW in one E-Tree. Or say, if one > PE has Root-only ACs, it will setup one PW with another PE, Root-only, > Leaf-only or Root-Leaf-Mixed. If 2 PEs are root-Leaf-Mixed or other cases, > then 2 PWs will be established. As you know, this can be done on control > plane. > > [JY] Assume there are 2 other nodes PE3& PE4 in this network scenario, and > both PE3 and PE4 have both root and leaf ACs, then there are compatible PWs > from PE3 which may carry both root and leaf traffic (to PE1), which may > carry only root traffic (to PE2); and further there are root PW and leaf PW > to PE4. Thus, the VSI on PE3 has at least 4 different types of PW > transmitting behaviours with regard to the E-Tree traffic. In the reverse > direction, the VSI on PE3 further has at least 4 different types of PW > receiving behaviours. Not sure how you will accommodate for these PWs in > both the data plane and control plane. > > Regards, > Yuanlong > > Is this clear for you? Is this necessary to optimize PW setup in this case? > > Maybe we need to add one paragraph on forwarding behavior. > > Again thank you very much for your comments, > > Sam > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 10:27 AM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Please see my comments in line. > > -----Original Message----- > From: Sam Cao [mailto:yuqun.cao@gmail.com] > Sent: Monday, May 14, 2012 8:31 PM > To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > We have discussed this in another thread. In fact, Daniel or I have given > the answers to the questions you raised here for several time :). If we do > in this way, we will reach deadlock and can not move forward :). I try to > explain it again. > > [JY] I will apologize if you had ever provided such answers before, and you > may just refer to the links rather than repeat the explanation. > As you can see, I just try to understand the mechanism of 2PW and its > implications, but the I-D does not include enough information. > > As you know, initial design we will setup 2 PWs all the time (if do in this > way, I think that you have no question), > > [JY] I will be concerned with the operational complexity of this approach. > > but in most cases 2 PWs are not > necessary. So in 01 version, we optimize it. > > "Root-only VSI<-> any VSI: only root PW required" > "Leaf-only VSI<-> leaf-only VSI: no PWs required" > > In other cases 2 PWs are needed. If so, "Leaf-only -> root-only = one leaf > PW" is not correct: On Leaf-only side, yes, one Leaf-only PW is created > between Local Leaf type with remote Root type; on root-only side, one > root-only PW is created. Maybe it is better to call this as compatible or > mixed PW. So the left items you list are not correct for multi_PW solution. > > [JY] This is something new, right? To be honest, I could not understand what > is your point: doesn't the mixed PW as you called also consist of one > Leaf-only PW in one direction and one root-only PW in the other direction? > Furthermore, the case you took is also one case in your guideline "Root-only > VSI<-> any VSI: only root PW required", don't you think that only one root > PW is required following this guideline? > Actually, I don't care much about what is the bidirectional PW or > unidirectional PW called, but how can a VSI support such a mixed scenarios: > traditional VSI assumes only one PW is required for each peer VSI, and its > MAC leaning is based on bidirectional PW. But for 2PW, there are > bidirectional root PW, bidirectional leaf PW, mixed PW, etc..., how to > support these kinds of PWs in the same VSI is my top concern. > > BTW, I guess you also care this case we also have discussed before: for > example, if we configure one Leaf AC on root-only PE (then it will be > root-leaf-mixed PE), we will teardown the compatible PW and re-setup PWs > again with 01. > [JY] This was discussed in the emails indeed. > > Regards, > > Yuqun (Sam) Cao > E-mail: Yuqun.cao@gmail.com > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Monday, May 14, 2012 7:10 PM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Daniel, > > Fine, now it seems more in line with what we had proposed in 2VLAN: a spoke > PW behaves like root/leaf AC for a PE-r. > > But the same problem may also apply to the root/spoke "core PW" for > Multi-PW: > According to Multi-PW, only one PW is required between two PEs except when > both PEs are mixed with root and leaf, so these PWs may be formed by > combinations of the following unidirectional PW cases (extracted and adapted > from Josh's email): > Root-only -> any VSI = one root PW > Leaf-only -> root-only = one leaf PW > Leaf-only -> mixed = one leaf PW > Mixed -> root-only = one (root+leaf) PW > Mixed -> leaf-only = one (root+leaf) PW > > I have a concern that the forwarding plane of PE to implement this will be > very different from the traditional VPLS. > > Regards, > Yuanlong > > -----Original Message----- > From: Daniel Cohn [mailto:DanielC@orckit.com] > Sent: Monday, May 14, 2012 5:00 PM > To: Jiangyuanlong; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > Like I wrote below, root/leaf spoke PW behave like root/leaf AC, not > like root/spoke "core PW". So no changes to forwarding plane once this > is understood. > > DC > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Monday, May 14, 2012 11:36 AM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Daniel, please see my comments in line. > > -----Original Message----- > From: Daniel Cohn [mailto:DanielC@orckit.com] > Sent: Monday, May 14, 2012 3:37 PM > To: Jiangyuanlong; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > As I see it, for the PE-r spoke (figure 4 in RFC 4762) we establish a > single PW per AC - root PW for root AC and leaf PW for leaf AC. With > local configuration at the PE-rs as part of the spoke PW provisioning. > And the PE-rs will treat root/leaf spoke PWs exactly as it treat > root/leaf ACs. So when leaf-originated BUM traffic arrives from the core > (over a leaf PW), it will be forwarded over all root spoke PWs but not > on the leaf spoke PWs. > > [JY] So in the reverse direction, you need to transport both root and > leaf traffic from PE-rs over a root PW to PE-r, and transport root > traffic over a leaf PW. It seems against the definition of root PW and > leaf PW in the multi-PW draft. Don't this make the forwarding plane of > PE-rs more complex? > > The forwarding plane is exactly the same as described in the multi-PW > draft, where spoke PWs are treated exactly like ACs. > > Regards, > > Daniel > > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Friday, May 11, 2012 5:03 AM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Daniel and all, > > When you set up two PWs from the PE-rs to a PE-r for each of its AC, do > you mean that one PW is bidirectional root PW and the other is > bidirectional leaf PW? > My concern is: where should the leaf traffic be filtered, on the PE-rs > or on the PE-r? > If filtered on the PE-r, then lots of bandwidth will be wasted (for > example, if the PE-r is attached with 9 leafs, then the BUM traffic from > one of its leafs will be multiplied by 8 times, and be forwarded by the > PE-rs to the same PE-r). > If filtered on the PE-rs, not sure how you will design its forwarding > plane, can you give a hint? > > Thanks, > Yuanlong > > ------------------------------ > Date: Wed, 9 May 2012 09:16:36 +0300 > From: "Daniel Cohn" > To: "Alexander Vainshtein", "Sam > Cao", > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > Message-ID:<44F4E579A764584EA9BDFD07D0CA08130780CBA6@tlvmail1> > Content-Type: text/plain; charset="ISO-2022-JP" > > Hi Sasha, > > It's actually very simple. A frame that originated in a root AC is > always transmitted only in root PW, no matter what the frame type > (known/unknown unicast or broadcast). This is how the frame source > information is propagated across the VPLS. So in the H-VPLS example, the > PE-r will never forward a frame received over a root PW on any leaf PW, > only on root PWs (toward the core or toward other spokes). > > Hope this clarifies it, regards, > > Daniel > > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Alexander Vainshtein > Sent: Wednesday, May 09, 2012 7:59 AM > To: Sam Cao; l2vpn@ietf.org > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > > Sam, Lizhong and all, > You've written that in the two-PW solution combined with H-VPLS the PE-r > must set up two PWs with each MTU-s. > > If this is the case, what kind of forwarding logic should be used to > prevent sending a BUM frame received from a root-PW to a given MTU-S: > - back to the same MTU-S on the corresponding leaf-PW? > - twice (to both root-PW and Leaf-PW) to another MTU-s? And, BTW, how is > the PW selected in this case? > > I am aware of a technique of multiple split horizon groups in PE-r which > could be possibly used for this purpose. However, since these groups > have to be represented explicitly in the data plane, their potential > number is limited by the forwarding HW. Other methods could be probably > used for the same purpose, but they would probably subject to similar > HW-based limitations. > > I suspect that with the dual-PW approach, the HW would pose an implicit > limit, say, on a number of MTU-s that can be connected to the same PE-r > and that this limit could be quite low in most cases. > > Based on this I suspect that the H-VPLS issue as a critical drawback of > the dual-PW approach to E-Tree. > > My 2c, > Sasha > > > ________________________________________ > From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Sam > Cao [yuqun.cao@gmail.com] > Sent: Wednesday, May 09, 2012 3:40 AM > To: l2vpn@ietf.org > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Lizhong? > > Thank you very much for your comments. I updated the result on this > question. > > [Lizhong] agree with the above analysis. And we did not say it is a > technical problem, but it is an operational problem again. > [Sam] I agree. Dual-VLAN does not make sense. I also discussed this with > Giles and Yuanlong in another mail, and we reached agreement on this: > MTU should know the access mode, VPWS or VPLS, VPWS mode should > configure VLAN ID on MTU but VPLS mode can not. I thought this is NOT > reasonable :), but we can figure this out in draft. It seems ok. > > [Lizhong] not fully understand. Do you mean, when VPWS accessing for > H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf > PW) for each AC access? > [Sam] Yes. > > Thanks, > > Sam > > > > > > -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From yuqun.cao@gmail.com Tue May 15 20:37: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 E716421F8686 for ; Tue, 15 May 2012 20:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.844 X-Spam-Level: X-Spam-Status: No, score=-2.844 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, J_CHICKENPOX_23=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 y-qffxyCjANt for ; Tue, 15 May 2012 20:37:41 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE4521F8674 for ; Tue, 15 May 2012 20:37:41 -0700 (PDT) Received: by dacx6 with SMTP id x6so377673dac.31 for ; Tue, 15 May 2012 20:37:41 -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=U+vx6ogsXwPr+JMG/F0WJ+SXxew/nNrfHWapH6nULbg=; b=AD28hhMpkybr3iI21Wnf42+nYsGqHz+dQyLejdi1R5O1EQKRNWnO/IRUBsj/2xa1Dd rtg5FVGjLbNcubGGDCd3ivGyYNORY+SmIkTo5qpv6QdsRJt+aw+weRwoJsQ/oPBSm9xN GAwIhiR71lvOdODHG1tRVUNEdCEkwughsppIsIVrKlBT3CQ/KtvSy5ed6PGwSwpwl111 YwsoINxPDeoS6zqcxsGDKsCz4w9HGBokofiaPpFKPHDlxb6VTxt+KaEsX9I5Bd1euNEj hIsereFUOE7ftDwoPEuF2M6C50ddAnW0PDi5xF4RSbEPZaAYel/cYCTDpppnW5kbdQh7 ZOGg== Received: by 10.68.242.67 with SMTP id wo3mr6339078pbc.91.1337139460951; Tue, 15 May 2012 20:37:40 -0700 (PDT) Received: from R01842 ([110.90.119.113]) by mx.google.com with ESMTPS id pd3sm3932938pbc.53.2012.05.15.20.37.34 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 May 2012 20:37:38 -0700 (PDT) From: "Sam Cao" To: "'Loa Andersson'" References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D411694@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF5C@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D4130E1@szxeml546-mbs.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF8F@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413216@szxeml546-mbs.china.huawei.com> <3F1F3739E2B04D399CC7D26CE934F91A@v2comsam> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413694@szxeml546-mbs.china.huawei.com> <7A564821DF1642E592E884D5C623772C@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D41370E@szxeml546-mbs.china.huawei.com> <400D5D93E6AA4075861CE09919D84747@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413741@szxeml546-mbs.china.huawei.com> <7BDA456234D045E1BD42EA059A4E9579@v2comsam> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D41392A@szxeml546-mbs.china.huawei.com> <4BDAB74EAC0C49FEAD65A9575DB2E159@R01842> <4FB317A8.6060104@pi.nu> Subject: RE: Discussion on forwarding performance Date: Wed, 16 May 2012 11:37:30 +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: <4FB317A8.6060104@pi.nu> Thread-index: Ac0zD6pmtb1wyb/aQ72V3Mw1Mz6Z2AAAuOoA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: l2vpn@ietf.org, 'Jiangyuanlong' 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, 16 May 2012 03:37:43 -0000 Loa, 1) This question comes from remaining issues list in past threads, raised by other members, and I can not find any agreement on this. 2) If the E-tree frames are fully forwarded via chip, we could forward at wire speed, so I also mentioned in that mail "If chipset can support this and we don't care NP or other solutions, yes, we can ignore any side effect on forwarding performance". But in some cases we can not forward at wire speed. Does my test result mislead me? Loa, can you get forwarding parameters from some Router's datasheet? Thank you very much for your comments, Sam -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu] Sent: Wednesday, May 16, 2012 10:58 AM To: Sam Cao Cc: 'Jiangyuanlong'; 'Daniel Cohn'; 'Alexander Vainshtein'; l2vpn@ietf.org Subject: Re: Discussion on forwarding performance Folks, an innocent question since I it is a long time since I worked with forwarding performance, I lost most of the interest when it was clear that whichever we used we could forward at wire speed. There has been other discussions around how many label look up certain hw can handle, but I thought we were past this point also. Would one extra label cause us to drop below wire speed in forwarding performance? Is this mostly a implementation complexity issue? /Loa On 2012-05-16 04:49, Sam Cao wrote: > Yes, Yuanlong. We have discussed this before, but I can not get clear > conclusion till now. From that linkage I also can not find it. > > Compared to traditional VPLS, forwarding performance of all solutions will > be decreased. If chip can fully support the solutions and we ignore other > non-chip solution, we can ignore forwarding performance. But can we ignore > it? > > I found your patent application on this, and think that we need to re-design > VLAN Bridge you mentioned. VLAN Bridge can not support this inherently :). > > BTW, Yuanlong, is there any experimental data on forwarding performance? > > Thanks, > > Sam > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Wednesday, May 16, 2012 10:17 AM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on forwarding performance > > 3rd mapping will make data plane complex, I think. Anyway, we reached a > consensus on Multi-PW implementation. > > If we use 3rd mapping, I agree with your opinion, maybe dual-VLAN seems > simple, but 2 mapping is enough. > > [JY] Can't see how 2 mapping is enough for 2PW, do you mean to use 2 PWs for > all the peer PEs? > > Then we can focus on data plane > performance. While stripe PW label out on egress PE, data-plane knows how to > forward the frames from PW, to Root AC or Leaf AC or all. But if we use > Dual-VLAN, after strip PW label out, data plane should strip VLAN-ID out and > then does same forwarding work as Multi-PW does. > > [JY] We are running into the same cycle: forward implications for 2PW was > already covered in > http://www.ietf.org/mail-archive/web/l2vpn/current/msg03513.html, no need to > repeat it here. > > The most important is, do > one more operation while forwarding E-Tree frames. Obviously the forwarding > performance of Dual-VLAN will be much lower than what of Multi-PW. > > [JY] VLAN operation is generally available in VPLS already, does this > statement also mean Multi-PW will have a much higher performance even > compared with VPLS itself? > > Regards, > > Yuqun (Sam) Cao > E-mail: Yuqun.cao@gmail.com > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 7:03 PM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > See my further comments in line. > > -----Original Message----- > From: Sam Cao [mailto:yuqun.cao@gmail.com] > Sent: Tuesday, May 15, 2012 6:14 PM > To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > Thank you very much for your comments. I draw the topology you gave, and 7 > PWs will be established if we follow 01. > > Root AC ---- PE 1 ----- PW 1 -------- PE 2 ----- Leaf _AC > | \ / || > | \ /===PW 6,7=== || > PW 2 -----PW 5------\ || > | /----Root PW 3 --- \ || > Root _AC ---- PE 3 PE 4 ------ Root AC > | \ / | > | ----Leaf PW 4----- | > Leaf AC Leaf AC > Yes, on PE 3 there are several PWs, but if you want to clarify it, there are > only 3 types, one can carry frames originated from Root and Leaf AC(one > endpoint of this PW should be Root-only, otherwise this is invalid), one > only can carry frames from Root AC, and the last can carry frames from Leaf > ACs. On second thoughts, we still can classify the PWs into 2 sets, one is > Leaf set, and another is Root set, and the union of the sets Leaf and Root > is the PW we called it as compatible PW (Maybe this is not correct, we can > find one good term on this). > > So this optimization still follows the original design of Dual-PW approach, > Leaf PW only carries frames from Leaf AC; Root-PW only carries frames from > Root AC. Is it right? > > I don't know whether chip can support this forwarding behavior for > compatible PW or not, but if we implement it in NP, it is nearly same as > VPLS. The only difference is, setup 2 mappings, one between Leaf-ACs and > Leaf-PWs, one between Root-ACs and Root-PWs. For traditional VPLS, there is > only one mapping. > > [JY] It seems you may need a 3rd mapping: from both root& leaf AC to a > compatible PW. > BTW, for the forwarding and reverse direction, the mapping may be asymmetric > for you compatible PW. > > Based on my understanding, all drafts should have similar mapping. > > [JY] Dual-VLAN seems simpler here. > > Thanks, > > Sam > > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 3:32 PM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Sam, > > Thanks, please see my further comments with [JY]. > > Ok, we go on the case in your mail, where PE1 has one Root-only AC, AC1, and > PE2 has one Leaf-only AC, AC2. In general we can setup 2 "unidirectional" > PWs (bidirectional PW, but just carry unidirectional frames), Root-PW which > carries frames originated from AC1 and Leaf-PW which carries frames > originated from AC2. But only one PW also can work, just as some members > commented. Ok, we setup one PW between PE1 and PE2, we can call this PW as > compatible PW or something else. Frames originated from Root or leaf ACs > will be carried via this PW. Its forwarding behavior is fully same as what > traditional VPLS did, MAC learning on AC or PW in one E-Tree. Or say, if one > PE has Root-only ACs, it will setup one PW with another PE, Root-only, > Leaf-only or Root-Leaf-Mixed. If 2 PEs are root-Leaf-Mixed or other cases, > then 2 PWs will be established. As you know, this can be done on control > plane. > > [JY] Assume there are 2 other nodes PE3& PE4 in this network scenario, and > both PE3 and PE4 have both root and leaf ACs, then there are compatible PWs > from PE3 which may carry both root and leaf traffic (to PE1), which may > carry only root traffic (to PE2); and further there are root PW and leaf PW > to PE4. Thus, the VSI on PE3 has at least 4 different types of PW > transmitting behaviours with regard to the E-Tree traffic. In the reverse > direction, the VSI on PE3 further has at least 4 different types of PW > receiving behaviours. Not sure how you will accommodate for these PWs in > both the data plane and control plane. > > Regards, > Yuanlong > > Is this clear for you? Is this necessary to optimize PW setup in this case? > > Maybe we need to add one paragraph on forwarding behavior. > > Again thank you very much for your comments, > > Sam > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 10:27 AM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Please see my comments in line. > > -----Original Message----- > From: Sam Cao [mailto:yuqun.cao@gmail.com] > Sent: Monday, May 14, 2012 8:31 PM > To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > We have discussed this in another thread. In fact, Daniel or I have given > the answers to the questions you raised here for several time :). If we do > in this way, we will reach deadlock and can not move forward :). I try to > explain it again. > > [JY] I will apologize if you had ever provided such answers before, and you > may just refer to the links rather than repeat the explanation. > As you can see, I just try to understand the mechanism of 2PW and its > implications, but the I-D does not include enough information. > > As you know, initial design we will setup 2 PWs all the time (if do in this > way, I think that you have no question), > > [JY] I will be concerned with the operational complexity of this approach. > > but in most cases 2 PWs are not > necessary. So in 01 version, we optimize it. > > "Root-only VSI<-> any VSI: only root PW required" > "Leaf-only VSI<-> leaf-only VSI: no PWs required" > > In other cases 2 PWs are needed. If so, "Leaf-only -> root-only = one leaf > PW" is not correct: On Leaf-only side, yes, one Leaf-only PW is created > between Local Leaf type with remote Root type; on root-only side, one > root-only PW is created. Maybe it is better to call this as compatible or > mixed PW. So the left items you list are not correct for multi_PW solution. > > [JY] This is something new, right? To be honest, I could not understand what > is your point: doesn't the mixed PW as you called also consist of one > Leaf-only PW in one direction and one root-only PW in the other direction? > Furthermore, the case you took is also one case in your guideline "Root-only > VSI<-> any VSI: only root PW required", don't you think that only one root > PW is required following this guideline? > Actually, I don't care much about what is the bidirectional PW or > unidirectional PW called, but how can a VSI support such a mixed scenarios: > traditional VSI assumes only one PW is required for each peer VSI, and its > MAC leaning is based on bidirectional PW. But for 2PW, there are > bidirectional root PW, bidirectional leaf PW, mixed PW, etc..., how to > support these kinds of PWs in the same VSI is my top concern. > > BTW, I guess you also care this case we also have discussed before: for > example, if we configure one Leaf AC on root-only PE (then it will be > root-leaf-mixed PE), we will teardown the compatible PW and re-setup PWs > again with 01. > [JY] This was discussed in the emails indeed. > > Regards, > > Yuqun (Sam) Cao > E-mail: Yuqun.cao@gmail.com > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Monday, May 14, 2012 7:10 PM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Daniel, > > Fine, now it seems more in line with what we had proposed in 2VLAN: a spoke > PW behaves like root/leaf AC for a PE-r. > > But the same problem may also apply to the root/spoke "core PW" for > Multi-PW: > According to Multi-PW, only one PW is required between two PEs except when > both PEs are mixed with root and leaf, so these PWs may be formed by > combinations of the following unidirectional PW cases (extracted and adapted > from Josh's email): > Root-only -> any VSI = one root PW > Leaf-only -> root-only = one leaf PW > Leaf-only -> mixed = one leaf PW > Mixed -> root-only = one (root+leaf) PW > Mixed -> leaf-only = one (root+leaf) PW > > I have a concern that the forwarding plane of PE to implement this will be > very different from the traditional VPLS. > > Regards, > Yuanlong > > -----Original Message----- > From: Daniel Cohn [mailto:DanielC@orckit.com] > Sent: Monday, May 14, 2012 5:00 PM > To: Jiangyuanlong; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > Like I wrote below, root/leaf spoke PW behave like root/leaf AC, not > like root/spoke "core PW". So no changes to forwarding plane once this > is understood. > > DC > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Monday, May 14, 2012 11:36 AM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Daniel, please see my comments in line. > > -----Original Message----- > From: Daniel Cohn [mailto:DanielC@orckit.com] > Sent: Monday, May 14, 2012 3:37 PM > To: Jiangyuanlong; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > As I see it, for the PE-r spoke (figure 4 in RFC 4762) we establish a > single PW per AC - root PW for root AC and leaf PW for leaf AC. With > local configuration at the PE-rs as part of the spoke PW provisioning. > And the PE-rs will treat root/leaf spoke PWs exactly as it treat > root/leaf ACs. So when leaf-originated BUM traffic arrives from the core > (over a leaf PW), it will be forwarded over all root spoke PWs but not > on the leaf spoke PWs. > > [JY] So in the reverse direction, you need to transport both root and > leaf traffic from PE-rs over a root PW to PE-r, and transport root > traffic over a leaf PW. It seems against the definition of root PW and > leaf PW in the multi-PW draft. Don't this make the forwarding plane of > PE-rs more complex? > > The forwarding plane is exactly the same as described in the multi-PW > draft, where spoke PWs are treated exactly like ACs. > > Regards, > > Daniel > > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Friday, May 11, 2012 5:03 AM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Daniel and all, > > When you set up two PWs from the PE-rs to a PE-r for each of its AC, do > you mean that one PW is bidirectional root PW and the other is > bidirectional leaf PW? > My concern is: where should the leaf traffic be filtered, on the PE-rs > or on the PE-r? > If filtered on the PE-r, then lots of bandwidth will be wasted (for > example, if the PE-r is attached with 9 leafs, then the BUM traffic from > one of its leafs will be multiplied by 8 times, and be forwarded by the > PE-rs to the same PE-r). > If filtered on the PE-rs, not sure how you will design its forwarding > plane, can you give a hint? > > Thanks, > Yuanlong > > ------------------------------ > Date: Wed, 9 May 2012 09:16:36 +0300 > From: "Daniel Cohn" > To: "Alexander Vainshtein", "Sam > Cao", > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > Message-ID:<44F4E579A764584EA9BDFD07D0CA08130780CBA6@tlvmail1> > Content-Type: text/plain; charset="ISO-2022-JP" > > Hi Sasha, > > It's actually very simple. A frame that originated in a root AC is > always transmitted only in root PW, no matter what the frame type > (known/unknown unicast or broadcast). This is how the frame source > information is propagated across the VPLS. So in the H-VPLS example, the > PE-r will never forward a frame received over a root PW on any leaf PW, > only on root PWs (toward the core or toward other spokes). > > Hope this clarifies it, regards, > > Daniel > > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Alexander Vainshtein > Sent: Wednesday, May 09, 2012 7:59 AM > To: Sam Cao; l2vpn@ietf.org > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > > Sam, Lizhong and all, > You've written that in the two-PW solution combined with H-VPLS the PE-r > must set up two PWs with each MTU-s. > > If this is the case, what kind of forwarding logic should be used to > prevent sending a BUM frame received from a root-PW to a given MTU-S: > - back to the same MTU-S on the corresponding leaf-PW? > - twice (to both root-PW and Leaf-PW) to another MTU-s? And, BTW, how is > the PW selected in this case? > > I am aware of a technique of multiple split horizon groups in PE-r which > could be possibly used for this purpose. However, since these groups > have to be represented explicitly in the data plane, their potential > number is limited by the forwarding HW. Other methods could be probably > used for the same purpose, but they would probably subject to similar > HW-based limitations. > > I suspect that with the dual-PW approach, the HW would pose an implicit > limit, say, on a number of MTU-s that can be connected to the same PE-r > and that this limit could be quite low in most cases. > > Based on this I suspect that the H-VPLS issue as a critical drawback of > the dual-PW approach to E-Tree. > > My 2c, > Sasha > > > ________________________________________ > From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Sam > Cao [yuqun.cao@gmail.com] > Sent: Wednesday, May 09, 2012 3:40 AM > To: l2vpn@ietf.org > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Lizhong? > > Thank you very much for your comments. I updated the result on this > question. > > [Lizhong] agree with the above analysis. And we did not say it is a > technical problem, but it is an operational problem again. > [Sam] I agree. Dual-VLAN does not make sense. I also discussed this with > Giles and Yuanlong in another mail, and we reached agreement on this: > MTU should know the access mode, VPWS or VPLS, VPWS mode should > configure VLAN ID on MTU but VPLS mode can not. I thought this is NOT > reasonable :), but we can figure this out in draft. It seems ok. > > [Lizhong] not fully understand. Do you mean, when VPWS accessing for > H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf > PW) for each AC access? > [Sam] Yes. > > Thanks, > > Sam > > > > > > -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From jiangyuanlong@huawei.com Tue May 15 21:02: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 065AC21F8540 for ; Tue, 15 May 2012 21:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.143 X-Spam-Level: X-Spam-Status: No, score=-4.143 tagged_above=-999 required=5 tests=[AWL=1.856, BAYES_00=-2.599, J_CHICKENPOX_23=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 qW9Yw+BTojGR for ; Tue, 15 May 2012 21:02:41 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 44B7D21F853F for ; Tue, 15 May 2012 21:02:41 -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 AGF65123; Wed, 16 May 2012 00:02:41 -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; Tue, 15 May 2012 20:59:27 -0700 Received: from SZXEML430-HUB.china.huawei.com (10.72.61.38) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 15 May 2012 20:59:30 -0700 Received: from SZXEML546-MBS.china.huawei.com ([169.254.4.75]) by szxeml430-hub.china.huawei.com ([10.72.61.38]) with mapi id 14.01.0323.003; Wed, 16 May 2012 11:59:25 +0800 From: Jiangyuanlong To: Sam Cao , 'Daniel Cohn' , 'Alexander Vainshtein' Subject: RE: Discussion on forwarding performance Thread-Topic: Discussion on forwarding performance Thread-Index: AQHNMp8ego9/CtMoakapN2JoMtGUPZbLpm1ggAAMumCAAAVoUA== Date: Wed, 16 May 2012 03:59:24 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413A10@szxeml546-mbs.china.huawei.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D411694@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF5C@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D4130E1@szxeml546-mbs.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF8F@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413216@szxeml546-mbs.china.huawei.com> <3F1F3739E2B04D399CC7D26CE934F91A@v2comsam> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413694@szxeml546-mbs.china.huawei.com> <7A564821DF1642E592E884D5C623772C@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D41370E@szxeml546-mbs.china.huawei.com> <400D5D93E6AA4075861CE09919D84747@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413741@szxeml546-mbs.china.huawei.com> <7BDA456234D045E1BD42EA059A4E9579@v2comsam> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D41392A@szxeml546-mbs.china.huawei.com> <4BDAB74EAC0C49FEAD65A9575DB2E159@R01842> In-Reply-To: <4BDAB74EAC0C49FEAD65A9575DB2E159@R01842> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.40.73] 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, 16 May 2012 04:02:43 -0000 See in line. -----Original Message----- From: Sam Cao [mailto:yuqun.cao@gmail.com]=20 Sent: Wednesday, May 16, 2012 10:50 AM To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance Yes, Yuanlong. We have discussed this before, but I can not get clear conclusion till now. From that linkage I also can not find it. [JY] the linkage analyzed the implications of Multi-PW in forwarding, it is= not so simple as "data-plane knows how to forward the frames from PW, to Root AC or Leaf AC or all."=20 Compared to traditional VPLS, forwarding performance of all solutions will be decreased. If chip can fully support the solutions and we ignore other non-chip solution, we can ignore forwarding performance. But can we ignore it? [JY] no, we will not ignore them. But there is no evidence that it is much = different in performance comparison. I found your patent application on this, and think that we need to re-desig= n VLAN Bridge you mentioned. VLAN Bridge can not support this inherently :). [JY] VLAN bridge with E-Tree support is standardized in IEEE already.=20 BTW, Yuanlong, is there any experimental data on forwarding performance? [JY] please see the off the shelf PE routers with the same support of VLAN = operations just as described in RFC 6246. Thanks, Sam -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Wednesday, May 16, 2012 10:17 AM To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance 3rd mapping will make data plane complex, I think. Anyway, we reached a consensus on Multi-PW implementation.=20 If we use 3rd mapping, I agree with your opinion, maybe dual-VLAN seems simple, but 2 mapping is enough.=20 [JY] Can't see how 2 mapping is enough for 2PW, do you mean to use 2 PWs fo= r all the peer PEs? Then we can focus on data plane performance. While stripe PW label out on egress PE, data-plane knows how t= o forward the frames from PW, to Root AC or Leaf AC or all. But if we use Dual-VLAN, after strip PW label out, data plane should strip VLAN-ID out an= d then does same forwarding work as Multi-PW does.=20 [JY] We are running into the same cycle: forward implications for 2PW was already covered in http://www.ietf.org/mail-archive/web/l2vpn/current/msg03513.html, no need t= o repeat it here. The most important is, do one more operation while forwarding E-Tree frames. Obviously the forwarding performance of Dual-VLAN will be much lower than what of Multi-PW. [JY] VLAN operation is generally available in VPLS already, does this statement also mean Multi-PW will have a much higher performance even compared with VPLS itself? Regards, =20 Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com=20 =20 -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Tuesday, May 15, 2012 7:03 PM To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS See my further comments in line. -----Original Message----- From: Sam Cao [mailto:yuqun.cao@gmail.com]=20 Sent: Tuesday, May 15, 2012 6:14 PM To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Yuanlong, Thank you very much for your comments. I draw the topology you gave, and 7 PWs will be established if we follow 01. Root AC ---- PE 1 ----- PW 1 -------- PE 2 ----- Leaf _AC | \ / || | \ /=3D=3D=3DPW 6,7=3D=3D=3D || PW 2 -----PW 5------\ || | /----Root PW 3 --- \ || Root _AC ---- PE 3 PE 4 ------ Root AC | \ / | | ----Leaf PW 4----- |=20 Leaf AC Leaf AC Yes, on PE 3 there are several PWs, but if you want to clarify it, there ar= e only 3 types, one can carry frames originated from Root and Leaf AC(one endpoint of this PW should be Root-only, otherwise this is invalid), one only can carry frames from Root AC, and the last can carry frames from Leaf ACs. On second thoughts, we still can classify the PWs into 2 sets, one is Leaf set, and another is Root set, and the union of the sets Leaf and Root is the PW we called it as compatible PW (Maybe this is not correct, we can find one good term on this).=20 So this optimization still follows the original design of Dual-PW approach, Leaf PW only carries frames from Leaf AC; Root-PW only carries frames from Root AC. Is it right? I don't know whether chip can support this forwarding behavior for compatible PW or not, but if we implement it in NP, it is nearly same as VPLS. The only difference is, setup 2 mappings, one between Leaf-ACs and Leaf-PWs, one between Root-ACs and Root-PWs. For traditional VPLS, there is only one mapping.=20 [JY] It seems you may need a 3rd mapping: from both root & leaf AC to a compatible PW. BTW, for the forwarding and reverse direction, the mapping may be asymmetri= c for you compatible PW. Based on my understanding, all drafts should have similar mapping.=20 [JY] Dual-VLAN seems simpler here. Thanks, Sam -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Tuesday, May 15, 2012 3:32 PM To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Sam, Thanks, please see my further comments with [JY]. Ok, we go on the case in your mail, where PE1 has one Root-only AC, AC1, an= d PE2 has one Leaf-only AC, AC2. In general we can setup 2 "unidirectional" PWs (bidirectional PW, but just carry unidirectional frames), Root-PW which carries frames originated from AC1 and Leaf-PW which carries frames originated from AC2. But only one PW also can work, just as some members commented. Ok, we setup one PW between PE1 and PE2, we can call this PW as compatible PW or something else. Frames originated from Root or leaf ACs will be carried via this PW. Its forwarding behavior is fully same as what traditional VPLS did, MAC learning on AC or PW in one E-Tree. Or say, if on= e PE has Root-only ACs, it will setup one PW with another PE, Root-only, Leaf-only or Root-Leaf-Mixed. If 2 PEs are root-Leaf-Mixed or other cases, then 2 PWs will be established. As you know, this can be done on control plane.=20 [JY] Assume there are 2 other nodes PE3 & PE4 in this network scenario, and both PE3 and PE4 have both root and leaf ACs, then there are compatible PWs from PE3 which may carry both root and leaf traffic (to PE1), which may carry only root traffic (to PE2); and further there are root PW and leaf PW to PE4. Thus, the VSI on PE3 has at least 4 different types of PW transmitting behaviours with regard to the E-Tree traffic. In the reverse direction, the VSI on PE3 further has at least 4 different types of PW receiving behaviours. Not sure how you will accommodate for these PWs in both the data plane and control plane. Regards, Yuanlong Is this clear for you? Is this necessary to optimize PW setup in this case?= =20 Maybe we need to add one paragraph on forwarding behavior.=20 Again thank you very much for your comments, Sam -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Tuesday, May 15, 2012 10:27 AM To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Please see my comments in line. -----Original Message----- From: Sam Cao [mailto:yuqun.cao@gmail.com]=20 Sent: Monday, May 14, 2012 8:31 PM To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Yuanlong, We have discussed this in another thread. In fact, Daniel or I have given the answers to the questions you raised here for several time :). If we do in this way, we will reach deadlock and can not move forward :). I try to explain it again. [JY] I will apologize if you had ever provided such answers before, and you may just refer to the links rather than repeat the explanation. As you can see, I just try to understand the mechanism of 2PW and its implications, but the I-D does not include enough information. As you know, initial design we will setup 2 PWs all the time (if do in this way, I think that you have no question),=20 [JY] I will be concerned with the operational complexity of this approach. but in most cases 2 PWs are not necessary. So in 01 version, we optimize it. "Root-only VSI <-> any VSI: only root PW required" "Leaf-only VSI <-> leaf-only VSI: no PWs required" In other cases 2 PWs are needed. If so, "Leaf-only -> root-only =3D one lea= f PW" is not correct: On Leaf-only side, yes, one Leaf-only PW is created between Local Leaf type with remote Root type; on root-only side, one root-only PW is created. Maybe it is better to call this as compatible or mixed PW. So the left items you list are not correct for multi_PW solution. [JY] This is something new, right? To be honest, I could not understand wha= t is your point: doesn't the mixed PW as you called also consist of one Leaf-only PW in one direction and one root-only PW in the other direction? Furthermore, the case you took is also one case in your guideline "Root-onl= y VSI <-> any VSI: only root PW required", don't you think that only one root PW is required following this guideline? Actually, I don't care much about what is the bidirectional PW or unidirectional PW called, but how can a VSI support such a mixed scenarios: traditional VSI assumes only one PW is required for each peer VSI, and its MAC leaning is based on bidirectional PW. But for 2PW, there are bidirectional root PW, bidirectional leaf PW, mixed PW, etc..., how to support these kinds of PWs in the same VSI is my top concern. BTW, I guess you also care this case we also have discussed before: for example, if we configure one Leaf AC on root-only PE (then it will be root-leaf-mixed PE), we will teardown the compatible PW and re-setup PWs again with 01.=20 [JY] This was discussed in the emails indeed. Regards, =20 Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com=20 =20 -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Monday, May 14, 2012 7:10 PM To: Daniel Cohn; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Daniel, Fine, now it seems more in line with what we had proposed in 2VLAN: a spoke PW behaves like root/leaf AC for a PE-r. But the same problem may also apply to the root/spoke "core PW" for Multi-PW: According to Multi-PW, only one PW is required between two PEs except when both PEs are mixed with root and leaf, so these PWs may be formed by combinations of the following unidirectional PW cases (extracted and adapte= d from Josh's email): Root-only -> any VSI =3D one root PW Leaf-only -> root-only =3D one leaf PW Leaf-only -> mixed =3D one leaf PW=20 Mixed -> root-only =3D one (root+leaf) PW =20 Mixed -> leaf-only =3D one (root+leaf) PW =20 I have a concern that the forwarding plane of PE to implement this will be very different from the traditional VPLS. Regards, Yuanlong -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Monday, May 14, 2012 5:00 PM To: Jiangyuanlong; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Yuanlong, Like I wrote below, root/leaf spoke PW behave like root/leaf AC, not like root/spoke "core PW". So no changes to forwarding plane once this is understood. DC -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Monday, May 14, 2012 11:36 AM To: Daniel Cohn; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Daniel, please see my comments in line. -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Monday, May 14, 2012 3:37 PM To: Jiangyuanlong; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Yuanlong, As I see it, for the PE-r spoke (figure 4 in RFC 4762) we establish a single PW per AC - root PW for root AC and leaf PW for leaf AC. With local configuration at the PE-rs as part of the spoke PW provisioning. And the PE-rs will treat root/leaf spoke PWs exactly as it treat root/leaf ACs. So when leaf-originated BUM traffic arrives from the core (over a leaf PW), it will be forwarded over all root spoke PWs but not on the leaf spoke PWs.=20 [JY] So in the reverse direction, you need to transport both root and leaf traffic from PE-rs over a root PW to PE-r, and transport root traffic over a leaf PW. It seems against the definition of root PW and leaf PW in the multi-PW draft. Don't this make the forwarding plane of PE-rs more complex?=20 The forwarding plane is exactly the same as described in the multi-PW draft, where spoke PWs are treated exactly like ACs. Regards, Daniel -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Friday, May 11, 2012 5:03 AM To: Daniel Cohn; Alexander Vainshtein; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Hi Daniel and all, When you set up two PWs from the PE-rs to a PE-r for each of its AC, do you mean that one PW is bidirectional root PW and the other is bidirectional leaf PW? My concern is: where should the leaf traffic be filtered, on the PE-rs or on the PE-r? If filtered on the PE-r, then lots of bandwidth will be wasted (for example, if the PE-r is attached with 9 leafs, then the BUM traffic from one of its leafs will be multiplied by 8 times, and be forwarded by the PE-rs to the same PE-r). If filtered on the PE-rs, not sure how you will design its forwarding plane, can you give a hint? Thanks, Yuanlong ------------------------------ Date: Wed, 9 May 2012 09:16:36 +0300 From: "Daniel Cohn" To: "Alexander Vainshtein" , "Sam Cao" , Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780CBA6@tlvmail1> Content-Type: text/plain; charset=3D"ISO-2022-JP" Hi Sasha, It's actually very simple. A frame that originated in a root AC is always transmitted only in root PW, no matter what the frame type (known/unknown unicast or broadcast). This is how the frame source information is propagated across the VPLS. So in the H-VPLS example, the PE-r will never forward a frame received over a root PW on any leaf PW, only on root PWs (toward the core or toward other spokes). Hope this clarifies it, regards, Daniel -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Alexander Vainshtein Sent: Wednesday, May 09, 2012 7:59 AM To: Sam Cao; l2vpn@ietf.org Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Sam, Lizhong and all, You've written that in the two-PW solution combined with H-VPLS the PE-r must set up two PWs with each MTU-s. If this is the case, what kind of forwarding logic should be used to prevent sending a BUM frame received from a root-PW to a given MTU-S: - back to the same MTU-S on the corresponding leaf-PW? - twice (to both root-PW and Leaf-PW) to another MTU-s? And, BTW, how is the PW selected in this case? I am aware of a technique of multiple split horizon groups in PE-r which could be possibly used for this purpose. However, since these groups have to be represented explicitly in the data plane, their potential number is limited by the forwarding HW. Other methods could be probably used for the same purpose, but they would probably subject to similar HW-based limitations. I suspect that with the dual-PW approach, the HW would pose an implicit limit, say, on a number of MTU-s that can be connected to the same PE-r and that this limit could be quite low in most cases. Based on this I suspect that the H-VPLS issue as a critical drawback of the dual-PW approach to E-Tree. My 2c, Sasha ________________________________________ From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Sam Cao [yuqun.cao@gmail.com] Sent: Wednesday, May 09, 2012 3:40 AM To: l2vpn@ietf.org Cc: lizhong.jin@zte.com.cn Subject: RE: Discussion on E-Tree and H-VPLS Hi Lizhong? Thank you very much for your comments. I updated the result on this question. [Lizhong] agree with the above analysis. And we did not say it is a technical problem, but it is an operational problem again. [Sam] I agree. Dual-VLAN does not make sense. I also discussed this with Giles and Yuanlong in another mail, and we reached agreement on this: MTU should know the access mode, VPWS or VPLS, VPWS mode should configure VLAN ID on MTU but VPLS mode can not. I thought this is NOT reasonable :), but we can figure this out in draft. It seems ok. [Lizhong] not fully understand. Do you mean, when VPWS accessing for H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf PW) for each AC access? [Sam] Yes. Thanks, Sam =20 From yuqun.cao@gmail.com Tue May 15 21:06: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 7C36011E80B8 for ; Tue, 15 May 2012 21:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.85 X-Spam-Level: X-Spam-Status: No, score=-2.85 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, J_CHICKENPOX_23=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 poCIvtO7TxbF for ; Tue, 15 May 2012 21:06:32 -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 C66F121F864E for ; Tue, 15 May 2012 21:06:32 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so521465pbc.31 for ; Tue, 15 May 2012 21:06: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=9DXUEApqCfN14au2/2sW8u2ldt65daNq18cpXBOYtyw=; b=Muv97HIbd/KFxm+1gKnYfPcIdkQznFoIPJBvetNXXqZGtQ7ep8P1y+ZXGJJQV82nup 5MEdhNbJbeYlY1W0REgCE79H9b4N1VpCYazpXqNOFp53hFqVi7vU3T+MNSeef7iBGdra F2xJe3w26xWEhyhAPWJO9VUGC1csUiMYT5y4yx+zofLEwJXF4l4ael4kbvOf7vwnCJjQ uZzhyAiG7+1ZnqNd8cfAqSejxec/Zsz/QL8unQ600KmFTNHu9HoluFfpnQI8LlE4XCfB dN+ekgs4sB7rLzYnxf2r9joOY42mc8XiLRFXlKuuvyyR+fSTRhqxdgAdFKGwIYovKm2W trRQ== Received: by 10.68.242.2 with SMTP id wm2mr12227414pbc.125.1337141192417; Tue, 15 May 2012 21:06:32 -0700 (PDT) Received: from R01842 ([110.90.119.113]) by mx.google.com with ESMTPS id d6sm4021444pbi.23.2012.05.15.21.06.26 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 May 2012 21:06:31 -0700 (PDT) From: "Sam Cao" To: "'Jiangyuanlong'" , "'Lucy yong'" , "'David Allan I'" , "'Balus, Florin Stelian \(Florin\)'" , "'Daniel Cohn'" , "'Alexander Vainshtein'" References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D411694@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF5C@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D4130E1@szxeml546-mbs.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF8F@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413216@szxeml546-mbs.china.huawei.com> <3F1F3739E2B04D399CC7D26CE934F91A@v2comsam> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413694@szxeml546-mbs.china.huawei.com> <7A564821DF1642E592E884D5C623772C@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D41370E@szxeml546-mbs.china.huawei.com> <400D5D93E6AA4075861CE09919D84747@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413741@szxeml546-mbs.china.huawei.com> <7BDA456234D045E1BD42EA059A4E9579@v2comsam> <2073A6C5467C99478898544C6EBA3F4602C1907568@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> <60C093A41B5E45409A19D42CF7786DFD52328D98DF@EUSAACMS0703.eamcs.ericsson.se> <1A7E043E03FF48A2B3E5ECCD4F124B4C@R01842> <3B0A1BED22 CAD649A1B3E97BE5DDD6 8B1D41394A@szxeml546-mbs.china.huawei.com> Subject: RE: Discussion on forwarding performance Date: Wed, 16 May 2012 12:06:21 +0800 Message-ID: <7F31E97F973E4F339E0DF43D08C2EBF9@R01842> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D41394A@szxeml546-mbs.china.huawei.com> Thread-index: AQHNMp8ego9/CtMoakapN2JoMtGUPZbKvTGAgAAAzYCAAAV4AIAAYvAAgACKNECAABTmwA== 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: Wed, 16 May 2012 04:06:34 -0000 Yuanlong, I have no NP implementation either for Dual-VLAN or Multi-PW since there is no resource on this :). This is just my guess on software side, not accurate data. I shared my tester experience data on IP frame forwarding with VPLS frame forwarding. In back-to-back topology: VPLS frame forwarding performance is about 80% of IP frame forwarding performance. Yuanlong, I think you also have such data since you have experience on NP and developers should care this. Again, if work on chip, we can ignore site effect on forwarding performance. Maybe we can improve software architecture, but I guess there is a little side effect on Multi-PW, but more on Dual-VLAN. Yuanlong, Is there any authoritative data on this? Anyway, if we need, I want to ask some co-workers to get the forwarding difference between IP forwarding and VPLS forwarding on some vendor's routers, but it needs a little time and human resource^_^. Sam -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] Sent: Wednesday, May 16, 2012 10:46 AM To: Sam Cao; Lucy yong; 'David Allan I'; 'Balus, Florin Stelian (Florin)'; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance See my comments in line. -----Original Message----- From: Sam Cao [mailto:yuqun.cao@gmail.com] Sent: Wednesday, May 16, 2012 10:09 AM To: Lucy yong; 'David Allan I'; 'Balus, Florin Stelian (Florin)'; Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance Lucy/David/Florin, Thank you very much for your comments. I can not give the accurate data to support my conclusion, and just conclude that if we implement it in NP module. Except for common operations of 2 approaches, Tunnel Label push/pop-out, MAC-based forwarding, and etc., Dual-VLAN needs one more VLAN push/pop-out operation while forwarding every frame. So compared with Multi-PW, it needs more resource and time for NP module if there are VSIs or PWs up limit to the capacity on one PE, and standing on software architect's side, the performance will be decreased by at least 20%, I guess. I implemented one prototype which has similar solution as current Multi-PW, and the performance will be decreased by 5%, compared with traditional VPLS. Daniel has experience on 2-PW deployment, maybe he can give accurate data on Multi-PW. [JY] So you have no NP implementation either for Dual-VLAN or Multi-PW... but why do you think the performance will be decreased by at least 20%? I also have some experiences in NP programming, it must be a big surprise that one more VLAN push/pop-out operation will incur a penalty of performance degradation of 20%. Florin, do you mean that you have implemented E-Tree in MPLS network? If chipset can support this and we don't care NP or other solutions, yes, we can ignore any side effect on forwarding performance. Yes, it can support E-tree in IP (Ethernet) network, but I read some CHIP datasheets, after strip PW label out, chip can not handle 2 VLAN IDs at same time. Could you please give me some hints, say, which chip you used? [JY] the chip doesn't need to handle 2 VLAN IDs at same time, see the previous msg: http://www.ietf.org/mail-archive/web/l2vpn/current/msg03392.html Maybe if we raised only one issue in one mail, we can get more and insight comments :). I will raise another after we agree with this in the main :). Thanks, Sam -----Original Message----- From: Lucy yong [mailto:lucy.yong@huawei.com] Sent: Wednesday, May 16, 2012 4:15 AM To: David Allan I; Balus, Florin Stelian (Florin); Sam Cao; Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance +1 We can't just make a conclusion from nowhere. Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of David Allan I Sent: Tuesday, May 15, 2012 2:55 PM To: Balus, Florin Stelian (Florin); Sam Cao; Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance Florin: I agree. The statement, at least to me, is a non-sequitor... Cheers Dave -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Balus, Florin Stelian (Florin) Sent: Tuesday, May 15, 2012 12:53 PM To: Sam Cao; 'Jiangyuanlong'; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance Sam, > Obviously the forwarding performance of Dual-VLAN will be much lower than what of Multi-PW. Sorry I could not keep up with some of the threads on this subject but the above statement caught my eyes. We have been doing all kind of egress operations on VLANs in the egress PE for the last 8 years and I am not aware of any "much lower" forwarding performance. As far as I know the chipsets used in the PEs can do this processing no problem. Do you want to clarify which kind of hardware may have problems? > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Sam Cao > Sent: Tuesday, May 15, 2012 6:32 AM > To: 'Jiangyuanlong'; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on forwarding performance > > Hi Yuanlong, > > 3rd mapping will make data plane complex, I think. Anyway, we reached > a consensus on Multi-PW implementation. > > If we use 3rd mapping, I agree with your opinion, maybe dual-VLAN > seems simple, but 2 mapping is enough. Then we can focus on data plane > performance. While stripe PW label out on egress PE, data-plane knows > how to forward the frames from PW, to Root AC or Leaf AC or all. But > if we use Dual-VLAN, after strip PW label out, data plane should strip > VLAN-ID out and then does same forwarding work as Multi-PW does. The > most important is, do one more operation while forwarding E-Tree > frames. Obviously the forwarding performance of Dual-VLAN will be much > lower than what of Multi-PW. > > Regards, > > Yuqun (Sam) Cao > E-mail: Yuqun.cao@gmail.com > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 7:03 PM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > See my further comments in line. > > -----Original Message----- > From: Sam Cao [mailto:yuqun.cao@gmail.com] > Sent: Tuesday, May 15, 2012 6:14 PM > To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > Thank you very much for your comments. I draw the topology you gave, > and 7 PWs will be established if we follow 01. > > Root AC ---- PE 1 ----- PW 1 -------- PE 2 ----- Leaf _AC > | \ / || > | \ /===PW 6,7=== || > PW 2 -----PW 5------\ || > | /----Root PW 3 --- \ || > Root _AC ---- PE 3 PE 4 ------ Root AC > | \ / | > | ----Leaf PW 4----- | > Leaf AC Leaf AC > Yes, on PE 3 there are several PWs, but if you want to clarify it, > there are only 3 types, one can carry frames originated from Root and > Leaf AC(one endpoint of this PW should be Root-only, otherwise this is > invalid), one only can carry frames from Root AC, and the last can > carry frames from Leaf ACs. On second thoughts, we still can classify > the PWs into 2 sets, one is Leaf set, and another is Root set, and the > union of the sets Leaf and Root is the PW we called it as compatible > PW (Maybe this is not correct, we can find one good term on this). > > So this optimization still follows the original design of Dual-PW > approach, Leaf PW only carries frames from Leaf AC; Root-PW only > carries frames from Root AC. Is it right? > > I don't know whether chip can support this forwarding behavior for > compatible PW or not, but if we implement it in NP, it is nearly same > as VPLS. The only difference is, setup 2 mappings, one between > Leaf-ACs and Leaf-PWs, one between Root-ACs and Root-PWs. For > traditional VPLS, there is only one mapping. > > [JY] It seems you may need a 3rd mapping: from both root & leaf AC to > a compatible PW. > BTW, for the forwarding and reverse direction, the mapping may be > asymmetric for you compatible PW. > > Based on my understanding, all drafts should have similar mapping. > > [JY] Dual-VLAN seems simpler here. > > Thanks, > > Sam > > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 3:32 PM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Sam, > > Thanks, please see my further comments with [JY]. > > Ok, we go on the case in your mail, where PE1 has one Root-only AC, > AC1, and > PE2 has one Leaf-only AC, AC2. In general we can setup 2 > "unidirectional" > PWs (bidirectional PW, but just carry unidirectional frames), Root-PW > which carries frames originated from AC1 and Leaf-PW which carries > frames originated from AC2. But only one PW also can work, just as > some members commented. Ok, we setup one PW between PE1 and PE2, we > can call this PW as compatible PW or something else. Frames originated > from Root or leaf ACs will be carried via this PW. Its forwarding > behavior is fully same as what traditional VPLS did, MAC learning on > AC or PW in one E-Tree. Or say, if one PE has Root-only ACs, it will > setup one PW with another PE, Root-only, Leaf-only or Root-Leaf-Mixed. > If 2 PEs are root-Leaf-Mixed or other cases, then 2 PWs will be > established. As you know, this can be done on control plane. > > [JY] Assume there are 2 other nodes PE3 & PE4 in this network > scenario, and both PE3 and PE4 have both root and leaf ACs, then there > are compatible PWs from PE3 which may carry both root and leaf traffic > (to PE1), which may carry only root traffic (to PE2); and further > there are root PW and leaf PW to PE4. Thus, the VSI on PE3 has at > least 4 different types of PW transmitting behaviours with regard to > the E-Tree traffic. In the reverse direction, the VSI on PE3 further > has at least > 4 different types of PW receiving behaviours. Not sure how you will > accommodate for these PWs in both the data plane and control plane. > > Regards, > Yuanlong > > Is this clear for you? Is this necessary to optimize PW setup in this > case? > > Maybe we need to add one paragraph on forwarding behavior. > > Again thank you very much for your comments, > > Sam > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 10:27 AM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Please see my comments in line. > > -----Original Message----- > From: Sam Cao [mailto:yuqun.cao@gmail.com] > Sent: Monday, May 14, 2012 8:31 PM > To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > We have discussed this in another thread. In fact, Daniel or I have > given the answers to the questions you raised here for several time :). > If we do in this way, we will reach deadlock and can not move forward > :). I try to explain it again. > > [JY] I will apologize if you had ever provided such answers before, > and you may just refer to the links rather than repeat the explanation. > As you can see, I just try to understand the mechanism of 2PW and its > implications, but the I-D does not include enough information. > > As you know, initial design we will setup 2 PWs all the time (if do in > this way, I think that you have no question), > > [JY] I will be concerned with the operational complexity of this > approach. > > but in most cases 2 PWs are not > necessary. So in 01 version, we optimize it. > > "Root-only VSI <-> any VSI: only root PW required" > "Leaf-only VSI <-> leaf-only VSI: no PWs required" > > In other cases 2 PWs are needed. If so, "Leaf-only -> root-only = one > leaf PW" is not correct: On Leaf-only side, yes, one Leaf-only PW is > created between Local Leaf type with remote Root type; on root-only > side, one root-only PW is created. Maybe it is better to call this as > compatible or mixed PW. So the left items you list are not correct for > multi_PW solution. > > [JY] This is something new, right? To be honest, I could not > understand what is your point: doesn't the mixed PW as you called also > consist of one Leaf-only PW in one direction and one root-only PW in > the other direction? > Furthermore, the case you took is also one case in your guideline > "Root-only VSI <-> any VSI: only root PW required", don't you think > that only one root PW is required following this guideline? > Actually, I don't care much about what is the bidirectional PW or > unidirectional PW called, but how can a VSI support such a mixed > scenarios: > traditional VSI assumes only one PW is required for each peer VSI, and > its MAC leaning is based on bidirectional PW. But for 2PW, there are > bidirectional root PW, bidirectional leaf PW, mixed PW, etc..., how to > support these kinds of PWs in the same VSI is my top concern. > > BTW, I guess you also care this case we also have discussed before: > for example, if we configure one Leaf AC on root-only PE (then it will > be root-leaf-mixed PE), we will teardown the compatible PW and > re-setup PWs again with 01. > [JY] This was discussed in the emails indeed. > > Regards, > > Yuqun (Sam) Cao > E-mail: Yuqun.cao@gmail.com > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Monday, May 14, 2012 7:10 PM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Daniel, > > Fine, now it seems more in line with what we had proposed in 2VLAN: a > spoke PW behaves like root/leaf AC for a PE-r. > > But the same problem may also apply to the root/spoke "core PW" for > Multi-PW: > According to Multi-PW, only one PW is required between two PEs except > when both PEs are mixed with root and leaf, so these PWs may be formed > by combinations of the following unidirectional PW cases (extracted > and adapted from Josh's email): > Root-only -> any VSI = one root PW > Leaf-only -> root-only = one leaf PW > Leaf-only -> mixed = one leaf PW > Mixed -> root-only = one (root+leaf) PW Mixed -> leaf-only = one > (root+leaf) PW > > I have a concern that the forwarding plane of PE to implement this > will be very different from the traditional VPLS. > > Regards, > Yuanlong > > -----Original Message----- > From: Daniel Cohn [mailto:DanielC@orckit.com] > Sent: Monday, May 14, 2012 5:00 PM > To: Jiangyuanlong; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > Like I wrote below, root/leaf spoke PW behave like root/leaf AC, not > like root/spoke "core PW". So no changes to forwarding plane once this > is understood. > > DC > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Monday, May 14, 2012 11:36 AM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Daniel, please see my comments in line. > > -----Original Message----- > From: Daniel Cohn [mailto:DanielC@orckit.com] > Sent: Monday, May 14, 2012 3:37 PM > To: Jiangyuanlong; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > As I see it, for the PE-r spoke (figure 4 in RFC 4762) we establish a > single PW per AC - root PW for root AC and leaf PW for leaf AC. With > local configuration at the PE-rs as part of the spoke PW provisioning. > And the PE-rs will treat root/leaf spoke PWs exactly as it treat > root/leaf ACs. So when leaf-originated BUM traffic arrives from the > core (over a leaf PW), it will be forwarded over all root spoke PWs > but not on the leaf spoke PWs. > > [JY] So in the reverse direction, you need to transport both root and > leaf traffic from PE-rs over a root PW to PE-r, and transport root > traffic over a leaf PW. It seems against the definition of root PW and > leaf PW in the multi-PW draft. Don't this make the forwarding plane of > PE-rs more complex? > > The forwarding plane is exactly the same as described in the multi-PW > draft, where spoke PWs are treated exactly like ACs. > > Regards, > > Daniel > > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Friday, May 11, 2012 5:03 AM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Daniel and all, > > When you set up two PWs from the PE-rs to a PE-r for each of its AC, > do you mean that one PW is bidirectional root PW and the other is > bidirectional leaf PW? > My concern is: where should the leaf traffic be filtered, on the PE-rs > or on the PE-r? > If filtered on the PE-r, then lots of bandwidth will be wasted (for > example, if the PE-r is attached with 9 leafs, then the BUM traffic > from one of its leafs will be multiplied by 8 times, and be forwarded > by the PE-rs to the same PE-r). > If filtered on the PE-rs, not sure how you will design its forwarding > plane, can you give a hint? > > Thanks, > Yuanlong > > ------------------------------ > Date: Wed, 9 May 2012 09:16:36 +0300 > From: "Daniel Cohn" > To: "Alexander Vainshtein" , "Sam > Cao" , > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780CBA6@tlvmail1> > Content-Type: text/plain; charset="ISO-2022-JP" > > Hi Sasha, > > It's actually very simple. A frame that originated in a root AC is > always transmitted only in root PW, no matter what the frame type > (known/unknown unicast or broadcast). This is how the frame source > information is propagated across the VPLS. So in the H-VPLS example, > the PE-r will never forward a frame received over a root PW on any > leaf PW, only on root PWs (toward the core or toward other spokes). > > Hope this clarifies it, regards, > > Daniel > > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Alexander Vainshtein > Sent: Wednesday, May 09, 2012 7:59 AM > To: Sam Cao; l2vpn@ietf.org > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > > Sam, Lizhong and all, > You've written that in the two-PW solution combined with H-VPLS the > PE- r must set up two PWs with each MTU-s. > > If this is the case, what kind of forwarding logic should be used to > prevent sending a BUM frame received from a root-PW to a given MTU-S: > - back to the same MTU-S on the corresponding leaf-PW? > - twice (to both root-PW and Leaf-PW) to another MTU-s? And, BTW, how > is the PW selected in this case? > > I am aware of a technique of multiple split horizon groups in PE-r > which could be possibly used for this purpose. However, since these > groups have to be represented explicitly in the data plane, their > potential number is limited by the forwarding HW. Other methods could > be probably used for the same purpose, but they would probably subject > to similar HW-based limitations. > > I suspect that with the dual-PW approach, the HW would pose an > implicit limit, say, on a number of MTU-s that can be connected to the > same PE-r and that this limit could be quite low in most cases. > > Based on this I suspect that the H-VPLS issue as a critical drawback > of the dual-PW approach to E-Tree. > > My 2c, > Sasha > > > ________________________________________ > From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Sam > Cao [yuqun.cao@gmail.com] > Sent: Wednesday, May 09, 2012 3:40 AM > To: l2vpn@ietf.org > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Lizhong? > > Thank you very much for your comments. I updated the result on this > question. > > [Lizhong] agree with the above analysis. And we did not say it is a > technical problem, but it is an operational problem again. > [Sam] I agree. Dual-VLAN does not make sense. I also discussed this > with Giles and Yuanlong in another mail, and we reached agreement on > this: > MTU should know the access mode, VPWS or VPLS, VPWS mode should > configure VLAN ID on MTU but VPLS mode can not. I thought this is NOT > reasonable :), but we can figure this out in draft. It seems ok. > > [Lizhong] not fully understand. Do you mean, when VPWS accessing for > H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf > PW) for each AC access? > [Sam] Yes. > > Thanks, > > Sam > > > > From loa@pi.nu Tue May 15 21:15: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 53BAC11E80C2 for ; Tue, 15 May 2012 21:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.239 X-Spam-Level: X-Spam-Status: No, score=-102.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1X7DzkaGNry4 for ; Tue, 15 May 2012 21:15:13 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id D6BE911E80B8 for ; Tue, 15 May 2012 21:15:12 -0700 (PDT) Received: from [192.168.1.101] (unknown [121.54.51.4]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id EBD2A2A8002; Wed, 16 May 2012 06:15:06 +0200 (CEST) Message-ID: <4FB329D0.8040301@pi.nu> Date: Wed, 16 May 2012 06:15:12 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Sam Cao Subject: Re: Discussion on forwarding performance References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D411694@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF5C@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D4130E1@szxeml546-mbs.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF8F@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413216@szxeml546-mbs.china.huawei.com> <3F1F3739E2B04D399CC7D26CE934F91A@v2comsam> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413694@szxeml546-mbs.china.huawei.com> <7A564821DF1642E592E884D5C623772C@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D41370E@szxeml546-mbs.china.huawei.com> <400D5D93E6AA4075861CE09919D84747@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413741@szxeml546-mbs.china.huawei.com> <7BDA456234D045E1BD42EA059A4E9579@v2comsam> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D41392A@szxeml546-mbs.china.huawei.com> <4BDAB74EAC0C49FEAD65A9575DB2E159@R01842> <4FB317A8.6060104@pi.nu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org, 'Jiangyuanlong' 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, 16 May 2012 04:15:17 -0000 Sam, sorry for jumping in late - I will look into if there are available forwarding parameters that I can share. Do I understand you correctly if you say that for a chip we will be able to do wire line forwarding for any number of labels that we reasonably can expect to handle? A NP will hit the limit earlier, and for E-tree this [is, might be] an issue. /Loa On 2012-05-16 05:37, Sam Cao wrote: > Loa, > > 1) This question comes from remaining issues list in past threads, raised by > other members, and I can not find any agreement on this. > > 2) If the E-tree frames are fully forwarded via chip, we could forward at > wire speed, so I also mentioned in that mail "If chipset can support this > and we don't care NP or other solutions, yes, we can ignore any side effect > on forwarding performance". But in some cases we can not forward at wire > speed. Does my test result mislead me? > > Loa, can you get forwarding parameters from some Router's datasheet? Thank > you very much for your comments, > > Sam > > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Wednesday, May 16, 2012 10:58 AM > To: Sam Cao > Cc: 'Jiangyuanlong'; 'Daniel Cohn'; 'Alexander Vainshtein'; l2vpn@ietf.org > Subject: Re: Discussion on forwarding performance > > Folks, > > an innocent question since I it is a long time since I worked with > forwarding performance, I lost most of the interest when it was clear > that whichever we used we could forward at wire speed. > > There has been other discussions around how many label look up certain > hw can handle, but I thought we were past this point also. > > Would one extra label cause us to drop below wire speed in forwarding > performance? Is this mostly a implementation complexity issue? > > /Loa > > On 2012-05-16 04:49, Sam Cao wrote: >> Yes, Yuanlong. We have discussed this before, but I can not get clear >> conclusion till now. From that linkage I also can not find it. >> >> Compared to traditional VPLS, forwarding performance of all solutions will >> be decreased. If chip can fully support the solutions and we ignore other >> non-chip solution, we can ignore forwarding performance. But can we ignore >> it? >> >> I found your patent application on this, and think that we need to > re-design >> VLAN Bridge you mentioned. VLAN Bridge can not support this inherently :). >> >> BTW, Yuanlong, is there any experimental data on forwarding performance? >> >> Thanks, >> >> Sam >> >> -----Original Message----- >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> Sent: Wednesday, May 16, 2012 10:17 AM >> To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on forwarding performance >> >> 3rd mapping will make data plane complex, I think. Anyway, we reached a >> consensus on Multi-PW implementation. >> >> If we use 3rd mapping, I agree with your opinion, maybe dual-VLAN seems >> simple, but 2 mapping is enough. >> >> [JY] Can't see how 2 mapping is enough for 2PW, do you mean to use 2 PWs > for >> all the peer PEs? >> >> Then we can focus on data plane >> performance. While stripe PW label out on egress PE, data-plane knows how > to >> forward the frames from PW, to Root AC or Leaf AC or all. But if we use >> Dual-VLAN, after strip PW label out, data plane should strip VLAN-ID out > and >> then does same forwarding work as Multi-PW does. >> >> [JY] We are running into the same cycle: forward implications for 2PW was >> already covered in >> http://www.ietf.org/mail-archive/web/l2vpn/current/msg03513.html, no need > to >> repeat it here. >> >> The most important is, do >> one more operation while forwarding E-Tree frames. Obviously the > forwarding >> performance of Dual-VLAN will be much lower than what of Multi-PW. >> >> [JY] VLAN operation is generally available in VPLS already, does this >> statement also mean Multi-PW will have a much higher performance even >> compared with VPLS itself? >> >> Regards, >> >> Yuqun (Sam) Cao >> E-mail: Yuqun.cao@gmail.com >> >> -----Original Message----- >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> Sent: Tuesday, May 15, 2012 7:03 PM >> To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> See my further comments in line. >> >> -----Original Message----- >> From: Sam Cao [mailto:yuqun.cao@gmail.com] >> Sent: Tuesday, May 15, 2012 6:14 PM >> To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Hi Yuanlong, >> >> Thank you very much for your comments. I draw the topology you gave, and 7 >> PWs will be established if we follow 01. >> >> Root AC ---- PE 1 ----- PW 1 -------- PE 2 ----- Leaf _AC >> | \ / || >> | \ /===PW 6,7=== || >> PW 2 -----PW 5------\ || >> | /----Root PW 3 --- \ || >> Root _AC ---- PE 3 PE 4 ------ Root AC >> | \ / | >> | ----Leaf PW 4----- | >> Leaf AC Leaf AC >> Yes, on PE 3 there are several PWs, but if you want to clarify it, there > are >> only 3 types, one can carry frames originated from Root and Leaf AC(one >> endpoint of this PW should be Root-only, otherwise this is invalid), one >> only can carry frames from Root AC, and the last can carry frames from > Leaf >> ACs. On second thoughts, we still can classify the PWs into 2 sets, one is >> Leaf set, and another is Root set, and the union of the sets Leaf and Root >> is the PW we called it as compatible PW (Maybe this is not correct, we can >> find one good term on this). >> >> So this optimization still follows the original design of Dual-PW > approach, >> Leaf PW only carries frames from Leaf AC; Root-PW only carries frames from >> Root AC. Is it right? >> >> I don't know whether chip can support this forwarding behavior for >> compatible PW or not, but if we implement it in NP, it is nearly same as >> VPLS. The only difference is, setup 2 mappings, one between Leaf-ACs and >> Leaf-PWs, one between Root-ACs and Root-PWs. For traditional VPLS, there > is >> only one mapping. >> >> [JY] It seems you may need a 3rd mapping: from both root& leaf AC to a >> compatible PW. >> BTW, for the forwarding and reverse direction, the mapping may be > asymmetric >> for you compatible PW. >> >> Based on my understanding, all drafts should have similar mapping. >> >> [JY] Dual-VLAN seems simpler here. >> >> Thanks, >> >> Sam >> >> >> -----Original Message----- >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> Sent: Tuesday, May 15, 2012 3:32 PM >> To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Sam, >> >> Thanks, please see my further comments with [JY]. >> >> Ok, we go on the case in your mail, where PE1 has one Root-only AC, AC1, > and >> PE2 has one Leaf-only AC, AC2. In general we can setup 2 "unidirectional" >> PWs (bidirectional PW, but just carry unidirectional frames), Root-PW > which >> carries frames originated from AC1 and Leaf-PW which carries frames >> originated from AC2. But only one PW also can work, just as some members >> commented. Ok, we setup one PW between PE1 and PE2, we can call this PW as >> compatible PW or something else. Frames originated from Root or leaf ACs >> will be carried via this PW. Its forwarding behavior is fully same as what >> traditional VPLS did, MAC learning on AC or PW in one E-Tree. Or say, if > one >> PE has Root-only ACs, it will setup one PW with another PE, Root-only, >> Leaf-only or Root-Leaf-Mixed. If 2 PEs are root-Leaf-Mixed or other cases, >> then 2 PWs will be established. As you know, this can be done on control >> plane. >> >> [JY] Assume there are 2 other nodes PE3& PE4 in this network scenario, > and >> both PE3 and PE4 have both root and leaf ACs, then there are compatible > PWs >> from PE3 which may carry both root and leaf traffic (to PE1), which may >> carry only root traffic (to PE2); and further there are root PW and leaf > PW >> to PE4. Thus, the VSI on PE3 has at least 4 different types of PW >> transmitting behaviours with regard to the E-Tree traffic. In the reverse >> direction, the VSI on PE3 further has at least 4 different types of PW >> receiving behaviours. Not sure how you will accommodate for these PWs in >> both the data plane and control plane. >> >> Regards, >> Yuanlong >> >> Is this clear for you? Is this necessary to optimize PW setup in this > case? >> >> Maybe we need to add one paragraph on forwarding behavior. >> >> Again thank you very much for your comments, >> >> Sam >> >> -----Original Message----- >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> Sent: Tuesday, May 15, 2012 10:27 AM >> To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Please see my comments in line. >> >> -----Original Message----- >> From: Sam Cao [mailto:yuqun.cao@gmail.com] >> Sent: Monday, May 14, 2012 8:31 PM >> To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Hi Yuanlong, >> >> We have discussed this in another thread. In fact, Daniel or I have given >> the answers to the questions you raised here for several time :). If we do >> in this way, we will reach deadlock and can not move forward :). I try to >> explain it again. >> >> [JY] I will apologize if you had ever provided such answers before, and > you >> may just refer to the links rather than repeat the explanation. >> As you can see, I just try to understand the mechanism of 2PW and its >> implications, but the I-D does not include enough information. >> >> As you know, initial design we will setup 2 PWs all the time (if do in > this >> way, I think that you have no question), >> >> [JY] I will be concerned with the operational complexity of this approach. >> >> but in most cases 2 PWs are not >> necessary. So in 01 version, we optimize it. >> >> "Root-only VSI<-> any VSI: only root PW required" >> "Leaf-only VSI<-> leaf-only VSI: no PWs required" >> >> In other cases 2 PWs are needed. If so, "Leaf-only -> root-only = one > leaf >> PW" is not correct: On Leaf-only side, yes, one Leaf-only PW is created >> between Local Leaf type with remote Root type; on root-only side, one >> root-only PW is created. Maybe it is better to call this as compatible or >> mixed PW. So the left items you list are not correct for multi_PW > solution. >> >> [JY] This is something new, right? To be honest, I could not understand > what >> is your point: doesn't the mixed PW as you called also consist of one >> Leaf-only PW in one direction and one root-only PW in the other direction? >> Furthermore, the case you took is also one case in your guideline > "Root-only >> VSI<-> any VSI: only root PW required", don't you think that only one > root >> PW is required following this guideline? >> Actually, I don't care much about what is the bidirectional PW or >> unidirectional PW called, but how can a VSI support such a mixed > scenarios: >> traditional VSI assumes only one PW is required for each peer VSI, and its >> MAC leaning is based on bidirectional PW. But for 2PW, there are >> bidirectional root PW, bidirectional leaf PW, mixed PW, etc..., how to >> support these kinds of PWs in the same VSI is my top concern. >> >> BTW, I guess you also care this case we also have discussed before: for >> example, if we configure one Leaf AC on root-only PE (then it will be >> root-leaf-mixed PE), we will teardown the compatible PW and re-setup PWs >> again with 01. >> [JY] This was discussed in the emails indeed. >> >> Regards, >> >> Yuqun (Sam) Cao >> E-mail: Yuqun.cao@gmail.com >> >> -----Original Message----- >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> Sent: Monday, May 14, 2012 7:10 PM >> To: Daniel Cohn; Alexander Vainshtein; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Hi Daniel, >> >> Fine, now it seems more in line with what we had proposed in 2VLAN: a > spoke >> PW behaves like root/leaf AC for a PE-r. >> >> But the same problem may also apply to the root/spoke "core PW" for >> Multi-PW: >> According to Multi-PW, only one PW is required between two PEs except when >> both PEs are mixed with root and leaf, so these PWs may be formed by >> combinations of the following unidirectional PW cases (extracted and > adapted >> from Josh's email): >> Root-only -> any VSI = one root PW >> Leaf-only -> root-only = one leaf PW >> Leaf-only -> mixed = one leaf PW >> Mixed -> root-only = one (root+leaf) PW >> Mixed -> leaf-only = one (root+leaf) PW >> >> I have a concern that the forwarding plane of PE to implement this will be >> very different from the traditional VPLS. >> >> Regards, >> Yuanlong >> >> -----Original Message----- >> From: Daniel Cohn [mailto:DanielC@orckit.com] >> Sent: Monday, May 14, 2012 5:00 PM >> To: Jiangyuanlong; Alexander Vainshtein; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Hi Yuanlong, >> >> Like I wrote below, root/leaf spoke PW behave like root/leaf AC, not >> like root/spoke "core PW". So no changes to forwarding plane once this >> is understood. >> >> DC >> >> -----Original Message----- >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> Sent: Monday, May 14, 2012 11:36 AM >> To: Daniel Cohn; Alexander Vainshtein; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Daniel, please see my comments in line. >> >> -----Original Message----- >> From: Daniel Cohn [mailto:DanielC@orckit.com] >> Sent: Monday, May 14, 2012 3:37 PM >> To: Jiangyuanlong; Alexander Vainshtein; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Hi Yuanlong, >> >> As I see it, for the PE-r spoke (figure 4 in RFC 4762) we establish a >> single PW per AC - root PW for root AC and leaf PW for leaf AC. With >> local configuration at the PE-rs as part of the spoke PW provisioning. >> And the PE-rs will treat root/leaf spoke PWs exactly as it treat >> root/leaf ACs. So when leaf-originated BUM traffic arrives from the core >> (over a leaf PW), it will be forwarded over all root spoke PWs but not >> on the leaf spoke PWs. >> >> [JY] So in the reverse direction, you need to transport both root and >> leaf traffic from PE-rs over a root PW to PE-r, and transport root >> traffic over a leaf PW. It seems against the definition of root PW and >> leaf PW in the multi-PW draft. Don't this make the forwarding plane of >> PE-rs more complex? >> >> The forwarding plane is exactly the same as described in the multi-PW >> draft, where spoke PWs are treated exactly like ACs. >> >> Regards, >> >> Daniel >> >> >> -----Original Message----- >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> Sent: Friday, May 11, 2012 5:03 AM >> To: Daniel Cohn; Alexander Vainshtein; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Hi Daniel and all, >> >> When you set up two PWs from the PE-rs to a PE-r for each of its AC, do >> you mean that one PW is bidirectional root PW and the other is >> bidirectional leaf PW? >> My concern is: where should the leaf traffic be filtered, on the PE-rs >> or on the PE-r? >> If filtered on the PE-r, then lots of bandwidth will be wasted (for >> example, if the PE-r is attached with 9 leafs, then the BUM traffic from >> one of its leafs will be multiplied by 8 times, and be forwarded by the >> PE-rs to the same PE-r). >> If filtered on the PE-rs, not sure how you will design its forwarding >> plane, can you give a hint? >> >> Thanks, >> Yuanlong >> >> ------------------------------ >> Date: Wed, 9 May 2012 09:16:36 +0300 >> From: "Daniel Cohn" >> To: "Alexander Vainshtein", "Sam >> Cao", >> Cc: lizhong.jin@zte.com.cn >> Subject: RE: Discussion on E-Tree and H-VPLS >> Message-ID:<44F4E579A764584EA9BDFD07D0CA08130780CBA6@tlvmail1> >> Content-Type: text/plain; charset="ISO-2022-JP" >> >> Hi Sasha, >> >> It's actually very simple. A frame that originated in a root AC is >> always transmitted only in root PW, no matter what the frame type >> (known/unknown unicast or broadcast). This is how the frame source >> information is propagated across the VPLS. So in the H-VPLS example, the >> PE-r will never forward a frame received over a root PW on any leaf PW, >> only on root PWs (toward the core or toward other spokes). >> >> Hope this clarifies it, regards, >> >> Daniel >> >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >> Of Alexander Vainshtein >> Sent: Wednesday, May 09, 2012 7:59 AM >> To: Sam Cao; l2vpn@ietf.org >> Cc: lizhong.jin@zte.com.cn >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Sam, Lizhong and all, >> You've written that in the two-PW solution combined with H-VPLS the PE-r >> must set up two PWs with each MTU-s. >> >> If this is the case, what kind of forwarding logic should be used to >> prevent sending a BUM frame received from a root-PW to a given MTU-S: >> - back to the same MTU-S on the corresponding leaf-PW? >> - twice (to both root-PW and Leaf-PW) to another MTU-s? And, BTW, how is >> the PW selected in this case? >> >> I am aware of a technique of multiple split horizon groups in PE-r which >> could be possibly used for this purpose. However, since these groups >> have to be represented explicitly in the data plane, their potential >> number is limited by the forwarding HW. Other methods could be probably >> used for the same purpose, but they would probably subject to similar >> HW-based limitations. >> >> I suspect that with the dual-PW approach, the HW would pose an implicit >> limit, say, on a number of MTU-s that can be connected to the same PE-r >> and that this limit could be quite low in most cases. >> >> Based on this I suspect that the H-VPLS issue as a critical drawback of >> the dual-PW approach to E-Tree. >> >> My 2c, >> Sasha >> >> >> ________________________________________ >> From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Sam >> Cao [yuqun.cao@gmail.com] >> Sent: Wednesday, May 09, 2012 3:40 AM >> To: l2vpn@ietf.org >> Cc: lizhong.jin@zte.com.cn >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Hi Lizhong? >> >> Thank you very much for your comments. I updated the result on this >> question. >> >> [Lizhong] agree with the above analysis. And we did not say it is a >> technical problem, but it is an operational problem again. >> [Sam] I agree. Dual-VLAN does not make sense. I also discussed this with >> Giles and Yuanlong in another mail, and we reached agreement on this: >> MTU should know the access mode, VPWS or VPLS, VPWS mode should >> configure VLAN ID on MTU but VPLS mode can not. I thought this is NOT >> reasonable :), but we can figure this out in draft. It seems ok. >> >> [Lizhong] not fully understand. Do you mean, when VPWS accessing for >> H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf >> PW) for each AC access? >> [Sam] Yes. >> >> Thanks, >> >> Sam >> >> >> >> >> >> > -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From florin.balus@alcatel-lucent.com Tue May 15 21:25: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 720FD11E80C2 for ; Tue, 15 May 2012 21:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.378 X-Spam-Level: X-Spam-Status: No, score=-9.378 tagged_above=-999 required=5 tests=[AWL=0.622, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQtPyi2ws+1X for ; Tue, 15 May 2012 21:25:02 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 5D24411E80D3 for ; Tue, 15 May 2012 21:25:02 -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 q4G4OrPX014473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 May 2012 23:24:53 -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 q4G4Oqpc025641 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 15 May 2012 23:24:52 -0500 Received: from USNAVSXCHMBSC3.ndc.alcatel-lucent.com ([135.3.39.144]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Tue, 15 May 2012 23:24:52 -0500 From: "Balus, Florin Stelian (Florin)" To: Sam Cao Date: Tue, 15 May 2012 23:29:31 -0500 Subject: Re: Discussion on forwarding performance Thread-Topic: Discussion on forwarding performance Thread-Index: Ac0zG9ZkBmDHYDeBS26a2LclBdAeHQ== Message-ID: References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D411694@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF5C@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D4130E1@szxeml546-mbs.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF8F@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413216@szxeml546-mbs.china.huawei.com> <3F1F3739E2B04D399CC7D26CE934F91A@v2comsam> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413694@szxeml546-mbs.china.huawei.com> <7A564821DF1642E592E884D5C623772C@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D41370E@szxeml546-mbs.china.huawei.com> <400D5D93E6AA4075861CE09919D84747@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413741@szxeml546-mbs.china.huawei.com> <7BDA456234D045E1BD42EA059A4E9579@v2comsam> <2073A6C5467C99478898544C6EBA3F4602C1907568@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> <60C093A41B5E45409A19D42CF7786DFD52328D98DF@EUSAACMS0703.eamcs.ericsson.se> <2691CE0099834E4A9C5044EEC662BB9D33108DD9@dfweml506-! mbx> <1A7E043E03FF48A2B3E5ECCD4F124B4C@R01842> In-Reply-To: <1A7E043E03FF48A2B3E5ECCD4F124B4C@R01842> 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.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: "l2vpn@ietf.org" , Jiangyuanlong 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, 16 May 2012 04:25:04 -0000 Sam, On May 15, 2012, at 7:09 PM, "Sam Cao" wrote: > Lucy/David/Florin, > > Thank you very much for your comments. > > I can not give the accurate data to support my conclusion, and just concl= ude > that if we implement it in NP module. Except for common operations of 2 > approaches, Tunnel Label push/pop-out, MAC-based forwarding, and etc., > Dual-VLAN needs one more VLAN push/pop-out operation while forwarding eve= ry > frame. So compared with Multi-PW, it needs more resource and time for NP > module if there are VSIs or PWs up limit to the capacity on one PE, and > standing on software architect's side, the performance will be decreased = by > at least 20%, I guess. I implemented one prototype which has similar > solution as current Multi-PW, and the performance will be decreased by 5%= , > compared with traditional VPLS. Daniel has experience on 2-PW deployment, > maybe he can give accurate data on Multi-PW. FB> Are you saying there are already largescale deployment of the 2-PW solu= tion. Would like to hear from service providers running the solution... > > Florin, do you mean that you have implemented E-Tree in MPLS network? FB> Proprietary ETREE solutions are available from a number of vendors, som= e involving filtering based on inner payload.... But that was not the point= of my comment. I was saying a number of implementations are available that = operate on VLANs without performance hit. > If > chipset can support this and we don't care NP or other solutions, yes, we > can ignore any side effect on forwarding performance. Yes, it can support > E-tree in IP (Ethernet) network, but I read some CHIP datasheets, after > strip PW label out, chip can not handle 2 VLAN IDs at same time. Could yo= u > please give me some hints, say, which chip you used? FB> this is not the place to advertise hardware capabilities... If you sear= ch the archive though about an year ago a well known chip vendor expressed = support for the vlan based solution. Florin > > Maybe if we raised only one issue in one mail, we can get more and insigh= t > comments :). I will raise another after we agree with this in the main :)= . > > Thanks, > > Sam > > > -----Original Message----- > From: Lucy yong [mailto:lucy.yong@huawei.com] > Sent: Wednesday, May 16, 2012 4:15 AM > To: David Allan I; Balus, Florin Stelian (Florin); Sam Cao; Jiangyuanlong= ; > 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on forwarding performance > > +1 > > We can't just make a conclusion from nowhere. > > Lucy > > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of > David Allan I > Sent: Tuesday, May 15, 2012 2:55 PM > To: Balus, Florin Stelian (Florin); Sam Cao; Jiangyuanlong; 'Daniel Cohn'= ; > 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on forwarding performance > > Florin: > > I agree. The statement, at least to me, is a non-sequitor... > > Cheers > Dave > > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of > Balus, Florin Stelian (Florin) > Sent: Tuesday, May 15, 2012 12:53 PM > To: Sam Cao; 'Jiangyuanlong'; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on forwarding performance > > Sam, > >> Obviously the forwarding performance of Dual-VLAN will be much lower tha= n > what of Multi-PW. > > Sorry I could not keep up with some of the threads on this subject but th= e > above statement caught my eyes. We have been doing all kind of egress > operations on VLANs in the egress PE for the last 8 years and I am not aw= are > of any "much lower" forwarding performance. As far as I know the chipsets > used in the PEs can do this processing no problem. Do you want to clarify > which kind of hardware may have problems? > >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >> Of Sam Cao >> Sent: Tuesday, May 15, 2012 6:32 AM >> To: 'Jiangyuanlong'; 'Daniel Cohn'; 'Alexander Vainshtein' >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on forwarding performance >> >> Hi Yuanlong, >> >> 3rd mapping will make data plane complex, I think. Anyway, we reached >> a consensus on Multi-PW implementation. >> >> If we use 3rd mapping, I agree with your opinion, maybe dual-VLAN >> seems simple, but 2 mapping is enough. Then we can focus on data plane >> performance. While stripe PW label out on egress PE, data-plane knows >> how to forward the frames from PW, to Root AC or Leaf AC or all. But >> if we use Dual-VLAN, after strip PW label out, data plane should strip >> VLAN-ID out and then does same forwarding work as Multi-PW does. The >> most important is, do one more operation while forwarding E-Tree >> frames. Obviously the forwarding performance of Dual-VLAN will be much >> lower than what of Multi-PW. >> >> Regards, >> >> Yuqun (Sam) Cao >> E-mail: Yuqun.cao@gmail.com >> >> -----Original Message----- >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> Sent: Tuesday, May 15, 2012 7:03 PM >> To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> See my further comments in line. >> >> -----Original Message----- >> From: Sam Cao [mailto:yuqun.cao@gmail.com] >> Sent: Tuesday, May 15, 2012 6:14 PM >> To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Hi Yuanlong, >> >> Thank you very much for your comments. I draw the topology you gave, >> and 7 PWs will be established if we follow 01. >> >> Root AC ---- PE 1 ----- PW 1 -------- PE 2 ----- Leaf _AC >> | \ / || >> | \ /=3D=3D=3DPW 6,7=3D=3D=3D || >> PW 2 -----PW 5------\ || >> | /----Root PW 3 --- \ || >> Root _AC ---- PE 3 PE 4 ------ Root AC >> | \ / | >> | ----Leaf PW 4----- | >> Leaf AC Leaf AC >> Yes, on PE 3 there are several PWs, but if you want to clarify it, >> there are only 3 types, one can carry frames originated from Root and >> Leaf AC(one endpoint of this PW should be Root-only, otherwise this is >> invalid), one only can carry frames from Root AC, and the last can >> carry frames from Leaf ACs. On second thoughts, we still can classify >> the PWs into 2 sets, one is Leaf set, and another is Root set, and the >> union of the sets Leaf and Root is the PW we called it as compatible >> PW (Maybe this is not correct, we can find one good term on this). >> >> So this optimization still follows the original design of Dual-PW >> approach, Leaf PW only carries frames from Leaf AC; Root-PW only >> carries frames from Root AC. Is it right? >> >> I don't know whether chip can support this forwarding behavior for >> compatible PW or not, but if we implement it in NP, it is nearly same >> as VPLS. The only difference is, setup 2 mappings, one between >> Leaf-ACs and Leaf-PWs, one between Root-ACs and Root-PWs. For >> traditional VPLS, there is only one mapping. >> >> [JY] It seems you may need a 3rd mapping: from both root & leaf AC to >> a compatible PW. >> BTW, for the forwarding and reverse direction, the mapping may be >> asymmetric for you compatible PW. >> >> Based on my understanding, all drafts should have similar mapping. >> >> [JY] Dual-VLAN seems simpler here. >> >> Thanks, >> >> Sam >> >> >> -----Original Message----- >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> Sent: Tuesday, May 15, 2012 3:32 PM >> To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Sam, >> >> Thanks, please see my further comments with [JY]. >> >> Ok, we go on the case in your mail, where PE1 has one Root-only AC, >> AC1, and >> PE2 has one Leaf-only AC, AC2. In general we can setup 2 >> "unidirectional" >> PWs (bidirectional PW, but just carry unidirectional frames), Root-PW >> which carries frames originated from AC1 and Leaf-PW which carries >> frames originated from AC2. But only one PW also can work, just as >> some members commented. Ok, we setup one PW between PE1 and PE2, we >> can call this PW as compatible PW or something else. Frames originated >> from Root or leaf ACs will be carried via this PW. Its forwarding >> behavior is fully same as what traditional VPLS did, MAC learning on >> AC or PW in one E-Tree. Or say, if one PE has Root-only ACs, it will >> setup one PW with another PE, Root-only, Leaf-only or Root-Leaf-Mixed. >> If 2 PEs are root-Leaf-Mixed or other cases, then 2 PWs will be >> established. As you know, this can be done on control plane. >> >> [JY] Assume there are 2 other nodes PE3 & PE4 in this network >> scenario, and both PE3 and PE4 have both root and leaf ACs, then there >> are compatible PWs from PE3 which may carry both root and leaf traffic >> (to PE1), which may carry only root traffic (to PE2); and further >> there are root PW and leaf PW to PE4. Thus, the VSI on PE3 has at >> least 4 different types of PW transmitting behaviours with regard to >> the E-Tree traffic. In the reverse direction, the VSI on PE3 further >> has at least >> 4 different types of PW receiving behaviours. Not sure how you will >> accommodate for these PWs in both the data plane and control plane. >> >> Regards, >> Yuanlong >> >> Is this clear for you? Is this necessary to optimize PW setup in this >> case? >> >> Maybe we need to add one paragraph on forwarding behavior. >> >> Again thank you very much for your comments, >> >> Sam >> >> -----Original Message----- >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> Sent: Tuesday, May 15, 2012 10:27 AM >> To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Please see my comments in line. >> >> -----Original Message----- >> From: Sam Cao [mailto:yuqun.cao@gmail.com] >> Sent: Monday, May 14, 2012 8:31 PM >> To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Hi Yuanlong, >> >> We have discussed this in another thread. In fact, Daniel or I have >> given the answers to the questions you raised here for several time :). >> If we do in this way, we will reach deadlock and can not move forward >> :). I try to explain it again. >> >> [JY] I will apologize if you had ever provided such answers before, >> and you may just refer to the links rather than repeat the explanation. >> As you can see, I just try to understand the mechanism of 2PW and its >> implications, but the I-D does not include enough information. >> >> As you know, initial design we will setup 2 PWs all the time (if do in >> this way, I think that you have no question), >> >> [JY] I will be concerned with the operational complexity of this >> approach. >> >> but in most cases 2 PWs are not >> necessary. So in 01 version, we optimize it. >> >> "Root-only VSI <-> any VSI: only root PW required" >> "Leaf-only VSI <-> leaf-only VSI: no PWs required" >> >> In other cases 2 PWs are needed. If so, "Leaf-only -> root-only =3D one >> leaf PW" is not correct: On Leaf-only side, yes, one Leaf-only PW is >> created between Local Leaf type with remote Root type; on root-only >> side, one root-only PW is created. Maybe it is better to call this as >> compatible or mixed PW. So the left items you list are not correct for >> multi_PW solution. >> >> [JY] This is something new, right? To be honest, I could not >> understand what is your point: doesn't the mixed PW as you called also >> consist of one Leaf-only PW in one direction and one root-only PW in >> the other direction? >> Furthermore, the case you took is also one case in your guideline >> "Root-only VSI <-> any VSI: only root PW required", don't you think >> that only one root PW is required following this guideline? >> Actually, I don't care much about what is the bidirectional PW or >> unidirectional PW called, but how can a VSI support such a mixed >> scenarios: >> traditional VSI assumes only one PW is required for each peer VSI, and >> its MAC leaning is based on bidirectional PW. But for 2PW, there are >> bidirectional root PW, bidirectional leaf PW, mixed PW, etc..., how to >> support these kinds of PWs in the same VSI is my top concern. >> >> BTW, I guess you also care this case we also have discussed before: >> for example, if we configure one Leaf AC on root-only PE (then it will >> be root-leaf-mixed PE), we will teardown the compatible PW and >> re-setup PWs again with 01. >> [JY] This was discussed in the emails indeed. >> >> Regards, >> >> Yuqun (Sam) Cao >> E-mail: Yuqun.cao@gmail.com >> >> -----Original Message----- >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> Sent: Monday, May 14, 2012 7:10 PM >> To: Daniel Cohn; Alexander Vainshtein; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Hi Daniel, >> >> Fine, now it seems more in line with what we had proposed in 2VLAN: a >> spoke PW behaves like root/leaf AC for a PE-r. >> >> But the same problem may also apply to the root/spoke "core PW" for >> Multi-PW: >> According to Multi-PW, only one PW is required between two PEs except >> when both PEs are mixed with root and leaf, so these PWs may be formed >> by combinations of the following unidirectional PW cases (extracted >> and adapted from Josh's email): >> Root-only -> any VSI =3D one root PW >> Leaf-only -> root-only =3D one leaf PW >> Leaf-only -> mixed =3D one leaf PW >> Mixed -> root-only =3D one (root+leaf) PW Mixed -> leaf-only =3D one >> (root+leaf) PW >> >> I have a concern that the forwarding plane of PE to implement this >> will be very different from the traditional VPLS. >> >> Regards, >> Yuanlong >> >> -----Original Message----- >> From: Daniel Cohn [mailto:DanielC@orckit.com] >> Sent: Monday, May 14, 2012 5:00 PM >> To: Jiangyuanlong; Alexander Vainshtein; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Hi Yuanlong, >> >> Like I wrote below, root/leaf spoke PW behave like root/leaf AC, not >> like root/spoke "core PW". So no changes to forwarding plane once this >> is understood. >> >> DC >> >> -----Original Message----- >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> Sent: Monday, May 14, 2012 11:36 AM >> To: Daniel Cohn; Alexander Vainshtein; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Daniel, please see my comments in line. >> >> -----Original Message----- >> From: Daniel Cohn [mailto:DanielC@orckit.com] >> Sent: Monday, May 14, 2012 3:37 PM >> To: Jiangyuanlong; Alexander Vainshtein; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Hi Yuanlong, >> >> As I see it, for the PE-r spoke (figure 4 in RFC 4762) we establish a >> single PW per AC - root PW for root AC and leaf PW for leaf AC. With >> local configuration at the PE-rs as part of the spoke PW provisioning. >> And the PE-rs will treat root/leaf spoke PWs exactly as it treat >> root/leaf ACs. So when leaf-originated BUM traffic arrives from the >> core (over a leaf PW), it will be forwarded over all root spoke PWs >> but not on the leaf spoke PWs. >> >> [JY] So in the reverse direction, you need to transport both root and >> leaf traffic from PE-rs over a root PW to PE-r, and transport root >> traffic over a leaf PW. It seems against the definition of root PW and >> leaf PW in the multi-PW draft. Don't this make the forwarding plane of >> PE-rs more complex? >> >> The forwarding plane is exactly the same as described in the multi-PW >> draft, where spoke PWs are treated exactly like ACs. >> >> Regards, >> >> Daniel >> >> >> -----Original Message----- >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> Sent: Friday, May 11, 2012 5:03 AM >> To: Daniel Cohn; Alexander Vainshtein; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Hi Daniel and all, >> >> When you set up two PWs from the PE-rs to a PE-r for each of its AC, >> do you mean that one PW is bidirectional root PW and the other is >> bidirectional leaf PW? >> My concern is: where should the leaf traffic be filtered, on the PE-rs >> or on the PE-r? >> If filtered on the PE-r, then lots of bandwidth will be wasted (for >> example, if the PE-r is attached with 9 leafs, then the BUM traffic >> from one of its leafs will be multiplied by 8 times, and be forwarded >> by the PE-rs to the same PE-r). >> If filtered on the PE-rs, not sure how you will design its forwarding >> plane, can you give a hint? >> >> Thanks, >> Yuanlong >> >> ------------------------------ >> Date: Wed, 9 May 2012 09:16:36 +0300 >> From: "Daniel Cohn" >> To: "Alexander Vainshtein" , "S= am >> Cao" , >> Cc: lizhong.jin@zte.com.cn >> Subject: RE: Discussion on E-Tree and H-VPLS >> Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780CBA6@tlvmail1> >> Content-Type: text/plain; charset=3D"ISO-2022-JP" >> >> Hi Sasha, >> >> It's actually very simple. A frame that originated in a root AC is >> always transmitted only in root PW, no matter what the frame type >> (known/unknown unicast or broadcast). This is how the frame source >> information is propagated across the VPLS. So in the H-VPLS example, >> the PE-r will never forward a frame received over a root PW on any >> leaf PW, only on root PWs (toward the core or toward other spokes). >> >> Hope this clarifies it, regards, >> >> Daniel >> >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >> Of Alexander Vainshtein >> Sent: Wednesday, May 09, 2012 7:59 AM >> To: Sam Cao; l2vpn@ietf.org >> Cc: lizhong.jin@zte.com.cn >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Sam, Lizhong and all, >> You've written that in the two-PW solution combined with H-VPLS the >> PE- r must set up two PWs with each MTU-s. >> >> If this is the case, what kind of forwarding logic should be used to >> prevent sending a BUM frame received from a root-PW to a given MTU-S: >> - back to the same MTU-S on the corresponding leaf-PW? >> - twice (to both root-PW and Leaf-PW) to another MTU-s? And, BTW, how >> is the PW selected in this case? >> >> I am aware of a technique of multiple split horizon groups in PE-r >> which could be possibly used for this purpose. However, since these >> groups have to be represented explicitly in the data plane, their >> potential number is limited by the forwarding HW. Other methods could >> be probably used for the same purpose, but they would probably subject >> to similar HW-based limitations. >> >> I suspect that with the dual-PW approach, the HW would pose an >> implicit limit, say, on a number of MTU-s that can be connected to the >> same PE-r and that this limit could be quite low in most cases. >> >> Based on this I suspect that the H-VPLS issue as a critical drawback >> of the dual-PW approach to E-Tree. >> >> My 2c, >> Sasha >> >> >> ________________________________________ >> From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Sam >> Cao [yuqun.cao@gmail.com] >> Sent: Wednesday, May 09, 2012 3:40 AM >> To: l2vpn@ietf.org >> Cc: lizhong.jin@zte.com.cn >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Hi Lizhong? >> >> Thank you very much for your comments. I updated the result on this >> question. >> >> [Lizhong] agree with the above analysis. And we did not say it is a >> technical problem, but it is an operational problem again. >> [Sam] I agree. Dual-VLAN does not make sense. I also discussed this >> with Giles and Yuanlong in another mail, and we reached agreement on >> this: >> MTU should know the access mode, VPWS or VPLS, VPWS mode should >> configure VLAN ID on MTU but VPLS mode can not. I thought this is NOT >> reasonable :), but we can figure this out in draft. It seems ok. >> >> [Lizhong] not fully understand. Do you mean, when VPWS accessing for >> H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf >> PW) for each AC access? >> [Sam] Yes. >> >> Thanks, >> >> Sam >> >> >> >> > > From jeff.tantsura@ericsson.com Tue May 15 21:56: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 F0B8721F8653 for ; Tue, 15 May 2012 21:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.174 X-Spam-Level: X-Spam-Status: No, score=-6.174 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, J_CHICKENPOX_23=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 OKlVi7PRphIZ for ; Tue, 15 May 2012 21:56:43 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id CE97321F8652 for ; Tue, 15 May 2012 21:56:41 -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 q4G4uah9016403; Tue, 15 May 2012 23:56:37 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.6]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 16 May 2012 00:56:29 -0400 From: Jeff Tantsura To: Loa Andersson Date: Wed, 16 May 2012 00:56:25 -0400 Subject: Re: Discussion on forwarding performance Thread-Topic: Discussion on forwarding performance Thread-Index: Ac0zIECuWjwwCdCJTgCM2TnsU8Nt4g== Message-ID: References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D411694@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF5C@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D4130E1@szxeml546-mbs.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF8F@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413216@szxeml546-mbs.china.huawei.com> <3F1F3739E2B04D399CC7D26CE934F91A@v2comsam> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413694@szxeml546-mbs.china.huawei.com> <7A564821DF1642E592E884D5C623772C@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D41370E@szxeml546-mbs.china.huawei.com> <400D5D93E6AA4075861CE09919D84747@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413741@szxeml546-mbs.china.huawei.com> <7BDA456234D045E1BD42EA059A4E9579@v2comsam> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D41392A@szxeml546-mbs.china.huawei.com> <4BDAB74EAC0C49FEAD65A9575DB2E159@R01842> <4FB317A8.6060104@pi.nu> In-Reply-To: <4FB317A8.6060104@pi.nu> 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" , Jiangyuanlong , 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: Wed, 16 May 2012 04:56:45 -0000 Hi, To my knowledge most of commercially available silicon can do upto 4 labels= lookup without affecting FW performance. That's also why entropy label shouldn't be places too deep in the stack in = order not to affect performance. Regards, Jeff On May 16, 2012, at 4:57, "Loa Andersson" wrote: > Folks, > > an innocent question since I it is a long time since I worked with > forwarding performance, I lost most of the interest when it was clear > that whichever we used we could forward at wire speed. > > There has been other discussions around how many label look up certain > hw can handle, but I thought we were past this point also. > > Would one extra label cause us to drop below wire speed in forwarding > performance? Is this mostly a implementation complexity issue? > > /Loa > > On 2012-05-16 04:49, Sam Cao wrote: >> Yes, Yuanlong. We have discussed this before, but I can not get clear >> conclusion till now. From that linkage I also can not find it. >> >> Compared to traditional VPLS, forwarding performance of all solutions wi= ll >> be decreased. If chip can fully support the solutions and we ignore othe= r >> non-chip solution, we can ignore forwarding performance. But can we igno= re >> it? >> >> I found your patent application on this, and think that we need to re-de= sign >> VLAN Bridge you mentioned. VLAN Bridge can not support this inherently := ). >> >> BTW, Yuanlong, is there any experimental data on forwarding performance? >> >> Thanks, >> >> Sam >> >> -----Original Message----- >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> Sent: Wednesday, May 16, 2012 10:17 AM >> To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on forwarding performance >> >> 3rd mapping will make data plane complex, I think. Anyway, we reached a >> consensus on Multi-PW implementation. >> >> If we use 3rd mapping, I agree with your opinion, maybe dual-VLAN seems >> simple, but 2 mapping is enough. >> >> [JY] Can't see how 2 mapping is enough for 2PW, do you mean to use 2 PWs= for >> all the peer PEs? >> >> Then we can focus on data plane >> performance. While stripe PW label out on egress PE, data-plane knows ho= w to >> forward the frames from PW, to Root AC or Leaf AC or all. But if we use >> Dual-VLAN, after strip PW label out, data plane should strip VLAN-ID out= and >> then does same forwarding work as Multi-PW does. >> >> [JY] We are running into the same cycle: forward implications for 2PW wa= s >> already covered in >> http://www.ietf.org/mail-archive/web/l2vpn/current/msg03513.html, no nee= d to >> repeat it here. >> >> The most important is, do >> one more operation while forwarding E-Tree frames. Obviously the forward= ing >> performance of Dual-VLAN will be much lower than what of Multi-PW. >> >> [JY] VLAN operation is generally available in VPLS already, does this >> statement also mean Multi-PW will have a much higher performance even >> compared with VPLS itself? >> >> Regards, >> >> Yuqun (Sam) Cao >> E-mail: Yuqun.cao@gmail.com >> >> -----Original Message----- >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> Sent: Tuesday, May 15, 2012 7:03 PM >> To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> See my further comments in line. >> >> -----Original Message----- >> From: Sam Cao [mailto:yuqun.cao@gmail.com] >> Sent: Tuesday, May 15, 2012 6:14 PM >> To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Hi Yuanlong, >> >> Thank you very much for your comments. I draw the topology you gave, and= 7 >> PWs will be established if we follow 01. >> >> Root AC ---- PE 1 ----- PW 1 -------- PE 2 ----- Leaf _AC >> | \ / || >> | \ /=3D=3D=3DPW 6,7=3D=3D=3D || >> PW 2 -----PW 5------\ || >> | /----Root PW 3 --- \ || >> Root _AC ---- PE 3 PE 4 ------ Root AC >> | \ / | >> | ----Leaf PW 4----- | >> Leaf AC Leaf AC >> Yes, on PE 3 there are several PWs, but if you want to clarify it, there= are >> only 3 types, one can carry frames originated from Root and Leaf AC(one >> endpoint of this PW should be Root-only, otherwise this is invalid), one >> only can carry frames from Root AC, and the last can carry frames from L= eaf >> ACs. On second thoughts, we still can classify the PWs into 2 sets, one = is >> Leaf set, and another is Root set, and the union of the sets Leaf and Ro= ot >> is the PW we called it as compatible PW (Maybe this is not correct, we c= an >> find one good term on this). >> >> So this optimization still follows the original design of Dual-PW approa= ch, >> Leaf PW only carries frames from Leaf AC; Root-PW only carries frames fr= om >> Root AC. Is it right? >> >> I don't know whether chip can support this forwarding behavior for >> compatible PW or not, but if we implement it in NP, it is nearly same as >> VPLS. The only difference is, setup 2 mappings, one between Leaf-ACs and >> Leaf-PWs, one between Root-ACs and Root-PWs. For traditional VPLS, there= is >> only one mapping. >> >> [JY] It seems you may need a 3rd mapping: from both root& leaf AC to a >> compatible PW. >> BTW, for the forwarding and reverse direction, the mapping may be asymme= tric >> for you compatible PW. >> >> Based on my understanding, all drafts should have similar mapping. >> >> [JY] Dual-VLAN seems simpler here. >> >> Thanks, >> >> Sam >> >> >> -----Original Message----- >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> Sent: Tuesday, May 15, 2012 3:32 PM >> To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Sam, >> >> Thanks, please see my further comments with [JY]. >> >> Ok, we go on the case in your mail, where PE1 has one Root-only AC, AC1,= and >> PE2 has one Leaf-only AC, AC2. In general we can setup 2 "unidirectional= " >> PWs (bidirectional PW, but just carry unidirectional frames), Root-PW wh= ich >> carries frames originated from AC1 and Leaf-PW which carries frames >> originated from AC2. But only one PW also can work, just as some members >> commented. Ok, we setup one PW between PE1 and PE2, we can call this PW = as >> compatible PW or something else. Frames originated from Root or leaf ACs >> will be carried via this PW. Its forwarding behavior is fully same as wh= at >> traditional VPLS did, MAC learning on AC or PW in one E-Tree. Or say, if= one >> PE has Root-only ACs, it will setup one PW with another PE, Root-only, >> Leaf-only or Root-Leaf-Mixed. If 2 PEs are root-Leaf-Mixed or other case= s, >> then 2 PWs will be established. As you know, this can be done on control >> plane. >> >> [JY] Assume there are 2 other nodes PE3& PE4 in this network scenario, = and >> both PE3 and PE4 have both root and leaf ACs, then there are compatible = PWs >> from PE3 which may carry both root and leaf traffic (to PE1), which may >> carry only root traffic (to PE2); and further there are root PW and leaf= PW >> to PE4. Thus, the VSI on PE3 has at least 4 different types of PW >> transmitting behaviours with regard to the E-Tree traffic. In the revers= e >> direction, the VSI on PE3 further has at least 4 different types of PW >> receiving behaviours. Not sure how you will accommodate for these PWs in >> both the data plane and control plane. >> >> Regards, >> Yuanlong >> >> Is this clear for you? Is this necessary to optimize PW setup in this ca= se? >> >> Maybe we need to add one paragraph on forwarding behavior. >> >> Again thank you very much for your comments, >> >> Sam >> >> -----Original Message----- >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> Sent: Tuesday, May 15, 2012 10:27 AM >> To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Please see my comments in line. >> >> -----Original Message----- >> From: Sam Cao [mailto:yuqun.cao@gmail.com] >> Sent: Monday, May 14, 2012 8:31 PM >> To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Hi Yuanlong, >> >> We have discussed this in another thread. In fact, Daniel or I have give= n >> the answers to the questions you raised here for several time :). If we = do >> in this way, we will reach deadlock and can not move forward :). I try t= o >> explain it again. >> >> [JY] I will apologize if you had ever provided such answers before, and = you >> may just refer to the links rather than repeat the explanation. >> As you can see, I just try to understand the mechanism of 2PW and its >> implications, but the I-D does not include enough information. >> >> As you know, initial design we will setup 2 PWs all the time (if do in t= his >> way, I think that you have no question), >> >> [JY] I will be concerned with the operational complexity of this approac= h. >> >> but in most cases 2 PWs are not >> necessary. So in 01 version, we optimize it. >> >> "Root-only VSI<-> any VSI: only root PW required" >> "Leaf-only VSI<-> leaf-only VSI: no PWs required" >> >> In other cases 2 PWs are needed. If so, "Leaf-only -> root-only =3D one= leaf >> PW" is not correct: On Leaf-only side, yes, one Leaf-only PW is created >> between Local Leaf type with remote Root type; on root-only side, one >> root-only PW is created. Maybe it is better to call this as compatible o= r >> mixed PW. So the left items you list are not correct for multi_PW soluti= on. >> >> [JY] This is something new, right? To be honest, I could not understand = what >> is your point: doesn't the mixed PW as you called also consist of one >> Leaf-only PW in one direction and one root-only PW in the other directio= n? >> Furthermore, the case you took is also one case in your guideline "Root-= only >> VSI<-> any VSI: only root PW required", don't you think that only one r= oot >> PW is required following this guideline? >> Actually, I don't care much about what is the bidirectional PW or >> unidirectional PW called, but how can a VSI support such a mixed scenari= os: >> traditional VSI assumes only one PW is required for each peer VSI, and i= ts >> MAC leaning is based on bidirectional PW. But for 2PW, there are >> bidirectional root PW, bidirectional leaf PW, mixed PW, etc..., how to >> support these kinds of PWs in the same VSI is my top concern. >> >> BTW, I guess you also care this case we also have discussed before: for >> example, if we configure one Leaf AC on root-only PE (then it will be >> root-leaf-mixed PE), we will teardown the compatible PW and re-setup PWs >> again with 01. >> [JY] This was discussed in the emails indeed. >> >> Regards, >> >> Yuqun (Sam) Cao >> E-mail: Yuqun.cao@gmail.com >> >> -----Original Message----- >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> Sent: Monday, May 14, 2012 7:10 PM >> To: Daniel Cohn; Alexander Vainshtein; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Hi Daniel, >> >> Fine, now it seems more in line with what we had proposed in 2VLAN: a sp= oke >> PW behaves like root/leaf AC for a PE-r. >> >> But the same problem may also apply to the root/spoke "core PW" for >> Multi-PW: >> According to Multi-PW, only one PW is required between two PEs except wh= en >> both PEs are mixed with root and leaf, so these PWs may be formed by >> combinations of the following unidirectional PW cases (extracted and ada= pted >> from Josh's email): >> Root-only -> any VSI =3D one root PW >> Leaf-only -> root-only =3D one leaf PW >> Leaf-only -> mixed =3D one leaf PW >> Mixed -> root-only =3D one (root+leaf) PW >> Mixed -> leaf-only =3D one (root+leaf) PW >> >> I have a concern that the forwarding plane of PE to implement this will = be >> very different from the traditional VPLS. >> >> Regards, >> Yuanlong >> >> -----Original Message----- >> From: Daniel Cohn [mailto:DanielC@orckit.com] >> Sent: Monday, May 14, 2012 5:00 PM >> To: Jiangyuanlong; Alexander Vainshtein; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Hi Yuanlong, >> >> Like I wrote below, root/leaf spoke PW behave like root/leaf AC, not >> like root/spoke "core PW". So no changes to forwarding plane once this >> is understood. >> >> DC >> >> -----Original Message----- >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> Sent: Monday, May 14, 2012 11:36 AM >> To: Daniel Cohn; Alexander Vainshtein; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Daniel, please see my comments in line. >> >> -----Original Message----- >> From: Daniel Cohn [mailto:DanielC@orckit.com] >> Sent: Monday, May 14, 2012 3:37 PM >> To: Jiangyuanlong; Alexander Vainshtein; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Hi Yuanlong, >> >> As I see it, for the PE-r spoke (figure 4 in RFC 4762) we establish a >> single PW per AC - root PW for root AC and leaf PW for leaf AC. With >> local configuration at the PE-rs as part of the spoke PW provisioning. >> And the PE-rs will treat root/leaf spoke PWs exactly as it treat >> root/leaf ACs. So when leaf-originated BUM traffic arrives from the core >> (over a leaf PW), it will be forwarded over all root spoke PWs but not >> on the leaf spoke PWs. >> >> [JY] So in the reverse direction, you need to transport both root and >> leaf traffic from PE-rs over a root PW to PE-r, and transport root >> traffic over a leaf PW. It seems against the definition of root PW and >> leaf PW in the multi-PW draft. Don't this make the forwarding plane of >> PE-rs more complex? >> >> The forwarding plane is exactly the same as described in the multi-PW >> draft, where spoke PWs are treated exactly like ACs. >> >> Regards, >> >> Daniel >> >> >> -----Original Message----- >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> Sent: Friday, May 11, 2012 5:03 AM >> To: Daniel Cohn; Alexander Vainshtein; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Hi Daniel and all, >> >> When you set up two PWs from the PE-rs to a PE-r for each of its AC, do >> you mean that one PW is bidirectional root PW and the other is >> bidirectional leaf PW? >> My concern is: where should the leaf traffic be filtered, on the PE-rs >> or on the PE-r? >> If filtered on the PE-r, then lots of bandwidth will be wasted (for >> example, if the PE-r is attached with 9 leafs, then the BUM traffic from >> one of its leafs will be multiplied by 8 times, and be forwarded by the >> PE-rs to the same PE-r). >> If filtered on the PE-rs, not sure how you will design its forwarding >> plane, can you give a hint? >> >> Thanks, >> Yuanlong >> >> ------------------------------ >> Date: Wed, 9 May 2012 09:16:36 +0300 >> From: "Daniel Cohn" >> To: "Alexander Vainshtein", "Sam >> Cao", >> Cc: lizhong.jin@zte.com.cn >> Subject: RE: Discussion on E-Tree and H-VPLS >> Message-ID:<44F4E579A764584EA9BDFD07D0CA08130780CBA6@tlvmail1> >> Content-Type: text/plain; charset=3D"ISO-2022-JP" >> >> Hi Sasha, >> >> It's actually very simple. A frame that originated in a root AC is >> always transmitted only in root PW, no matter what the frame type >> (known/unknown unicast or broadcast). This is how the frame source >> information is propagated across the VPLS. So in the H-VPLS example, the >> PE-r will never forward a frame received over a root PW on any leaf PW, >> only on root PWs (toward the core or toward other spokes). >> >> Hope this clarifies it, regards, >> >> Daniel >> >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >> Of Alexander Vainshtein >> Sent: Wednesday, May 09, 2012 7:59 AM >> To: Sam Cao; l2vpn@ietf.org >> Cc: lizhong.jin@zte.com.cn >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Sam, Lizhong and all, >> You've written that in the two-PW solution combined with H-VPLS the PE-r >> must set up two PWs with each MTU-s. >> >> If this is the case, what kind of forwarding logic should be used to >> prevent sending a BUM frame received from a root-PW to a given MTU-S: >> - back to the same MTU-S on the corresponding leaf-PW? >> - twice (to both root-PW and Leaf-PW) to another MTU-s? And, BTW, how is >> the PW selected in this case? >> >> I am aware of a technique of multiple split horizon groups in PE-r which >> could be possibly used for this purpose. However, since these groups >> have to be represented explicitly in the data plane, their potential >> number is limited by the forwarding HW. Other methods could be probably >> used for the same purpose, but they would probably subject to similar >> HW-based limitations. >> >> I suspect that with the dual-PW approach, the HW would pose an implicit >> limit, say, on a number of MTU-s that can be connected to the same PE-r >> and that this limit could be quite low in most cases. >> >> Based on this I suspect that the H-VPLS issue as a critical drawback of >> the dual-PW approach to E-Tree. >> >> My 2c, >> Sasha >> >> >> ________________________________________ >> From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Sam >> Cao [yuqun.cao@gmail.com] >> Sent: Wednesday, May 09, 2012 3:40 AM >> To: l2vpn@ietf.org >> Cc: lizhong.jin@zte.com.cn >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Hi Lizhong? >> >> Thank you very much for your comments. I updated the result on this >> question. >> >> [Lizhong] agree with the above analysis. And we did not say it is a >> technical problem, but it is an operational problem again. >> [Sam] I agree. Dual-VLAN does not make sense. I also discussed this with >> Giles and Yuanlong in another mail, and we reached agreement on this: >> MTU should know the access mode, VPWS or VPLS, VPWS mode should >> configure VLAN ID on MTU but VPLS mode can not. I thought this is NOT >> reasonable :), but we can figure this out in draft. It seems ok. >> >> [Lizhong] not fully understand. Do you mean, when VPWS accessing for >> H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf >> PW) for each AC access? >> [Sam] Yes. >> >> Thanks, >> >> Sam >> >> >> >> >> >> > > -- > > > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 From DanielC@orckit.com Tue May 15 23:13: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 0DF2721F86FC for ; Tue, 15 May 2012 23:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[AWL=-0.189, BAYES_00=-2.599, J_CHICKENPOX_23=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 Qqoa+mlT5jgU for ; Tue, 15 May 2012 23:13:26 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id C734221F86E8 for ; Tue, 15 May 2012 23:13: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: Discussion on forwarding performance Date: Wed, 16 May 2012 09:16:10 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780D1AB@tlvmail1> In-Reply-To: <2073A6C5467C99478898544C6EBA3F4602C1907568@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Discussion on forwarding performance Thread-Index: AQHNLxo31u2OjZw96UuBF9QPOwJXg5bHcLkAgAGHLZCAAAmjYIAAHGPggAAUqSCAAOHDIIAAM7tggAAlyMCAADHVIIAAElJAgAAmSSCAAGzc8IAAspUA References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D411694@szxeml546-mbx.china.huawei.com><44F4E579A764584EA9BDFD07D0CA08130780CF5C@tlvmail1><3B0A1BED22CAD649A1B3E97BE5DDD68B1D4130E1@szxeml546-mbs.china.huawei.com><44F4E579A764584EA9BDFD07D0CA08130780CF8F@tlvmail1><3B0A1BED22CAD649A1B3E97BE5DDD68B1D413216@szxeml546-mbs.china.huawei.com><3F1F3739E2B04D399CC7D26CE934F91A@v2comsam><3B0A1BED22CAD649A1B3E97BE5DDD68B1D413694@szxeml546-mbs.china.huawei.com><7A564821DF1642E592E884D5C623772C@R01842><3B0A1BED22CAD649A1B3E97BE5DDD68B1D41370E@szxeml546-mbs.china.huawei.com><400D5D93E6AA4075861CE09919D84747@R01842><3B0A1BED22CAD649A1B3E97BE5DDD68B1D413741@szxeml546-mbs.china.huawei.com> <7BDA456234D045E1BD42EA059A4E9579@v2comsam> <2073A6C5467C99478898544C6EBA3F4602C1907568@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> From: "Daniel Cohn" To: "Balus, Florin Stelian (Florin)" , "Sam Cao" , "Jiangyuanlong" , "Alexander Vainshtein" 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, 16 May 2012 06:13:28 -0000 Hi, I agree that for a chip-based solution there should be no difference in performance for the additional lookup. However from conversations with chip vendors, I understood there might be an impact on scalability because the double lookup would require a longer search key (assuming VLAN and VCID lookups are performed simultaneously on ingress), thus taking up more TCAM resources per E-Tree instance. This would depend on specific TCAM implementation (e.g. granularity of search key length). DC -----Original Message----- From: Balus, Florin Stelian (Florin) [mailto:florin.balus@alcatel-lucent.com]=20 Sent: Tuesday, May 15, 2012 10:53 PM To: Sam Cao; 'Jiangyuanlong'; Daniel Cohn; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance Sam, > Obviously the forwarding performance of Dual-VLAN will be much lower than what of Multi-PW. Sorry I could not keep up with some of the threads on this subject but the above statement caught my eyes. We have been doing all kind of egress operations on VLANs in the egress PE for the last 8 years and I am not aware of any "much lower" forwarding performance. As far as I know the chipsets used in the PEs can do this processing no problem. Do you want to clarify which kind of hardware may have problems? > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Sam Cao > Sent: Tuesday, May 15, 2012 6:32 AM > To: 'Jiangyuanlong'; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on forwarding performance > > Hi Yuanlong, > > 3rd mapping will make data plane complex, I think. Anyway, we reached a > consensus on Multi-PW implementation. > > If we use 3rd mapping, I agree with your opinion, maybe dual-VLAN seems > simple, but 2 mapping is enough. Then we can focus on data plane > performance. While stripe PW label out on egress PE, data-plane knows > how to forward the frames from PW, to Root AC or Leaf AC or all. But if > we use Dual-VLAN, after strip PW label out, data plane should strip > VLAN-ID out and then does same forwarding work as Multi-PW does. The > most important is, do one more operation while forwarding E-Tree > frames. Obviously the forwarding performance of Dual-VLAN will be much > lower than what of Multi-PW. > > Regards, > > Yuqun (Sam) Cao > E-mail: Yuqun.cao@gmail.com > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 7:03 PM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > See my further comments in line. > > -----Original Message----- > From: Sam Cao [mailto:yuqun.cao@gmail.com] > Sent: Tuesday, May 15, 2012 6:14 PM > To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > Thank you very much for your comments. I draw the topology you gave, > and 7 PWs will be established if we follow 01. > > Root AC ---- PE 1 ----- PW 1 -------- PE 2 ----- Leaf _AC > | \ / || > | \ /=3D=3D=3DPW 6,7=3D=3D=3D || > PW 2 -----PW 5------\ || > | /----Root PW 3 --- \ || > Root _AC ---- PE 3 PE 4 ------ Root AC > | \ / | > | ----Leaf PW 4----- | > Leaf AC Leaf AC > Yes, on PE 3 there are several PWs, but if you want to clarify it, > there are only 3 types, one can carry frames originated from Root and > Leaf AC(one endpoint of this PW should be Root-only, otherwise this is > invalid), one only can carry frames from Root AC, and the last can > carry frames from Leaf ACs. On second thoughts, we still can classify > the PWs into 2 sets, one is Leaf set, and another is Root set, and the > union of the sets Leaf and Root is the PW we called it as compatible PW > (Maybe this is not correct, we can find one good term on this). > > So this optimization still follows the original design of Dual-PW > approach, Leaf PW only carries frames from Leaf AC; Root-PW only > carries frames from Root AC. Is it right? > > I don't know whether chip can support this forwarding behavior for > compatible PW or not, but if we implement it in NP, it is nearly same > as VPLS. The only difference is, setup 2 mappings, one between Leaf-ACs > and Leaf-PWs, one between Root-ACs and Root-PWs. For traditional VPLS, > there is only one mapping. > > [JY] It seems you may need a 3rd mapping: from both root & leaf AC to a > compatible PW. > BTW, for the forwarding and reverse direction, the mapping may be > asymmetric for you compatible PW. > > Based on my understanding, all drafts should have similar mapping. > > [JY] Dual-VLAN seems simpler here. > > Thanks, > > Sam > > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 3:32 PM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Sam, > > Thanks, please see my further comments with [JY]. > > Ok, we go on the case in your mail, where PE1 has one Root-only AC, > AC1, and > PE2 has one Leaf-only AC, AC2. In general we can setup 2 > "unidirectional" > PWs (bidirectional PW, but just carry unidirectional frames), Root-PW > which carries frames originated from AC1 and Leaf-PW which carries > frames originated from AC2. But only one PW also can work, just as some > members commented. Ok, we setup one PW between PE1 and PE2, we can call > this PW as compatible PW or something else. Frames originated from Root > or leaf ACs will be carried via this PW. Its forwarding behavior is > fully same as what traditional VPLS did, MAC learning on AC or PW in > one E-Tree. Or say, if one PE has Root-only ACs, it will setup one PW > with another PE, Root-only, Leaf-only or Root-Leaf-Mixed. If 2 PEs are > root-Leaf-Mixed or other cases, then 2 PWs will be established. As you > know, this can be done on control plane. > > [JY] Assume there are 2 other nodes PE3 & PE4 in this network scenario, > and both PE3 and PE4 have both root and leaf ACs, then there are > compatible PWs from PE3 which may carry both root and leaf traffic (to > PE1), which may carry only root traffic (to PE2); and further there are > root PW and leaf PW to PE4. Thus, the VSI on PE3 has at least 4 > different types of PW transmitting behaviours with regard to the E-Tree > traffic. In the reverse direction, the VSI on PE3 further has at least > 4 different types of PW receiving behaviours. Not sure how you will > accommodate for these PWs in both the data plane and control plane. > > Regards, > Yuanlong > > Is this clear for you? Is this necessary to optimize PW setup in this > case? > > Maybe we need to add one paragraph on forwarding behavior. > > Again thank you very much for your comments, > > Sam > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 10:27 AM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Please see my comments in line. > > -----Original Message----- > From: Sam Cao [mailto:yuqun.cao@gmail.com] > Sent: Monday, May 14, 2012 8:31 PM > To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > We have discussed this in another thread. In fact, Daniel or I have > given the answers to the questions you raised here for several time :). > If we do in this way, we will reach deadlock and can not move forward > :). I try to explain it again. > > [JY] I will apologize if you had ever provided such answers before, and > you may just refer to the links rather than repeat the explanation. > As you can see, I just try to understand the mechanism of 2PW and its > implications, but the I-D does not include enough information. > > As you know, initial design we will setup 2 PWs all the time (if do in > this way, I think that you have no question), > > [JY] I will be concerned with the operational complexity of this > approach. > > but in most cases 2 PWs are not > necessary. So in 01 version, we optimize it. > > "Root-only VSI <-> any VSI: only root PW required" > "Leaf-only VSI <-> leaf-only VSI: no PWs required" > > In other cases 2 PWs are needed. If so, "Leaf-only -> root-only =3D = one > leaf PW" is not correct: On Leaf-only side, yes, one Leaf-only PW is > created between Local Leaf type with remote Root type; on root-only > side, one root-only PW is created. Maybe it is better to call this as > compatible or mixed PW. So the left items you list are not correct for > multi_PW solution. > > [JY] This is something new, right? To be honest, I could not understand > what is your point: doesn't the mixed PW as you called also consist of > one Leaf-only PW in one direction and one root-only PW in the other > direction? > Furthermore, the case you took is also one case in your guideline > "Root-only VSI <-> any VSI: only root PW required", don't you think > that only one root PW is required following this guideline? > Actually, I don't care much about what is the bidirectional PW or > unidirectional PW called, but how can a VSI support such a mixed > scenarios: > traditional VSI assumes only one PW is required for each peer VSI, and > its MAC leaning is based on bidirectional PW. But for 2PW, there are > bidirectional root PW, bidirectional leaf PW, mixed PW, etc..., how to > support these kinds of PWs in the same VSI is my top concern. > > BTW, I guess you also care this case we also have discussed before: for > example, if we configure one Leaf AC on root-only PE (then it will be > root-leaf-mixed PE), we will teardown the compatible PW and re-setup > PWs again with 01. > [JY] This was discussed in the emails indeed. > > Regards, > > Yuqun (Sam) Cao > E-mail: Yuqun.cao@gmail.com > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Monday, May 14, 2012 7:10 PM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Daniel, > > Fine, now it seems more in line with what we had proposed in 2VLAN: a > spoke PW behaves like root/leaf AC for a PE-r. > > But the same problem may also apply to the root/spoke "core PW" for > Multi-PW: > According to Multi-PW, only one PW is required between two PEs except > when both PEs are mixed with root and leaf, so these PWs may be formed > by combinations of the following unidirectional PW cases (extracted and > adapted from Josh's email): > Root-only -> any VSI =3D one root PW > Leaf-only -> root-only =3D one leaf PW > Leaf-only -> mixed =3D one leaf PW > Mixed -> root-only =3D one (root+leaf) PW > Mixed -> leaf-only =3D one (root+leaf) PW > > I have a concern that the forwarding plane of PE to implement this will > be very different from the traditional VPLS. > > Regards, > Yuanlong > > -----Original Message----- > From: Daniel Cohn [mailto:DanielC@orckit.com] > Sent: Monday, May 14, 2012 5:00 PM > To: Jiangyuanlong; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > Like I wrote below, root/leaf spoke PW behave like root/leaf AC, not > like root/spoke "core PW". So no changes to forwarding plane once this > is understood. > > DC > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Monday, May 14, 2012 11:36 AM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Daniel, please see my comments in line. > > -----Original Message----- > From: Daniel Cohn [mailto:DanielC@orckit.com] > Sent: Monday, May 14, 2012 3:37 PM > To: Jiangyuanlong; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > As I see it, for the PE-r spoke (figure 4 in RFC 4762) we establish a > single PW per AC - root PW for root AC and leaf PW for leaf AC. With > local configuration at the PE-rs as part of the spoke PW provisioning. > And the PE-rs will treat root/leaf spoke PWs exactly as it treat > root/leaf ACs. So when leaf-originated BUM traffic arrives from the > core (over a leaf PW), it will be forwarded over all root spoke PWs but > not on the leaf spoke PWs. > > [JY] So in the reverse direction, you need to transport both root and > leaf traffic from PE-rs over a root PW to PE-r, and transport root > traffic over a leaf PW. It seems against the definition of root PW and > leaf PW in the multi-PW draft. Don't this make the forwarding plane of > PE-rs more complex? > > The forwarding plane is exactly the same as described in the multi-PW > draft, where spoke PWs are treated exactly like ACs. > > Regards, > > Daniel > > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Friday, May 11, 2012 5:03 AM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Daniel and all, > > When you set up two PWs from the PE-rs to a PE-r for each of its AC, do > you mean that one PW is bidirectional root PW and the other is > bidirectional leaf PW? > My concern is: where should the leaf traffic be filtered, on the PE-rs > or on the PE-r? > If filtered on the PE-r, then lots of bandwidth will be wasted (for > example, if the PE-r is attached with 9 leafs, then the BUM traffic > from one of its leafs will be multiplied by 8 times, and be forwarded > by the PE-rs to the same PE-r). > If filtered on the PE-rs, not sure how you will design its forwarding > plane, can you give a hint? > > Thanks, > Yuanlong > > ------------------------------ > Date: Wed, 9 May 2012 09:16:36 +0300 > From: "Daniel Cohn" > To: "Alexander Vainshtein" , "Sam > Cao" , > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780CBA6@tlvmail1> > Content-Type: text/plain; charset=3D"ISO-2022-JP" > > Hi Sasha, > > It's actually very simple. A frame that originated in a root AC is > always transmitted only in root PW, no matter what the frame type > (known/unknown unicast or broadcast). This is how the frame source > information is propagated across the VPLS. So in the H-VPLS example, > the PE-r will never forward a frame received over a root PW on any leaf > PW, only on root PWs (toward the core or toward other spokes). > > Hope this clarifies it, regards, > > Daniel > > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Alexander Vainshtein > Sent: Wednesday, May 09, 2012 7:59 AM > To: Sam Cao; l2vpn@ietf.org > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > > Sam, Lizhong and all, > You've written that in the two-PW solution combined with H-VPLS the PE- > r must set up two PWs with each MTU-s. > > If this is the case, what kind of forwarding logic should be used to > prevent sending a BUM frame received from a root-PW to a given MTU-S: > - back to the same MTU-S on the corresponding leaf-PW? > - twice (to both root-PW and Leaf-PW) to another MTU-s? And, BTW, how > is the PW selected in this case? > > I am aware of a technique of multiple split horizon groups in PE-r > which could be possibly used for this purpose. However, since these > groups have to be represented explicitly in the data plane, their > potential number is limited by the forwarding HW. Other methods could > be probably used for the same purpose, but they would probably subject > to similar HW-based limitations. > > I suspect that with the dual-PW approach, the HW would pose an implicit > limit, say, on a number of MTU-s that can be connected to the same PE-r > and that this limit could be quite low in most cases. > > Based on this I suspect that the H-VPLS issue as a critical drawback of > the dual-PW approach to E-Tree. > > My 2c, > Sasha > > > ________________________________________ > From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Sam > Cao [yuqun.cao@gmail.com] > Sent: Wednesday, May 09, 2012 3:40 AM > To: l2vpn@ietf.org > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Lizhong? > > Thank you very much for your comments. I updated the result on this > question. > > [Lizhong] agree with the above analysis. And we did not say it is a > technical problem, but it is an operational problem again. > [Sam] I agree. Dual-VLAN does not make sense. I also discussed this > with Giles and Yuanlong in another mail, and we reached agreement on > this: > MTU should know the access mode, VPWS or VPLS, VPWS mode should > configure VLAN ID on MTU but VPLS mode can not. I thought this is NOT > reasonable :), but we can figure this out in draft. It seems ok. > > [Lizhong] not fully understand. Do you mean, when VPWS accessing for > H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf > PW) for each AC access? > [Sam] Yes. > > Thanks, > > Sam > > > > From jiangyuanlong@huawei.com Tue May 15 23:35: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 BCAD621F86A0 for ; Tue, 15 May 2012 23:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.179 X-Spam-Level: X-Spam-Status: No, score=-4.179 tagged_above=-999 required=5 tests=[AWL=1.820, BAYES_00=-2.599, J_CHICKENPOX_23=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 s8sJrRFLVCyH for ; Tue, 15 May 2012 23:35:28 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0C021F86BE for ; Tue, 15 May 2012 23:35: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 AFY75966; Wed, 16 May 2012 02:35:25 -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; Tue, 15 May 2012 23:32:03 -0700 Received: from SZXEML437-HUB.china.huawei.com (10.72.61.72) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 15 May 2012 23:32:02 -0700 Received: from SZXEML546-MBS.china.huawei.com ([169.254.4.75]) by szxeml437-hub.china.huawei.com ([10.72.61.72]) with mapi id 14.01.0323.003; Wed, 16 May 2012 14:31:48 +0800 From: Jiangyuanlong To: Sam Cao , Lucy yong , 'David Allan I' , "'Balus, Florin Stelian (Florin)'" , 'Daniel Cohn' , 'Alexander Vainshtein' Subject: RE: Discussion on forwarding performance Thread-Topic: Discussion on forwarding performance Thread-Index: AQHNMp8ego9/CtMoakapN2JoMtGUPZbKvTGAgAAAzYCAAAV4AIAAYvAAgACKNECAABTmwIAALuwA Date: Wed, 16 May 2012 06:31:48 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413A84@szxeml546-mbs.china.huawei.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D411694@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF5C@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D4130E1@szxeml546-mbs.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF8F@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413216@szxeml546-mbs.china.huawei.com> <3F1F3739E2B04D399CC7D26CE934F91A@v2comsam> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413694@szxeml546-mbs.china.huawei.com> <7A564821DF1642E592E884D5C623772C@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D41370E@szxeml546-mbs.china.huawei.com> <400D5D93E6AA4075861CE09919D84747@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413741@szxeml546-mbs.china.huawei.com> <7BDA456234D045E1BD42EA059A4E9579@v2comsam> <2073A6C5467C99478898544C6EBA3F4602C1907568@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> <60C093A41B5E45409A19D42CF7786DFD52328D98DF@EUSAACMS0703.eamcs.ericsson.se> <1A7E043E03FF48A2B3E5ECCD4F124B4C@R01842> <3B0A1BED2 2CAD649A1B3E97BE5DDD6 8B1D41394A@szxeml546-mbs.china.huawei.com> <7F31E97F973E4F339E0DF43D08C2EBF9@R01842> In-Reply-To: <7F31E97F973E4F339E0DF43D08C2EBF9@R01842> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.40.73] 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, 16 May 2012 06:35:33 -0000 What is the meaning of compare IP forwarding vs. VPLS forwarding? Both Dual= -VLAN and Multi-PW approach reuse the VPLS forwarding and have nothing to d= o with IP forwarding. Did I miss something? -----Original Message----- From: Sam Cao [mailto:yuqun.cao@gmail.com]=20 Sent: Wednesday, May 16, 2012 12:06 PM To: Jiangyuanlong; Lucy yong; 'David Allan I'; 'Balus, Florin Stelian (Flor= in)'; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance Yuanlong, I have no NP implementation either for Dual-VLAN or Multi-PW since there is no resource on this :). This is just my guess on software side, not accurat= e data. I shared my tester experience data on IP frame forwarding with VPLS frame forwarding. In back-to-back topology: VPLS frame forwarding performance is about 80% of IP frame forwarding performance. Yuanlong, I think you also have such data since you have experience on NP and developers should care this. Again, if work on chip, we can ignore site effect on forwarding performance. Maybe we can improve software architecture, but I guess there is a little side effect on Multi-PW, but more on Dual-VLAN. Yuanlong, Is there any authoritative data on this? Anyway, if we need, I want to ask some co-workers to get the forwarding difference between IP forwarding and VPLS forwarding on some vendor's routers, but it needs a little time and human resource^_^. Sam -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Wednesday, May 16, 2012 10:46 AM To: Sam Cao; Lucy yong; 'David Allan I'; 'Balus, Florin Stelian (Florin)'; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance See my comments in line. -----Original Message----- From: Sam Cao [mailto:yuqun.cao@gmail.com]=20 Sent: Wednesday, May 16, 2012 10:09 AM To: Lucy yong; 'David Allan I'; 'Balus, Florin Stelian (Florin)'; Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance Lucy/David/Florin, Thank you very much for your comments.=20 I can not give the accurate data to support my conclusion, and just conclud= e that if we implement it in NP module. Except for common operations of 2 approaches, Tunnel Label push/pop-out, MAC-based forwarding, and etc., Dual-VLAN needs one more VLAN push/pop-out operation while forwarding every frame. So compared with Multi-PW, it needs more resource and time for NP module if there are VSIs or PWs up limit to the capacity on one PE, and standing on software architect's side, the performance will be decreased by at least 20%, I guess. I implemented one prototype which has similar solution as current Multi-PW, and the performance will be decreased by 5%, compared with traditional VPLS. Daniel has experience on 2-PW deployment, maybe he can give accurate data on Multi-PW. [JY] So you have no NP implementation either for Dual-VLAN or Multi-PW... but why do you think the performance will be decreased by at least 20%? I also have some experiences in NP programming, it must be a big surprise that one more VLAN push/pop-out operation will incur a penalty of performance degradation of 20%.=20 Florin, do you mean that you have implemented E-Tree in MPLS network? If chipset can support this and we don't care NP or other solutions, yes, we can ignore any side effect on forwarding performance. Yes, it can support E-tree in IP (Ethernet) network, but I read some CHIP datasheets, after strip PW label out, chip can not handle 2 VLAN IDs at same time. Could you please give me some hints, say, which chip you used? [JY] the chip doesn't need to handle 2 VLAN IDs at same time, see the previous msg: http://www.ietf.org/mail-archive/web/l2vpn/current/msg03392.html Maybe if we raised only one issue in one mail, we can get more and insight comments :). I will raise another after we agree with this in the main :).= =20 Thanks, Sam -----Original Message----- From: Lucy yong [mailto:lucy.yong@huawei.com]=20 Sent: Wednesday, May 16, 2012 4:15 AM To: David Allan I; Balus, Florin Stelian (Florin); Sam Cao; Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance +1 We can't just make a conclusion from nowhere. Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of David Allan I Sent: Tuesday, May 15, 2012 2:55 PM To: Balus, Florin Stelian (Florin); Sam Cao; Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance Florin: I agree. The statement, at least to me, is a non-sequitor... Cheers Dave -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Balus, Florin Stelian (Florin) Sent: Tuesday, May 15, 2012 12:53 PM To: Sam Cao; 'Jiangyuanlong'; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance Sam, > Obviously the forwarding performance of Dual-VLAN will be much lower than what of Multi-PW. Sorry I could not keep up with some of the threads on this subject but the above statement caught my eyes. We have been doing all kind of egress operations on VLANs in the egress PE for the last 8 years and I am not awar= e of any "much lower" forwarding performance. As far as I know the chipsets used in the PEs can do this processing no problem. Do you want to clarify which kind of hardware may have problems? > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Sam Cao > Sent: Tuesday, May 15, 2012 6:32 AM > To: 'Jiangyuanlong'; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on forwarding performance > > Hi Yuanlong, > > 3rd mapping will make data plane complex, I think. Anyway, we reached > a consensus on Multi-PW implementation. > > If we use 3rd mapping, I agree with your opinion, maybe dual-VLAN > seems simple, but 2 mapping is enough. Then we can focus on data plane > performance. While stripe PW label out on egress PE, data-plane knows > how to forward the frames from PW, to Root AC or Leaf AC or all. But > if we use Dual-VLAN, after strip PW label out, data plane should strip > VLAN-ID out and then does same forwarding work as Multi-PW does. The > most important is, do one more operation while forwarding E-Tree > frames. Obviously the forwarding performance of Dual-VLAN will be much > lower than what of Multi-PW. > > Regards, > > Yuqun (Sam) Cao > E-mail: Yuqun.cao@gmail.com > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 7:03 PM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > See my further comments in line. > > -----Original Message----- > From: Sam Cao [mailto:yuqun.cao@gmail.com] > Sent: Tuesday, May 15, 2012 6:14 PM > To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > Thank you very much for your comments. I draw the topology you gave, > and 7 PWs will be established if we follow 01. > > Root AC ---- PE 1 ----- PW 1 -------- PE 2 ----- Leaf _AC > | \ / || > | \ /=3D=3D=3DPW 6,7=3D=3D=3D || > PW 2 -----PW 5------\ || > | /----Root PW 3 --- \ || > Root _AC ---- PE 3 PE 4 ------ Root AC > | \ / | > | ----Leaf PW 4----- | > Leaf AC Leaf AC > Yes, on PE 3 there are several PWs, but if you want to clarify it, > there are only 3 types, one can carry frames originated from Root and > Leaf AC(one endpoint of this PW should be Root-only, otherwise this is > invalid), one only can carry frames from Root AC, and the last can > carry frames from Leaf ACs. On second thoughts, we still can classify > the PWs into 2 sets, one is Leaf set, and another is Root set, and the > union of the sets Leaf and Root is the PW we called it as compatible > PW (Maybe this is not correct, we can find one good term on this). > > So this optimization still follows the original design of Dual-PW > approach, Leaf PW only carries frames from Leaf AC; Root-PW only > carries frames from Root AC. Is it right? > > I don't know whether chip can support this forwarding behavior for > compatible PW or not, but if we implement it in NP, it is nearly same > as VPLS. The only difference is, setup 2 mappings, one between > Leaf-ACs and Leaf-PWs, one between Root-ACs and Root-PWs. For > traditional VPLS, there is only one mapping. > > [JY] It seems you may need a 3rd mapping: from both root & leaf AC to > a compatible PW. > BTW, for the forwarding and reverse direction, the mapping may be > asymmetric for you compatible PW. > > Based on my understanding, all drafts should have similar mapping. > > [JY] Dual-VLAN seems simpler here. > > Thanks, > > Sam > > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 3:32 PM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Sam, > > Thanks, please see my further comments with [JY]. > > Ok, we go on the case in your mail, where PE1 has one Root-only AC, > AC1, and > PE2 has one Leaf-only AC, AC2. In general we can setup 2 > "unidirectional" > PWs (bidirectional PW, but just carry unidirectional frames), Root-PW > which carries frames originated from AC1 and Leaf-PW which carries > frames originated from AC2. But only one PW also can work, just as > some members commented. Ok, we setup one PW between PE1 and PE2, we > can call this PW as compatible PW or something else. Frames originated > from Root or leaf ACs will be carried via this PW. Its forwarding > behavior is fully same as what traditional VPLS did, MAC learning on > AC or PW in one E-Tree. Or say, if one PE has Root-only ACs, it will > setup one PW with another PE, Root-only, Leaf-only or Root-Leaf-Mixed. > If 2 PEs are root-Leaf-Mixed or other cases, then 2 PWs will be > established. As you know, this can be done on control plane. > > [JY] Assume there are 2 other nodes PE3 & PE4 in this network > scenario, and both PE3 and PE4 have both root and leaf ACs, then there > are compatible PWs from PE3 which may carry both root and leaf traffic > (to PE1), which may carry only root traffic (to PE2); and further > there are root PW and leaf PW to PE4. Thus, the VSI on PE3 has at > least 4 different types of PW transmitting behaviours with regard to > the E-Tree traffic. In the reverse direction, the VSI on PE3 further > has at least > 4 different types of PW receiving behaviours. Not sure how you will > accommodate for these PWs in both the data plane and control plane. > > Regards, > Yuanlong > > Is this clear for you? Is this necessary to optimize PW setup in this > case? > > Maybe we need to add one paragraph on forwarding behavior. > > Again thank you very much for your comments, > > Sam > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 10:27 AM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Please see my comments in line. > > -----Original Message----- > From: Sam Cao [mailto:yuqun.cao@gmail.com] > Sent: Monday, May 14, 2012 8:31 PM > To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > We have discussed this in another thread. In fact, Daniel or I have > given the answers to the questions you raised here for several time :). > If we do in this way, we will reach deadlock and can not move forward > :). I try to explain it again. > > [JY] I will apologize if you had ever provided such answers before, > and you may just refer to the links rather than repeat the explanation. > As you can see, I just try to understand the mechanism of 2PW and its > implications, but the I-D does not include enough information. > > As you know, initial design we will setup 2 PWs all the time (if do in > this way, I think that you have no question), > > [JY] I will be concerned with the operational complexity of this > approach. > > but in most cases 2 PWs are not > necessary. So in 01 version, we optimize it. > > "Root-only VSI <-> any VSI: only root PW required" > "Leaf-only VSI <-> leaf-only VSI: no PWs required" > > In other cases 2 PWs are needed. If so, "Leaf-only -> root-only =3D one > leaf PW" is not correct: On Leaf-only side, yes, one Leaf-only PW is > created between Local Leaf type with remote Root type; on root-only > side, one root-only PW is created. Maybe it is better to call this as > compatible or mixed PW. So the left items you list are not correct for > multi_PW solution. > > [JY] This is something new, right? To be honest, I could not > understand what is your point: doesn't the mixed PW as you called also > consist of one Leaf-only PW in one direction and one root-only PW in > the other direction? > Furthermore, the case you took is also one case in your guideline > "Root-only VSI <-> any VSI: only root PW required", don't you think > that only one root PW is required following this guideline? > Actually, I don't care much about what is the bidirectional PW or > unidirectional PW called, but how can a VSI support such a mixed > scenarios: > traditional VSI assumes only one PW is required for each peer VSI, and > its MAC leaning is based on bidirectional PW. But for 2PW, there are > bidirectional root PW, bidirectional leaf PW, mixed PW, etc..., how to > support these kinds of PWs in the same VSI is my top concern. > > BTW, I guess you also care this case we also have discussed before: > for example, if we configure one Leaf AC on root-only PE (then it will > be root-leaf-mixed PE), we will teardown the compatible PW and > re-setup PWs again with 01. > [JY] This was discussed in the emails indeed. > > Regards, > > Yuqun (Sam) Cao > E-mail: Yuqun.cao@gmail.com > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Monday, May 14, 2012 7:10 PM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Daniel, > > Fine, now it seems more in line with what we had proposed in 2VLAN: a > spoke PW behaves like root/leaf AC for a PE-r. > > But the same problem may also apply to the root/spoke "core PW" for > Multi-PW: > According to Multi-PW, only one PW is required between two PEs except > when both PEs are mixed with root and leaf, so these PWs may be formed > by combinations of the following unidirectional PW cases (extracted > and adapted from Josh's email): > Root-only -> any VSI =3D one root PW > Leaf-only -> root-only =3D one leaf PW > Leaf-only -> mixed =3D one leaf PW > Mixed -> root-only =3D one (root+leaf) PW Mixed -> leaf-only =3D one > (root+leaf) PW > > I have a concern that the forwarding plane of PE to implement this > will be very different from the traditional VPLS. > > Regards, > Yuanlong > > -----Original Message----- > From: Daniel Cohn [mailto:DanielC@orckit.com] > Sent: Monday, May 14, 2012 5:00 PM > To: Jiangyuanlong; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > Like I wrote below, root/leaf spoke PW behave like root/leaf AC, not > like root/spoke "core PW". So no changes to forwarding plane once this > is understood. > > DC > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Monday, May 14, 2012 11:36 AM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Daniel, please see my comments in line. > > -----Original Message----- > From: Daniel Cohn [mailto:DanielC@orckit.com] > Sent: Monday, May 14, 2012 3:37 PM > To: Jiangyuanlong; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > As I see it, for the PE-r spoke (figure 4 in RFC 4762) we establish a > single PW per AC - root PW for root AC and leaf PW for leaf AC. With > local configuration at the PE-rs as part of the spoke PW provisioning. > And the PE-rs will treat root/leaf spoke PWs exactly as it treat > root/leaf ACs. So when leaf-originated BUM traffic arrives from the > core (over a leaf PW), it will be forwarded over all root spoke PWs > but not on the leaf spoke PWs. > > [JY] So in the reverse direction, you need to transport both root and > leaf traffic from PE-rs over a root PW to PE-r, and transport root > traffic over a leaf PW. It seems against the definition of root PW and > leaf PW in the multi-PW draft. Don't this make the forwarding plane of > PE-rs more complex? > > The forwarding plane is exactly the same as described in the multi-PW > draft, where spoke PWs are treated exactly like ACs. > > Regards, > > Daniel > > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Friday, May 11, 2012 5:03 AM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Daniel and all, > > When you set up two PWs from the PE-rs to a PE-r for each of its AC, > do you mean that one PW is bidirectional root PW and the other is > bidirectional leaf PW? > My concern is: where should the leaf traffic be filtered, on the PE-rs > or on the PE-r? > If filtered on the PE-r, then lots of bandwidth will be wasted (for > example, if the PE-r is attached with 9 leafs, then the BUM traffic > from one of its leafs will be multiplied by 8 times, and be forwarded > by the PE-rs to the same PE-r). > If filtered on the PE-rs, not sure how you will design its forwarding > plane, can you give a hint? > > Thanks, > Yuanlong > > ------------------------------ > Date: Wed, 9 May 2012 09:16:36 +0300 > From: "Daniel Cohn" > To: "Alexander Vainshtein" , "Sa= m > Cao" , > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780CBA6@tlvmail1> > Content-Type: text/plain; charset=3D"ISO-2022-JP" > > Hi Sasha, > > It's actually very simple. A frame that originated in a root AC is > always transmitted only in root PW, no matter what the frame type > (known/unknown unicast or broadcast). This is how the frame source > information is propagated across the VPLS. So in the H-VPLS example, > the PE-r will never forward a frame received over a root PW on any > leaf PW, only on root PWs (toward the core or toward other spokes). > > Hope this clarifies it, regards, > > Daniel > > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Alexander Vainshtein > Sent: Wednesday, May 09, 2012 7:59 AM > To: Sam Cao; l2vpn@ietf.org > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > > Sam, Lizhong and all, > You've written that in the two-PW solution combined with H-VPLS the > PE- r must set up two PWs with each MTU-s. > > If this is the case, what kind of forwarding logic should be used to > prevent sending a BUM frame received from a root-PW to a given MTU-S: > - back to the same MTU-S on the corresponding leaf-PW? > - twice (to both root-PW and Leaf-PW) to another MTU-s? And, BTW, how > is the PW selected in this case? > > I am aware of a technique of multiple split horizon groups in PE-r > which could be possibly used for this purpose. However, since these > groups have to be represented explicitly in the data plane, their > potential number is limited by the forwarding HW. Other methods could > be probably used for the same purpose, but they would probably subject > to similar HW-based limitations. > > I suspect that with the dual-PW approach, the HW would pose an > implicit limit, say, on a number of MTU-s that can be connected to the > same PE-r and that this limit could be quite low in most cases. > > Based on this I suspect that the H-VPLS issue as a critical drawback > of the dual-PW approach to E-Tree. > > My 2c, > Sasha > > > ________________________________________ > From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Sam > Cao [yuqun.cao@gmail.com] > Sent: Wednesday, May 09, 2012 3:40 AM > To: l2vpn@ietf.org > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Lizhong? > > Thank you very much for your comments. I updated the result on this > question. > > [Lizhong] agree with the above analysis. And we did not say it is a > technical problem, but it is an operational problem again. > [Sam] I agree. Dual-VLAN does not make sense. I also discussed this > with Giles and Yuanlong in another mail, and we reached agreement on > this: > MTU should know the access mode, VPWS or VPLS, VPWS mode should > configure VLAN ID on MTU but VPLS mode can not. I thought this is NOT > reasonable :), but we can figure this out in draft. It seems ok. > > [Lizhong] not fully understand. Do you mean, when VPWS accessing for > H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf > PW) for each AC access? > [Sam] Yes. > > Thanks, > > Sam > > > > From Alexander.Vainshtein@ecitele.com Tue May 15 23:42: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 A16F621F8678 for ; Tue, 15 May 2012 23:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, 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 ja5ooRpKDtD0 for ; Tue, 15 May 2012 23:42: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 5975521F8674 for ; Tue, 15 May 2012 23:42:50 -0700 (PDT) Received: from [85.158.143.99:44976] by server-1.bemta-4.messagelabs.com id A1/83-20925-96C43BF4; Wed, 16 May 2012 06:42:49 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1337150568!22942548!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.5.10; banners=-,-,- Received: (qmail 2090 invoked from network); 16 May 2012 06:42:48 -0000 Received: from unknown (HELO fridlppsb001.ecitele.com) (168.87.1.157) by server-4.tower-216.messagelabs.com with SMTP; 16 May 2012 06:42:48 -0000 X-AuditID: a8571401-b7f876d00000476f-30-4fb34d02e81c Received: from FRIDWPPCH001.ecitele.com (fridwppch001.ecitele.com [10.1.16.52]) by fridlppsb001.ecitele.com (Symantec Messaging Gateway) with SMTP id 37.51.18287.20D43BF4; Wed, 16 May 2012 08:45:22 +0200 (CEST) Received: from FRIDWPPMB001.ecitele.com ([169.254.3.187]) by FRIDWPPCH001.ecitele.com ([10.1.16.52]) with mapi id 14.01.0339.001; Wed, 16 May 2012 08:42:47 +0200 From: Alexander Vainshtein To: Daniel Cohn , "Balus, Florin Stelian (Florin)" , Sam Cao , Jiangyuanlong Subject: RE: Discussion on forwarding performance Thread-Topic: Discussion on forwarding performance Thread-Index: AQHNLxo31u2OjZw96UuBF9QPOwJXg5bHcLkAgAGHLZCAAAmjYIAAHGPggAAUqSCAAOHDIIAAM7tggAAlyMCAADHVIIAAElJAgAAmSSCAAGzc8IAAspUAgAAH+MA= Date: Wed, 16 May 2012 06:42:46 +0000 Message-ID: References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D411694@szxeml546-mbx.china.huawei.com><44F4E579A764584EA9BDFD07D0CA08130780CF5C@tlvmail1><3B0A1BED22CAD649A1B3E97BE5DDD68B1D4130E1@szxeml546-mbs.china.huawei.com><44F4E579A764584EA9BDFD07D0CA08130780CF8F@tlvmail1><3B0A1BED22CAD649A1B3E97BE5DDD68B1D413216@szxeml546-mbs.china.huawei.com><3F1F3739E2B04D399CC7D26CE934F91A@v2comsam><3B0A1BED22CAD649A1B3E97BE5DDD68B1D413694@szxeml546-mbs.china.huawei.com><7A564821DF1642E592E884D5C623772C@R01842><3B0A1BED22CAD649A1B3E97BE5DDD68B1D41370E@szxeml546-mbs.china.huawei.com><400D5D93E6AA4075861CE09919D84747@R01842><3B0A1BED22CAD649A1B3E97BE5DDD68B1D413741@szxeml546-mbs.china.huawei.com> <7BDA456234D045E1BD42EA059A4E9579@v2comsam> <2073A6C5467C99478898544C6EBA3F4602C1907568@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> <44F4E579A764584EA9BDFD07D0CA08130780D1AB@tlvmail1> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA08130780D1AB@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: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2VTa2wMURh1Z2Z3p9VhjNZeq2Ezgnhs7dZrSLcq9WNFmm2KCJEw3b12h93Z sTMa2yCrnm1VCJF0G49SlIpKG496xkaVhqBar6g3iUpFiFcIZgxVMb/Oveec79zv3m9InFlr spCCqKCwyAdYYyKRCHpYbFhOvdt+/PVQLtqyF+NqtrWYuLa3643cs49xE7dj9TVjlsG19uVZ g6sh1m5yrbnYaXBVVX3BXKVHt+K5hrlRkMGLYkjhFWT1ItnjZHPDQgHvibBWwetkHaxVCvAe FESi4mR5SUKil81MtP73ZagyQbQi0RPyCqLPyU6b4bZx3LiJNgebOdMvyFZkC/JCwBpEssz7 kFXd0XoRvQuO4P73q1oJ6fJ2sKyo6QkeBeVKCUggIT0Wfr54Fei4H7zxsNZYAhJJhm4F8Pzj vUBf7ANwy4c3Bk1lpJ2wrqbdqOFk+hiA0Y+DNYzTQ+CaunO/KvWlHbCxuMKga9LhiZp9uFYo mS4BsOPFKkwjCNXwoLIZ1zBF58BHTTd/mRm61ATL2vI0nEBnwR9NBwkNA/V4n5oPY3qYGd5/ vgvTj03DqjPXcR2nwFfPvht0PBAWHWw16fpRcPfpd0Ydj4T7K1//zu0Dr5Q/J3R9f3ih+i6x GZhj3SJi3eyxbvZYN/tuQBwC5oVhwStJcr7d7khDHkFBAZTmCQXrgDpG1bOTwUnwtCwtDmgS sEkUV1znZgx8gRwJxkF/EmNTqIJp9W6mV37IG/Hzsn9+eGkAyXEASZxNpqa+UOWUl48UonDo D8Wpd7gFt/T0hLRHVuaPsdv/WbBmqjYv083QPnXyFiMkofAfaypJspAqnK4m9gkjH1q2UAgo f2mMTNCSk9TkJZqGkiU+KAs+nW8GI8lvT/bcBuSmp4dvA4YQQyKymPVytCb1LxW7qnUAs9px X2q5xiap89hVp0ONwNSIgqDWnKz+H12UJQpqT90bNP5op3Qur/ZMzjXTm4xgBdb5YSPKjsxo qkmPFKc0TK6wJbUtOjR2kpj/KbV+QOr2YZOzv5bkThjIXGi0K6PTJ21Y0Zv8eqvfvPZhBxqz 1i9pKE2/kzYnGxb1XNlyYG5ZfIrL1NxhC3haLn1eZzkNCitXVszamTOcOba8ekpbPkvIft4x Ag/L/E/xYXn/GAQAAA== 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, 16 May 2012 06:42:52 -0000 Daniel, and all, I am not sure that discussion of implementation-specific issues (e.g., wheth= er you use or do not use TCAM lookups) really belongs to this list. Regards, Sasha > -----Original Message----- > From: Daniel Cohn [mailto:DanielC@orckit.com] > Sent: Wednesday, May 16, 2012 9:16 AM > To: Balus, Florin Stelian (Florin); Sam Cao; Jiangyuanlong; Alexander > Vainshtein > Cc: l2vpn@ietf.org > Subject: RE: Discussion on forwarding performance > > Hi, > > I agree that for a chip-based solution there should be no difference in > performance for the additional lookup. However from conversations with > chip vendors, I understood there might be an impact on scalability > because the double lookup would require a longer search key (assuming > VLAN and VCID lookups are performed simultaneously on ingress), thus > taking up more TCAM resources per E-Tree instance. This would depend on > specific TCAM implementation (e.g. granularity of search key length). > > DC > > -----Original Message----- > From: Balus, Florin Stelian (Florin) > [mailto:florin.balus@alcatel-lucent.com] > Sent: Tuesday, May 15, 2012 10:53 PM > To: Sam Cao; 'Jiangyuanlong'; Daniel Cohn; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on forwarding performance > > Sam, > > > Obviously the forwarding performance of Dual-VLAN will be much lower > than what of Multi-PW. > > Sorry I could not keep up with some of the threads on this subject but > the above statement caught my eyes. We have been doing all kind of > egress operations on VLANs in the egress PE for the last 8 years and I > am not aware of any "much lower" forwarding performance. As far as I > know the chipsets used in the PEs can do this processing no problem. Do > you want to clarify which kind of hardware may have problems? > > > -----Original Message----- > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > > Of Sam Cao > > Sent: Tuesday, May 15, 2012 6:32 AM > > To: 'Jiangyuanlong'; 'Daniel Cohn'; 'Alexander Vainshtein' > > Cc: l2vpn@ietf.org > > Subject: RE: Discussion on forwarding performance > > > > Hi Yuanlong, > > > > 3rd mapping will make data plane complex, I think. Anyway, we reached > a > > consensus on Multi-PW implementation. > > > > If we use 3rd mapping, I agree with your opinion, maybe dual-VLAN > seems > > simple, but 2 mapping is enough. Then we can focus on data plane > > performance. While stripe PW label out on egress PE, data-plane knows > > how to forward the frames from PW, to Root AC or Leaf AC or all. But > if > > we use Dual-VLAN, after strip PW label out, data plane should strip > > VLAN-ID out and then does same forwarding work as Multi-PW does. The > > most important is, do one more operation while forwarding E-Tree > > frames. Obviously the forwarding performance of Dual-VLAN will be much > > lower than what of Multi-PW. > > > > Regards, > > > > Yuqun (Sam) Cao > > E-mail: Yuqun.cao@gmail.com > > > > -----Original Message----- > > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > > Sent: Tuesday, May 15, 2012 7:03 PM > > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > > Cc: l2vpn@ietf.org > > Subject: RE: Discussion on E-Tree and H-VPLS > > > > See my further comments in line. > > > > -----Original Message----- > > From: Sam Cao [mailto:yuqun.cao@gmail.com] > > Sent: Tuesday, May 15, 2012 6:14 PM > > To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' > > Cc: l2vpn@ietf.org > > Subject: RE: Discussion on E-Tree and H-VPLS > > > > Hi Yuanlong, > > > > Thank you very much for your comments. I draw the topology you gave, > > and 7 PWs will be established if we follow 01. > > > > Root AC ---- PE 1 ----- PW 1 -------- PE 2 ----- Leaf _AC > > | \ / || > > | \ /=3D=3D=3DPW 6,7=3D=3D=3D || > > PW 2 -----PW 5------\ || > > | /----Root PW 3 --- \ || > > Root _AC ---- PE 3 PE 4 ------ Root AC > > | \ / | > > | ----Leaf PW 4----- | > > Leaf AC Leaf AC > > Yes, on PE 3 there are several PWs, but if you want to clarify it, > > there are only 3 types, one can carry frames originated from Root and > > Leaf AC(one endpoint of this PW should be Root-only, otherwise this is > > invalid), one only can carry frames from Root AC, and the last can > > carry frames from Leaf ACs. On second thoughts, we still can classify > > the PWs into 2 sets, one is Leaf set, and another is Root set, and the > > union of the sets Leaf and Root is the PW we called it as compatible > PW > > (Maybe this is not correct, we can find one good term on this). > > > > So this optimization still follows the original design of Dual-PW > > approach, Leaf PW only carries frames from Leaf AC; Root-PW only > > carries frames from Root AC. Is it right? > > > > I don't know whether chip can support this forwarding behavior for > > compatible PW or not, but if we implement it in NP, it is nearly same > > as VPLS. The only difference is, setup 2 mappings, one between > Leaf-ACs > > and Leaf-PWs, one between Root-ACs and Root-PWs. For traditional VPLS, > > there is only one mapping. > > > > [JY] It seems you may need a 3rd mapping: from both root & leaf AC to > a > > compatible PW. > > BTW, for the forwarding and reverse direction, the mapping may be > > asymmetric for you compatible PW. > > > > Based on my understanding, all drafts should have similar mapping. > > > > [JY] Dual-VLAN seems simpler here. > > > > Thanks, > > > > Sam > > > > > > -----Original Message----- > > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > > Sent: Tuesday, May 15, 2012 3:32 PM > > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > > Cc: l2vpn@ietf.org > > Subject: RE: Discussion on E-Tree and H-VPLS > > > > Sam, > > > > Thanks, please see my further comments with [JY]. > > > > Ok, we go on the case in your mail, where PE1 has one Root-only AC, > > AC1, and > > PE2 has one Leaf-only AC, AC2. In general we can setup 2 > > "unidirectional" > > PWs (bidirectional PW, but just carry unidirectional frames), Root-PW > > which carries frames originated from AC1 and Leaf-PW which carries > > frames originated from AC2. But only one PW also can work, just as > some > > members commented. Ok, we setup one PW between PE1 and PE2, we > can > call > > this PW as compatible PW or something else. Frames originated from > Root > > or leaf ACs will be carried via this PW. Its forwarding behavior is > > fully same as what traditional VPLS did, MAC learning on AC or PW in > > one E-Tree. Or say, if one PE has Root-only ACs, it will setup one PW > > with another PE, Root-only, Leaf-only or Root-Leaf-Mixed. If 2 PEs are > > root-Leaf-Mixed or other cases, then 2 PWs will be established. As you > > know, this can be done on control plane. > > > > [JY] Assume there are 2 other nodes PE3 & PE4 in this network > scenario, > > and both PE3 and PE4 have both root and leaf ACs, then there are > > compatible PWs from PE3 which may carry both root and leaf traffic (to > > PE1), which may carry only root traffic (to PE2); and further there > are > > root PW and leaf PW to PE4. Thus, the VSI on PE3 has at least 4 > > different types of PW transmitting behaviours with regard to the > E-Tree > > traffic. In the reverse direction, the VSI on PE3 further has at least > > 4 different types of PW receiving behaviours. Not sure how you will > > accommodate for these PWs in both the data plane and control plane. > > > > Regards, > > Yuanlong > > > > Is this clear for you? Is this necessary to optimize PW setup in this > > case? > > > > Maybe we need to add one paragraph on forwarding behavior. > > > > Again thank you very much for your comments, > > > > Sam > > > > -----Original Message----- > > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > > Sent: Tuesday, May 15, 2012 10:27 AM > > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > > Cc: l2vpn@ietf.org > > Subject: RE: Discussion on E-Tree and H-VPLS > > > > Please see my comments in line. > > > > -----Original Message----- > > From: Sam Cao [mailto:yuqun.cao@gmail.com] > > Sent: Monday, May 14, 2012 8:31 PM > > To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' > > Cc: l2vpn@ietf.org > > Subject: RE: Discussion on E-Tree and H-VPLS > > > > Hi Yuanlong, > > > > We have discussed this in another thread. In fact, Daniel or I have > > given the answers to the questions you raised here for several time > :). > > If we do in this way, we will reach deadlock and can not move forward > > :). I try to explain it again. > > > > [JY] I will apologize if you had ever provided such answers before, > and > > you may just refer to the links rather than repeat the explanation. > > As you can see, I just try to understand the mechanism of 2PW and its > > implications, but the I-D does not include enough information. > > > > As you know, initial design we will setup 2 PWs all the time (if do in > > this way, I think that you have no question), > > > > [JY] I will be concerned with the operational complexity of this > > approach. > > > > but in most cases 2 PWs are not > > necessary. So in 01 version, we optimize it. > > > > "Root-only VSI <-> any VSI: only root PW required" > > "Leaf-only VSI <-> leaf-only VSI: no PWs required" > > > > In other cases 2 PWs are needed. If so, "Leaf-only -> root-only =3D one > > leaf PW" is not correct: On Leaf-only side, yes, one Leaf-only PW is > > created between Local Leaf type with remote Root type; on root-only > > side, one root-only PW is created. Maybe it is better to call this as > > compatible or mixed PW. So the left items you list are not correct for > > multi_PW solution. > > > > [JY] This is something new, right? To be honest, I could not > understand > > what is your point: doesn't the mixed PW as you called also consist of > > one Leaf-only PW in one direction and one root-only PW in the other > > direction? > > Furthermore, the case you took is also one case in your guideline > > "Root-only VSI <-> any VSI: only root PW required", don't you think > > that only one root PW is required following this guideline? > > Actually, I don't care much about what is the bidirectional PW or > > unidirectional PW called, but how can a VSI support such a mixed > > scenarios: > > traditional VSI assumes only one PW is required for each peer VSI, and > > its MAC leaning is based on bidirectional PW. But for 2PW, there are > > bidirectional root PW, bidirectional leaf PW, mixed PW, etc..., how to > > support these kinds of PWs in the same VSI is my top concern. > > > > BTW, I guess you also care this case we also have discussed before: > for > > example, if we configure one Leaf AC on root-only PE (then it will be > > root-leaf-mixed PE), we will teardown the compatible PW and re-setup > > PWs again with 01. > > [JY] This was discussed in the emails indeed. > > > > Regards, > > > > Yuqun (Sam) Cao > > E-mail: Yuqun.cao@gmail.com > > > > -----Original Message----- > > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > > Sent: Monday, May 14, 2012 7:10 PM > > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > > Cc: l2vpn@ietf.org > > Subject: RE: Discussion on E-Tree and H-VPLS > > > > Hi Daniel, > > > > Fine, now it seems more in line with what we had proposed in 2VLAN: a > > spoke PW behaves like root/leaf AC for a PE-r. > > > > But the same problem may also apply to the root/spoke "core PW" for > > Multi-PW: > > According to Multi-PW, only one PW is required between two PEs except > > when both PEs are mixed with root and leaf, so these PWs may be formed > > by combinations of the following unidirectional PW cases (extracted > and > > adapted from Josh's email): > > Root-only -> any VSI =3D one root PW > > Leaf-only -> root-only =3D one leaf PW > > Leaf-only -> mixed =3D one leaf PW > > Mixed -> root-only =3D one (root+leaf) PW > > Mixed -> leaf-only =3D one (root+leaf) PW > > > > I have a concern that the forwarding plane of PE to implement this > will > > be very different from the traditional VPLS. > > > > Regards, > > Yuanlong > > > > -----Original Message----- > > From: Daniel Cohn [mailto:DanielC@orckit.com] > > Sent: Monday, May 14, 2012 5:00 PM > > To: Jiangyuanlong; Alexander Vainshtein; Sam Cao > > Cc: l2vpn@ietf.org > > Subject: RE: Discussion on E-Tree and H-VPLS > > > > Hi Yuanlong, > > > > Like I wrote below, root/leaf spoke PW behave like root/leaf AC, not > > like root/spoke "core PW". So no changes to forwarding plane once this > > is understood. > > > > DC > > > > -----Original Message----- > > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > > Sent: Monday, May 14, 2012 11:36 AM > > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > > Cc: l2vpn@ietf.org > > Subject: RE: Discussion on E-Tree and H-VPLS > > > > Daniel, please see my comments in line. > > > > -----Original Message----- > > From: Daniel Cohn [mailto:DanielC@orckit.com] > > Sent: Monday, May 14, 2012 3:37 PM > > To: Jiangyuanlong; Alexander Vainshtein; Sam Cao > > Cc: l2vpn@ietf.org > > Subject: RE: Discussion on E-Tree and H-VPLS > > > > Hi Yuanlong, > > > > As I see it, for the PE-r spoke (figure 4 in RFC 4762) we establish a > > single PW per AC - root PW for root AC and leaf PW for leaf AC. With > > local configuration at the PE-rs as part of the spoke PW provisioning. > > And the PE-rs will treat root/leaf spoke PWs exactly as it treat > > root/leaf ACs. So when leaf-originated BUM traffic arrives from the > > core (over a leaf PW), it will be forwarded over all root spoke PWs > but > > not on the leaf spoke PWs. > > > > [JY] So in the reverse direction, you need to transport both root and > > leaf traffic from PE-rs over a root PW to PE-r, and transport root > > traffic over a leaf PW. It seems against the definition of root PW and > > leaf PW in the multi-PW draft. Don't this make the forwarding plane of > > PE-rs more complex? > > > > The forwarding plane is exactly the same as described in the multi-PW > > draft, where spoke PWs are treated exactly like ACs. > > > > Regards, > > > > Daniel > > > > > > -----Original Message----- > > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > > Sent: Friday, May 11, 2012 5:03 AM > > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > > Cc: l2vpn@ietf.org > > Subject: RE: Discussion on E-Tree and H-VPLS > > > > Hi Daniel and all, > > > > When you set up two PWs from the PE-rs to a PE-r for each of its AC, > do > > you mean that one PW is bidirectional root PW and the other is > > bidirectional leaf PW? > > My concern is: where should the leaf traffic be filtered, on the PE-rs > > or on the PE-r? > > If filtered on the PE-r, then lots of bandwidth will be wasted (for > > example, if the PE-r is attached with 9 leafs, then the BUM traffic > > from one of its leafs will be multiplied by 8 times, and be forwarded > > by the PE-rs to the same PE-r). > > If filtered on the PE-rs, not sure how you will design its forwarding > > plane, can you give a hint? > > > > Thanks, > > Yuanlong > > > > ------------------------------ > > Date: Wed, 9 May 2012 09:16:36 +0300 > > From: "Daniel Cohn" > > To: "Alexander Vainshtein" , > "Sam > > Cao" , > > Cc: lizhong.jin@zte.com.cn > > Subject: RE: Discussion on E-Tree and H-VPLS > > Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780CBA6@tlvmail1> > > Content-Type: text/plain; charset=3D"ISO-2022-JP" > > > > Hi Sasha, > > > > It's actually very simple. A frame that originated in a root AC is > > always transmitted only in root PW, no matter what the frame type > > (known/unknown unicast or broadcast). This is how the frame source > > information is propagated across the VPLS. So in the H-VPLS example, > > the PE-r will never forward a frame received over a root PW on any > leaf > > PW, only on root PWs (toward the core or toward other spokes). > > > > Hope this clarifies it, regards, > > > > Daniel > > > > -----Original Message----- > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > > Of Alexander Vainshtein > > Sent: Wednesday, May 09, 2012 7:59 AM > > To: Sam Cao; l2vpn@ietf.org > > Cc: lizhong.jin@zte.com.cn > > Subject: RE: Discussion on E-Tree and H-VPLS > > > > Sam, Lizhong and all, > > You've written that in the two-PW solution combined with H-VPLS the > PE- > > r must set up two PWs with each MTU-s. > > > > If this is the case, what kind of forwarding logic should be used to > > prevent sending a BUM frame received from a root-PW to a given MTU-S: > > - back to the same MTU-S on the corresponding leaf-PW? > > - twice (to both root-PW and Leaf-PW) to another MTU-s? And, BTW, how > > is the PW selected in this case? > > > > I am aware of a technique of multiple split horizon groups in PE-r > > which could be possibly used for this purpose. However, since these > > groups have to be represented explicitly in the data plane, their > > potential number is limited by the forwarding HW. Other methods could > > be probably used for the same purpose, but they would probably subject > > to similar HW-based limitations. > > > > I suspect that with the dual-PW approach, the HW would pose an > implicit > > limit, say, on a number of MTU-s that can be connected to the same > PE-r > > and that this limit could be quite low in most cases. > > > > Based on this I suspect that the H-VPLS issue as a critical drawback > of > > the dual-PW approach to E-Tree. > > > > My 2c, > > Sasha > > > > > > ________________________________________ > > From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Sam > > Cao [yuqun.cao@gmail.com] > > Sent: Wednesday, May 09, 2012 3:40 AM > > To: l2vpn@ietf.org > > Cc: lizhong.jin@zte.com.cn > > Subject: RE: Discussion on E-Tree and H-VPLS > > > > Hi Lizhong? > > > > Thank you very much for your comments. I updated the result on this > > question. > > > > [Lizhong] agree with the above analysis. And we did not say it is a > > technical problem, but it is an operational problem again. > > [Sam] I agree. Dual-VLAN does not make sense. I also discussed this > > with Giles and Yuanlong in another mail, and we reached agreement on > > this: > > MTU should know the access mode, VPWS or VPLS, VPWS mode should > > configure VLAN ID on MTU but VPLS mode can not. I thought this is NOT > > reasonable :), but we can figure this out in draft. It seems ok. > > > > [Lizhong] not fully understand. Do you mean, when VPWS accessing for > > H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf > > PW) for each AC access? > > [Sam] Yes. > > > > Thanks, > > > > Sam > > > > > > > > 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 Tue May 15 23:46: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 3B3A421F87F1 for ; Tue, 15 May 2012 23:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.846 X-Spam-Level: * X-Spam-Status: No, score=1.846 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, 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 JY7m2p9P-AR6 for ; Tue, 15 May 2012 23:46:46 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id 28E7D21F86FE for ; Tue, 15 May 2012 23:46:45 -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, 16 May 2012 06:49:33 +0000 Date: Wed, 16 May 2012 09:46:41 +0300 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Subject: RE: Discussion on forwarding performance Thread-Topic: Discussion on forwarding performance Thread-Index: AQHNLxo31u2OjZw96UuBF9QPOwJXg5bHcLkAgAGHLZCAAAmjYIAAHGPggAAUqSCAAOHDIIAAM7tggAAlyMCAADHVIIAAElJAgAAmSSCAAGzc8IAAspUAgAAH+MCAAAIx8w== X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <20ab01cd3330$0ced2b69$05280101@corrigent.com> Importance: normal From: "Daniel Cohn" To: "Alexander Vainshtein" , "Balus, Florin Stelian (Florin)" , "Sam Cao" , "Jiangyuanlong" 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, 16 May 2012 06:46:48 -0000 Why not? Aren't ease of implementation and performance efficiency valid = considerations when selecting one solution over another?=0A= =0A= Thumb typed - please be tolerant=0A= =0A= Alexander Vainshtein wrote:=0A= =0A= Daniel, and all, I am not sure that discussion of implementation-specific issues (e.g., = whether you use or do not use TCAM lookups) really belongs to this list. Regards, Sasha > -----Original Message----- > From: Daniel Cohn [mailto:DanielC@orckit.com] > Sent: Wednesday, May 16, 2012 9:16 AM > To: Balus, Florin Stelian (Florin); Sam Cao; Jiangyuanlong; Alexander > Vainshtein > Cc: l2vpn@ietf.org > Subject: RE: Discussion on forwarding performance >=20 > Hi, >=20 > I agree that for a chip-based solution there should be no difference = in > performance for the additional lookup. However from conversations with > chip vendors, I understood there might be an impact on scalability > because the double lookup would require a longer search key (assuming > VLAN and VCID lookups are performed simultaneously on ingress), thus > taking up more TCAM resources per E-Tree instance. This would depend = on > specific TCAM implementation (e.g. granularity of search key length). >=20 > DC >=20 > -----Original Message----- > From: Balus, Florin Stelian (Florin) > [mailto:florin.balus@alcatel-lucent.com] > Sent: Tuesday, May 15, 2012 10:53 PM > To: Sam Cao; 'Jiangyuanlong'; Daniel Cohn; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on forwarding performance >=20 > Sam, >=20 > > Obviously the forwarding performance of Dual-VLAN will be much lower > than what of Multi-PW. >=20 > Sorry I could not keep up with some of the threads on this subject but > the above statement caught my eyes. We have been doing all kind of > egress operations on VLANs in the egress PE for the last 8 years and I > am not aware of any "much lower" forwarding performance. As far as I > know the chipsets used in the PEs can do this processing no problem. = Do > you want to clarify which kind of hardware may have problems? >=20 > > -----Original Message----- > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On = Behalf > > Of Sam Cao > > Sent: Tuesday, May 15, 2012 6:32 AM > > To: 'Jiangyuanlong'; 'Daniel Cohn'; 'Alexander Vainshtein' > > Cc: l2vpn@ietf.org > > Subject: RE: Discussion on forwarding performance > > > > Hi Yuanlong, > > > > 3rd mapping will make data plane complex, I think. Anyway, we = reached > a > > consensus on Multi-PW implementation. > > > > If we use 3rd mapping, I agree with your opinion, maybe dual-VLAN > seems > > simple, but 2 mapping is enough. Then we can focus on data plane > > performance. While stripe PW label out on egress PE, data-plane = knows > > how to forward the frames from PW, to Root AC or Leaf AC or all. But > if > > we use Dual-VLAN, after strip PW label out, data plane should strip > > VLAN-ID out and then does same forwarding work as Multi-PW does. The > > most important is, do one more operation while forwarding E-Tree > > frames. Obviously the forwarding performance of Dual-VLAN will be = much > > lower than what of Multi-PW. > > > > Regards, > > > > Yuqun (Sam) Cao > > E-mail: Yuqun.cao@gmail.com > > > > -----Original Message----- > > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > > Sent: Tuesday, May 15, 2012 7:03 PM > > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > > Cc: l2vpn@ietf.org > > Subject: RE: Discussion on E-Tree and H-VPLS > > > > See my further comments in line. > > > > -----Original Message----- > > From: Sam Cao [mailto:yuqun.cao@gmail.com] > > Sent: Tuesday, May 15, 2012 6:14 PM > > To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' > > Cc: l2vpn@ietf.org > > Subject: RE: Discussion on E-Tree and H-VPLS > > > > Hi Yuanlong, > > > > Thank you very much for your comments. I draw the topology you gave, > > and 7 PWs will be established if we follow 01. > > > > Root AC ---- PE 1 ----- PW 1 -------- PE 2 ----- Leaf _AC > > | \ / || > > | \ /=3D=3D=3DPW 6,7=3D=3D=3D || > > PW 2 -----PW 5------\ || > > | /----Root PW 3 --- \ || > > Root _AC ---- PE 3 PE 4 ------ Root AC > > | \ / | > > | ----Leaf PW 4----- | > > Leaf AC Leaf AC > > Yes, on PE 3 there are several PWs, but if you want to clarify it, > > there are only 3 types, one can carry frames originated from Root = and > > Leaf AC(one endpoint of this PW should be Root-only, otherwise this = is > > invalid), one only can carry frames from Root AC, and the last can > > carry frames from Leaf ACs. On second thoughts, we still can = classify > > the PWs into 2 sets, one is Leaf set, and another is Root set, and = the > > union of the sets Leaf and Root is the PW we called it as compatible > PW > > (Maybe this is not correct, we can find one good term on this). > > > > So this optimization still follows the original design of Dual-PW > > approach, Leaf PW only carries frames from Leaf AC; Root-PW only > > carries frames from Root AC. Is it right? > > > > I don't know whether chip can support this forwarding behavior for > > compatible PW or not, but if we implement it in NP, it is nearly = same > > as VPLS. The only difference is, setup 2 mappings, one between > Leaf-ACs > > and Leaf-PWs, one between Root-ACs and Root-PWs. For traditional = VPLS, > > there is only one mapping. > > > > [JY] It seems you may need a 3rd mapping: from both root & leaf AC = to > a > > compatible PW. > > BTW, for the forwarding and reverse direction, the mapping may be > > asymmetric for you compatible PW. > > > > Based on my understanding, all drafts should have similar mapping. > > > > [JY] Dual-VLAN seems simpler here. > > > > Thanks, > > > > Sam > > > > > > -----Original Message----- > > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > > Sent: Tuesday, May 15, 2012 3:32 PM > > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > > Cc: l2vpn@ietf.org > > Subject: RE: Discussion on E-Tree and H-VPLS > > > > Sam, > > > > Thanks, please see my further comments with [JY]. > > > > Ok, we go on the case in your mail, where PE1 has one Root-only AC, > > AC1, and > > PE2 has one Leaf-only AC, AC2. In general we can setup 2 > > "unidirectional" > > PWs (bidirectional PW, but just carry unidirectional frames), = Root-PW > > which carries frames originated from AC1 and Leaf-PW which carries > > frames originated from AC2. But only one PW also can work, just as > some > > members commented. Ok, we setup one PW between PE1 and PE2, we > can > call > > this PW as compatible PW or something else. Frames originated from > Root > > or leaf ACs will be carried via this PW. Its forwarding behavior is > > fully same as what traditional VPLS did, MAC learning on AC or PW in > > one E-Tree. Or say, if one PE has Root-only ACs, it will setup one = PW > > with another PE, Root-only, Leaf-only or Root-Leaf-Mixed. If 2 PEs = are > > root-Leaf-Mixed or other cases, then 2 PWs will be established. As = you > > know, this can be done on control plane. > > > > [JY] Assume there are 2 other nodes PE3 & PE4 in this network > scenario, > > and both PE3 and PE4 have both root and leaf ACs, then there are > > compatible PWs from PE3 which may carry both root and leaf traffic = (to > > PE1), which may carry only root traffic (to PE2); and further there > are > > root PW and leaf PW to PE4. Thus, the VSI on PE3 has at least 4 > > different types of PW transmitting behaviours with regard to the > E-Tree > > traffic. In the reverse direction, the VSI on PE3 further has at = least > > 4 different types of PW receiving behaviours. Not sure how you will > > accommodate for these PWs in both the data plane and control plane. > > > > Regards, > > Yuanlong > > > > Is this clear for you? Is this necessary to optimize PW setup in = this > > case? > > > > Maybe we need to add one paragraph on forwarding behavior. > > > > Again thank you very much for your comments, > > > > Sam > > > > -----Original Message----- > > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > > Sent: Tuesday, May 15, 2012 10:27 AM > > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > > Cc: l2vpn@ietf.org > > Subject: RE: Discussion on E-Tree and H-VPLS > > > > Please see my comments in line. > > > > -----Original Message----- > > From: Sam Cao [mailto:yuqun.cao@gmail.com] > > Sent: Monday, May 14, 2012 8:31 PM > > To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' > > Cc: l2vpn@ietf.org > > Subject: RE: Discussion on E-Tree and H-VPLS > > > > Hi Yuanlong, > > > > We have discussed this in another thread. In fact, Daniel or I have > > given the answers to the questions you raised here for several time > :). > > If we do in this way, we will reach deadlock and can not move = forward > > :). I try to explain it again. > > > > [JY] I will apologize if you had ever provided such answers before, > and > > you may just refer to the links rather than repeat the explanation. > > As you can see, I just try to understand the mechanism of 2PW and = its > > implications, but the I-D does not include enough information. > > > > As you know, initial design we will setup 2 PWs all the time (if do = in > > this way, I think that you have no question), > > > > [JY] I will be concerned with the operational complexity of this > > approach. > > > > but in most cases 2 PWs are not > > necessary. So in 01 version, we optimize it. > > > > "Root-only VSI <-> any VSI: only root PW required" > > "Leaf-only VSI <-> leaf-only VSI: no PWs required" > > > > In other cases 2 PWs are needed. If so, "Leaf-only -> root-only =3D = one > > leaf PW" is not correct: On Leaf-only side, yes, one Leaf-only PW is > > created between Local Leaf type with remote Root type; on root-only > > side, one root-only PW is created. Maybe it is better to call this = as > > compatible or mixed PW. So the left items you list are not correct = for > > multi_PW solution. > > > > [JY] This is something new, right? To be honest, I could not > understand > > what is your point: doesn't the mixed PW as you called also consist = of > > one Leaf-only PW in one direction and one root-only PW in the other > > direction? > > Furthermore, the case you took is also one case in your guideline > > "Root-only VSI <-> any VSI: only root PW required", don't you think > > that only one root PW is required following this guideline? > > Actually, I don't care much about what is the bidirectional PW or > > unidirectional PW called, but how can a VSI support such a mixed > > scenarios: > > traditional VSI assumes only one PW is required for each peer VSI, = and > > its MAC leaning is based on bidirectional PW. But for 2PW, there are > > bidirectional root PW, bidirectional leaf PW, mixed PW, etc..., how = to > > support these kinds of PWs in the same VSI is my top concern. > > > > BTW, I guess you also care this case we also have discussed before: > for > > example, if we configure one Leaf AC on root-only PE (then it will = be > > root-leaf-mixed PE), we will teardown the compatible PW and re-setup > > PWs again with 01. > > [JY] This was discussed in the emails indeed. > > > > Regards, > > > > Yuqun (Sam) Cao > > E-mail: Yuqun.cao@gmail.com > > > > -----Original Message----- > > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > > Sent: Monday, May 14, 2012 7:10 PM > > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > > Cc: l2vpn@ietf.org > > Subject: RE: Discussion on E-Tree and H-VPLS > > > > Hi Daniel, > > > > Fine, now it seems more in line with what we had proposed in 2VLAN: = a > > spoke PW behaves like root/leaf AC for a PE-r. > > > > But the same problem may also apply to the root/spoke "core PW" for > > Multi-PW: > > According to Multi-PW, only one PW is required between two PEs = except > > when both PEs are mixed with root and leaf, so these PWs may be = formed > > by combinations of the following unidirectional PW cases (extracted > and > > adapted from Josh's email): > > Root-only -> any VSI =3D one root PW > > Leaf-only -> root-only =3D one leaf PW > > Leaf-only -> mixed =3D one leaf PW > > Mixed -> root-only =3D one (root+leaf) PW > > Mixed -> leaf-only =3D one (root+leaf) PW > > > > I have a concern that the forwarding plane of PE to implement this > will > > be very different from the traditional VPLS. > > > > Regards, > > Yuanlong > > > > -----Original Message----- > > From: Daniel Cohn [mailto:DanielC@orckit.com] > > Sent: Monday, May 14, 2012 5:00 PM > > To: Jiangyuanlong; Alexander Vainshtein; Sam Cao > > Cc: l2vpn@ietf.org > > Subject: RE: Discussion on E-Tree and H-VPLS > > > > Hi Yuanlong, > > > > Like I wrote below, root/leaf spoke PW behave like root/leaf AC, not > > like root/spoke "core PW". So no changes to forwarding plane once = this > > is understood. > > > > DC > > > > -----Original Message----- > > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > > Sent: Monday, May 14, 2012 11:36 AM > > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > > Cc: l2vpn@ietf.org > > Subject: RE: Discussion on E-Tree and H-VPLS > > > > Daniel, please see my comments in line. > > > > -----Original Message----- > > From: Daniel Cohn [mailto:DanielC@orckit.com] > > Sent: Monday, May 14, 2012 3:37 PM > > To: Jiangyuanlong; Alexander Vainshtein; Sam Cao > > Cc: l2vpn@ietf.org > > Subject: RE: Discussion on E-Tree and H-VPLS > > > > Hi Yuanlong, > > > > As I see it, for the PE-r spoke (figure 4 in RFC 4762) we establish = a > > single PW per AC - root PW for root AC and leaf PW for leaf AC. With > > local configuration at the PE-rs as part of the spoke PW = provisioning. > > And the PE-rs will treat root/leaf spoke PWs exactly as it treat > > root/leaf ACs. So when leaf-originated BUM traffic arrives from the > > core (over a leaf PW), it will be forwarded over all root spoke PWs > but > > not on the leaf spoke PWs. > > > > [JY] So in the reverse direction, you need to transport both root = and > > leaf traffic from PE-rs over a root PW to PE-r, and transport root > > traffic over a leaf PW. It seems against the definition of root PW = and > > leaf PW in the multi-PW draft. Don't this make the forwarding plane = of > > PE-rs more complex? > > > > The forwarding plane is exactly the same as described in the = multi-PW > > draft, where spoke PWs are treated exactly like ACs. > > > > Regards, > > > > Daniel > > > > > > -----Original Message----- > > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > > Sent: Friday, May 11, 2012 5:03 AM > > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > > Cc: l2vpn@ietf.org > > Subject: RE: Discussion on E-Tree and H-VPLS > > > > Hi Daniel and all, > > > > When you set up two PWs from the PE-rs to a PE-r for each of its AC, > do > > you mean that one PW is bidirectional root PW and the other is > > bidirectional leaf PW? > > My concern is: where should the leaf traffic be filtered, on the = PE-rs > > or on the PE-r? > > If filtered on the PE-r, then lots of bandwidth will be wasted (for > > example, if the PE-r is attached with 9 leafs, then the BUM traffic > > from one of its leafs will be multiplied by 8 times, and be = forwarded > > by the PE-rs to the same PE-r). > > If filtered on the PE-rs, not sure how you will design its = forwarding > > plane, can you give a hint? > > > > Thanks, > > Yuanlong > > > > ------------------------------ > > Date: Wed, 9 May 2012 09:16:36 +0300 > > From: "Daniel Cohn" > > To: "Alexander Vainshtein" , > "Sam > > Cao" , > > Cc: lizhong.jin@zte.com.cn > > Subject: RE: Discussion on E-Tree and H-VPLS > > Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780CBA6@tlvmail1> > > Content-Type: text/plain; charset=3D"ISO-2022-JP" > > > > Hi Sasha, > > > > It's actually very simple. A frame that originated in a root AC is > > always transmitted only in root PW, no matter what the frame type > > (known/unknown unicast or broadcast). This is how the frame source > > information is propagated across the VPLS. So in the H-VPLS example, > > the PE-r will never forward a frame received over a root PW on any > leaf > > PW, only on root PWs (toward the core or toward other spokes). > > > > Hope this clarifies it, regards, > > > > Daniel > > > > -----Original Message----- > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On = Behalf > > Of Alexander Vainshtein > > Sent: Wednesday, May 09, 2012 7:59 AM > > To: Sam Cao; l2vpn@ietf.org > > Cc: lizhong.jin@zte.com.cn > > Subject: RE: Discussion on E-Tree and H-VPLS > > > > Sam, Lizhong and all, > > You've written that in the two-PW solution combined with H-VPLS the > PE- > > r must set up two PWs with each MTU-s. > > > > If this is the case, what kind of forwarding logic should be used to > > prevent sending a BUM frame received from a root-PW to a given = MTU-S: > > - back to the same MTU-S on the corresponding leaf-PW? > > - twice (to both root-PW and Leaf-PW) to another MTU-s? And, BTW, = how > > is the PW selected in this case? > > > > I am aware of a technique of multiple split horizon groups in PE-r > > which could be possibly used for this purpose. However, since these > > groups have to be represented explicitly in the data plane, their > > potential number is limited by the forwarding HW. Other methods = could > > be probably used for the same purpose, but they would probably = subject > > to similar HW-based limitations. > > > > I suspect that with the dual-PW approach, the HW would pose an > implicit > > limit, say, on a number of MTU-s that can be connected to the same > PE-r > > and that this limit could be quite low in most cases. > > > > Based on this I suspect that the H-VPLS issue as a critical drawback > of > > the dual-PW approach to E-Tree. > > > > My 2c, > > Sasha > > > > > > ________________________________________ > > From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of = Sam > > Cao [yuqun.cao@gmail.com] > > Sent: Wednesday, May 09, 2012 3:40 AM > > To: l2vpn@ietf.org > > Cc: lizhong.jin@zte.com.cn > > Subject: RE: Discussion on E-Tree and H-VPLS > > > > Hi Lizhong? > > > > Thank you very much for your comments. I updated the result on this > > question. > > > > [Lizhong] agree with the above analysis. And we did not say it is a > > technical problem, but it is an operational problem again. > > [Sam] I agree. Dual-VLAN does not make sense. I also discussed this > > with Giles and Yuanlong in another mail, and we reached agreement on > > this: > > MTU should know the access mode, VPWS or VPLS, VPWS mode should > > configure VLAN ID on MTU but VPLS mode can not. I thought this is = NOT > > reasonable :), but we can figure this out in draft. It seems ok. > > > > [Lizhong] not fully understand. Do you mean, when VPWS accessing = for > > H-VPLS, the PE-r is also necessary to configure two PWs (root and = leaf > > PW) for each AC access? > > [Sam] Yes. > > > > Thanks, > > > > Sam > > > > > > > > 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 Tue May 15 23:46: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 77AB711E8080 for ; Tue, 15 May 2012 23:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.214 X-Spam-Level: X-Spam-Status: No, score=-4.214 tagged_above=-999 required=5 tests=[AWL=1.785, BAYES_00=-2.599, J_CHICKENPOX_23=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 9p8WUKCWo3td for ; Tue, 15 May 2012 23:46:55 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id AE95C11E8086 for ; Tue, 15 May 2012 23:46:55 -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 AGF75417; Wed, 16 May 2012 02:46:55 -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; Tue, 15 May 2012 23:43:34 -0700 Received: from SZXEML439-HUB.china.huawei.com (10.72.61.74) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 15 May 2012 23:43:31 -0700 Received: from SZXEML546-MBS.china.huawei.com ([169.254.4.75]) by szxeml439-hub.china.huawei.com ([10.72.61.74]) with mapi id 14.01.0323.003; Wed, 16 May 2012 14:43:29 +0800 From: Jiangyuanlong To: Daniel Cohn , "Balus, Florin Stelian (Florin)" , Sam Cao , Alexander Vainshtein Subject: RE: Discussion on forwarding performance Thread-Topic: Discussion on forwarding performance Thread-Index: AQHNMp8ego9/CtMoakapN2JoMtGUPZbKvTGAgACuOgCAAIsAgA== Date: Wed, 16 May 2012 06:43:28 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413AA8@szxeml546-mbs.china.huawei.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D411694@szxeml546-mbx.china.huawei.com><44F4E579A764584EA9BDFD07D0CA08130780CF5C@tlvmail1><3B0A1BED22CAD649A1B3E97BE5DDD68B1D4130E1@szxeml546-mbs.china.huawei.com><44F4E579A764584EA9BDFD07D0CA08130780CF8F@tlvmail1><3B0A1BED22CAD649A1B3E97BE5DDD68B1D413216@szxeml546-mbs.china.huawei.com><3F1F3739E2B04D399CC7D26CE934F91A@v2comsam><3B0A1BED22CAD649A1B3E97BE5DDD68B1D413694@szxeml546-mbs.china.huawei.com><7A564821DF1642E592E884D5C623772C@R01842><3B0A1BED22CAD649A1B3E97BE5DDD68B1D41370E@szxeml546-mbs.china.huawei.com><400D5D93E6AA4075861CE09919D84747@R01842><3B0A1BED22CAD649A1B3E97BE5DDD68B1D413741@szxeml546-mbs.china.huawei.com> <7BDA456234D045E1BD42EA059A4E9579@v2comsam> <2073A6C5467C99478898544C6EBA3F4602C1907568@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> <44F4E579A764584EA9BDFD07D0CA08130780D1AB@tlvmail1> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA08130780D1AB@tlvmail1> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.40.73] 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, 16 May 2012 06:46:57 -0000 Daniel,=20 Not sure I fully understand what you mean by "VLAN and VCID lookups are per= formed simultaneously on ingress", do you mean VLAN and PW? Can you give more details on this requirement? Regards, Yuanlong -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Wednesday, May 16, 2012 2:16 PM To: Balus, Florin Stelian (Florin); Sam Cao; Jiangyuanlong; Alexander Vains= htein Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance Hi, I agree that for a chip-based solution there should be no difference in performance for the additional lookup. However from conversations with chip vendors, I understood there might be an impact on scalability because the double lookup would require a longer search key (assuming VLAN and VCID lookups are performed simultaneously on ingress), thus taking up more TCAM resources per E-Tree instance. This would depend on specific TCAM implementation (e.g. granularity of search key length). DC -----Original Message----- From: Balus, Florin Stelian (Florin) [mailto:florin.balus@alcatel-lucent.com]=20 Sent: Tuesday, May 15, 2012 10:53 PM To: Sam Cao; 'Jiangyuanlong'; Daniel Cohn; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance Sam, > Obviously the forwarding performance of Dual-VLAN will be much lower than what of Multi-PW. Sorry I could not keep up with some of the threads on this subject but the above statement caught my eyes. We have been doing all kind of egress operations on VLANs in the egress PE for the last 8 years and I am not aware of any "much lower" forwarding performance. As far as I know the chipsets used in the PEs can do this processing no problem. Do you want to clarify which kind of hardware may have problems? > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Sam Cao > Sent: Tuesday, May 15, 2012 6:32 AM > To: 'Jiangyuanlong'; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on forwarding performance > > Hi Yuanlong, > > 3rd mapping will make data plane complex, I think. Anyway, we reached a > consensus on Multi-PW implementation. > > If we use 3rd mapping, I agree with your opinion, maybe dual-VLAN seems > simple, but 2 mapping is enough. Then we can focus on data plane > performance. While stripe PW label out on egress PE, data-plane knows > how to forward the frames from PW, to Root AC or Leaf AC or all. But if > we use Dual-VLAN, after strip PW label out, data plane should strip > VLAN-ID out and then does same forwarding work as Multi-PW does. The > most important is, do one more operation while forwarding E-Tree > frames. Obviously the forwarding performance of Dual-VLAN will be much > lower than what of Multi-PW. > > Regards, > > Yuqun (Sam) Cao > E-mail: Yuqun.cao@gmail.com > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 7:03 PM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > See my further comments in line. > > -----Original Message----- > From: Sam Cao [mailto:yuqun.cao@gmail.com] > Sent: Tuesday, May 15, 2012 6:14 PM > To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > Thank you very much for your comments. I draw the topology you gave, > and 7 PWs will be established if we follow 01. > > Root AC ---- PE 1 ----- PW 1 -------- PE 2 ----- Leaf _AC > | \ / || > | \ /=3D=3D=3DPW 6,7=3D=3D=3D || > PW 2 -----PW 5------\ || > | /----Root PW 3 --- \ || > Root _AC ---- PE 3 PE 4 ------ Root AC > | \ / | > | ----Leaf PW 4----- | > Leaf AC Leaf AC > Yes, on PE 3 there are several PWs, but if you want to clarify it, > there are only 3 types, one can carry frames originated from Root and > Leaf AC(one endpoint of this PW should be Root-only, otherwise this is > invalid), one only can carry frames from Root AC, and the last can > carry frames from Leaf ACs. On second thoughts, we still can classify > the PWs into 2 sets, one is Leaf set, and another is Root set, and the > union of the sets Leaf and Root is the PW we called it as compatible PW > (Maybe this is not correct, we can find one good term on this). > > So this optimization still follows the original design of Dual-PW > approach, Leaf PW only carries frames from Leaf AC; Root-PW only > carries frames from Root AC. Is it right? > > I don't know whether chip can support this forwarding behavior for > compatible PW or not, but if we implement it in NP, it is nearly same > as VPLS. The only difference is, setup 2 mappings, one between Leaf-ACs > and Leaf-PWs, one between Root-ACs and Root-PWs. For traditional VPLS, > there is only one mapping. > > [JY] It seems you may need a 3rd mapping: from both root & leaf AC to a > compatible PW. > BTW, for the forwarding and reverse direction, the mapping may be > asymmetric for you compatible PW. > > Based on my understanding, all drafts should have similar mapping. > > [JY] Dual-VLAN seems simpler here. > > Thanks, > > Sam > > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 3:32 PM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Sam, > > Thanks, please see my further comments with [JY]. > > Ok, we go on the case in your mail, where PE1 has one Root-only AC, > AC1, and > PE2 has one Leaf-only AC, AC2. In general we can setup 2 > "unidirectional" > PWs (bidirectional PW, but just carry unidirectional frames), Root-PW > which carries frames originated from AC1 and Leaf-PW which carries > frames originated from AC2. But only one PW also can work, just as some > members commented. Ok, we setup one PW between PE1 and PE2, we can call > this PW as compatible PW or something else. Frames originated from Root > or leaf ACs will be carried via this PW. Its forwarding behavior is > fully same as what traditional VPLS did, MAC learning on AC or PW in > one E-Tree. Or say, if one PE has Root-only ACs, it will setup one PW > with another PE, Root-only, Leaf-only or Root-Leaf-Mixed. If 2 PEs are > root-Leaf-Mixed or other cases, then 2 PWs will be established. As you > know, this can be done on control plane. > > [JY] Assume there are 2 other nodes PE3 & PE4 in this network scenario, > and both PE3 and PE4 have both root and leaf ACs, then there are > compatible PWs from PE3 which may carry both root and leaf traffic (to > PE1), which may carry only root traffic (to PE2); and further there are > root PW and leaf PW to PE4. Thus, the VSI on PE3 has at least 4 > different types of PW transmitting behaviours with regard to the E-Tree > traffic. In the reverse direction, the VSI on PE3 further has at least > 4 different types of PW receiving behaviours. Not sure how you will > accommodate for these PWs in both the data plane and control plane. > > Regards, > Yuanlong > > Is this clear for you? Is this necessary to optimize PW setup in this > case? > > Maybe we need to add one paragraph on forwarding behavior. > > Again thank you very much for your comments, > > Sam > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 10:27 AM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Please see my comments in line. > > -----Original Message----- > From: Sam Cao [mailto:yuqun.cao@gmail.com] > Sent: Monday, May 14, 2012 8:31 PM > To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > We have discussed this in another thread. In fact, Daniel or I have > given the answers to the questions you raised here for several time :). > If we do in this way, we will reach deadlock and can not move forward > :). I try to explain it again. > > [JY] I will apologize if you had ever provided such answers before, and > you may just refer to the links rather than repeat the explanation. > As you can see, I just try to understand the mechanism of 2PW and its > implications, but the I-D does not include enough information. > > As you know, initial design we will setup 2 PWs all the time (if do in > this way, I think that you have no question), > > [JY] I will be concerned with the operational complexity of this > approach. > > but in most cases 2 PWs are not > necessary. So in 01 version, we optimize it. > > "Root-only VSI <-> any VSI: only root PW required" > "Leaf-only VSI <-> leaf-only VSI: no PWs required" > > In other cases 2 PWs are needed. If so, "Leaf-only -> root-only =3D one > leaf PW" is not correct: On Leaf-only side, yes, one Leaf-only PW is > created between Local Leaf type with remote Root type; on root-only > side, one root-only PW is created. Maybe it is better to call this as > compatible or mixed PW. So the left items you list are not correct for > multi_PW solution. > > [JY] This is something new, right? To be honest, I could not understand > what is your point: doesn't the mixed PW as you called also consist of > one Leaf-only PW in one direction and one root-only PW in the other > direction? > Furthermore, the case you took is also one case in your guideline > "Root-only VSI <-> any VSI: only root PW required", don't you think > that only one root PW is required following this guideline? > Actually, I don't care much about what is the bidirectional PW or > unidirectional PW called, but how can a VSI support such a mixed > scenarios: > traditional VSI assumes only one PW is required for each peer VSI, and > its MAC leaning is based on bidirectional PW. But for 2PW, there are > bidirectional root PW, bidirectional leaf PW, mixed PW, etc..., how to > support these kinds of PWs in the same VSI is my top concern. > > BTW, I guess you also care this case we also have discussed before: for > example, if we configure one Leaf AC on root-only PE (then it will be > root-leaf-mixed PE), we will teardown the compatible PW and re-setup > PWs again with 01. > [JY] This was discussed in the emails indeed. > > Regards, > > Yuqun (Sam) Cao > E-mail: Yuqun.cao@gmail.com > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Monday, May 14, 2012 7:10 PM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Daniel, > > Fine, now it seems more in line with what we had proposed in 2VLAN: a > spoke PW behaves like root/leaf AC for a PE-r. > > But the same problem may also apply to the root/spoke "core PW" for > Multi-PW: > According to Multi-PW, only one PW is required between two PEs except > when both PEs are mixed with root and leaf, so these PWs may be formed > by combinations of the following unidirectional PW cases (extracted and > adapted from Josh's email): > Root-only -> any VSI =3D one root PW > Leaf-only -> root-only =3D one leaf PW > Leaf-only -> mixed =3D one leaf PW > Mixed -> root-only =3D one (root+leaf) PW > Mixed -> leaf-only =3D one (root+leaf) PW > > I have a concern that the forwarding plane of PE to implement this will > be very different from the traditional VPLS. > > Regards, > Yuanlong > > -----Original Message----- > From: Daniel Cohn [mailto:DanielC@orckit.com] > Sent: Monday, May 14, 2012 5:00 PM > To: Jiangyuanlong; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > Like I wrote below, root/leaf spoke PW behave like root/leaf AC, not > like root/spoke "core PW". So no changes to forwarding plane once this > is understood. > > DC > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Monday, May 14, 2012 11:36 AM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Daniel, please see my comments in line. > > -----Original Message----- > From: Daniel Cohn [mailto:DanielC@orckit.com] > Sent: Monday, May 14, 2012 3:37 PM > To: Jiangyuanlong; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > As I see it, for the PE-r spoke (figure 4 in RFC 4762) we establish a > single PW per AC - root PW for root AC and leaf PW for leaf AC. With > local configuration at the PE-rs as part of the spoke PW provisioning. > And the PE-rs will treat root/leaf spoke PWs exactly as it treat > root/leaf ACs. So when leaf-originated BUM traffic arrives from the > core (over a leaf PW), it will be forwarded over all root spoke PWs but > not on the leaf spoke PWs. > > [JY] So in the reverse direction, you need to transport both root and > leaf traffic from PE-rs over a root PW to PE-r, and transport root > traffic over a leaf PW. It seems against the definition of root PW and > leaf PW in the multi-PW draft. Don't this make the forwarding plane of > PE-rs more complex? > > The forwarding plane is exactly the same as described in the multi-PW > draft, where spoke PWs are treated exactly like ACs. > > Regards, > > Daniel > > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Friday, May 11, 2012 5:03 AM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Daniel and all, > > When you set up two PWs from the PE-rs to a PE-r for each of its AC, do > you mean that one PW is bidirectional root PW and the other is > bidirectional leaf PW? > My concern is: where should the leaf traffic be filtered, on the PE-rs > or on the PE-r? > If filtered on the PE-r, then lots of bandwidth will be wasted (for > example, if the PE-r is attached with 9 leafs, then the BUM traffic > from one of its leafs will be multiplied by 8 times, and be forwarded > by the PE-rs to the same PE-r). > If filtered on the PE-rs, not sure how you will design its forwarding > plane, can you give a hint? > > Thanks, > Yuanlong > > ------------------------------ > Date: Wed, 9 May 2012 09:16:36 +0300 > From: "Daniel Cohn" > To: "Alexander Vainshtein" , "Sam > Cao" , > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780CBA6@tlvmail1> > Content-Type: text/plain; charset=3D"ISO-2022-JP" > > Hi Sasha, > > It's actually very simple. A frame that originated in a root AC is > always transmitted only in root PW, no matter what the frame type > (known/unknown unicast or broadcast). This is how the frame source > information is propagated across the VPLS. So in the H-VPLS example, > the PE-r will never forward a frame received over a root PW on any leaf > PW, only on root PWs (toward the core or toward other spokes). > > Hope this clarifies it, regards, > > Daniel > > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Alexander Vainshtein > Sent: Wednesday, May 09, 2012 7:59 AM > To: Sam Cao; l2vpn@ietf.org > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > > Sam, Lizhong and all, > You've written that in the two-PW solution combined with H-VPLS the PE- > r must set up two PWs with each MTU-s. > > If this is the case, what kind of forwarding logic should be used to > prevent sending a BUM frame received from a root-PW to a given MTU-S: > - back to the same MTU-S on the corresponding leaf-PW? > - twice (to both root-PW and Leaf-PW) to another MTU-s? And, BTW, how > is the PW selected in this case? > > I am aware of a technique of multiple split horizon groups in PE-r > which could be possibly used for this purpose. However, since these > groups have to be represented explicitly in the data plane, their > potential number is limited by the forwarding HW. Other methods could > be probably used for the same purpose, but they would probably subject > to similar HW-based limitations. > > I suspect that with the dual-PW approach, the HW would pose an implicit > limit, say, on a number of MTU-s that can be connected to the same PE-r > and that this limit could be quite low in most cases. > > Based on this I suspect that the H-VPLS issue as a critical drawback of > the dual-PW approach to E-Tree. > > My 2c, > Sasha > > > ________________________________________ > From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Sam > Cao [yuqun.cao@gmail.com] > Sent: Wednesday, May 09, 2012 3:40 AM > To: l2vpn@ietf.org > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Lizhong? > > Thank you very much for your comments. I updated the result on this > question. > > [Lizhong] agree with the above analysis. And we did not say it is a > technical problem, but it is an operational problem again. > [Sam] I agree. Dual-VLAN does not make sense. I also discussed this > with Giles and Yuanlong in another mail, and we reached agreement on > this: > MTU should know the access mode, VPWS or VPLS, VPWS mode should > configure VLAN ID on MTU but VPLS mode can not. I thought this is NOT > reasonable :), but we can figure this out in draft. It seems ok. > > [Lizhong] not fully understand. Do you mean, when VPWS accessing for > H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf > PW) for each AC access? > [Sam] Yes. > > Thanks, > > Sam > > > > From jiangyuanlong@huawei.com Wed May 16 00:25: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 084A021F857D for ; Wed, 16 May 2012 00:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.248 X-Spam-Level: X-Spam-Status: No, score=-4.248 tagged_above=-999 required=5 tests=[AWL=1.751, BAYES_00=-2.599, J_CHICKENPOX_23=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 FvfA9rC9AGvG for ; Wed, 16 May 2012 00:25:18 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4024721F86EA for ; Wed, 16 May 2012 00:25:18 -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 AFY80012; Wed, 16 May 2012 03:25:18 -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; Wed, 16 May 2012 00:23:23 -0700 Received: from SZXEML438-HUB.china.huawei.com (10.72.61.73) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 16 May 2012 00:23:21 -0700 Received: from SZXEML546-MBS.china.huawei.com ([169.254.4.75]) by szxeml438-hub.china.huawei.com ([10.72.61.73]) with mapi id 14.01.0323.003; Wed, 16 May 2012 15:23:17 +0800 From: Jiangyuanlong To: Daniel Cohn , Alexander Vainshtein , "Balus, Florin Stelian (Florin)" , Sam Cao Subject: RE: Discussion on forwarding performance Thread-Topic: Discussion on forwarding performance Thread-Index: AQHNLxo3go9/CtMoakapN2JoMtGUPZbHcLkAgAGHLZCAAAmjYIAAHGPggAAUqSCAAOHDIIAAM7tggAAlyMCAADHVIIAAElJAgAAmSSCAAGzc8IAAspUAgAAH+MCAAAIx84AAB7AA Date: Wed, 16 May 2012 07:23:16 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413ACA@szxeml546-mbs.china.huawei.com> References: <20ab01cd3330$0ced2b69$05280101@corrigent.com> In-Reply-To: <20ab01cd3330$0ced2b69$05280101@corrigent.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.40.73] 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, 16 May 2012 07:25:20 -0000 UGVyaGFwcyBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gdW5kZXJzdGFuZCB0aGUgcHJvYmxlbSBmaXJz dDogSW4gd2hhdCBjaXJjdW1zdGFuY2VzIGRvIHlvdSB0aGluayB0aGF0IGRvdWJsZSBsb29rdXAg b2YgVkxBTiBhbmQgVkNJRCBpcyBuZWVkZWQgZm9yIER1YWwtVkxBTj8NCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IERhbmllbCBDb2huIFttYWlsdG86RGFuaWVsQ0BvcmNraXQu Y29tXSANClNlbnQ6IFdlZG5lc2RheSwgTWF5IDE2LCAyMDEyIDI6NDcgUE0NClRvOiBBbGV4YW5k ZXIgVmFpbnNodGVpbjsgQmFsdXMsIEZsb3JpbiBTdGVsaWFuIChGbG9yaW4pOyBTYW0gQ2FvOyBK aWFuZ3l1YW5sb25nDQpDYzogbDJ2cG5AaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBEaXNjdXNzaW9u IG9uIGZvcndhcmRpbmcgcGVyZm9ybWFuY2UNCg0KV2h5IG5vdD8gQXJlbid0IGVhc2Ugb2YgaW1w bGVtZW50YXRpb24gYW5kIHBlcmZvcm1hbmNlIGVmZmljaWVuY3kgdmFsaWQgY29uc2lkZXJhdGlv bnMgd2hlbiBzZWxlY3Rpbmcgb25lIHNvbHV0aW9uIG92ZXIgYW5vdGhlcj8NCg0KVGh1bWIgdHlw ZWQgLSBwbGVhc2UgYmUgdG9sZXJhbnQNCg0KQWxleGFuZGVyIFZhaW5zaHRlaW4gPEFsZXhhbmRl ci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPiB3cm90ZToNCg0KRGFuaWVsLCBhbmQgYWxsLA0KSSBh bSBub3Qgc3VyZSB0aGF0IGRpc2N1c3Npb24gb2YgaW1wbGVtZW50YXRpb24tc3BlY2lmaWMgaXNz dWVzIChlLmcuLCB3aGV0aGVyIHlvdSB1c2Ugb3IgZG8gbm90IHVzZSBUQ0FNIGxvb2t1cHMpIHJl YWxseSBiZWxvbmdzIHRvIHRoaXMgbGlzdC4NCg0KUmVnYXJkcywNCiAgICAgU2FzaGENCg0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBEYW5pZWwgQ29obiBbbWFpbHRvOkRh bmllbENAb3Jja2l0LmNvbV0NCj4gU2VudDogV2VkbmVzZGF5LCBNYXkgMTYsIDIwMTIgOToxNiBB TQ0KPiBUbzogQmFsdXMsIEZsb3JpbiBTdGVsaWFuIChGbG9yaW4pOyBTYW0gQ2FvOyBKaWFuZ3l1 YW5sb25nOyBBbGV4YW5kZXINCj4gVmFpbnNodGVpbg0KPiBDYzogbDJ2cG5AaWV0Zi5vcmcNCj4g U3ViamVjdDogUkU6IERpc2N1c3Npb24gb24gZm9yd2FyZGluZyBwZXJmb3JtYW5jZQ0KPiANCj4g SGksDQo+IA0KPiBJIGFncmVlIHRoYXQgZm9yIGEgY2hpcC1iYXNlZCBzb2x1dGlvbiB0aGVyZSBz aG91bGQgYmUgbm8gZGlmZmVyZW5jZSBpbg0KPiBwZXJmb3JtYW5jZSBmb3IgdGhlIGFkZGl0aW9u YWwgbG9va3VwLiBIb3dldmVyIGZyb20gY29udmVyc2F0aW9ucyB3aXRoDQo+IGNoaXAgdmVuZG9y cywgSSB1bmRlcnN0b29kIHRoZXJlIG1pZ2h0IGJlIGFuIGltcGFjdCBvbiBzY2FsYWJpbGl0eQ0K PiBiZWNhdXNlIHRoZSBkb3VibGUgbG9va3VwIHdvdWxkIHJlcXVpcmUgYSBsb25nZXIgc2VhcmNo IGtleSAoYXNzdW1pbmcNCj4gVkxBTiBhbmQgVkNJRCBsb29rdXBzIGFyZSBwZXJmb3JtZWQgc2lt dWx0YW5lb3VzbHkgb24gaW5ncmVzcyksIHRodXMNCj4gdGFraW5nIHVwIG1vcmUgVENBTSByZXNv dXJjZXMgcGVyIEUtVHJlZSBpbnN0YW5jZS4gVGhpcyB3b3VsZCBkZXBlbmQgb24NCj4gc3BlY2lm aWMgVENBTSBpbXBsZW1lbnRhdGlvbiAoZS5nLiBncmFudWxhcml0eSBvZiBzZWFyY2gga2V5IGxl bmd0aCkuDQo+IA0KPiBEQw0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogQmFsdXMsIEZsb3JpbiBTdGVsaWFuIChGbG9yaW4pDQo+IFttYWlsdG86ZmxvcmluLmJhbHVz QGFsY2F0ZWwtbHVjZW50LmNvbV0NCj4gU2VudDogVHVlc2RheSwgTWF5IDE1LCAyMDEyIDEwOjUz IFBNDQo+IFRvOiBTYW0gQ2FvOyAnSmlhbmd5dWFubG9uZyc7IERhbmllbCBDb2huOyAnQWxleGFu ZGVyIFZhaW5zaHRlaW4nDQo+IENjOiBsMnZwbkBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogRGlz Y3Vzc2lvbiBvbiBmb3J3YXJkaW5nIHBlcmZvcm1hbmNlDQo+IA0KPiBTYW0sDQo+IA0KPiA+IE9i dmlvdXNseSB0aGUgZm9yd2FyZGluZyBwZXJmb3JtYW5jZSBvZiBEdWFsLVZMQU4gd2lsbCBiZSBt dWNoIGxvd2VyDQo+IHRoYW4gd2hhdCBvZiBNdWx0aS1QVy4NCj4gDQo+IFNvcnJ5IEkgY291bGQg bm90IGtlZXAgdXAgd2l0aCBzb21lIG9mIHRoZSB0aHJlYWRzIG9uIHRoaXMgc3ViamVjdCBidXQN Cj4gdGhlIGFib3ZlIHN0YXRlbWVudCBjYXVnaHQgbXkgZXllcy4gV2UgaGF2ZSBiZWVuIGRvaW5n IGFsbCBraW5kIG9mDQo+IGVncmVzcyBvcGVyYXRpb25zIG9uIFZMQU5zIGluIHRoZSBlZ3Jlc3Mg UEUgZm9yIHRoZSBsYXN0IDggeWVhcnMgYW5kIEkNCj4gYW0gbm90IGF3YXJlIG9mIGFueSAibXVj aCBsb3dlciIgZm9yd2FyZGluZyBwZXJmb3JtYW5jZS4gQXMgZmFyIGFzIEkNCj4ga25vdyB0aGUg Y2hpcHNldHMgdXNlZCBpbiB0aGUgUEVzIGNhbiBkbyB0aGlzIHByb2Nlc3Npbmcgbm8gcHJvYmxl bS4gRG8NCj4geW91IHdhbnQgdG8gY2xhcmlmeSB3aGljaCBraW5kIG9mIGhhcmR3YXJlIG1heSBo YXZlIHByb2JsZW1zPw0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZy b206IGwydnBuLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYNCj4gPiBPZiBTYW0gQ2FvDQo+ID4gU2VudDogVHVlc2RheSwgTWF5IDE1LCAy MDEyIDY6MzIgQU0NCj4gPiBUbzogJ0ppYW5neXVhbmxvbmcnOyAnRGFuaWVsIENvaG4nOyAnQWxl eGFuZGVyIFZhaW5zaHRlaW4nDQo+ID4gQ2M6IGwydnBuQGlldGYub3JnDQo+ID4gU3ViamVjdDog UkU6IERpc2N1c3Npb24gb24gZm9yd2FyZGluZyBwZXJmb3JtYW5jZQ0KPiA+DQo+ID4gSGkgWXVh bmxvbmcsDQo+ID4NCj4gPiAzcmQgbWFwcGluZyB3aWxsIG1ha2UgZGF0YSBwbGFuZSBjb21wbGV4 LCBJIHRoaW5rLiBBbnl3YXksIHdlIHJlYWNoZWQNCj4gYQ0KPiA+IGNvbnNlbnN1cyBvbiBNdWx0 aS1QVyBpbXBsZW1lbnRhdGlvbi4NCj4gPg0KPiA+IElmIHdlIHVzZSAzcmQgbWFwcGluZywgSSBh Z3JlZSB3aXRoIHlvdXIgb3BpbmlvbiwgbWF5YmUgZHVhbC1WTEFODQo+IHNlZW1zDQo+ID4gc2lt cGxlLCBidXQgMiBtYXBwaW5nIGlzIGVub3VnaC4gVGhlbiB3ZSBjYW4gZm9jdXMgb24gZGF0YSBw bGFuZQ0KPiA+IHBlcmZvcm1hbmNlLiBXaGlsZSBzdHJpcGUgUFcgbGFiZWwgb3V0IG9uIGVncmVz cyBQRSwgZGF0YS1wbGFuZSBrbm93cw0KPiA+IGhvdyB0byBmb3J3YXJkIHRoZSBmcmFtZXMgZnJv bSBQVywgdG8gUm9vdCBBQyBvciBMZWFmIEFDIG9yIGFsbC4gQnV0DQo+IGlmDQo+ID4gd2UgdXNl IER1YWwtVkxBTiwgYWZ0ZXIgc3RyaXAgUFcgbGFiZWwgb3V0LCBkYXRhIHBsYW5lIHNob3VsZCBz dHJpcA0KPiA+IFZMQU4tSUQgb3V0IGFuZCB0aGVuIGRvZXMgc2FtZSBmb3J3YXJkaW5nIHdvcmsg YXMgTXVsdGktUFcgZG9lcy4gVGhlDQo+ID4gbW9zdCBpbXBvcnRhbnQgaXMsIGRvIG9uZSBtb3Jl IG9wZXJhdGlvbiB3aGlsZSBmb3J3YXJkaW5nIEUtVHJlZQ0KPiA+IGZyYW1lcy4gT2J2aW91c2x5 IHRoZSBmb3J3YXJkaW5nIHBlcmZvcm1hbmNlIG9mIER1YWwtVkxBTiB3aWxsIGJlIG11Y2gNCj4g PiBsb3dlciB0aGFuIHdoYXQgb2YgTXVsdGktUFcuDQo+ID4NCj4gPiBSZWdhcmRzLA0KPiA+DQo+ ID4gWXVxdW4gKFNhbSkgQ2FvDQo+ID4gRS1tYWlsOiBZdXF1bi5jYW9AZ21haWwuY29tDQo+ID4N Cj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IEppYW5neXVhbmxvbmcg W21haWx0bzpqaWFuZ3l1YW5sb25nQGh1YXdlaS5jb21dDQo+ID4gU2VudDogVHVlc2RheSwgTWF5 IDE1LCAyMDEyIDc6MDMgUE0NCj4gPiBUbzogU2FtIENhbzsgJ0RhbmllbCBDb2huJzsgJ0FsZXhh bmRlciBWYWluc2h0ZWluJw0KPiA+IENjOiBsMnZwbkBpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJF OiBEaXNjdXNzaW9uIG9uIEUtVHJlZSBhbmQgSC1WUExTDQo+ID4NCj4gPiBTZWUgbXkgZnVydGhl ciBjb21tZW50cyBpbiBsaW5lLg0KPiA+DQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gPiBGcm9tOiBTYW0gQ2FvIFttYWlsdG86eXVxdW4uY2FvQGdtYWlsLmNvbV0NCj4gPiBTZW50 OiBUdWVzZGF5LCBNYXkgMTUsIDIwMTIgNjoxNCBQTQ0KPiA+IFRvOiBKaWFuZ3l1YW5sb25nOyAn RGFuaWVsIENvaG4nOyAnQWxleGFuZGVyIFZhaW5zaHRlaW4nDQo+ID4gQ2M6IGwydnBuQGlldGYu b3JnDQo+ID4gU3ViamVjdDogUkU6IERpc2N1c3Npb24gb24gRS1UcmVlIGFuZCBILVZQTFMNCj4g Pg0KPiA+IEhpIFl1YW5sb25nLA0KPiA+DQo+ID4gVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgeW91 ciBjb21tZW50cy4gSSBkcmF3IHRoZSB0b3BvbG9neSB5b3UgZ2F2ZSwNCj4gPiBhbmQgNyBQV3Mg d2lsbCBiZSBlc3RhYmxpc2hlZCBpZiB3ZSBmb2xsb3cgMDEuDQo+ID4NCj4gPiBSb290IEFDIC0t LS0gUEUgMSAtLS0tLSBQVyAxIC0tLS0tLS0tIFBFIDIgLS0tLS0gTGVhZiBfQUMNCj4gPiAgICAg ICAgICAgICAgICB8ICBcICAgICAgICAgICAgICAgICAvICB8fA0KPiA+ICAgICAgICAgICAgICAg IHwgICBcICAvPT09UFcgNiw3PT09ICAgIHx8DQo+ID4gICAgICAgICAgICAgICAgIFBXIDIgIC0t LS0tUFcgNS0tLS0tLVwgIHx8DQo+ID4gICAgICAgICAgICAgICAgfCAgLy0tLS1Sb290IFBXIDMg LS0tIFwgfHwNCj4gPiBSb290IF9BQyAtLS0tIFBFIDMgICAgICAgICAgICAgICAgICAgIFBFIDQg LS0tLS0tIFJvb3QgQUMNCj4gPiAgICAgICAgICAgICAgICB8ICAgXCAgICAgICAgICAgICAgICAg IC8gIHwNCj4gPiAgICAgICAgICAgICAgICB8ICAgIC0tLS1MZWFmIFBXIDQtLS0tLSAgIHwNCj4g PiAgICAgICAgICAgICBMZWFmIEFDICAgICAgICAgICAgICAgICAgICBMZWFmIEFDDQo+ID4gWWVz LCBvbiBQRSAzIHRoZXJlIGFyZSBzZXZlcmFsIFBXcywgYnV0IGlmIHlvdSB3YW50IHRvIGNsYXJp ZnkgaXQsDQo+ID4gdGhlcmUgYXJlIG9ubHkgMyB0eXBlcywgb25lIGNhbiBjYXJyeSBmcmFtZXMg b3JpZ2luYXRlZCBmcm9tIFJvb3QgYW5kDQo+ID4gTGVhZiBBQyhvbmUgZW5kcG9pbnQgb2YgdGhp cyBQVyBzaG91bGQgYmUgUm9vdC1vbmx5LCBvdGhlcndpc2UgdGhpcyBpcw0KPiA+IGludmFsaWQp LCBvbmUgb25seSBjYW4gY2FycnkgZnJhbWVzIGZyb20gUm9vdCBBQywgYW5kIHRoZSBsYXN0IGNh bg0KPiA+IGNhcnJ5IGZyYW1lcyBmcm9tIExlYWYgQUNzLiBPbiBzZWNvbmQgdGhvdWdodHMsIHdl IHN0aWxsIGNhbiBjbGFzc2lmeQ0KPiA+IHRoZSBQV3MgaW50byAyIHNldHMsIG9uZSBpcyBMZWFm IHNldCwgYW5kIGFub3RoZXIgaXMgUm9vdCBzZXQsIGFuZCB0aGUNCj4gPiB1bmlvbiBvZiB0aGUg c2V0cyBMZWFmIGFuZCBSb290IGlzIHRoZSBQVyB3ZSBjYWxsZWQgaXQgYXMgY29tcGF0aWJsZQ0K PiBQVw0KPiA+IChNYXliZSB0aGlzIGlzIG5vdCBjb3JyZWN0LCB3ZSBjYW4gZmluZCBvbmUgZ29v ZCB0ZXJtIG9uIHRoaXMpLg0KPiA+DQo+ID4gU28gdGhpcyBvcHRpbWl6YXRpb24gc3RpbGwgZm9s bG93cyB0aGUgb3JpZ2luYWwgZGVzaWduIG9mIER1YWwtUFcNCj4gPiBhcHByb2FjaCwgTGVhZiBQ VyBvbmx5IGNhcnJpZXMgZnJhbWVzIGZyb20gTGVhZiBBQzsgUm9vdC1QVyBvbmx5DQo+ID4gY2Fy cmllcyBmcmFtZXMgZnJvbSBSb290IEFDLiBJcyBpdCByaWdodD8NCj4gPg0KPiA+IEkgZG9uJ3Qg a25vdyB3aGV0aGVyIGNoaXAgY2FuIHN1cHBvcnQgdGhpcyBmb3J3YXJkaW5nIGJlaGF2aW9yIGZv cg0KPiA+IGNvbXBhdGlibGUgUFcgb3Igbm90LCBidXQgaWYgd2UgaW1wbGVtZW50IGl0IGluIE5Q LCBpdCBpcyBuZWFybHkgc2FtZQ0KPiA+IGFzIFZQTFMuIFRoZSBvbmx5IGRpZmZlcmVuY2UgaXMs IHNldHVwIDIgbWFwcGluZ3MsIG9uZSBiZXR3ZWVuDQo+IExlYWYtQUNzDQo+ID4gYW5kIExlYWYt UFdzLCBvbmUgYmV0d2VlbiBSb290LUFDcyBhbmQgUm9vdC1QV3MuIEZvciB0cmFkaXRpb25hbCBW UExTLA0KPiA+IHRoZXJlIGlzIG9ubHkgb25lIG1hcHBpbmcuDQo+ID4NCj4gPiBbSlldIEl0IHNl ZW1zIHlvdSBtYXkgbmVlZCBhIDNyZCBtYXBwaW5nOiBmcm9tIGJvdGggcm9vdCAmIGxlYWYgQUMg dG8NCj4gYQ0KPiA+IGNvbXBhdGlibGUgUFcuDQo+ID4gQlRXLCBmb3IgdGhlIGZvcndhcmRpbmcg YW5kIHJldmVyc2UgZGlyZWN0aW9uLCB0aGUgbWFwcGluZyBtYXkgYmUNCj4gPiBhc3ltbWV0cmlj IGZvciB5b3UgY29tcGF0aWJsZSBQVy4NCj4gPg0KPiA+IEJhc2VkIG9uIG15IHVuZGVyc3RhbmRp bmcsIGFsbCBkcmFmdHMgc2hvdWxkIGhhdmUgc2ltaWxhciBtYXBwaW5nLg0KPiA+DQo+ID4gW0pZ XSBEdWFsLVZMQU4gc2VlbXMgc2ltcGxlciBoZXJlLg0KPiA+DQo+ID4gVGhhbmtzLA0KPiA+DQo+ ID4gU2FtDQo+ID4NCj4gPg0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJv bTogSmlhbmd5dWFubG9uZyBbbWFpbHRvOmppYW5neXVhbmxvbmdAaHVhd2VpLmNvbV0NCj4gPiBT ZW50OiBUdWVzZGF5LCBNYXkgMTUsIDIwMTIgMzozMiBQTQ0KPiA+IFRvOiBTYW0gQ2FvOyAnRGFu aWVsIENvaG4nOyAnQWxleGFuZGVyIFZhaW5zaHRlaW4nDQo+ID4gQ2M6IGwydnBuQGlldGYub3Jn DQo+ID4gU3ViamVjdDogUkU6IERpc2N1c3Npb24gb24gRS1UcmVlIGFuZCBILVZQTFMNCj4gPg0K PiA+IFNhbSwNCj4gPg0KPiA+IFRoYW5rcywgcGxlYXNlIHNlZSBteSBmdXJ0aGVyIGNvbW1lbnRz IHdpdGggW0pZXS4NCj4gPg0KPiA+IE9rLCB3ZSBnbyBvbiB0aGUgY2FzZSBpbiB5b3VyIG1haWws IHdoZXJlIFBFMSBoYXMgb25lIFJvb3Qtb25seSBBQywNCj4gPiBBQzEsIGFuZA0KPiA+IFBFMiBo YXMgb25lIExlYWYtb25seSBBQywgQUMyLiBJbiBnZW5lcmFsIHdlIGNhbiBzZXR1cCAyDQo+ID4g InVuaWRpcmVjdGlvbmFsIg0KPiA+IFBXcyAoYmlkaXJlY3Rpb25hbCBQVywgYnV0IGp1c3QgY2Fy cnkgdW5pZGlyZWN0aW9uYWwgZnJhbWVzKSwgUm9vdC1QVw0KPiA+IHdoaWNoIGNhcnJpZXMgZnJh bWVzIG9yaWdpbmF0ZWQgZnJvbSBBQzEgYW5kIExlYWYtUFcgd2hpY2ggY2Fycmllcw0KPiA+IGZy YW1lcyBvcmlnaW5hdGVkIGZyb20gQUMyLiBCdXQgb25seSBvbmUgUFcgYWxzbyBjYW4gd29yaywg anVzdCBhcw0KPiBzb21lDQo+ID4gbWVtYmVycyBjb21tZW50ZWQuIE9rLCB3ZSBzZXR1cCBvbmUg UFcgYmV0d2VlbiBQRTEgYW5kIFBFMiwgd2UNCj4gY2FuDQo+IGNhbGwNCj4gPiB0aGlzIFBXIGFz IGNvbXBhdGlibGUgUFcgb3Igc29tZXRoaW5nIGVsc2UuIEZyYW1lcyBvcmlnaW5hdGVkIGZyb20N Cj4gUm9vdA0KPiA+IG9yIGxlYWYgQUNzIHdpbGwgYmUgY2FycmllZCB2aWEgdGhpcyBQVy4gSXRz IGZvcndhcmRpbmcgYmVoYXZpb3IgaXMNCj4gPiBmdWxseSBzYW1lIGFzIHdoYXQgdHJhZGl0aW9u YWwgVlBMUyBkaWQsIE1BQyBsZWFybmluZyBvbiBBQyBvciBQVyBpbg0KPiA+IG9uZSBFLVRyZWUu IE9yIHNheSwgaWYgb25lIFBFIGhhcyBSb290LW9ubHkgQUNzLCBpdCB3aWxsIHNldHVwIG9uZSBQ Vw0KPiA+IHdpdGggYW5vdGhlciBQRSwgUm9vdC1vbmx5LCBMZWFmLW9ubHkgb3IgUm9vdC1MZWFm LU1peGVkLiBJZiAyIFBFcyBhcmUNCj4gPiByb290LUxlYWYtTWl4ZWQgb3Igb3RoZXIgY2FzZXMs IHRoZW4gMiBQV3Mgd2lsbCBiZSBlc3RhYmxpc2hlZC4gQXMgeW91DQo+ID4ga25vdywgdGhpcyBj YW4gYmUgZG9uZSBvbiBjb250cm9sIHBsYW5lLg0KPiA+DQo+ID4gW0pZXSBBc3N1bWUgdGhlcmUg YXJlIDIgb3RoZXIgbm9kZXMgUEUzICYgUEU0IGluIHRoaXMgbmV0d29yaw0KPiBzY2VuYXJpbywN Cj4gPiBhbmQgYm90aCBQRTMgYW5kIFBFNCBoYXZlIGJvdGggcm9vdCBhbmQgbGVhZiBBQ3MsIHRo ZW4gdGhlcmUgYXJlDQo+ID4gY29tcGF0aWJsZSBQV3MgZnJvbSBQRTMgd2hpY2ggbWF5IGNhcnJ5 IGJvdGggcm9vdCBhbmQgbGVhZiB0cmFmZmljICh0bw0KPiA+IFBFMSksIHdoaWNoIG1heSBjYXJy eSBvbmx5IHJvb3QgdHJhZmZpYyAodG8gUEUyKTsgYW5kIGZ1cnRoZXIgdGhlcmUNCj4gYXJlDQo+ ID4gcm9vdCBQVyBhbmQgbGVhZiBQVyB0byBQRTQuIFRodXMsIHRoZSBWU0kgb24gUEUzIGhhcyBh dCBsZWFzdCA0DQo+ID4gZGlmZmVyZW50IHR5cGVzIG9mIFBXIHRyYW5zbWl0dGluZyBiZWhhdmlv dXJzIHdpdGggcmVnYXJkIHRvIHRoZQ0KPiBFLVRyZWUNCj4gPiB0cmFmZmljLiBJbiB0aGUgcmV2 ZXJzZSBkaXJlY3Rpb24sIHRoZSBWU0kgb24gUEUzIGZ1cnRoZXIgaGFzIGF0IGxlYXN0DQo+ID4g NCBkaWZmZXJlbnQgdHlwZXMgb2YgUFcgcmVjZWl2aW5nIGJlaGF2aW91cnMuIE5vdCBzdXJlIGhv dyB5b3Ugd2lsbA0KPiA+IGFjY29tbW9kYXRlIGZvciB0aGVzZSBQV3MgaW4gYm90aCB0aGUgZGF0 YSBwbGFuZSBhbmQgY29udHJvbCBwbGFuZS4NCj4gPg0KPiA+IFJlZ2FyZHMsDQo+ID4gWXVhbmxv bmcNCj4gPg0KPiA+IElzIHRoaXMgY2xlYXIgZm9yIHlvdT8gSXMgdGhpcyBuZWNlc3NhcnkgdG8g b3B0aW1pemUgUFcgc2V0dXAgaW4gdGhpcw0KPiA+IGNhc2U/DQo+ID4NCj4gPiBNYXliZSB3ZSBu ZWVkIHRvIGFkZCBvbmUgcGFyYWdyYXBoIG9uIGZvcndhcmRpbmcgYmVoYXZpb3IuDQo+ID4NCj4g PiBBZ2FpbiB0aGFuayB5b3UgdmVyeSBtdWNoIGZvciB5b3VyIGNvbW1lbnRzLA0KPiA+DQo+ID4g U2FtDQo+ID4NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IEppYW5n eXVhbmxvbmcgW21haWx0bzpqaWFuZ3l1YW5sb25nQGh1YXdlaS5jb21dDQo+ID4gU2VudDogVHVl c2RheSwgTWF5IDE1LCAyMDEyIDEwOjI3IEFNDQo+ID4gVG86IFNhbSBDYW87ICdEYW5pZWwgQ29o bic7ICdBbGV4YW5kZXIgVmFpbnNodGVpbicNCj4gPiBDYzogbDJ2cG5AaWV0Zi5vcmcNCj4gPiBT dWJqZWN0OiBSRTogRGlzY3Vzc2lvbiBvbiBFLVRyZWUgYW5kIEgtVlBMUw0KPiA+DQo+ID4gUGxl YXNlIHNlZSBteSBjb21tZW50cyBpbiBsaW5lLg0KPiA+DQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gPiBGcm9tOiBTYW0gQ2FvIFttYWlsdG86eXVxdW4uY2FvQGdtYWlsLmNvbV0N Cj4gPiBTZW50OiBNb25kYXksIE1heSAxNCwgMjAxMiA4OjMxIFBNDQo+ID4gVG86IEppYW5neXVh bmxvbmc7ICdEYW5pZWwgQ29obic7ICdBbGV4YW5kZXIgVmFpbnNodGVpbicNCj4gPiBDYzogbDJ2 cG5AaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSRTogRGlzY3Vzc2lvbiBvbiBFLVRyZWUgYW5kIEgt VlBMUw0KPiA+DQo+ID4gSGkgWXVhbmxvbmcsDQo+ID4NCj4gPiBXZSBoYXZlIGRpc2N1c3NlZCB0 aGlzIGluIGFub3RoZXIgdGhyZWFkLiBJbiBmYWN0LCBEYW5pZWwgb3IgSSBoYXZlDQo+ID4gZ2l2 ZW4gdGhlIGFuc3dlcnMgdG8gdGhlIHF1ZXN0aW9ucyB5b3UgcmFpc2VkIGhlcmUgZm9yIHNldmVy YWwgdGltZQ0KPiA6KS4NCj4gPiBJZiB3ZSBkbyBpbiB0aGlzIHdheSwgd2Ugd2lsbCByZWFjaCBk ZWFkbG9jayBhbmQgY2FuIG5vdCBtb3ZlIGZvcndhcmQNCj4gPiA6KS4gSSB0cnkgdG8gZXhwbGFp biBpdCBhZ2Fpbi4NCj4gPg0KPiA+IFtKWV0gSSB3aWxsIGFwb2xvZ2l6ZSBpZiB5b3UgaGFkIGV2 ZXIgcHJvdmlkZWQgc3VjaCBhbnN3ZXJzIGJlZm9yZSwNCj4gYW5kDQo+ID4geW91IG1heSBqdXN0 IHJlZmVyIHRvIHRoZSBsaW5rcyByYXRoZXIgdGhhbiByZXBlYXQgdGhlIGV4cGxhbmF0aW9uLg0K PiA+IEFzIHlvdSBjYW4gc2VlLCBJIGp1c3QgdHJ5IHRvIHVuZGVyc3RhbmQgdGhlIG1lY2hhbmlz bSBvZiAyUFcgYW5kIGl0cw0KPiA+IGltcGxpY2F0aW9ucywgYnV0IHRoZSBJLUQgZG9lcyBub3Qg aW5jbHVkZSBlbm91Z2ggaW5mb3JtYXRpb24uDQo+ID4NCj4gPiBBcyB5b3Uga25vdywgaW5pdGlh bCBkZXNpZ24gd2Ugd2lsbCBzZXR1cCAyIFBXcyBhbGwgdGhlIHRpbWUgKGlmIGRvIGluDQo+ID4g dGhpcyB3YXksIEkgdGhpbmsgdGhhdCB5b3UgaGF2ZSBubyBxdWVzdGlvbiksDQo+ID4NCj4gPiBb SlldIEkgd2lsbCBiZSBjb25jZXJuZWQgd2l0aCB0aGUgb3BlcmF0aW9uYWwgY29tcGxleGl0eSBv ZiB0aGlzDQo+ID4gYXBwcm9hY2guDQo+ID4NCj4gPiBidXQgaW4gbW9zdCBjYXNlcyAyIFBXcyBh cmUgbm90DQo+ID4gbmVjZXNzYXJ5LiBTbyBpbiAwMSB2ZXJzaW9uLCB3ZSBvcHRpbWl6ZSBpdC4N Cj4gPg0KPiA+ICJSb290LW9ubHkgVlNJIDwtPiBhbnkgVlNJOiBvbmx5IHJvb3QgUFcgcmVxdWly ZWQiDQo+ID4gIkxlYWYtb25seSBWU0kgPC0+IGxlYWYtb25seSBWU0k6IG5vIFBXcyByZXF1aXJl ZCINCj4gPg0KPiA+IEluIG90aGVyIGNhc2VzIDIgUFdzIGFyZSBuZWVkZWQuIElmIHNvLCAiTGVh Zi1vbmx5IC0+IHJvb3Qtb25seSA9IG9uZQ0KPiA+IGxlYWYgUFciIGlzIG5vdCBjb3JyZWN0OiBP biBMZWFmLW9ubHkgc2lkZSwgeWVzLCBvbmUgTGVhZi1vbmx5IFBXIGlzDQo+ID4gY3JlYXRlZCBi ZXR3ZWVuIExvY2FsIExlYWYgdHlwZSB3aXRoIHJlbW90ZSBSb290IHR5cGU7IG9uIHJvb3Qtb25s eQ0KPiA+IHNpZGUsIG9uZSByb290LW9ubHkgUFcgaXMgY3JlYXRlZC4gTWF5YmUgaXQgaXMgYmV0 dGVyIHRvIGNhbGwgdGhpcyBhcw0KPiA+IGNvbXBhdGlibGUgb3IgbWl4ZWQgUFcuIFNvIHRoZSBs ZWZ0IGl0ZW1zIHlvdSBsaXN0IGFyZSBub3QgY29ycmVjdCBmb3INCj4gPiBtdWx0aV9QVyBzb2x1 dGlvbi4NCj4gPg0KPiA+IFtKWV0gVGhpcyBpcyBzb21ldGhpbmcgbmV3LCByaWdodD8gVG8gYmUg aG9uZXN0LCBJIGNvdWxkIG5vdA0KPiB1bmRlcnN0YW5kDQo+ID4gd2hhdCBpcyB5b3VyIHBvaW50 OiBkb2Vzbid0IHRoZSBtaXhlZCBQVyBhcyB5b3UgY2FsbGVkIGFsc28gY29uc2lzdCBvZg0KPiA+ IG9uZSBMZWFmLW9ubHkgUFcgaW4gb25lIGRpcmVjdGlvbiBhbmQgb25lIHJvb3Qtb25seSBQVyBp biB0aGUgb3RoZXINCj4gPiBkaXJlY3Rpb24/DQo+ID4gRnVydGhlcm1vcmUsIHRoZSBjYXNlIHlv dSB0b29rIGlzIGFsc28gb25lIGNhc2UgaW4geW91ciBndWlkZWxpbmUNCj4gPiAiUm9vdC1vbmx5 IFZTSSA8LT4gYW55IFZTSTogb25seSByb290IFBXIHJlcXVpcmVkIiwgZG9uJ3QgeW91IHRoaW5r DQo+ID4gdGhhdCBvbmx5IG9uZSByb290IFBXIGlzIHJlcXVpcmVkIGZvbGxvd2luZyB0aGlzIGd1 aWRlbGluZT8NCj4gPiBBY3R1YWxseSwgSSBkb24ndCBjYXJlIG11Y2ggYWJvdXQgd2hhdCBpcyB0 aGUgYmlkaXJlY3Rpb25hbCBQVyBvcg0KPiA+IHVuaWRpcmVjdGlvbmFsIFBXIGNhbGxlZCwgYnV0 IGhvdyBjYW4gYSBWU0kgc3VwcG9ydCBzdWNoIGEgbWl4ZWQNCj4gPiBzY2VuYXJpb3M6DQo+ID4g dHJhZGl0aW9uYWwgVlNJIGFzc3VtZXMgb25seSBvbmUgUFcgaXMgcmVxdWlyZWQgZm9yIGVhY2gg cGVlciBWU0ksIGFuZA0KPiA+IGl0cyBNQUMgbGVhbmluZyBpcyBiYXNlZCBvbiBiaWRpcmVjdGlv bmFsIFBXLiBCdXQgZm9yIDJQVywgdGhlcmUgYXJlDQo+ID4gYmlkaXJlY3Rpb25hbCByb290IFBX LCBiaWRpcmVjdGlvbmFsIGxlYWYgUFcsIG1peGVkIFBXLCBldGMuLi4sIGhvdyB0bw0KPiA+IHN1 cHBvcnQgdGhlc2Uga2luZHMgb2YgUFdzIGluIHRoZSBzYW1lIFZTSSBpcyBteSB0b3AgY29uY2Vy bi4NCj4gPg0KPiA+IEJUVywgSSBndWVzcyB5b3UgYWxzbyBjYXJlIHRoaXMgY2FzZSB3ZSBhbHNv IGhhdmUgZGlzY3Vzc2VkIGJlZm9yZToNCj4gZm9yDQo+ID4gZXhhbXBsZSwgaWYgd2UgY29uZmln dXJlIG9uZSBMZWFmIEFDIG9uIHJvb3Qtb25seSBQRSAodGhlbiBpdCB3aWxsIGJlDQo+ID4gcm9v dC1sZWFmLW1peGVkIFBFKSwgd2Ugd2lsbCB0ZWFyZG93biB0aGUgY29tcGF0aWJsZSBQVyBhbmQg cmUtc2V0dXANCj4gPiBQV3MgYWdhaW4gd2l0aCAwMS4NCj4gPiBbSlldIFRoaXMgd2FzIGRpc2N1 c3NlZCBpbiB0aGUgZW1haWxzIGluZGVlZC4NCj4gPg0KPiA+IFJlZ2FyZHMsDQo+ID4NCj4gPiBZ dXF1biAoU2FtKSBDYW8NCj4gPiBFLW1haWw6IFl1cXVuLmNhb0BnbWFpbC5jb20NCj4gPg0KPiA+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogSmlhbmd5dWFubG9uZyBbbWFp bHRvOmppYW5neXVhbmxvbmdAaHVhd2VpLmNvbV0NCj4gPiBTZW50OiBNb25kYXksIE1heSAxNCwg MjAxMiA3OjEwIFBNDQo+ID4gVG86IERhbmllbCBDb2huOyBBbGV4YW5kZXIgVmFpbnNodGVpbjsg U2FtIENhbw0KPiA+IENjOiBsMnZwbkBpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJFOiBEaXNjdXNz aW9uIG9uIEUtVHJlZSBhbmQgSC1WUExTDQo+ID4NCj4gPiBIaSBEYW5pZWwsDQo+ID4NCj4gPiBG aW5lLCBub3cgaXQgc2VlbXMgbW9yZSBpbiBsaW5lIHdpdGggd2hhdCB3ZSBoYWQgcHJvcG9zZWQg aW4gMlZMQU46IGENCj4gPiBzcG9rZSBQVyBiZWhhdmVzIGxpa2Ugcm9vdC9sZWFmIEFDIGZvciBh IFBFLXIuDQo+ID4NCj4gPiBCdXQgdGhlIHNhbWUgcHJvYmxlbSBtYXkgYWxzbyBhcHBseSB0byB0 aGUgcm9vdC9zcG9rZSAiY29yZSBQVyIgZm9yDQo+ID4gTXVsdGktUFc6DQo+ID4gQWNjb3JkaW5n IHRvIE11bHRpLVBXLCBvbmx5IG9uZSBQVyBpcyByZXF1aXJlZCBiZXR3ZWVuIHR3byBQRXMgZXhj ZXB0DQo+ID4gd2hlbiBib3RoIFBFcyBhcmUgbWl4ZWQgd2l0aCByb290IGFuZCBsZWFmLCBzbyB0 aGVzZSBQV3MgbWF5IGJlIGZvcm1lZA0KPiA+IGJ5IGNvbWJpbmF0aW9ucyBvZiB0aGUgZm9sbG93 aW5nIHVuaWRpcmVjdGlvbmFsIFBXIGNhc2VzIChleHRyYWN0ZWQNCj4gYW5kDQo+ID4gYWRhcHRl ZCBmcm9tIEpvc2gncyBlbWFpbCk6DQo+ID4gUm9vdC1vbmx5IC0+IGFueSBWU0kgPSBvbmUgcm9v dCBQVw0KPiA+IExlYWYtb25seSAtPiByb290LW9ubHkgPSBvbmUgbGVhZiBQVw0KPiA+IExlYWYt b25seSAtPiBtaXhlZCA9IG9uZSBsZWFmIFBXDQo+ID4gTWl4ZWQgLT4gcm9vdC1vbmx5ID0gb25l IChyb290K2xlYWYpIFBXDQo+ID4gTWl4ZWQgLT4gbGVhZi1vbmx5ID0gb25lIChyb290K2xlYWYp IFBXDQo+ID4NCj4gPiBJIGhhdmUgYSBjb25jZXJuIHRoYXQgdGhlIGZvcndhcmRpbmcgcGxhbmUg b2YgUEUgdG8gaW1wbGVtZW50IHRoaXMNCj4gd2lsbA0KPiA+IGJlIHZlcnkgZGlmZmVyZW50IGZy b20gdGhlIHRyYWRpdGlvbmFsIFZQTFMuDQo+ID4NCj4gPiBSZWdhcmRzLA0KPiA+IFl1YW5sb25n DQo+ID4NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IERhbmllbCBD b2huIFttYWlsdG86RGFuaWVsQ0BvcmNraXQuY29tXQ0KPiA+IFNlbnQ6IE1vbmRheSwgTWF5IDE0 LCAyMDEyIDU6MDAgUE0NCj4gPiBUbzogSmlhbmd5dWFubG9uZzsgQWxleGFuZGVyIFZhaW5zaHRl aW47IFNhbSBDYW8NCj4gPiBDYzogbDJ2cG5AaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSRTogRGlz Y3Vzc2lvbiBvbiBFLVRyZWUgYW5kIEgtVlBMUw0KPiA+DQo+ID4gSGkgWXVhbmxvbmcsDQo+ID4N Cj4gPiBMaWtlIEkgd3JvdGUgYmVsb3csIHJvb3QvbGVhZiBzcG9rZSBQVyBiZWhhdmUgbGlrZSBy b290L2xlYWYgQUMsIG5vdA0KPiA+IGxpa2Ugcm9vdC9zcG9rZSAiY29yZSBQVyIuIFNvIG5vIGNo YW5nZXMgdG8gZm9yd2FyZGluZyBwbGFuZSBvbmNlIHRoaXMNCj4gPiBpcyB1bmRlcnN0b29kLg0K PiA+DQo+ID4gREMNCj4gPg0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJv bTogSmlhbmd5dWFubG9uZyBbbWFpbHRvOmppYW5neXVhbmxvbmdAaHVhd2VpLmNvbV0NCj4gPiBT ZW50OiBNb25kYXksIE1heSAxNCwgMjAxMiAxMTozNiBBTQ0KPiA+IFRvOiBEYW5pZWwgQ29objsg QWxleGFuZGVyIFZhaW5zaHRlaW47IFNhbSBDYW8NCj4gPiBDYzogbDJ2cG5AaWV0Zi5vcmcNCj4g PiBTdWJqZWN0OiBSRTogRGlzY3Vzc2lvbiBvbiBFLVRyZWUgYW5kIEgtVlBMUw0KPiA+DQo+ID4g RGFuaWVsLCBwbGVhc2Ugc2VlIG15IGNvbW1lbnRzIGluIGxpbmUuDQo+ID4NCj4gPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IERhbmllbCBDb2huIFttYWlsdG86RGFuaWVs Q0BvcmNraXQuY29tXQ0KPiA+IFNlbnQ6IE1vbmRheSwgTWF5IDE0LCAyMDEyIDM6MzcgUE0NCj4g PiBUbzogSmlhbmd5dWFubG9uZzsgQWxleGFuZGVyIFZhaW5zaHRlaW47IFNhbSBDYW8NCj4gPiBD YzogbDJ2cG5AaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSRTogRGlzY3Vzc2lvbiBvbiBFLVRyZWUg YW5kIEgtVlBMUw0KPiA+DQo+ID4gSGkgWXVhbmxvbmcsDQo+ID4NCj4gPiBBcyBJIHNlZSBpdCwg Zm9yIHRoZSBQRS1yIHNwb2tlIChmaWd1cmUgNCBpbiBSRkMgNDc2Mikgd2UgZXN0YWJsaXNoIGEN Cj4gPiBzaW5nbGUgUFcgcGVyIEFDIC0gcm9vdCBQVyBmb3Igcm9vdCBBQyBhbmQgbGVhZiBQVyBm b3IgbGVhZiBBQy4gV2l0aA0KPiA+IGxvY2FsIGNvbmZpZ3VyYXRpb24gYXQgdGhlIFBFLXJzIGFz IHBhcnQgb2YgdGhlIHNwb2tlIFBXIHByb3Zpc2lvbmluZy4NCj4gPiBBbmQgdGhlIFBFLXJzIHdp bGwgdHJlYXQgcm9vdC9sZWFmIHNwb2tlIFBXcyBleGFjdGx5IGFzIGl0IHRyZWF0DQo+ID4gcm9v dC9sZWFmIEFDcy4gU28gd2hlbiBsZWFmLW9yaWdpbmF0ZWQgQlVNIHRyYWZmaWMgYXJyaXZlcyBm cm9tIHRoZQ0KPiA+IGNvcmUgKG92ZXIgYSBsZWFmIFBXKSwgaXQgd2lsbCBiZSBmb3J3YXJkZWQg b3ZlciBhbGwgcm9vdCBzcG9rZSBQV3MNCj4gYnV0DQo+ID4gbm90IG9uIHRoZSBsZWFmIHNwb2tl IFBXcy4NCj4gPg0KPiA+IFtKWV0gU28gaW4gdGhlIHJldmVyc2UgZGlyZWN0aW9uLCB5b3UgbmVl ZCB0byB0cmFuc3BvcnQgYm90aCByb290IGFuZA0KPiA+IGxlYWYgdHJhZmZpYyBmcm9tIFBFLXJz IG92ZXIgYSByb290IFBXIHRvIFBFLXIsIGFuZCB0cmFuc3BvcnQgcm9vdA0KPiA+IHRyYWZmaWMg b3ZlciBhIGxlYWYgUFcuIEl0IHNlZW1zIGFnYWluc3QgdGhlIGRlZmluaXRpb24gb2Ygcm9vdCBQ VyBhbmQNCj4gPiBsZWFmIFBXIGluIHRoZSBtdWx0aS1QVyBkcmFmdC4gRG9uJ3QgdGhpcyBtYWtl IHRoZSBmb3J3YXJkaW5nIHBsYW5lIG9mDQo+ID4gUEUtcnMgbW9yZSBjb21wbGV4Pw0KPiA+DQo+ ID4gVGhlIGZvcndhcmRpbmcgcGxhbmUgaXMgZXhhY3RseSB0aGUgc2FtZSBhcyBkZXNjcmliZWQg aW4gdGhlIG11bHRpLVBXDQo+ID4gZHJhZnQsIHdoZXJlIHNwb2tlIFBXcyBhcmUgdHJlYXRlZCBl eGFjdGx5IGxpa2UgQUNzLg0KPiA+DQo+ID4gUmVnYXJkcywNCj4gPg0KPiA+IERhbmllbA0KPiA+ DQo+ID4NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IEppYW5neXVh bmxvbmcgW21haWx0bzpqaWFuZ3l1YW5sb25nQGh1YXdlaS5jb21dDQo+ID4gU2VudDogRnJpZGF5 LCBNYXkgMTEsIDIwMTIgNTowMyBBTQ0KPiA+IFRvOiBEYW5pZWwgQ29objsgQWxleGFuZGVyIFZh aW5zaHRlaW47IFNhbSBDYW8NCj4gPiBDYzogbDJ2cG5AaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBS RTogRGlzY3Vzc2lvbiBvbiBFLVRyZWUgYW5kIEgtVlBMUw0KPiA+DQo+ID4gSGkgRGFuaWVsIGFu ZCBhbGwsDQo+ID4NCj4gPiBXaGVuIHlvdSBzZXQgdXAgdHdvIFBXcyBmcm9tIHRoZSBQRS1ycyB0 byBhIFBFLXIgZm9yIGVhY2ggb2YgaXRzIEFDLA0KPiBkbw0KPiA+IHlvdSBtZWFuIHRoYXQgb25l IFBXIGlzIGJpZGlyZWN0aW9uYWwgcm9vdCBQVyBhbmQgdGhlIG90aGVyIGlzDQo+ID4gYmlkaXJl Y3Rpb25hbCBsZWFmIFBXPw0KPiA+IE15IGNvbmNlcm4gaXM6IHdoZXJlIHNob3VsZCB0aGUgbGVh ZiB0cmFmZmljIGJlIGZpbHRlcmVkLCBvbiB0aGUgUEUtcnMNCj4gPiBvciBvbiB0aGUgUEUtcj8N Cj4gPiBJZiBmaWx0ZXJlZCBvbiB0aGUgUEUtciwgdGhlbiBsb3RzIG9mIGJhbmR3aWR0aCB3aWxs IGJlIHdhc3RlZCAoZm9yDQo+ID4gZXhhbXBsZSwgaWYgdGhlIFBFLXIgaXMgYXR0YWNoZWQgd2l0 aCA5IGxlYWZzLCB0aGVuIHRoZSBCVU0gdHJhZmZpYw0KPiA+IGZyb20gb25lIG9mIGl0cyBsZWFm cyB3aWxsIGJlIG11bHRpcGxpZWQgYnkgOCB0aW1lcywgYW5kIGJlIGZvcndhcmRlZA0KPiA+IGJ5 IHRoZSBQRS1ycyB0byB0aGUgc2FtZSBQRS1yKS4NCj4gPiBJZiBmaWx0ZXJlZCBvbiB0aGUgUEUt cnMsIG5vdCBzdXJlIGhvdyB5b3Ugd2lsbCBkZXNpZ24gaXRzIGZvcndhcmRpbmcNCj4gPiBwbGFu ZSwgY2FuIHlvdSBnaXZlIGEgaGludD8NCj4gPg0KPiA+IFRoYW5rcywNCj4gPiBZdWFubG9uZw0K PiA+DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gRGF0ZTogV2VkLCA5 IE1heSAyMDEyIDA5OjE2OjM2ICswMzAwDQo+ID4gRnJvbTogIkRhbmllbCBDb2huIiA8RGFuaWVs Q0BvcmNraXQuY29tPg0KPiA+IFRvOiAiQWxleGFuZGVyIFZhaW5zaHRlaW4iIDxBbGV4YW5kZXIu VmFpbnNodGVpbkBlY2l0ZWxlLmNvbT4sDQo+ICJTYW0NCj4gPiAgICAgICBDYW8iIDx5dXF1bi5j YW9AZ21haWwuY29tPiwgPGwydnBuQGlldGYub3JnPg0KPiA+IENjOiBsaXpob25nLmppbkB6dGUu Y29tLmNuDQo+ID4gU3ViamVjdDogUkU6IERpc2N1c3Npb24gb24gRS1UcmVlIGFuZCBILVZQTFMN Cj4gPiBNZXNzYWdlLUlEOiA8NDRGNEU1NzlBNzY0NTg0RUE5QkRGRDA3RDBDQTA4MTMwNzgwQ0JB NkB0bHZtYWlsMT4NCj4gPiBDb250ZW50LVR5cGU6IHRleHQvcGxhaW47ICAgICBjaGFyc2V0PSJJ U08tMjAyMi1KUCINCj4gPg0KPiA+IEhpIFNhc2hhLA0KPiA+DQo+ID4gSXQncyBhY3R1YWxseSB2 ZXJ5IHNpbXBsZS4gQSBmcmFtZSB0aGF0IG9yaWdpbmF0ZWQgaW4gYSByb290IEFDIGlzDQo+ID4g YWx3YXlzIHRyYW5zbWl0dGVkIG9ubHkgaW4gcm9vdCBQVywgbm8gbWF0dGVyIHdoYXQgdGhlIGZy YW1lIHR5cGUNCj4gPiAoa25vd24vdW5rbm93biB1bmljYXN0IG9yIGJyb2FkY2FzdCkuIFRoaXMg aXMgaG93IHRoZSBmcmFtZSBzb3VyY2UNCj4gPiBpbmZvcm1hdGlvbiBpcyBwcm9wYWdhdGVkIGFj cm9zcyB0aGUgVlBMUy4gU28gaW4gdGhlIEgtVlBMUyBleGFtcGxlLA0KPiA+IHRoZSBQRS1yIHdp bGwgbmV2ZXIgZm9yd2FyZCBhIGZyYW1lIHJlY2VpdmVkIG92ZXIgYSByb290IFBXIG9uIGFueQ0K PiBsZWFmDQo+ID4gUFcsIG9ubHkgb24gcm9vdCBQV3MgKHRvd2FyZCB0aGUgY29yZSBvciB0b3dh cmQgb3RoZXIgc3Bva2VzKS4NCj4gPg0KPiA+IEhvcGUgdGhpcyBjbGFyaWZpZXMgaXQsIHJlZ2Fy ZHMsDQo+ID4NCj4gPiBEYW5pZWwNCj4gPg0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+ID4gRnJvbTogbDJ2cG4tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwydnBuLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZg0KPiA+IE9mIEFsZXhhbmRlciBWYWluc2h0ZWluDQo+ID4gU2Vu dDogV2VkbmVzZGF5LCBNYXkgMDksIDIwMTIgNzo1OSBBTQ0KPiA+IFRvOiBTYW0gQ2FvOyBsMnZw bkBpZXRmLm9yZw0KPiA+IENjOiBsaXpob25nLmppbkB6dGUuY29tLmNuDQo+ID4gU3ViamVjdDog UkU6IERpc2N1c3Npb24gb24gRS1UcmVlIGFuZCBILVZQTFMNCj4gPg0KPiA+IFNhbSwgTGl6aG9u ZyBhbmQgYWxsLA0KPiA+IFlvdSd2ZSB3cml0dGVuIHRoYXQgaW4gdGhlIHR3by1QVyBzb2x1dGlv biBjb21iaW5lZCB3aXRoIEgtVlBMUyB0aGUNCj4gUEUtDQo+ID4gciBtdXN0IHNldCB1cCB0d28g UFdzIHdpdGggZWFjaCBNVFUtcy4NCj4gPg0KPiA+IElmIHRoaXMgaXMgdGhlIGNhc2UsIHdoYXQg a2luZCBvZiBmb3J3YXJkaW5nIGxvZ2ljIHNob3VsZCBiZSB1c2VkIHRvDQo+ID4gcHJldmVudCBz ZW5kaW5nIGEgQlVNIGZyYW1lIHJlY2VpdmVkIGZyb20gYSByb290LVBXIHRvIGEgZ2l2ZW4gTVRV LVM6DQo+ID4gLSBiYWNrIHRvIHRoZSBzYW1lIE1UVS1TIG9uIHRoZSBjb3JyZXNwb25kaW5nIGxl YWYtUFc/DQo+ID4gLSB0d2ljZSAodG8gYm90aCByb290LVBXIGFuZCBMZWFmLVBXKSB0byBhbm90 aGVyIE1UVS1zPyBBbmQsIEJUVywgaG93DQo+ID4gaXMgdGhlIFBXIHNlbGVjdGVkIGluIHRoaXMg Y2FzZT8NCj4gPg0KPiA+IEkgYW0gYXdhcmUgb2YgYSB0ZWNobmlxdWUgb2YgbXVsdGlwbGUgc3Bs aXQgaG9yaXpvbiBncm91cHMgaW4gUEUtcg0KPiA+IHdoaWNoIGNvdWxkIGJlIHBvc3NpYmx5IHVz ZWQgZm9yIHRoaXMgcHVycG9zZS4gSG93ZXZlciwgc2luY2UgdGhlc2UNCj4gPiBncm91cHMgaGF2 ZSB0byBiZSByZXByZXNlbnRlZCBleHBsaWNpdGx5IGluIHRoZSBkYXRhIHBsYW5lLCB0aGVpcg0K PiA+IHBvdGVudGlhbCBudW1iZXIgaXMgbGltaXRlZCBieSB0aGUgZm9yd2FyZGluZyBIVy4gT3Ro ZXIgbWV0aG9kcyBjb3VsZA0KPiA+IGJlIHByb2JhYmx5IHVzZWQgZm9yIHRoZSBzYW1lIHB1cnBv c2UsIGJ1dCB0aGV5IHdvdWxkIHByb2JhYmx5IHN1YmplY3QNCj4gPiB0byBzaW1pbGFyIEhXLWJh c2VkIGxpbWl0YXRpb25zLg0KPiA+DQo+ID4gSSBzdXNwZWN0IHRoYXQgd2l0aCB0aGUgZHVhbC1Q VyBhcHByb2FjaCwgdGhlIEhXIHdvdWxkIHBvc2UgYW4NCj4gaW1wbGljaXQNCj4gPiBsaW1pdCwg c2F5LCBvbiBhIG51bWJlciBvZiBNVFUtcyB0aGF0IGNhbiBiZSBjb25uZWN0ZWQgdG8gdGhlIHNh bWUNCj4gUEUtcg0KPiA+IGFuZCB0aGF0IHRoaXMgbGltaXQgY291bGQgYmUgcXVpdGUgbG93IGlu IG1vc3QgY2FzZXMuDQo+ID4NCj4gPiBCYXNlZCBvbiB0aGlzIEkgc3VzcGVjdCB0aGF0IHRoZSBI LVZQTFMgaXNzdWUgYXMgYSBjcml0aWNhbCBkcmF3YmFjaw0KPiBvZg0KPiA+IHRoZSBkdWFsLVBX IGFwcHJvYWNoIHRvIEUtVHJlZS4NCj4gPg0KPiA+IE15IDJjLA0KPiA+ICAgICAgU2FzaGENCj4g Pg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ IEZyb206IGwydnBuLWJvdW5jZXNAaWV0Zi5vcmcgW2wydnBuLWJvdW5jZXNAaWV0Zi5vcmddIG9u IGJlaGFsZiBvZiBTYW0NCj4gPiBDYW8gW3l1cXVuLmNhb0BnbWFpbC5jb21dDQo+ID4gU2VudDog V2VkbmVzZGF5LCBNYXkgMDksIDIwMTIgMzo0MCBBTQ0KPiA+IFRvOiBsMnZwbkBpZXRmLm9yZw0K PiA+IENjOiBsaXpob25nLmppbkB6dGUuY29tLmNuDQo+ID4gU3ViamVjdDogUkU6IERpc2N1c3Np b24gb24gRS1UcmVlIGFuZCBILVZQTFMNCj4gPg0KPiA+IEhpIExpemhvbmc/DQo+ID4NCj4gPiBU aGFuayB5b3UgdmVyeSBtdWNoIGZvciB5b3VyIGNvbW1lbnRzLiBJIHVwZGF0ZWQgdGhlIHJlc3Vs dCBvbiB0aGlzDQo+ID4gcXVlc3Rpb24uDQo+ID4NCj4gPiBbTGl6aG9uZ10gYWdyZWUgd2l0aCB0 aGUgYWJvdmUgYW5hbHlzaXMuIEFuZCB3ZSBkaWQgbm90IHNheSBpdCBpcyBhDQo+ID4gdGVjaG5p Y2FsIHByb2JsZW0sIGJ1dCBpdCBpcyBhbiBvcGVyYXRpb25hbCBwcm9ibGVtIGFnYWluLg0KPiA+ IFtTYW1dIEkgYWdyZWUuIER1YWwtVkxBTiBkb2VzIG5vdCBtYWtlIHNlbnNlLiBJIGFsc28gZGlz Y3Vzc2VkIHRoaXMNCj4gPiB3aXRoIEdpbGVzIGFuZCBZdWFubG9uZyBpbiBhbm90aGVyIG1haWws IGFuZCB3ZSByZWFjaGVkIGFncmVlbWVudCBvbg0KPiA+IHRoaXM6DQo+ID4gTVRVIHNob3VsZCBr bm93IHRoZSBhY2Nlc3MgbW9kZSwgVlBXUyBvciBWUExTLCBWUFdTIG1vZGUgc2hvdWxkDQo+ID4g Y29uZmlndXJlIFZMQU4gSUQgb24gTVRVIGJ1dCBWUExTIG1vZGUgY2FuIG5vdC4gSSB0aG91Z2h0 IHRoaXMgaXMgTk9UDQo+ID4gcmVhc29uYWJsZSA6KSwgYnV0IHdlIGNhbiBmaWd1cmUgdGhpcyBv dXQgaW4gZHJhZnQuIEl0IHNlZW1zIG9rLg0KPiA+DQo+ID4gW0xpemhvbmddIG5vdCBmdWxseSB1 bmRlcnN0YW5kLiBEbyB5b3UgbWVhbiwgIHdoZW4gVlBXUyBhY2Nlc3NpbmcgZm9yDQo+ID4gSC1W UExTLCB0aGUgUEUtciBpcyBhbHNvIG5lY2Vzc2FyeSB0byBjb25maWd1cmUgdHdvIFBXcyAocm9v dCBhbmQgbGVhZg0KPiA+IFBXKSBmb3IgZWFjaCBBQyBhY2Nlc3M/DQo+ID4gW1NhbV0gWWVzLg0K PiA+DQo+ID4gVGhhbmtzLA0KPiA+DQo+ID4gU2FtDQo+ID4NCj4gPg0KPiA+DQo+ID4NCg0KDQpU aGlzIGUtbWFpbCBtZXNzYWdlIGlzIGludGVuZGVkIGZvciB0aGUgcmVjaXBpZW50IG9ubHkgYW5k IGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIGlzIENPTkZJREVOVElBTCBhbmQgd2hpY2ggbWF5 IGJlIHByb3ByaWV0YXJ5IHRvIEVDSSBUZWxlY29tLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGluZm9ybSB1cyBieSBlLW1haWwsIHBob25l IG9yIGZheCwgYW5kIHRoZW4gZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYWxsIGNvcGllcyB0aGVy ZW9mLg0KDQo= From Alexander.Vainshtein@ecitele.com Wed May 16 00: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 8E70021F8798 for ; Wed, 16 May 2012 00:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.024 X-Spam-Level: X-Spam-Status: No, score=-5.024 tagged_above=-999 required=5 tests=[AWL=0.974, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, 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 P1POq+tD3CY2 for ; Wed, 16 May 2012 00:39:39 -0700 (PDT) Received: from mail1.bemta4.messagelabs.com (mail1.bemta4.messagelabs.com [85.158.143.242]) by ietfa.amsl.com (Postfix) with ESMTP id 18D7121F8797 for ; Wed, 16 May 2012 00:39:38 -0700 (PDT) Received: from [85.158.143.99:59646] by server-3.bemta-4.messagelabs.com id 16/E5-05853-AB953BF4; Wed, 16 May 2012 07:39:38 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1337153977!27337897!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.5.10; banners=-,-,- Received: (qmail 30117 invoked from network); 16 May 2012 07:39:37 -0000 Received: from unknown (HELO fridlpvsb005.ecitele.com) (168.87.1.157) by server-13.tower-216.messagelabs.com with SMTP; 16 May 2012 07:39:37 -0000 X-AuditID: a8571406-b7f656d0000010a7-d9-4fb359b58e16 Received: from FRIDWPPCH002.ecitele.com (fridwppch002.ecitele.com [10.1.16.53]) by fridlpvsb005.ecitele.com (Symantec Messaging Gateway) with SMTP id 73.31.04263.5B953BF4; Wed, 16 May 2012 09:39:33 +0200 (CEST) Received: from FRIDWPPMB001.ecitele.com ([169.254.3.187]) by FRIDWPPCH002.ecitele.com ([10.1.16.53]) with mapi id 14.01.0339.001; Wed, 16 May 2012 09:39:36 +0200 From: Alexander Vainshtein To: Daniel Cohn Subject: RE: Discussion on forwarding performance Thread-Topic: Discussion on forwarding performance Thread-Index: AQHNLxo31u2OjZw96UuBF9QPOwJXg5bHcLkAgAGHLZCAAAmjYIAAHGPggAAUqSCAAOHDIIAAM7tggAAlyMCAADHVIIAAElJAgAAmSSCAAGzc8IAAspUAgAAH+MCAAAIx84AACK2w Date: Wed, 16 May 2012 07:39:36 +0000 Message-ID: References: <20ab01cd3330$0ced2b69$05280101@corrigent.com> In-Reply-To: <20ab01cd3330$0ced2b69$05280101@corrigent.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="utf-8" content-transfer-encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupml+LIzCtJLcpLzFFi42LhYmSQ0t0audnf4Mhfa4uGS4uZLFZPucRu cfVDO5vF42+H2C3mNp9lc2D1aH22l9Vj56y77B4tR96yeixZ8pPJo3vDZOYA1qgGRpvEvLz8 ksSSVIWU1OJkW6WAosyyxORKJYXMFFslQyWFgpzE5NTc1LwSW6XEgoLUvBQlOy4FDGADVJaZ p5Cal5yfkpmXbqvkGeyva2FhaqlrqGQXkpFZrJCqm5uYmaOQm1pcnJieqgAUAfklLyVhHXPG i7nOBU/eM1bs2rmErYHxwkvGLkZODgkBE4nW3x3sELaYxIV769m6GLk4hASuMEp8XPqUGcJZ yijx/9ERsA42AVuJTavvsoHYIgIqEhuvfWQHKWIW2MYocXzjbGaQhLCAocTRztmsEEVGEttX LwWbJCIwjVHifcdysCIWAVWJdzN7wWxeAV+JBRPegt0hJGAlMfXhQRYQm1PAWmLv66NMIDYj 0H3fT60Bs5kFxCVuPZnPBHG3gMSSPeeZIWxRiZeP/7FC2HISTSuvAM3kAKrXlFi/Sx+iVVFi SvdDdoi1ghInZz5hgSiXlDi44gbLBEbxWUg2zELonoWkexaS7gWMLKsYJdKKMlNyCsqKkwwM TPVSkzNLUnNS9ZLzczcxApPRinARth2MDRP0DjEKcDAq8fBadG7yF2JNLCuuzD3EKMnBpCTK eyV8s78QX1J+SmVGYnFGfFFpTmrxIUYJDmYlEV6Xp0DlvCmJlVWpRfkwKQtgEE5kluJOzgdF ckm8sYEBCkdJnHd9kJ2/kEA6MOVlp6YWpBbBtMpwcChJ8C6KANooWJSanlqRlplTgpBm4uAE 2cwDtPkiSA1vcUFibnFmOkT+FKMhx5+Hi64xcjzeuwxI9j1ac41RiCUvPy9VSpx3BUiDAEhD Rmke3MxXjOJAfwvz3gPJ8gBTJdy0V0CLmIAWleWCvFgMzCVwKakGRu8P3kXv2e7ZnG/P15k9 vd506iZ162dmwhsjLlp/XF+0bPWUvtLpTkc9G95L8Ts883lc0Rcp3Oz5Tu+Lp5nxt4x6v4sn Lj+wVmK6vlbJMlDwjkyAT+Dn2Aolodmc9acFrKu8jepu2uw4uUzr4cc3N2VrPq3cIbmN8+Lx +LK5t7yWtsWEB76IVGIpzkg01GIuKk4EAJlXZzIeBAAA Cc: "l2vpn@ietf.org" , Sam Cao , Jiangyuanlong 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, 16 May 2012 07:39:41 -0000 RGFuLA0KTG90cyBvZiB0aGFua3MgZm9yIGEgcHJvbXB0IHJlc3BvbnNlLg0KDQpJdCBpcyBu b3QgYWx3YXlzIGVhc3kgdG8gZHJhdyBhIGxpbmUgYmV0d2VlbiBwZXJmb3JtYW5jZSBhbmQg c2ltcGxpY2l0eSBvZiBpbXBsZW1lbnRhdGlvbiBpc3N1ZXMgdGhhdCBhcmUgYXBwcm9wcmlh dGUgZm9yIGRpc2N1c3Npb24gb24gYW4gSUVURiBtYWlsaW5nIGxpc3QgYW5kIG9uZXMgdGhh dCBhcmUgbm90Lg0KDQpBIGNsZWFyLWN1dCBjYXNlIG9mIGFuIGFwcHJvcHJpYXRlIGlzc3Vl IHdvdWxkIGJlIGEgbnVtYmVyIG9mIGJpdHMgb24gdGhlIHdpcmUgdGhhdCBhIGNlcnRhaW4g cHJvdG9jb2wgYWRkcyAtIGJlY2F1c2UgaXQgd291bGQgZXF1YWxseSBhZmZlY3QgYWxsIGlu dGVyb3BlcmFibGUgcHJvdG9jb2wgaW1wbGVtZW50YXRpb25zLg0KDQpBIGxlc3MgY2xlYXIg Y2FzZSBpcyBhIHJlZmVyZW5jZSB0byB0aGUgbnVtYmVyIG9mIGxhYmVsIGxvb2t1cHMgYXQg d2lyZXNwZWVkIHRoYXQgYXJlIHJlcXVpcmVkIGJ5IGEgcHJvdG9jb2w6IGFsbCBpbnRlcm9w ZXJhYmxlIGltcGxlbWVudGF0aW9ucyBzaG91bGQgYmUgcmVhZHkgdG8gcGVyZm9ybSB0aGlz IG51bWJlciBvZiBsb29rdXBzLCBidXQgaWYgc29tZSBvZiB0aGVtIGNhbm5vdCBkbyB0aGF0 IGF0IHdpcmVzcGVlZCwgaXQgaXMgYW4gaW1wbGVtZW50YXRpb24tc3BlY2lmaWMgcHJvYmxl bS4gVGhleSBzaG91bGQgYmUgY29uc2lkZXJlZCBvbmx5IGlmIHRoZSByZXF1aXJlZCBudW1i ZXIgb2YgbGFiZWwgbG9va3VwcyBleGNlZWRzIHdoYXQgaXMgY29tbW9ubHkgYWdyZWVkIHRv IGJlIGEgZGUtZmFjdG8gaW5kdXN0cnkgc3RhbmRhcmQgLSBhbmQgc3ViamVjdCB0byByZWNv bnNpZGVyYXRpb24gZnJvbSB0aW1lIHRvIHRpbWUuIFRoZXJlIGhhcyBiZWVuIHRpbWUgd2hl biBsb29raW5nIHVwIHR3byBsYWJlbHMgcmVxdWlyZWQgYSBkZWRpY2F0ZWQgcGh5c2ljYWwg aW50ZXJmYWNlIGNsb3NlZCBpbiBhIGxvb3AsIGFuZCBQSFAgaXMgb25lIG9mIHRoZSBoYWNr cyBpbnRyb2R1Y2VkIGluIE1QTFMgdG8gb3ZlcmNvbWUgdGhpcyBsaW1pdGF0aW9uLiBUb2Rh eSBzb21lIE1QTFMtVFAgcGVvcGxlIHVzdWFsbHkgZG8gbm90IGNhcmUgYWJvdXQgdGhlIG51 bWJlciBvZiBsYWJlbHMgdGhhdCBoYXZlIHRvIGJlIGxvb2tlZCB1cC4uLg0KDQpBdCB0aGUg c2FtZSB0aW1lLCByZWZlcmVuY2VzIHRvIGEgc3BlY2lmaWMgbG9va3VwIGltcGxlbWVudGF0 aW9uIChlLmcuLCBUQ0FNIHZzLiBhIGhhc2ggdGFibGUgdnMuIGEgZGlyZWN0IHRhYmxlICkg YXJlIElNSE8gY2xlYXJseSBiZXlvbmQgdGhlIHBhbGUuIA0KDQpNeSAyYywNCiAgICAgU2Fz aGENCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IERhbmllbCBD b2huIFttYWlsdG86RGFuaWVsQ0BvcmNraXQuY29tXQ0KPiBTZW50OiBXZWRuZXNkYXksIE1h eSAxNiwgMjAxMiA5OjQ3IEFNDQo+IFRvOiBBbGV4YW5kZXIgVmFpbnNodGVpbjsgQmFsdXMs IEZsb3JpbiBTdGVsaWFuIChGbG9yaW4pOyBTYW0gQ2FvOw0KPiBKaWFuZ3l1YW5sb25nDQo+ IENjOiBsMnZwbkBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogRGlzY3Vzc2lvbiBvbiBmb3J3 YXJkaW5nIHBlcmZvcm1hbmNlDQo+IA0KPiBXaHkgbm90PyBBcmVuJ3QgZWFzZSBvZiBpbXBs ZW1lbnRhdGlvbiBhbmQgcGVyZm9ybWFuY2UgZWZmaWNpZW5jeSB2YWxpZA0KPiBjb25zaWRl cmF0aW9ucyB3aGVuIHNlbGVjdGluZyBvbmUgc29sdXRpb24gb3ZlciBhbm90aGVyPw0KPiAN Cj4gVGh1bWIgdHlwZWQgLSBwbGVhc2UgYmUgdG9sZXJhbnQNCj4gDQo+IEFsZXhhbmRlciBW YWluc2h0ZWluIDxBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbT4gd3JvdGU6DQo+ IA0KPiBEYW5pZWwsIGFuZCBhbGwsDQo+IEkgYW0gbm90IHN1cmUgdGhhdCBkaXNjdXNzaW9u IG9mIGltcGxlbWVudGF0aW9uLXNwZWNpZmljIGlzc3VlcyAoZS5nLiwNCj4gd2hldGhlciB5 b3UgdXNlIG9yIGRvIG5vdCB1c2UgVENBTSBsb29rdXBzKSByZWFsbHkgYmVsb25ncyB0byB0 aGlzIGxpc3QuDQo+IA0KPiBSZWdhcmRzLA0KPiAgICAgIFNhc2hhDQo+IA0KPiA+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogRGFuaWVsIENvaG4gW21haWx0bzpE YW5pZWxDQG9yY2tpdC5jb21dDQo+ID4gU2VudDogV2VkbmVzZGF5LCBNYXkgMTYsIDIwMTIg OToxNiBBTQ0KPiA+IFRvOiBCYWx1cywgRmxvcmluIFN0ZWxpYW4gKEZsb3Jpbik7IFNhbSBD YW87IEppYW5neXVhbmxvbmc7IEFsZXhhbmRlcg0KPiA+IFZhaW5zaHRlaW4NCj4gPiBDYzog bDJ2cG5AaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSRTogRGlzY3Vzc2lvbiBvbiBmb3J3YXJk aW5nIHBlcmZvcm1hbmNlDQo+ID4NCj4gPiBIaSwNCj4gPg0KPiA+IEkgYWdyZWUgdGhhdCBm b3IgYSBjaGlwLWJhc2VkIHNvbHV0aW9uIHRoZXJlIHNob3VsZCBiZSBubyBkaWZmZXJlbmNl IGluDQo+ID4gcGVyZm9ybWFuY2UgZm9yIHRoZSBhZGRpdGlvbmFsIGxvb2t1cC4gSG93ZXZl ciBmcm9tIGNvbnZlcnNhdGlvbnMgd2l0aA0KPiA+IGNoaXAgdmVuZG9ycywgSSB1bmRlcnN0 b29kIHRoZXJlIG1pZ2h0IGJlIGFuIGltcGFjdCBvbiBzY2FsYWJpbGl0eQ0KPiA+IGJlY2F1 c2UgdGhlIGRvdWJsZSBsb29rdXAgd291bGQgcmVxdWlyZSBhIGxvbmdlciBzZWFyY2gga2V5 IChhc3N1bWluZw0KPiA+IFZMQU4gYW5kIFZDSUQgbG9va3VwcyBhcmUgcGVyZm9ybWVkIHNp bXVsdGFuZW91c2x5IG9uIGluZ3Jlc3MpLCB0aHVzDQo+ID4gdGFraW5nIHVwIG1vcmUgVENB TSByZXNvdXJjZXMgcGVyIEUtVHJlZSBpbnN0YW5jZS4gVGhpcyB3b3VsZCBkZXBlbmQNCj4g b24NCj4gPiBzcGVjaWZpYyBUQ0FNIGltcGxlbWVudGF0aW9uIChlLmcuIGdyYW51bGFyaXR5 IG9mIHNlYXJjaCBrZXkgbGVuZ3RoKS4NCj4gPg0KPiA+IERDDQo+ID4NCj4gPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IEJhbHVzLCBGbG9yaW4gU3RlbGlhbiAo RmxvcmluKQ0KPiA+IFttYWlsdG86ZmxvcmluLmJhbHVzQGFsY2F0ZWwtbHVjZW50LmNvbV0N Cj4gPiBTZW50OiBUdWVzZGF5LCBNYXkgMTUsIDIwMTIgMTA6NTMgUE0NCj4gPiBUbzogU2Ft IENhbzsgJ0ppYW5neXVhbmxvbmcnOyBEYW5pZWwgQ29objsgJ0FsZXhhbmRlciBWYWluc2h0 ZWluJw0KPiA+IENjOiBsMnZwbkBpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJFOiBEaXNjdXNz aW9uIG9uIGZvcndhcmRpbmcgcGVyZm9ybWFuY2UNCj4gPg0KPiA+IFNhbSwNCj4gPg0KPiA+ ID4gT2J2aW91c2x5IHRoZSBmb3J3YXJkaW5nIHBlcmZvcm1hbmNlIG9mIER1YWwtVkxBTiB3 aWxsIGJlIG11Y2ggbG93ZXINCj4gPiB0aGFuIHdoYXQgb2YgTXVsdGktUFcuDQo+ID4NCj4g PiBTb3JyeSBJIGNvdWxkIG5vdCBrZWVwIHVwIHdpdGggc29tZSBvZiB0aGUgdGhyZWFkcyBv biB0aGlzIHN1YmplY3QgYnV0DQo+ID4gdGhlIGFib3ZlIHN0YXRlbWVudCBjYXVnaHQgbXkg ZXllcy4gV2UgaGF2ZSBiZWVuIGRvaW5nIGFsbCBraW5kIG9mDQo+ID4gZWdyZXNzIG9wZXJh dGlvbnMgb24gVkxBTnMgaW4gdGhlIGVncmVzcyBQRSBmb3IgdGhlIGxhc3QgOCB5ZWFycyBh bmQgSQ0KPiA+IGFtIG5vdCBhd2FyZSBvZiBhbnkgIm11Y2ggbG93ZXIiIGZvcndhcmRpbmcg cGVyZm9ybWFuY2UuIEFzIGZhciBhcyBJDQo+ID4ga25vdyB0aGUgY2hpcHNldHMgdXNlZCBp biB0aGUgUEVzIGNhbiBkbyB0aGlzIHByb2Nlc3Npbmcgbm8gcHJvYmxlbS4gRG8NCj4gPiB5 b3Ugd2FudCB0byBjbGFyaWZ5IHdoaWNoIGtpbmQgb2YgaGFyZHdhcmUgbWF5IGhhdmUgcHJv YmxlbXM/DQo+ID4NCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBG cm9tOiBsMnZwbi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRm Lm9yZ10gT24NCj4gQmVoYWxmDQo+ID4gPiBPZiBTYW0gQ2FvDQo+ID4gPiBTZW50OiBUdWVz ZGF5LCBNYXkgMTUsIDIwMTIgNjozMiBBTQ0KPiA+ID4gVG86ICdKaWFuZ3l1YW5sb25nJzsg J0RhbmllbCBDb2huJzsgJ0FsZXhhbmRlciBWYWluc2h0ZWluJw0KPiA+ID4gQ2M6IGwydnBu QGlldGYub3JnDQo+ID4gPiBTdWJqZWN0OiBSRTogRGlzY3Vzc2lvbiBvbiBmb3J3YXJkaW5n IHBlcmZvcm1hbmNlDQo+ID4gPg0KPiA+ID4gSGkgWXVhbmxvbmcsDQo+ID4gPg0KPiA+ID4g M3JkIG1hcHBpbmcgd2lsbCBtYWtlIGRhdGEgcGxhbmUgY29tcGxleCwgSSB0aGluay4gQW55 d2F5LCB3ZSByZWFjaGVkDQo+ID4gYQ0KPiA+ID4gY29uc2Vuc3VzIG9uIE11bHRpLVBXIGlt cGxlbWVudGF0aW9uLg0KPiA+ID4NCj4gPiA+IElmIHdlIHVzZSAzcmQgbWFwcGluZywgSSBh Z3JlZSB3aXRoIHlvdXIgb3BpbmlvbiwgbWF5YmUgZHVhbC1WTEFODQo+ID4gc2VlbXMNCj4g PiA+IHNpbXBsZSwgYnV0IDIgbWFwcGluZyBpcyBlbm91Z2guIFRoZW4gd2UgY2FuIGZvY3Vz IG9uIGRhdGEgcGxhbmUNCj4gPiA+IHBlcmZvcm1hbmNlLiBXaGlsZSBzdHJpcGUgUFcgbGFi ZWwgb3V0IG9uIGVncmVzcyBQRSwgZGF0YS1wbGFuZSBrbm93cw0KPiA+ID4gaG93IHRvIGZv cndhcmQgdGhlIGZyYW1lcyBmcm9tIFBXLCB0byBSb290IEFDIG9yIExlYWYgQUMgb3IgYWxs LiBCdXQNCj4gPiBpZg0KPiA+ID4gd2UgdXNlIER1YWwtVkxBTiwgYWZ0ZXIgc3RyaXAgUFcg bGFiZWwgb3V0LCBkYXRhIHBsYW5lIHNob3VsZCBzdHJpcA0KPiA+ID4gVkxBTi1JRCBvdXQg YW5kIHRoZW4gZG9lcyBzYW1lIGZvcndhcmRpbmcgd29yayBhcyBNdWx0aS1QVyBkb2VzLiBU aGUNCj4gPiA+IG1vc3QgaW1wb3J0YW50IGlzLCBkbyBvbmUgbW9yZSBvcGVyYXRpb24gd2hp bGUgZm9yd2FyZGluZyBFLVRyZWUNCj4gPiA+IGZyYW1lcy4gT2J2aW91c2x5IHRoZSBmb3J3 YXJkaW5nIHBlcmZvcm1hbmNlIG9mIER1YWwtVkxBTiB3aWxsIGJlDQo+IG11Y2gNCj4gPiA+ IGxvd2VyIHRoYW4gd2hhdCBvZiBNdWx0aS1QVy4NCj4gPiA+DQo+ID4gPiBSZWdhcmRzLA0K PiA+ID4NCj4gPiA+IFl1cXVuIChTYW0pIENhbw0KPiA+ID4gRS1tYWlsOiBZdXF1bi5jYW9A Z21haWwuY29tDQo+ID4gPg0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g PiA+IEZyb206IEppYW5neXVhbmxvbmcgW21haWx0bzpqaWFuZ3l1YW5sb25nQGh1YXdlaS5j b21dDQo+ID4gPiBTZW50OiBUdWVzZGF5LCBNYXkgMTUsIDIwMTIgNzowMyBQTQ0KPiA+ID4g VG86IFNhbSBDYW87ICdEYW5pZWwgQ29obic7ICdBbGV4YW5kZXIgVmFpbnNodGVpbicNCj4g PiA+IENjOiBsMnZwbkBpZXRmLm9yZw0KPiA+ID4gU3ViamVjdDogUkU6IERpc2N1c3Npb24g b24gRS1UcmVlIGFuZCBILVZQTFMNCj4gPiA+DQo+ID4gPiBTZWUgbXkgZnVydGhlciBjb21t ZW50cyBpbiBsaW5lLg0KPiA+ID4NCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+ID4gPiBGcm9tOiBTYW0gQ2FvIFttYWlsdG86eXVxdW4uY2FvQGdtYWlsLmNvbV0NCj4g PiA+IFNlbnQ6IFR1ZXNkYXksIE1heSAxNSwgMjAxMiA2OjE0IFBNDQo+ID4gPiBUbzogSmlh bmd5dWFubG9uZzsgJ0RhbmllbCBDb2huJzsgJ0FsZXhhbmRlciBWYWluc2h0ZWluJw0KPiA+ ID4gQ2M6IGwydnBuQGlldGYub3JnDQo+ID4gPiBTdWJqZWN0OiBSRTogRGlzY3Vzc2lvbiBv biBFLVRyZWUgYW5kIEgtVlBMUw0KPiA+ID4NCj4gPiA+IEhpIFl1YW5sb25nLA0KPiA+ID4N Cj4gPiA+IFRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHlvdXIgY29tbWVudHMuIEkgZHJhdyB0 aGUgdG9wb2xvZ3kgeW91IGdhdmUsDQo+ID4gPiBhbmQgNyBQV3Mgd2lsbCBiZSBlc3RhYmxp c2hlZCBpZiB3ZSBmb2xsb3cgMDEuDQo+ID4gPg0KPiA+ID4gUm9vdCBBQyAtLS0tIFBFIDEg LS0tLS0gUFcgMSAtLS0tLS0tLSBQRSAyIC0tLS0tIExlYWYgX0FDDQo+ID4gPiAgICAgICAg ICAgICAgICB8ICBcICAgICAgICAgICAgICAgICAvICB8fA0KPiA+ID4gICAgICAgICAgICAg ICAgfCAgIFwgIC89PT1QVyA2LDc9PT0gICAgfHwNCj4gPiA+ICAgICAgICAgICAgICAgICBQ VyAyICAtLS0tLVBXIDUtLS0tLS1cICB8fA0KPiA+ID4gICAgICAgICAgICAgICAgfCAgLy0t LS1Sb290IFBXIDMgLS0tIFwgfHwNCj4gPiA+IFJvb3QgX0FDIC0tLS0gUEUgMyAgICAgICAg ICAgICAgICAgICAgUEUgNCAtLS0tLS0gUm9vdCBBQw0KPiA+ID4gICAgICAgICAgICAgICAg fCAgIFwgICAgICAgICAgICAgICAgICAvICB8DQo+ID4gPiAgICAgICAgICAgICAgICB8ICAg IC0tLS1MZWFmIFBXIDQtLS0tLSAgIHwNCj4gPiA+ICAgICAgICAgICAgIExlYWYgQUMgICAg ICAgICAgICAgICAgICAgIExlYWYgQUMNCj4gPiA+IFllcywgb24gUEUgMyB0aGVyZSBhcmUg c2V2ZXJhbCBQV3MsIGJ1dCBpZiB5b3Ugd2FudCB0byBjbGFyaWZ5IGl0LA0KPiA+ID4gdGhl cmUgYXJlIG9ubHkgMyB0eXBlcywgb25lIGNhbiBjYXJyeSBmcmFtZXMgb3JpZ2luYXRlZCBm cm9tIFJvb3QgYW5kDQo+ID4gPiBMZWFmIEFDKG9uZSBlbmRwb2ludCBvZiB0aGlzIFBXIHNo b3VsZCBiZSBSb290LW9ubHksIG90aGVyd2lzZSB0aGlzIGlzDQo+ID4gPiBpbnZhbGlkKSwg b25lIG9ubHkgY2FuIGNhcnJ5IGZyYW1lcyBmcm9tIFJvb3QgQUMsIGFuZCB0aGUgbGFzdCBj YW4NCj4gPiA+IGNhcnJ5IGZyYW1lcyBmcm9tIExlYWYgQUNzLiBPbiBzZWNvbmQgdGhvdWdo dHMsIHdlIHN0aWxsIGNhbiBjbGFzc2lmeQ0KPiA+ID4gdGhlIFBXcyBpbnRvIDIgc2V0cywg b25lIGlzIExlYWYgc2V0LCBhbmQgYW5vdGhlciBpcyBSb290IHNldCwgYW5kIHRoZQ0KPiA+ ID4gdW5pb24gb2YgdGhlIHNldHMgTGVhZiBhbmQgUm9vdCBpcyB0aGUgUFcgd2UgY2FsbGVk IGl0IGFzIGNvbXBhdGlibGUNCj4gPiBQVw0KPiA+ID4gKE1heWJlIHRoaXMgaXMgbm90IGNv cnJlY3QsIHdlIGNhbiBmaW5kIG9uZSBnb29kIHRlcm0gb24gdGhpcykuDQo+ID4gPg0KPiA+ ID4gU28gdGhpcyBvcHRpbWl6YXRpb24gc3RpbGwgZm9sbG93cyB0aGUgb3JpZ2luYWwgZGVz aWduIG9mIER1YWwtUFcNCj4gPiA+IGFwcHJvYWNoLCBMZWFmIFBXIG9ubHkgY2FycmllcyBm cmFtZXMgZnJvbSBMZWFmIEFDOyBSb290LVBXIG9ubHkNCj4gPiA+IGNhcnJpZXMgZnJhbWVz IGZyb20gUm9vdCBBQy4gSXMgaXQgcmlnaHQ/DQo+ID4gPg0KPiA+ID4gSSBkb24ndCBrbm93 IHdoZXRoZXIgY2hpcCBjYW4gc3VwcG9ydCB0aGlzIGZvcndhcmRpbmcgYmVoYXZpb3IgZm9y DQo+ID4gPiBjb21wYXRpYmxlIFBXIG9yIG5vdCwgYnV0IGlmIHdlIGltcGxlbWVudCBpdCBp biBOUCwgaXQgaXMgbmVhcmx5IHNhbWUNCj4gPiA+IGFzIFZQTFMuIFRoZSBvbmx5IGRpZmZl cmVuY2UgaXMsIHNldHVwIDIgbWFwcGluZ3MsIG9uZSBiZXR3ZWVuDQo+ID4gTGVhZi1BQ3MN Cj4gPiA+IGFuZCBMZWFmLVBXcywgb25lIGJldHdlZW4gUm9vdC1BQ3MgYW5kIFJvb3QtUFdz LiBGb3IgdHJhZGl0aW9uYWwNCj4gVlBMUywNCj4gPiA+IHRoZXJlIGlzIG9ubHkgb25lIG1h cHBpbmcuDQo+ID4gPg0KPiA+ID4gW0pZXSBJdCBzZWVtcyB5b3UgbWF5IG5lZWQgYSAzcmQg bWFwcGluZzogZnJvbSBib3RoIHJvb3QgJiBsZWFmIEFDIHRvDQo+ID4gYQ0KPiA+ID4gY29t cGF0aWJsZSBQVy4NCj4gPiA+IEJUVywgZm9yIHRoZSBmb3J3YXJkaW5nIGFuZCByZXZlcnNl IGRpcmVjdGlvbiwgdGhlIG1hcHBpbmcgbWF5IGJlDQo+ID4gPiBhc3ltbWV0cmljIGZvciB5 b3UgY29tcGF0aWJsZSBQVy4NCj4gPiA+DQo+ID4gPiBCYXNlZCBvbiBteSB1bmRlcnN0YW5k aW5nLCBhbGwgZHJhZnRzIHNob3VsZCBoYXZlIHNpbWlsYXIgbWFwcGluZy4NCj4gPiA+DQo+ ID4gPiBbSlldIER1YWwtVkxBTiBzZWVtcyBzaW1wbGVyIGhlcmUuDQo+ID4gPg0KPiA+ID4g VGhhbmtzLA0KPiA+ID4NCj4gPiA+IFNhbQ0KPiA+ID4NCj4gPiA+DQo+ID4gPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogSmlhbmd5dWFubG9uZyBbbWFpbHRv OmppYW5neXVhbmxvbmdAaHVhd2VpLmNvbV0NCj4gPiA+IFNlbnQ6IFR1ZXNkYXksIE1heSAx NSwgMjAxMiAzOjMyIFBNDQo+ID4gPiBUbzogU2FtIENhbzsgJ0RhbmllbCBDb2huJzsgJ0Fs ZXhhbmRlciBWYWluc2h0ZWluJw0KPiA+ID4gQ2M6IGwydnBuQGlldGYub3JnDQo+ID4gPiBT dWJqZWN0OiBSRTogRGlzY3Vzc2lvbiBvbiBFLVRyZWUgYW5kIEgtVlBMUw0KPiA+ID4NCj4g PiA+IFNhbSwNCj4gPiA+DQo+ID4gPiBUaGFua3MsIHBsZWFzZSBzZWUgbXkgZnVydGhlciBj b21tZW50cyB3aXRoIFtKWV0uDQo+ID4gPg0KPiA+ID4gT2ssIHdlIGdvIG9uIHRoZSBjYXNl IGluIHlvdXIgbWFpbCwgd2hlcmUgUEUxIGhhcyBvbmUgUm9vdC1vbmx5IEFDLA0KPiA+ID4g QUMxLCBhbmQNCj4gPiA+IFBFMiBoYXMgb25lIExlYWYtb25seSBBQywgQUMyLiBJbiBnZW5l cmFsIHdlIGNhbiBzZXR1cCAyDQo+ID4gPiAidW5pZGlyZWN0aW9uYWwiDQo+ID4gPiBQV3Mg KGJpZGlyZWN0aW9uYWwgUFcsIGJ1dCBqdXN0IGNhcnJ5IHVuaWRpcmVjdGlvbmFsIGZyYW1l cyksIFJvb3QtUFcNCj4gPiA+IHdoaWNoIGNhcnJpZXMgZnJhbWVzIG9yaWdpbmF0ZWQgZnJv bSBBQzEgYW5kIExlYWYtUFcgd2hpY2ggY2Fycmllcw0KPiA+ID4gZnJhbWVzIG9yaWdpbmF0 ZWQgZnJvbSBBQzIuIEJ1dCBvbmx5IG9uZSBQVyBhbHNvIGNhbiB3b3JrLCBqdXN0IGFzDQo+ ID4gc29tZQ0KPiA+ID4gbWVtYmVycyBjb21tZW50ZWQuIE9rLCB3ZSBzZXR1cCBvbmUgUFcg YmV0d2VlbiBQRTEgYW5kIFBFMiwgd2UNCj4gPiBjYW4NCj4gPiBjYWxsDQo+ID4gPiB0aGlz IFBXIGFzIGNvbXBhdGlibGUgUFcgb3Igc29tZXRoaW5nIGVsc2UuIEZyYW1lcyBvcmlnaW5h dGVkIGZyb20NCj4gPiBSb290DQo+ID4gPiBvciBsZWFmIEFDcyB3aWxsIGJlIGNhcnJpZWQg dmlhIHRoaXMgUFcuIEl0cyBmb3J3YXJkaW5nIGJlaGF2aW9yIGlzDQo+ID4gPiBmdWxseSBz YW1lIGFzIHdoYXQgdHJhZGl0aW9uYWwgVlBMUyBkaWQsIE1BQyBsZWFybmluZyBvbiBBQyBv ciBQVyBpbg0KPiA+ID4gb25lIEUtVHJlZS4gT3Igc2F5LCBpZiBvbmUgUEUgaGFzIFJvb3Qt b25seSBBQ3MsIGl0IHdpbGwgc2V0dXAgb25lIFBXDQo+ID4gPiB3aXRoIGFub3RoZXIgUEUs IFJvb3Qtb25seSwgTGVhZi1vbmx5IG9yIFJvb3QtTGVhZi1NaXhlZC4gSWYgMiBQRXMgYXJl DQo+ID4gPiByb290LUxlYWYtTWl4ZWQgb3Igb3RoZXIgY2FzZXMsIHRoZW4gMiBQV3Mgd2ls bCBiZSBlc3RhYmxpc2hlZC4gQXMgeW91DQo+ID4gPiBrbm93LCB0aGlzIGNhbiBiZSBkb25l IG9uIGNvbnRyb2wgcGxhbmUuDQo+ID4gPg0KPiA+ID4gW0pZXSBBc3N1bWUgdGhlcmUgYXJl IDIgb3RoZXIgbm9kZXMgUEUzICYgUEU0IGluIHRoaXMgbmV0d29yaw0KPiA+IHNjZW5hcmlv LA0KPiA+ID4gYW5kIGJvdGggUEUzIGFuZCBQRTQgaGF2ZSBib3RoIHJvb3QgYW5kIGxlYWYg QUNzLCB0aGVuIHRoZXJlIGFyZQ0KPiA+ID4gY29tcGF0aWJsZSBQV3MgZnJvbSBQRTMgd2hp Y2ggbWF5IGNhcnJ5IGJvdGggcm9vdCBhbmQgbGVhZiB0cmFmZmljICh0bw0KPiA+ID4gUEUx KSwgd2hpY2ggbWF5IGNhcnJ5IG9ubHkgcm9vdCB0cmFmZmljICh0byBQRTIpOyBhbmQgZnVy dGhlciB0aGVyZQ0KPiA+IGFyZQ0KPiA+ID4gcm9vdCBQVyBhbmQgbGVhZiBQVyB0byBQRTQu IFRodXMsIHRoZSBWU0kgb24gUEUzIGhhcyBhdCBsZWFzdCA0DQo+ID4gPiBkaWZmZXJlbnQg dHlwZXMgb2YgUFcgdHJhbnNtaXR0aW5nIGJlaGF2aW91cnMgd2l0aCByZWdhcmQgdG8gdGhl DQo+ID4gRS1UcmVlDQo+ID4gPiB0cmFmZmljLiBJbiB0aGUgcmV2ZXJzZSBkaXJlY3Rpb24s IHRoZSBWU0kgb24gUEUzIGZ1cnRoZXIgaGFzIGF0IGxlYXN0DQo+ID4gPiA0IGRpZmZlcmVu dCB0eXBlcyBvZiBQVyByZWNlaXZpbmcgYmVoYXZpb3Vycy4gTm90IHN1cmUgaG93IHlvdSB3 aWxsDQo+ID4gPiBhY2NvbW1vZGF0ZSBmb3IgdGhlc2UgUFdzIGluIGJvdGggdGhlIGRhdGEg cGxhbmUgYW5kIGNvbnRyb2wgcGxhbmUuDQo+ID4gPg0KPiA+ID4gUmVnYXJkcywNCj4gPiA+ IFl1YW5sb25nDQo+ID4gPg0KPiA+ID4gSXMgdGhpcyBjbGVhciBmb3IgeW91PyBJcyB0aGlz IG5lY2Vzc2FyeSB0byBvcHRpbWl6ZSBQVyBzZXR1cCBpbiB0aGlzDQo+ID4gPiBjYXNlPw0K PiA+ID4NCj4gPiA+IE1heWJlIHdlIG5lZWQgdG8gYWRkIG9uZSBwYXJhZ3JhcGggb24gZm9y d2FyZGluZyBiZWhhdmlvci4NCj4gPiA+DQo+ID4gPiBBZ2FpbiB0aGFuayB5b3UgdmVyeSBt dWNoIGZvciB5b3VyIGNvbW1lbnRzLA0KPiA+ID4NCj4gPiA+IFNhbQ0KPiA+ID4NCj4gPiA+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBKaWFuZ3l1YW5sb25n IFttYWlsdG86amlhbmd5dWFubG9uZ0BodWF3ZWkuY29tXQ0KPiA+ID4gU2VudDogVHVlc2Rh eSwgTWF5IDE1LCAyMDEyIDEwOjI3IEFNDQo+ID4gPiBUbzogU2FtIENhbzsgJ0RhbmllbCBD b2huJzsgJ0FsZXhhbmRlciBWYWluc2h0ZWluJw0KPiA+ID4gQ2M6IGwydnBuQGlldGYub3Jn DQo+ID4gPiBTdWJqZWN0OiBSRTogRGlzY3Vzc2lvbiBvbiBFLVRyZWUgYW5kIEgtVlBMUw0K PiA+ID4NCj4gPiA+IFBsZWFzZSBzZWUgbXkgY29tbWVudHMgaW4gbGluZS4NCj4gPiA+DQo+ ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogU2FtIENhbyBb bWFpbHRvOnl1cXVuLmNhb0BnbWFpbC5jb21dDQo+ID4gPiBTZW50OiBNb25kYXksIE1heSAx NCwgMjAxMiA4OjMxIFBNDQo+ID4gPiBUbzogSmlhbmd5dWFubG9uZzsgJ0RhbmllbCBDb2hu JzsgJ0FsZXhhbmRlciBWYWluc2h0ZWluJw0KPiA+ID4gQ2M6IGwydnBuQGlldGYub3JnDQo+ ID4gPiBTdWJqZWN0OiBSRTogRGlzY3Vzc2lvbiBvbiBFLVRyZWUgYW5kIEgtVlBMUw0KPiA+ ID4NCj4gPiA+IEhpIFl1YW5sb25nLA0KPiA+ID4NCj4gPiA+IFdlIGhhdmUgZGlzY3Vzc2Vk IHRoaXMgaW4gYW5vdGhlciB0aHJlYWQuIEluIGZhY3QsIERhbmllbCBvciBJIGhhdmUNCj4g PiA+IGdpdmVuIHRoZSBhbnN3ZXJzIHRvIHRoZSBxdWVzdGlvbnMgeW91IHJhaXNlZCBoZXJl IGZvciBzZXZlcmFsIHRpbWUNCj4gPiA6KS4NCj4gPiA+IElmIHdlIGRvIGluIHRoaXMgd2F5 LCB3ZSB3aWxsIHJlYWNoIGRlYWRsb2NrIGFuZCBjYW4gbm90IG1vdmUgZm9yd2FyZA0KPiA+ ID4gOikuIEkgdHJ5IHRvIGV4cGxhaW4gaXQgYWdhaW4uDQo+ID4gPg0KPiA+ID4gW0pZXSBJ IHdpbGwgYXBvbG9naXplIGlmIHlvdSBoYWQgZXZlciBwcm92aWRlZCBzdWNoIGFuc3dlcnMg YmVmb3JlLA0KPiA+IGFuZA0KPiA+ID4geW91IG1heSBqdXN0IHJlZmVyIHRvIHRoZSBsaW5r cyByYXRoZXIgdGhhbiByZXBlYXQgdGhlIGV4cGxhbmF0aW9uLg0KPiA+ID4gQXMgeW91IGNh biBzZWUsIEkganVzdCB0cnkgdG8gdW5kZXJzdGFuZCB0aGUgbWVjaGFuaXNtIG9mIDJQVyBh bmQgaXRzDQo+ID4gPiBpbXBsaWNhdGlvbnMsIGJ1dCB0aGUgSS1EIGRvZXMgbm90IGluY2x1 ZGUgZW5vdWdoIGluZm9ybWF0aW9uLg0KPiA+ID4NCj4gPiA+IEFzIHlvdSBrbm93LCBpbml0 aWFsIGRlc2lnbiB3ZSB3aWxsIHNldHVwIDIgUFdzIGFsbCB0aGUgdGltZSAoaWYgZG8gaW4N Cj4gPiA+IHRoaXMgd2F5LCBJIHRoaW5rIHRoYXQgeW91IGhhdmUgbm8gcXVlc3Rpb24pLA0K PiA+ID4NCj4gPiA+IFtKWV0gSSB3aWxsIGJlIGNvbmNlcm5lZCB3aXRoIHRoZSBvcGVyYXRp b25hbCBjb21wbGV4aXR5IG9mIHRoaXMNCj4gPiA+IGFwcHJvYWNoLg0KPiA+ID4NCj4gPiA+ IGJ1dCBpbiBtb3N0IGNhc2VzIDIgUFdzIGFyZSBub3QNCj4gPiA+IG5lY2Vzc2FyeS4gU28g aW4gMDEgdmVyc2lvbiwgd2Ugb3B0aW1pemUgaXQuDQo+ID4gPg0KPiA+ID4gIlJvb3Qtb25s eSBWU0kgPC0+IGFueSBWU0k6IG9ubHkgcm9vdCBQVyByZXF1aXJlZCINCj4gPiA+ICJMZWFm LW9ubHkgVlNJIDwtPiBsZWFmLW9ubHkgVlNJOiBubyBQV3MgcmVxdWlyZWQiDQo+ID4gPg0K PiA+ID4gSW4gb3RoZXIgY2FzZXMgMiBQV3MgYXJlIG5lZWRlZC4gSWYgc28sICJMZWFmLW9u bHkgLT4gcm9vdC1vbmx5ID0gb25lDQo+ID4gPiBsZWFmIFBXIiBpcyBub3QgY29ycmVjdDog T24gTGVhZi1vbmx5IHNpZGUsIHllcywgb25lIExlYWYtb25seSBQVyBpcw0KPiA+ID4gY3Jl YXRlZCBiZXR3ZWVuIExvY2FsIExlYWYgdHlwZSB3aXRoIHJlbW90ZSBSb290IHR5cGU7IG9u IHJvb3Qtb25seQ0KPiA+ID4gc2lkZSwgb25lIHJvb3Qtb25seSBQVyBpcyBjcmVhdGVkLiBN YXliZSBpdCBpcyBiZXR0ZXIgdG8gY2FsbCB0aGlzIGFzDQo+ID4gPiBjb21wYXRpYmxlIG9y IG1peGVkIFBXLiBTbyB0aGUgbGVmdCBpdGVtcyB5b3UgbGlzdCBhcmUgbm90IGNvcnJlY3Qg Zm9yDQo+ID4gPiBtdWx0aV9QVyBzb2x1dGlvbi4NCj4gPiA+DQo+ID4gPiBbSlldIFRoaXMg aXMgc29tZXRoaW5nIG5ldywgcmlnaHQ/IFRvIGJlIGhvbmVzdCwgSSBjb3VsZCBub3QNCj4g PiB1bmRlcnN0YW5kDQo+ID4gPiB3aGF0IGlzIHlvdXIgcG9pbnQ6IGRvZXNuJ3QgdGhlIG1p eGVkIFBXIGFzIHlvdSBjYWxsZWQgYWxzbyBjb25zaXN0IG9mDQo+ID4gPiBvbmUgTGVhZi1v bmx5IFBXIGluIG9uZSBkaXJlY3Rpb24gYW5kIG9uZSByb290LW9ubHkgUFcgaW4gdGhlIG90 aGVyDQo+ID4gPiBkaXJlY3Rpb24/DQo+ID4gPiBGdXJ0aGVybW9yZSwgdGhlIGNhc2UgeW91 IHRvb2sgaXMgYWxzbyBvbmUgY2FzZSBpbiB5b3VyIGd1aWRlbGluZQ0KPiA+ID4gIlJvb3Qt b25seSBWU0kgPC0+IGFueSBWU0k6IG9ubHkgcm9vdCBQVyByZXF1aXJlZCIsIGRvbid0IHlv dSB0aGluaw0KPiA+ID4gdGhhdCBvbmx5IG9uZSByb290IFBXIGlzIHJlcXVpcmVkIGZvbGxv d2luZyB0aGlzIGd1aWRlbGluZT8NCj4gPiA+IEFjdHVhbGx5LCBJIGRvbid0IGNhcmUgbXVj aCBhYm91dCB3aGF0IGlzIHRoZSBiaWRpcmVjdGlvbmFsIFBXIG9yDQo+ID4gPiB1bmlkaXJl Y3Rpb25hbCBQVyBjYWxsZWQsIGJ1dCBob3cgY2FuIGEgVlNJIHN1cHBvcnQgc3VjaCBhIG1p eGVkDQo+ID4gPiBzY2VuYXJpb3M6DQo+ID4gPiB0cmFkaXRpb25hbCBWU0kgYXNzdW1lcyBv bmx5IG9uZSBQVyBpcyByZXF1aXJlZCBmb3IgZWFjaCBwZWVyIFZTSSwgYW5kDQo+ID4gPiBp dHMgTUFDIGxlYW5pbmcgaXMgYmFzZWQgb24gYmlkaXJlY3Rpb25hbCBQVy4gQnV0IGZvciAy UFcsIHRoZXJlIGFyZQ0KPiA+ID4gYmlkaXJlY3Rpb25hbCByb290IFBXLCBiaWRpcmVjdGlv bmFsIGxlYWYgUFcsIG1peGVkIFBXLCBldGMuLi4sIGhvdyB0bw0KPiA+ID4gc3VwcG9ydCB0 aGVzZSBraW5kcyBvZiBQV3MgaW4gdGhlIHNhbWUgVlNJIGlzIG15IHRvcCBjb25jZXJuLg0K PiA+ID4NCj4gPiA+IEJUVywgSSBndWVzcyB5b3UgYWxzbyBjYXJlIHRoaXMgY2FzZSB3ZSBh bHNvIGhhdmUgZGlzY3Vzc2VkIGJlZm9yZToNCj4gPiBmb3INCj4gPiA+IGV4YW1wbGUsIGlm IHdlIGNvbmZpZ3VyZSBvbmUgTGVhZiBBQyBvbiByb290LW9ubHkgUEUgKHRoZW4gaXQgd2ls bCBiZQ0KPiA+ID4gcm9vdC1sZWFmLW1peGVkIFBFKSwgd2Ugd2lsbCB0ZWFyZG93biB0aGUg Y29tcGF0aWJsZSBQVyBhbmQgcmUtc2V0dXANCj4gPiA+IFBXcyBhZ2FpbiB3aXRoIDAxLg0K PiA+ID4gW0pZXSBUaGlzIHdhcyBkaXNjdXNzZWQgaW4gdGhlIGVtYWlscyBpbmRlZWQuDQo+ ID4gPg0KPiA+ID4gUmVnYXJkcywNCj4gPiA+DQo+ID4gPiBZdXF1biAoU2FtKSBDYW8NCj4g PiA+IEUtbWFpbDogWXVxdW4uY2FvQGdtYWlsLmNvbQ0KPiA+ID4NCj4gPiA+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBKaWFuZ3l1YW5sb25nIFttYWlsdG86 amlhbmd5dWFubG9uZ0BodWF3ZWkuY29tXQ0KPiA+ID4gU2VudDogTW9uZGF5LCBNYXkgMTQs IDIwMTIgNzoxMCBQTQ0KPiA+ID4gVG86IERhbmllbCBDb2huOyBBbGV4YW5kZXIgVmFpbnNo dGVpbjsgU2FtIENhbw0KPiA+ID4gQ2M6IGwydnBuQGlldGYub3JnDQo+ID4gPiBTdWJqZWN0 OiBSRTogRGlzY3Vzc2lvbiBvbiBFLVRyZWUgYW5kIEgtVlBMUw0KPiA+ID4NCj4gPiA+IEhp IERhbmllbCwNCj4gPiA+DQo+ID4gPiBGaW5lLCBub3cgaXQgc2VlbXMgbW9yZSBpbiBsaW5l IHdpdGggd2hhdCB3ZSBoYWQgcHJvcG9zZWQgaW4gMlZMQU46IGENCj4gPiA+IHNwb2tlIFBX IGJlaGF2ZXMgbGlrZSByb290L2xlYWYgQUMgZm9yIGEgUEUtci4NCj4gPiA+DQo+ID4gPiBC dXQgdGhlIHNhbWUgcHJvYmxlbSBtYXkgYWxzbyBhcHBseSB0byB0aGUgcm9vdC9zcG9rZSAi Y29yZSBQVyIgZm9yDQo+ID4gPiBNdWx0aS1QVzoNCj4gPiA+IEFjY29yZGluZyB0byBNdWx0 aS1QVywgb25seSBvbmUgUFcgaXMgcmVxdWlyZWQgYmV0d2VlbiB0d28gUEVzIGV4Y2VwdA0K PiA+ID4gd2hlbiBib3RoIFBFcyBhcmUgbWl4ZWQgd2l0aCByb290IGFuZCBsZWFmLCBzbyB0 aGVzZSBQV3MgbWF5IGJlDQo+IGZvcm1lZA0KPiA+ID4gYnkgY29tYmluYXRpb25zIG9mIHRo ZSBmb2xsb3dpbmcgdW5pZGlyZWN0aW9uYWwgUFcgY2FzZXMgKGV4dHJhY3RlZA0KPiA+IGFu ZA0KPiA+ID4gYWRhcHRlZCBmcm9tIEpvc2gncyBlbWFpbCk6DQo+ID4gPiBSb290LW9ubHkg LT4gYW55IFZTSSA9IG9uZSByb290IFBXDQo+ID4gPiBMZWFmLW9ubHkgLT4gcm9vdC1vbmx5 ID0gb25lIGxlYWYgUFcNCj4gPiA+IExlYWYtb25seSAtPiBtaXhlZCA9IG9uZSBsZWFmIFBX DQo+ID4gPiBNaXhlZCAtPiByb290LW9ubHkgPSBvbmUgKHJvb3QrbGVhZikgUFcNCj4gPiA+ IE1peGVkIC0+IGxlYWYtb25seSA9IG9uZSAocm9vdCtsZWFmKSBQVw0KPiA+ID4NCj4gPiA+ IEkgaGF2ZSBhIGNvbmNlcm4gdGhhdCB0aGUgZm9yd2FyZGluZyBwbGFuZSBvZiBQRSB0byBp bXBsZW1lbnQgdGhpcw0KPiA+IHdpbGwNCj4gPiA+IGJlIHZlcnkgZGlmZmVyZW50IGZyb20g dGhlIHRyYWRpdGlvbmFsIFZQTFMuDQo+ID4gPg0KPiA+ID4gUmVnYXJkcywNCj4gPiA+IFl1 YW5sb25nDQo+ID4gPg0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ IEZyb206IERhbmllbCBDb2huIFttYWlsdG86RGFuaWVsQ0BvcmNraXQuY29tXQ0KPiA+ID4g U2VudDogTW9uZGF5LCBNYXkgMTQsIDIwMTIgNTowMCBQTQ0KPiA+ID4gVG86IEppYW5neXVh bmxvbmc7IEFsZXhhbmRlciBWYWluc2h0ZWluOyBTYW0gQ2FvDQo+ID4gPiBDYzogbDJ2cG5A aWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IFJFOiBEaXNjdXNzaW9uIG9uIEUtVHJlZSBhbmQg SC1WUExTDQo+ID4gPg0KPiA+ID4gSGkgWXVhbmxvbmcsDQo+ID4gPg0KPiA+ID4gTGlrZSBJ IHdyb3RlIGJlbG93LCByb290L2xlYWYgc3Bva2UgUFcgYmVoYXZlIGxpa2Ugcm9vdC9sZWFm IEFDLCBub3QNCj4gPiA+IGxpa2Ugcm9vdC9zcG9rZSAiY29yZSBQVyIuIFNvIG5vIGNoYW5n ZXMgdG8gZm9yd2FyZGluZyBwbGFuZSBvbmNlIHRoaXMNCj4gPiA+IGlzIHVuZGVyc3Rvb2Qu DQo+ID4gPg0KPiA+ID4gREMNCj4gPiA+DQo+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiA+ID4gRnJvbTogSmlhbmd5dWFubG9uZyBbbWFpbHRvOmppYW5neXVhbmxvbmdA aHVhd2VpLmNvbV0NCj4gPiA+IFNlbnQ6IE1vbmRheSwgTWF5IDE0LCAyMDEyIDExOjM2IEFN DQo+ID4gPiBUbzogRGFuaWVsIENvaG47IEFsZXhhbmRlciBWYWluc2h0ZWluOyBTYW0gQ2Fv DQo+ID4gPiBDYzogbDJ2cG5AaWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IFJFOiBEaXNjdXNz aW9uIG9uIEUtVHJlZSBhbmQgSC1WUExTDQo+ID4gPg0KPiA+ID4gRGFuaWVsLCBwbGVhc2Ug c2VlIG15IGNvbW1lbnRzIGluIGxpbmUuDQo+ID4gPg0KPiA+ID4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IERhbmllbCBDb2huIFttYWlsdG86RGFuaWVsQ0Bv cmNraXQuY29tXQ0KPiA+ID4gU2VudDogTW9uZGF5LCBNYXkgMTQsIDIwMTIgMzozNyBQTQ0K PiA+ID4gVG86IEppYW5neXVhbmxvbmc7IEFsZXhhbmRlciBWYWluc2h0ZWluOyBTYW0gQ2Fv DQo+ID4gPiBDYzogbDJ2cG5AaWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IFJFOiBEaXNjdXNz aW9uIG9uIEUtVHJlZSBhbmQgSC1WUExTDQo+ID4gPg0KPiA+ID4gSGkgWXVhbmxvbmcsDQo+ ID4gPg0KPiA+ID4gQXMgSSBzZWUgaXQsIGZvciB0aGUgUEUtciBzcG9rZSAoZmlndXJlIDQg aW4gUkZDIDQ3NjIpIHdlIGVzdGFibGlzaCBhDQo+ID4gPiBzaW5nbGUgUFcgcGVyIEFDIC0g cm9vdCBQVyBmb3Igcm9vdCBBQyBhbmQgbGVhZiBQVyBmb3IgbGVhZiBBQy4gV2l0aA0KPiA+ ID4gbG9jYWwgY29uZmlndXJhdGlvbiBhdCB0aGUgUEUtcnMgYXMgcGFydCBvZiB0aGUgc3Bv a2UgUFcgcHJvdmlzaW9uaW5nLg0KPiA+ID4gQW5kIHRoZSBQRS1ycyB3aWxsIHRyZWF0IHJv b3QvbGVhZiBzcG9rZSBQV3MgZXhhY3RseSBhcyBpdCB0cmVhdA0KPiA+ID4gcm9vdC9sZWFm IEFDcy4gU28gd2hlbiBsZWFmLW9yaWdpbmF0ZWQgQlVNIHRyYWZmaWMgYXJyaXZlcyBmcm9t IHRoZQ0KPiA+ID4gY29yZSAob3ZlciBhIGxlYWYgUFcpLCBpdCB3aWxsIGJlIGZvcndhcmRl ZCBvdmVyIGFsbCByb290IHNwb2tlIFBXcw0KPiA+IGJ1dA0KPiA+ID4gbm90IG9uIHRoZSBs ZWFmIHNwb2tlIFBXcy4NCj4gPiA+DQo+ID4gPiBbSlldIFNvIGluIHRoZSByZXZlcnNlIGRp cmVjdGlvbiwgeW91IG5lZWQgdG8gdHJhbnNwb3J0IGJvdGggcm9vdCBhbmQNCj4gPiA+IGxl YWYgdHJhZmZpYyBmcm9tIFBFLXJzIG92ZXIgYSByb290IFBXIHRvIFBFLXIsIGFuZCB0cmFu c3BvcnQgcm9vdA0KPiA+ID4gdHJhZmZpYyBvdmVyIGEgbGVhZiBQVy4gSXQgc2VlbXMgYWdh aW5zdCB0aGUgZGVmaW5pdGlvbiBvZiByb290IFBXIGFuZA0KPiA+ID4gbGVhZiBQVyBpbiB0 aGUgbXVsdGktUFcgZHJhZnQuIERvbid0IHRoaXMgbWFrZSB0aGUgZm9yd2FyZGluZyBwbGFu ZSBvZg0KPiA+ID4gUEUtcnMgbW9yZSBjb21wbGV4Pw0KPiA+ID4NCj4gPiA+IFRoZSBmb3J3 YXJkaW5nIHBsYW5lIGlzIGV4YWN0bHkgdGhlIHNhbWUgYXMgZGVzY3JpYmVkIGluIHRoZSBt dWx0aS1QVw0KPiA+ID4gZHJhZnQsIHdoZXJlIHNwb2tlIFBXcyBhcmUgdHJlYXRlZCBleGFj dGx5IGxpa2UgQUNzLg0KPiA+ID4NCj4gPiA+IFJlZ2FyZHMsDQo+ID4gPg0KPiA+ID4gRGFu aWVsDQo+ID4gPg0KPiA+ID4NCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ ID4gPiBGcm9tOiBKaWFuZ3l1YW5sb25nIFttYWlsdG86amlhbmd5dWFubG9uZ0BodWF3ZWku Y29tXQ0KPiA+ID4gU2VudDogRnJpZGF5LCBNYXkgMTEsIDIwMTIgNTowMyBBTQ0KPiA+ID4g VG86IERhbmllbCBDb2huOyBBbGV4YW5kZXIgVmFpbnNodGVpbjsgU2FtIENhbw0KPiA+ID4g Q2M6IGwydnBuQGlldGYub3JnDQo+ID4gPiBTdWJqZWN0OiBSRTogRGlzY3Vzc2lvbiBvbiBF LVRyZWUgYW5kIEgtVlBMUw0KPiA+ID4NCj4gPiA+IEhpIERhbmllbCBhbmQgYWxsLA0KPiA+ ID4NCj4gPiA+IFdoZW4geW91IHNldCB1cCB0d28gUFdzIGZyb20gdGhlIFBFLXJzIHRvIGEg UEUtciBmb3IgZWFjaCBvZiBpdHMgQUMsDQo+ID4gZG8NCj4gPiA+IHlvdSBtZWFuIHRoYXQg b25lIFBXIGlzIGJpZGlyZWN0aW9uYWwgcm9vdCBQVyBhbmQgdGhlIG90aGVyIGlzDQo+ID4g PiBiaWRpcmVjdGlvbmFsIGxlYWYgUFc/DQo+ID4gPiBNeSBjb25jZXJuIGlzOiB3aGVyZSBz aG91bGQgdGhlIGxlYWYgdHJhZmZpYyBiZSBmaWx0ZXJlZCwgb24gdGhlIFBFLXJzDQo+ID4g PiBvciBvbiB0aGUgUEUtcj8NCj4gPiA+IElmIGZpbHRlcmVkIG9uIHRoZSBQRS1yLCB0aGVu IGxvdHMgb2YgYmFuZHdpZHRoIHdpbGwgYmUgd2FzdGVkIChmb3INCj4gPiA+IGV4YW1wbGUs IGlmIHRoZSBQRS1yIGlzIGF0dGFjaGVkIHdpdGggOSBsZWFmcywgdGhlbiB0aGUgQlVNIHRy YWZmaWMNCj4gPiA+IGZyb20gb25lIG9mIGl0cyBsZWFmcyB3aWxsIGJlIG11bHRpcGxpZWQg YnkgOCB0aW1lcywgYW5kIGJlIGZvcndhcmRlZA0KPiA+ID4gYnkgdGhlIFBFLXJzIHRvIHRo ZSBzYW1lIFBFLXIpLg0KPiA+ID4gSWYgZmlsdGVyZWQgb24gdGhlIFBFLXJzLCBub3Qgc3Vy ZSBob3cgeW91IHdpbGwgZGVzaWduIGl0cyBmb3J3YXJkaW5nDQo+ID4gPiBwbGFuZSwgY2Fu IHlvdSBnaXZlIGEgaGludD8NCj4gPiA+DQo+ID4gPiBUaGFua3MsDQo+ID4gPiBZdWFubG9u Zw0KPiA+ID4NCj4gPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ID4g RGF0ZTogV2VkLCA5IE1heSAyMDEyIDA5OjE2OjM2ICswMzAwDQo+ID4gPiBGcm9tOiAiRGFu aWVsIENvaG4iIDxEYW5pZWxDQG9yY2tpdC5jb20+DQo+ID4gPiBUbzogIkFsZXhhbmRlciBW YWluc2h0ZWluIiA8QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+LA0KPiA+ICJT YW0NCj4gPiA+ICAgICAgIENhbyIgPHl1cXVuLmNhb0BnbWFpbC5jb20+LCA8bDJ2cG5AaWV0 Zi5vcmc+DQo+ID4gPiBDYzogbGl6aG9uZy5qaW5AenRlLmNvbS5jbg0KPiA+ID4gU3ViamVj dDogUkU6IERpc2N1c3Npb24gb24gRS1UcmVlIGFuZCBILVZQTFMNCj4gPiA+IE1lc3NhZ2Ut SUQ6DQo+IDw0NEY0RTU3OUE3NjQ1ODRFQTlCREZEMDdEMENBMDgxMzA3ODBDQkE2QHRsdm1h aWwxPg0KPiA+ID4gQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyAgICAgY2hhcnNldD0iSVNP LTIwMjItSlAiDQo+ID4gPg0KPiA+ID4gSGkgU2FzaGEsDQo+ID4gPg0KPiA+ID4gSXQncyBh Y3R1YWxseSB2ZXJ5IHNpbXBsZS4gQSBmcmFtZSB0aGF0IG9yaWdpbmF0ZWQgaW4gYSByb290 IEFDIGlzDQo+ID4gPiBhbHdheXMgdHJhbnNtaXR0ZWQgb25seSBpbiByb290IFBXLCBubyBt YXR0ZXIgd2hhdCB0aGUgZnJhbWUgdHlwZQ0KPiA+ID4gKGtub3duL3Vua25vd24gdW5pY2Fz dCBvciBicm9hZGNhc3QpLiBUaGlzIGlzIGhvdyB0aGUgZnJhbWUgc291cmNlDQo+ID4gPiBp bmZvcm1hdGlvbiBpcyBwcm9wYWdhdGVkIGFjcm9zcyB0aGUgVlBMUy4gU28gaW4gdGhlIEgt VlBMUyBleGFtcGxlLA0KPiA+ID4gdGhlIFBFLXIgd2lsbCBuZXZlciBmb3J3YXJkIGEgZnJh bWUgcmVjZWl2ZWQgb3ZlciBhIHJvb3QgUFcgb24gYW55DQo+ID4gbGVhZg0KPiA+ID4gUFcs IG9ubHkgb24gcm9vdCBQV3MgKHRvd2FyZCB0aGUgY29yZSBvciB0b3dhcmQgb3RoZXIgc3Bv a2VzKS4NCj4gPiA+DQo+ID4gPiBIb3BlIHRoaXMgY2xhcmlmaWVzIGl0LCByZWdhcmRzLA0K PiA+ID4NCj4gPiA+IERhbmllbA0KPiA+ID4NCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+ID4gPiBGcm9tOiBsMnZwbi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bDJ2 cG4tYm91bmNlc0BpZXRmLm9yZ10gT24NCj4gQmVoYWxmDQo+ID4gPiBPZiBBbGV4YW5kZXIg VmFpbnNodGVpbg0KPiA+ID4gU2VudDogV2VkbmVzZGF5LCBNYXkgMDksIDIwMTIgNzo1OSBB TQ0KPiA+ID4gVG86IFNhbSBDYW87IGwydnBuQGlldGYub3JnDQo+ID4gPiBDYzogbGl6aG9u Zy5qaW5AenRlLmNvbS5jbg0KPiA+ID4gU3ViamVjdDogUkU6IERpc2N1c3Npb24gb24gRS1U cmVlIGFuZCBILVZQTFMNCj4gPiA+DQo+ID4gPiBTYW0sIExpemhvbmcgYW5kIGFsbCwNCj4g PiA+IFlvdSd2ZSB3cml0dGVuIHRoYXQgaW4gdGhlIHR3by1QVyBzb2x1dGlvbiBjb21iaW5l ZCB3aXRoIEgtVlBMUyB0aGUNCj4gPiBQRS0NCj4gPiA+IHIgbXVzdCBzZXQgdXAgdHdvIFBX cyB3aXRoIGVhY2ggTVRVLXMuDQo+ID4gPg0KPiA+ID4gSWYgdGhpcyBpcyB0aGUgY2FzZSwg d2hhdCBraW5kIG9mIGZvcndhcmRpbmcgbG9naWMgc2hvdWxkIGJlIHVzZWQgdG8NCj4gPiA+ IHByZXZlbnQgc2VuZGluZyBhIEJVTSBmcmFtZSByZWNlaXZlZCBmcm9tIGEgcm9vdC1QVyB0 byBhIGdpdmVuIE1UVS1TOg0KPiA+ID4gLSBiYWNrIHRvIHRoZSBzYW1lIE1UVS1TIG9uIHRo ZSBjb3JyZXNwb25kaW5nIGxlYWYtUFc/DQo+ID4gPiAtIHR3aWNlICh0byBib3RoIHJvb3Qt UFcgYW5kIExlYWYtUFcpIHRvIGFub3RoZXIgTVRVLXM/IEFuZCwgQlRXLCBob3cNCj4gPiA+ IGlzIHRoZSBQVyBzZWxlY3RlZCBpbiB0aGlzIGNhc2U/DQo+ID4gPg0KPiA+ID4gSSBhbSBh d2FyZSBvZiBhIHRlY2huaXF1ZSBvZiBtdWx0aXBsZSBzcGxpdCBob3Jpem9uIGdyb3VwcyBp biBQRS1yDQo+ID4gPiB3aGljaCBjb3VsZCBiZSBwb3NzaWJseSB1c2VkIGZvciB0aGlzIHB1 cnBvc2UuIEhvd2V2ZXIsIHNpbmNlIHRoZXNlDQo+ID4gPiBncm91cHMgaGF2ZSB0byBiZSBy ZXByZXNlbnRlZCBleHBsaWNpdGx5IGluIHRoZSBkYXRhIHBsYW5lLCB0aGVpcg0KPiA+ID4g cG90ZW50aWFsIG51bWJlciBpcyBsaW1pdGVkIGJ5IHRoZSBmb3J3YXJkaW5nIEhXLiBPdGhl ciBtZXRob2RzIGNvdWxkDQo+ID4gPiBiZSBwcm9iYWJseSB1c2VkIGZvciB0aGUgc2FtZSBw dXJwb3NlLCBidXQgdGhleSB3b3VsZCBwcm9iYWJseSBzdWJqZWN0DQo+ID4gPiB0byBzaW1p bGFyIEhXLWJhc2VkIGxpbWl0YXRpb25zLg0KPiA+ID4NCj4gPiA+IEkgc3VzcGVjdCB0aGF0 IHdpdGggdGhlIGR1YWwtUFcgYXBwcm9hY2gsIHRoZSBIVyB3b3VsZCBwb3NlIGFuDQo+ID4g aW1wbGljaXQNCj4gPiA+IGxpbWl0LCBzYXksIG9uIGEgbnVtYmVyIG9mIE1UVS1zIHRoYXQg Y2FuIGJlIGNvbm5lY3RlZCB0byB0aGUgc2FtZQ0KPiA+IFBFLXINCj4gPiA+IGFuZCB0aGF0 IHRoaXMgbGltaXQgY291bGQgYmUgcXVpdGUgbG93IGluIG1vc3QgY2FzZXMuDQo+ID4gPg0K PiA+ID4gQmFzZWQgb24gdGhpcyBJIHN1c3BlY3QgdGhhdCB0aGUgSC1WUExTIGlzc3VlIGFz IGEgY3JpdGljYWwgZHJhd2JhY2sNCj4gPiBvZg0KPiA+ID4gdGhlIGR1YWwtUFcgYXBwcm9h Y2ggdG8gRS1UcmVlLg0KPiA+ID4NCj4gPiA+IE15IDJjLA0KPiA+ID4gICAgICBTYXNoYQ0K PiA+ID4NCj4gPiA+DQo+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+ID4gPiBGcm9tOiBsMnZwbi1ib3VuY2VzQGlldGYub3JnIFtsMnZwbi1ib3Vu Y2VzQGlldGYub3JnXSBvbiBiZWhhbGYgb2YNCj4gU2FtDQo+ID4gPiBDYW8gW3l1cXVuLmNh b0BnbWFpbC5jb21dDQo+ID4gPiBTZW50OiBXZWRuZXNkYXksIE1heSAwOSwgMjAxMiAzOjQw IEFNDQo+ID4gPiBUbzogbDJ2cG5AaWV0Zi5vcmcNCj4gPiA+IENjOiBsaXpob25nLmppbkB6 dGUuY29tLmNuDQo+ID4gPiBTdWJqZWN0OiBSRTogRGlzY3Vzc2lvbiBvbiBFLVRyZWUgYW5k IEgtVlBMUw0KPiA+ID4NCj4gPiA+IEhpIExpemhvbmc/DQo+ID4gPg0KPiA+ID4gVGhhbmsg eW91IHZlcnkgbXVjaCBmb3IgeW91ciBjb21tZW50cy4gSSB1cGRhdGVkIHRoZSByZXN1bHQg b24gdGhpcw0KPiA+ID4gcXVlc3Rpb24uDQo+ID4gPg0KPiA+ID4gW0xpemhvbmddIGFncmVl IHdpdGggdGhlIGFib3ZlIGFuYWx5c2lzLiBBbmQgd2UgZGlkIG5vdCBzYXkgaXQgaXMgYQ0K PiA+ID4gdGVjaG5pY2FsIHByb2JsZW0sIGJ1dCBpdCBpcyBhbiBvcGVyYXRpb25hbCBwcm9i bGVtIGFnYWluLg0KPiA+ID4gW1NhbV0gSSBhZ3JlZS4gRHVhbC1WTEFOIGRvZXMgbm90IG1h a2Ugc2Vuc2UuIEkgYWxzbyBkaXNjdXNzZWQgdGhpcw0KPiA+ID4gd2l0aCBHaWxlcyBhbmQg WXVhbmxvbmcgaW4gYW5vdGhlciBtYWlsLCBhbmQgd2UgcmVhY2hlZCBhZ3JlZW1lbnQgb24N Cj4gPiA+IHRoaXM6DQo+ID4gPiBNVFUgc2hvdWxkIGtub3cgdGhlIGFjY2VzcyBtb2RlLCBW UFdTIG9yIFZQTFMsIFZQV1MgbW9kZSBzaG91bGQNCj4gPiA+IGNvbmZpZ3VyZSBWTEFOIElE IG9uIE1UVSBidXQgVlBMUyBtb2RlIGNhbiBub3QuIEkgdGhvdWdodCB0aGlzIGlzIE5PVA0K PiA+ID4gcmVhc29uYWJsZSA6KSwgYnV0IHdlIGNhbiBmaWd1cmUgdGhpcyBvdXQgaW4gZHJh ZnQuIEl0IHNlZW1zIG9rLg0KPiA+ID4NCj4gPiA+IFtMaXpob25nXSBub3QgZnVsbHkgdW5k ZXJzdGFuZC4gRG8geW91IG1lYW4sICB3aGVuIFZQV1MgYWNjZXNzaW5nIGZvcg0KPiA+ID4g SC1WUExTLCB0aGUgUEUtciBpcyBhbHNvIG5lY2Vzc2FyeSB0byBjb25maWd1cmUgdHdvIFBX cyAocm9vdCBhbmQgbGVhZg0KPiA+ID4gUFcpIGZvciBlYWNoIEFDIGFjY2Vzcz8NCj4gPiA+ IFtTYW1dIFllcy4NCj4gPiA+DQo+ID4gPiBUaGFua3MsDQo+ID4gPg0KPiA+ID4gU2FtDQo+ ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiANCj4gDQo+IFRoaXMgZS1tYWlsIG1lc3Nh Z2UgaXMgaW50ZW5kZWQgZm9yIHRoZSByZWNpcGllbnQgb25seSBhbmQgY29udGFpbnMNCj4g aW5mb3JtYXRpb24gd2hpY2ggaXMgQ09ORklERU5USUFMIGFuZCB3aGljaCBtYXkgYmUgcHJv cHJpZXRhcnkgdG8gRUNJDQo+IFRlbGVjb20uIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg dHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW5mb3JtIHVzIGJ5DQo+IGUtbWFpbCwg cGhvbmUgb3IgZmF4LCBhbmQgdGhlbiBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbGwgY29w aWVzIHRoZXJlb2YuDQoNCg0KVGhpcyBlLW1haWwgbWVzc2FnZSBpcyBpbnRlbmRlZCBmb3Ig dGhlIHJlY2lwaWVudCBvbmx5IGFuZCBjb250YWlucyBpbmZvcm1hdGlvbiB3aGljaCBpcyBD T05GSURFTlRJQUwgYW5kIHdoaWNoIG1heSBiZSBwcm9wcmlldGFyeSB0byBFQ0kgVGVsZWNv bS4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBs ZWFzZSBpbmZvcm0gdXMgYnkgZS1tYWlsLCBwaG9uZSBvciBmYXgsIGFuZCB0aGVuIGRlbGV0 ZSB0aGUgb3JpZ2luYWwgYW5kIGFsbCBjb3BpZXMgdGhlcmVvZi4NCg0K From DanielC@orckit.com Wed May 16 01: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 EB1D721F8769 for ; Wed, 16 May 2012 01:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.181 X-Spam-Level: X-Spam-Status: No, score=-2.181 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, J_CHICKENPOX_23=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 W-WzumMWSeEK for ; Wed, 16 May 2012 01:46:44 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id D61C921F8768 for ; Wed, 16 May 2012 01:46:43 -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: Discussion on forwarding performance Date: Wed, 16 May 2012 11:49:29 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780D1FC@tlvmail1> In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413AA8@szxeml546-mbs.china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Discussion on forwarding performance Thread-Index: AQHNMp8ego9/CtMoakapN2JoMtGUPZbKvTGAgACuOgCAAIsAgIAAIx7w References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D411694@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF5C@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D4130E1@szxeml546-mbs.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF8F@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413216@szxeml546-mbs.china.huawei.com> <3F1F3739E2B04D399CC7D26CE934F91A@v2comsam> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413694@szxeml546-mbs.china.huawei.com> <7A564821DF1642E592E884D5C623772C@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D41370E@szxeml546-mbs.china.huawei.com> <400D5D93E6AA4075861CE09919D84747@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413741@szxeml546-mbs.china.huawei.com> <7BDA456234D045E1BD42EA059A4E9579@v2comsam> <2073A6C5467C99478898544C6EBA3F4602C1907568@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> <44F4E579A764584EA9BDFD07D0CA08130780D1AB@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413AA8@szxeml546-mbs.china.huawei.com> From: "Daniel Cohn" To: "Jiangyuanlong" , "Balus, Florin Stelian (Florin)" , "Sam Cao" , "Alexander Vainshtein" 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, 16 May 2012 08:46:46 -0000 VC ID is another name for PW label, right. ;-) >From conversations with chip vendors, I understood that when multiple lookups are required (as in the dual-VLAN example, you need to lookup PW label to identify E-Tree instance and then VLAN ID to identify root/leaf origin), typically a single lookup is performed on ingress with a composite search key (in this case, including PW label and VLAN ID).=20 / ;-) But perhaps we are getting too much into implementation here. It would be better if neutral NP and ASIC-based solution vendors could analyze both solutions and confirm impact on performance and scalability - and BTW, we also need input regarding existing silicon that doesn't support VLAN mapping. DC -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Wednesday, May 16, 2012 9:43 AM To: Daniel Cohn; Balus, Florin Stelian (Florin); Sam Cao; Alexander Vainshtein Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance Daniel,=20 Not sure I fully understand what you mean by "VLAN and VCID lookups are performed simultaneously on ingress", do you mean VLAN and PW? Can you give more details on this requirement? Regards, Yuanlong -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Wednesday, May 16, 2012 2:16 PM To: Balus, Florin Stelian (Florin); Sam Cao; Jiangyuanlong; Alexander Vainshtein Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance Hi, I agree that for a chip-based solution there should be no difference in performance for the additional lookup. However from conversations with chip vendors, I understood there might be an impact on scalability because the double lookup would require a longer search key (assuming VLAN and VCID lookups are performed simultaneously on ingress), thus taking up more TCAM resources per E-Tree instance. This would depend on specific TCAM implementation (e.g. granularity of search key length). DC -----Original Message----- From: Balus, Florin Stelian (Florin) [mailto:florin.balus@alcatel-lucent.com]=20 Sent: Tuesday, May 15, 2012 10:53 PM To: Sam Cao; 'Jiangyuanlong'; Daniel Cohn; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance Sam, > Obviously the forwarding performance of Dual-VLAN will be much lower than what of Multi-PW. Sorry I could not keep up with some of the threads on this subject but the above statement caught my eyes. We have been doing all kind of egress operations on VLANs in the egress PE for the last 8 years and I am not aware of any "much lower" forwarding performance. As far as I know the chipsets used in the PEs can do this processing no problem. Do you want to clarify which kind of hardware may have problems? > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Sam Cao > Sent: Tuesday, May 15, 2012 6:32 AM > To: 'Jiangyuanlong'; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on forwarding performance > > Hi Yuanlong, > > 3rd mapping will make data plane complex, I think. Anyway, we reached a > consensus on Multi-PW implementation. > > If we use 3rd mapping, I agree with your opinion, maybe dual-VLAN seems > simple, but 2 mapping is enough. Then we can focus on data plane > performance. While stripe PW label out on egress PE, data-plane knows > how to forward the frames from PW, to Root AC or Leaf AC or all. But if > we use Dual-VLAN, after strip PW label out, data plane should strip > VLAN-ID out and then does same forwarding work as Multi-PW does. The > most important is, do one more operation while forwarding E-Tree > frames. Obviously the forwarding performance of Dual-VLAN will be much > lower than what of Multi-PW. > > Regards, > > Yuqun (Sam) Cao > E-mail: Yuqun.cao@gmail.com > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 7:03 PM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > See my further comments in line. > > -----Original Message----- > From: Sam Cao [mailto:yuqun.cao@gmail.com] > Sent: Tuesday, May 15, 2012 6:14 PM > To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > Thank you very much for your comments. I draw the topology you gave, > and 7 PWs will be established if we follow 01. > > Root AC ---- PE 1 ----- PW 1 -------- PE 2 ----- Leaf _AC > | \ / || > | \ /=3D=3D=3DPW 6,7=3D=3D=3D || > PW 2 -----PW 5------\ || > | /----Root PW 3 --- \ || > Root _AC ---- PE 3 PE 4 ------ Root AC > | \ / | > | ----Leaf PW 4----- | > Leaf AC Leaf AC > Yes, on PE 3 there are several PWs, but if you want to clarify it, > there are only 3 types, one can carry frames originated from Root and > Leaf AC(one endpoint of this PW should be Root-only, otherwise this is > invalid), one only can carry frames from Root AC, and the last can > carry frames from Leaf ACs. On second thoughts, we still can classify > the PWs into 2 sets, one is Leaf set, and another is Root set, and the > union of the sets Leaf and Root is the PW we called it as compatible PW > (Maybe this is not correct, we can find one good term on this). > > So this optimization still follows the original design of Dual-PW > approach, Leaf PW only carries frames from Leaf AC; Root-PW only > carries frames from Root AC. Is it right? > > I don't know whether chip can support this forwarding behavior for > compatible PW or not, but if we implement it in NP, it is nearly same > as VPLS. The only difference is, setup 2 mappings, one between Leaf-ACs > and Leaf-PWs, one between Root-ACs and Root-PWs. For traditional VPLS, > there is only one mapping. > > [JY] It seems you may need a 3rd mapping: from both root & leaf AC to a > compatible PW. > BTW, for the forwarding and reverse direction, the mapping may be > asymmetric for you compatible PW. > > Based on my understanding, all drafts should have similar mapping. > > [JY] Dual-VLAN seems simpler here. > > Thanks, > > Sam > > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 3:32 PM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Sam, > > Thanks, please see my further comments with [JY]. > > Ok, we go on the case in your mail, where PE1 has one Root-only AC, > AC1, and > PE2 has one Leaf-only AC, AC2. In general we can setup 2 > "unidirectional" > PWs (bidirectional PW, but just carry unidirectional frames), Root-PW > which carries frames originated from AC1 and Leaf-PW which carries > frames originated from AC2. But only one PW also can work, just as some > members commented. Ok, we setup one PW between PE1 and PE2, we can call > this PW as compatible PW or something else. Frames originated from Root > or leaf ACs will be carried via this PW. Its forwarding behavior is > fully same as what traditional VPLS did, MAC learning on AC or PW in > one E-Tree. Or say, if one PE has Root-only ACs, it will setup one PW > with another PE, Root-only, Leaf-only or Root-Leaf-Mixed. If 2 PEs are > root-Leaf-Mixed or other cases, then 2 PWs will be established. As you > know, this can be done on control plane. > > [JY] Assume there are 2 other nodes PE3 & PE4 in this network scenario, > and both PE3 and PE4 have both root and leaf ACs, then there are > compatible PWs from PE3 which may carry both root and leaf traffic (to > PE1), which may carry only root traffic (to PE2); and further there are > root PW and leaf PW to PE4. Thus, the VSI on PE3 has at least 4 > different types of PW transmitting behaviours with regard to the E-Tree > traffic. In the reverse direction, the VSI on PE3 further has at least > 4 different types of PW receiving behaviours. Not sure how you will > accommodate for these PWs in both the data plane and control plane. > > Regards, > Yuanlong > > Is this clear for you? Is this necessary to optimize PW setup in this > case? > > Maybe we need to add one paragraph on forwarding behavior. > > Again thank you very much for your comments, > > Sam > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 10:27 AM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Please see my comments in line. > > -----Original Message----- > From: Sam Cao [mailto:yuqun.cao@gmail.com] > Sent: Monday, May 14, 2012 8:31 PM > To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > We have discussed this in another thread. In fact, Daniel or I have > given the answers to the questions you raised here for several time :). > If we do in this way, we will reach deadlock and can not move forward > :). I try to explain it again. > > [JY] I will apologize if you had ever provided such answers before, and > you may just refer to the links rather than repeat the explanation. > As you can see, I just try to understand the mechanism of 2PW and its > implications, but the I-D does not include enough information. > > As you know, initial design we will setup 2 PWs all the time (if do in > this way, I think that you have no question), > > [JY] I will be concerned with the operational complexity of this > approach. > > but in most cases 2 PWs are not > necessary. So in 01 version, we optimize it. > > "Root-only VSI <-> any VSI: only root PW required" > "Leaf-only VSI <-> leaf-only VSI: no PWs required" > > In other cases 2 PWs are needed. If so, "Leaf-only -> root-only =3D = one > leaf PW" is not correct: On Leaf-only side, yes, one Leaf-only PW is > created between Local Leaf type with remote Root type; on root-only > side, one root-only PW is created. Maybe it is better to call this as > compatible or mixed PW. So the left items you list are not correct for > multi_PW solution. > > [JY] This is something new, right? To be honest, I could not understand > what is your point: doesn't the mixed PW as you called also consist of > one Leaf-only PW in one direction and one root-only PW in the other > direction? > Furthermore, the case you took is also one case in your guideline > "Root-only VSI <-> any VSI: only root PW required", don't you think > that only one root PW is required following this guideline? > Actually, I don't care much about what is the bidirectional PW or > unidirectional PW called, but how can a VSI support such a mixed > scenarios: > traditional VSI assumes only one PW is required for each peer VSI, and > its MAC leaning is based on bidirectional PW. But for 2PW, there are > bidirectional root PW, bidirectional leaf PW, mixed PW, etc..., how to > support these kinds of PWs in the same VSI is my top concern. > > BTW, I guess you also care this case we also have discussed before: for > example, if we configure one Leaf AC on root-only PE (then it will be > root-leaf-mixed PE), we will teardown the compatible PW and re-setup > PWs again with 01. > [JY] This was discussed in the emails indeed. > > Regards, > > Yuqun (Sam) Cao > E-mail: Yuqun.cao@gmail.com > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Monday, May 14, 2012 7:10 PM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Daniel, > > Fine, now it seems more in line with what we had proposed in 2VLAN: a > spoke PW behaves like root/leaf AC for a PE-r. > > But the same problem may also apply to the root/spoke "core PW" for > Multi-PW: > According to Multi-PW, only one PW is required between two PEs except > when both PEs are mixed with root and leaf, so these PWs may be formed > by combinations of the following unidirectional PW cases (extracted and > adapted from Josh's email): > Root-only -> any VSI =3D one root PW > Leaf-only -> root-only =3D one leaf PW > Leaf-only -> mixed =3D one leaf PW > Mixed -> root-only =3D one (root+leaf) PW > Mixed -> leaf-only =3D one (root+leaf) PW > > I have a concern that the forwarding plane of PE to implement this will > be very different from the traditional VPLS. > > Regards, > Yuanlong > > -----Original Message----- > From: Daniel Cohn [mailto:DanielC@orckit.com] > Sent: Monday, May 14, 2012 5:00 PM > To: Jiangyuanlong; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > Like I wrote below, root/leaf spoke PW behave like root/leaf AC, not > like root/spoke "core PW". So no changes to forwarding plane once this > is understood. > > DC > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Monday, May 14, 2012 11:36 AM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Daniel, please see my comments in line. > > -----Original Message----- > From: Daniel Cohn [mailto:DanielC@orckit.com] > Sent: Monday, May 14, 2012 3:37 PM > To: Jiangyuanlong; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > As I see it, for the PE-r spoke (figure 4 in RFC 4762) we establish a > single PW per AC - root PW for root AC and leaf PW for leaf AC. With > local configuration at the PE-rs as part of the spoke PW provisioning. > And the PE-rs will treat root/leaf spoke PWs exactly as it treat > root/leaf ACs. So when leaf-originated BUM traffic arrives from the > core (over a leaf PW), it will be forwarded over all root spoke PWs but > not on the leaf spoke PWs. > > [JY] So in the reverse direction, you need to transport both root and > leaf traffic from PE-rs over a root PW to PE-r, and transport root > traffic over a leaf PW. It seems against the definition of root PW and > leaf PW in the multi-PW draft. Don't this make the forwarding plane of > PE-rs more complex? > > The forwarding plane is exactly the same as described in the multi-PW > draft, where spoke PWs are treated exactly like ACs. > > Regards, > > Daniel > > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Friday, May 11, 2012 5:03 AM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Daniel and all, > > When you set up two PWs from the PE-rs to a PE-r for each of its AC, do > you mean that one PW is bidirectional root PW and the other is > bidirectional leaf PW? > My concern is: where should the leaf traffic be filtered, on the PE-rs > or on the PE-r? > If filtered on the PE-r, then lots of bandwidth will be wasted (for > example, if the PE-r is attached with 9 leafs, then the BUM traffic > from one of its leafs will be multiplied by 8 times, and be forwarded > by the PE-rs to the same PE-r). > If filtered on the PE-rs, not sure how you will design its forwarding > plane, can you give a hint? > > Thanks, > Yuanlong > > ------------------------------ > Date: Wed, 9 May 2012 09:16:36 +0300 > From: "Daniel Cohn" > To: "Alexander Vainshtein" , "Sam > Cao" , > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780CBA6@tlvmail1> > Content-Type: text/plain; charset=3D"ISO-2022-JP" > > Hi Sasha, > > It's actually very simple. A frame that originated in a root AC is > always transmitted only in root PW, no matter what the frame type > (known/unknown unicast or broadcast). This is how the frame source > information is propagated across the VPLS. So in the H-VPLS example, > the PE-r will never forward a frame received over a root PW on any leaf > PW, only on root PWs (toward the core or toward other spokes). > > Hope this clarifies it, regards, > > Daniel > > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Alexander Vainshtein > Sent: Wednesday, May 09, 2012 7:59 AM > To: Sam Cao; l2vpn@ietf.org > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > > Sam, Lizhong and all, > You've written that in the two-PW solution combined with H-VPLS the PE- > r must set up two PWs with each MTU-s. > > If this is the case, what kind of forwarding logic should be used to > prevent sending a BUM frame received from a root-PW to a given MTU-S: > - back to the same MTU-S on the corresponding leaf-PW? > - twice (to both root-PW and Leaf-PW) to another MTU-s? And, BTW, how > is the PW selected in this case? > > I am aware of a technique of multiple split horizon groups in PE-r > which could be possibly used for this purpose. However, since these > groups have to be represented explicitly in the data plane, their > potential number is limited by the forwarding HW. Other methods could > be probably used for the same purpose, but they would probably subject > to similar HW-based limitations. > > I suspect that with the dual-PW approach, the HW would pose an implicit > limit, say, on a number of MTU-s that can be connected to the same PE-r > and that this limit could be quite low in most cases. > > Based on this I suspect that the H-VPLS issue as a critical drawback of > the dual-PW approach to E-Tree. > > My 2c, > Sasha > > > ________________________________________ > From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Sam > Cao [yuqun.cao@gmail.com] > Sent: Wednesday, May 09, 2012 3:40 AM > To: l2vpn@ietf.org > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Lizhong? > > Thank you very much for your comments. I updated the result on this > question. > > [Lizhong] agree with the above analysis. And we did not say it is a > technical problem, but it is an operational problem again. > [Sam] I agree. Dual-VLAN does not make sense. I also discussed this > with Giles and Yuanlong in another mail, and we reached agreement on > this: > MTU should know the access mode, VPWS or VPLS, VPWS mode should > configure VLAN ID on MTU but VPLS mode can not. I thought this is NOT > reasonable :), but we can figure this out in draft. It seems ok. > > [Lizhong] not fully understand. Do you mean, when VPWS accessing for > H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf > PW) for each AC access? > [Sam] Yes. > > Thanks, > > Sam > > > > From jiangyuanlong@huawei.com Wed May 16 03:06: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 49A4A21F85C5 for ; Wed, 16 May 2012 03:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.28 X-Spam-Level: X-Spam-Status: No, score=-4.28 tagged_above=-999 required=5 tests=[AWL=1.719, BAYES_00=-2.599, J_CHICKENPOX_23=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 DXtzZuGdg0Sy for ; Wed, 16 May 2012 03:06:31 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4A98321F85C3 for ; Wed, 16 May 2012 03:06:29 -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 AFY92002; Wed, 16 May 2012 06:06:29 -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; Wed, 16 May 2012 03:04:26 -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; Wed, 16 May 2012 03:04:24 -0700 Received: from SZXEML546-MBS.china.huawei.com ([169.254.4.75]) by szxeml411-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Wed, 16 May 2012 18:04:17 +0800 From: Jiangyuanlong To: Daniel Cohn , "Balus, Florin Stelian (Florin)" , Sam Cao , Alexander Vainshtein Subject: RE: Discussion on forwarding performance Thread-Topic: Discussion on forwarding performance Thread-Index: AQHNMp8ego9/CtMoakapN2JoMtGUPZbKvTGAgACuOgCAAIsAgIAAIx7wgAAPG/A= Date: Wed, 16 May 2012 10:04:15 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413B06@szxeml546-mbs.china.huawei.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D411694@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF5C@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D4130E1@szxeml546-mbs.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF8F@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413216@szxeml546-mbs.china.huawei.com> <3F1F3739E2B04D399CC7D26CE934F91A@v2comsam> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413694@szxeml546-mbs.china.huawei.com> <7A564821DF1642E592E884D5C623772C@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D41370E@szxeml546-mbs.china.huawei.com> <400D5D93E6AA4075861CE09919D84747@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413741@szxeml546-mbs.china.huawei.com> <7BDA456234D045E1BD42EA059A4E9579@v2comsam> <2073A6C5467C99478898544C6EBA3F4602C1907568@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> <44F4E579A764584EA9BDFD07D0CA08130780D1AB@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413AA8@szxeml546-mbs.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780D1FC@tlvmail1> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA08130780D1FC@tlvmail1> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.40.73] 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, 16 May 2012 10:06:33 -0000 Daniel, I don't think we need to look up the VLAN and PW at the same time for Dual-= VLAN: On the ingress PE, VLAN is firstly appended or translated for a incoming Et= hernet frame from AC, then MAC forwarded in VSI to one or multiple logical = ports each corresponding to a PW (the VLAN mapping may be processed on a lo= gical port), finally a PW label is appended and transported over the corres= ponding PW. On the egress PE, PW is popped and used to indicate a VSI (also correspondi= ng to a logical port, where the VLAN mapping may also be processed), then M= AC forwarded in VSI to one or multiple ports each corresponding to an AC (w= here a frame with a leaf VLAN will be dropped upon a leaf AC, actually, it = is also a simple VLAN translation in IEEE, that is, from leaf VLAN to 0xFFF= , and all frames with this VLAN will be dropped). Therefore, double lookup of VLAN and PW seems unnecessary or even impossibl= e for this service IMHO.=20 Regards, Yuanlong -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Wednesday, May 16, 2012 4:49 PM To: Jiangyuanlong; Balus, Florin Stelian (Florin); Sam Cao; Alexander Vains= htein Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance VC ID is another name for PW label, right. ;-) >From conversations with chip vendors, I understood that when multiple lookups are required (as in the dual-VLAN example, you need to lookup PW label to identify E-Tree instance and then VLAN ID to identify root/leaf origin), typically a single lookup is performed on ingress with a composite search key (in this case, including PW label and VLAN ID).=20 / ;-) But perhaps we are getting too much into implementation here. It would be better if neutral NP and ASIC-based solution vendors could analyze both solutions and confirm impact on performance and scalability - and BTW, we also need input regarding existing silicon that doesn't support VLAN mapping. DC -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Wednesday, May 16, 2012 9:43 AM To: Daniel Cohn; Balus, Florin Stelian (Florin); Sam Cao; Alexander Vainshtein Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance Daniel,=20 Not sure I fully understand what you mean by "VLAN and VCID lookups are performed simultaneously on ingress", do you mean VLAN and PW? Can you give more details on this requirement? Regards, Yuanlong -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Wednesday, May 16, 2012 2:16 PM To: Balus, Florin Stelian (Florin); Sam Cao; Jiangyuanlong; Alexander Vainshtein Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance Hi, I agree that for a chip-based solution there should be no difference in performance for the additional lookup. However from conversations with chip vendors, I understood there might be an impact on scalability because the double lookup would require a longer search key (assuming VLAN and VCID lookups are performed simultaneously on ingress), thus taking up more TCAM resources per E-Tree instance. This would depend on specific TCAM implementation (e.g. granularity of search key length). DC -----Original Message----- From: Balus, Florin Stelian (Florin) [mailto:florin.balus@alcatel-lucent.com]=20 Sent: Tuesday, May 15, 2012 10:53 PM To: Sam Cao; 'Jiangyuanlong'; Daniel Cohn; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance Sam, > Obviously the forwarding performance of Dual-VLAN will be much lower than what of Multi-PW. Sorry I could not keep up with some of the threads on this subject but the above statement caught my eyes. We have been doing all kind of egress operations on VLANs in the egress PE for the last 8 years and I am not aware of any "much lower" forwarding performance. As far as I know the chipsets used in the PEs can do this processing no problem. Do you want to clarify which kind of hardware may have problems? > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Sam Cao > Sent: Tuesday, May 15, 2012 6:32 AM > To: 'Jiangyuanlong'; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on forwarding performance > > Hi Yuanlong, > > 3rd mapping will make data plane complex, I think. Anyway, we reached a > consensus on Multi-PW implementation. > > If we use 3rd mapping, I agree with your opinion, maybe dual-VLAN seems > simple, but 2 mapping is enough. Then we can focus on data plane > performance. While stripe PW label out on egress PE, data-plane knows > how to forward the frames from PW, to Root AC or Leaf AC or all. But if > we use Dual-VLAN, after strip PW label out, data plane should strip > VLAN-ID out and then does same forwarding work as Multi-PW does. The > most important is, do one more operation while forwarding E-Tree > frames. Obviously the forwarding performance of Dual-VLAN will be much > lower than what of Multi-PW. > > Regards, > > Yuqun (Sam) Cao > E-mail: Yuqun.cao@gmail.com > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 7:03 PM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > See my further comments in line. > > -----Original Message----- > From: Sam Cao [mailto:yuqun.cao@gmail.com] > Sent: Tuesday, May 15, 2012 6:14 PM > To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > Thank you very much for your comments. I draw the topology you gave, > and 7 PWs will be established if we follow 01. > > Root AC ---- PE 1 ----- PW 1 -------- PE 2 ----- Leaf _AC > | \ / || > | \ /=3D=3D=3DPW 6,7=3D=3D=3D || > PW 2 -----PW 5------\ || > | /----Root PW 3 --- \ || > Root _AC ---- PE 3 PE 4 ------ Root AC > | \ / | > | ----Leaf PW 4----- | > Leaf AC Leaf AC > Yes, on PE 3 there are several PWs, but if you want to clarify it, > there are only 3 types, one can carry frames originated from Root and > Leaf AC(one endpoint of this PW should be Root-only, otherwise this is > invalid), one only can carry frames from Root AC, and the last can > carry frames from Leaf ACs. On second thoughts, we still can classify > the PWs into 2 sets, one is Leaf set, and another is Root set, and the > union of the sets Leaf and Root is the PW we called it as compatible PW > (Maybe this is not correct, we can find one good term on this). > > So this optimization still follows the original design of Dual-PW > approach, Leaf PW only carries frames from Leaf AC; Root-PW only > carries frames from Root AC. Is it right? > > I don't know whether chip can support this forwarding behavior for > compatible PW or not, but if we implement it in NP, it is nearly same > as VPLS. The only difference is, setup 2 mappings, one between Leaf-ACs > and Leaf-PWs, one between Root-ACs and Root-PWs. For traditional VPLS, > there is only one mapping. > > [JY] It seems you may need a 3rd mapping: from both root & leaf AC to a > compatible PW. > BTW, for the forwarding and reverse direction, the mapping may be > asymmetric for you compatible PW. > > Based on my understanding, all drafts should have similar mapping. > > [JY] Dual-VLAN seems simpler here. > > Thanks, > > Sam > > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 3:32 PM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Sam, > > Thanks, please see my further comments with [JY]. > > Ok, we go on the case in your mail, where PE1 has one Root-only AC, > AC1, and > PE2 has one Leaf-only AC, AC2. In general we can setup 2 > "unidirectional" > PWs (bidirectional PW, but just carry unidirectional frames), Root-PW > which carries frames originated from AC1 and Leaf-PW which carries > frames originated from AC2. But only one PW also can work, just as some > members commented. Ok, we setup one PW between PE1 and PE2, we can call > this PW as compatible PW or something else. Frames originated from Root > or leaf ACs will be carried via this PW. Its forwarding behavior is > fully same as what traditional VPLS did, MAC learning on AC or PW in > one E-Tree. Or say, if one PE has Root-only ACs, it will setup one PW > with another PE, Root-only, Leaf-only or Root-Leaf-Mixed. If 2 PEs are > root-Leaf-Mixed or other cases, then 2 PWs will be established. As you > know, this can be done on control plane. > > [JY] Assume there are 2 other nodes PE3 & PE4 in this network scenario, > and both PE3 and PE4 have both root and leaf ACs, then there are > compatible PWs from PE3 which may carry both root and leaf traffic (to > PE1), which may carry only root traffic (to PE2); and further there are > root PW and leaf PW to PE4. Thus, the VSI on PE3 has at least 4 > different types of PW transmitting behaviours with regard to the E-Tree > traffic. In the reverse direction, the VSI on PE3 further has at least > 4 different types of PW receiving behaviours. Not sure how you will > accommodate for these PWs in both the data plane and control plane. > > Regards, > Yuanlong > > Is this clear for you? Is this necessary to optimize PW setup in this > case? > > Maybe we need to add one paragraph on forwarding behavior. > > Again thank you very much for your comments, > > Sam > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 10:27 AM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Please see my comments in line. > > -----Original Message----- > From: Sam Cao [mailto:yuqun.cao@gmail.com] > Sent: Monday, May 14, 2012 8:31 PM > To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > We have discussed this in another thread. In fact, Daniel or I have > given the answers to the questions you raised here for several time :). > If we do in this way, we will reach deadlock and can not move forward > :). I try to explain it again. > > [JY] I will apologize if you had ever provided such answers before, and > you may just refer to the links rather than repeat the explanation. > As you can see, I just try to understand the mechanism of 2PW and its > implications, but the I-D does not include enough information. > > As you know, initial design we will setup 2 PWs all the time (if do in > this way, I think that you have no question), > > [JY] I will be concerned with the operational complexity of this > approach. > > but in most cases 2 PWs are not > necessary. So in 01 version, we optimize it. > > "Root-only VSI <-> any VSI: only root PW required" > "Leaf-only VSI <-> leaf-only VSI: no PWs required" > > In other cases 2 PWs are needed. If so, "Leaf-only -> root-only =3D one > leaf PW" is not correct: On Leaf-only side, yes, one Leaf-only PW is > created between Local Leaf type with remote Root type; on root-only > side, one root-only PW is created. Maybe it is better to call this as > compatible or mixed PW. So the left items you list are not correct for > multi_PW solution. > > [JY] This is something new, right? To be honest, I could not understand > what is your point: doesn't the mixed PW as you called also consist of > one Leaf-only PW in one direction and one root-only PW in the other > direction? > Furthermore, the case you took is also one case in your guideline > "Root-only VSI <-> any VSI: only root PW required", don't you think > that only one root PW is required following this guideline? > Actually, I don't care much about what is the bidirectional PW or > unidirectional PW called, but how can a VSI support such a mixed > scenarios: > traditional VSI assumes only one PW is required for each peer VSI, and > its MAC leaning is based on bidirectional PW. But for 2PW, there are > bidirectional root PW, bidirectional leaf PW, mixed PW, etc..., how to > support these kinds of PWs in the same VSI is my top concern. > > BTW, I guess you also care this case we also have discussed before: for > example, if we configure one Leaf AC on root-only PE (then it will be > root-leaf-mixed PE), we will teardown the compatible PW and re-setup > PWs again with 01. > [JY] This was discussed in the emails indeed. > > Regards, > > Yuqun (Sam) Cao > E-mail: Yuqun.cao@gmail.com > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Monday, May 14, 2012 7:10 PM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Daniel, > > Fine, now it seems more in line with what we had proposed in 2VLAN: a > spoke PW behaves like root/leaf AC for a PE-r. > > But the same problem may also apply to the root/spoke "core PW" for > Multi-PW: > According to Multi-PW, only one PW is required between two PEs except > when both PEs are mixed with root and leaf, so these PWs may be formed > by combinations of the following unidirectional PW cases (extracted and > adapted from Josh's email): > Root-only -> any VSI =3D one root PW > Leaf-only -> root-only =3D one leaf PW > Leaf-only -> mixed =3D one leaf PW > Mixed -> root-only =3D one (root+leaf) PW > Mixed -> leaf-only =3D one (root+leaf) PW > > I have a concern that the forwarding plane of PE to implement this will > be very different from the traditional VPLS. > > Regards, > Yuanlong > > -----Original Message----- > From: Daniel Cohn [mailto:DanielC@orckit.com] > Sent: Monday, May 14, 2012 5:00 PM > To: Jiangyuanlong; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > Like I wrote below, root/leaf spoke PW behave like root/leaf AC, not > like root/spoke "core PW". So no changes to forwarding plane once this > is understood. > > DC > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Monday, May 14, 2012 11:36 AM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Daniel, please see my comments in line. > > -----Original Message----- > From: Daniel Cohn [mailto:DanielC@orckit.com] > Sent: Monday, May 14, 2012 3:37 PM > To: Jiangyuanlong; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > As I see it, for the PE-r spoke (figure 4 in RFC 4762) we establish a > single PW per AC - root PW for root AC and leaf PW for leaf AC. With > local configuration at the PE-rs as part of the spoke PW provisioning. > And the PE-rs will treat root/leaf spoke PWs exactly as it treat > root/leaf ACs. So when leaf-originated BUM traffic arrives from the > core (over a leaf PW), it will be forwarded over all root spoke PWs but > not on the leaf spoke PWs. > > [JY] So in the reverse direction, you need to transport both root and > leaf traffic from PE-rs over a root PW to PE-r, and transport root > traffic over a leaf PW. It seems against the definition of root PW and > leaf PW in the multi-PW draft. Don't this make the forwarding plane of > PE-rs more complex? > > The forwarding plane is exactly the same as described in the multi-PW > draft, where spoke PWs are treated exactly like ACs. > > Regards, > > Daniel > > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Friday, May 11, 2012 5:03 AM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Daniel and all, > > When you set up two PWs from the PE-rs to a PE-r for each of its AC, do > you mean that one PW is bidirectional root PW and the other is > bidirectional leaf PW? > My concern is: where should the leaf traffic be filtered, on the PE-rs > or on the PE-r? > If filtered on the PE-r, then lots of bandwidth will be wasted (for > example, if the PE-r is attached with 9 leafs, then the BUM traffic > from one of its leafs will be multiplied by 8 times, and be forwarded > by the PE-rs to the same PE-r). > If filtered on the PE-rs, not sure how you will design its forwarding > plane, can you give a hint? > > Thanks, > Yuanlong > > ------------------------------ > Date: Wed, 9 May 2012 09:16:36 +0300 > From: "Daniel Cohn" > To: "Alexander Vainshtein" , "Sam > Cao" , > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780CBA6@tlvmail1> > Content-Type: text/plain; charset=3D"ISO-2022-JP" > > Hi Sasha, > > It's actually very simple. A frame that originated in a root AC is > always transmitted only in root PW, no matter what the frame type > (known/unknown unicast or broadcast). This is how the frame source > information is propagated across the VPLS. So in the H-VPLS example, > the PE-r will never forward a frame received over a root PW on any leaf > PW, only on root PWs (toward the core or toward other spokes). > > Hope this clarifies it, regards, > > Daniel > > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Alexander Vainshtein > Sent: Wednesday, May 09, 2012 7:59 AM > To: Sam Cao; l2vpn@ietf.org > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > > Sam, Lizhong and all, > You've written that in the two-PW solution combined with H-VPLS the PE- > r must set up two PWs with each MTU-s. > > If this is the case, what kind of forwarding logic should be used to > prevent sending a BUM frame received from a root-PW to a given MTU-S: > - back to the same MTU-S on the corresponding leaf-PW? > - twice (to both root-PW and Leaf-PW) to another MTU-s? And, BTW, how > is the PW selected in this case? > > I am aware of a technique of multiple split horizon groups in PE-r > which could be possibly used for this purpose. However, since these > groups have to be represented explicitly in the data plane, their > potential number is limited by the forwarding HW. Other methods could > be probably used for the same purpose, but they would probably subject > to similar HW-based limitations. > > I suspect that with the dual-PW approach, the HW would pose an implicit > limit, say, on a number of MTU-s that can be connected to the same PE-r > and that this limit could be quite low in most cases. > > Based on this I suspect that the H-VPLS issue as a critical drawback of > the dual-PW approach to E-Tree. > > My 2c, > Sasha > > > ________________________________________ > From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Sam > Cao [yuqun.cao@gmail.com] > Sent: Wednesday, May 09, 2012 3:40 AM > To: l2vpn@ietf.org > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Lizhong? > > Thank you very much for your comments. I updated the result on this > question. > > [Lizhong] agree with the above analysis. And we did not say it is a > technical problem, but it is an operational problem again. > [Sam] I agree. Dual-VLAN does not make sense. I also discussed this > with Giles and Yuanlong in another mail, and we reached agreement on > this: > MTU should know the access mode, VPWS or VPLS, VPWS mode should > configure VLAN ID on MTU but VPLS mode can not. I thought this is NOT > reasonable :), but we can figure this out in draft. It seems ok. > > [Lizhong] not fully understand. Do you mean, when VPWS accessing for > H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf > PW) for each AC access? > [Sam] Yes. > > Thanks, > > Sam > > > > From DanielC@orckit.com Wed May 16 03:27: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 65A1321F86C7 for ; Wed, 16 May 2012 03:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.175 X-Spam-Level: X-Spam-Status: No, score=-2.175 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, J_CHICKENPOX_23=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 xai262-sfIBN for ; Wed, 16 May 2012 03:27:28 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id 2279421F8663 for ; Wed, 16 May 2012 03:27: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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Discussion on forwarding performance Date: Wed, 16 May 2012 13:30:14 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780D224@tlvmail1> In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413B06@szxeml546-mbs.china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Discussion on forwarding performance Thread-Index: AQHNMp8ego9/CtMoakapN2JoMtGUPZbKvTGAgACuOgCAAIsAgIAAIx7wgAAPG/CAAA8QAA== References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D411694@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF5C@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D4130E1@szxeml546-mbs.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF8F@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413216@szxeml546-mbs.china.huawei.com> <3F1F3739E2B04D399CC7D26CE934F91A@v2comsam> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413694@szxeml546-mbs.china.huawei.com> <7A564821DF1642E592E884D5C623772C@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D41370E@szxeml546-mbs.china.huawei.com> <400D5D93E6AA4075861CE09919D84747@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413741@szxeml546-mbs.china.huawei.com> <7BDA456234D045E1BD42EA059A4E9579@v2comsam> <2073A6C5467C99478898544C6EBA3F4602C1907568@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> <44F4E579A764584EA9BDFD07D0CA08130780D1AB@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413AA8@szxeml546-mbs.china.huawei.com> <44 F4E579A7 64584EA9BDFD 07D0CA08130780D1FC@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413B06@szxeml546-mbs.china.huawei.com> From: "Daniel Cohn" To: "Jiangyuanlong" , "Balus, Florin Stelian (Florin)" , "Sam Cao" , "Alexander Vainshtein" 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, 16 May 2012 10:27:30 -0000 Yuanlong, I was referring always to the egress PE. In my understanding (going deeper and deeper into implementation) an ASIC-based solution will typically perform PW and VLAN lookup on ingress and as a result of the lookup add internal tags to the frame representing VSI instance and root/leaf attribute. But now we're going too much into individual implementations so I repeat my comment from the previous e-mail - It would be better if neutral NP and ASIC-based solution vendors could analyze both solutions and confirm impact on performance and scalability - and BTW, we also need input regarding existing silicon that doesn't support VLAN mapping. DC -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Wednesday, May 16, 2012 1:04 PM To: Daniel Cohn; Balus, Florin Stelian (Florin); Sam Cao; Alexander Vainshtein Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance Daniel, I don't think we need to look up the VLAN and PW at the same time for Dual-VLAN: On the ingress PE, VLAN is firstly appended or translated for a incoming Ethernet frame from AC, then MAC forwarded in VSI to one or multiple logical ports each corresponding to a PW (the VLAN mapping may be processed on a logical port), finally a PW label is appended and transported over the corresponding PW. On the egress PE, PW is popped and used to indicate a VSI (also corresponding to a logical port, where the VLAN mapping may also be processed), then MAC forwarded in VSI to one or multiple ports each corresponding to an AC (where a frame with a leaf VLAN will be dropped upon a leaf AC, actually, it is also a simple VLAN translation in IEEE, that is, from leaf VLAN to 0xFFF, and all frames with this VLAN will be dropped). Therefore, double lookup of VLAN and PW seems unnecessary or even impossible for this service IMHO.=20 Regards, Yuanlong -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Wednesday, May 16, 2012 4:49 PM To: Jiangyuanlong; Balus, Florin Stelian (Florin); Sam Cao; Alexander Vainshtein Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance VC ID is another name for PW label, right. ;-) >From conversations with chip vendors, I understood that when multiple lookups are required (as in the dual-VLAN example, you need to lookup PW label to identify E-Tree instance and then VLAN ID to identify root/leaf origin), typically a single lookup is performed on ingress with a composite search key (in this case, including PW label and VLAN ID).=20 / ;-) But perhaps we are getting too much into implementation here. It would be better if neutral NP and ASIC-based solution vendors could analyze both solutions and confirm impact on performance and scalability - and BTW, we also need input regarding existing silicon that doesn't support VLAN mapping. DC -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Wednesday, May 16, 2012 9:43 AM To: Daniel Cohn; Balus, Florin Stelian (Florin); Sam Cao; Alexander Vainshtein Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance Daniel,=20 Not sure I fully understand what you mean by "VLAN and VCID lookups are performed simultaneously on ingress", do you mean VLAN and PW? Can you give more details on this requirement? Regards, Yuanlong -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Wednesday, May 16, 2012 2:16 PM To: Balus, Florin Stelian (Florin); Sam Cao; Jiangyuanlong; Alexander Vainshtein Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance Hi, I agree that for a chip-based solution there should be no difference in performance for the additional lookup. However from conversations with chip vendors, I understood there might be an impact on scalability because the double lookup would require a longer search key (assuming VLAN and VCID lookups are performed simultaneously on ingress), thus taking up more TCAM resources per E-Tree instance. This would depend on specific TCAM implementation (e.g. granularity of search key length). DC -----Original Message----- From: Balus, Florin Stelian (Florin) [mailto:florin.balus@alcatel-lucent.com]=20 Sent: Tuesday, May 15, 2012 10:53 PM To: Sam Cao; 'Jiangyuanlong'; Daniel Cohn; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance Sam, > Obviously the forwarding performance of Dual-VLAN will be much lower than what of Multi-PW. Sorry I could not keep up with some of the threads on this subject but the above statement caught my eyes. We have been doing all kind of egress operations on VLANs in the egress PE for the last 8 years and I am not aware of any "much lower" forwarding performance. As far as I know the chipsets used in the PEs can do this processing no problem. Do you want to clarify which kind of hardware may have problems? > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Sam Cao > Sent: Tuesday, May 15, 2012 6:32 AM > To: 'Jiangyuanlong'; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on forwarding performance > > Hi Yuanlong, > > 3rd mapping will make data plane complex, I think. Anyway, we reached a > consensus on Multi-PW implementation. > > If we use 3rd mapping, I agree with your opinion, maybe dual-VLAN seems > simple, but 2 mapping is enough. Then we can focus on data plane > performance. While stripe PW label out on egress PE, data-plane knows > how to forward the frames from PW, to Root AC or Leaf AC or all. But if > we use Dual-VLAN, after strip PW label out, data plane should strip > VLAN-ID out and then does same forwarding work as Multi-PW does. The > most important is, do one more operation while forwarding E-Tree > frames. Obviously the forwarding performance of Dual-VLAN will be much > lower than what of Multi-PW. > > Regards, > > Yuqun (Sam) Cao > E-mail: Yuqun.cao@gmail.com > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 7:03 PM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > See my further comments in line. > > -----Original Message----- > From: Sam Cao [mailto:yuqun.cao@gmail.com] > Sent: Tuesday, May 15, 2012 6:14 PM > To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > Thank you very much for your comments. I draw the topology you gave, > and 7 PWs will be established if we follow 01. > > Root AC ---- PE 1 ----- PW 1 -------- PE 2 ----- Leaf _AC > | \ / || > | \ /=3D=3D=3DPW 6,7=3D=3D=3D || > PW 2 -----PW 5------\ || > | /----Root PW 3 --- \ || > Root _AC ---- PE 3 PE 4 ------ Root AC > | \ / | > | ----Leaf PW 4----- | > Leaf AC Leaf AC > Yes, on PE 3 there are several PWs, but if you want to clarify it, > there are only 3 types, one can carry frames originated from Root and > Leaf AC(one endpoint of this PW should be Root-only, otherwise this is > invalid), one only can carry frames from Root AC, and the last can > carry frames from Leaf ACs. On second thoughts, we still can classify > the PWs into 2 sets, one is Leaf set, and another is Root set, and the > union of the sets Leaf and Root is the PW we called it as compatible PW > (Maybe this is not correct, we can find one good term on this). > > So this optimization still follows the original design of Dual-PW > approach, Leaf PW only carries frames from Leaf AC; Root-PW only > carries frames from Root AC. Is it right? > > I don't know whether chip can support this forwarding behavior for > compatible PW or not, but if we implement it in NP, it is nearly same > as VPLS. The only difference is, setup 2 mappings, one between Leaf-ACs > and Leaf-PWs, one between Root-ACs and Root-PWs. For traditional VPLS, > there is only one mapping. > > [JY] It seems you may need a 3rd mapping: from both root & leaf AC to a > compatible PW. > BTW, for the forwarding and reverse direction, the mapping may be > asymmetric for you compatible PW. > > Based on my understanding, all drafts should have similar mapping. > > [JY] Dual-VLAN seems simpler here. > > Thanks, > > Sam > > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 3:32 PM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Sam, > > Thanks, please see my further comments with [JY]. > > Ok, we go on the case in your mail, where PE1 has one Root-only AC, > AC1, and > PE2 has one Leaf-only AC, AC2. In general we can setup 2 > "unidirectional" > PWs (bidirectional PW, but just carry unidirectional frames), Root-PW > which carries frames originated from AC1 and Leaf-PW which carries > frames originated from AC2. But only one PW also can work, just as some > members commented. Ok, we setup one PW between PE1 and PE2, we can call > this PW as compatible PW or something else. Frames originated from Root > or leaf ACs will be carried via this PW. Its forwarding behavior is > fully same as what traditional VPLS did, MAC learning on AC or PW in > one E-Tree. Or say, if one PE has Root-only ACs, it will setup one PW > with another PE, Root-only, Leaf-only or Root-Leaf-Mixed. If 2 PEs are > root-Leaf-Mixed or other cases, then 2 PWs will be established. As you > know, this can be done on control plane. > > [JY] Assume there are 2 other nodes PE3 & PE4 in this network scenario, > and both PE3 and PE4 have both root and leaf ACs, then there are > compatible PWs from PE3 which may carry both root and leaf traffic (to > PE1), which may carry only root traffic (to PE2); and further there are > root PW and leaf PW to PE4. Thus, the VSI on PE3 has at least 4 > different types of PW transmitting behaviours with regard to the E-Tree > traffic. In the reverse direction, the VSI on PE3 further has at least > 4 different types of PW receiving behaviours. Not sure how you will > accommodate for these PWs in both the data plane and control plane. > > Regards, > Yuanlong > > Is this clear for you? Is this necessary to optimize PW setup in this > case? > > Maybe we need to add one paragraph on forwarding behavior. > > Again thank you very much for your comments, > > Sam > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 10:27 AM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Please see my comments in line. > > -----Original Message----- > From: Sam Cao [mailto:yuqun.cao@gmail.com] > Sent: Monday, May 14, 2012 8:31 PM > To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > We have discussed this in another thread. In fact, Daniel or I have > given the answers to the questions you raised here for several time :). > If we do in this way, we will reach deadlock and can not move forward > :). I try to explain it again. > > [JY] I will apologize if you had ever provided such answers before, and > you may just refer to the links rather than repeat the explanation. > As you can see, I just try to understand the mechanism of 2PW and its > implications, but the I-D does not include enough information. > > As you know, initial design we will setup 2 PWs all the time (if do in > this way, I think that you have no question), > > [JY] I will be concerned with the operational complexity of this > approach. > > but in most cases 2 PWs are not > necessary. So in 01 version, we optimize it. > > "Root-only VSI <-> any VSI: only root PW required" > "Leaf-only VSI <-> leaf-only VSI: no PWs required" > > In other cases 2 PWs are needed. If so, "Leaf-only -> root-only =3D = one > leaf PW" is not correct: On Leaf-only side, yes, one Leaf-only PW is > created between Local Leaf type with remote Root type; on root-only > side, one root-only PW is created. Maybe it is better to call this as > compatible or mixed PW. So the left items you list are not correct for > multi_PW solution. > > [JY] This is something new, right? To be honest, I could not understand > what is your point: doesn't the mixed PW as you called also consist of > one Leaf-only PW in one direction and one root-only PW in the other > direction? > Furthermore, the case you took is also one case in your guideline > "Root-only VSI <-> any VSI: only root PW required", don't you think > that only one root PW is required following this guideline? > Actually, I don't care much about what is the bidirectional PW or > unidirectional PW called, but how can a VSI support such a mixed > scenarios: > traditional VSI assumes only one PW is required for each peer VSI, and > its MAC leaning is based on bidirectional PW. But for 2PW, there are > bidirectional root PW, bidirectional leaf PW, mixed PW, etc..., how to > support these kinds of PWs in the same VSI is my top concern. > > BTW, I guess you also care this case we also have discussed before: for > example, if we configure one Leaf AC on root-only PE (then it will be > root-leaf-mixed PE), we will teardown the compatible PW and re-setup > PWs again with 01. > [JY] This was discussed in the emails indeed. > > Regards, > > Yuqun (Sam) Cao > E-mail: Yuqun.cao@gmail.com > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Monday, May 14, 2012 7:10 PM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Daniel, > > Fine, now it seems more in line with what we had proposed in 2VLAN: a > spoke PW behaves like root/leaf AC for a PE-r. > > But the same problem may also apply to the root/spoke "core PW" for > Multi-PW: > According to Multi-PW, only one PW is required between two PEs except > when both PEs are mixed with root and leaf, so these PWs may be formed > by combinations of the following unidirectional PW cases (extracted and > adapted from Josh's email): > Root-only -> any VSI =3D one root PW > Leaf-only -> root-only =3D one leaf PW > Leaf-only -> mixed =3D one leaf PW > Mixed -> root-only =3D one (root+leaf) PW > Mixed -> leaf-only =3D one (root+leaf) PW > > I have a concern that the forwarding plane of PE to implement this will > be very different from the traditional VPLS. > > Regards, > Yuanlong > > -----Original Message----- > From: Daniel Cohn [mailto:DanielC@orckit.com] > Sent: Monday, May 14, 2012 5:00 PM > To: Jiangyuanlong; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > Like I wrote below, root/leaf spoke PW behave like root/leaf AC, not > like root/spoke "core PW". So no changes to forwarding plane once this > is understood. > > DC > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Monday, May 14, 2012 11:36 AM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Daniel, please see my comments in line. > > -----Original Message----- > From: Daniel Cohn [mailto:DanielC@orckit.com] > Sent: Monday, May 14, 2012 3:37 PM > To: Jiangyuanlong; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > As I see it, for the PE-r spoke (figure 4 in RFC 4762) we establish a > single PW per AC - root PW for root AC and leaf PW for leaf AC. With > local configuration at the PE-rs as part of the spoke PW provisioning. > And the PE-rs will treat root/leaf spoke PWs exactly as it treat > root/leaf ACs. So when leaf-originated BUM traffic arrives from the > core (over a leaf PW), it will be forwarded over all root spoke PWs but > not on the leaf spoke PWs. > > [JY] So in the reverse direction, you need to transport both root and > leaf traffic from PE-rs over a root PW to PE-r, and transport root > traffic over a leaf PW. It seems against the definition of root PW and > leaf PW in the multi-PW draft. Don't this make the forwarding plane of > PE-rs more complex? > > The forwarding plane is exactly the same as described in the multi-PW > draft, where spoke PWs are treated exactly like ACs. > > Regards, > > Daniel > > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Friday, May 11, 2012 5:03 AM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Daniel and all, > > When you set up two PWs from the PE-rs to a PE-r for each of its AC, do > you mean that one PW is bidirectional root PW and the other is > bidirectional leaf PW? > My concern is: where should the leaf traffic be filtered, on the PE-rs > or on the PE-r? > If filtered on the PE-r, then lots of bandwidth will be wasted (for > example, if the PE-r is attached with 9 leafs, then the BUM traffic > from one of its leafs will be multiplied by 8 times, and be forwarded > by the PE-rs to the same PE-r). > If filtered on the PE-rs, not sure how you will design its forwarding > plane, can you give a hint? > > Thanks, > Yuanlong > > ------------------------------ > Date: Wed, 9 May 2012 09:16:36 +0300 > From: "Daniel Cohn" > To: "Alexander Vainshtein" , "Sam > Cao" , > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780CBA6@tlvmail1> > Content-Type: text/plain; charset=3D"ISO-2022-JP" > > Hi Sasha, > > It's actually very simple. A frame that originated in a root AC is > always transmitted only in root PW, no matter what the frame type > (known/unknown unicast or broadcast). This is how the frame source > information is propagated across the VPLS. So in the H-VPLS example, > the PE-r will never forward a frame received over a root PW on any leaf > PW, only on root PWs (toward the core or toward other spokes). > > Hope this clarifies it, regards, > > Daniel > > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Alexander Vainshtein > Sent: Wednesday, May 09, 2012 7:59 AM > To: Sam Cao; l2vpn@ietf.org > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > > Sam, Lizhong and all, > You've written that in the two-PW solution combined with H-VPLS the PE- > r must set up two PWs with each MTU-s. > > If this is the case, what kind of forwarding logic should be used to > prevent sending a BUM frame received from a root-PW to a given MTU-S: > - back to the same MTU-S on the corresponding leaf-PW? > - twice (to both root-PW and Leaf-PW) to another MTU-s? And, BTW, how > is the PW selected in this case? > > I am aware of a technique of multiple split horizon groups in PE-r > which could be possibly used for this purpose. However, since these > groups have to be represented explicitly in the data plane, their > potential number is limited by the forwarding HW. Other methods could > be probably used for the same purpose, but they would probably subject > to similar HW-based limitations. > > I suspect that with the dual-PW approach, the HW would pose an implicit > limit, say, on a number of MTU-s that can be connected to the same PE-r > and that this limit could be quite low in most cases. > > Based on this I suspect that the H-VPLS issue as a critical drawback of > the dual-PW approach to E-Tree. > > My 2c, > Sasha > > > ________________________________________ > From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Sam > Cao [yuqun.cao@gmail.com] > Sent: Wednesday, May 09, 2012 3:40 AM > To: l2vpn@ietf.org > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Lizhong? > > Thank you very much for your comments. I updated the result on this > question. > > [Lizhong] agree with the above analysis. And we did not say it is a > technical problem, but it is an operational problem again. > [Sam] I agree. Dual-VLAN does not make sense. I also discussed this > with Giles and Yuanlong in another mail, and we reached agreement on > this: > MTU should know the access mode, VPWS or VPLS, VPWS mode should > configure VLAN ID on MTU but VPLS mode can not. I thought this is NOT > reasonable :), but we can figure this out in draft. It seems ok. > > [Lizhong] not fully understand. Do you mean, when VPWS accessing for > H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf > PW) for each AC access? > [Sam] Yes. > > Thanks, > > Sam > > > > From david.i.allan@ericsson.com Wed May 16 09:21: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 152D821F86C7 for ; Wed, 16 May 2012 09:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.288 X-Spam-Level: X-Spam-Status: No, score=-6.288 tagged_above=-999 required=5 tests=[AWL=-0.289, BAYES_00=-2.599, J_CHICKENPOX_23=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 TOYwKm8y6b5v for ; Wed, 16 May 2012 09:21:52 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id BAA7421F8674 for ; Wed, 16 May 2012 09:21:50 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q4GGLM6T010398 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 May 2012 11:21:38 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.69]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 16 May 2012 12:21:36 -0400 From: David Allan I To: Sam Cao , "'Lucy yong'" , "'Balus, Florin Stelian (Florin)'" , "'Jiangyuanlong'" , "'Daniel Cohn'" , "'Alexander Vainshtein'" Date: Wed, 16 May 2012 12:20:36 -0400 Subject: RE: Discussion on forwarding performance Thread-Topic: Discussion on forwarding performance Thread-Index: AQHNLxo31u2OjZw96UuBF9QPOwJXg5bHcLkAgAGHLZCAAAmjYIAAHGPggAAUqSCAAOHDIIAAM7tggAAlyMCAADHVIIAAElJAgAAmSSCAAGzc8IAABagAgAAFRDCAAFXG8IAA+RMg Message-ID: <60C093A41B5E45409A19D42CF7786DFD5232948CBE@EUSAACMS0703.eamcs.ericsson.se> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D411694@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF5C@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D4130E1@szxeml546-mbs.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF8F@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413216@szxeml546-mbs.china.huawei.com> <3F1F3739E2B04D399CC7D26CE934F91A@v2comsam> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413694@szxeml546-mbs.china.huawei.com> <7A564821DF1642E592E884D5C623772C@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D41370E@szxeml546-mbs.china.huawei.com> <400D5D93E6AA4075861CE09919D84747@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413741@szxeml546-mbs.china.huawei.com> <7BDA456234D045E1BD42EA059A4E9579@v2comsam> <2073A6C5467C99478898544C6EBA3F4602C1907568@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> <60C093A41B5E45409A19D42CF7786DFD52328D98DF@EUSAACMS0703.eamcs.ericsson.se> <2691CE0099834E4A9C5044EEC662BB9D33108DD9@dfweml506-mbx> <1A7E043E03FF48A2B3E5ECCD4F124B4C@R01842> In-Reply-To: <1A7E043E03FF48A2B3E5ECCD4F124B4C@R01842> 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: Wed, 16 May 2012 16:21:57 -0000 Hi Sam: Thanks for explaining your reasoning, this is useful. Based on your comments I assume you believe that the scope of the S-tag is = only the PW section, so it is imposed by the ingress PE and removed by the = egress PE? And you would prefer recreating an S-tag if an egress PE had a subtending P= BN and stripping it if it in is an ingress from a PBN? So this has little to do with ETREE itself, but tag interworking with a PBN= or not? Thanks Dave -----Original Message----- From: Sam Cao [mailto:yuqun.cao@gmail.com] Sent: Tuesday, May 15, 2012 7:09 PM To: 'Lucy yong'; David Allan I; 'Balus, Florin Stelian (Florin)'; 'Jiangyua= nlong'; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance Lucy/David/Florin, Thank you very much for your comments. I can not give the accurate data to support my conclusion, and just conclud= e that if we implement it in NP module. Except for common operations of 2 a= pproaches, Tunnel Label push/pop-out, MAC-based forwarding, and etc., Dual-= VLAN needs one more VLAN push/pop-out operation while forwarding every fram= e. So compared with Multi-PW, it needs more resource and time for NP module= if there are VSIs or PWs up limit to the capacity on one PE, and standing = on software architect's side, the performance will be decreased by at least= 20%, I guess. I implemented one prototype which has similar solution as cu= rrent Multi-PW, and the performance will be decreased by 5%, compared with = traditional VPLS. Daniel has experience on 2-PW deployment, maybe he can gi= ve accurate data on Multi-PW. Florin, do you mean that you have implemented E-Tree in MPLS network? If ch= ipset can support this and we don't care NP or other solutions, yes, we can= ignore any side effect on forwarding performance. Yes, it can support E-tr= ee in IP (Ethernet) network, but I read some CHIP datasheets, after strip P= W label out, chip can not handle 2 VLAN IDs at same time. Could you please = give me some hints, say, which chip you used? Maybe if we raised only one issue in one mail, we can get more and insight = comments :). I will raise another after we agree with this in the main :). Thanks, Sam -----Original Message----- From: Lucy yong [mailto:lucy.yong@huawei.com] Sent: Wednesday, May 16, 2012 4:15 AM To: David Allan I; Balus, Florin Stelian (Florin); Sam Cao; Jiangyuanlong; = 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance +1 We can't just make a conclusion from nowhere. Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= avid Allan I Sent: Tuesday, May 15, 2012 2:55 PM To: Balus, Florin Stelian (Florin); Sam Cao; Jiangyuanlong; 'Daniel Cohn'; = 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance Florin: I agree. The statement, at least to me, is a non-sequitor... Cheers Dave -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of B= alus, Florin Stelian (Florin) Sent: Tuesday, May 15, 2012 12:53 PM To: Sam Cao; 'Jiangyuanlong'; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance Sam, > Obviously the forwarding performance of Dual-VLAN will be much lower > than what of Multi-PW. Sorry I could not keep up with some of the threads on this subject but the = above statement caught my eyes. We have been doing all kind of egress opera= tions on VLANs in the egress PE for the last 8 years and I am not aware of = any "much lower" forwarding performance. As far as I know the chipsets used= in the PEs can do this processing no problem. Do you want to clarify which= kind of hardware may have problems? > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Sam Cao > Sent: Tuesday, May 15, 2012 6:32 AM > To: 'Jiangyuanlong'; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on forwarding performance > > Hi Yuanlong, > > 3rd mapping will make data plane complex, I think. Anyway, we reached > a consensus on Multi-PW implementation. > > If we use 3rd mapping, I agree with your opinion, maybe dual-VLAN > seems simple, but 2 mapping is enough. Then we can focus on data plane > performance. While stripe PW label out on egress PE, data-plane knows > how to forward the frames from PW, to Root AC or Leaf AC or all. But > if we use Dual-VLAN, after strip PW label out, data plane should strip > VLAN-ID out and then does same forwarding work as Multi-PW does. The > most important is, do one more operation while forwarding E-Tree > frames. Obviously the forwarding performance of Dual-VLAN will be much > lower than what of Multi-PW. > > Regards, > > Yuqun (Sam) Cao > E-mail: Yuqun.cao@gmail.com > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 7:03 PM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > See my further comments in line. > > -----Original Message----- > From: Sam Cao [mailto:yuqun.cao@gmail.com] > Sent: Tuesday, May 15, 2012 6:14 PM > To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > Thank you very much for your comments. I draw the topology you gave, > and 7 PWs will be established if we follow 01. > > Root AC ---- PE 1 ----- PW 1 -------- PE 2 ----- Leaf _AC > | \ / || > | \ /=3D=3D=3DPW 6,7=3D=3D=3D || > PW 2 -----PW 5------\ || > | /----Root PW 3 --- \ || > Root _AC ---- PE 3 PE 4 ------ Root AC > | \ / | > | ----Leaf PW 4----- | > Leaf AC Leaf AC > Yes, on PE 3 there are several PWs, but if you want to clarify it, > there are only 3 types, one can carry frames originated from Root and > Leaf AC(one endpoint of this PW should be Root-only, otherwise this is > invalid), one only can carry frames from Root AC, and the last can > carry frames from Leaf ACs. On second thoughts, we still can classify > the PWs into 2 sets, one is Leaf set, and another is Root set, and the > union of the sets Leaf and Root is the PW we called it as compatible > PW (Maybe this is not correct, we can find one good term on this). > > So this optimization still follows the original design of Dual-PW > approach, Leaf PW only carries frames from Leaf AC; Root-PW only > carries frames from Root AC. Is it right? > > I don't know whether chip can support this forwarding behavior for > compatible PW or not, but if we implement it in NP, it is nearly same > as VPLS. The only difference is, setup 2 mappings, one between > Leaf-ACs and Leaf-PWs, one between Root-ACs and Root-PWs. For > traditional VPLS, there is only one mapping. > > [JY] It seems you may need a 3rd mapping: from both root & leaf AC to > a compatible PW. > BTW, for the forwarding and reverse direction, the mapping may be > asymmetric for you compatible PW. > > Based on my understanding, all drafts should have similar mapping. > > [JY] Dual-VLAN seems simpler here. > > Thanks, > > Sam > > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 3:32 PM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Sam, > > Thanks, please see my further comments with [JY]. > > Ok, we go on the case in your mail, where PE1 has one Root-only AC, > AC1, and > PE2 has one Leaf-only AC, AC2. In general we can setup 2 > "unidirectional" > PWs (bidirectional PW, but just carry unidirectional frames), Root-PW > which carries frames originated from AC1 and Leaf-PW which carries > frames originated from AC2. But only one PW also can work, just as > some members commented. Ok, we setup one PW between PE1 and PE2, we > can call this PW as compatible PW or something else. Frames originated > from Root or leaf ACs will be carried via this PW. Its forwarding > behavior is fully same as what traditional VPLS did, MAC learning on > AC or PW in one E-Tree. Or say, if one PE has Root-only ACs, it will > setup one PW with another PE, Root-only, Leaf-only or Root-Leaf-Mixed. > If 2 PEs are root-Leaf-Mixed or other cases, then 2 PWs will be > established. As you know, this can be done on control plane. > > [JY] Assume there are 2 other nodes PE3 & PE4 in this network > scenario, and both PE3 and PE4 have both root and leaf ACs, then there > are compatible PWs from PE3 which may carry both root and leaf traffic > (to PE1), which may carry only root traffic (to PE2); and further > there are root PW and leaf PW to PE4. Thus, the VSI on PE3 has at > least 4 different types of PW transmitting behaviours with regard to > the E-Tree traffic. In the reverse direction, the VSI on PE3 further > has at least > 4 different types of PW receiving behaviours. Not sure how you will > accommodate for these PWs in both the data plane and control plane. > > Regards, > Yuanlong > > Is this clear for you? Is this necessary to optimize PW setup in this > case? > > Maybe we need to add one paragraph on forwarding behavior. > > Again thank you very much for your comments, > > Sam > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 10:27 AM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Please see my comments in line. > > -----Original Message----- > From: Sam Cao [mailto:yuqun.cao@gmail.com] > Sent: Monday, May 14, 2012 8:31 PM > To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > We have discussed this in another thread. In fact, Daniel or I have > given the answers to the questions you raised here for several time :). > If we do in this way, we will reach deadlock and can not move forward > :). I try to explain it again. > > [JY] I will apologize if you had ever provided such answers before, > and you may just refer to the links rather than repeat the explanation. > As you can see, I just try to understand the mechanism of 2PW and its > implications, but the I-D does not include enough information. > > As you know, initial design we will setup 2 PWs all the time (if do in > this way, I think that you have no question), > > [JY] I will be concerned with the operational complexity of this > approach. > > but in most cases 2 PWs are not > necessary. So in 01 version, we optimize it. > > "Root-only VSI <-> any VSI: only root PW required" > "Leaf-only VSI <-> leaf-only VSI: no PWs required" > > In other cases 2 PWs are needed. If so, "Leaf-only -> root-only =3D one > leaf PW" is not correct: On Leaf-only side, yes, one Leaf-only PW is > created between Local Leaf type with remote Root type; on root-only > side, one root-only PW is created. Maybe it is better to call this as > compatible or mixed PW. So the left items you list are not correct for > multi_PW solution. > > [JY] This is something new, right? To be honest, I could not > understand what is your point: doesn't the mixed PW as you called also > consist of one Leaf-only PW in one direction and one root-only PW in > the other direction? > Furthermore, the case you took is also one case in your guideline > "Root-only VSI <-> any VSI: only root PW required", don't you think > that only one root PW is required following this guideline? > Actually, I don't care much about what is the bidirectional PW or > unidirectional PW called, but how can a VSI support such a mixed > scenarios: > traditional VSI assumes only one PW is required for each peer VSI, and > its MAC leaning is based on bidirectional PW. But for 2PW, there are > bidirectional root PW, bidirectional leaf PW, mixed PW, etc..., how to > support these kinds of PWs in the same VSI is my top concern. > > BTW, I guess you also care this case we also have discussed before: > for example, if we configure one Leaf AC on root-only PE (then it will > be root-leaf-mixed PE), we will teardown the compatible PW and > re-setup PWs again with 01. > [JY] This was discussed in the emails indeed. > > Regards, > > Yuqun (Sam) Cao > E-mail: Yuqun.cao@gmail.com > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Monday, May 14, 2012 7:10 PM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Daniel, > > Fine, now it seems more in line with what we had proposed in 2VLAN: a > spoke PW behaves like root/leaf AC for a PE-r. > > But the same problem may also apply to the root/spoke "core PW" for > Multi-PW: > According to Multi-PW, only one PW is required between two PEs except > when both PEs are mixed with root and leaf, so these PWs may be formed > by combinations of the following unidirectional PW cases (extracted > and adapted from Josh's email): > Root-only -> any VSI =3D one root PW > Leaf-only -> root-only =3D one leaf PW > Leaf-only -> mixed =3D one leaf PW > Mixed -> root-only =3D one (root+leaf) PW Mixed -> leaf-only =3D one > (root+leaf) PW > > I have a concern that the forwarding plane of PE to implement this > will be very different from the traditional VPLS. > > Regards, > Yuanlong > > -----Original Message----- > From: Daniel Cohn [mailto:DanielC@orckit.com] > Sent: Monday, May 14, 2012 5:00 PM > To: Jiangyuanlong; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > Like I wrote below, root/leaf spoke PW behave like root/leaf AC, not > like root/spoke "core PW". So no changes to forwarding plane once this > is understood. > > DC > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Monday, May 14, 2012 11:36 AM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Daniel, please see my comments in line. > > -----Original Message----- > From: Daniel Cohn [mailto:DanielC@orckit.com] > Sent: Monday, May 14, 2012 3:37 PM > To: Jiangyuanlong; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > As I see it, for the PE-r spoke (figure 4 in RFC 4762) we establish a > single PW per AC - root PW for root AC and leaf PW for leaf AC. With > local configuration at the PE-rs as part of the spoke PW provisioning. > And the PE-rs will treat root/leaf spoke PWs exactly as it treat > root/leaf ACs. So when leaf-originated BUM traffic arrives from the > core (over a leaf PW), it will be forwarded over all root spoke PWs > but not on the leaf spoke PWs. > > [JY] So in the reverse direction, you need to transport both root and > leaf traffic from PE-rs over a root PW to PE-r, and transport root > traffic over a leaf PW. It seems against the definition of root PW and > leaf PW in the multi-PW draft. Don't this make the forwarding plane of > PE-rs more complex? > > The forwarding plane is exactly the same as described in the multi-PW > draft, where spoke PWs are treated exactly like ACs. > > Regards, > > Daniel > > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Friday, May 11, 2012 5:03 AM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Daniel and all, > > When you set up two PWs from the PE-rs to a PE-r for each of its AC, > do you mean that one PW is bidirectional root PW and the other is > bidirectional leaf PW? > My concern is: where should the leaf traffic be filtered, on the PE-rs > or on the PE-r? > If filtered on the PE-r, then lots of bandwidth will be wasted (for > example, if the PE-r is attached with 9 leafs, then the BUM traffic > from one of its leafs will be multiplied by 8 times, and be forwarded > by the PE-rs to the same PE-r). > If filtered on the PE-rs, not sure how you will design its forwarding > plane, can you give a hint? > > Thanks, > Yuanlong > > ------------------------------ > Date: Wed, 9 May 2012 09:16:36 +0300 > From: "Daniel Cohn" > To: "Alexander Vainshtein" , "Sa= m > Cao" , > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780CBA6@tlvmail1> > Content-Type: text/plain; charset=3D"ISO-2022-JP" > > Hi Sasha, > > It's actually very simple. A frame that originated in a root AC is > always transmitted only in root PW, no matter what the frame type > (known/unknown unicast or broadcast). This is how the frame source > information is propagated across the VPLS. So in the H-VPLS example, > the PE-r will never forward a frame received over a root PW on any > leaf PW, only on root PWs (toward the core or toward other spokes). > > Hope this clarifies it, regards, > > Daniel > > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Alexander Vainshtein > Sent: Wednesday, May 09, 2012 7:59 AM > To: Sam Cao; l2vpn@ietf.org > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > > Sam, Lizhong and all, > You've written that in the two-PW solution combined with H-VPLS the > PE- r must set up two PWs with each MTU-s. > > If this is the case, what kind of forwarding logic should be used to > prevent sending a BUM frame received from a root-PW to a given MTU-S: > - back to the same MTU-S on the corresponding leaf-PW? > - twice (to both root-PW and Leaf-PW) to another MTU-s? And, BTW, how > is the PW selected in this case? > > I am aware of a technique of multiple split horizon groups in PE-r > which could be possibly used for this purpose. However, since these > groups have to be represented explicitly in the data plane, their > potential number is limited by the forwarding HW. Other methods could > be probably used for the same purpose, but they would probably subject > to similar HW-based limitations. > > I suspect that with the dual-PW approach, the HW would pose an > implicit limit, say, on a number of MTU-s that can be connected to the > same PE-r and that this limit could be quite low in most cases. > > Based on this I suspect that the H-VPLS issue as a critical drawback > of the dual-PW approach to E-Tree. > > My 2c, > Sasha > > > ________________________________________ > From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Sam > Cao [yuqun.cao@gmail.com] > Sent: Wednesday, May 09, 2012 3:40 AM > To: l2vpn@ietf.org > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Lizhong? > > Thank you very much for your comments. I updated the result on this > question. > > [Lizhong] agree with the above analysis. And we did not say it is a > technical problem, but it is an operational problem again. > [Sam] I agree. Dual-VLAN does not make sense. I also discussed this > with Giles and Yuanlong in another mail, and we reached agreement on > this: > MTU should know the access mode, VPWS or VPLS, VPWS mode should > configure VLAN ID on MTU but VPLS mode can not. I thought this is NOT > reasonable :), but we can figure this out in draft. It seems ok. > > [Lizhong] not fully understand. Do you mean, when VPWS accessing for > H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf > PW) for each AC access? > [Sam] Yes. > > Thanks, > > Sam > > > > From josh.rogers@twcable.com Wed May 16 12:42:14 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C132221F858E for ; Wed, 16 May 2012 12:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.503 X-Spam-Level: X-Spam-Status: No, score=-0.503 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_23=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 rkgQ-a5KRhyn for ; Wed, 16 May 2012 12:42:13 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id B4D0921F86DA for ; Wed, 16 May 2012 12:42:12 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.75,604,1330923600"; d="scan'208";a="382007749" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 16 May 2012 15:42:00 -0400 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.36]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Wed, 16 May 2012 15:42:10 -0400 From: "Rogers, Josh" To: Jiangyuanlong , Daniel Cohn , "Balus, Florin Stelian (Florin)" , Sam Cao , Alexander Vainshtein Date: Wed, 16 May 2012 15:42:07 -0400 Subject: Re: Discussion on forwarding performance - 2VLAN Thread-Topic: Discussion on forwarding performance - 2VLAN Thread-Index: Ac0zm/tSB4z1pFV2SMqygKakXrXfEw== Message-ID: In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413B06@szxeml546-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="Windows-1252" 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, 16 May 2012 19:42:14 -0000 Yuanlong, I agree with your statement/assessment of where lookups occur to decide how to forward (egress PE), however=8A If optimization is done to prevent the frame from being forwarded to PE's that have no AC's of the appropriate type, then there has to some sort of mapping between the ingress AC and the appropriate PW. Earlier I assumed that this mapping would be done by looking at the S-VLAN that would be applied on the ingress PE physical interface. In the case of optimization being used, you'd see lookup of S-VLAN on both ingress and egress PE's, right? If not, how is the mapping between ingress AC and appropriate PW's done? On 5/16/12 5:04 AM, "Jiangyuanlong" wrote: >Daniel, > >I don't think we need to look up the VLAN and PW at the same time for >Dual-VLAN: >On the ingress PE, VLAN is firstly appended or translated for a incoming >Ethernet frame from AC, then MAC forwarded in VSI to one or multiple >logical ports each corresponding to a PW (the VLAN mapping may be >processed on a logical port), finally a PW label is appended and >transported over the corresponding PW. >On the egress PE, PW is popped and used to indicate a VSI (also >corresponding to a logical port, where the VLAN mapping may also be >processed), then MAC forwarded in VSI to one or multiple ports each >corresponding to an AC (where a frame with a leaf VLAN will be dropped >upon a leaf AC, actually, it is also a simple VLAN translation in IEEE, >that is, from leaf VLAN to 0xFFF, and all frames with this VLAN will be >dropped). > >Therefore, double lookup of VLAN and PW seems unnecessary or even >impossible for this service IMHO. > >Regards, >Yuanlong > >-----Original Message----- >From: Daniel Cohn [mailto:DanielC@orckit.com] >Sent: Wednesday, May 16, 2012 4:49 PM >To: Jiangyuanlong; Balus, Florin Stelian (Florin); Sam Cao; Alexander >Vainshtein >Cc: l2vpn@ietf.org >Subject: RE: Discussion on forwarding performance > >VC ID is another name for PW label, right. > ;-) >From conversations with chip vendors, I understood that when multiple >lookups are required (as in the dual-VLAN example, you need to lookup PW >label to identify E-Tree instance and then VLAN ID to identify root/leaf >origin), typically a single lookup is performed on ingress with a >composite search key (in this case, including PW label and VLAN ID). >/ ;-) >But perhaps we are getting too much into implementation here. It would >be better if neutral NP and ASIC-based solution vendors could analyze >both solutions and confirm impact on performance and scalability - and >BTW, we also need input regarding existing silicon that doesn't support >VLAN mapping. > >DC > >-----Original Message----- >From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >Sent: Wednesday, May 16, 2012 9:43 AM >To: Daniel Cohn; Balus, Florin Stelian (Florin); Sam Cao; Alexander >Vainshtein >Cc: l2vpn@ietf.org >Subject: RE: Discussion on forwarding performance > >Daniel, > >Not sure I fully understand what you mean by "VLAN and VCID lookups are >performed simultaneously on ingress", do you mean VLAN and PW? >Can you give more details on this requirement? > >Regards, >Yuanlong > > >-----Original Message----- >From: Daniel Cohn [mailto:DanielC@orckit.com] >Sent: Wednesday, May 16, 2012 2:16 PM >To: Balus, Florin Stelian (Florin); Sam Cao; Jiangyuanlong; Alexander >Vainshtein >Cc: l2vpn@ietf.org >Subject: RE: Discussion on forwarding performance > >Hi, > >I agree that for a chip-based solution there should be no difference in >performance for the additional lookup. However from conversations with >chip vendors, I understood there might be an impact on scalability >because the double lookup would require a longer search key (assuming >VLAN and VCID lookups are performed simultaneously on ingress), thus >taking up more TCAM resources per E-Tree instance. This would depend on >specific TCAM implementation (e.g. granularity of search key length). > >DC > >-----Original Message----- >From: Balus, Florin Stelian (Florin) >[mailto:florin.balus@alcatel-lucent.com] >Sent: Tuesday, May 15, 2012 10:53 PM >To: Sam Cao; 'Jiangyuanlong'; Daniel Cohn; 'Alexander Vainshtein' >Cc: l2vpn@ietf.org >Subject: RE: Discussion on forwarding performance > >Sam, > >> Obviously the forwarding performance of Dual-VLAN will be much lower >than what of Multi-PW. > >Sorry I could not keep up with some of the threads on this subject but >the above statement caught my eyes. We have been doing all kind of >egress operations on VLANs in the egress PE for the last 8 years and I >am not aware of any "much lower" forwarding performance. As far as I >know the chipsets used in the PEs can do this processing no problem. Do >you want to clarify which kind of hardware may have problems? > >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >> Of Sam Cao >> Sent: Tuesday, May 15, 2012 6:32 AM >> To: 'Jiangyuanlong'; 'Daniel Cohn'; 'Alexander Vainshtein' >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on forwarding performance >> >> Hi Yuanlong, >> >> 3rd mapping will make data plane complex, I think. Anyway, we reached >a >> consensus on Multi-PW implementation. >> >> If we use 3rd mapping, I agree with your opinion, maybe dual-VLAN >seems >> simple, but 2 mapping is enough. Then we can focus on data plane >> performance. While stripe PW label out on egress PE, data-plane knows >> how to forward the frames from PW, to Root AC or Leaf AC or all. But >if >> we use Dual-VLAN, after strip PW label out, data plane should strip >> VLAN-ID out and then does same forwarding work as Multi-PW does. The >> most important is, do one more operation while forwarding E-Tree >> frames. Obviously the forwarding performance of Dual-VLAN will be much >> lower than what of Multi-PW. >> >> Regards, >> >> Yuqun (Sam) Cao >> E-mail: Yuqun.cao@gmail.com >> >> -----Original Message----- >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> Sent: Tuesday, May 15, 2012 7:03 PM >> To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> See my further comments in line. >> >> -----Original Message----- >> From: Sam Cao [mailto:yuqun.cao@gmail.com] >> Sent: Tuesday, May 15, 2012 6:14 PM >> To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Hi Yuanlong, >> >> Thank you very much for your comments. I draw the topology you gave, >> and 7 PWs will be established if we follow 01. >> >> Root AC ---- PE 1 ----- PW 1 -------- PE 2 ----- Leaf _AC >> | \ / || >> | \ /=3D=3D=3DPW 6,7=3D=3D=3D || >> PW 2 -----PW 5------\ || >> | /----Root PW 3 --- \ || >> Root _AC ---- PE 3 PE 4 ------ Root AC >> | \ / | >> | ----Leaf PW 4----- | >> Leaf AC Leaf AC >> Yes, on PE 3 there are several PWs, but if you want to clarify it, >> there are only 3 types, one can carry frames originated from Root and >> Leaf AC(one endpoint of this PW should be Root-only, otherwise this is >> invalid), one only can carry frames from Root AC, and the last can >> carry frames from Leaf ACs. On second thoughts, we still can classify >> the PWs into 2 sets, one is Leaf set, and another is Root set, and the >> union of the sets Leaf and Root is the PW we called it as compatible >PW >> (Maybe this is not correct, we can find one good term on this). >> >> So this optimization still follows the original design of Dual-PW >> approach, Leaf PW only carries frames from Leaf AC; Root-PW only >> carries frames from Root AC. Is it right? >> >> I don't know whether chip can support this forwarding behavior for >> compatible PW or not, but if we implement it in NP, it is nearly same >> as VPLS. The only difference is, setup 2 mappings, one between >Leaf-ACs >> and Leaf-PWs, one between Root-ACs and Root-PWs. For traditional VPLS, >> there is only one mapping. >> >> [JY] It seems you may need a 3rd mapping: from both root & leaf AC to >a >> compatible PW. >> BTW, for the forwarding and reverse direction, the mapping may be >> asymmetric for you compatible PW. >> >> Based on my understanding, all drafts should have similar mapping. >> >> [JY] Dual-VLAN seems simpler here. >> >> Thanks, >> >> Sam >> >> >> -----Original Message----- >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> Sent: Tuesday, May 15, 2012 3:32 PM >> To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Sam, >> >> Thanks, please see my further comments with [JY]. >> >> Ok, we go on the case in your mail, where PE1 has one Root-only AC, >> AC1, and >> PE2 has one Leaf-only AC, AC2. In general we can setup 2 >> "unidirectional" >> PWs (bidirectional PW, but just carry unidirectional frames), Root-PW >> which carries frames originated from AC1 and Leaf-PW which carries >> frames originated from AC2. But only one PW also can work, just as >some >> members commented. Ok, we setup one PW between PE1 and PE2, we can >call >> this PW as compatible PW or something else. Frames originated from >Root >> or leaf ACs will be carried via this PW. Its forwarding behavior is >> fully same as what traditional VPLS did, MAC learning on AC or PW in >> one E-Tree. Or say, if one PE has Root-only ACs, it will setup one PW >> with another PE, Root-only, Leaf-only or Root-Leaf-Mixed. If 2 PEs are >> root-Leaf-Mixed or other cases, then 2 PWs will be established. As you >> know, this can be done on control plane. >> >> [JY] Assume there are 2 other nodes PE3 & PE4 in this network >scenario, >> and both PE3 and PE4 have both root and leaf ACs, then there are >> compatible PWs from PE3 which may carry both root and leaf traffic (to >> PE1), which may carry only root traffic (to PE2); and further there >are >> root PW and leaf PW to PE4. Thus, the VSI on PE3 has at least 4 >> different types of PW transmitting behaviours with regard to the >E-Tree >> traffic. In the reverse direction, the VSI on PE3 further has at least >> 4 different types of PW receiving behaviours. Not sure how you will >> accommodate for these PWs in both the data plane and control plane. >> >> Regards, >> Yuanlong >> >> Is this clear for you? Is this necessary to optimize PW setup in this >> case? >> >> Maybe we need to add one paragraph on forwarding behavior. >> >> Again thank you very much for your comments, >> >> Sam >> >> -----Original Message----- >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> Sent: Tuesday, May 15, 2012 10:27 AM >> To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Please see my comments in line. >> >> -----Original Message----- >> From: Sam Cao [mailto:yuqun.cao@gmail.com] >> Sent: Monday, May 14, 2012 8:31 PM >> To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Hi Yuanlong, >> >> We have discussed this in another thread. In fact, Daniel or I have >> given the answers to the questions you raised here for several time >:). >> If we do in this way, we will reach deadlock and can not move forward >> :). I try to explain it again. >> >> [JY] I will apologize if you had ever provided such answers before, >and >> you may just refer to the links rather than repeat the explanation. >> As you can see, I just try to understand the mechanism of 2PW and its >> implications, but the I-D does not include enough information. >> >> As you know, initial design we will setup 2 PWs all the time (if do in >> this way, I think that you have no question), >> >> [JY] I will be concerned with the operational complexity of this >> approach. >> >> but in most cases 2 PWs are not >> necessary. So in 01 version, we optimize it. >> >> "Root-only VSI <-> any VSI: only root PW required" >> "Leaf-only VSI <-> leaf-only VSI: no PWs required" >> >> In other cases 2 PWs are needed. If so, "Leaf-only -> root-only =3D one >> leaf PW" is not correct: On Leaf-only side, yes, one Leaf-only PW is >> created between Local Leaf type with remote Root type; on root-only >> side, one root-only PW is created. Maybe it is better to call this as >> compatible or mixed PW. So the left items you list are not correct for >> multi_PW solution. >> >> [JY] This is something new, right? To be honest, I could not >understand >> what is your point: doesn't the mixed PW as you called also consist of >> one Leaf-only PW in one direction and one root-only PW in the other >> direction? >> Furthermore, the case you took is also one case in your guideline >> "Root-only VSI <-> any VSI: only root PW required", don't you think >> that only one root PW is required following this guideline? >> Actually, I don't care much about what is the bidirectional PW or >> unidirectional PW called, but how can a VSI support such a mixed >> scenarios: >> traditional VSI assumes only one PW is required for each peer VSI, and >> its MAC leaning is based on bidirectional PW. But for 2PW, there are >> bidirectional root PW, bidirectional leaf PW, mixed PW, etc..., how to >> support these kinds of PWs in the same VSI is my top concern. >> >> BTW, I guess you also care this case we also have discussed before: >for >> example, if we configure one Leaf AC on root-only PE (then it will be >> root-leaf-mixed PE), we will teardown the compatible PW and re-setup >> PWs again with 01. >> [JY] This was discussed in the emails indeed. >> >> Regards, >> >> Yuqun (Sam) Cao >> E-mail: Yuqun.cao@gmail.com >> >> -----Original Message----- >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> Sent: Monday, May 14, 2012 7:10 PM >> To: Daniel Cohn; Alexander Vainshtein; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Hi Daniel, >> >> Fine, now it seems more in line with what we had proposed in 2VLAN: a >> spoke PW behaves like root/leaf AC for a PE-r. >> >> But the same problem may also apply to the root/spoke "core PW" for >> Multi-PW: >> According to Multi-PW, only one PW is required between two PEs except >> when both PEs are mixed with root and leaf, so these PWs may be formed >> by combinations of the following unidirectional PW cases (extracted >and >> adapted from Josh's email): >> Root-only -> any VSI =3D one root PW >> Leaf-only -> root-only =3D one leaf PW >> Leaf-only -> mixed =3D one leaf PW >> Mixed -> root-only =3D one (root+leaf) PW >> Mixed -> leaf-only =3D one (root+leaf) PW >> >> I have a concern that the forwarding plane of PE to implement this >will >> be very different from the traditional VPLS. >> >> Regards, >> Yuanlong >> >> -----Original Message----- >> From: Daniel Cohn [mailto:DanielC@orckit.com] >> Sent: Monday, May 14, 2012 5:00 PM >> To: Jiangyuanlong; Alexander Vainshtein; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Hi Yuanlong, >> >> Like I wrote below, root/leaf spoke PW behave like root/leaf AC, not >> like root/spoke "core PW". So no changes to forwarding plane once this >> is understood. >> >> DC >> >> -----Original Message----- >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> Sent: Monday, May 14, 2012 11:36 AM >> To: Daniel Cohn; Alexander Vainshtein; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Daniel, please see my comments in line. >> >> -----Original Message----- >> From: Daniel Cohn [mailto:DanielC@orckit.com] >> Sent: Monday, May 14, 2012 3:37 PM >> To: Jiangyuanlong; Alexander Vainshtein; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Hi Yuanlong, >> >> As I see it, for the PE-r spoke (figure 4 in RFC 4762) we establish a >> single PW per AC - root PW for root AC and leaf PW for leaf AC. With >> local configuration at the PE-rs as part of the spoke PW provisioning. >> And the PE-rs will treat root/leaf spoke PWs exactly as it treat >> root/leaf ACs. So when leaf-originated BUM traffic arrives from the >> core (over a leaf PW), it will be forwarded over all root spoke PWs >but >> not on the leaf spoke PWs. >> >> [JY] So in the reverse direction, you need to transport both root and >> leaf traffic from PE-rs over a root PW to PE-r, and transport root >> traffic over a leaf PW. It seems against the definition of root PW and >> leaf PW in the multi-PW draft. Don't this make the forwarding plane of >> PE-rs more complex? >> >> The forwarding plane is exactly the same as described in the multi-PW >> draft, where spoke PWs are treated exactly like ACs. >> >> Regards, >> >> Daniel >> >> >> -----Original Message----- >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> Sent: Friday, May 11, 2012 5:03 AM >> To: Daniel Cohn; Alexander Vainshtein; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Hi Daniel and all, >> >> When you set up two PWs from the PE-rs to a PE-r for each of its AC, >do >> you mean that one PW is bidirectional root PW and the other is >> bidirectional leaf PW? >> My concern is: where should the leaf traffic be filtered, on the PE-rs >> or on the PE-r? >> If filtered on the PE-r, then lots of bandwidth will be wasted (for >> example, if the PE-r is attached with 9 leafs, then the BUM traffic >> from one of its leafs will be multiplied by 8 times, and be forwarded >> by the PE-rs to the same PE-r). >> If filtered on the PE-rs, not sure how you will design its forwarding >> plane, can you give a hint? >> >> Thanks, >> Yuanlong >> >> ------------------------------ >> Date: Wed, 9 May 2012 09:16:36 +0300 >> From: "Daniel Cohn" >> To: "Alexander Vainshtein" , >"Sam >> Cao" , >> Cc: lizhong.jin@zte.com.cn >> Subject: RE: Discussion on E-Tree and H-VPLS >> Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780CBA6@tlvmail1> >> Content-Type: text/plain; charset=3D"ISO-2022-JP" >> >> Hi Sasha, >> >> It's actually very simple. A frame that originated in a root AC is >> always transmitted only in root PW, no matter what the frame type >> (known/unknown unicast or broadcast). This is how the frame source >> information is propagated across the VPLS. So in the H-VPLS example, >> the PE-r will never forward a frame received over a root PW on any >leaf >> PW, only on root PWs (toward the core or toward other spokes). >> >> Hope this clarifies it, regards, >> >> Daniel >> >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >> Of Alexander Vainshtein >> Sent: Wednesday, May 09, 2012 7:59 AM >> To: Sam Cao; l2vpn@ietf.org >> Cc: lizhong.jin@zte.com.cn >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Sam, Lizhong and all, >> You've written that in the two-PW solution combined with H-VPLS the >PE- >> r must set up two PWs with each MTU-s. >> >> If this is the case, what kind of forwarding logic should be used to >> prevent sending a BUM frame received from a root-PW to a given MTU-S: >> - back to the same MTU-S on the corresponding leaf-PW? >> - twice (to both root-PW and Leaf-PW) to another MTU-s? And, BTW, how >> is the PW selected in this case? >> >> I am aware of a technique of multiple split horizon groups in PE-r >> which could be possibly used for this purpose. However, since these >> groups have to be represented explicitly in the data plane, their >> potential number is limited by the forwarding HW. Other methods could >> be probably used for the same purpose, but they would probably subject >> to similar HW-based limitations. >> >> I suspect that with the dual-PW approach, the HW would pose an >implicit >> limit, say, on a number of MTU-s that can be connected to the same >PE-r >> and that this limit could be quite low in most cases. >> >> Based on this I suspect that the H-VPLS issue as a critical drawback >of >> the dual-PW approach to E-Tree. >> >> My 2c, >> Sasha >> >> >> ________________________________________ >> From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Sam >> Cao [yuqun.cao@gmail.com] >> Sent: Wednesday, May 09, 2012 3:40 AM >> To: l2vpn@ietf.org >> Cc: lizhong.jin@zte.com.cn >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Hi Lizhong? >> >> Thank you very much for your comments. I updated the result on this >> question. >> >> [Lizhong] agree with the above analysis. And we did not say it is a >> technical problem, but it is an operational problem again. >> [Sam] I agree. Dual-VLAN does not make sense. I also discussed this >> with Giles and Yuanlong in another mail, and we reached agreement on >> this: >> MTU should know the access mode, VPWS or VPLS, VPWS mode should >> configure VLAN ID on MTU but VPLS mode can not. I thought this is NOT >> reasonable :), but we can figure this out in draft. It seems ok. >> >> [Lizhong] not fully understand. Do you mean, when VPWS accessing for >> H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf >> PW) for each AC access? >> [Sam] Yes. >> >> Thanks, >> >> Sam >> >> >> >> > 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 florin.balus@alcatel-lucent.com Wed May 16 12:53: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 2EC0421F85B5 for ; Wed, 16 May 2012 12:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.455 X-Spam-Level: X-Spam-Status: No, score=-9.455 tagged_above=-999 required=5 tests=[AWL=0.544, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZo2kEXRidgG for ; Wed, 16 May 2012 12:52:58 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 1287921F85A1 for ; Wed, 16 May 2012 12:52:58 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q4GJqpeR007165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 May 2012 14:52:51 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q4GJqpIo025475 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 16 May 2012 14:52:51 -0500 Received: from USNAVSXCHMBSC3.ndc.alcatel-lucent.com ([135.3.39.144]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Wed, 16 May 2012 14:52:51 -0500 From: "Balus, Florin Stelian (Florin)" To: "Rogers, Josh" , Jiangyuanlong , Daniel Cohn , Sam Cao , Alexander Vainshtein Date: Wed, 16 May 2012 14:52:49 -0500 Subject: RE: Discussion on forwarding performance - 2VLAN Thread-Topic: Discussion on forwarding performance - 2VLAN Thread-Index: Ac0zm/tSB4z1pFV2SMqygKakXrXfEwAAFdKQ Message-ID: <2073A6C5467C99478898544C6EBA3F4602C19077F0@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413B06@szxeml546-mbs.china.huawei.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="iso-8859-2" Content-Transfer-Encoding: quoted-printable 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.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: Wed, 16 May 2012 19:53:00 -0000 As soon as the packet is received on the ingress PE the ingress card (e.g. = service manager) will know on what kind of entry point it arrived: i.e. whe= ther it is a leaf or a root. Then right there it could make a decision whet= her it goes out on a PW or not. The SVLAN indication is really for the next= PE in the chain. > -----Original Message----- > From: Rogers, Josh [mailto:josh.rogers@twcable.com] > Sent: Wednesday, May 16, 2012 12:42 PM > To: Jiangyuanlong; Daniel Cohn; Balus, Florin Stelian (Florin); Sam > Cao; Alexander Vainshtein > Cc: l2vpn@ietf.org > Subject: Re: Discussion on forwarding performance - 2VLAN > > Yuanlong, I agree with your statement/assessment of where lookups occur > to decide how to forward (egress PE), however=A9 If optimization is done > to prevent the frame from being forwarded to PE's that have no AC's of > the appropriate type, then there has to some sort of mapping between > the ingress AC and the appropriate PW. Earlier I assumed that this > mapping would be done by looking at the S-VLAN that would be applied on > the ingress PE physical interface. In the case of optimization being > used, you'd see lookup of S-VLAN on both ingress and egress PE's, > right? If not, how is the mapping between ingress AC and appropriate > PW's done? > > > > On 5/16/12 5:04 AM, "Jiangyuanlong" wrote: > > >Daniel, > > > >I don't think we need to look up the VLAN and PW at the same time for > >Dual-VLAN: > >On the ingress PE, VLAN is firstly appended or translated for a > >incoming Ethernet frame from AC, then MAC forwarded in VSI to one or > >multiple logical ports each corresponding to a PW (the VLAN mapping > may > >be processed on a logical port), finally a PW label is appended and > >transported over the corresponding PW. > >On the egress PE, PW is popped and used to indicate a VSI (also > >corresponding to a logical port, where the VLAN mapping may also be > >processed), then MAC forwarded in VSI to one or multiple ports each > >corresponding to an AC (where a frame with a leaf VLAN will be dropped > >upon a leaf AC, actually, it is also a simple VLAN translation in > IEEE, > >that is, from leaf VLAN to 0xFFF, and all frames with this VLAN will > be > >dropped). > > > >Therefore, double lookup of VLAN and PW seems unnecessary or even > >impossible for this service IMHO. > > > >Regards, > >Yuanlong > > > >-----Original Message----- > >From: Daniel Cohn [mailto:DanielC@orckit.com] > >Sent: Wednesday, May 16, 2012 4:49 PM > >To: Jiangyuanlong; Balus, Florin Stelian (Florin); Sam Cao; Alexander > >Vainshtein > >Cc: l2vpn@ietf.org > >Subject: RE: Discussion on forwarding performance > > > >VC ID is another name for PW label, right. > > ;-) > >From conversations with chip vendors, I understood that when multiple > >lookups are required (as in the dual-VLAN example, you need to lookup > >PW label to identify E-Tree instance and then VLAN ID to identify > >root/leaf origin), typically a single lookup is performed on ingress > >with a composite search key (in this case, including PW label and VLAN > ID). > >/ ;-) > >But perhaps we are getting too much into implementation here. It would > >be better if neutral NP and ASIC-based solution vendors could analyze > >both solutions and confirm impact on performance and scalability - and > >BTW, we also need input regarding existing silicon that doesn't > support > >VLAN mapping. > > > >DC > > > >-----Original Message----- > >From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > >Sent: Wednesday, May 16, 2012 9:43 AM > >To: Daniel Cohn; Balus, Florin Stelian (Florin); Sam Cao; Alexander > >Vainshtein > >Cc: l2vpn@ietf.org > >Subject: RE: Discussion on forwarding performance > > > >Daniel, > > > >Not sure I fully understand what you mean by "VLAN and VCID lookups > are > >performed simultaneously on ingress", do you mean VLAN and PW? > >Can you give more details on this requirement? > > > >Regards, > >Yuanlong > > > > > >-----Original Message----- > >From: Daniel Cohn [mailto:DanielC@orckit.com] > >Sent: Wednesday, May 16, 2012 2:16 PM > >To: Balus, Florin Stelian (Florin); Sam Cao; Jiangyuanlong; Alexander > >Vainshtein > >Cc: l2vpn@ietf.org > >Subject: RE: Discussion on forwarding performance > > > >Hi, > > > >I agree that for a chip-based solution there should be no difference > in > >performance for the additional lookup. However from conversations with > >chip vendors, I understood there might be an impact on scalability > >because the double lookup would require a longer search key (assuming > >VLAN and VCID lookups are performed simultaneously on ingress), thus > >taking up more TCAM resources per E-Tree instance. This would depend > on > >specific TCAM implementation (e.g. granularity of search key length). > > > >DC > > > >-----Original Message----- > >From: Balus, Florin Stelian (Florin) > >[mailto:florin.balus@alcatel-lucent.com] > >Sent: Tuesday, May 15, 2012 10:53 PM > >To: Sam Cao; 'Jiangyuanlong'; Daniel Cohn; 'Alexander Vainshtein' > >Cc: l2vpn@ietf.org > >Subject: RE: Discussion on forwarding performance > > > >Sam, > > > >> Obviously the forwarding performance of Dual-VLAN will be much lower > >than what of Multi-PW. > > > >Sorry I could not keep up with some of the threads on this subject but > >the above statement caught my eyes. We have been doing all kind of > >egress operations on VLANs in the egress PE for the last 8 years and I > >am not aware of any "much lower" forwarding performance. As far as I > >know the chipsets used in the PEs can do this processing no problem. > Do > >you want to clarify which kind of hardware may have problems? > > > >> -----Original Message----- > >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > >> Behalf Of Sam Cao > >> Sent: Tuesday, May 15, 2012 6:32 AM > >> To: 'Jiangyuanlong'; 'Daniel Cohn'; 'Alexander Vainshtein' > >> Cc: l2vpn@ietf.org > >> Subject: RE: Discussion on forwarding performance > >> > >> Hi Yuanlong, > >> > >> 3rd mapping will make data plane complex, I think. Anyway, we > reached > >a > >> consensus on Multi-PW implementation. > >> > >> If we use 3rd mapping, I agree with your opinion, maybe dual-VLAN > >seems > >> simple, but 2 mapping is enough. Then we can focus on data plane > >> performance. While stripe PW label out on egress PE, data-plane > knows > >> how to forward the frames from PW, to Root AC or Leaf AC or all. But > >if > >> we use Dual-VLAN, after strip PW label out, data plane should strip > >> VLAN-ID out and then does same forwarding work as Multi-PW does. The > >> most important is, do one more operation while forwarding E-Tree > >> frames. Obviously the forwarding performance of Dual-VLAN will be > >> much lower than what of Multi-PW. > >> > >> Regards, > >> > >> Yuqun (Sam) Cao > >> E-mail: Yuqun.cao@gmail.com > >> > >> -----Original Message----- > >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > >> Sent: Tuesday, May 15, 2012 7:03 PM > >> To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > >> Cc: l2vpn@ietf.org > >> Subject: RE: Discussion on E-Tree and H-VPLS > >> > >> See my further comments in line. > >> > >> -----Original Message----- > >> From: Sam Cao [mailto:yuqun.cao@gmail.com] > >> Sent: Tuesday, May 15, 2012 6:14 PM > >> To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' > >> Cc: l2vpn@ietf.org > >> Subject: RE: Discussion on E-Tree and H-VPLS > >> > >> Hi Yuanlong, > >> > >> Thank you very much for your comments. I draw the topology you gave, > >> and 7 PWs will be established if we follow 01. > >> > >> Root AC ---- PE 1 ----- PW 1 -------- PE 2 ----- Leaf _AC > >> | \ / || > >> | \ /=3D=3D=3DPW 6,7=3D=3D=3D || > >> PW 2 -----PW 5------\ || > >> | /----Root PW 3 --- \ || > >> Root _AC ---- PE 3 PE 4 ------ Root AC > >> | \ / | > >> | ----Leaf PW 4----- | > >> Leaf AC Leaf AC > >> Yes, on PE 3 there are several PWs, but if you want to clarify it, > >> there are only 3 types, one can carry frames originated from Root > and > >> Leaf AC(one endpoint of this PW should be Root-only, otherwise this > >> is invalid), one only can carry frames from Root AC, and the last > can > >> carry frames from Leaf ACs. On second thoughts, we still can > classify > >> the PWs into 2 sets, one is Leaf set, and another is Root set, and > >> the union of the sets Leaf and Root is the PW we called it as > >> compatible > >PW > >> (Maybe this is not correct, we can find one good term on this). > >> > >> So this optimization still follows the original design of Dual-PW > >> approach, Leaf PW only carries frames from Leaf AC; Root-PW only > >> carries frames from Root AC. Is it right? > >> > >> I don't know whether chip can support this forwarding behavior for > >> compatible PW or not, but if we implement it in NP, it is nearly > same > >> as VPLS. The only difference is, setup 2 mappings, one between > >Leaf-ACs > >> and Leaf-PWs, one between Root-ACs and Root-PWs. For traditional > >> VPLS, there is only one mapping. > >> > >> [JY] It seems you may need a 3rd mapping: from both root & leaf AC > to > >a > >> compatible PW. > >> BTW, for the forwarding and reverse direction, the mapping may be > >> asymmetric for you compatible PW. > >> > >> Based on my understanding, all drafts should have similar mapping. > >> > >> [JY] Dual-VLAN seems simpler here. > >> > >> Thanks, > >> > >> Sam > >> > >> > >> -----Original Message----- > >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > >> Sent: Tuesday, May 15, 2012 3:32 PM > >> To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > >> Cc: l2vpn@ietf.org > >> Subject: RE: Discussion on E-Tree and H-VPLS > >> > >> Sam, > >> > >> Thanks, please see my further comments with [JY]. > >> > >> Ok, we go on the case in your mail, where PE1 has one Root-only AC, > >> AC1, and > >> PE2 has one Leaf-only AC, AC2. In general we can setup 2 > >> "unidirectional" > >> PWs (bidirectional PW, but just carry unidirectional frames), Root- > PW > >> which carries frames originated from AC1 and Leaf-PW which carries > >> frames originated from AC2. But only one PW also can work, just as > >some > >> members commented. Ok, we setup one PW between PE1 and PE2, we can > >call > >> this PW as compatible PW or something else. Frames originated from > >Root > >> or leaf ACs will be carried via this PW. Its forwarding behavior is > >> fully same as what traditional VPLS did, MAC learning on AC or PW in > >> one E-Tree. Or say, if one PE has Root-only ACs, it will setup one > PW > >> with another PE, Root-only, Leaf-only or Root-Leaf-Mixed. If 2 PEs > >> are root-Leaf-Mixed or other cases, then 2 PWs will be established. > >> As you know, this can be done on control plane. > >> > >> [JY] Assume there are 2 other nodes PE3 & PE4 in this network > >scenario, > >> and both PE3 and PE4 have both root and leaf ACs, then there are > >> compatible PWs from PE3 which may carry both root and leaf traffic > >> (to PE1), which may carry only root traffic (to PE2); and further > >> there > >are > >> root PW and leaf PW to PE4. Thus, the VSI on PE3 has at least 4 > >> different types of PW transmitting behaviours with regard to the > >E-Tree > >> traffic. In the reverse direction, the VSI on PE3 further has at > >> least > >> 4 different types of PW receiving behaviours. Not sure how you will > >> accommodate for these PWs in both the data plane and control plane. > >> > >> Regards, > >> Yuanlong > >> > >> Is this clear for you? Is this necessary to optimize PW setup in > this > >> case? > >> > >> Maybe we need to add one paragraph on forwarding behavior. > >> > >> Again thank you very much for your comments, > >> > >> Sam > >> > >> -----Original Message----- > >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > >> Sent: Tuesday, May 15, 2012 10:27 AM > >> To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > >> Cc: l2vpn@ietf.org > >> Subject: RE: Discussion on E-Tree and H-VPLS > >> > >> Please see my comments in line. > >> > >> -----Original Message----- > >> From: Sam Cao [mailto:yuqun.cao@gmail.com] > >> Sent: Monday, May 14, 2012 8:31 PM > >> To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' > >> Cc: l2vpn@ietf.org > >> Subject: RE: Discussion on E-Tree and H-VPLS > >> > >> Hi Yuanlong, > >> > >> We have discussed this in another thread. In fact, Daniel or I have > >> given the answers to the questions you raised here for several time > >:). > >> If we do in this way, we will reach deadlock and can not move > forward > >> :). I try to explain it again. > >> > >> [JY] I will apologize if you had ever provided such answers before, > >and > >> you may just refer to the links rather than repeat the explanation. > >> As you can see, I just try to understand the mechanism of 2PW and > its > >> implications, but the I-D does not include enough information. > >> > >> As you know, initial design we will setup 2 PWs all the time (if do > >> in this way, I think that you have no question), > >> > >> [JY] I will be concerned with the operational complexity of this > >> approach. > >> > >> but in most cases 2 PWs are not > >> necessary. So in 01 version, we optimize it. > >> > >> "Root-only VSI <-> any VSI: only root PW required" > >> "Leaf-only VSI <-> leaf-only VSI: no PWs required" > >> > >> In other cases 2 PWs are needed. If so, "Leaf-only -> root-only =3D > one > >> leaf PW" is not correct: On Leaf-only side, yes, one Leaf-only PW is > >> created between Local Leaf type with remote Root type; on root-only > >> side, one root-only PW is created. Maybe it is better to call this > as > >> compatible or mixed PW. So the left items you list are not correct > >> for multi_PW solution. > >> > >> [JY] This is something new, right? To be honest, I could not > >understand > >> what is your point: doesn't the mixed PW as you called also consist > >> of one Leaf-only PW in one direction and one root-only PW in the > >> other direction? > >> Furthermore, the case you took is also one case in your guideline > >> "Root-only VSI <-> any VSI: only root PW required", don't you think > >> that only one root PW is required following this guideline? > >> Actually, I don't care much about what is the bidirectional PW or > >> unidirectional PW called, but how can a VSI support such a mixed > >> scenarios: > >> traditional VSI assumes only one PW is required for each peer VSI, > >> and its MAC leaning is based on bidirectional PW. But for 2PW, there > >> are bidirectional root PW, bidirectional leaf PW, mixed PW, etc..., > >> how to support these kinds of PWs in the same VSI is my top concern. > >> > >> BTW, I guess you also care this case we also have discussed before: > >for > >> example, if we configure one Leaf AC on root-only PE (then it will > be > >> root-leaf-mixed PE), we will teardown the compatible PW and re-setup > >> PWs again with 01. > >> [JY] This was discussed in the emails indeed. > >> > >> Regards, > >> > >> Yuqun (Sam) Cao > >> E-mail: Yuqun.cao@gmail.com > >> > >> -----Original Message----- > >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > >> Sent: Monday, May 14, 2012 7:10 PM > >> To: Daniel Cohn; Alexander Vainshtein; Sam Cao > >> Cc: l2vpn@ietf.org > >> Subject: RE: Discussion on E-Tree and H-VPLS > >> > >> Hi Daniel, > >> > >> Fine, now it seems more in line with what we had proposed in 2VLAN: > a > >> spoke PW behaves like root/leaf AC for a PE-r. > >> > >> But the same problem may also apply to the root/spoke "core PW" for > >> Multi-PW: > >> According to Multi-PW, only one PW is required between two PEs > except > >> when both PEs are mixed with root and leaf, so these PWs may be > >> formed by combinations of the following unidirectional PW cases > >> (extracted > >and > >> adapted from Josh's email): > >> Root-only -> any VSI =3D one root PW > >> Leaf-only -> root-only =3D one leaf PW > >> Leaf-only -> mixed =3D one leaf PW > >> Mixed -> root-only =3D one (root+leaf) PW Mixed -> leaf-only =3D one > >> (root+leaf) PW > >> > >> I have a concern that the forwarding plane of PE to implement this > >will > >> be very different from the traditional VPLS. > >> > >> Regards, > >> Yuanlong > >> > >> -----Original Message----- > >> From: Daniel Cohn [mailto:DanielC@orckit.com] > >> Sent: Monday, May 14, 2012 5:00 PM > >> To: Jiangyuanlong; Alexander Vainshtein; Sam Cao > >> Cc: l2vpn@ietf.org > >> Subject: RE: Discussion on E-Tree and H-VPLS > >> > >> Hi Yuanlong, > >> > >> Like I wrote below, root/leaf spoke PW behave like root/leaf AC, not > >> like root/spoke "core PW". So no changes to forwarding plane once > >> this is understood. > >> > >> DC > >> > >> -----Original Message----- > >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > >> Sent: Monday, May 14, 2012 11:36 AM > >> To: Daniel Cohn; Alexander Vainshtein; Sam Cao > >> Cc: l2vpn@ietf.org > >> Subject: RE: Discussion on E-Tree and H-VPLS > >> > >> Daniel, please see my comments in line. > >> > >> -----Original Message----- > >> From: Daniel Cohn [mailto:DanielC@orckit.com] > >> Sent: Monday, May 14, 2012 3:37 PM > >> To: Jiangyuanlong; Alexander Vainshtein; Sam Cao > >> Cc: l2vpn@ietf.org > >> Subject: RE: Discussion on E-Tree and H-VPLS > >> > >> Hi Yuanlong, > >> > >> As I see it, for the PE-r spoke (figure 4 in RFC 4762) we establish > a > >> single PW per AC - root PW for root AC and leaf PW for leaf AC. With > >> local configuration at the PE-rs as part of the spoke PW > provisioning. > >> And the PE-rs will treat root/leaf spoke PWs exactly as it treat > >> root/leaf ACs. So when leaf-originated BUM traffic arrives from the > >> core (over a leaf PW), it will be forwarded over all root spoke PWs > >but > >> not on the leaf spoke PWs. > >> > >> [JY] So in the reverse direction, you need to transport both root > and > >> leaf traffic from PE-rs over a root PW to PE-r, and transport root > >> traffic over a leaf PW. It seems against the definition of root PW > >> and leaf PW in the multi-PW draft. Don't this make the forwarding > >> plane of PE-rs more complex? > >> > >> The forwarding plane is exactly the same as described in the multi- > PW > >> draft, where spoke PWs are treated exactly like ACs. > >> > >> Regards, > >> > >> Daniel > >> > >> > >> -----Original Message----- > >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > >> Sent: Friday, May 11, 2012 5:03 AM > >> To: Daniel Cohn; Alexander Vainshtein; Sam Cao > >> Cc: l2vpn@ietf.org > >> Subject: RE: Discussion on E-Tree and H-VPLS > >> > >> Hi Daniel and all, > >> > >> When you set up two PWs from the PE-rs to a PE-r for each of its AC, > >do > >> you mean that one PW is bidirectional root PW and the other is > >> bidirectional leaf PW? > >> My concern is: where should the leaf traffic be filtered, on the > >> PE-rs or on the PE-r? > >> If filtered on the PE-r, then lots of bandwidth will be wasted (for > >> example, if the PE-r is attached with 9 leafs, then the BUM traffic > >> from one of its leafs will be multiplied by 8 times, and be > forwarded > >> by the PE-rs to the same PE-r). > >> If filtered on the PE-rs, not sure how you will design its > forwarding > >> plane, can you give a hint? > >> > >> Thanks, > >> Yuanlong > >> > >> ------------------------------ > >> Date: Wed, 9 May 2012 09:16:36 +0300 > >> From: "Daniel Cohn" > >> To: "Alexander Vainshtein" , > >"Sam > >> Cao" , > >> Cc: lizhong.jin@zte.com.cn > >> Subject: RE: Discussion on E-Tree and H-VPLS > >> Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780CBA6@tlvmail1> > >> Content-Type: text/plain; charset=3D"ISO-2022-JP" > >> > >> Hi Sasha, > >> > >> It's actually very simple. A frame that originated in a root AC is > >> always transmitted only in root PW, no matter what the frame type > >> (known/unknown unicast or broadcast). This is how the frame source > >> information is propagated across the VPLS. So in the H-VPLS example, > >> the PE-r will never forward a frame received over a root PW on any > >leaf > >> PW, only on root PWs (toward the core or toward other spokes). > >> > >> Hope this clarifies it, regards, > >> > >> Daniel > >> > >> -----Original Message----- > >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > >> Behalf Of Alexander Vainshtein > >> Sent: Wednesday, May 09, 2012 7:59 AM > >> To: Sam Cao; l2vpn@ietf.org > >> Cc: lizhong.jin@zte.com.cn > >> Subject: RE: Discussion on E-Tree and H-VPLS > >> > >> Sam, Lizhong and all, > >> You've written that in the two-PW solution combined with H-VPLS the > >PE- > >> r must set up two PWs with each MTU-s. > >> > >> If this is the case, what kind of forwarding logic should be used to > >> prevent sending a BUM frame received from a root-PW to a given MTU- > S: > >> - back to the same MTU-S on the corresponding leaf-PW? > >> - twice (to both root-PW and Leaf-PW) to another MTU-s? And, BTW, > how > >> is the PW selected in this case? > >> > >> I am aware of a technique of multiple split horizon groups in PE-r > >> which could be possibly used for this purpose. However, since these > >> groups have to be represented explicitly in the data plane, their > >> potential number is limited by the forwarding HW. Other methods > could > >> be probably used for the same purpose, but they would probably > >> subject to similar HW-based limitations. > >> > >> I suspect that with the dual-PW approach, the HW would pose an > >implicit > >> limit, say, on a number of MTU-s that can be connected to the same > >PE-r > >> and that this limit could be quite low in most cases. > >> > >> Based on this I suspect that the H-VPLS issue as a critical drawback > >of > >> the dual-PW approach to E-Tree. > >> > >> My 2c, > >> Sasha > >> > >> > >> ________________________________________ > >> From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of > >> Sam Cao [yuqun.cao@gmail.com] > >> Sent: Wednesday, May 09, 2012 3:40 AM > >> To: l2vpn@ietf.org > >> Cc: lizhong.jin@zte.com.cn > >> Subject: RE: Discussion on E-Tree and H-VPLS > >> > >> Hi Lizhong? > >> > >> Thank you very much for your comments. I updated the result on this > >> question. > >> > >> [Lizhong] agree with the above analysis. And we did not say it is a > >> technical problem, but it is an operational problem again. > >> [Sam] I agree. Dual-VLAN does not make sense. I also discussed this > >> with Giles and Yuanlong in another mail, and we reached agreement on > >> this: > >> MTU should know the access mode, VPWS or VPLS, VPWS mode should > >> configure VLAN ID on MTU but VPLS mode can not. I thought this is > NOT > >> reasonable :), but we can figure this out in draft. It seems ok. > >> > >> [Lizhong] not fully understand. Do you mean, when VPWS accessing > for > >> H-VPLS, the PE-r is also necessary to configure two PWs (root and > >> leaf > >> PW) for each AC access? > >> [Sam] Yes. > >> > >> Thanks, > >> > >> Sam > >> > >> > >> > >> > > > > > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject > to copyright belonging to Time Warner Cable. This E-mail is intended > solely for the use of the individual or entity to which it is > addressed. If you are not the intended recipient of this E-mail, you > are hereby notified that any dissemination, distribution, copying, or > action taken in relation to the contents of and attachments to this E- > mail is strictly prohibited and may be unlawful. If you have received > this 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 May 16 13:14: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 1149121F864D for ; Wed, 16 May 2012 13:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.517 X-Spam-Level: X-Spam-Status: No, score=-0.517 tagged_above=-999 required=5 tests=[AWL=0.346, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_23=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 dFvT5XP75eJy for ; Wed, 16 May 2012 13:14:05 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id C8C1821F8616 for ; Wed, 16 May 2012 13:14:04 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.75,604,1330923600"; d="scan'208";a="382025590" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 16 May 2012 16:09:10 -0400 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.36]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Wed, 16 May 2012 16:09:19 -0400 From: "Rogers, Josh" To: "Balus, Florin Stelian (Florin)" , Jiangyuanlong , Daniel Cohn , Sam Cao , Alexander Vainshtein Date: Wed, 16 May 2012 16:09:17 -0400 Subject: Re: Discussion on forwarding performance - 2VLAN Thread-Topic: Discussion on forwarding performance - 2VLAN Thread-Index: Ac0zn8bVPxT1+7IJRdCqCy41OyiiFA== Message-ID: In-Reply-To: <2073A6C5467C99478898544C6EBA3F4602C19077F0@USNAVSXCHMBSC3.ndc.alcatel-lucent.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="iso-8859-2" 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, 16 May 2012 20:14:11 -0000 Florin, thanks for the explanation. Today, bridge (on a PE) expects to/from all endpoints in the domain. Will any particular effort in implementation have to be made to tie together appropriate AC's with appropriate PW's? This question should apply to both the 2VLAN and MultiPW methods, as both seem to rely on these source-dependant (as opposed to the destination based forwarding rules based on DST MAC only) On 5/16/12 2:52 PM, "Balus, Florin Stelian (Florin)" wrote: >As soon as the packet is received on the ingress PE the ingress card >(e.g. service manager) will know on what kind of entry point it arrived: >i.e. whether it is a leaf or a root. Then right there it could make a >decision whether it goes out on a PW or not. The SVLAN indication is >really for the next PE in the chain. > >> -----Original Message----- >> From: Rogers, Josh [mailto:josh.rogers@twcable.com] >> Sent: Wednesday, May 16, 2012 12:42 PM >> To: Jiangyuanlong; Daniel Cohn; Balus, Florin Stelian (Florin); Sam >> Cao; Alexander Vainshtein >> Cc: l2vpn@ietf.org >> Subject: Re: Discussion on forwarding performance - 2VLAN >> >> Yuanlong, I agree with your statement/assessment of where lookups occur >> to decide how to forward (egress PE), however=A9 If optimization is don= e >> to prevent the frame from being forwarded to PE's that have no AC's of >> the appropriate type, then there has to some sort of mapping between >> the ingress AC and the appropriate PW. Earlier I assumed that this >> mapping would be done by looking at the S-VLAN that would be applied on >> the ingress PE physical interface. In the case of optimization being >> used, you'd see lookup of S-VLAN on both ingress and egress PE's, >> right? If not, how is the mapping between ingress AC and appropriate >> PW's done? >> >> >> >> On 5/16/12 5:04 AM, "Jiangyuanlong" wrote: >> >> >Daniel, >> > >> >I don't think we need to look up the VLAN and PW at the same time for >> >Dual-VLAN: >> >On the ingress PE, VLAN is firstly appended or translated for a >> >incoming Ethernet frame from AC, then MAC forwarded in VSI to one or >> >multiple logical ports each corresponding to a PW (the VLAN mapping >> may >> >be processed on a logical port), finally a PW label is appended and >> >transported over the corresponding PW. >> >On the egress PE, PW is popped and used to indicate a VSI (also >> >corresponding to a logical port, where the VLAN mapping may also be >> >processed), then MAC forwarded in VSI to one or multiple ports each >> >corresponding to an AC (where a frame with a leaf VLAN will be dropped >> >upon a leaf AC, actually, it is also a simple VLAN translation in >> IEEE, >> >that is, from leaf VLAN to 0xFFF, and all frames with this VLAN will >> be >> >dropped). >> > >> >Therefore, double lookup of VLAN and PW seems unnecessary or even >> >impossible for this service IMHO. >> > >> >Regards, >> >Yuanlong >> > >> >-----Original Message----- >> >From: Daniel Cohn [mailto:DanielC@orckit.com] >> >Sent: Wednesday, May 16, 2012 4:49 PM >> >To: Jiangyuanlong; Balus, Florin Stelian (Florin); Sam Cao; Alexander >> >Vainshtein >> >Cc: l2vpn@ietf.org >> >Subject: RE: Discussion on forwarding performance >> > >> >VC ID is another name for PW label, right. >> > ;-) >> >From conversations with chip vendors, I understood that when multiple >> >lookups are required (as in the dual-VLAN example, you need to lookup >> >PW label to identify E-Tree instance and then VLAN ID to identify >> >root/leaf origin), typically a single lookup is performed on ingress >> >with a composite search key (in this case, including PW label and VLAN >> ID). >> >/ ;-) >> >But perhaps we are getting too much into implementation here. It would >> >be better if neutral NP and ASIC-based solution vendors could analyze >> >both solutions and confirm impact on performance and scalability - and >> >BTW, we also need input regarding existing silicon that doesn't >> support >> >VLAN mapping. >> > >> >DC >> > >> >-----Original Message----- >> >From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> >Sent: Wednesday, May 16, 2012 9:43 AM >> >To: Daniel Cohn; Balus, Florin Stelian (Florin); Sam Cao; Alexander >> >Vainshtein >> >Cc: l2vpn@ietf.org >> >Subject: RE: Discussion on forwarding performance >> > >> >Daniel, >> > >> >Not sure I fully understand what you mean by "VLAN and VCID lookups >> are >> >performed simultaneously on ingress", do you mean VLAN and PW? >> >Can you give more details on this requirement? >> > >> >Regards, >> >Yuanlong >> > >> > >> >-----Original Message----- >> >From: Daniel Cohn [mailto:DanielC@orckit.com] >> >Sent: Wednesday, May 16, 2012 2:16 PM >> >To: Balus, Florin Stelian (Florin); Sam Cao; Jiangyuanlong; Alexander >> >Vainshtein >> >Cc: l2vpn@ietf.org >> >Subject: RE: Discussion on forwarding performance >> > >> >Hi, >> > >> >I agree that for a chip-based solution there should be no difference >> in >> >performance for the additional lookup. However from conversations with >> >chip vendors, I understood there might be an impact on scalability >> >because the double lookup would require a longer search key (assuming >> >VLAN and VCID lookups are performed simultaneously on ingress), thus >> >taking up more TCAM resources per E-Tree instance. This would depend >> on >> >specific TCAM implementation (e.g. granularity of search key length). >> > >> >DC >> > >> >-----Original Message----- >> >From: Balus, Florin Stelian (Florin) >> >[mailto:florin.balus@alcatel-lucent.com] >> >Sent: Tuesday, May 15, 2012 10:53 PM >> >To: Sam Cao; 'Jiangyuanlong'; Daniel Cohn; 'Alexander Vainshtein' >> >Cc: l2vpn@ietf.org >> >Subject: RE: Discussion on forwarding performance >> > >> >Sam, >> > >> >> Obviously the forwarding performance of Dual-VLAN will be much lower >> >than what of Multi-PW. >> > >> >Sorry I could not keep up with some of the threads on this subject but >> >the above statement caught my eyes. We have been doing all kind of >> >egress operations on VLANs in the egress PE for the last 8 years and I >> >am not aware of any "much lower" forwarding performance. As far as I >> >know the chipsets used in the PEs can do this processing no problem. >> Do >> >you want to clarify which kind of hardware may have problems? >> > >> >> -----Original Message----- >> >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >> >> Behalf Of Sam Cao >> >> Sent: Tuesday, May 15, 2012 6:32 AM >> >> To: 'Jiangyuanlong'; 'Daniel Cohn'; 'Alexander Vainshtein' >> >> Cc: l2vpn@ietf.org >> >> Subject: RE: Discussion on forwarding performance >> >> >> >> Hi Yuanlong, >> >> >> >> 3rd mapping will make data plane complex, I think. Anyway, we >> reached >> >a >> >> consensus on Multi-PW implementation. >> >> >> >> If we use 3rd mapping, I agree with your opinion, maybe dual-VLAN >> >seems >> >> simple, but 2 mapping is enough. Then we can focus on data plane >> >> performance. While stripe PW label out on egress PE, data-plane >> knows >> >> how to forward the frames from PW, to Root AC or Leaf AC or all. But >> >if >> >> we use Dual-VLAN, after strip PW label out, data plane should strip >> >> VLAN-ID out and then does same forwarding work as Multi-PW does. The >> >> most important is, do one more operation while forwarding E-Tree >> >> frames. Obviously the forwarding performance of Dual-VLAN will be >> >> much lower than what of Multi-PW. >> >> >> >> Regards, >> >> >> >> Yuqun (Sam) Cao >> >> E-mail: Yuqun.cao@gmail.com >> >> >> >> -----Original Message----- >> >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> >> Sent: Tuesday, May 15, 2012 7:03 PM >> >> To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' >> >> Cc: l2vpn@ietf.org >> >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> >> >> See my further comments in line. >> >> >> >> -----Original Message----- >> >> From: Sam Cao [mailto:yuqun.cao@gmail.com] >> >> Sent: Tuesday, May 15, 2012 6:14 PM >> >> To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' >> >> Cc: l2vpn@ietf.org >> >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> >> >> Hi Yuanlong, >> >> >> >> Thank you very much for your comments. I draw the topology you gave, >> >> and 7 PWs will be established if we follow 01. >> >> >> >> Root AC ---- PE 1 ----- PW 1 -------- PE 2 ----- Leaf _AC >> >> | \ / || >> >> | \ /=3D=3D=3DPW 6,7=3D=3D=3D || >> >> PW 2 -----PW 5------\ || >> >> | /----Root PW 3 --- \ || >> >> Root _AC ---- PE 3 PE 4 ------ Root AC >> >> | \ / | >> >> | ----Leaf PW 4----- | >> >> Leaf AC Leaf AC >> >> Yes, on PE 3 there are several PWs, but if you want to clarify it, >> >> there are only 3 types, one can carry frames originated from Root >> and >> >> Leaf AC(one endpoint of this PW should be Root-only, otherwise this >> >> is invalid), one only can carry frames from Root AC, and the last >> can >> >> carry frames from Leaf ACs. On second thoughts, we still can >> classify >> >> the PWs into 2 sets, one is Leaf set, and another is Root set, and >> >> the union of the sets Leaf and Root is the PW we called it as >> >> compatible >> >PW >> >> (Maybe this is not correct, we can find one good term on this). >> >> >> >> So this optimization still follows the original design of Dual-PW >> >> approach, Leaf PW only carries frames from Leaf AC; Root-PW only >> >> carries frames from Root AC. Is it right? >> >> >> >> I don't know whether chip can support this forwarding behavior for >> >> compatible PW or not, but if we implement it in NP, it is nearly >> same >> >> as VPLS. The only difference is, setup 2 mappings, one between >> >Leaf-ACs >> >> and Leaf-PWs, one between Root-ACs and Root-PWs. For traditional >> >> VPLS, there is only one mapping. >> >> >> >> [JY] It seems you may need a 3rd mapping: from both root & leaf AC >> to >> >a >> >> compatible PW. >> >> BTW, for the forwarding and reverse direction, the mapping may be >> >> asymmetric for you compatible PW. >> >> >> >> Based on my understanding, all drafts should have similar mapping. >> >> >> >> [JY] Dual-VLAN seems simpler here. >> >> >> >> Thanks, >> >> >> >> Sam >> >> >> >> >> >> -----Original Message----- >> >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> >> Sent: Tuesday, May 15, 2012 3:32 PM >> >> To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' >> >> Cc: l2vpn@ietf.org >> >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> >> >> Sam, >> >> >> >> Thanks, please see my further comments with [JY]. >> >> >> >> Ok, we go on the case in your mail, where PE1 has one Root-only AC, >> >> AC1, and >> >> PE2 has one Leaf-only AC, AC2. In general we can setup 2 >> >> "unidirectional" >> >> PWs (bidirectional PW, but just carry unidirectional frames), Root- >> PW >> >> which carries frames originated from AC1 and Leaf-PW which carries >> >> frames originated from AC2. But only one PW also can work, just as >> >some >> >> members commented. Ok, we setup one PW between PE1 and PE2, we can >> >call >> >> this PW as compatible PW or something else. Frames originated from >> >Root >> >> or leaf ACs will be carried via this PW. Its forwarding behavior is >> >> fully same as what traditional VPLS did, MAC learning on AC or PW in >> >> one E-Tree. Or say, if one PE has Root-only ACs, it will setup one >> PW >> >> with another PE, Root-only, Leaf-only or Root-Leaf-Mixed. If 2 PEs >> >> are root-Leaf-Mixed or other cases, then 2 PWs will be established. >> >> As you know, this can be done on control plane. >> >> >> >> [JY] Assume there are 2 other nodes PE3 & PE4 in this network >> >scenario, >> >> and both PE3 and PE4 have both root and leaf ACs, then there are >> >> compatible PWs from PE3 which may carry both root and leaf traffic >> >> (to PE1), which may carry only root traffic (to PE2); and further >> >> there >> >are >> >> root PW and leaf PW to PE4. Thus, the VSI on PE3 has at least 4 >> >> different types of PW transmitting behaviours with regard to the >> >E-Tree >> >> traffic. In the reverse direction, the VSI on PE3 further has at >> >> least >> >> 4 different types of PW receiving behaviours. Not sure how you will >> >> accommodate for these PWs in both the data plane and control plane. >> >> >> >> Regards, >> >> Yuanlong >> >> >> >> Is this clear for you? Is this necessary to optimize PW setup in >> this >> >> case? >> >> >> >> Maybe we need to add one paragraph on forwarding behavior. >> >> >> >> Again thank you very much for your comments, >> >> >> >> Sam >> >> >> >> -----Original Message----- >> >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> >> Sent: Tuesday, May 15, 2012 10:27 AM >> >> To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' >> >> Cc: l2vpn@ietf.org >> >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> >> >> Please see my comments in line. >> >> >> >> -----Original Message----- >> >> From: Sam Cao [mailto:yuqun.cao@gmail.com] >> >> Sent: Monday, May 14, 2012 8:31 PM >> >> To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' >> >> Cc: l2vpn@ietf.org >> >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> >> >> Hi Yuanlong, >> >> >> >> We have discussed this in another thread. In fact, Daniel or I have >> >> given the answers to the questions you raised here for several time >> >:). >> >> If we do in this way, we will reach deadlock and can not move >> forward >> >> :). I try to explain it again. >> >> >> >> [JY] I will apologize if you had ever provided such answers before, >> >and >> >> you may just refer to the links rather than repeat the explanation. >> >> As you can see, I just try to understand the mechanism of 2PW and >> its >> >> implications, but the I-D does not include enough information. >> >> >> >> As you know, initial design we will setup 2 PWs all the time (if do >> >> in this way, I think that you have no question), >> >> >> >> [JY] I will be concerned with the operational complexity of this >> >> approach. >> >> >> >> but in most cases 2 PWs are not >> >> necessary. So in 01 version, we optimize it. >> >> >> >> "Root-only VSI <-> any VSI: only root PW required" >> >> "Leaf-only VSI <-> leaf-only VSI: no PWs required" >> >> >> >> In other cases 2 PWs are needed. If so, "Leaf-only -> root-only =3D >> one >> >> leaf PW" is not correct: On Leaf-only side, yes, one Leaf-only PW is >> >> created between Local Leaf type with remote Root type; on root-only >> >> side, one root-only PW is created. Maybe it is better to call this >> as >> >> compatible or mixed PW. So the left items you list are not correct >> >> for multi_PW solution. >> >> >> >> [JY] This is something new, right? To be honest, I could not >> >understand >> >> what is your point: doesn't the mixed PW as you called also consist >> >> of one Leaf-only PW in one direction and one root-only PW in the >> >> other direction? >> >> Furthermore, the case you took is also one case in your guideline >> >> "Root-only VSI <-> any VSI: only root PW required", don't you think >> >> that only one root PW is required following this guideline? >> >> Actually, I don't care much about what is the bidirectional PW or >> >> unidirectional PW called, but how can a VSI support such a mixed >> >> scenarios: >> >> traditional VSI assumes only one PW is required for each peer VSI, >> >> and its MAC leaning is based on bidirectional PW. But for 2PW, there >> >> are bidirectional root PW, bidirectional leaf PW, mixed PW, etc..., >> >> how to support these kinds of PWs in the same VSI is my top concern. >> >> >> >> BTW, I guess you also care this case we also have discussed before: >> >for >> >> example, if we configure one Leaf AC on root-only PE (then it will >> be >> >> root-leaf-mixed PE), we will teardown the compatible PW and re-setup >> >> PWs again with 01. >> >> [JY] This was discussed in the emails indeed. >> >> >> >> Regards, >> >> >> >> Yuqun (Sam) Cao >> >> E-mail: Yuqun.cao@gmail.com >> >> >> >> -----Original Message----- >> >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> >> Sent: Monday, May 14, 2012 7:10 PM >> >> To: Daniel Cohn; Alexander Vainshtein; Sam Cao >> >> Cc: l2vpn@ietf.org >> >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> >> >> Hi Daniel, >> >> >> >> Fine, now it seems more in line with what we had proposed in 2VLAN: >> a >> >> spoke PW behaves like root/leaf AC for a PE-r. >> >> >> >> But the same problem may also apply to the root/spoke "core PW" for >> >> Multi-PW: >> >> According to Multi-PW, only one PW is required between two PEs >> except >> >> when both PEs are mixed with root and leaf, so these PWs may be >> >> formed by combinations of the following unidirectional PW cases >> >> (extracted >> >and >> >> adapted from Josh's email): >> >> Root-only -> any VSI =3D one root PW >> >> Leaf-only -> root-only =3D one leaf PW >> >> Leaf-only -> mixed =3D one leaf PW >> >> Mixed -> root-only =3D one (root+leaf) PW Mixed -> leaf-only =3D one >> >> (root+leaf) PW >> >> >> >> I have a concern that the forwarding plane of PE to implement this >> >will >> >> be very different from the traditional VPLS. >> >> >> >> Regards, >> >> Yuanlong >> >> >> >> -----Original Message----- >> >> From: Daniel Cohn [mailto:DanielC@orckit.com] >> >> Sent: Monday, May 14, 2012 5:00 PM >> >> To: Jiangyuanlong; Alexander Vainshtein; Sam Cao >> >> Cc: l2vpn@ietf.org >> >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> >> >> Hi Yuanlong, >> >> >> >> Like I wrote below, root/leaf spoke PW behave like root/leaf AC, not >> >> like root/spoke "core PW". So no changes to forwarding plane once >> >> this is understood. >> >> >> >> DC >> >> >> >> -----Original Message----- >> >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> >> Sent: Monday, May 14, 2012 11:36 AM >> >> To: Daniel Cohn; Alexander Vainshtein; Sam Cao >> >> Cc: l2vpn@ietf.org >> >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> >> >> Daniel, please see my comments in line. >> >> >> >> -----Original Message----- >> >> From: Daniel Cohn [mailto:DanielC@orckit.com] >> >> Sent: Monday, May 14, 2012 3:37 PM >> >> To: Jiangyuanlong; Alexander Vainshtein; Sam Cao >> >> Cc: l2vpn@ietf.org >> >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> >> >> Hi Yuanlong, >> >> >> >> As I see it, for the PE-r spoke (figure 4 in RFC 4762) we establish >> a >> >> single PW per AC - root PW for root AC and leaf PW for leaf AC. With >> >> local configuration at the PE-rs as part of the spoke PW >> provisioning. >> >> And the PE-rs will treat root/leaf spoke PWs exactly as it treat >> >> root/leaf ACs. So when leaf-originated BUM traffic arrives from the >> >> core (over a leaf PW), it will be forwarded over all root spoke PWs >> >but >> >> not on the leaf spoke PWs. >> >> >> >> [JY] So in the reverse direction, you need to transport both root >> and >> >> leaf traffic from PE-rs over a root PW to PE-r, and transport root >> >> traffic over a leaf PW. It seems against the definition of root PW >> >> and leaf PW in the multi-PW draft. Don't this make the forwarding >> >> plane of PE-rs more complex? >> >> >> >> The forwarding plane is exactly the same as described in the multi- >> PW >> >> draft, where spoke PWs are treated exactly like ACs. >> >> >> >> Regards, >> >> >> >> Daniel >> >> >> >> >> >> -----Original Message----- >> >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> >> Sent: Friday, May 11, 2012 5:03 AM >> >> To: Daniel Cohn; Alexander Vainshtein; Sam Cao >> >> Cc: l2vpn@ietf.org >> >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> >> >> Hi Daniel and all, >> >> >> >> When you set up two PWs from the PE-rs to a PE-r for each of its AC, >> >do >> >> you mean that one PW is bidirectional root PW and the other is >> >> bidirectional leaf PW? >> >> My concern is: where should the leaf traffic be filtered, on the >> >> PE-rs or on the PE-r? >> >> If filtered on the PE-r, then lots of bandwidth will be wasted (for >> >> example, if the PE-r is attached with 9 leafs, then the BUM traffic >> >> from one of its leafs will be multiplied by 8 times, and be >> forwarded >> >> by the PE-rs to the same PE-r). >> >> If filtered on the PE-rs, not sure how you will design its >> forwarding >> >> plane, can you give a hint? >> >> >> >> Thanks, >> >> Yuanlong >> >> >> >> ------------------------------ >> >> Date: Wed, 9 May 2012 09:16:36 +0300 >> >> From: "Daniel Cohn" >> >> To: "Alexander Vainshtein" , >> >"Sam >> >> Cao" , >> >> Cc: lizhong.jin@zte.com.cn >> >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780CBA6@tlvmail1> >> >> Content-Type: text/plain; charset=3D"ISO-2022-JP" >> >> >> >> Hi Sasha, >> >> >> >> It's actually very simple. A frame that originated in a root AC is >> >> always transmitted only in root PW, no matter what the frame type >> >> (known/unknown unicast or broadcast). This is how the frame source >> >> information is propagated across the VPLS. So in the H-VPLS example, >> >> the PE-r will never forward a frame received over a root PW on any >> >leaf >> >> PW, only on root PWs (toward the core or toward other spokes). >> >> >> >> Hope this clarifies it, regards, >> >> >> >> Daniel >> >> >> >> -----Original Message----- >> >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >> >> Behalf Of Alexander Vainshtein >> >> Sent: Wednesday, May 09, 2012 7:59 AM >> >> To: Sam Cao; l2vpn@ietf.org >> >> Cc: lizhong.jin@zte.com.cn >> >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> >> >> Sam, Lizhong and all, >> >> You've written that in the two-PW solution combined with H-VPLS the >> >PE- >> >> r must set up two PWs with each MTU-s. >> >> >> >> If this is the case, what kind of forwarding logic should be used to >> >> prevent sending a BUM frame received from a root-PW to a given MTU- >> S: >> >> - back to the same MTU-S on the corresponding leaf-PW? >> >> - twice (to both root-PW and Leaf-PW) to another MTU-s? And, BTW, >> how >> >> is the PW selected in this case? >> >> >> >> I am aware of a technique of multiple split horizon groups in PE-r >> >> which could be possibly used for this purpose. However, since these >> >> groups have to be represented explicitly in the data plane, their >> >> potential number is limited by the forwarding HW. Other methods >> could >> >> be probably used for the same purpose, but they would probably >> >> subject to similar HW-based limitations. >> >> >> >> I suspect that with the dual-PW approach, the HW would pose an >> >implicit >> >> limit, say, on a number of MTU-s that can be connected to the same >> >PE-r >> >> and that this limit could be quite low in most cases. >> >> >> >> Based on this I suspect that the H-VPLS issue as a critical drawback >> >of >> >> the dual-PW approach to E-Tree. >> >> >> >> My 2c, >> >> Sasha >> >> >> >> >> >> ________________________________________ >> >> From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of >> >> Sam Cao [yuqun.cao@gmail.com] >> >> Sent: Wednesday, May 09, 2012 3:40 AM >> >> To: l2vpn@ietf.org >> >> Cc: lizhong.jin@zte.com.cn >> >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> >> >> Hi Lizhong? >> >> >> >> Thank you very much for your comments. I updated the result on this >> >> question. >> >> >> >> [Lizhong] agree with the above analysis. And we did not say it is a >> >> technical problem, but it is an operational problem again. >> >> [Sam] I agree. Dual-VLAN does not make sense. I also discussed this >> >> with Giles and Yuanlong in another mail, and we reached agreement on >> >> this: >> >> MTU should know the access mode, VPWS or VPLS, VPWS mode should >> >> configure VLAN ID on MTU but VPLS mode can not. I thought this is >> NOT >> >> reasonable :), but we can figure this out in draft. It seems ok. >> >> >> >> [Lizhong] not fully understand. Do you mean, when VPWS accessing >> for >> >> H-VPLS, the PE-r is also necessary to configure two PWs (root and >> >> leaf >> >> PW) for each AC access? >> >> [Sam] Yes. >> >> >> >> Thanks, >> >> >> >> Sam >> >> >> >> >> >> >> >> >> > >> >> >> This E-mail and any of its attachments may contain Time Warner Cable >> proprietary information, which is privileged, confidential, or subject >> to copyright belonging to Time Warner Cable. This E-mail is intended >> solely for the use of the individual or entity to which it is >> addressed. If you are not the intended recipient of this E-mail, you >> are hereby notified that any dissemination, distribution, copying, or >> action taken in relation to the contents of and attachments to this E- >> mail is strictly prohibited and may be unlawful. If you have received >> this 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 linda.dunbar@huawei.com Wed May 16 15:29: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 752EA11E8080; Wed, 16 May 2012 15:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.402 X-Spam-Level: X-Spam-Status: No, score=-4.402 tagged_above=-999 required=5 tests=[AWL=2.197, 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 5ezjMRyz5r5h; Wed, 16 May 2012 15:29:58 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 66D4D11E8072; Wed, 16 May 2012 15:29:58 -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 AFZ41883; Wed, 16 May 2012 18:29:58 -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, 16 May 2012 15:26:40 -0700 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.003; Wed, 16 May 2012 15:26:37 -0700 From: Linda Dunbar To: AshwoodsmithPeter , Murari Sridharan , "robert@raszuk.net" , Keshava A K Subject: RE: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version Notification for draft-xu-mpls-in-udp-00.txt Thread-Topic: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version Notification for draft-xu-mpls-in-udp-00.txt Thread-Index: AQHNMt2t4REqtqrRU0qCXQhYIdzhqZbM/g0g Date: Wed, 16 May 2012 22:26:36 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F633933704@dfweml506-mbx> References: <7AE6A4247B044C4ABE0A5B6BF427F8E2012DE3C3@dfweml513-mbx.china.huawei.com> In-Reply-To: <7AE6A4247B044C4ABE0A5B6BF427F8E2012DE3C3@dfweml513-mbx.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.192.11.156] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l2vpn@ietf.org" , "nvo3@ietf.org" , "l3vpn@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, 16 May 2012 22:29:59 -0000 Peter,=20 You are absolutely right. I am saying the same thing, i.e. the OverlayBouna= ryPoint has multiple addresses. So that some VMs can be encapsulated in one= SR/DST address and other VMs can be encapsulated with other addresses.=20 I agree with Murari that focusing on entropy values is too narrow. You can = have all the entropy values, but you still will run into in-balanced distri= bution because flow of each VM is different.=20 =20 I have noticed that VMware (in their document) and Microsoft tend to use "h= ost" to indicate "Server" which can support multiple VMs. V.s. in other env= ironment "Host" is referring to "End-Station".=20 Linda > -----Original Message----- > From: AshwoodsmithPeter > Sent: Tuesday, May 15, 2012 4:00 PM > To: Murari Sridharan; Linda Dunbar; robert@raszuk.net; Keshava A K > Cc: l2vpn@ietf.org; nvo3@ietf.org; l3vpn@ietf.org > Subject: RE: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN > traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version > Notification for draft-xu-mpls-in-udp-00.txt >=20 >=20 > Linda, just to clarify, its not the ultimate host addresses (VM) that > need to be multiple, it's the Hyperisor/Vswitch that needs multiple IP > addresses. The hash is on this *outer* IP address and is of course > limited because there are insufficient outer addresses for good entropy. >=20 > You'd use a single IP address for the VM/host but then when > encapsulating you'd pick one of say 32 or more Vswitch addresses for > your SA based on your VM IPs and the UDP/TCP ports. Everywhere there > was a dependency on /32 would have to be made flexible. Not sure if > that's an issue but its possibly hard coded in some places. Routers ARP > table for example? >=20 > The number of outer addresses you use dictates how much entropy you get > when you traverse a LAG which can have quite a few members, but 16 or > 32 is likely not unreasonable. Also if you go through several hops, the > number of bits of entropy puts a strict upper bound on the total number > of different paths you can exercise. So if you have 4 bits you can only > exercise 16 unique paths *end to end*. Since the number of paths grows > exponentially in the path length a small number of bits does limit > spead exponentially quickly. >=20 > This 'trick' is only needed of course if the LAG or ECMP hardware does > not know to look at an NVGRE header or is not capable of generic hash > extensions which some ASICs now can do... (even if they don't support > NVGRE termination/encapsulation) so its likely more a concern between > DC's than inside the DC. >=20 > Peter >=20 > -----Original Message----- > From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf Of > Murari Sridharan > Sent: Tuesday, May 15, 2012 4:29 PM > To: Murari Sridharan; Linda Dunbar; robert@raszuk.net; Keshava A K > Cc: l2vpn@ietf.org; nvo3@ietf.org; l3vpn@ietf.org > Subject: Re: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN > traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version > Notification for draft-xu-mpls-in-udp-00.txt >=20 > Linda, to clarify the address "assignment" could be setup as a SLAAC > and hosts can generate address from a given prefix etc. >=20 > -----Original Message----- > From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf Of > Murari Sridharan > Sent: Tuesday, May 15, 2012 1:12 PM > To: Linda Dunbar; robert@raszuk.net; Keshava A K > Cc: l2vpn@ietf.org; nvo3@ietf.org; l3vpn@ietf.org > Subject: Re: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN > traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version > Notification for draft-xu-mpls-in-udp-00.txt >=20 > Whichever entity assigns IP addresses to the host can assign one or > many including 1:1 for every VM in that host. This isn't specific to > IPv6 or IPv4. >=20 > On a general note, devices/appliances etc that want to participate in > NV03 will likely want to understand specific tenant information to > provide richer services. No matter what the encapsulation format is > devices/appliances will need to update if they want to do something > interesting with the flow. I have seen several threads where folks seem > to have a "let's keep switch-ECMP" view of the DC which I think is > narrow. >=20 > Thanks > Murari >=20 > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Linda Dunbar > Sent: Tuesday, May 15, 2012 12:41 PM > To: robert@raszuk.net; Keshava A K > Cc: l2vpn@ietf.org; nvo3@ietf.org; l3vpn@ietf.org > Subject: RE: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN > traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version > Notification for draft-xu-mpls-in-udp-00.txt >=20 > Robert, >=20 > When GRE encapsulation uses different SRC/DST addresses for different > flows, it means that same OverlayBoundaryPoint needs multiple addresses. > Does it also mean an IP prefix can be given to a OverlayBoundaryPoint? > I guess for IPv6, there shouldn't be any issues, should it? (well I am > not an IPv6 expert). >=20 > Linda >=20 > > -----Original Message----- > > From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf > > Of Robert Raszuk > > Sent: Wednesday, May 09, 2012 2:27 AM > > To: Keshava A K > > Cc: l2vpn@ietf.org; Xuxiaohu; nvo3@ietf.org; l3vpn@ietf.org > > Subject: Re: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN > > traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New > Version > > Notification for draft-xu-mpls-in-udp-00.txt > > > > > > > If switches were to try to distribute GRE flows between two VTEPs > > > that used a GRE encapsulation, all the traffic would be directed to > > > use only one link within these Port Channels. > > > > Not true. GRE encapsulation is not mandated to use the same src/dst > > addresses for all flows between given two end points. > > > > You do not need to parse deep into packet to enable good load > > balancing hash across parallel links when you use GRE as an > > encapsulation technology. > > > > And what is nice about IP encapsulation all GRE src/dst addresses can > > be naturally aggregated so from IGP point of view they still look > like > > a single prefix. > > > > Regards, > > R. > > _______________________________________________ > > nvo3 mailing list > > nvo3@ietf.org > > https://www.ietf.org/mailman/listinfo/nvo3 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 From florin.balus@alcatel-lucent.com Wed May 16 15:56: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 6038D21F871A for ; Wed, 16 May 2012 15:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.516 X-Spam-Level: X-Spam-Status: No, score=-7.516 tagged_above=-999 required=5 tests=[AWL=-1.517, BAYES_00=-2.599, J_CHICKENPOX_23=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 6R22BsSzS2fx for ; Wed, 16 May 2012 15:56:52 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 375DB21F86FD for ; Wed, 16 May 2012 15:56:52 -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 q4GMuiVR000118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 May 2012 17:56:45 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q4GMuh9F032256 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 16 May 2012 17:56:43 -0500 Received: from USNAVSXCHMBSC3.ndc.alcatel-lucent.com ([135.3.39.144]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Wed, 16 May 2012 17:56:43 -0500 From: "Balus, Florin Stelian (Florin)" To: "Rogers, Josh" , Jiangyuanlong , Daniel Cohn , Sam Cao , Alexander Vainshtein Date: Wed, 16 May 2012 17:56:42 -0500 Subject: RE: Discussion on forwarding performance - 2VLAN Thread-Topic: Discussion on forwarding performance - 2VLAN Thread-Index: Ac0zn8bVPxT1+7IJRdCqCy41OyiiFAAFhViQ Message-ID: <2073A6C5467C99478898544C6EBA3F4602C19078AB@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> References: <2073A6C5467C99478898544C6EBA3F4602C19077F0@USNAVSXCHMBSC3.ndc.alcatel-lucent.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="iso-8859-2" 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.12 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, 16 May 2012 22:56:54 -0000 In my opinion both options are at the end of the day implementable. The VLA= N one addresses more use cases/is consistent across native Ethernet and MPL= S domains. The amount of effort is implementation dependent. > -----Original Message----- > From: Rogers, Josh [mailto:josh.rogers@twcable.com] > Sent: Wednesday, May 16, 2012 1:09 PM > To: Balus, Florin Stelian (Florin); Jiangyuanlong; Daniel Cohn; Sam > Cao; Alexander Vainshtein > Cc: l2vpn@ietf.org > Subject: Re: Discussion on forwarding performance - 2VLAN > > Florin, thanks for the explanation. > > Today, bridge (on a PE) expects to/from all endpoints in the domain. > Will any particular effort in implementation have to be made to tie > together appropriate AC's with appropriate PW's? > > This question should apply to both the 2VLAN and MultiPW methods, as > both seem to rely on these source-dependant (as opposed to the > destination based forwarding rules based on DST MAC only) > > > > On 5/16/12 2:52 PM, "Balus, Florin Stelian (Florin)" > wrote: > > >As soon as the packet is received on the ingress PE the ingress card > >(e.g. service manager) will know on what kind of entry point it > arrived: > >i.e. whether it is a leaf or a root. Then right there it could make a > >decision whether it goes out on a PW or not. The SVLAN indication is > >really for the next PE in the chain. > > > >> -----Original Message----- > >> From: Rogers, Josh [mailto:josh.rogers@twcable.com] > >> Sent: Wednesday, May 16, 2012 12:42 PM > >> To: Jiangyuanlong; Daniel Cohn; Balus, Florin Stelian (Florin); Sam > >> Cao; Alexander Vainshtein > >> Cc: l2vpn@ietf.org > >> Subject: Re: Discussion on forwarding performance - 2VLAN > >> > >> Yuanlong, I agree with your statement/assessment of where lookups > >> occur to decide how to forward (egress PE), however=A9 If > optimization > >> is done to prevent the frame from being forwarded to PE's that have > >> no AC's of the appropriate type, then there has to some sort of > >> mapping between the ingress AC and the appropriate PW. Earlier I > >> assumed that this mapping would be done by looking at the S-VLAN > that > >> would be applied on the ingress PE physical interface. In the case > >> of optimization being used, you'd see lookup of S-VLAN on both > >> ingress and egress PE's, right? If not, how is the mapping between > >> ingress AC and appropriate PW's done? > >> > >> > >> > >> On 5/16/12 5:04 AM, "Jiangyuanlong" > wrote: > >> > >> >Daniel, > >> > > >> >I don't think we need to look up the VLAN and PW at the same time > >> >for > >> >Dual-VLAN: > >> >On the ingress PE, VLAN is firstly appended or translated for a > >> >incoming Ethernet frame from AC, then MAC forwarded in VSI to one > or > >> >multiple logical ports each corresponding to a PW (the VLAN mapping > >> may > >> >be processed on a logical port), finally a PW label is appended and > >> >transported over the corresponding PW. > >> >On the egress PE, PW is popped and used to indicate a VSI (also > >> >corresponding to a logical port, where the VLAN mapping may also be > >> >processed), then MAC forwarded in VSI to one or multiple ports each > >> >corresponding to an AC (where a frame with a leaf VLAN will be > >> >dropped upon a leaf AC, actually, it is also a simple VLAN > >> >translation in > >> IEEE, > >> >that is, from leaf VLAN to 0xFFF, and all frames with this VLAN > will > >> be > >> >dropped). > >> > > >> >Therefore, double lookup of VLAN and PW seems unnecessary or even > >> >impossible for this service IMHO. > >> > > >> >Regards, > >> >Yuanlong > >> > > >> >-----Original Message----- > >> >From: Daniel Cohn [mailto:DanielC@orckit.com] > >> >Sent: Wednesday, May 16, 2012 4:49 PM > >> >To: Jiangyuanlong; Balus, Florin Stelian (Florin); Sam Cao; > >> >Alexander Vainshtein > >> >Cc: l2vpn@ietf.org > >> >Subject: RE: Discussion on forwarding performance > >> > > >> >VC ID is another name for PW label, right. > >> > ;-) > >> >From conversations with chip vendors, I understood that when > >> >multiple lookups are required (as in the dual-VLAN example, you > need > >> >to lookup PW label to identify E-Tree instance and then VLAN ID to > >> >identify root/leaf origin), typically a single lookup is performed > >> >on ingress with a composite search key (in this case, including PW > >> >label and VLAN > >> ID). > >> >/ ;-) > >> >But perhaps we are getting too much into implementation here. It > >> >would be better if neutral NP and ASIC-based solution vendors could > >> >analyze both solutions and confirm impact on performance and > >> >scalability - and BTW, we also need input regarding existing > silicon > >> >that doesn't > >> support > >> >VLAN mapping. > >> > > >> >DC > >> > > >> >-----Original Message----- > >> >From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > >> >Sent: Wednesday, May 16, 2012 9:43 AM > >> >To: Daniel Cohn; Balus, Florin Stelian (Florin); Sam Cao; Alexander > >> >Vainshtein > >> >Cc: l2vpn@ietf.org > >> >Subject: RE: Discussion on forwarding performance > >> > > >> >Daniel, > >> > > >> >Not sure I fully understand what you mean by "VLAN and VCID lookups > >> are > >> >performed simultaneously on ingress", do you mean VLAN and PW? > >> >Can you give more details on this requirement? > >> > > >> >Regards, > >> >Yuanlong > >> > > >> > > >> >-----Original Message----- > >> >From: Daniel Cohn [mailto:DanielC@orckit.com] > >> >Sent: Wednesday, May 16, 2012 2:16 PM > >> >To: Balus, Florin Stelian (Florin); Sam Cao; Jiangyuanlong; > >> >Alexander Vainshtein > >> >Cc: l2vpn@ietf.org > >> >Subject: RE: Discussion on forwarding performance > >> > > >> >Hi, > >> > > >> >I agree that for a chip-based solution there should be no > difference > >> in > >> >performance for the additional lookup. However from conversations > >> >with chip vendors, I understood there might be an impact on > >> >scalability because the double lookup would require a longer search > >> >key (assuming VLAN and VCID lookups are performed simultaneously on > >> >ingress), thus taking up more TCAM resources per E-Tree instance. > >> >This would depend > >> on > >> >specific TCAM implementation (e.g. granularity of search key > length). > >> > > >> >DC > >> > > >> >-----Original Message----- > >> >From: Balus, Florin Stelian (Florin) > >> >[mailto:florin.balus@alcatel-lucent.com] > >> >Sent: Tuesday, May 15, 2012 10:53 PM > >> >To: Sam Cao; 'Jiangyuanlong'; Daniel Cohn; 'Alexander Vainshtein' > >> >Cc: l2vpn@ietf.org > >> >Subject: RE: Discussion on forwarding performance > >> > > >> >Sam, > >> > > >> >> Obviously the forwarding performance of Dual-VLAN will be much > >> >> lower > >> >than what of Multi-PW. > >> > > >> >Sorry I could not keep up with some of the threads on this subject > >> >but the above statement caught my eyes. We have been doing all kind > >> >of egress operations on VLANs in the egress PE for the last 8 years > >> >and I am not aware of any "much lower" forwarding performance. As > >> >far as I know the chipsets used in the PEs can do this processing > no problem. > >> Do > >> >you want to clarify which kind of hardware may have problems? > >> > > >> >> -----Original Message----- > >> >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > >> >> Behalf Of Sam Cao > >> >> Sent: Tuesday, May 15, 2012 6:32 AM > >> >> To: 'Jiangyuanlong'; 'Daniel Cohn'; 'Alexander Vainshtein' > >> >> Cc: l2vpn@ietf.org > >> >> Subject: RE: Discussion on forwarding performance > >> >> > >> >> Hi Yuanlong, > >> >> > >> >> 3rd mapping will make data plane complex, I think. Anyway, we > >> reached > >> >a > >> >> consensus on Multi-PW implementation. > >> >> > >> >> If we use 3rd mapping, I agree with your opinion, maybe dual-VLAN > >> >seems > >> >> simple, but 2 mapping is enough. Then we can focus on data plane > >> >> performance. While stripe PW label out on egress PE, data-plane > >> knows > >> >> how to forward the frames from PW, to Root AC or Leaf AC or all. > >> >> But > >> >if > >> >> we use Dual-VLAN, after strip PW label out, data plane should > >> >> strip VLAN-ID out and then does same forwarding work as Multi-PW > >> >> does. The most important is, do one more operation while > >> >> forwarding E-Tree frames. Obviously the forwarding performance of > >> >> Dual-VLAN will be much lower than what of Multi-PW. > >> >> > >> >> Regards, > >> >> > >> >> Yuqun (Sam) Cao > >> >> E-mail: Yuqun.cao@gmail.com > >> >> > >> >> -----Original Message----- > >> >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > >> >> Sent: Tuesday, May 15, 2012 7:03 PM > >> >> To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > >> >> Cc: l2vpn@ietf.org > >> >> Subject: RE: Discussion on E-Tree and H-VPLS > >> >> > >> >> See my further comments in line. > >> >> > >> >> -----Original Message----- > >> >> From: Sam Cao [mailto:yuqun.cao@gmail.com] > >> >> Sent: Tuesday, May 15, 2012 6:14 PM > >> >> To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' > >> >> Cc: l2vpn@ietf.org > >> >> Subject: RE: Discussion on E-Tree and H-VPLS > >> >> > >> >> Hi Yuanlong, > >> >> > >> >> Thank you very much for your comments. I draw the topology you > >> >> gave, and 7 PWs will be established if we follow 01. > >> >> > >> >> Root AC ---- PE 1 ----- PW 1 -------- PE 2 ----- Leaf _AC > >> >> | \ / || > >> >> | \ /=3D=3D=3DPW 6,7=3D=3D=3D || > >> >> PW 2 -----PW 5------\ || > >> >> | /----Root PW 3 --- \ || > >> >> Root _AC ---- PE 3 PE 4 ------ Root AC > >> >> | \ / | > >> >> | ----Leaf PW 4----- | > >> >> Leaf AC Leaf AC > >> >> Yes, on PE 3 there are several PWs, but if you want to clarify > it, > >> >> there are only 3 types, one can carry frames originated from Root > >> and > >> >> Leaf AC(one endpoint of this PW should be Root-only, otherwise > >> >> this is invalid), one only can carry frames from Root AC, and the > >> >> last > >> can > >> >> carry frames from Leaf ACs. On second thoughts, we still can > >> classify > >> >> the PWs into 2 sets, one is Leaf set, and another is Root set, > and > >> >> the union of the sets Leaf and Root is the PW we called it as > >> >> compatible > >> >PW > >> >> (Maybe this is not correct, we can find one good term on this). > >> >> > >> >> So this optimization still follows the original design of Dual-PW > >> >> approach, Leaf PW only carries frames from Leaf AC; Root-PW only > >> >> carries frames from Root AC. Is it right? > >> >> > >> >> I don't know whether chip can support this forwarding behavior > for > >> >> compatible PW or not, but if we implement it in NP, it is nearly > >> same > >> >> as VPLS. The only difference is, setup 2 mappings, one between > >> >Leaf-ACs > >> >> and Leaf-PWs, one between Root-ACs and Root-PWs. For traditional > >> >> VPLS, there is only one mapping. > >> >> > >> >> [JY] It seems you may need a 3rd mapping: from both root & leaf > AC > >> to > >> >a > >> >> compatible PW. > >> >> BTW, for the forwarding and reverse direction, the mapping may be > >> >> asymmetric for you compatible PW. > >> >> > >> >> Based on my understanding, all drafts should have similar > mapping. > >> >> > >> >> [JY] Dual-VLAN seems simpler here. > >> >> > >> >> Thanks, > >> >> > >> >> Sam > >> >> > >> >> > >> >> -----Original Message----- > >> >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > >> >> Sent: Tuesday, May 15, 2012 3:32 PM > >> >> To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > >> >> Cc: l2vpn@ietf.org > >> >> Subject: RE: Discussion on E-Tree and H-VPLS > >> >> > >> >> Sam, > >> >> > >> >> Thanks, please see my further comments with [JY]. > >> >> > >> >> Ok, we go on the case in your mail, where PE1 has one Root-only > >> >> AC, AC1, and > >> >> PE2 has one Leaf-only AC, AC2. In general we can setup 2 > >> >> "unidirectional" > >> >> PWs (bidirectional PW, but just carry unidirectional frames), > >> >> Root- > >> PW > >> >> which carries frames originated from AC1 and Leaf-PW which > carries > >> >> frames originated from AC2. But only one PW also can work, just > as > >> >some > >> >> members commented. Ok, we setup one PW between PE1 and PE2, we > can > >> >call > >> >> this PW as compatible PW or something else. Frames originated > from > >> >Root > >> >> or leaf ACs will be carried via this PW. Its forwarding behavior > >> >> is fully same as what traditional VPLS did, MAC learning on AC or > >> >> PW in one E-Tree. Or say, if one PE has Root-only ACs, it will > >> >> setup one > >> PW > >> >> with another PE, Root-only, Leaf-only or Root-Leaf-Mixed. If 2 > PEs > >> >> are root-Leaf-Mixed or other cases, then 2 PWs will be > established. > >> >> As you know, this can be done on control plane. > >> >> > >> >> [JY] Assume there are 2 other nodes PE3 & PE4 in this network > >> >scenario, > >> >> and both PE3 and PE4 have both root and leaf ACs, then there are > >> >> compatible PWs from PE3 which may carry both root and leaf > traffic > >> >> (to PE1), which may carry only root traffic (to PE2); and further > >> >> there > >> >are > >> >> root PW and leaf PW to PE4. Thus, the VSI on PE3 has at least 4 > >> >> different types of PW transmitting behaviours with regard to the > >> >E-Tree > >> >> traffic. In the reverse direction, the VSI on PE3 further has at > >> >> least > >> >> 4 different types of PW receiving behaviours. Not sure how you > >> >> will accommodate for these PWs in both the data plane and control > plane. > >> >> > >> >> Regards, > >> >> Yuanlong > >> >> > >> >> Is this clear for you? Is this necessary to optimize PW setup in > >> this > >> >> case? > >> >> > >> >> Maybe we need to add one paragraph on forwarding behavior. > >> >> > >> >> Again thank you very much for your comments, > >> >> > >> >> Sam > >> >> > >> >> -----Original Message----- > >> >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > >> >> Sent: Tuesday, May 15, 2012 10:27 AM > >> >> To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > >> >> Cc: l2vpn@ietf.org > >> >> Subject: RE: Discussion on E-Tree and H-VPLS > >> >> > >> >> Please see my comments in line. > >> >> > >> >> -----Original Message----- > >> >> From: Sam Cao [mailto:yuqun.cao@gmail.com] > >> >> Sent: Monday, May 14, 2012 8:31 PM > >> >> To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' > >> >> Cc: l2vpn@ietf.org > >> >> Subject: RE: Discussion on E-Tree and H-VPLS > >> >> > >> >> Hi Yuanlong, > >> >> > >> >> We have discussed this in another thread. In fact, Daniel or I > >> >> have given the answers to the questions you raised here for > >> >> several time > >> >:). > >> >> If we do in this way, we will reach deadlock and can not move > >> forward > >> >> :). I try to explain it again. > >> >> > >> >> [JY] I will apologize if you had ever provided such answers > >> >> before, > >> >and > >> >> you may just refer to the links rather than repeat the > explanation. > >> >> As you can see, I just try to understand the mechanism of 2PW and > >> its > >> >> implications, but the I-D does not include enough information. > >> >> > >> >> As you know, initial design we will setup 2 PWs all the time (if > >> >> do in this way, I think that you have no question), > >> >> > >> >> [JY] I will be concerned with the operational complexity of this > >> >> approach. > >> >> > >> >> but in most cases 2 PWs are not > >> >> necessary. So in 01 version, we optimize it. > >> >> > >> >> "Root-only VSI <-> any VSI: only root PW required" > >> >> "Leaf-only VSI <-> leaf-only VSI: no PWs required" > >> >> > >> >> In other cases 2 PWs are needed. If so, "Leaf-only -> root-only =3D > >> one > >> >> leaf PW" is not correct: On Leaf-only side, yes, one Leaf-only PW > >> >> is created between Local Leaf type with remote Root type; on > >> >> root-only side, one root-only PW is created. Maybe it is better > to > >> >> call this > >> as > >> >> compatible or mixed PW. So the left items you list are not > correct > >> >> for multi_PW solution. > >> >> > >> >> [JY] This is something new, right? To be honest, I could not > >> >understand > >> >> what is your point: doesn't the mixed PW as you called also > >> >> consist of one Leaf-only PW in one direction and one root-only PW > >> >> in the other direction? > >> >> Furthermore, the case you took is also one case in your guideline > >> >> "Root-only VSI <-> any VSI: only root PW required", don't you > >> >> think that only one root PW is required following this guideline? > >> >> Actually, I don't care much about what is the bidirectional PW or > >> >> unidirectional PW called, but how can a VSI support such a mixed > >> >> scenarios: > >> >> traditional VSI assumes only one PW is required for each peer > VSI, > >> >> and its MAC leaning is based on bidirectional PW. But for 2PW, > >> >> there are bidirectional root PW, bidirectional leaf PW, mixed PW, > >> >> etc..., how to support these kinds of PWs in the same VSI is my > top concern. > >> >> > >> >> BTW, I guess you also care this case we also have discussed > before: > >> >for > >> >> example, if we configure one Leaf AC on root-only PE (then it > will > >> be > >> >> root-leaf-mixed PE), we will teardown the compatible PW and > >> >> re-setup PWs again with 01. > >> >> [JY] This was discussed in the emails indeed. > >> >> > >> >> Regards, > >> >> > >> >> Yuqun (Sam) Cao > >> >> E-mail: Yuqun.cao@gmail.com > >> >> > >> >> -----Original Message----- > >> >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > >> >> Sent: Monday, May 14, 2012 7:10 PM > >> >> To: Daniel Cohn; Alexander Vainshtein; Sam Cao > >> >> Cc: l2vpn@ietf.org > >> >> Subject: RE: Discussion on E-Tree and H-VPLS > >> >> > >> >> Hi Daniel, > >> >> > >> >> Fine, now it seems more in line with what we had proposed in > 2VLAN: > >> a > >> >> spoke PW behaves like root/leaf AC for a PE-r. > >> >> > >> >> But the same problem may also apply to the root/spoke "core PW" > >> >> for > >> >> Multi-PW: > >> >> According to Multi-PW, only one PW is required between two PEs > >> except > >> >> when both PEs are mixed with root and leaf, so these PWs may be > >> >> formed by combinations of the following unidirectional PW cases > >> >> (extracted > >> >and > >> >> adapted from Josh's email): > >> >> Root-only -> any VSI =3D one root PW Leaf-only -> root-only =3D one > >> >> leaf PW Leaf-only -> mixed =3D one leaf PW Mixed -> root-only =3D o= ne > >> >> (root+leaf) PW Mixed -> leaf-only =3D one > >> >> (root+leaf) PW > >> >> > >> >> I have a concern that the forwarding plane of PE to implement > this > >> >will > >> >> be very different from the traditional VPLS. > >> >> > >> >> Regards, > >> >> Yuanlong > >> >> > >> >> -----Original Message----- > >> >> From: Daniel Cohn [mailto:DanielC@orckit.com] > >> >> Sent: Monday, May 14, 2012 5:00 PM > >> >> To: Jiangyuanlong; Alexander Vainshtein; Sam Cao > >> >> Cc: l2vpn@ietf.org > >> >> Subject: RE: Discussion on E-Tree and H-VPLS > >> >> > >> >> Hi Yuanlong, > >> >> > >> >> Like I wrote below, root/leaf spoke PW behave like root/leaf AC, > >> >> not like root/spoke "core PW". So no changes to forwarding plane > >> >> once this is understood. > >> >> > >> >> DC > >> >> > >> >> -----Original Message----- > >> >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > >> >> Sent: Monday, May 14, 2012 11:36 AM > >> >> To: Daniel Cohn; Alexander Vainshtein; Sam Cao > >> >> Cc: l2vpn@ietf.org > >> >> Subject: RE: Discussion on E-Tree and H-VPLS > >> >> > >> >> Daniel, please see my comments in line. > >> >> > >> >> -----Original Message----- > >> >> From: Daniel Cohn [mailto:DanielC@orckit.com] > >> >> Sent: Monday, May 14, 2012 3:37 PM > >> >> To: Jiangyuanlong; Alexander Vainshtein; Sam Cao > >> >> Cc: l2vpn@ietf.org > >> >> Subject: RE: Discussion on E-Tree and H-VPLS > >> >> > >> >> Hi Yuanlong, > >> >> > >> >> As I see it, for the PE-r spoke (figure 4 in RFC 4762) we > >> >> establish > >> a > >> >> single PW per AC - root PW for root AC and leaf PW for leaf AC. > >> >> With local configuration at the PE-rs as part of the spoke PW > >> provisioning. > >> >> And the PE-rs will treat root/leaf spoke PWs exactly as it treat > >> >> root/leaf ACs. So when leaf-originated BUM traffic arrives from > >> >> the core (over a leaf PW), it will be forwarded over all root > >> >> spoke PWs > >> >but > >> >> not on the leaf spoke PWs. > >> >> > >> >> [JY] So in the reverse direction, you need to transport both root > >> and > >> >> leaf traffic from PE-rs over a root PW to PE-r, and transport > root > >> >> traffic over a leaf PW. It seems against the definition of root > PW > >> >> and leaf PW in the multi-PW draft. Don't this make the forwarding > >> >> plane of PE-rs more complex? > >> >> > >> >> The forwarding plane is exactly the same as described in the > >> >> multi- > >> PW > >> >> draft, where spoke PWs are treated exactly like ACs. > >> >> > >> >> Regards, > >> >> > >> >> Daniel > >> >> > >> >> > >> >> -----Original Message----- > >> >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > >> >> Sent: Friday, May 11, 2012 5:03 AM > >> >> To: Daniel Cohn; Alexander Vainshtein; Sam Cao > >> >> Cc: l2vpn@ietf.org > >> >> Subject: RE: Discussion on E-Tree and H-VPLS > >> >> > >> >> Hi Daniel and all, > >> >> > >> >> When you set up two PWs from the PE-rs to a PE-r for each of its > >> >> AC, > >> >do > >> >> you mean that one PW is bidirectional root PW and the other is > >> >> bidirectional leaf PW? > >> >> My concern is: where should the leaf traffic be filtered, on the > >> >> PE-rs or on the PE-r? > >> >> If filtered on the PE-r, then lots of bandwidth will be wasted > >> >> (for example, if the PE-r is attached with 9 leafs, then the BUM > >> >> traffic from one of its leafs will be multiplied by 8 times, and > >> >> be > >> forwarded > >> >> by the PE-rs to the same PE-r). > >> >> If filtered on the PE-rs, not sure how you will design its > >> forwarding > >> >> plane, can you give a hint? > >> >> > >> >> Thanks, > >> >> Yuanlong > >> >> > >> >> ------------------------------ > >> >> Date: Wed, 9 May 2012 09:16:36 +0300 > >> >> From: "Daniel Cohn" > >> >> To: "Alexander Vainshtein" , > >> >"Sam > >> >> Cao" , > >> >> Cc: lizhong.jin@zte.com.cn > >> >> Subject: RE: Discussion on E-Tree and H-VPLS > >> >> Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780CBA6@tlvmail1> > >> >> Content-Type: text/plain; charset=3D"ISO-2022-JP" > >> >> > >> >> Hi Sasha, > >> >> > >> >> It's actually very simple. A frame that originated in a root AC > is > >> >> always transmitted only in root PW, no matter what the frame type > >> >> (known/unknown unicast or broadcast). This is how the frame > source > >> >> information is propagated across the VPLS. So in the H-VPLS > >> >> example, the PE-r will never forward a frame received over a root > >> >> PW on any > >> >leaf > >> >> PW, only on root PWs (toward the core or toward other spokes). > >> >> > >> >> Hope this clarifies it, regards, > >> >> > >> >> Daniel > >> >> > >> >> -----Original Message----- > >> >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > >> >> Behalf Of Alexander Vainshtein > >> >> Sent: Wednesday, May 09, 2012 7:59 AM > >> >> To: Sam Cao; l2vpn@ietf.org > >> >> Cc: lizhong.jin@zte.com.cn > >> >> Subject: RE: Discussion on E-Tree and H-VPLS > >> >> > >> >> Sam, Lizhong and all, > >> >> You've written that in the two-PW solution combined with H-VPLS > >> >> the > >> >PE- > >> >> r must set up two PWs with each MTU-s. > >> >> > >> >> If this is the case, what kind of forwarding logic should be used > >> >> to prevent sending a BUM frame received from a root-PW to a given > >> >> MTU- > >> S: > >> >> - back to the same MTU-S on the corresponding leaf-PW? > >> >> - twice (to both root-PW and Leaf-PW) to another MTU-s? And, BTW, > >> how > >> >> is the PW selected in this case? > >> >> > >> >> I am aware of a technique of multiple split horizon groups in PE- > r > >> >> which could be possibly used for this purpose. However, since > >> >> these groups have to be represented explicitly in the data plane, > >> >> their potential number is limited by the forwarding HW. Other > >> >> methods > >> could > >> >> be probably used for the same purpose, but they would probably > >> >> subject to similar HW-based limitations. > >> >> > >> >> I suspect that with the dual-PW approach, the HW would pose an > >> >implicit > >> >> limit, say, on a number of MTU-s that can be connected to the > same > >> >PE-r > >> >> and that this limit could be quite low in most cases. > >> >> > >> >> Based on this I suspect that the H-VPLS issue as a critical > >> >> drawback > >> >of > >> >> the dual-PW approach to E-Tree. > >> >> > >> >> My 2c, > >> >> Sasha > >> >> > >> >> > >> >> ________________________________________ > >> >> From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf > of > >> >> Sam Cao [yuqun.cao@gmail.com] > >> >> Sent: Wednesday, May 09, 2012 3:40 AM > >> >> To: l2vpn@ietf.org > >> >> Cc: lizhong.jin@zte.com.cn > >> >> Subject: RE: Discussion on E-Tree and H-VPLS > >> >> > >> >> Hi Lizhong? > >> >> > >> >> Thank you very much for your comments. I updated the result on > >> >> this question. > >> >> > >> >> [Lizhong] agree with the above analysis. And we did not say it is > >> >> a technical problem, but it is an operational problem again. > >> >> [Sam] I agree. Dual-VLAN does not make sense. I also discussed > >> >> this with Giles and Yuanlong in another mail, and we reached > >> >> agreement on > >> >> this: > >> >> MTU should know the access mode, VPWS or VPLS, VPWS mode should > >> >> configure VLAN ID on MTU but VPLS mode can not. I thought this is > >> NOT > >> >> reasonable :), but we can figure this out in draft. It seems ok. > >> >> > >> >> [Lizhong] not fully understand. Do you mean, when VPWS accessing > >> for > >> >> H-VPLS, the PE-r is also necessary to configure two PWs (root and > >> >> leaf > >> >> PW) for each AC access? > >> >> [Sam] Yes. > >> >> > >> >> Thanks, > >> >> > >> >> Sam > >> >> > >> >> > >> >> > >> >> > >> > > >> > >> > >> This E-mail and any of its attachments may contain Time Warner Cable > >> proprietary information, which is privileged, confidential, or > >> subject to copyright belonging to Time Warner Cable. This E-mail is > >> intended solely for the use of the individual or entity to which it > >> is addressed. If you are not the intended recipient of this E-mail, > >> you are hereby notified that any dissemination, distribution, > >> copying, or action taken in relation to the contents of and > >> attachments to this E- mail is strictly prohibited and may be > >> unlawful. If you have received this 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 jiangyuanlong@huawei.com Wed May 16 19:01: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 C691E11E8091 for ; Wed, 16 May 2012 19:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[AWL=1.688, BAYES_00=-2.599, J_CHICKENPOX_23=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 G73diajnha7x for ; Wed, 16 May 2012 19:01:25 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id CF32411E8073 for ; Wed, 16 May 2012 19:01: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 AGG49951; Wed, 16 May 2012 22:01:24 -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, 16 May 2012 18:59:21 -0700 Received: from SZXEML427-HUB.china.huawei.com (10.72.61.35) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 16 May 2012 18:59:25 -0700 Received: from SZXEML546-MBS.china.huawei.com ([169.254.4.75]) by szxeml427-hub.china.huawei.com ([10.72.61.35]) with mapi id 14.01.0323.003; Thu, 17 May 2012 09:59:19 +0800 From: Jiangyuanlong To: Daniel Cohn , "Balus, Florin Stelian (Florin)" , Sam Cao , Alexander Vainshtein Subject: RE: Discussion on forwarding performance Thread-Topic: Discussion on forwarding performance Thread-Index: AQHNMp8ego9/CtMoakapN2JoMtGUPZbKvTGAgACuOgCAAIsAgIAAIx7wgAAPG/CAAA8QAIAA9Seg Date: Thu, 17 May 2012 01:59:18 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413CCB@szxeml546-mbs.china.huawei.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D411694@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF5C@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D4130E1@szxeml546-mbs.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF8F@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413216@szxeml546-mbs.china.huawei.com> <3F1F3739E2B04D399CC7D26CE934F91A@v2comsam> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413694@szxeml546-mbs.china.huawei.com> <7A564821DF1642E592E884D5C623772C@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D41370E@szxeml546-mbs.china.huawei.com> <400D5D93E6AA4075861CE09919D84747@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413741@szxeml546-mbs.china.huawei.com> <7BDA456234D045E1BD42EA059A4E9579@v2comsam> <2073A6C5467C99478898544C6EBA3F4602C1907568@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> <44F4E579A764584EA9BDFD07D0CA08130780D1AB@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413AA8@szxeml546-mbs.china.huawei.com> <4 4F4E579A7 64584EA9BDFD 07D0CA08130780D1FC@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413B06@szxeml546-mbs.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780D224@tlvmail1> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA08130780D224@tlvmail1> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.40.73] 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, 17 May 2012 02:01:26 -0000 I was referring always to the egress PE. In my understanding (going deeper and deeper into implementation) an ASIC-based solution will typically perform PW and VLAN lookup on ingress and as a result of the lookup add internal tags to the frame representing VSI instance and root/leaf attribute. [JY] For an E-Tree, the outmost VLAN in a PW can only have two possible val= ues: either root or leaf VLAN. Thus we don't need TCAM to find the correspo= nding VLAN. Even if TCAM is used, only two TCAM items are needed at most, n= o matter what is the search key length. So I can't see the scalability issu= e in this regards. But now we're going too much into individual implementations so I repeat my comment from the previous e-mail - It would be better if neutral NP and ASIC-based solution vendors could analyze both solutions and confirm impact on performance and scalability - and BTW, we also need input regarding existing silicon that doesn't support VLAN mapping. [JY] In principle, I agree with you. However, a fair analysis is possible o= nly when the data plane of both approaches are fully understood, but I am n= ot sure this is the case for the Multi-PW approach, since both the forwardi= ng plane and OAM, two most important constructs of its data plane, is still= in the dark, please see http://www.ietf.org/mail-archive/web/l2vpn/current= /msg03636.html and http://www.ietf.org/mail-archive/web/l2vpn/current/msg03= 554.html for details.=20 For Dual-VLAN, the forwarding plane is very detailed in draft-jiang-l2vpn-v= pls-pe-etree, and the OAM as described in RFC 6136 will apply with no chang= e. Thanks, Yuanlong DC -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Wednesday, May 16, 2012 1:04 PM To: Daniel Cohn; Balus, Florin Stelian (Florin); Sam Cao; Alexander Vainshtein Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance Daniel, I don't think we need to look up the VLAN and PW at the same time for Dual-VLAN: On the ingress PE, VLAN is firstly appended or translated for a incoming Ethernet frame from AC, then MAC forwarded in VSI to one or multiple logical ports each corresponding to a PW (the VLAN mapping may be processed on a logical port), finally a PW label is appended and transported over the corresponding PW. On the egress PE, PW is popped and used to indicate a VSI (also corresponding to a logical port, where the VLAN mapping may also be processed), then MAC forwarded in VSI to one or multiple ports each corresponding to an AC (where a frame with a leaf VLAN will be dropped upon a leaf AC, actually, it is also a simple VLAN translation in IEEE, that is, from leaf VLAN to 0xFFF, and all frames with this VLAN will be dropped). Therefore, double lookup of VLAN and PW seems unnecessary or even impossible for this service IMHO.=20 Regards, Yuanlong -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Wednesday, May 16, 2012 4:49 PM To: Jiangyuanlong; Balus, Florin Stelian (Florin); Sam Cao; Alexander Vainshtein Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance VC ID is another name for PW label, right. ;-) >From conversations with chip vendors, I understood that when multiple lookups are required (as in the dual-VLAN example, you need to lookup PW label to identify E-Tree instance and then VLAN ID to identify root/leaf origin), typically a single lookup is performed on ingress with a composite search key (in this case, including PW label and VLAN ID).=20 / ;-) But perhaps we are getting too much into implementation here. It would be better if neutral NP and ASIC-based solution vendors could analyze both solutions and confirm impact on performance and scalability - and BTW, we also need input regarding existing silicon that doesn't support VLAN mapping. DC -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Wednesday, May 16, 2012 9:43 AM To: Daniel Cohn; Balus, Florin Stelian (Florin); Sam Cao; Alexander Vainshtein Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance Daniel,=20 Not sure I fully understand what you mean by "VLAN and VCID lookups are performed simultaneously on ingress", do you mean VLAN and PW? Can you give more details on this requirement? Regards, Yuanlong -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Wednesday, May 16, 2012 2:16 PM To: Balus, Florin Stelian (Florin); Sam Cao; Jiangyuanlong; Alexander Vainshtein Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance Hi, I agree that for a chip-based solution there should be no difference in performance for the additional lookup. However from conversations with chip vendors, I understood there might be an impact on scalability because the double lookup would require a longer search key (assuming VLAN and VCID lookups are performed simultaneously on ingress), thus taking up more TCAM resources per E-Tree instance. This would depend on specific TCAM implementation (e.g. granularity of search key length). DC -----Original Message----- From: Balus, Florin Stelian (Florin) [mailto:florin.balus@alcatel-lucent.com]=20 Sent: Tuesday, May 15, 2012 10:53 PM To: Sam Cao; 'Jiangyuanlong'; Daniel Cohn; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance Sam, > Obviously the forwarding performance of Dual-VLAN will be much lower than what of Multi-PW. Sorry I could not keep up with some of the threads on this subject but the above statement caught my eyes. We have been doing all kind of egress operations on VLANs in the egress PE for the last 8 years and I am not aware of any "much lower" forwarding performance. As far as I know the chipsets used in the PEs can do this processing no problem. Do you want to clarify which kind of hardware may have problems? > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Sam Cao > Sent: Tuesday, May 15, 2012 6:32 AM > To: 'Jiangyuanlong'; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on forwarding performance > > Hi Yuanlong, > > 3rd mapping will make data plane complex, I think. Anyway, we reached a > consensus on Multi-PW implementation. > > If we use 3rd mapping, I agree with your opinion, maybe dual-VLAN seems > simple, but 2 mapping is enough. Then we can focus on data plane > performance. While stripe PW label out on egress PE, data-plane knows > how to forward the frames from PW, to Root AC or Leaf AC or all. But if > we use Dual-VLAN, after strip PW label out, data plane should strip > VLAN-ID out and then does same forwarding work as Multi-PW does. The > most important is, do one more operation while forwarding E-Tree > frames. Obviously the forwarding performance of Dual-VLAN will be much > lower than what of Multi-PW. > > Regards, > > Yuqun (Sam) Cao > E-mail: Yuqun.cao@gmail.com > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 7:03 PM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > See my further comments in line. > > -----Original Message----- > From: Sam Cao [mailto:yuqun.cao@gmail.com] > Sent: Tuesday, May 15, 2012 6:14 PM > To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > Thank you very much for your comments. I draw the topology you gave, > and 7 PWs will be established if we follow 01. > > Root AC ---- PE 1 ----- PW 1 -------- PE 2 ----- Leaf _AC > | \ / || > | \ /=3D=3D=3DPW 6,7=3D=3D=3D || > PW 2 -----PW 5------\ || > | /----Root PW 3 --- \ || > Root _AC ---- PE 3 PE 4 ------ Root AC > | \ / | > | ----Leaf PW 4----- | > Leaf AC Leaf AC > Yes, on PE 3 there are several PWs, but if you want to clarify it, > there are only 3 types, one can carry frames originated from Root and > Leaf AC(one endpoint of this PW should be Root-only, otherwise this is > invalid), one only can carry frames from Root AC, and the last can > carry frames from Leaf ACs. On second thoughts, we still can classify > the PWs into 2 sets, one is Leaf set, and another is Root set, and the > union of the sets Leaf and Root is the PW we called it as compatible PW > (Maybe this is not correct, we can find one good term on this). > > So this optimization still follows the original design of Dual-PW > approach, Leaf PW only carries frames from Leaf AC; Root-PW only > carries frames from Root AC. Is it right? > > I don't know whether chip can support this forwarding behavior for > compatible PW or not, but if we implement it in NP, it is nearly same > as VPLS. The only difference is, setup 2 mappings, one between Leaf-ACs > and Leaf-PWs, one between Root-ACs and Root-PWs. For traditional VPLS, > there is only one mapping. > > [JY] It seems you may need a 3rd mapping: from both root & leaf AC to a > compatible PW. > BTW, for the forwarding and reverse direction, the mapping may be > asymmetric for you compatible PW. > > Based on my understanding, all drafts should have similar mapping. > > [JY] Dual-VLAN seems simpler here. > > Thanks, > > Sam > > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 3:32 PM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Sam, > > Thanks, please see my further comments with [JY]. > > Ok, we go on the case in your mail, where PE1 has one Root-only AC, > AC1, and > PE2 has one Leaf-only AC, AC2. In general we can setup 2 > "unidirectional" > PWs (bidirectional PW, but just carry unidirectional frames), Root-PW > which carries frames originated from AC1 and Leaf-PW which carries > frames originated from AC2. But only one PW also can work, just as some > members commented. Ok, we setup one PW between PE1 and PE2, we can call > this PW as compatible PW or something else. Frames originated from Root > or leaf ACs will be carried via this PW. Its forwarding behavior is > fully same as what traditional VPLS did, MAC learning on AC or PW in > one E-Tree. Or say, if one PE has Root-only ACs, it will setup one PW > with another PE, Root-only, Leaf-only or Root-Leaf-Mixed. If 2 PEs are > root-Leaf-Mixed or other cases, then 2 PWs will be established. As you > know, this can be done on control plane. > > [JY] Assume there are 2 other nodes PE3 & PE4 in this network scenario, > and both PE3 and PE4 have both root and leaf ACs, then there are > compatible PWs from PE3 which may carry both root and leaf traffic (to > PE1), which may carry only root traffic (to PE2); and further there are > root PW and leaf PW to PE4. Thus, the VSI on PE3 has at least 4 > different types of PW transmitting behaviours with regard to the E-Tree > traffic. In the reverse direction, the VSI on PE3 further has at least > 4 different types of PW receiving behaviours. Not sure how you will > accommodate for these PWs in both the data plane and control plane. > > Regards, > Yuanlong > > Is this clear for you? Is this necessary to optimize PW setup in this > case? > > Maybe we need to add one paragraph on forwarding behavior. > > Again thank you very much for your comments, > > Sam > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 10:27 AM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Please see my comments in line. > > -----Original Message----- > From: Sam Cao [mailto:yuqun.cao@gmail.com] > Sent: Monday, May 14, 2012 8:31 PM > To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > We have discussed this in another thread. In fact, Daniel or I have > given the answers to the questions you raised here for several time :). > If we do in this way, we will reach deadlock and can not move forward > :). I try to explain it again. > > [JY] I will apologize if you had ever provided such answers before, and > you may just refer to the links rather than repeat the explanation. > As you can see, I just try to understand the mechanism of 2PW and its > implications, but the I-D does not include enough information. > > As you know, initial design we will setup 2 PWs all the time (if do in > this way, I think that you have no question), > > [JY] I will be concerned with the operational complexity of this > approach. > > but in most cases 2 PWs are not > necessary. So in 01 version, we optimize it. > > "Root-only VSI <-> any VSI: only root PW required" > "Leaf-only VSI <-> leaf-only VSI: no PWs required" > > In other cases 2 PWs are needed. If so, "Leaf-only -> root-only =3D one > leaf PW" is not correct: On Leaf-only side, yes, one Leaf-only PW is > created between Local Leaf type with remote Root type; on root-only > side, one root-only PW is created. Maybe it is better to call this as > compatible or mixed PW. So the left items you list are not correct for > multi_PW solution. > > [JY] This is something new, right? To be honest, I could not understand > what is your point: doesn't the mixed PW as you called also consist of > one Leaf-only PW in one direction and one root-only PW in the other > direction? > Furthermore, the case you took is also one case in your guideline > "Root-only VSI <-> any VSI: only root PW required", don't you think > that only one root PW is required following this guideline? > Actually, I don't care much about what is the bidirectional PW or > unidirectional PW called, but how can a VSI support such a mixed > scenarios: > traditional VSI assumes only one PW is required for each peer VSI, and > its MAC leaning is based on bidirectional PW. But for 2PW, there are > bidirectional root PW, bidirectional leaf PW, mixed PW, etc..., how to > support these kinds of PWs in the same VSI is my top concern. > > BTW, I guess you also care this case we also have discussed before: for > example, if we configure one Leaf AC on root-only PE (then it will be > root-leaf-mixed PE), we will teardown the compatible PW and re-setup > PWs again with 01. > [JY] This was discussed in the emails indeed. > > Regards, > > Yuqun (Sam) Cao > E-mail: Yuqun.cao@gmail.com > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Monday, May 14, 2012 7:10 PM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Daniel, > > Fine, now it seems more in line with what we had proposed in 2VLAN: a > spoke PW behaves like root/leaf AC for a PE-r. > > But the same problem may also apply to the root/spoke "core PW" for > Multi-PW: > According to Multi-PW, only one PW is required between two PEs except > when both PEs are mixed with root and leaf, so these PWs may be formed > by combinations of the following unidirectional PW cases (extracted and > adapted from Josh's email): > Root-only -> any VSI =3D one root PW > Leaf-only -> root-only =3D one leaf PW > Leaf-only -> mixed =3D one leaf PW > Mixed -> root-only =3D one (root+leaf) PW > Mixed -> leaf-only =3D one (root+leaf) PW > > I have a concern that the forwarding plane of PE to implement this will > be very different from the traditional VPLS. > > Regards, > Yuanlong > > -----Original Message----- > From: Daniel Cohn [mailto:DanielC@orckit.com] > Sent: Monday, May 14, 2012 5:00 PM > To: Jiangyuanlong; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > Like I wrote below, root/leaf spoke PW behave like root/leaf AC, not > like root/spoke "core PW". So no changes to forwarding plane once this > is understood. > > DC > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Monday, May 14, 2012 11:36 AM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Daniel, please see my comments in line. > > -----Original Message----- > From: Daniel Cohn [mailto:DanielC@orckit.com] > Sent: Monday, May 14, 2012 3:37 PM > To: Jiangyuanlong; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > As I see it, for the PE-r spoke (figure 4 in RFC 4762) we establish a > single PW per AC - root PW for root AC and leaf PW for leaf AC. With > local configuration at the PE-rs as part of the spoke PW provisioning. > And the PE-rs will treat root/leaf spoke PWs exactly as it treat > root/leaf ACs. So when leaf-originated BUM traffic arrives from the > core (over a leaf PW), it will be forwarded over all root spoke PWs but > not on the leaf spoke PWs. > > [JY] So in the reverse direction, you need to transport both root and > leaf traffic from PE-rs over a root PW to PE-r, and transport root > traffic over a leaf PW. It seems against the definition of root PW and > leaf PW in the multi-PW draft. Don't this make the forwarding plane of > PE-rs more complex? > > The forwarding plane is exactly the same as described in the multi-PW > draft, where spoke PWs are treated exactly like ACs. > > Regards, > > Daniel > > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Friday, May 11, 2012 5:03 AM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Daniel and all, > > When you set up two PWs from the PE-rs to a PE-r for each of its AC, do > you mean that one PW is bidirectional root PW and the other is > bidirectional leaf PW? > My concern is: where should the leaf traffic be filtered, on the PE-rs > or on the PE-r? > If filtered on the PE-r, then lots of bandwidth will be wasted (for > example, if the PE-r is attached with 9 leafs, then the BUM traffic > from one of its leafs will be multiplied by 8 times, and be forwarded > by the PE-rs to the same PE-r). > If filtered on the PE-rs, not sure how you will design its forwarding > plane, can you give a hint? > > Thanks, > Yuanlong > > ------------------------------ > Date: Wed, 9 May 2012 09:16:36 +0300 > From: "Daniel Cohn" > To: "Alexander Vainshtein" , "Sam > Cao" , > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780CBA6@tlvmail1> > Content-Type: text/plain; charset=3D"ISO-2022-JP" > > Hi Sasha, > > It's actually very simple. A frame that originated in a root AC is > always transmitted only in root PW, no matter what the frame type > (known/unknown unicast or broadcast). This is how the frame source > information is propagated across the VPLS. So in the H-VPLS example, > the PE-r will never forward a frame received over a root PW on any leaf > PW, only on root PWs (toward the core or toward other spokes). > > Hope this clarifies it, regards, > > Daniel > > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Alexander Vainshtein > Sent: Wednesday, May 09, 2012 7:59 AM > To: Sam Cao; l2vpn@ietf.org > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > > Sam, Lizhong and all, > You've written that in the two-PW solution combined with H-VPLS the PE- > r must set up two PWs with each MTU-s. > > If this is the case, what kind of forwarding logic should be used to > prevent sending a BUM frame received from a root-PW to a given MTU-S: > - back to the same MTU-S on the corresponding leaf-PW? > - twice (to both root-PW and Leaf-PW) to another MTU-s? And, BTW, how > is the PW selected in this case? > > I am aware of a technique of multiple split horizon groups in PE-r > which could be possibly used for this purpose. However, since these > groups have to be represented explicitly in the data plane, their > potential number is limited by the forwarding HW. Other methods could > be probably used for the same purpose, but they would probably subject > to similar HW-based limitations. > > I suspect that with the dual-PW approach, the HW would pose an implicit > limit, say, on a number of MTU-s that can be connected to the same PE-r > and that this limit could be quite low in most cases. > > Based on this I suspect that the H-VPLS issue as a critical drawback of > the dual-PW approach to E-Tree. > > My 2c, > Sasha > > > ________________________________________ > From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Sam > Cao [yuqun.cao@gmail.com] > Sent: Wednesday, May 09, 2012 3:40 AM > To: l2vpn@ietf.org > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Lizhong? > > Thank you very much for your comments. I updated the result on this > question. > > [Lizhong] agree with the above analysis. And we did not say it is a > technical problem, but it is an operational problem again. > [Sam] I agree. Dual-VLAN does not make sense. I also discussed this > with Giles and Yuanlong in another mail, and we reached agreement on > this: > MTU should know the access mode, VPWS or VPLS, VPWS mode should > configure VLAN ID on MTU but VPLS mode can not. I thought this is NOT > reasonable :), but we can figure this out in draft. It seems ok. > > [Lizhong] not fully understand. Do you mean, when VPWS accessing for > H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf > PW) for each AC access? > [Sam] Yes. > > Thanks, > > Sam > > > > From jiangyuanlong@huawei.com Wed May 16 19:43: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 E7DE211E80A1 for ; Wed, 16 May 2012 19:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.342 X-Spam-Level: X-Spam-Status: No, score=-4.342 tagged_above=-999 required=5 tests=[AWL=1.657, BAYES_00=-2.599, J_CHICKENPOX_23=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 wmXasW6tnB+m for ; Wed, 16 May 2012 19:43:16 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id CBFB711E8089 for ; Wed, 16 May 2012 19:43: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 AGG52145; Wed, 16 May 2012 22:43:15 -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, 16 May 2012 19:41:20 -0700 Received: from SZXEML424-HUB.china.huawei.com (10.82.67.163) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 16 May 2012 19:41:24 -0700 Received: from SZXEML546-MBS.china.huawei.com ([169.254.4.75]) by szxeml424-hub.china.huawei.com ([10.82.67.163]) with mapi id 14.01.0323.003; Thu, 17 May 2012 10:41:19 +0800 From: Jiangyuanlong To: "Rogers, Josh" , Daniel Cohn , "Balus, Florin Stelian (Florin)" , Sam Cao , Alexander Vainshtein Subject: RE: Discussion on forwarding performance - 2VLAN Thread-Topic: Discussion on forwarding performance - 2VLAN Thread-Index: AQHNM5wCrqAbt+26fEKZd7gW8Lr9G5bNP8Rw Date: Thu, 17 May 2012 02:41:19 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413CF0@szxeml546-mbs.china.huawei.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413B06@szxeml546-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.73] Content-Type: text/plain; charset="iso-8859-2" 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, 17 May 2012 02:43:18 -0000 Josh, Yuanlong, I agree with your statement/assessment of where lookups occur to decide how to forward (egress PE), however=A9 If optimization is done to prevent the frame from being forwarded to PE's that have no AC's of the appropriate type, then there has to some sort of mapping between the ingress AC and the appropriate PW.=20 [JY] I assume the optimization you mean is filtering the leaf traffic on th= e ingress PE and not sending it to the leaf-only PE, right? I think there is no direct mapping from an ingress AC to a PW (except for s= poke PW in H-VPLS), as you know, there is only one PW between PEs in Dual-V= LAN solution. Earlier I assumed that this mapping would be done by looking at the S-VLAN that would be applied on the ingress PE physical interface. In the case of optimization being used, you'd see lookup of S-VLAN on both ingress and egress PE's, right? If not, how is the mapping between ingress AC and appropriate PW's done? [JY] In the case of optimization, the ingress PE may further filter the lea= f traffic on the logical ports corresponding to a PW which is connected to = a leaf-only remote PE (just as I said before, the VLAN mapping may be proce= ssed on a logical port), this was described in section 5.3.3 of draft-jiang= -l2vpn-vpls-pe-etree-05. But in a PW for E-Tree, as only 2 VLAN values are = possible, so we don't even need a table to implement it. Regards, Yuanlong On 5/16/12 5:04 AM, "Jiangyuanlong" wrote: >Daniel, > >I don't think we need to look up the VLAN and PW at the same time for >Dual-VLAN: >On the ingress PE, VLAN is firstly appended or translated for a incoming >Ethernet frame from AC, then MAC forwarded in VSI to one or multiple >logical ports each corresponding to a PW (the VLAN mapping may be >processed on a logical port), finally a PW label is appended and >transported over the corresponding PW. >On the egress PE, PW is popped and used to indicate a VSI (also >corresponding to a logical port, where the VLAN mapping may also be >processed), then MAC forwarded in VSI to one or multiple ports each >corresponding to an AC (where a frame with a leaf VLAN will be dropped >upon a leaf AC, actually, it is also a simple VLAN translation in IEEE, >that is, from leaf VLAN to 0xFFF, and all frames with this VLAN will be >dropped). > >Therefore, double lookup of VLAN and PW seems unnecessary or even >impossible for this service IMHO. > >Regards, >Yuanlong > >-----Original Message----- >From: Daniel Cohn [mailto:DanielC@orckit.com] >Sent: Wednesday, May 16, 2012 4:49 PM >To: Jiangyuanlong; Balus, Florin Stelian (Florin); Sam Cao; Alexander >Vainshtein >Cc: l2vpn@ietf.org >Subject: RE: Discussion on forwarding performance > >VC ID is another name for PW label, right. > ;-) >From conversations with chip vendors, I understood that when multiple >lookups are required (as in the dual-VLAN example, you need to lookup PW >label to identify E-Tree instance and then VLAN ID to identify root/leaf >origin), typically a single lookup is performed on ingress with a >composite search key (in this case, including PW label and VLAN ID). >/ ;-) >But perhaps we are getting too much into implementation here. It would >be better if neutral NP and ASIC-based solution vendors could analyze >both solutions and confirm impact on performance and scalability - and >BTW, we also need input regarding existing silicon that doesn't support >VLAN mapping. > >DC > >-----Original Message----- >From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >Sent: Wednesday, May 16, 2012 9:43 AM >To: Daniel Cohn; Balus, Florin Stelian (Florin); Sam Cao; Alexander >Vainshtein >Cc: l2vpn@ietf.org >Subject: RE: Discussion on forwarding performance > >Daniel, > >Not sure I fully understand what you mean by "VLAN and VCID lookups are >performed simultaneously on ingress", do you mean VLAN and PW? >Can you give more details on this requirement? > >Regards, >Yuanlong > > >-----Original Message----- >From: Daniel Cohn [mailto:DanielC@orckit.com] >Sent: Wednesday, May 16, 2012 2:16 PM >To: Balus, Florin Stelian (Florin); Sam Cao; Jiangyuanlong; Alexander >Vainshtein >Cc: l2vpn@ietf.org >Subject: RE: Discussion on forwarding performance > >Hi, > >I agree that for a chip-based solution there should be no difference in >performance for the additional lookup. However from conversations with >chip vendors, I understood there might be an impact on scalability >because the double lookup would require a longer search key (assuming >VLAN and VCID lookups are performed simultaneously on ingress), thus >taking up more TCAM resources per E-Tree instance. This would depend on >specific TCAM implementation (e.g. granularity of search key length). > >DC > >-----Original Message----- >From: Balus, Florin Stelian (Florin) >[mailto:florin.balus@alcatel-lucent.com] >Sent: Tuesday, May 15, 2012 10:53 PM >To: Sam Cao; 'Jiangyuanlong'; Daniel Cohn; 'Alexander Vainshtein' >Cc: l2vpn@ietf.org >Subject: RE: Discussion on forwarding performance > >Sam, > >> Obviously the forwarding performance of Dual-VLAN will be much lower >than what of Multi-PW. > >Sorry I could not keep up with some of the threads on this subject but >the above statement caught my eyes. We have been doing all kind of >egress operations on VLANs in the egress PE for the last 8 years and I >am not aware of any "much lower" forwarding performance. As far as I >know the chipsets used in the PEs can do this processing no problem. Do >you want to clarify which kind of hardware may have problems? > >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >> Of Sam Cao >> Sent: Tuesday, May 15, 2012 6:32 AM >> To: 'Jiangyuanlong'; 'Daniel Cohn'; 'Alexander Vainshtein' >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on forwarding performance >> >> Hi Yuanlong, >> >> 3rd mapping will make data plane complex, I think. Anyway, we reached >a >> consensus on Multi-PW implementation. >> >> If we use 3rd mapping, I agree with your opinion, maybe dual-VLAN >seems >> simple, but 2 mapping is enough. Then we can focus on data plane >> performance. While stripe PW label out on egress PE, data-plane knows >> how to forward the frames from PW, to Root AC or Leaf AC or all. But >if >> we use Dual-VLAN, after strip PW label out, data plane should strip >> VLAN-ID out and then does same forwarding work as Multi-PW does. The >> most important is, do one more operation while forwarding E-Tree >> frames. Obviously the forwarding performance of Dual-VLAN will be much >> lower than what of Multi-PW. >> >> Regards, >> >> Yuqun (Sam) Cao >> E-mail: Yuqun.cao@gmail.com >> >> -----Original Message----- >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> Sent: Tuesday, May 15, 2012 7:03 PM >> To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> See my further comments in line. >> >> -----Original Message----- >> From: Sam Cao [mailto:yuqun.cao@gmail.com] >> Sent: Tuesday, May 15, 2012 6:14 PM >> To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Hi Yuanlong, >> >> Thank you very much for your comments. I draw the topology you gave, >> and 7 PWs will be established if we follow 01. >> >> Root AC ---- PE 1 ----- PW 1 -------- PE 2 ----- Leaf _AC >> | \ / || >> | \ /=3D=3D=3DPW 6,7=3D=3D=3D || >> PW 2 -----PW 5------\ || >> | /----Root PW 3 --- \ || >> Root _AC ---- PE 3 PE 4 ------ Root AC >> | \ / | >> | ----Leaf PW 4----- | >> Leaf AC Leaf AC >> Yes, on PE 3 there are several PWs, but if you want to clarify it, >> there are only 3 types, one can carry frames originated from Root and >> Leaf AC(one endpoint of this PW should be Root-only, otherwise this is >> invalid), one only can carry frames from Root AC, and the last can >> carry frames from Leaf ACs. On second thoughts, we still can classify >> the PWs into 2 sets, one is Leaf set, and another is Root set, and the >> union of the sets Leaf and Root is the PW we called it as compatible >PW >> (Maybe this is not correct, we can find one good term on this). >> >> So this optimization still follows the original design of Dual-PW >> approach, Leaf PW only carries frames from Leaf AC; Root-PW only >> carries frames from Root AC. Is it right? >> >> I don't know whether chip can support this forwarding behavior for >> compatible PW or not, but if we implement it in NP, it is nearly same >> as VPLS. The only difference is, setup 2 mappings, one between >Leaf-ACs >> and Leaf-PWs, one between Root-ACs and Root-PWs. For traditional VPLS, >> there is only one mapping. >> >> [JY] It seems you may need a 3rd mapping: from both root & leaf AC to >a >> compatible PW. >> BTW, for the forwarding and reverse direction, the mapping may be >> asymmetric for you compatible PW. >> >> Based on my understanding, all drafts should have similar mapping. >> >> [JY] Dual-VLAN seems simpler here. >> >> Thanks, >> >> Sam >> >> >> -----Original Message----- >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> Sent: Tuesday, May 15, 2012 3:32 PM >> To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Sam, >> >> Thanks, please see my further comments with [JY]. >> >> Ok, we go on the case in your mail, where PE1 has one Root-only AC, >> AC1, and >> PE2 has one Leaf-only AC, AC2. In general we can setup 2 >> "unidirectional" >> PWs (bidirectional PW, but just carry unidirectional frames), Root-PW >> which carries frames originated from AC1 and Leaf-PW which carries >> frames originated from AC2. But only one PW also can work, just as >some >> members commented. Ok, we setup one PW between PE1 and PE2, we can >call >> this PW as compatible PW or something else. Frames originated from >Root >> or leaf ACs will be carried via this PW. Its forwarding behavior is >> fully same as what traditional VPLS did, MAC learning on AC or PW in >> one E-Tree. Or say, if one PE has Root-only ACs, it will setup one PW >> with another PE, Root-only, Leaf-only or Root-Leaf-Mixed. If 2 PEs are >> root-Leaf-Mixed or other cases, then 2 PWs will be established. As you >> know, this can be done on control plane. >> >> [JY] Assume there are 2 other nodes PE3 & PE4 in this network >scenario, >> and both PE3 and PE4 have both root and leaf ACs, then there are >> compatible PWs from PE3 which may carry both root and leaf traffic (to >> PE1), which may carry only root traffic (to PE2); and further there >are >> root PW and leaf PW to PE4. Thus, the VSI on PE3 has at least 4 >> different types of PW transmitting behaviours with regard to the >E-Tree >> traffic. In the reverse direction, the VSI on PE3 further has at least >> 4 different types of PW receiving behaviours. Not sure how you will >> accommodate for these PWs in both the data plane and control plane. >> >> Regards, >> Yuanlong >> >> Is this clear for you? Is this necessary to optimize PW setup in this >> case? >> >> Maybe we need to add one paragraph on forwarding behavior. >> >> Again thank you very much for your comments, >> >> Sam >> >> -----Original Message----- >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> Sent: Tuesday, May 15, 2012 10:27 AM >> To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Please see my comments in line. >> >> -----Original Message----- >> From: Sam Cao [mailto:yuqun.cao@gmail.com] >> Sent: Monday, May 14, 2012 8:31 PM >> To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Hi Yuanlong, >> >> We have discussed this in another thread. In fact, Daniel or I have >> given the answers to the questions you raised here for several time >:). >> If we do in this way, we will reach deadlock and can not move forward >> :). I try to explain it again. >> >> [JY] I will apologize if you had ever provided such answers before, >and >> you may just refer to the links rather than repeat the explanation. >> As you can see, I just try to understand the mechanism of 2PW and its >> implications, but the I-D does not include enough information. >> >> As you know, initial design we will setup 2 PWs all the time (if do in >> this way, I think that you have no question), >> >> [JY] I will be concerned with the operational complexity of this >> approach. >> >> but in most cases 2 PWs are not >> necessary. So in 01 version, we optimize it. >> >> "Root-only VSI <-> any VSI: only root PW required" >> "Leaf-only VSI <-> leaf-only VSI: no PWs required" >> >> In other cases 2 PWs are needed. If so, "Leaf-only -> root-only =3D one >> leaf PW" is not correct: On Leaf-only side, yes, one Leaf-only PW is >> created between Local Leaf type with remote Root type; on root-only >> side, one root-only PW is created. Maybe it is better to call this as >> compatible or mixed PW. So the left items you list are not correct for >> multi_PW solution. >> >> [JY] This is something new, right? To be honest, I could not >understand >> what is your point: doesn't the mixed PW as you called also consist of >> one Leaf-only PW in one direction and one root-only PW in the other >> direction? >> Furthermore, the case you took is also one case in your guideline >> "Root-only VSI <-> any VSI: only root PW required", don't you think >> that only one root PW is required following this guideline? >> Actually, I don't care much about what is the bidirectional PW or >> unidirectional PW called, but how can a VSI support such a mixed >> scenarios: >> traditional VSI assumes only one PW is required for each peer VSI, and >> its MAC leaning is based on bidirectional PW. But for 2PW, there are >> bidirectional root PW, bidirectional leaf PW, mixed PW, etc..., how to >> support these kinds of PWs in the same VSI is my top concern. >> >> BTW, I guess you also care this case we also have discussed before: >for >> example, if we configure one Leaf AC on root-only PE (then it will be >> root-leaf-mixed PE), we will teardown the compatible PW and re-setup >> PWs again with 01. >> [JY] This was discussed in the emails indeed. >> >> Regards, >> >> Yuqun (Sam) Cao >> E-mail: Yuqun.cao@gmail.com >> >> -----Original Message----- >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> Sent: Monday, May 14, 2012 7:10 PM >> To: Daniel Cohn; Alexander Vainshtein; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Hi Daniel, >> >> Fine, now it seems more in line with what we had proposed in 2VLAN: a >> spoke PW behaves like root/leaf AC for a PE-r. >> >> But the same problem may also apply to the root/spoke "core PW" for >> Multi-PW: >> According to Multi-PW, only one PW is required between two PEs except >> when both PEs are mixed with root and leaf, so these PWs may be formed >> by combinations of the following unidirectional PW cases (extracted >and >> adapted from Josh's email): >> Root-only -> any VSI =3D one root PW >> Leaf-only -> root-only =3D one leaf PW >> Leaf-only -> mixed =3D one leaf PW >> Mixed -> root-only =3D one (root+leaf) PW >> Mixed -> leaf-only =3D one (root+leaf) PW >> >> I have a concern that the forwarding plane of PE to implement this >will >> be very different from the traditional VPLS. >> >> Regards, >> Yuanlong >> >> -----Original Message----- >> From: Daniel Cohn [mailto:DanielC@orckit.com] >> Sent: Monday, May 14, 2012 5:00 PM >> To: Jiangyuanlong; Alexander Vainshtein; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Hi Yuanlong, >> >> Like I wrote below, root/leaf spoke PW behave like root/leaf AC, not >> like root/spoke "core PW". So no changes to forwarding plane once this >> is understood. >> >> DC >> >> -----Original Message----- >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> Sent: Monday, May 14, 2012 11:36 AM >> To: Daniel Cohn; Alexander Vainshtein; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Daniel, please see my comments in line. >> >> -----Original Message----- >> From: Daniel Cohn [mailto:DanielC@orckit.com] >> Sent: Monday, May 14, 2012 3:37 PM >> To: Jiangyuanlong; Alexander Vainshtein; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Hi Yuanlong, >> >> As I see it, for the PE-r spoke (figure 4 in RFC 4762) we establish a >> single PW per AC - root PW for root AC and leaf PW for leaf AC. With >> local configuration at the PE-rs as part of the spoke PW provisioning. >> And the PE-rs will treat root/leaf spoke PWs exactly as it treat >> root/leaf ACs. So when leaf-originated BUM traffic arrives from the >> core (over a leaf PW), it will be forwarded over all root spoke PWs >but >> not on the leaf spoke PWs. >> >> [JY] So in the reverse direction, you need to transport both root and >> leaf traffic from PE-rs over a root PW to PE-r, and transport root >> traffic over a leaf PW. It seems against the definition of root PW and >> leaf PW in the multi-PW draft. Don't this make the forwarding plane of >> PE-rs more complex? >> >> The forwarding plane is exactly the same as described in the multi-PW >> draft, where spoke PWs are treated exactly like ACs. >> >> Regards, >> >> Daniel >> >> >> -----Original Message----- >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> Sent: Friday, May 11, 2012 5:03 AM >> To: Daniel Cohn; Alexander Vainshtein; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Hi Daniel and all, >> >> When you set up two PWs from the PE-rs to a PE-r for each of its AC, >do >> you mean that one PW is bidirectional root PW and the other is >> bidirectional leaf PW? >> My concern is: where should the leaf traffic be filtered, on the PE-rs >> or on the PE-r? >> If filtered on the PE-r, then lots of bandwidth will be wasted (for >> example, if the PE-r is attached with 9 leafs, then the BUM traffic >> from one of its leafs will be multiplied by 8 times, and be forwarded >> by the PE-rs to the same PE-r). >> If filtered on the PE-rs, not sure how you will design its forwarding >> plane, can you give a hint? >> >> Thanks, >> Yuanlong >> >> ------------------------------ >> Date: Wed, 9 May 2012 09:16:36 +0300 >> From: "Daniel Cohn" >> To: "Alexander Vainshtein" , >"Sam >> Cao" , >> Cc: lizhong.jin@zte.com.cn >> Subject: RE: Discussion on E-Tree and H-VPLS >> Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780CBA6@tlvmail1> >> Content-Type: text/plain; charset=3D"ISO-2022-JP" >> >> Hi Sasha, >> >> It's actually very simple. A frame that originated in a root AC is >> always transmitted only in root PW, no matter what the frame type >> (known/unknown unicast or broadcast). This is how the frame source >> information is propagated across the VPLS. So in the H-VPLS example, >> the PE-r will never forward a frame received over a root PW on any >leaf >> PW, only on root PWs (toward the core or toward other spokes). >> >> Hope this clarifies it, regards, >> >> Daniel >> >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >> Of Alexander Vainshtein >> Sent: Wednesday, May 09, 2012 7:59 AM >> To: Sam Cao; l2vpn@ietf.org >> Cc: lizhong.jin@zte.com.cn >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Sam, Lizhong and all, >> You've written that in the two-PW solution combined with H-VPLS the >PE- >> r must set up two PWs with each MTU-s. >> >> If this is the case, what kind of forwarding logic should be used to >> prevent sending a BUM frame received from a root-PW to a given MTU-S: >> - back to the same MTU-S on the corresponding leaf-PW? >> - twice (to both root-PW and Leaf-PW) to another MTU-s? And, BTW, how >> is the PW selected in this case? >> >> I am aware of a technique of multiple split horizon groups in PE-r >> which could be possibly used for this purpose. However, since these >> groups have to be represented explicitly in the data plane, their >> potential number is limited by the forwarding HW. Other methods could >> be probably used for the same purpose, but they would probably subject >> to similar HW-based limitations. >> >> I suspect that with the dual-PW approach, the HW would pose an >implicit >> limit, say, on a number of MTU-s that can be connected to the same >PE-r >> and that this limit could be quite low in most cases. >> >> Based on this I suspect that the H-VPLS issue as a critical drawback >of >> the dual-PW approach to E-Tree. >> >> My 2c, >> Sasha >> >> >> ________________________________________ >> From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Sam >> Cao [yuqun.cao@gmail.com] >> Sent: Wednesday, May 09, 2012 3:40 AM >> To: l2vpn@ietf.org >> Cc: lizhong.jin@zte.com.cn >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Hi Lizhong? >> >> Thank you very much for your comments. I updated the result on this >> question. >> >> [Lizhong] agree with the above analysis. And we did not say it is a >> technical problem, but it is an operational problem again. >> [Sam] I agree. Dual-VLAN does not make sense. I also discussed this >> with Giles and Yuanlong in another mail, and we reached agreement on >> this: >> MTU should know the access mode, VPWS or VPLS, VPWS mode should >> configure VLAN ID on MTU but VPLS mode can not. I thought this is NOT >> reasonable :), but we can figure this out in draft. It seems ok. >> >> [Lizhong] not fully understand. Do you mean, when VPWS accessing for >> H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf >> PW) for each AC access? >> [Sam] Yes. >> >> Thanks, >> >> Sam >> >> >> >> > 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 May 16 20:47: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 0B23011E8073 for ; Wed, 16 May 2012 20:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.371 X-Spam-Level: X-Spam-Status: No, score=-4.371 tagged_above=-999 required=5 tests=[AWL=1.628, BAYES_00=-2.599, J_CHICKENPOX_23=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 3b72P88X7pu3 for ; Wed, 16 May 2012 20:47:47 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id E457C21F864A for ; Wed, 16 May 2012 20:47:46 -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 AFZ58241; Wed, 16 May 2012 23:47:46 -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; Wed, 16 May 2012 20:45:56 -0700 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 16 May 2012 20:45:54 -0700 Received: from SZXEML546-MBS.china.huawei.com ([169.254.4.75]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.003; Thu, 17 May 2012 11:45:50 +0800 From: Jiangyuanlong To: "Rogers, Josh" , "Balus, Florin Stelian (Florin)" , Daniel Cohn , Sam Cao , Alexander Vainshtein Subject: RE: Discussion on forwarding performance - 2VLAN Thread-Topic: Discussion on forwarding performance - 2VLAN Thread-Index: AQHNM5wCrqAbt+26fEKZd7gW8Lr9G5bMTZyAgAAEmoCAAPiSoA== Date: Thu, 17 May 2012 03:45:48 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413D1A@szxeml546-mbs.china.huawei.com> References: <2073A6C5467C99478898544C6EBA3F4602C19077F0@USNAVSXCHMBSC3.ndc.alcatel-lucent.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.73] 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: Thu, 17 May 2012 03:47:49 -0000 SGkgSm9zaCwNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFJvZ2VycywgSm9z aCBbbWFpbHRvOmpvc2gucm9nZXJzQHR3Y2FibGUuY29tXSANClNlbnQ6IFRodXJzZGF5LCBNYXkg MTcsIDIwMTIgNDowOSBBTQ0KVG86IEJhbHVzLCBGbG9yaW4gU3RlbGlhbiAoRmxvcmluKTsgSmlh bmd5dWFubG9uZzsgRGFuaWVsIENvaG47IFNhbSBDYW87IEFsZXhhbmRlciBWYWluc2h0ZWluDQpD YzogbDJ2cG5AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBEaXNjdXNzaW9uIG9uIGZvcndhcmRpbmcg cGVyZm9ybWFuY2UgLSAyVkxBTg0KDQpGbG9yaW4sIHRoYW5rcyBmb3IgdGhlIGV4cGxhbmF0aW9u Lg0KDQpUb2RheSwgYnJpZGdlIChvbiBhIFBFKSBleHBlY3RzIHRvL2Zyb20gYWxsIGVuZHBvaW50 cyBpbiB0aGUgZG9tYWluLiAgV2lsbA0KYW55IHBhcnRpY3VsYXIgZWZmb3J0IGluIGltcGxlbWVu dGF0aW9uIGhhdmUgdG8gYmUgbWFkZSB0byB0aWUgdG9nZXRoZXINCmFwcHJvcHJpYXRlIEFDJ3Mg d2l0aCBhcHByb3ByaWF0ZSBQVydzPw0KDQpbSlldIE1heWJlIEkgYW0gbmHDr3ZlLCBCdXQgSSB0 aGluayBpbiBnZW5lcmFsIGl0IGlzIG5vdCBwb3NzaWJsZSB0byB0aWUgYW4gQUMgd2l0aCBvbmUg b3IgbW9yZSBQV3MgZGlyZWN0bHkgZXhjZXB0IGZvciBzb21lIHZlcnkgc3BlY2lhbCB0b3BvbG9n eSwgb25jZSB0aGV5IGFyZSB0aWVkIHRvZ2V0aGVyLCB0aGUgTVAyTVAgY2hhcmFjdGVyaXN0aWMg b2YgYnJpZGdlIG9yIFZQTFMgaXMgbG9zdC4gQUNMIG1heSBiZSB1c2VkIHRvIGhlbHAgc291cmNl LWRlcGVuZGFudCBmb3J3YXJkaW5nIHJ1bGVzIGJ1dCB3aXRoIHNvbWUgbW9yZSBjb3N0Lg0KDQpS ZWdhcmRzLA0KWXVhbmxvbmcNCg0KVGhpcyBxdWVzdGlvbiBzaG91bGQgYXBwbHkgdG8gYm90aCB0 aGUgMlZMQU4gYW5kIE11bHRpUFcgbWV0aG9kcywgYXMgYm90aA0Kc2VlbSB0byByZWx5IG9uIHRo ZXNlIHNvdXJjZS1kZXBlbmRhbnQgKGFzIG9wcG9zZWQgdG8gdGhlIGRlc3RpbmF0aW9uDQpiYXNl ZCBmb3J3YXJkaW5nIHJ1bGVzIGJhc2VkIG9uIERTVCBNQUMgb25seSkNCg0KDQoNCk9uIDUvMTYv MTIgMjo1MiBQTSwgIkJhbHVzLCBGbG9yaW4gU3RlbGlhbiAoRmxvcmluKSINCjxmbG9yaW4uYmFs dXNAYWxjYXRlbC1sdWNlbnQuY29tPiB3cm90ZToNCg0KPkFzIHNvb24gYXMgdGhlIHBhY2tldCBp cyByZWNlaXZlZCBvbiB0aGUgaW5ncmVzcyBQRSB0aGUgaW5ncmVzcyBjYXJkDQo+KGUuZy4gc2Vy dmljZSBtYW5hZ2VyKSB3aWxsIGtub3cgb24gd2hhdCBraW5kIG9mIGVudHJ5IHBvaW50IGl0IGFy cml2ZWQ6DQo+aS5lLiB3aGV0aGVyIGl0IGlzIGEgbGVhZiBvciBhIHJvb3QuIFRoZW4gcmlnaHQg dGhlcmUgaXQgY291bGQgbWFrZSBhDQo+ZGVjaXNpb24gd2hldGhlciBpdCBnb2VzIG91dCBvbiBh IFBXIG9yIG5vdC4gVGhlIFNWTEFOIGluZGljYXRpb24gaXMNCj5yZWFsbHkgZm9yIHRoZSBuZXh0 IFBFIGluIHRoZSBjaGFpbi4NCj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBG cm9tOiBSb2dlcnMsIEpvc2ggW21haWx0bzpqb3NoLnJvZ2Vyc0B0d2NhYmxlLmNvbV0NCj4+IFNl bnQ6IFdlZG5lc2RheSwgTWF5IDE2LCAyMDEyIDEyOjQyIFBNDQo+PiBUbzogSmlhbmd5dWFubG9u ZzsgRGFuaWVsIENvaG47IEJhbHVzLCBGbG9yaW4gU3RlbGlhbiAoRmxvcmluKTsgU2FtDQo+PiBD YW87IEFsZXhhbmRlciBWYWluc2h0ZWluDQo+PiBDYzogbDJ2cG5AaWV0Zi5vcmcNCj4+IFN1Ympl Y3Q6IFJlOiBEaXNjdXNzaW9uIG9uIGZvcndhcmRpbmcgcGVyZm9ybWFuY2UgLSAyVkxBTg0KPj4N Cj4+IFl1YW5sb25nLCBJIGFncmVlIHdpdGggeW91ciBzdGF0ZW1lbnQvYXNzZXNzbWVudCBvZiB3 aGVyZSBsb29rdXBzIG9jY3VyDQo+PiB0byBkZWNpZGUgaG93IHRvIGZvcndhcmQgKGVncmVzcyBQ RSksIGhvd2V2ZXLFoCAgSWYgb3B0aW1pemF0aW9uIGlzIGRvbmUNCj4+IHRvIHByZXZlbnQgdGhl IGZyYW1lIGZyb20gYmVpbmcgZm9yd2FyZGVkIHRvIFBFJ3MgdGhhdCBoYXZlIG5vIEFDJ3Mgb2YN Cj4+IHRoZSBhcHByb3ByaWF0ZSB0eXBlLCB0aGVuIHRoZXJlIGhhcyB0byBzb21lIHNvcnQgb2Yg bWFwcGluZyBiZXR3ZWVuDQo+PiB0aGUgaW5ncmVzcyBBQyBhbmQgdGhlIGFwcHJvcHJpYXRlIFBX LiAgRWFybGllciBJIGFzc3VtZWQgdGhhdCB0aGlzDQo+PiBtYXBwaW5nIHdvdWxkIGJlIGRvbmUg YnkgbG9va2luZyBhdCB0aGUgUy1WTEFOIHRoYXQgd291bGQgYmUgYXBwbGllZCBvbg0KPj4gdGhl IGluZ3Jlc3MgUEUgcGh5c2ljYWwgaW50ZXJmYWNlLiAgSW4gdGhlIGNhc2Ugb2Ygb3B0aW1pemF0 aW9uIGJlaW5nDQo+PiB1c2VkLCB5b3UnZCBzZWUgbG9va3VwIG9mIFMtVkxBTiBvbiBib3RoIGlu Z3Jlc3MgYW5kIGVncmVzcyBQRSdzLA0KPj4gcmlnaHQ/ICBJZiBub3QsIGhvdyBpcyB0aGUgbWFw cGluZyBiZXR3ZWVuIGluZ3Jlc3MgQUMgYW5kIGFwcHJvcHJpYXRlDQo+PiBQVydzIGRvbmU/DQo+ Pg0KPj4NCj4+DQo+PiBPbiA1LzE2LzEyIDU6MDQgQU0sICJKaWFuZ3l1YW5sb25nIiA8amlhbmd5 dWFubG9uZ0BodWF3ZWkuY29tPiB3cm90ZToNCj4+DQo+PiA+RGFuaWVsLA0KPj4gPg0KPj4gPkkg ZG9uJ3QgdGhpbmsgd2UgbmVlZCB0byBsb29rIHVwIHRoZSBWTEFOIGFuZCBQVyBhdCB0aGUgc2Ft ZSB0aW1lIGZvcg0KPj4gPkR1YWwtVkxBTjoNCj4+ID5PbiB0aGUgaW5ncmVzcyBQRSwgVkxBTiBp cyBmaXJzdGx5IGFwcGVuZGVkIG9yIHRyYW5zbGF0ZWQgZm9yIGENCj4+ID5pbmNvbWluZyBFdGhl cm5ldCBmcmFtZSBmcm9tIEFDLCB0aGVuIE1BQyBmb3J3YXJkZWQgaW4gVlNJIHRvIG9uZSBvcg0K Pj4gPm11bHRpcGxlIGxvZ2ljYWwgcG9ydHMgZWFjaCBjb3JyZXNwb25kaW5nIHRvIGEgUFcgKHRo ZSBWTEFOIG1hcHBpbmcNCj4+IG1heQ0KPj4gPmJlIHByb2Nlc3NlZCBvbiBhIGxvZ2ljYWwgcG9y dCksIGZpbmFsbHkgYSBQVyBsYWJlbCBpcyBhcHBlbmRlZCBhbmQNCj4+ID50cmFuc3BvcnRlZCBv dmVyIHRoZSBjb3JyZXNwb25kaW5nIFBXLg0KPj4gPk9uIHRoZSBlZ3Jlc3MgUEUsIFBXIGlzIHBv cHBlZCBhbmQgdXNlZCB0byBpbmRpY2F0ZSBhIFZTSSAoYWxzbw0KPj4gPmNvcnJlc3BvbmRpbmcg dG8gYSBsb2dpY2FsIHBvcnQsIHdoZXJlIHRoZSBWTEFOIG1hcHBpbmcgbWF5IGFsc28gYmUNCj4+ ID5wcm9jZXNzZWQpLCB0aGVuIE1BQyBmb3J3YXJkZWQgaW4gVlNJIHRvIG9uZSBvciBtdWx0aXBs ZSBwb3J0cyBlYWNoDQo+PiA+Y29ycmVzcG9uZGluZyB0byBhbiBBQyAod2hlcmUgYSBmcmFtZSB3 aXRoIGEgbGVhZiBWTEFOIHdpbGwgYmUgZHJvcHBlZA0KPj4gPnVwb24gYSBsZWFmIEFDLCBhY3R1 YWxseSwgaXQgaXMgYWxzbyBhIHNpbXBsZSBWTEFOIHRyYW5zbGF0aW9uIGluDQo+PiBJRUVFLA0K Pj4gPnRoYXQgaXMsIGZyb20gbGVhZiBWTEFOIHRvIDB4RkZGLCBhbmQgYWxsIGZyYW1lcyB3aXRo IHRoaXMgVkxBTiB3aWxsDQo+PiBiZQ0KPj4gPmRyb3BwZWQpLg0KPj4gPg0KPj4gPlRoZXJlZm9y ZSwgZG91YmxlIGxvb2t1cCBvZiBWTEFOIGFuZCBQVyBzZWVtcyB1bm5lY2Vzc2FyeSBvciBldmVu DQo+PiA+aW1wb3NzaWJsZSBmb3IgdGhpcyBzZXJ2aWNlIElNSE8uDQo+PiA+DQo+PiA+UmVnYXJk cywNCj4+ID5ZdWFubG9uZw0KPj4gPg0KPj4gPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ PiA+RnJvbTogRGFuaWVsIENvaG4gW21haWx0bzpEYW5pZWxDQG9yY2tpdC5jb21dDQo+PiA+U2Vu dDogV2VkbmVzZGF5LCBNYXkgMTYsIDIwMTIgNDo0OSBQTQ0KPj4gPlRvOiBKaWFuZ3l1YW5sb25n OyBCYWx1cywgRmxvcmluIFN0ZWxpYW4gKEZsb3Jpbik7IFNhbSBDYW87IEFsZXhhbmRlcg0KPj4g PlZhaW5zaHRlaW4NCj4+ID5DYzogbDJ2cG5AaWV0Zi5vcmcNCj4+ID5TdWJqZWN0OiBSRTogRGlz Y3Vzc2lvbiBvbiBmb3J3YXJkaW5nIHBlcmZvcm1hbmNlDQo+PiA+DQo+PiA+VkMgSUQgaXMgYW5v dGhlciBuYW1lIGZvciBQVyBsYWJlbCwgcmlnaHQuDQo+PiA+PFNhc2hhLCBzdG9wIHlvdXIgZWFy cyBub3c+IDstKQ0KPj4gPkZyb20gY29udmVyc2F0aW9ucyB3aXRoIGNoaXAgdmVuZG9ycywgSSB1 bmRlcnN0b29kIHRoYXQgd2hlbiBtdWx0aXBsZQ0KPj4gPmxvb2t1cHMgYXJlIHJlcXVpcmVkIChh cyBpbiB0aGUgZHVhbC1WTEFOIGV4YW1wbGUsIHlvdSBuZWVkIHRvIGxvb2t1cA0KPj4gPlBXIGxh YmVsIHRvIGlkZW50aWZ5IEUtVHJlZSBpbnN0YW5jZSBhbmQgdGhlbiBWTEFOIElEIHRvIGlkZW50 aWZ5DQo+PiA+cm9vdC9sZWFmIG9yaWdpbiksIHR5cGljYWxseSBhIHNpbmdsZSBsb29rdXAgaXMg cGVyZm9ybWVkIG9uIGluZ3Jlc3MNCj4+ID53aXRoIGEgY29tcG9zaXRlIHNlYXJjaCBrZXkgKGlu IHRoaXMgY2FzZSwgaW5jbHVkaW5nIFBXIGxhYmVsIGFuZCBWTEFODQo+PiBJRCkuDQo+PiA+LzxT YXNoYSwgc3RvcCB5b3VyIGVhcnMgbm93PiA7LSkNCj4+ID5CdXQgcGVyaGFwcyB3ZSBhcmUgZ2V0 dGluZyB0b28gbXVjaCBpbnRvIGltcGxlbWVudGF0aW9uIGhlcmUuIEl0IHdvdWxkDQo+PiA+YmUg YmV0dGVyIGlmIG5ldXRyYWwgTlAgYW5kIEFTSUMtYmFzZWQgc29sdXRpb24gdmVuZG9ycyBjb3Vs ZCBhbmFseXplDQo+PiA+Ym90aCBzb2x1dGlvbnMgYW5kIGNvbmZpcm0gaW1wYWN0IG9uIHBlcmZv cm1hbmNlIGFuZCBzY2FsYWJpbGl0eSAtIGFuZA0KPj4gPkJUVywgd2UgYWxzbyBuZWVkIGlucHV0 IHJlZ2FyZGluZyBleGlzdGluZyBzaWxpY29uIHRoYXQgZG9lc24ndA0KPj4gc3VwcG9ydA0KPj4g PlZMQU4gbWFwcGluZy4NCj4+ID4NCj4+ID5EQw0KPj4gPg0KPj4gPi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+PiA+RnJvbTogSmlhbmd5dWFubG9uZyBbbWFpbHRvOmppYW5neXVhbmxvbmdA aHVhd2VpLmNvbV0NCj4+ID5TZW50OiBXZWRuZXNkYXksIE1heSAxNiwgMjAxMiA5OjQzIEFNDQo+ PiA+VG86IERhbmllbCBDb2huOyBCYWx1cywgRmxvcmluIFN0ZWxpYW4gKEZsb3Jpbik7IFNhbSBD YW87IEFsZXhhbmRlcg0KPj4gPlZhaW5zaHRlaW4NCj4+ID5DYzogbDJ2cG5AaWV0Zi5vcmcNCj4+ ID5TdWJqZWN0OiBSRTogRGlzY3Vzc2lvbiBvbiBmb3J3YXJkaW5nIHBlcmZvcm1hbmNlDQo+PiA+ DQo+PiA+RGFuaWVsLA0KPj4gPg0KPj4gPk5vdCBzdXJlIEkgZnVsbHkgdW5kZXJzdGFuZCB3aGF0 IHlvdSBtZWFuIGJ5ICJWTEFOIGFuZCBWQ0lEIGxvb2t1cHMNCj4+IGFyZQ0KPj4gPnBlcmZvcm1l ZCBzaW11bHRhbmVvdXNseSBvbiBpbmdyZXNzIiwgZG8geW91IG1lYW4gVkxBTiBhbmQgUFc/DQo+ PiA+Q2FuIHlvdSBnaXZlIG1vcmUgZGV0YWlscyBvbiB0aGlzIHJlcXVpcmVtZW50Pw0KPj4gPg0K Pj4gPlJlZ2FyZHMsDQo+PiA+WXVhbmxvbmcNCj4+ID4NCj4+ID4NCj4+ID4tLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPj4gPkZyb206IERhbmllbCBDb2huIFttYWlsdG86RGFuaWVsQ0BvcmNr aXQuY29tXQ0KPj4gPlNlbnQ6IFdlZG5lc2RheSwgTWF5IDE2LCAyMDEyIDI6MTYgUE0NCj4+ID5U bzogQmFsdXMsIEZsb3JpbiBTdGVsaWFuIChGbG9yaW4pOyBTYW0gQ2FvOyBKaWFuZ3l1YW5sb25n OyBBbGV4YW5kZXINCj4+ID5WYWluc2h0ZWluDQo+PiA+Q2M6IGwydnBuQGlldGYub3JnDQo+PiA+ U3ViamVjdDogUkU6IERpc2N1c3Npb24gb24gZm9yd2FyZGluZyBwZXJmb3JtYW5jZQ0KPj4gPg0K Pj4gPkhpLA0KPj4gPg0KPj4gPkkgYWdyZWUgdGhhdCBmb3IgYSBjaGlwLWJhc2VkIHNvbHV0aW9u IHRoZXJlIHNob3VsZCBiZSBubyBkaWZmZXJlbmNlDQo+PiBpbg0KPj4gPnBlcmZvcm1hbmNlIGZv ciB0aGUgYWRkaXRpb25hbCBsb29rdXAuIEhvd2V2ZXIgZnJvbSBjb252ZXJzYXRpb25zIHdpdGgN Cj4+ID5jaGlwIHZlbmRvcnMsIEkgdW5kZXJzdG9vZCB0aGVyZSBtaWdodCBiZSBhbiBpbXBhY3Qg b24gc2NhbGFiaWxpdHkNCj4+ID5iZWNhdXNlIHRoZSBkb3VibGUgbG9va3VwIHdvdWxkIHJlcXVp cmUgYSBsb25nZXIgc2VhcmNoIGtleSAoYXNzdW1pbmcNCj4+ID5WTEFOIGFuZCBWQ0lEIGxvb2t1 cHMgYXJlIHBlcmZvcm1lZCBzaW11bHRhbmVvdXNseSBvbiBpbmdyZXNzKSwgdGh1cw0KPj4gPnRh a2luZyB1cCBtb3JlIFRDQU0gcmVzb3VyY2VzIHBlciBFLVRyZWUgaW5zdGFuY2UuIFRoaXMgd291 bGQgZGVwZW5kDQo+PiBvbg0KPj4gPnNwZWNpZmljIFRDQU0gaW1wbGVtZW50YXRpb24gKGUuZy4g Z3JhbnVsYXJpdHkgb2Ygc2VhcmNoIGtleSBsZW5ndGgpLg0KPj4gPg0KPj4gPkRDDQo+PiA+DQo+ PiA+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID5Gcm9tOiBCYWx1cywgRmxvcmluIFN0 ZWxpYW4gKEZsb3JpbikNCj4+ID5bbWFpbHRvOmZsb3Jpbi5iYWx1c0BhbGNhdGVsLWx1Y2VudC5j b21dDQo+PiA+U2VudDogVHVlc2RheSwgTWF5IDE1LCAyMDEyIDEwOjUzIFBNDQo+PiA+VG86IFNh bSBDYW87ICdKaWFuZ3l1YW5sb25nJzsgRGFuaWVsIENvaG47ICdBbGV4YW5kZXIgVmFpbnNodGVp bicNCj4+ID5DYzogbDJ2cG5AaWV0Zi5vcmcNCj4+ID5TdWJqZWN0OiBSRTogRGlzY3Vzc2lvbiBv biBmb3J3YXJkaW5nIHBlcmZvcm1hbmNlDQo+PiA+DQo+PiA+U2FtLA0KPj4gPg0KPj4gPj4gT2J2 aW91c2x5IHRoZSBmb3J3YXJkaW5nIHBlcmZvcm1hbmNlIG9mIER1YWwtVkxBTiB3aWxsIGJlIG11 Y2ggbG93ZXINCj4+ID50aGFuIHdoYXQgb2YgTXVsdGktUFcuDQo+PiA+DQo+PiA+U29ycnkgSSBj b3VsZCBub3Qga2VlcCB1cCB3aXRoIHNvbWUgb2YgdGhlIHRocmVhZHMgb24gdGhpcyBzdWJqZWN0 IGJ1dA0KPj4gPnRoZSBhYm92ZSBzdGF0ZW1lbnQgY2F1Z2h0IG15IGV5ZXMuIFdlIGhhdmUgYmVl biBkb2luZyBhbGwga2luZCBvZg0KPj4gPmVncmVzcyBvcGVyYXRpb25zIG9uIFZMQU5zIGluIHRo ZSBlZ3Jlc3MgUEUgZm9yIHRoZSBsYXN0IDggeWVhcnMgYW5kIEkNCj4+ID5hbSBub3QgYXdhcmUg b2YgYW55ICJtdWNoIGxvd2VyIiBmb3J3YXJkaW5nIHBlcmZvcm1hbmNlLiBBcyBmYXIgYXMgSQ0K Pj4gPmtub3cgdGhlIGNoaXBzZXRzIHVzZWQgaW4gdGhlIFBFcyBjYW4gZG8gdGhpcyBwcm9jZXNz aW5nIG5vIHByb2JsZW0uDQo+PiBEbw0KPj4gPnlvdSB3YW50IHRvIGNsYXJpZnkgd2hpY2gga2lu ZCBvZiBoYXJkd2FyZSBtYXkgaGF2ZSBwcm9ibGVtcz8NCj4+ID4NCj4+ID4+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+PiA+PiBGcm9tOiBsMnZwbi1ib3VuY2VzQGlldGYub3JnIFttYWls dG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZ10gT24NCj4+ID4+IEJlaGFsZiBPZiBTYW0gQ2FvDQo+ PiA+PiBTZW50OiBUdWVzZGF5LCBNYXkgMTUsIDIwMTIgNjozMiBBTQ0KPj4gPj4gVG86ICdKaWFu Z3l1YW5sb25nJzsgJ0RhbmllbCBDb2huJzsgJ0FsZXhhbmRlciBWYWluc2h0ZWluJw0KPj4gPj4g Q2M6IGwydnBuQGlldGYub3JnDQo+PiA+PiBTdWJqZWN0OiBSRTogRGlzY3Vzc2lvbiBvbiBmb3J3 YXJkaW5nIHBlcmZvcm1hbmNlDQo+PiA+Pg0KPj4gPj4gSGkgWXVhbmxvbmcsDQo+PiA+Pg0KPj4g Pj4gM3JkIG1hcHBpbmcgd2lsbCBtYWtlIGRhdGEgcGxhbmUgY29tcGxleCwgSSB0aGluay4gQW55 d2F5LCB3ZQ0KPj4gcmVhY2hlZA0KPj4gPmENCj4+ID4+IGNvbnNlbnN1cyBvbiBNdWx0aS1QVyBp bXBsZW1lbnRhdGlvbi4NCj4+ID4+DQo+PiA+PiBJZiB3ZSB1c2UgM3JkIG1hcHBpbmcsIEkgYWdy ZWUgd2l0aCB5b3VyIG9waW5pb24sIG1heWJlIGR1YWwtVkxBTg0KPj4gPnNlZW1zDQo+PiA+PiBz aW1wbGUsIGJ1dCAyIG1hcHBpbmcgaXMgZW5vdWdoLiBUaGVuIHdlIGNhbiBmb2N1cyBvbiBkYXRh IHBsYW5lDQo+PiA+PiBwZXJmb3JtYW5jZS4gV2hpbGUgc3RyaXBlIFBXIGxhYmVsIG91dCBvbiBl Z3Jlc3MgUEUsIGRhdGEtcGxhbmUNCj4+IGtub3dzDQo+PiA+PiBob3cgdG8gZm9yd2FyZCB0aGUg ZnJhbWVzIGZyb20gUFcsIHRvIFJvb3QgQUMgb3IgTGVhZiBBQyBvciBhbGwuIEJ1dA0KPj4gPmlm DQo+PiA+PiB3ZSB1c2UgRHVhbC1WTEFOLCBhZnRlciBzdHJpcCBQVyBsYWJlbCBvdXQsIGRhdGEg cGxhbmUgc2hvdWxkIHN0cmlwDQo+PiA+PiBWTEFOLUlEIG91dCBhbmQgdGhlbiBkb2VzIHNhbWUg Zm9yd2FyZGluZyB3b3JrIGFzIE11bHRpLVBXIGRvZXMuIFRoZQ0KPj4gPj4gbW9zdCBpbXBvcnRh bnQgaXMsIGRvIG9uZSBtb3JlIG9wZXJhdGlvbiB3aGlsZSBmb3J3YXJkaW5nIEUtVHJlZQ0KPj4g Pj4gZnJhbWVzLiBPYnZpb3VzbHkgdGhlIGZvcndhcmRpbmcgcGVyZm9ybWFuY2Ugb2YgRHVhbC1W TEFOIHdpbGwgYmUNCj4+ID4+IG11Y2ggbG93ZXIgdGhhbiB3aGF0IG9mIE11bHRpLVBXLg0KPj4g Pj4NCj4+ID4+IFJlZ2FyZHMsDQo+PiA+Pg0KPj4gPj4gWXVxdW4gKFNhbSkgQ2FvDQo+PiA+PiBF LW1haWw6IFl1cXVuLmNhb0BnbWFpbC5jb20NCj4+ID4+DQo+PiA+PiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPj4gPj4gRnJvbTogSmlhbmd5dWFubG9uZyBbbWFpbHRvOmppYW5neXVhbmxv bmdAaHVhd2VpLmNvbV0NCj4+ID4+IFNlbnQ6IFR1ZXNkYXksIE1heSAxNSwgMjAxMiA3OjAzIFBN DQo+PiA+PiBUbzogU2FtIENhbzsgJ0RhbmllbCBDb2huJzsgJ0FsZXhhbmRlciBWYWluc2h0ZWlu Jw0KPj4gPj4gQ2M6IGwydnBuQGlldGYub3JnDQo+PiA+PiBTdWJqZWN0OiBSRTogRGlzY3Vzc2lv biBvbiBFLVRyZWUgYW5kIEgtVlBMUw0KPj4gPj4NCj4+ID4+IFNlZSBteSBmdXJ0aGVyIGNvbW1l bnRzIGluIGxpbmUuDQo+PiA+Pg0KPj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ ID4+IEZyb206IFNhbSBDYW8gW21haWx0bzp5dXF1bi5jYW9AZ21haWwuY29tXQ0KPj4gPj4gU2Vu dDogVHVlc2RheSwgTWF5IDE1LCAyMDEyIDY6MTQgUE0NCj4+ID4+IFRvOiBKaWFuZ3l1YW5sb25n OyAnRGFuaWVsIENvaG4nOyAnQWxleGFuZGVyIFZhaW5zaHRlaW4nDQo+PiA+PiBDYzogbDJ2cG5A aWV0Zi5vcmcNCj4+ID4+IFN1YmplY3Q6IFJFOiBEaXNjdXNzaW9uIG9uIEUtVHJlZSBhbmQgSC1W UExTDQo+PiA+Pg0KPj4gPj4gSGkgWXVhbmxvbmcsDQo+PiA+Pg0KPj4gPj4gVGhhbmsgeW91IHZl cnkgbXVjaCBmb3IgeW91ciBjb21tZW50cy4gSSBkcmF3IHRoZSB0b3BvbG9neSB5b3UgZ2F2ZSwN Cj4+ID4+IGFuZCA3IFBXcyB3aWxsIGJlIGVzdGFibGlzaGVkIGlmIHdlIGZvbGxvdyAwMS4NCj4+ ID4+DQo+PiA+PiBSb290IEFDIC0tLS0gUEUgMSAtLS0tLSBQVyAxIC0tLS0tLS0tIFBFIDIgLS0t LS0gTGVhZiBfQUMNCj4+ID4+ICAgICAgICAgICAgICAgIHwgIFwgICAgICAgICAgICAgICAgIC8g IHx8DQo+PiA+PiAgICAgICAgICAgICAgICB8ICAgXCAgLz09PVBXIDYsNz09PSAgICB8fA0KPj4g Pj4gICAgICAgICAgICAgICAgIFBXIDIgIC0tLS0tUFcgNS0tLS0tLVwgIHx8DQo+PiA+PiAgICAg ICAgICAgICAgICB8ICAvLS0tLVJvb3QgUFcgMyAtLS0gXCB8fA0KPj4gPj4gUm9vdCBfQUMgLS0t LSBQRSAzICAgICAgICAgICAgICAgICAgICBQRSA0IC0tLS0tLSBSb290IEFDDQo+PiA+PiAgICAg ICAgICAgICAgICB8ICAgXCAgICAgICAgICAgICAgICAgIC8gIHwNCj4+ID4+ICAgICAgICAgICAg ICAgIHwgICAgLS0tLUxlYWYgUFcgNC0tLS0tICAgfA0KPj4gPj4gICAgICAgICAgICAgTGVhZiBB QyAgICAgICAgICAgICAgICAgICAgTGVhZiBBQw0KPj4gPj4gWWVzLCBvbiBQRSAzIHRoZXJlIGFy ZSBzZXZlcmFsIFBXcywgYnV0IGlmIHlvdSB3YW50IHRvIGNsYXJpZnkgaXQsDQo+PiA+PiB0aGVy ZSBhcmUgb25seSAzIHR5cGVzLCBvbmUgY2FuIGNhcnJ5IGZyYW1lcyBvcmlnaW5hdGVkIGZyb20g Um9vdA0KPj4gYW5kDQo+PiA+PiBMZWFmIEFDKG9uZSBlbmRwb2ludCBvZiB0aGlzIFBXIHNob3Vs ZCBiZSBSb290LW9ubHksIG90aGVyd2lzZSB0aGlzDQo+PiA+PiBpcyBpbnZhbGlkKSwgb25lIG9u bHkgY2FuIGNhcnJ5IGZyYW1lcyBmcm9tIFJvb3QgQUMsIGFuZCB0aGUgbGFzdA0KPj4gY2FuDQo+ PiA+PiBjYXJyeSBmcmFtZXMgZnJvbSBMZWFmIEFDcy4gT24gc2Vjb25kIHRob3VnaHRzLCB3ZSBz dGlsbCBjYW4NCj4+IGNsYXNzaWZ5DQo+PiA+PiB0aGUgUFdzIGludG8gMiBzZXRzLCBvbmUgaXMg TGVhZiBzZXQsIGFuZCBhbm90aGVyIGlzIFJvb3Qgc2V0LCBhbmQNCj4+ID4+IHRoZSB1bmlvbiBv ZiB0aGUgc2V0cyBMZWFmIGFuZCBSb290IGlzIHRoZSBQVyB3ZSBjYWxsZWQgaXQgYXMNCj4+ID4+ IGNvbXBhdGlibGUNCj4+ID5QVw0KPj4gPj4gKE1heWJlIHRoaXMgaXMgbm90IGNvcnJlY3QsIHdl IGNhbiBmaW5kIG9uZSBnb29kIHRlcm0gb24gdGhpcykuDQo+PiA+Pg0KPj4gPj4gU28gdGhpcyBv cHRpbWl6YXRpb24gc3RpbGwgZm9sbG93cyB0aGUgb3JpZ2luYWwgZGVzaWduIG9mIER1YWwtUFcN Cj4+ID4+IGFwcHJvYWNoLCBMZWFmIFBXIG9ubHkgY2FycmllcyBmcmFtZXMgZnJvbSBMZWFmIEFD OyBSb290LVBXIG9ubHkNCj4+ID4+IGNhcnJpZXMgZnJhbWVzIGZyb20gUm9vdCBBQy4gSXMgaXQg cmlnaHQ/DQo+PiA+Pg0KPj4gPj4gSSBkb24ndCBrbm93IHdoZXRoZXIgY2hpcCBjYW4gc3VwcG9y dCB0aGlzIGZvcndhcmRpbmcgYmVoYXZpb3IgZm9yDQo+PiA+PiBjb21wYXRpYmxlIFBXIG9yIG5v dCwgYnV0IGlmIHdlIGltcGxlbWVudCBpdCBpbiBOUCwgaXQgaXMgbmVhcmx5DQo+PiBzYW1lDQo+ PiA+PiBhcyBWUExTLiBUaGUgb25seSBkaWZmZXJlbmNlIGlzLCBzZXR1cCAyIG1hcHBpbmdzLCBv bmUgYmV0d2Vlbg0KPj4gPkxlYWYtQUNzDQo+PiA+PiBhbmQgTGVhZi1QV3MsIG9uZSBiZXR3ZWVu IFJvb3QtQUNzIGFuZCBSb290LVBXcy4gRm9yIHRyYWRpdGlvbmFsDQo+PiA+PiBWUExTLCB0aGVy ZSBpcyBvbmx5IG9uZSBtYXBwaW5nLg0KPj4gPj4NCj4+ID4+IFtKWV0gSXQgc2VlbXMgeW91IG1h eSBuZWVkIGEgM3JkIG1hcHBpbmc6IGZyb20gYm90aCByb290ICYgbGVhZiBBQw0KPj4gdG8NCj4+ ID5hDQo+PiA+PiBjb21wYXRpYmxlIFBXLg0KPj4gPj4gQlRXLCBmb3IgdGhlIGZvcndhcmRpbmcg YW5kIHJldmVyc2UgZGlyZWN0aW9uLCB0aGUgbWFwcGluZyBtYXkgYmUNCj4+ID4+IGFzeW1tZXRy aWMgZm9yIHlvdSBjb21wYXRpYmxlIFBXLg0KPj4gPj4NCj4+ID4+IEJhc2VkIG9uIG15IHVuZGVy c3RhbmRpbmcsIGFsbCBkcmFmdHMgc2hvdWxkIGhhdmUgc2ltaWxhciBtYXBwaW5nLg0KPj4gPj4N Cj4+ID4+IFtKWV0gRHVhbC1WTEFOIHNlZW1zIHNpbXBsZXIgaGVyZS4NCj4+ID4+DQo+PiA+PiBU aGFua3MsDQo+PiA+Pg0KPj4gPj4gU2FtDQo+PiA+Pg0KPj4gPj4NCj4+ID4+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+PiA+PiBGcm9tOiBKaWFuZ3l1YW5sb25nIFttYWlsdG86amlhbmd5 dWFubG9uZ0BodWF3ZWkuY29tXQ0KPj4gPj4gU2VudDogVHVlc2RheSwgTWF5IDE1LCAyMDEyIDM6 MzIgUE0NCj4+ID4+IFRvOiBTYW0gQ2FvOyAnRGFuaWVsIENvaG4nOyAnQWxleGFuZGVyIFZhaW5z aHRlaW4nDQo+PiA+PiBDYzogbDJ2cG5AaWV0Zi5vcmcNCj4+ID4+IFN1YmplY3Q6IFJFOiBEaXNj dXNzaW9uIG9uIEUtVHJlZSBhbmQgSC1WUExTDQo+PiA+Pg0KPj4gPj4gU2FtLA0KPj4gPj4NCj4+ ID4+IFRoYW5rcywgcGxlYXNlIHNlZSBteSBmdXJ0aGVyIGNvbW1lbnRzIHdpdGggW0pZXS4NCj4+ ID4+DQo+PiA+PiBPaywgd2UgZ28gb24gdGhlIGNhc2UgaW4geW91ciBtYWlsLCB3aGVyZSBQRTEg aGFzIG9uZSBSb290LW9ubHkgQUMsDQo+PiA+PiBBQzEsIGFuZA0KPj4gPj4gUEUyIGhhcyBvbmUg TGVhZi1vbmx5IEFDLCBBQzIuIEluIGdlbmVyYWwgd2UgY2FuIHNldHVwIDINCj4+ID4+ICJ1bmlk aXJlY3Rpb25hbCINCj4+ID4+IFBXcyAoYmlkaXJlY3Rpb25hbCBQVywgYnV0IGp1c3QgY2Fycnkg dW5pZGlyZWN0aW9uYWwgZnJhbWVzKSwgUm9vdC0NCj4+IFBXDQo+PiA+PiB3aGljaCBjYXJyaWVz IGZyYW1lcyBvcmlnaW5hdGVkIGZyb20gQUMxIGFuZCBMZWFmLVBXIHdoaWNoIGNhcnJpZXMNCj4+ ID4+IGZyYW1lcyBvcmlnaW5hdGVkIGZyb20gQUMyLiBCdXQgb25seSBvbmUgUFcgYWxzbyBjYW4g d29yaywganVzdCBhcw0KPj4gPnNvbWUNCj4+ID4+IG1lbWJlcnMgY29tbWVudGVkLiBPaywgd2Ug c2V0dXAgb25lIFBXIGJldHdlZW4gUEUxIGFuZCBQRTIsIHdlIGNhbg0KPj4gPmNhbGwNCj4+ID4+ IHRoaXMgUFcgYXMgY29tcGF0aWJsZSBQVyBvciBzb21ldGhpbmcgZWxzZS4gRnJhbWVzIG9yaWdp bmF0ZWQgZnJvbQ0KPj4gPlJvb3QNCj4+ID4+IG9yIGxlYWYgQUNzIHdpbGwgYmUgY2FycmllZCB2 aWEgdGhpcyBQVy4gSXRzIGZvcndhcmRpbmcgYmVoYXZpb3IgaXMNCj4+ID4+IGZ1bGx5IHNhbWUg YXMgd2hhdCB0cmFkaXRpb25hbCBWUExTIGRpZCwgTUFDIGxlYXJuaW5nIG9uIEFDIG9yIFBXIGlu DQo+PiA+PiBvbmUgRS1UcmVlLiBPciBzYXksIGlmIG9uZSBQRSBoYXMgUm9vdC1vbmx5IEFDcywg aXQgd2lsbCBzZXR1cCBvbmUNCj4+IFBXDQo+PiA+PiB3aXRoIGFub3RoZXIgUEUsIFJvb3Qtb25s eSwgTGVhZi1vbmx5IG9yIFJvb3QtTGVhZi1NaXhlZC4gSWYgMiBQRXMNCj4+ID4+IGFyZSByb290 LUxlYWYtTWl4ZWQgb3Igb3RoZXIgY2FzZXMsIHRoZW4gMiBQV3Mgd2lsbCBiZSBlc3RhYmxpc2hl ZC4NCj4+ID4+IEFzIHlvdSBrbm93LCB0aGlzIGNhbiBiZSBkb25lIG9uIGNvbnRyb2wgcGxhbmUu DQo+PiA+Pg0KPj4gPj4gW0pZXSBBc3N1bWUgdGhlcmUgYXJlIDIgb3RoZXIgbm9kZXMgUEUzICYg UEU0IGluIHRoaXMgbmV0d29yaw0KPj4gPnNjZW5hcmlvLA0KPj4gPj4gYW5kIGJvdGggUEUzIGFu ZCBQRTQgaGF2ZSBib3RoIHJvb3QgYW5kIGxlYWYgQUNzLCB0aGVuIHRoZXJlIGFyZQ0KPj4gPj4g Y29tcGF0aWJsZSBQV3MgZnJvbSBQRTMgd2hpY2ggbWF5IGNhcnJ5IGJvdGggcm9vdCBhbmQgbGVh ZiB0cmFmZmljDQo+PiA+PiAodG8gUEUxKSwgd2hpY2ggbWF5IGNhcnJ5IG9ubHkgcm9vdCB0cmFm ZmljICh0byBQRTIpOyBhbmQgZnVydGhlcg0KPj4gPj4gdGhlcmUNCj4+ID5hcmUNCj4+ID4+IHJv b3QgUFcgYW5kIGxlYWYgUFcgdG8gUEU0LiBUaHVzLCB0aGUgVlNJIG9uIFBFMyBoYXMgYXQgbGVh c3QgNA0KPj4gPj4gZGlmZmVyZW50IHR5cGVzIG9mIFBXIHRyYW5zbWl0dGluZyBiZWhhdmlvdXJz IHdpdGggcmVnYXJkIHRvIHRoZQ0KPj4gPkUtVHJlZQ0KPj4gPj4gdHJhZmZpYy4gSW4gdGhlIHJl dmVyc2UgZGlyZWN0aW9uLCB0aGUgVlNJIG9uIFBFMyBmdXJ0aGVyIGhhcyBhdA0KPj4gPj4gbGVh c3QNCj4+ID4+IDQgZGlmZmVyZW50IHR5cGVzIG9mIFBXIHJlY2VpdmluZyBiZWhhdmlvdXJzLiBO b3Qgc3VyZSBob3cgeW91IHdpbGwNCj4+ID4+IGFjY29tbW9kYXRlIGZvciB0aGVzZSBQV3MgaW4g Ym90aCB0aGUgZGF0YSBwbGFuZSBhbmQgY29udHJvbCBwbGFuZS4NCj4+ID4+DQo+PiA+PiBSZWdh cmRzLA0KPj4gPj4gWXVhbmxvbmcNCj4+ID4+DQo+PiA+PiBJcyB0aGlzIGNsZWFyIGZvciB5b3U/ IElzIHRoaXMgbmVjZXNzYXJ5IHRvIG9wdGltaXplIFBXIHNldHVwIGluDQo+PiB0aGlzDQo+PiA+ PiBjYXNlPw0KPj4gPj4NCj4+ID4+IE1heWJlIHdlIG5lZWQgdG8gYWRkIG9uZSBwYXJhZ3JhcGgg b24gZm9yd2FyZGluZyBiZWhhdmlvci4NCj4+ID4+DQo+PiA+PiBBZ2FpbiB0aGFuayB5b3UgdmVy eSBtdWNoIGZvciB5b3VyIGNvbW1lbnRzLA0KPj4gPj4NCj4+ID4+IFNhbQ0KPj4gPj4NCj4+ID4+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+PiBGcm9tOiBKaWFuZ3l1YW5sb25nIFtt YWlsdG86amlhbmd5dWFubG9uZ0BodWF3ZWkuY29tXQ0KPj4gPj4gU2VudDogVHVlc2RheSwgTWF5 IDE1LCAyMDEyIDEwOjI3IEFNDQo+PiA+PiBUbzogU2FtIENhbzsgJ0RhbmllbCBDb2huJzsgJ0Fs ZXhhbmRlciBWYWluc2h0ZWluJw0KPj4gPj4gQ2M6IGwydnBuQGlldGYub3JnDQo+PiA+PiBTdWJq ZWN0OiBSRTogRGlzY3Vzc2lvbiBvbiBFLVRyZWUgYW5kIEgtVlBMUw0KPj4gPj4NCj4+ID4+IFBs ZWFzZSBzZWUgbXkgY29tbWVudHMgaW4gbGluZS4NCj4+ID4+DQo+PiA+PiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPj4gPj4gRnJvbTogU2FtIENhbyBbbWFpbHRvOnl1cXVuLmNhb0BnbWFp bC5jb21dDQo+PiA+PiBTZW50OiBNb25kYXksIE1heSAxNCwgMjAxMiA4OjMxIFBNDQo+PiA+PiBU bzogSmlhbmd5dWFubG9uZzsgJ0RhbmllbCBDb2huJzsgJ0FsZXhhbmRlciBWYWluc2h0ZWluJw0K Pj4gPj4gQ2M6IGwydnBuQGlldGYub3JnDQo+PiA+PiBTdWJqZWN0OiBSRTogRGlzY3Vzc2lvbiBv biBFLVRyZWUgYW5kIEgtVlBMUw0KPj4gPj4NCj4+ID4+IEhpIFl1YW5sb25nLA0KPj4gPj4NCj4+ ID4+IFdlIGhhdmUgZGlzY3Vzc2VkIHRoaXMgaW4gYW5vdGhlciB0aHJlYWQuIEluIGZhY3QsIERh bmllbCBvciBJIGhhdmUNCj4+ID4+IGdpdmVuIHRoZSBhbnN3ZXJzIHRvIHRoZSBxdWVzdGlvbnMg eW91IHJhaXNlZCBoZXJlIGZvciBzZXZlcmFsIHRpbWUNCj4+ID46KS4NCj4+ID4+IElmIHdlIGRv IGluIHRoaXMgd2F5LCB3ZSB3aWxsIHJlYWNoIGRlYWRsb2NrIGFuZCBjYW4gbm90IG1vdmUNCj4+ IGZvcndhcmQNCj4+ID4+IDopLiBJIHRyeSB0byBleHBsYWluIGl0IGFnYWluLg0KPj4gPj4NCj4+ ID4+IFtKWV0gSSB3aWxsIGFwb2xvZ2l6ZSBpZiB5b3UgaGFkIGV2ZXIgcHJvdmlkZWQgc3VjaCBh bnN3ZXJzIGJlZm9yZSwNCj4+ID5hbmQNCj4+ID4+IHlvdSBtYXkganVzdCByZWZlciB0byB0aGUg bGlua3MgcmF0aGVyIHRoYW4gcmVwZWF0IHRoZSBleHBsYW5hdGlvbi4NCj4+ID4+IEFzIHlvdSBj YW4gc2VlLCBJIGp1c3QgdHJ5IHRvIHVuZGVyc3RhbmQgdGhlIG1lY2hhbmlzbSBvZiAyUFcgYW5k DQo+PiBpdHMNCj4+ID4+IGltcGxpY2F0aW9ucywgYnV0IHRoZSBJLUQgZG9lcyBub3QgaW5jbHVk ZSBlbm91Z2ggaW5mb3JtYXRpb24uDQo+PiA+Pg0KPj4gPj4gQXMgeW91IGtub3csIGluaXRpYWwg ZGVzaWduIHdlIHdpbGwgc2V0dXAgMiBQV3MgYWxsIHRoZSB0aW1lIChpZiBkbw0KPj4gPj4gaW4g dGhpcyB3YXksIEkgdGhpbmsgdGhhdCB5b3UgaGF2ZSBubyBxdWVzdGlvbiksDQo+PiA+Pg0KPj4g Pj4gW0pZXSBJIHdpbGwgYmUgY29uY2VybmVkIHdpdGggdGhlIG9wZXJhdGlvbmFsIGNvbXBsZXhp dHkgb2YgdGhpcw0KPj4gPj4gYXBwcm9hY2guDQo+PiA+Pg0KPj4gPj4gYnV0IGluIG1vc3QgY2Fz ZXMgMiBQV3MgYXJlIG5vdA0KPj4gPj4gbmVjZXNzYXJ5LiBTbyBpbiAwMSB2ZXJzaW9uLCB3ZSBv cHRpbWl6ZSBpdC4NCj4+ID4+DQo+PiA+PiAiUm9vdC1vbmx5IFZTSSA8LT4gYW55IFZTSTogb25s eSByb290IFBXIHJlcXVpcmVkIg0KPj4gPj4gIkxlYWYtb25seSBWU0kgPC0+IGxlYWYtb25seSBW U0k6IG5vIFBXcyByZXF1aXJlZCINCj4+ID4+DQo+PiA+PiBJbiBvdGhlciBjYXNlcyAyIFBXcyBh cmUgbmVlZGVkLiBJZiBzbywgIkxlYWYtb25seSAtPiByb290LW9ubHkgPQ0KPj4gb25lDQo+PiA+ PiBsZWFmIFBXIiBpcyBub3QgY29ycmVjdDogT24gTGVhZi1vbmx5IHNpZGUsIHllcywgb25lIExl YWYtb25seSBQVyBpcw0KPj4gPj4gY3JlYXRlZCBiZXR3ZWVuIExvY2FsIExlYWYgdHlwZSB3aXRo IHJlbW90ZSBSb290IHR5cGU7IG9uIHJvb3Qtb25seQ0KPj4gPj4gc2lkZSwgb25lIHJvb3Qtb25s eSBQVyBpcyBjcmVhdGVkLiBNYXliZSBpdCBpcyBiZXR0ZXIgdG8gY2FsbCB0aGlzDQo+PiBhcw0K Pj4gPj4gY29tcGF0aWJsZSBvciBtaXhlZCBQVy4gU28gdGhlIGxlZnQgaXRlbXMgeW91IGxpc3Qg YXJlIG5vdCBjb3JyZWN0DQo+PiA+PiBmb3IgbXVsdGlfUFcgc29sdXRpb24uDQo+PiA+Pg0KPj4g Pj4gW0pZXSBUaGlzIGlzIHNvbWV0aGluZyBuZXcsIHJpZ2h0PyBUbyBiZSBob25lc3QsIEkgY291 bGQgbm90DQo+PiA+dW5kZXJzdGFuZA0KPj4gPj4gd2hhdCBpcyB5b3VyIHBvaW50OiBkb2Vzbid0 IHRoZSBtaXhlZCBQVyBhcyB5b3UgY2FsbGVkIGFsc28gY29uc2lzdA0KPj4gPj4gb2Ygb25lIExl YWYtb25seSBQVyBpbiBvbmUgZGlyZWN0aW9uIGFuZCBvbmUgcm9vdC1vbmx5IFBXIGluIHRoZQ0K Pj4gPj4gb3RoZXIgZGlyZWN0aW9uPw0KPj4gPj4gRnVydGhlcm1vcmUsIHRoZSBjYXNlIHlvdSB0 b29rIGlzIGFsc28gb25lIGNhc2UgaW4geW91ciBndWlkZWxpbmUNCj4+ID4+ICJSb290LW9ubHkg VlNJIDwtPiBhbnkgVlNJOiBvbmx5IHJvb3QgUFcgcmVxdWlyZWQiLCBkb24ndCB5b3UgdGhpbmsN Cj4+ID4+IHRoYXQgb25seSBvbmUgcm9vdCBQVyBpcyByZXF1aXJlZCBmb2xsb3dpbmcgdGhpcyBn dWlkZWxpbmU/DQo+PiA+PiBBY3R1YWxseSwgSSBkb24ndCBjYXJlIG11Y2ggYWJvdXQgd2hhdCBp cyB0aGUgYmlkaXJlY3Rpb25hbCBQVyBvcg0KPj4gPj4gdW5pZGlyZWN0aW9uYWwgUFcgY2FsbGVk LCBidXQgaG93IGNhbiBhIFZTSSBzdXBwb3J0IHN1Y2ggYSBtaXhlZA0KPj4gPj4gc2NlbmFyaW9z Og0KPj4gPj4gdHJhZGl0aW9uYWwgVlNJIGFzc3VtZXMgb25seSBvbmUgUFcgaXMgcmVxdWlyZWQg Zm9yIGVhY2ggcGVlciBWU0ksDQo+PiA+PiBhbmQgaXRzIE1BQyBsZWFuaW5nIGlzIGJhc2VkIG9u IGJpZGlyZWN0aW9uYWwgUFcuIEJ1dCBmb3IgMlBXLCB0aGVyZQ0KPj4gPj4gYXJlIGJpZGlyZWN0 aW9uYWwgcm9vdCBQVywgYmlkaXJlY3Rpb25hbCBsZWFmIFBXLCBtaXhlZCBQVywgZXRjLi4uLA0K Pj4gPj4gaG93IHRvIHN1cHBvcnQgdGhlc2Uga2luZHMgb2YgUFdzIGluIHRoZSBzYW1lIFZTSSBp cyBteSB0b3AgY29uY2Vybi4NCj4+ID4+DQo+PiA+PiBCVFcsIEkgZ3Vlc3MgeW91IGFsc28gY2Fy ZSB0aGlzIGNhc2Ugd2UgYWxzbyBoYXZlIGRpc2N1c3NlZCBiZWZvcmU6DQo+PiA+Zm9yDQo+PiA+ PiBleGFtcGxlLCBpZiB3ZSBjb25maWd1cmUgb25lIExlYWYgQUMgb24gcm9vdC1vbmx5IFBFICh0 aGVuIGl0IHdpbGwNCj4+IGJlDQo+PiA+PiByb290LWxlYWYtbWl4ZWQgUEUpLCB3ZSB3aWxsIHRl YXJkb3duIHRoZSBjb21wYXRpYmxlIFBXIGFuZCByZS1zZXR1cA0KPj4gPj4gUFdzIGFnYWluIHdp dGggMDEuDQo+PiA+PiBbSlldIFRoaXMgd2FzIGRpc2N1c3NlZCBpbiB0aGUgZW1haWxzIGluZGVl ZC4NCj4+ID4+DQo+PiA+PiBSZWdhcmRzLA0KPj4gPj4NCj4+ID4+IFl1cXVuIChTYW0pIENhbw0K Pj4gPj4gRS1tYWlsOiBZdXF1bi5jYW9AZ21haWwuY29tDQo+PiA+Pg0KPj4gPj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4+IEZyb206IEppYW5neXVhbmxvbmcgW21haWx0bzpqaWFu Z3l1YW5sb25nQGh1YXdlaS5jb21dDQo+PiA+PiBTZW50OiBNb25kYXksIE1heSAxNCwgMjAxMiA3 OjEwIFBNDQo+PiA+PiBUbzogRGFuaWVsIENvaG47IEFsZXhhbmRlciBWYWluc2h0ZWluOyBTYW0g Q2FvDQo+PiA+PiBDYzogbDJ2cG5AaWV0Zi5vcmcNCj4+ID4+IFN1YmplY3Q6IFJFOiBEaXNjdXNz aW9uIG9uIEUtVHJlZSBhbmQgSC1WUExTDQo+PiA+Pg0KPj4gPj4gSGkgRGFuaWVsLA0KPj4gPj4N Cj4+ID4+IEZpbmUsIG5vdyBpdCBzZWVtcyBtb3JlIGluIGxpbmUgd2l0aCB3aGF0IHdlIGhhZCBw cm9wb3NlZCBpbiAyVkxBTjoNCj4+IGENCj4+ID4+IHNwb2tlIFBXIGJlaGF2ZXMgbGlrZSByb290 L2xlYWYgQUMgZm9yIGEgUEUtci4NCj4+ID4+DQo+PiA+PiBCdXQgdGhlIHNhbWUgcHJvYmxlbSBt YXkgYWxzbyBhcHBseSB0byB0aGUgcm9vdC9zcG9rZSAiY29yZSBQVyIgZm9yDQo+PiA+PiBNdWx0 aS1QVzoNCj4+ID4+IEFjY29yZGluZyB0byBNdWx0aS1QVywgb25seSBvbmUgUFcgaXMgcmVxdWly ZWQgYmV0d2VlbiB0d28gUEVzDQo+PiBleGNlcHQNCj4+ID4+IHdoZW4gYm90aCBQRXMgYXJlIG1p eGVkIHdpdGggcm9vdCBhbmQgbGVhZiwgc28gdGhlc2UgUFdzIG1heSBiZQ0KPj4gPj4gZm9ybWVk IGJ5IGNvbWJpbmF0aW9ucyBvZiB0aGUgZm9sbG93aW5nIHVuaWRpcmVjdGlvbmFsIFBXIGNhc2Vz DQo+PiA+PiAoZXh0cmFjdGVkDQo+PiA+YW5kDQo+PiA+PiBhZGFwdGVkIGZyb20gSm9zaCdzIGVt YWlsKToNCj4+ID4+IFJvb3Qtb25seSAtPiBhbnkgVlNJID0gb25lIHJvb3QgUFcNCj4+ID4+IExl YWYtb25seSAtPiByb290LW9ubHkgPSBvbmUgbGVhZiBQVw0KPj4gPj4gTGVhZi1vbmx5IC0+IG1p eGVkID0gb25lIGxlYWYgUFcNCj4+ID4+IE1peGVkIC0+IHJvb3Qtb25seSA9IG9uZSAocm9vdCts ZWFmKSBQVyBNaXhlZCAtPiBsZWFmLW9ubHkgPSBvbmUNCj4+ID4+IChyb290K2xlYWYpIFBXDQo+ PiA+Pg0KPj4gPj4gSSBoYXZlIGEgY29uY2VybiB0aGF0IHRoZSBmb3J3YXJkaW5nIHBsYW5lIG9m IFBFIHRvIGltcGxlbWVudCB0aGlzDQo+PiA+d2lsbA0KPj4gPj4gYmUgdmVyeSBkaWZmZXJlbnQg ZnJvbSB0aGUgdHJhZGl0aW9uYWwgVlBMUy4NCj4+ID4+DQo+PiA+PiBSZWdhcmRzLA0KPj4gPj4g WXVhbmxvbmcNCj4+ID4+DQo+PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gPj4g RnJvbTogRGFuaWVsIENvaG4gW21haWx0bzpEYW5pZWxDQG9yY2tpdC5jb21dDQo+PiA+PiBTZW50 OiBNb25kYXksIE1heSAxNCwgMjAxMiA1OjAwIFBNDQo+PiA+PiBUbzogSmlhbmd5dWFubG9uZzsg QWxleGFuZGVyIFZhaW5zaHRlaW47IFNhbSBDYW8NCj4+ID4+IENjOiBsMnZwbkBpZXRmLm9yZw0K Pj4gPj4gU3ViamVjdDogUkU6IERpc2N1c3Npb24gb24gRS1UcmVlIGFuZCBILVZQTFMNCj4+ID4+ DQo+PiA+PiBIaSBZdWFubG9uZywNCj4+ID4+DQo+PiA+PiBMaWtlIEkgd3JvdGUgYmVsb3csIHJv b3QvbGVhZiBzcG9rZSBQVyBiZWhhdmUgbGlrZSByb290L2xlYWYgQUMsIG5vdA0KPj4gPj4gbGlr ZSByb290L3Nwb2tlICJjb3JlIFBXIi4gU28gbm8gY2hhbmdlcyB0byBmb3J3YXJkaW5nIHBsYW5l IG9uY2UNCj4+ID4+IHRoaXMgaXMgdW5kZXJzdG9vZC4NCj4+ID4+DQo+PiA+PiBEQw0KPj4gPj4N Cj4+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+PiBGcm9tOiBKaWFuZ3l1YW5s b25nIFttYWlsdG86amlhbmd5dWFubG9uZ0BodWF3ZWkuY29tXQ0KPj4gPj4gU2VudDogTW9uZGF5 LCBNYXkgMTQsIDIwMTIgMTE6MzYgQU0NCj4+ID4+IFRvOiBEYW5pZWwgQ29objsgQWxleGFuZGVy IFZhaW5zaHRlaW47IFNhbSBDYW8NCj4+ID4+IENjOiBsMnZwbkBpZXRmLm9yZw0KPj4gPj4gU3Vi amVjdDogUkU6IERpc2N1c3Npb24gb24gRS1UcmVlIGFuZCBILVZQTFMNCj4+ID4+DQo+PiA+PiBE YW5pZWwsIHBsZWFzZSBzZWUgbXkgY29tbWVudHMgaW4gbGluZS4NCj4+ID4+DQo+PiA+PiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gPj4gRnJvbTogRGFuaWVsIENvaG4gW21haWx0bzpE YW5pZWxDQG9yY2tpdC5jb21dDQo+PiA+PiBTZW50OiBNb25kYXksIE1heSAxNCwgMjAxMiAzOjM3 IFBNDQo+PiA+PiBUbzogSmlhbmd5dWFubG9uZzsgQWxleGFuZGVyIFZhaW5zaHRlaW47IFNhbSBD YW8NCj4+ID4+IENjOiBsMnZwbkBpZXRmLm9yZw0KPj4gPj4gU3ViamVjdDogUkU6IERpc2N1c3Np b24gb24gRS1UcmVlIGFuZCBILVZQTFMNCj4+ID4+DQo+PiA+PiBIaSBZdWFubG9uZywNCj4+ID4+ DQo+PiA+PiBBcyBJIHNlZSBpdCwgZm9yIHRoZSBQRS1yIHNwb2tlIChmaWd1cmUgNCBpbiBSRkMg NDc2Mikgd2UgZXN0YWJsaXNoDQo+PiBhDQo+PiA+PiBzaW5nbGUgUFcgcGVyIEFDIC0gcm9vdCBQ VyBmb3Igcm9vdCBBQyBhbmQgbGVhZiBQVyBmb3IgbGVhZiBBQy4gV2l0aA0KPj4gPj4gbG9jYWwg Y29uZmlndXJhdGlvbiBhdCB0aGUgUEUtcnMgYXMgcGFydCBvZiB0aGUgc3Bva2UgUFcNCj4+IHBy b3Zpc2lvbmluZy4NCj4+ID4+IEFuZCB0aGUgUEUtcnMgd2lsbCB0cmVhdCByb290L2xlYWYgc3Bv a2UgUFdzIGV4YWN0bHkgYXMgaXQgdHJlYXQNCj4+ID4+IHJvb3QvbGVhZiBBQ3MuIFNvIHdoZW4g bGVhZi1vcmlnaW5hdGVkIEJVTSB0cmFmZmljIGFycml2ZXMgZnJvbSB0aGUNCj4+ID4+IGNvcmUg KG92ZXIgYSBsZWFmIFBXKSwgaXQgd2lsbCBiZSBmb3J3YXJkZWQgb3ZlciBhbGwgcm9vdCBzcG9r ZSBQV3MNCj4+ID5idXQNCj4+ID4+IG5vdCBvbiB0aGUgbGVhZiBzcG9rZSBQV3MuDQo+PiA+Pg0K Pj4gPj4gW0pZXSBTbyBpbiB0aGUgcmV2ZXJzZSBkaXJlY3Rpb24sIHlvdSBuZWVkIHRvIHRyYW5z cG9ydCBib3RoIHJvb3QNCj4+IGFuZA0KPj4gPj4gbGVhZiB0cmFmZmljIGZyb20gUEUtcnMgb3Zl ciBhIHJvb3QgUFcgdG8gUEUtciwgYW5kIHRyYW5zcG9ydCByb290DQo+PiA+PiB0cmFmZmljIG92 ZXIgYSBsZWFmIFBXLiBJdCBzZWVtcyBhZ2FpbnN0IHRoZSBkZWZpbml0aW9uIG9mIHJvb3QgUFcN Cj4+ID4+IGFuZCBsZWFmIFBXIGluIHRoZSBtdWx0aS1QVyBkcmFmdC4gRG9uJ3QgdGhpcyBtYWtl IHRoZSBmb3J3YXJkaW5nDQo+PiA+PiBwbGFuZSBvZiBQRS1ycyBtb3JlIGNvbXBsZXg/DQo+PiA+ Pg0KPj4gPj4gVGhlIGZvcndhcmRpbmcgcGxhbmUgaXMgZXhhY3RseSB0aGUgc2FtZSBhcyBkZXNj cmliZWQgaW4gdGhlIG11bHRpLQ0KPj4gUFcNCj4+ID4+IGRyYWZ0LCB3aGVyZSBzcG9rZSBQV3Mg YXJlIHRyZWF0ZWQgZXhhY3RseSBsaWtlIEFDcy4NCj4+ID4+DQo+PiA+PiBSZWdhcmRzLA0KPj4g Pj4NCj4+ID4+IERhbmllbA0KPj4gPj4NCj4+ID4+DQo+PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPj4gPj4gRnJvbTogSmlhbmd5dWFubG9uZyBbbWFpbHRvOmppYW5neXVhbmxvbmdA aHVhd2VpLmNvbV0NCj4+ID4+IFNlbnQ6IEZyaWRheSwgTWF5IDExLCAyMDEyIDU6MDMgQU0NCj4+ ID4+IFRvOiBEYW5pZWwgQ29objsgQWxleGFuZGVyIFZhaW5zaHRlaW47IFNhbSBDYW8NCj4+ID4+ IENjOiBsMnZwbkBpZXRmLm9yZw0KPj4gPj4gU3ViamVjdDogUkU6IERpc2N1c3Npb24gb24gRS1U cmVlIGFuZCBILVZQTFMNCj4+ID4+DQo+PiA+PiBIaSBEYW5pZWwgYW5kIGFsbCwNCj4+ID4+DQo+ PiA+PiBXaGVuIHlvdSBzZXQgdXAgdHdvIFBXcyBmcm9tIHRoZSBQRS1ycyB0byBhIFBFLXIgZm9y IGVhY2ggb2YgaXRzIEFDLA0KPj4gPmRvDQo+PiA+PiB5b3UgbWVhbiB0aGF0IG9uZSBQVyBpcyBi aWRpcmVjdGlvbmFsIHJvb3QgUFcgYW5kIHRoZSBvdGhlciBpcw0KPj4gPj4gYmlkaXJlY3Rpb25h bCBsZWFmIFBXPw0KPj4gPj4gTXkgY29uY2VybiBpczogd2hlcmUgc2hvdWxkIHRoZSBsZWFmIHRy YWZmaWMgYmUgZmlsdGVyZWQsIG9uIHRoZQ0KPj4gPj4gUEUtcnMgb3Igb24gdGhlIFBFLXI/DQo+ PiA+PiBJZiBmaWx0ZXJlZCBvbiB0aGUgUEUtciwgdGhlbiBsb3RzIG9mIGJhbmR3aWR0aCB3aWxs IGJlIHdhc3RlZCAoZm9yDQo+PiA+PiBleGFtcGxlLCBpZiB0aGUgUEUtciBpcyBhdHRhY2hlZCB3 aXRoIDkgbGVhZnMsIHRoZW4gdGhlIEJVTSB0cmFmZmljDQo+PiA+PiBmcm9tIG9uZSBvZiBpdHMg bGVhZnMgd2lsbCBiZSBtdWx0aXBsaWVkIGJ5IDggdGltZXMsIGFuZCBiZQ0KPj4gZm9yd2FyZGVk DQo+PiA+PiBieSB0aGUgUEUtcnMgdG8gdGhlIHNhbWUgUEUtcikuDQo+PiA+PiBJZiBmaWx0ZXJl ZCBvbiB0aGUgUEUtcnMsIG5vdCBzdXJlIGhvdyB5b3Ugd2lsbCBkZXNpZ24gaXRzDQo+PiBmb3J3 YXJkaW5nDQo+PiA+PiBwbGFuZSwgY2FuIHlvdSBnaXZlIGEgaGludD8NCj4+ID4+DQo+PiA+PiBU aGFua3MsDQo+PiA+PiBZdWFubG9uZw0KPj4gPj4NCj4+ID4+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPj4gPj4gRGF0ZTogV2VkLCA5IE1heSAyMDEyIDA5OjE2OjM2ICswMzAwDQo+ PiA+PiBGcm9tOiAiRGFuaWVsIENvaG4iIDxEYW5pZWxDQG9yY2tpdC5jb20+DQo+PiA+PiBUbzog IkFsZXhhbmRlciBWYWluc2h0ZWluIiA8QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+ LA0KPj4gPiJTYW0NCj4+ID4+ICAgICAgIENhbyIgPHl1cXVuLmNhb0BnbWFpbC5jb20+LCA8bDJ2 cG5AaWV0Zi5vcmc+DQo+PiA+PiBDYzogbGl6aG9uZy5qaW5AenRlLmNvbS5jbg0KPj4gPj4gU3Vi amVjdDogUkU6IERpc2N1c3Npb24gb24gRS1UcmVlIGFuZCBILVZQTFMNCj4+ID4+IE1lc3NhZ2Ut SUQ6IDw0NEY0RTU3OUE3NjQ1ODRFQTlCREZEMDdEMENBMDgxMzA3ODBDQkE2QHRsdm1haWwxPg0K Pj4gPj4gQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyAgICAgY2hhcnNldD0iSVNPLTIwMjItSlAi DQo+PiA+Pg0KPj4gPj4gSGkgU2FzaGEsDQo+PiA+Pg0KPj4gPj4gSXQncyBhY3R1YWxseSB2ZXJ5 IHNpbXBsZS4gQSBmcmFtZSB0aGF0IG9yaWdpbmF0ZWQgaW4gYSByb290IEFDIGlzDQo+PiA+PiBh bHdheXMgdHJhbnNtaXR0ZWQgb25seSBpbiByb290IFBXLCBubyBtYXR0ZXIgd2hhdCB0aGUgZnJh bWUgdHlwZQ0KPj4gPj4gKGtub3duL3Vua25vd24gdW5pY2FzdCBvciBicm9hZGNhc3QpLiBUaGlz IGlzIGhvdyB0aGUgZnJhbWUgc291cmNlDQo+PiA+PiBpbmZvcm1hdGlvbiBpcyBwcm9wYWdhdGVk IGFjcm9zcyB0aGUgVlBMUy4gU28gaW4gdGhlIEgtVlBMUyBleGFtcGxlLA0KPj4gPj4gdGhlIFBF LXIgd2lsbCBuZXZlciBmb3J3YXJkIGEgZnJhbWUgcmVjZWl2ZWQgb3ZlciBhIHJvb3QgUFcgb24g YW55DQo+PiA+bGVhZg0KPj4gPj4gUFcsIG9ubHkgb24gcm9vdCBQV3MgKHRvd2FyZCB0aGUgY29y ZSBvciB0b3dhcmQgb3RoZXIgc3Bva2VzKS4NCj4+ID4+DQo+PiA+PiBIb3BlIHRoaXMgY2xhcmlm aWVzIGl0LCByZWdhcmRzLA0KPj4gPj4NCj4+ID4+IERhbmllbA0KPj4gPj4NCj4+ID4+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+PiBGcm9tOiBsMnZwbi1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZ10gT24NCj4+ID4+IEJlaGFsZiBPZiBBbGV4 YW5kZXIgVmFpbnNodGVpbg0KPj4gPj4gU2VudDogV2VkbmVzZGF5LCBNYXkgMDksIDIwMTIgNzo1 OSBBTQ0KPj4gPj4gVG86IFNhbSBDYW87IGwydnBuQGlldGYub3JnDQo+PiA+PiBDYzogbGl6aG9u Zy5qaW5AenRlLmNvbS5jbg0KPj4gPj4gU3ViamVjdDogUkU6IERpc2N1c3Npb24gb24gRS1UcmVl IGFuZCBILVZQTFMNCj4+ID4+DQo+PiA+PiBTYW0sIExpemhvbmcgYW5kIGFsbCwNCj4+ID4+IFlv dSd2ZSB3cml0dGVuIHRoYXQgaW4gdGhlIHR3by1QVyBzb2x1dGlvbiBjb21iaW5lZCB3aXRoIEgt VlBMUyB0aGUNCj4+ID5QRS0NCj4+ID4+IHIgbXVzdCBzZXQgdXAgdHdvIFBXcyB3aXRoIGVhY2gg TVRVLXMuDQo+PiA+Pg0KPj4gPj4gSWYgdGhpcyBpcyB0aGUgY2FzZSwgd2hhdCBraW5kIG9mIGZv cndhcmRpbmcgbG9naWMgc2hvdWxkIGJlIHVzZWQgdG8NCj4+ID4+IHByZXZlbnQgc2VuZGluZyBh IEJVTSBmcmFtZSByZWNlaXZlZCBmcm9tIGEgcm9vdC1QVyB0byBhIGdpdmVuIE1UVS0NCj4+IFM6 DQo+PiA+PiAtIGJhY2sgdG8gdGhlIHNhbWUgTVRVLVMgb24gdGhlIGNvcnJlc3BvbmRpbmcgbGVh Zi1QVz8NCj4+ID4+IC0gdHdpY2UgKHRvIGJvdGggcm9vdC1QVyBhbmQgTGVhZi1QVykgdG8gYW5v dGhlciBNVFUtcz8gQW5kLCBCVFcsDQo+PiBob3cNCj4+ID4+IGlzIHRoZSBQVyBzZWxlY3RlZCBp biB0aGlzIGNhc2U/DQo+PiA+Pg0KPj4gPj4gSSBhbSBhd2FyZSBvZiBhIHRlY2huaXF1ZSBvZiBt dWx0aXBsZSBzcGxpdCBob3Jpem9uIGdyb3VwcyBpbiBQRS1yDQo+PiA+PiB3aGljaCBjb3VsZCBi ZSBwb3NzaWJseSB1c2VkIGZvciB0aGlzIHB1cnBvc2UuIEhvd2V2ZXIsIHNpbmNlIHRoZXNlDQo+ PiA+PiBncm91cHMgaGF2ZSB0byBiZSByZXByZXNlbnRlZCBleHBsaWNpdGx5IGluIHRoZSBkYXRh IHBsYW5lLCB0aGVpcg0KPj4gPj4gcG90ZW50aWFsIG51bWJlciBpcyBsaW1pdGVkIGJ5IHRoZSBm b3J3YXJkaW5nIEhXLiBPdGhlciBtZXRob2RzDQo+PiBjb3VsZA0KPj4gPj4gYmUgcHJvYmFibHkg dXNlZCBmb3IgdGhlIHNhbWUgcHVycG9zZSwgYnV0IHRoZXkgd291bGQgcHJvYmFibHkNCj4+ID4+ IHN1YmplY3QgdG8gc2ltaWxhciBIVy1iYXNlZCBsaW1pdGF0aW9ucy4NCj4+ID4+DQo+PiA+PiBJ IHN1c3BlY3QgdGhhdCB3aXRoIHRoZSBkdWFsLVBXIGFwcHJvYWNoLCB0aGUgSFcgd291bGQgcG9z ZSBhbg0KPj4gPmltcGxpY2l0DQo+PiA+PiBsaW1pdCwgc2F5LCBvbiBhIG51bWJlciBvZiBNVFUt cyB0aGF0IGNhbiBiZSBjb25uZWN0ZWQgdG8gdGhlIHNhbWUNCj4+ID5QRS1yDQo+PiA+PiBhbmQg dGhhdCB0aGlzIGxpbWl0IGNvdWxkIGJlIHF1aXRlIGxvdyBpbiBtb3N0IGNhc2VzLg0KPj4gPj4N Cj4+ID4+IEJhc2VkIG9uIHRoaXMgSSBzdXNwZWN0IHRoYXQgdGhlIEgtVlBMUyBpc3N1ZSBhcyBh IGNyaXRpY2FsIGRyYXdiYWNrDQo+PiA+b2YNCj4+ID4+IHRoZSBkdWFsLVBXIGFwcHJvYWNoIHRv IEUtVHJlZS4NCj4+ID4+DQo+PiA+PiBNeSAyYywNCj4+ID4+ICAgICAgU2FzaGENCj4+ID4+DQo+ PiA+Pg0KPj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4g Pj4gRnJvbTogbDJ2cG4tYm91bmNlc0BpZXRmLm9yZyBbbDJ2cG4tYm91bmNlc0BpZXRmLm9yZ10g b24gYmVoYWxmIG9mDQo+PiA+PiBTYW0gQ2FvIFt5dXF1bi5jYW9AZ21haWwuY29tXQ0KPj4gPj4g U2VudDogV2VkbmVzZGF5LCBNYXkgMDksIDIwMTIgMzo0MCBBTQ0KPj4gPj4gVG86IGwydnBuQGll dGYub3JnDQo+PiA+PiBDYzogbGl6aG9uZy5qaW5AenRlLmNvbS5jbg0KPj4gPj4gU3ViamVjdDog UkU6IERpc2N1c3Npb24gb24gRS1UcmVlIGFuZCBILVZQTFMNCj4+ID4+DQo+PiA+PiBIaSBMaXpo b25nPw0KPj4gPj4NCj4+ID4+IFRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHlvdXIgY29tbWVudHMu IEkgdXBkYXRlZCB0aGUgcmVzdWx0IG9uIHRoaXMNCj4+ID4+IHF1ZXN0aW9uLg0KPj4gPj4NCj4+ ID4+IFtMaXpob25nXSBhZ3JlZSB3aXRoIHRoZSBhYm92ZSBhbmFseXNpcy4gQW5kIHdlIGRpZCBu b3Qgc2F5IGl0IGlzIGENCj4+ID4+IHRlY2huaWNhbCBwcm9ibGVtLCBidXQgaXQgaXMgYW4gb3Bl cmF0aW9uYWwgcHJvYmxlbSBhZ2Fpbi4NCj4+ID4+IFtTYW1dIEkgYWdyZWUuIER1YWwtVkxBTiBk b2VzIG5vdCBtYWtlIHNlbnNlLiBJIGFsc28gZGlzY3Vzc2VkIHRoaXMNCj4+ID4+IHdpdGggR2ls ZXMgYW5kIFl1YW5sb25nIGluIGFub3RoZXIgbWFpbCwgYW5kIHdlIHJlYWNoZWQgYWdyZWVtZW50 IG9uDQo+PiA+PiB0aGlzOg0KPj4gPj4gTVRVIHNob3VsZCBrbm93IHRoZSBhY2Nlc3MgbW9kZSwg VlBXUyBvciBWUExTLCBWUFdTIG1vZGUgc2hvdWxkDQo+PiA+PiBjb25maWd1cmUgVkxBTiBJRCBv biBNVFUgYnV0IFZQTFMgbW9kZSBjYW4gbm90LiBJIHRob3VnaHQgdGhpcyBpcw0KPj4gTk9UDQo+ PiA+PiByZWFzb25hYmxlIDopLCBidXQgd2UgY2FuIGZpZ3VyZSB0aGlzIG91dCBpbiBkcmFmdC4g SXQgc2VlbXMgb2suDQo+PiA+Pg0KPj4gPj4gW0xpemhvbmddIG5vdCBmdWxseSB1bmRlcnN0YW5k LiBEbyB5b3UgbWVhbiwgIHdoZW4gVlBXUyBhY2Nlc3NpbmcNCj4+IGZvcg0KPj4gPj4gSC1WUExT LCB0aGUgUEUtciBpcyBhbHNvIG5lY2Vzc2FyeSB0byBjb25maWd1cmUgdHdvIFBXcyAocm9vdCBh bmQNCj4+ID4+IGxlYWYNCj4+ID4+IFBXKSBmb3IgZWFjaCBBQyBhY2Nlc3M/DQo+PiA+PiBbU2Ft XSBZZXMuDQo+PiA+Pg0KPj4gPj4gVGhhbmtzLA0KPj4gPj4NCj4+ID4+IFNhbQ0KPj4gPj4NCj4+ ID4+DQo+PiA+Pg0KPj4gPj4NCj4+ID4NCj4+DQo+Pg0KPj4gVGhpcyBFLW1haWwgYW5kIGFueSBv ZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUNCj4+IHByb3By aWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9y IHN1YmplY3QNCj4+IHRvIGNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUu IFRoaXMgRS1tYWlsIGlzIGludGVuZGVkDQo+PiBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGlu ZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzDQo+PiBhZGRyZXNzZWQuIElmIHlvdSBh cmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdQ0KPj4gYXJl IGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIGNv cHlpbmcsIG9yDQo+PiBhY3Rpb24gdGFrZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzIG9m IGFuZCBhdHRhY2htZW50cyB0byB0aGlzIEUtDQo+PiBtYWlsIGlzIHN0cmljdGx5IHByb2hpYml0 ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQNCj4+IHRoaXMgRS1t YWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kDQo+ PiBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUt bWFpbCBhbmQgYW55DQo+PiBwcmludG91dC4NCg0KDQpUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0 cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBp bmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0 IHRvIGNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWls IGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRp dHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQg cmVjaXBpZW50IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFu eSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBp biByZWxhdGlvbiB0byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1t YWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55 IGNvcHkgb2YgdGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC4NCg== From internet-drafts@ietf.org Sun May 20 14:51: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 89D3B21F8528; Sun, 20 May 2012 14:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.386 X-Spam-Level: X-Spam-Status: No, score=-102.386 tagged_above=-999 required=5 tests=[AWL=0.213, 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 h54dz0pt1Z0Y; Sun, 20 May 2012 14:51:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2983421F8483; Sun, 20 May 2012 14:51:01 -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-vpls-ldp-mac-opt-06.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120520215101.387.50163.idtracker@ietfa.amsl.com> Date: Sun, 20 May 2012 14:51:01 -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: Sun, 20 May 2012 21:51:01 -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 : LDP Extensions for Optimized MAC Address Withdrawal in H= -VPLS Author(s) : Pranjal Kumar Dutta Florin Balus Olen Stokes Geraldine Calvignac Filename : draft-ietf-l2vpn-vpls-ldp-mac-opt-06.txt Pages : 18 Date : 2012-05-20 [RFC4762] describes a mechanism to remove or unlearn MAC addresses that have been dynamically learned in a VPLS Instance for faster convergence on topology change. The procedure also removes MAC addresses in the VPLS that do not require relearning due to such topology change. This document defines an enhancement to the MAC Address Withdrawal procedure with empty MAC List [RFC4762], which enables a Provider Edge(PE) device to remove only the MAC addresses that need to be relearned. Additional extensions to [RFC4762] MAC Withdrawal procedures are specified to provide optimized MAC flushing for the PBB-VPLS specified in [PBB-VPLS Model]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-ldp-mac-opt-06.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-vpls-ldp-mac-opt-06.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-l2vpn-vpls-ldp-mac-opt/