From hshah@force10networks.com Wed Nov 11 07:55: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 0659C3A67F4 for ; Wed, 11 Nov 2009 07:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 bLbehCXlhE+i for ; Wed, 11 Nov 2009 07:55:11 -0800 (PST) Received: from mx.force10networks.com (corp.force10networks.com [64.186.164.204]) by core3.amsl.com (Postfix) with ESMTP id EA6343A684F for ; Wed, 11 Nov 2009 07:55:10 -0800 (PST) Received: from EXCH-CLUSTER-10.force10networks.com ([10.11.10.130]) by exch7-sjc-fe.force10networks.com ([10.11.0.87]) with mapi; Wed, 11 Nov 2009 07:55:39 -0800 From: Himanshu Shah To: "l2vpn@ietf.org" Date: Wed, 11 Nov 2009 07:55:37 -0800 Subject: IANA allocation status code assignment conflict resolution Thread-Topic: IANA allocation status code assignment conflict resolution Thread-Index: Acpi52lgSD+6IexQQ6qvJSBnU0/A7Q== Message-ID: <34F81DE93A7AA840A6A3B1187BAD5FC8030D0493AA@EXCH-CLUSTER-10.force10networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_34F81DE93A7AA840A6A3B1187BAD5FC8030D0493AAEXCHCLUSTER10_" MIME-Version: 1.0 Cc: Shane Amante , Stewart Bryant , Luca Martini , BOCCI Matthew 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, 11 Nov 2009 15:55:12 -0000 --_000_34F81DE93A7AA840A6A3B1187BAD5FC8030D0493AAEXCHCLUSTER10_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear WG members, There has been a mix-up of the LDP status code assignment between L2VPN signaling and arp-mediation draft. This has been resolved between the authors after some investigative work and has been determined that ARP-Mediation draft can use the 0x2c LDP status code. We intend to request IANA for early allocation of this status code and rect= ify the the current allocation (it shows assignment to l2vpn-signaling). We would like to request the WG to review this matter and express any opinion/concern on the mailing list. Thanks, himanshu and co-authors of ARP-Mediation draft. Following is the detail: Text from arp-mediation draft: (draft-ietf-l2vpn-arp-mediation-12.txt) ------------------------------------------------------------- 7.1. LDP Status messages This document uses new LDP status codes, IANA already maintains a registry of name "STATUS CODE NAME SPACE" defined by [RFC 5036]. The following values are suggested for assignment: 0x0000002C "IP Address of CE" Text from the L2VPN-signaling draft: (draft-ietf-l2vpn-signaling-08.txt) -------------------------------------------------------------- This document assumes the assignment of an AFI and a SAFI for L2VPN NLRI. Both AFI and SAFI should be the same as the values assigned for [I-D.ietf-l2vpn-vpls-bgp]. That is, the AFI should be 25= (L2VPN) and the SAFI should be 65 (already allocated for VPLS). The same AFI and SAFI are used for both VPLS and VPWS autodiscovery as described in this document. [I-D.ietf-pwe3-iana-allocation] defines registries for "Attachment Group Identifier (AGI) Type" and "Attachment Individual Identifier (AII) Type". Type 1 in each registry has been assigned to the AGI and AII formats defined in this document. This document requires two new LDP status codes. IANA already maintains a registry of name "STATUS CODE NAME SPACE" defined by [RFC3036]. The following values are= suggested for assignment: 0x0000002C "Attachment Circuit bound to different PE" --_000_34F81DE93A7AA840A6A3B1187BAD5FC8030D0493AAEXCHCLUSTER10_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Dear WG members,

 

There has been a mix-up of the LDP status code assignment between

L2VPN signaling  and arp-mediation draft. This has been resolved =

between the authors after some investigative work and has been

determined that ARP-Mediation draft can use the 0x2c LDP status code.

We intend to request IANA for early allocation of this status code and rectify= the

the current allocation (it shows assignment to l2vpn-signaling).

 

We would like to request the WG to review this matter and express any

opinion/concern on the mailing list.

 

Thanks,

himanshu and co-authors of ARP-Mediation draft.

 

Following is the detail:

 

Text from arp-=
mediation draft:  (draft-ietf-l2vpn-arp-mediation-12.txt)<=
/o:p>

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

7.1. LDP Status messages<= o:p>

 

    

     This document uses new LDP status codes, IANA already maintains<= /span>

     a registry of name "STATUS CODE NAME SPACE" defined by [RFC<= /o:p>

     5036]. The following values are suggested for assignment:=

    

        0x0000002C "IP Address of CE"

 

Text from the =
L2VPN-signaling draft:  (draft-ietf-l2vpn-signaling-08.txt)
---------------------------------------------------------=
-----

 

This document assumes the assignment of an AFI and a SAFI for L2VPN
   NLRI.  Both AFI and SAFI should be the=
 same as the values assigned
   for [I-D.ietf-l2vpn-vpls-bgp].  That is, the AFI should be 25 (L2VPN)
 =
;  and the SAFI should be 65 (already allocated for VPLS).  The s=
ame AFI
   and SAFI are used for both VPLS a=
nd VPWS autodiscovery as described
   in thi=
s document.
 
   [=
I-D.ietf-pwe3-iana-allocation] defines registries for "Attach=
ment
   Group Identifier (AGI) Type" an=
d "Attachment Individual Identifier
   =
(AII) Type".  Type 1 in each registry has been assigned to the AG=
I
   and AII formats defined in this documen=
t.
 
   This docum=
ent requires two new LDP status codes.  IANA already
<= pre>   maintains a registry of name "STATUS CODE NAME SPACE&= quot; defined by
   [RFC3036].  The following values are suggested for assignm=
ent:
 
   0x000000=
2C "Attachment Circuit bound to different PE"

 

 

 

 

 

--_000_34F81DE93A7AA840A6A3B1187BAD5FC8030D0493AAEXCHCLUSTER10_-- From root@core3.amsl.com Fri Nov 20 15:00:02 2009 Return-Path: X-Original-To: l2vpn@ietf.org Delivered-To: l2vpn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 175293A699D; Fri, 20 Nov 2009 15:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-l2vpn-vpls-multihoming-00.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091120230002.175293A699D@core3.amsl.com> Date: Fri, 20 Nov 2009 15:00:02 -0800 (PST) Cc: l2vpn@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: Fri, 20 Nov 2009 23:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 2 Virtual Private Networks Working Group of the IETF. Title : BGP based Multi-homing in Virtual Private LAN Service Author(s) : B. Kothari, et al. Filename : draft-ietf-l2vpn-vpls-multihoming-00.txt Pages : 19 Date : 2009-11-20 Virtual Private LAN Service (VPLS) is a Layer 2 Virtual Private Network (VPN) that gives its customers the appearance that their sites are connected via a Local Area Network (LAN). It is often required for the Service Provider (SP) to give the customer redundant connectivity to some sites, often called "multi-homing". This memo shows how BGP-based multi-homing can be offered in the context of LDP and BGP VPLS solutions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-multihoming-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-l2vpn-vpls-multihoming-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-11-20145546.I-D@ietf.org> --NextPart-- From simon.delord@gmail.com Thu Nov 26 21:05:53 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 E6AF43A6891; Thu, 26 Nov 2009 21:05:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.726 X-Spam-Level: X-Spam-Status: No, score=-1.726 tagged_above=-999 required=5 tests=[AWL=0.872, BAYES_00=-2.599, 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 q4V3Y4oAUbga; Thu, 26 Nov 2009 21:05:52 -0800 (PST) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id AE9903A6824; Thu, 26 Nov 2009 21:05:52 -0800 (PST) Received: by pzk6 with SMTP id 6so864052pzk.29 for ; Thu, 26 Nov 2009 21:05:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=LLzCQvf7y6tFv8d2fQQx5AZikocMI6oVXsimt0EcAvA=; b=sYqBY5jOefC2zqwnPGomximCyYpLYiUURKWb9kr/NPhXzzYIhhgaw26HI4JaDjJWlC vuJ4iodyUjy/EfMqn0fw5Yl1aVczjhi8+4+45dXinKKdS/sh0Ozs/BrYZ3mVKdl9+Qjg nZ5WHeNp44J1xKT+Rr1mn7TFzzsHLHO09gSwQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=gmWEu6/SIZSpgzHDiPMQm4/m5+HRPps8qv2CKwXK4Egkva57BhuDo/DbBiFjTZXItu Z3NCphMGtdWjJAJsJ6x+b07/9BO/5Cz2i9R74L5sY0sgWv9fFp1q8+by6iD+RDjUKm5y ysPiYYRsqINUAJqZT4w7sv+D0F0ydq6gx9QNo= MIME-Version: 1.0 Received: by 10.115.101.18 with SMTP id d18mr1091186wam.191.1259298344323; Thu, 26 Nov 2009 21:05:44 -0800 (PST) Date: Fri, 27 Nov 2009 16:05:44 +1100 Message-ID: Subject: MEF E-Tree over MPLS/VPLS From: Simon Delord To: pwe3 , l2vpn@ietf.org Content-Type: multipart/alternative; boundary=0016e64b96de7acb590479533e96 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: Fri, 27 Nov 2009 05:05:54 -0000 --0016e64b96de7acb590479533e96 Content-Type: text/plain; charset=ISO-8859-1 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 --0016e64b96de7acb590479533e96 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Bonjour everyone,

We have recently submitted two Internet drafts to both the PWE3 and L2VP= N WG regarding how to implement E-Tree services (defined by the Metro Ether= net 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 Encap= sulation standard (RFC 4448). With such extension, VPLS can be used to supp= ort both E-LAN and E-Tree services at the same time on an MPLS network.=20

http://www.ietf.org/id/draft-key-l2vpn-vpls-etree-01.txt<= /font>=20

http://www.ietf.org/id/draft-delord-pwe3-cw-bit-etr= ee-01.txt=20

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 t= o have the working group members comments on the proposed extension.

In particular, if the authors of the current standards (RFC 4761, RFC 47= 62, RFC 4448) can give us some feedback, it would be fantastic.

We also produced a third document on the L2VPN WG, a framework that expl= ains 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<= /font>

Many thanks.

Simon

 --0016e64b96de7acb590479533e96-- From lmartini@cisco.com Mon Nov 30 19:20:07 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 CF80C3A67E7; Mon, 30 Nov 2009 19:20:07 -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 GlyhyPvdZlzN; Mon, 30 Nov 2009 19:20:06 -0800 (PST) Received: from napoleon.monoski.com (napoleon.monoski.com [67.41.208.110]) by core3.amsl.com (Postfix) with ESMTP id 194BD28C199; Mon, 30 Nov 2009 19:20:06 -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 nB13JmfC003964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Nov 2009 20:19:48 -0700 (MST) Message-ID: <4B148B54.2080007@cisco.com> Date: Mon, 30 Nov 2009 20:19:48 -0700 From: Luca Martini User-Agent: Thunderbird 2.0.0.19 (X11/20081209) MIME-Version: 1.0 To: Simon Delord Subject: Re: [PWE3] MEF E-Tree over MPLS/VPLS References: In-Reply-To: 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 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 03:20:08 -0000 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 > From Edwin.Mallette@bhnis.com Mon Nov 30 21:04:59 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 4BF933A67E1; Mon, 30 Nov 2009 21:04:59 -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 3O1aqNQRswzk; Mon, 30 Nov 2009 21:04:58 -0800 (PST) Received: from mx3.mybrighthouse.com (MX3.mybrighthouse.com [209.16.122.105]) by core3.amsl.com (Postfix) with ESMTP id ECBE928C1BB; Mon, 30 Nov 2009 21:04:57 -0800 (PST) Received: from cntpacas1.corp.local ([10.225.1.123]) by mx3.mybrighthouse.com (8.14.3/8.14.3) with ESMTP id nB154lRY000842 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 1 Dec 2009 00:04:47 -0500 Received: from cntpaowa1.corp.local (10.225.4.5) by cnvscas.corp.local (10.225.1.127) with Microsoft SMTP Server id 8.2.176.0; Tue, 1 Dec 2009 00:04:46 -0500 Received: from CNEMAIL.corp.local ([10.225.1.130]) by cntpaowa1.corp.local ([10.225.4.5]) with mapi; Mon, 30 Nov 2009 23:59:22 -0500 From: "Mallette, Edwin" To: Luca Martini , Simon Delord Date: Mon, 30 Nov 2009 23:59:18 -0500 Subject: RE: [PWE3] MEF E-Tree over MPLS/VPLS Thread-Topic: [PWE3] MEF E-Tree over MPLS/VPLS Thread-Index: AcpyNS3uCATfWS5USqikxReutYtObAABvryA Message-ID: <6569379E42CFCB4192ECE021966F9A444AE61790E5@CNEMAIL.corp.local> 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-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-0911030000 definitions=main-0911300267 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 05:04:59 -0000 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 lear= n if a root lives off a specific pseudowire. Option a) we track the presen= ce of the L-bit from a pseudowire (in a table like the bridge table) to ens= ure we correctly forward from leaf to root, root to root, etc. Option b) w= e use a BGP autodiscovery mechanism to distribute whether a PE "owns" a roo= t 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 frame is f= orwarded 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 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 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.