From Wim.Henderickx@alcatel-lucent.com Tue Dec 1 04:56:33 2009 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FDE13A6936; Tue, 1 Dec 2009 04:56:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.955 X-Spam-Level: X-Spam-Status: No, score=-4.955 tagged_above=-999 required=5 tests=[AWL=1.294, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGzxj9gYE6Za; Tue, 1 Dec 2009 04:56:32 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by core3.amsl.com (Postfix) with ESMTP id 2A6E33A68CB; Tue, 1 Dec 2009 04:56:31 -0800 (PST) Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.dc-m.alcatel-lucent.com [155.132.6.74]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id nB1CuChE026907; Tue, 1 Dec 2009 13:56:12 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 13:56:11 +0100 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: [PWE3] MEF E-Tree over MPLS/VPLS Date: Tue, 1 Dec 2009 13:56:07 +0100 Message-ID: In-Reply-To: <1832FCB0BDD61149B996F7AE2DEAFF4C044325501C@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] MEF E-Tree over MPLS/VPLS Thread-Index: AcpyNS3uCATfWS5USqikxReutYtObAABvryAAAL0tAAAD2ZVQA== References: <4B148B54.2080007@cisco.com> <6569379E42CFCB4192ECE021966F9A444AE61790E5@CNEMAIL.corp.local> <1832FCB0BDD61149B996F7AE2DEAFF4C044325501C@FRVELSMBS22.ad2.ad.alcatel.com> From: "HENDERICKX Wim" To: "Mallette, Edwin" , "Luca Martini" , "Simon Delord" X-OriginalArrivalTime: 01 Dec 2009 12:56:11.0870 (UTC) FILETIME=[A89F27E0:01CA7285] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Cc: l2vpn@ietf.org, pwe3 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 12:56:33 -0000 The whole reason why this proposal was retained after long discussions is because it does not add any additional signaling on the PW infrastructure and does not touches the PW infrastructure for VPLS services.=20 When we create multiple VSIs we end up setting up more PW which we want to avoid in this proposal. As Edwin indicated the idea is to complement the draft with auto-discovery procedures to optimize the traffic flows which are unnecessary. -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Mallette, Edwin Sent: dinsdag 1 december 2009 5:59 To: Luca Martini; Simon Delord Cc: l2vpn@ietf.org; pwe3 Subject: RE: [PWE3] MEF E-Tree over MPLS/VPLS Luca, This could be a simple question of terminology, but unless I'm missing something there is no real change to the CW signaling mechanism. The CW signaling mechanism is really do I use a control word or not. It strikes me that this draft simply proposes utilizing the CW as a forwarding mechanism. Then the egress PE would have to look at the control word and the MAC header to determine where (if) to forward the frame. The corner cases of how to handle leafs and roots in the same PE can be handled much like "private" VLANs are handled in traditional ethernet switches - given that you would actually define a leaf and a root AC in advance this would be a relatively simple logic modification within the PE. Now I understand that the draft states it does not intend to address efficient packet replication or bandwidth optimization, though I think this could be accomplished with another step. Thus to the next problem - how we learn if a root lives off a specific pseudowire. Option a) we track the presence of the L-bit from a pseudowire (in a table like the bridge table) to ensure we correctly forward from leaf to root, root to root, etc. Option b) we use a BGP autodiscovery mechanism to distribute whether a PE "owns" a root AC for a given VFI or not. Ultimately, I still can't see a way around setting a bit somewhere in either the PW header or MAC header (if you say the CW is not the right place) to designate the source type (leaf or root) so we could ensure the frame is forwarded correctly at the egress PE. Regards, Ed -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Luca Martini Sent: Monday, November 30, 2009 10:20 PM To: Simon Delord Cc: l2vpn@ietf.org; pwe3 Subject: Re: [PWE3] MEF E-Tree over MPLS/VPLS Simon, The main problem with this design is that it uses the CW to signal topology information. This is not an appropriate use of the CW. Now, having said that , let's explore the problem a bit further. Th E-tree construct was always envisioned to be used in conjunction with VPLS BGP autodiscovery. It is simple to use a scheme of leaf RT , and Root RT and BGP import filters to achieve the functionality you desire using today's standards. There are a couple of corner problems , like when there are leafs co-located with Roots in the same PE. These I believe can be solved by using multiple VFIs in that particular PE. Any more corner cases I did not think about ? The reference the P2MP PW , I do not understand. Can you explain a bit more ? Thanks. Luca Simon Delord wrote: > > Bonjour everyone, > > We have recently submitted two Internet drafts to both the PWE3 and > L2VPN WG regarding how to implement E-Tree services (defined by the > Metro Ethernet Forum in MEF6.1 and MEF10.1 specifications) over MPLS > networks. > > Our > > approach relies on a simple extension to the current Virtual Private > LAN Service (VPLS) standards (RFC 4761 / RFC 4762) and PWE3 Ethernet > Encapsulation standard (RFC 4448). With such extension, VPLS can be > used to support both E-LAN and E-Tree services at the same time on an > MPLS network. > _http://www.ietf.org/id/draft-key-l2vpn-vpls-etree-01.txt_ > _http://www.ietf.org/id/draft-delord-pwe3-cw-bit-etree-01.txt_ > > Based on the comments and discussions we've had so far with a number > of vendors and carriers, no critical technical issue with the proposal > has been raised. We are currently working on the next version and > would like to have the working group members comments on the proposed > extension. > > In particular, if the authors of the current standards (RFC 4761, RFC > 4762, RFC 4448) can give us some feedback, it would be fantastic. > > We also produced a third document on the L2VPN WG, a framework that > explains the need for E-Tree services as well as the problem statement > with the current situation. > > _http://www.ietf.org/id/draft-key-l2vpn-etree-frwk-00.txt_ > > Many thanks. > > Simon > > ------------------------------------------------------------------------ > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 CONFIDENTIALITY NOTICE: This e-mail may contain information that is privileged, confidential or otherwise protected from disclosure. If you are not the intended recipient of this e-mail, please notify the sender immediately by return e-mail, purge it and do not disseminate or copy it. CONFIDENTIALITY NOTICE: This e-mail may contain information that is privileged, confidential or otherwise protected from disclosure. If you are not the intended recipient of this e-mail, please notify the sender immediately by return e-mail, purge it and do not disseminate or copy it. From david.i.allan@ericsson.com Tue Dec 1 08:15:43 2009 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 347D63A68D6; Tue, 1 Dec 2009 08:15:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.874 X-Spam-Level: X-Spam-Status: No, score=-5.874 tagged_above=-999 required=5 tests=[AWL=0.725, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSAmq0w3Xi91; Tue, 1 Dec 2009 08:15:41 -0800 (PST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 8C4E43A68B9; Tue, 1 Dec 2009 08:15:41 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id nB1Fu05g005306; Tue, 1 Dec 2009 10:14:53 -0600 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.228]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 1 Dec 2009 11:12:38 -0500 From: David Allan I To: HENDERICKX Wim , "Mallette, Edwin" , Luca Martini , Simon Delord Date: Tue, 1 Dec 2009 11:12:36 -0500 Subject: RE: [PWE3] MEF E-Tree over MPLS/VPLS Thread-Topic: [PWE3] MEF E-Tree over MPLS/VPLS Thread-Index: AcpyNS3uCATfWS5USqikxReutYtObAABvryAAAL0tAAAD2ZVQAAAc04w Message-ID: <60C093A41B5E45409A19D42CF7786DFD4DF147D196@EUSAACMS0703.eamcs.ericsson.se> References: <4B148B54.2080007@cisco.com> <6569379E42CFCB4192ECE021966F9A444AE61790E5@CNEMAIL.corp.local> <1832FCB0BDD61149B996F7AE2DEAFF4C044325501C@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "l2vpn@ietf.org" , pwe3 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 16:15:43 -0000 Hi Wim: Just to clarify. If I have redundant roots, two of them, and a root co-loca= ted with a leaf I am only actually saving one PW... One from the alternate = root to the node that hosts both root and a leaf...as otherwise I would nee= d one root to root and one root to leaf.... Is my math correct? Dave=20 -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of H= ENDERICKX Wim Sent: Tuesday, December 01, 2009 1:56 PM To: Mallette, Edwin; Luca Martini; Simon Delord Cc: l2vpn@ietf.org; pwe3 Subject: RE: [PWE3] MEF E-Tree over MPLS/VPLS The whole reason why this proposal was retained after long discussions is b= ecause it does not add any additional signaling on the PW infrastructure an= d does not touches the PW infrastructure for VPLS services.=20 When we create multiple VSIs we end up setting up more PW which we want to = avoid in this proposal. As Edwin indicated the idea is to complement the draft with auto-discovery = procedures to optimize the traffic flows which are unnecessary. -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of M= allette, Edwin Sent: dinsdag 1 december 2009 5:59 To: Luca Martini; Simon Delord Cc: l2vpn@ietf.org; pwe3 Subject: RE: [PWE3] MEF E-Tree over MPLS/VPLS Luca, This could be a simple question of terminology, but unless I'm missing some= thing there is no real change to the CW signaling mechanism. The CW signal= ing mechanism is really do I use a control word or not. It strikes me that= this draft simply proposes utilizing the CW as a forwarding mechanism. Th= en the egress PE would have to look at the control word and the MAC header = to determine where (if) to forward the frame. The corner cases of how to handle leafs and roots in the same PE can be han= dled much like "private" VLANs are handled in traditional ethernet switches= - given that you would actually define a leaf and a root AC in advance thi= s would be a relatively simple logic modification within the PE. Now I understand that the draft states it does not intend to address effici= ent packet replication or bandwidth optimization, though I think this could= be accomplished with another step. Thus to the next problem - how we learn if a root lives off a specific pseudowire. Option a) we tra= ck the presence of the L-bit from a pseudowire (in a table like the bridge = table) to ensure we correctly forward from leaf to root, root to root, etc.= Option b) we use a BGP autodiscovery mechanism to distribute whether a PE= "owns" a root AC for a given VFI or not. Ultimately, I still can't see a way around setting a bit somewhere in eithe= r the PW header or MAC header (if you say the CW is not the right place) to designate the source type (leaf or root) so we could ensure the f= rame is forwarded correctly at the egress PE. Regards, Ed -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Luc= a Martini Sent: Monday, November 30, 2009 10:20 PM To: Simon Delord Cc: l2vpn@ietf.org; pwe3 Subject: Re: [PWE3] MEF E-Tree over MPLS/VPLS Simon, The main problem with this design is that it uses the CW to signal topology= information. This is not an appropriate use of the CW. Now, having said th= at , let's explore the problem a bit further. Th E-tree construct was always envisioned to be used in conjunction with V= PLS BGP autodiscovery. It is simple to use a scheme of leaf RT , and Root R= T and BGP import filters to achieve the functionality you desire using toda= y's standards. There are a couple of corner problems , like when there are leafs co-locate= d with Roots in the same PE. These I believe can be solved by using multipl= e VFIs in that particular PE. Any more corner cases I did not think about ? The reference the P2MP PW , I do not understand. Can you explain a bit mo= re ? Thanks. Luca Simon Delord wrote: > > Bonjour everyone, > > We have recently submitted two Internet drafts to both the PWE3 and=20 > L2VPN WG regarding how to implement E-Tree services (defined by the=20 > Metro Ethernet Forum in MEF6.1 and MEF10.1 specifications) over MPLS=20 > networks. > > Our > > approach relies on a simple extension to the current Virtual Private=20 > LAN Service (VPLS) standards (RFC 4761 / RFC 4762) and PWE3 Ethernet=20 > Encapsulation standard (RFC 4448). With such extension, VPLS can be=20 > used to support both E-LAN and E-Tree services at the same time on an=20 > MPLS network. > _http://www.ietf.org/id/draft-key-l2vpn-vpls-etree-01.txt_ > _http://www.ietf.org/id/draft-delord-pwe3-cw-bit-etree-01.txt_ > > Based on the comments and discussions we've had so far with a number=20 > of vendors and carriers, no critical technical issue with the proposal=20 > has been raised. We are currently working on the next version and=20 > would like to have the working group members comments on the proposed=20 > extension. > > In particular, if the authors of the current standards (RFC 4761, RFC=20 > 4762, RFC 4448) can give us some feedback, it would be fantastic. > > We also produced a third document on the L2VPN WG, a framework that=20 > explains the need for E-Tree services as well as the problem statement=20 > with the current situation. > > _http://www.ietf.org/id/draft-key-l2vpn-etree-frwk-00.txt_ > > Many thanks. > > Simon > > ------------------------------------------------------------------------ > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 CONFIDENTIALITY NOTICE: This e-mail may contain information that is privile= ged, confidential or otherwise protected from disclosure. If you are not th= e intended recipient of this e-mail, please notify the sender immediately b= y return e-mail, purge it and do not disseminate or copy it. CONFIDENTIALITY NOTICE: This e-mail may contain information that is privile= ged, confidential or otherwise protected from disclosure. If you are not th= e intended recipient of this e-mail, please notify the sender immediately b= y return e-mail, purge it and do not disseminate or copy it. From Wim.Henderickx@alcatel-lucent.com Tue Dec 1 09:17:16 2009 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A10103A6966; Tue, 1 Dec 2009 09:17:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.103 X-Spam-Level: X-Spam-Status: No, score=-3.103 tagged_above=-999 required=5 tests=[AWL=-0.854, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XjEXO5McQsYb; Tue, 1 Dec 2009 09:17:15 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 270A23A68E4; Tue, 1 Dec 2009 09:17:14 -0800 (PST) Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.dc-m.alcatel-lucent.com [155.132.6.78]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id nB1HGvZE026393; Tue, 1 Dec 2009 18:16:57 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 18:16:57 +0100 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: [PWE3] MEF E-Tree over MPLS/VPLS Date: Tue, 1 Dec 2009 18:16:50 +0100 Message-ID: In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD4DF147D196@EUSAACMS0703.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] MEF E-Tree over MPLS/VPLS Thread-Index: AcpyNS3uCATfWS5USqikxReutYtObAABvryAAAL0tAAAD2ZVQAAAc04wAAiS+ZA= References: <4B148B54.2080007@cisco.com><6569379E42CFCB4192ECE021966F9A444AE61790E5@CNEMAIL.corp.local><1832FCB0BDD61149B996F7AE2DEAFF4C044325501C@FRVELSMBS22.ad2.ad.alcatel.com> <60C093A41B5E45409A19D42CF7786DFD4DF147D196@EUSAACMS0703.eamcs.ericsson.se> From: "HENDERICKX Wim" To: "David Allan I" , "Mallette, Edwin" , "Luca Martini" , "Simon Delord" X-OriginalArrivalTime: 01 Dec 2009 17:16:57.0468 (UTC) FILETIME=[161FF3C0:01CA72AA] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: l2vpn@ietf.org, pwe3 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 17:17:16 -0000 Dave, In terms of PW yes, but you also need to add a bunch of configuration to ensure you have proper split-horizon behavior between leafs, leaf and root, etc. Also when you have leafs and root ACs on the same node it becomes even more interesting. So all in all I believe that the draft ensures operational simplicity of deploying an E-TREE solution with VPLS. Cheers, Wim -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of David Allan I Sent: dinsdag 1 december 2009 17:13 To: HENDERICKX Wim; Mallette, Edwin; Luca Martini; Simon Delord Cc: l2vpn@ietf.org; pwe3 Subject: RE: [PWE3] MEF E-Tree over MPLS/VPLS Hi Wim: Just to clarify. If I have redundant roots, two of them, and a root co-located with a leaf I am only actually saving one PW... One from the alternate root to the node that hosts both root and a leaf...as otherwise I would need one root to root and one root to leaf.... Is my math correct? Dave=20 -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of HENDERICKX Wim Sent: Tuesday, December 01, 2009 1:56 PM To: Mallette, Edwin; Luca Martini; Simon Delord Cc: l2vpn@ietf.org; pwe3 Subject: RE: [PWE3] MEF E-Tree over MPLS/VPLS The whole reason why this proposal was retained after long discussions is because it does not add any additional signaling on the PW infrastructure and does not touches the PW infrastructure for VPLS services.=20 When we create multiple VSIs we end up setting up more PW which we want to avoid in this proposal. As Edwin indicated the idea is to complement the draft with auto-discovery procedures to optimize the traffic flows which are unnecessary. -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Mallette, Edwin Sent: dinsdag 1 december 2009 5:59 To: Luca Martini; Simon Delord Cc: l2vpn@ietf.org; pwe3 Subject: RE: [PWE3] MEF E-Tree over MPLS/VPLS Luca, This could be a simple question of terminology, but unless I'm missing something there is no real change to the CW signaling mechanism. The CW signaling mechanism is really do I use a control word or not. It strikes me that this draft simply proposes utilizing the CW as a forwarding mechanism. Then the egress PE would have to look at the control word and the MAC header to determine where (if) to forward the frame. The corner cases of how to handle leafs and roots in the same PE can be handled much like "private" VLANs are handled in traditional ethernet switches - given that you would actually define a leaf and a root AC in advance this would be a relatively simple logic modification within the PE. Now I understand that the draft states it does not intend to address efficient packet replication or bandwidth optimization, though I think this could be accomplished with another step. Thus to the next problem - how we learn if a root lives off a specific pseudowire. Option a) we track the presence of the L-bit from a pseudowire (in a table like the bridge table) to ensure we correctly forward from leaf to root, root to root, etc. Option b) we use a BGP autodiscovery mechanism to distribute whether a PE "owns" a root AC for a given VFI or not. Ultimately, I still can't see a way around setting a bit somewhere in either the PW header or MAC header (if you say the CW is not the right place) to designate the source type (leaf or root) so we could ensure the frame is forwarded correctly at the egress PE. Regards, Ed -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Luca Martini Sent: Monday, November 30, 2009 10:20 PM To: Simon Delord Cc: l2vpn@ietf.org; pwe3 Subject: Re: [PWE3] MEF E-Tree over MPLS/VPLS Simon, The main problem with this design is that it uses the CW to signal topology information. This is not an appropriate use of the CW. Now, having said that , let's explore the problem a bit further. Th E-tree construct was always envisioned to be used in conjunction with VPLS BGP autodiscovery. It is simple to use a scheme of leaf RT , and Root RT and BGP import filters to achieve the functionality you desire using today's standards. There are a couple of corner problems , like when there are leafs co-located with Roots in the same PE. These I believe can be solved by using multiple VFIs in that particular PE. Any more corner cases I did not think about ? The reference the P2MP PW , I do not understand. Can you explain a bit more ? Thanks. Luca Simon Delord wrote: > > Bonjour everyone, > > We have recently submitted two Internet drafts to both the PWE3 and=20 > L2VPN WG regarding how to implement E-Tree services (defined by the=20 > Metro Ethernet Forum in MEF6.1 and MEF10.1 specifications) over MPLS=20 > networks. > > Our > > approach relies on a simple extension to the current Virtual Private=20 > LAN Service (VPLS) standards (RFC 4761 / RFC 4762) and PWE3 Ethernet=20 > Encapsulation standard (RFC 4448). With such extension, VPLS can be=20 > used to support both E-LAN and E-Tree services at the same time on an=20 > MPLS network. > _http://www.ietf.org/id/draft-key-l2vpn-vpls-etree-01.txt_ > _http://www.ietf.org/id/draft-delord-pwe3-cw-bit-etree-01.txt_ > > Based on the comments and discussions we've had so far with a number=20 > of vendors and carriers, no critical technical issue with the proposal > has been raised. We are currently working on the next version and=20 > would like to have the working group members comments on the proposed=20 > extension. > > In particular, if the authors of the current standards (RFC 4761, RFC=20 > 4762, RFC 4448) can give us some feedback, it would be fantastic. > > We also produced a third document on the L2VPN WG, a framework that=20 > explains the need for E-Tree services as well as the problem statement > with the current situation. > > _http://www.ietf.org/id/draft-key-l2vpn-etree-frwk-00.txt_ > > Many thanks. > > Simon > > ------------------------------------------------------------------------ > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 CONFIDENTIALITY NOTICE: This e-mail may contain information that is privileged, confidential or otherwise protected from disclosure. If you are not the intended recipient of this e-mail, please notify the sender immediately by return e-mail, purge it and do not disseminate or copy it. CONFIDENTIALITY NOTICE: This e-mail may contain information that is privileged, confidential or otherwise protected from disclosure. If you are not the intended recipient of this e-mail, please notify the sender immediately by return e-mail, purge it and do not disseminate or copy it. From Florin.Balus@alcatel-lucent.com Tue Dec 1 10:39:12 2009 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECA273A6903; Tue, 1 Dec 2009 10:39:12 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bB5hdtWFKvbo; Tue, 1 Dec 2009 10:39:11 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by core3.amsl.com (Postfix) with ESMTP id 961A73A6899; Tue, 1 Dec 2009 10:39:11 -0800 (PST) Received: from horh1.usa.alcatel.com (h172-22-218-55.lucent.com [172.22.218.55]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id nB1IcxYw000010; Tue, 1 Dec 2009 12:38:59 -0600 (CST) Received: from usdalsbhs01.ad3.ad.alcatel.com (usdalsbhs01.pdc.alcatel-lucent.com [172.22.216.19]) by horh1.usa.alcatel.com (8.13.8/emsr) with ESMTP id nB1Icvs9019416; Tue, 1 Dec 2009 12:38:59 -0600 (CST) Received: from USDALSMBS03.ad3.ad.alcatel.com ([172.22.216.8]) by usdalsbhs01.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 12:38:57 -0600 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: [PWE3] MEF E-Tree over MPLS/VPLS Date: Tue, 1 Dec 2009 12:38:39 -0600 Message-ID: <4A5028372622294A99B8FFF6BD06EB7B06010EEC@USDALSMBS03.ad3.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] MEF E-Tree over MPLS/VPLS Thread-Index: AcpyNS3uCATfWS5USqikxReutYtObAABvryAAAL0tAAAD2ZVQAAAc04wAAiS+ZAAAKXgwA== References: <4B148B54.2080007@cisco.com><6569379E42CFCB4192ECE021966F9A444AE61790E5@CNEMAIL.corp.local><1832FCB0BDD61149B996F7AE2DEAFF4C044325501C@FRVELSMBS22.ad2.ad.alcatel.com><60C093A41B5E45409A19D42CF7786DFD4DF147D196@EUSAACMS0703.eamcs.ericsson.se> From: "BALUS Florin" To: "HENDERICKX Wim" , "David Allan I" , "Mallette, Edwin" , "Luca Martini" , "Simon Delord" X-OriginalArrivalTime: 01 Dec 2009 18:38:57.0800 (UTC) FILETIME=[8ADF0880:01CA72B5] X-Scanned-By: MIMEDefang 2.57 on 172.22.12.28 Cc: l2vpn@ietf.org, Stephen Haddock , pwe3 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 18:39:13 -0000 Operational simplicity is important indeed here and configuring 2 sites as root beats in my opinion the additional provisioning required for VSIs, RTs etc.=20 In addition and maybe the main argument for considering other options than the BGP-AD one is the existence of other use cases, already deployed and/or discussed in MEF and IEEE: i.e. HVPLS with no BGP-AD, PBB-VPLS (where one PW could be used for different ETREE topologies and even for ELINE, ELAN) and native Ethernet environments (QinQ or PBB with no PWs) or a combination of these use cases.=20 In my opinion the best option is to reactivate the discussion in IEEE to get a solution based on the Ethernet data plane that is the simple to use and works across technologies. From what I remember there was an IEEE proposal to use two tags (I think by Steve in cc): one assigned to traffic originated by Root site (say 1), a different one assigned for traffic originated by Leaves (say 0). Then as the traffic passes through the network, controls may be applied as required to limit its distribution. These controls can be technology dependent mechanisms (BGP-AD/T-LDP/manual provisioning/IEEE protocols) that build knowledge in the network of leaf-only PEs/regions so that traffic tagged as leaf (tag=3D0) is not distributed to a leaf only PE/region. In some use cases these optimizations might not be required and the leaf originated traffic can be dropped only at the leaf UNIs. The solution proposed by Simon & Co uses a CW bit as a tag somehow similarly with the IEEE approach. Ideally we should try to find though a flag/tag in the Ethernet header that works for all use cases instead of just VPLS. If there is no flag available in the Ethernet header maybe we should consider the past IEEE proposal to use a VLAN tag for this function. This is a bit of an overkill but it has the advantage that everybody supports it right of the bat. But this is a discussion to have first in IEEE rather than IETF. Florin > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > HENDERICKX Wim > Sent: Tuesday, December 01, 2009 9:17 AM > To: David Allan I; Mallette, Edwin; Luca Martini; Simon Delord > Cc: l2vpn@ietf.org; pwe3 > Subject: Re: [PWE3] MEF E-Tree over MPLS/VPLS >=20 > Dave, >=20 > In terms of PW yes, but you also need to add a bunch of configuration > to > ensure you have proper split-horizon behavior between leafs, leaf and > root, etc. >=20 > Also when you have leafs and root ACs on the same node it becomes even > more interesting. >=20 > So all in all I believe that the draft ensures operational simplicity > of > deploying an E-TREE solution with VPLS. >=20 > Cheers, > Wim >=20 > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of David Allan I > Sent: dinsdag 1 december 2009 17:13 > To: HENDERICKX Wim; Mallette, Edwin; Luca Martini; Simon Delord > Cc: l2vpn@ietf.org; pwe3 > Subject: RE: [PWE3] MEF E-Tree over MPLS/VPLS >=20 > Hi Wim: >=20 > Just to clarify. If I have redundant roots, two of them, and a root > co-located with a leaf I am only actually saving one PW... One from the > alternate root to the node that hosts both root and a leaf...as > otherwise I would need one root to root and one root to leaf.... >=20 > Is my math correct? > Dave >=20 > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of HENDERICKX Wim > Sent: Tuesday, December 01, 2009 1:56 PM > To: Mallette, Edwin; Luca Martini; Simon Delord > Cc: l2vpn@ietf.org; pwe3 > Subject: RE: [PWE3] MEF E-Tree over MPLS/VPLS >=20 >=20 > The whole reason why this proposal was retained after long discussions > is because it does not add any additional signaling on the PW > infrastructure and does not touches the PW infrastructure for VPLS > services. >=20 > When we create multiple VSIs we end up setting up more PW which we want > to avoid in this proposal. >=20 > As Edwin indicated the idea is to complement the draft with > auto-discovery procedures to optimize the traffic flows which are > unnecessary. >=20 > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Mallette, Edwin > Sent: dinsdag 1 december 2009 5:59 > To: Luca Martini; Simon Delord > Cc: l2vpn@ietf.org; pwe3 > Subject: RE: [PWE3] MEF E-Tree over MPLS/VPLS >=20 > Luca, >=20 > This could be a simple question of terminology, but unless I'm missing > something there is no real change to the CW signaling mechanism. The > CW > signaling mechanism is really do I use a control word or not. It > strikes me that this draft simply proposes utilizing the CW as a > forwarding mechanism. Then the egress PE would have to look at the > control word and the MAC header to determine where (if) to forward the > frame. >=20 > The corner cases of how to handle leafs and roots in the same PE can be > handled much like "private" VLANs are handled in traditional ethernet > switches - given that you would actually define a leaf and a root AC in > advance this would be a relatively simple logic modification within the > PE. >=20 > Now I understand that the draft states it does not intend to address > efficient packet replication or bandwidth optimization, though I think > this could be accomplished with another step. Thus to the next problem > - how we learn if a root lives off a specific pseudowire. Option a) we > track the presence of the L-bit from a pseudowire (in a table like the > bridge table) to ensure we correctly forward from leaf to root, root to > root, etc. Option b) we use a BGP autodiscovery mechanism to > distribute > whether a PE "owns" a root AC for a given VFI or not. >=20 > Ultimately, I still can't see a way around setting a bit somewhere in > either the PW header or MAC header (if you say the CW is not the right > place) to designate the source type (leaf or root) so we could ensure > the frame is forwarded correctly at the egress PE. >=20 > Regards, > Ed >=20 > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > Luca Martini > Sent: Monday, November 30, 2009 10:20 PM > To: Simon Delord > Cc: l2vpn@ietf.org; pwe3 > Subject: Re: [PWE3] MEF E-Tree over MPLS/VPLS >=20 > Simon, >=20 > The main problem with this design is that it uses the CW to signal > topology information. This is not an appropriate use of the CW. Now, > having said that , let's explore the problem a bit further. > Th E-tree construct was always envisioned to be used in conjunction > with VPLS BGP autodiscovery. It is simple to use a scheme of leaf RT , > and Root RT and BGP import filters to achieve the functionality you > desire using today's standards. > There are a couple of corner problems , like when there are leafs > co-located with Roots in the same PE. These I believe can be solved by > using multiple VFIs in that particular PE. > Any more corner cases I did not think about ? >=20 > The reference the P2MP PW , I do not understand. Can you explain a > bit > more ? >=20 > Thanks. > Luca >=20 >=20 >=20 >=20 > Simon Delord wrote: > > > > Bonjour everyone, > > > > We have recently submitted two Internet drafts to both the PWE3 and > > L2VPN WG regarding how to implement E-Tree services (defined by the > > Metro Ethernet Forum in MEF6.1 and MEF10.1 specifications) over MPLS > > networks. > > > > Our > > > > approach relies on a simple extension to the current Virtual Private > > LAN Service (VPLS) standards (RFC 4761 / RFC 4762) and PWE3 Ethernet > > Encapsulation standard (RFC 4448). With such extension, VPLS can be > > used to support both E-LAN and E-Tree services at the same time on an > > MPLS network. > > _http://www.ietf.org/id/draft-key-l2vpn-vpls-etree-01.txt_ > > _http://www.ietf.org/id/draft-delord-pwe3-cw-bit-etree-01.txt_ > > > > Based on the comments and discussions we've had so far with a number > > of vendors and carriers, no critical technical issue with the > proposal >=20 > > has been raised. We are currently working on the next version and > > would like to have the working group members comments on the proposed > > extension. > > > > In particular, if the authors of the current standards (RFC 4761, RFC > > 4762, RFC 4448) can give us some feedback, it would be fantastic. > > > > We also produced a third document on the L2VPN WG, a framework that > > explains the need for E-Tree services as well as the problem > statement >=20 > > with the current situation. > > > > _http://www.ietf.org/id/draft-key-l2vpn-etree-frwk-00.txt_ > > > > Many thanks. > > > > Simon > > > > > ----------------------------------------------------------------------- > - > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www.ietf.org/mailman/listinfo/pwe3 > > >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 >=20 > CONFIDENTIALITY NOTICE: This e-mail may contain information that is > privileged, confidential or otherwise protected from disclosure. If you > are not the intended recipient of this e-mail, please notify the sender > immediately by return e-mail, purge it and do not disseminate or copy > it. >=20 > CONFIDENTIALITY NOTICE: This e-mail may contain information that is > privileged, confidential or otherwise protected from disclosure. If you > are not the intended recipient of this e-mail, please notify the sender > immediately by return e-mail, purge it and do not disseminate or copy > it. > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From Jack.Pugaczewski@qwest.com Tue Dec 1 09:00:42 2009 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C0813A6A37; Tue, 1 Dec 2009 09:00:42 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EM9lOf8JQn7O; Tue, 1 Dec 2009 09:00:41 -0800 (PST) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by core3.amsl.com (Postfix) with ESMTP id 4E1983A6807; Tue, 1 Dec 2009 09:00:41 -0800 (PST) Received: from suomp60i.qintra.com (suomp60i.qintra.com [151.117.69.27]) by sudnp799.qwest.com (8.14.0/8.14.0) with ESMTP id nB1H0UrH009067; Tue, 1 Dec 2009 10:00:31 -0700 (MST) Received: from qtomaexhtm22.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.0/8.14.0) with ESMTP id nB1H0Pm8025403; Tue, 1 Dec 2009 11:00:25 -0600 (CST) Received: from qtomaexmbm25.AD.QINTRA.COM ([10.6.10.176]) by qtomaexhtm22.AD.QINTRA.COM ([10.6.10.188]) with mapi; Tue, 1 Dec 2009 11:00:23 -0600 From: "Pugaczewski, Jack" To: "'Luca Martini'" , Simon Delord Date: Tue, 1 Dec 2009 11:00:23 -0600 Subject: RE: [PWE3] MEF E-Tree over MPLS/VPLS Thread-Topic: [PWE3] MEF E-Tree over MPLS/VPLS Thread-Index: AcpyNTBxHL+NYd1wTxWYVzRRhzKVygAcmfJw Message-ID: <29A6F51000D949418BA974A07A2E8CFB3C40F525EE@qtomaexmbm25.AD.QINTRA.COM> References: <4B148B54.2080007@cisco.com> In-Reply-To: <4B148B54.2080007@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 01 Dec 2009 12:01:04 -0800 Cc: "l2vpn@ietf.org" , pwe3 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 17:01:41 -0000 Luca, Does this mean E-Tree is not envisioned to be used without VPLS BGP Autodis= covery ? Jack -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Luc= a Martini Sent: Monday, November 30, 2009 9:20 PM To: Simon Delord Cc: l2vpn@ietf.org; pwe3 Subject: Re: [PWE3] MEF E-Tree over MPLS/VPLS Simon, The main problem with this design is that it uses the CW to signal topology= information. This is not an appropriate use of the CW. Now, having said th= at , let's explore the problem a bit further. Th E-tree construct was always envisioned to be used in conjunction with V= PLS BGP autodiscovery. It is simple to use a scheme of leaf RT , and Root R= T and BGP import filters to achieve the functionality you desire using toda= y's standards. There are a couple of corner problems , like when there are leafs co-locate= d with Roots in the same PE. These I believe can be solved by using multipl= e VFIs in that particular PE. Any more corner cases I did not think about ? The reference the P2MP PW , I do not understand. Can you explain a bit mo= re ? Thanks. Luca Simon Delord wrote: > > Bonjour everyone, > > We have recently submitted two Internet drafts to both the PWE3 and > L2VPN WG regarding how to implement E-Tree services (defined by the > Metro Ethernet Forum in MEF6.1 and MEF10.1 specifications) over MPLS > networks. > > Our > > approach relies on a simple extension to the current Virtual Private > LAN Service (VPLS) standards (RFC 4761 / RFC 4762) and PWE3 Ethernet > Encapsulation standard (RFC 4448). With such extension, VPLS can be > used to support both E-LAN and E-Tree services at the same time on an > MPLS network. > _http://www.ietf.org/id/draft-key-l2vpn-vpls-etree-01.txt_ > _http://www.ietf.org/id/draft-delord-pwe3-cw-bit-etree-01.txt_ > > Based on the comments and discussions we've had so far with a number > of vendors and carriers, no critical technical issue with the proposal > has been raised. We are currently working on the next version and > would like to have the working group members comments on the proposed > extension. > > In particular, if the authors of the current standards (RFC 4761, RFC > 4762, RFC 4448) can give us some feedback, it would be fantastic. > > We also produced a third document on the L2VPN WG, a framework that > explains the need for E-Tree services as well as the problem statement > with the current situation. > > _http://www.ietf.org/id/draft-key-l2vpn-etree-frwk-00.txt_ > > Many thanks. > > Simon > > ---------------------------------------------------------------------- > -- > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From loa@pi.nu Wed Dec 2 05:15:10 2009 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E55F28C1C9; Wed, 2 Dec 2009 05:15:10 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffTLLKx35MPT; Wed, 2 Dec 2009 05:15:09 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id B3E7928C0FC; Wed, 2 Dec 2009 05:15:09 -0800 (PST) Received: from [192.36.158.71] (wdhcp-158-71.verkstad.net [192.36.158.71]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 20B0CD404B; Wed, 2 Dec 2009 14:14:59 +0100 (CET) Message-ID: <4B166852.2060502@pi.nu> Date: Wed, 02 Dec 2009 14:14:58 +0100 From: Loa Andersson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "mpls-tp@ietf.org" , mpls@ietf.org, ccamp@ietf.org, pwe3@ietf.org, l2vpn@ietf.org Subject: wg lasxt call on draft-ietf-mpls-tp-nm-framework-02 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 13:15:10 -0000 All, this is to start a 2 week wg last call on draft-ietf-mpls-tp-nm-framework-02. The wg last call ends on Dec 17. Please send yor comments to the mpls-tp@ietf.org mailing list. /Loa -- 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 raymond.key@ieee.org Wed Dec 2 18:00:12 2009 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C34843A6863; Wed, 2 Dec 2009 18:00:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.024 X-Spam-Level: X-Spam-Status: No, score=-100.024 tagged_above=-999 required=5 tests=[AWL=1.068, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwCXb6GOoTvt; Wed, 2 Dec 2009 18:00:11 -0800 (PST) Received: from mail04.syd.optusnet.com.au (mail04.syd.optusnet.com.au [211.29.132.185]) by core3.amsl.com (Postfix) with ESMTP id 5228E3A6909; Wed, 2 Dec 2009 18:00:11 -0800 (PST) Received: from localhost.localdomain (webmail02.syd.optusnet.com.au [211.29.132.236]) by mail04.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id nB31xxPJ002143; Thu, 3 Dec 2009 13:00:00 +1100 Message-Id: <200912030200.nB31xxPJ002143@mail04.syd.optusnet.com.au> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: MIME-tools 5.420 (Entity 5.420) Received: from bcbvo.tcif.telstra.com.au ([203.35.135.136]) by webmail02.syd.optusnet.com.au with http (user=rkey_ieee@optusnet.com.au); Thu, 03 Dec 2009 12:59:59 +1100 From: Raymond Key To: l2vpn@ietf.org, pwe3@ietf.org Date: Thu, 03 Dec 2009 12:59:59 +1100 Subject: MEF E-Tree over MPLS/VPLS X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raymond.key@ieee.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 02:00:12 -0000 Thanks a lot for the comments. I would like to share my view with the workgroups. (1) "it uses the CW to signal topology information." The information in the proposed Control Word L-bit is "whether the Ethernet frame encapsulated is coming from a Leaf AC on the ingress PE or not". I consider this as per-payload information, rather than topology information. (2) "E-tree construct was always envisioned to be used in conjunction with VPLS BGP autodiscovery." Metro Ethernet Forum (MEF) defined the Ethernet Tree (E-Tree) service definition with no reference to MPLS, VPLS, BGP, LDP, auto-discovery, static provisioning. Service providers and vendors have the freedom to use any technologies (existing or develop new) to implement E-Tree services. (3) "There are a couple of corner problems, like when there are leafs co-located with Roots in the same PE. These I believe can be solved by using multiple VFIs in that particular PE." The problem re Leaf-to-Leaf communication restriction that leads to the proposed Control Word L-bit is "Two or more PEs in one E-Tree construct with both Root AC and Leaf AC", as specified in section 5.2.1 in the Internet-Draft - A Framework for E-Tree Service over MPLS Network (draft-key-l2vpn-etree-frwk-00.txt). There are possible ways to get around this problem without any extension to current VPLS and PWE3 standards. The main ones I know are H-VPLS, separate VSIs for Root and Leaf, separate PWs for "From Leaf" traffic and "From Root" traffic, separate PEs for Root and Leaf, all Roots on same PE. Unfortunately, they all come with significant design complexity and/or deployment constraints. That is the reason why we explore whether a minimal extension to the current standards could bring a simple and effective solution. (4) "The reference the P2MP PW, I do not understand." The current VPLS standards use only P2P PW and PWE3 Ethernet Encapsulation [RFC4448]. The Control Word L-bit I-D proposes an extension to [RFC4448] by using bit 4 (one of the reserved bits specified in [RFC4448]) for the ingress PE to signal per payload to the egress PE whether the frame is from a Leaf AC on the ingress PE or not. If future development of VPLS uses P2MP PW for unicast unknown/broadcast/multicast frame, provided that [RFC4448] is used on the P2MP PW, the extension proposed in this I-D should be applicable. (5) "Ideally we should try to find though a flag/tag in the Ethernet header that works for all use cases instead of just VPLS. ... ... But this is a discussion to have first in IEEE rather than IETF." I believe there are considerable number of service providers currently implementing MEF E-LAN services on "just VPLS". The proposed Control Word L-bit approach is a straight forward solution for VPLS. It is good to explore the approach of using the Ethernet header but I would like to see things progressing in different angles rather than "first in IEEE rather than IETF". Thanks, Raymond Key From lucyyong@huawei.com Wed Dec 2 20:46:37 2009 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B59D28C106; Wed, 2 Dec 2009 20:46:37 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDjQ--hBaD7H; Wed, 2 Dec 2009 20:46:36 -0800 (PST) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id 871E43A69BB; Wed, 2 Dec 2009 20:46:36 -0800 (PST) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KU200AAA7XFZ7@usaga03-in.huawei.com>; Wed, 02 Dec 2009 22:46:27 -0600 (CST) Received: from y736742 (cpe-173-173-92-181.tx.res.rr.com [173.173.92.181]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KU2008Z47XEPF@usaga03-in.huawei.com>; Wed, 02 Dec 2009 22:46:27 -0600 (CST) Date: Wed, 02 Dec 2009 22:46:17 -0600 From: Yong Lucy Subject: RE: [PWE3] MEF E-Tree over MPLS/VPLS In-reply-to: <200912030200.nB31xxPJ002143@mail04.syd.optusnet.com.au> To: l2vpn@ietf.org, pwe3@ietf.org Message-id: <001001ca73d3$8d7e7890$6401a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcpzvMIK9hXbDAbZS56HBGUdFzvw1AAEAQ7g References: <200912030200.nB31xxPJ002143@mail04.syd.optusnet.com.au> X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 04:46:37 -0000 Raymond has given great answers for all the questions. Thanks Raymond. PW label and CW is for service encapsulation. CW is for per-packet encapsulation. L-bit in CW indicates whether the packet is from root or leaf that is the service attribute, it is not topology information. This indication enables egress PE to perform forwarding properly. Thanks, Lucy > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > Raymond Key > Sent: Wednesday, December 02, 2009 8:00 PM > To: l2vpn@ietf.org; pwe3@ietf.org > Subject: [PWE3] MEF E-Tree over MPLS/VPLS > > Thanks a lot for the comments. I would like to share my view with the > workgroups. > > (1) "it uses the CW to signal topology information." > > The information in the proposed Control Word L-bit is "whether the > Ethernet frame encapsulated is coming from a Leaf AC on the ingress PE or > not". I consider this as per-payload information, rather than topology > information. > > (2) "E-tree construct was always envisioned to be used in conjunction with > VPLS BGP autodiscovery." > > Metro Ethernet Forum (MEF) defined the Ethernet Tree (E-Tree) service > definition with no reference to MPLS, VPLS, BGP, LDP, auto-discovery, > static provisioning. Service providers and vendors have the freedom to use > any technologies (existing or develop new) to implement E-Tree services. > > (3) "There are a couple of corner problems, like when there are leafs co- > located with Roots in the same PE. These I believe can be solved by using > multiple VFIs in that particular PE." > > The problem re Leaf-to-Leaf communication restriction that leads to the > proposed Control Word L-bit is "Two or more PEs in one E-Tree construct > with both Root AC and Leaf AC", as specified in section 5.2.1 in the > Internet-Draft - A Framework for E-Tree Service over MPLS Network (draft- > key-l2vpn-etree-frwk-00.txt). > > There are possible ways to get around this problem without any extension > to current VPLS and PWE3 standards. The main ones I know are H-VPLS, > separate VSIs for Root and Leaf, separate PWs for "From Leaf" traffic and > "From Root" traffic, separate PEs for Root and Leaf, all Roots on same PE. > Unfortunately, they all come with significant design complexity and/or > deployment constraints. That is the reason why we explore whether a > minimal extension to the current standards could bring a simple and > effective solution. > > (4) "The reference the P2MP PW, I do not understand." > > The current VPLS standards use only P2P PW and PWE3 Ethernet Encapsulation > [RFC4448]. The Control Word L-bit I-D proposes an extension to [RFC4448] > by using bit 4 (one of the reserved bits specified in [RFC4448]) for the > ingress PE to signal per payload to the egress PE whether the frame is > from a Leaf AC on the ingress PE or not. If future development of VPLS > uses P2MP PW for unicast unknown/broadcast/multicast frame, provided that > [RFC4448] is used on the P2MP PW, the extension proposed in this I-D > should be applicable. > > (5) "Ideally we should try to find though a flag/tag in the Ethernet > header that works for all use cases instead of just VPLS. ... ... But this > is a discussion to have first in IEEE rather than IETF." > > I believe there are considerable number of service providers currently > implementing MEF E-LAN services on "just VPLS". The proposed Control Word > L-bit approach is a straight forward solution for VPLS. It is good to > explore the approach of using the Ethernet header but I would like to see > things progressing in different angles rather than "first in IEEE rather > than IETF". > > Thanks, > Raymond Key > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From lmartini@cisco.com Thu Dec 3 08:24:35 2009 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D25C73A682B; Thu, 3 Dec 2009 08:24:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5NvHK8gIVI9; Thu, 3 Dec 2009 08:24:35 -0800 (PST) Received: from napoleon.monoski.com (napoleon.monoski.com [67.41.208.110]) by core3.amsl.com (Postfix) with ESMTP id AF35B3A67FC; Thu, 3 Dec 2009 08:24:34 -0800 (PST) Received: from confusion.monoski.com (confusion.monoski.com [209.245.27.2]) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id nB3GOEIY022513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Dec 2009 09:24:16 -0700 (MST) Message-ID: <4B17E62E.8050406@cisco.com> Date: Thu, 03 Dec 2009 09:24:14 -0700 From: Luca Martini User-Agent: Thunderbird 2.0.0.19 (X11/20081209) MIME-Version: 1.0 To: raymond.key@ieee.org Subject: Re: MEF E-Tree over MPLS/VPLS References: <200912030200.nB31xxPJ002143@mail04.syd.optusnet.com.au> In-Reply-To: <200912030200.nB31xxPJ002143@mail04.syd.optusnet.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.63 on 209.245.27.1 Cc: l2vpn@ietf.org, pwe3@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 16:24:35 -0000 Raymond Key wrote: > Thanks a lot for the comments. I would like to share my view with the workgroups. > > (1) "it uses the CW to signal topology information." > > The information in the proposed Control Word L-bit is "whether the Ethernet frame encapsulated is coming from a Leaf AC on the ingress PE or not". I consider this as per-payload information, rather than topology information. > No. this is routing , or topology information in the same way as source IP address is. This does not belong in the CW. Why are you not using the MPLS label ? You can simply bind this information to a label. > (2) "E-tree construct was always envisioned to be used in conjunction with VPLS BGP autodiscovery." > > Metro Ethernet Forum (MEF) defined the Ethernet Tree (E-Tree) service definition with no reference to MPLS, VPLS, BGP, LDP, auto-discovery, static provisioning. Service providers and vendors have the freedom to use any technologies (existing or develop new) to implement E-Tree services. > > ok. so BGP VPLS autodiscovery is a very good fit . > (3) "There are a couple of corner problems, like when there are leafs co-located with Roots in the same PE. These I believe can be solved by using multiple VFIs in that particular PE." > > The problem re Leaf-to-Leaf communication restriction that leads to the proposed Control Word L-bit is "Two or more PEs in one E-Tree construct with both Root AC and Leaf AC", as specified in section 5.2.1 in the Internet-Draft - A Framework for E-Tree Service over MPLS Network (draft-key-l2vpn-etree-frwk-00.txt). > > There are possible ways to get around this problem without any extension to current VPLS and PWE3 standards. The main ones I know are H-VPLS, separate VSIs for Root and Leaf, separate PWs for "From Leaf" traffic and "From Root" traffic, separate PEs for Root and Leaf, all Roots on same PE. Unfortunately, they all come with significant design complexity and/or deployment constraints. That is the reason why we explore whether a minimal extension to the current standards could bring a simple and effective solution. > > Splitting the VSI on the PE for ROOT/LEAF is very simple. In fact this is a common practice today in networks using BGP to signal Labels. (4) "The reference the P2MP PW, I do not understand." > The current VPLS standards use only P2P PW and PWE3 Ethernet Encapsulation [RFC4448]. The Control Word L-bit I-D proposes an extension to [RFC4448] by using bit 4 (one of the reserved bits specified in [RFC4448]) for the ingress PE to signal per payload to the egress PE whether the frame is from a Leaf AC on the ingress PE or not. If future development of VPLS uses P2MP PW for unicast unknown/broadcast/multicast frame, provided that [RFC4448] is used on the P2MP PW, the extension proposed in this I-D should be applicable. > > ok, but that path has been already explored 10 years ago. It has all the problems of ATM LANE..., SO I doubt we'll look at it again. > (5) "Ideally we should try to find though a flag/tag in the Ethernet header that works for all use cases instead of just VPLS. ... ... But this is a discussion to have first in IEEE rather than IETF." > > Or we can simply bing the E-tree bit to the label .... > I believe there are considerable number of service providers currently implementing MEF E-LAN services on "just VPLS". The proposed Control Word L-bit approach is a straight forward solution for VPLS. It is good to explore the approach of using the Ethernet header but I would like to see things progressing in different angles rather than "first in IEEE rather than IETF". > > I think that give that the forwarding in the IETF is not based on the Ethernet MAC, but rather on a label .... it should be easy to add this topology constraint to the information that is bound to the MPLS label in the control plane. Luca > Thanks, > Raymond Key > > From Florin.Balus@alcatel-lucent.com Thu Dec 3 08:53:51 2009 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59BD53A66B4; Thu, 3 Dec 2009 08:53:51 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XU6Bw-SqAHWb; Thu, 3 Dec 2009 08:53:50 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by core3.amsl.com (Postfix) with ESMTP id EB5F83A69F1; Thu, 3 Dec 2009 08:53:41 -0800 (PST) Received: from horh1.usa.alcatel.com (h172-22-218-55.lucent.com [172.22.218.55]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id nB3GrSG3016288; Thu, 3 Dec 2009 10:53:28 -0600 (CST) Received: from usdalsbhs02.ad3.ad.alcatel.com (usdalsbhs02.pdc.alcatel-lucent.com [172.22.216.13]) by horh1.usa.alcatel.com (8.13.8/emsr) with ESMTP id nB3GrODY018304; Thu, 3 Dec 2009 10:53:28 -0600 (CST) Received: from USDALSMBS03.ad3.ad.alcatel.com ([172.22.216.8]) by usdalsbhs02.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Dec 2009 10:53:25 -0600 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: MEF E-Tree over MPLS/VPLS Date: Thu, 3 Dec 2009 10:53:03 -0600 Message-ID: <4A5028372622294A99B8FFF6BD06EB7B06011236@USDALSMBS03.ad3.ad.alcatel.com> In-Reply-To: <200912030200.nB31xxPJ002143@mail04.syd.optusnet.com.au> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MEF E-Tree over MPLS/VPLS Thread-Index: AcpzvFc3v6LTqfSQT6idG6UtaMPmGQAdPnrw References: <200912030200.nB31xxPJ002143@mail04.syd.optusnet.com.au> From: "BALUS Florin" To: , , X-OriginalArrivalTime: 03 Dec 2009 16:53:25.0735 (UTC) FILETIME=[217E1770:01CA7439] X-Scanned-By: MIMEDefang 2.57 on 172.22.12.28 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 16:53:51 -0000 On your answer for (5) > (5) "Ideally we should try to find though a flag/tag in the Ethernet > header that works for all use cases instead of just VPLS. ... ... But > this is a discussion to have first in IEEE rather than IETF." >=20 > I believe there are considerable number of service providers currently > implementing MEF E-LAN services on "just VPLS". The proposed Control > Word L-bit approach is a straight forward solution for VPLS. It is good > to explore the approach of using the Ethernet header but I would like > to see things progressing in different angles rather than "first in > IEEE rather than IETF". Maybe I should have stated differently: we should ask IEEE for an opinion on this and take their feedback into consideration. A good venue for that might be the interim IEEE 802.1 meeting in January 2010. Then we can pick up the discussion in IETF in the spring. I think it is worthwhile to try to come up with one solution for all use cases instead of multiple ones.=20 > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Raymond Key > Sent: Wednesday, December 02, 2009 6:00 PM > To: l2vpn@ietf.org; pwe3@ietf.org > Subject: MEF E-Tree over MPLS/VPLS >=20 > Thanks a lot for the comments. I would like to share my view with the > workgroups. >=20 > (1) "it uses the CW to signal topology information." >=20 > The information in the proposed Control Word L-bit is "whether the > Ethernet frame encapsulated is coming from a Leaf AC on the ingress PE > or not". I consider this as per-payload information, rather than > topology information. >=20 > (2) "E-tree construct was always envisioned to be used in conjunction > with VPLS BGP autodiscovery." >=20 > Metro Ethernet Forum (MEF) defined the Ethernet Tree (E-Tree) service > definition with no reference to MPLS, VPLS, BGP, LDP, auto-discovery, > static provisioning. Service providers and vendors have the freedom to > use any technologies (existing or develop new) to implement E-Tree > services. >=20 > (3) "There are a couple of corner problems, like when there are leafs > co-located with Roots in the same PE. These I believe can be solved by > using multiple VFIs in that particular PE." >=20 > The problem re Leaf-to-Leaf communication restriction that leads to the > proposed Control Word L-bit is "Two or more PEs in one E-Tree construct > with both Root AC and Leaf AC", as specified in section 5.2.1 in the > Internet-Draft - A Framework for E-Tree Service over MPLS Network > (draft-key-l2vpn-etree-frwk-00.txt). >=20 > There are possible ways to get around this problem without any > extension to current VPLS and PWE3 standards. The main ones I know are > H-VPLS, separate VSIs for Root and Leaf, separate PWs for "From Leaf" > traffic and "From Root" traffic, separate PEs for Root and Leaf, all > Roots on same PE. Unfortunately, they all come with significant design > complexity and/or deployment constraints. That is the reason why we > explore whether a minimal extension to the current standards could > bring a simple and effective solution. >=20 > (4) "The reference the P2MP PW, I do not understand." >=20 > The current VPLS standards use only P2P PW and PWE3 Ethernet > Encapsulation [RFC4448]. The Control Word L-bit I-D proposes an > extension to [RFC4448] by using bit 4 (one of the reserved bits > specified in [RFC4448]) for the ingress PE to signal per payload to the > egress PE whether the frame is from a Leaf AC on the ingress PE or not. > If future development of VPLS uses P2MP PW for unicast > unknown/broadcast/multicast frame, provided that [RFC4448] is used on > the P2MP PW, the extension proposed in this I-D should be applicable. >=20 > (5) "Ideally we should try to find though a flag/tag in the Ethernet > header that works for all use cases instead of just VPLS. ... ... But > this is a discussion to have first in IEEE rather than IETF." >=20 > I believe there are considerable number of service providers currently > implementing MEF E-LAN services on "just VPLS". The proposed Control > Word L-bit approach is a straight forward solution for VPLS. It is good > to explore the approach of using the Ethernet header but I would like > to see things progressing in different angles rather than "first in > IEEE rather than IETF". >=20 > Thanks, > Raymond Key From lucyyong@huawei.com Thu Dec 3 09:00:31 2009 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 529053A672F; Thu, 3 Dec 2009 09:00:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.724 X-Spam-Level: X-Spam-Status: No, score=-2.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpMt7I-yWIxs; Thu, 3 Dec 2009 09:00:30 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id F01163A66B4; Thu, 3 Dec 2009 09:00:29 -0800 (PST) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KU300EL75WIXZ@usaga04-in.huawei.com>; Thu, 03 Dec 2009 11:00:19 -0600 (CST) Received: from y736742 ([10.124.12.82]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KU300BMO5WHXZ@usaga04-in.huawei.com>; Thu, 03 Dec 2009 11:00:18 -0600 (CST) Date: Thu, 03 Dec 2009 11:00:17 -0600 From: Yong Lucy Subject: RE: MEF E-Tree over MPLS/VPLS In-reply-to: <4B17E62E.8050406@cisco.com> To: 'Luca Martini' , raymond.key@ieee.org Message-id: <003001ca743a$17772590$520c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acp0NTcZGvEGnrHXTMa4pnhWA28f6AAAQa2A References: <200912030200.nB31xxPJ002143@mail04.syd.optusnet.com.au> <4B17E62E.8050406@cisco.com> Cc: l2vpn@ietf.org, pwe3@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 17:00:31 -0000 Hi Luca, Couple of comments on your statement: > No. this is routing , or topology information in the same way as source > IP address is. > This does not belong in the CW. > Why are you not using the MPLS label ? You can simply bind this > information to a label. Root and leaf represent AC attribute parameters only. One E-tree service can have multiple root ACs and many leaf ACs, it is not like IP address to associate with one certain entity. The attribute gives some forwarding restriction and does not contribute for routing at all. So it is not topology information. > Splitting the VSI on the PE for ROOT/LEAF is very simple. In fact this > is a common practice today in networks using BGP to signal Labels. This solution requires building more PWs and interworking between two VSIs on a PE. Our proposal seems more simple that this extension. >I think that give that the forwarding in the IETF is not based on the > Ethernet MAC, but rather on a label .... it should be easy to add this > topology constraint to the information that is bound to the MPLS label > in the control plane. Disagree on that is a topology constraint. In addition, this leads to "MUST" separating roof PW label and leaf PW label, which requires the more complex extension than this. Regards, Lucy > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of > Luca Martini > Sent: Thursday, December 03, 2009 10:24 AM > To: raymond.key@ieee.org > Cc: l2vpn@ietf.org; pwe3@ietf.org > Subject: Re: MEF E-Tree over MPLS/VPLS > > Raymond Key wrote: > > Thanks a lot for the comments. I would like to share my view with the > workgroups. > > > > (1) "it uses the CW to signal topology information." > > > > The information in the proposed Control Word L-bit is "whether the > Ethernet frame encapsulated is coming from a Leaf AC on the ingress PE or > not". I consider this as per-payload information, rather than topology > information. > > > No. this is routing , or topology information in the same way as source > IP address is. > This does not belong in the CW. > Why are you not using the MPLS label ? You can simply bind this > information to a label. > > > (2) "E-tree construct was always envisioned to be used in conjunction > with VPLS BGP autodiscovery." > > > > Metro Ethernet Forum (MEF) defined the Ethernet Tree (E-Tree) service > definition with no reference to MPLS, VPLS, BGP, LDP, auto-discovery, > static provisioning. Service providers and vendors have the freedom to use > any technologies (existing or develop new) to implement E-Tree services. > > > > > ok. so BGP VPLS autodiscovery is a very good fit . > > > (3) "There are a couple of corner problems, like when there are leafs > co-located with Roots in the same PE. These I believe can be solved by > using multiple VFIs in that particular PE." > > > > The problem re Leaf-to-Leaf communication restriction that leads to the > proposed Control Word L-bit is "Two or more PEs in one E-Tree construct > with both Root AC and Leaf AC", as specified in section 5.2.1 in the > Internet-Draft - A Framework for E-Tree Service over MPLS Network (draft- > key-l2vpn-etree-frwk-00.txt). > > > > There are possible ways to get around this problem without any extension > to current VPLS and PWE3 standards. The main ones I know are H-VPLS, > separate VSIs for Root and Leaf, separate PWs for "From Leaf" traffic and > "From Root" traffic, separate PEs for Root and Leaf, all Roots on same PE. > Unfortunately, they all come with significant design complexity and/or > deployment constraints. That is the reason why we explore whether a > minimal extension to the current standards could bring a simple and > effective solution. > > > > > Splitting the VSI on the PE for ROOT/LEAF is very simple. In fact this > is a common practice today in networks using BGP to signal Labels. > > > (4) "The reference the P2MP PW, I do not understand." > > The current VPLS standards use only P2P PW and PWE3 Ethernet > Encapsulation [RFC4448]. The Control Word L-bit I-D proposes an extension > to [RFC4448] by using bit 4 (one of the reserved bits specified in > [RFC4448]) for the ingress PE to signal per payload to the egress PE > whether the frame is from a Leaf AC on the ingress PE or not. If future > development of VPLS uses P2MP PW for unicast unknown/broadcast/multicast > frame, provided that [RFC4448] is used on the P2MP PW, the extension > proposed in this I-D should be applicable. > > > > > ok, but that path has been already explored 10 years ago. It has all the > problems of ATM LANE..., SO I doubt we'll look at it again. > > (5) "Ideally we should try to find though a flag/tag in the Ethernet > header that works for all use cases instead of just VPLS. ... ... But this > is a discussion to have first in IEEE rather than IETF." > > > > > Or we can simply bing the E-tree bit to the label .... > > I believe there are considerable number of service providers currently > implementing MEF E-LAN services on "just VPLS". The proposed Control Word > L-bit approach is a straight forward solution for VPLS. It is good to > explore the approach of using the Ethernet header but I would like to see > things progressing in different angles rather than "first in IEEE rather > than IETF". > > > > > I think that give that the forwarding in the IETF is not based on the > Ethernet MAC, but rather on a label .... it should be easy to add this > topology constraint to the information that is bound to the MPLS label > in the control plane. > > Luca > > > Thanks, > > Raymond Key > > > > From raymond.key@ieee.org Mon Dec 7 18:28:29 2009 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC32D3A6974; Mon, 7 Dec 2009 18:28:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.08 X-Spam-Level: X-Spam-Status: No, score=-99.08 tagged_above=-999 required=5 tests=[AWL=-0.588, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVu8r18IaRLr; Mon, 7 Dec 2009 18:28:29 -0800 (PST) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by core3.amsl.com (Postfix) with ESMTP id AA68A3A693D; Mon, 7 Dec 2009 18:28:28 -0800 (PST) Received: from localhost.localdomain (webmail10.syd.optusnet.com.au [211.29.133.172]) by mail09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id nB82SAV1004239; Tue, 8 Dec 2009 13:28:12 +1100 Message-Id: <200912080228.nB82SAV1004239@mail09.syd.optusnet.com.au> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: MIME-tools 5.420 (Entity 5.420) Received: from bcavo.tcif.telstra.com.au ([203.35.135.133]) by webmail10.syd.optusnet.com.au with http (user=rkey_ieee@optusnet.com.au); Tue, 08 Dec 2009 13:28:10 +1100 From: Raymond Key To: Edwin.Mallette@bhnis.com Date: Tue, 08 Dec 2009 13:28:10 +1100 Subject: MEF E-Tree over MPLS/VPLS Cc: l2vpn@ietf.org, pwe3@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raymond.key@ieee.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 02:28:29 -0000 Hi Ed, "Now I understand that the draft states it does not intend to address efficient packet replication or bandwidth optimization, though I think this could be accomplished with another step. Thus to the next problem - how we learn if a root lives off a specific pseudowire. Option a) we track the presence of the L-bit from a pseudowire (in a table like the bridge table) to ensure we correctly forward from leaf to root, root to root, etc. Option b) we use a BGP autodiscovery mechanism to distribute whether a PE "owns" a root AC for a given VFI or not." [RK] Yes, we intend to first address the mandatory requirement of E-Tree service definition with minimal extension to current stardards, then next step look at packet replication and bandwidth optimization. Thanks for your input. We will consider the options in our next step. Raymond From tnadeau@lucidvision.com Thu Dec 10 12:28:03 2009 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50E4D3A6A55 for ; Thu, 10 Dec 2009 12:28:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.529 X-Spam-Level: X-Spam-Status: No, score=-3.529 tagged_above=-999 required=5 tests=[AWL=1.069, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeh0UBOMFKNV for ; Thu, 10 Dec 2009 12:28:02 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by core3.amsl.com (Postfix) with ESMTP id 2258C3A6A4D for ; Thu, 10 Dec 2009 12:28:02 -0800 (PST) Received: from [192.168.1.120] (unknown [72.71.250.36]) by lucidvision.com (Postfix) with ESMTP id CC962422D1DF for ; Thu, 10 Dec 2009 15:27:50 -0500 (EST) From: Thomas Nadeau Content-Type: multipart/alternative; boundary=Apple-Mail-12-849312939 Subject: ONTC-PRISM Newsletter: Call for Papers - Special Issue on Cloud Computing and Data Center Networks Date: Thu, 10 Dec 2009 15:27:50 -0500 Message-Id: To: l2vpn@ietf.org Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 20:28:03 -0000 --Apple-Mail-12-849312939 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii FYI: ONTC-PRISM Newsletter: Call for Papers - Special Issue on Cloud Computing and Data Center Networks Scope: IT services have proliferated significantly through most enterprises and even to end-users. This explosion of IT services has led to the emergence, growth and consolidation of computationally intensive data centers. Data centers are principle network wide entities that are responsible for the successful provisioning and scaling of IT services across disparate users over a heterogenous network. We seek to understand the network-wide design, implementation, architecture and technology aspects of data centers and of emerging applications such as cloud computing. We seek original review articles on technologies, architectures, implementation excercises associated with data centers including cloud computing, distributed and virtual data centers and applications using such infrastructures. Articles must be written as per the format prescribed below. Keywords: Cloud computing, data centers, Carrier Ethernet, MPLS-TP, PBB-TE, Virtualization, Consolidation. Format: up to 3 pages with single column format, Times new roman 10 point font for the text and 8 point font for the figure captions. Submission information: Please send manuscripts to submissions@ontc-prism.org. All articles will be reviewed by the TAB and/or external reviewers. Timeline: Submission Deadline: Dec 31, 2009 Notification: Feb 1, 2010 Issue date: Feb 15, 2010 TAB in-charge: Thomas Nadeau BT Group LLC. About ONTC Prism (www.ontc-prism.org): Prism is a quarterly newsletter aimed at the dissemination of relevant content pertaining to optical and high-speed networks and related growth areas across industry and academia. Prism seeks to promote the growth of optical networking activity by creation of a unified knowledge base and aims to create a communication bridge between industry and academia in terms of research frontiers and complementary strategies for future growth. --Apple-Mail-12-849312939 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii submissions@ontc-prism.org.= All articles will be reviewed by the TAB
and/or external = reviewers.

Timeline:
Submission Deadline: Dec 31, = 2009
Notification: Feb 1, 2010
Issue date: Feb 15, 2010

TAB = in-charge: Thomas Nadeau BT Group LLC.

About ONTC Prism (www.ontc-prism.org): Prism is a = quarterly newsletter
aimed at the dissemination of relevant content = pertaining to optical and
high-speed networks and related growth = areas across industry and academia.
Prism seeks to promote the growth = of optical networking activity by
creation of a unified knowledge = base and aims to create a communication
bridge between industry and = academia in terms of research frontiers and
complementary strategies = for future growth.
= --Apple-Mail-12-849312939--