From l2vpn-bounces@ietf.org Fri Mar 03 18:50:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFK2M-0007HL-N5; Fri, 03 Mar 2006 18:50:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFK27-0006cg-7l; Fri, 03 Mar 2006 18:50:03 -0500 Received: from [156.154.16.129] (helo=cypress.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFK26-00039c-Kb; Fri, 03 Mar 2006 18:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k23No20e006638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Mar 2006 23:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FFK25-0000dl-Up; Fri, 03 Mar 2006 18:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 03 Mar 2006 18:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: l2vpn@ietf.org Subject: I-D ACTION:draft-ietf-l2vpn-signaling-07.txt X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org --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 : Provisioning, Autodiscovery, and Signaling in L2VPNs Author(s) : E. Rosen, et al. Filename : draft-ietf-l2vpn-signaling-07.txt Pages : 37 Date : 2006-3-3 Provider Provisioned Layer 2 Virtual Private Networks (L2VPNs) may have different "provisioning models", i.e., models for what information needs to be configured in what entities. Once configured, the provisioning information is distributed by a "discovery process". When the discovery process is complete, a signaling protocol is automatically invoked to set up the mesh of Pseudowires (PWs) that form the (virtual) backbone of the L2VPN. This document specifies a number of L2VPN provisioning models, and further specifies the semantic structure of the endpoint identifiers required by each model. It discusses the distribution of these identifiers by the discovery process, especially when discovery is based on the Border Gateway Protocol (BGP). It then specifies how the endpoint identifiers are carried in the two signaling protocols that are used to set up PWs, the Label Distribution Protocol (LDP) and the Layer 2 Tunneling Protocol (L2TPv3). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-signaling-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-l2vpn-signaling-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-l2vpn-signaling-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-3153024.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l2vpn-signaling-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l2vpn-signaling-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-3153024.I-D@ietf.org> --OtherAccess-- --NextPart-- From l2vpn-bounces@ietf.org Tue Mar 07 00:21:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGUds-0006cg-5a; Tue, 07 Mar 2006 00:21:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGUdq-0006cY-Us for l2vpn@ietf.org; Tue, 07 Mar 2006 00:21:50 -0500 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGUdp-0001IW-MI for l2vpn@ietf.org; Tue, 07 Mar 2006 00:21:50 -0500 Received: from [172.16.15.25] (dsl081-098-224.den1.dsl.speakeasy.net [64.81.98.224]) by dog.tcb.net (Postfix) with ESMTP id 687BD64353 for ; Mon, 6 Mar 2006 22:21:42 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <43FCF992.4020200@castlepoint.net> References: <43FCF992.4020200@castlepoint.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Shane Amante Date: Mon, 6 Mar 2006 22:21:47 -0700 To: l2vpn@ietf.org X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: WG Last Call Ended: draft-ietf-l2tpext-l2vpn-06.txt X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org This e-mail signals the end of the WG Last Call for draft-ietf- l2tpext-l2vpn-06.txt. -shane & Vach On Feb 22, 2006, at 4:53 PM, Shane Amante wrote: > Folks, > > This begins a 1 week WG LC on draft-ietf-l2tpext-l2vpn-06.txt: > http://www.ietf.org/internet-drafts/draft-ietf-l2tpext-l2vpn-06.txt > > Please raise any comments to the list. Last Call will end on > 3/1/2006 at 17:00 MST (GMT -7). > > -shane & Vach > From l2vpn-bounces@ietf.org Tue Mar 07 15:51:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGj9W-0003Pi-MB; Tue, 07 Mar 2006 15:51:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGj87-0000qm-CL; Tue, 07 Mar 2006 15:50:03 -0500 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGj86-00022Y-2o; Tue, 07 Mar 2006 15:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k27Ko1BX012541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Mar 2006 20:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FGj85-00019h-QZ; Tue, 07 Mar 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 07 Mar 2006 15:50:01 -0500 X-Spam-Score: 0.3 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: l2vpn@ietf.org Subject: I-D ACTION:draft-ietf-l2vpn-vpls-mcast-reqts-01.txt X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org --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 : Requirements for Multicast Support in Virtual Private LAN Services Author(s) : Y. Kamite, et al. Filename : draft-ietf-l2vpn-vpls-mcast-reqts-01.txt Pages : 27 Date : 2006-3-7 This document provides functional requirements for network solutions that support multicast over Virtual Private LAN Service (VPLS). It specifies requirements both from the end user and service provider standpoints. It is intended that potential solutions will use these requirements as guidelines. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-mcast-reqts-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-l2vpn-vpls-mcast-reqts-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-l2vpn-vpls-mcast-reqts-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-7115428.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l2vpn-vpls-mcast-reqts-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l2vpn-vpls-mcast-reqts-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-7115428.I-D@ietf.org> --OtherAccess-- --NextPart-- From l2vpn-bounces@ietf.org Wed Mar 08 02:50:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGtRI-0005p6-19; Wed, 08 Mar 2006 02:50:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGtQp-0005BF-HC; Wed, 08 Mar 2006 02:50:04 -0500 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGtQo-0001iK-1C; Wed, 08 Mar 2006 02:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k287o19W014767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Mar 2006 07:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FGtQn-0001cD-PB; Wed, 08 Mar 2006 02:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 08 Mar 2006 02:50:01 -0500 X-Spam-Score: 0.3 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: l2vpn@ietf.org Subject: I-D ACTION:draft-ietf-l2vpn-oam-req-frmk-05.txt X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org --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 : L2VPN OAM Requirements and Framework Author(s) : D. Mohan, A. Sajassi Filename : draft-ietf-l2vpn-oam-req-frmk-05.txt Pages : 36 Date : 2006-3-7 This draft provides framework and requirements for Layer 2 Virtual Private Networks (L2VPN) Operation, Administration and Maintenance (OAM). The OAM framework is intended to provide OAM layering across L2VPN services, Pseudo Wires (PWs) and Packet Switched Network (PSN) tunnels. The requirements are intended to identify OAM requirement for L2VPN services (i.e. VPLS, VPWS, and IPLS). Furthermore, if L2VPN services OAM requirements impose specific requirements on PW OAM and/or PSN OAM, those specific PW and/or PSN OAM requirements are also identified. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-oam-req-frmk-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-l2vpn-oam-req-frmk-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-l2vpn-oam-req-frmk-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-7203550.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l2vpn-oam-req-frmk-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l2vpn-oam-req-frmk-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-7203550.I-D@ietf.org> --OtherAccess-- --NextPart-- From l2vpn-bounces@ietf.org Wed Mar 08 10:10:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH0Ip-0005zI-7E; Wed, 08 Mar 2006 10:10:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH0Io-0005zD-Gq for l2vpn@ietf.org; Wed, 08 Mar 2006 10:10:14 -0500 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH0In-0004ma-6t for l2vpn@ietf.org; Wed, 08 Mar 2006 10:10:14 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k28FACX07855 for ; Wed, 8 Mar 2006 07:10:12 -0800 (PST) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k28FA7514865 for ; Wed, 8 Mar 2006 07:10:07 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200603081510.k28FA7514865@merlot.juniper.net> To: l2vpn@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <29487.1141830607.1@juniper.net> Date: Wed, 08 Mar 2006 07:10:07 -0800 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: changes in draft-ietf-l2vpn-signaling-07.txt X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org Folks, >From 3.2.2.1: It is RECOMMENDED that a single VPN-ID be assigned to a VPLS instance. That VPN-ID MAY be a VPN-ID as defined in [RFC2685], in which case it SHOULD be encoded as an RD by placing the value 0x80 in the first byte of the RD (to indicate the RD type) and the 7-byte VPN-ID in the remaining bytes of the RD. The above is clearly well beyond an editorial change. It was added after the document passed the WG Last Call. It was added with no discussion on the l2vpn mailing list, and no consensus of the WG. With this in mind before progressing this document any further I'd like the authors of draft-ietf-l2vpn-signaling-07.txt to document the rationale for this change, and for the WG chairs to ask for the WG consensus on this change. Yakov. From l2vpn-bounces@ietf.org Wed Mar 08 12:29:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH2TN-00070b-JX; Wed, 08 Mar 2006 12:29:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH2TM-00070T-GX for l2vpn@ietf.org; Wed, 08 Mar 2006 12:29:16 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH2TM-0001DE-6F for l2vpn@ietf.org; Wed, 08 Mar 2006 12:29:16 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 08 Mar 2006 09:29:16 -0800 X-IronPort-AV: i="4.02,176,1139212800"; d="scan'208"; a="1783107501:sNHT94612140" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k28HTF1n015712; Wed, 8 Mar 2006 09:29:15 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Mar 2006 09:29:15 -0800 Received: from [206.117.31.211] ([10.21.90.153]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Mar 2006 09:29:14 -0800 In-Reply-To: <200603081510.k28FA7514865@merlot.juniper.net> References: <200603081510.k28FA7514865@merlot.juniper.net> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6C4379B2-974B-445A-81C9-73428549C45B@cisco.com> Content-Transfer-Encoding: 7bit From: Bruce Davie Date: Wed, 8 Mar 2006 12:29:16 -0500 To: Yakov Rekhter X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 08 Mar 2006 17:29:14.0762 (UTC) FILETIME=[D22316A0:01C642D5] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: l2vpn@ietf.org Subject: Re: changes in draft-ietf-l2vpn-signaling-07.txt X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org Yakov, Fair comment. As you know we did discuss this privately but reached no consensus. So I have no problem discussing it on the list. Let me explain the change. First, there is an editorial change to remove a dependency of draft-ietf-l3vpn-bgpvpn-auto-06.txt. That is why I said: > That VPN-ID MAY be a VPN-ID as defined in [RFC2685], in > which case it SHOULD be encoded as an RD by placing the value > 0x80 in > the first byte of the RD (to indicate the RD type) and the 7-byte > VPN-ID in the remaining bytes of the RD. where as previously there was text that said If the globally unique identifier for a VPLS is an RFC2685 VPN-id, it can be encoded as an RD as specified in [BGP- AUTO]. The non-editorial change is the first sentence: > It is RECOMMENDED that a single VPN-ID be assigned to a VPLS > instance. whereas previously the draft said: In order to use BGP-based auto-discovery as specified in [BGP-AUTO], there must be at least one globally unique identifier associated with a VPLS, and each such identifier must be encodable as an 8-byte Route Distinguisher (RD). That is, in addition to requiring that there MUST be *at least one* globally unique ID for a VPLS, it now says, in effect, that there SHOULD be exactly one. The rationale for the change was that, on close reading of the PWE control protocol draft, I realised that some implementations of that draft might attempt to build 2 PWs between a pair of VSIs if the two VSIs had different RDs. Rather than try to change the PWE draft (which was already in the RFC editor queue) I elected to add this guidance - but not a MUST - to the l2vpn signaling draft. Since the draft still allows the use of multiple RDs per VPLS instance, I leave it to the WG to decide if the change is acceptable or not. Bruce On Mar 8, 2006, at 10:10 AM, Yakov Rekhter wrote: > Folks, > >> From 3.2.2.1: > > It is RECOMMENDED that a single VPN-ID be assigned to a VPLS > instance. That VPN-ID MAY be a VPN-ID as defined in [RFC2685], in > which case it SHOULD be encoded as an RD by placing the value > 0x80 in > the first byte of the RD (to indicate the RD type) and the 7-byte > VPN-ID in the remaining bytes of the RD. > > The above is clearly well beyond an editorial change. It was added > after the document passed the WG Last Call. It was added with no > discussion on the l2vpn mailing list, and no consensus of the WG. > > With this in mind before progressing this document any further > I'd like the authors of draft-ietf-l2vpn-signaling-07.txt to document > the rationale for this change, and for the WG chairs to ask for the > WG consensus on this change. > > Yakov. From l2vpn-bounces@ietf.org Sun Mar 12 11:31:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FITT1-00044u-Uq; Sun, 12 Mar 2006 11:30:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FITT0-00044L-M8 for l2vpn@ietf.org; Sun, 12 Mar 2006 11:30:50 -0500 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FITSz-0001fz-EB for l2vpn@ietf.org; Sun, 12 Mar 2006 11:30:50 -0500 Received: from [172.16.15.25] (dsl081-098-224.den1.dsl.speakeasy.net [64.81.98.224]) by dog.tcb.net (Postfix) with ESMTP id 5710164537 for ; Sun, 12 Mar 2006 09:30:29 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: l2vpn@ietf.org From: Shane Amante Date: Sun, 12 Mar 2006 09:30:33 -0700 X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: DRAFT Agenda for L2VPN WG @ IETF 65 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org Hello, A draft agenda for L2VPN is published at: http://www3.ietf.org/proceedings/06mar/agenda/l2vpn.txt Alternatively, if that doesn't work, the draft agenda is also located here: http://l2vpn.tcb.net/meetings/ietf65/l2vpn-agenda.txt We have been confirmed to meet on Thursday, March 23, 1300-1500. Right now, the L2VPN WG agenda is fairly light and are unlikely to need the whole two hours. If you have requested a slot and it's not on here, please let Vach or I know ASAP. If you haven't requested a slot on the agenda, and still need one, please remember that we are allocating time to those items where there is the most value from a face-to-face discussion over unresolved or outstanding points. Thanks, -shane & Vach From l2vpn-bounces@ietf.org Mon Mar 13 14:04:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIsLd-00039i-MN; Mon, 13 Mar 2006 14:04:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH1pT-0000FR-71 for l2vpn@ietf.org; Wed, 08 Mar 2006 11:48:03 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH1pS-00083k-TY for l2vpn@ietf.org; Wed, 08 Mar 2006 11:48:03 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 08 Mar 2006 08:48:03 -0800 X-IronPort-AV: i="4.02,176,1139212800"; d="scan'208"; a="312640714:sNHT31718756" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k28Gm2w1019640; Wed, 8 Mar 2006 08:48:02 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Mar 2006 08:48:02 -0800 Received: from [198.18.187.223] ([10.21.146.9]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Mar 2006 08:48:01 -0800 In-Reply-To: <200603081510.k28FA7514865@merlot.juniper.net> References: <200603081510.k28FA7514865@merlot.juniper.net> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9A0DA6DA-3A8F-4E7B-B03A-A18E179F5131@cisco.com> Content-Transfer-Encoding: 7bit From: Bruce Davie Date: Wed, 8 Mar 2006 11:48:04 -0500 To: Yakov Rekhter X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 08 Mar 2006 16:48:01.0412 (UTC) FILETIME=[0FE7D440:01C642D0] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 X-Mailman-Approved-At: Mon, 13 Mar 2006 14:04:53 -0500 Cc: l2vpn@ietf.org Subject: Re: changes in draft-ietf-l2vpn-signaling-07.txt X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org Yakov, Fair comment. As you know we did discuss this privately but reached no consensus. So I have no problem discussing it on the list. Let me explain the change. First, there is an editorial change to remove a dependency of draft-ietf-l3vpn-bgpvpn-auto-06.txt. That is why I said: > That VPN-ID MAY be a VPN-ID as defined in [RFC2685], in > which case it SHOULD be encoded as an RD by placing the value > 0x80 in > the first byte of the RD (to indicate the RD type) and the 7-byte > VPN-ID in the remaining bytes of the RD. where as previously there was text that said If the globally unique identifier for a VPLS is an RFC2685 VPN-id, it can be encoded as an RD as specified in [BGP- AUTO]. The non-editorial change is the first sentence: > It is RECOMMENDED that a single VPN-ID be assigned to a VPLS > instance. whereas previously the draft said: In order to use BGP-based auto-discovery as specified in [BGP-AUTO], there must be at least one globally unique identifier associated with a VPLS, and each such identifier must be encodable as an 8-byte Route Distinguisher (RD). That is, in addition to requiring that there MUST be *at least one* globally unique ID for a VPLS, it now says, in effect, that there SHOULD be exactly one. The rationale for the change was that, on close reading of the PWE control protocol draft, I realised that some implementations of that draft might attempt to build 2 PWs between a pair of VSIs if the two VSIs had different RDs. Rather than try to change the PWE draft (which was already in the RFC editor queue) I elected to add this guidance - but not a MUST - to the l2vpn signaling draft. Since the draft still allows the use of multiple RDs per VPLS instance, I leave it to the WG to decide if the change is acceptable or not. Bruce On Mar 8, 2006, at 10:10 AM, Yakov Rekhter wrote: > Folks, > >> From 3.2.2.1: > > It is RECOMMENDED that a single VPN-ID be assigned to a VPLS > instance. That VPN-ID MAY be a VPN-ID as defined in [RFC2685], in > which case it SHOULD be encoded as an RD by placing the value > 0x80 in > the first byte of the RD (to indicate the RD type) and the 7-byte > VPN-ID in the remaining bytes of the RD. > > The above is clearly well beyond an editorial change. It was added > after the document passed the WG Last Call. It was added with no > discussion on the l2vpn mailing list, and no consensus of the WG. > > With this in mind before progressing this document any further > I'd like the authors of draft-ietf-l2vpn-signaling-07.txt to document > the rationale for this change, and for the WG chairs to ask for the > WG consensus on this change. > > Yakov. From l2vpn-bounces@ietf.org Fri Mar 17 09:14:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKFiU-0001hm-P7; Fri, 17 Mar 2006 09:14:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKFiU-0001hT-27 for l2vpn@ietf.org; Fri, 17 Mar 2006 09:14:10 -0500 Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56] helo=zrtps0kp.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKFiP-0008MP-Ly for l2vpn@ietf.org; Fri, 17 Mar 2006 09:14:10 -0500 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2HEE1t20928; Fri, 17 Mar 2006 09:14:01 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message Date: Fri, 17 Mar 2006 09:13:55 -0500 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D090B51C9@zcarhxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: changes in draft-ietf-l2vpn-signaling-07.txt Thread-Index: AcZG0Ri6Y+6PZrJmSGu08JhYdpQOWgC9q1hg From: "Hamid Ould-Brahim" To: "Bruce Davie" , "Yakov Rekhter" X-Spam-Score: 0.1 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: l2vpn@ietf.org Subject: RE: changes in draft-ietf-l2vpn-signaling-07.txt X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org Bruce, [clipped...] > > Let me explain the change. First, there is an editorial change to > remove a dependency of draft-ietf-l3vpn-bgpvpn-auto-06.txt. What is the motivation behind removing this dependency? >That is > why I said: > > > That VPN-ID MAY be a VPN-ID as defined in [RFC2685], in > > which case it SHOULD be encoded as an RD by placing the value > > 0x80 in > > the first byte of the RD (to indicate the RD type) and the 7-byte > > VPN-ID in the remaining bytes of the RD. > This text is coming from draft-ietf-l3vpn-bgpvpn-auto-06.txt, could you please add a reference to this text for the bgp-ad draft such that people will know where this text is coming from. > where as previously there was text that said > > If the globally unique identifier for a VPLS is > an RFC2685 VPN-id, it can be encoded as an RD as > specified in [BGP- > AUTO]. > > The non-editorial change is the first sentence: > > > It is RECOMMENDED that a single VPN-ID be assigned to a VPLS > > instance. > If a single VPN-ID is recommended then the question is what format are you suggesting for this VPN-ID? RFC2685? I think one of the problem of the new text proposed is it makes the concept of VPN-ID central to the draft (but without defined it) and is confusing on the format of this term. Is this draft defining new VPN-ID concept besides RFC2685? In that case this VPN-ID needs to be standardized as such. Hamid. > whereas previously the draft said: > > In order to use BGP-based auto-discovery as specified in > [BGP-AUTO], > there must be at least one globally unique identifier associated > with > a VPLS, and each such identifier must be encodable as an 8-byte > Route > Distinguisher (RD). > > That is, in addition to requiring that there MUST be *at least one* > globally unique ID for a VPLS, it now says, in effect, that there > SHOULD be exactly one. > > The rationale for the change was that, on close reading of the PWE > control protocol draft, I realised that some implementations of that > draft might attempt to build 2 PWs between a pair of VSIs if the two > VSIs had different RDs. Rather than try to change the PWE draft > (which was already in the RFC editor queue) I elected to add this > guidance - but not a MUST - to the l2vpn signaling draft. > > Since the draft still allows the use of multiple RDs per VPLS > instance, I leave it to the WG to decide if the change is acceptable > or not. > > Bruce > > > > > > > > On Mar 8, 2006, at 10:10 AM, Yakov Rekhter wrote: > > > Folks, > > > >> From 3.2.2.1: > > > > It is RECOMMENDED that a single VPN-ID be assigned to a VPLS > > instance. That VPN-ID MAY be a VPN-ID as defined in > [RFC2685], in > > which case it SHOULD be encoded as an RD by placing the value > > 0x80 in > > the first byte of the RD (to indicate the RD type) and the 7-byte > > VPN-ID in the remaining bytes of the RD. > > > > The above is clearly well beyond an editorial change. It was added > > after the document passed the WG Last Call. It was added with no > > discussion on the l2vpn mailing list, and no consensus of the WG. > > > > With this in mind before progressing this document any further I'd > > like the authors of draft-ietf-l2vpn-signaling-07.txt to > document the > > rationale for this change, and for the WG chairs to ask for the WG > > consensus on this change. > > > > Yakov. > > > From l2vpn-bounces@ietf.org Sun Mar 19 18:28:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL7KN-0007Sz-1e; Sun, 19 Mar 2006 18:28:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL7KL-0007Sr-P1 for l2vpn@ietf.org; Sun, 19 Mar 2006 18:28:49 -0500 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL7KK-0007fk-HT for l2vpn@ietf.org; Sun, 19 Mar 2006 18:28:49 -0500 Received: from [127.0.0.1] (dog.tcb.net [64.78.150.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id 3A05E64558 for ; Sun, 19 Mar 2006 16:28:41 -0700 (MST) Message-ID: <441DE92E.6050507@castlepoint.net> Date: Sun, 19 Mar 2006 16:28:46 -0700 From: Shane Amante User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: l2vpn@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org The authors of draft-ietf-l2vpn-oam-req-frmk-05, have requested a L2VPN WG Last Call for this I-D, "L2VPN OAM Requirements and Framework". It can be found at: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-oam-req-frmk-05.txt Please thoroughly review the document and send any comments to the list. Also, please indicate whether you believe this document is ready to go to the IESG "as is", or whether there should be a cleaner separation between the requirements and framework. In the latter case, the I-D would not pass LC, would need to get re-drafted for WG comments and the separate components sent out for WG Last Call again. The WG Last Call will end on 10 Apr 2006 at 1700 MST (UTC/GMT -7). -shane From l2vpn-bounces@ietf.org Tue Mar 21 09:04:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLhSr-0004wv-IN; Tue, 21 Mar 2006 09:04:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLhSq-0004ll-3t for l2vpn@ietf.org; Tue, 21 Mar 2006 09:04:00 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLhSp-0000W4-IU for l2vpn@ietf.org; Tue, 21 Mar 2006 09:04:00 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 21 Mar 2006 06:03:59 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2LE3gw9027194 for ; Tue, 21 Mar 2006 06:03:59 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Mar 2006 06:03:50 -0800 Received: from [10.32.241.74] ([10.32.241.74]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Mar 2006 06:03:48 -0800 Mime-Version: 1.0 (Apple Message framework v746.3) In-Reply-To: <085091CB2CA14E4B8B163FFC37C84E9D090B51C9@zcarhxm0.corp.nortel.com> References: <085091CB2CA14E4B8B163FFC37C84E9D090B51C9@zcarhxm0.corp.nortel.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4E2C28A0-BDF9-4450-BDD2-F579EA995E66@cisco.com> Content-Transfer-Encoding: 7bit From: Bruce Davie Date: Tue, 21 Mar 2006 09:03:47 -0500 To: "'l2vpn@ietf.org '" X-Mailer: Apple Mail (2.746.3) X-OriginalArrivalTime: 21 Mar 2006 14:03:49.0120 (UTC) FILETIME=[46DA2000:01C64CF0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Subject: Re: changes in draft-ietf-l2vpn-signaling-07.txt X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org On Mar 17, 2006, at 9:13 AM, Hamid Ould-Brahim wrote: > Bruce, > > [clipped...] > >> >> Let me explain the change. First, there is an editorial change to >> remove a dependency of draft-ietf-l3vpn-bgpvpn-auto-06.txt. > > What is the motivation behind removing this dependency? 1. To ensure that the signaling draft doesn't get help up by the IESG while the fate of another draft (on which it doesn't really depend) is debated 2. To make it easier for an implementor to implement the l2vpn- signaling spec without having to look up the relevant paragraph of another document > >> That is >> why I said: >> >>> That VPN-ID MAY be a VPN-ID as defined in [RFC2685], in >>> which case it SHOULD be encoded as an RD by placing the value >>> 0x80 in >>> the first byte of the RD (to indicate the RD type) and the 7-byte >>> VPN-ID in the remaining bytes of the RD. >> > > This text is coming from draft-ietf-l3vpn-bgpvpn-auto-06.txt, > could you please add a reference to this text for the bgp-ad draft > such that people will know where this text is coming from. There are 2 separate issues here - giving credit to others, and enabling the implementor to figure out what to do. That draft is referenced 3 paragraphs above, and your personal contribution to the signaling draft is noted in the Acknowledgements. So I feel like I've done OK at making sure your work is credited. I'm concerned that if I add yet another reference to bgpvpn-auto, there is a risk of confusing the reader, who might think that he couldn't implement the signaling draft without first refering to the bgpvpn-auto draft. (I have in fact encountered this confusion among members of the IESG already with the prior reference.) > >> where as previously there was text that said >> >> If the globally unique identifier for a VPLS is >> an RFC2685 VPN-id, it can be encoded as an RD as >> specified in [BGP- >> AUTO]. >> >> The non-editorial change is the first sentence: >> >>> It is RECOMMENDED that a single VPN-ID be assigned to a VPLS >>> instance. >> > > If a single VPN-ID is recommended then the question is what format > are you suggesting for this VPN-ID? RFC2685? The draft clearly says that 2685 MAY be used and that other schemes may also be used. > > I think one of the problem of the new text proposed is it makes the > concept of VPN-ID central to the draft (but without defined it) > and is confusing on the format of this term. > > Is this draft defining new VPN-ID concept besides RFC2685? > In that case this VPN-ID needs to be standardized as such. I believe the following 2 paragraphs completely specify what sort of identifier is needed and provides one concrete example of how the identifier MAY be encoded without over-specifying the solution. I think the concept of a globally unique identifier is reasonably well defined, and the specification of the RD in RFC 4364 provides enough detail on how to encode globally unique identifiers as RDs. In order to use BGP-based auto-discovery, there must be at least one globally unique identifier associated with a VPLS, and each such identifier must be encodable as an 8-byte Route Distinguisher (RD). Any method of assigning one or more unique identifiers to a VPLS and encoding each of them as an RD (using the encoding techniques of [RFC4364]) will do. It is RECOMMENDED that a single VPN-ID be assigned to a VPLS instance. That VPN-ID MAY be a VPN-ID as defined in [RFC2685], in which case it SHOULD be encoded as an RD by placing the value 0x80 in the first byte of the RD (to indicate the RD type) and the 7-byte VPN-ID in the remaining bytes of the RD. However, any method of assigning a unique VPN-ID to each VPLS instance and encoding that VPN-ID in an RD MAY be used. > > Hamid. > > >> whereas previously the draft said: >> >> In order to use BGP-based auto-discovery as specified in >> [BGP-AUTO], >> there must be at least one globally unique identifier associated >> with >> a VPLS, and each such identifier must be encodable as an 8-byte >> Route >> Distinguisher (RD). >> > > >> That is, in addition to requiring that there MUST be *at least one* >> globally unique ID for a VPLS, it now says, in effect, that there >> SHOULD be exactly one. >> >> The rationale for the change was that, on close reading of the PWE >> control protocol draft, I realised that some implementations of that >> draft might attempt to build 2 PWs between a pair of VSIs if the two >> VSIs had different RDs. Rather than try to change the PWE draft >> (which was already in the RFC editor queue) I elected to add this >> guidance - but not a MUST - to the l2vpn signaling draft. >> >> Since the draft still allows the use of multiple RDs per VPLS >> instance, I leave it to the WG to decide if the change is acceptable >> or not. >> >> Bruce >> >> >> >> >> >> >> >> On Mar 8, 2006, at 10:10 AM, Yakov Rekhter wrote: >> >>> Folks, >>> >>>> From 3.2.2.1: >>> >>> It is RECOMMENDED that a single VPN-ID be assigned to a VPLS >>> instance. That VPN-ID MAY be a VPN-ID as defined in >> [RFC2685], in >>> which case it SHOULD be encoded as an RD by placing the value >>> 0x80 in >>> the first byte of the RD (to indicate the RD type) and the 7-byte >>> VPN-ID in the remaining bytes of the RD. >>> >>> The above is clearly well beyond an editorial change. It was added >>> after the document passed the WG Last Call. It was added with no >>> discussion on the l2vpn mailing list, and no consensus of the WG. >>> >>> With this in mind before progressing this document any further I'd >>> like the authors of draft-ietf-l2vpn-signaling-07.txt to >> document the >>> rationale for this change, and for the WG chairs to ask for the WG >>> consensus on this change. >>> >>> Yakov. >> >> >> From l2vpn-bounces@ietf.org Tue Mar 21 10:46:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLj3Y-0006i9-4y; Tue, 21 Mar 2006 10:46:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLj3X-0006hp-Ki for l2vpn@ietf.org; Tue, 21 Mar 2006 10:45:59 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLj3X-0004b3-7P for l2vpn@ietf.org; Tue, 21 Mar 2006 10:45:59 -0500 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2LFjuj13203; Tue, 21 Mar 2006 10:45:56 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message Date: Tue, 21 Mar 2006 10:45:48 -0500 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D09260C87@zcarhxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: changes in draft-ietf-l2vpn-signaling-07.txt Thread-Index: AcZM8G4qqz0oZ/syTU+gr1XLq53UDwAChYsw From: "Hamid Ould-Brahim" To: "Bruce Davie" , X-Spam-Score: 0.0 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 Cc: Subject: RE: changes in draft-ietf-l2vpn-signaling-07.txt X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org Bruce, See comments inline. > > On Mar 17, 2006, at 9:13 AM, Hamid Ould-Brahim wrote: > > > Bruce, > > > > [clipped...] > > > >> > >> Let me explain the change. First, there is an editorial change to > >> remove a dependency of draft-ietf-l3vpn-bgpvpn-auto-06.txt. > > > > What is the motivation behind removing this dependency? > > 1. To ensure that the signaling draft doesn't get help up by > the IESG > while the fate of another draft (on which it doesn't really depend) > is debated > 2. To make it easier for an implementor to implement the l2vpn- > signaling spec without having to look up the relevant paragraph of > another document > I understand the goal you're trying to achieve, but I think it would have been more appropriate to discuss first with the authors of the draft-ietf-l3vpn-bgpvpn-auto-06.txt of that goal such that the dependency can be removed in an appropriate way without loosing key information. Because what we really are talking here is to make draft-ietf-l2vpn-signalling-07 as the "standard" for implementing BGP discovery for l2vpn. I wasn't aware of such change was done in the recent 07 draft only after I saw Yakov's email in the mailing list. There are other drafts such as draft-ietf-l2vpn-vpls-ldp-08.txt that have a section on discovery (section 5) that only refers to bgp-auto draft as the discovery for l2vpn. If draft-ietf-l2vpn-signaling-07.txt becomes the main standard for discovery for l2vpn then even this draft needs to be updated. It is certainly a change that impacts other drafts in l2vpn. > > > >> That is > >> why I said: > >> > >>> That VPN-ID MAY be a VPN-ID as defined in [RFC2685], in > >>> which case it SHOULD be encoded as an RD by placing the value > >>> 0x80 in > >>> the first byte of the RD (to indicate the RD type) and > the 7-byte > >>> VPN-ID in the remaining bytes of the RD. > >> > > > > This text is coming from draft-ietf-l3vpn-bgpvpn-auto-06.txt, > > could you please add a reference to this text for the bgp-ad draft > > such that people will know where this text is coming from. > > There are 2 separate issues here - giving credit to others, and > enabling the implementor to figure out what to do. > > That draft is referenced 3 paragraphs above, and your personal > contribution to the signaling draft is noted in the > Acknowledgements. > So I feel like I've done OK at making sure your work is credited. > Believe me my question wasn't about personal credit and draft-ietf-bgpvpn-auto is not just my personal effort, credit is definitely not the issue here at all. > I'm concerned that if I add yet another reference to bgpvpn-auto, > there is a risk of confusing the reader, who might think that he > couldn't implement the signaling draft without first refering to the > bgpvpn-auto draft. (I have in fact encountered this confusion among > members of the IESG already with the prior reference.) > I think this concern can be addressed if we make draft-bgpvpn-auto explicitly as a framework document for implementing bgp as a discovery mechanism. That is why I think removing the dependency can be done but let's do it in an appropriate consulted way. > > > > >> where as previously there was text that said > >> > >> If the globally unique identifier for a VPLS is > >> an RFC2685 VPN-id, it can be encoded as an RD as specified in > >> [BGP- > >> AUTO]. > >> > >> The non-editorial change is the first sentence: > >> > >>> It is RECOMMENDED that a single VPN-ID be assigned to a VPLS > >>> instance. > >> > > > > If a single VPN-ID is recommended then the question is what > format are > > you suggesting for this VPN-ID? RFC2685? > > The draft clearly says that 2685 MAY be used and that other schemes > may also be used. > I think that's the main problem I have with vpn-ids. Why do we need multiple formats for VPN-IDs to be used in a single solution. What's the requirement for that? I understand multiple types for RD since RD is just to build non overlapping addresses. Suppose one provider use RFC2685 as the vpn-id format (complying to this standard) and the other use some other form then they won't be able to interoperate (think about the other issues management, security, etc). > > > > I think one of the problem of the new text proposed is it makes the > > concept of VPN-ID central to the draft (but without defined > it) and is > > confusing on the format of this term. > > > > Is this draft defining new VPN-ID concept besides RFC2685? > > In that case this VPN-ID needs to be standardized as such. > > I believe the following 2 paragraphs completely specify what sort of > identifier is needed and provides one concrete example of how the > identifier MAY be encoded without over-specifying the solution. I > think the concept of a globally unique identifier is reasonably well > defined, and the specification of the RD in RFC 4364 provides enough > detail on how to encode globally unique identifiers as RDs. > Yes. But these are just globally unique identifiers used as RDs. RD is not a VPN-ID. In fact RD is a concept needed for BGP discovery, VPN-ID is a concept that goes beyond the discovery, signaling mechanisms. Hamid. > In order to use BGP-based auto-discovery, there must be > at least one > globally unique identifier associated with a VPLS, and each such > identifier must be encodable as an 8-byte Route > Distinguisher (RD). > Any method of assigning one or more unique identifiers to > a VPLS and > encoding each of them as an RD (using the encoding techniques of > [RFC4364]) will do. > > It is RECOMMENDED that a single VPN-ID be assigned to a VPLS > instance. That VPN-ID MAY be a VPN-ID as defined in [RFC2685], in > which case it SHOULD be encoded as an RD by placing the value > 0x80 in > the first byte of the RD (to indicate the RD type) and the 7-byte > VPN-ID in the remaining bytes of the RD. However, any method of > assigning a unique VPN-ID to each VPLS instance and encoding that > VPN-ID in an RD MAY be used. > > > > > Hamid. > > > > > >> whereas previously the draft said: > >> > >> In order to use BGP-based auto-discovery as specified in > >> [BGP-AUTO], > >> there must be at least one globally unique identifier > associated > >> with > >> a VPLS, and each such identifier must be encodable as > an 8-byte > >> Route > >> Distinguisher (RD). > >> > > > > > >> That is, in addition to requiring that there MUST be *at > least one* > >> globally unique ID for a VPLS, it now says, in effect, that there > >> SHOULD be exactly one. > >> > >> The rationale for the change was that, on close reading of the PWE > >> control protocol draft, I realised that some > implementations of that > >> draft might attempt to build 2 PWs between a pair of VSIs > if the two > >> VSIs had different RDs. Rather than try to change the PWE draft > >> (which was already in the RFC editor queue) I elected to add this > >> guidance - but not a MUST - to the l2vpn signaling draft. > >> > >> Since the draft still allows the use of multiple RDs per VPLS > >> instance, I leave it to the WG to decide if the change is > acceptable > >> or not. > >> > >> Bruce > >> > >> > >> > >> > >> > >> > >> > >> On Mar 8, 2006, at 10:10 AM, Yakov Rekhter wrote: > >> > >>> Folks, > >>> > >>>> From 3.2.2.1: > >>> > >>> It is RECOMMENDED that a single VPN-ID be assigned to a VPLS > >>> instance. That VPN-ID MAY be a VPN-ID as defined in > >> [RFC2685], in > >>> which case it SHOULD be encoded as an RD by placing the value > >>> 0x80 in > >>> the first byte of the RD (to indicate the RD type) and > the 7-byte > >>> VPN-ID in the remaining bytes of the RD. > >>> > >>> The above is clearly well beyond an editorial change. It > was added > >>> after the document passed the WG Last Call. It was added with no > >>> discussion on the l2vpn mailing list, and no consensus of the WG. > >>> > >>> With this in mind before progressing this document any > further I'd > >>> like the authors of draft-ietf-l2vpn-signaling-07.txt to > >> document the > >>> rationale for this change, and for the WG chairs to ask > for the WG > >>> consensus on this change. > >>> > >>> Yakov. > >> > >> > >> > > > From l2vpn-bounces@ietf.org Tue Mar 21 12:36:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLkmq-0002Vm-28; Tue, 21 Mar 2006 12:36:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLkmo-0002Ua-7r for l2vpn@ietf.org; Tue, 21 Mar 2006 12:36:50 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLkmn-0000q6-VR for l2vpn@ietf.org; Tue, 21 Mar 2006 12:36:50 -0500 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2LHalk12330 for ; Tue, 21 Mar 2006 12:36:47 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message Date: Tue, 21 Mar 2006 12:36:44 -0500 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D09260EFF@zcarhxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 2 different signaling procedures for vpls-ldp Thread-Index: AcZLyJ/jh6OAawHDSCu7T0YavrfJ7QBQvcaA From: "Hamid Ould-Brahim" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Subject: 2 different signaling procedures for vpls-ldp X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org > As I am reading through the recent version of > draft-ietf-l2vpn-signaling-07 and contrasting it to draft-ietf-l2vpn-vpls-ldp-08.txt, I find out that there is > an issue that need some clarification with respect to signaling > procedures for VPLS using LDP protocol. > > I noticed we have in fact two different signaling procedures > for vpls-ldp that do exactly the same thing and > are not inline and cannot interoperate. > > In draft draft-ietf-l2vpn-vpls-ldp-08.txt section 6.1.1 > ("Using the Generalized PWid FEC Element", part of section 6.1 > Signaling for LDP...), it says: > > "TAII, SAII: These are null because the mesh of PWs in a VPLS > terminate on MAC learning tables, rather than on individual > attachment circuits. The use of non-null TAII and SAII is reserved > for future enhancements." > > But draft draft-ietf-l2vpn-signaling-07 says in the > "signalling" section 3.2.3 (part of section 3.2 VPLS): > > "The SAII MUST be set to the PE_addr of the sending PE (or, more > generally, > the VSI-ID, without the RD, of the VSI associated with this VPLS in > the > sending PE), to enable signaling of the reverse half of the PW if > needed. > > The structure of the AGI and AII fields for the Generalized ID FEC > in > LDP is defined in [I-D.ietf-pwe3-control-protocol]. The AGI field > in > this case consists of a Type of 1, a length field of value 8, and > the > 8 bytes of the RD. The TAII consists of a Type of 1, a length > field > of value 4, followed by the 4-byte PE address (or other 4-byte > identifier)." > These two signaling procedures are non interoperable in their way of handling the SAII, TAII. A PE (that is signaling compliant to draft draft-ietf-l2vpn-signaling-07) talking to a PE that is only signaling compliant to draft-ietf-l2vpn-vpls-ldp-08.txt will not be able to establish a pseudowire to it. If one wants to implement VPLS using ldp which draft should she/he pick for signaling purposes? or to be more precise which signaling procedures are the minimum required for standard purposes? Note that both are doing exactly the same thing establish pseudowires between VSIs. This needs clarification. > Hamid. > > From l2vpn-bounces@ietf.org Tue Mar 21 12:44:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLkts-00061T-3y; Tue, 21 Mar 2006 12:44:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLktq-00061N-Pe for l2vpn@ietf.org; Tue, 21 Mar 2006 12:44:06 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLktq-00014d-Fn for l2vpn@ietf.org; Tue, 21 Mar 2006 12:44:06 -0500 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2LHi4k13377 for ; Tue, 21 Mar 2006 12:44:04 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message Date: Tue, 21 Mar 2006 12:44:02 -0500 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D09260F1C@zcarhxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 2 different signaling procedures for vpls-ldp Thread-Index: AcZNDwpfKkitb/GiS82upZzQK/aJlg== From: "Hamid Ould-Brahim" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Subject: 2 different signaling procedures for vpls-ldp X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org As I am reading through the recent version of draft-ietf-l2vpn-signaling-07 and contrasting it to draft-ietf-l2vpn-vpls-ldp-08.txt, I find out that there is an issue that need some clarification with respect to signaling procedures for VPLS using LDP protocol. I noticed we have in fact two different signaling procedures for vpls-ldp that do exactly the same thing and are not inline and cannot interoperate. In draft draft-ietf-l2vpn-vpls-ldp-08.txt section 6.1.1 ("Using the Generalized PWid FEC Element", part of section 6.1 Signaling for LDP...), it says: "TAII, SAII: These are null because the mesh of PWs in a VPLS terminate on MAC learning tables, rather than on individual attachment circuits. The use of non-null TAII and SAII is reserved for future enhancements." But draft draft-ietf-l2vpn-signaling-07 says in the "signalling" section 3.2.3 (part of section 3.2 VPLS): "The SAII MUST be set to the PE_addr of the sending PE (or, more generally, the VSI-ID, without the RD, of the VSI associated with this VPLS in the sending PE), to enable signaling of the reverse half of the PW if needed. The structure of the AGI and AII fields for the Generalized ID FEC in LDP is defined in [I-D.ietf-pwe3-control-protocol]. The AGI field in this case consists of a Type of 1, a length field of value 8, and the 8 bytes of the RD. The TAII consists of a Type of 1, a length field of value 4, followed by the 4-byte PE address (or other 4-byte identifier)." These two signaling procedures are non interoperable in their way of handling the SAII, TAII. A PE (that is signaling compliant to draft draft-ietf-l2vpn-signaling-07) talking to a PE that is only signaling compliant to draft-ietf-l2vpn-vpls-ldp-08.txt will not be able to establish a pseudowire to it. If one wants to implement VPLS using ldp which draft should she/he pick for signaling purposes? or to be more precise which signaling procedures are the minimum required for standard purposes? Note that both are doing exactly the same thing establish pseudowires between VSIs. This needs clarification. Hamid. From l2vpn-bounces@ietf.org Tue Mar 21 13:05:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLlEv-00039a-K8; Tue, 21 Mar 2006 13:05:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLlEu-00039V-GN for l2vpn@ietf.org; Tue, 21 Mar 2006 13:05:52 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLlEu-0002PL-6Y for l2vpn@ietf.org; Tue, 21 Mar 2006 13:05:52 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 21 Mar 2006 10:05:51 -0800 X-IronPort-AV: i="4.03,115,1141632000"; d="scan'208"; a="316710229:sNHT27015656" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k2LI5o7X025976; Tue, 21 Mar 2006 10:05:51 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Mar 2006 10:05:50 -0800 Received: from [10.32.241.74] ([10.32.241.74]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Mar 2006 10:05:49 -0800 In-Reply-To: <085091CB2CA14E4B8B163FFC37C84E9D09260EFF@zcarhxm0.corp.nortel.com> References: <085091CB2CA14E4B8B163FFC37C84E9D09260EFF@zcarhxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Bruce Davie Date: Tue, 21 Mar 2006 13:05:47 -0500 To: "Hamid Ould-Brahim" X-Mailer: Apple Mail (2.746.3) X-OriginalArrivalTime: 21 Mar 2006 18:05:49.0640 (UTC) FILETIME=[15C1A480:01C64D12] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: l2vpn@ietf.org Subject: Re: 2 different signaling procedures for vpls-ldp X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org I pointed out this problem to the authors of draft-ietf-l2vpn-vpls- ldp a little more than 12 months ago. They were reluctant to change a draft that had already passed WG last call. I think the answer is that if you want to do autodiscovery, they you should do what is specified in draft-ietf-l2vpn-signaling. If you don't care about autodiscovery, then the procedures draft-ietf-l2vpn- vpls-ldp will work. As a practical matter, I think that all implementations of draft-ietf-l2vpn-vpls-ldp today are using FEC 128, not 129. I would expect that as vendors start to implement autodiscovery, they will have to implement FEC 129 (it's the only thing specified in draft-ietf-l2vpn-signaling) and fill in the SAII and TAII fields as specified in draft-ietf-l2vpn-signaling. Bruce On Mar 21, 2006, at 12:36 PM, Hamid Ould-Brahim wrote: > >> As I am reading through the recent version of >> draft-ietf-l2vpn-signaling-07 and contrasting it to > draft-ietf-l2vpn-vpls-ldp-08.txt, I find out that there is >> an issue that need some clarification with respect to signaling >> procedures for VPLS using LDP protocol. >> >> I noticed we have in fact two different signaling procedures >> for vpls-ldp that do exactly the same thing and >> are not inline and cannot interoperate. >> >> In draft draft-ietf-l2vpn-vpls-ldp-08.txt section 6.1.1 >> ("Using the Generalized PWid FEC Element", part of section 6.1 >> Signaling for LDP...), it says: >> >> "TAII, SAII: These are null because the mesh of PWs in a VPLS >> terminate on MAC learning tables, rather than on individual >> attachment circuits. The use of non-null TAII and SAII is reserved >> for future enhancements." >> >> But draft draft-ietf-l2vpn-signaling-07 says in the >> "signalling" section 3.2.3 (part of section 3.2 VPLS): >> >> "The SAII MUST be set to the PE_addr of the sending PE (or, more >> generally, >> the VSI-ID, without the RD, of the VSI associated with this VPLS in >> the >> sending PE), to enable signaling of the reverse half of the PW if >> needed. >> >> The structure of the AGI and AII fields for the Generalized ID FEC >> in >> LDP is defined in [I-D.ietf-pwe3-control-protocol]. The AGI field >> in >> this case consists of a Type of 1, a length field of value 8, and >> the >> 8 bytes of the RD. The TAII consists of a Type of 1, a length >> field >> of value 4, followed by the 4-byte PE address (or other 4-byte >> identifier)." >> > These two signaling procedures are non interoperable in their way > of handling the SAII, TAII. A PE (that is signaling compliant > to draft draft-ietf-l2vpn-signaling-07) talking to a PE > that is only signaling compliant to draft-ietf-l2vpn-vpls-ldp-08.txt > will not be able to establish a pseudowire to it. > > If one wants to implement VPLS using ldp which draft should > she/he pick for signaling purposes? or to be more precise which > signaling procedures are the minimum required for standard purposes? > > Note that both are doing exactly the same thing establish > pseudowires between VSIs. This needs clarification. > >> Hamid. >> >> From l2vpn-bounces@ietf.org Tue Mar 21 15:10:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLnBK-0007WL-3T; Tue, 21 Mar 2006 15:10:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLnBI-0007UD-7b for l2vpn@ietf.org; Tue, 21 Mar 2006 15:10:16 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLnBH-0006l3-TC for l2vpn@ietf.org; Tue, 21 Mar 2006 15:10:16 -0500 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2LKACk04169; Tue, 21 Mar 2006 15:10:12 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message Date: Tue, 21 Mar 2006 15:10:10 -0500 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D09261252@zcarhxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 2 different signaling procedures for vpls-ldp Thread-Index: AcZNEhnQjqe/z+PBSLKsEueVqEDitQACqgVw From: "Hamid Ould-Brahim" To: "Bruce Davie" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: l2vpn@ietf.org Subject: RE: 2 different signaling procedures for vpls-ldp X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org Bruce, > > I pointed out this problem to the authors of draft-ietf-l2vpn-vpls- > ldp a little more than 12 months ago. They were reluctant to change > a draft that had already passed WG last call. > > I think the answer is that if you want to do autodiscovery, they you > should do what is specified in draft-ietf-l2vpn-signaling. If you > don't care about autodiscovery, then the procedures draft-ietf-l2vpn- > vpls-ldp will work. But that's not what draft-ietf-l2vpn-vpls-ldp is saying (and also is not what draft-ietf-l2vpn-signaling is saying). The vpls-ldp draft does not preclude the use of an auto-discovery mechanism referring to the BGP and Radius drafts (with no reference and dependency on draft-ietf-l2vpn-signaling from discovery point of view (according to section 5)). While what you are saying is a) if one needs to implement a *BGP* auto-discovery for VPLS then it MUST use the signaling procedures described in draft-ietf-l2vpn-signaling (BTW it wasn't clear to me that to use draft-ietf-l2vpn-signaling-07 then one MUST deploy bgp auto-discovery mechanism). While the vpls-ldp draft is saying that the signaling procedures described in vpls-ldp draft work whether you use an auto-discovery mechanism or not. b) if one wants to use the signaling procedures described in draft-l2vpn-signaling-07 then it MUST implement and use a BGP auto-discovery mechanism. While the requirement draft seems implying that an auto-discovery mechanism is optional for l2vpn not a MUST have mechanism. This implies that if one wants to deploy first VPLS solution without an auto-discovery mechanism then it needs to use the signaling procedures described in vpls-ldp draft. But if later on, this provider wants to deploy a BGP auto-discovery (for scalability reasons) then this provider MUST change all its signaling scheme including provisioning deployed using vpls-ldp draft. This doesn't seem right. Looks like there is no other option then to have one signaling standard procedures for VPLS using LDP (for SAII, TAII, etc) not two different ones. Hamid. > As a practical matter, I think that all > implementations of draft-ietf-l2vpn-vpls-ldp today are using > FEC 128, > not 129. I would expect that as vendors start to implement > autodiscovery, they will have to implement FEC 129 (it's the only > thing specified in draft-ietf-l2vpn-signaling) and fill in the SAII > and TAII fields as specified in draft-ietf-l2vpn-signaling. > > Bruce > > On Mar 21, 2006, at 12:36 PM, Hamid Ould-Brahim wrote: > > > > >> As I am reading through the recent version of > >> draft-ietf-l2vpn-signaling-07 and contrasting it to > > draft-ietf-l2vpn-vpls-ldp-08.txt, I find out that there is > >> an issue that need some clarification with respect to signaling > >> procedures for VPLS using LDP protocol. > >> > >> I noticed we have in fact two different signaling procedures for > >> vpls-ldp that do exactly the same thing and are not inline > and cannot > >> interoperate. > >> > >> In draft draft-ietf-l2vpn-vpls-ldp-08.txt section 6.1.1 > ("Using the > >> Generalized PWid FEC Element", part of section 6.1 Signaling for > >> LDP...), it says: > >> > >> "TAII, SAII: These are null because the mesh of PWs in a VPLS > >> terminate on MAC learning tables, rather than on individual > >> attachment circuits. The use of non-null TAII and SAII is > reserved > >> for future enhancements." > >> > >> But draft draft-ietf-l2vpn-signaling-07 says in the "signalling" > >> section 3.2.3 (part of section 3.2 VPLS): > >> > >> "The SAII MUST be set to the PE_addr of the sending PE (or, more > >> generally, the VSI-ID, without the RD, of the VSI associated with > >> this VPLS in the > >> sending PE), to enable signaling of the reverse half of the PW if > >> needed. > >> > >> The structure of the AGI and AII fields for the > Generalized ID FEC > >> in > >> LDP is defined in [I-D.ietf-pwe3-control-protocol]. > The AGI field > >> in > >> this case consists of a Type of 1, a length field of > value 8, and > >> the > >> 8 bytes of the RD. The TAII consists of a Type of 1, a length > >> field > >> of value 4, followed by the 4-byte PE address (or other 4-byte > >> identifier)." > >> > > These two signaling procedures are non interoperable in > their way of > > handling the SAII, TAII. A PE (that is signaling compliant to draft > > draft-ietf-l2vpn-signaling-07) talking to a PE that is only > signaling > > compliant to draft-ietf-l2vpn-vpls-ldp-08.txt will not be able to > > establish a pseudowire to it. > > > > If one wants to implement VPLS using ldp which draft should she/he > > pick for signaling purposes? or to be more precise which signaling > > procedures are the minimum required for standard purposes? > > > > Note that both are doing exactly the same thing establish > pseudowires > > between VSIs. This needs clarification. > > > >> Hamid. > >> > >> > > From l2vpn-bounces@ietf.org Tue Mar 21 16:48:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLoii-00081D-4e; Tue, 21 Mar 2006 16:48:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLoig-0007zP-2m for l2vpn@ietf.org; Tue, 21 Mar 2006 16:48:50 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLoie-0004nt-Gv for l2vpn@ietf.org; Tue, 21 Mar 2006 16:48:50 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 21 Mar 2006 13:48:48 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2LLmlGv009680; Tue, 21 Mar 2006 13:48:47 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Mar 2006 13:48:47 -0800 Received: from [10.32.241.74] ([10.32.241.74]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Mar 2006 13:48:47 -0800 In-Reply-To: <085091CB2CA14E4B8B163FFC37C84E9D09261252@zcarhxm0.corp.nortel.com> References: <085091CB2CA14E4B8B163FFC37C84E9D09261252@zcarhxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2C162760-D74C-4E79-8112-DE0C755C87B4@cisco.com> Content-Transfer-Encoding: 7bit From: Bruce Davie Date: Tue, 21 Mar 2006 16:48:45 -0500 To: "Hamid Ould-Brahim" X-Mailer: Apple Mail (2.746.3) X-OriginalArrivalTime: 21 Mar 2006 21:48:47.0187 (UTC) FILETIME=[3B655230:01C64D31] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: l2vpn@ietf.org Subject: Re: 2 different signaling procedures for vpls-ldp X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org Hamid, The vpls-ldp does not *intentionally* preclude autodiscovery. However, because autodiscovery (and its impact on signaling) had not been fully specified at the time of the WG last call for vpls-ldp, the signaling procedures there are incomplete for the purposes of autodiscovery. Specifically they don't convey enough information to work in an inter-AS environment with autodiscovery and multisegment PWs. The key words in vpls-ldp are: " The use of non-null TAII and SAII is reserved for future enhancements." Autodiscovery turns out to be a future enhancement relative to the vpls-ldp spec. Since the signaling procedures defined in draft-ietf-l2vpn- signaling work with or without autodiscovery, one might choose to implement only those procedures. It is worth noting that a device knows whether or not it is doing autodiscovery, so it could choose to use the signaling messages of vpls-ldp when it does not do autodiscovery and the messages of l2vpn- signaling when it is doing autodiscovery. I agree that this is not ideal. But I don't think it causes fundamental breakage either. Bruce On Mar 21, 2006, at 3:10 PM, Hamid Ould-Brahim wrote: > Bruce, > >> >> I pointed out this problem to the authors of draft-ietf-l2vpn-vpls- >> ldp a little more than 12 months ago. They were reluctant to change >> a draft that had already passed WG last call. >> >> I think the answer is that if you want to do autodiscovery, they you >> should do what is specified in draft-ietf-l2vpn-signaling. If you >> don't care about autodiscovery, then the procedures draft-ietf-l2vpn- >> vpls-ldp will work. > > But that's not what draft-ietf-l2vpn-vpls-ldp is saying > (and also is not what draft-ietf-l2vpn-signaling is saying). > The vpls-ldp draft does not preclude the use of an auto-discovery > mechanism referring to the BGP and Radius drafts > (with no reference and dependency on draft-ietf-l2vpn-signaling > from discovery point of view (according to section 5)). > > While what you are saying is > > a) if one needs to implement a *BGP* auto-discovery for VPLS then > it MUST use the signaling procedures described in > draft-ietf-l2vpn-signaling (BTW it wasn't clear to me > that to use draft-ietf-l2vpn-signaling-07 then one MUST deploy > bgp auto-discovery mechanism). While the vpls-ldp draft is saying > that the signaling procedures described in vpls-ldp draft > work whether you use an auto-discovery mechanism or not. > > b) if one wants to use the signaling procedures described in > draft-l2vpn-signaling-07 then it MUST implement and use > a BGP auto-discovery mechanism. While the requirement draft seems > implying that an auto-discovery mechanism is optional for > l2vpn not a MUST have mechanism. > > This implies that if one wants to deploy first VPLS > solution without an auto-discovery mechanism then > it needs to use the signaling procedures described in > vpls-ldp draft. But if later on, this provider wants to deploy a BGP > auto-discovery (for scalability reasons) then this provider > MUST change all its signaling scheme including provisioning > deployed using vpls-ldp draft. This doesn't seem right. > > Looks like there is no other option then to have one signaling > standard procedures for VPLS using LDP (for SAII, TAII, etc) > not two different ones. > > Hamid. > > >> As a practical matter, I think that all >> implementations of draft-ietf-l2vpn-vpls-ldp today are using >> FEC 128, >> not 129. I would expect that as vendors start to implement >> autodiscovery, they will have to implement FEC 129 (it's the only >> thing specified in draft-ietf-l2vpn-signaling) and fill in the SAII >> and TAII fields as specified in draft-ietf-l2vpn-signaling. >> >> Bruce >> >> On Mar 21, 2006, at 12:36 PM, Hamid Ould-Brahim wrote: >> >>> >>>> As I am reading through the recent version of >>>> draft-ietf-l2vpn-signaling-07 and contrasting it to >>> draft-ietf-l2vpn-vpls-ldp-08.txt, I find out that there is >>>> an issue that need some clarification with respect to signaling >>>> procedures for VPLS using LDP protocol. >>>> >>>> I noticed we have in fact two different signaling procedures for >>>> vpls-ldp that do exactly the same thing and are not inline >> and cannot >>>> interoperate. >>>> >>>> In draft draft-ietf-l2vpn-vpls-ldp-08.txt section 6.1.1 >> ("Using the >>>> Generalized PWid FEC Element", part of section 6.1 Signaling for >>>> LDP...), it says: >>>> >>>> "TAII, SAII: These are null because the mesh of PWs in a VPLS >>>> terminate on MAC learning tables, rather than on individual >>>> attachment circuits. The use of non-null TAII and SAII is >> reserved >>>> for future enhancements." >>>> >>>> But draft draft-ietf-l2vpn-signaling-07 says in the "signalling" >>>> section 3.2.3 (part of section 3.2 VPLS): >>>> >>>> "The SAII MUST be set to the PE_addr of the sending PE (or, more >>>> generally, the VSI-ID, without the RD, of the VSI associated with >>>> this VPLS in the >>>> sending PE), to enable signaling of the reverse half of the PW if >>>> needed. >>>> >>>> The structure of the AGI and AII fields for the >> Generalized ID FEC >>>> in >>>> LDP is defined in [I-D.ietf-pwe3-control-protocol]. >> The AGI field >>>> in >>>> this case consists of a Type of 1, a length field of >> value 8, and >>>> the >>>> 8 bytes of the RD. The TAII consists of a Type of 1, a length >>>> field >>>> of value 4, followed by the 4-byte PE address (or other 4-byte >>>> identifier)." >>>> >>> These two signaling procedures are non interoperable in >> their way of >>> handling the SAII, TAII. A PE (that is signaling compliant to draft >>> draft-ietf-l2vpn-signaling-07) talking to a PE that is only >> signaling >>> compliant to draft-ietf-l2vpn-vpls-ldp-08.txt will not be able to >>> establish a pseudowire to it. >>> >>> If one wants to implement VPLS using ldp which draft should she/he >>> pick for signaling purposes? or to be more precise which signaling >>> procedures are the minimum required for standard purposes? >>> >>> Note that both are doing exactly the same thing establish >> pseudowires >>> between VSIs. This needs clarification. >>> >>>> Hamid. >>>> >>>> >> >> From l2vpn-bounces@ietf.org Tue Mar 21 19:41:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLrPj-0006Cf-S1; Tue, 21 Mar 2006 19:41:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLrPf-0005ze-Q2 for l2vpn@ietf.org; Tue, 21 Mar 2006 19:41:23 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLrPf-0004A8-Dc for l2vpn@ietf.org; Tue, 21 Mar 2006 19:41:23 -0500 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2M0fJP07485; Tue, 21 Mar 2006 19:41:20 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message Date: Tue, 21 Mar 2006 19:41:17 -0500 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D09261578@zcarhxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 2 different signaling procedures for vpls-ldp Thread-Index: AcZNMT75fZpfJAU3TfGMrokyGKZBYgAE8hMA From: "Hamid Ould-Brahim" To: "Bruce Davie" X-Spam-Score: 0.0 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Cc: l2vpn@ietf.org Subject: RE: 2 different signaling procedures for vpls-ldp X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org Bruce, > > The vpls-ldp does not *intentionally* preclude autodiscovery. > However, because autodiscovery (and its impact on signaling) had not > been fully specified at the time of the WG last call for vpls-ldp, > the signaling procedures there are incomplete for the purposes of > autodiscovery. Specifically they don't convey enough information to > work in an inter-AS environment with autodiscovery and multisegment > PWs. In fact ideally l2vpn-signaling draft is in fact obsoleting the signaling procedures of vpls-ldp with respect to the use of FEC129. >The key words in vpls-ldp are: > > " The use of non-null TAII and SAII is reserved > for future enhancements." > > Autodiscovery turns out to be a future enhancement relative to the > vpls-ldp spec. > The above statement is too vague. If that is the case then somewhere this needs to be captured (or section 5 updated and the signaling section removed?). > Since the signaling procedures defined in draft-ietf-l2vpn- > signaling work with or without autodiscovery, one might choose to > implement only those procedures. > > It is worth noting that a device knows whether or not it is doing > autodiscovery, so it could choose to use the signaling messages of > vpls-ldp when it does not do autodiscovery and the messages of l2vpn- > signaling when it is doing autodiscovery. The problem may arise if some PEs are using one form of signaling while other PEs (or other provider network) are using the signaling draft form. Even if the device can do auto-discovery, the remote device (which doesn't participate in the discovery) may send to this device a label mapping formatted using vpls-ldp procedures. What should the receiving device do in this case? Use null SAII, TAII for some PE and VSI-IDs for others for the same VPLS? In that case there will be a need to specify the interworking rules between the two schemes (lack of better term). This is assuming that some provider may take them more time to switch to l2vpn-signaling model... > I agree that this is not > ideal. But I don't think it causes fundamental breakage either. > It may not as long as it is clear and documented. Right now it doesn't seem so just from the texts we have! Hamid. > > Bruce > > On Mar 21, 2006, at 3:10 PM, Hamid Ould-Brahim wrote: > > > Bruce, > > > >> > >> I pointed out this problem to the authors of > draft-ietf-l2vpn-vpls- > >> ldp a little more than 12 months ago. They were reluctant > to change > >> a draft that had already passed WG last call. > >> > >> I think the answer is that if you want to do > autodiscovery, they you > >> should do what is specified in draft-ietf-l2vpn-signaling. If you > >> don't care about autodiscovery, then the procedures > draft-ietf-l2vpn- > >> vpls-ldp will work. > > > > But that's not what draft-ietf-l2vpn-vpls-ldp is saying > > (and also is not what draft-ietf-l2vpn-signaling is saying). The > > vpls-ldp draft does not preclude the use of an auto-discovery > > mechanism referring to the BGP and Radius drafts (with no reference > > and dependency on draft-ietf-l2vpn-signaling from discovery > point of > > view (according to section 5)). > > > > While what you are saying is > > > > a) if one needs to implement a *BGP* auto-discovery for VPLS then > > it MUST use the signaling procedures described in > > draft-ietf-l2vpn-signaling (BTW it wasn't clear to me > > that to use draft-ietf-l2vpn-signaling-07 then one MUST deploy > > bgp auto-discovery mechanism). While the vpls-ldp draft is saying > > that the signaling procedures described in vpls-ldp draft > > work whether you use an auto-discovery mechanism or not. > > > > b) if one wants to use the signaling procedures described in > > draft-l2vpn-signaling-07 then it MUST implement and use > > a BGP auto-discovery mechanism. While the requirement draft seems > > implying that an auto-discovery mechanism is optional for > > l2vpn not a MUST have mechanism. > > > > This implies that if one wants to deploy first VPLS > > solution without an auto-discovery mechanism then > > it needs to use the signaling procedures described in > vpls-ldp draft. > > But if later on, this provider wants to deploy a BGP auto-discovery > > (for scalability reasons) then this provider MUST change all its > > signaling scheme including provisioning deployed using > vpls-ldp draft. > > This doesn't seem right. > > > > Looks like there is no other option then to have one signaling > > standard procedures for VPLS using LDP (for SAII, TAII, > etc) not two > > different ones. > > > > Hamid. > > > > > >> As a practical matter, I think that all > >> implementations of draft-ietf-l2vpn-vpls-ldp today are > using FEC 128, > >> not 129. I would expect that as vendors start to implement > >> autodiscovery, they will have to implement FEC 129 (it's the only > >> thing specified in draft-ietf-l2vpn-signaling) and fill in the SAII > >> and TAII fields as specified in draft-ietf-l2vpn-signaling. > >> > >> Bruce > >> > >> On Mar 21, 2006, at 12:36 PM, Hamid Ould-Brahim wrote: > >> > >>> > >>>> As I am reading through the recent version of > >>>> draft-ietf-l2vpn-signaling-07 and contrasting it to > >>> draft-ietf-l2vpn-vpls-ldp-08.txt, I find out that there is > >>>> an issue that need some clarification with respect to signaling > >>>> procedures for VPLS using LDP protocol. > >>>> > >>>> I noticed we have in fact two different signaling procedures for > >>>> vpls-ldp that do exactly the same thing and are not inline > >> and cannot > >>>> interoperate. > >>>> > >>>> In draft draft-ietf-l2vpn-vpls-ldp-08.txt section 6.1.1 > >> ("Using the > >>>> Generalized PWid FEC Element", part of section 6.1 Signaling for > >>>> LDP...), it says: > >>>> > >>>> "TAII, SAII: These are null because the mesh of PWs in a VPLS > >>>> terminate on MAC learning tables, rather than on individual > >>>> attachment circuits. The use of non-null TAII and SAII is > >> reserved > >>>> for future enhancements." > >>>> > >>>> But draft draft-ietf-l2vpn-signaling-07 says in the "signalling" > >>>> section 3.2.3 (part of section 3.2 VPLS): > >>>> > >>>> "The SAII MUST be set to the PE_addr of the sending PE (or, more > >>>> generally, the VSI-ID, without the RD, of the VSI > associated with > >>>> this VPLS in the sending PE), to enable signaling of > the reverse > >>>> half of the PW if needed. > >>>> > >>>> The structure of the AGI and AII fields for the > >> Generalized ID FEC > >>>> in > >>>> LDP is defined in [I-D.ietf-pwe3-control-protocol]. > >> The AGI field > >>>> in > >>>> this case consists of a Type of 1, a length field of > >> value 8, and > >>>> the > >>>> 8 bytes of the RD. The TAII consists of a Type of 1, > a length > >>>> field > >>>> of value 4, followed by the 4-byte PE address (or other 4-byte > >>>> identifier)." > >>>> > >>> These two signaling procedures are non interoperable in > >> their way of > >>> handling the SAII, TAII. A PE (that is signaling > compliant to draft > >>> draft-ietf-l2vpn-signaling-07) talking to a PE that is only > >> signaling > >>> compliant to draft-ietf-l2vpn-vpls-ldp-08.txt will not be able to > >>> establish a pseudowire to it. > >>> > >>> If one wants to implement VPLS using ldp which draft > should she/he > >>> pick for signaling purposes? or to be more precise which > signaling > >>> procedures are the minimum required for standard purposes? > >>> > >>> Note that both are doing exactly the same thing establish > >> pseudowires > >>> between VSIs. This needs clarification. > >>> > >>>> Hamid. > >>>> > >>>> > >> > >> > > From l2vpn-bounces@ietf.org Wed Mar 22 11:57:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6ea-0000nr-O0; Wed, 22 Mar 2006 11:57:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6eZ-0000nm-Pw for l2vpn@ietf.org; Wed, 22 Mar 2006 11:57:47 -0500 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM6eY-00084p-IO for l2vpn@ietf.org; Wed, 22 Mar 2006 11:57:47 -0500 Received: from [127.0.0.1] (dog.tcb.net [64.78.150.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id 662CB64367 for ; Wed, 22 Mar 2006 09:57:39 -0700 (MST) Message-ID: <44218208.1050309@castlepoint.net> Date: Wed, 22 Mar 2006 09:57:44 -0700 From: Shane Amante User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: l2vpn@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: FINAL Agenda for L2VPN WG @ IETF 65 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org Hello, Some minor changes have been made the the L2VPN WG agenda. A final agenda for L2VPN has been published at: http://www3.ietf.org/proceedings/06mar/agenda/l2vpn.txt Alternatively, an HTML version can be found at: http://l2vpn.tcb.net/meetings/ietf65/index.html Can people who are presenting please mail me copies of their slides this evening by 6:00PM CST? Thanks, -shane & Vach From l2vpn-bounces@ietf.org Thu Mar 23 23:19:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMdlv-00069D-Ix; Thu, 23 Mar 2006 23:19:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMdlu-00065f-By for l2vpn@ietf.org; Thu, 23 Mar 2006 23:19:34 -0500 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMdls-0003GM-Oy for l2vpn@ietf.org; Thu, 23 Mar 2006 23:19:34 -0500 Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k2O4JVlK013586 for ; Thu, 23 Mar 2006 22:19:31 -0600 (CST) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 23 Mar 2006 23:19:31 -0500 Message-ID: From: "Busschbach, Peter B (Peter)" To: l2vpn@ietf.org Date: Thu, 23 Mar 2006 23:19:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: RE: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org I have a few minor comments. Otherwise, I believe the document is ready to become an RFC. I don't see a need to separate the document into a framework document and a requirements document. Some of the requirements (e.g. the security requirements) would be hard to understand without the framework. Comments: Section 1.1: delete the final "s" in: STP - Spanning Tree Protocols Section 4.2.3: "The MIP associated with (C) are expected to be implemented ..." It is IMO not very likely that a service provider will instantiate customer-related MIPs on his equipment. The sentence should be reworded to convey that MIPs "could" be implemented, or something similar. Section 5.2: in many figures, arrows are shown as <---. instead of <---> Section 7.13 prioritization: Two comments: (1) 7.13 should be replaced by 7.14; (2) Why isn't the same requirement mentioned for VPLS services? That's all. Peter > -----Original Message----- > From: Shane Amante [mailto:shane@castlepoint.net] > Sent: Sunday, March 19, 2006 6:29 PM > To: l2vpn@ietf.org > Subject: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05 > > > The authors of draft-ietf-l2vpn-oam-req-frmk-05, have > requested a L2VPN > WG Last Call for this I-D, "L2VPN OAM Requirements and > Framework". It > can be found at: > http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-oam-req-f rmk-05.txt Please thoroughly review the document and send any comments to the list. Also, please indicate whether you believe this document is ready to go to the IESG "as is", or whether there should be a cleaner separation between the requirements and framework. In the latter case, the I-D would not pass LC, would need to get re-drafted for WG comments and the separate components sent out for WG Last Call again. The WG Last Call will end on 10 Apr 2006 at 1700 MST (UTC/GMT -7). -shane From l2vpn-bounces@ietf.org Mon Mar 27 22:28:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO4sN-00046l-QR; Mon, 27 Mar 2006 22:28:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO4sL-00046c-N8 for l2vpn@ietf.org; Mon, 27 Mar 2006 22:28:09 -0500 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FO4sK-000386-FW for l2vpn@ietf.org; Mon, 27 Mar 2006 22:28:09 -0500 Received: from [172.16.15.25] (dsl081-098-224.den1.dsl.speakeasy.net [64.81.98.224]) by dog.tcb.net (Postfix) with ESMTP id CCEBE64352 for ; Mon, 27 Mar 2006 20:28:00 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v746.3) Content-Transfer-Encoding: 7bit Message-Id: <2FB7E348-ACA5-4BDA-89B1-37A13D5886AF@castlepoint.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: l2vpn@ietf.org From: Shane Amante Date: Mon, 27 Mar 2006 20:28:06 -0700 X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: Draft Minutes of L2VPN WG Meeting @ IETF 65 (Dallas, TX, USA) X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org Draft meeting minutes of the L2VPN WG Session @ IETF 65 have been posted to the IETF Web Site at the following URL: http://www3.ietf.org/proceedings/06mar/minutes/l2vpn.txt Please review and provide corrections no later than Friday, 4/14/2006, 1700 MDT, UTC -6. Some of the discussion after Ali Sajassi's presentation on "Congruency for VPLS Multicast and Unicast Paths" I-D may not be complete, so if people could review that section in particular that would be great. In addition to the meeting minutes, most of the presentations have been uploaded to the following URL: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=65 I am still missing slides from Ali & Dinesh. If you could forward me slides ASAP, that would be great! Thanks to Rohit Mediratta for taking minutes! -shane & Vach From l2vpn-bounces@ietf.org Mon Mar 27 22:57:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO5L3-0001A7-Oj; Mon, 27 Mar 2006 22:57:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO5L2-0001A1-K4 for l2vpn@ietf.org; Mon, 27 Mar 2006 22:57:48 -0500 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FO5L1-0003zC-BA for l2vpn@ietf.org; Mon, 27 Mar 2006 22:57:48 -0500 Received: from [172.16.15.25] (dsl081-098-224.den1.dsl.speakeasy.net [64.81.98.224]) by dog.tcb.net (Postfix) with ESMTP id E272964352 for ; Mon, 27 Mar 2006 20:57:39 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v746.3) Content-Transfer-Encoding: 7bit Message-Id: <5FEF6A1B-B24B-4A18-98B6-19B84D62D468@castlepoint.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: l2vpn@ietf.org From: Shane Amante Date: Mon, 27 Mar 2006 20:57:45 -0700 X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: Proposed Updated L2VPN WG Milestones X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org As discussed at the L2VPN WG meeting in Dallas, TX, below is a copy of the proposed updated L2VPN WG milestones. Please provide comments to the list if you have objections to these proposed dates no later than Friday, 4/7/2006, 1700 MDT, UTC -6. *Done Submit L2 requirements to IESG for publication as Informational RFC Done Identify VPLS and VPWS solutions for the WG Done Submit L2 framework to IESG for publication as Informational RFC *Done Submit VPLS solution documents to IESG *Done Submit VPWS solution documents to IESG *Done Submit IP-only L2VPN solution documents to IESG *May 2006 Submit an I-D describing MIB for VPLS *May 2006 Submit an I-D describing MIB for VPWS *Dec 2006 Submit MIB for VPLS to IESG *Dec 2006 Submit MIB for VPWS to IESG *June 2006 Submit an I-D on OAM for VPLS *June 2006 Submit an I-D on OAM for VPWS *Mar 2007 Submit OAM for VPWS to IESG *Mar 2007 Submit OAM for VPLS to IESG *Mar 2007 Submit OAM for IP L2VPN to IESG NOTE: the asterisk before the date is meant to reflect a change from the date recorded in the existing L2VPN WG Charter. Thanks! -shane & Vach