From l2vpn-bounces@ietf.org Mon Aug 01 03:30:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzUkV-0007vj-7h; Mon, 01 Aug 2005 03:30:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzUkS-0007tZ-7v for l2vpn@megatron.ietf.org; Mon, 01 Aug 2005 03:30:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01614 for ; Mon, 1 Aug 2005 03:30:06 -0400 (EDT) Received: from dsl081-098-224.den1.dsl.speakeasy.net ([64.81.98.224] helo=mail.castlepoint.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzVGf-0000yw-4R for l2vpn@ietf.org; Mon, 01 Aug 2005 04:03:26 -0400 Received: from [127.0.0.1] (ns1.castlepoint.net [172.16.15.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.castlepoint.net (Postfix) with ESMTP id 53723426B5 for ; Mon, 1 Aug 2005 01:29:44 -0600 (MDT) Message-ID: <42EDCF65.8090307@castlepoint.net> Date: Mon, 01 Aug 2005 09:29:41 +0200 From: Shane Amante User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en 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: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Subject: Slides for Paris l2vpn session 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Can those who making a presentation at l2vpn on Wednesday, please forward a copy of their slides to Vach & I as soon as possible, but no later than 24 hours before l2vpn meets? (In other words, no later than Tuesday, 8/2, 1030). Thanks! -shane From l2vpn-bounces@ietf.org Tue Aug 02 01:59:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzpoE-0004ji-IB; Tue, 02 Aug 2005 01:59:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzpoC-0004hN-Dw for l2vpn@megatron.ietf.org; Tue, 02 Aug 2005 01:59:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00520 for ; Tue, 2 Aug 2005 01:59:22 -0400 (EDT) Received: from dsl081-098-224.den1.dsl.speakeasy.net ([64.81.98.224] helo=mail.castlepoint.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzqKP-0004EH-GE for l2vpn@ietf.org; Tue, 02 Aug 2005 02:32:42 -0400 Received: from [127.0.0.1] (ns1.castlepoint.net [172.16.15.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.castlepoint.net (Postfix) with ESMTP id 8481342706 for ; Mon, 1 Aug 2005 23:58:54 -0600 (MDT) Message-ID: <42EF0B9C.10606@castlepoint.net> Date: Tue, 02 Aug 2005 07:58:52 +0200 From: Shane Amante User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en 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: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Subject: Slides for l2vpn Paris 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org I've only received slides from a small handful of people. (Those that did send them in already, thank you!) Just a reminder to send your slides to Vach & I this morning, by 1030! Thanks! -shane From l2vpn-bounces@ietf.org Wed Aug 03 05:28:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0FYN-0007Qf-S7; Wed, 03 Aug 2005 05:28:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0FYM-0007Pw-5C; Wed, 03 Aug 2005 05:28:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28272; Wed, 3 Aug 2005 05:28:44 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0G50-0005yu-6W; Wed, 03 Aug 2005 06:02:31 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 03 Aug 2005 02:28:38 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.95,163,1120460400"; d="scan'208"; a="4464673:sNHT19655660" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j739SaVu022374; Wed, 3 Aug 2005 05:28:36 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 3 Aug 2005 05:28:35 -0400 Received: from [86.255.24.128] ([10.82.240.36]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 3 Aug 2005 05:28:35 -0400 Message-ID: <42F08E3F.4060201@cisco.com> Date: Wed, 03 Aug 2005 11:28:31 +0200 From: Mark Townsley User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: l2vpn@ietf.org, pwe3 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Aug 2005 09:28:35.0444 (UTC) FILETIME=[B8ECA340:01C5980D] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: Margaret Wasserman Subject: IPv4 and IPv6 for draft-ietf-l2vpn-ipls-02.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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Since I suggested taking this to the list... It seems to me that for IPv4 and IPv6 are quite different (different ARP issues, etc). At a minimum, we would need a new PW Type for an IPv6 IPLS PW. I cannot speak for the entire IESG, but my view is that the current IPLS work should be documented clearly as IPv4 only. IPv6 should be defined as well, ideally as a section in the same document. However, if there is no one willing and able to do the work now it could be covered in a future document. - Mark From l2vpn-bounces@ietf.org Wed Aug 03 06:06:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0G90-0005fk-Rt; Wed, 03 Aug 2005 06:06:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0G8y-0005ff-Mo for l2vpn@megatron.ietf.org; Wed, 03 Aug 2005 06:06:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01565 for ; Wed, 3 Aug 2005 06:06:34 -0400 (EDT) Received: from tlv1.axerra.com ([80.74.100.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0Gfc-0007nb-VQ for l2vpn@ietf.org; Wed, 03 Aug 2005 06:40:22 -0400 Received: by TLV1 with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Aug 2005 13:06:40 +0300 Message-ID: From: Sasha Vainshtein To: "'yaakov_s@rad.com'" Date: Wed, 3 Aug 2005 13:06:40 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 2.0 (++) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: "'l2vpn@ietf.org'" Subject: A comment on draft-stein-ldp-auto-00.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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Yaakov and all, In addition to the comments during the L2VPN WG session today: I do not see why new LDP messages are required to achieve exactly the same functionality you want toachieve. IMO, sending a Label Mapping message with the appropriate FEC 129 to exactly the same set of adjacencies would suffice: - adjacencies that participate in the VPLS intstance defined by this FEC would respond with their own Label Mapping message back - adjacencies that do NOT participate in the VPLS instance defined by this FEC would respond with the Label Release message using the LDP Status Code "Unassigned/Unrecognized TAI" as defined in Section 5.3.3 of the current PWE3 control protocol draft (draft-ietf-pwe3-control-protocol-17.txt). Please note that the information carried in the proposed Join message does not differ from one carried in the already defined FEC 129. So why such a MAJOR (a new messsage, not just a new TLV!) extension to LDP? Regards, Sasha From l2vpn-bounces@ietf.org Wed Aug 03 06:20:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0GHn-000218-6f; Wed, 03 Aug 2005 06:15:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0GHl-000213-TK for l2vpn@megatron.ietf.org; Wed, 03 Aug 2005 06:15:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02035 for ; Wed, 3 Aug 2005 06:15:39 -0400 (EDT) Received: from radmail2.rad.co.il ([80.74.100.136] helo=antivir1.rad.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0GoP-0008DD-R6 for l2vpn@ietf.org; Wed, 03 Aug 2005 06:49:27 -0400 Received: from antivir1.rad.co.il (localhost [127.0.0.1]) by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id j73ADF3O000373 for ; Wed, 3 Aug 2005 13:13:16 +0300 (IDT) Received: from exrad2.ad.rad.co.il (exrad2 [192.114.24.112]) by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id j73ADEgd000364; Wed, 3 Aug 2005 13:13:14 +0300 (IDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Aug 2005 13:16:03 +0200 Message-ID: <27A0F290348F8E45AEF79889DDE65A5205219C1E@exrad2.ad.rad.co.il> Thread-Topic: A comment on draft-stein-ldp-auto-00.txt Thread-Index: AcWYG4DlOgCsQhkPR7qvi/KOZ11iqwAACWpA From: "Yaakov Stein" To: "Sasha Vainshtein" X-Spam-Score: 2.0 (++) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable Cc: l2vpn@ietf.org Subject: RE: A comment on draft-stein-ldp-auto-00.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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Sasha,=20 > IMO, sending a Label Mapping message with the appropriate FEC=20 > 129 to exactly the same set of adjacencies would suffice: > - adjacencies that participate in the VPLS intstance defined by this > FEC would respond with their own Label Mapping message back > - adjacencies that do NOT participate in the VPLS instance defined > by this FEC would respond with the Label Release message using > the LDP Status Code "Unassigned/Unrecognized TAI" as defined > in Section 5.3.3 of the current PWE3 control protocol draft > (draft-ietf-pwe3-control-protocol-17.txt). Yes, this is one of the alternatives we considered. Although it re-uses a TLV, it requires a procedure change, which I am not sure is better.=20 Right now when an LDP peer receives a mapping it may liberally retain it even though it has no use for it. There certainly is no procedure for conditioning acceptance on information maintained in a table. In addition, in the naive way of doing this it would require propagation of the label mapping into whole domains where I don't (access networks where there are no PEs belonging to the VPLS instance). Yes this could also be fixed by having the S-PE snoop the mapping message, but then it would have to process every LDP packet (even non-VPLS joining ones) in this fashion.=20 Finally, PEs that are not VPLS-aware will mis-handle the mapping request. In our case PEs that do not handle VPLS will silently ignore the message. >=20 > Please note that the information carried in the proposed Join=20 > message does not differ from one carried in the already=20 > defined FEC 129. Yes, this is discussed in the draft. >=20 > So why such a MAJOR (a new messsage, not just a new TLV!)=20 > extension to LDP? I do not see a major advantage in saving IANA a little bit of work in allocating two new TLVs, if we have to overload a lot of logic on existing ones. Y(J)S From l2vpn-bounces@ietf.org Wed Aug 03 06:24:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0GPs-0005IM-8g; Wed, 03 Aug 2005 06:24:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0GPq-0005IH-2a for l2vpn@megatron.ietf.org; Wed, 03 Aug 2005 06:24:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02339 for ; Wed, 3 Aug 2005 06:23:59 -0400 (EDT) Received: from tlv1.axerra.com ([80.74.100.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0GwT-00006O-FH for l2vpn@ietf.org; Wed, 03 Aug 2005 06:57:47 -0400 Received: by TLV1 with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Aug 2005 13:24:11 +0300 Message-ID: From: Sasha Vainshtein To: "'Yaakov Stein '" Date: Wed, 3 Aug 2005 13:24:11 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-8" X-Spam-Score: 2.0 (++) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: "'l2vpn@ietf.org '" Subject: RE: A comment on draft-stein-ldp-auto-00.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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Yaakoc, I do not think that you are right there. The procedure (as listed in Section 5.3.3) mandates the receiver of a FEC 129 with unknown TAI to release the label. I do not think that the LDP liberal retention mode includes ability to retain a label binding that has been explicitly released. Such behavior does not much sense to me, since the entity that has advertised the binding can now re-use a released label making the retained original binding somewhat meaningless and possibly harmful. (This does not preclude the fact that some broken LDP implementations do exactly that:-) Do I miss something here? Regards, Sasha -----Original Message----- From: Yaakov Stein To: Sasha Vainshtein Cc: l2vpn@ietf.org Sent: 8/3/2005 1:16 PM Subject: RE: A comment on draft-stein-ldp-auto-00.txt Sasha, > IMO, sending a Label Mapping message with the appropriate FEC > 129 to exactly the same set of adjacencies would suffice: > - adjacencies that participate in the VPLS intstance defined by this > FEC would respond with their own Label Mapping message back > - adjacencies that do NOT participate in the VPLS instance defined > by this FEC would respond with the Label Release message using > the LDP Status Code "Unassigned/Unrecognized TAI" as defined > in Section 5.3.3 of the current PWE3 control protocol draft > (draft-ietf-pwe3-control-protocol-17.txt). Yes, this is one of the alternatives we considered. Although it re-uses a TLV, it requires a procedure change, which I am not sure is better. Right now when an LDP peer receives a mapping it may liberally retain it even though it has no use for it. There certainly is no procedure for conditioning acceptance on information maintained in a table. In addition, in the naive way of doing this it would require propagation of the label mapping into whole domains where I don't (access networks where there are no PEs belonging to the VPLS instance). Yes this could also be fixed by having the S-PE snoop the mapping message, but then it would have to process every LDP packet (even non-VPLS joining ones) in this fashion. Finally, PEs that are not VPLS-aware will mis-handle the mapping request. In our case PEs that do not handle VPLS will silently ignore the message. > > Please note that the information carried in the proposed Join > message does not differ from one carried in the already > defined FEC 129. Yes, this is discussed in the draft. > > So why such a MAJOR (a new messsage, not just a new TLV!) > extension to LDP? I do not see a major advantage in saving IANA a little bit of work in allocating two new TLVs, if we have to overload a lot of logic on existing ones. Y(J)S From l2vpn-bounces@ietf.org Wed Aug 03 09:42:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0JVk-0007hQ-3e; Wed, 03 Aug 2005 09:42:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0JVj-0007hF-2T for l2vpn@megatron.ietf.org; Wed, 03 Aug 2005 09:42:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16498 for ; Wed, 3 Aug 2005 09:42:17 -0400 (EDT) Received: from radmail1.rad.co.il ([62.0.23.193] helo=antivir1.rad.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0K2N-0001Y3-K2 for l2vpn@ietf.org; Wed, 03 Aug 2005 10:16:06 -0400 Received: from antivir1.rad.co.il (localhost [127.0.0.1]) by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id j73Ddo3O024438 for ; Wed, 3 Aug 2005 16:39:51 +0300 (IDT) Received: from exrad2.ad.rad.co.il (exrad2 [192.114.24.112]) by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id j73Ddogd024435; Wed, 3 Aug 2005 16:39:50 +0300 (IDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Aug 2005 16:42:41 +0200 Message-ID: <27A0F290348F8E45AEF79889DDE65A5205219C96@exrad2.ad.rad.co.il> Thread-Topic: A comment on draft-stein-ldp-auto-00.txt Thread-Index: AcWYHfQvYwmQmv2RRIydYq7SbTFWXgAG3oLQ From: "Yaakov Stein" To: "Sasha Vainshtein" X-Spam-Score: 2.0 (++) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: quoted-printable Cc: l2vpn@ietf.org Subject: RE: A comment on draft-stein-ldp-auto-00.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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Sasha,=20 What exactly are you assuming as the connection between the VPLS identity and the TAIs for the various MS PWs that need to be set up for each=20 PE in the VPLS instance ? Y(J)S=20 > -----Original Message----- > From: Sasha Vainshtein [mailto:Sasha@AXERRA.com]=20 > Sent: Wednesday, August 03, 2005 12:24 > To: Yaakov Stein > Cc: 'l2vpn@ietf.org ' > Subject: RE: A comment on draft-stein-ldp-auto-00.txt >=20 > Yaakoc, > I do not think that you are right there. >=20 > The procedure (as listed in Section 5.3.3) mandates the=20 > receiver of a FEC 129 with unknown TAI to release the label. >=20 > I do not think that the LDP liberal retention mode includes=20 > ability to retain a label binding that has been explicitly=20 > released. Such behavior does not much sense to me, since the=20 > entity that has advertised the binding can now re-use a=20 > released label making the retained original binding somewhat=20 > meaningless and possibly harmful.=20 >=20 >=20 > (This does not preclude the fact that some broken LDP=20 > implementations do exactly that:-) >=20 > Do I miss something here? >=20 > Regards, > Sasha >=20 >=20 > -----Original Message----- > From: Yaakov Stein > To: Sasha Vainshtein > Cc: l2vpn@ietf.org > Sent: 8/3/2005 1:16 PM > Subject: RE: A comment on draft-stein-ldp-auto-00.txt >=20 > Sasha,=20 >=20 > > IMO, sending a Label Mapping message with the appropriate FEC > > 129 to exactly the same set of adjacencies would suffice: > > - adjacencies that participate in the VPLS intstance defined by this > > FEC would respond with their own Label Mapping message back > > - adjacencies that do NOT participate in the VPLS instance defined > > by this FEC would respond with the Label Release message using > > the LDP Status Code "Unassigned/Unrecognized TAI" as defined > > in Section 5.3.3 of the current PWE3 control protocol draft > > (draft-ietf-pwe3-control-protocol-17.txt). >=20 > Yes, this is one of the alternatives we considered. >=20 > Although it re-uses a TLV, it requires a procedure change,=20 > which I am not sure is better.=20 >=20 > Right now when an LDP peer receives a mapping it may=20 > liberally retain it even though it has no use for it. > There certainly is no procedure for conditioning acceptance=20 > on information maintained in a table. >=20 > In addition, in the naive way of doing this it would require=20 > propagation of the label mapping into whole domains where I=20 > don't (access networks where there are no PEs belonging to=20 > the VPLS instance). Yes this could also be fixed by having=20 > the S-PE snoop the mapping message, but then it would have to=20 > process every LDP packet (even non-VPLS joining ones) in this=20 > fashion.=20 >=20 > Finally, PEs that are not VPLS-aware will mis-handle the=20 > mapping request. In our case PEs that do not handle VPLS will=20 > silently ignore the message. >=20 > >=20 > > Please note that the information carried in the proposed=20 > Join message=20 > > does not differ from one carried in the already defined FEC 129. >=20 > Yes, this is discussed in the draft. >=20 > >=20 > > So why such a MAJOR (a new messsage, not just a new TLV!)=20 > extension to=20 > > LDP? >=20 > I do not see a major advantage in saving IANA a little bit of=20 > work in allocating two new TLVs, if we have to overload a=20 > lot of logic on existing ones. >=20 > Y(J)S >=20 >=20 From l2vpn-bounces@ietf.org Wed Aug 03 09:53:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Jgu-0007Vx-Tu; Wed, 03 Aug 2005 09:53:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Jgt-0007Vp-6f for l2vpn@megatron.ietf.org; Wed, 03 Aug 2005 09:53:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17512 for ; Wed, 3 Aug 2005 09:53:49 -0400 (EDT) Received: from tlv1.axerra.com ([80.74.100.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0KDX-0002CF-C0 for l2vpn@ietf.org; Wed, 03 Aug 2005 10:27:38 -0400 Received: by TLV1 with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Aug 2005 16:53:59 +0300 Message-ID: From: Sasha Vainshtein To: "'Yaakov Stein '" Date: Wed, 3 Aug 2005 16:53:58 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-8" X-Spam-Score: 2.0 (++) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: "'l2vpn@ietf.org '" Subject: RE: A comment on draft-stein-ldp-auto-00.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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Yaakov, I follow the assumptions in draft-ietf-l2vpn-vpls-ldp-07.txt, section 6.1.1 that says that AGI is the VPLS identifier, while SAII and TAII are NULL (and explains whyit is so). I am not aware of any alternative proposals. Did I miss one in your draft? Regards, Sasha -----Original Message----- From: Yaakov Stein To: Sasha Vainshtein Cc: l2vpn@ietf.org Sent: 8/3/2005 4:42 PM Subject: RE: A comment on draft-stein-ldp-auto-00.txt Sasha, What exactly are you assuming as the connection between the VPLS identity and the TAIs for the various MS PWs that need to be set up for each PE in the VPLS instance ? Y(J)S > -----Original Message----- > From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] > Sent: Wednesday, August 03, 2005 12:24 > To: Yaakov Stein > Cc: 'l2vpn@ietf.org ' > Subject: RE: A comment on draft-stein-ldp-auto-00.txt > > Yaakoc, > I do not think that you are right there. > > The procedure (as listed in Section 5.3.3) mandates the > receiver of a FEC 129 with unknown TAI to release the label. > > I do not think that the LDP liberal retention mode includes > ability to retain a label binding that has been explicitly > released. Such behavior does not much sense to me, since the > entity that has advertised the binding can now re-use a > released label making the retained original binding somewhat > meaningless and possibly harmful. > > > (This does not preclude the fact that some broken LDP > implementations do exactly that:-) > > Do I miss something here? > > Regards, > Sasha > > > -----Original Message----- > From: Yaakov Stein > To: Sasha Vainshtein > Cc: l2vpn@ietf.org > Sent: 8/3/2005 1:16 PM > Subject: RE: A comment on draft-stein-ldp-auto-00.txt > > Sasha, > > > IMO, sending a Label Mapping message with the appropriate FEC > > 129 to exactly the same set of adjacencies would suffice: > > - adjacencies that participate in the VPLS intstance defined by this > > FEC would respond with their own Label Mapping message back > > - adjacencies that do NOT participate in the VPLS instance defined > > by this FEC would respond with the Label Release message using > > the LDP Status Code "Unassigned/Unrecognized TAI" as defined > > in Section 5.3.3 of the current PWE3 control protocol draft > > (draft-ietf-pwe3-control-protocol-17.txt). > > Yes, this is one of the alternatives we considered. > > Although it re-uses a TLV, it requires a procedure change, > which I am not sure is better. > > Right now when an LDP peer receives a mapping it may > liberally retain it even though it has no use for it. > There certainly is no procedure for conditioning acceptance > on information maintained in a table. > > In addition, in the naive way of doing this it would require > propagation of the label mapping into whole domains where I > don't (access networks where there are no PEs belonging to > the VPLS instance). Yes this could also be fixed by having > the S-PE snoop the mapping message, but then it would have to > process every LDP packet (even non-VPLS joining ones) in this > fashion. > > Finally, PEs that are not VPLS-aware will mis-handle the > mapping request. In our case PEs that do not handle VPLS will > silently ignore the message. > > > > > Please note that the information carried in the proposed > Join message > > does not differ from one carried in the already defined FEC 129. > > Yes, this is discussed in the draft. > > > > > So why such a MAJOR (a new messsage, not just a new TLV!) > extension to > > LDP? > > I do not see a major advantage in saving IANA a little bit of > work in allocating two new TLVs, if we have to overload a > lot of logic on existing ones. > > Y(J)S > > From l2vpn-bounces@ietf.org Wed Aug 03 12:09:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0LoW-00080Q-Jx; Wed, 03 Aug 2005 12:09:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0LoV-000802-GD; Wed, 03 Aug 2005 12:09:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27787; Wed, 3 Aug 2005 12:09:49 -0400 (EDT) Received: from lin1-118-39-27.ciena.com ([63.118.39.27] helo=mdmxm02.ciena.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0MLB-0008IO-1D; Wed, 03 Aug 2005 12:43:40 -0400 Received: from mamxm01.ciena.com ([10.172.0.155]) by mdmxm02.ciena.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 3 Aug 2005 12:09:27 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 3 Aug 2005 12:09:26 -0400 Message-ID: Thread-Topic: [PWE3] IPv4 and IPv6 for draft-ietf-l2vpn-ipls-02.txt Thread-Index: AcWYDgEH/wf4DKRHTVyAOYij9l9nWgANz8Sw From: "Shah, Himanshu" To: "Mark Townsley" , , "pwe3" X-OriginalArrivalTime: 03 Aug 2005 16:09:27.0659 (UTC) FILETIME=[B92963B0:01C59845] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Cc: Margaret Wasserman Subject: RE: [PWE3] IPv4 and IPv6 for draft-ietf-l2vpn-ipls-02.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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Precisely. We will add a section (I think Chris Metz is going to look into providing the appropriate text) in the current draft, may be outlining the issues and noting that details will be covered in another draft or as future work item. /himanshu -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Mark Townsley Sent: Wednesday, August 03, 2005 5:29 AM To: l2vpn@ietf.org; pwe3 Cc: Margaret Wasserman Subject: [PWE3] IPv4 and IPv6 for draft-ietf-l2vpn-ipls-02.txt Since I suggested taking this to the list... It seems to me that for IPv4 and IPv6 are quite different (different ARP issues, etc). At a minimum, we would need a new PW Type for an IPv6 IPLS PW. I cannot speak for the entire IESG, but my view is that the current IPLS work should be documented clearly as IPv4 only. IPv6 should be defined=20 as well, ideally as a section in the same document. However, if there is no one willing and able to do the work now it could be covered in a=20 future document. - Mark _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From l2vpn-bounces@ietf.org Wed Aug 03 12:30:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0M8p-0003Hk-Jh; Wed, 03 Aug 2005 12:30:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0M8n-0003H3-SQ; Wed, 03 Aug 2005 12:30:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29036; Wed, 3 Aug 2005 12:30:47 -0400 (EDT) Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0MfV-0000lU-GW; Wed, 03 Aug 2005 13:04:38 -0400 Received: from default.mail.com (concorde301.adptelecom.net[212.180.41.212]) by comcast.net (sccrmhc11) with SMTP id <2005080316303801100bqcvae>; Wed, 3 Aug 2005 16:30:38 +0000 Message-Id: <6.2.1.2.2.20050803122941.0697a390@mail.comcast.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 03 Aug 2005 12:30:34 -0400 To: "Shah, Himanshu" From: "Andrew G. Malis" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 3.5 (+++) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: l2vpn@ietf.org, Mark Townsley , Margaret Wasserman , pwe3 Subject: RE: [PWE3] IPv4 and IPv6 for draft-ietf-l2vpn-ipls-02.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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org I'll repeat what I said at the microphone - if anyone feels that it's essential that IPv6 be supported in the current draft, please supply the text. Thanks, Andy ------------ At 8/3/2005 12:09 -0400, Shah, Himanshu wrote: >Precisely. We will add a section (I think Chris Metz is going to look >into providing the appropriate text) in the current draft, may be >outlining the issues and noting that details will be covered in another >draft or as future work item. > >/himanshu > >-----Original Message----- >From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of >Mark Townsley >Sent: Wednesday, August 03, 2005 5:29 AM >To: l2vpn@ietf.org; pwe3 >Cc: Margaret Wasserman >Subject: [PWE3] IPv4 and IPv6 for draft-ietf-l2vpn-ipls-02.txt > > >Since I suggested taking this to the list... > >It seems to me that for IPv4 and IPv6 are quite different (different ARP > >issues, etc). At a minimum, we would need a new PW Type for an IPv6 IPLS >PW. > >I cannot speak for the entire IESG, but my view is that the current IPLS > >work should be documented clearly as IPv4 only. IPv6 should be defined >as well, ideally as a section in the same document. However, if there is > >no one willing and able to do the work now it could be covered in a >future document. > >- Mark > > > > > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 From l2vpn-bounces@ietf.org Thu Aug 04 05:22:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0bw9-0006xT-CD; Thu, 04 Aug 2005 05:22:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0bw6-0006xG-Kg for l2vpn@megatron.ietf.org; Thu, 04 Aug 2005 05:22:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15685 for ; Thu, 4 Aug 2005 05:22:44 -0400 (EDT) Received: from tlv1.axerra.com ([80.74.100.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0cSw-0007mQ-J2 for l2vpn@ietf.org; Thu, 04 Aug 2005 05:56:44 -0400 Received: by TLV1 with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Aug 2005 12:22:51 +0300 Message-ID: From: Sasha Vainshtein To: "'Bruce Davie'" Date: Thu, 4 Aug 2005 12:22:50 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-8" X-Spam-Score: 2.0 (++) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: "'l2vpn@ietf.org '" Subject: RE: A comment on draft-stein-ldp-auto-00.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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Bruce, I have looked up the draft in question. IMHO t mentions the need for non-NULL SAII and TAII wrt Hierarchical VPLS rather than Inter-AS. Could you please be a bit more specific as to which part of the draft do you have in mind? And, regardless of that, this thread was, IMO, essentially about two points: - FEC 129 contains ALL the information that would be carried in the proposed Join/Leave messages since the AGI is ALWAYS equivalent to the VPLS identifeir. IMO your comments indicates that it could contain some additional information as well, but I do not see why this could be a problem - There is a regular, well defined procedure in the PWE3 Control Protocol draft that requires the receiver of a Label Mapping message for a FEC 129 with unknown/unrecognized TAI to release the label binding advertized for this FEC. And, to the best of my understanding, explicitly released label bindings MUST NOT be retained even in the Liberal retention mode. (I would highly appreciate comments by the LDP gurus on this specific point.) Regards, Sasha > -----Original Message----- > From: Bruce Davie [mailto:bdavie@cisco.com] > Sent: Thursday, August 04, 2005 9:25 AM > To: Sasha Vainshtein > Cc: 'l2vpn@ietf.org '; 'Yaakov Stein ' > Subject: Re: A comment on draft-stein-ldp-auto-00.txt > > > Sasha, > You may want to look at draft-ietf-l2vpn-signaling-04.txt which > explains why non-null SAII and TAII values are needed when building > inter-AS PWs between the VSIs. > > Bruce > > On Aug 3, 2005, at 9:53 AM, Sasha Vainshtein wrote: > > > Yaakov, > > I follow the assumptions in > draft-ietf-l2vpn-vpls-ldp-07.txt, section > > 6.1.1 that says that AGI is the VPLS identifier, while SAII > and TAII > > are > > NULL (and explains whyit is so). > > > > I am not aware of any alternative proposals. > > Did I miss one in your draft? > > > > Regards, > > Sasha > > -----Original Message----- > > From: Yaakov Stein > > To: Sasha Vainshtein > > Cc: l2vpn@ietf.org > > Sent: 8/3/2005 4:42 PM > > Subject: RE: A comment on draft-stein-ldp-auto-00.txt > > > > Sasha, > > > > What exactly are you assuming as the connection > > between the VPLS identity and the TAIs for the > > various MS PWs that need to be set up for each > > PE in the VPLS instance ? > > > > Y(J)S > > > >> -----Original Message----- > >> From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] > >> Sent: Wednesday, August 03, 2005 12:24 > >> To: Yaakov Stein > >> Cc: 'l2vpn@ietf.org ' > >> Subject: RE: A comment on draft-stein-ldp-auto-00.txt > >> > >> Yaakoc, > >> I do not think that you are right there. > >> > >> The procedure (as listed in Section 5.3.3) mandates the > >> receiver of a FEC 129 with unknown TAI to release the label. > >> > >> I do not think that the LDP liberal retention mode includes > >> ability to retain a label binding that has been explicitly > >> released. Such behavior does not much sense to me, since the > >> entity that has advertised the binding can now re-use a > >> released label making the retained original binding somewhat > >> meaningless and possibly harmful. > >> > >> > >> (This does not preclude the fact that some broken LDP > >> implementations do exactly that:-) > >> > >> Do I miss something here? > >> > >> Regards, > >> Sasha > >> > >> > >> -----Original Message----- > >> From: Yaakov Stein > >> To: Sasha Vainshtein > >> Cc: l2vpn@ietf.org > >> Sent: 8/3/2005 1:16 PM > >> Subject: RE: A comment on draft-stein-ldp-auto-00.txt > >> > >> Sasha, > >> > >>> IMO, sending a Label Mapping message with the appropriate FEC > >>> 129 to exactly the same set of adjacencies would suffice: > >>> - adjacencies that participate in the VPLS intstance > defined by this > >>> FEC would respond with their own Label Mapping message back > >>> - adjacencies that do NOT participate in the VPLS instance defined > >>> by this FEC would respond with the Label Release message using > >>> the LDP Status Code "Unassigned/Unrecognized TAI" as defined > >>> in Section 5.3.3 of the current PWE3 control protocol draft > >>> (draft-ietf-pwe3-control-protocol-17.txt). > >> > >> Yes, this is one of the alternatives we considered. > >> > >> Although it re-uses a TLV, it requires a procedure change, > >> which I am not sure is better. > >> > >> Right now when an LDP peer receives a mapping it may > >> liberally retain it even though it has no use for it. > >> There certainly is no procedure for conditioning acceptance > >> on information maintained in a table. > >> > >> In addition, in the naive way of doing this it would require > >> propagation of the label mapping into whole domains where I > >> don't (access networks where there are no PEs belonging to > >> the VPLS instance). Yes this could also be fixed by having > >> the S-PE snoop the mapping message, but then it would have to > >> process every LDP packet (even non-VPLS joining ones) in this > >> fashion. > >> > >> Finally, PEs that are not VPLS-aware will mis-handle the > >> mapping request. In our case PEs that do not handle VPLS will > >> silently ignore the message. > >> > >>> > >>> Please note that the information carried in the proposed > >> Join message > >>> does not differ from one carried in the already defined FEC 129. > >> > >> Yes, this is discussed in the draft. > >> > >>> > >>> So why such a MAJOR (a new messsage, not just a new TLV!) > >> extension to > >>> LDP? > >> > >> I do not see a major advantage in saving IANA a little bit of > >> work in allocating two new TLVs, if we have to overload a > >> lot of logic on existing ones. > >> > >> Y(J)S > >> > >> > From l2vpn-bounces@ietf.org Thu Aug 04 06:19:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0cjb-0008Ox-Rb; Thu, 04 Aug 2005 06:13:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0cjY-0008Nt-4M for l2vpn@megatron.ietf.org; Thu, 04 Aug 2005 06:13:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19216 for ; Thu, 4 Aug 2005 06:13:49 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0dGP-0001uo-Sz for l2vpn@ietf.org; Thu, 04 Aug 2005 06:47:50 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 04 Aug 2005 12:13:43 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j74ADPVd006183 for ; Thu, 4 Aug 2005 12:13:40 +0200 (MEST) Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 4 Aug 2005 12:12:53 +0200 Received: from [127.0.0.1] ([144.254.226.40]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 Aug 2005 12:12:53 +0200 Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5a09c2f7af553a5b108a17d0d525837d@cisco.com> Content-Transfer-Encoding: 7bit From: Bruce Davie Date: Thu, 4 Aug 2005 06:12:56 -0400 To: "'l2vpn@ietf.org '" X-Mailer: Apple Mail (2.619.2) X-OriginalArrivalTime: 04 Aug 2005 10:12:53.0035 (UTC) FILETIME=[136297B0:01C598DD] X-Spam-Score: 2.0 (++) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: 7bit Subject: Re: A comment on draft-stein-ldp-auto-00.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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Sasha, You may want to look at draft-ietf-l2vpn-signaling-04.txt which explains why non-null SAII and TAII values are needed when building inter-AS PWs between the VSIs. Bruce On Aug 3, 2005, at 9:53 AM, Sasha Vainshtein wrote: > Yaakov, > I follow the assumptions in draft-ietf-l2vpn-vpls-ldp-07.txt, section > 6.1.1 that says that AGI is the VPLS identifier, while SAII and TAII > are > NULL (and explains whyit is so). > > I am not aware of any alternative proposals. > Did I miss one in your draft? > > Regards, > Sasha > -----Original Message----- > From: Yaakov Stein > To: Sasha Vainshtein > Cc: l2vpn@ietf.org > Sent: 8/3/2005 4:42 PM > Subject: RE: A comment on draft-stein-ldp-auto-00.txt > > Sasha, > > What exactly are you assuming as the connection > between the VPLS identity and the TAIs for the > various MS PWs that need to be set up for each > PE in the VPLS instance ? > > Y(J)S > >> -----Original Message----- >> From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] >> Sent: Wednesday, August 03, 2005 12:24 >> To: Yaakov Stein >> Cc: 'l2vpn@ietf.org ' >> Subject: RE: A comment on draft-stein-ldp-auto-00.txt >> >> Yaakoc, >> I do not think that you are right there. >> >> The procedure (as listed in Section 5.3.3) mandates the >> receiver of a FEC 129 with unknown TAI to release the label. >> >> I do not think that the LDP liberal retention mode includes >> ability to retain a label binding that has been explicitly >> released. Such behavior does not much sense to me, since the >> entity that has advertised the binding can now re-use a >> released label making the retained original binding somewhat >> meaningless and possibly harmful. >> >> >> (This does not preclude the fact that some broken LDP >> implementations do exactly that:-) >> >> Do I miss something here? >> >> Regards, >> Sasha >> >> >> -----Original Message----- >> From: Yaakov Stein >> To: Sasha Vainshtein >> Cc: l2vpn@ietf.org >> Sent: 8/3/2005 1:16 PM >> Subject: RE: A comment on draft-stein-ldp-auto-00.txt >> >> Sasha, >> >>> IMO, sending a Label Mapping message with the appropriate FEC >>> 129 to exactly the same set of adjacencies would suffice: >>> - adjacencies that participate in the VPLS intstance defined by this >>> FEC would respond with their own Label Mapping message back >>> - adjacencies that do NOT participate in the VPLS instance defined >>> by this FEC would respond with the Label Release message using >>> the LDP Status Code "Unassigned/Unrecognized TAI" as defined >>> in Section 5.3.3 of the current PWE3 control protocol draft >>> (draft-ietf-pwe3-control-protocol-17.txt). >> >> Yes, this is one of the alternatives we considered. >> >> Although it re-uses a TLV, it requires a procedure change, >> which I am not sure is better. >> >> Right now when an LDP peer receives a mapping it may >> liberally retain it even though it has no use for it. >> There certainly is no procedure for conditioning acceptance >> on information maintained in a table. >> >> In addition, in the naive way of doing this it would require >> propagation of the label mapping into whole domains where I >> don't (access networks where there are no PEs belonging to >> the VPLS instance). Yes this could also be fixed by having >> the S-PE snoop the mapping message, but then it would have to >> process every LDP packet (even non-VPLS joining ones) in this >> fashion. >> >> Finally, PEs that are not VPLS-aware will mis-handle the >> mapping request. In our case PEs that do not handle VPLS will >> silently ignore the message. >> >>> >>> Please note that the information carried in the proposed >> Join message >>> does not differ from one carried in the already defined FEC 129. >> >> Yes, this is discussed in the draft. >> >>> >>> So why such a MAJOR (a new messsage, not just a new TLV!) >> extension to >>> LDP? >> >> I do not see a major advantage in saving IANA a little bit of >> work in allocating two new TLVs, if we have to overload a >> lot of logic on existing ones. >> >> Y(J)S >> >> From l2vpn-bounces@ietf.org Thu Aug 04 06:19:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0cij-0008Cp-H8; Thu, 04 Aug 2005 06:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0cih-0008Cf-LQ for l2vpn@megatron.ietf.org; Thu, 04 Aug 2005 06:12:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19146 for ; Thu, 4 Aug 2005 06:12:57 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0dFZ-0001se-7r for l2vpn@ietf.org; Thu, 04 Aug 2005 06:46:57 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 04 Aug 2005 12:12:50 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j74ACcVX006014 for ; Thu, 4 Aug 2005 12:12:47 +0200 (MEST) Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 4 Aug 2005 12:12:32 +0200 Received: from [127.0.0.1] ([144.254.226.40]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 Aug 2005 12:12:31 +0200 Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <453c717e30b5573bd4e851541f5be505@cisco.com> Content-Transfer-Encoding: 7bit From: Bruce Davie Date: Thu, 4 Aug 2005 06:12:35 -0400 To: "'l2vpn@ietf.org '" X-Mailer: Apple Mail (2.619.2) X-OriginalArrivalTime: 04 Aug 2005 10:12:32.0004 (UTC) FILETIME=[06D98440:01C598DD] X-Spam-Score: 2.0 (++) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Content-Transfer-Encoding: 7bit Subject: Re: A comment on draft-stein-ldp-auto-00.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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org On Aug 4, 2005, at 5:22 AM, Sasha Vainshtein wrote: > Bruce, > I have looked up the draft in question. > IMHO t mentions the need for non-NULL SAII and TAII wrt Hierarchical > VPLS > rather > than Inter-AS. Could you please be a bit more specific as to which > part of > the draft > do you have in mind? Quoting draft-ietf-l2vpn-signaling-04.txt 3.2.3 Signaling It is necessary to create Attachment Identifiers which identify the VSIs. In the preceding section, a VSI-ID was encoded as RD:PE_addr for the purposes of autodiscovery. For signaling purposes, the same information is carried but is encoded slightly differently. Noting that the RD is effectively a VPN identifier, we therefore encode the RD in the AGI field, and place the PE_addr in the TAII field. The SAII can be null. The motivation for this is to enable the inter-AS (not dist. VPLS) procedures that are described in Section 4.2 to work correctly. If you didn't include some sort of PE identifier in the TAII, you would not be able to figure out what to do at an SPE (ASBRs in this case) But as your comments below correctly point out, this isn't all that relevant to the original thread. I just wanted to address your question about why non-null AIIs might be needed, and to point out that the base VPLS-LDP draft isn't the last word on that subject. It certainly would be good if any attempt to define new autodiscovery methods (e.g. using LDP) drew on the overall approach to autodiscovery and signalling that has been developed over several years and documented in draft-ietf-l2vpn-signaling-xx.txt. Bruce > > And, regardless of that, this thread was, IMO, essentially about two > points: > > - FEC 129 contains ALL the information that would be carried in the > proposed Join/Leave > messages since the AGI is ALWAYS equivalent to the VPLS identifeir. > IMO > your comments > indicates that it could contain some additional information as well, > but I > do not see > why this could be a problem > > - There is a regular, well defined procedure in the PWE3 Control > Protocol > draft that > requires the receiver of a Label Mapping message for a FEC 129 with > unknown/unrecognized > TAI to release the label binding advertized for this FEC. And, to > the best > of my > understanding, explicitly released label bindings MUST NOT be > retained > even in the > Liberal retention mode. (I would highly appreciate comments by the > LDP > gurus on this > specific point.) > > Regards, > Sasha > > >> -----Original Message----- >> From: Bruce Davie [mailto:bdavie@cisco.com] >> Sent: Thursday, August 04, 2005 9:25 AM >> To: Sasha Vainshtein >> Cc: 'l2vpn@ietf.org '; 'Yaakov Stein ' >> Subject: Re: A comment on draft-stein-ldp-auto-00.txt >> >> >> Sasha, >> You may want to look at draft-ietf-l2vpn-signaling-04.txt which >> explains why non-null SAII and TAII values are needed when building >> inter-AS PWs between the VSIs. >> >> Bruce >> >> On Aug 3, 2005, at 9:53 AM, Sasha Vainshtein wrote: >> >>> Yaakov, >>> I follow the assumptions in >> draft-ietf-l2vpn-vpls-ldp-07.txt, section >>> 6.1.1 that says that AGI is the VPLS identifier, while SAII >> and TAII >>> are >>> NULL (and explains whyit is so). >>> >>> I am not aware of any alternative proposals. >>> Did I miss one in your draft? >>> >>> Regards, >>> Sasha >>> -----Original Message----- >>> From: Yaakov Stein >>> To: Sasha Vainshtein >>> Cc: l2vpn@ietf.org >>> Sent: 8/3/2005 4:42 PM >>> Subject: RE: A comment on draft-stein-ldp-auto-00.txt >>> >>> Sasha, >>> >>> What exactly are you assuming as the connection >>> between the VPLS identity and the TAIs for the >>> various MS PWs that need to be set up for each >>> PE in the VPLS instance ? >>> >>> Y(J)S >>> >>>> -----Original Message----- >>>> From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] >>>> Sent: Wednesday, August 03, 2005 12:24 >>>> To: Yaakov Stein >>>> Cc: 'l2vpn@ietf.org ' >>>> Subject: RE: A comment on draft-stein-ldp-auto-00.txt >>>> >>>> Yaakoc, >>>> I do not think that you are right there. >>>> >>>> The procedure (as listed in Section 5.3.3) mandates the >>>> receiver of a FEC 129 with unknown TAI to release the label. >>>> >>>> I do not think that the LDP liberal retention mode includes >>>> ability to retain a label binding that has been explicitly >>>> released. Such behavior does not much sense to me, since the >>>> entity that has advertised the binding can now re-use a >>>> released label making the retained original binding somewhat >>>> meaningless and possibly harmful. >>>> >>>> >>>> (This does not preclude the fact that some broken LDP >>>> implementations do exactly that:-) >>>> >>>> Do I miss something here? >>>> >>>> Regards, >>>> Sasha >>>> >>>> >>>> -----Original Message----- >>>> From: Yaakov Stein >>>> To: Sasha Vainshtein >>>> Cc: l2vpn@ietf.org >>>> Sent: 8/3/2005 1:16 PM >>>> Subject: RE: A comment on draft-stein-ldp-auto-00.txt >>>> >>>> Sasha, >>>> >>>>> IMO, sending a Label Mapping message with the appropriate FEC >>>>> 129 to exactly the same set of adjacencies would suffice: >>>>> - adjacencies that participate in the VPLS intstance >> defined by this >>>>> FEC would respond with their own Label Mapping message back >>>>> - adjacencies that do NOT participate in the VPLS instance defined >>>>> by this FEC would respond with the Label Release message using >>>>> the LDP Status Code "Unassigned/Unrecognized TAI" as defined >>>>> in Section 5.3.3 of the current PWE3 control protocol draft >>>>> (draft-ietf-pwe3-control-protocol-17.txt). >>>> >>>> Yes, this is one of the alternatives we considered. >>>> >>>> Although it re-uses a TLV, it requires a procedure change, >>>> which I am not sure is better. >>>> >>>> Right now when an LDP peer receives a mapping it may >>>> liberally retain it even though it has no use for it. >>>> There certainly is no procedure for conditioning acceptance >>>> on information maintained in a table. >>>> >>>> In addition, in the naive way of doing this it would require >>>> propagation of the label mapping into whole domains where I >>>> don't (access networks where there are no PEs belonging to >>>> the VPLS instance). Yes this could also be fixed by having >>>> the S-PE snoop the mapping message, but then it would have to >>>> process every LDP packet (even non-VPLS joining ones) in this >>>> fashion. >>>> >>>> Finally, PEs that are not VPLS-aware will mis-handle the >>>> mapping request. In our case PEs that do not handle VPLS will >>>> silently ignore the message. >>>> >>>>> >>>>> Please note that the information carried in the proposed >>>> Join message >>>>> does not differ from one carried in the already defined FEC 129. >>>> >>>> Yes, this is discussed in the draft. >>>> >>>>> >>>>> So why such a MAJOR (a new messsage, not just a new TLV!) >>>> extension to >>>>> LDP? >>>> >>>> I do not see a major advantage in saving IANA a little bit of >>>> work in allocating two new TLVs, if we have to overload a >>>> lot of logic on existing ones. >>>> >>>> Y(J)S >>>> >>>> >> From l2vpn-bounces@ietf.org Thu Aug 04 06:26:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0cw7-00060T-AW; Thu, 04 Aug 2005 06:26:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0cw5-0005zR-Dt for l2vpn@megatron.ietf.org; Thu, 04 Aug 2005 06:26:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22147 for ; Thu, 4 Aug 2005 06:26:46 -0400 (EDT) Received: from tlv1.axerra.com ([80.74.100.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0dSu-0002v3-Jf for l2vpn@ietf.org; Thu, 04 Aug 2005 07:00:47 -0400 Received: by TLV1 with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Aug 2005 13:26:52 +0300 Message-ID: From: Sasha Vainshtein To: "'Bruce Davie'" Date: Thu, 4 Aug 2005 13:26:51 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-8" X-Spam-Score: 2.0 (++) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a Cc: "'l2vpn@ietf.org '" Subject: RE: A comment on draft-stein-ldp-auto-00.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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Bruce, Lots of thanks for a prompt response. Please see a brief comment inline below. Regards, Sasha > -----Original Message----- > From: Bruce Davie [mailto:bdavie@cisco.com] > Sent: Thursday, August 04, 2005 11:08 AM > To: Sasha Vainshtein > Cc: 'l2vpn@ietf.org '; 'Yaakov Stein ' > Subject: Re: A comment on draft-stein-ldp-auto-00.txt > > > > On Aug 4, 2005, at 5:22 AM, Sasha Vainshtein wrote: > > > Bruce, > > I have looked up the draft in question. > > IMHO t mentions the need for non-NULL SAII and TAII wrt > Hierarchical > > VPLS > > rather > > than Inter-AS. Could you please be a bit more specific as to which > > part of > > the draft > > do you have in mind? > > Quoting draft-ietf-l2vpn-signaling-04.txt > > 3.2.3 Signaling > > It is necessary to create Attachment Identifiers which > identify the > VSIs. In the preceding section, a VSI-ID was encoded as > RD:PE_addr > for the purposes of autodiscovery. For signaling > purposes, the same > information is carried but is encoded slightly > differently. Noting > that the RD is effectively a VPN identifier, we therefore > encode the > RD in the AGI field, and place the PE_addr in the TAII field. The > SAII can be null. > > The motivation for this is to enable the inter-AS (not dist. VPLS) > procedures that are described in Section 4.2 to work > correctly. If you > didn't include some sort of PE identifier in the TAII, you > would not be > able to figure out what to do at an SPE (ASBRs in this case) > > But as your comments below correctly point out, this isn't all that > relevant to the original thread. I just wanted to address > your question > about why non-null AIIs might be needed, and to point out > that the base > VPLS-LDP draft isn't the last word on that subject. > > It certainly would be good if any attempt to define new autodiscovery > methods (e.g. using LDP) drew on the overall approach to > autodiscovery > and signalling that has been developed over several years and > documented in draft-ietf-l2vpn-signaling-xx.txt. > [Sasha] I agree wholeheartedly. > > Bruce > > > > > > > And, regardless of that, this thread was, IMO, essentially > about two > > points: > > > > - FEC 129 contains ALL the information that would be carried in the > > proposed Join/Leave > > messages since the AGI is ALWAYS equivalent to the VPLS > identifeir. > > IMO > > your comments > > indicates that it could contain some additional > information as well, > > but I > > do not see > > why this could be a problem > > > > - There is a regular, well defined procedure in the PWE3 Control > > Protocol > > draft that > > requires the receiver of a Label Mapping message for a > FEC 129 with > > unknown/unrecognized > > TAI to release the label binding advertized for this FEC. And, to > > the best > > of my > > understanding, explicitly released label bindings MUST NOT be > > retained > > even in the > > Liberal retention mode. (I would highly appreciate > comments by the > > LDP > > gurus on this > > specific point.) > > > > Regards, > > Sasha > > > > > >> -----Original Message----- > >> From: Bruce Davie [mailto:bdavie@cisco.com] > >> Sent: Thursday, August 04, 2005 9:25 AM > >> To: Sasha Vainshtein > >> Cc: 'l2vpn@ietf.org '; 'Yaakov Stein ' > >> Subject: Re: A comment on draft-stein-ldp-auto-00.txt > >> > >> > >> Sasha, > >> You may want to look at draft-ietf-l2vpn-signaling-04.txt which > >> explains why non-null SAII and TAII values are needed when building > >> inter-AS PWs between the VSIs. > >> > >> Bruce > >> > >> On Aug 3, 2005, at 9:53 AM, Sasha Vainshtein wrote: > >> > >>> Yaakov, > >>> I follow the assumptions in > >> draft-ietf-l2vpn-vpls-ldp-07.txt, section > >>> 6.1.1 that says that AGI is the VPLS identifier, while SAII > >> and TAII > >>> are > >>> NULL (and explains whyit is so). > >>> > >>> I am not aware of any alternative proposals. > >>> Did I miss one in your draft? > >>> > >>> Regards, > >>> Sasha > >>> -----Original Message----- > >>> From: Yaakov Stein > >>> To: Sasha Vainshtein > >>> Cc: l2vpn@ietf.org > >>> Sent: 8/3/2005 4:42 PM > >>> Subject: RE: A comment on draft-stein-ldp-auto-00.txt > >>> > >>> Sasha, > >>> > >>> What exactly are you assuming as the connection > >>> between the VPLS identity and the TAIs for the > >>> various MS PWs that need to be set up for each > >>> PE in the VPLS instance ? > >>> > >>> Y(J)S > >>> > >>>> -----Original Message----- > >>>> From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] > >>>> Sent: Wednesday, August 03, 2005 12:24 > >>>> To: Yaakov Stein > >>>> Cc: 'l2vpn@ietf.org ' > >>>> Subject: RE: A comment on draft-stein-ldp-auto-00.txt > >>>> > >>>> Yaakoc, > >>>> I do not think that you are right there. > >>>> > >>>> The procedure (as listed in Section 5.3.3) mandates the > >>>> receiver of a FEC 129 with unknown TAI to release the label. > >>>> > >>>> I do not think that the LDP liberal retention mode includes > >>>> ability to retain a label binding that has been explicitly > >>>> released. Such behavior does not much sense to me, since the > >>>> entity that has advertised the binding can now re-use a > >>>> released label making the retained original binding somewhat > >>>> meaningless and possibly harmful. > >>>> > >>>> > >>>> (This does not preclude the fact that some broken LDP > >>>> implementations do exactly that:-) > >>>> > >>>> Do I miss something here? > >>>> > >>>> Regards, > >>>> Sasha > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: Yaakov Stein > >>>> To: Sasha Vainshtein > >>>> Cc: l2vpn@ietf.org > >>>> Sent: 8/3/2005 1:16 PM > >>>> Subject: RE: A comment on draft-stein-ldp-auto-00.txt > >>>> > >>>> Sasha, > >>>> > >>>>> IMO, sending a Label Mapping message with the appropriate FEC > >>>>> 129 to exactly the same set of adjacencies would suffice: > >>>>> - adjacencies that participate in the VPLS intstance > >> defined by this > >>>>> FEC would respond with their own Label Mapping message back > >>>>> - adjacencies that do NOT participate in the VPLS > instance defined > >>>>> by this FEC would respond with the Label Release message using > >>>>> the LDP Status Code "Unassigned/Unrecognized TAI" as defined > >>>>> in Section 5.3.3 of the current PWE3 control protocol draft > >>>>> (draft-ietf-pwe3-control-protocol-17.txt). > >>>> > >>>> Yes, this is one of the alternatives we considered. > >>>> > >>>> Although it re-uses a TLV, it requires a procedure change, > >>>> which I am not sure is better. > >>>> > >>>> Right now when an LDP peer receives a mapping it may > >>>> liberally retain it even though it has no use for it. > >>>> There certainly is no procedure for conditioning acceptance > >>>> on information maintained in a table. > >>>> > >>>> In addition, in the naive way of doing this it would require > >>>> propagation of the label mapping into whole domains where I > >>>> don't (access networks where there are no PEs belonging to > >>>> the VPLS instance). Yes this could also be fixed by having > >>>> the S-PE snoop the mapping message, but then it would have to > >>>> process every LDP packet (even non-VPLS joining ones) in this > >>>> fashion. > >>>> > >>>> Finally, PEs that are not VPLS-aware will mis-handle the > >>>> mapping request. In our case PEs that do not handle VPLS will > >>>> silently ignore the message. > >>>> > >>>>> > >>>>> Please note that the information carried in the proposed > >>>> Join message > >>>>> does not differ from one carried in the already defined FEC 129. > >>>> > >>>> Yes, this is discussed in the draft. > >>>> > >>>>> > >>>>> So why such a MAJOR (a new messsage, not just a new TLV!) > >>>> extension to > >>>>> LDP? > >>>> > >>>> I do not see a major advantage in saving IANA a little bit of > >>>> work in allocating two new TLVs, if we have to overload a > >>>> lot of logic on existing ones. > >>>> > >>>> Y(J)S > >>>> > >>>> > >> > From l2vpn-bounces@ietf.org Thu Aug 04 17:49:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0nac-00038A-R9; Thu, 04 Aug 2005 17:49:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0naa-000382-SH for l2vpn@megatron.ietf.org; Thu, 04 Aug 2005 17:49:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11074 for ; Thu, 4 Aug 2005 17:49:18 -0400 (EDT) Received: from web32415.mail.mud.yahoo.com ([68.142.207.208]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E0o7W-0000QS-GV for l2vpn@ietf.org; Thu, 04 Aug 2005 18:23:25 -0400 Received: (qmail 57707 invoked by uid 60001); 4 Aug 2005 21:49:04 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=DyJqy5Bgwn17GsCCusXQOoQITANJfl+YiXxOO26uqMD0pC1FlIZDAXRi1QwrHrX31voU4FFIgptf12wQjX//YNN8q8en2/ajKITeDk7pxIVBdgZDEsgJdileYQIKcWhScjIYzpn168TjA7inp9v7Ienzr/lOAl9IF7bfyjpZ784= ; Message-ID: <20050804214904.57705.qmail@web32415.mail.mud.yahoo.com> Received: from [204.154.128.112] by web32415.mail.mud.yahoo.com via HTTP; Thu, 04 Aug 2005 14:49:04 PDT Date: Thu, 4 Aug 2005 14:49:04 -0700 (PDT) From: narasimhan g To: l2vpn@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 2.7 (++) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 8bit Subject: customer BPDU ethernet encapsulation over rfc1483(2684) ATM PVCs. 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Hi, I have a question regarding customer BPDU encapsulation over ATM PVCs. The VPLS draft draft-ietf-l2vpn-vpls-ldp-07.txt seems to suggest that the all frames that traverse a VPLS will have ethernet encasulation ( see below for quotes from the draft). Does it mean that customer BPDUs received over an rfc1483/2684 ATM PVC will/must also have an ethernet encasulation? RFC1483 encapsulation of BPDUs suggests otherwise. Can someone please clarify. Attached below is relevant text from sections 7.1 and 4.4. thanks, narasim 7.1. VPLS Encapsulation actions By following the above rules, the Ethernet frame that traverses a <============== VPLS is always a customer Ethernet frame. Note that the two actions, at ingress and egress, of dealing with service delimiters are local actions that neither PE has to signal to the other. They allow, for example, a mix-and-match of VLAN tagged and untagged services at either end, and do not carry across a VPLS a VLAN tag that has local significance only. The service delimiter may be an MPLS label also, whereby an Ethernet PW given by [PWE3-ETHERNET] can serve as the access side connection into a PE. An RFC1483 Bridged PVC encapsulation could also serve as a service delimiter. By limiting the scope of locally significant encapsulations to the edge, hierarchical VPLS models can be developed that provide the capability to network-engineer scalable VPLS deployments, as described below. 4.4. Loop free VPLS If the topology of the VPLS is not restricted to a full mesh, then it may be that for two PEs not directly connected via PWs, they would have to use an intermediary PE to relay packets. This topology would require the use of some loop-breaking protocol, like a spanning tree protocol. Instead, a full mesh of PWs is established between PEs. Since every PE is now directly connected to every other PE in the VPLS via a PW, there is no longer any need to relay packets, and we can instantiate a simpler loop-breaking rule - the "split horizon" rule: a PE MUST NOT forward traffic from one PW to another in the same VPLS mesh. Note that customers are allowed to run the Spanning Tree Protocol (STP) such as when a customer has "back door" links used to provide redundancy in the case of a failure within the VPLS. In such a <============== case, STP Bridge PDUs (BPDUs) are simply tunneled through the provider cloud. ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs From l2vpn-bounces@ietf.org Sun Aug 07 14:45:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1q9f-000750-12; Sun, 07 Aug 2005 14:45:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1q9d-00074v-HP for l2vpn@megatron.ietf.org; Sun, 07 Aug 2005 14:45:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19916 for ; Sun, 7 Aug 2005 14:45:48 -0400 (EDT) Received: from dsl081-098-224.den1.dsl.speakeasy.net ([64.81.98.224] helo=mail.castlepoint.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E1qh7-0006uR-GP for l2vpn@ietf.org; Sun, 07 Aug 2005 15:20:29 -0400 Received: from [127.0.0.1] (ns1.castlepoint.net [172.16.15.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.castlepoint.net (Postfix) with ESMTP id C5462426CD for ; Sun, 7 Aug 2005 12:45:24 -0600 (MDT) Message-ID: <42F656C2.7020707@castlepoint.net> Date: Sun, 07 Aug 2005 20:45:22 +0200 From: Shane Amante User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en 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: 4f585e1bcd209294c6b9386034cecfc6 Content-Transfer-Encoding: 7bit Subject: Draft Minutes of L2VPN WG Meeting @ IETF 63 (Paris) 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Below are the draft L2VPN WG meeting minutes from Paris. Thanks to Andrew Dolganow, Jaime Miles and Cary Wright for serving as scribes. Please forward any updates or corrections to the list. -shane (& Vach) IETF 63: Layer 2 Virtual Private Network WG (l2vpn) Meeting Minutes ----------------------------------------------------------------------- Wednesday, August 3, 1030-1230 ============================== Chairs: Vach Kompella Shane Amante ----------------------------------------------------------------------- 1) Agenda Update ----------------------------------------------------------------------- Two presentations cancelled: + Florin Balus' presentation cancelled, because discussion on MS-PW occurred the day before in PWE3. + Greg Weber's presentation on "Using RADIUS for PE-Based VPN Discovery" (draft-ietf-l2vpn-radius-pe-discovery-01.txt) cancelled, due to WG scheduling conflict. ----------------------------------------------------------------------- 2) WG Document Status (Vach) ----------------------------------------------------------------------- - Documents Status + draft-ietf-l2vpn-arp-mediation-02 (ARP Mediation): There are a few comments that are being addressed. MPLS WG being asked to review code points and changes to LDP. + draft-ietf-ipls-02 (IPLS): There are a lot of edits so working group last call is being delayed. Vach asked for more review from the working group. + draft-ietf-l2vpn-signalling-04 (L2VPN Signaling): Close to WG last call, however some issues raised in PWE3 may require some changes to the draft so WG will wait to see what happens in PWE3. - Charter Status + Good progress, or almost done with most items in charter. + OAM and MIBs are significant bodies of work that still need work. + Volunteers for work on MIB are requested. - ITU Liason Statement + 36 from ITU-T SG13 Y.ethoam needs to be reviewed. + Action is to read, evaluate and respond; asked for volunteers to see Vach or Shane afterwards to review and respond. - Loa Anderson commented that VPLS BGP has progressed into the IANA for the code point allocation, and that they are ready to assign the code point. ----------------------------------------------------------------------- 3) Update: IP-Only LAN Service (IPLS) draft-ietf-l2vpn-ipls-02.txt Himanshu Shah ----------------------------------------------------------------------- - IPLS changes: + multicast mp2p PW type changes from IPLayer2Transport to Ethernet + All ARP and multicast frames are sent over multicast PW with Ethernet headers + A copy of ARP and link local multicast packets are sent to control plane for local CE discovery + addressed other comments from the list - IPLS simplified as a result - IPLS pending changes reviewed + Proposed IANA type and status code points to use. + Code points not yet in the draft + Will send email to MPLS WG to review code points. - Asked for a final call on IPLS draft - Show of hands indicated not too many people read a draft, Vach made a call for people to read a draft and have a discussion on the mailing list. Questions raised at the microphone: - Bernard Tuy: asked about support of IPv6 in this draft. - Himanshu: This was not supported in this version of the draft. - Bernard: Why is this not supported now? It is strange to have this work being done without IPv6 supported now. - Himanshu: v6 is planned, but wanted to get IPv4 out first. - Vach: Asked Mark Townsley if we can wait on IPv6 or if we have to address it right away? - Mark: We should take it to the list. - Himanshu: emphasized again that the goal is to get IPv4 done right away, IPv6 later. - Janusz: Should not go for a protocol without IPv6 consideration, at least a section on v6 is required. - Andy Malice: asked for IPv6 supporters to offer text. - George Swallow: commented that lacking IPv6 in the document may cause the work to be rejected. - Mark: agreed that people who want IPv6 need to provide the text. ----------------------------------------------------------------------- 4) Update: ARP Mediation for IP Interworking of Layer 2 VPN draft-ietf-l2vpn-arp-mediation-02.txt Himanshu Shah ----------------------------------------------------------------------- - Final call on -01 version, good support on the list. - Major comments on: PPP AC procedures, some ID nits, IP TLV etc. Presented response to those comments. - Proposed needed IANA code points, (0x096B type, 0x00000029 status) - Conclusion: + send email to MPLS WG for code points assignment review + propose to submit draft for IESG review + can do another final call for changes Vach: Let's do another final call, comments restricted to what's in the draft (specifically changes from last final call). 2 week last call will start right after this IETF. No Questions/Discussion raised at the microphone. ----------------------------------------------------------------------- 5) Provisioning Models and Endpoint Identifiers in L2VPN Signaling draft-ietf-l2vpn-signaling-04.txt Bruce Davie ----------------------------------------------------------------------- - Presented changes from last version: + Fixed distributed VPLS case + Addressed comments on the list (editorial, clarifications, bug fixes) + Clarified use of PE address in VSI identifier + Added IANA considerations section - All comments since Minneapolis were addressed, propose last call for this draft. Questions/Discussion raised at the microphone: - Mustapha Aissaoui: It will be hard to maintain this one central document and maybe it should only be informational. We have separate documents for applications, is this to become guidance RFC? - Bruce: Would like this to not just be informational but standards track, because it shows how to do interoperability between BGP and LDP. - Hamid: If intent of the draft is to be more like a solution draft with discovery, then the title should be corrected. - Bruce: Would be happy to change title. - Hamid: Is this consistent with existing documentation? - Bruce: This document is consistent with other work. Context of a signalling message (VPLS spec) does not have enough info for BGP auto-discovery, this document flushes out the details. - Vach: Do we need distributed case described here? - Bruce: ??? - Ted Seely: There is a lot of work going on to go across ASes, but there is little work being done to address how service providers honor SLAs across these services. There is nothing on the edge to actually say that it is working. Ted says that maybe the IETF should start to think how to address this. - Bruce: Not sure which working group is best to address this question. Suggested maybe we need a new Ops specific working group area? - Bruce: Are we ready to do last call on this document? - Vach took a poll of the room of who is ready for last call. Many hands went up. Room seemed to support the idea to make final changes (related to IANA code points) and then go to last call. - Mark: Do we need IANA code points to be allocated before the final call? - (Someone): No ----------------------------------------------------------------------- 6) LDP-based Autodiscovery for L2 Services draft-stein-ldp-auto-00.txt Yaakov Stein ----------------------------------------------------------------------- - Presentation talked about Access Network Architecture and important characteristics of that network that need to be taken into account. - Scale, simplicity of devices, combined devices (multiservice nodes), simple tree, limited BW, limited computational power, 1000s of nodes, no BGP may not be IGP, LDP for access LSP setup. - Manual configuration to join such a network would be difficult. - Basic assumptions in the draft: network element and links are relatively static, hence network discovery not a burden, services are dynamic, manual provisioning is difficult, want auto-discovery. When BGP available in core network it could be used, when LDP is only thing available then it should be used for auto-discovery. - New LDP message: JOIN Message, like label request, but only sent to nodes that are part of the VPLS instance. Vset members nodes after receiving the message start PW setup procedures to connect the new node. Questions/Discussion raised at the microphone: - Ali Sajassi: main point appears to be avoiding BGP in DSLAM's. BruceD's presentation shows how to do this without BGP, so this works. It's already taken care of by current framework. - YaakovS: Not negating other things may work, this draft proposes a simple way of doing that. - Ali: Specific autodiscovery case, very narrow, already taken care by current framework, (general enough). - YaakovS: Thinks it doesn't scale. - Kireeti: Like to see the work. Questions scalability, if the access network is simple, building LDP mesh would be challenging, how about reflectors? - YaakovS: Referenced how others have said that LDP is not that chatty. - Kireeti: we may still need something like route reflectors. - YaakovS: had not worked on this, but interested to look into idea like LDP reflectors. - Kireeti: went on to ask about using BGP if it only carries one NLRI, for auto-discovery, and how complicated that really is? - YaakovS: had not seen studies that really help resolve whether BGP or LDP is the best. - Kireeti: If all you implement is "light" BGP, the BGP requirements may be small, BGP would be fine in this case. - Vach: "Managing DSLAMS are configuration nightmare", not a feedback he has heard. - YaakovS: Depends on DSL architecture. - Vach: Still disagrees. Re: "Hierarchical model hides CEs" statement, that model not being as scalable as the one shown, is a wrong assumption. Thinks that people know how to do redundancy on RADIUS servers so a central server approach is not an issue. - YaakovS: RADIUS is one idea, but not the only one asked for. - Sasha: Who is talking to who over targeted LDP? - YaakovS: There are sessions within an access network and then between S-PEs. - Yakov Rekhter: thinks BGP processor overhead is not an issue and that the majority of boxes can run BGP. - Yaakov Stein: he would like to see a study to compare BGP to LDP. - Pedro: Algorithmically BGP is not as complex as stated. ----------------------------------------------------------------------- 7) Requirements for Multicast Support in Virtual Private LAN Services draft-kamite-l2vpn-vpls-mcast-reqts-00.txt Yuji Kamite ----------------------------------------------------------------------- - Scalability issues for multicast, need requirement documentation as a basis, the draft clarifies issues, describes requirements, guides multicast VPLS solution design. - Illustrates multicast challenges in VPLS. Issue A: Replication to non-member sites; Issue B: Replication of PWs on shared physical paths. - Presented summary of the requirements in the draft from multiple angles (General, Customer, Service Provider). - Major open questions: requirement levels, which PE-CE protocols are consulted, etc. - Next steps: enhance document with more feedback, propose as a WG document. Questions/Discussion raised at the microphone: - Rahul: Thinks this is useful work and should move forward. Also, thinks the document needs to require both solutions A and B. - Yuji: Does not want to limit scope and thinks, ideally, both solutions A and B should be addressed. - Bernard Tuy: Need to ensure IPv6 support and multicast auto-discovery and reporting of membership. - Yuji: Haven't given this any consideration yet. Feedback requested from a mailing list - Shane: polled room to see who had read the draft? A significant # of hands raised. Asked room: should this become a WG draft? Fair # of hands raised. Will take same question to list re: becoming WG draft. ----------------------------------------------------------------------- 8) Supporting IP Multicast over VPLS draft-serbest-l2vpn-vpls-mcast-03.txt Venu Hemige ----------------------------------------------------------------------- - Solving issue A from previous presentation, (multicast traffic flooded to all sites, with or without receivers). - Draft addresses building of replication state in PEs for IGMP and PIM only, PEs on cust-facing port must perform IGMP/PIM snooping, PE on PW port may learn multicast state using either IGMP/PIM snooping (no additional work, good up to medium scale deployments but does not scale above well, hence LDP). Why LDP? Already used to setup PW, reliable, will scale well. - Overview of LDP mechanism and special considerations as per draft were presented. - Next steps: + Comments please + Talk about combining with other draft (Rahul's) Questions/Discussion raised at the microphone: - Ali: Can you alleviate with PIM refresh-reduction. Have you been in touch with the work done there? - Rahul: PIM WG is in very early stages, but we have a solution now so we should use it. - George: This draft needs review by MPLS WG - Janusz: Recommend to split doc into 2 parts: IGMP/PIM in one, LDP in another - Venu: That discussion currently in progress ----------------------------------------------------------------------- 9) Multicast in VPLS - draft-raggarwa-l2vpn-vpls-mcast-01.txt Propagation of VPLS IP Multicast Group Membership Information - draft-raggarwa-l2vpn-vpls-mcast-ctrl-00.txt Rahul Aggarwal + NOTE: Rahul made one presentation, which covered both drafts. ----------------------------------------------------------------------- - Showed multiple VPLS multicast proposals, restated again the VPLS multicast limitations focus on optimizing state and not BW. - Optimizing BW and state are conflicting goals. - Tools to do that: + VPLS Auto-Discovery (use existing Auto-Discovery methods) + Allow elimination of flooding (PE-CE IGMP/PIM snooping, PE-PE reliable exchange of multicast control messages can be done with either BGP or LDP). - Presented overview of proposed solution in the drafts, overview of functional blocks for VPLS multicast, showed how various drafts address those functional blocks. - Conclusion: lots of interest, let's align drafts to follow functional decomposition, move drafts that fit (functional decomposition) already into WG docs, move others after restructuring to WG drafts. Questions/Discussion raised at the microphone: - Ali: Breaking down drafts to follow functional decomposition is a good idea. If I have bridges, and I send multicast, how does Ethernet OAM get treated? - Rahul: Haven't thought of that. - Shane (CH): Take it to the list. - Ali: Mechanism for shared tree, PE routers need to keep state need clarifications. - Rahul: There are procedures/clarifications missing in the current specs. - Ali: How close will we come to LAN Emulation? We need to be clear in the documents what the trade offs are for each document. - Rahul: Happy to include clarification, please provide specific text. - Ben Agrovitz: Glad to see we acknowledge tradoffs of the architecture. Challenge is finding the middle ground for tree sharing procedures. - Rahul: There is already a mechism in the draft. If anything is missing, happy to add it. - Shane: who has read the drafts? Good response. - Shane: should these both be WG drafts? Some responses. Will take same questions to the list. ----------------------------------------------------------------------- 10) L2VPN OAM Requirements and Framework draft-ietf-l2vpn-oam-req-frmk-03.txt Dinesh Mohan ----------------------------------------------------------------------- - Presented update on the draft, (overview of framework and requirements) - Status: + OAM framework adopted for other related work + New draft submitted - Section 7 added - IPLS OAM is FFS - input welcomed - VPWS OAM references draft-delord-pwe3-oam-application-01.txt, (goal is to avoid duplication). - Next steps: + Add VPWS OAM Reqs + Continue refining requirements on PW OAM + Other editorial updates. + Still work in progress, no intention for last call at this time. No Questions/Discussion raised at the microphone. ----------------------------------------------------------------------- 11) OAM Procedures for VPWS Interworking draft-aissaoui-l2vpn-vpws-iw-oam-03.txt Mustapha Aissaoui ----------------------------------------------------------------------- - No slides, Mustapha gave verbal update. - Planning revision by the end of August. - BFD for reverse concatenated path - Editorial changes - Had a good show of hands on this as a WG doc, but no response on the list. No Questions/Discussion raised at the microphone. ----------------------------------------------------------------------- 12) VPLS Interoperability with CE Bridges draft-sajassi-l2vpn-vpls-bridge-interop-01.txt Ali Sajassi ----------------------------------------------------------------------- - Updates from last draft + First presented in IETF61 + Comments/discussions on a mailing list + Almost all discussions on clarification - Main objectives: + Identity interop issues between VPLS and 802.1D bridges. - Presented recap of interop issues: + CE Bridge Protocol handling + Customer network topology changes + PE redundancy + MAC address scaling + Partial-mesh PWs + Muticast + Interop with 802.1ad Provider Bridges - Next steps: + What's the consensus on the draft? + What areas need further clarification? Questions/Discussion raised at the microphone: - Vach: Some issues seem not to be bridge interop issues, (MAC address scalability). Should take them out of here. Some may be too hard to handle: perfect LAN emulation. Need more refinement what's required & what's nice-to-have, (like protocol handling). - Ali: Regarding perfect LAN emulation, some things will just not work. - Vach: For problems already solved by some other organizations, we don't need to solve them here. Would be nice to know those problems already solved. - Ali: This is not the intent, important to point out the functionality required at the PE for interoperability. Will update the draft to address these comments. - Himanshu: Draft brings up good points. How will the draft address each of these issues? - Ali: Agreed. Need to point to solutions that exist, come up with solutions for things that are missing. - Himanshu: Would you like to address these issues with solutions in this draft? - Ali: Would like to address some, more extensive things may need a separate draft. - Dinesh: Suggests we consider an applicability statement to address these issues. Meeting Adjourned @ 1230 From l2vpn-bounces@ietf.org Mon Aug 08 10:40:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E28o8-0007oO-N9; Mon, 08 Aug 2005 10:40:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E28o7-0007mz-1V for l2vpn@megatron.ietf.org; Mon, 08 Aug 2005 10:40:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25515 for ; Mon, 8 Aug 2005 10:40:48 -0400 (EDT) Received: from lin1-118-39-26.ciena.com ([63.118.39.26] helo=mdmxm01.ciena.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E29Lo-0001Z3-Kf for l2vpn@ietf.org; Mon, 08 Aug 2005 11:15:41 -0400 Received: from mamxm01.ciena.com ([10.172.0.155]) by mdmxm01.ciena.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 8 Aug 2005 10:40:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 8 Aug 2005 10:40:27 -0400 Message-ID: Thread-Topic: ARP-mediation IP TLV IANA code information Thread-Index: AcWcJwCk9Gu2ROorTBSle9sQ1yVOiA== From: "Shah, Himanshu" To: X-OriginalArrivalTime: 08 Aug 2005 14:40:29.0051 (UTC) FILETIME=[1F2B34B0:01C59C27] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable Subject: ARP-mediation IP TLV IANA code information 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org In the last week IETF meeting, I proposed using 0x096B type for IP TLV that is dispatched in Label Mapping message and LDP Notification in optional parameter=20 field when establishing IP PW. Subsequent to the meeting, Loa Anderson and Vach recommended using Address List TLV defined in LDP for this purpose. There is no change in proposed IANA assignment for=20 Status Code - 0x00000029. Following is the proposal for IP TLV: Reusing of Address List TLV for ARP Mediation: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= The Address List TLV is defined in RFC 3036. It is typically used in Address and Address Withdraw messages. The ARP Mediation draft would use the same TLV when signaling IP PW. The TLV is included in optional parameter field of the Label Mapping Message and contains the IP address of the local CE. When the IP address of the local CE is not known, the address value is set to zero. The ARP Mediation draft also uses the same TLV in LDP's Notification message to update the changes in CE's IP address. Its encoding is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Address List (0x0101) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Family | CE's IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CE's IP Address | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length When Address Family is IPV4, Length is equal to 6 bytes; 2 bytes for address family and 4 bytes of IP address. Address Family Two octet quantity containing a value from ADDRESS FAMILY NUMBERS in [RFC1700] that encodes the addresses contained in the Addresses field. CE's IP Address IP address of CE from Address Family specified. The encoding of the individual addresse depends on the Address Family. The following address encodings are defined by this version of the protocol: Address Family Address Encoding IPv4 4 octet full IPv4 address IPv6 16 octet full IPv6 address Please review and comment. /himanshu From l2vpn-bounces@ietf.org Mon Aug 08 11:02:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E299S-000698-70; Mon, 08 Aug 2005 11:02:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E299Q-00068y-AI for l2vpn@megatron.ietf.org; Mon, 08 Aug 2005 11:02:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26907 for ; Mon, 8 Aug 2005 11:02:50 -0400 (EDT) Received: from lin1-118-39-26.ciena.com ([63.118.39.26] helo=mdmxm01.ciena.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E29h8-0002GH-Q5 for l2vpn@ietf.org; Mon, 08 Aug 2005 11:37:43 -0400 Received: from mamxm01.ciena.com ([10.172.0.155]) by mdmxm01.ciena.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 8 Aug 2005 11:02:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59C2A.3E3BCD2C" Date: Mon, 8 Aug 2005 11:02:49 -0400 Message-ID: Thread-Topic: IPLS - IP and MAC TLV IANA code information Thread-Index: AcWcKjg7Gh8/a97sTzyak1eX+thDFQ== From: "Shah, Himanshu" To: X-OriginalArrivalTime: 08 Aug 2005 15:02:50.0666 (UTC) FILETIME=[3ED568A0:01C59C2A] X-Spam-Score: 0.1 (/) X-Scan-Signature: 407b2b2f241d630837da70082e911e77 Subject: IPLS - IP and MAC TLV IANA code information 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C59C2A.3E3BCD2C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In the last week IETF meeting, I proposed using 0x096C type for IP+MAC TLV that is dispatched in Label Mapping message and LDP Notification in optional parameter=20 field when establishing IP PW. This TLV contained IP and MAC address of the local CE. =20 Subsequent to the meeting, Loa Anderson and Vach recommended using Address List TLV defined in LDP for this purpose. There is no change in proposed IANA assignment for=20 Status Code - 0x0000002A. =20 Following is the proposal for IP and MAC TLV as address list tlvs: =20 Reusing of Address List TLV for IPLS: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =20 The Address List TLV is defined in RFC 3036. It is typically used in Address and Address Withdraw messages. The IPLS draft would use the same TLV when signaling IP PW. The two TLVs are included in optional parameter field of the Label Mapping Message; one containing IP address of the local CE and other containing MAC address of the local CE. The IPLS draft also uses the same TLVs in LDP's Notification message to=20 signal the update in these values. =20 Encoding of the IP Address TLV is: =20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Address List (0x0101) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Family | CE's IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CE's IP Address | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 Length When Address Family is IPV4, Length is equal to 6 bytes; 2 bytes for address family and 4 bytes of IP address. =20 Address Family Two octet quantity containing a value from ADDRESS FAMILY NUMBERS in [RFC1700] that encodes the addresses contained in the Addresses field. =20 CE's IP Address IP address of CE from Address Family specified. The encoding of the individual addresse depends on the Address Family. =20 The following address encodings are defined by this version of the protocol: =20 Address Family Address Encoding =20 IPv4 (1) 4 octet full IPv4 address IPv6 (2) 16 octet full IPv6 address =20 Encoding of the MAC Address TLV is: =20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Address List (0x0101) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Family | CE's MAC address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 Length The length field is set to value 8 (2 for address family, 6 for=20 MAC address) =20 Address Family Two octet quantity containing a value from ADDRESS FAMILY NUMBERS in [RFC1700] that encodes the addresses contained in the Addresses field. =20 CE's IP Address IP address of CE from Address Family specified. The encoding of the individual addresse depends on the Address Family. =20 The following address encodings are defined by this version of the protocol: =20 Address Family Address Encoding =20 MAC (6) 6 octet full Ethernet MAC address =20 Please review and comment. =20 /himanshu =20 =20 =20 ------_=_NextPart_001_01C59C2A.3E3BCD2C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In the last week IETF meeting, I proposed using 0x096C type for IP+MAC TLV = that is dispatched in Label Mapping message and LDP Notification in optional = parameter

field when establishing IP PW. This TLV contained IP and MAC address of the = local

CE.

 

Subsequent to the meeting, Loa Anderson and Vach = recommended using Address List TLV defined in LDP for this purpose. There is no = change in proposed IANA assignment for

Status Code - = 0x0000002A.

 

Following is the proposal for IP and MAC TLV as address list tlvs:

 

Reusing of Address List TLV for IPLS:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

 

   The Address List TLV is = defined in RFC 3036. It is typically used

   in Address and Address Withdraw messages. The IPLS = draft

   would use the same TLV when signaling IP PW. The two TLVs are included in

   optional parameter field of the  = Label Mapping Message; one containing

   IP = address of the local CE and other containing MAC address of the local = CE.

   The IPLS draft also uses = the same TLVs in LDP's = Notification message to

   signal the update in these values.

 

   Encoding of the IP = Address TLV is:

 

    0       &nbs= p;           1       &nbs= p;           2       &nbs= p;           3

    0 1 2 3 4 5 6 7 8 9 = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= o:p>

   |0|0| Address List = (0x0101)     |      = Length       &nbs= p;           |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= o:p>

   |     Address = Family       &nbs= p;    |     = CE's IP Address       &nbs= p;   |

   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= o:p>

   |       = CE's IP Address       &nbs= p; |       &nbs= p;            = ;           |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= o:p>

 

   = Length

      When = Address Family is IPV4, Length is equal to 6 bytes;

      2 bytes = for address family and 4 bytes of IP address.

 

   Address = Family

      Two = octet quantity containing a value from ADDRESS FAMILY = NUMBERS

      in [RFC1700] that encodes the addresses contained = in the Addresses

      field.

 

   CE's IP = Address

      IP = address of CE from Address Family specified.  = The

      encoding of the individual addresse depends on the Address Family.

 

      The = following address encodings are defined by this version of = the

      protocol:

 

       &nbs= p; Address Family      Address = Encoding

 

       &nbs= p; IPv4 (1)       &nbs= p;     4 octet full IPv4 address

       &nbs= p; IPv6 (2)       &nbs= p;     16 octet full IPv6 address

 

Encoding of the MAC Address TLV is:

 

    0       &nbs= p;           1         &nbs= p;         2       &nbs= p;           3

    0 1 2 3 4 5 6 7 8 9 = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= o:p>

   |0|0| Address List = (0x0101)     |      = Length       &nbs= p;           |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= o:p>

   |     Address = Family       &nbs= p;    |     = CE's MAC address       &nbs= p;  |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       &nbs= p;            = ;           +

   |       &nbs= p;            = ;            =                     &nbs= p;          |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= o:p>

 

   = Length

      The = length field is set to value 8 (2 for address family, 6 for =

      MAC = address)

 

   Address = Family

      Two = octet quantity containing a value from ADDRESS FAMILY = NUMBERS

      in [RFC1700] that encodes the addresses contained = in the Addresses

      field.

 

   CE's IP = Address

      IP = address of CE from Address Family specified.  = The

      encoding of the individual addresse depends on the Address Family.

 

      The = following address encodings are defined by this version of = the

      protocol:

 

       &nbs= p; Address Family      Address = Encoding

 

       &nbs= p; MAC (6)       &nbs= p;     6 octet full Ethernet MAC address

 

Please review and comment.

 

/himanshu

 

 

 

=00 ------_=_NextPart_001_01C59C2A.3E3BCD2C-- From l2vpn-bounces@ietf.org Mon Aug 08 14:14:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2C5J-0006cK-Rh; Mon, 08 Aug 2005 14:10:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2C5G-0006a2-Gx for l2vpn@megatron.ietf.org; Mon, 08 Aug 2005 14:10:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07005 for ; Mon, 8 Aug 2005 14:10:45 -0400 (EDT) Received: from lin1-118-39-27.ciena.com ([63.118.39.27] helo=mdmxm02.ciena.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2Cd0-0007b9-KN for l2vpn@ietf.org; Mon, 08 Aug 2005 14:45:39 -0400 Received: from mamxm01.ciena.com ([10.172.0.155]) by mdmxm02.ciena.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 8 Aug 2005 14:10:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59C44.754D52D0" Date: Mon, 8 Aug 2005 14:10:28 -0400 Message-ID: Thread-Topic: IPLS - IP and MAC TLV IANA code information Thread-Index: AcWcKjg7Gh8/a97sTzyak1eX+thDFQAGfZsw From: "Shah, Himanshu" To: X-OriginalArrivalTime: 08 Aug 2005 18:10:30.0693 (UTC) FILETIME=[76552D50:01C59C44] X-Spam-Score: 0.2 (/) X-Scan-Signature: 86df8ce7a29490312557c74a439f90f8 Subject: RE: IPLS - IP and MAC TLV IANA code information 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C59C44.754D52D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have made a cut-and-paste error near the last paragraph. Please read CE's MAC address instead of CE's IP address in=20 MAC address TLV description below. -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org]On Behalf Of = Shah, Himanshu Sent: Monday, August 08, 2005 11:03 AM To: l2vpn@ietf.org Subject: IPLS - IP and MAC TLV IANA code information In the last week IETF meeting, I proposed using 0x096C type for IP+MAC = TLV that is dispatched in Label Mapping message and LDP Notification in = optional parameter=20 field when establishing IP PW. This TLV contained IP and MAC address of = the local CE. =20 Subsequent to the meeting, Loa Anderson and Vach recommended using = Address List TLV defined in LDP for this purpose. There is no change in = proposed IANA assignment for=20 Status Code - 0x0000002A. =20 Following is the proposal for IP and MAC TLV as address list tlvs: =20 Reusing of Address List TLV for IPLS: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =20 The Address List TLV is defined in RFC 3036. It is typically used in Address and Address Withdraw messages. The IPLS draft would use the same TLV when signaling IP PW. The two TLVs are = included in optional parameter field of the Label Mapping Message; one = containing IP address of the local CE and other containing MAC address of the = local CE. The IPLS draft also uses the same TLVs in LDP's Notification message = to=20 signal the update in these values. =20 Encoding of the IP Address TLV is: =20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Address List (0x0101) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Family | CE's IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CE's IP Address | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 Length When Address Family is IPV4, Length is equal to 6 bytes; 2 bytes for address family and 4 bytes of IP address. =20 Address Family Two octet quantity containing a value from ADDRESS FAMILY NUMBERS in [RFC1700] that encodes the addresses contained in the Addresses field. =20 CE's IP Address IP address of CE from Address Family specified. The encoding of the individual addresse depends on the Address Family. =20 The following address encodings are defined by this version of the protocol: =20 Address Family Address Encoding =20 IPv4 (1) 4 octet full IPv4 address IPv6 (2) 16 octet full IPv6 address =20 Encoding of the MAC Address TLV is: =20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Address List (0x0101) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Family | CE's MAC address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 Length The length field is set to value 8 (2 for address family, 6 for=20 MAC address) =20 Address Family Two octet quantity containing a value from ADDRESS FAMILY NUMBERS in [RFC1700] that encodes the addresses contained in the Addresses field. =20 CE's IP Address IP address of CE from Address Family specified. The encoding of the individual addresse depends on the Address Family. =20 The following address encodings are defined by this version of the protocol: =20 Address Family Address Encoding =20 MAC (6) 6 octet full Ethernet MAC address =20 Please review and comment. =20 /himanshu =20 =20 =20 ------_=_NextPart_001_01C59C44.754D52D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I have made a cut-and-paste error near = the last=20 paragraph.
Please read CE's MAC address instead of CE's = IP address=20 in
MAC address TLV description = below.
-----Original Message-----
From: = l2vpn-bounces@ietf.org=20 [mailto:l2vpn-bounces@ietf.org]On Behalf Of Shah,=20 Himanshu
Sent: Monday, August 08, 2005 11:03 = AM
To:=20 l2vpn@ietf.org
Subject: IPLS - IP and MAC TLV IANA code=20 information

In the last week = IETF=20 meeting, I proposed using 0x096C type for IP+MAC TLV that is = dispatched in=20 Label Mapping message and LDP Notification in optional parameter=20

field when = establishing IP PW.=20 This TLV contained IP and MAC address of the=20 local

CE.

 

Subsequent to = the meeting,=20 Loa Anderson and Vach recommended using = Address List=20 TLV defined in LDP for this purpose. There is no change in proposed = IANA=20 assignment for

Status Code -=20 0x0000002A.

 

Following is the = proposal=20 for IP and MAC TLV as address list tlvs:

 

Reusing of = Address List=20 TLV for IPLS:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

 

   The Address List TLV = is defined=20 in RFC 3036. It is typically used

   in=20 Address and Address Withdraw messages. The IPLS=20 draft

   would=20 use the same TLV when signaling IP PW. The two TLVs=20 are included in

   optional parameter field of the  Label Mapping Message; one=20 containing

   IP = address of=20 the local CE and other containing MAC address of the local=20 CE.

   The IPLS draft also = uses the=20 same TLVs in LDP's=20 Notification message to

   signal=20 the update in these values.

 

   Encoding of the IP = Address TLV=20 is:

 

    0           &n= bsp;      =20 1           &n= bsp;      =20 2           &n= bsp;      =20 3

    0 1 2 3 4 5 6 7 = 8 9 0 1 2=20 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= o:p>

   |0|0| Address List = (0x0101)     |      = Length           &n= bsp;      =20 |

  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= o:p>

   |     Address = Family           =20 |     = CE's=20 IP Address          =20 |

  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= o:p>

   |       = CE's IP=20 Address        =20 |           &n= bsp;           &nb= sp;      =20 |

  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= o:p>

 

  =20 Length

      When = Address=20 Family is IPV4, Length is equal to 6 = bytes;

      2 = bytes for=20 address family and 4 bytes of IP address.

 

   Address=20 Family

      Two = octet=20 quantity containing a value from ADDRESS FAMILY=20 NUMBERS

      = in [RFC1700] that encodes the addresses contained = in the=20 Addresses

      = field.

 

   CE's IP=20 Address

      IP = address of=20 CE from Address Family specified. =20 The

      = encoding of the individual addresse depends on the Address=20 Family.

 

      The = following=20 address encodings are defined by this version of=20 the

      = protocol:

 

        =20 Address Family      = Address=20 Encoding

 

        =20 IPv4 (1)           &n= bsp;=20 4 octet full IPv4 address

        =20 IPv6 (2)           &n= bsp;=20 16 octet full IPv6 address

 

Encoding of the = MAC=20 Address TLV is:

 

    0           &n= bsp;      =20 1             &n= bsp;     2           &n= bsp;      =20 3

    0 1 2 3 4 5 6 7 = 8 9 0 1 2=20 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= o:p>

   |0|0| Address List = (0x0101)     |      = Length           &n= bsp;      =20 |

  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= o:p>

   |     Address = Family           =20 |     = CE's=20 MAC address         =20 |

  =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+           &n= bsp;           &nb= sp;      =20 +

   |           &n= bsp;           &nb= sp;           &nbs= p;        =20            &n= bsp;      |=

  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= o:p>

 

  =20 Length

      The = length=20 field is set to value 8 (2 for address family, 6 for=20

      MAC=20 address)

 

   Address=20 Family

      Two = octet=20 quantity containing a value from ADDRESS FAMILY=20 NUMBERS

      = in [RFC1700] that encodes the addresses contained = in the=20 Addresses

      = field.

 

   CE's IP=20 Address

      IP = address of=20 CE from Address Family specified. =20 The

      = encoding of the individual addresse depends on the Address=20 Family.

 

      The = following=20 address encodings are defined by this version of=20 the

      = protocol:

 

        =20 Address Family      = Address=20 Encoding

 

        =20 MAC (6)           &n= bsp;=20 6 octet full Ethernet MAC address

 

Please review = and=20 comment.

 

/himanshu

 

 

 

------_=_NextPart_001_01C59C44.754D52D0-- From l2vpn-bounces@ietf.org Mon Aug 08 15:07:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Cxm-0006xH-SF; Mon, 08 Aug 2005 15:07:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0b2l-0001M2-0g for l2vpn@megatron.ietf.org; Thu, 04 Aug 2005 04:25:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11787 for ; Thu, 4 Aug 2005 04:25:33 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0bZa-0004rx-Tw for l2vpn@ietf.org; Thu, 04 Aug 2005 04:59:32 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 04 Aug 2005 10:25:25 +0200 Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j748OkVp005572; Thu, 4 Aug 2005 10:25:17 +0200 (MEST) Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 Aug 2005 10:25:07 +0200 Received: from [127.0.0.1] ([144.254.226.40]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 4 Aug 2005 10:25:07 +0200 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Bruce Davie Date: Thu, 4 Aug 2005 04:25:10 -0400 To: Sasha Vainshtein X-Mailer: Apple Mail (2.619.2) X-OriginalArrivalTime: 04 Aug 2005 08:25:07.0670 (UTC) FILETIME=[05BA2F60:01C598CE] X-Spam-Score: 2.0 (++) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 08 Aug 2005 15:07:05 -0400 Cc: "'l2vpn@ietf.org '" Subject: Re: A comment on draft-stein-ldp-auto-00.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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Sasha, You may want to look at draft-ietf-l2vpn-signaling-04.txt which explains why non-null SAII and TAII values are needed when building inter-AS PWs between the VSIs. Bruce On Aug 3, 2005, at 9:53 AM, Sasha Vainshtein wrote: > Yaakov, > I follow the assumptions in draft-ietf-l2vpn-vpls-ldp-07.txt, section > 6.1.1 that says that AGI is the VPLS identifier, while SAII and TAII > are > NULL (and explains whyit is so). > > I am not aware of any alternative proposals. > Did I miss one in your draft? > > Regards, > Sasha > -----Original Message----- > From: Yaakov Stein > To: Sasha Vainshtein > Cc: l2vpn@ietf.org > Sent: 8/3/2005 4:42 PM > Subject: RE: A comment on draft-stein-ldp-auto-00.txt > > Sasha, > > What exactly are you assuming as the connection > between the VPLS identity and the TAIs for the > various MS PWs that need to be set up for each > PE in the VPLS instance ? > > Y(J)S > >> -----Original Message----- >> From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] >> Sent: Wednesday, August 03, 2005 12:24 >> To: Yaakov Stein >> Cc: 'l2vpn@ietf.org ' >> Subject: RE: A comment on draft-stein-ldp-auto-00.txt >> >> Yaakoc, >> I do not think that you are right there. >> >> The procedure (as listed in Section 5.3.3) mandates the >> receiver of a FEC 129 with unknown TAI to release the label. >> >> I do not think that the LDP liberal retention mode includes >> ability to retain a label binding that has been explicitly >> released. Such behavior does not much sense to me, since the >> entity that has advertised the binding can now re-use a >> released label making the retained original binding somewhat >> meaningless and possibly harmful. >> >> >> (This does not preclude the fact that some broken LDP >> implementations do exactly that:-) >> >> Do I miss something here? >> >> Regards, >> Sasha >> >> >> -----Original Message----- >> From: Yaakov Stein >> To: Sasha Vainshtein >> Cc: l2vpn@ietf.org >> Sent: 8/3/2005 1:16 PM >> Subject: RE: A comment on draft-stein-ldp-auto-00.txt >> >> Sasha, >> >>> IMO, sending a Label Mapping message with the appropriate FEC >>> 129 to exactly the same set of adjacencies would suffice: >>> - adjacencies that participate in the VPLS intstance defined by this >>> FEC would respond with their own Label Mapping message back >>> - adjacencies that do NOT participate in the VPLS instance defined >>> by this FEC would respond with the Label Release message using >>> the LDP Status Code "Unassigned/Unrecognized TAI" as defined >>> in Section 5.3.3 of the current PWE3 control protocol draft >>> (draft-ietf-pwe3-control-protocol-17.txt). >> >> Yes, this is one of the alternatives we considered. >> >> Although it re-uses a TLV, it requires a procedure change, >> which I am not sure is better. >> >> Right now when an LDP peer receives a mapping it may >> liberally retain it even though it has no use for it. >> There certainly is no procedure for conditioning acceptance >> on information maintained in a table. >> >> In addition, in the naive way of doing this it would require >> propagation of the label mapping into whole domains where I >> don't (access networks where there are no PEs belonging to >> the VPLS instance). Yes this could also be fixed by having >> the S-PE snoop the mapping message, but then it would have to >> process every LDP packet (even non-VPLS joining ones) in this >> fashion. >> >> Finally, PEs that are not VPLS-aware will mis-handle the >> mapping request. In our case PEs that do not handle VPLS will >> silently ignore the message. >> >>> >>> Please note that the information carried in the proposed >> Join message >>> does not differ from one carried in the already defined FEC 129. >> >> Yes, this is discussed in the draft. >> >>> >>> So why such a MAJOR (a new messsage, not just a new TLV!) >> extension to >>> LDP? >> >> I do not see a major advantage in saving IANA a little bit of >> work in allocating two new TLVs, if we have to overload a >> lot of logic on existing ones. >> >> Y(J)S >> >> From l2vpn-bounces@ietf.org Mon Aug 08 15:07:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Cxn-0006yu-D1; Mon, 08 Aug 2005 15:07:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0cdj-0007ac-Ji for l2vpn@megatron.ietf.org; Thu, 04 Aug 2005 06:07:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18904 for ; Thu, 4 Aug 2005 06:07:49 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0dAb-0001dl-5H for l2vpn@ietf.org; Thu, 04 Aug 2005 06:41:49 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 04 Aug 2005 12:07:42 +0200 Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j74A7DVn004538; Thu, 4 Aug 2005 12:07:38 +0200 (MEST) Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 Aug 2005 12:07:33 +0200 Received: from [127.0.0.1] ([144.254.226.40]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 Aug 2005 12:07:32 +0200 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6fffa2faec426ea3e1732e0ceeeca870@cisco.com> Content-Transfer-Encoding: 7bit From: Bruce Davie Date: Thu, 4 Aug 2005 06:07:36 -0400 To: Sasha Vainshtein X-Mailer: Apple Mail (2.619.2) X-OriginalArrivalTime: 04 Aug 2005 10:07:32.0836 (UTC) FILETIME=[54881A40:01C598DC] X-Spam-Score: 2.0 (++) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 08 Aug 2005 15:07:05 -0400 Cc: "'l2vpn@ietf.org '" Subject: Re: A comment on draft-stein-ldp-auto-00.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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org On Aug 4, 2005, at 5:22 AM, Sasha Vainshtein wrote: > Bruce, > I have looked up the draft in question. > IMHO t mentions the need for non-NULL SAII and TAII wrt Hierarchical > VPLS > rather > than Inter-AS. Could you please be a bit more specific as to which > part of > the draft > do you have in mind? Quoting draft-ietf-l2vpn-signaling-04.txt 3.2.3 Signaling It is necessary to create Attachment Identifiers which identify the VSIs. In the preceding section, a VSI-ID was encoded as RD:PE_addr for the purposes of autodiscovery. For signaling purposes, the same information is carried but is encoded slightly differently. Noting that the RD is effectively a VPN identifier, we therefore encode the RD in the AGI field, and place the PE_addr in the TAII field. The SAII can be null. The motivation for this is to enable the inter-AS (not dist. VPLS) procedures that are described in Section 4.2 to work correctly. If you didn't include some sort of PE identifier in the TAII, you would not be able to figure out what to do at an SPE (ASBRs in this case) But as your comments below correctly point out, this isn't all that relevant to the original thread. I just wanted to address your question about why non-null AIIs might be needed, and to point out that the base VPLS-LDP draft isn't the last word on that subject. It certainly would be good if any attempt to define new autodiscovery methods (e.g. using LDP) drew on the overall approach to autodiscovery and signalling that has been developed over several years and documented in draft-ietf-l2vpn-signaling-xx.txt. Bruce > > And, regardless of that, this thread was, IMO, essentially about two > points: > > - FEC 129 contains ALL the information that would be carried in the > proposed Join/Leave > messages since the AGI is ALWAYS equivalent to the VPLS identifeir. > IMO > your comments > indicates that it could contain some additional information as well, > but I > do not see > why this could be a problem > > - There is a regular, well defined procedure in the PWE3 Control > Protocol > draft that > requires the receiver of a Label Mapping message for a FEC 129 with > unknown/unrecognized > TAI to release the label binding advertized for this FEC. And, to > the best > of my > understanding, explicitly released label bindings MUST NOT be > retained > even in the > Liberal retention mode. (I would highly appreciate comments by the > LDP > gurus on this > specific point.) > > Regards, > Sasha > > >> -----Original Message----- >> From: Bruce Davie [mailto:bdavie@cisco.com] >> Sent: Thursday, August 04, 2005 9:25 AM >> To: Sasha Vainshtein >> Cc: 'l2vpn@ietf.org '; 'Yaakov Stein ' >> Subject: Re: A comment on draft-stein-ldp-auto-00.txt >> >> >> Sasha, >> You may want to look at draft-ietf-l2vpn-signaling-04.txt which >> explains why non-null SAII and TAII values are needed when building >> inter-AS PWs between the VSIs. >> >> Bruce >> >> On Aug 3, 2005, at 9:53 AM, Sasha Vainshtein wrote: >> >>> Yaakov, >>> I follow the assumptions in >> draft-ietf-l2vpn-vpls-ldp-07.txt, section >>> 6.1.1 that says that AGI is the VPLS identifier, while SAII >> and TAII >>> are >>> NULL (and explains whyit is so). >>> >>> I am not aware of any alternative proposals. >>> Did I miss one in your draft? >>> >>> Regards, >>> Sasha >>> -----Original Message----- >>> From: Yaakov Stein >>> To: Sasha Vainshtein >>> Cc: l2vpn@ietf.org >>> Sent: 8/3/2005 4:42 PM >>> Subject: RE: A comment on draft-stein-ldp-auto-00.txt >>> >>> Sasha, >>> >>> What exactly are you assuming as the connection >>> between the VPLS identity and the TAIs for the >>> various MS PWs that need to be set up for each >>> PE in the VPLS instance ? >>> >>> Y(J)S >>> >>>> -----Original Message----- >>>> From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] >>>> Sent: Wednesday, August 03, 2005 12:24 >>>> To: Yaakov Stein >>>> Cc: 'l2vpn@ietf.org ' >>>> Subject: RE: A comment on draft-stein-ldp-auto-00.txt >>>> >>>> Yaakoc, >>>> I do not think that you are right there. >>>> >>>> The procedure (as listed in Section 5.3.3) mandates the >>>> receiver of a FEC 129 with unknown TAI to release the label. >>>> >>>> I do not think that the LDP liberal retention mode includes >>>> ability to retain a label binding that has been explicitly >>>> released. Such behavior does not much sense to me, since the >>>> entity that has advertised the binding can now re-use a >>>> released label making the retained original binding somewhat >>>> meaningless and possibly harmful. >>>> >>>> >>>> (This does not preclude the fact that some broken LDP >>>> implementations do exactly that:-) >>>> >>>> Do I miss something here? >>>> >>>> Regards, >>>> Sasha >>>> >>>> >>>> -----Original Message----- >>>> From: Yaakov Stein >>>> To: Sasha Vainshtein >>>> Cc: l2vpn@ietf.org >>>> Sent: 8/3/2005 1:16 PM >>>> Subject: RE: A comment on draft-stein-ldp-auto-00.txt >>>> >>>> Sasha, >>>> >>>>> IMO, sending a Label Mapping message with the appropriate FEC >>>>> 129 to exactly the same set of adjacencies would suffice: >>>>> - adjacencies that participate in the VPLS intstance >> defined by this >>>>> FEC would respond with their own Label Mapping message back >>>>> - adjacencies that do NOT participate in the VPLS instance defined >>>>> by this FEC would respond with the Label Release message using >>>>> the LDP Status Code "Unassigned/Unrecognized TAI" as defined >>>>> in Section 5.3.3 of the current PWE3 control protocol draft >>>>> (draft-ietf-pwe3-control-protocol-17.txt). >>>> >>>> Yes, this is one of the alternatives we considered. >>>> >>>> Although it re-uses a TLV, it requires a procedure change, >>>> which I am not sure is better. >>>> >>>> Right now when an LDP peer receives a mapping it may >>>> liberally retain it even though it has no use for it. >>>> There certainly is no procedure for conditioning acceptance >>>> on information maintained in a table. >>>> >>>> In addition, in the naive way of doing this it would require >>>> propagation of the label mapping into whole domains where I >>>> don't (access networks where there are no PEs belonging to >>>> the VPLS instance). Yes this could also be fixed by having >>>> the S-PE snoop the mapping message, but then it would have to >>>> process every LDP packet (even non-VPLS joining ones) in this >>>> fashion. >>>> >>>> Finally, PEs that are not VPLS-aware will mis-handle the >>>> mapping request. In our case PEs that do not handle VPLS will >>>> silently ignore the message. >>>> >>>>> >>>>> Please note that the information carried in the proposed >>>> Join message >>>>> does not differ from one carried in the already defined FEC 129. >>>> >>>> Yes, this is discussed in the draft. >>>> >>>>> >>>>> So why such a MAJOR (a new messsage, not just a new TLV!) >>>> extension to >>>>> LDP? >>>> >>>> I do not see a major advantage in saving IANA a little bit of >>>> work in allocating two new TLVs, if we have to overload a >>>> lot of logic on existing ones. >>>> >>>> Y(J)S >>>> >>>> >> From l2vpn-bounces@ietf.org Mon Aug 08 16:40:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2EQU-0008N2-Iu; Mon, 08 Aug 2005 16:40:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2EQR-0008MA-DI for l2vpn@megatron.ietf.org; Mon, 08 Aug 2005 16:40:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23516 for ; Mon, 8 Aug 2005 16:40:45 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2EyD-00068j-8Y for l2vpn@ietf.org; Mon, 08 Aug 2005 17:15:41 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 08 Aug 2005 13:40:38 -0700 X-IronPort-AV: i="3.96,89,1122879600"; d="scan'208"; a="203579181:sNHT55549662" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j78KeWZ1018531; Mon, 8 Aug 2005 13:40:35 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 8 Aug 2005 16:40:29 -0400 Received: from [161.44.70.109] ([161.44.70.109]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 8 Aug 2005 16:40:28 -0400 In-Reply-To: <42F656C2.7020707@castlepoint.net> References: <42F656C2.7020707@castlepoint.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <89238da3e9abedbea4df60b677af5071@cisco.com> Content-Transfer-Encoding: 7bit From: Bruce Davie Date: Mon, 8 Aug 2005 16:40:33 -0400 To: Shane Amante X-Mailer: Apple Mail (2.619.2) X-OriginalArrivalTime: 08 Aug 2005 20:40:29.0021 (UTC) FILETIME=[69C110D0:01C59C59] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org Subject: Re: Draft Minutes of L2VPN WG Meeting @ IETF 63 (Paris) 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org A few comments related to my presentation of draft-ietf-l2vpn-signaling-05.txt: On Aug 7, 2005, at 2:45 PM, Shane Amante wrote: > > - Vach: Do we need distributed case described here? > - Bruce: ??? What I said was this: distributed case is described in draft-ietf-l2vpn-vpls-bgp-05.txt, so it seems prudent to keep it in this draft as well, lest anyone claim that the lack of distributed VPLS support is a drawback of using LDP. > > - Ted Seely: There is a lot of work going on to go across ASes, but > there is little work being done to address how service providers > honor SLAs across these services. There is nothing on the edge to > actually say that it is working. Ted says that maybe the IETF > should start to think how to address this. > - Bruce: Not sure which working group is best to address this > question. Suggested maybe we need a new Ops specific working group > area? > > - Bruce: Are we ready to do last call on this document? > - Vach took a poll of the room of who is ready for last call. Many > hands went up. Room seemed to support the idea to make final > changes (related to IANA code points) and then go to last call. > - Mark: Do we need IANA code points to be allocated before the final > call? > - (Someone): No My intent was not to get the code points, simply to clarify in the document that we need to obtain code points for AGI type and AII type in the FEC 129 TLV. The actual allocation can be done later (by IANA or PWE3, whoever actually has control over those fields). Bruce From l2vpn-bounces@ietf.org Mon Aug 08 17:06:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2EpI-0000Yq-DO; Mon, 08 Aug 2005 17:06:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2EpE-0000XS-GE for l2vpn@megatron.ietf.org; Mon, 08 Aug 2005 17:06:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24803 for ; Mon, 8 Aug 2005 17:06:22 -0400 (EDT) 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 1E2FMz-0006pf-Jd for l2vpn@ietf.org; Mon, 08 Aug 2005 17:41:18 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 08 Aug 2005 14:06:14 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j78L61ow000985; Mon, 8 Aug 2005 14:06:11 -0700 (PDT) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 8 Aug 2005 14:06:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 8 Aug 2005 14:06:10 -0700 Message-ID: <75B2A84D9323BC4CA3977CF378CE75EB65DEAC@xmb-sjc-21e.amer.cisco.com> Thread-Topic: Draft Minutes of L2VPN WG Meeting @ IETF 63 (Paris) Thread-Index: AcWcWgEVPX2hx0uJTUGDEaP1+iQWhAAAdKCg From: "Ali Sajassi \(sajassi\)" To: "Bruce Davie" , "Shane Amante" X-OriginalArrivalTime: 08 Aug 2005 21:06:11.0253 (UTC) FILETIME=[00FEFE50:01C59C5D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable Cc: l2vpn@ietf.org Subject: RE: Draft Minutes of L2VPN WG Meeting @ IETF 63 (Paris) 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org =20 [snip] > > - Vach: Do we need distributed case described here? > > - Bruce: ??? >=20 > What I said was this: distributed case is described in=20 > draft-ietf-l2vpn-vpls-bgp-05.txt, so it seems prudent to keep it in=20 > this draft as well, lest anyone claim that the lack of=20 > distributed VPLS=20 > support is a drawback of using LDP. >=20 I am wondering whether the notion of distributed case should be deprecated from both drafts since distributed PE in case of intra-AS, increases the number of PWs by an order of magnitude or two (depending on number of u-PEs getting aggregated by n-PE) which in turn increases complexity of PW full-mesh monitoring and partial-mesh detection. And in case of inter-AS, it is really a MS-PW rather than distributed PE. -Ali >=20 > > > > - Ted Seely: There is a lot of work going on to go across=20 > ASes, but > > there is little work being done to address how service providers > > honor SLAs across these services. There is nothing on=20 > the edge to > > actually say that it is working. Ted says that maybe the IETF > > should start to think how to address this. > > - Bruce: Not sure which working group is best to address this > > question. Suggested maybe we need a new Ops specific=20 > working group > > area? > > > > - Bruce: Are we ready to do last call on this document? > > - Vach took a poll of the room of who is ready for last=20 > call. Many > > hands went up. Room seemed to support the idea to make final > > changes (related to IANA code points) and then go to last call. > > - Mark: Do we need IANA code points to be allocated=20 > before the final > > call? > > - (Someone): No >=20 > My intent was not to get the code points, simply to clarify in the=20 > document that we need to obtain code points for AGI type and AII type=20 > in the FEC 129 TLV. The actual allocation can be done later=20 > (by IANA or=20 > PWE3, whoever actually has control over those fields). >=20 > Bruce >=20 >=20 From l2vpn-bounces@ietf.org Tue Aug 09 03:10:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2OFs-0004bk-Ic; Tue, 09 Aug 2005 03:10:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2OFp-0004bc-Lc for l2vpn@megatron.ietf.org; Tue, 09 Aug 2005 03:10:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16228 for ; Tue, 9 Aug 2005 03:10:27 -0400 (EDT) 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 1E2Onh-0004tV-1G for l2vpn@ietf.org; Tue, 09 Aug 2005 03:45:29 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 08 Aug 2005 22:42:08 -0700 X-IronPort-AV: i="3.96,90,1122879600"; d="scan'208"; a="653688911:sNHT31869108" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j795fpQW000297; Mon, 8 Aug 2005 22:42:03 -0700 (PDT) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 8 Aug 2005 22:42:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 8 Aug 2005 22:42:02 -0700 Message-ID: <75B2A84D9323BC4CA3977CF378CE75EB65E006@xmb-sjc-21e.amer.cisco.com> Thread-Topic: customer BPDU ethernet encapsulation over rfc1483(2684) ATM PVCs. Thread-Index: AcWZPqjM5abRkuLlS+mBh6tfw/m9egDY10KA From: "Ali Sajassi \(sajassi\)" To: "narasimhan g" , X-OriginalArrivalTime: 09 Aug 2005 05:42:03.0519 (UTC) FILETIME=[11FBF8F0:01C59CA5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: quoted-printable Cc: Subject: RE: customer BPDU ethernet encapsulation over rfc1483(2684) ATM PVCs. 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org In case of either 2684 (bridged encap over ATM) or 2427 (bridge encap over FR), the interworking unit of the PE needs to add the MAC header to the BPDU frames before passing it to the forwarding unit of the PE. The destination address is the standard IEEE 802.1D multicast address for BPDU and the source address is the MAC address of the PE (or more precisely of the IW unit).=20 -Ali > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org]=20 > On Behalf Of narasimhan g > Sent: Thursday, August 04, 2005 2:49 PM > To: l2vpn@ietf.org > Subject: customer BPDU ethernet encapsulation over=20 > rfc1483(2684) ATM PVCs. >=20 > Hi, >=20 > I have a question regarding customer BPDU encapsulation over ATM PVCs. >=20 > The VPLS draft draft-ietf-l2vpn-vpls-ldp-07.txt seems to=20 > suggest that the all frames that traverse a VPLS will have=20 > ethernet encasulation ( see below for quotes from the draft).=20 > Does it mean that customer BPDUs received over an=20 > rfc1483/2684 ATM PVC will/must also have an ethernet=20 > encasulation? RFC1483 encapsulation of BPDUs suggests=20 > otherwise. Can someone please clarify. >=20 > Attached below is relevant text from sections 7.1 and 4.4. >=20 >=20 > thanks, >=20 > narasim >=20 > 7.1. VPLS Encapsulation actions=20 >=20 > >=20 > =20 >=20 > By following the above rules, the Ethernet frame that=20 > traverses a <=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > VPLS is always a customer Ethernet frame. Note that the two > actions, at ingress and egress, of dealing with service delimiters > are local actions that neither PE has to signal to the other. They > allow, for example, a mix-and-match of VLAN tagged and untagged > services at either end, and do not carry across a VPLS a VLAN tag > that has local significance only. The service delimiter may be an > MPLS label also, whereby an Ethernet PW given by [PWE3-ETHERNET] > can serve as the access side connection into a PE. An RFC1483 > Bridged PVC encapsulation could also serve as a service delimiter. =20 > By limiting the scope of locally significant encapsulations to the > edge, hierarchical VPLS models can be developed that provide the > capability to network-engineer scalable VPLS deployments, as > described below.=20 >=20 > =20 >=20 > 4.4. Loop free VPLS=20 > =20 > If the topology of the VPLS is not restricted to a full mesh, then > it may be that for two PEs not directly connected via PWs, they > would have to use an intermediary PE to relay packets. This > topology would require the use of some loop-breaking protocol, like > a spanning tree protocol.=20 > =20 > Instead, a full mesh of PWs is established between PEs. Since > every PE is now directly connected to every other PE in the VPLS > via a PW, there is no longer any need to relay packets, and we can > instantiate a simpler loop-breaking rule - the "split horizon"=20 > rule: a PE MUST NOT forward traffic from one PW to another in the > same VPLS mesh.=20 > =20 > Note that customers are allowed to run the Spanning Tree Protocol > (STP) such as when a customer has "back door" links used to provide=20 > redundancy in the case of a failure within the VPLS. In=20 > such a <=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > case, STP Bridge PDUs (BPDUs) are simply tunneled through the > provider cloud.=20 >=20 >=20 >=20 >=20 > =09 > ____________________________________________________ > Start your day with Yahoo! - make it your home page=20 > http://www.yahoo.com/r/hs=20 > =20 >=20 From l2vpn-bounces@ietf.org Tue Aug 09 14:40:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Z1T-0006BO-Pg; Tue, 09 Aug 2005 14:40:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Z1S-0006BJ-RY for l2vpn@megatron.ietf.org; Tue, 09 Aug 2005 14:40:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28747 for ; Tue, 9 Aug 2005 14:40:21 -0400 (EDT) Received: from web32415.mail.mud.yahoo.com ([68.142.207.208]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E2ZZO-0000gU-2n for l2vpn@ietf.org; Tue, 09 Aug 2005 15:15:28 -0400 Received: (qmail 96513 invoked by uid 60001); 9 Aug 2005 18:40:10 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=c4mn2cHHtjWDWXTkQtJqvaJuTUVUsCjeWpq42zZfITqR3tbsN1m3sS8qy23hCrBdqhAxtT4GtW4o2e/2pQBHRPCEnm+tf0iziYYw1FSrD58WEGQo8L1c9MBlYl2t4lEPEA47lxw4hf78iwDKQ2zf1SGbr4JjsDVpQ5kE2cPb8rA= ; Message-ID: <20050809184010.96511.qmail@web32415.mail.mud.yahoo.com> Received: from [204.154.128.112] by web32415.mail.mud.yahoo.com via HTTP; Tue, 09 Aug 2005 11:40:10 PDT Date: Tue, 9 Aug 2005 11:40:10 -0700 (PDT) From: narasimhan g To: "Ali Sajassi \(sajassi\)" , l2vpn@ietf.org In-Reply-To: <75B2A84D9323BC4CA3977CF378CE75EB65E006@xmb-sjc-21e.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 2.7 (++) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: 8bit Cc: Subject: RE: customer BPDU ethernet encapsulation over rfc1483(2684) ATM PVCs. 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Hi Ali, Thanks for the clarification. narasim --- "Ali Sajassi (sajassi)" wrote: > > In case of either 2684 (bridged encap over ATM) or 2427 (bridge encap > over FR), the interworking unit of the PE needs to add the MAC header to > the BPDU frames before passing it to the forwarding unit of the PE. The > destination address is the standard IEEE 802.1D multicast address for > BPDU and the source address is the MAC address of the PE (or more > precisely of the IW unit). > > -Ali > > > -----Original Message----- > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] > > On Behalf Of narasimhan g > > Sent: Thursday, August 04, 2005 2:49 PM > > To: l2vpn@ietf.org > > Subject: customer BPDU ethernet encapsulation over > > rfc1483(2684) ATM PVCs. > > > > Hi, > > > > I have a question regarding customer BPDU encapsulation over ATM PVCs. > > > > The VPLS draft draft-ietf-l2vpn-vpls-ldp-07.txt seems to > > suggest that the all frames that traverse a VPLS will have > > ethernet encasulation ( see below for quotes from the draft). > > Does it mean that customer BPDUs received over an > > rfc1483/2684 ATM PVC will/must also have an ethernet > > encasulation? RFC1483 encapsulation of BPDUs suggests > > otherwise. Can someone please clarify. > > > > Attached below is relevant text from sections 7.1 and 4.4. > > > > > > thanks, > > > > narasim > > > > 7.1. VPLS Encapsulation actions > > > > > > > > > > > > By following the above rules, the Ethernet frame that > > traverses a <============== > > VPLS is always a customer Ethernet frame. Note that the two > > actions, at ingress and egress, of dealing with service delimiters > > are local actions that neither PE has to signal to the other. They > > allow, for example, a mix-and-match of VLAN tagged and untagged > > services at either end, and do not carry across a VPLS a VLAN tag > > that has local significance only. The service delimiter may be an > > MPLS label also, whereby an Ethernet PW given by [PWE3-ETHERNET] > > can serve as the access side connection into a PE. An RFC1483 > > Bridged PVC encapsulation could also serve as a service delimiter. > > By limiting the scope of locally significant encapsulations to the > > edge, hierarchical VPLS models can be developed that provide the > > capability to network-engineer scalable VPLS deployments, as > > described below. > > > > > > > > 4.4. Loop free VPLS > > > > If the topology of the VPLS is not restricted to a full mesh, then > > it may be that for two PEs not directly connected via PWs, they > > would have to use an intermediary PE to relay packets. This > > topology would require the use of some loop-breaking protocol, like > > a spanning tree protocol. > > > > Instead, a full mesh of PWs is established between PEs. Since > > every PE is now directly connected to every other PE in the VPLS > > via a PW, there is no longer any need to relay packets, and we can > > instantiate a simpler loop-breaking rule - the "split horizon" > > rule: a PE MUST NOT forward traffic from one PW to another in the > > same VPLS mesh. > > > > Note that customers are allowed to run the Spanning Tree Protocol > > (STP) such as when a customer has "back door" links used to provide > > redundancy in the case of a failure within the VPLS. In > > such a <============== > > case, STP Bridge PDUs (BPDUs) are simply tunneled through the > > provider cloud. > > > > > > > > > > > > ____________________________________________________ > > Start your day with Yahoo! - make it your home page > > http://www.yahoo.com/r/hs > > > > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From l2vpn-bounces@ietf.org Tue Aug 09 15:16:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Zab-0003nG-Al; Tue, 09 Aug 2005 15:16:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2ZaW-0003n1-Sy for l2vpn@megatron.ietf.org; Tue, 09 Aug 2005 15:16:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01432 for ; Tue, 9 Aug 2005 15:16:34 -0400 (EDT) Received: from lin1-118-39-26.ciena.com ([63.118.39.26] helo=mdmxm01.ciena.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2a8T-0001cf-O4 for l2vpn@ietf.org; Tue, 09 Aug 2005 15:51:42 -0400 Received: from mamxm01.ciena.com ([10.172.0.155]) by mdmxm01.ciena.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 9 Aug 2005 15:16:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59D16.DAEB68A2" Date: Tue, 9 Aug 2005 15:16:33 -0400 Message-ID: Thread-Topic: IPLS-04 version Thread-Index: AcWdFtrRwGqn4rxoRDKJE9tZh9RWpQ== From: "Shah, Himanshu" To: X-OriginalArrivalTime: 09 Aug 2005 19:16:34.0802 (UTC) FILETIME=[DB89F520:01C59D16] X-Spam-Score: 0.5 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: Shane Amante , Vach Kompella Subject: IPLS-04 version 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C59D16.DAEB68A2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I would like chairs to request for a two week review period=20 for ipls-04 version, in a separate email. The lastest draft, posted yesterday, contains changes for IANA code assignment. The previous draft (posted last month) contained substantial changes that simplified IPLS operations. The chairs wish to provide enough time for WG to review these changes before the final call is made. As indicated in the meeting notes from last week, the final call should begin right after the review period. thanks, himanshu Himanshu Shah Ciena Corp=20 ------_=_NextPart_001_01C59D16.DAEB68A2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IPLS-04 version

I would like chairs to request = for a two week review period
for ipls-04 version, in a = separate email.

The lastest draft, posted = yesterday, contains changes for
IANA code assignment. The = previous draft (posted last month)
contained substantial changes = that simplified IPLS operations.
The chairs wish to provide = enough time for WG to review these
changes before the final call = is made.

As indicated in the meeting = notes from last week, the final
call should begin right after = the review period.

thanks,
himanshu


Himanshu Shah
Ciena Corp

------_=_NextPart_001_01C59D16.DAEB68A2-- From l2vpn-bounces@ietf.org Tue Aug 09 15:50:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2a79-0000io-8S; Tue, 09 Aug 2005 15:50:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2a6t-0000dT-MX; Tue, 09 Aug 2005 15:50:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03645; Tue, 9 Aug 2005 15:50:00 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2aeq-0002c9-Uj; Tue, 09 Aug 2005 16:25:09 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E2a6r-0007HS-PV; Tue, 09 Aug 2005 15:50:01 -0400 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, 09 Aug 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: l2vpn@ietf.org Subject: I-D ACTION:draft-ietf-l2vpn-ipls-04.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: , Sender: l2vpn-bounces@ietf.org 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 : IP-Only LAN Service (IPLS) Author(s) : H. Shah, et al. Filename : draft-ietf-l2vpn-ipls-04.txt Pages : 20 Date : 2005-8-9 A Virtual Private LAN Service (VPLS) [VPLS] is used to interconnect systems across a wide-area or metropolitan-area network, making it appear that they are on a private LAN. The systems which are interconnected may themselves be LAN switches. If, however, they are IP hosts or IP routers, certain simplifications to the operation of the VPLS are possible. We call this simplified type of VPLS an "IP-only LAN Service" (IPLS). In an IPLS, as in a VPLS, LAN interfaces are run in promiscuous mode, and frames are forwarded based on their destination MAC addresses. However, the maintenance of the MAC forwarding tables is done via signaling, rather than via the MAC address learning procedures specified in [IEEE 802.1D]. This draft specifies the protocol extensions and procedures for support of the IPLS service. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-ipls-04.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-ipls-04.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-ipls-04.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: <2005-8-9113238.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l2vpn-ipls-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l2vpn-ipls-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-9113238.I-D@ietf.org> --OtherAccess-- --NextPart-- From l2vpn-bounces@ietf.org Tue Aug 09 15:50:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2a7L-0000of-4j; Tue, 09 Aug 2005 15:50:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2a6u-0000e2-Fg; Tue, 09 Aug 2005 15:50:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03662; Tue, 9 Aug 2005 15:50:02 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2aer-0002cC-2r; Tue, 09 Aug 2005 16:25:09 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E2a6r-0007HO-Oa; Tue, 09 Aug 2005 15:50:01 -0400 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, 09 Aug 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: l2vpn@ietf.org Subject: I-D ACTION:draft-ietf-l2vpn-ipls-03.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: , Sender: l2vpn-bounces@ietf.org 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 : IP-Only LAN Service (IPLS) Author(s) : H. Shah, et al. Filename : draft-ietf-l2vpn-ipls-03.txt Pages : 19 Date : 2005-8-9 A Virtual Private LAN Service (VPLS) [VPLS] is used to interconnect systems across a wide-area or metropolitan-area network, making it appear that they are on a private LAN. The systems which are interconnected may themselves be LAN switches. If, however, they are IP hosts or IP routers, certain simplifications to the operation of the VPLS are possible. We call this simplified type of VPLS an "IP-only LAN Service" (IPLS). In an IPLS, as in a VPLS, LAN interfaces are run in promiscuous mode, and frames are forwarded based on their destination MAC addresses. However, the maintenance of the MAC forwarding tables is done via signaling, rather than via the MAC address learning procedures specified in [IEEE 802.1D]. This draft specifies the protocol extensions and procedures for support of the IPLS service. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-ipls-03.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-ipls-03.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-ipls-03.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: <2005-8-9112302.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l2vpn-ipls-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l2vpn-ipls-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-9112302.I-D@ietf.org> --OtherAccess-- --NextPart-- From l2vpn-bounces@ietf.org Wed Aug 10 15:50:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2wal-0002vR-Ii; Wed, 10 Aug 2005 15:50:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2waS-0002m2-N5; Wed, 10 Aug 2005 15:50:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24213; Wed, 10 Aug 2005 15:50:01 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2x8b-0001wk-IV; Wed, 10 Aug 2005 16:25:22 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E2waQ-0007jd-70; Wed, 10 Aug 2005 15:50:02 -0400 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, 10 Aug 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: l2vpn@ietf.org Subject: I-D ACTION:draft-ietf-l2vpn-arp-mediation-03.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: , Sender: l2vpn-bounces@ietf.org 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 : ARP Mediation for IP Interworking of Layer 2 VPN Author(s) : H. Shah, et al. Filename : draft-ietf-l2vpn-arp-mediation-03.txt Pages : 16 Date : 2005-8-10 The VPWS service [L2VPN Framework] provides point-to-point connections between pairs of Customer Edge (CE) devices. It does so by binding two Attachment Circuits (each connecting a CE device with a Provider Edge, PE, device) to a pseudo-wire (connecting the two PEs). In general, the Attachment Circuits must be of the same technology (e.g., both Ethernet, both ATM), and the pseudo-wire must carry the frames of that technology. However, if it is known that the frames' payload consists solely of IP datagrams, it is possible to provide a point-to-point connection in which the pseudo-wire connects Attachment Circuits of different technologies. This requires the PEs to perform a function known as "ARP Mediation". ARP Mediation refers to the process of resolving Layer 2 addresses when different resolution protocols are used on either draft-ietf-l2vpn-arp-mediation-03.txt Attachment Circuit. The methods described in this document are applicable even when the CEs run a routing protocol between them, as long as the routing protocol runs over IP. In particular, the applicability of ARP mediation to ISIS is not addressed as IS-IS PDUs are not sent over IP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-arp-mediation-03.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-arp-mediation-03.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-arp-mediation-03.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: <2005-8-10142850.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l2vpn-arp-mediation-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l2vpn-arp-mediation-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-10142850.I-D@ietf.org> --OtherAccess-- --NextPart-- From l2vpn-bounces@ietf.org Wed Aug 10 16:03:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2wnk-0008T4-B5; Wed, 10 Aug 2005 16:03:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2wni-0008SO-LG for l2vpn@megatron.ietf.org; Wed, 10 Aug 2005 16:03:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27892 for ; Wed, 10 Aug 2005 16:03:44 -0400 (EDT) Received: from lin1-118-39-27.ciena.com ([63.118.39.27] helo=mdmxm02.ciena.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2xLr-0003MS-VA for l2vpn@ietf.org; Wed, 10 Aug 2005 16:39:05 -0400 Received: from mamxm01.ciena.com ([10.172.0.155]) by mdmxm02.ciena.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 10 Aug 2005 16:03:23 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59DE6.8F6A3658" Date: Wed, 10 Aug 2005 16:03:22 -0400 Message-ID: Thread-Topic: arp-mediation-03 Thread-Index: AcWd5o9nUargBI4yQqSNTRjuNQLvcA== From: "Shah, Himanshu" To: X-OriginalArrivalTime: 10 Aug 2005 20:03:23.0367 (UTC) FILETIME=[8FFCB770:01C59DE6] X-Spam-Score: 0.5 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: Shane Amante , Vach Kompella Subject: arp-mediation-03 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C59DE6.8F6A3658 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I would like chairs to issue a final call on=20 draft-ietf-l2vpn-arp-mediation-03.txt. The -02- version contained changes related to comments received on the final call before the last ietf (last week)=20 meeting. The -03- version (submitted a couple of days ago)=20 contains IANA code assignment proposal for IP address TLV. As noted in the meeting last week, the final call review this time should limit the comments to the changes made in version 02 and 03. thanks, himanshu Himanshu Shah Ciena Corp=20 ------_=_NextPart_001_01C59DE6.8F6A3658 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable arp-mediation-03

I would like chairs to issue a = final call on
draft-ietf-l2vpn-arp-mediation-03.txt.

The -02- version contained = changes related to comments
received on the final call = before the last ietf (last week)
meeting. The -03- version = (submitted a couple of days ago)
contains IANA code assignment = proposal for IP address TLV.

As noted in the meeting last = week, the final call review this time
should limit the comments to = the changes made in version
02 and 03.

thanks,
himanshu

Himanshu Shah
Ciena Corp

------_=_NextPart_001_01C59DE6.8F6A3658-- From l2vpn-bounces@ietf.org Fri Aug 12 17:01:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3geG-0000bt-T6; Fri, 12 Aug 2005 17:01:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3geF-0000bo-B2 for l2vpn@megatron.ietf.org; Fri, 12 Aug 2005 17:01:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02899 for ; Fri, 12 Aug 2005 17:01:00 -0400 (EDT) Received: from dsl081-098-224.den1.dsl.speakeasy.net ([64.81.98.224] helo=mail.castlepoint.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3hCo-00027D-VI for l2vpn@ietf.org; Fri, 12 Aug 2005 17:36:48 -0400 Received: from [127.0.0.1] (ns1.castlepoint.net [172.16.15.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.castlepoint.net (Postfix) with ESMTP id 1AC6E426BC for ; Fri, 12 Aug 2005 15:01:00 -0600 (MDT) Message-ID: <42FD0E0A.9090406@castlepoint.net> Date: Fri, 12 Aug 2005 15:00:58 -0600 From: Shane Amante User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en 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: 916029c14bdb340aa234d3ec4cd24f52 Content-Transfer-Encoding: 7bit Subject: Final Minutes of L2VPN WG Meeting @ IETF 63 (Paris) 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Below are the final L2VPN WG minutes from Paris, which only includes two clarifications that Bruce Davie forwarded to the list. Again, thanks to Andrew Dolganow, Jaime Miles and Cary Wright for serving as scribes. -shane & Vach IETF 63: Layer 2 Virtual Private Network WG (l2vpn) Meeting Minutes ----------------------------------------------------------------------- Wednesday, August 3, 1030-1230 ============================== Chairs: Vach Kompella Shane Amante ----------------------------------------------------------------------- 1) Agenda Update ----------------------------------------------------------------------- Two presentations cancelled: + Florin Balus' presentation cancelled, because discussion on MS-PW occurred the day before in PWE3. + Greg Weber's presentation on "Using RADIUS for PE-Based VPN Discovery" (draft-ietf-l2vpn-radius-pe-discovery-01.txt) cancelled, due to WG scheduling conflict. ----------------------------------------------------------------------- 2) WG Document Status (Vach) ----------------------------------------------------------------------- - Documents Status + draft-ietf-l2vpn-arp-mediation-02 (ARP Mediation): There are a few comments that are being addressed. MPLS WG being asked to review code points and changes to LDP. + draft-ietf-ipls-02 (IPLS): There are a lot of edits so working group last call is being delayed. Vach asked for more review from the working group. + draft-ietf-l2vpn-signalling-04 (L2VPN Signaling): Close to WG last call, however some issues raised in PWE3 may require some changes to the draft so WG will wait to see what happens in PWE3. - Charter Status + Good progress, or almost done with most items in charter. + OAM and MIBs are significant bodies of work that still need work. + Volunteers for work on MIB are requested. - ITU Liason Statement + 36 from ITU-T SG13 Y.ethoam needs to be reviewed. + Action is to read, evaluate and respond; asked for volunteers to see Vach or Shane afterwards to review and respond. - Loa Anderson made comment that VPLS BGP has progressed into the IANA for the code point allocation, and that they are ready to assign the code point. ----------------------------------------------------------------------- 3) Update: IP-Only LAN Service (IPLS) draft-ietf-l2vpn-ipls-02.txt Himanshu Shah ----------------------------------------------------------------------- - IPLS changes: + multicast mp2p PW type changes from IPLayer2Transport to Ethernet + All ARP and multicast frames are sent over multicast PW with Ethernet headers + A copy of ARP and link local multicast packets are sent to control plane for local CE discovery + addressed other comments from the list - IPLS simplified as a result - IPLS pending changes reviewed + Proposed IANA type and status code points to use. + Code points not yet in the draft + Will send email to MPLS WG to review code points. - Asked for a final call on IPLS draft - Show of hands indicated not too many people read a draft, Vach made a call for people to read a draft and have a discussion on the mailing list. Questions raised at the microphone: - Bernard Tuy: asked about support of IPv6 in this draft. - Himanshu: This was not supported in this version of the draft. - Bernard: Why is this not supported now? It is strange to have this work being done without IPv6 supported now. - Himanshu: v6 is planned, but wanted to get IPv4 out first. - Vach: Asked Mark Townsley if we can wait on IPv6 or if we have to address it right away? - Mark: We should take it to the list. - Himanshu: emphasized again that the goal is to get IPv4 done right away, IPv6 later. - Janusz: Should not go for a protocol without IPv6 consideration, at least a section on v6 is required. - Andy Malice: asked for IPv6 supporters to offer text. - George Swallow: commented that lacking IPv6 in the document may cause the work to be rejected. - Mark: agreed that people who want IPv6 need to provide the text. ----------------------------------------------------------------------- 4) Update: ARP Mediation for IP Interworking of Layer 2 VPN draft-ietf-l2vpn-arp-mediation-02.txt Himanshu Shah ----------------------------------------------------------------------- - Final call on -01 version, good support on the list. - Major comments on: PPP AC procedures, some ID nits, IP TLV etc. Presented response to those comments. - Proposed needed IANA code points, (0x096B type, 0x00000029 status) - Conclusion: + send email to MPLS WG for code points assignment review + propose to submit draft for IESG review + can do another final call for changes Vach: Let's do another final call, comments restricted to what's in the draft (specifically changes from last final call). 2 week last call will start right after this IETF. No Questions/Discussion raised at the microphone. ----------------------------------------------------------------------- 5) Provisioning Models and Endpoint Identifiers in L2VPN Signaling draft-ietf-l2vpn-signaling-04.txt Bruce Davie ----------------------------------------------------------------------- - Presented changes from last version: + Fixed distributed VPLS case + Addressed comments on the list (editorial, clarifications, bug fixes) + Clarified use of PE address in VSI identifier + Added IANA considerations section - All comments since Minneapolis were addressed, propose last call for this draft. Questions/Discussion raised at the microphone: - Mustapha Aissaoui: It will be hard to maintain this one central document and maybe it should only be informational. We have separate documents for applications, is this to become guidance RFC? - Bruce: Would like this to not just be informational but standards track, because it shows how to do interoperability between BGP and LDP. - Hamid: If intent of the draft is to be more like a solution draft with discovery, then the title should be corrected. - Bruce: Would be happy to change title. - Hamid: Is this consistent with existing documentation? - Bruce: This document is consistent with other work. Context of a signalling message (VPLS spec) does not have enough info for BGP auto-discovery, this document flushes out the details. - Vach: Do we need distributed case described here? - Bruce: The distributed case is described in draft-ietf-l2vpn-vpls- bgp-05.txt, so it seems prudent to keep it in this draft as well, lest anyone claim that the lack of distributed VPLS support is a drawback of using LDP. - Ted Seely: There is a lot of work going on to go across ASes, but there is little work being done to address how service providers honor SLAs across these services. There is nothing on the edge to actually say that it is working. Ted says that maybe the IETF should start to think how to address this. - Bruce: Not sure which working group is best to address this question. Suggested maybe we need a new Ops specific working group area? - Bruce: Are we ready to do last call on this document? - Vach took a poll of the room of who is ready for last call. Many hands went up. Room seemed to support the idea to make final changes (related to IANA code points) and then go to last call. - Mark: Do we need IANA code points to be allocated before the final call? - Bruce: My intent was not to get the code points, simply to clarify in the document that we need to obtain code points for AGI type and AII type in the FEC 129 TLV. The actual allocation can be done later (by IANA or PWE3, whoever actually has control over those fields). ----------------------------------------------------------------------- 6) LDP-based Autodiscovery for L2 Services draft-stein-ldp-auto-00.txt Yaakov Stein ----------------------------------------------------------------------- - Presentation talked about Access Network Architecture and important characteristics of that network that need to be taken into account. - Scale, simplicity of devices, combined devices (multiservice nodes), simple tree, limited BW, limited computational power, 1000s of nodes, no BGP may not be IGP, LDP for access LSP setup. - Manual configuration to join such a network would be difficult. - Basic assumptions in the draft: network element and links are relatively static, hence network discovery not a burden, services are dynamic, manual provisioning is difficult, want auto-discovery. When BGP available in core network it could be used, when LDP is only thing available then it should be used for auto-discovery. - New LDP message: JOIN Message, like label request, but only sent to nodes that are part of the VPLS instance. Vset members nodes after receiving the message start PW setup procedures to connect the new node. Questions/Discussion raised at the microphone: - Ali Sajassi: main point appears to be avoiding BGP in DSLAM's. BruceD's presentation shows how to do this without BGP, so this works. It's already taken care of by current framework. - YaakovS: Not negating other things may work, this draft proposes a simple way of doing that. - Ali: Specific autodiscovery case, very narrow, already taken care by current framework, (general enough). - YaakovS: Thinks it doesn't scale. - Kireeti: Like to see the work. Questions scalability, if the access network is simple, building LDP mesh would be challenging, how about reflectors? - YaakovS: Referenced how others have said that LDP is not that chatty. - Kireeti: we may still need something like route reflectors. - YaakovS: had not worked on this, but interested to look into idea like LDP reflectors. - Kireeti: went on to ask about using BGP if it only carries one NLRI, for auto-discovery, and how complicated that really is? - YaakovS: had not seen studies that really help resolve whether BGP or LDP is the best. - Kireeti: If all you implement is "light" BGP, the BGP requirements may be small, BGP would be fine in this case. - Vach: "Managing DSLAMS are configuration nightmare", not a feedback he has heard. - YaakovS: Depends on DSL architecture. - Vach: Still disagrees. Re: "Hierarchical model hides CEs" statement, that model not being as scalable as the one shown, is a wrong assumption. Thinks that people know how to do redundancy on RADIUS servers so a central server approach is not an issue. - YaakovS: RADIUS is one idea, but not the only one asked for. - Sasha: Who is talking to who over targeted LDP? - YaakovS: There are sessions within an access network and then between S-PEs. - Yakov Rekhter: thinks BGP processor overhead is not an issue and that the majority of boxes can run BGP. - Yaakov Stein: he would like to see a study to compare BGP to LDP. - Pedro: Algorithmically BGP is not as complex as stated. ----------------------------------------------------------------------- 7) Requirements for Multicast Support in Virtual Private LAN Services draft-kamite-l2vpn-vpls-mcast-reqts-00.txt Yuji Kamite ----------------------------------------------------------------------- - Scalability issues for multicast, need requirement documentation as a basis, the draft clarifies issues, describes requirements, guides multicast VPLS solution design. - Illustrates multicast challenges in VPLS. Issue A: Replication to non-member sites; Issue B: Replication of PWs on shared physical paths. - Presented summary of the requirements in the draft from multiple angles (General, Customer, Service Provider). - Major open questions: requirement levels, which PE-CE protocols are consulted, etc. - Next steps: enhance document with more feedback, propose as a WG document. Questions/Discussion raised at the microphone: - Rahul: Thinks this is useful work and should move forward. Also, thinks the document needs to require both solutions A and B. - Yuji: Does not want to limit scope and thinks, ideally, both solutions A and B should be addressed. - Bernard Tuy: Need to ensure IPv6 support and multicast auto-discovery and reporting of membership. - Yuji: Haven't given this any consideration yet. Feedback requested from a mailing list - Shane: polled room to see who had read the draft? A significant # of hands raised. Asked room: should this become a WG draft? Fair # of hands raised. Will take same question to list re: becoming WG draft. ----------------------------------------------------------------------- 8) Supporting IP Multicast over VPLS draft-serbest-l2vpn-vpls-mcast-03.txt Venu Hemige ----------------------------------------------------------------------- - Solving issue A from previous presentation, (multicast traffic flooded to all sites, with or without receivers). - Draft addresses building of replication state in PEs for IGMP and PIM only, PEs on cust-facing port must perform IGMP/PIM snooping, PE on PW port may learn multicast state using either IGMP/PIM snooping (no additional work, good up to medium scale deployments but does not scale above well, hence LDP). Why LDP? Already used to setup PW, reliable, will scale well. - Overview of LDP mechanism and special considerations as per draft were presented. - Next steps: + Comments please + Talk about combining with other draft (Rahul's) Questions/Discussion raised at the microphone: - Ali: Can you alleviate with PIM refresh-reduction. Have you been in touch with the work done there? - Rahul: PIM WG is in very early stages, but we have a solution now so we should use it. - George: This draft needs review by MPLS WG - Janusz: Recommend to split doc into 2 parts: IGMP/PIM in one, LDP in another - Venu: That discussion currently in progress ----------------------------------------------------------------------- 9) Multicast in VPLS - draft-raggarwa-l2vpn-vpls-mcast-01.txt Propagation of VPLS IP Multicast Group Membership Information - draft-raggarwa-l2vpn-vpls-mcast-ctrl-00.txt Rahul Aggarwal + NOTE: Rahul made one presentation, which covered both drafts. ----------------------------------------------------------------------- - Showed multiple VPLS multicast proposals, restated again the VPLS multicast limitations focus on optimizing state and not BW. - Optimizing BW and state are conflicting goals. - Tools to do that: + VPLS Auto-Discovery (use existing Auto-Discovery methods) + Allow elimination of flooding (PE-CE IGMP/PIM snooping, PE-PE reliable exchange of multicast control messages can be done with either BGP or LDP). - Presented overview of proposed solution in the drafts, overview of functional blocks for VPLS multicast, showed how various drafts address those functional blocks. - Conclusion: lots of interest, let's align drafts to follow functional decomposition, move drafts that fit (functional decomposition) already into WG docs, move others after restructuring to WG drafts. Questions/Discussion raised at the microphone: - Ali: Breaking down drafts to follow functional decomposition is a good idea. If I have bridges, and I send multicast, how does Ethernet OAM get treated? - Rahul: Haven't thought of that. - Shane (CH): Take it to the list. - Ali: Mechanism for shared tree, PE routers need to keep state need clarifications. - Rahul: There are procedures/clarifications missing in the current specs. - Ali: How close will we come to LAN Emulation? We need to be clear in the documents what the trade offs are for each document. - Rahul: Happy to include clarification, please provide specific text. - Ben Agrovitz: Glad to see we acknowledge tradoffs of the architecture. Challenge is finding the middle ground for tree sharing procedures. - Rahul: There is already a mechism in the draft. If anything is missing, happy to add it. - Shane: who has read the drafts? Good response. - Shane: should these both be WG drafts? Some responses. Will take same questions to the list. ----------------------------------------------------------------------- 10) L2VPN OAM Requirements and Framework draft-ietf-l2vpn-oam-req-frmk-03.txt Dinesh Mohan ----------------------------------------------------------------------- - Presented update on the draft, (overview of framework and requirements) - Status: + OAM framework adopted for other related work + New draft submitted - Section 7 added - IPLS OAM is FFS - input welcomed - VPWS OAM references draft-delord-pwe3-oam-application-01.txt, (goal is to avoid duplication). - Next steps: + Add VPWS OAM Reqs + Continue refining requirements on PW OAM + Other editorial updates. + Still work in progress, no intention for last call at this time. No Questions/Discussion raised at the microphone. ----------------------------------------------------------------------- 11) OAM Procedures for VPWS Interworking draft-aissaoui-l2vpn-vpws-iw-oam-03.txt Mustapha Aissaoui ----------------------------------------------------------------------- - No slides, Mustapha gave verbal update. - Planning revision by the end of August. - BFD for reverse concatenated path - Editorial changes - Had a good show of hands on this as a WG doc, but no response on the list. No Questions/Discussion raised at the microphone. ----------------------------------------------------------------------- 12) VPLS Interoperability with CE Bridges draft-sajassi-l2vpn-vpls-bridge-interop-01.txt Ali Sajassi ----------------------------------------------------------------------- - Updates from last draft + First presented in IETF61 + Comments/discussions on a mailing list + Almost all discussions on clarification - Main objectives: + Identity interop issues between VPLS and 802.1D bridges. - Presented recap of interop issues: + CE Bridge Protocol handling + Customer network topology changes + PE redundancy + MAC address scaling + Partial-mesh PWs + Muticast + Interop with 802.1ad Provider Bridges - Next steps: + What's the consensus on the draft? + What areas need further clarification? Questions/Discussion raised at the microphone: - Vach: Some issues seem not to be bridge interop issues, (MAC address scalability). Should take them out of here. Some may be too hard to handle: perfect LAN emulation. Need more refinement what's required & what's nice-to-have, (like protocol handling). - Ali: Regarding perfect LAN emulation, some things will just not work. - Vach: For problems already solved by some other organizations, we don't need to solve them here. Would be nice to know those problems already solved. - Ali: This is not the intent, important to point out the functionality required at the PE for interoperability. Will update the draft to address these comments. - Himanshu: Draft brings up good points. How will the draft address each of these issues? - Ali: Agreed. Need to point to solutions that exist, come up with solutions for things that are missing. - Himanshu: Would you like to address these issues with solutions in this draft? - Ali: Would like to address some, more extensive things may need a separate draft. - Dinesh: Suggests we consider an applicability statement to address these issues. Meeting Adjourned @ 1230 From l2vpn-bounces@ietf.org Tue Aug 16 11:41:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E53Z0-00056q-W7; Tue, 16 Aug 2005 11:41:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E53Yz-00056l-Di for l2vpn@megatron.ietf.org; Tue, 16 Aug 2005 11:41:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18833 for ; Tue, 16 Aug 2005 11:41:14 -0400 (EDT) Received: from lin1-118-39-27.ciena.com ([63.118.39.27] helo=mdmxm02.ciena.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E548L-0004Wc-7C for l2vpn@ietf.org; Tue, 16 Aug 2005 12:17:50 -0400 Received: from mamxm01.ciena.com ([10.172.0.155]) by mdmxm02.ciena.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 16 Aug 2005 11:40:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5A278.E332552E" Date: Tue, 16 Aug 2005 11:40:54 -0400 Message-ID: Thread-Topic: support of IPv6 in IPLS Thread-Index: AcWieOLyU/PnLFTKTiCrO+xiS54EJA== From: "Shah, Himanshu" To: X-OriginalArrivalTime: 16 Aug 2005 15:40:54.0767 (UTC) FILETIME=[E3918FF0:01C5A278] X-Spam-Score: 0.8 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Subject: support of IPv6 in IPLS 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C5A278.E332552E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In the last IETF WG meeting, a concern was raised that IPLS should address IPv6. There is some text in the=20 draft stating that support for IPv6 and ISIS is for future study and/or another work item. The conclusion of the discussions at the = meeting was that if any member of the WG feels strongly about support of IPv6 for IPLS, he/she should provide the text. I am asking WG to comment on this subject and/or provide text to support IPv6 for IPLS. The plan is to make a final call for IPLS draft (draft-ietf-l2vpn-ipls-04.txt) within 2-3 weeks. thanks, himanshu Himanshu Shah Ciena Corp=20 ------_=_NextPart_001_01C5A278.E332552E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable support of IPv6 in IPLS

In the last IETF WG meeting, a = concern was raised that
IPLS should address IPv6. There = is some text in the
draft stating that support for = IPv6 and ISIS is for future study
and/or another work item. The = conclusion of the discussions at the meeting
was that if any member of the = WG feels strongly about
support of IPv6 for IPLS, = he/she should provide the text.

I am asking WG to comment on = this subject and/or provide text
to support IPv6 for IPLS. The = plan is to make a final call for
IPLS draft = (draft-ietf-l2vpn-ipls-04.txt) within 2-3 weeks.

thanks,
himanshu

Himanshu Shah
Ciena Corp

------_=_NextPart_001_01C5A278.E332552E-- From l2vpn-bounces@ietf.org Wed Aug 17 11:11:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5PZd-00084p-8q; Wed, 17 Aug 2005 11:11:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5PZb-00083l-27 for l2vpn@megatron.ietf.org; Wed, 17 Aug 2005 11:11:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06572 for ; Wed, 17 Aug 2005 11:11:20 -0400 (EDT) From: kkhanna@isocore.com Received: from ns1.cpanel.btnaccess.com ([205.177.121.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5Q96-0002NP-Td for l2vpn@ietf.org; Wed, 17 Aug 2005 11:48:08 -0400 Received: from cpanel by ns1.cpanel.btnaccess.com with local (Exim 4.52) id 1E5PZH-0007bl-I7 for l2vpn@ietf.org; Wed, 17 Aug 2005 11:11:03 -0400 Received: from 65.213.193.37 ([65.213.193.37]) by www.isocore.com (Horde MIME library) with HTTP; Wed, 17 Aug 2005 11:11:03 -0400 Message-ID: <20050817111103.ez2cf4cb12ysg8og@www.isocore.com> Date: Wed, 17 Aug 2005 11:11:03 -0400 To: l2vpn@ietf.org References: <20050815114930.im8ojyqh1aggocss@www.isocore.com> In-Reply-To: <20050815114930.im8ojyqh1aggocss@www.isocore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ns1.cpanel.btnaccess.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [32001 502] / [47 12] X-AntiAbuse: Sender Address Domain - isocore.com X-Spam-Score: 0.3 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Subject: Important Info: MPLS 2005 (October 16-19; Washington DC) 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Greetings, You are invited to participate in the premier event on MPLS and related technologies at the MPLS 2005 International Conference () to be held from October 16-19, 2005 in Washington DC. PROGRAM: ---------- The conference includes presentations by leading exterts on hot topics in MPLS and GMPLS, tutorials, exhibits by key vendors, a panel discussion by Service Providers on Advanced Services using MPLS, and a panel discussion by industry vendors on LDP versus RSVP-TE. Program details are available at: REGISTRATION: -------------- Registration is underway - to register, go to: HOTEL RESERVATIONS: -------------------- The designated Hotel for the MPLS 2005 International Conference is the Omni Shoreham Hotel in Washington, D.C. (Tel: 202-234-0700 or 800-843-6664). A limited number of rooms are available at special rates for conference attendees. We suggest you make your reservation as soon as possible, since October is typically a busy period for hotels in Washington DC. To make reservations please call the Hotel Reservation Desk directly. You must identify yourself as MPLS 2005 conference attendees for discounted rates. We look forward to your participation in this event. Regards, Kavita From l2vpn-bounces@ietf.org Fri Aug 19 02:56:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E60nO-00046w-Uf; Fri, 19 Aug 2005 02:56:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E60nN-00046o-Mc for l2vpn@megatron.ietf.org; Fri, 19 Aug 2005 02:56:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16874 for ; Fri, 19 Aug 2005 02:56:03 -0400 (EDT) Received: from mgw2.noc.ntt.com ([210.163.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E61NG-0006sG-JL for l2vpn@ietf.org; Fri, 19 Aug 2005 03:33:12 -0400 Received: from mop3.noc.ntt.com by mgw2.noc.ntt.com (NTT-Com MailSV) with ESMTP id j7J6tXhj001911 for ; Fri, 19 Aug 2005 15:55:33 +0900 (JST) Received: from mip3.noc.ntt.com (mvi3.noc.ntt.com) by mop3.noc.ntt.com (NTT-Com MailSV) with ESMTP id <0ILG00HKEJ8K9X@ntt.com> for l2vpn@ietf.org; Fri, 19 Aug 2005 15:55:32 +0900 (JST) Date: Fri, 19 Aug 2005 15:55:32 +0900 From: "Yuji KAMITE" To: l2vpn@ietf.org Message-id: <0ILG00IRUJ8K0N@ntt.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Thread-index: AcWkivgg8N8HzflyQQmhp8uQKes4QA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Subject: IPv6 in multicast VPLS reqts 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Hi all, In Paris, there was a comment on IPv6 support for multicast VPLS requirement. > (Minutes of the last meeting) > - Bernard Tuy: Need to ensure IPv6 support and multicast > auto-discovery and reporting of membership. In my view, current requirement document already covers necessity minimum set in terms of IPv6 support too, because: - MLD is already mentioned as a CE-PE protocol. As shown in 5.1.2, if you are using IPv6, MLD SHOULD be supported if a solution consults Layer-3 information. - MLD can be snooped in a similar way to IGMP. - Section 4.1 states that Layer-3 multicast control packets (e.g. PIM, IGMP) MAY be flooded only to relevant members, with control of limiting flooding scope. This part is also applicable to MLD. - Also, [draft-ietf-magma-snoop-12.txt] says, the basic functionality of intercepting MLD packets, and building membership lists and multicast router lists, is the same as for IGMP. In the next revision I'm going to refer to this draft too. - NDP uses multicast forwarding, but this kind of packet is just flooded. - Section 4.1 says that Layer-3 control packets (e.g., OSPF, ISIS) other than multicast routing SHOULD be flooded to all PE/ CEs in a VPLS instance. This part also includes IPv6 relevant cases. Your feedback is welcome. Regards, -Yuji From l2vpn-bounces@ietf.org Fri Aug 19 15:50:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6CsX-0004L8-Oo; Fri, 19 Aug 2005 15:50:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6CsN-0004H7-Jw; Fri, 19 Aug 2005 15:50:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25872; Fri, 19 Aug 2005 15:50:00 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6DSN-0004Mu-Rq; Fri, 19 Aug 2005 16:27:16 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E6CsM-0002gp-6W; Fri, 19 Aug 2005 15:50:02 -0400 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, 19 Aug 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: l2vpn@ietf.org Subject: I-D ACTION:draft-ietf-l2vpn-signaling-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: , Sender: l2vpn-bounces@ietf.org 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-05.txt Pages : 35 Date : 2005-8-19 There are a number of different kinds of "Provider Provisioned Layer 2 VPNs" (L2VPNs). The different kinds of L2VPN may have different "provisioning models", i.e., different 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. The signaling protocol sets up the mesh of Pseudowires (PWs) that form the (virtual) backbone of the L2VPN. Any PW signaling protocol needs to have a method which allows each PW endpoint to identify the other; thus a PW signaling protocol will have the notion of an endpoint identifier. The semantics of the endpoint identifiers which the signaling protocol uses for a particular type of L2VPN are determined by the provisioning model. This document specifies a number of L2VPN provisioning models, and further specifies the semantic structure of the endpoint identifiers required by each provisioning model. It discusses the way in which the endpoint identifiers are distributed by the discovery process, especially when the discovery process is based upon 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-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-signaling-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-signaling-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: <2005-8-19141902.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l2vpn-signaling-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l2vpn-signaling-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-19141902.I-D@ietf.org> --OtherAccess-- --NextPart-- From l2vpn-bounces@ietf.org Fri Aug 19 17:00:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6DyK-0007VU-2q; Fri, 19 Aug 2005 17:00:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6DyH-0007Pc-V2 for l2vpn@megatron.ietf.org; Fri, 19 Aug 2005 17:00:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04947 for ; Fri, 19 Aug 2005 17:00:10 -0400 (EDT) Received: from dsl081-098-224.den1.dsl.speakeasy.net ([64.81.98.224] helo=mail.castlepoint.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6EYH-0008Ll-CI for l2vpn@ietf.org; Fri, 19 Aug 2005 17:37:26 -0400 Received: from [127.0.0.1] (ns1.castlepoint.net [172.16.15.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.castlepoint.net (Postfix) with ESMTP id 529B8426A3 for ; Fri, 19 Aug 2005 15:00:03 -0600 (MDT) Message-ID: <43064851.8030901@castlepoint.net> Date: Fri, 19 Aug 2005 15:00:01 -0600 From: Shane Amante User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en 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: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Subject: Last Call: draft-ietf-l2vpn-signaling-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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org This is the start of last call for: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-signaling-05.txt Last call will close at end of day 2 September 2005. -shane From l2vpn-bounces@ietf.org Mon Aug 22 13:43:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7GKa-00011K-ER; Mon, 22 Aug 2005 13:43:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7GKY-00010V-HS for l2vpn@megatron.ietf.org; Mon, 22 Aug 2005 13:43:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00321 for ; Mon, 22 Aug 2005 13:43:29 -0400 (EDT) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7Gv9-0000HR-Co for l2vpn@ietf.org; Mon, 22 Aug 2005 14:21:20 -0400 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 j7MHh9905659; Mon, 22 Aug 2005 10:43:10 -0700 (PDT) (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 j7MHh4G02500; Mon, 22 Aug 2005 10:43:04 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200508221743.j7MHh4G02500@merlot.juniper.net> To: Shane Amante In-Reply-To: Your message of "Fri, 19 Aug 2005 15:00:01 MDT." <43064851.8030901@castlepoint.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <51144.1124732583.1@juniper.net> Date: Mon, 22 Aug 2005 10:43:03 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: l2vpn@ietf.org Subject: Re: Last Call: draft-ietf-l2vpn-signaling-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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org > This is the start of last call for: > http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-signaling-05.txt > > Last call will close at end of day 2 September 2005. Couple of comments: >From 3.2.1: See Section 4 for a discussion of VSI-ID assignment in the case of multiple providers.) Perhaps I missed it, but I was not able to find any references to VSI-ID in Section 4. >From 3.2.2.1: In order to use BGP-based auto-discovery as specified in [BGP-AUTO], the globally unique identifier associated with a VPLS must be encodable as an 8-byte Route Distinguisher (RD). That seems to imply that in order to use [BGP-AUTO] a VPLS has to have a (single) unique identifier, and this identifier has to be encodable as an RD. First of all this is incorrect, as [BGP-AUTO] explicitly states that Note that it is not strictly necessary for all the VSIs in the same VPLS to have the same RD, all that is really necessary is that the NLRI uniquely identify a virtual LAN switch. Second, I'd the authors to explain what breaks when not all the VSIs within a given VPLS use the same RD (provided that the RD is still globally unique). Yakov. From l2vpn-bounces@ietf.org Tue Aug 23 16:46:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7ff7-0003GR-FE; Tue, 23 Aug 2005 16:46:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7ff3-0003FF-EW for l2vpn@megatron.ietf.org; Tue, 23 Aug 2005 16:46:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10585 for ; Tue, 23 Aug 2005 16:46:19 -0400 (EDT) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7ffD-0005LA-R9 for l2vpn@ietf.org; Tue, 23 Aug 2005 16:46:33 -0400 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j7NKjtP23834; Tue, 23 Aug 2005 16:45:56 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message Date: Tue, 23 Aug 2005 16:45:51 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D05DD8E97@zcarhxm0.corp.nortel.com> Thread-Topic: Last Call: draft-ietf-l2vpn-signaling-05.txt Thread-Index: AcWlAUvgJUFJib+sRaie/28w6FictwDE4ZkQAAOni2A= From: "Hamid Ould-Brahim" To: "Shane Amante" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Subject: RE: Last Call: draft-ietf-l2vpn-signaling-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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org One comment on this version: Section 2.1 indicates that: " For example, the long prefix type of [AII-TYPES] could be used to enable the communication of administrative information, perhaps combined with information learned during autodiscovery." I couldn't find the reference to [AII-TYPES]. Is it for draft-metz-aii-aggregate-00.txt? Hamid. > > > This is the start of last call for: > > http://www.ietf.org/internet-drafts/draft-> ietf-l2vpn-signaling-05.txt > > Last call will close at end of day 2 September 2005. > > -shane > From l2vpn-bounces@ietf.org Wed Aug 24 10:08:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7vvk-0006QE-Ab; Wed, 24 Aug 2005 10:08:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7vvi-0006Q6-NN for l2vpn@megatron.ietf.org; Wed, 24 Aug 2005 10:08:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22461 for ; Wed, 24 Aug 2005 10:08:37 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7vw2-0001PS-BX for l2vpn@ietf.org; Wed, 24 Aug 2005 10:08:59 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 24 Aug 2005 16:08:28 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7OE7uVp017022; Wed, 24 Aug 2005 16:08:26 +0200 (MEST) Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 24 Aug 2005 16:08:24 +0200 Received: from [64.134.95.78] ([10.82.242.118]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 24 Aug 2005 16:08:23 +0200 In-Reply-To: <085091CB2CA14E4B8B163FFC37C84E9D05DD8E97@zcarhxm0.corp.nortel.com> References: <085091CB2CA14E4B8B163FFC37C84E9D05DD8E97@zcarhxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8aadfd9abcdca758c8f8d8d71227abfd@cisco.com> Content-Transfer-Encoding: 7bit From: Bruce Davie Date: Wed, 24 Aug 2005 10:07:04 -0400 To: "Hamid Ould-Brahim" X-Mailer: Apple Mail (2.622) X-OriginalArrivalTime: 24 Aug 2005 14:08:23.0838 (UTC) FILETIME=[4A4303E0:01C5A8B5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org, Shane Amante Subject: Re: Last Call: draft-ietf-l2vpn-signaling-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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org On Aug 23, 2005, at 4:45 PM, Hamid Ould-Brahim wrote: > > > One comment on this version: > > Section 2.1 indicates that: > > " For example, the long prefix type of [AII-TYPES] could be > used to enable the communication of administrative > information, perhaps combined with information learned during > autodiscovery." > > I couldn't find the reference to [AII-TYPES]. > > Is it for draft-metz-aii-aggregate-00.txt? > Yes - my mistake. Will fix it in next rev. > Hamid. From l2vpn-bounces@ietf.org Wed Aug 24 12:28:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7y6g-0004Ef-V5; Wed, 24 Aug 2005 12:28:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7y6f-0004EY-73 for l2vpn@megatron.ietf.org; Wed, 24 Aug 2005 12:28:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02590 for ; Wed, 24 Aug 2005 12:28:02 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7y70-0006Xk-0q for l2vpn@ietf.org; Wed, 24 Aug 2005 12:28:27 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 24 Aug 2005 18:27:50 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7OGRmVP024726; Wed, 24 Aug 2005 18:27:48 +0200 (MEST) Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 24 Aug 2005 18:27:48 +0200 Received: from [64.134.95.78] ([10.82.240.103]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 24 Aug 2005 18:27:47 +0200 In-Reply-To: <200508221743.j7MHh4G02500@merlot.juniper.net> References: <200508221743.j7MHh4G02500@merlot.juniper.net> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <78076308154c2f29d3ec623f4a3f19a2@cisco.com> Content-Transfer-Encoding: 7bit From: Bruce Davie Date: Wed, 24 Aug 2005 12:27:49 -0400 To: Yakov Rekhter X-Mailer: Apple Mail (2.622) X-OriginalArrivalTime: 24 Aug 2005 16:27:47.0881 (UTC) FILETIME=[C39EB190:01C5A8C8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org, Shane Amante Subject: Re: Last Call: draft-ietf-l2vpn-signaling-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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org On Aug 22, 2005, at 1:43 PM, Yakov Rekhter wrote: >> This is the start of last call for: >> http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-signaling-05.txt >> >> Last call will close at end of day 2 September 2005. > > Couple of comments: > >> From 3.2.1: > > See Section 4 for a discussion of VSI-ID assignment in the case of > multiple providers.) > > Perhaps I missed it, but I was not able to find any references to > VSI-ID in Section 4. Sorry, that was careless writing on my part. The VSI-ID is the concatenation of an RD with another 32 bits of ID, and we discuss RD allocation in 4.4. I will clarify this. > >> From 3.2.2.1: > > In order to use BGP-based auto-discovery as specified in [BGP-AUTO], > the globally unique identifier associated with a VPLS must be > encodable as an 8-byte Route Distinguisher (RD). > > That seems to imply that in order to use [BGP-AUTO] a VPLS has to > have a (single) unique identifier, I don't understand why you think this text implies a single unique ID. That was not our intent, and as you point out below, nothing breaks if one does not. Perhaps to avoid this confusion I could change the above text along the lines of: 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). Bruce > and this identifier has to be encodable > as an RD. First of all this is incorrect, as [BGP-AUTO] explicitly > states that > > Note that it is not strictly necessary for all > the VSIs in the same VPLS to have the same RD, all that is really > necessary is that the NLRI uniquely identify a virtual LAN switch. > > Second, I'd the authors to explain what breaks when not all the > VSIs within a given VPLS use the same RD (provided that the RD is > still globally unique). > > Yakov. From l2vpn-bounces@ietf.org Wed Aug 24 15:54:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E81Ko-0007vG-8Z; Wed, 24 Aug 2005 15:54:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E81Km-0007v8-Nm for l2vpn@megatron.ietf.org; Wed, 24 Aug 2005 15:54:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15884 for ; Wed, 24 Aug 2005 15:54:51 -0400 (EDT) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E81L9-0005M3-DI for l2vpn@ietf.org; Wed, 24 Aug 2005 15:55:16 -0400 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 j7OJsW951170; Wed, 24 Aug 2005 12:54:32 -0700 (PDT) (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 j7OJsQG89508; Wed, 24 Aug 2005 12:54:26 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200508241954.j7OJsQG89508@merlot.juniper.net> To: Bruce Davie In-Reply-To: Your message of "Wed, 24 Aug 2005 12:27:49 EDT." <78076308154c2f29d3ec623f4a3f19a2@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <74060.1124913266.1@juniper.net> Date: Wed, 24 Aug 2005 12:54:26 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: l2vpn@ietf.org, Shane Amante Subject: Re: Last Call: draft-ietf-l2vpn-signaling-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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org > > On Aug 22, 2005, at 1:43 PM, Yakov Rekhter wrote: > > >> This is the start of last call for: > >> http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-signaling-05.txt > >> > >> Last call will close at end of day 2 September 2005. > > > > Couple of comments: > > > >> From 3.2.1: > > > > See Section 4 for a discussion of VSI-ID assignment in the case of > > multiple providers.) > > > > Perhaps I missed it, but I was not able to find any references to > > VSI-ID in Section 4. > > Sorry, that was careless writing on my part. The VSI-ID is the > concatenation of an RD with another 32 bits of ID, and we discuss RD > allocation in 4.4. I will clarify this. That would be fine. > >> From 3.2.2.1: > > > > In order to use BGP-based auto-discovery as specified in [BGP-AUTO], > > the globally unique identifier associated with a VPLS must be > > encodable as an 8-byte Route Distinguisher (RD). > > > > That seems to imply that in order to use [BGP-AUTO] a VPLS has to > > have a (single) unique identifier, > > I don't understand why you think this text implies a single unique ID. > That was not our intent, and as you point out below, nothing breaks if > one does not. Perhaps to avoid this confusion I could change the above > text along the lines of: > > 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 would certainly address my concern. Yakov. From l2vpn-bounces@ietf.org Thu Aug 25 12:06:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8KFe-0006ta-Av; Thu, 25 Aug 2005 12:06:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7e5s-0002nD-H0 for l2vpn@megatron.ietf.org; Tue, 23 Aug 2005 15:05:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23766 for ; Tue, 23 Aug 2005 15:05:54 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7e61-0006oK-Ao for l2vpn@ietf.org; Tue, 23 Aug 2005 15:06:06 -0400 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j7NJ5TN07200; Tue, 23 Aug 2005 15:05:30 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message Date: Tue, 23 Aug 2005 15:05:24 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D05DD8CAC@zcarhxm0.corp.nortel.com> Thread-Topic: Last Call: draft-ietf-l2vpn-signaling-05.txt Thread-Index: AcWlAUvgJUFJib+sRaie/28w6FictwDE4ZkQ From: "Hamid Ould-Brahim" To: "Shane Amante" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-Mailman-Approved-At: Thu, 25 Aug 2005 12:06:48 -0400 Cc: Subject: RE: Last Call: draft-ietf-l2vpn-signaling-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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org One comment on this version: Section 2.1 indicates that: " For example, the long prefix type of [AII-TYPES] could be used to enable the communication of administrative information, perhaps combined with information learned during autodiscovery." I couldn't find the reference to [AII-TYPES]. Is it for draft-metz-aii-aggregate-00.txt? Hamid. > > > This is the start of last call for: > http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-signaling-05.txt > > Last call will close at end of day 2 September 2005. > > -shane > > > > From l2vpn-bounces@ietf.org Fri Aug 26 14:36:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8j3p-0003xE-LA; Fri, 26 Aug 2005 14:36:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8j3n-0003x4-T3 for l2vpn@megatron.ietf.org; Fri, 26 Aug 2005 14:36:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05840 for ; Fri, 26 Aug 2005 14:36:14 -0400 (EDT) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8j4Z-0008AI-0W for l2vpn@ietf.org; Fri, 26 Aug 2005 14:37:04 -0400 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 j7QIa2988178; Fri, 26 Aug 2005 11:36:02 -0700 (PDT) (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 j7QIZrG01300; Fri, 26 Aug 2005 11:35:53 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200508261835.j7QIZrG01300@merlot.juniper.net> To: Bruce Davie In-Reply-To: Your message of "Wed, 24 Aug 2005 12:27:49 EDT." <78076308154c2f29d3ec623f4a3f19a2@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <42370.1125081353.1@juniper.net> Date: Fri, 26 Aug 2005 11:35:53 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: l2vpn@ietf.org, Shane Amante Subject: Re: Last Call: draft-ietf-l2vpn-signaling-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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Bruce, [clipped...] > >> From 3.2.2.1: > > > > In order to use BGP-based auto-discovery as specified in [BGP-AUTO], > > the globally unique identifier associated with a VPLS must be > > encodable as an 8-byte Route Distinguisher (RD). > > > > That seems to imply that in order to use [BGP-AUTO] a VPLS has to > > have a (single) unique identifier, > > I don't understand why you think this text implies a single unique ID. > That was not our intent, and as you point out below, nothing breaks if > one does not. Perhaps to avoid this confusion I could change the above > text along the lines of: > > 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). As I said in my previous e-mail, this would be fine. But please also apply the same fix to the similar text in 3.3.2.1. Yakov. > > > Bruce > > > and this identifier has to be encodable > > as an RD. First of all this is incorrect, as [BGP-AUTO] explicitly > > states that > > > > Note that it is not strictly necessary for all > > the VSIs in the same VPLS to have the same RD, all that is really > > necessary is that the NLRI uniquely identify a virtual LAN switch. > > > > Second, I'd the authors to explain what breaks when not all the > > VSIs within a given VPLS use the same RD (provided that the RD is > > still globally unique). > > > > Yakov.