From Internet-Drafts@ietf.org Tue Mar 1 13:00:07 2011 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 614BC3A6AB3; Tue, 1 Mar 2011 13:00:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, 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 r2uiCpgB9IjH; Tue, 1 Mar 2011 13:00:03 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9D303A6AA9; Tue, 1 Mar 2011 13:00:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-l2vpn-pbb-vpls-pe-model-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110301210002.15271.15304.idtracker@localhost> Date: Tue, 01 Mar 2011 13:00:02 -0800 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: Tue, 01 Mar 2011 21:00:07 -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 : Extensions to VPLS PE model for Provider Backbone Bridging Author(s) : A. Sajassi, et al. Filename : draft-ietf-l2vpn-pbb-vpls-pe-model-03.txt Pages : 14 Date : 2011-03-01 IEEE 802.1ah standard [IEEE802.1ah], also known as Provider Backbone Bridges (PBB) defines an architecture and bridge protocols for interconnection of multiple Provider Bridge Networks (PBNs). PBB was defined in IEEE as a connectionless technology based on multipoint VLAN tunnels. MSTP is used as the core control plane for loop avoidance and load balancing. As a result, the coverage of the solution is limited by STP scale in the core of large service provider networks. PBB on the other hand can be used to attain better scalability in terms of number of customer MAC addresses and number of service instances that can be supported. Virtual Private LAN Service (VPLS) [RFC4664] provides a framework for extending Ethernet LAN services, using MPLS tunneling capabilities, through a routed MPLS backbone without running (M)STP across the backbone. As a result, VPLS has been deployed on a large scale in service provider networks. This draft discusses extensions to the VPLS PE model required to incorporate desirable PBB components while maintaining the Service Provider fit of the initial model. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-pbb-vpls-pe-model-03.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-pbb-vpls-pe-model-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-01125657.I-D@ietf.org> --NextPart-- From nabil.n.bitar@verizon.com Wed Mar 2 04:38:38 2011 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 7D6723A67D1 for ; Wed, 2 Mar 2011 04:38:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.228 X-Spam-Level: X-Spam-Status: No, score=-3.228 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 tyrKDT1r587P for ; Wed, 2 Mar 2011 04:38:34 -0800 (PST) Received: from sacmail2.verizon.com (sacmail2.verizon.com [192.76.84.41]) by core3.amsl.com (Postfix) with ESMTP id 035A53A6C3A for ; Wed, 2 Mar 2011 04:38:31 -0800 (PST) Received: from fldsmtpi01.verizon.com (fldsmtpi01.verizon.com [166.68.71.143]) by sacmail2.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p22CdWYJ012635 for ; Wed, 2 Mar 2011 07:39:32 -0500 (EST) From: "Bitar, Nabil N" X-IronPort-AV: E=Sophos;i="4.62,253,1297036800"; d="scan'208,217";a="3916592" Received: from fldp1lumxc7hb04.verizon.com (HELO FLDP1LUMXC7HB04.us.one.verizon.com) ([166.68.75.83]) by fldsmtpi01.verizon.com with ESMTP; 02 Mar 2011 12:39:32 +0000 Received: from fldp1lumxc7v63.us.one.verizon.com ([fe80::303e:41f6:bcf4:d607]) by FLDP1LUMXC7HB04.us.one.verizon.com ([2002:a644:4b53::a644:4b53]) with mapi; Wed, 2 Mar 2011 07:39:32 -0500 To: "l2vpn@ietf.org" Date: Wed, 2 Mar 2011 07:39:32 -0500 Subject: Re: [l2vpn] WG last call for draft-ietf-l2vpn-vpls-mcast-08.txt Thread-Topic: [l2vpn] WG last call for draft-ietf-l2vpn-vpls-mcast-08.txt Thread-Index: AcvR9YWrVnCYJkRc7ESrJrvX/vcvBwG4Vta9 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C993A4B413000nabilnbitarverizoncom_" MIME-Version: 1.0 Cc: "y.kamite@ntt.com" , Giles Heron , "lufang@cisco.com" , Rahul Aggarwal 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 Mar 2011 12:38:38 -0000 --_000_C993A4B413000nabilnbitarverizoncom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Just a friendly reminder that this draft LC will close on March 8th 2011. P= lease send your comments to L2VPN WG email list. Thanks, Nabil On 2/21/11 1:31 PM, "Nabil Bitar" wrote: This is the start of a two-week working group last call on the draft "Multi= cast in VPLS". The draft can be found at http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-= mcast-08. Please, review the draft and send any comments to the L2VPN working group e= mail list. This WG last call will close on Tuesday March 8th, 2011. Regards, Nabil --------------------------------------------- Nabil Bitar, PhD Principal Member of Technical Staff Packet Network Technology Verizon Corporate Network and Technology 60 Sylvan Road Waltham, MA 02451 Office Phone: (781) 466-2161 --_000_C993A4B413000nabilnbitarverizoncom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [l2vpn] WG last call for draft-ietf-l2vpn-vpls-mcast-08.txt</TIT= LE> </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:= 11pt'>Just a friendly reminder that this draft LC will close on March 8th 2= 011. Please send your comments to L2VPN WG email list.<BR> <BR> Thanks,<BR> Nabil<BR> <BR> <BR> On 2/21/11 1:31 PM, "Nabil Bitar" <<a href=3D"nabil.n.bitar@ve= rizon.com">nabil.n.bitar@verizon.com</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'fon= t-size:12pt'><BR> This is the start of a two-week working group last call on the draft “= ;</SPAN></FONT><SPAN STYLE=3D'font-size:12pt'><FONT FACE=3D"Cambria">Multic= ast in VPLS</FONT><FONT FACE=3D"Times New Roman">”. <BR> The draft can be found at <FONT COLOR=3D"#0000FF"><U><a href=3D"http://tool= s.ietf.org/html/draft-ietf-l2vpn-vpls-mcast-08">http://tools.ietf.org/html/= draft-ietf-l2vpn-vpls-mcast-08</a></U></FONT>.<BR>  <BR> Please, review the draft and send any comments to the L2VPN working group e= mail list. <BR> <BR> This WG last call will close on Tuesday March 8th, 2011.<BR>  <BR> Regards,<BR> Nabil<BR> </FONT></SPAN></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial= "><SPAN STYLE=3D'font-size:11pt'><BR> ---------------------------------------------<BR> Nabil Bitar, PhD<BR> Principal Member of Technical Staff<BR> Packet Network Technology<BR> Verizon Corporate Network and Technology<BR> <BR> 60 Sylvan Road<BR> Waltham, MA 02451<BR> Office Phone: (781) 466-2161<BR> </SPAN></FONT> </BODY> </HTML> --_000_C993A4B413000nabilnbitarverizoncom_-- From nabil.n.bitar@verizon.com Wed Mar 2 04:50:29 2011 Return-Path: <nabil.n.bitar@verizon.com> 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 15DD83A67D1 for <l2vpn@core3.amsl.com>; Wed, 2 Mar 2011 04:50:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.321 X-Spam-Level: X-Spam-Status: No, score=-3.321 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 oDG0QLdbvlJa for <l2vpn@core3.amsl.com>; Wed, 2 Mar 2011 04:50:24 -0800 (PST) Received: from sacmail4.verizon.com (sacmail4.verizon.com [192.76.84.42]) by core3.amsl.com (Postfix) with ESMTP id BECAB3A67AD for <l2vpn@ietf.org>; Wed, 2 Mar 2011 04:50:24 -0800 (PST) Received: from fldsmtpi03.verizon.com (fldsmtpi03.verizon.com [166.68.71.145]) by sacmail4.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p22CpUJw009899 for <l2vpn@ietf.org>; Wed, 2 Mar 2011 07:51:30 -0500 (EST) From: "Bitar, Nabil N" <nabil.n.bitar@verizon.com> X-IronPort-AV: E=Sophos;i="4.62,253,1297036800"; d="scan'208,217";a="3924969" Received: from fldp1lumxc7hb02.verizon.com (HELO FLDP1LUMXC7HB02.us.one.verizon.com) ([166.68.75.85]) by fldsmtpi03.verizon.com with ESMTP; 02 Mar 2011 12:51:30 +0000 Received: from fldp1lumxc7v63.us.one.verizon.com ([fe80::303e:41f6:bcf4:d607]) by FLDP1LUMXC7HB02.us.one.verizon.com ([2002:a644:4b55::a644:4b55]) with mapi; Wed, 2 Mar 2011 07:51:30 -0500 To: "l2vpn@ietf.org" <l2vpn@ietf.org> Date: Wed, 2 Mar 2011 07:51:29 -0500 Subject: L2VPN Agenda Slot Call for IETF 80 - Prague : Reminder Thread-Topic: L2VPN Agenda Slot Call for IETF 80 - Prague : Reminder Thread-Index: AcvOkeGOaVyb9NhWMES00dp+3+qfygKRqrXz Message-ID: <C993A781.13008%nabil.n.bitar@verizon.com> In-Reply-To: <C98269FA.12956%nabil.n.bitar@verizon.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C993A78113008nabilnbitarverizoncom_" MIME-Version: 1.0 Cc: "Giles Heron \(giheron\)" <giheron@cisco.com> X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <l2vpn.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/l2vpn> List-Post: <mailto:l2vpn@ietf.org> List-Help: <mailto:l2vpn-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 02 Mar 2011 12:50:29 -0000 --_000_C993A78113008nabilnbitarverizoncom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is a reminder if you would like to request a time slot for the L2VPN s= ession at IETF 80 - Prague. Please, see email below for details and for dra= ft submission dates. In addition, the IETF-80 meeting agenda had been posted. It can be found at= : https://datatracker.ietf.org/meeting/80/agenda.html The L2vpn WG session is scheduled for Tuesday March 29, 2011 9-11:30AM. Thanks, Nabil On 2/17/11 6:00 AM, "Nabil Bitar" <nabil.n.bitar@verizon.com> wrote: Hi L2VPN WG. Please let us know if you have a time-slot request for the L2VPN session at= IETF 80 - Prague. Please, email us your request by Sunday March 13 2011 a= long with the following information: 1) Draft title 2) Presenter name 3) Requested duration Please note that priority will be given to drafts that are clearly within t= he scope of the current L2VPN charter. Additional key dates to remember are: 2011-03-07 (Monday): Internet Draft Cut-off for initial document (-00) subm= ission by 17:00 PT (01:00 Tuesday, March 8 UTC) 2011-03-14 (Monday): Internet Draft final submission cut-off by 17:00 PT (0= 1:00 Tuesday, March 15 UTC) Thanks, Giles and Nabil --------------------------------------------- Nabil Bitar, PhD Principal Member of Technical Staff Packet Network Technology Verizon Corporate Network and Technology 60 Sylvan Road Waltham, MA 02451 Office Phone: (781) 466-2161 --_000_C993A78113008nabilnbitarverizoncom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <HTML> <HEAD> <TITLE>L2VPN Agenda Slot Call for IETF 80 - Prague : Reminder This is a reminder if you would like to request a time slot for the L= 2VPN session at IETF 80 – Prague. Please, see email below for details= and for draft submission dates.
In addition, the IETF-80 meeting agenda had been posted. It can be found at= :

 https= ://datatracker.ietf.org/meeting/80/agenda.html

The L2vpn WG session is scheduled for Tuesday March 29, 2011  9-11:30A= M.

Thanks,
Nabil



On 2/17/11 6:00 AM, "Nabil Bitar" <nabil.n.bitar@verizon.com> wrote:

Hi L2VPN WG.
Please let us know if you have a time-slot request for the L2VPN session at= IETF 80 – Prague. Please,  email us your request by Sunday Marc= h 13 2011 along with the following information:
1) Draft title
2) Presenter name
3) Requested duration

Please note that priority will be given to drafts that are clearly within t= he scope of the current L2VPN charter.

Additional key dates to remember are:
2011-03-07 (Monday): Internet Draft Cut-off for initial document (-00) subm= ission by 17:00 PT (01:00 Tuesday, March 8 UTC)
2011-03-14 (Monday): Internet Draft final submission cut-off by 17:00 PT (0= 1:00 Tuesday, March 15 UTC)

Thanks,
Giles and Nabil
Date: Mon, 07 Mar 2011 12:15:02 -0800 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: Mon, 07 Mar 2011 20:15:08 -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 : ARP Mediation for IP Interworking of Layer 2 VPN Author(s) : H. Shah, et al Filename : draft-ietf-l2vpn-arp-mediation-16.txt Pages : 33 Date : 2011-03-07 The Virtual Private Wire Service (VPWS) [RFC4664] provides point-to-point connections between pairs of Customer Edge (CE) devices. It does so by binding two Attachment Circuits (each connecting a CE device with a Provider Edge, PE, device) to a pseudowire (connecting the two PEs). In general, the Attachment Circuits must be of the same technology (e.g., both Ethernet, both ATM), and the pseudowire must carry the frames of that technology. However, if it is known that the frames' payload consists solely of IP datagrams, it is possible to provide a point-to-point connection in which the pseudowire connects Attachment Circuits of different technologies. This requires the PEs to perform a function known as "ARP Mediation". ARP Mediation refers to the process of resolving Layer 2 addresses when different resolution protocols are used on either Attachment Circuit. The methods described in this document are applicable even when the CEs run a routing protocol between them, as long as the routing protocol runs over IP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-arp-mediation-16.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-arp-mediation-16.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-07121140.I-D@ietf.org> --NextPart-- From nabil.n.bitar@verizon.com Tue Mar 8 05:37:11 2011 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 680BE3A686C for ; Tue, 8 Mar 2011 05:37:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.376 X-Spam-Level: X-Spam-Status: No, score=-3.376 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 NRbApEzl3vBw for ; Tue, 8 Mar 2011 05:37:05 -0800 (PST) Received: from sacmail4.verizon.com (sacmail4.verizon.com [192.76.84.42]) by core3.amsl.com (Postfix) with ESMTP id B06F33A67A8 for ; Tue, 8 Mar 2011 05:37:05 -0800 (PST) Received: from fldsmtpi03.verizon.com (fldsmtpi03.verizon.com [166.68.71.145]) by sacmail4.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p28DcDPI000396 for ; Tue, 8 Mar 2011 08:38:16 -0500 (EST) From: "Bitar, Nabil N" X-IronPort-AV: E=Sophos;i="4.62,284,1297036800"; d="scan'208,217";a="7432211" Received: from fldp1lumxc7hb01.verizon.com (HELO FLDP1LUMXC7HB01.us.one.verizon.com) ([166.68.45.78]) by fldsmtpi03.verizon.com with ESMTP; 08 Mar 2011 13:38:13 +0000 Received: from fldp1lumxc7v63.us.one.verizon.com ([fe80::303e:41f6:bcf4:d607]) by FLDP1LUMXC7HB01.us.one.verizon.com ([2002:a644:2d4e::a644:2d4e]) with mapi; Tue, 8 Mar 2011 08:38:11 -0500 To: "l2vpn@ietf.org" Date: Tue, 8 Mar 2011 08:38:11 -0500 Subject: [l2vpn] VPWS OAM Interworking (draft-ietf-l2vpn-vpws-iw-oam-01.txt) survey to implementers and service providers. Your feedback is needed Thread-Topic: [l2vpn] VPWS OAM Interworking (draft-ietf-l2vpn-vpws-iw-oam-01.txt) survey to implementers and service providers. Your feedback is needed Thread-Index: AcvZoNpCpvkJRPsaHkysORzEsnLf5wD7C9D3 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C99B8C4D1338Cnabilnbitarverizoncom_" MIME-Version: 1.0 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, 08 Mar 2011 13:37:11 -0000 --_000_C99B8C4D1338Cnabilnbitarverizoncom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, This is a survey to implementers (equipment vendors) and to service provide= rs in order to assist in progressing draft-ietf-l2vpn-vpws-iw-oam-01.txt, "= OAM Procedures for VPWS Interworking". Since this draft has existed for som= e time and given the technologies involved, we are assuming that vendors wo= uld have implemented what the market needs by this time and that service pr= oviders would have deployed the technology that satisfies their needs. The = goal of the survey is to enable focusing on the technologies of interest go= ing forward. Please respond to the survey below by replying to me only at nabil.n.bitar@= verizon.com. Your response will remain confidential. As a co-chair of the l= 2vpn WG, I will present the results in number of implementations and in num= ber of users without mentioning company names. You may include comments in = your response, if needed, following each question. This survey will close i= n 2 weeks on Tuesday March 22, 2011. Your response is appreciated by the su= rvey closure date. Are you an equipment vendor? (Y/N) Are you a service provider? (Y/N) What is your company name? Needed for authenticity. Please, remember this w= ill remain confidential and will not be included in the published survey re= sults Has the VPWS OAM Interworking implementation included any the of following = VPWS types and corresponding OAM interworking models as stated in the intro= duction section of draft-ietf-l2vpn-vpws-iw-oam-01.txt and in Table 1 of th= at document: 1. VPWS with heterogeneous ACs of ATM and FR types, and in which the PW type is ATM or FR. In this case, FR-ATM service interworking [FRF8.2] is performed in PE1 (or PE2) and a FR (or ATM) PW is extended to the remote PE. This VPWS type will be referred to as "FR-ATM Interworking VPWS". (Y/N)? In addition, please indicate which PW type is supported: a. ATM cell mode PW. (Y/N)? b. ATM AAL5 PDU/SDU mode PW. If one of the two types is supported, = state which one is supported. (Y/N)? c. FR PW. (Y/N)? 2. VPWS with heterogeneous ACs of ATM, FR, and Ethernet types, and in which the PW type is Ethernet. This VPWS type will be referred to as "Ethernet Interworking VPWS". (Y/N)? 3. VPWS with heterogeneous ACs of ATM, FR, and Ethernet types, and in which the PW type is IP [ARP-Mediation]. This VPWS type will be referred to as "IP Interworking VPWS". (Y/N)? Regards, Nabil --_000_C99B8C4D1338Cnabilnbitarverizoncom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [l2vpn] VPWS OAM Interworking (draft-ietf-l2vpn-vpws-iw-oam-01.txt) = survey  to implementers and service providers. Your feedback is needed=
Hi,

This is a survey to implementers (equipment vendors) and to service provide= rs in order to assist in progressing draft-ietf-l2vpn-vpws-iw-oam-01.txt, &= #8220;OAM Procedures for VPWS Interworking”. Since this draft has exi= sted for some time and given the technologies involved, we are assuming tha= t vendors would have implemented what the market needs by this time and tha= t service providers would have deployed the technology that satisfies their= needs. The goal of the survey is to enable focusing on the technologies of= interest going forward.

Please respond to the survey below by replying to me only at nabil.n.bitar@verizon.com. Your response will r= emain confidential. As a co-chair of the l2vpn WG, I will present the resul= ts in number of implementations and in number of users without mentioning c= ompany names. You may include comments in your response, if needed, followi= ng each question. This survey will close in 2 weeks on Tuesday March 22,= 2011. Your response is appreciated by the survey closure date.


Are you an equipment vendor? (Y/N)
Are you a service provider? (Y/N)
What is your company name? Needed for authenticity. Please, remember th= is will remain confidential and will not be included in the published surve= y results


Has the VPWS OAM Interworking implementation included any the of following = VPWS types and corresponding OAM interworking models as stated in the intro= duction section of draft-ietf-l2vpn-vpws-iw-oam-01.txt and in Table 1 of th= at document:
  
     1. VPWS with heterogeneous ACs of ATM and FR = types, and in which
        the PW type is ATM or FR. I= n this case, FR-ATM service
        interworking [FRF8.2] is performed in PE1 (or PE2) and a FR (o= r
        ATM) PW is extended to the = remote PE. This VPWS type will be
        referred to as "FR-ATM= Interworking VPWS". (Y/N)?
        
    In addition, please indicate which PW type is suppor= ted:
         a. ATM cell mode PW. = (Y/N)?
         b. ATM AAL5 PDU/SDU mo= de PW. If one of the two types is supported, state which one is supported. = (Y/N)?
         c. FR PW. (Y/N)?   
     2. VPWS with heterogeneous ACs of ATM, FR, an= d Ethernet types, and
        in which the PW type is Eth= ernet. This VPWS type will be
        referred to as "Ethern= et Interworking VPWS". (Y/N)?
  
     3. VPWS with heterogeneous ACs of ATM, FR, an= d Ethernet types, and
        in which the PW type is IP = [ARP-Mediation]. This VPWS type will
        be referred to as "IP = Interworking VPWS". (Y/N)?


Regards,
Nabil --_000_C99B8C4D1338Cnabilnbitarverizoncom_-- From wwwrun@core3.amsl.com Mon Feb 28 08:36:54 2011 Return-Path: X-Original-To: l2vpn@ietf.org Delivered-To: l2vpn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 0770E3A6C2F; Mon, 28 Feb 2011 08:36:53 -0800 (PST) To: florin.balus@alcatel-lucent.com,sajassi@cisco.com,metz@cisco.com From: IETF Secretariat Subject: IPR Disclosure: Nortel Networks Limited Statement about IPR claimed in draft-ietf-l2vpn-pbb-vpls-interop-00 Message-Id: <20110228163654.0770E3A6C2F@core3.amsl.com> Date: Mon, 28 Feb 2011 08:36:54 -0800 (PST) X-Mailman-Approved-At: Fri, 11 Mar 2011 09:59:18 -0800 Cc: l2vpn@ietf.org, giheron@cisco.com, housley@vigilsec.com, adrian.farrel@huawei.com, ipr-announce@ietf.org, stbryant@cisco.com 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: Mon, 28 Feb 2011 16:36:54 -0000 Dear Florin Balus, Ali Sajassi, San Jose: An IPR disclosure that pertains to your Internet-Draft entitled "VPLS Interoperability with Provider Backbone Bridges" (draft-ietf-l2vpn-pbb-vpls-interop) was submitted to the IETF Secretariat on 2011-02-25 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1497/). The title of the IPR disclosure is " Nortel Networks Limited Statement about IPR claimed in draft-ietf-l2vpn-pbb-vpls-interop-00." The IETF Secretariat From wwwrun@core3.amsl.com Mon Feb 28 08:44:28 2011 Return-Path: X-Original-To: l2vpn@ietf.org Delivered-To: l2vpn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 91BC63A6BE1; Mon, 28 Feb 2011 08:44:28 -0800 (PST) To: florin.balus@alcatel-lucent.com,raymond.zhang@bt.com,sajassi@cisco.com From: IETF Secretariat Subject: IPR Disclosure: Nortel Networks Limited Statement about IPR claimed in draft-ietf-l2vpn-pbb-vpls-pe-model-02 Message-Id: <20110228164428.91BC63A6BE1@core3.amsl.com> Date: Mon, 28 Feb 2011 08:44:28 -0800 (PST) X-Mailman-Approved-At: Fri, 11 Mar 2011 09:59:18 -0800 Cc: l2vpn@ietf.org, giheron@cisco.com, housley@vigilsec.com, adrian.farrel@huawei.com, ipr-announce@ietf.org, stbryant@cisco.com 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: Mon, 28 Feb 2011 16:44:28 -0000 Dear Florin Balus, Raymond Zhang, Ali Sajassi: An IPR disclosure that pertains to your Internet-Draft entitled "Extensions to VPLS PE model for Provider Backbone Bridging" (draft-ietf-l2vpn-pbb-vpls-pe-model) was submitted to the IETF Secretariat on 2011-02-25 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1498/). The title of the IPR disclosure is "Nortel Networks Limited Statement about IPR claimed in draft-ietf-l2vpn-pbb-vpls-pe-model-02." The IETF Secretariat From wwwrun@rfc-editor.org Fri Mar 11 18:11:24 2011 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 C48CF3A6C9F; Fri, 11 Mar 2011 18:11:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.415 X-Spam-Level: X-Spam-Status: No, score=-102.415 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 Cj0IQYQVmogQ; Fri, 11 Mar 2011 18:11:19 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 355F23A6C99; Fri, 11 Mar 2011 18:11:14 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 4836AE0759; Fri, 11 Mar 2011 18:12:34 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 6136 on Layer 2 Virtual Private Network (L2VPN) Operations, Administration, and Maintenance (OAM) Requirements and Framework From: rfc-editor@rfc-editor.org Message-Id: <20110312021234.4836AE0759@rfc-editor.org> Date: Fri, 11 Mar 2011 18:12:34 -0800 (PST) Cc: l2vpn@ietf.org, rfc-editor@rfc-editor.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: Sat, 12 Mar 2011 02:11:25 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6136 Title: Layer 2 Virtual Private Network (L2VPN) Operations, Administration, and Maintenance (OAM) Requirements and Framework Author: A. Sajassi, Ed., D. Mohan, Ed. Status: Informational Stream: IETF Date: March 2011 Mailbox: sajassi@cisco.com, mohand@nortel.com Pages: 42 Characters: 92170 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-l2vpn-oam-req-frmk-11.txt URL: http://www.rfc-editor.org/rfc/rfc6136.txt This document provides framework and requirements for Layer 2 Virtual Private Network (L2VPN) Operations, Administration, and Maintenance (OAM). The OAM framework is intended to provide OAM layering across L2VPN services, pseudowires (PWs), and Packet Switched Network (PSN) tunnels. This document is intended to identify OAM requirements for L2VPN services, i.e., Virtual Private LAN Service (VPLS), Virtual Private Wire Service (VPWS), and IP-only LAN Service (IPLS). Furthermore, if L2VPN service OAM requirements impose specific requirements on PW OAM and/or PSN OAM, those specific PW and/or PSN OAM requirements are also identified. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Layer 2 Virtual Private Networks Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nabil.n.bitar@verizon.com Sat Mar 12 06:27:27 2011 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 467533A69AB for ; Sat, 12 Mar 2011 06:27:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.413 X-Spam-Level: X-Spam-Status: No, score=-3.413 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 gcOPSv-VO+l1 for ; Sat, 12 Mar 2011 06:27:23 -0800 (PST) Received: from sacmail2.verizon.com (sacmail2.verizon.com [192.76.84.41]) by core3.amsl.com (Postfix) with ESMTP id 82FDF3A6868 for ; Sat, 12 Mar 2011 06:27:15 -0800 (PST) Received: from fldsmtpi03.verizon.com (fldsmtpi03.verizon.com [166.68.71.145]) by sacmail2.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p2CESNFN017950 for ; Sat, 12 Mar 2011 09:28:28 -0500 (EST) From: "Bitar, Nabil N" To: "Bitar, Nabil N" , "l2vpn@ietf.org" X-IronPort-AV: E=Sophos;i="4.62,307,1297036800"; d="scan'208,217";a="10275642" Received: from fldp1lumxc7hb03.verizon.com (HELO FLDP1LUMXC7HB03.us.one.verizon.com) ([166.68.75.86]) by fldsmtpi03.verizon.com with ESMTP; 12 Mar 2011 14:28:23 +0000 Received: from fldp1lumxc7v63.us.one.verizon.com ([fe80::303e:41f6:bcf4:d607]) by FLDP1LUMXC7HB03.us.one.verizon.com ([2002:a644:4b56::a644:4b56]) with mapi; Sat, 12 Mar 2011 09:28:23 -0500 Date: Sat, 12 Mar 2011 09:28:21 -0500 Subject: [l2vpn] WG last call results for draft-ietf-l2vpn-vpls-mcast-08.txt Thread-Topic: [l2vpn] WG last call results for draft-ietf-l2vpn-vpls-mcast-08.txt Thread-Index: AcvR9YWrVnCYJkRc7ESrJrvX/vcvBwOv7BUl Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C9A0D83113639nabilnbitarverizoncom_" MIME-Version: 1.0 Cc: "y.kamite@ntt.com" , "lufang@cisco.com" , Giles Heron , Rahul Aggarwal 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: Sat, 12 Mar 2011 14:27:27 -0000 --_000_C9A0D83113639nabilnbitarverizoncom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, The WG last call closed on Tuesday march 8th 2011. There was no feedback r= eceived during the last call. This will be interpreted as implicit support = to proceed. The authors will work with the WG chairs to proceed with the dr= aft. Thanks, Nabil On 2/21/11 1:31 PM, "Bitar, Nabil N" wrote: This is the start of a two-week working group last call on the draft "Multi= cast in VPLS". The draft can be found at http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-= mcast-08. Please, review the draft and send any comments to the L2VPN working group e= mail list. This WG last call will close on Tuesday March 8th, 2011. Regards, Nabil --------------------------------------------- Nabil Bitar, PhD Principal Member of Technical Staff Packet Network Technology Verizon Corporate Network and Technology 60 Sylvan Road Waltham, MA 02451 Office Phone: (781) 466-2161 --_000_C9A0D83113639nabilnbitarverizoncom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [l2vpn] WG last call results for draft-ietf-l2vpn-vpls-mcast-08.txt<= /TITLE> </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:= 11pt'>Hi,<BR> The WG last call closed on Tuesday march 8th 2011.  There was no feedb= ack received during the last call. This will be interpreted as implicit sup= port to proceed. The authors will work with the WG chairs to proceed with t= he draft.<BR> <BR> Thanks,<BR> Nabil<BR> <BR> <BR> On 2/21/11 1:31 PM, "Bitar, Nabil N" <<a href=3D"nabil.n.bitar= @one.verizon.com">nabil.n.bitar@one.verizon.com</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'fon= t-size:12pt'><BR> This is the start of a two-week working group last call on the draft “= ;</SPAN></FONT><SPAN STYLE=3D'font-size:12pt'><FONT FACE=3D"Cambria">Multic= ast in VPLS</FONT><FONT FACE=3D"Times New Roman">”. <BR> The draft can be found at <FONT COLOR=3D"#0000FF"><U><a href=3D"http://tool= s.ietf.org/html/draft-ietf-l2vpn-vpls-mcast-08">http://tools.ietf.org/html/= draft-ietf-l2vpn-vpls-mcast-08</a></U></FONT>.<BR>  <BR> Please, review the draft and send any comments to the L2VPN working group e= mail list. <BR> <BR> This WG last call will close on Tuesday March 8th, 2011.<BR>  <BR> Regards,<BR> Nabil<BR> </FONT></SPAN><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE= =3D'font-size:11pt'><BR> </SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial= "><SPAN STYLE=3D'font-size:11pt'><BR> ---------------------------------------------<BR> Nabil Bitar, PhD<BR> Principal Member of Technical Staff<BR> Packet Network Technology<BR> Verizon Corporate Network and Technology<BR> <BR> 60 Sylvan Road<BR> Waltham, MA 02451<BR> Office Phone: (781) 466-2161<BR> </SPAN></FONT> </BODY> </HTML> --_000_C9A0D83113639nabilnbitarverizoncom_-- From nabil.n.bitar@verizon.com Sat Mar 12 07:26:18 2011 Return-Path: <nabil.n.bitar@verizon.com> 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 437113A69DA for <l2vpn@core3.amsl.com>; Sat, 12 Mar 2011 07:26:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.439 X-Spam-Level: X-Spam-Status: No, score=-3.439 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 iM4WmJM8p-bN for <l2vpn@core3.amsl.com>; Sat, 12 Mar 2011 07:26:17 -0800 (PST) Received: from sacmail2.verizon.com (sacmail2.verizon.com [192.76.84.41]) by core3.amsl.com (Postfix) with ESMTP id 73A853A69D7 for <l2vpn@ietf.org>; Sat, 12 Mar 2011 07:26:17 -0800 (PST) Received: from fldsmtpi02.verizon.com (fldsmtpi02.verizon.com [166.68.71.144]) by sacmail2.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p2CFRRfb011472 for <l2vpn@ietf.org>; Sat, 12 Mar 2011 10:27:28 -0500 (EST) From: "Bitar, Nabil N" <nabil.n.bitar@verizon.com> X-IronPort-AV: E=Sophos;i="4.62,307,1297036800"; d="scan'208,217";a="10298535" Received: from fldp1lumxc7hb04.verizon.com (HELO FLDP1LUMXC7HB04.us.one.verizon.com) ([166.68.75.83]) by fldsmtpi02.verizon.com with ESMTP; 12 Mar 2011 15:27:27 +0000 Received: from fldp1lumxc7v63.us.one.verizon.com ([fe80::303e:41f6:bcf4:d607]) by FLDP1LUMXC7HB04.us.one.verizon.com ([2002:a644:4b53::a644:4b53]) with mapi; Sat, 12 Mar 2011 10:27:27 -0500 To: "l2vpn@ietf.org" <l2vpn@ietf.org> Date: Sat, 12 Mar 2011 10:27:25 -0500 Subject: [l2vpn] WG Last Call for updates in draft-ietf-l2vpn-arp-mediation-16.txt Thread-Topic: [l2vpn] WG Last Call for updates in draft-ietf-l2vpn-arp-mediation-16.txt Thread-Index: Acvgyf0gzEwRXQeJzEyL8hqC3ZD1OA== Message-ID: <C9A0FB0D.13662%nabil.n.bitar@verizon.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C9A0FB0D13662nabilnbitarverizoncom_" MIME-Version: 1.0 Cc: "Giles Heron \(giheron\)" <giheron@cisco.com> X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <l2vpn.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/l2vpn> List-Post: <mailto:l2vpn@ietf.org> List-Help: <mailto:l2vpn-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 12 Mar 2011 15:26:18 -0000 --_000_C9A0FB0D13662nabilnbitarverizoncom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Following the working group last call on draft-ietf-l2vpn-arp-mediation-15.= txt, there were some updates made to the draft that have technical implicat= ion in addition to minor editorial changes. This WG LC is focusing on section 5.2 and section 6 of draft-ietf-l2vpn-arp= -mediation-16.txt where the technical changes were made, and it is specific= ally to call the working group attention to these changes. The draft can be= fount at http://tools.ietf.org/html/draft-ietf-l2vpn-arp-mediation-16. This last call will end on Sunday March 20, 2011. Please, send your comment= s to the L2VPN WG email list. Thanks, Nabil & Giles --_000_C9A0FB0D13662nabilnbitarverizoncom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <HTML> <HEAD> <TITLE>[l2vpn] WG Last Call for updates in draft-ietf-l2vpn-arp-mediation-1= 6.txt Following the working group last call on draft-ietf-l2vpn-arp-mediati= on-15.txt, there were some updates made to the draft that have technical im= plication in addition to minor editorial changes.

This WG LC is focusing on section 5.2 and section 6 of draft-ietf-l2vpn-arp= -mediation-16.txt where the technical changes were made, and it is specific= ally to call the working group attention to these changes. The draft can be= fount at http://tools.ietf.org/html/draft-ietf-l2vpn-arp-mediation-16.
This last call will end on Sunday March 20, 2011. Please, send your comment= s to the L2VPN WG email list.

Thanks,
Nabil & Giles
 --_000_C9A0FB0D13662nabilnbitarverizoncom_-- From Internet-Drafts@ietf.org Mon Mar 14 09:00:09 2011 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 785F63A6DF7; Mon, 14 Mar 2011 09:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, 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 ezwdkkejH1WJ; Mon, 14 Mar 2011 09:00:06 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 485163A6DFB; Mon, 14 Mar 2011 09:00:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D ACTION:draft-ietf-l2vpn-vpws-iw-oam-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110314160003.12937.462.idtracker@localhost> Date: Mon, 14 Mar 2011 09:00:03 -0700 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: Mon, 14 Mar 2011 16:00:09 -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 : OAM Procedures for VPWS Interworking Author(s) : M. Aissaoui Filename : draft-ietf-l2vpn-vpws-iw-oam-02.txt Pages : 12 Date : 2011-03-14 This draft proposes OAM procedures for the Ethernet interworking, IP interworking and FR-ATM interworking Virtual Private Wire Service (VPWS). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpws-iw-oam-02.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-vpws-iw-oam-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14085414.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Mon Mar 14 15:00:11 2011 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 175E23A6FD7; Mon, 14 Mar 2011 15:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, 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 viXCurEA++21; Mon, 14 Mar 2011 15:00:06 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 630193A6F95; Mon, 14 Mar 2011 15:00:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-l2vpn-pbb-vpls-interop-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110314220004.1830.64579.idtracker@localhost> Date: Mon, 14 Mar 2011 15:00:04 -0700 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: Mon, 14 Mar 2011 22:00:11 -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 : VPLS Interoperability with Provider Backbone Bridges Author(s) : A. Sajassi, et al. Filename : draft-ietf-l2vpn-pbb-vpls-interop-01.txt Pages : 23 Date : 2011-03-14 The scalability of H-VPLS with Ethernet access network can be improved by incorporating Provider Backbone Bridge functionality in VPLS access. Provider Backbone Bridging has been standardized as IEEE 802.1ah-2008, and aims to improve the scalability of MAC addresses and service instances in Provider Ethernet networks. This document describes different interoperability scenarios where Provider Backbone Bridge functionality is used in H-VPLS with Ethernet or MPLS access network to attain better scalability in terms of number of customer MAC addresses and number of service instances. The document also describes the scenarios and the mechanisms for incorporating Provider Backbone Bridge functionality within H-VPLS with existing Ethernet access and interoperability among them. Furthermore, the document discusses the migration mechanisms and scenarios by which Provider Backbone Bridge functionality can be incorporated into H-VPLS with existing MPLS access. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-pbb-vpls-interop-01.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-pbb-vpls-interop-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14144946.I-D@ietf.org> --NextPart-- From jie.dong@huawei.com Thu Mar 17 18:52:18 2011 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 231CE3A69E2 for ; Thu, 17 Mar 2011 18:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[AWL=-1.397, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 HRf+OSLJFFxs for ; Thu, 17 Mar 2011 18:52:17 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 2E0893A6A05 for ; Thu, 17 Mar 2011 18:52:17 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LI800M2OD7T69@szxga05-in.huawei.com> for l2vpn@ietf.org; Fri, 18 Mar 2011 09:52:41 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LI800HE5D7TCC@szxga05-in.huawei.com> for l2vpn@ietf.org; Fri, 18 Mar 2011 09:52:41 +0800 (CST) Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 18 Mar 2011 09:52:32 +0800 Received: from SZXEML508-MBX.china.huawei.com ([169.254.6.65]) by szxeml404-hub.china.huawei.com ([fe80::75b7:3db9:fedc:a56d%13]) with mapi id 14.01.0270.001; Fri, 18 Mar 2011 09:52:41 +0800 Date: Fri, 18 Mar 2011 01:52:40 +0000 From: Jie Dong Subject: New draft notification: draft-gu-l2vpn-vpls-analysis-00 X-Originating-IP: [10.110.98.31] To: "l2vpn@ietf.org" Message-id: <76CD132C3ADEF848BD84D028D243C927AB5189@szxeml508-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: New draft notification: draft-gu-l2vpn-vpls-analysis-00 Thread-index: AcvlDynCHcVF6sHgRLWo0U66b+WdDA== X-MS-Has-Attach: X-MS-TNEF-Correlator: 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, 18 Mar 2011 01:52:18 -0000 Hi all, A new Internet-Draft is available from the on-line Internet-Drafts directories. Title : Analysis of Virtual Private LAN Service (VPLS) Deployment Author(s) : R. Gu, J. Dong, et al Filename : draft-gu-l2vpn-vpls-analysis-00.txt This document analyses the deployment of typical VPLS network with existing solutions, and discusses the features of each solution. In addition, this document indicates that the advantages of the existing VPLS mechanisms may be integrated to achieve easier and more efficient VPLS provisioning. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-gu-l2vpn-vpls-analysis-00.txt Any comments are welcome. Best regards, Jie From giles.heron@gmail.com Fri Mar 18 10:39:37 2011 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 613A03A69B2 for ; Fri, 18 Mar 2011 10:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7AKYe9z+DVe for ; Fri, 18 Mar 2011 10:39:36 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id CAD9C3A69AC for ; Fri, 18 Mar 2011 10:39:34 -0700 (PDT) Received: by wwa36 with SMTP id 36so3470087wwa.13 for ; Fri, 18 Mar 2011 10:41:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:user-agent:date:subject:from:to:cc:message-id :thread-topic:thread-index:mime-version:content-type; bh=yHTo4l4x+V1HKtF9KsJfPRvHdV1JoeqGo0d8RB+uxwE=; b=jg3JwHbVskMSaHGEnYuj6cRxJcp/hz8VgM3Xf49spaCu+ssd6ktyDiGbND/sszeQze WukWlvOzqqYSIqe2vkSLCnPC8mzcF3hF4NMuyrAWrwpLY0rUJqnUfi7GVgIRATolDmIF y1Z/GV1tA7SVBwZpTkVa32z1rYpkk4/uTSVNI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:mime-version:content-type; b=lBL5+FVQM5vZYEELh/L383SG325apyzc4g6TprFGB1x9QiEOWAN1Rv/UExbJuGgL0H uxr8C+x/4cbtU1fi2lIuNWQ9VxyPgLV92Q2SScVGVGlAGV82OkbFEXIrzhBpyFneO1Rv g5cQSEoB4837mKHzgXsSBet4cTuhxC/wQvpfo= Received: by 10.216.245.11 with SMTP id n11mr2511733wer.108.1300470063874; Fri, 18 Mar 2011 10:41:03 -0700 (PDT) Received: from [10.61.86.242] (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id z50sm1668862weq.47.2011.03.18.10.41.00 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 18 Mar 2011 10:41:02 -0700 (PDT) User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Fri, 18 Mar 2011 17:41:08 +0000 Subject: Draft of new L2VPN WG Charter From: Giles Heron To: Message-ID: Thread-Topic: Draft of new L2VPN WG Charter Thread-Index: Acvlk6mvByfCCAJ7pEaQouOVm51qug== Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3383314876_13779263" 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, 18 Mar 2011 17:39:37 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3383314876_13779263 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit We plan to re-charter the L2VPN WG - primarily to bring E-VPN and E-Tree in-scope. Please find attached a draft charter for discussion both on this list and at IETF 80 in Prague. Nabil and Giles --B_3383314876_13779263 Content-type: video/x-fl; name="L2VPN_WG_charter_draft_v1.txt" Content-disposition: attachment; filename="L2VPN_WG_charter_draft_v1.txt" Content-transfer-encoding: x-uuencode begin 644 L2VPN_WG_charter_draft_v1.txt M5&AE($PR5E!.('=O65R+3(@#59I2!C;&]U M9"!C;VUP=71I;F<@65R+3(-5E!.('-E2!F86ET:&9U;"!T;RP@ M8G5T(&UA>2!N;W0*8F4@96YT:7)E;'D@:6YD:7-T:6YG=6ES:&%B;&4@9G)O M;2!T:&4@;F%T:79E('-E65R+3(@ M2!F;W(@82!V87)I971Y(&]F(&QI;FL@;&%Y97)S+`UI;F-L=61I;F<@ M1G)A;64@4F5L87DL($%432P@171H97)N970L(%!04"P@971C+BP@86-R;W-S M(&%N($U03%,@4%-.+@T-,RX@5FER='5A;"!065R+3(@2!,,E903CH-#6$I(%!O:6YT+71O+7!O:6YT($QA>65R M+3(@5E!.+B`@5&AI65R+3(@ M5E!.+B`@5&AI2!T87)G M971E9"!T;R!S=7!P;W)T(&QA2!T:&4@345&+"!W:&EC:"!P2!T:&4@97AI'1E;G-I;VYS(&]F(&5X:7-T:6YG('!R;W1O8V]L'1E;G-I;VYS('1O M('!S975D;W=I'1E;G-I;VYS('=I;&P@8F4@0IM96-H86YI2!R96QA=&5D M('1O('!S975D;W=I2!M96-H86YI2!M96-H86YI2!D969I;F4@;F%T:79E(&1A=&$@<&QA;F4@ M86YD+V]R(&-O;G1R;VP@<&QA;F4*:6YT97)W;W)K:6YG(&)E='=E96X@86X@ M3#)64$X@86YD(&%N(&%S65R+3(@2!R97%U:7)E M9"!F;W(@8V]N;F5C=&EV:71Y(&]F('1H92!64$Q3+"!64%=3+"!64$U3(&]R M($4M5E!.#2!S97)V:6-E+@T-,BX@4VEG;F%L:6YG(&]F(&EN9F]R;6%T:6]N M(')E;&%T960@=&\@=&AE(&1I2!A;F0@;65M8F5R2!T>7!E M(&]F#4PR5E!.+@T--2X@365C:&%N:7-MF%T M:6]N(&]F(&UU;'1I8V%S="!D871A('1R869F:6,@=VET:&EN#6%N($PR5E!. M+@T--BX@268@=')A;G-P;W)T(&1O97,@;F]T(&EN=F]L=F4@4%=S+"!M96-H M86YI2!T;R!C2!,,E903B!T;R!)15-'#4UA List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 18:19:58 -0000 OK - looks like the attachment didn't come through as intended. My apologies. Text inline: ---------------- The L2VPN working group is responsible for defining and specifying a limited number of solutions for supporting provider-provisioned Layer-2 Virtual Private Networks (L2VPNs). It will also address requirements driven by cloud computing services and data centers as they apply to Layer-2 VPN services. Layer-2 VPNs defined by L2VPN operate over pseudowires (PWs) as defined by the PWE3 WG or over MPLS PSN tunnels. A L2VPN emulates a "native" service over a PSN that is adequately faithful to, but may not be entirely indistinguishable from the native service itself. Further, following in the "edge-to-edge" nature of the service, the L2VPN WG will not define any mechanisms which exert control over the underlying PSN. When necessary it may, however, recommend or require the use of existing PSN QoS and path control mechanisms between the PEs which provide the L2VPN connectivity. Layer-2 VPNs comprise the following: 1. Virtual Private LAN Service (VPLS) -- A Layer-2 service that emulates a switched Ethernet (V)LAN across an MPLS Packet Switched Network (PSN). 2. Virtual Private Wire Service (VPWS) -- A Layer-2 service that provides point-to-point connectivity for a variety of link layers, including Frame Relay, ATM, Ethernet, PPP, etc., across an MPLS PSN. 3. Virtual Private Multicast Service (VPMS) -- A Layer-2 service that provides point-to-multipoint connectivity for a variety of link layers across an MPLS PSN. 4. IP-only L2VPN =AD An IP-only service over an MPLS PSN. The WG will address two specific types of IP-only L2VPN: a) Point-to-point Layer-2 VPN. This service is similar to VPWS, but also supports heterogenous Attachment Circuits at either end of a single point-to-point service. b) Multipoint-to-multipoint Layer-2 VPN. This service is similar to VPLS, but learns IP and MAC address bindings from ARPs and broadcast/multicast IP packets. 5. Ethernet VPN (E-VPN) - A Layer-2 technology that emulates an Ethernet (V)LAN across an MPLS PSN. E-VPN supports load-sharing across multiple connections from a Layer-2 site to an L2VPN service, and also supports control plane distribution of MAC addresses and IP to MAC address bindings in the VPN. E-VPN is primarily targeted to support large-scale L2VPNs with resiliency requirements not satisfied by other L2VPN solutions. 6. E-Tree =AD a Layer-2 technology defined by the MEF, which provides connectivity between one or more =B3root=B2 nodes and one or more =B3leaf=B2 nodes, with the restriction that leaves may only communicate with roots (and not with each other). L2VPNs will make use of existing IETF specified mechanisms unless there are technical reasons why the existing mechanisms are insufficient or unnecessary. The L2VPN WG is responsible for specification of the discovery and membership of PEs participating in a Layer-2 VPN as well as the membership of CE devices for a specific instance of an L2VPN. The L2VPN WG will provide extensions of existing protocols that will be discussed in protocol-specific WGs. In particular, the L2VPN WG may define extensions to pseudowire management mechanisms for VPLS. Those extensions will be reviewed by the PWE3 WG to ensure they are aligned with the overall design/architecture of PWE3. The L2VPN WG will not define new encapsulations, control, or resiliency mechanisms specifically related to pseudowires. Furthermore, when the L2VPN solution is based on PWs, the L2VPN WG will not define protocol inter-working between an L2VPN and native service Layer-2 OAM or resiliency mechanisms. The L2VPN WG may define how to operate native service-layer control, OAM or resiliency mechanisms on top of an L2VPN. In addition, it may define native data plane and/or control plane interworking between an L2VPN and an associated native Layer-2 service. The L2VPN WG scope includes the following: 1. Discovery of PEs participating in a Layer-2 VPN and the associated topology required for connectivity of the VPLS, VPWS, VPMS or E-VPN service. 2. Signaling of information related to the discovery and membership of PEs within a L2VPN. These procedures must use PWE3 control and management procedures, or define requirements for extensions of PWE3 protocols to suit the needs of an L2VPN, when the L2VPN operates over PWs. Once those requirements have been reviewed by the L2VPN WG, they should be provided to the PWE3 WG to derive solutions. 3. MIBs for Layer-2 VPN solutions. 4. Specification of requirements, framework and solutions that facilitate Operations Administration and Management (OAM) of any type of L2VPN. 5. Mechanisms to permit optimization of multicast data traffic within an L2VPN. 6. If transport does not involve PWs, mechanisms that support load-balancing/multipathing between PEs interconnecting a Layer-2 service using an L2VPN across the MPLS PSN. 7. requirements for the multi-homing of CEs to several VPLS or E-VPN PEs, inclusive of active/backup and active/active (load-sharing) configurations. Based on these requirements define VPLS or E-VPN control plane solutions for achieving fast convergence after failure of an active path in the PSN or on the AC side. 8. Enhancements to increase the scalability of the Control Plane and Data Plane of L2VPN PE nodes, and of core nodes that provide transport services for L2VPN. 9. Requirements and solutions for Auto-Discovery and Signaling of Inter-AS L2VPNs, in addition to Inter-AS solutions for multicast-optimized L2VPNs. 10. Requirements and solutions for supporting "E-Tree" services using VPLS.=20 11. Extensions to L2VPN protocols and RFCs necessary to create an MPLS Transport Profile (MPLS-TP). The work on the MPLS TP will be coordinated between four primary working groups (MPLS, PWE3, L2VPN and CCAMP) that are chartered to do MPLS TP work. Milestones: Done Submit an I-D describing MIB for VPLS Done Submit an I-D describing MIB for VPWS Done Submit an I-D on OAM requirements for VPLS Done Submit an I-D on OAM requirements for VPWS Done Submit L2 requirements to IESG for publication as Informational RFC Done Submit L2 framework to IESG for publication as Informational RF= C Done Identify VPLS and VPWS solutions for the WG Done Submit VPLS solution documents to IESG Done Submit VPWS solution documents to IESG Done Submit Auto-Discovery and Signaling for Intra-AS and Inter-AS VPLS and VPWS Layer-2 VPNs Jul 2011 Submit IP-only L2VPN solution documents to IESG Jul 2011 Submit OAM solutions for VPWS to IESG Jul 2011 Submit OAM solutions for VPLS to IESG Jul 2011 Submit signaling solution for multicast-optimized VPLS to IESG Jul 2011 Submit I-D on Virtual Private Multicast Service (VPMS) requirements to IESG Jul 2011 Submit MIB for VPLS to IESG Jul 2011 Submit MIB for VPWS to IESG Nov 2011 Submit scalability solutions for VPLS Data-Plane to IESG Nov 2011 Submit scalability solutions for VPLS Control-Plane to IESG Mar 2012 Submit MIB for IP-only L2VPN to IESG Mar 2012 Submit OAM solutions for IP-only L2VPN to IESG Mar 2012 Submit Auto-Discovery solution for VPMS to IESG Mar 2012 Submit VPLS service convergence improvement solutions to IESG Mar 2012 Submit VPLS multi-homing solutions to IESG Mar 2012 Submit E-Tree documents to IESG Mar 2012 Submit E-VPN requirements/framework to IESG Jul 2012 Submit E-VPN solution to IESG Nov 2012 Submit E-VPN MIB/OAM to IESG ----------------- On 18/03/2011 17:41, "Giles Heron" wrote: > We plan to re-charter the L2VPN WG - primarily to bring E-VPN and E-Tree > in-scope. >=20 > Please find attached a draft charter for discussion both on this list and= at > IETF 80 in Prague. >=20 > Nabil and Giles >=20 >=20 From giles.heron@gmail.com Fri Mar 18 13:01:31 2011 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 5E1B93A6996 for ; Fri, 18 Mar 2011 13:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nZHZdzwPTPe for ; Fri, 18 Mar 2011 13:01:30 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 9F1053A695B for ; Fri, 18 Mar 2011 13:01:30 -0700 (PDT) Received: by pwi5 with SMTP id 5so750317pwi.31 for ; Fri, 18 Mar 2011 13:03:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:user-agent:date:subject:from:to:cc:message-id :thread-topic:thread-index:mime-version:content-type :content-transfer-encoding; bh=cFXiXDvaFTAY+8KfTqsf8mEf7C7u2CQQgeIGp3q1yGw=; b=tOgDmgSm1Ydnqt8z4F9Ke7PDNjbAWhU6tTK7VEt+YsZIWzkTvAZBmLWCNvuD6kJaHH 0uI25AJkDWLFI+iulfSH7hMTBE+Ef+2qsIdS1FuZ0V71lo1RpPY0ykvRyntlsULUEthS OIxE2qg0/oMb6IOr76KKgKP3mNexsGvZp0suw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:mime-version:content-type:content-transfer-encoding; b=HKxv9/I3B++xUyHucqd5hbYhYmG07MZ8ljEP/cnunrL82bVTmmwbZ+ONITF7JKqIp3 fZw7chJ3eaMv6jTDB8p7JIkXIYkMQgKet9YOpD7Jdviva9gOXYOrDEOTVou5YmBfTj7M 49wwXWjAfJ+dP6h3oW4Hwzi0oEY+L4p69DB7E= Received: by 10.142.144.5 with SMTP id r5mr330222wfd.384.1300478580386; Fri, 18 Mar 2011 13:03:00 -0700 (PDT) Received: from [10.21.115.6] (128-107-239-233.cisco.com [128.107.239.233]) by mx.google.com with ESMTPS id s41sm3295541wfc.3.2011.03.18.13.02.52 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 18 Mar 2011 13:02:58 -0700 (PDT) User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Fri, 18 Mar 2011 20:03:01 +0000 Subject: Draft L2VPN Agenda for IETF 80 (Prague) From: Giles Heron To: Message-ID: Thread-Topic: Draft L2VPN Agenda for IETF 80 (Prague) Thread-Index: Acvlp3vUywZSc6TSw0qO6ZovDGHIVA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 20:01:31 -0000 The draft agenda is now posted at: http://www.ietf.org/proceedings/80/agenda/l2vpn.txt Could those who made slot requests please confirm that their requests have made it into the agenda. And could presenters please send their slides to the chairs by 6pm Prague time on Sunday 27th March so we can upload them. Thank you! Nabil & Giles From josh.rogers@twcable.com Fri Mar 18 13:25:01 2011 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 8AB613A6A19 for ; Fri, 18 Mar 2011 13:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 8kPZl+CwG7Sn for ; Fri, 18 Mar 2011 13:25:00 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by core3.amsl.com (Postfix) with ESMTP id 6BD863A69E0 for ; Fri, 18 Mar 2011 13:25:00 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.63,207,1299474000"; d="scan'208";a="191666670" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 18 Mar 2011 16:26:59 -0400 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.37]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Fri, 18 Mar 2011 16:26:28 -0400 From: "Rogers, Josh" To: Giles Heron , "l2vpn@ietf.org" Date: Fri, 18 Mar 2011 16:26:27 -0400 Subject: Re: Draft of new L2VPN WG Charter Thread-Topic: Draft of new L2VPN WG Charter Thread-Index: Acvlk6mvByfCCAJ7pEaQouOVm51qugAFxiIC Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-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, 18 Mar 2011 20:25:01 -0000 I emphatically agree with this proposal. Giles Heron wrote: We plan to re-charter the L2VPN WG - primarily to bring E-VPN and E-Tree in-scope. Please find attached a draft charter for discussion both on this list and a= t IETF 80 in Prague. Nabil and Giles This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From josh.rogers@twcable.com Fri Mar 18 19:07:12 2011 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 B20623A6A2D for ; Fri, 18 Mar 2011 19:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 WBfdnTL1HVQs for ; Fri, 18 Mar 2011 19:07:11 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by core3.amsl.com (Postfix) with ESMTP id C590D3A6975 for ; Fri, 18 Mar 2011 19:07:11 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.63,208,1299474000"; d="scan'208";a="203524379" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 18 Mar 2011 22:29:31 -0400 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.37]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Fri, 18 Mar 2011 22:08:41 -0400 From: "Rogers, Josh" To: Jie Dong Date: Fri, 18 Mar 2011 22:08:40 -0400 Subject: Re: New draft notification: draft-gu-l2vpn-vpls-analysis-00 Thread-Topic: New draft notification: draft-gu-l2vpn-vpls-analysis-00 Thread-Index: Acvl2pD/++OacPPWSuWPneY2RJZKrQ== Message-ID: <763D4225-5EC2-4845-8EB9-E44D9C7F6D3A@twcable.com> References: <76CD132C3ADEF848BD84D028D243C927AB5189@szxeml508-mbx.china.huawei.com> In-Reply-To: <76CD132C3ADEF848BD84D028D243C927AB5189@szxeml508-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Mar 2011 02:07:12 -0000 Jie (and other authors), Thanks much for your work on this, I wish this was available back when I fi= rst started evaluating deployment options for VPLS. While my overall impre= ssion is that this is a rather complete and well written draft on the subje= ct, I'd like to submit a few comments: + Mention of 'maintaining VE-IDs' seems to sound like its difficult or admi= nistratively costly, but managing VPLS-ID (for LDP) is not mentioned on the= comparison table, or mentioned as a negative anywhere. Was this intention= al because VE-ID must be globally unique, where VPLS-ID must only be unique= among the PE's that are in the instance? I'd expect that operators would = maintain a globally unique list, regardless of whether they use LDP-VPLS or= BGP-VPLS, just to avoid accidental overlaps, or problems with adding addit= ional sites to an instance. + Comparison of 'full mesh' targeted LDP sessions and BGP may look similar = due to the N*(N-1) sessions of each, however I don't think that is complete= ly accurate. If I understand most vendors implementation, you'd need N*(N-= 1) PER INSTANCE, where BGP only requires the a full mesh of sessions for th= e PE's involved. For example, using Figure 1 as an example, there would be= 6 configured BGP peers (two per PE), but would be 12 configured LDP peers = (2 per VPLS instance per PE). + At the end of section 3, it seems that a proposed improvement to BGP-VPLS= (adding on-demand label allocation, MAC withdrawal, and status notificatio= n) is suggested. While I think this is an excellent notion, it should prob= ably be included in a separate draft proposing those enhancements (and mayb= e also include other BGP based messages, such as VPMS signaling) If I've misunderstood anything here, I'd really appreciate a detailed expla= nation that would set me straight. Thanks much, Josh On Mar 17, 2011, at 8:52 PM, Jie Dong wrote: > Hi all, > > A new Internet-Draft is available from the on-line Internet-Drafts direct= ories. > > Title : Analysis of Virtual Private LAN Service (VPLS) Deploym= ent > Author(s) : R. Gu, J. Dong, et al > Filename : draft-gu-l2vpn-vpls-analysis-00.txt > > This document analyses the deployment of typical VPLS network with > existing solutions, and discusses the features of each solution. In > addition, this document indicates that the advantages of the > existing VPLS mechanisms may be integrated to achieve easier and > more efficient VPLS provisioning. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-gu-l2vpn-vpls-analysis-00.txt > > Any comments are welcome. > > Best regards, > Jie This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From ju1738@att.com Sun Mar 20 17:02:32 2011 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 1941C28C107 for ; Sun, 20 Mar 2011 17:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.669 X-Spam-Level: X-Spam-Status: No, score=-105.669 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 pRS6kjYojqC6 for ; Sun, 20 Mar 2011 17:02:31 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 4678F28C100 for ; Sun, 20 Mar 2011 17:02:31 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ju1738@att.com X-Msg-Ref: server-14.tower-120.messagelabs.com!1300665842!8793762!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 32327 invoked from network); 21 Mar 2011 00:04:03 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-14.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Mar 2011 00:04:03 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p2L034uC005126; Sun, 20 Mar 2011 20:03:04 -0400 Received: from misout7msgusr7e.ugd.att.com (misout7msgusr7e.ugd.att.com [144.155.43.107]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p2L032Uc005122; Sun, 20 Mar 2011 20:03:03 -0400 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: Draft of new L2VPN WG Charter Date: Sun, 20 Mar 2011 20:04:00 -0400 Message-ID: <1477DEAE19DD884CB004730D0FD77FD7041A91F6@misout7msgusr7e.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft of new L2VPN WG Charter Thread-Index: Acvlk6mvByfCCAJ7pEaQouOVm51qugAFxiICAGwsYrA= References: From: "UTTARO, JAMES (ATTSI)" To: "Rogers, Josh" , "Giles Heron" , 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: Mon, 21 Mar 2011 00:02:32 -0000 Makes Sense.. Jim Uttaro -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Rogers, Josh Sent: Friday, March 18, 2011 4:26 PM To: Giles Heron; l2vpn@ietf.org Subject: Re: Draft of new L2VPN WG Charter I emphatically agree with this proposal. Giles Heron wrote: We plan to re-charter the L2VPN WG - primarily to bring E-VPN and E-Tree in-scope. Please find attached a draft charter for discussion both on this list and at IETF 80 in Prague. Nabil and Giles This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From jie.dong@huawei.com Mon Mar 21 00:37:29 2011 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 80A7F3A67DF for ; Mon, 21 Mar 2011 00:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.612 X-Spam-Level: X-Spam-Status: No, score=-1.612 tagged_above=-999 required=5 tests=[AWL=-1.117, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 kW+Ck3R6HvuS for ; Mon, 21 Mar 2011 00:37:28 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 32C0A3A67D1 for ; Mon, 21 Mar 2011 00:37:28 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIE006FTD8NW7@szxga05-in.huawei.com> for l2vpn@ietf.org; Mon, 21 Mar 2011 15:38:47 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIE0040ED8748@szxga05-in.huawei.com> for l2vpn@ietf.org; Mon, 21 Mar 2011 15:38:47 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 21 Mar 2011 15:38:33 +0800 Received: from SZXEML508-MBS.china.huawei.com ([169.254.8.98]) by SZXEML401-HUB.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Mon, 21 Mar 2011 15:38:42 +0800 Date: Mon, 21 Mar 2011 07:38:42 +0000 From: Jie Dong Subject: RE: New draft notification: draft-gu-l2vpn-vpls-analysis-00 In-reply-to: <763D4225-5EC2-4845-8EB9-E44D9C7F6D3A@twcable.com> X-Originating-IP: [10.110.98.31] To: "Rogers, Josh" Message-id: <76CD132C3ADEF848BD84D028D243C927ABC075@szxeml508-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: New draft notification: draft-gu-l2vpn-vpls-analysis-00 Thread-index: AcvlDynCHcVF6sHgRLWo0U66b+WdDAAiFiYAAHYrMdA= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <76CD132C3ADEF848BD84D028D243C927AB5189@szxeml508-mbx.china.huawei.com> <763D4225-5EC2-4845-8EB9-E44D9C7F6D3A@twcable.com> 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: Mon, 21 Mar 2011 07:37:29 -0000 Hi Rogers, Thanks a lot for your comments, and hope this document still helps in evaluating VPLS options:) Please see some replies inline. > + Mention of 'maintaining VE-IDs' seems to sound like its difficult or > administratively costly, but managing VPLS-ID (for LDP) is not mentioned on > the comparison table, or mentioned as a negative anywhere. Was this > intentional because VE-ID must be globally unique, where VPLS-ID must only > be unique among the PE's that are in the instance? I'd expect that > operators would maintain a globally unique list, regardless of whether they > use LDP-VPLS or BGP-VPLS, just to avoid accidental overlaps, or problems > with adding additional sites to an instance. Yes this version did not discuss lot about VPLS-ID (LDP) management, we could add some description in next revision to make the comparison clearer. In section 2.1 , the third paragraph briefly describes the assignment of VPLS-ID: "When using LDP based mechanism to deploy a VPLS network, one unique VPLS Identifier needs to be assigned for each VPLS instance." VPLS ID needs to be globally unique among different VPLS instances, but for each instance all the participating PEs are using the same VPLS ID. Thus operators only need to maintain a global list of VPLS IDs and do not need to care about number of PEs in each instance. The management is at the granularity of VPLS instance. As for VE-IDs, in each VPLS instance it MUST be unique for every participating PE, hence the management is at the granularity of PE. Operators need to maintain different lists of VE-IDs for different VPLS instances. And the list needs be updated when adding additional sites to an instance. >From this perspective, this draft takes "management of VE-ID" as a disadvantage compared with "management of VPLS ID". > + Comparison of 'full mesh' targeted LDP sessions and BGP may look similar > due to the N*(N-1) sessions of each, however I don't think that is completely > accurate. If I understand most vendors implementation, you'd need N*(N-1) > PER INSTANCE, where BGP only requires the a full mesh of sessions for the > PE's involved. For example, using Figure 1 as an example, there would be 6 > configured BGP peers (two per PE), but would be 12 configured LDP peers (2 > per VPLS instance per PE). The difference in configurations between BGP and LDP in your example may due to BGP membership auto-discovery, thus in LDP (without BGP AD) operators need to configure remote participating PEs in each instance, while using BGP operators only need to configure the BGP peers and the VPLS members are auto-discovered. Since signaling of different VPLS instances in LDP is identified using different PW FEC elements, hence multiple VPLS instances may share the same underlying T-LDP session. While signaling overhead in the full-mesh scenario may be similar, BGP signaling could have better scalability with use of Route Reflector. > + At the end of section 3, it seems that a proposed improvement to > BGP-VPLS (adding on-demand label allocation, MAC withdrawal, and status > notification) is suggested. While I think this is an excellent notion, it should > probably be included in a separate draft proposing those enhancements (and > maybe also include other BGP based messages, such as VPMS signaling) Agreed. This analysis draft is mainly to compare existing VPLS deployment options. After such comparison, it may be straight to ask whether we could obtain all the advantages and avoid most the disadvantages, hence section 3 gives some general description of a possible solution. Such solution (including protocol extensions) would be specified in detail in a separate draft. > If I've misunderstood anything here, I'd really appreciate a detailed > explanation that would set me straight. Thanks for these comments, and hope the replies could be helpful. Further comments are more than appreciated. Many thanks, Jie > > On Mar 17, 2011, at 8:52 PM, Jie Dong wrote: > > > Hi all, > > > > A new Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > Title : Analysis of Virtual Private LAN Service (VPLS) > Deployment > > Author(s) : R. Gu, J. Dong, et al > > Filename : draft-gu-l2vpn-vpls-analysis-00.txt > > > > This document analyses the deployment of typical VPLS network with > > existing solutions, and discusses the features of each solution. In > > addition, this document indicates that the advantages of the > > existing VPLS mechanisms may be integrated to achieve easier and > > more efficient VPLS provisioning. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-gu-l2vpn-vpls-analysis-00.txt > > > > Any comments are welcome. > > > > Best regards, > > Jie > > > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright belonging to Time Warner Cable. This E-mail is intended solely for > the use of the individual or entity to which it is addressed. If you are not the > intended recipient of this E-mail, you are hereby notified that any > dissemination, distribution, copying, or action taken in relation to the > contents of and attachments to this E-mail is strictly prohibited and may be > unlawful. If you have received this E-mail in error, please notify the sender > immediately and permanently delete the original and any copy of this E-mail > and any printout. From lufang@cisco.com Wed Mar 23 18:14:26 2011 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 ED9B43A679F for ; Wed, 23 Mar 2011 18:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 HaaTLjQKI5Hh for ; Wed, 23 Mar 2011 18:14:25 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id C107B3A63CA for ; Wed, 23 Mar 2011 18:14:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=8350; q=dns/txt; s=iport; t=1300929360; x=1302138960; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=xZt2f8ilGXw8Yj9RdvkoYNLSuOqzjVd+RfsBz/2D1LM=; b=Q9t6qi2GImCT8Tts4a40oHRcPuLi+5yu6udQ5Wh6Iw8BA4VeZvT5aOwP hOsgTIfYhmgFFmMMz1B7F6IaI+NQfCHvqSh8EhSHpy6x3UaR2YCeN8sz9 ckUJ1ZXW5K2YneT8Vz5OjPAx48p3mmDgACJKOvTGV0/mGHO0jKJ3lazoA o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUHAGo4ik2tJV2c/2dsb2JhbACCX5VrjHh3pjecNYVpBIF4gz+LEA X-IronPort-AV: E=Sophos;i="4.63,234,1299456000"; d="scan'208,217";a="280316650" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by sj-iport-4.cisco.com with ESMTP; 24 Mar 2011 01:15:59 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p2O1FxWx007794; Thu, 24 Mar 2011 01:15:59 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 Mar 2011 20:15:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBE9C1.08E28712" Subject: MPLS 2011 International Conference - Call for Papers Date: Wed, 23 Mar 2011 20:15:57 -0500 Message-ID: <238542D917511A45B6B8AA806E875E25050C3370@XMB-RCD-201.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MPLS 2011 International Conference - Call for Papers Thread-Index: AcvR9YWrVnCYJkRc7ESrJrvX/vcvBwOv7BUlAkJaUnA= References: From: "Luyuan Fang (lufang)" To: X-OriginalArrivalTime: 24 Mar 2011 01:15:59.0771 (UTC) FILETIME=[08EA16B0:01CBE9C1] Cc: tpc-mpls2010-L@isocore.com 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, 24 Mar 2011 01:14:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE9C1.08E28712 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear colleagues, =20 The MPLS 2011 International Conference, the 14th Annual International Conference on MPLS and Related Technologies, will be held October 16 - 19, 2011, in Washington, DC. The Technical Program Committee is soliciting abstracts summarizing a proposed presentation representing original/unpublished work covering cutting-edge topics. =20 Presentations covering new technologies and operational experience are solicited from network equipment vendors, service/transport providers, government agencies, the research community, and enterprise users. =20 The deadline for submission of presentation proposals is April 29, 2011. If you want further information on MPLS 2010 or want to submit a presentation abstract, please see the following URL: =20 http://www.isocore.com/mpls2011/call_for_papers/cfp.htm =20 Many of these topics have been of interest to members of this community in the past, and many people active on this list have been presenters at past events. =20 Regards,=20 Luyuan =20 ------_=_NextPart_001_01CBE9C1.08E28712 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [l2vpn] WG last call results for = draft-ietf-l2vpn-vpls-mcast-08.txt

Dear colleagues,

 

The MPLS 2011 International Conference, the 14th = Annual International Conference on MPLS and Related Technologies, will be held = October 16 - 19, 2011, in Washington, DC. The Technical Program Committee is = soliciting abstracts summarizing a proposed presentation representing = original/unpublished work covering cutting-edge topics.

 

Presentations covering new technologies and = operational experience are solicited from network equipment vendors, = service/transport providers, government agencies, the research community, and enterprise = users.

 

The deadline for submission of presentation = proposals is April 29, 2011.

If you want further information on MPLS 2010 or = want to submit a presentation abstract, please see the following = URL:

 

http://w= ww.isocore.com/mpls2011/call_for_papers/cfp.htm

 

Many of these topics have been of interest to = members of this community in the past, and many people active on this list have = been presenters at past events.

 

Regards,

Luyuan

 

------_=_NextPart_001_01CBE9C1.08E28712-- From nabil.n.bitar@verizon.com Mon Mar 28 22:06:54 2011 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 DE1E23A6A8A for ; Mon, 28 Mar 2011 22:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.475 X-Spam-Level: X-Spam-Status: No, score=-3.475 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 rGGqdgpt3ahv for ; Mon, 28 Mar 2011 22:06:53 -0700 (PDT) Received: from sacmail2.verizon.com (sacmail2.verizon.com [192.76.84.41]) by core3.amsl.com (Postfix) with ESMTP id 85D703A6802 for ; Mon, 28 Mar 2011 22:06:53 -0700 (PDT) Received: from fldsmtpi02.verizon.com (fldsmtpi02.verizon.com [166.68.71.144]) by sacmail2.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p2T58Pk5023684 for ; Tue, 29 Mar 2011 01:08:27 -0400 (EDT) From: "Bitar, Nabil N" X-IronPort-AV: E=Sophos;i="4.63,259,1299456000"; d="scan'208,217";a="20157437" Received: from fldp1lumxc7hb01.verizon.com (HELO FLDP1LUMXC7HB01.us.one.verizon.com) ([166.68.45.78]) by fldsmtpi02.verizon.com with ESMTP; 29 Mar 2011 05:08:07 +0000 Received: from fldp1lumxc7v63.us.one.verizon.com ([fe80::303e:41f6:bcf4:d607]) by FLDP1LUMXC7HB01.us.one.verizon.com ([2002:a644:2d4e::a644:2d4e]) with mapi; Tue, 29 Mar 2011 01:08:07 -0400 To: "l2vpn@ietf.org" Date: Tue, 29 Mar 2011 01:08:00 -0400 Subject: Re: [l2vpn] WG Last Call for updates in draft-ietf-l2vpn-arp-mediation-16.txt Thread-Topic: [l2vpn] WG Last Call for updates in draft-ietf-l2vpn-arp-mediation-16.txt Thread-Index: Acvgyf0gzEwRXQeJzEyL8hqC3ZD1OANBUj2n Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C9B6E17013FBBnabilnbitarverizoncom_" MIME-Version: 1.0 Cc: "Giles Heron \(giheron\)" 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, 29 Mar 2011 05:06:55 -0000 --_000_C9B6E17013FBBnabilnbitarverizoncom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, The WG last call for draft-ietf-l2vpn-arp-mediation-16.txt updates was clos= ed on Sunday March 20, 2011. No comments were received on the mailing list.= This will be interpreted as implicit support to proceed. Thanks, Nabil & Giles On 3/12/11 10:27 AM, "Nabil Bitar" wrote: Following the working group last call on draft-ietf-l2vpn-arp-mediation-15.= txt, there were some updates made to the draft that have technical implicat= ion in addition to minor editorial changes. This WG LC is focusing on section 5.2 and section 6 of draft-ietf-l2vpn-arp= -mediation-16.txt where the technical changes were made, and it is specific= ally to call the working group attention to these changes. The draft can be= fount at http://tools.ietf.org/html/draft-ietf-l2vpn-arp-mediation-16. This last call will end on Sunday March 20, 2011. Please, send your comment= s to the L2VPN WG email list. Thanks, Nabil & Giles --------------------------------------------- Nabil Bitar, PhD Principal Member of Technical Staff Packet Network Technology Verizon Corporate Network and Technology 60 Sylvan Road Waltham, MA 02451 Office Phone: (781) 466-2161 --_000_C9B6E17013FBBnabilnbitarverizoncom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [l2vpn] WG Last Call for updates in draft-ietf-l2vpn-arp-mediati= on-16.txt Hi,
The WG last call for draft-ietf-l2vpn-arp-mediation-16.txt updates was clos= ed on Sunday March 20, 2011. No comments were received on the mailing list.= This will be interpreted as implicit support to proceed.

Thanks,
Nabil & Giles

On 3/12/11 10:27 AM, "Nabil Bitar" <nabil.n.bitar@verizon.com> wrote:

Following the working group last call on dr= aft-ietf-l2vpn-arp-mediation-15.txt, there were some updates made to the dr= aft that have technical implication in addition to minor editorial changes.=

This WG LC is focusing on section 5.2 and section 6 of draft-ietf-l2vpn-arp= -mediation-16.txt where the technical changes were made, and it is specific= ally to call the working group attention to these changes. The draft can be= fount at http://tools.ietf.org/html/draft-ietf-l2vpn-arp-mediation-16.
This last call will end on Sunday March 20, 2011. Please, send your comment= s to the L2VPN WG email list.

Thanks,
Nabil & Giles
List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 08:06:32 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3384320920_5022544 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit All in L2VPN WG. Please note that the RTGAREA Open Meeting at 1pm has moved to Congress Hall II, so more people can fit in the meeting... Giles ------ Forwarded Message From: Wanda Lo Date: Wed, 30 Mar 2011 00:00:50 -0700 To: <80all@ietf.org> Subject: [80all] Wednesday 3-30-2011 Agenda Change Hi Everyone, There's a room change in today's afternoon session I (13:00-15:00). RTGAREA has moved to Congress Hall II. CLUE has moved to Congress Hall I. Please note it in on your pocket agenda to reflect the change. Of course, the agenda on the IETF website (https://datatracker.ietf.org/meeting/80/agenda.html) always has the most up-to-date information. Thanks, Wanda =========================== Wanda Lo Internet Engineering Task Force (IETF) 48377 Fremont Blvd., Ste. 117 Fremont, California 94538 / USA +1-510-492-4082 +1-510-492-4001 (fax) www.ietf.org -- Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com _______________________________________________ 80all mailing list 80all@ietf.org https://www.ietf.org/mailman/listinfo/80all ------ End of Forwarded Message --B_3384320920_5022544 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable FW: [80all] Wednesday 3-30-2011 Agenda Change All in L2VPN WG.  Please note that the RTGAREA Open Meeting at 1pm ha= s moved to Congress Hall II, so more people can fit in the meeting...

Giles

------ Forwarded Message
From: Wanda Lo <wlo@amsl.com>
Date: Wed, 30 Mar 2011 00:00:50 -0700
To: <80all@ietf.org>
Subject: [80all] Wednesday 3-30-2011 Agenda Change

Hi Everyone,

There's a room change in today's afternoon session I (13:00-15:00).

RTGAREA has moved to Congress Hall II.

CLUE has moved to Congress Hall I.

Please note it in on your pocket agenda to reflect the change.  Of cou= rse, the agenda on the IETF website (https://datatracker.ietf.org/meeting/80/agenda.html) always has the most up-to-date information.


Thanks,
Wanda





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Wanda Lo
Internet Engineering Task Force (IETF)
48377 Fremont Blvd., Ste. 117
Fremont, California 94538 / USA
+1-510-492-4082
+1-510-492-4001 (fax)
www.ietf.org <ht= tp://www.ietf.org/>

--
Managed by= Association Management Solutions (AMS)
Forum Management, Meeting and Event Planning
www.amsl.com <http:/= /www.amsl.com/>





___________= ____________________________________
80all mailing list
80all@ietf.org
https://www.ietf.org/= mailman/listinfo/80all

------ End of Forwarded Message
 --B_3384320920_5022544-- From jiangyuanlong@huawei.com Wed Mar 30 02:58:51 2011 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 7FADA3A68CE for ; Wed, 30 Mar 2011 02:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.859 X-Spam-Level: X-Spam-Status: No, score=-4.859 tagged_above=-999 required=5 tests=[AWL=-0.365, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 gINVHodsjrIx for ; Wed, 30 Mar 2011 02:58:50 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 9188528C0D6 for ; Wed, 30 Mar 2011 02:58:50 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIV00BG67SI86@szxga03-in.huawei.com> for l2vpn@ietf.org; Wed, 30 Mar 2011 18:00:18 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIV00MYV7SIAZ@szxga03-in.huawei.com> for l2vpn@ietf.org; Wed, 30 Mar 2011 18:00:18 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 30 Mar 2011 18:00:13 +0800 Received: from SZXEML514-MBS.china.huawei.com ([169.254.6.193]) by SZXEML401-HUB.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Wed, 30 Mar 2011 18:00:17 +0800 Date: Wed, 30 Mar 2011 10:00:17 +0000 From: Jiangyuanlong Subject: S-VLAN access in E-Tree X-Originating-IP: [172.24.2.40] To: "rafir@orckit.com" Message-id: <3B0A1BED22CAD649A1B3E97BE5DDD68B0317B271@SZXEML514-MBS.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_AP1WDP5hkwx+GSWLpgc/JQ)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: S-VLAN access in E-Tree Thread-index: AcvuwSPJzDbXjemeSb+thu3WLafxvA== X-MS-Has-Attach: X-MS-TNEF-Correlator: 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: Wed, 30 Mar 2011 09:58:51 -0000 --Boundary_(ID_AP1WDP5hkwx+GSWLpgc/JQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Rafi and all, Yesterday we discussed the S-VLAN access of E-Tree during the WG meeting, in addition to S-VLAN mapping or B-VLAN method, a third option is also possible if it is a carrier over carrier network use case, that is, the E-Tree traffic from the 1st carrier can be transparently transported over the 2nd carrier's VPLS network, just as in the traditional VPLS. This seems more practical as the E-Tree topology is usually only known to the 1st carrier while unavailable to the 2nd carrier, furthermore, it requires no change on the 2nd carrier network. Best regards, Yuanlong --Boundary_(ID_AP1WDP5hkwx+GSWLpgc/JQ) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Rafi and all,

Yesterday we discussed the S-VLAN access of E-Tree during the WG meeting, in addition to S-VLAN mapping or B-VLAN method, a third option is also possible if it is a carrier over carrier network use case, that is, the E-Tree traffic from the 1st carrier can be transparently transported over the 2nd carrier's VPLS network, just as in the traditional VPLS. This seems more practical as the E-Tree topology is usually only known to the 1st carrier while unavailable to the 2nd carrier, furthermore, it requires no change on the 2nd carrier network.

Best regards,
Yuanlong

--Boundary_(ID_AP1WDP5hkwx+GSWLpgc/JQ)-- From josh.rogers@twcable.com Wed Mar 30 05:50:11 2011 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 1556328C108 for ; Wed, 30 Mar 2011 05:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.413 X-Spam-Level: X-Spam-Status: No, score=0.413 tagged_above=-999 required=5 tests=[AWL=-0.877, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, MIME_BASE64_TEXT=1.753] 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 dEQlAVN34UIZ for ; Wed, 30 Mar 2011 05:50:08 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by core3.amsl.com (Postfix) with ESMTP id 090683A6A1C for ; Wed, 30 Mar 2011 05:50:07 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.63,268,1299474000"; d="scan'208";a="195666955" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 30 Mar 2011 08:52:21 -0400 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.37]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Wed, 30 Mar 2011 08:51:46 -0400 From: "Rogers, Josh" To: Jiangyuanlong , "rafir@orckit.com" Date: Wed, 30 Mar 2011 08:51:46 -0400 Subject: Re: S-VLAN access in E-Tree Thread-Topic: S-VLAN access in E-Tree Thread-Index: AcvuwSPJzDbXjemeSb+thu3WLafxvAAGBaLP Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 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: Wed, 30 Mar 2011 12:50:11 -0000 SXQgc291bmRzIGxpa2UgdGhpcyBtYXkgYmUgYSBjb250aW51YXRpb24gb2YgYSBjb252ZXJzYXRp b24gaW4gcGVyc29uLiBCZWZvcmUgY29udGludWluZywgSSdkIGxpa2UgdG8ga25vdyBpZiB0aGVy ZSBpcyBkb2N1bWVudCB0aGF0IGRlZmluZXMgdmxhbiB0YWcgdHlwZSBuYW1lcyAoUy1WTEFOLCBD LVZMQU4sIGV0YykNCg0KT24gYSByZWd1bGFyIGJhc2lzLCBJIHdvcmsgd2l0aCBvdGhlciBvcGVy YXRvcnMsIGFuZCB0aGVyZSBzZWVtcyB0byBiZSBhIGdyZWF0IGRlYWwgb2YgY29uZnVzaW9uIG9u IGNvbW1vbiB0ZXJtaW5vbG9neS4NCg0KDQoNCkppYW5neXVhbmxvbmcgPGppYW5neXVhbmxvbmdA aHVhd2VpLmNvbT4gd3JvdGU6DQoNCg0KDQpSYWZpIGFuZCBhbGwsDQoNClllc3RlcmRheSB3ZSBk aXNjdXNzZWQgdGhlIFMtVkxBTiBhY2Nlc3Mgb2YgRS1UcmVlIGR1cmluZyB0aGUgV0cgbWVldGlu ZywgaW4gYWRkaXRpb24gdG8gUy1WTEFOIG1hcHBpbmcgb3IgQi1WTEFOIG1ldGhvZCwgYSB0aGly ZCBvcHRpb24gaXMgYWxzbyBwb3NzaWJsZSBpZiBpdCBpcyBhIGNhcnJpZXIgb3ZlciBjYXJyaWVy IG5ldHdvcmsgdXNlIGNhc2UsIHRoYXQgaXMsIHRoZSBFLVRyZWUgdHJhZmZpYyBmcm9tIHRoZSAx c3QgY2FycmllciBjYW4gYmUgdHJhbnNwYXJlbnRseSB0cmFuc3BvcnRlZCBvdmVyIHRoZSAybmQg Y2FycmllcidzIFZQTFMgbmV0d29yaywganVzdCBhcyBpbiB0aGUgdHJhZGl0aW9uYWwgVlBMUy4g VGhpcyBzZWVtcyBtb3JlIHByYWN0aWNhbCBhcyB0aGUgRS1UcmVlIHRvcG9sb2d5IGlzIHVzdWFs bHkgb25seSBrbm93biB0byB0aGUgMXN0IGNhcnJpZXIgd2hpbGUgdW5hdmFpbGFibGUgdG8gdGhl IDJuZCBjYXJyaWVyLCBmdXJ0aGVybW9yZSwgaXQgcmVxdWlyZXMgbm8gY2hhbmdlIG9uIHRoZSAy bmQgY2FycmllciBuZXR3b3JrLg0KDQpCZXN0IHJlZ2FyZHMsDQpZdWFubG9uZw0KDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBh dHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBpbmZv cm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRv IGNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlz IGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkg dG8gd2hpY2ggaXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVj aXBpZW50IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBk aXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiBy ZWxhdGlvbiB0byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWls IGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBp bW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55IGNv cHkgb2YgdGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC4NCg== From jiangyuanlong@huawei.com Wed Mar 30 06:19:16 2011 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 E51473A687F for ; Wed, 30 Mar 2011 06:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.636 X-Spam-Level: X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[AWL=-2.344, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 jN5hsVS93gAo for ; Wed, 30 Mar 2011 06:19:13 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 0E79528C17F for ; Wed, 30 Mar 2011 06:18:54 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIV00BEZH1Y86@szxga03-in.huawei.com> for l2vpn@ietf.org; Wed, 30 Mar 2011 21:20:22 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIV00CHWH1YI8@szxga03-in.huawei.com> for l2vpn@ietf.org; Wed, 30 Mar 2011 21:20:22 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 30 Mar 2011 21:20:16 +0800 Received: from SZXEML514-MBS.china.huawei.com ([169.254.6.193]) by SZXEML401-HUB.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Wed, 30 Mar 2011 21:20:21 +0800 Date: Wed, 30 Mar 2011 13:20:21 +0000 From: Jiangyuanlong Subject: Re: S-VLAN access in E-Tree In-reply-to: X-Originating-IP: [172.24.2.40] To: "Rogers, Josh" , "rafir@orckit.com" Message-id: <3B0A1BED22CAD649A1B3E97BE5DDD68B0317C325@SZXEML514-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: S-VLAN access in E-Tree Thread-index: AcvuwSPJzDbXjemeSb+thu3WLafxvAAGBaLPAAClGVA= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: 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: Wed, 30 Mar 2011 13:19:17 -0000 Sm9zaCwKCkFjdHVhbGx5IGl0IHdhcyBhIGNvbnZlcnNhdGlvbiBoYXBwZW5lZCBpbiBwdWJsaWMg ZHVyaW5nIHRoZSBwcmVzZW50YXRpb24gb2YgdGhlIHNsaWRlLCB0aG91Z2ggSSBkaWQgZGlzY3Vz cyBtb3JlIGRldGFpbHMgd2l0aCBSYWZpIHdpdGggcmVnYXJkIHRvIHRoZSBzb2x1dGlvbiBhZnRl ciB0aGUgbWVldGluZyAodGhhbmsgUmFmaSBmb3IgdGhlIHRpbWU6KS4KSW4gdGVybXMgb2YgdGhl IFZMQU4gdGFnLCBTLVZMQU4gYW5kIEMtVkxBTiBhcmUgZGVmaW5lZCBpbiBJRUVFIDgwMi4xYWQs IGFuZCBCLVZMQU4gaXMgZGVmaW5lZCBpbiBJRUVFIDgwMi4xYWguCgpUaGFua3MKWXVhbmxvbmcK X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwq3orz+yMs6IFJvZ2Vycywg Sm9zaCBbam9zaC5yb2dlcnNAdHdjYWJsZS5jb21dCreiy83KsbzkOiAyMDExxOoz1MIzMMjVIDIw OjUxCrW9OiBKaWFuZ3l1YW5sb25nOyByYWZpckBvcmNraXQuY29tCkNjOiBsMnZwbkBpZXRmLm9y ZwrW98ziOiBSZTogUy1WTEFOIGFjY2VzcyBpbiBFLVRyZWUKCkl0IHNvdW5kcyBsaWtlIHRoaXMg bWF5IGJlIGEgY29udGludWF0aW9uIG9mIGEgY29udmVyc2F0aW9uIGluIHBlcnNvbi4gQmVmb3Jl IGNvbnRpbnVpbmcsIEknZCBsaWtlIHRvIGtub3cgaWYgdGhlcmUgaXMgZG9jdW1lbnQgdGhhdCBk ZWZpbmVzIHZsYW4gdGFnIHR5cGUgbmFtZXMgKFMtVkxBTiwgQy1WTEFOLCBldGMpCgpPbiBhIHJl Z3VsYXIgYmFzaXMsIEkgd29yayB3aXRoIG90aGVyIG9wZXJhdG9ycywgYW5kIHRoZXJlIHNlZW1z IHRvIGJlIGEgZ3JlYXQgZGVhbCBvZiBjb25mdXNpb24gb24gY29tbW9uIHRlcm1pbm9sb2d5LgoK CgpKaWFuZ3l1YW5sb25nIDxqaWFuZ3l1YW5sb25nQGh1YXdlaS5jb20+IHdyb3RlOgoKCgpSYWZp IGFuZCBhbGwsCgpZZXN0ZXJkYXkgd2UgZGlzY3Vzc2VkIHRoZSBTLVZMQU4gYWNjZXNzIG9mIEUt VHJlZSBkdXJpbmcgdGhlIFdHIG1lZXRpbmcsIGluIGFkZGl0aW9uIHRvIFMtVkxBTiBtYXBwaW5n IG9yIEItVkxBTiBtZXRob2QsIGEgdGhpcmQgb3B0aW9uIGlzIGFsc28gcG9zc2libGUgaWYgaXQg aXMgYSBjYXJyaWVyIG92ZXIgY2FycmllciBuZXR3b3JrIHVzZSBjYXNlLCB0aGF0IGlzLCB0aGUg RS1UcmVlIHRyYWZmaWMgZnJvbSB0aGUgMXN0IGNhcnJpZXIgY2FuIGJlIHRyYW5zcGFyZW50bHkg dHJhbnNwb3J0ZWQgb3ZlciB0aGUgMm5kIGNhcnJpZXIncyBWUExTIG5ldHdvcmssIGp1c3QgYXMg aW4gdGhlIHRyYWRpdGlvbmFsIFZQTFMuIFRoaXMgc2VlbXMgbW9yZSBwcmFjdGljYWwgYXMgdGhl IEUtVHJlZSB0b3BvbG9neSBpcyB1c3VhbGx5IG9ubHkga25vd24gdG8gdGhlIDFzdCBjYXJyaWVy IHdoaWxlIHVuYXZhaWxhYmxlIHRvIHRoZSAybmQgY2FycmllciwgZnVydGhlcm1vcmUsIGl0IHJl cXVpcmVzIG5vIGNoYW5nZSBvbiB0aGUgMm5kIGNhcnJpZXIgbmV0d29yay4KCkJlc3QgcmVnYXJk cywKWXVhbmxvbmcKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpUaGlzIEUtbWFp bCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJs ZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50 aWFsLCBvciBzdWJqZWN0IHRvIGNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2Fi bGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5k aXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5v dCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBu b3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9y IGFjdGlvbiB0YWtlbiBpbiByZWxhdGlvbiB0byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1l bnRzIHRvIHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxh d2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBv cmlnaW5hbCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC4K From DanielC@orckit.com Wed Mar 30 08:54:51 2011 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 3DF4E3A6B73 for ; Wed, 30 Mar 2011 08:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=-0.002, 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 iS3sWqdzabqw for ; Wed, 30 Mar 2011 08:54:47 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by core3.amsl.com (Postfix) with ESMTP id 21FCC3A6B72 for ; Wed, 30 Mar 2011 08:54:46 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBEEF3.05C428E4" Subject: RE: S-VLAN access in E-Tree Date: Wed, 30 Mar 2011 17:56:23 +0200 Message-ID: <44F4E579A764584EA9BDFD07D0CA0813069E165D@tlvmail1> In-reply-to: <3B0A1BED22CAD649A1B3E97BE5DDD68B0317B271@SZXEML514-MBS.china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: S-VLAN access in E-Tree Thread-Index: AcvuwSPJzDbXjemeSb+thu3WLafxvAAMURTg References: <3B0A1BED22CAD649A1B3E97BE5DDD68B0317B271@SZXEML514-MBS.china.huawei.com> From: "Daniel Cohn" To: "Jiangyuanlong" Cc: l2vpn@ietf.org, Rafi Ram 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, 30 Mar 2011 15:54:51 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBEEF3.05C428E4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Yuanlong, thanks for your comments. Looking at the scenario you describe - if the second carrier is just doing transparent transport for the e-tree VPLS, from a scalability point of view it would make more sense to subtend the PW-VSIs directly between the e-tree-aware PEs, with the second carrier acting simply as PSN for these PWs. =20 Also, actually I'm not sure the scenario you describe is a valid one. If the second carrier is not e-tree aware, the e-tree VPLS won't comply with the e-tree requirements as stated in http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-reqt-02 and http://tools.ietf.org/html/draft-key-l2vpn-etree-frwk-03, no matter what solution is adopted. =20 Please note that adding VLAN tag for E-Tree functionality might be problematic to many implementations if the original frame already contains S-TAG/C-TAG or B-TAG. =20 Daniel - not Rafi ;-) =20 =20 From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Jiangyuanlong Sent: Wednesday, March 30, 2011 12:00 PM To: Rafi Ram Cc: l2vpn@ietf.org Subject: S-VLAN access in E-Tree =20 Rafi and all, =20 Yesterday we discussed the S-VLAN access of E-Tree during the WG meeting, in addition to S-VLAN mapping or B-VLAN method, a third option is also possible if it is a carrier over carrier network use case, that is, the E-Tree traffic from the 1st carrier can be transparently transported over the 2nd carrier's VPLS network, just as in the traditional VPLS. This seems more practical as the E-Tree topology is usually only known to the 1st carrier while unavailable to the 2nd carrier, furthermore, it requires no change on the 2nd carrier network. =20 Best regards, Yuanlong =20 ------_=_NextPart_001_01CBEEF3.05C428E4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Yuanlong, = thanks for your comments. Looking at the scenario you describe - if the = second carrier is just doing transparent transport for the e-tree VPLS, = from a scalability point of view it would make more sense to subtend the = PW-VSIs directly between the e-tree-aware PEs, with the second carrier = acting simply as PSN for these PWs.

 

Also, = actually I’m not sure the scenario you describe is a valid one. If = the second carrier is not e-tree aware, the e-tree VPLS won't comply = with the e-tree requirements as stated in ht= tp://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-reqt-02 and http://= tools.ietf.org/html/draft-key-l2vpn-etree-frwk-03, no matter what = solution is adopted.

 

Please note = that adding VLAN tag for E-Tree functionality might be problematic to = many implementations if the original frame already contains S-TAG/C-TAG = or B-TAG.

 

Daniel - not = Rafi ;-)

 

 

From:= = l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of = Jiangyuanlong
Sent: Wednesday, March 30, 2011 12:00 = PM
To: Rafi Ram
Cc: = l2vpn@ietf.org
Subject: S-VLAN access in = E-Tree

 

R= afi and all,=

=  

Y= esterday we discussed the S-VLAN access of E-Tree during the WG meeting, = in addition to S-VLAN mapping or B-VLAN method, a third option is = also possible if it is a carrier over carrier network use case, that is, = the E-Tree traffic from the 1st carrier can be transparently transported = over the 2nd carrier's VPLS network, just as in the traditional VPLS. = This seems more practical as the E-Tree topology is usually only known = to the 1st carrier while unavailable to the 2nd carrier, furthermore, it = requires no change on the 2nd carrier network.=

=  

B= est regards,=

Y= uanlong=

=  

------_=_NextPart_001_01CBEEF3.05C428E4-- From jiangyuanlong@huawei.com Wed Mar 30 11:11:05 2011 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 EA1D528C18C for ; Wed, 30 Mar 2011 11:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.05 X-Spam-Level: X-Spam-Status: No, score=-2.05 tagged_above=-999 required=5 tests=[AWL=-1.759, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 AGZLrp3FyVFN for ; Wed, 30 Mar 2011 11:11:04 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 9D95A28C164 for ; Wed, 30 Mar 2011 11:11:03 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIV002DIUKW00@szxga04-in.huawei.com> for l2vpn@ietf.org; Thu, 31 Mar 2011 02:12:32 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIV00J3XUKWN5@szxga04-in.huawei.com> for l2vpn@ietf.org; Thu, 31 Mar 2011 02:12:32 +0800 (CST) Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 31 Mar 2011 02:12:27 +0800 Received: from SZXEML514-MBS.china.huawei.com ([169.254.6.193]) by SZXEML402-HUB.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0270.001; Thu, 31 Mar 2011 02:12:31 +0800 Date: Wed, 30 Mar 2011 18:12:31 +0000 From: Jiangyuanlong Subject: Re: S-VLAN access in E-Tree In-reply-to: <44F4E579A764584EA9BDFD07D0CA0813069E165D@tlvmail1> X-Originating-IP: [172.24.2.40] To: Daniel Cohn Message-id: <3B0A1BED22CAD649A1B3E97BE5DDD68B0317D663@SZXEML514-MBS.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_UEd/hTyhRsyjTgHZHE9hzw)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: S-VLAN access in E-Tree Thread-index: AcvuwSPJzDbXjemeSb+thu3WLafxvAAMURTgAALLnGU= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <3B0A1BED22CAD649A1B3E97BE5DDD68B0317B271@SZXEML514-MBS.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA0813069E165D@tlvmail1> Cc: "l2vpn@ietf.org" , Rafi Ram 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, 30 Mar 2011 18:11:06 -0000 --Boundary_(ID_UEd/hTyhRsyjTgHZHE9hzw) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 RGFuaWVsLA0KDQpQbGVhc2Ugc2VlIG15IGNvbW1lbnRzIGlubGluZS4NCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCreivP7IyzogRGFuaWVsIENvaG4gW0RhbmllbENAb3Jja2l0 LmNvbV0NCreiy83KsbzkOiAyMDExxOoz1MIzMMjVIDIzOjU2DQq1vTogSmlhbmd5dWFubG9uZw0K Q2M6IGwydnBuQGlldGYub3JnOyBSYWZpIFJhbQ0K1vfM4jogUkU6IFMtVkxBTiBhY2Nlc3MgaW4g RS1UcmVlDQoNCg0KSGkgWXVhbmxvbmcsIHRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4gTG9va2lu ZyBhdCB0aGUgc2NlbmFyaW8geW91IGRlc2NyaWJlIC0gaWYgdGhlIHNlY29uZCBjYXJyaWVyIGlz IGp1c3QgZG9pbmcgdHJhbnNwYXJlbnQgdHJhbnNwb3J0IGZvciB0aGUgZS10cmVlIFZQTFMsIGZy b20gYSBzY2FsYWJpbGl0eSBwb2ludCBvZiB2aWV3IGl0IHdvdWxkIG1ha2UgbW9yZSBzZW5zZSB0 byBzdWJ0ZW5kIHRoZSBQVy1WU0lzIGRpcmVjdGx5IGJldHdlZW4gdGhlIGUtdHJlZS1hd2FyZSBQ RXMsIHdpdGggdGhlIHNlY29uZCBjYXJyaWVyIGFjdGluZyBzaW1wbHkgYXMgUFNOIGZvciB0aGVz ZSBQV3MuDQoNCltKWUxdICBBY3R1YWxseSB3ZSBhcmUgdGFsa2luZyBhYm91dCB0aGUgdXNlIGNh c2Ugd2hlcmUgY2FycmllciAxIGF0dGFjaGVkIHRvIGNhcnJpZXIgMiB3aXRoIGEgUy1WTEFOIHRh Z2dlZCBBQy4gWW91ciAgdXNlIGNhc2UgaXMgdmFsaWQsIGJ1dCB0aGUgc2VydmljZSBpbnRlcmZh Y2UgdG8gY2FycmllciAyIGlzIE1QTFMuDQoNCg0KQWxzbywgYWN0dWFsbHkgSaGvbSBub3Qgc3Vy ZSB0aGUgc2NlbmFyaW8geW91IGRlc2NyaWJlIGlzIGEgdmFsaWQgb25lLiBJZiB0aGUgc2Vjb25k IGNhcnJpZXIgaXMgbm90IGUtdHJlZSBhd2FyZSwgdGhlIGUtdHJlZSBWUExTIHdvbid0IGNvbXBs eSB3aXRoIHRoZSBlLXRyZWUgcmVxdWlyZW1lbnRzIGFzIHN0YXRlZCBpbiBodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1rZXktbDJ2cG4tdnBscy1ldHJlZS1yZXF0LTAyIGFuZCBodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1rZXktbDJ2cG4tZXRyZWUtZnJ3ay0wMywgbm8g bWF0dGVyIHdoYXQgc29sdXRpb24gaXMgYWRvcHRlZC4NCg0KW0pZTF0gU2luY2UgYWxsIGxlYWYg c2l0ZXMgYXJlIGNvbm5lY3RlZCB0byB0aGUgMXN0IGNhcnJpZXIsIGFzc3VtZSBhbGwgaXRzIG5l dHdvcmsgUEVzIGNhbiBzdXBwb3J0IEUtVHJlZSwgdGhlbiB0aGUgMm5kIGNhcnJpZXIgZG9lcyBu b3QgbmVlZCB0byBiZSBFLVRyZWUgYXdhcmUuIEJ1dCBhcyBhIHdob2xlLCB0aGUgRS1UcmVlIHJl cXVpcmVtZW50cyBhcmUgZnVsZmlsbGVkLg0KDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBhZGRpbmcg VkxBTiB0YWcgZm9yIEUtVHJlZSBmdW5jdGlvbmFsaXR5IG1pZ2h0IGJlIHByb2JsZW1hdGljIHRv IG1hbnkgaW1wbGVtZW50YXRpb25zIGlmIHRoZSBvcmlnaW5hbCBmcmFtZSBhbHJlYWR5IGNvbnRh aW5zIFMtVEFHL0MtVEFHIG9yIEItVEFHLg0KDQpbSllMXSBBcyBJIHNhaWQgYmVmb3JlLCBnbG9i YWwgVkxBTiBwcm92aXNpb25pbmcsIFZMQU4gbWFwcGluZyBvciB0cmFuc3BhcmVudGx5IHRyYW5z cG9ydCBhcmUgYWxsIG9wdGlvbmFsIG1lY2hhbmlzbXMgZm9yIHRoZSBhYm92ZSB1c2UgY2FzZXMu IEFmdGVyIGFsbCwgdGhlIHR5cGljYWwgVlBMUyBQRSBjb25zaXN0cyBvZiBhIGJyaWRnZSBtb2R1 bGUgYW5kIG9uZSBvciBtb3JlIFZTSXMsIG5vIG1hdHRlciB3aGF0IGlzIHVzZWQgdG8gaW5kaWNh dGUgcm9vdC9sZWFmIGluIGEgUFcgKFBXLCBjb250cm9sIHdvcmQsIG9yIFZMQU4sIGV0Yy4pLCB3 ZSBzdGlsbCBuZWVkIGFuIEV0aGVybmV0IG1lY2hhbmlzbSB0byBzdXBwb3J0IEUtVHJlZSBhY2Nl c3MgYW5kIGZpbHRlcmluZyBpbiB0aGUgYnJpZGdlIG1vZHVsZSBpdHNlbGYsIElNSE8sIGl0IHNo b3VsZCBiZSBiYXNlZCBvbiBJRUVFIHN0YW5kYXJkIHJhdGhlciB0aGFuIGRldmVsb3AgYW5vdGhl ciB3aGVlbCBpbiBvdXIgV0cuIFRoZXJlZm9yZSwgYWxsIG90aGVyIHNvbHV0aW9ucyBuZWVkIHRo ZSBzYW1lIFZMQU4gYmFzZWQgbWVjaGFuaXNtIGluIHRoZSBicmlkZ2UgbW9kdWxlLCB3aGlsZSBp bnRyb2R1Y2UgbW9yZSBjb21wbGV4aXRpZXMgaW4gdGhlIFZTSSBmb3J3YXJkaW5nIHBsYW5lIGF0 IHRoZSBzYW1lIHRpbWUuDQoNCg0KDQpEYW5pZWwgLSBub3QgUmFmaSA7LSkNCg0KW0pZTF0gV293 LCBpdCdzIG15IGZhdWx0ISBUaGFua3MgZm9yIHlvdXIgY29tbWVudHMgYW5kIHlvdXIga2luZG5l c3MuDQoNCg0KUmVnYXJkcw0KDQpZdWFubG9uZw0KDQoNCg0KRnJvbTogbDJ2cG4tYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKaWFu Z3l1YW5sb25nDQpTZW50OiBXZWRuZXNkYXksIE1hcmNoIDMwLCAyMDExIDEyOjAwIFBNDQpUbzog UmFmaSBSYW0NCkNjOiBsMnZwbkBpZXRmLm9yZw0KU3ViamVjdDogUy1WTEFOIGFjY2VzcyBpbiBF LVRyZWUNCg0KUmFmaSBhbmQgYWxsLA0KDQpZZXN0ZXJkYXkgd2UgZGlzY3Vzc2VkIHRoZSBTLVZM QU4gYWNjZXNzIG9mIEUtVHJlZSBkdXJpbmcgdGhlIFdHIG1lZXRpbmcsIGluIGFkZGl0aW9uIHRv IFMtVkxBTiBtYXBwaW5nIG9yIEItVkxBTiBtZXRob2QsIGEgdGhpcmQgb3B0aW9uIGlzIGFsc28g cG9zc2libGUgaWYgaXQgaXMgYSBjYXJyaWVyIG92ZXIgY2FycmllciBuZXR3b3JrIHVzZSBjYXNl LCB0aGF0IGlzLCB0aGUgRS1UcmVlIHRyYWZmaWMgZnJvbSB0aGUgMXN0IGNhcnJpZXIgY2FuIGJl IHRyYW5zcGFyZW50bHkgdHJhbnNwb3J0ZWQgb3ZlciB0aGUgMm5kIGNhcnJpZXIncyBWUExTIG5l dHdvcmssIGp1c3QgYXMgaW4gdGhlIHRyYWRpdGlvbmFsIFZQTFMuIFRoaXMgc2VlbXMgbW9yZSBw cmFjdGljYWwgYXMgdGhlIEUtVHJlZSB0b3BvbG9neSBpcyB1c3VhbGx5IG9ubHkga25vd24gdG8g dGhlIDFzdCBjYXJyaWVyIHdoaWxlIHVuYXZhaWxhYmxlIHRvIHRoZSAybmQgY2FycmllciwgZnVy dGhlcm1vcmUsIGl0IHJlcXVpcmVzIG5vIGNoYW5nZSBvbiB0aGUgMm5kIGNhcnJpZXIgbmV0d29y ay4NCg0KQmVzdCByZWdhcmRzLA0KWXVhbmxvbmcNCg0K --Boundary_(ID_UEd/hTyhRsyjTgHZHE9hzw) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable
Daniel,

Please see my comments inline.

=B7=A2=BC=FE=C8=CB: Daniel Cohn [DanielC@orckit.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA3=D4=C230=C8=D5 23:56
=B5=BD: Jiangyuanlong
Cc: l2vpn@ietf.org; Rafi Ram
=D6=F7=CC=E2: RE: S-VLAN access in E-Tree

Hi Yuanlong, thanks for your comments. Looking at the scenario = you describe - if the second carrier is just doing transparent transport fo= r the e-tree VPLS, from a scalability point of view it would make more sense to subtend the PW-VSIs directly between the e-tree-a= ware PEs, with the second carrier acting simply as PSN for these PWs.

[JYL]  Actually we are talking about the use case where ca= rrier 1 attached to carrier 2 with a S-VLAN tagged AC. Your  use case = is valid, but the service interface to carrier 2 is MPLS.


Also, actually I=A1=AFm not sure the scenario you describe is a= valid one. If the second carrier is not e-tree aware, the e-tree VPLS won'= t comply with the e-tree requirements as stated in http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-reqt-02 and http://tools.ietf.org/html/draft-key-l2vpn-etree-frwk-03, no matter wha= t solution is adopted.

[JYL] Since all leaf sites are connected to the 1st carrier, as= sume all its network PEs can support E-Tree, then the 2nd carrier does not = need to be E-Tree aware. But as a whole, the E-Tree requirements are fulfilled.

 

Please note that adding VLAN tag for E-Tree functionality might= be problematic to many implementations if the original frame already conta= ins S-TAG/C-TAG or B-TAG.

[JYL] As I said before, global VLAN provisioning, VLAN mapping = or transparently transport are all optional mechanisms for the above use ca= ses. After all, the typical VPLS PE consists of a bridge module and one or more VSIs, no matter what is used to indicate root/leaf = in a PW (PW, control word, or VLAN, etc.), we still need an Ethernet mechan= ism to support E-Tree access and filtering in the bridge module itself, IMH= O, it should be based on IEEE standard rather than develop another wheel in our WG. Therefore, all other solution= s need the same VLAN based mechanism in the bridge module, while introduce = more complexities in the VSI forwarding plane at the same time.

 

Daniel - not Rafi ;-)

[JYL] Wow, it's my fault! Thanks for your comments and your kin= dness.


Regards

Yuanlong


 

 

From: l2vpn-= bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Jiangyuanlong
Sent: Wednesday, March 30, 2011 12:00 PM
To: Rafi Ram
Cc: l2vpn@ietf.org
Subject: S-VLAN access in E-Tree

 

Rafi and all,

 

Yesterday we discussed the S-VLAN access of E-Tree during the WG meet= ing, in addition to S-VLAN mapping or B-VLAN method, a third option is also possible if it is a carrier over carrier network use case, = that is, the E-Tree traffic from the 1st carrier can be transparently trans= ported over the 2nd carrier's VPLS network, just as in the traditional VPLS= . This seems more practical as the E-Tree topology is usually only known to the 1st carrier while unavailable= to the 2nd carrier, furthermore, it requires no change on the 2nd carrier = network.

 

Best regards,

Yuanlong

 

--Boundary_(ID_UEd/hTyhRsyjTgHZHE9hzw)-- From raymond.key@hotmail.com Wed Mar 30 13:37:01 2011 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 B9AB73A6BC5 for ; Wed, 30 Mar 2011 13:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 96eBdBDzGlvU for ; Wed, 30 Mar 2011 13:37:00 -0700 (PDT) Received: from snt0-omc3-s35.snt0.hotmail.com (snt0-omc3-s35.snt0.hotmail.com [65.55.90.174]) by core3.amsl.com (Postfix) with ESMTP id AE4433A6A64 for ; Wed, 30 Mar 2011 13:37:00 -0700 (PDT) Received: from SNT123-W52 ([65.55.90.137]) by snt0-omc3-s35.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 Mar 2011 13:38:39 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_86849792-5fa3-4a35-9a16-8d02be6cb0df_" X-Originating-IP: [122.107.153.185] From: Raymond Key Sender: To: , Subject: RE: Draft of new L2VPN WG Charter Date: Thu, 31 Mar 2011 07:38:39 +1100 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 30 Mar 2011 20:38:39.0886 (UTC) FILETIME=[73A962E0:01CBEF1A] 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, 30 Mar 2011 20:37:01 -0000 --_86849792-5fa3-4a35-9a16-8d02be6cb0df_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I support the re-charter. Raymond Key =20 > Date: Fri=2C 18 Mar 2011 17:41:08 +0000 > Subject: Draft of new L2VPN WG Charter > From: giles.heron@gmail.com > To: l2vpn@ietf.org >=20 > We plan to re-charter the L2VPN WG - primarily to bring E-VPN and E-Tree > in-scope. >=20 > Please find attached a draft charter for discussion both on this list and= at > IETF 80 in Prague. >=20 > Nabil and Giles >=20 >=20 = --_86849792-5fa3-4a35-9a16-8d02be6cb0df_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I support the re-charter.
Raymond Key
 =3B
>=3B Date: Fri=2C 18 Mar 2011 17:41:08 +0000
>=3B Subject: Draft of = new L2VPN WG Charter
>=3B From: giles.heron@gmail.com
>=3B To: l2= vpn@ietf.org
>=3B
>=3B We plan to re-charter the L2VPN WG - prim= arily to bring E-VPN and E-Tree
>=3B in-scope.
>=3B
>=3B Pl= ease find attached a draft charter for discussion both on this list and at<= BR>>=3B IETF 80 in Prague.
>=3B
>=3B Nabil and Giles
>=3B=
>=3B
= --_86849792-5fa3-4a35-9a16-8d02be6cb0df_-- From DanielC@orckit.com Thu Mar 31 01:55:00 2011 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 875C728C1AE for ; Thu, 31 Mar 2011 01:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.374 X-Spam-Level: X-Spam-Status: No, score=-1.374 tagged_above=-999 required=5 tests=[AWL=-1.226, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] 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 jK5RvgQGy4ZH for ; Thu, 31 Mar 2011 01:54:59 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by core3.amsl.com (Postfix) with ESMTP id 064DB28C1B6 for ; Thu, 31 Mar 2011 01:54:57 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBEF81.89023140" Subject: RE: S-VLAN access in E-Tree Date: Thu, 31 Mar 2011 10:57:32 +0200 Message-ID: <44F4E579A764584EA9BDFD07D0CA0813069E1762@tlvmail1> In-reply-to: <45A67426326F814AAC27DBEC3FC7EEC203DC8461@tlvmail1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: S-VLAN access in E-Tree Thread-Index: AcvuwSPJzDbXjemeSb+thu3WLafxvAAMURTgAALLnGUAHgXNUAACfbgw References: <3B0A1BED22CAD649A1B3E97BE5DDD68B0317B271@SZXEML514-MBS.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA0813069E165D@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B0317D663@SZXEML514-MBS.china.huawei.com> <45A67426326F814AAC27DBEC3FC7EEC203DC8461@tlvmail1> From: "Daniel Cohn" To: "Jiangyuanlong" Cc: l2vpn@ietf.org, Rafi Ram 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, 31 Mar 2011 08:55:00 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBEF81.89023140 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi Yuanlong, please see inline with [DC]. =20 ________________________________ =B7=A2=BC=FE=C8=CB: Daniel Cohn [DanielC@orckit.com] =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA3=D4=C230=C8=D5 23:56 =B5=BD: Jiangyuanlong Cc: l2vpn@ietf.org; Rafi Ram =D6=F7=CC=E2: RE: S-VLAN access in E-Tree Hi Yuanlong, thanks for your comments. Looking at the scenario you = describe - if the second carrier is just doing transparent transport for = the e-tree VPLS, from a scalability point of view it would make more = sense to subtend the PW-VSIs directly between the e-tree-aware PEs, with = the second carrier acting simply as PSN for these PWs. [JYL] Actually we are talking about the use case where carrier 1 = attached to carrier 2 with a S-VLAN tagged AC. Your use case is valid, = but the service interface to carrier 2 is MPLS. =20 [DC] Interfacing between carriers using VLAN handoff (SP interconnection = on tagged AC) has the following drawbacks: 1. Service scalability =A8C each E-Tree service uses up two VLANs = out of 4K VLAN range 2. VID coordination =A8C VLAN-ID X of carrier 1 may be already in = use in carrier 2 network for different service 3. End-to-end OAM =A8C Assuming the carriers have MPLS network, = VLAN handoff precludes the usage of MPLS end-to-end OAM tools =20 =20 Also, actually I=A1=AFm not sure the scenario you describe is a valid = one. If the second carrier is not e-tree aware, the e-tree VPLS won't = comply with the e-tree requirements as stated in = http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-reqt-02 and = http://tools.ietf.org/html/draft-key-l2vpn-etree-frwk-03, no matter what = solution is adopted. [JYL] Since all leaf sites are connected to the 1st carrier, assume all = its network PEs can support E-Tree, then the 2nd carrier does not need = to be E-Tree aware. But as a whole, the E-Tree requirements are = fulfilled. =20 [DC] This assumption (=A1=B0all leaf sites are connected to the 1st = carrier) appears to conflict with =A1=B0Service Provider = Independence=A1=B1. From L2VPN requirements : =20 Customers MAY require L2VPN service that spans multiple administrative domains or SP networks. Therefore, an L2VPN service MUST be able to span multiple AS and SP networks but still to act and to appear as a single, homogeneous L2VPN from a customer point of view. =20 A customer might also start with an L2VPN provided in a single AS with a certain SLS but then ask for an expansion of the service spanning multiple ASes and/or multiple-SPs. In this case, as well as for all kinds of multi-AS and multiple-SP L2VPNs, L2VPN service SHOULD be able to deliver the same SLS to all sites in a VPN regardless of the AS/SP to which it homes. =20 =20 Please note that adding VLAN tag for E-Tree functionality might be = problematic to many implementations if the original frame already = contains S-TAG/C-TAG or B-TAG. [JYL] As I said before, global VLAN provisioning, VLAN mapping or = transparently transport are all optional mechanisms for the above use = cases. After all, the typical VPLS PE consists of a bridge module and = one or more VSIs, no matter what is used to indicate root/leaf in a PW = (PW, control word, or VLAN, etc.), we still need an Ethernet mechanism = to support E-Tree access and filtering in the bridge module itself, = IMHO, it should be based on IEEE standard rather than develop another = wheel in our WG. Therefore, all other solutions need the same VLAN based = mechanism in the bridge module, while introduce more complexities in the = VSI forwarding plane at the same time. =20 Daniel - not Rafi ;-) [JYL] Wow, it's my fault! Thanks for your comments and your kindness. =20 Regards Yuanlong =20 =20 =20 From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of Jiangyuanlong Sent: Wednesday, March 30, 2011 12:00 PM To: Rafi Ram Cc: l2vpn@ietf.org Subject: S-VLAN access in E-Tree =20 Rafi and all, =20 Yesterday we discussed the S-VLAN access of E-Tree during the WG = meeting, in addition to S-VLAN mapping or B-VLAN method, a third option = is also possible if it is a carrier over carrier network use case, that = is, the E-Tree traffic from the 1st carrier can be transparently = transported over the 2nd carrier's VPLS network, just as in the = traditional VPLS. This seems more practical as the E-Tree topology is = usually only known to the 1st carrier while unavailable to the 2nd = carrier, furthermore, it requires no change on the 2nd carrier network. =20 Best regards, Yuanlong =20 ------_=_NextPart_001_01CBEF81.89023140 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Yuanlong, please see inline with = [DC].

=  

=

=B7=A2=BC=FE=C8=CB= := Daniel Cohn [DanielC@orckit.com]
=B7=A2=CB=CD=CA=B1=BC=E4= := 2011=C4=EA= 3=D4=C2= 30=C8=D5= 23:56
=B5=BD= := Jiangyuanlong
Cc: l2vpn@ietf.org; Rafi Ram
=D6=F7=CC=E2= := RE: S-VLAN access in E-Tree

H= i Yuanlong, thanks for your comments. Looking at the scenario you = describe - if the second carrier is just doing transparent transport for = the e-tree VPLS, from a scalability point of view it would make more = sense to subtend the PW-VSIs directly between the e-tree-aware PEs, with = the second carrier acting simply as PSN for these = PWs.

[= JYL]  Actually we are talking about the use case where carrier 1 = attached to carrier 2 with a S-VLAN tagged AC. Your  use case is = valid, but the service interface to carrier 2 is = MPLS.

 

[DC] Interfacing between carriers using VLAN = handoff (SP interconnection on tagged AC) = has the following = drawbacks:

1.      Service scalability =A8C each E-Tree = service uses up two VLANs out of 4K VLAN range

2.      VID coordination =A8C VLAN-ID X of carrier 1 = may be already in use in carrier 2 network for different = service

3.      End-to-end OAM =A8C Assuming the carriers = have MPLS network, VLAN handoff precludes the usage of MPLS end-to-end OAM tools =  

 <= /o:p>

A= lso, actually I=A1=AFm not sure the scenario you describe is a valid = one. If the second carrier is not e-tree aware, the e-tree VPLS won't = comply with the e-tree requirements as stated in http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-r= eqt-02 and http://tools.ietf.org/html/draft-key-l2vpn-etree-frwk-0= 3, no matter what solution is adopted.

[= JYL] Since all leaf sites are connected to the 1st carrier, assume all = its network PEs can support E-Tree, then the 2nd carrier does not need = to be E-Tree aware. But as a whole, the E-Tree requirements are = fulfilled.

&n= bsp;

[DC]  This assumption (=A1=B0all leaf sites are connected to the = 1st carrier) appears to conflict with =A1=B0Service = Provider Independence=A1=B1. From L2VPN = requirements :

 

   Customers MAY require L2VPN service that = spans multiple

   administrative domains or SP = networks.  Therefore, an L2VPN service

   MUST be = able to span multiple AS and SP networks but still to act = and

   to appear as a single, homogeneous L2VPN = from a customer point of

   view.

 

   A customer might also start with an L2VPN = provided in a single AS

   with a certain SLS but then ask for an = expansion of the service

   spanning multiple ASes and/or = multiple-SPs.  In this case, as well as

   for all = kinds of multi-AS and multiple-SP L2VPNs, L2VPN = service

   SHOULD be able to deliver the same SLS to = all sites in a VPN

   regardless of the AS/SP to which it = homes.

 <= /o:p>

&= nbsp;

P= lease note that adding VLAN tag for E-Tree functionality might be = problematic to many implementations if the original frame already = contains S-TAG/C-TAG or B-TAG.

[= JYL] As I said before, global VLAN provisioning, VLAN mapping or = transparently transport are all optional mechanisms for the above use = cases. After all, the typical VPLS PE consists of a bridge module and = one or more VSIs, no matter what is used to indicate root/leaf in a PW = (PW, control word, or VLAN, etc.), we still need an Ethernet mechanism = to support E-Tree access and filtering in the bridge module itself, = IMHO, it should be based on IEEE standard rather than develop another = wheel in our WG. Therefore, all other solutions need the same VLAN based = mechanism in the bridge module, while introduce more complexities in the = VSI forwarding plane at the same time.

&= nbsp;

D= aniel - not Rafi ;-)

[= JYL] Wow, it's my fault! Thanks for your comments and your = kindness.

 

R= egards

Y= uanlong

 

 

 

= From:= l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of = Jiangyuanlong
Sent: Wednesday, March 30, 2011 12:00 = PM
To: Rafi Ram
Cc: = l2vpn@ietf.org
Subject: S-VLAN access in = E-Tree

 

R= afi and all,

=  

Y= esterday we discussed the S-VLAN access of E-Tree during the WG meeting, = in addition to S-VLAN mapping or B-VLAN method, a third option is = also possible if it is a carrier over carrier network use case, that is, = the E-Tree traffic from the 1st carrier can be transparently transported = over the 2nd carrier's VPLS network, just as in the traditional VPLS. = This seems more practical as the E-Tree topology is usually only known = to the 1st carrier while unavailable to the 2nd carrier, furthermore, it = requires no change on the 2nd carrier = network.

=  

B= est regards,

Y= uanlong

=  

------_=_NextPart_001_01CBEF81.89023140-- From jiangyuanlong@huawei.com Thu Mar 31 02:50:03 2011 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 0DB873A680E for ; Thu, 31 Mar 2011 02:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.744 X-Spam-Level: X-Spam-Status: No, score=0.744 tagged_above=-999 required=5 tests=[AWL=-3.849, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] 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 MCChCzJnXCl2 for ; Thu, 31 Mar 2011 02:50:01 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id BF4EB3A6949 for ; Thu, 31 Mar 2011 02:49:59 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIX00GVH21QSF@szxga05-in.huawei.com> for l2vpn@ietf.org; Thu, 31 Mar 2011 17:51:26 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIX008Z621N46@szxga05-in.huawei.com> for l2vpn@ietf.org; Thu, 31 Mar 2011 17:51:26 +0800 (CST) Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 31 Mar 2011 17:51:19 +0800 Received: from SZXEML514-MBS.china.huawei.com ([169.254.6.193]) by SZXEML402-HUB.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0270.001; Thu, 31 Mar 2011 17:51:23 +0800 Date: Thu, 31 Mar 2011 09:51:22 +0000 From: Jiangyuanlong Subject: Re: S-VLAN access in E-Tree In-reply-to: <44F4E579A764584EA9BDFD07D0CA0813069E1762@tlvmail1> X-Originating-IP: [172.24.2.40] To: Daniel Cohn Message-id: <3B0A1BED22CAD649A1B3E97BE5DDD68B0317EA29@SZXEML514-MBS.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_vuW20AQe1sMZUS/VaVOTTg)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: S-VLAN access in E-Tree Thread-index: AcvuwSPJzDbXjemeSb+thu3WLafxvAAMURTgAALLnGUAHgXNUAACfbgwAADFz9s= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <3B0A1BED22CAD649A1B3E97BE5DDD68B0317B271@SZXEML514-MBS.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA0813069E165D@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B0317D663@SZXEML514-MBS.china.huawei.com> <45A67426326F814AAC27DBEC3FC7EEC203DC8461@tlvmail1> <44F4E579A764584EA9BDFD07D0CA0813069E1762@tlvmail1> Cc: "l2vpn@ietf.org" , Rafi Ram 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, 31 Mar 2011 09:50:03 -0000 --Boundary_(ID_vuW20AQe1sMZUS/VaVOTTg) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 RGFuaWVsLCB0aGUgc2NlbmFyaW8gd2UgYXJlIGRpc2N1c3NpbmcgZnJvbSB0aGUgYmVnaW5uaW5n IGlzIGEgImNhcnJpZXIgb3ZlciBjYXJyaWVyIiBuZXR3b3JrIHdpdGggUy1WTEFOIGludGVyZmFj ZSwgZm9yIGV4YW1wbGUsIHRoZSAxc3QgY2FycmllciBpcyBhIHByb3ZpZGVyIG5ldHdvcmsgaW4g YWNjb3JkYW5jZSB3aXRoIElFRUUgODAyLjFhZCwgYW5kIHRoZSAybmQgY2FycmllciBpcyBhIFZQ TFMgbmV0d29yay4gVGhpcyBraW5kIG9mIG5ldHdvcmsgc2NlbmFyaW8gZXhpc3RzIHRvZGF5LiBU aGUgdXNlIGNhc2UgeW91IGRlc2NyaWJlZCBpcyBhbm90aGVyIHNjZW5hcmlvLCB3aGVyZSBhIGNh cnJpZXIgcGVlcnMgd2l0aCBhbm90aGVyIGNhcnJpZXIuDQoNCkZ1cnRoZXIgY29tbWVudHMgYXJl IGlubGluZS4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogRGFu aWVsIENvaG4gW0RhbmllbENAb3Jja2l0LmNvbV0NCreiy83KsbzkOiAyMDExxOoz1MIzMcjVIDE2 OjU3DQq1vTogSmlhbmd5dWFubG9uZw0KQ2M6IGwydnBuQGlldGYub3JnOyBSYWZpIFJhbQ0K1vfM 4jogUkU6IFMtVkxBTiBhY2Nlc3MgaW4gRS1UcmVlDQoNCkhpIFl1YW5sb25nLCBwbGVhc2Ugc2Vl IGlubGluZSB3aXRoIFtEQ10uDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3 orz+yMs6IERhbmllbCBDb2huIFtEYW5pZWxDQG9yY2tpdC5jb21dDQq3osvNyrG85DogMjAxMcTq M9TCMzDI1SAyMzo1Ng0Ktb06IEppYW5neXVhbmxvbmcNCkNjOiBsMnZwbkBpZXRmLm9yZzsgUmFm aSBSYW0NCtb3zOI6IFJFOiBTLVZMQU4gYWNjZXNzIGluIEUtVHJlZQ0KDQpIaSBZdWFubG9uZywg dGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLiBMb29raW5nIGF0IHRoZSBzY2VuYXJpbyB5b3UgZGVz Y3JpYmUgLSBpZiB0aGUgc2Vjb25kIGNhcnJpZXIgaXMganVzdCBkb2luZyB0cmFuc3BhcmVudCB0 cmFuc3BvcnQgZm9yIHRoZSBlLXRyZWUgVlBMUywgZnJvbSBhIHNjYWxhYmlsaXR5IHBvaW50IG9m IHZpZXcgaXQgd291bGQgbWFrZSBtb3JlIHNlbnNlIHRvIHN1YnRlbmQgdGhlIFBXLVZTSXMgZGly ZWN0bHkgYmV0d2VlbiB0aGUgZS10cmVlLWF3YXJlIFBFcywgd2l0aCB0aGUgc2Vjb25kIGNhcnJp ZXIgYWN0aW5nIHNpbXBseSBhcyBQU04gZm9yIHRoZXNlIFBXcy4NCg0KW0pZTF0gIEFjdHVhbGx5 IHdlIGFyZSB0YWxraW5nIGFib3V0IHRoZSB1c2UgY2FzZSB3aGVyZSBjYXJyaWVyIDEgYXR0YWNo ZWQgdG8gY2FycmllciAyIHdpdGggYSBTLVZMQU4gdGFnZ2VkIEFDLiBZb3VyICB1c2UgY2FzZSBp cyB2YWxpZCwgYnV0IHRoZSBzZXJ2aWNlIGludGVyZmFjZSB0byBjYXJyaWVyIDIgaXMgTVBMUy4N Cg0KDQoNCltEQ10gSW50ZXJmYWNpbmcgYmV0d2VlbiBjYXJyaWVycyB1c2luZyBWTEFOIGhhbmRv ZmYgKFNQIGludGVyY29ubmVjdGlvbiBvbiB0YWdnZWQgQUMpIGhhcyB0aGUgZm9sbG93aW5nIGRy YXdiYWNrczoNCg0KMS4gICAgICBTZXJ2aWNlIHNjYWxhYmlsaXR5IKhDIGVhY2ggRS1UcmVlIHNl cnZpY2UgdXNlcyB1cCB0d28gVkxBTnMgb3V0IG9mIDRLIFZMQU4gcmFuZ2UNCg0KMi4gICAgICBW SUQgY29vcmRpbmF0aW9uIKhDIFZMQU4tSUQgWCBvZiBjYXJyaWVyIDEgbWF5IGJlIGFscmVhZHkg aW4gdXNlIGluIGNhcnJpZXIgMiBuZXR3b3JrIGZvciBkaWZmZXJlbnQgc2VydmljZQ0KDQpbSllM XSBJZiBsb2NhbCBWTEFOIG1hcHBpbmcgaXMgc3VwcG9ydGVkLCB0aGUgYWJvdmUgMiBwcm9ibGVt IHNlZW1zIHRyaXZpYWwuIEZ1cnRoZXJtb3JlLCBWUExTIGNhbiBleHRlbmQgdGhlIHNjYWxhYmls aXR5IG9mIHRoZSBFLVRyZWUgd2l0aCBhcHByb3ByaWF0ZSBQRSBtb2RlbHMuDQoNCg0KMy4gICAg ICBFbmQtdG8tZW5kIE9BTSCoQyBBc3N1bWluZyB0aGUgY2FycmllcnMgaGF2ZSBNUExTIG5ldHdv cmssIFZMQU4gaGFuZG9mZiBwcmVjbHVkZXMgdGhlIHVzYWdlIG9mIE1QTFMgZW5kLXRvLWVuZCBP QU0gdG9vbHMNCg0KW0pZTF0gQXMgaW5kaWNhdGVkIGFib3ZlLCB0aGUgYXNzdW1wdGlvbiBvZiB1 bmlmb3JtIE1QTFMgbmV0d29yayBkb2VzIG5vdCBhcHBseSBoZXJlLg0KDQoNCg0KQWxzbywgYWN0 dWFsbHkgSaGvbSBub3Qgc3VyZSB0aGUgc2NlbmFyaW8geW91IGRlc2NyaWJlIGlzIGEgdmFsaWQg b25lLiBJZiB0aGUgc2Vjb25kIGNhcnJpZXIgaXMgbm90IGUtdHJlZSBhd2FyZSwgdGhlIGUtdHJl ZSBWUExTIHdvbid0IGNvbXBseSB3aXRoIHRoZSBlLXRyZWUgcmVxdWlyZW1lbnRzIGFzIHN0YXRl ZCBpbiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1rZXktbDJ2cG4tdnBscy1ldHJl ZS1yZXF0LTAyIGFuZCBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1rZXktbDJ2cG4t ZXRyZWUtZnJ3ay0wMywgbm8gbWF0dGVyIHdoYXQgc29sdXRpb24gaXMgYWRvcHRlZC4NCg0KW0pZ TF0gU2luY2UgYWxsIGxlYWYgc2l0ZXMgYXJlIGNvbm5lY3RlZCB0byB0aGUgMXN0IGNhcnJpZXIs IGFzc3VtZSBhbGwgaXRzIG5ldHdvcmsgUEVzIGNhbiBzdXBwb3J0IEUtVHJlZSwgdGhlbiB0aGUg Mm5kIGNhcnJpZXIgZG9lcyBub3QgbmVlZCB0byBiZSBFLVRyZWUgYXdhcmUuIEJ1dCBhcyBhIHdo b2xlLCB0aGUgRS1UcmVlIHJlcXVpcmVtZW50cyBhcmUgZnVsZmlsbGVkLg0KDQoNCg0KW0RDXSAg VGhpcyBhc3N1bXB0aW9uICihsGFsbCBsZWFmIHNpdGVzIGFyZSBjb25uZWN0ZWQgdG8gdGhlIDFz dCBjYXJyaWVyKSBhcHBlYXJzIHRvIGNvbmZsaWN0IHdpdGggobBTZXJ2aWNlIFByb3ZpZGVyIElu ZGVwZW5kZW5jZaGxLiBGcm9tIEwyVlBOIHJlcXVpcmVtZW50cyA6DQoNCg0KICAgQ3VzdG9tZXJz IE1BWSByZXF1aXJlIEwyVlBOIHNlcnZpY2UgdGhhdCBzcGFucyBtdWx0aXBsZQ0KICAgYWRtaW5p c3RyYXRpdmUgZG9tYWlucyBvciBTUCBuZXR3b3Jrcy4gIFRoZXJlZm9yZSwgYW4gTDJWUE4gc2Vy dmljZQ0KICAgTVVTVCBiZSBhYmxlIHRvIHNwYW4gbXVsdGlwbGUgQVMgYW5kIFNQIG5ldHdvcmtz IGJ1dCBzdGlsbCB0byBhY3QgYW5kDQogICB0byBhcHBlYXIgYXMgYSBzaW5nbGUsIGhvbW9nZW5l b3VzIEwyVlBOIGZyb20gYSBjdXN0b21lciBwb2ludCBvZg0KICAgdmlldy4NCg0KICAgQSBjdXN0 b21lciBtaWdodCBhbHNvIHN0YXJ0IHdpdGggYW4gTDJWUE4gcHJvdmlkZWQgaW4gYSBzaW5nbGUg QVMNCiAgIHdpdGggYSBjZXJ0YWluIFNMUyBidXQgdGhlbiBhc2sgZm9yIGFuIGV4cGFuc2lvbiBv ZiB0aGUgc2VydmljZQ0KICAgc3Bhbm5pbmcgbXVsdGlwbGUgQVNlcyBhbmQvb3IgbXVsdGlwbGUt U1BzLiAgSW4gdGhpcyBjYXNlLCBhcyB3ZWxsIGFzDQogICBmb3IgYWxsIGtpbmRzIG9mIG11bHRp LUFTIGFuZCBtdWx0aXBsZS1TUCBMMlZQTnMsIEwyVlBOIHNlcnZpY2UNCiAgIFNIT1VMRCBiZSBh YmxlIHRvIGRlbGl2ZXIgdGhlIHNhbWUgU0xTIHRvIGFsbCBzaXRlcyBpbiBhIFZQTg0KICAgcmVn YXJkbGVzcyBvZiB0aGUgQVMvU1AgdG8gd2hpY2ggaXQgaG9tZXMuDQoNCg0KDQoNCg0KUGxlYXNl IG5vdGUgdGhhdCBhZGRpbmcgVkxBTiB0YWcgZm9yIEUtVHJlZSBmdW5jdGlvbmFsaXR5IG1pZ2h0 IGJlIHByb2JsZW1hdGljIHRvIG1hbnkgaW1wbGVtZW50YXRpb25zIGlmIHRoZSBvcmlnaW5hbCBm cmFtZSBhbHJlYWR5IGNvbnRhaW5zIFMtVEFHL0MtVEFHIG9yIEItVEFHLg0KDQpbSllMXSBBcyBJ IHNhaWQgYmVmb3JlLCBnbG9iYWwgVkxBTiBwcm92aXNpb25pbmcsIFZMQU4gbWFwcGluZyBvciB0 cmFuc3BhcmVudGx5IHRyYW5zcG9ydCBhcmUgYWxsIG9wdGlvbmFsIG1lY2hhbmlzbXMgZm9yIHRo ZSBhYm92ZSB1c2UgY2FzZXMuIEFmdGVyIGFsbCwgdGhlIHR5cGljYWwgVlBMUyBQRSBjb25zaXN0 cyBvZiBhIGJyaWRnZSBtb2R1bGUgYW5kIG9uZSBvciBtb3JlIFZTSXMsIG5vIG1hdHRlciB3aGF0 IGlzIHVzZWQgdG8gaW5kaWNhdGUgcm9vdC9sZWFmIGluIGEgUFcgKFBXLCBjb250cm9sIHdvcmQs IG9yIFZMQU4sIGV0Yy4pLCB3ZSBzdGlsbCBuZWVkIGFuIEV0aGVybmV0IG1lY2hhbmlzbSB0byBz dXBwb3J0IEUtVHJlZSBhY2Nlc3MgYW5kIGZpbHRlcmluZyBpbiB0aGUgYnJpZGdlIG1vZHVsZSBp dHNlbGYsIElNSE8sIGl0IHNob3VsZCBiZSBiYXNlZCBvbiBJRUVFIHN0YW5kYXJkIHJhdGhlciB0 aGFuIGRldmVsb3AgYW5vdGhlciB3aGVlbCBpbiBvdXIgV0cuIFRoZXJlZm9yZSwgYWxsIG90aGVy IHNvbHV0aW9ucyBuZWVkIHRoZSBzYW1lIFZMQU4gYmFzZWQgbWVjaGFuaXNtIGluIHRoZSBicmlk Z2UgbW9kdWxlLCB3aGlsZSBpbnRyb2R1Y2UgbW9yZSBjb21wbGV4aXRpZXMgaW4gdGhlIFZTSSBm b3J3YXJkaW5nIHBsYW5lIGF0IHRoZSBzYW1lIHRpbWUuDQoNCg0KDQpEYW5pZWwgLSBub3QgUmFm aSA7LSkNCg0KW0pZTF0gV293LCBpdCdzIG15IGZhdWx0ISBUaGFua3MgZm9yIHlvdXIgY29tbWVu dHMgYW5kIHlvdXIga2luZG5lc3MuDQoNCg0KDQpSZWdhcmRzDQoNCll1YW5sb25nDQoNCg0KDQoN CkZyb206IGwydnBuLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgSmlhbmd5dWFubG9uZw0KU2VudDogV2VkbmVzZGF5LCBNYXJjaCAz MCwgMjAxMSAxMjowMCBQTQ0KVG86IFJhZmkgUmFtDQpDYzogbDJ2cG5AaWV0Zi5vcmcNClN1Ympl Y3Q6IFMtVkxBTiBhY2Nlc3MgaW4gRS1UcmVlDQoNClJhZmkgYW5kIGFsbCwNCg0KWWVzdGVyZGF5 IHdlIGRpc2N1c3NlZCB0aGUgUy1WTEFOIGFjY2VzcyBvZiBFLVRyZWUgZHVyaW5nIHRoZSBXRyBt ZWV0aW5nLCBpbiBhZGRpdGlvbiB0byBTLVZMQU4gbWFwcGluZyBvciBCLVZMQU4gbWV0aG9kLCBh IHRoaXJkIG9wdGlvbiBpcyBhbHNvIHBvc3NpYmxlIGlmIGl0IGlzIGEgY2FycmllciBvdmVyIGNh cnJpZXIgbmV0d29yayB1c2UgY2FzZSwgdGhhdCBpcywgdGhlIEUtVHJlZSB0cmFmZmljIGZyb20g dGhlIDFzdCBjYXJyaWVyIGNhbiBiZSB0cmFuc3BhcmVudGx5IHRyYW5zcG9ydGVkIG92ZXIgdGhl IDJuZCBjYXJyaWVyJ3MgVlBMUyBuZXR3b3JrLCBqdXN0IGFzIGluIHRoZSB0cmFkaXRpb25hbCBW UExTLiBUaGlzIHNlZW1zIG1vcmUgcHJhY3RpY2FsIGFzIHRoZSBFLVRyZWUgdG9wb2xvZ3kgaXMg dXN1YWxseSBvbmx5IGtub3duIHRvIHRoZSAxc3QgY2FycmllciB3aGlsZSB1bmF2YWlsYWJsZSB0 byB0aGUgMm5kIGNhcnJpZXIsIGZ1cnRoZXJtb3JlLCBpdCByZXF1aXJlcyBubyBjaGFuZ2Ugb24g dGhlIDJuZCBjYXJyaWVyIG5ldHdvcmsuDQoNCkJlc3QgcmVnYXJkcywNCll1YW5sb25nDQoNCg== --Boundary_(ID_vuW20AQe1sMZUS/VaVOTTg) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable
Daniel, the scenario we are discussing from the beginning is a "c= arrier over carrier" network with S-VLAN interface, for example, the 1= st carrier is a provider network in accordance with IEEE 802.1ad, and the 2= nd carrier is a VPLS network. This kind of network scenario exists today. The use case you described is another scena= rio, where a carrier peers with another carrier. 

Further comments are inline.

=B7=A2=BC=FE=C8=CB: Daniel Cohn [DanielC@orckit.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA3=D4=C231=C8=D5 16:57
=B5=BD: Jiangyuanlong
Cc: l2vpn@ietf.org; Rafi Ram
=D6=F7=CC=E2: RE: S-VLAN access in E-Tree

Hi Yuanlong, please se= e inline with [DC].

 

=B7=A2=BC=FE=C8=CB= : Daniel Cohn [DanielC@orckit.com]
=B7= =A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA3=D4=C230=C8=D5 23:56
=B5= =BD: Jiangyuanlong
Cc: l2vpn@ietf.org; Rafi Ram
=D6= =F7=CC=E2: RE: S-VLAN access in E-Tree

Hi Yuanlong, thanks for your comments. Looking at = the scenario you describe - if the second carrier is just doing transparent= transport for the e-tree VPLS, from a scalability point of view it would make more sense to subtend the PW-VSIs directly between t= he e-tree-aware PEs, with the second carrier acting simply as PSN for these= PWs.

[JYL]  Actually we are talking about the use = case where carrier 1 attached to carrier 2 with a S-VLAN tagged AC. Your &n= bsp;use case is valid, but the service interface to carrier 2 is MPLS.

 

[DC] Interfacing between carriers using VLAN= handoff (SP interconnection on tagged AC) has the following drawbacks:

1. &nb= sp;    Service scalability =A8C each E-Tree se= rvice uses up two VLANs out of 4K VLAN range

2. &nb= sp;    VID coordination =A8C VLAN-ID X of carr= ier 1 may be already in use in carrier 2 network for different service

[JYL] If local VLAN mapping is supported, the above 2 problem seems trivial. Furthermore, VPLS can extend the scalability of th= e E-Tree with appropriate PE models.


3. &nb= sp;    End-to-end OAM =A8C Assuming the carrie= rs have MPLS network, VLAN handoff precludes the usage of MPLS end-to-end OAM tools  =

[JYL] As indicated above, the assumption of un= iform MPLS network does not apply here.

 

Also, actually I=A1=AFm not sure the scenario you = describe is a valid one. If the second carrier is not e-tree aware, the e-t= ree VPLS won't comply with the e-tree requirements as stated in http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-reqt-02 and http://tools.ietf.org/html/draft-key-l2vpn-etree-frwk-03, no matter wha= t solution is adopted.

[JYL] Since all leaf sites are connected to the 1s= t carrier, assume all its network PEs can support E-Tree, then the 2nd carr= ier does not need to be E-Tree aware. But as a whole, the E-Tree requirements are fulfilled.

 

[DC]  This assumption (=A1=B0all leaf sites are connected = to the 1st carrier) appears to conflict with =A1=B0Service = Provider Independence=A1=B1.<= span style=3D"font-size:11.0pt; font-family:"Times New Roman",&qu= ot;serif"; color:navy"> From L2VPN requirements :

 

 &nbs= p; Customers MAY require L2VPN service that spans multiple

 &nbs= p; administrative domains or SP networks.  Therefore, an L2VPN service=

 &nbs= p; MUST be able to span multiple AS and SP networks but still to act and

 &nbs= p; to appear as a single, homogeneous L2VPN from a customer point of=

 &nbs= p; view.

 

 &nbs= p; A customer might also start with an L2VPN provided in a single AS=

 &nbs= p; with a certain SLS but then ask for an expansion of the service

 &nbs= p; spanning multiple ASes and/or multiple-SPs.  In this case, as well = as

 &nbs= p; for all kinds of multi-AS and multiple-SP L2VPNs, L2VPN service

 &nbs= p; SHOULD be able to deliver the same SLS to all sites in a VPN

 &nbs= p; regardless of the AS/SP to which it homes.

 

 

Please note that adding VLAN tag for E-Tree functi= onality might be problematic to many implementations if the original frame = already contains S-TAG/C-TAG or B-TAG.

[JYL] As I said before, global VLAN provisioning, = VLAN mapping or transparently transport are all optional mechanisms for the= above use cases. After all, the typical VPLS PE consists of a bridge module and one or more VSIs, no matter what is used to indicat= e root/leaf in a PW (PW, control word, or VLAN, etc.), we still need an Eth= ernet mechanism to support E-Tree access and filtering in the bridge module= itself, IMHO, it should be based on IEEE standard rather than develop another wheel in our WG. Therefore, a= ll other solutions need the same VLAN based mechanism in the bridge module,= while introduce more complexities in the VSI forwarding plane at the same = time.

 

Daniel - not Rafi ;-)

[JYL] Wow, it's my fault! Thanks for your comments= and your kindness.

 

Regards

Yuanlong

 

 

 

From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Jiangyuanlong
Sent: Wednesday, March 30, 2011 12:00 PM
To: Rafi Ram
Cc: l2vpn@ietf.org
Subject: S-VLAN access in E-Tree

 

Rafi and all,

 

Yesterday we discussed the S-VLAN access of E-Tree during the WG meet= ing, in addition to S-VLAN mapping or B-VLAN method, a third option is also possible if it is a carrier over carrier network use case, = that is, the E-Tree traffic from the 1st carrier can be transparently trans= ported over the 2nd carrier's VPLS network, just as in the traditional VPLS= . This seems more practical as the E-Tree topology is usually only known to the 1st carrier while unavailable= to the 2nd carrier, furthermore, it requires no change on the 2nd carrier = network.

 

Best regards,

Yuanlong

 

--Boundary_(ID_vuW20AQe1sMZUS/VaVOTTg)-- From davarish@yahoo.com Thu Mar 31 07:34:35 2011 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 265D73A6A92 for ; Thu, 31 Mar 2011 07:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, REPTO_QUOTE_YAHOO=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 WGXxrNa84yoT for ; Thu, 31 Mar 2011 07:34:33 -0700 (PDT) Received: from nm22-vm0.bullet.mail.ac4.yahoo.com (nm22-vm0.bullet.mail.ac4.yahoo.com [98.139.53.218]) by core3.amsl.com (Postfix) with SMTP id 571223A6A27 for ; Thu, 31 Mar 2011 07:34:33 -0700 (PDT) Received: from [98.139.52.190] by nm22.bullet.mail.ac4.yahoo.com with NNFMP; 31 Mar 2011 14:36:10 -0000 Received: from [98.139.52.140] by tm3.bullet.mail.ac4.yahoo.com with NNFMP; 31 Mar 2011 14:36:10 -0000 Received: from [127.0.0.1] by omp1023.mail.ac4.yahoo.com with NNFMP; 31 Mar 2011 14:36:10 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 195855.27738.bm@omp1023.mail.ac4.yahoo.com Received: (qmail 13787 invoked by uid 60001); 31 Mar 2011 14:36:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1301582170; bh=wwSUpvJ8Vw9u2LLP3Vxg/7SpVCBS/H0FUHvXRgOEIao=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=VOHDSq8dwGXL9ItDk3ahI9xZVswEDT8EPNLo8FZPFsaExsiG8qIngRSY455bf6wsQWuAAzf4jIuYUGs9utqjI0JwV/MIdD+iZBFo8/dkjvl6akJobgr1icTPOVl3t9O36H9yU9I8LWnOjZ4u1lbjPKy1y5D5mbZq4xb8/yU7oXw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=KPXBl+PxWsFt51x2aUYolVpz0kamMZvAqvaV+oqnCxjFMTaEn21CeoVOd0Z+yXG2anYXGUw0gZ7lA1tKBwGn95dDdm5nMPE9KMfwIvAnR1kie5PwnBJZwNrI9tkrqCWcoIA4YBEA9/WuwMCu4XR8FL4Paapfe81DdLbEiLqECt4=; Message-ID: <43820.93614.qm@web88412.mail.re1.yahoo.com> X-YMail-OSG: FdePqcAVM1n4_PrF27W7n5U21Q3v8W6KDJXj0m9aZnrDToc dEHjIPlaPyfDFc_6kEA3ikkCkR.QmJjlQugRXztXq5zYSADhz8y8qgUYQ7xz sPpDZBuc9SnhQtfaBpPNPr40aU_n.6ApR1me1Qc2hjKhIRKDAm3NDHy.381V 0Gi8YDovZMSTyeGM2.8pCKDMdSLaZqr_bXEf8LF5y836DeiYnZ229D0sVp5b HBdTaisLqpLFS_6kggRPyypImsVV.xbo9Rkqj233cUj.foiaW8f3tBg9WtVZ QBcF7y8M7lEKRIhoM6aFuCF8oMsoxNdL6EQDjphwv12XE2cXrZTaxxKFGH7D j.ab6rh7RMn4CvX3vNFT9Ny0.6MTsdJ1zpCD.agdnkOTEm6j2Tw2ql_pmDz8 jYAb7z5HkSNoR Received: from [130.129.65.85] by web88412.mail.re1.yahoo.com via HTTP; Thu, 31 Mar 2011 07:36:09 PDT X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.109.295617 References: <3B0A1BED22CAD649A1B3E97BE5DDD68B0317B271@SZXEML514-MBS.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA0813069E165D@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B0317D663@SZXEML514-MBS.china.huawei.com> <45A67426326F814AAC27DBEC3FC7EEC203DC8461@tlvmail1> <44F4E579A764584EA9BDFD07D0CA0813069E1762@tlvmail1> Date: Thu, 31 Mar 2011 07:36:09 -0700 (PDT) From: "S. Davari" Subject: Re: S-VLAN access in E-Tree To: Daniel Cohn , Jiangyuanlong In-Reply-To: <44F4E579A764584EA9BDFD07D0CA0813069E1762@tlvmail1> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1083667167-1301582169=:93614" Cc: l2vpn@ietf.org, Rafi Ram X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "S. Davari" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 14:34:35 -0000 --0-1083667167-1301582169=:93614 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Daniel,=0A=0A=0A=0A=0A=0A________________________________=0AFrom: Daniel= Cohn =0ATo: Jiangyuanlong = =0ACc: l2vpn@ietf.org; Rafi Ram =0ASent: Thu, March 31, 2= 011 1:57:32 AM=0ASubject: RE: S-VLAN access in E-Tree=0A=0A=0AHi Yuanlong, = please see inline with [DC].=0A =0A=0A________________________________=0A= =0A=E5=8F=91=E4=BB=B6=E4=BA=BA:Daniel Cohn [DanielC@orckit.com]=0A=E5=8F=91= =E9=80=81=E6=97=B6=E9=97=B4:2011=E5=B9=B43=E6=9C=8830=E6=97=A523:56=0A=E5= =88=B0:Jiangyuanlong=0ACc: l2vpn@ietf.org; Rafi Ram=0A=E4=B8=BB=E9=A2=98:RE= : S-VLAN access in E-Tree=0AHi Yuanlong, thanks for your comments. Looking = at the scenario you describe - if =0Athe second carrier is just doing trans= parent transport for the e-tree VPLS, from =0Aa scalability point of view i= t would make more sense to subtend the PW-VSIs =0Adirectly between the e-tr= ee-aware PEs, with the second carrier acting simply as =0APSN for these PWs= .=0A[JYL] Actually we are talking about the use case where carrier 1 attac= hed to =0Acarrier 2 with a S-VLAN tagged AC. Your use case is valid, but t= he service =0Ainterface to carrier 2 is MPLS.=0A =0A[DC] Interfacing betwee= n carriers using VLAN handoff (SP interconnection on =0Atagged AC) has the = following drawbacks:=0A1. Service scalability =E2=80=93 each E-Tree se= rviceuses up two VLANsout of 4K VLAN =0Arange=0A2. VID coordination = =E2=80=93 VLAN-ID X of carrier 1 may be already in use in =0Acarrier 2 netw= ork for different service=0A3. End-to-end OAM =E2=80=93 Assuming the c= arriers have MPLS network, VLAN handoff =0Aprecludes the usage of MPLS end-= to-end OAM tools =0A=0A=0A=0A SD> Actually MEF is using SVLAN at the E-NNI.= I agree with the scalability =0Aissue. However the idea is to translate SV= LAN at the ENNI. The End-to End OAM =0Afor E-Tree service which is Ethernet= OAM works fine. The MPLS OAM is just =0Aprotecting the Transport and does = not need to be End-to-End. Each network can =0Ahave its own independent Tra= nsport OAM.=0A=0A=0AAlso, actually I=E2=80=99m not sure the scenario you de= scribe is a valid one. If the =0Asecond carrier is not e-tree aware, the e-= tree VPLS won't comply with the e-tree =0Arequirements as stated in =0Ahttp= ://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-reqt-02 and =0Ahttp://too= ls.ietf.org/html/draft-key-l2vpn-etree-frwk-03, no matter what =0Asolution = is adopted.=0A[JYL] Since all leaf sites are connected to the 1st carrier, = assume all its =0Anetwork PEs can support E-Tree, then the 2nd carrier does= not need to be E-Tree =0Aaware. But as a whole, the E-Tree requirements ar= e fulfilled.=0A =0A[DC] This assumption (=E2=80=9Call leaf sites are conne= cted to the 1st carrier) appears =0Ato conflict with =E2=80=9CService Provi= der Independence=E2=80=9D.From L2VPN requirements :=0A=0ASD> I agree. There= are 2 ways to do this. 1) Both networks can support E-Tree, =0Awhich then = we wont have a problem. 2) One network (network 2) does not support =0AE-Tr= ee. In this case that network 2 should just provide E-Line (VPWS) service = =0Afor customers and connect them to network 2. Network 2 PE box now should= do VFI =0Aswitching (requires Hairpin switching).=0A=0A =0A Customers MA= Y require L2VPN service that spans multiple=0A administrative domains or = SP networks. Therefore, an L2VPN service=0A MUST be able to span multipl= e AS and SP networks but still to act and=0A to appear as a single, homog= eneous L2VPN from a customer point of=0A view.=0A =0A A customer might = also start with an L2VPN provided in a single AS=0A with a certain SLS bu= t then ask for an expansion of the service=0A spanning multiple ASes and/= or multiple-SPs. In this case, as well as=0A for all kinds of multi-AS a= nd multiple-SP L2VPNs, L2VPN service=0A SHOULD be able to deliver the sam= e SLS to all sites in a VPN=0A regardless of the AS/SP to which it homes.= =0A =0A =0APlease note that adding VLAN tag for E-Tree functionality might = be problematic =0Ato many implementations if the original frame already con= tains S-TAG/C-TAG or =0AB-TAG.=0A[JYL] As I said before, global VLAN provis= ioning, VLAN mapping or transparently =0Atransport are all optional mechani= sms for the above use cases. After all, the =0Atypical VPLS PE consists of = a bridge module and one or more VSIs, no matter what =0Ais used to indicate= root/leaf in a PW (PW, control word, or VLAN, etc.), we =0Astill need an E= thernet mechanism to support E-Tree access and filtering in the =0Abridge m= odule itself, IMHO, it should be based on IEEE standard rather than =0Adeve= lop another wheel in our WG. Therefore, all other solutions need the same = =0AVLAN based mechanism in the bridge module, while introduce more complexi= ties in =0Athe VSI forwarding plane at the same time.=0A =0ADaniel - not Ra= fi ;-)=0A[JYL] Wow, it's my fault! Thanks for your comments and your kindne= ss.=0A =0ARegards=0AYuanlong=0A =0A =0A =0AFrom:l2vpn-bounces@ietf.org [mai= lto:l2vpn-bounces@ietf.org] On Behalf Of =0AJiangyuanlong=0ASent: Wednesday= , March 30, 2011 12:00 PM=0ATo: Rafi Ram=0ACc: l2vpn@ietf.org=0ASubject: S-= VLAN access in E-Tree=0A =0ARafi and all,=0A =0AYesterday we discussed the = S-VLAN access of E-Tree during the WG meeting, in =0Aaddition to S-VLAN map= ping or B-VLAN method, a third option is also possible if =0Ait is a carrie= r over carrier network use case, that is, the E-Tree traffic from =0Athe 1s= t carrier can be transparently transported over the 2nd carrier's VPLS =0An= etwork, just as in the traditional VPLS. This seems more practical as the = =0AE-Tree topology is usually only known to the 1st carrier while unavailab= le to =0Athe 2nd carrier, furthermore, it requires no change on the 2nd car= rier network.=0A =0ABest regards,=0AYuanlong=0A=0A --0-1083667167-1301582169=:93614 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Daniel,


To: Jiangyuanlong <jiangyuanlong@huaw= ei.com>
Cc: l2vpn@ie= tf.org; Rafi Ram <RafiR@orckit.com>
Sent: Thu, March 31, 2011 1:57:32 AM
Subject: RE: S-VLAN access in E-Tree
=

Hi Yuanlong, please see i= nline with [DC].

=  

=

=E5=8F=91=E4=BB=B6=E4=BA=BA:=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2011=E5=B9=B43=E6=9C=8830=E6=97=A5<= /span> 23:56
=E5=88=B0:= Jiangyuanlong
Cc: l2vpn@ietf.org; Rafi Ram
=E4=B8=BB=E9=A2=98: R= E: S-VLAN access in E-Tree

Hi Yuanlong, thanks for your comments. Looking at the scenario= you describe - if the second carrier is just doing transparent transport f= or the e-tree VPLS, from a scalability point of view it would make more sen= se to subtend the PW-VSIs directly between the e-tree-aware PEs, with the s= econd carrier acting simply as PSN for these PWs.

[JYL]  Actually we are talking about the use case = where carrier 1 attached to carrier 2 with a S-VLAN tagged AC. Your  use case is vali= d, but the service interface to carrier 2 is MPLS.

 

[D= C] Interfacing between carriers using VLAN handoff (SP interconnection on tagged AC) has the following drawb= acks:

1= .      Service scalability =E2=80= =93 each E-Tree service uses up two VLANs out of 4K VL= AN range

<= span style=3D"font-size: 11pt; font-family: "serif"; color: navy;= ">2.      VID coordination =E2=80=93= VLAN-ID X of carrier 1 may be already in use in carrier 2 network for diff= erent service

3.      End-to-end OAM = =E2=80=93 Assuming the carriers have MPLS network, VLAN handoff precludes the usage of MPLS end-to-end OAM tools
<= /span>


 SD> Actually MEF is using SVLAN at the E-NNI. I = agree with the scalability issue. However the idea is to translate SVLAN at= the ENNI. The End-to End OAM for E-Tree service which is Ethernet OAM work= s fine. The MPLS OAM is just protecting the Transport and does not need to = be End-to-End. Each network can have its own independent Transport OAM.


Also, act= ually I=E2=80=99m not sure the scenario you describe is a valid one. If the= second carrier is not e-tree aware, the e-tree VPLS won't comply with the e-tree requirement= s as stated in http://tools.ietf.org/html= /draft-key-l2vpn-vpls-etree-reqt-02 and ht= tp://tools.ietf.org/html/draft-key-l2vpn-etree-frwk-03, no matter what = solution is adopted.

[JYL] Sin= ce all leaf sites are connected to the 1st carrier, assume all its network = PEs can support E-Tree, then the 2nd carrier does not need to be E-Tree awa= re. But as a whole, the E-Tree requirements are fulfilled.

 

[DC]  This assumption (=E2= =80=9Call leaf sites are connected to the 1st carrier) appears to conflict with =E2=80=9CService Provider Independence=E2=80=9D. Fr= om L2VPN requirements :


= SD> I agree. There are 2 ways to do this. 1) Both networks can support E= -Tree, which then we wont have a problem. 2) One network (network 2) does not support E-Tree. In this case = that network 2 should just provide E-Line (VPWS) service for customers and = connect them to network 2. Network 2 PE box now should do VFI switching (re= quires Hairpin switching).

 

   Customers MAY require L2VPN service that = spans multiple

   administra= tive domains or SP networks.  Therefore, an L2VPN service

   MUST be able to span multiple AS and = SP networks but still to act and

 = ;  to appear as a single, homogeneous L2VPN from a customer point of

   view.

 

  = A customer might also start with an L2VPN provided in a single AS

   with a certain SLS but then ask f= or an expansion of the service

   spanning multipl= e ASes and/or multiple-SPs.  In this case, as well as

   for all kinds of multi-AS and multiple-SP= L2VPNs, L2VPN service

   SH= OULD be able to deliver the same SLS to all sites in a VPN

   regardless of the AS/SP to which it homes= .

 

 

Please note that adding VLAN tag for E-Tre= e functionality might be problematic to many implementations if the origina= l frame already contains S-TAG/C-TAG or B-TAG.

[JYL] As I said before, global VLAN provisioning, VLAN map= ping or transparently transport are all optional mechanisms for the above u= se cases. After all, the typical VPLS PE consists of a bridge module and on= e or more VSIs, no matter what is used to indicate root/leaf in a PW (PW, c= ontrol word, or VLAN, etc.), we still need an Ethernet mechanism to support= E-Tree access and filtering in the bridge module itself, IMHO, it should b= e based on IEEE standard rather than develop another wheel in our WG. There= fore, all other solutions need the same VLAN based mechanism in the bridge module, while introduce more complexities in the VSI forwarding plane at t= he same time.

 

Daniel - not Rafi ;-)

[JYL] Wow, it's my fault! Thanks for your comme= nts and your kindness.

 

Regards

Yuanlong

 

 

&n= bsp;

From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces= @ietf.org] On Behalf Of Jiangyuanlong
Sent: Wednesday, Mar= ch 30, 2011 12:00 PM
To: Rafi Ram
Cc: l2vpn@ietf.org
Subject: S-VLAN access in E-Tree

=

 

Rafi and all,

 

<= div>

Yest= erday we discussed the S-VLAN access of E-Tree during the WG meeting, in ad= dition to S-VLAN mapping or B-VLAN method, a third option is also poss= ible if it is a carrier over carrier network use case, that is, the E-Tree = traffic from the 1st carrier can be transparently transported over the 2nd = carrier's VPLS network, just as in the traditional VPLS. This seems more practical a= s the E-Tree topology is usually only known to the 1st carrier while unavai= lable to the 2nd carrier, furthermore, it requires no change on the 2nd car= rier network.

&= nbsp;

Best regards,

Yuanlong=

 

=0A

--0-1083667167-1301582169=:93614-- From bschlies@cisco.com Thu Mar 31 07:35:47 2011 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 6E7333A6B4A for ; Thu, 31 Mar 2011 07:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.664 X-Spam-Level: X-Spam-Status: No, score=-9.664 tagged_above=-999 required=5 tests=[AWL=-0.625, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_MLB_Stock6=1.56] 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 7qqVj16cW63o for ; Thu, 31 Mar 2011 07:35:45 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id D887B3A6B49 for ; Thu, 31 Mar 2011 07:35:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=9056; q=dns/txt; s=iport; t=1301582245; x=1302791845; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=uhWettSiXn0ljS6HvUZjAtr7WDEzoK5L7sHEgNon84M=; b=UvjoR4y9UNuW1Wged21JJ+FLQM6ncP2WcbaiwmKx15z3jaLJ7dXuqmSp Q/OgLWd8eUmu/ds583caBdP2OUCbKqfp58LrR03rEfyzjSz+mJJVOdcPE H82C6/vlhXBkruaPb+7yCzXvbIosLz3GNVTez9nhQTUuGzei0P5leEA/6 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADORlE2tJV2b/2dsb2JhbAClTXeIeZoOnBOCfYJuBIVBh1CDW4Mp X-IronPort-AV: E=Sophos;i="4.63,275,1299456000"; d="scan'208";a="328228344" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by sj-iport-2.cisco.com with ESMTP; 31 Mar 2011 14:37:25 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2VEbPHl020571; Thu, 31 Mar 2011 14:37:25 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 31 Mar 2011 09:37:25 -0500 Received: from 10.55.91.240 ([10.55.91.240]) by XMB-RCD-206.cisco.com ([72.163.62.213]) via Exchange Front-End Server email.cisco.com ([144.254.231.96]) with Microsoft Exchange Server HTTP-DAV ; Thu, 31 Mar 2011 14:37:24 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Thu, 31 Mar 2011 09:37:25 -0500 Subject: Re: Draft of new L2VPN WG Charter From: Benson Schliesser To: Giles Heron , Message-ID: Thread-Topic: Draft of new L2VPN WG Charter Thread-Index: Acvlk6mvByfCCAJ7pEaQouOVm51qugABaMGqAoX2iAk= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 31 Mar 2011 14:37:25.0165 (UTC) FILETIME=[26EF2DD0:01CBEFB1] 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, 31 Mar 2011 14:35:47 -0000 Hi, Giles. I have a clarifying question about the first paragraph: What is the purpos= e of the 2nd sentence, bringing cloud and DC requirements into the mix? Assuming this is meant to include non-provider L2VPN environments (like enterprise data centers), then why not just remove the phrase "provider-provisioned" from the first sentence? Otherwise, it seems redundant. This is a real question, not a suggestion at this time. Thanks, -Benson On 3/18/11 1:21 PM, "Giles Heron" wrote: > OK - looks like the attachment didn't come through as intended. My > apologies. >=20 > Text inline: >=20 > ---------------- >=20 > The L2VPN working group is responsible for defining and specifying a > limited number of solutions for supporting provider-provisioned Layer-2 > Virtual Private Networks (L2VPNs). It will also address requirements driv= en > by cloud computing services and data centers as they apply to Layer-2 > VPN services. >=20 > Layer-2 VPNs defined by L2VPN operate over pseudowires (PWs) as > defined by the PWE3 WG or over MPLS PSN tunnels. A L2VPN emulates a > "native" service over a PSN that is adequately faithful to, but may not > be entirely indistinguishable from the native service itself. Further, > following in the "edge-to-edge" nature of the service, the L2VPN WG will > not define any mechanisms which exert control over the underlying PSN. > When necessary it may, however, recommend or require the use of existing > PSN QoS and path control mechanisms between the PEs which provide the > L2VPN connectivity. >=20 > Layer-2 VPNs comprise the following: >=20 > 1. Virtual Private LAN Service (VPLS) -- A Layer-2 service that emulates > a switched Ethernet (V)LAN across an MPLS Packet Switched Network (PSN). >=20 > 2. Virtual Private Wire Service (VPWS) -- A Layer-2 service that > provides point-to-point connectivity for a variety of link layers, > including Frame Relay, ATM, Ethernet, PPP, etc., across an MPLS PSN. >=20 > 3. Virtual Private Multicast Service (VPMS) -- A Layer-2 service that > provides point-to-multipoint connectivity for a variety of link > layers across an MPLS PSN. >=20 > 4. IP-only L2VPN =AD An IP-only service over an MPLS PSN. The WG will > address two specific types of IP-only L2VPN: >=20 > a) Point-to-point Layer-2 VPN. This service is similar to VPWS, but also > supports heterogenous Attachment Circuits at either end of a single > point-to-point service. >=20 > b) Multipoint-to-multipoint Layer-2 VPN. This service is similar to VPLS= , > but learns IP and MAC address bindings from ARPs and broadcast/multicast > IP packets. >=20 > 5. Ethernet VPN (E-VPN) - A Layer-2 technology that emulates an > Ethernet (V)LAN across an MPLS PSN. E-VPN supports load-sharing across > multiple connections from a Layer-2 site to an L2VPN service, and also > supports control plane distribution of MAC addresses and IP to MAC addres= s > bindings in the VPN. E-VPN is primarily targeted to support large-scale > L2VPNs with resiliency requirements not satisfied by other L2VPN solution= s. >=20 > 6. E-Tree =AD a Layer-2 technology defined by the MEF, which provides > connectivity between one or more =B3root=B2 nodes and one or more > =B3leaf=B2 nodes, with the restriction that leaves may only communicate > with roots (and not with each other). >=20 > L2VPNs will make use of existing IETF specified mechanisms unless there > are technical reasons why the existing mechanisms are insufficient or > unnecessary. >=20 > The L2VPN WG is responsible for specification of the discovery and > membership of PEs participating in a Layer-2 VPN as well as the > membership of CE devices for a specific instance of an L2VPN. >=20 > The L2VPN WG will provide extensions of existing protocols that will be > discussed in protocol-specific WGs. In particular, the L2VPN WG > may define extensions to pseudowire management mechanisms for VPLS. > Those extensions will be reviewed by the PWE3 WG to ensure they are > aligned with the overall design/architecture of PWE3. >=20 > The L2VPN WG will not define new encapsulations, control, or resiliency > mechanisms specifically related to pseudowires. Furthermore, when the > L2VPN solution is based on PWs, the L2VPN WG will not define protocol > inter-working between an L2VPN and native service Layer-2 OAM or > resiliency mechanisms. The L2VPN WG may define how to operate native > service-layer control, OAM or resiliency mechanisms on top of an L2VPN. > In addition, it may define native data plane and/or control plane > interworking between an L2VPN and an associated native Layer-2 service. >=20 > The L2VPN WG scope includes the following: >=20 > 1. Discovery of PEs participating in a Layer-2 VPN and the associated > topology required for connectivity of the VPLS, VPWS, VPMS or E-VPN > service. >=20 > 2. Signaling of information related to the discovery and membership of > PEs within a L2VPN. These procedures must use PWE3 control and > management procedures, or define requirements for extensions of PWE3 > protocols to suit the needs of an L2VPN, when the L2VPN operates over > PWs. Once those requirements have been reviewed by the L2VPN WG, they > should be provided to the PWE3 WG to derive solutions. >=20 > 3. MIBs for Layer-2 VPN solutions. >=20 > 4. Specification of requirements, framework and solutions that > facilitate Operations Administration and Management (OAM) of any type of > L2VPN. >=20 > 5. Mechanisms to permit optimization of multicast data traffic within > an L2VPN. >=20 > 6. If transport does not involve PWs, mechanisms that support > load-balancing/multipathing between PEs interconnecting a Layer-2 > service using an L2VPN across the MPLS PSN. >=20 > 7. requirements for the multi-homing of CEs to several VPLS or > E-VPN PEs, inclusive of active/backup and active/active (load-sharing) > configurations. Based on these requirements define VPLS or E-VPN control > plane solutions for achieving fast convergence after failure of an active > path in the PSN or on the AC side. >=20 > 8. Enhancements to increase the scalability of the Control Plane and > Data Plane of L2VPN PE nodes, and of core nodes that provide transport > services for L2VPN. >=20 > 9. Requirements and solutions for Auto-Discovery and Signaling of > Inter-AS L2VPNs, in addition to Inter-AS solutions for multicast-optimize= d > L2VPNs. >=20 > 10. Requirements and solutions for supporting "E-Tree" services using > VPLS.=20 >=20 > 11. Extensions to L2VPN protocols and RFCs necessary to create an MPLS > Transport Profile (MPLS-TP). The work on the MPLS TP will be coordinated > between four primary working groups (MPLS, PWE3, L2VPN and CCAMP) that ar= e > chartered to do MPLS TP work. >=20 > Milestones: >=20 > Done Submit an I-D describing MIB for VPLS > Done Submit an I-D describing MIB for VPWS > Done Submit an I-D on OAM requirements for VPLS > Done Submit an I-D on OAM requirements for VPWS > Done Submit L2 requirements to IESG for publication as Information= al > RFC > Done Submit L2 framework to IESG for publication as Informational = RFC > Done Identify VPLS and VPWS solutions for the WG > Done Submit VPLS solution documents to IESG > Done Submit VPWS solution documents to IESG > Done Submit Auto-Discovery and Signaling for Intra-AS and Inter-AS > VPLS and VPWS Layer-2 VPNs > Jul 2011 Submit IP-only L2VPN solution documents to IESG > Jul 2011 Submit OAM solutions for VPWS to IESG > Jul 2011 Submit OAM solutions for VPLS to IESG > Jul 2011 Submit signaling solution for multicast-optimized VPLS to IES= G > Jul 2011 Submit I-D on Virtual Private Multicast Service (VPMS) > requirements to IESG > Jul 2011 Submit MIB for VPLS to IESG > Jul 2011 Submit MIB for VPWS to IESG > Nov 2011 Submit scalability solutions for VPLS Data-Plane to IESG > Nov 2011 Submit scalability solutions for VPLS Control-Plane to IESG > Mar 2012 Submit MIB for IP-only L2VPN to IESG > Mar 2012 Submit OAM solutions for IP-only L2VPN to IESG > Mar 2012 Submit Auto-Discovery solution for VPMS to IESG > Mar 2012 Submit VPLS service convergence improvement solutions to IESG > Mar 2012 Submit VPLS multi-homing solutions to IESG > Mar 2012 Submit E-Tree documents to IESG > Mar 2012 Submit E-VPN requirements/framework to IESG > Jul 2012 Submit E-VPN solution to IESG > Nov 2012 Submit E-VPN MIB/OAM to IESG >=20 > ----------------- >=20 > On 18/03/2011 17:41, "Giles Heron" wrote: >=20 >> We plan to re-charter the L2VPN WG - primarily to bring E-VPN and E-Tree >> in-scope. >>=20 >> Please find attached a draft charter for discussion both on this list an= d at >> IETF 80 in Prague. >>=20 >> Nabil and Giles >>=20 >>=20 >=20 >=20 From giles.heron@gmail.com Thu Mar 31 07:47:52 2011 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 684C43A6B49 for ; Thu, 31 Mar 2011 07:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=-0.520, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MLB_Stock6=1.56] 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 xYOdxwg2m4zZ for ; Thu, 31 Mar 2011 07:47:51 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id C552A3A6B38 for ; Thu, 31 Mar 2011 07:47:50 -0700 (PDT) Received: by wyb29 with SMTP id 29so2353736wyb.31 for ; Thu, 31 Mar 2011 07:49:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:user-agent:date:subject:from:to:message-id :thread-topic:thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=h3JDWsNlW9OSTnTj7nYAAQI8jbpjf/gAlItv3OdL03E=; b=m2dEqe1OILjIfvbSjcrWxRePobUmLtBHBKNO9m48WCVzU9Rwyts7cwNXX+ZJco/N20 yjB0X5h+04NXIx+XoakD8QmZ6bAt17mACW0Nug0qGf4WqYVX561bLbqCrTeIX/q/Hvsf UzVhgtOLz4yiVstOhVDM57Eqt8LMn9qQaTh6E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=QYeJ0lZYFnqAgxSSnuXUrmytUP1iTmseGbZOjWxbSzql1/ffaPRVj+F+2Cngn2LvpR JxSsU2PiGL9ECaqgtS4WKsmQEpeK6kzVCvXhyrSnvRLFqiGGOrw3piqR92sgtDCBLRIF FqigbJhT1uVExZ7UsoPR2qEEUinCR8sW5YSDI= Received: by 10.227.139.89 with SMTP id d25mr2493343wbu.58.1301582968152; Thu, 31 Mar 2011 07:49:28 -0700 (PDT) Received: from [10.61.106.177] (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id z13sm697305wbd.12.2011.03.31.07.49.21 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 31 Mar 2011 07:49:27 -0700 (PDT) User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Thu, 31 Mar 2011 15:49:51 +0100 Subject: Re: Draft of new L2VPN WG Charter From: Giles Heron To: Benson Schliesser , Message-ID: Thread-Topic: Draft of new L2VPN WG Charter Thread-Index: Acvlk6mvByfCCAJ7pEaQouOVm51qugABaMGqAoX2iAkAAG8q8w== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable 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, 31 Mar 2011 14:47:52 -0000 Hi Benson, This would be provider-provisioned L2VPN environments (whether data-centre interconnect, or scaling of a large multi-tenant data-centre). Personally I'm not sure we need the sentence there, but others were keen to mention the data-centre requirements. =20 Giles On 31/03/2011 15:37, "Benson Schliesser" wrote: > Hi, Giles. >=20 > I have a clarifying question about the first paragraph: What is the purp= ose > of the 2nd sentence, bringing cloud and DC requirements into the mix? > Assuming this is meant to include non-provider L2VPN environments (like > enterprise data centers), then why not just remove the phrase > "provider-provisioned" from the first sentence? Otherwise, it seems > redundant. >=20 > This is a real question, not a suggestion at this time. >=20 > Thanks, > -Benson >=20 >=20 >=20 > On 3/18/11 1:21 PM, "Giles Heron" wrote: >=20 >> OK - looks like the attachment didn't come through as intended. My >> apologies. >>=20 >> Text inline: >>=20 >> ---------------- >>=20 >> The L2VPN working group is responsible for defining and specifying a >> limited number of solutions for supporting provider-provisioned Layer-2 >> Virtual Private Networks (L2VPNs). It will also address requirements dri= ven >> by cloud computing services and data centers as they apply to Layer-2 >> VPN services. >>=20 >> Layer-2 VPNs defined by L2VPN operate over pseudowires (PWs) as >> defined by the PWE3 WG or over MPLS PSN tunnels. A L2VPN emulates a >> "native" service over a PSN that is adequately faithful to, but may not >> be entirely indistinguishable from the native service itself. Further, >> following in the "edge-to-edge" nature of the service, the L2VPN WG wil= l >> not define any mechanisms which exert control over the underlying PSN. >> When necessary it may, however, recommend or require the use of existing >> PSN QoS and path control mechanisms between the PEs which provide the >> L2VPN connectivity. >>=20 >> Layer-2 VPNs comprise the following: >>=20 >> 1. Virtual Private LAN Service (VPLS) -- A Layer-2 service that emulates >> a switched Ethernet (V)LAN across an MPLS Packet Switched Network (PSN). >>=20 >> 2. Virtual Private Wire Service (VPWS) -- A Layer-2 service that >> provides point-to-point connectivity for a variety of link layers, >> including Frame Relay, ATM, Ethernet, PPP, etc., across an MPLS PSN. >>=20 >> 3. Virtual Private Multicast Service (VPMS) -- A Layer-2 service that >> provides point-to-multipoint connectivity for a variety of link >> layers across an MPLS PSN. >>=20 >> 4. IP-only L2VPN =AD An IP-only service over an MPLS PSN. The WG will >> address two specific types of IP-only L2VPN: >>=20 >> a) Point-to-point Layer-2 VPN. This service is similar to VPWS, but als= o >> supports heterogenous Attachment Circuits at either end of a single >> point-to-point service. >>=20 >> b) Multipoint-to-multipoint Layer-2 VPN. This service is similar to VPL= S, >> but learns IP and MAC address bindings from ARPs and broadcast/multicast >> IP packets. >>=20 >> 5. Ethernet VPN (E-VPN) - A Layer-2 technology that emulates an >> Ethernet (V)LAN across an MPLS PSN. E-VPN supports load-sharing across >> multiple connections from a Layer-2 site to an L2VPN service, and also >> supports control plane distribution of MAC addresses and IP to MAC addre= ss >> bindings in the VPN. E-VPN is primarily targeted to support large-scale >> L2VPNs with resiliency requirements not satisfied by other L2VPN solutio= ns. >>=20 >> 6. E-Tree =AD a Layer-2 technology defined by the MEF, which provides >> connectivity between one or more =B3root=B2 nodes and one or more >> =B3leaf=B2 nodes, with the restriction that leaves may only communicate >> with roots (and not with each other). >>=20 >> L2VPNs will make use of existing IETF specified mechanisms unless there >> are technical reasons why the existing mechanisms are insufficient or >> unnecessary. >>=20 >> The L2VPN WG is responsible for specification of the discovery and >> membership of PEs participating in a Layer-2 VPN as well as the >> membership of CE devices for a specific instance of an L2VPN. >>=20 >> The L2VPN WG will provide extensions of existing protocols that will be >> discussed in protocol-specific WGs. In particular, the L2VPN WG >> may define extensions to pseudowire management mechanisms for VPLS. >> Those extensions will be reviewed by the PWE3 WG to ensure they are >> aligned with the overall design/architecture of PWE3. >>=20 >> The L2VPN WG will not define new encapsulations, control, or resiliency >> mechanisms specifically related to pseudowires. Furthermore, when the >> L2VPN solution is based on PWs, the L2VPN WG will not define protocol >> inter-working between an L2VPN and native service Layer-2 OAM or >> resiliency mechanisms. The L2VPN WG may define how to operate native >> service-layer control, OAM or resiliency mechanisms on top of an L2VPN. >> In addition, it may define native data plane and/or control plane >> interworking between an L2VPN and an associated native Layer-2 service. >>=20 >> The L2VPN WG scope includes the following: >>=20 >> 1. Discovery of PEs participating in a Layer-2 VPN and the associated >> topology required for connectivity of the VPLS, VPWS, VPMS or E-VPN >> service. >>=20 >> 2. Signaling of information related to the discovery and membership of >> PEs within a L2VPN. These procedures must use PWE3 control and >> management procedures, or define requirements for extensions of PWE3 >> protocols to suit the needs of an L2VPN, when the L2VPN operates over >> PWs. Once those requirements have been reviewed by the L2VPN WG, they >> should be provided to the PWE3 WG to derive solutions. >>=20 >> 3. MIBs for Layer-2 VPN solutions. >>=20 >> 4. Specification of requirements, framework and solutions that >> facilitate Operations Administration and Management (OAM) of any type of >> L2VPN. >>=20 >> 5. Mechanisms to permit optimization of multicast data traffic within >> an L2VPN. >>=20 >> 6. If transport does not involve PWs, mechanisms that support >> load-balancing/multipathing between PEs interconnecting a Layer-2 >> service using an L2VPN across the MPLS PSN. >>=20 >> 7. requirements for the multi-homing of CEs to several VPLS or >> E-VPN PEs, inclusive of active/backup and active/active (load-sharing) >> configurations. Based on these requirements define VPLS or E-VPN control >> plane solutions for achieving fast convergence after failure of an activ= e >> path in the PSN or on the AC side. >>=20 >> 8. Enhancements to increase the scalability of the Control Plane and >> Data Plane of L2VPN PE nodes, and of core nodes that provide transport >> services for L2VPN. >>=20 >> 9. Requirements and solutions for Auto-Discovery and Signaling of >> Inter-AS L2VPNs, in addition to Inter-AS solutions for multicast-optimiz= ed >> L2VPNs. >>=20 >> 10. Requirements and solutions for supporting "E-Tree" services using >> VPLS.=20 >>=20 >> 11. Extensions to L2VPN protocols and RFCs necessary to create an MPLS >> Transport Profile (MPLS-TP). The work on the MPLS TP will be coordinated >> between four primary working groups (MPLS, PWE3, L2VPN and CCAMP) that a= re >> chartered to do MPLS TP work. >>=20 >> Milestones: >>=20 >> Done Submit an I-D describing MIB for VPLS >> Done Submit an I-D describing MIB for VPWS >> Done Submit an I-D on OAM requirements for VPLS >> Done Submit an I-D on OAM requirements for VPWS >> Done Submit L2 requirements to IESG for publication as Informatio= nal >> RFC >> Done Submit L2 framework to IESG for publication as Informational= RFC >> Done Identify VPLS and VPWS solutions for the WG >> Done Submit VPLS solution documents to IESG >> Done Submit VPWS solution documents to IESG >> Done Submit Auto-Discovery and Signaling for Intra-AS and Inter-A= S >> VPLS and VPWS Layer-2 VPNs >> Jul 2011 Submit IP-only L2VPN solution documents to IESG >> Jul 2011 Submit OAM solutions for VPWS to IESG >> Jul 2011 Submit OAM solutions for VPLS to IESG >> Jul 2011 Submit signaling solution for multicast-optimized VPLS to IE= SG >> Jul 2011 Submit I-D on Virtual Private Multicast Service (VPMS) >> requirements to IESG >> Jul 2011 Submit MIB for VPLS to IESG >> Jul 2011 Submit MIB for VPWS to IESG >> Nov 2011 Submit scalability solutions for VPLS Data-Plane to IESG >> Nov 2011 Submit scalability solutions for VPLS Control-Plane to IESG >> Mar 2012 Submit MIB for IP-only L2VPN to IESG >> Mar 2012 Submit OAM solutions for IP-only L2VPN to IESG >> Mar 2012 Submit Auto-Discovery solution for VPMS to IESG >> Mar 2012 Submit VPLS service convergence improvement solutions to IES= G >> Mar 2012 Submit VPLS multi-homing solutions to IESG >> Mar 2012 Submit E-Tree documents to IESG >> Mar 2012 Submit E-VPN requirements/framework to IESG >> Jul 2012 Submit E-VPN solution to IESG >> Nov 2012 Submit E-VPN MIB/OAM to IESG >>=20 >> ----------------- >>=20 >> On 18/03/2011 17:41, "Giles Heron" wrote: >>=20 >>> We plan to re-charter the L2VPN WG - primarily to bring E-VPN and E-Tre= e >>> in-scope. >>>=20 >>> Please find attached a draft charter for discussion both on this list a= nd at >>> IETF 80 in Prague. >>>=20 >>> Nabil and Giles >>>=20 >>>=20 >>=20 >>=20 >=20 From prvs=7071a0f4f3=hshah@ciena.com Thu Mar 31 07:56:04 2011 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 6FD2A28C133 for ; Thu, 31 Mar 2011 07:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.704 X-Spam-Level: X-Spam-Status: No, score=-0.704 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SARE_MLB_Stock6=1.56] 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 Q+3BkXhty2zg for ; Thu, 31 Mar 2011 07:56:02 -0700 (PDT) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) by core3.amsl.com (Postfix) with ESMTP id 66FBA28C12B for ; Thu, 31 Mar 2011 07:56:02 -0700 (PDT) Received: from pps.filterd (m0001124 [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.14.3/8.14.3) with SMTP id p2VEuq5B027505; Thu, 31 Mar 2011 10:57:36 -0400 Received: from mdwexght01.ciena.com (LIN1-118-36-28.ciena.com [63.118.36.28]) by mx0b-00103a01.pphosted.com with ESMTP id vcnpch457-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 31 Mar 2011 10:57:35 -0400 Received: from mdmxm05.ciena.com (63.118.39.23) by MDWEXGHT01.ciena.com (10.4.140.138) with Microsoft SMTP Server id 8.1.436.0; Thu, 31 Mar 2011 10:57:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBEFB3.D86596BE" Subject: RE: Draft of new L2VPN WG Charter Date: Thu, 31 Mar 2011 10:52:46 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft of new L2VPN WG Charter Thread-Index: Acvlk6mvByfCCAJ7pEaQouOVm51qugABaMGqAoX2iAkAAIlixA== References: From: "Shah, Himanshu" To: "Benson Schliesser" , "Giles Heron" , X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-03-31_05:2011-03-31, 2011-03-31, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1103310063 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, 31 Mar 2011 14:56:04 -0000 ------_=_NextPart_001_01CBEFB3.D86596BE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Another point for item 5 - "and also supports control plane distribution of MAC addresses=20 and IP to MAC address bindings in the VPN." Well, Item 4 also supports control plane distribution of MAC addresses and IP to MAC address bindings in the VPN. I do not support having this explicit phrase in the item 5. What is the justification? It is not a new concept. /himanshu =20 -----Original Message----- From: l2vpn-bounces@ietf.org on behalf of Benson Schliesser Sent: Thu 3/31/2011 10:37 AM To: Giles Heron; l2vpn@ietf.org Subject: Re: Draft of new L2VPN WG Charter =20 Hi, Giles. I have a clarifying question about the first paragraph: What is the = purpose of the 2nd sentence, bringing cloud and DC requirements into the mix? Assuming this is meant to include non-provider L2VPN environments (like enterprise data centers), then why not just remove the phrase "provider-provisioned" from the first sentence? Otherwise, it seems redundant. This is a real question, not a suggestion at this time. Thanks, -Benson On 3/18/11 1:21 PM, "Giles Heron" wrote: > OK - looks like the attachment didn't come through as intended. My > apologies. >=20 > Text inline: >=20 > ---------------- >=20 > The L2VPN working group is responsible for defining and specifying a > limited number of solutions for supporting provider-provisioned = Layer-2 > Virtual Private Networks (L2VPNs). It will also address requirements = driven > by cloud computing services and data centers as they apply to Layer-2 > VPN services. >=20 > Layer-2 VPNs defined by L2VPN operate over pseudowires (PWs) as > defined by the PWE3 WG or over MPLS PSN tunnels. A L2VPN emulates a > "native" service over a PSN that is adequately faithful to, but may = not > be entirely indistinguishable from the native service itself. Further, > following in the "edge-to-edge" nature of the service, the L2VPN WG = will > not define any mechanisms which exert control over the underlying PSN. > When necessary it may, however, recommend or require the use of = existing > PSN QoS and path control mechanisms between the PEs which provide the > L2VPN connectivity. >=20 > Layer-2 VPNs comprise the following: >=20 > 1. Virtual Private LAN Service (VPLS) -- A Layer-2 service that = emulates > a switched Ethernet (V)LAN across an MPLS Packet Switched Network = (PSN). >=20 > 2. Virtual Private Wire Service (VPWS) -- A Layer-2 service that > provides point-to-point connectivity for a variety of link layers, > including Frame Relay, ATM, Ethernet, PPP, etc., across an MPLS PSN. >=20 > 3. Virtual Private Multicast Service (VPMS) -- A Layer-2 service that > provides point-to-multipoint connectivity for a variety of link > layers across an MPLS PSN. >=20 > 4. IP-only L2VPN =AD An IP-only service over an MPLS PSN. The WG will > address two specific types of IP-only L2VPN: >=20 > a) Point-to-point Layer-2 VPN. This service is similar to VPWS, but = also > supports heterogenous Attachment Circuits at either end of a single > point-to-point service. >=20 > b) Multipoint-to-multipoint Layer-2 VPN. This service is similar to = VPLS, > but learns IP and MAC address bindings from ARPs and = broadcast/multicast > IP packets. >=20 > 5. Ethernet VPN (E-VPN) - A Layer-2 technology that emulates an > Ethernet (V)LAN across an MPLS PSN. E-VPN supports load-sharing across > multiple connections from a Layer-2 site to an L2VPN service, and also > supports control plane distribution of MAC addresses and IP to MAC = address > bindings in the VPN. E-VPN is primarily targeted to support = large-scale > L2VPNs with resiliency requirements not satisfied by other L2VPN = solutions. >=20 > 6. E-Tree =AD a Layer-2 technology defined by the MEF, which provides > connectivity between one or more =B3root=B2 nodes and one or more > =B3leaf=B2 nodes, with the restriction that leaves may only = communicate > with roots (and not with each other). >=20 > L2VPNs will make use of existing IETF specified mechanisms unless = there > are technical reasons why the existing mechanisms are insufficient or > unnecessary. >=20 > The L2VPN WG is responsible for specification of the discovery and > membership of PEs participating in a Layer-2 VPN as well as the > membership of CE devices for a specific instance of an L2VPN. >=20 > The L2VPN WG will provide extensions of existing protocols that will = be > discussed in protocol-specific WGs. In particular, the L2VPN WG > may define extensions to pseudowire management mechanisms for VPLS. > Those extensions will be reviewed by the PWE3 WG to ensure they are > aligned with the overall design/architecture of PWE3. >=20 > The L2VPN WG will not define new encapsulations, control, or = resiliency > mechanisms specifically related to pseudowires. Furthermore, when the > L2VPN solution is based on PWs, the L2VPN WG will not define protocol > inter-working between an L2VPN and native service Layer-2 OAM or > resiliency mechanisms. The L2VPN WG may define how to operate native > service-layer control, OAM or resiliency mechanisms on top of an = L2VPN. > In addition, it may define native data plane and/or control plane > interworking between an L2VPN and an associated native Layer-2 = service. >=20 > The L2VPN WG scope includes the following: >=20 > 1. Discovery of PEs participating in a Layer-2 VPN and the associated > topology required for connectivity of the VPLS, VPWS, VPMS or E-VPN > service. >=20 > 2. Signaling of information related to the discovery and membership of > PEs within a L2VPN. These procedures must use PWE3 control and > management procedures, or define requirements for extensions of PWE3 > protocols to suit the needs of an L2VPN, when the L2VPN operates over > PWs. Once those requirements have been reviewed by the L2VPN WG, they > should be provided to the PWE3 WG to derive solutions. >=20 > 3. MIBs for Layer-2 VPN solutions. >=20 > 4. Specification of requirements, framework and solutions that > facilitate Operations Administration and Management (OAM) of any type = of > L2VPN. >=20 > 5. Mechanisms to permit optimization of multicast data traffic within > an L2VPN. >=20 > 6. If transport does not involve PWs, mechanisms that support > load-balancing/multipathing between PEs interconnecting a Layer-2 > service using an L2VPN across the MPLS PSN. >=20 > 7. requirements for the multi-homing of CEs to several VPLS or > E-VPN PEs, inclusive of active/backup and active/active (load-sharing) > configurations. Based on these requirements define VPLS or E-VPN = control > plane solutions for achieving fast convergence after failure of an = active > path in the PSN or on the AC side. >=20 > 8. Enhancements to increase the scalability of the Control Plane and > Data Plane of L2VPN PE nodes, and of core nodes that provide transport > services for L2VPN. >=20 > 9. Requirements and solutions for Auto-Discovery and Signaling of > Inter-AS L2VPNs, in addition to Inter-AS solutions for = multicast-optimized > L2VPNs. >=20 > 10. Requirements and solutions for supporting "E-Tree" services using > VPLS.=20 >=20 > 11. Extensions to L2VPN protocols and RFCs necessary to create an MPLS > Transport Profile (MPLS-TP). The work on the MPLS TP will be = coordinated > between four primary working groups (MPLS, PWE3, L2VPN and CCAMP) that = are > chartered to do MPLS TP work. >=20 > Milestones: >=20 > Done Submit an I-D describing MIB for VPLS > Done Submit an I-D describing MIB for VPWS > Done Submit an I-D on OAM requirements for VPLS > Done Submit an I-D on OAM requirements for VPWS > Done Submit L2 requirements to IESG for publication as = Informational > RFC > Done Submit L2 framework to IESG for publication as = Informational RFC > Done Identify VPLS and VPWS solutions for the WG > Done Submit VPLS solution documents to IESG > Done Submit VPWS solution documents to IESG > Done Submit Auto-Discovery and Signaling for Intra-AS and = Inter-AS > VPLS and VPWS Layer-2 VPNs > Jul 2011 Submit IP-only L2VPN solution documents to IESG > Jul 2011 Submit OAM solutions for VPWS to IESG > Jul 2011 Submit OAM solutions for VPLS to IESG > Jul 2011 Submit signaling solution for multicast-optimized VPLS to = IESG > Jul 2011 Submit I-D on Virtual Private Multicast Service (VPMS) > requirements to IESG > Jul 2011 Submit MIB for VPLS to IESG > Jul 2011 Submit MIB for VPWS to IESG > Nov 2011 Submit scalability solutions for VPLS Data-Plane to IESG > Nov 2011 Submit scalability solutions for VPLS Control-Plane to = IESG > Mar 2012 Submit MIB for IP-only L2VPN to IESG > Mar 2012 Submit OAM solutions for IP-only L2VPN to IESG > Mar 2012 Submit Auto-Discovery solution for VPMS to IESG > Mar 2012 Submit VPLS service convergence improvement solutions to = IESG > Mar 2012 Submit VPLS multi-homing solutions to IESG > Mar 2012 Submit E-Tree documents to IESG > Mar 2012 Submit E-VPN requirements/framework to IESG > Jul 2012 Submit E-VPN solution to IESG > Nov 2012 Submit E-VPN MIB/OAM to IESG >=20 > ----------------- >=20 > On 18/03/2011 17:41, "Giles Heron" wrote: >=20 >> We plan to re-charter the L2VPN WG - primarily to bring E-VPN and = E-Tree >> in-scope. >>=20 >> Please find attached a draft charter for discussion both on this list = and at >> IETF 80 in Prague. >>=20 >> Nabil and Giles >>=20 >>=20 >=20 >=20 ------_=_NextPart_001_01CBEFB3.D86596BE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Draft of new L2VPN WG Charter

Another point for item 5 -

"and also supports control plane distribution of MAC addresses
and IP to MAC address bindings in the VPN."

Well, Item 4 also supports control plane distribution of MAC = addresses
and IP to MAC address bindings in the VPN.

I do not support having this explicit phrase in the item 5. What is = the
justification? It is not a new concept.

/himanshu

-----Original Message-----
From: l2vpn-bounces@ietf.org on behalf of Benson Schliesser
Sent: Thu 3/31/2011 10:37 AM
To: Giles Heron; l2vpn@ietf.org
Subject: Re: Draft of new L2VPN WG Charter

Hi, Giles.

I have a clarifying question about the first paragraph:  What is = the purpose
of the 2nd sentence, bringing cloud and DC requirements into the = mix?
Assuming this is meant to include non-provider L2VPN environments = (like
enterprise data centers), then why not just remove the phrase
"provider-provisioned" from the first sentence?  = Otherwise, it seems
redundant.

This is a real question, not a suggestion at this time.

Thanks,
-Benson



On 3/18/11 1:21 PM, "Giles Heron" = <giles.heron@gmail.com> wrote:

> OK - looks like the attachment didn't come through as = intended.  My
> apologies.
>
> Text inline:
>
> ----------------
>
> The L2VPN working group is responsible for defining and specifying = a
> limited number of solutions for supporting provider-provisioned = Layer-2
> Virtual Private Networks (L2VPNs). It will also address = requirements driven
> by cloud computing services and data centers as they apply to = Layer-2
> VPN services.
>
> Layer-2 VPNs defined by L2VPN operate over pseudowires (PWs) as
> defined by the PWE3 WG or over MPLS PSN tunnels. A L2VPN emulates = a
> "native" service over a PSN that is adequately faithful = to, but may not
> be entirely indistinguishable from the native service itself. = Further,
> following in the "edge-to-edge" nature of the  = service, the L2VPN WG will
> not define any mechanisms which exert control over the underlying = PSN.
> When necessary it may, however, recommend or require the use of = existing
> PSN QoS and path control mechanisms between the PEs which provide = the
> L2VPN connectivity.
>
> Layer-2 VPNs comprise the following:
>
> 1. Virtual Private LAN Service (VPLS) -- A Layer-2 service that = emulates
> a switched Ethernet (V)LAN across an MPLS Packet Switched Network = (PSN).
>
> 2. Virtual Private Wire Service (VPWS) -- A Layer-2 service = that
> provides point-to-point connectivity for a variety of link = layers,
> including Frame Relay, ATM, Ethernet, PPP, etc., across an MPLS = PSN.
>
> 3. Virtual Private Multicast Service (VPMS) -- A Layer-2 service = that
> provides point-to-multipoint connectivity for a variety of link
> layers across an MPLS PSN.
>
> 4. IP-only L2VPN =AD An IP-only service over an MPLS PSN.  The = WG will
> address two specific types of IP-only L2VPN:
>
> a) Point-to-point Layer-2 VPN.  This service is similar to = VPWS, but also
> supports heterogenous Attachment Circuits at either end of a = single
> point-to-point service.
>
> b) Multipoint-to-multipoint Layer-2 VPN.  This service is = similar to VPLS,
> but learns IP and MAC address bindings from ARPs and = broadcast/multicast
> IP packets.
>
> 5. Ethernet VPN (E-VPN) - A Layer-2 technology that emulates an
> Ethernet (V)LAN across an MPLS PSN. E-VPN supports load-sharing = across
> multiple connections from a Layer-2 site to an L2VPN service, and = also
> supports control plane distribution of MAC addresses and IP to MAC = address
> bindings in the VPN. E-VPN is primarily targeted to support = large-scale
> L2VPNs with resiliency requirements not satisfied by other L2VPN = solutions.
>
> 6. E-Tree =AD a Layer-2 technology defined by the MEF, which = provides
> connectivity between one or more =B3root=B2 nodes and one or = more
> =B3leaf=B2 nodes, with the restriction that leaves may only = communicate
> with roots (and not with each other).
>
> L2VPNs will make use of existing IETF specified mechanisms unless = there
> are technical reasons why the existing mechanisms are insufficient = or
> unnecessary.
>
> The L2VPN WG is responsible for specification of the discovery = and
> membership of PEs participating in a Layer-2 VPN as well as the
> membership of CE devices for a specific instance of an L2VPN.
>
> The L2VPN WG will provide extensions of existing protocols that = will be
> discussed in protocol-specific WGs. In particular, the L2VPN WG
> may define extensions to pseudowire management mechanisms for = VPLS.
> Those extensions will be reviewed by the PWE3 WG to ensure they = are
> aligned with the overall design/architecture of PWE3.
>
> The L2VPN WG will not define new encapsulations, control, or = resiliency
> mechanisms specifically related to pseudowires. Furthermore, when = the
> L2VPN solution is based on PWs, the L2VPN WG will not define = protocol
> inter-working between an L2VPN and native service Layer-2 OAM = or
> resiliency mechanisms. The L2VPN WG may define how to operate = native
> service-layer control, OAM or resiliency mechanisms on top of an = L2VPN.
> In addition, it may define native data plane and/or control = plane
> interworking between an L2VPN and an associated native Layer-2 = service.
>
> The L2VPN WG scope includes the following:
>
> 1. Discovery of PEs participating in a Layer-2 VPN and the = associated
>  topology required for connectivity of the VPLS, VPWS, VPMS or = E-VPN
>  service.
>
> 2. Signaling of information related to the discovery and membership = of
> PEs within a L2VPN. These procedures must use PWE3 control and
> management procedures, or define requirements for extensions of = PWE3
> protocols to suit the needs of an L2VPN, when the L2VPN operates = over
> PWs. Once those requirements have been reviewed by the L2VPN WG, = they
> should be provided to the PWE3 WG to derive solutions.
>
> 3. MIBs for Layer-2 VPN solutions.
>
> 4. Specification of requirements, framework and solutions that
> facilitate Operations Administration and Management (OAM) of any = type of
> L2VPN.
>
> 5. Mechanisms to permit optimization of multicast data traffic = within
> an L2VPN.
>
> 6. If transport does not involve PWs, mechanisms that support
> load-balancing/multipathing between PEs interconnecting a = Layer-2
> service using an L2VPN across the MPLS PSN.
>
> 7. requirements for the multi-homing of CEs to several VPLS or
> E-VPN PEs, inclusive of active/backup and active/active = (load-sharing)
> configurations. Based on these requirements define VPLS or E-VPN = control
> plane solutions for achieving fast convergence after failure of an = active
> path in the PSN or on the AC side.
>
> 8. Enhancements to increase the scalability of the Control Plane = and
> Data Plane of L2VPN PE nodes, and of core nodes that provide = transport
> services for L2VPN.
>
> 9. Requirements and solutions for Auto-Discovery and Signaling = of
> Inter-AS L2VPNs, in addition to Inter-AS solutions for = multicast-optimized
> L2VPNs.
>
> 10. Requirements and solutions for supporting "E-Tree" = services using
> VPLS.
>
> 11. Extensions to L2VPN protocols and RFCs necessary to create an = MPLS
> Transport Profile (MPLS-TP). The work on the MPLS TP will be = coordinated
> between four primary working groups (MPLS, PWE3, L2VPN and CCAMP) = that are
> chartered to do MPLS TP work.
>
> Milestones:
>
> Done        Submit an I-D = describing MIB for VPLS
> Done        Submit an I-D = describing MIB for VPWS
> Done        Submit an I-D on OAM = requirements for VPLS
> Done        Submit an I-D on OAM = requirements for VPWS
> Done        Submit L2 = requirements to IESG for publication as Informational
> RFC
> Done        Submit L2 framework = to IESG for publication as Informational RFC
> Done        Identify VPLS and = VPWS solutions for the WG
> Done        Submit VPLS solution = documents to IESG
> Done        Submit VPWS solution = documents to IESG
> Done        Submit = Auto-Discovery and Signaling for Intra-AS and Inter-AS
>           &nb= sp; VPLS and VPWS Layer-2 VPNs
> Jul 2011    Submit IP-only L2VPN solution documents = to IESG
> Jul 2011    Submit OAM solutions for VPWS to = IESG
> Jul 2011    Submit OAM solutions for VPLS to = IESG
> Jul 2011    Submit signaling solution for = multicast-optimized VPLS to IESG
> Jul 2011    Submit I-D on Virtual Private Multicast = Service (VPMS)
>           &nb= sp; requirements to IESG
> Jul 2011    Submit MIB for VPLS to IESG
> Jul 2011    Submit MIB for VPWS to IESG
> Nov 2011    Submit scalability solutions for VPLS = Data-Plane to IESG
> Nov 2011    Submit scalability solutions for VPLS = Control-Plane to IESG
> Mar 2012    Submit MIB for IP-only L2VPN to IESG
> Mar 2012    Submit OAM solutions for IP-only L2VPN = to IESG
> Mar 2012    Submit Auto-Discovery solution for VPMS = to IESG
> Mar 2012    Submit VPLS service convergence = improvement solutions to IESG
> Mar 2012    Submit VPLS multi-homing solutions to = IESG
> Mar 2012    Submit E-Tree documents to IESG
> Mar 2012    Submit E-VPN requirements/framework to = IESG
> Jul 2012    Submit E-VPN solution to IESG
> Nov 2012    Submit E-VPN MIB/OAM to IESG
>
> -----------------
>
> On 18/03/2011 17:41, "Giles Heron" = <giles.heron@gmail.com> wrote:
>
>> We plan to re-charter the L2VPN WG - primarily to bring E-VPN = and E-Tree
>> in-scope.
>>
>> Please find attached a draft charter for discussion both on = this list and at
>> IETF 80 in Prague.
>>
>> Nabil and Giles
>>
>>
>
>

------_=_NextPart_001_01CBEFB3.D86596BE-- From tnadeau@lucidvision.com Thu Mar 31 07:56:22 2011 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 30C7928C12B for ; Thu, 31 Mar 2011 07:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.309 X-Spam-Level: X-Spam-Status: No, score=-1.309 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, SARE_MLB_Stock6=1.56] 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 x1mvOJNmx4aJ for ; Thu, 31 Mar 2011 07:56:21 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by core3.amsl.com (Postfix) with ESMTP id 9A58428C0F7 for ; Thu, 31 Mar 2011 07:56:20 -0700 (PDT) Received: from [192.168.1.133] (unknown [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 90E841AB0A5A; Thu, 31 Mar 2011 10:57:59 -0400 (EDT) Subject: Re: Draft of new L2VPN WG Charter Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Thomas Nadeau In-Reply-To: Date: Thu, 31 Mar 2011 10:57:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Giles Heron X-Mailer: Apple Mail (2.1084) 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: Thu, 31 Mar 2011 14:56:22 -0000 On Mar 31, 2011, at 10:49 AM, Giles Heron wrote: > Hi Benson, >=20 > This would be provider-provisioned L2VPN environments (whether = data-centre > interconnect, or scaling of a large multi-tenant data-centre). >=20 > Personally I'm not sure we need the sentence there, but others were = keen to > mention the data-centre requirements. I think that is meant to explicitly field requirements for = solutions=20 that come from ARMD/etc... into the WG, since they cannot build their = own=20 solutions. While that isn't implicitly handled in the existing charter, = I do not know either.=20 --Tom >=20 > Giles >=20 > On 31/03/2011 15:37, "Benson Schliesser" wrote: >=20 >> Hi, Giles. >>=20 >> I have a clarifying question about the first paragraph: What is the = purpose >> of the 2nd sentence, bringing cloud and DC requirements into the mix? >> Assuming this is meant to include non-provider L2VPN environments = (like >> enterprise data centers), then why not just remove the phrase >> "provider-provisioned" from the first sentence? Otherwise, it seems >> redundant. >>=20 >> This is a real question, not a suggestion at this time. >>=20 >> Thanks, >> -Benson >>=20 >>=20 >>=20 >> On 3/18/11 1:21 PM, "Giles Heron" wrote: >>=20 >>> OK - looks like the attachment didn't come through as intended. My >>> apologies. >>>=20 >>> Text inline: >>>=20 >>> ---------------- >>>=20 >>> The L2VPN working group is responsible for defining and specifying a >>> limited number of solutions for supporting provider-provisioned = Layer-2 >>> Virtual Private Networks (L2VPNs). It will also address requirements = driven >>> by cloud computing services and data centers as they apply to = Layer-2 >>> VPN services. >>>=20 >>> Layer-2 VPNs defined by L2VPN operate over pseudowires (PWs) as >>> defined by the PWE3 WG or over MPLS PSN tunnels. A L2VPN emulates a >>> "native" service over a PSN that is adequately faithful to, but may = not >>> be entirely indistinguishable from the native service itself. = Further, >>> following in the "edge-to-edge" nature of the service, the L2VPN WG = will >>> not define any mechanisms which exert control over the underlying = PSN. >>> When necessary it may, however, recommend or require the use of = existing >>> PSN QoS and path control mechanisms between the PEs which provide = the >>> L2VPN connectivity. >>>=20 >>> Layer-2 VPNs comprise the following: >>>=20 >>> 1. Virtual Private LAN Service (VPLS) -- A Layer-2 service that = emulates >>> a switched Ethernet (V)LAN across an MPLS Packet Switched Network = (PSN). >>>=20 >>> 2. Virtual Private Wire Service (VPWS) -- A Layer-2 service that >>> provides point-to-point connectivity for a variety of link layers, >>> including Frame Relay, ATM, Ethernet, PPP, etc., across an MPLS PSN. >>>=20 >>> 3. Virtual Private Multicast Service (VPMS) -- A Layer-2 service = that >>> provides point-to-multipoint connectivity for a variety of link >>> layers across an MPLS PSN. >>>=20 >>> 4. IP-only L2VPN =96 An IP-only service over an MPLS PSN. The WG = will >>> address two specific types of IP-only L2VPN: >>>=20 >>> a) Point-to-point Layer-2 VPN. This service is similar to VPWS, but = also >>> supports heterogenous Attachment Circuits at either end of a single >>> point-to-point service. >>>=20 >>> b) Multipoint-to-multipoint Layer-2 VPN. This service is similar to = VPLS, >>> but learns IP and MAC address bindings from ARPs and = broadcast/multicast >>> IP packets. >>>=20 >>> 5. Ethernet VPN (E-VPN) - A Layer-2 technology that emulates an >>> Ethernet (V)LAN across an MPLS PSN. E-VPN supports load-sharing = across >>> multiple connections from a Layer-2 site to an L2VPN service, and = also >>> supports control plane distribution of MAC addresses and IP to MAC = address >>> bindings in the VPN. E-VPN is primarily targeted to support = large-scale >>> L2VPNs with resiliency requirements not satisfied by other L2VPN = solutions. >>>=20 >>> 6. E-Tree =96 a Layer-2 technology defined by the MEF, which = provides >>> connectivity between one or more =93root=94 nodes and one or more >>> =93leaf=94 nodes, with the restriction that leaves may only = communicate >>> with roots (and not with each other). >>>=20 >>> L2VPNs will make use of existing IETF specified mechanisms unless = there >>> are technical reasons why the existing mechanisms are insufficient = or >>> unnecessary. >>>=20 >>> The L2VPN WG is responsible for specification of the discovery and >>> membership of PEs participating in a Layer-2 VPN as well as the >>> membership of CE devices for a specific instance of an L2VPN. >>>=20 >>> The L2VPN WG will provide extensions of existing protocols that will = be >>> discussed in protocol-specific WGs. In particular, the L2VPN WG >>> may define extensions to pseudowire management mechanisms for VPLS. >>> Those extensions will be reviewed by the PWE3 WG to ensure they are >>> aligned with the overall design/architecture of PWE3. >>>=20 >>> The L2VPN WG will not define new encapsulations, control, or = resiliency >>> mechanisms specifically related to pseudowires. Furthermore, when = the >>> L2VPN solution is based on PWs, the L2VPN WG will not define = protocol >>> inter-working between an L2VPN and native service Layer-2 OAM or >>> resiliency mechanisms. The L2VPN WG may define how to operate native >>> service-layer control, OAM or resiliency mechanisms on top of an = L2VPN. >>> In addition, it may define native data plane and/or control plane >>> interworking between an L2VPN and an associated native Layer-2 = service. >>>=20 >>> The L2VPN WG scope includes the following: >>>=20 >>> 1. Discovery of PEs participating in a Layer-2 VPN and the = associated >>> topology required for connectivity of the VPLS, VPWS, VPMS or E-VPN >>> service. >>>=20 >>> 2. Signaling of information related to the discovery and membership = of >>> PEs within a L2VPN. These procedures must use PWE3 control and >>> management procedures, or define requirements for extensions of PWE3 >>> protocols to suit the needs of an L2VPN, when the L2VPN operates = over >>> PWs. Once those requirements have been reviewed by the L2VPN WG, = they >>> should be provided to the PWE3 WG to derive solutions. >>>=20 >>> 3. MIBs for Layer-2 VPN solutions. >>>=20 >>> 4. Specification of requirements, framework and solutions that >>> facilitate Operations Administration and Management (OAM) of any = type of >>> L2VPN. >>>=20 >>> 5. Mechanisms to permit optimization of multicast data traffic = within >>> an L2VPN. >>>=20 >>> 6. If transport does not involve PWs, mechanisms that support >>> load-balancing/multipathing between PEs interconnecting a Layer-2 >>> service using an L2VPN across the MPLS PSN. >>>=20 >>> 7. requirements for the multi-homing of CEs to several VPLS or >>> E-VPN PEs, inclusive of active/backup and active/active = (load-sharing) >>> configurations. Based on these requirements define VPLS or E-VPN = control >>> plane solutions for achieving fast convergence after failure of an = active >>> path in the PSN or on the AC side. >>>=20 >>> 8. Enhancements to increase the scalability of the Control Plane and >>> Data Plane of L2VPN PE nodes, and of core nodes that provide = transport >>> services for L2VPN. >>>=20 >>> 9. Requirements and solutions for Auto-Discovery and Signaling of >>> Inter-AS L2VPNs, in addition to Inter-AS solutions for = multicast-optimized >>> L2VPNs. >>>=20 >>> 10. Requirements and solutions for supporting "E-Tree" services = using >>> VPLS.=20 >>>=20 >>> 11. Extensions to L2VPN protocols and RFCs necessary to create an = MPLS >>> Transport Profile (MPLS-TP). The work on the MPLS TP will be = coordinated >>> between four primary working groups (MPLS, PWE3, L2VPN and CCAMP) = that are >>> chartered to do MPLS TP work. >>>=20 >>> Milestones: >>>=20 >>> Done Submit an I-D describing MIB for VPLS >>> Done Submit an I-D describing MIB for VPWS >>> Done Submit an I-D on OAM requirements for VPLS >>> Done Submit an I-D on OAM requirements for VPWS >>> Done Submit L2 requirements to IESG for publication as = Informational >>> RFC >>> Done Submit L2 framework to IESG for publication as = Informational RFC >>> Done Identify VPLS and VPWS solutions for the WG >>> Done Submit VPLS solution documents to IESG >>> Done Submit VPWS solution documents to IESG >>> Done Submit Auto-Discovery and Signaling for Intra-AS and = Inter-AS >>> VPLS and VPWS Layer-2 VPNs >>> Jul 2011 Submit IP-only L2VPN solution documents to IESG >>> Jul 2011 Submit OAM solutions for VPWS to IESG >>> Jul 2011 Submit OAM solutions for VPLS to IESG >>> Jul 2011 Submit signaling solution for multicast-optimized VPLS = to IESG >>> Jul 2011 Submit I-D on Virtual Private Multicast Service (VPMS) >>> requirements to IESG >>> Jul 2011 Submit MIB for VPLS to IESG >>> Jul 2011 Submit MIB for VPWS to IESG >>> Nov 2011 Submit scalability solutions for VPLS Data-Plane to IESG >>> Nov 2011 Submit scalability solutions for VPLS Control-Plane to = IESG >>> Mar 2012 Submit MIB for IP-only L2VPN to IESG >>> Mar 2012 Submit OAM solutions for IP-only L2VPN to IESG >>> Mar 2012 Submit Auto-Discovery solution for VPMS to IESG >>> Mar 2012 Submit VPLS service convergence improvement solutions to = IESG >>> Mar 2012 Submit VPLS multi-homing solutions to IESG >>> Mar 2012 Submit E-Tree documents to IESG >>> Mar 2012 Submit E-VPN requirements/framework to IESG >>> Jul 2012 Submit E-VPN solution to IESG >>> Nov 2012 Submit E-VPN MIB/OAM to IESG >>>=20 >>> ----------------- >>>=20 >>> On 18/03/2011 17:41, "Giles Heron" wrote: >>>=20 >>>> We plan to re-charter the L2VPN WG - primarily to bring E-VPN and = E-Tree >>>> in-scope. >>>>=20 >>>> Please find attached a draft charter for discussion both on this = list and at >>>> IETF 80 in Prague. >>>>=20 >>>> Nabil and Giles >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >=20 >=20 >=20 From prvs=7071a0f4f3=hshah@ciena.com Thu Mar 31 07:58:03 2011 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 6171328B56A for ; Thu, 31 Mar 2011 07:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.704 X-Spam-Level: X-Spam-Status: No, score=-0.704 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SARE_MLB_Stock6=1.56] 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 hAbWJ7m8n7p3 for ; Thu, 31 Mar 2011 07:58:01 -0700 (PDT) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) by core3.amsl.com (Postfix) with ESMTP id A3A8A28C102 for ; Thu, 31 Mar 2011 07:58:01 -0700 (PDT) Received: from pps.filterd (m0000419 [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.14.3/8.14.3) with SMTP id p2VEupY6025015; Thu, 31 Mar 2011 10:59:38 -0400 Received: from mdwexght02.ciena.com (LIN1-118-36-29.ciena.com [63.118.36.29]) by mx0a-00103a01.pphosted.com with ESMTP id vcujar2k6-3 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 31 Mar 2011 10:59:38 -0400 Received: from mdmxm05.ciena.com (63.118.39.23) by MDWEXGHT02.ciena.com (10.4.140.213) with Microsoft SMTP Server id 8.1.436.0; Thu, 31 Mar 2011 10:59:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBEFB4.2F7F6455" Subject: RE: Draft of new L2VPN WG Charter Date: Thu, 31 Mar 2011 10:57:10 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft of new L2VPN WG Charter Thread-Index: Acvlk6mvByfCCAJ7pEaQouOVm51qugABaMGqAoX2iAkAAG8q8wAAQXP3 References: From: "Shah, Himanshu" To: "Giles Heron" , "Benson Schliesser" , X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-03-31_05:2011-03-31, 2011-03-31, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1103310063 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, 31 Mar 2011 14:58:03 -0000 ------_=_NextPart_001_01CBEFB4.2F7F6455 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree with Ben (and apparently yours) concern. I suggest we remove that sentence. /himanshu -----Original Message----- From: l2vpn-bounces@ietf.org on behalf of Giles Heron Sent: Thu 3/31/2011 10:49 AM To: Benson Schliesser; l2vpn@ietf.org Subject: Re: Draft of new L2VPN WG Charter =20 Hi Benson, This would be provider-provisioned L2VPN environments (whether = data-centre interconnect, or scaling of a large multi-tenant data-centre). Personally I'm not sure we need the sentence there, but others were keen = to mention the data-centre requirements. =20 Giles On 31/03/2011 15:37, "Benson Schliesser" wrote: > Hi, Giles. >=20 > I have a clarifying question about the first paragraph: What is the = purpose > of the 2nd sentence, bringing cloud and DC requirements into the mix? > Assuming this is meant to include non-provider L2VPN environments = (like > enterprise data centers), then why not just remove the phrase > "provider-provisioned" from the first sentence? Otherwise, it seems > redundant. >=20 > This is a real question, not a suggestion at this time. >=20 > Thanks, > -Benson >=20 >=20 >=20 > On 3/18/11 1:21 PM, "Giles Heron" wrote: >=20 >> OK - looks like the attachment didn't come through as intended. My >> apologies. >>=20 >> Text inline: >>=20 >> ---------------- >>=20 >> The L2VPN working group is responsible for defining and specifying a >> limited number of solutions for supporting provider-provisioned = Layer-2 >> Virtual Private Networks (L2VPNs). It will also address requirements = driven >> by cloud computing services and data centers as they apply to Layer-2 >> VPN services. >>=20 >> Layer-2 VPNs defined by L2VPN operate over pseudowires (PWs) as >> defined by the PWE3 WG or over MPLS PSN tunnels. A L2VPN emulates a >> "native" service over a PSN that is adequately faithful to, but may = not >> be entirely indistinguishable from the native service itself. = Further, >> following in the "edge-to-edge" nature of the service, the L2VPN WG = will >> not define any mechanisms which exert control over the underlying = PSN. >> When necessary it may, however, recommend or require the use of = existing >> PSN QoS and path control mechanisms between the PEs which provide the >> L2VPN connectivity. >>=20 >> Layer-2 VPNs comprise the following: >>=20 >> 1. Virtual Private LAN Service (VPLS) -- A Layer-2 service that = emulates >> a switched Ethernet (V)LAN across an MPLS Packet Switched Network = (PSN). >>=20 >> 2. Virtual Private Wire Service (VPWS) -- A Layer-2 service that >> provides point-to-point connectivity for a variety of link layers, >> including Frame Relay, ATM, Ethernet, PPP, etc., across an MPLS PSN. >>=20 >> 3. Virtual Private Multicast Service (VPMS) -- A Layer-2 service that >> provides point-to-multipoint connectivity for a variety of link >> layers across an MPLS PSN. >>=20 >> 4. IP-only L2VPN =AD An IP-only service over an MPLS PSN. The WG = will >> address two specific types of IP-only L2VPN: >>=20 >> a) Point-to-point Layer-2 VPN. This service is similar to VPWS, but = also >> supports heterogenous Attachment Circuits at either end of a single >> point-to-point service. >>=20 >> b) Multipoint-to-multipoint Layer-2 VPN. This service is similar to = VPLS, >> but learns IP and MAC address bindings from ARPs and = broadcast/multicast >> IP packets. >>=20 >> 5. Ethernet VPN (E-VPN) - A Layer-2 technology that emulates an >> Ethernet (V)LAN across an MPLS PSN. E-VPN supports load-sharing = across >> multiple connections from a Layer-2 site to an L2VPN service, and = also >> supports control plane distribution of MAC addresses and IP to MAC = address >> bindings in the VPN. E-VPN is primarily targeted to support = large-scale >> L2VPNs with resiliency requirements not satisfied by other L2VPN = solutions. >>=20 >> 6. E-Tree =AD a Layer-2 technology defined by the MEF, which provides >> connectivity between one or more =B3root=B2 nodes and one or more >> =B3leaf=B2 nodes, with the restriction that leaves may only = communicate >> with roots (and not with each other). >>=20 >> L2VPNs will make use of existing IETF specified mechanisms unless = there >> are technical reasons why the existing mechanisms are insufficient or >> unnecessary. >>=20 >> The L2VPN WG is responsible for specification of the discovery and >> membership of PEs participating in a Layer-2 VPN as well as the >> membership of CE devices for a specific instance of an L2VPN. >>=20 >> The L2VPN WG will provide extensions of existing protocols that will = be >> discussed in protocol-specific WGs. In particular, the L2VPN WG >> may define extensions to pseudowire management mechanisms for VPLS. >> Those extensions will be reviewed by the PWE3 WG to ensure they are >> aligned with the overall design/architecture of PWE3. >>=20 >> The L2VPN WG will not define new encapsulations, control, or = resiliency >> mechanisms specifically related to pseudowires. Furthermore, when the >> L2VPN solution is based on PWs, the L2VPN WG will not define protocol >> inter-working between an L2VPN and native service Layer-2 OAM or >> resiliency mechanisms. The L2VPN WG may define how to operate native >> service-layer control, OAM or resiliency mechanisms on top of an = L2VPN. >> In addition, it may define native data plane and/or control plane >> interworking between an L2VPN and an associated native Layer-2 = service. >>=20 >> The L2VPN WG scope includes the following: >>=20 >> 1. Discovery of PEs participating in a Layer-2 VPN and the associated >> topology required for connectivity of the VPLS, VPWS, VPMS or E-VPN >> service. >>=20 >> 2. Signaling of information related to the discovery and membership = of >> PEs within a L2VPN. These procedures must use PWE3 control and >> management procedures, or define requirements for extensions of PWE3 >> protocols to suit the needs of an L2VPN, when the L2VPN operates over >> PWs. Once those requirements have been reviewed by the L2VPN WG, they >> should be provided to the PWE3 WG to derive solutions. >>=20 >> 3. MIBs for Layer-2 VPN solutions. >>=20 >> 4. Specification of requirements, framework and solutions that >> facilitate Operations Administration and Management (OAM) of any type = of >> L2VPN. >>=20 >> 5. Mechanisms to permit optimization of multicast data traffic within >> an L2VPN. >>=20 >> 6. If transport does not involve PWs, mechanisms that support >> load-balancing/multipathing between PEs interconnecting a Layer-2 >> service using an L2VPN across the MPLS PSN. >>=20 >> 7. requirements for the multi-homing of CEs to several VPLS or >> E-VPN PEs, inclusive of active/backup and active/active = (load-sharing) >> configurations. Based on these requirements define VPLS or E-VPN = control >> plane solutions for achieving fast convergence after failure of an = active >> path in the PSN or on the AC side. >>=20 >> 8. Enhancements to increase the scalability of the Control Plane and >> Data Plane of L2VPN PE nodes, and of core nodes that provide = transport >> services for L2VPN. >>=20 >> 9. Requirements and solutions for Auto-Discovery and Signaling of >> Inter-AS L2VPNs, in addition to Inter-AS solutions for = multicast-optimized >> L2VPNs. >>=20 >> 10. Requirements and solutions for supporting "E-Tree" services using >> VPLS.=20 >>=20 >> 11. Extensions to L2VPN protocols and RFCs necessary to create an = MPLS >> Transport Profile (MPLS-TP). The work on the MPLS TP will be = coordinated >> between four primary working groups (MPLS, PWE3, L2VPN and CCAMP) = that are >> chartered to do MPLS TP work. >>=20 >> Milestones: >>=20 >> Done Submit an I-D describing MIB for VPLS >> Done Submit an I-D describing MIB for VPWS >> Done Submit an I-D on OAM requirements for VPLS >> Done Submit an I-D on OAM requirements for VPWS >> Done Submit L2 requirements to IESG for publication as = Informational >> RFC >> Done Submit L2 framework to IESG for publication as = Informational RFC >> Done Identify VPLS and VPWS solutions for the WG >> Done Submit VPLS solution documents to IESG >> Done Submit VPWS solution documents to IESG >> Done Submit Auto-Discovery and Signaling for Intra-AS and = Inter-AS >> VPLS and VPWS Layer-2 VPNs >> Jul 2011 Submit IP-only L2VPN solution documents to IESG >> Jul 2011 Submit OAM solutions for VPWS to IESG >> Jul 2011 Submit OAM solutions for VPLS to IESG >> Jul 2011 Submit signaling solution for multicast-optimized VPLS to = IESG >> Jul 2011 Submit I-D on Virtual Private Multicast Service (VPMS) >> requirements to IESG >> Jul 2011 Submit MIB for VPLS to IESG >> Jul 2011 Submit MIB for VPWS to IESG >> Nov 2011 Submit scalability solutions for VPLS Data-Plane to IESG >> Nov 2011 Submit scalability solutions for VPLS Control-Plane to = IESG >> Mar 2012 Submit MIB for IP-only L2VPN to IESG >> Mar 2012 Submit OAM solutions for IP-only L2VPN to IESG >> Mar 2012 Submit Auto-Discovery solution for VPMS to IESG >> Mar 2012 Submit VPLS service convergence improvement solutions to = IESG >> Mar 2012 Submit VPLS multi-homing solutions to IESG >> Mar 2012 Submit E-Tree documents to IESG >> Mar 2012 Submit E-VPN requirements/framework to IESG >> Jul 2012 Submit E-VPN solution to IESG >> Nov 2012 Submit E-VPN MIB/OAM to IESG >>=20 >> ----------------- >>=20 >> On 18/03/2011 17:41, "Giles Heron" wrote: >>=20 >>> We plan to re-charter the L2VPN WG - primarily to bring E-VPN and = E-Tree >>> in-scope. >>>=20 >>> Please find attached a draft charter for discussion both on this = list and at >>> IETF 80 in Prague. >>>=20 >>> Nabil and Giles >>>=20 >>>=20 >>=20 >>=20 >=20 ------_=_NextPart_001_01CBEFB4.2F7F6455 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Draft of new L2VPN WG Charter

I agree with Ben (and apparently yours) concern.
I suggest we remove that sentence.
/himanshu

-----Original Message-----
From: l2vpn-bounces@ietf.org on behalf of Giles Heron
Sent: Thu 3/31/2011 10:49 AM
To: Benson Schliesser; l2vpn@ietf.org
Subject: Re: Draft of new L2VPN WG Charter

Hi Benson,

This would be provider-provisioned L2VPN environments (whether = data-centre
interconnect, or scaling of a large multi-tenant data-centre).

Personally I'm not sure we need the sentence there, but others were keen = to
mention the data-centre requirements.

Giles

On 31/03/2011 15:37, "Benson Schliesser" = <bschlies@cisco.com> wrote:

> Hi, Giles.
>
> I have a clarifying question about the first paragraph:  What = is the purpose
> of the 2nd sentence, bringing cloud and DC requirements into the = mix?
> Assuming this is meant to include non-provider L2VPN environments = (like
> enterprise data centers), then why not just remove the phrase
> "provider-provisioned" from the first sentence?  = Otherwise, it seems
> redundant.
>
> This is a real question, not a suggestion at this time.
>
> Thanks,
> -Benson
>
>
>
> On 3/18/11 1:21 PM, "Giles Heron" = <giles.heron@gmail.com> wrote:
>
>> OK - looks like the attachment didn't come through as = intended.  My
>> apologies.
>>
>> Text inline:
>>
>> ----------------
>>
>> The L2VPN working group is responsible for defining and = specifying a
>> limited number of solutions for supporting provider-provisioned = Layer-2
>> Virtual Private Networks (L2VPNs). It will also address = requirements driven
>> by cloud computing services and data centers as they apply to = Layer-2
>> VPN services.
>>
>> Layer-2 VPNs defined by L2VPN operate over pseudowires (PWs) = as
>> defined by the PWE3 WG or over MPLS PSN tunnels. A L2VPN = emulates a
>> "native" service over a PSN that is adequately = faithful to, but may not
>> be entirely indistinguishable from the native service itself. = Further,
>> following in the "edge-to-edge" nature of the  = service, the L2VPN WG will
>> not define any mechanisms which exert control over the = underlying PSN.
>> When necessary it may, however, recommend or require the use of = existing
>> PSN QoS and path control mechanisms between the PEs which = provide the
>> L2VPN connectivity.
>>
>> Layer-2 VPNs comprise the following:
>>
>> 1. Virtual Private LAN Service (VPLS) -- A Layer-2 service that = emulates
>> a switched Ethernet (V)LAN across an MPLS Packet Switched = Network (PSN).
>>
>> 2. Virtual Private Wire Service (VPWS) -- A Layer-2 service = that
>> provides point-to-point connectivity for a variety of link = layers,
>> including Frame Relay, ATM, Ethernet, PPP, etc., across an MPLS = PSN.
>>
>> 3. Virtual Private Multicast Service (VPMS) -- A Layer-2 = service that
>> provides point-to-multipoint connectivity for a variety of = link
>> layers across an MPLS PSN.
>>
>> 4. IP-only L2VPN =AD An IP-only service over an MPLS PSN.  = The WG will
>> address two specific types of IP-only L2VPN:
>>
>> a) Point-to-point Layer-2 VPN.  This service is similar to = VPWS, but also
>> supports heterogenous Attachment Circuits at either end of a = single
>> point-to-point service.
>>
>> b) Multipoint-to-multipoint Layer-2 VPN.  This service is = similar to VPLS,
>> but learns IP and MAC address bindings from ARPs and = broadcast/multicast
>> IP packets.
>>
>> 5. Ethernet VPN (E-VPN) - A Layer-2 technology that emulates = an
>> Ethernet (V)LAN across an MPLS PSN. E-VPN supports load-sharing = across
>> multiple connections from a Layer-2 site to an L2VPN service, = and also
>> supports control plane distribution of MAC addresses and IP to = MAC address
>> bindings in the VPN. E-VPN is primarily targeted to support = large-scale
>> L2VPNs with resiliency requirements not satisfied by other = L2VPN solutions.
>>
>> 6. E-Tree =AD a Layer-2 technology defined by the MEF, which = provides
>> connectivity between one or more =B3root=B2 nodes and one or = more
>> =B3leaf=B2 nodes, with the restriction that leaves may only = communicate
>> with roots (and not with each other).
>>
>> L2VPNs will make use of existing IETF specified mechanisms = unless there
>> are technical reasons why the existing mechanisms are = insufficient or
>> unnecessary.
>>
>> The L2VPN WG is responsible for specification of the discovery = and
>> membership of PEs participating in a Layer-2 VPN as well as = the
>> membership of CE devices for a specific instance of an = L2VPN.
>>
>> The L2VPN WG will provide extensions of existing protocols that = will be
>> discussed in protocol-specific WGs. In particular, the L2VPN = WG
>> may define extensions to pseudowire management mechanisms for = VPLS.
>> Those extensions will be reviewed by the PWE3 WG to ensure they = are
>> aligned with the overall design/architecture of PWE3.
>>
>> The L2VPN WG will not define new encapsulations, control, or = resiliency
>> mechanisms specifically related to pseudowires. Furthermore, = when the
>> L2VPN solution is based on PWs, the L2VPN WG will not define = protocol
>> inter-working between an L2VPN and native service Layer-2 OAM = or
>> resiliency mechanisms. The L2VPN WG may define how to operate = native
>> service-layer control, OAM or resiliency mechanisms on top of = an L2VPN.
>> In addition, it may define native data plane and/or control = plane
>> interworking between an L2VPN and an associated native Layer-2 = service.
>>
>> The L2VPN WG scope includes the following:
>>
>> 1. Discovery of PEs participating in a Layer-2 VPN and the = associated
>>  topology required for connectivity of the VPLS, VPWS, = VPMS or E-VPN
>>  service.
>>
>> 2. Signaling of information related to the discovery and = membership of
>> PEs within a L2VPN. These procedures must use PWE3 control = and
>> management procedures, or define requirements for extensions of = PWE3
>> protocols to suit the needs of an L2VPN, when the L2VPN = operates over
>> PWs. Once those requirements have been reviewed by the L2VPN = WG, they
>> should be provided to the PWE3 WG to derive solutions.
>>
>> 3. MIBs for Layer-2 VPN solutions.
>>
>> 4. Specification of requirements, framework and solutions = that
>> facilitate Operations Administration and Management (OAM) of = any type of
>> L2VPN.
>>
>> 5. Mechanisms to permit optimization of multicast data traffic = within
>> an L2VPN.
>>
>> 6. If transport does not involve PWs, mechanisms that = support
>> load-balancing/multipathing between PEs interconnecting a = Layer-2
>> service using an L2VPN across the MPLS PSN.
>>
>> 7. requirements for the multi-homing of CEs to several VPLS = or
>> E-VPN PEs, inclusive of active/backup and active/active = (load-sharing)
>> configurations. Based on these requirements define VPLS or = E-VPN control
>> plane solutions for achieving fast convergence after failure of = an active
>> path in the PSN or on the AC side.
>>
>> 8. Enhancements to increase the scalability of the Control = Plane and
>> Data Plane of L2VPN PE nodes, and of core nodes that provide = transport
>> services for L2VPN.
>>
>> 9. Requirements and solutions for Auto-Discovery and Signaling = of
>> Inter-AS L2VPNs, in addition to Inter-AS solutions for = multicast-optimized
>> L2VPNs.
>>
>> 10. Requirements and solutions for supporting = "E-Tree" services using
>> VPLS.
>>
>> 11. Extensions to L2VPN protocols and RFCs necessary to create = an MPLS
>> Transport Profile (MPLS-TP). The work on the MPLS TP will be = coordinated
>> between four primary working groups (MPLS, PWE3, L2VPN and = CCAMP) that are
>> chartered to do MPLS TP work.
>>
>> Milestones:
>>
>> Done        Submit an I-D = describing MIB for VPLS
>> Done        Submit an I-D = describing MIB for VPWS
>> Done        Submit an I-D on = OAM requirements for VPLS
>> Done        Submit an I-D on = OAM requirements for VPWS
>> Done        Submit L2 = requirements to IESG for publication as Informational
>> RFC
>> Done        Submit L2 = framework to IESG for publication as Informational RFC
>> Done        Identify VPLS = and VPWS solutions for the WG
>> Done        Submit VPLS = solution documents to IESG
>> Done        Submit VPWS = solution documents to IESG
>> Done        Submit = Auto-Discovery and Signaling for Intra-AS and Inter-AS
>>           = ;  VPLS and VPWS Layer-2 VPNs
>> Jul 2011    Submit IP-only L2VPN solution = documents to IESG
>> Jul 2011    Submit OAM solutions for VPWS to = IESG
>> Jul 2011    Submit OAM solutions for VPLS to = IESG
>> Jul 2011    Submit signaling solution for = multicast-optimized VPLS to IESG
>> Jul 2011    Submit I-D on Virtual Private = Multicast Service (VPMS)
>>           = ;  requirements to IESG
>> Jul 2011    Submit MIB for VPLS to IESG
>> Jul 2011    Submit MIB for VPWS to IESG
>> Nov 2011    Submit scalability solutions for = VPLS Data-Plane to IESG
>> Nov 2011    Submit scalability solutions for = VPLS Control-Plane to IESG
>> Mar 2012    Submit MIB for IP-only L2VPN to = IESG
>> Mar 2012    Submit OAM solutions for IP-only = L2VPN to IESG
>> Mar 2012    Submit Auto-Discovery solution for = VPMS to IESG
>> Mar 2012    Submit VPLS service convergence = improvement solutions to IESG
>> Mar 2012    Submit VPLS multi-homing solutions = to IESG
>> Mar 2012    Submit E-Tree documents to IESG
>> Mar 2012    Submit E-VPN requirements/framework = to IESG
>> Jul 2012    Submit E-VPN solution to IESG
>> Nov 2012    Submit E-VPN MIB/OAM to IESG
>>
>> -----------------
>>
>> On 18/03/2011 17:41, "Giles Heron" = <giles.heron@gmail.com> wrote:
>>
>>> We plan to re-charter the L2VPN WG - primarily to bring = E-VPN and E-Tree
>>> in-scope.
>>>
>>> Please find attached a draft charter for discussion both on = this list and at
>>> IETF 80 in Prague.
>>>
>>> Nabil and Giles
>>>
>>>
>>
>>
>

------_=_NextPart_001_01CBEFB4.2F7F6455-- From giles.heron@gmail.com Thu Mar 31 08:16:40 2011 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 CB6EE3A6B20 for ; Thu, 31 Mar 2011 08:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.731 X-Spam-Level: X-Spam-Status: No, score=-1.731 tagged_above=-999 required=5 tests=[AWL=-1.089, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, SARE_MLB_Stock6=1.56] 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 jyTKNOz7l+V9 for ; Thu, 31 Mar 2011 08:16:30 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 17F263A680E for ; Thu, 31 Mar 2011 08:16:29 -0700 (PDT) Received: by wyb29 with SMTP id 29so2382454wyb.31 for ; Thu, 31 Mar 2011 08:18:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:user-agent:date:subject:from:to:message-id :thread-topic:thread-index:in-reply-to:mime-version:content-type; bh=sU2D8A0P3Awgjy9cOwOAevaYbySXtgKWXiMpynrQYJU=; b=nfkSqnpwJOQ/LcLpvSPIOlH6mkWJmkmlF/Jto786DdIj38X8UROZIFK/9PxPsugEfw Qh0SOoehQ7j8l1l+jaJbcsoXDSdzPEUqRAxrsqLJS3TuaGZGOylEvXFvFaKne5lxaLcV lsqRnbD96AX5wAqyIH2/49Faa+ewKNoOuTKhU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type; b=aHPGngo6w0JJ3ojdlBBtb6bty24Lf3TOMtIhSwh+V8xakXY4Zz82TfL5vUWGSTAyvP +JdtyZ+MZmqm+lnPsanbFc7n76NA/jYfJPfUOUU6Cnzwqfndsf5+pmEZOPMwM+9hMCkK NzH+3scGKnwW2Br+6Hj8VoCIo1XBMVMpeGGO8= Received: by 10.227.171.207 with SMTP id i15mr2850449wbz.121.1301584689174; Thu, 31 Mar 2011 08:18:09 -0700 (PDT) Received: from [10.61.106.177] (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id ed10sm709608wbb.49.2011.03.31.08.18.06 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 31 Mar 2011 08:18:07 -0700 (PDT) User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Thu, 31 Mar 2011 16:18:38 +0100 Subject: Re: Draft of new L2VPN WG Charter From: Giles Heron To: "Shah, Himanshu" , Benson Schliesser , Message-ID: Thread-Topic: Draft of new L2VPN WG Charter Thread-Index: Acvlk6mvByfCCAJ7pEaQouOVm51qugABaMGqAoX2iAkAAG8q8wAAQXP3AAC/5bc= In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3384433121_2537818" 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, 31 Mar 2011 15:16:40 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3384433121_2537818 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Let=B9s see what others say. I=B9m off on vacation for the next 10 days but will discuss the charter again with Nabil and the ADs when I return. Giles On 31/03/2011 15:57, "Shah, Himanshu" wrote: >=20 >=20 > I agree with Ben (and apparently yours) concern. > I suggest we remove that sentence. > /himanshu >=20 > -----Original Message----- > From: l2vpn-bounces@ietf.org on behalf of Giles Heron > Sent: Thu 3/31/2011 10:49 AM > To: Benson Schliesser; l2vpn@ietf.org > Subject: Re: Draft of new L2VPN WG Charter >=20 > Hi Benson, >=20 > This would be provider-provisioned L2VPN environments (whether data-centr= e > interconnect, or scaling of a large multi-tenant data-centre). >=20 > Personally I'm not sure we need the sentence there, but others were keen = to > mention the data-centre requirements. >=20 > Giles >=20 > On 31/03/2011 15:37, "Benson Schliesser" wrote: >=20 >> > Hi, Giles. >> > >> > I have a clarifying question about the first paragraph: What is the >> purpose >> > of the 2nd sentence, bringing cloud and DC requirements into the mix? >> > Assuming this is meant to include non-provider L2VPN environments (lik= e >> > enterprise data centers), then why not just remove the phrase >> > "provider-provisioned" from the first sentence? Otherwise, it seems >> > redundant. >> > >> > This is a real question, not a suggestion at this time. >> > >> > Thanks, >> > -Benson >> > >> > >> > >> > On 3/18/11 1:21 PM, "Giles Heron" wrote: >> > >>> >> OK - looks like the attachment didn't come through as intended. My >>> >> apologies. >>> >> >>> >> Text inline: >>> >> >>> >> ---------------- >>> >> >>> >> The L2VPN working group is responsible for defining and specifying a >>> >> limited number of solutions for supporting provider-provisioned Laye= r-2 >>> >> Virtual Private Networks (L2VPNs). It will also address requirements >>> driven >>> >> by cloud computing services and data centers as they apply to Layer-= 2 >>> >> VPN services. >>> >> >>> >> Layer-2 VPNs defined by L2VPN operate over pseudowires (PWs) as >>> >> defined by the PWE3 WG or over MPLS PSN tunnels. A L2VPN emulates a >>> >> "native" service over a PSN that is adequately faithful to, but may = not >>> >> be entirely indistinguishable from the native service itself. Furthe= r, >>> >> following in the "edge-to-edge" nature of the service, the L2VPN WG= will >>> >> not define any mechanisms which exert control over the underlying PS= N. >>> >> When necessary it may, however, recommend or require the use of exis= ting >>> >> PSN QoS and path control mechanisms between the PEs which provide th= e >>> >> L2VPN connectivity. >>> >> >>> >> Layer-2 VPNs comprise the following: >>> >> >>> >> 1. Virtual Private LAN Service (VPLS) -- A Layer-2 service that emul= ates >>> >> a switched Ethernet (V)LAN across an MPLS Packet Switched Network (P= SN). >>> >> >>> >> 2. Virtual Private Wire Service (VPWS) -- A Layer-2 service that >>> >> provides point-to-point connectivity for a variety of link layers, >>> >> including Frame Relay, ATM, Ethernet, PPP, etc., across an MPLS PSN. >>> >> >>> >> 3. Virtual Private Multicast Service (VPMS) -- A Layer-2 service tha= t >>> >> provides point-to-multipoint connectivity for a variety of link >>> >> layers across an MPLS PSN. >>> >> >>> >> 4. IP-only L2VPN =AD An IP-only service over an MPLS PSN. The WG will >>> >> address two specific types of IP-only L2VPN: >>> >> >>> >> a) Point-to-point Layer-2 VPN. This service is similar to VPWS, but= also >>> >> supports heterogenous Attachment Circuits at either end of a single >>> >> point-to-point service. >>> >> >>> >> b) Multipoint-to-multipoint Layer-2 VPN. This service is similar to >>> VPLS, >>> >> but learns IP and MAC address bindings from ARPs and broadcast/multi= cast >>> >> IP packets. >>> >> >>> >> 5. Ethernet VPN (E-VPN) - A Layer-2 technology that emulates an >>> >> Ethernet (V)LAN across an MPLS PSN. E-VPN supports load-sharing acro= ss >>> >> multiple connections from a Layer-2 site to an L2VPN service, and al= so >>> >> supports control plane distribution of MAC addresses and IP to MAC >>> address >>> >> bindings in the VPN. E-VPN is primarily targeted to support large-sc= ale >>> >> L2VPNs with resiliency requirements not satisfied by other L2VPN >>> solutions. >>> >> >>> >> 6. E-Tree =AD a Layer-2 technology defined by the MEF, which provides >>> >> connectivity between one or more =B3root=B2 nodes and one or more >>> >> =B3leaf=B2 nodes, with the restriction that leaves may only communicate >>> >> with roots (and not with each other). >>> >> >>> >> L2VPNs will make use of existing IETF specified mechanisms unless th= ere >>> >> are technical reasons why the existing mechanisms are insufficient o= r >>> >> unnecessary. >>> >> >>> >> The L2VPN WG is responsible for specification of the discovery and >>> >> membership of PEs participating in a Layer-2 VPN as well as the >>> >> membership of CE devices for a specific instance of an L2VPN. >>> >> >>> >> The L2VPN WG will provide extensions of existing protocols that will= be >>> >> discussed in protocol-specific WGs. In particular, the L2VPN WG >>> >> may define extensions to pseudowire management mechanisms for VPLS. >>> >> Those extensions will be reviewed by the PWE3 WG to ensure they are >>> >> aligned with the overall design/architecture of PWE3. >>> >> >>> >> The L2VPN WG will not define new encapsulations, control, or resilie= ncy >>> >> mechanisms specifically related to pseudowires. Furthermore, when th= e >>> >> L2VPN solution is based on PWs, the L2VPN WG will not define protoco= l >>> >> inter-working between an L2VPN and native service Layer-2 OAM or >>> >> resiliency mechanisms. The L2VPN WG may define how to operate native >>> >> service-layer control, OAM or resiliency mechanisms on top of an L2V= PN. >>> >> In addition, it may define native data plane and/or control plane >>> >> interworking between an L2VPN and an associated native Layer-2 servi= ce. >>> >> >>> >> The L2VPN WG scope includes the following: >>> >> >>> >> 1. Discovery of PEs participating in a Layer-2 VPN and the associate= d >>> >> topology required for connectivity of the VPLS, VPWS, VPMS or E-VPN >>> >> service. >>> >> >>> >> 2. Signaling of information related to the discovery and membership = of >>> >> PEs within a L2VPN. These procedures must use PWE3 control and >>> >> management procedures, or define requirements for extensions of PWE3 >>> >> protocols to suit the needs of an L2VPN, when the L2VPN operates ove= r >>> >> PWs. Once those requirements have been reviewed by the L2VPN WG, the= y >>> >> should be provided to the PWE3 WG to derive solutions. >>> >> >>> >> 3. MIBs for Layer-2 VPN solutions. >>> >> >>> >> 4. Specification of requirements, framework and solutions that >>> >> facilitate Operations Administration and Management (OAM) of any typ= e of >>> >> L2VPN. >>> >> >>> >> 5. Mechanisms to permit optimization of multicast data traffic withi= n >>> >> an L2VPN. >>> >> >>> >> 6. If transport does not involve PWs, mechanisms that support >>> >> load-balancing/multipathing between PEs interconnecting a Layer-2 >>> >> service using an L2VPN across the MPLS PSN. >>> >> >>> >> 7. requirements for the multi-homing of CEs to several VPLS or >>> >> E-VPN PEs, inclusive of active/backup and active/active (load-sharin= g) >>> >> configurations. Based on these requirements define VPLS or E-VPN con= trol >>> >> plane solutions for achieving fast convergence after failure of an a= ctive >>> >> path in the PSN or on the AC side. >>> >> >>> >> 8. Enhancements to increase the scalability of the Control Plane and >>> >> Data Plane of L2VPN PE nodes, and of core nodes that provide transpo= rt >>> >> services for L2VPN. >>> >> >>> >> 9. Requirements and solutions for Auto-Discovery and Signaling of >>> >> Inter-AS L2VPNs, in addition to Inter-AS solutions for >>> multicast-optimized >>> >> L2VPNs. >>> >> >>> >> 10. Requirements and solutions for supporting "E-Tree" services usin= g >>> >> VPLS. >>> >> >>> >> 11. Extensions to L2VPN protocols and RFCs necessary to create an MP= LS >>> >> Transport Profile (MPLS-TP). The work on the MPLS TP will be coordin= ated >>> >> between four primary working groups (MPLS, PWE3, L2VPN and CCAMP) th= at >>> are >>> >> chartered to do MPLS TP work. >>> >> >>> >> Milestones: >>> >> >>> >> Done Submit an I-D describing MIB for VPLS >>> >> Done Submit an I-D describing MIB for VPWS >>> >> Done Submit an I-D on OAM requirements for VPLS >>> >> Done Submit an I-D on OAM requirements for VPWS >>> >> Done Submit L2 requirements to IESG for publication as >>> Informational >>> >> RFC >>> >> Done Submit L2 framework to IESG for publication as Informati= onal >>> RFC >>> >> Done Identify VPLS and VPWS solutions for the WG >>> >> Done Submit VPLS solution documents to IESG >>> >> Done Submit VPWS solution documents to IESG >>> >> Done Submit Auto-Discovery and Signaling for Intra-AS and Int= er-AS >>> >> VPLS and VPWS Layer-2 VPNs >>> >> Jul 2011 Submit IP-only L2VPN solution documents to IESG >>> >> Jul 2011 Submit OAM solutions for VPWS to IESG >>> >> Jul 2011 Submit OAM solutions for VPLS to IESG >>> >> Jul 2011 Submit signaling solution for multicast-optimized VPLS t= o >>> IESG >>> >> Jul 2011 Submit I-D on Virtual Private Multicast Service (VPMS) >>> >> requirements to IESG >>> >> Jul 2011 Submit MIB for VPLS to IESG >>> >> Jul 2011 Submit MIB for VPWS to IESG >>> >> Nov 2011 Submit scalability solutions for VPLS Data-Plane to IESG >>> >> Nov 2011 Submit scalability solutions for VPLS Control-Plane to I= ESG >>> >> Mar 2012 Submit MIB for IP-only L2VPN to IESG >>> >> Mar 2012 Submit OAM solutions for IP-only L2VPN to IESG >>> >> Mar 2012 Submit Auto-Discovery solution for VPMS to IESG >>> >> Mar 2012 Submit VPLS service convergence improvement solutions to= IESG >>> >> Mar 2012 Submit VPLS multi-homing solutions to IESG >>> >> Mar 2012 Submit E-Tree documents to IESG >>> >> Mar 2012 Submit E-VPN requirements/framework to IESG >>> >> Jul 2012 Submit E-VPN solution to IESG >>> >> Nov 2012 Submit E-VPN MIB/OAM to IESG >>> >> >>> >> ----------------- >>> >> >>> >> On 18/03/2011 17:41, "Giles Heron" wrote: >>> >> >>>> >>> We plan to re-charter the L2VPN WG - primarily to bring E-VPN and >>>> E-Tree >>>> >>> in-scope. >>>> >>> >>>> >>> Please find attached a draft charter for discussion both on this l= ist >>>> and at >>>> >>> IETF 80 in Prague. >>>> >>> >>>> >>> Nabil and Giles >>>> >>> >>>> >>> >>> >> >>> >> >> > >=20 >=20 >=20 >=20 --B_3384433121_2537818 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: Draft of new L2VPN WG Charter Let’s see what others say.

I’m off on vacation for the next 10 days but will discuss the charter= again with Nabil and the ADs when I return.

Giles

On 31/03/2011 15:57, "Shah, Himanshu" <hshah@ciena.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>

I agree with Ben (and apparently yours) concern.
I suggest we remove that sentence.
/himanshu

-----Original Message-----
From: l2vpn-bounces@ietf.org on behalf= of Giles Heron
Sent: Thu 3/31/2011 10:49 AM
To: Benson Schliesser; l2vpn@ietf.org
Subject: Re: Draft of new L2VPN WG Charter

Hi Benson,

This would be provider-provisioned L2VPN environments (whether data-centre<= BR> interconnect, or scaling of a large multi-tenant data-centre).

Personally I'm not sure we need the sentence there, but others were keen to=
mention the data-centre requirements.

Giles

On 31/03/2011 15:37, "Benson Schliesser" <bschlies@cisco.com> wrote:

> Hi, Giles.
>
> I have a clarifying question about the first paragraph:  What is = the purpose
> of the 2nd sentence, bringing cloud and DC requirements into the mix?<= BR> > Assuming this is meant to include non-provider L2VPN environments (lik= e
> enterprise data centers), then why not just remove the phrase
> "provider-provisioned" from the first sentence?  Otherw= ise, it seems
> redundant.
>
> This is a real question, not a suggestion at this time.
>
> Thanks,
> -Benson
>
>
>
> On 3/18/11 1:21 PM, "Giles Heron" <giles.heron@gmail.com> wrote:
>
>> OK - looks like the attachment didn't come through as intended. &n= bsp;My
>> apologies.
>>
>> Text inline:
>>
>> ----------------
>>
>> The L2VPN working group is responsible for defining and specifying= a
>> limited number of solutions for supporting provider-provisioned La= yer-2
>> Virtual Private Networks (L2VPNs). It will also address requiremen= ts driven
>> by cloud computing services and data centers as they apply to Laye= r-2
>> VPN services.
>>
>> Layer-2 VPNs defined by L2VPN operate over pseudowires (PWs) as >> defined by the PWE3 WG or over MPLS PSN tunnels. A L2VPN emulates = a
>> "native" service over a PSN that is adequately faithful = to, but may not
>> be entirely indistinguishable from the native service itself. Furt= her,
>> following in the "edge-to-edge" nature of the  serv= ice, the L2VPN WG will
>> not define any mechanisms which exert control over the underlying = PSN.
>> When necessary it may, however, recommend or require the use of ex= isting
>> PSN QoS and path control mechanisms between the PEs which provide = the
>> L2VPN connectivity.
>>
>> Layer-2 VPNs comprise the following:
>>
>> 1. Virtual Private LAN Service (VPLS) -- A Layer-2 service that em= ulates
>> a switched Ethernet (V)LAN across an MPLS Packet Switched Network = (PSN).
>>
>> 2. Virtual Private Wire Service (VPWS) -- A Layer-2 service that >> provides point-to-point connectivity for a variety of link layers,=
>> including Frame Relay, ATM, Ethernet, PPP, etc., across an MPLS PS= N.
>>
>> 3. Virtual Private Multicast Service (VPMS) -- A Layer-2 service t= hat
>> provides point-to-multipoint connectivity for a variety of link >> layers across an MPLS PSN.
>>
>> 4. IP-only L2VPN – An IP-only service over an MPLS PSN. &nbs= p;The WG will
>> address two specific types of IP-only L2VPN:
>>
>> a) Point-to-point Layer-2 VPN.  This service is similar to VP= WS, but also
>> supports heterogenous Attachment Circuits at either end of a singl= e
>> point-to-point service.
>>
>> b) Multipoint-to-multipoint Layer-2 VPN.  This service is sim= ilar to VPLS,
>> but learns IP and MAC address bindings from ARPs and broadcast/mul= ticast
>> IP packets.
>>
>> 5. Ethernet VPN (E-VPN) - A Layer-2 technology that emulates an >> Ethernet (V)LAN across an MPLS PSN. E-VPN supports load-sharing ac= ross
>> multiple connections from a Layer-2 site to an L2VPN service, and = also
>> supports control plane distribution of MAC addresses and IP to MAC= address
>> bindings in the VPN. E-VPN is primarily targeted to support large-= scale
>> L2VPNs with resiliency requirements not satisfied by other L2VPN s= olutions.
>>
>> 6. E-Tree – a Layer-2 technology defined by the MEF, which p= rovides
>> connectivity between one or more “root” nodes and one = or more
>> “leaf” nodes, with the restriction that leaves may onl= y communicate
>> with roots (and not with each other).
>>
>> L2VPNs will make use of existing IETF specified mechanisms unless = there
>> are technical reasons why the existing mechanisms are insufficient= or
>> unnecessary.
>>
>> The L2VPN WG is responsible for specification of the discovery and=
>> membership of PEs participating in a Layer-2 VPN as well as the >> membership of CE devices for a specific instance of an L2VPN.
>>
>> The L2VPN WG will provide extensions of existing protocols that wi= ll be
>> discussed in protocol-specific WGs. In particular, the L2VPN WG >> may define extensions to pseudowire management mechanisms for VPLS= .
>> Those extensions will be reviewed by the PWE3 WG to ensure they ar= e
>> aligned with the overall design/architecture of PWE3.
>>
>> The L2VPN WG will not define new encapsulations, control, or resil= iency
>> mechanisms specifically related to pseudowires. Furthermore, when = the
>> L2VPN solution is based on PWs, the L2VPN WG will not define proto= col
>> inter-working between an L2VPN and native service Layer-2 OAM or >> resiliency mechanisms. The L2VPN WG may define how to operate nati= ve
>> service-layer control, OAM or resiliency mechanisms on top of an L= 2VPN.
>> In addition, it may define native data plane and/or control plane<= BR> >> interworking between an L2VPN and an associated native Layer-2 ser= vice.
>>
>> The L2VPN WG scope includes the following:
>>
>> 1. Discovery of PEs participating in a Layer-2 VPN and the associa= ted
>>  topology required for connectivity of the VPLS, VPWS, VPMS o= r E-VPN
>>  service.
>>
>> 2. Signaling of information related to the discovery and membershi= p of
>> PEs within a L2VPN. These procedures must use PWE3 control and
>> management procedures, or define requirements for extensions of PW= E3
>> protocols to suit the needs of an L2VPN, when the L2VPN operates o= ver
>> PWs. Once those requirements have been reviewed by the L2VPN WG, t= hey
>> should be provided to the PWE3 WG to derive solutions.
>>
>> 3. MIBs for Layer-2 VPN solutions.
>>
>> 4. Specification of requirements, framework and solutions that
>> facilitate Operations Administration and Management (OAM) of any t= ype of
>> L2VPN.
>>
>> 5. Mechanisms to permit optimization of multicast data traffic wit= hin
>> an L2VPN.
>>
>> 6. If transport does not involve PWs, mechanisms that support
>> load-balancing/multipathing between PEs interconnecting a Layer-2<= BR> >> service using an L2VPN across the MPLS PSN.
>>
>> 7. requirements for the multi-homing of CEs to several VPLS or
>> E-VPN PEs, inclusive of active/backup and active/active (load-shar= ing)
>> configurations. Based on these requirements define VPLS or E-VPN c= ontrol
>> plane solutions for achieving fast convergence after failure of an= active
>> path in the PSN or on the AC side.
>>
>> 8. Enhancements to increase the scalability of the Control Plane a= nd
>> Data Plane of L2VPN PE nodes, and of core nodes that provide trans= port
>> services for L2VPN.
>>
>> 9. Requirements and solutions for Auto-Discovery and Signaling of<= BR> >> Inter-AS L2VPNs, in addition to Inter-AS solutions for multicast-o= ptimized
>> L2VPNs.
>>
>> 10. Requirements and solutions for supporting "E-Tree" s= ervices using
>> VPLS.
>>
>> 11. Extensions to L2VPN protocols and RFCs necessary to create an = MPLS
>> Transport Profile (MPLS-TP). The work on the MPLS TP will be coord= inated
>> between four primary working groups (MPLS, PWE3, L2VPN and CCAMP) = that are
>> chartered to do MPLS TP work.
>>
>> Milestones:
>>
>> Done        Submit an I-D descr= ibing MIB for VPLS
>> Done        Submit an I-D descr= ibing MIB for VPWS
>> Done        Submit an I-D on OA= M requirements for VPLS
>> Done        Submit an I-D on OA= M requirements for VPWS
>> Done        Submit L2 requireme= nts to IESG for publication as Informational
>> RFC
>> Done        Submit L2 framework= to IESG for publication as Informational RFC
>> Done        Identify VPLS and V= PWS solutions for the WG
>> Done        Submit VPLS solutio= n documents to IESG
>> Done        Submit VPWS solutio= n documents to IESG
>> Done        Submit Auto-Discove= ry and Signaling for Intra-AS and Inter-AS
>>            =  VPLS and VPWS Layer-2 VPNs
>> Jul 2011    Submit IP-only L2VPN solution documents= to IESG
>> Jul 2011    Submit OAM solutions for VPWS to IESG >> Jul 2011    Submit OAM solutions for VPLS to IESG >> Jul 2011    Submit signaling solution for multicast= -optimized VPLS to IESG
>> Jul 2011    Submit I-D on Virtual Private Multicast= Service (VPMS)
>>            =  requirements to IESG
>> Jul 2011    Submit MIB for VPLS to IESG
>> Jul 2011    Submit MIB for VPWS to IESG
>> Nov 2011    Submit scalability solutions for VPLS D= ata-Plane to IESG
>> Nov 2011    Submit scalability solutions for VPLS C= ontrol-Plane to IESG
>> Mar 2012    Submit MIB for IP-only L2VPN to IESG >> Mar 2012    Submit OAM solutions for IP-only L2VPN = to IESG
>> Mar 2012    Submit Auto-Discovery solution for VPMS= to IESG
>> Mar 2012    Submit VPLS service convergence improve= ment solutions to IESG
>> Mar 2012    Submit VPLS multi-homing solutions to I= ESG
>> Mar 2012    Submit E-Tree documents to IESG
>> Mar 2012    Submit E-VPN requirements/framework to = IESG
>> Jul 2012    Submit E-VPN solution to IESG
>> Nov 2012    Submit E-VPN MIB/OAM to IESG
>>
>> -----------------
>>
>> On 18/03/2011 17:41, "Giles Heron" <giles.heron@gmail.com> wrote:
>>
>>> We plan to re-charter the L2VPN WG - primarily to bring E-VPN = and E-Tree
>>> in-scope.
>>>
>>> Please find attached a draft charter for discussion both on th= is list and at
>>> IETF 80 in Prague.
>>>
>>> Nabil and Giles
>>>
>>>
>>
>>
>




--B_3384433121_2537818-- From xuxh@huawei.com Thu Mar 31 08:16:56 2011 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 5400B3A6B20 for ; Thu, 31 Mar 2011 08:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.057 X-Spam-Level: **** X-Spam-Status: No, score=4.057 tagged_above=-999 required=5 tests=[AWL=-2.538, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_MLB_Stock6=1.56, SARE_SUB_ENC_GB2312=1.345] 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 q8I8-acHwSQ5 for ; Thu, 31 Mar 2011 08:16:55 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 06C203A680E for ; Thu, 31 Mar 2011 08:16:55 -0700 (PDT) Received: from huawei.com (usaml01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIX00BKPH6Y8U@usaga01-in.huawei.com> for l2vpn@ietf.org; Thu, 31 Mar 2011 10:18:34 -0500 (CDT) Received: from huawei.com ([172.17.1.87]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIX00A7YH6WP0@usaga01-in.huawei.com> for l2vpn@ietf.org; Thu, 31 Mar 2011 10:18:34 -0500 (CDT) Received: from [172.24.1.52] (Forwarded-For: [130.129.64.179]) by szxmc02-in.huawei.com (mshttpd); Thu, 31 Mar 2011 17:18:26 +0200 Date: Thu, 31 Mar 2011 17:18:26 +0200 From: xuxiaohu 41208 Subject: =?gb2312?B?u9i4tA==?=:RE: Draft of new L2VPN WG Charter In-reply-to: To: "Shah, Himanshu" Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: quoted-printable Content-disposition: inline X-Accept-Language: zh-CN Priority: normal References: 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: Thu, 31 Mar 2011 15:16:56 -0000 Agree=2E Maybe a neutral definition of such special VPLS is more acceptab= le=2C such as=2C =22MAC Announcement based VPLS=22=2C in contrast to the = existing VPLS which uses data-driven MAC learning=2E E-VPN is just a spec= ial instance of such catagory=2C which uses BGP to announce MAC reachabil= ity information=2E Best regards=2C Xiaohu ----- =D4=AD=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A =22Shah=2C Himanshu=22 =3Chshah=40ciena=2Ecom=3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=CB=C4=2C =C8=FD=D4=C2 31=C8=D5=2C 2011 =CF=C2= =CE=E74=3A58 =D6=F7=CC=E2=3A RE=3A Draft of new L2VPN WG Charter =CA=D5=BC=FE=C8=CB=3A Benson Schliesser =3Cbschlies=40cisco=2Ecom=3E=2C G= iles Heron =3Cgiles=2Eheron=40gmail=2Ecom=3E=2C l2vpn=40ietf=2Eorg =3E = =3E Another point for item 5 - =3E = =3E =22and also supports control plane distribution of MAC addresses = =3E and IP to MAC address bindings in the VPN=2E=22 =3E = =3E Well=2C Item 4 also supports control plane distribution of MAC addres= ses =3E and IP to MAC address bindings in the VPN=2E =3E = =3E I do not support having this explicit phrase in the item 5=2E What = =3E is the =3E justification=3F It is not a new concept=2E =3E = =3E /himanshu =3E = =3E -----Original Message----- =3E From=3A l2vpn-bounces=40ietf=2Eorg on behalf of Benson Schliesser =3E Sent=3A Thu 3/31/2011 10=3A37 AM =3E To=3A Giles Heron=3B l2vpn=40ietf=2Eorg =3E Subject=3A Re=3A Draft of new L2VPN WG Charter =3E = =3E Hi=2C Giles=2E =3E = =3E I have a clarifying question about the first paragraph=3A What is = =3E the purpose =3E of the 2nd sentence=2C bringing cloud and DC requirements into the mi= x=3F =3E Assuming this is meant to include non-provider L2VPN environments = =3E (likeenterprise data centers)=2C then why not just remove the phrase =3E =22provider-provisioned=22 from the first sentence=3F Otherwise=2C i= t seems =3E redundant=2E =3E = =3E This is a real question=2C not a suggestion at this time=2E =3E = =3E Thanks=2C =3E -Benson =3E = =3E = =3E = =3E On 3/18/11 1=3A21 PM=2C =22Giles Heron=22 =3Cgiles=2Eheron=40gmail=2E= com=3E wrote=3A =3E = =3E =3E OK - looks like the attachment didn=27t come through as intended=2E= My =3E =3E apologies=2E =3E =3E = =3E =3E Text inline=3A =3E =3E = =3E =3E ---------------- =3E =3E = =3E =3E The L2VPN working group is responsible for defining and = =3E specifying a =3E =3E limited number of solutions for supporting provider-provisioned = =3E Layer-2 =3E =3E Virtual Private Networks (L2VPNs)=2E It will also address = =3E requirements driven =3E =3E by cloud computing services and data centers as they apply to = =3E Layer-2 =3E =3E VPN services=2E =3E =3E = =3E =3E Layer-2 VPNs defined by L2VPN operate over pseudowires (PWs) as =3E =3E defined by the PWE3 WG or over MPLS PSN tunnels=2E A L2VPN = =3E emulates a =3E =3E =22native=22 service over a PSN that is adequately faithful to=2C= but = =3E may not =3E =3E be entirely indistinguishable from the native service itself=2E = =3E Further=2C=3E following in the =22edge-to-edge=22 nature of the serv= ice=2C = =3E the L2VPN WG will =3E =3E not define any mechanisms which exert control over the = =3E underlying PSN=2E =3E =3E When necessary it may=2C however=2C recommend or require the use = of = =3E existing=3E PSN QoS and path control mechanisms between the PEs = =3E which provide the =3E =3E L2VPN connectivity=2E =3E =3E = =3E =3E Layer-2 VPNs comprise the following=3A =3E =3E = =3E =3E 1=2E Virtual Private LAN Service (VPLS) -- A Layer-2 service that= = =3E emulates=3E a switched Ethernet (V)LAN across an MPLS Packet = =3E Switched Network (PSN)=2E =3E =3E = =3E =3E 2=2E Virtual Private Wire Service (VPWS) -- A Layer-2 service tha= t =3E =3E provides point-to-point connectivity for a variety of link layers= =2C =3E =3E including Frame Relay=2C ATM=2C Ethernet=2C PPP=2C etc=2E=2C acro= ss an MPLS PSN=2E =3E =3E = =3E =3E 3=2E Virtual Private Multicast Service (VPMS) -- A Layer-2 servic= e = =3E that=3E provides point-to-multipoint connectivity for a variety of li= nk =3E =3E layers across an MPLS PSN=2E =3E =3E = =3E =3E 4=2E IP-only L2VPN =3F An IP-only service over an MPLS PSN=2E Th= e WG will =3E =3E address two specific types of IP-only L2VPN=3A =3E =3E = =3E =3E a) Point-to-point Layer-2 VPN=2E This service is similar to VPWS= =2C = =3E but also =3E =3E supports heterogenous Attachment Circuits at either end of a sing= le =3E =3E point-to-point service=2E =3E =3E = =3E =3E b) Multipoint-to-multipoint Layer-2 VPN=2E This service is = =3E similar to VPLS=2C =3E =3E but learns IP and MAC address bindings from ARPs and = =3E broadcast/multicast=3E IP packets=2E =3E =3E = =3E =3E 5=2E Ethernet VPN (E-VPN) - A Layer-2 technology that emulates an= =3E =3E Ethernet (V)LAN across an MPLS PSN=2E E-VPN supports load-sharing= = =3E across=3E multiple connections from a Layer-2 site to an L2VPN = =3E service=2C and also =3E =3E supports control plane distribution of MAC addresses and IP to = =3E MAC address =3E =3E bindings in the VPN=2E E-VPN is primarily targeted to support = =3E large-scale =3E =3E L2VPNs with resiliency requirements not satisfied by other L2VPN = =3E solutions=2E=3E = =3E =3E 6=2E E-Tree =3F a Layer-2 technology defined by the MEF=2C which = provides =3E =3E connectivity between one or more =3Froot=3F nodes and one or more= =3E =3E =3Fleaf=3F nodes=2C with the restriction that leaves may only com= municate =3E =3E with roots (and not with each other)=2E =3E =3E = =3E =3E L2VPNs will make use of existing IETF specified mechanisms = =3E unless there =3E =3E are technical reasons why the existing mechanisms are = =3E insufficient or =3E =3E unnecessary=2E =3E =3E = =3E =3E The L2VPN WG is responsible for specification of the discovery an= d =3E =3E membership of PEs participating in a Layer-2 VPN as well as the =3E =3E membership of CE devices for a specific instance of an L2VPN=2E =3E =3E = =3E =3E The L2VPN WG will provide extensions of existing protocols that = =3E will be =3E =3E discussed in protocol-specific WGs=2E In particular=2C the L2VPN = WG =3E =3E may define extensions to pseudowire management mechanisms for VPL= S=2E =3E =3E Those extensions will be reviewed by the PWE3 WG to ensure they a= re =3E =3E aligned with the overall design/architecture of PWE3=2E =3E =3E = =3E =3E The L2VPN WG will not define new encapsulations=2C control=2C or = =3E resiliency=3E mechanisms specifically related to pseudowires=2E = =3E Furthermore=2C when the =3E =3E L2VPN solution is based on PWs=2C the L2VPN WG will not define = =3E protocol=3E inter-working between an L2VPN and native service Layer- =3E 2 OAM or =3E =3E resiliency mechanisms=2E The L2VPN WG may define how to operate n= ative =3E =3E service-layer control=2C OAM or resiliency mechanisms on top of a= n = =3E L2VPN=2E=3E In addition=2C it may define native data plane and/or = =3E control plane =3E =3E interworking between an L2VPN and an associated native Layer-2 = =3E service=2E=3E = =3E =3E The L2VPN WG scope includes the following=3A =3E =3E = =3E =3E 1=2E Discovery of PEs participating in a Layer-2 VPN and the = =3E associated=3E topology required for connectivity of the VPLS=2C VPWS= =2C = =3E VPMS or E-VPN =3E =3E service=2E =3E =3E = =3E =3E 2=2E Signaling of information related to the discovery and = =3E membership of =3E =3E PEs within a L2VPN=2E These procedures must use PWE3 control and =3E =3E management procedures=2C or define requirements for extensions of= PWE3 =3E =3E protocols to suit the needs of an L2VPN=2C when the L2VPN operate= s = =3E over=3E PWs=2E Once those requirements have been reviewed by the L2VP= N = =3E WG=2C they =3E =3E should be provided to the PWE3 WG to derive solutions=2E =3E =3E = =3E =3E 3=2E MIBs for Layer-2 VPN solutions=2E =3E =3E = =3E =3E 4=2E Specification of requirements=2C framework and solutions tha= t =3E =3E facilitate Operations Administration and Management (OAM) of any = =3E type of =3E =3E L2VPN=2E =3E =3E = =3E =3E 5=2E Mechanisms to permit optimization of multicast data traffic = =3E within=3E an L2VPN=2E =3E =3E = =3E =3E 6=2E If transport does not involve PWs=2C mechanisms that support= =3E =3E load-balancing/multipathing between PEs interconnecting a Layer-2= =3E =3E service using an L2VPN across the MPLS PSN=2E =3E =3E = =3E =3E 7=2E requirements for the multi-homing of CEs to several VPLS or =3E =3E E-VPN PEs=2C inclusive of active/backup and active/active (load- =3E sharing)=3E configurations=2E Based on these requirements define VPLS= = =3E or E-VPN control =3E =3E plane solutions for achieving fast convergence after failure of = =3E an active =3E =3E path in the PSN or on the AC side=2E =3E =3E = =3E =3E 8=2E Enhancements to increase the scalability of the Control Plan= e and =3E =3E Data Plane of L2VPN PE nodes=2C and of core nodes that provide = =3E transport=3E services for L2VPN=2E =3E =3E = =3E =3E 9=2E Requirements and solutions for Auto-Discovery and Signaling = of =3E =3E Inter-AS L2VPNs=2C in addition to Inter-AS solutions for multicas= t- =3E optimized=3E L2VPNs=2E =3E =3E = =3E =3E 10=2E Requirements and solutions for supporting =22E-Tree=22 serv= ices = =3E using=3E VPLS=2E = =3E =3E = =3E =3E 11=2E Extensions to L2VPN protocols and RFCs necessary to create = =3E an MPLS =3E =3E Transport Profile (MPLS-TP)=2E The work on the MPLS TP will be = =3E coordinated=3E between four primary working groups (MPLS=2C PWE3=2C = =3E L2VPN and CCAMP) that are =3E =3E chartered to do MPLS TP work=2E =3E =3E = =3E =3E Milestones=3A =3E =3E = =3E =3E Done Submit an I-D describing MIB for VPLS =3E =3E Done Submit an I-D describing MIB for VPWS =3E =3E Done Submit an I-D on OAM requirements for VPLS =3E =3E Done Submit an I-D on OAM requirements for VPWS =3E =3E Done Submit L2 requirements to IESG for publication as = =3E Informational=3E RFC =3E =3E Done Submit L2 framework to IESG for publication as = =3E Informational RFC =3E =3E Done Identify VPLS and VPWS solutions for the WG =3E =3E Done Submit VPLS solution documents to IESG =3E =3E Done Submit VPWS solution documents to IESG =3E =3E Done Submit Auto-Discovery and Signaling for Intra-AS and = =3E Inter-AS =3E =3E VPLS and VPWS Layer-2 VPNs =3E =3E Jul 2011 Submit IP-only L2VPN solution documents to IESG =3E =3E Jul 2011 Submit OAM solutions for VPWS to IESG =3E =3E Jul 2011 Submit OAM solutions for VPLS to IESG =3E =3E Jul 2011 Submit signaling solution for multicast-optimized = =3E VPLS to IESG =3E =3E Jul 2011 Submit I-D on Virtual Private Multicast Service (VPMS= ) =3E =3E requirements to IESG =3E =3E Jul 2011 Submit MIB for VPLS to IESG =3E =3E Jul 2011 Submit MIB for VPWS to IESG =3E =3E Nov 2011 Submit scalability solutions for VPLS Data-Plane to I= ESG =3E =3E Nov 2011 Submit scalability solutions for VPLS Control-Plane = =3E to IESG =3E =3E Mar 2012 Submit MIB for IP-only L2VPN to IESG =3E =3E Mar 2012 Submit OAM solutions for IP-only L2VPN to IESG =3E =3E Mar 2012 Submit Auto-Discovery solution for VPMS to IESG =3E =3E Mar 2012 Submit VPLS service convergence improvement = =3E solutions to IESG =3E =3E Mar 2012 Submit VPLS multi-homing solutions to IESG =3E =3E Mar 2012 Submit E-Tree documents to IESG =3E =3E Mar 2012 Submit E-VPN requirements/framework to IESG =3E =3E Jul 2012 Submit E-VPN solution to IESG =3E =3E Nov 2012 Submit E-VPN MIB/OAM to IESG =3E =3E = =3E =3E ----------------- =3E =3E = =3E =3E On 18/03/2011 17=3A41=2C =22Giles Heron=22 =3Cgiles=2Eheron=40gma= il=2Ecom=3E wrote=3A =3E =3E = =3E =3E=3E We plan to re-charter the L2VPN WG - primarily to bring E-VPN = =3E and E-Tree =3E =3E=3E in-scope=2E =3E =3E=3E = =3E =3E=3E Please find attached a draft charter for discussion both on = =3E this list and at =3E =3E=3E IETF 80 in Prague=2E =3E =3E=3E = =3E =3E=3E Nabil and Giles =3E =3E=3E = =3E =3E=3E = =3E =3E = =3E =3E = =3E = =3E = =3E From prvs=7071a0f4f3=hshah@ciena.com Thu Mar 31 08:19:28 2011 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 A68753A6AD7 for ; Thu, 31 Mar 2011 08:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.964 X-Spam-Level: X-Spam-Status: No, score=-0.964 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SARE_MLB_Stock6=1.56] 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 HQQ8eOKGl+RR for ; Thu, 31 Mar 2011 08:19:26 -0700 (PDT) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) by core3.amsl.com (Postfix) with ESMTP id 7E81E3A6B4B for ; Thu, 31 Mar 2011 08:19:26 -0700 (PDT) Received: from pps.filterd (m0001124 [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.14.3/8.14.3) with SMTP id p2VFKw4w022824; Thu, 31 Mar 2011 11:21:05 -0400 Received: from mdwexght01.ciena.com (LIN1-118-36-28.ciena.com [63.118.36.28]) by mx0b-00103a01.pphosted.com with ESMTP id vcuuh027u-4 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 31 Mar 2011 11:21:04 -0400 Received: from mdmxm05.ciena.com (63.118.39.23) by MDWEXGHT01.ciena.com (10.4.140.138) with Microsoft SMTP Server id 8.1.436.0; Thu, 31 Mar 2011 11:21:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBEFB7.3F2C019B" Subject: RE: Draft of new L2VPN WG Charter Date: Thu, 31 Mar 2011 11:21:02 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft of new L2VPN WG Charter Thread-Index: AcvvtA2JzqTxhFkJSFamDqHmBDPKfwAAiweP References: From: "Shah, Himanshu" To: "Thomas Nadeau" , "Giles Heron" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-03-31_07:2011-03-31, 2011-03-31, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1103310066 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: Thu, 31 Mar 2011 15:19:28 -0000 ------_=_NextPart_001_01CBEFB7.3F2C019B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable My understanding is that, as a first step, the problem scope needs to be understood. Solutions, if any required, could follow only after the problem is well understood. Solutions are part of ARMD charter but only after first step is completed. Although, it appears that L2VPN group has already acknowledged and understood the problem well enough to propose solutions?? /himanshu -----Original Message----- From: l2vpn-bounces@ietf.org on behalf of Thomas Nadeau Sent: Thu 3/31/2011 10:57 AM To: Giles Heron Cc: l2vpn@ietf.org Subject: Re: Draft of new L2VPN WG Charter =20 On Mar 31, 2011, at 10:49 AM, Giles Heron wrote: > Hi Benson, >=20 > This would be provider-provisioned L2VPN environments (whether = data-centre > interconnect, or scaling of a large multi-tenant data-centre). >=20 > Personally I'm not sure we need the sentence there, but others were = keen to > mention the data-centre requirements. I think that is meant to explicitly field requirements for solutions=20 that come from ARMD/etc... into the WG, since they cannot build their = own=20 solutions. While that isn't implicitly handled in the existing charter, = I do not know either.=20 --Tom >=20 > Giles >=20 > On 31/03/2011 15:37, "Benson Schliesser" wrote: >=20 >> Hi, Giles. >>=20 >> I have a clarifying question about the first paragraph: What is the = purpose >> of the 2nd sentence, bringing cloud and DC requirements into the mix? >> Assuming this is meant to include non-provider L2VPN environments = (like >> enterprise data centers), then why not just remove the phrase >> "provider-provisioned" from the first sentence? Otherwise, it seems >> redundant. >>=20 >> This is a real question, not a suggestion at this time. >>=20 >> Thanks, >> -Benson >>=20 >>=20 >>=20 >> On 3/18/11 1:21 PM, "Giles Heron" wrote: >>=20 >>> OK - looks like the attachment didn't come through as intended. My >>> apologies. >>>=20 >>> Text inline: >>>=20 >>> ---------------- >>>=20 >>> The L2VPN working group is responsible for defining and specifying a >>> limited number of solutions for supporting provider-provisioned = Layer-2 >>> Virtual Private Networks (L2VPNs). It will also address requirements = driven >>> by cloud computing services and data centers as they apply to = Layer-2 >>> VPN services. >>>=20 >>> Layer-2 VPNs defined by L2VPN operate over pseudowires (PWs) as >>> defined by the PWE3 WG or over MPLS PSN tunnels. A L2VPN emulates a >>> "native" service over a PSN that is adequately faithful to, but may = not >>> be entirely indistinguishable from the native service itself. = Further, >>> following in the "edge-to-edge" nature of the service, the L2VPN WG = will >>> not define any mechanisms which exert control over the underlying = PSN. >>> When necessary it may, however, recommend or require the use of = existing >>> PSN QoS and path control mechanisms between the PEs which provide = the >>> L2VPN connectivity. >>>=20 >>> Layer-2 VPNs comprise the following: >>>=20 >>> 1. Virtual Private LAN Service (VPLS) -- A Layer-2 service that = emulates >>> a switched Ethernet (V)LAN across an MPLS Packet Switched Network = (PSN). >>>=20 >>> 2. Virtual Private Wire Service (VPWS) -- A Layer-2 service that >>> provides point-to-point connectivity for a variety of link layers, >>> including Frame Relay, ATM, Ethernet, PPP, etc., across an MPLS PSN. >>>=20 >>> 3. Virtual Private Multicast Service (VPMS) -- A Layer-2 service = that >>> provides point-to-multipoint connectivity for a variety of link >>> layers across an MPLS PSN. >>>=20 >>> 4. IP-only L2VPN - An IP-only service over an MPLS PSN. The WG will >>> address two specific types of IP-only L2VPN: >>>=20 >>> a) Point-to-point Layer-2 VPN. This service is similar to VPWS, but = also >>> supports heterogenous Attachment Circuits at either end of a single >>> point-to-point service. >>>=20 >>> b) Multipoint-to-multipoint Layer-2 VPN. This service is similar to = VPLS, >>> but learns IP and MAC address bindings from ARPs and = broadcast/multicast >>> IP packets. >>>=20 >>> 5. Ethernet VPN (E-VPN) - A Layer-2 technology that emulates an >>> Ethernet (V)LAN across an MPLS PSN. E-VPN supports load-sharing = across >>> multiple connections from a Layer-2 site to an L2VPN service, and = also >>> supports control plane distribution of MAC addresses and IP to MAC = address >>> bindings in the VPN. E-VPN is primarily targeted to support = large-scale >>> L2VPNs with resiliency requirements not satisfied by other L2VPN = solutions. >>>=20 >>> 6. E-Tree - a Layer-2 technology defined by the MEF, which provides >>> connectivity between one or more "root" nodes and one or more >>> "leaf" nodes, with the restriction that leaves may only communicate >>> with roots (and not with each other). >>>=20 >>> L2VPNs will make use of existing IETF specified mechanisms unless = there >>> are technical reasons why the existing mechanisms are insufficient = or >>> unnecessary. >>>=20 >>> The L2VPN WG is responsible for specification of the discovery and >>> membership of PEs participating in a Layer-2 VPN as well as the >>> membership of CE devices for a specific instance of an L2VPN. >>>=20 >>> The L2VPN WG will provide extensions of existing protocols that will = be >>> discussed in protocol-specific WGs. In particular, the L2VPN WG >>> may define extensions to pseudowire management mechanisms for VPLS. >>> Those extensions will be reviewed by the PWE3 WG to ensure they are >>> aligned with the overall design/architecture of PWE3. >>>=20 >>> The L2VPN WG will not define new encapsulations, control, or = resiliency >>> mechanisms specifically related to pseudowires. Furthermore, when = the >>> L2VPN solution is based on PWs, the L2VPN WG will not define = protocol >>> inter-working between an L2VPN and native service Layer-2 OAM or >>> resiliency mechanisms. The L2VPN WG may define how to operate native >>> service-layer control, OAM or resiliency mechanisms on top of an = L2VPN. >>> In addition, it may define native data plane and/or control plane >>> interworking between an L2VPN and an associated native Layer-2 = service. >>>=20 >>> The L2VPN WG scope includes the following: >>>=20 >>> 1. Discovery of PEs participating in a Layer-2 VPN and the = associated >>> topology required for connectivity of the VPLS, VPWS, VPMS or E-VPN >>> service. >>>=20 >>> 2. Signaling of information related to the discovery and membership = of >>> PEs within a L2VPN. These procedures must use PWE3 control and >>> management procedures, or define requirements for extensions of PWE3 >>> protocols to suit the needs of an L2VPN, when the L2VPN operates = over >>> PWs. Once those requirements have been reviewed by the L2VPN WG, = they >>> should be provided to the PWE3 WG to derive solutions. >>>=20 >>> 3. MIBs for Layer-2 VPN solutions. >>>=20 >>> 4. Specification of requirements, framework and solutions that >>> facilitate Operations Administration and Management (OAM) of any = type of >>> L2VPN. >>>=20 >>> 5. Mechanisms to permit optimization of multicast data traffic = within >>> an L2VPN. >>>=20 >>> 6. If transport does not involve PWs, mechanisms that support >>> load-balancing/multipathing between PEs interconnecting a Layer-2 >>> service using an L2VPN across the MPLS PSN. >>>=20 >>> 7. requirements for the multi-homing of CEs to several VPLS or >>> E-VPN PEs, inclusive of active/backup and active/active = (load-sharing) >>> configurations. Based on these requirements define VPLS or E-VPN = control >>> plane solutions for achieving fast convergence after failure of an = active >>> path in the PSN or on the AC side. >>>=20 >>> 8. Enhancements to increase the scalability of the Control Plane and >>> Data Plane of L2VPN PE nodes, and of core nodes that provide = transport >>> services for L2VPN. >>>=20 >>> 9. Requirements and solutions for Auto-Discovery and Signaling of >>> Inter-AS L2VPNs, in addition to Inter-AS solutions for = multicast-optimized >>> L2VPNs. >>>=20 >>> 10. Requirements and solutions for supporting "E-Tree" services = using >>> VPLS.=20 >>>=20 >>> 11. Extensions to L2VPN protocols and RFCs necessary to create an = MPLS >>> Transport Profile (MPLS-TP). The work on the MPLS TP will be = coordinated >>> between four primary working groups (MPLS, PWE3, L2VPN and CCAMP) = that are >>> chartered to do MPLS TP work. >>>=20 >>> Milestones: >>>=20 >>> Done Submit an I-D describing MIB for VPLS >>> Done Submit an I-D describing MIB for VPWS >>> Done Submit an I-D on OAM requirements for VPLS >>> Done Submit an I-D on OAM requirements for VPWS >>> Done Submit L2 requirements to IESG for publication as = Informational >>> RFC >>> Done Submit L2 framework to IESG for publication as = Informational RFC >>> Done Identify VPLS and VPWS solutions for the WG >>> Done Submit VPLS solution documents to IESG >>> Done Submit VPWS solution documents to IESG >>> Done Submit Auto-Discovery and Signaling for Intra-AS and = Inter-AS >>> VPLS and VPWS Layer-2 VPNs >>> Jul 2011 Submit IP-only L2VPN solution documents to IESG >>> Jul 2011 Submit OAM solutions for VPWS to IESG >>> Jul 2011 Submit OAM solutions for VPLS to IESG >>> Jul 2011 Submit signaling solution for multicast-optimized VPLS = to IESG >>> Jul 2011 Submit I-D on Virtual Private Multicast Service (VPMS) >>> requirements to IESG >>> Jul 2011 Submit MIB for VPLS to IESG >>> Jul 2011 Submit MIB for VPWS to IESG >>> Nov 2011 Submit scalability solutions for VPLS Data-Plane to IESG >>> Nov 2011 Submit scalability solutions for VPLS Control-Plane to = IESG >>> Mar 2012 Submit MIB for IP-only L2VPN to IESG >>> Mar 2012 Submit OAM solutions for IP-only L2VPN to IESG >>> Mar 2012 Submit Auto-Discovery solution for VPMS to IESG >>> Mar 2012 Submit VPLS service convergence improvement solutions to = IESG >>> Mar 2012 Submit VPLS multi-homing solutions to IESG >>> Mar 2012 Submit E-Tree documents to IESG >>> Mar 2012 Submit E-VPN requirements/framework to IESG >>> Jul 2012 Submit E-VPN solution to IESG >>> Nov 2012 Submit E-VPN MIB/OAM to IESG >>>=20 >>> ----------------- >>>=20 >>> On 18/03/2011 17:41, "Giles Heron" wrote: >>>=20 >>>> We plan to re-charter the L2VPN WG - primarily to bring E-VPN and = E-Tree >>>> in-scope. >>>>=20 >>>> Please find attached a draft charter for discussion both on this = list and at >>>> IETF 80 in Prague. >>>>=20 >>>> Nabil and Giles >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >=20 >=20 >=20 ------_=_NextPart_001_01CBEFB7.3F2C019B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Draft of new L2VPN WG Charter

My understanding is that, as a first step, the = problem
scope needs to be understood. Solutions, if any required,
could follow only after the problem is well understood.
Solutions are part of ARMD charter but only after first step
is completed.

Although, it appears that L2VPN group has already acknowledged
and understood the problem well enough to propose solutions??

/himanshu


-----Original Message-----
From: l2vpn-bounces@ietf.org on behalf of Thomas Nadeau
Sent: Thu 3/31/2011 10:57 AM
To: Giles Heron
Cc: l2vpn@ietf.org
Subject: Re: Draft of new L2VPN WG Charter


On Mar 31, 2011, at 10:49 AM, Giles Heron wrote:

> Hi Benson,
>
> This would be provider-provisioned L2VPN environments (whether = data-centre
> interconnect, or scaling of a large multi-tenant data-centre).
>
> Personally I'm not sure we need the sentence there, but others were = keen to
> mention the data-centre requirements.

        I think that is meant to = explicitly field requirements for solutions
that come from ARMD/etc... into the WG, since they cannot build their = own
solutions.  While that isn't implicitly handled in the existing = charter, I
do not know either.

        --Tom


>
> Giles
>
> On 31/03/2011 15:37, "Benson Schliesser" = <bschlies@cisco.com> wrote:
>
>> Hi, Giles.
>>
>> I have a clarifying question about the first paragraph:  = What is the purpose
>> of the 2nd sentence, bringing cloud and DC requirements into = the mix?
>> Assuming this is meant to include non-provider L2VPN = environments (like
>> enterprise data centers), then why not just remove the = phrase
>> "provider-provisioned" from the first sentence?  = Otherwise, it seems
>> redundant.
>>
>> This is a real question, not a suggestion at this time.
>>
>> Thanks,
>> -Benson
>>
>>
>>
>> On 3/18/11 1:21 PM, "Giles Heron" = <giles.heron@gmail.com> wrote:
>>
>>> OK - looks like the attachment didn't come through as = intended.  My
>>> apologies.
>>>
>>> Text inline:
>>>
>>> ----------------
>>>
>>> The L2VPN working group is responsible for defining and = specifying a
>>> limited number of solutions for supporting = provider-provisioned Layer-2
>>> Virtual Private Networks (L2VPNs). It will also address = requirements driven
>>> by cloud computing services and data centers as they apply = to Layer-2
>>> VPN services.
>>>
>>> Layer-2 VPNs defined by L2VPN operate over pseudowires = (PWs) as
>>> defined by the PWE3 WG or over MPLS PSN tunnels. A L2VPN = emulates a
>>> "native" service over a PSN that is adequately = faithful to, but may not
>>> be entirely indistinguishable from the native service = itself. Further,
>>> following in the "edge-to-edge" nature of = the  service, the L2VPN WG will
>>> not define any mechanisms which exert control over the = underlying PSN.
>>> When necessary it may, however, recommend or require the = use of existing
>>> PSN QoS and path control mechanisms between the PEs which = provide the
>>> L2VPN connectivity.
>>>
>>> Layer-2 VPNs comprise the following:
>>>
>>> 1. Virtual Private LAN Service (VPLS) -- A Layer-2 service = that emulates
>>> a switched Ethernet (V)LAN across an MPLS Packet Switched = Network (PSN).
>>>
>>> 2. Virtual Private Wire Service (VPWS) -- A Layer-2 service = that
>>> provides point-to-point connectivity for a variety of link = layers,
>>> including Frame Relay, ATM, Ethernet, PPP, etc., across an = MPLS PSN.
>>>
>>> 3. Virtual Private Multicast Service (VPMS) -- A Layer-2 = service that
>>> provides point-to-multipoint connectivity for a variety of = link
>>> layers across an MPLS PSN.
>>>
>>> 4. IP-only L2VPN - An IP-only service over an MPLS = PSN.  The WG will
>>> address two specific types of IP-only L2VPN:
>>>
>>> a) Point-to-point Layer-2 VPN.  This service is = similar to VPWS, but also
>>> supports heterogenous Attachment Circuits at either end of = a single
>>> point-to-point service.
>>>
>>> b) Multipoint-to-multipoint Layer-2 VPN.  This service = is similar to VPLS,
>>> but learns IP and MAC address bindings from ARPs and = broadcast/multicast
>>> IP packets.
>>>
>>> 5. Ethernet VPN (E-VPN) - A Layer-2 technology that = emulates an
>>> Ethernet (V)LAN across an MPLS PSN. E-VPN supports = load-sharing across
>>> multiple connections from a Layer-2 site to an L2VPN = service, and also
>>> supports control plane distribution of MAC addresses and IP = to MAC address
>>> bindings in the VPN. E-VPN is primarily targeted to support = large-scale
>>> L2VPNs with resiliency requirements not satisfied by other = L2VPN solutions.
>>>
>>> 6. E-Tree - a Layer-2 technology defined by the MEF, which = provides
>>> connectivity between one or more "root" nodes and = one or more
>>> "leaf" nodes, with the restriction that leaves = may only communicate
>>> with roots (and not with each other).
>>>
>>> L2VPNs will make use of existing IETF specified mechanisms = unless there
>>> are technical reasons why the existing mechanisms are = insufficient or
>>> unnecessary.
>>>
>>> The L2VPN WG is responsible for specification of the = discovery and
>>> membership of PEs participating in a Layer-2 VPN as well as = the
>>> membership of CE devices for a specific instance of an = L2VPN.
>>>
>>> The L2VPN WG will provide extensions of existing protocols = that will be
>>> discussed in protocol-specific WGs. In particular, the = L2VPN WG
>>> may define extensions to pseudowire management mechanisms = for VPLS.
>>> Those extensions will be reviewed by the PWE3 WG to ensure = they are
>>> aligned with the overall design/architecture of PWE3.
>>>
>>> The L2VPN WG will not define new encapsulations, control, = or resiliency
>>> mechanisms specifically related to pseudowires. = Furthermore, when the
>>> L2VPN solution is based on PWs, the L2VPN WG will not = define protocol
>>> inter-working between an L2VPN and native service Layer-2 = OAM or
>>> resiliency mechanisms. The L2VPN WG may define how to = operate native
>>> service-layer control, OAM or resiliency mechanisms on top = of an L2VPN.
>>> In addition, it may define native data plane and/or control = plane
>>> interworking between an L2VPN and an associated native = Layer-2 service.
>>>
>>> The L2VPN WG scope includes the following:
>>>
>>> 1. Discovery of PEs participating in a Layer-2 VPN and the = associated
>>> topology required for connectivity of the VPLS, VPWS, VPMS = or E-VPN
>>> service.
>>>
>>> 2. Signaling of information related to the discovery and = membership of
>>> PEs within a L2VPN. These procedures must use PWE3 control = and
>>> management procedures, or define requirements for = extensions of PWE3
>>> protocols to suit the needs of an L2VPN, when the L2VPN = operates over
>>> PWs. Once those requirements have been reviewed by the = L2VPN WG, they
>>> should be provided to the PWE3 WG to derive solutions.
>>>
>>> 3. MIBs for Layer-2 VPN solutions.
>>>
>>> 4. Specification of requirements, framework and solutions = that
>>> facilitate Operations Administration and Management (OAM) = of any type of
>>> L2VPN.
>>>
>>> 5. Mechanisms to permit optimization of multicast data = traffic within
>>> an L2VPN.
>>>
>>> 6. If transport does not involve PWs, mechanisms that = support
>>> load-balancing/multipathing between PEs interconnecting a = Layer-2
>>> service using an L2VPN across the MPLS PSN.
>>>
>>> 7. requirements for the multi-homing of CEs to several VPLS = or
>>> E-VPN PEs, inclusive of active/backup and active/active = (load-sharing)
>>> configurations. Based on these requirements define VPLS or = E-VPN control
>>> plane solutions for achieving fast convergence after = failure of an active
>>> path in the PSN or on the AC side.
>>>
>>> 8. Enhancements to increase the scalability of the Control = Plane and
>>> Data Plane of L2VPN PE nodes, and of core nodes that = provide transport
>>> services for L2VPN.
>>>
>>> 9. Requirements and solutions for Auto-Discovery and = Signaling of
>>> Inter-AS L2VPNs, in addition to Inter-AS solutions for = multicast-optimized
>>> L2VPNs.
>>>
>>> 10. Requirements and solutions for supporting = "E-Tree" services using
>>> VPLS.
>>>
>>> 11. Extensions to L2VPN protocols and RFCs necessary to = create an MPLS
>>> Transport Profile (MPLS-TP). The work on the MPLS TP will = be coordinated
>>> between four primary working groups (MPLS, PWE3, L2VPN and = CCAMP) that are
>>> chartered to do MPLS TP work.
>>>
>>> Milestones:
>>>
>>> Done        Submit an = I-D describing MIB for VPLS
>>> Done        Submit an = I-D describing MIB for VPWS
>>> Done        Submit an = I-D on OAM requirements for VPLS
>>> Done        Submit an = I-D on OAM requirements for VPWS
>>> Done        Submit L2 = requirements to IESG for publication as Informational
>>> RFC
>>> Done        Submit L2 = framework to IESG for publication as Informational RFC
>>> Done        Identify = VPLS and VPWS solutions for the WG
>>> Done        Submit VPLS = solution documents to IESG
>>> Done        Submit VPWS = solution documents to IESG
>>> Done        Submit = Auto-Discovery and Signaling for Intra-AS and Inter-AS
>>>          &= nbsp; VPLS and VPWS Layer-2 VPNs
>>> Jul 2011    Submit IP-only L2VPN solution = documents to IESG
>>> Jul 2011    Submit OAM solutions for VPWS to = IESG
>>> Jul 2011    Submit OAM solutions for VPLS to = IESG
>>> Jul 2011    Submit signaling solution for = multicast-optimized VPLS to IESG
>>> Jul 2011    Submit I-D on Virtual Private = Multicast Service (VPMS)
>>>          &= nbsp; requirements to IESG
>>> Jul 2011    Submit MIB for VPLS to IESG
>>> Jul 2011    Submit MIB for VPWS to IESG
>>> Nov 2011    Submit scalability solutions for = VPLS Data-Plane to IESG
>>> Nov 2011    Submit scalability solutions for = VPLS Control-Plane to IESG
>>> Mar 2012    Submit MIB for IP-only L2VPN to = IESG
>>> Mar 2012    Submit OAM solutions for IP-only = L2VPN to IESG
>>> Mar 2012    Submit Auto-Discovery solution = for VPMS to IESG
>>> Mar 2012    Submit VPLS service convergence = improvement solutions to IESG
>>> Mar 2012    Submit VPLS multi-homing = solutions to IESG
>>> Mar 2012    Submit E-Tree documents to = IESG
>>> Mar 2012    Submit E-VPN = requirements/framework to IESG
>>> Jul 2012    Submit E-VPN solution to = IESG
>>> Nov 2012    Submit E-VPN MIB/OAM to IESG
>>>
>>> -----------------
>>>
>>> On 18/03/2011 17:41, "Giles Heron" = <giles.heron@gmail.com> wrote:
>>>
>>>> We plan to re-charter the L2VPN WG - primarily to bring = E-VPN and E-Tree
>>>> in-scope.
>>>>
>>>> Please find attached a draft charter for discussion = both on this list and at
>>>> IETF 80 in Prague.
>>>>
>>>> Nabil and Giles
>>>>
>>>>
>>>
>>>
>>
>
>
>

------_=_NextPart_001_01CBEFB7.3F2C019B-- From bschlies@cisco.com Thu Mar 31 09:16:34 2011 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 4FAE43A6C11 for ; Thu, 31 Mar 2011 09:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.943 X-Spam-Level: X-Spam-Status: No, score=-8.943 tagged_above=-999 required=5 tests=[AWL=-1.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, SARE_MLB_Stock6=1.56] 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 MrE3cKAvb0Pj for ; Thu, 31 Mar 2011 09:16:27 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id A22333A684E for ; Thu, 31 Mar 2011 09:16:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=29328; q=dns/txt; s=iport; t=1301588287; x=1302797887; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=z26AeBGjZQL2xDTeBmoalRNi7o2LKU9gFH7Q5HQL0OQ=; b=PDCMYNr02UFQYn/BDINPH5kWKGdmEeBdL4wIVoUS4FGDHUUlEn4Mgx8D 5v0zdGf/rkQWHd4wzmS291vjlUHQ8xqaAapZwC8xzXQuw4BsqiWa/cp/A gbs0RVQoeJEJCyCqdRdQycXZqkP+cF28/6sF9U0VW06jbCD2eB5gmO9XA c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGaolE2tJXG//2dsb2JhbACCXqIUYHeIeZpKnCmCfYJuBIVBh1CDW4Mp X-IronPort-AV: E=Sophos;i="4.63,276,1299456000"; d="scan'208,217";a="286656867" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by sj-iport-3.cisco.com with ESMTP; 31 Mar 2011 16:18:06 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2VGI6uE013034; Thu, 31 Mar 2011 16:18:06 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 31 Mar 2011 11:18:06 -0500 Received: from 10.61.105.231 ([10.61.105.231]) by XMB-RCD-206.cisco.com ([72.163.62.213]) via Exchange Front-End Server email.cisco.com ([144.254.231.93]) with Microsoft Exchange Server HTTP-DAV ; Thu, 31 Mar 2011 16:18:05 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Thu, 31 Mar 2011 11:18:05 -0500 Subject: Re: Draft of new L2VPN WG Charter From: Benson Schliesser To: "Shah, Himanshu" , Thomas Nadeau , Giles Heron Message-ID: Thread-Topic: Draft of new L2VPN WG Charter Thread-Index: AcvvtA2JzqTxhFkJSFamDqHmBDPKfwAAiwePAAI/U3Q= In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3384415086_4560360" X-OriginalArrivalTime: 31 Mar 2011 16:18:06.0471 (UTC) FILETIME=[37D55170:01CBEFBF] 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: Thu, 31 Mar 2011 16:16:34 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3384415086_4560360 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Speaking as ARMD co-chair: Solution development is not in our charter, but analysis of existing solutions (and identification of gaps) is. If we identify gaps, then ARMD might be re-chartered to develop solutions =AD or we might send our requirements into other WGs for development. This is TBD pending our work on the Problem Statement. Speaking personally: I don=B9t have any objection to L2VPN working on data center solutions. If somebody deploys e.g. VPLS inside an enterprise network, provider data center, provider metro network, etc, I think these are all valid use-cases. This is why I asked my question about the 2nd sentence =AD it seems redundant. Cheers, -Benson On 3/31/11 10:21 AM, "Shah, Himanshu" wrote: > My understanding is that, as a first step, the problem > scope needs to be understood. Solutions, if any required, > could follow only after the problem is well understood. > Solutions are part of ARMD charter but only after first step > is completed. >=20 > Although, it appears that L2VPN group has already acknowledged > and understood the problem well enough to propose solutions?? >=20 > /himanshu >=20 >=20 > -----Original Message----- > From: l2vpn-bounces@ietf.org on behalf of Thomas Nadeau > Sent: Thu 3/31/2011 10:57 AM > To: Giles Heron > Cc: l2vpn@ietf.org > Subject: Re: Draft of new L2VPN WG Charter >=20 >=20 > On Mar 31, 2011, at 10:49 AM, Giles Heron wrote: >=20 >> > Hi Benson, >> > >> > This would be provider-provisioned L2VPN environments (whether data-ce= ntre >> > interconnect, or scaling of a large multi-tenant data-centre). >> > >> > Personally I'm not sure we need the sentence there, but others were ke= en to >> > mention the data-centre requirements. >=20 > I think that is meant to explicitly field requirements for soluti= ons > that come from ARMD/etc... into the WG, since they cannot build their own > solutions. While that isn't implicitly handled in the existing charter, = I > do not know either. >=20 > --Tom >=20 >=20 >> > >> > Giles >> > >> > On 31/03/2011 15:37, "Benson Schliesser" wrote: >> > >>> >> Hi, Giles. >>> >> >>> >> I have a clarifying question about the first paragraph: What is the >>> purpose >>> >> of the 2nd sentence, bringing cloud and DC requirements into the mix= ? >>> >> Assuming this is meant to include non-provider L2VPN environments (l= ike >>> >> enterprise data centers), then why not just remove the phrase >>> >> "provider-provisioned" from the first sentence? Otherwise, it seems >>> >> redundant. >>> >> >>> >> This is a real question, not a suggestion at this time. >>> >> >>> >> Thanks, >>> >> -Benson >>> >> >>> >> >>> >> >>> >> On 3/18/11 1:21 PM, "Giles Heron" wrote: >>> >> >>>> >>> OK - looks like the attachment didn't come through as intended. M= y >>>> >>> apologies. >>>> >>> >>>> >>> Text inline: >>>> >>> >>>> >>> ---------------- >>>> >>> >>>> >>> The L2VPN working group is responsible for defining and specifying= a >>>> >>> limited number of solutions for supporting provider-provisioned La= yer-2 >>>> >>> Virtual Private Networks (L2VPNs). It will also address requiremen= ts >>>> driven >>>> >>> by cloud computing services and data centers as they apply to Laye= r-2 >>>> >>> VPN services. >>>> >>> >>>> >>> Layer-2 VPNs defined by L2VPN operate over pseudowires (PWs) as >>>> >>> defined by the PWE3 WG or over MPLS PSN tunnels. A L2VPN emulates = a >>>> >>> "native" service over a PSN that is adequately faithful to, but ma= y not >>>> >>> be entirely indistinguishable from the native service itself. Furt= her, >>>> >>> following in the "edge-to-edge" nature of the service, the L2VPN = WG >>>> will >>>> >>> not define any mechanisms which exert control over the underlying = PSN. >>>> >>> When necessary it may, however, recommend or require the use of >>>> existing >>>> >>> PSN QoS and path control mechanisms between the PEs which provide = the >>>> >>> L2VPN connectivity. >>>> >>> >>>> >>> Layer-2 VPNs comprise the following: >>>> >>> >>>> >>> 1. Virtual Private LAN Service (VPLS) -- A Layer-2 service that >>>> emulates >>>> >>> a switched Ethernet (V)LAN across an MPLS Packet Switched Network >>>> (PSN). >>>> >>> >>>> >>> 2. Virtual Private Wire Service (VPWS) -- A Layer-2 service that >>>> >>> provides point-to-point connectivity for a variety of link layers, >>>> >>> including Frame Relay, ATM, Ethernet, PPP, etc., across an MPLS PS= N. >>>> >>> >>>> >>> 3. Virtual Private Multicast Service (VPMS) -- A Layer-2 service t= hat >>>> >>> provides point-to-multipoint connectivity for a variety of link >>>> >>> layers across an MPLS PSN. >>>> >>> >>>> >>> 4. IP-only L2VPN - An IP-only service over an MPLS PSN. The WG wi= ll >>>> >>> address two specific types of IP-only L2VPN: >>>> >>> >>>> >>> a) Point-to-point Layer-2 VPN. This service is similar to VPWS, b= ut >>>> also >>>> >>> supports heterogenous Attachment Circuits at either end of a singl= e >>>> >>> point-to-point service. >>>> >>> >>>> >>> b) Multipoint-to-multipoint Layer-2 VPN. This service is similar = to >>>> VPLS, >>>> >>> but learns IP and MAC address bindings from ARPs and >>>> broadcast/multicast >>>> >>> IP packets. >>>> >>> >>>> >>> 5. Ethernet VPN (E-VPN) - A Layer-2 technology that emulates an >>>> >>> Ethernet (V)LAN across an MPLS PSN. E-VPN supports load-sharing ac= ross >>>> >>> multiple connections from a Layer-2 site to an L2VPN service, and = also >>>> >>> supports control plane distribution of MAC addresses and IP to MAC >>>> address >>>> >>> bindings in the VPN. E-VPN is primarily targeted to support large-= scale >>>> >>> L2VPNs with resiliency requirements not satisfied by other L2VPN >>>> solutions. >>>> >>> >>>> >>> 6. E-Tree - a Layer-2 technology defined by the MEF, which provide= s >>>> >>> connectivity between one or more "root" nodes and one or more >>>> >>> "leaf" nodes, with the restriction that leaves may only communicat= e >>>> >>> with roots (and not with each other). >>>> >>> >>>> >>> L2VPNs will make use of existing IETF specified mechanisms unless = there >>>> >>> are technical reasons why the existing mechanisms are insufficient= or >>>> >>> unnecessary. >>>> >>> >>>> >>> The L2VPN WG is responsible for specification of the discovery and >>>> >>> membership of PEs participating in a Layer-2 VPN as well as the >>>> >>> membership of CE devices for a specific instance of an L2VPN. >>>> >>> >>>> >>> The L2VPN WG will provide extensions of existing protocols that wi= ll be >>>> >>> discussed in protocol-specific WGs. In particular, the L2VPN WG >>>> >>> may define extensions to pseudowire management mechanisms for VPLS= . >>>> >>> Those extensions will be reviewed by the PWE3 WG to ensure they ar= e >>>> >>> aligned with the overall design/architecture of PWE3. >>>> >>> >>>> >>> The L2VPN WG will not define new encapsulations, control, or resil= iency >>>> >>> mechanisms specifically related to pseudowires. Furthermore, when = the >>>> >>> L2VPN solution is based on PWs, the L2VPN WG will not define proto= col >>>> >>> inter-working between an L2VPN and native service Layer-2 OAM or >>>> >>> resiliency mechanisms. The L2VPN WG may define how to operate nati= ve >>>> >>> service-layer control, OAM or resiliency mechanisms on top of an L= 2VPN. >>>> >>> In addition, it may define native data plane and/or control plane >>>> >>> interworking between an L2VPN and an associated native Layer-2 ser= vice. >>>> >>> >>>> >>> The L2VPN WG scope includes the following: >>>> >>> >>>> >>> 1. Discovery of PEs participating in a Layer-2 VPN and the associa= ted >>>> >>> topology required for connectivity of the VPLS, VPWS, VPMS or E-VP= N >>>> >>> service. >>>> >>> >>>> >>> 2. Signaling of information related to the discovery and membershi= p of >>>> >>> PEs within a L2VPN. These procedures must use PWE3 control and >>>> >>> management procedures, or define requirements for extensions of PW= E3 >>>> >>> protocols to suit the needs of an L2VPN, when the L2VPN operates o= ver >>>> >>> PWs. Once those requirements have been reviewed by the L2VPN WG, t= hey >>>> >>> should be provided to the PWE3 WG to derive solutions. >>>> >>> >>>> >>> 3. MIBs for Layer-2 VPN solutions. >>>> >>> >>>> >>> 4. Specification of requirements, framework and solutions that >>>> >>> facilitate Operations Administration and Management (OAM) of any t= ype of >>>> >>> L2VPN. >>>> >>> >>>> >>> 5. Mechanisms to permit optimization of multicast data traffic wit= hin >>>> >>> an L2VPN. >>>> >>> >>>> >>> 6. If transport does not involve PWs, mechanisms that support >>>> >>> load-balancing/multipathing between PEs interconnecting a Layer-2 >>>> >>> service using an L2VPN across the MPLS PSN. >>>> >>> >>>> >>> 7. requirements for the multi-homing of CEs to several VPLS or >>>> >>> E-VPN PEs, inclusive of active/backup and active/active (load-shar= ing) >>>> >>> configurations. Based on these requirements define VPLS or E-VPN >>>> control >>>> >>> plane solutions for achieving fast convergence after failure of an >>>> active >>>> >>> path in the PSN or on the AC side. >>>> >>> >>>> >>> 8. Enhancements to increase the scalability of the Control Plane a= nd >>>> >>> Data Plane of L2VPN PE nodes, and of core nodes that provide trans= port >>>> >>> services for L2VPN. >>>> >>> >>>> >>> 9. Requirements and solutions for Auto-Discovery and Signaling of >>>> >>> Inter-AS L2VPNs, in addition to Inter-AS solutions for >>>> multicast-optimized >>>> >>> L2VPNs. >>>> >>> >>>> >>> 10. Requirements and solutions for supporting "E-Tree" services us= ing >>>> >>> VPLS. >>>> >>> >>>> >>> 11. Extensions to L2VPN protocols and RFCs necessary to create an = MPLS >>>> >>> Transport Profile (MPLS-TP). The work on the MPLS TP will be >>>> coordinated >>>> >>> between four primary working groups (MPLS, PWE3, L2VPN and CCAMP) = that are >>>> >>> chartered to do MPLS TP work. >>>> >>> >>>> >>> Milestones: >>>> >>> >>>> >>> Done Submit an I-D describing MIB for VPLS >>>> >>> Done Submit an I-D describing MIB for VPWS >>>> >>> Done Submit an I-D on OAM requirements for VPLS >>>> >>> Done Submit an I-D on OAM requirements for VPWS >>>> >>> Done Submit L2 requirements to IESG for publication as >>>> Informational >>>> >>> RFC >>>> >>> Done Submit L2 framework to IESG for publication as >>>> Informational RFC >>>> >>> Done Identify VPLS and VPWS solutions for the WG >>>> >>> Done Submit VPLS solution documents to IESG >>>> >>> Done Submit VPWS solution documents to IESG >>>> >>> Done Submit Auto-Discovery and Signaling for Intra-AS and >>>> Inter-AS >>>> >>> VPLS and VPWS Layer-2 VPNs >>>> >>> Jul 2011 Submit IP-only L2VPN solution documents to IESG >>>> >>> Jul 2011 Submit OAM solutions for VPWS to IESG >>>> >>> Jul 2011 Submit OAM solutions for VPLS to IESG >>>> >>> Jul 2011 Submit signaling solution for multicast-optimized VPLS= to >>>> IESG >>>> >>> Jul 2011 Submit I-D on Virtual Private Multicast Service (VPMS) >>>> >>> requirements to IESG >>>> >>> Jul 2011 Submit MIB for VPLS to IESG >>>> >>> Jul 2011 Submit MIB for VPWS to IESG >>>> >>> Nov 2011 Submit scalability solutions for VPLS Data-Plane to IE= SG >>>> >>> Nov 2011 Submit scalability solutions for VPLS Control-Plane to= IESG >>>> >>> Mar 2012 Submit MIB for IP-only L2VPN to IESG >>>> >>> Mar 2012 Submit OAM solutions for IP-only L2VPN to IESG >>>> >>> Mar 2012 Submit Auto-Discovery solution for VPMS to IESG >>>> >>> Mar 2012 Submit VPLS service convergence improvement solutions = to >>>> IESG >>>> >>> Mar 2012 Submit VPLS multi-homing solutions to IESG >>>> >>> Mar 2012 Submit E-Tree documents to IESG >>>> >>> Mar 2012 Submit E-VPN requirements/framework to IESG >>>> >>> Jul 2012 Submit E-VPN solution to IESG >>>> >>> Nov 2012 Submit E-VPN MIB/OAM to IESG >>>> >>> >>>> >>> ----------------- >>>> >>> >>>> >>> On 18/03/2011 17:41, "Giles Heron" wrote: >>>> >>> >>>>> >>>> We plan to re-charter the L2VPN WG - primarily to bring E-VPN an= d >>>>> E-Tree >>>>> >>>> in-scope. >>>>> >>>> >>>>> >>>> Please find attached a draft charter for discussion both on this= list >>>>> and at >>>>> >>>> IETF 80 in Prague. >>>>> >>>> >>>>> >>>> Nabil and Giles >>>>> >>>> >>>>> >>>> >>>> >>> >>>> >>> >>> >> >> > >> > >> > >=20 >=20 >=20 --B_3384415086_4560360 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: Draft of new L2VPN WG Charter Speaking as ARMD co-chair:  Solution development is not in our charte= r, but analysis of existing solutions (and identification of gaps) is.  = ;If we identify gaps, then ARMD might be re-chartered to develop solutions &= #8211; or we might send our requirements into other WGs for development. &nb= sp;This is TBD pending our work on the Problem Statement.

Speaking personally: I don’t have any objection to L2VPN working on d= ata center solutions.  If somebody deploys e.g. VPLS inside an enterpri= se network, provider data center, provider metro network, etc, I think these= are all valid use-cases.  This is why I asked my question about the 2n= d sentence – it seems redundant.

Cheers,
-Benson


On 3/31/11 10:21 AM, "Shah, Himanshu" <hshah@ciena.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>My understanding is that, as a first step, the p= roblem
scope needs to be understood. Solutions, if any required,
could follow only after the problem is well understood.
Solutions are part of ARMD charter but only after first step
is completed.

Although, it appears that L2VPN group has already acknowledged
and understood the problem well enough to propose solutions??

/himanshu


-----Original Message-----
From: l2vpn-bounces@ietf.org on behalf= of Thomas Nadeau
Sent: Thu 3/31/2011 10:57 AM
To: Giles Heron
Cc: l2vpn@ietf.org
Subject: Re: Draft of new L2VPN WG Charter


On Mar 31, 2011, at 10:49 AM, Giles Heron wrote:

> Hi Benson,
>
> This would be provider-provisioned L2VPN environments (whether data-ce= ntre
> interconnect, or scaling of a large multi-tenant data-centre).
>
> Personally I'm not sure we need the sentence there, but others were ke= en to
> mention the data-centre requirements.

        I think that is meant to ex= plicitly field requirements for solutions
that come from ARMD/etc... into the WG, since they cannot build their own solutions.  While that isn't implicitly handled in the existing charte= r, I
do not know either.

        --Tom


>
> Giles
>
> On 31/03/2011 15:37, "Benson Schliesser" <bschlies@cisco.com> wrote:
>
>> Hi, Giles.
>>
>> I have a clarifying question about the first paragraph:  What= is the purpose
>> of the 2nd sentence, bringing cloud and DC requirements into the m= ix?
>> Assuming this is meant to include non-provider L2VPN environments = (like
>> enterprise data centers), then why not just remove the phrase
>> "provider-provisioned" from the first sentence?  Ot= herwise, it seems
>> redundant.
>>
>> This is a real question, not a suggestion at this time.
>>
>> Thanks,
>> -Benson
>>
>>
>>
>> On 3/18/11 1:21 PM, "Giles Heron" <giles.heron@gmail.com> wrote:
>>
>>> OK - looks like the attachment didn't come through as intended= .  My
>>> apologies.
>>>
>>> Text inline:
>>>
>>> ----------------
>>>
>>> The L2VPN working group is responsible for defining and specif= ying a
>>> limited number of solutions for supporting provider-provisione= d Layer-2
>>> Virtual Private Networks (L2VPNs). It will also address requir= ements driven
>>> by cloud computing services and data centers as they apply to = Layer-2
>>> VPN services.
>>>
>>> Layer-2 VPNs defined by L2VPN operate over pseudowires (PWs) a= s
>>> defined by the PWE3 WG or over MPLS PSN tunnels. A L2VPN emula= tes a
>>> "native" service over a PSN that is adequately faith= ful to, but may not
>>> be entirely indistinguishable from the native service itself. = Further,
>>> following in the "edge-to-edge" nature of the  = service, the L2VPN WG will
>>> not define any mechanisms which exert control over the underly= ing PSN.
>>> When necessary it may, however, recommend or require the use o= f existing
>>> PSN QoS and path control mechanisms between the PEs which prov= ide the
>>> L2VPN connectivity.
>>>
>>> Layer-2 VPNs comprise the following:
>>>
>>> 1. Virtual Private LAN Service (VPLS) -- A Layer-2 service tha= t emulates
>>> a switched Ethernet (V)LAN across an MPLS Packet Switched Netw= ork (PSN).
>>>
>>> 2. Virtual Private Wire Service (VPWS) -- A Layer-2 service th= at
>>> provides point-to-point connectivity for a variety of link lay= ers,
>>> including Frame Relay, ATM, Ethernet, PPP, etc., across an MPL= S PSN.
>>>
>>> 3. Virtual Private Multicast Service (VPMS) -- A Layer-2 servi= ce that
>>> provides point-to-multipoint connectivity for a variety of lin= k
>>> layers across an MPLS PSN.
>>>
>>> 4. IP-only L2VPN - An IP-only service over an MPLS PSN.  = The WG will
>>> address two specific types of IP-only L2VPN:
>>>
>>> a) Point-to-point Layer-2 VPN.  This service is similar t= o VPWS, but also
>>> supports heterogenous Attachment Circuits at either end of a s= ingle
>>> point-to-point service.
>>>
>>> b) Multipoint-to-multipoint Layer-2 VPN.  This service is= similar to VPLS,
>>> but learns IP and MAC address bindings from ARPs and broadcast= /multicast
>>> IP packets.
>>>
>>> 5. Ethernet VPN (E-VPN) - A Layer-2 technology that emulates a= n
>>> Ethernet (V)LAN across an MPLS PSN. E-VPN supports load-sharin= g across
>>> multiple connections from a Layer-2 site to an L2VPN service, = and also
>>> supports control plane distribution of MAC addresses and IP to= MAC address
>>> bindings in the VPN. E-VPN is primarily targeted to support la= rge-scale
>>> L2VPNs with resiliency requirements not satisfied by other L2V= PN solutions.
>>>
>>> 6. E-Tree - a Layer-2 technology defined by the MEF, which pro= vides
>>> connectivity between one or more "root" nodes and on= e or more
>>> "leaf" nodes, with the restriction that leaves may o= nly communicate
>>> with roots (and not with each other).
>>>
>>> L2VPNs will make use of existing IETF specified mechanisms unl= ess there
>>> are technical reasons why the existing mechanisms are insuffic= ient or
>>> unnecessary.
>>>
>>> The L2VPN WG is responsible for specification of the discovery= and
>>> membership of PEs participating in a Layer-2 VPN as well as th= e
>>> membership of CE devices for a specific instance of an L2VPN.<= BR> >>>
>>> The L2VPN WG will provide extensions of existing protocols tha= t will be
>>> discussed in protocol-specific WGs. In particular, the L2VPN W= G
>>> may define extensions to pseudowire management mechanisms for = VPLS.
>>> Those extensions will be reviewed by the PWE3 WG to ensure the= y are
>>> aligned with the overall design/architecture of PWE3.
>>>
>>> The L2VPN WG will not define new encapsulations, control, or r= esiliency
>>> mechanisms specifically related to pseudowires. Furthermore, w= hen the
>>> L2VPN solution is based on PWs, the L2VPN WG will not define p= rotocol
>>> inter-working between an L2VPN and native service Layer-2 OAM = or
>>> resiliency mechanisms. The L2VPN WG may define how to operate = native
>>> service-layer control, OAM or resiliency mechanisms on top of = an L2VPN.
>>> In addition, it may define native data plane and/or control pl= ane
>>> interworking between an L2VPN and an associated native Layer-2= service.
>>>
>>> The L2VPN WG scope includes the following:
>>>
>>> 1. Discovery of PEs participating in a Layer-2 VPN and the ass= ociated
>>> topology required for connectivity of the VPLS, VPWS, VPMS or = E-VPN
>>> service.
>>>
>>> 2. Signaling of information related to the discovery and membe= rship of
>>> PEs within a L2VPN. These procedures must use PWE3 control and=
>>> management procedures, or define requirements for extensions o= f PWE3
>>> protocols to suit the needs of an L2VPN, when the L2VPN operat= es over
>>> PWs. Once those requirements have been reviewed by the L2VPN W= G, they
>>> should be provided to the PWE3 WG to derive solutions.
>>>
>>> 3. MIBs for Layer-2 VPN solutions.
>>>
>>> 4. Specification of requirements, framework and solutions that=
>>> facilitate Operations Administration and Management (OAM) of a= ny type of
>>> L2VPN.
>>>
>>> 5. Mechanisms to permit optimization of multicast data traffic= within
>>> an L2VPN.
>>>
>>> 6. If transport does not involve PWs, mechanisms that support<= BR> >>> load-balancing/multipathing between PEs interconnecting a Laye= r-2
>>> service using an L2VPN across the MPLS PSN.
>>>
>>> 7. requirements for the multi-homing of CEs to several VPLS or=
>>> E-VPN PEs, inclusive of active/backup and active/active (load-= sharing)
>>> configurations. Based on these requirements define VPLS or E-V= PN control
>>> plane solutions for achieving fast convergence after failure o= f an active
>>> path in the PSN or on the AC side.
>>>
>>> 8. Enhancements to increase the scalability of the Control Pla= ne and
>>> Data Plane of L2VPN PE nodes, and of core nodes that provide t= ransport
>>> services for L2VPN.
>>>
>>> 9. Requirements and solutions for Auto-Discovery and Signaling= of
>>> Inter-AS L2VPNs, in addition to Inter-AS solutions for multica= st-optimized
>>> L2VPNs.
>>>
>>> 10. Requirements and solutions for supporting "E-Tree&quo= t; services using
>>> VPLS.
>>>
>>> 11. Extensions to L2VPN protocols and RFCs necessary to create= an MPLS
>>> Transport Profile (MPLS-TP). The work on the MPLS TP will be c= oordinated
>>> between four primary working groups (MPLS, PWE3, L2VPN and CCA= MP) that are
>>> chartered to do MPLS TP work.
>>>
>>> Milestones:
>>>
>>> Done        Submit an I-D d= escribing MIB for VPLS
>>> Done        Submit an I-D d= escribing MIB for VPWS
>>> Done        Submit an I-D o= n OAM requirements for VPLS
>>> Done        Submit an I-D o= n OAM requirements for VPWS
>>> Done        Submit L2 requi= rements to IESG for publication as Informational
>>> RFC
>>> Done        Submit L2 frame= work to IESG for publication as Informational RFC
>>> Done        Identify VPLS a= nd VPWS solutions for the WG
>>> Done        Submit VPLS sol= ution documents to IESG
>>> Done        Submit VPWS sol= ution documents to IESG
>>> Done        Submit Auto-Dis= covery and Signaling for Intra-AS and Inter-AS
>>>           &n= bsp;VPLS and VPWS Layer-2 VPNs
>>> Jul 2011    Submit IP-only L2VPN solution docum= ents to IESG
>>> Jul 2011    Submit OAM solutions for VPWS to IE= SG
>>> Jul 2011    Submit OAM solutions for VPLS to IE= SG
>>> Jul 2011    Submit signaling solution for multi= cast-optimized VPLS to IESG
>>> Jul 2011    Submit I-D on Virtual Private Multi= cast Service (VPMS)
>>>           &n= bsp;requirements to IESG
>>> Jul 2011    Submit MIB for VPLS to IESG
>>> Jul 2011    Submit MIB for VPWS to IESG
>>> Nov 2011    Submit scalability solutions for VP= LS Data-Plane to IESG
>>> Nov 2011    Submit scalability solutions for VP= LS Control-Plane to IESG
>>> Mar 2012    Submit MIB for IP-only L2VPN to IES= G
>>> Mar 2012    Submit OAM solutions for IP-only L2= VPN to IESG
>>> Mar 2012    Submit Auto-Discovery solution for = VPMS to IESG
>>> Mar 2012    Submit VPLS service convergence imp= rovement solutions to IESG
>>> Mar 2012    Submit VPLS multi-homing solutions = to IESG
>>> Mar 2012    Submit E-Tree documents to IESG
>>> Mar 2012    Submit E-VPN requirements/framework= to IESG
>>> Jul 2012    Submit E-VPN solution to IESG
>>> Nov 2012    Submit E-VPN MIB/OAM to IESG
>>>
>>> -----------------
>>>
>>> On 18/03/2011 17:41, "Giles Heron" <giles.heron@gmail.com> wrote:
>>>
>>>> We plan to re-charter the L2VPN WG - primarily to bring E-= VPN and E-Tree
>>>> in-scope.
>>>>
>>>> Please find attached a draft charter for discussion both o= n this list and at
>>>> IETF 80 in Prague.
>>>>
>>>> Nabil and Giles
>>>>
>>>>
>>>
>>>
>>
>
>
>



--B_3384415086_4560360--