From l2vpn-bounces@ietf.org Wed Jul 05 11:17:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy97q-00014v-Py; Wed, 05 Jul 2006 11:17:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy97o-00014f-TD for l2vpn@ietf.org; Wed, 05 Jul 2006 11:17:12 -0400 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy97n-0003KF-L4 for l2vpn@ietf.org; Wed, 05 Jul 2006 11:17:12 -0400 Received: from [127.0.0.1] (dog.tcb.net [64.78.150.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id 1B975644C1 for ; Wed, 5 Jul 2006 09:17:07 -0600 (MDT) Message-ID: <44ABD7F5.1080609@castlepoint.net> Date: Wed, 05 Jul 2006 09:17:09 -0600 From: Shane Amante User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) 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: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: L2VPN Agenda for IETF 66 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org The agenda for the upcoming meeting in Montreal is located here, (and in-line below): http://www3.ietf.org/proceedings/06jul/agenda/l2vpn.txt For those who are presenting at the upcoming meeting, please e-mail your slides to Vach & I by no later than noon EST on July 12. Thanks, -shane & Vach ---cut here--- IETF 66: Layer 2 Virtual Private Network WG (l2vpn) Agenda Thursday, July 13, 2006, 1510-1610 ================================== Chairs: Vach Kompella Shane Amante 1) Administrivia - Mailing list: http://www.ietf.org/mail-archive/web/l2vpn/index.html - Scribe? - Blue Sheets - Agenda Bashing 2) WG Status and Update Chairs 10 mins 3) Virtual Private Lan Services (VPLS) Management Information Base http://www.ietf.org/internet-drafts/draft-nadeau-l2vpn-vpls-mib-00.txt Tom Nadeau (tnadeau@cisco.com) 10 mins 4) PIM Snooping over VPLS http://www.ietf.org/internet-drafts/draft-hemige-serbest-l2vpn-vpls-pim-snooping-01.txt Venu Hemige (venu.hemige@alcatel.com) 10 mins 5) Meeting Closes From l2vpn-bounces@ietf.org Wed Jul 05 12:35:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyAL1-0000EF-J0; Wed, 05 Jul 2006 12:34:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyAL0-0000Dw-Al; Wed, 05 Jul 2006 12:34:54 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyAKz-0000FW-31; Wed, 05 Jul 2006 12:34:54 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k65GYY1u030988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Jul 2006 16:34:34 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FyAKg-0007Z4-1w; Wed, 05 Jul 2006 12:34:34 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Wed, 05 Jul 2006 12:34:34 -0400 X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: l2vpn mailing list , l2vpn chair , Internet Architecture Board , l2vpn chair , RFC Editor Subject: Protocol Action: 'Virtual Private LAN Service (VPLS) Using BGP for Auto-discovery and Signaling' to Proposed Standard X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org The IESG has approved the following document: - 'Virtual Private LAN Service (VPLS) Using BGP for Auto-discovery and Signaling ' as a Proposed Standard This document is the product of the Layer 2 Virtual Private Networks Working Group. The IESG contact persons are Mark Townsley and Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-bgp-08.txt Technical Summary This document describes the Virtual Private LAN Service (VPLS), also known as Transparent LAN Service and Virtual Private Switched Network service. The service offers a Layer 2 Virtual Private Network (VPN); however, in the case ofVPLS, the customers in the VPN are connected by a multipoint network, in contrast to traditional Layer 2 VPNs, which are point-to-point in nature. Thisdocument describes the functions required to offer VPLS, a mechanism for signaling a VPLS using BGP, and rules for forwarding VPLS frames across a packet switched network. Working Group Summary The VPLS solutions have been one of great controversies within the VPN workinggroups ever since the PPVPN days. There have been two sets of solutionsand much debate on the relative merits of these solutions. An agreement was reached that it is not really the choice of signaling protocol that is the major difference between the LDP and BGP based solutions, but the kind of environment they are targeted at. VPLS-LDP is aimed at a market of networks built on relatively small and functionally simple switches, while VPLS-BGP is primarily suited for use by high-end routers. There is a comparatively good understanding for this agreement in the working group. Within the working group there is no one that wants to go over that debate again. VPLS-BGP has been through a number of reviews, including reviews in the L2VPN working group and the IDR WG. We know that Alex has requested that it shall be reviewed in routing directorate. Protocol Quality The protocol is implemented and deployed. There is one vendor who is known tohave implemented, and widely deployed, the VPLS-BGP spec. There is believed to be two other implementations, but that hasn't been confirmed. The number of deployments is larger, but I don't have figures. We have not had any reviewer stand up and saying there is any need for major re-work. This is most likely attributable to the fact that this specification is rather limited in scope, specifically: signaling and discovery of VPLS instances. The specification has been reviewed by Alex Zinin, the IDR WG, and Mark Townsley. IESG Note The L2VPN Working Group produced two separate documents, [RFC-draft-ietf-l2vpn-vpls-ldp] and [RFC-draft-ietf-l2vpn-vpls-bgp], that ultimately perform similar functions in different manners. Be aware that each method is commonly referred to as "VPLS" even though they are distinct and incompatible with one another. From l2vpn-bounces@ietf.org Sat Jul 08 10:12:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzDXv-0000cM-LL; Sat, 08 Jul 2006 10:12:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzDXu-0000cH-JL for l2vpn@ietf.org; Sat, 08 Jul 2006 10:12:34 -0400 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzDXt-0005a0-7h for l2vpn@ietf.org; Sat, 08 Jul 2006 10:12:34 -0400 Received: from [172.16.15.25] (dsl081-098-224.den1.dsl.speakeasy.net [64.81.98.224]) by dog.tcb.net (Postfix) with ESMTP id 3D0A8644D2 for ; Sat, 8 Jul 2006 08:12:24 -0600 (MDT) Mime-Version: 1.0 (Apple Message framework v752.2) References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Shane Amante Date: Sat, 8 Jul 2006 08:12:27 -0600 To: l2vpn@ietf.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Subject: Fwd: [L2VPN] comments on VPLS MIB X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org Forwarding to the list on behalf of Anil. -shane Begin forwarded message: > From: anilr@accton.com > Date: July 7, 2006 10:52:55 AM MDT > To: Shane Amante , tnadeau@cisco.com > Subject: Fwd: [L2VPN] comments on VPLS MIB > > Shane, Tom, > > For some reason, my mail bounces off the l2vpn list. > > Please forward it if you could, for consideration at the meeting. > > Regards, > Anil > > ----- Forwarded by Anil Rijhsinghani/AcctonUS on 07/07/2006 12:39 > PM ----- > > Anil > Rijhsinghani To: tnadeau@cisco.com > cc: l2vpn@ietf.org > 07/05/2006 Subject: comments on > VPLS MIB(Document link: Anil Rijhsinghani) > 01:27 PM > > > > > > Tom, > > I was preparing to send in a contribution for VPLS MIB, before I > saw yours > on the agenda. > > Some initial comments/questions on the MIB: > > - table of contents either not updated, or some piece of the MIB > missing? > (page numbers) > - I assume this only convers the LDP method; if so perhaps mention in > abstract > - need an optional static table to manually configure VPLS peers > - what forms of auto-discovery in vplsPwBindBindType, can these be > listed > as types? > - vplsMacLearning: why is this needed? (corresponding function not > described in VPLS document) > - vplsDiscardUnknownDest: why needed? (ditto) > - vplMacAging: why needed? (ditto) > - object needed for VPLS MTU > - object needed for information on HVPLS Spoke connection (eg, > correlation > to Q-in-Q) > - object to correlate the interface on which a VPLS instance is > running > would be useful, which in turn ties into MAC address based on ifTable > - up-front text to describe relationship to ifTable (in addition to > Bridge > MIB and PW MIB) > - traps for high-water and low-mater mark: suggest removing these > (there > isn't such a thing in Bridge MIB either) > > Regards, > Anil > > > > > > Shane Amante > oint.net> cc: > Subject: L2VPN Agenda > for IETF 66 > 07/05/2006 > 11:17 AM > > > > > > > The agenda for the upcoming meeting in Montreal is located here, (and > in-line below): > http://www3.ietf.org/proceedings/06jul/agenda/l2vpn.txt > > For those who are presenting at the upcoming meeting, please e-mail > your > slides to Vach & I by no later than noon EST on July 12. > > Thanks, > > -shane & Vach > > > ---cut here--- > > IETF 66: Layer 2 Virtual Private Network WG (l2vpn) Agenda > > Thursday, July 13, 2006, 1510-1610 > ================================== > > Chairs: Vach Kompella > Shane Amante > > 1) Administrivia > - Mailing list: http://www.ietf.org/mail-archive/web/l2vpn/ > index.html > - Scribe? > - Blue Sheets > - Agenda Bashing > > 2) WG Status and Update > Chairs > 10 mins > > 3) Virtual Private Lan Services (VPLS) Management Information Base > http://www.ietf.org/internet-drafts/draft-nadeau-l2vpn-vpls-mib-00.txt > Tom Nadeau (tnadeau@cisco.com) > 10 mins > > 4) PIM Snooping over VPLS > http://www.ietf.org/internet-drafts/draft-hemige-serbest-l2vpn-vpls- > pim-snooping-01.txt > > Venu Hemige (venu.hemige@alcatel.com) > 10 mins > > 5) Meeting Closes > > > > > > From l2vpn-bounces@ietf.org Sat Jul 08 13:35:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzGhs-0007j4-Mm; Sat, 08 Jul 2006 13:35:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzGhs-0007hL-2u for l2vpn@ietf.org; Sat, 08 Jul 2006 13:35:04 -0400 Received: from mail.tataelxsi.co.in ([203.200.1.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzGhp-0006BD-Gg for l2vpn@ietf.org; Sat, 08 Jul 2006 13:35:04 -0400 Received: from jayanta (dialpool-210-214-122-226.maa.sify.net [210.214.122.226]) by mail.tataelxsi.co.in (MOS 3.7.4b-GA) with ESMTP id BSV95616 (AUTH jayanta); Sat, 8 Jul 2006 23:05:46 +0530 (IST) From: Jayanta Tewari To: "'Shane Amante'" , Date: Sat, 8 Jul 2006 23:06:45 +0530 Message-ID: <000201c6a2b5$165494e0$7781110a@telxsi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Importance: Normal In-Reply-To: X-Junkmail: Blacklisted X-Mirapoint-Sig: mail.tataelxsi.co.in X-Spam-Score: 1.0 (+) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: Subject: RE: [L2VPN] comments on VPLS MIB X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org Should not there be objects to distinguish between qualified and unqualified learning methods for Virtual switch instances ? Refering to 4.2,will it be possible to keep label information through BRIDGE MIB with respect to learning processes (as it might map to interfaces or label.Right ?)What about a table related to Mac learning in this MIB itself ? Pls. see other comments below starting with JT. rgds, --Jayanta -----Original Message----- From: Shane Amante [mailto:shane@castlepoint.net] Sent: Saturday, July 08, 2006 7:42 PM To: l2vpn@ietf.org Subject: Fwd: [L2VPN] comments on VPLS MIB Forwarding to the list on behalf of Anil. -shane Begin forwarded message: > From: anilr@accton.com > Date: July 7, 2006 10:52:55 AM MDT > To: Shane Amante , tnadeau@cisco.com > Subject: Fwd: [L2VPN] comments on VPLS MIB > > Shane, Tom, > > For some reason, my mail bounces off the l2vpn list. > > Please forward it if you could, for consideration at the meeting. > > Regards, > Anil > > ----- Forwarded by Anil Rijhsinghani/AcctonUS on 07/07/2006 12:39 > PM ----- > > Anil > Rijhsinghani To: tnadeau@cisco.com > cc: l2vpn@ietf.org > 07/05/2006 Subject: comments on > VPLS MIB(Document link: Anil Rijhsinghani) > 01:27 PM > > > > > > Tom, > > I was preparing to send in a contribution for VPLS MIB, before I > saw yours > on the agenda. > > Some initial comments/questions on the MIB: > > - table of contents either not updated, or some piece of the MIB > missing? > (page numbers) > - I assume this only convers the LDP method; if so perhaps mention in > abstract > - need an optional static table to manually configure VPLS peers > - what forms of auto-discovery in vplsPwBindBindType, can these be > listed > as types? > - vplsMacLearning: why is this needed? (corresponding function not > described in VPLS document) > - vplsDiscardUnknownDest: why needed? (ditto) > - vplMacAging: why needed? (ditto) JT:I guess these correspond to sections 4.2,6.2,9.1 etc. draft-ietf-l2vpn-vpls-ldp-08.txt. > - object needed for VPLS MTU > - object needed for information on HVPLS Spoke connection (eg, > correlation > to Q-in-Q) JT:Is there anything special needed for HVPLS architecure as the spokes will follow normal L2 technoligies and will keep the related information in already developed MIBs for them ? > - object to correlate the interface on which a VPLS instance is > running > would be useful, which in turn ties into MAC address based on ifTable > - up-front text to describe relationship to ifTable (in addition to > Bridge > MIB and PW MIB) > - traps for high-water and low-mater mark: suggest removing these > (there > isn't such a thing in Bridge MIB either) > > Regards, > Anil > > > > > > Shane Amante > oint.net> cc: > Subject: L2VPN Agenda > for IETF 66 > 07/05/2006 > 11:17 AM > > > > > > > The agenda for the upcoming meeting in Montreal is located here, (and > in-line below): > http://www3.ietf.org/proceedings/06jul/agenda/l2vpn.txt > > For those who are presenting at the upcoming meeting, please e-mail > your > slides to Vach & I by no later than noon EST on July 12. > > Thanks, > > -shane & Vach > > > ---cut here--- > > IETF 66: Layer 2 Virtual Private Network WG (l2vpn) Agenda > > Thursday, July 13, 2006, 1510-1610 > ================================== > > Chairs: Vach Kompella > Shane Amante > > 1) Administrivia > - Mailing list: http://www.ietf.org/mail-archive/web/l2vpn/ > index.html > - Scribe? > - Blue Sheets > - Agenda Bashing > > 2) WG Status and Update > Chairs > 10 mins > > 3) Virtual Private Lan Services (VPLS) Management Information Base > http://www.ietf.org/internet-drafts/draft-nadeau-l2vpn-vpls-mib-00.txt > Tom Nadeau (tnadeau@cisco.com) > 10 mins > > 4) PIM Snooping over VPLS > http://www.ietf.org/internet-drafts/draft-hemige-serbest-l2vpn-vpls- > pim-snooping-01.txt > > Venu Hemige (venu.hemige@alcatel.com) > 10 mins > > 5) Meeting Closes > > > > > > The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or administrator@tataelxsi.co.in From l2vpn-bounces@ietf.org Sat Jul 08 22:06:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzOh2-0006iC-63; Sat, 08 Jul 2006 22:06:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzOh0-0006i1-Et for l2vpn@ietf.org; Sat, 08 Jul 2006 22:06:42 -0400 Received: from mail2.zte.com.cn ([202.103.147.144] helo=Riskfilter2.zte.com.cn) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzOgu-0006en-8z for l2vpn@ietf.org; Sat, 08 Jul 2006 22:06:42 -0400 Received: from [10.30.1.239] by 10.30.2.249 with StormMail ESMTP id 4627.1467280226; Sun, 9 Jul 2006 10:24:00 +0800 (CST) In-Reply-To: <000201c6a2b5$165494e0$7781110a@telxsi.com> To: Jayanta Tewari MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.4 June 01, 2004 Message-ID: From: jin.lizhong@zte.com.cn Date: Sun, 9 Jul 2006 09:31:04 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2006-07-09 10:06:03, Serialize complete at 2006-07-09 10:06:03 Content-Type: multipart/alternative; boundary="=_alternative 00087312482571A6_=" X-Spam-Score: 4.5 (++++) X-Scan-Signature: 90e8b0e368115979782f8b3d811b226b Cc: l2vpn@ietf.org, 'Shane Amante' Subject: RE: [L2VPN] comments on VPLS MIB X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org This is a multipart message in MIME format. --=_alternative 00087312482571A6_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SXQgbWF5IGJlIG1vcmUgb3B0aW1pemVkIHRvIG1lcmdlIFZQV1MgYW5kIFZQTFMgdG8gb25lIE1J Qi4NCg0KUGxzLiBzZWUgbXkgY29tbWVudHMgYmVsb3cgc3RhcnRpbmcgd2l0aCBKaW4ubGl6aG9u Zy4NCg0KDQoNCg0KDQpKYXlhbnRhIFRld2FyaSA8amF5YW50YUB0YXRhZWx4c2kuY28uaW4+DQoN CjIwMDYtMDctMDkgMDE6MzYNCiANCiAgICAgICAgytW8/sjLo7ogICAgICAgICInU2hhbmUgQW1h bnRlJyIgPHNoYW5lQGNhc3RsZXBvaW50Lm5ldD4sIA0KPGwydnBuQGlldGYub3JnPg0KICAgICAg ICCzrcvNo7ogDQogICAgICAgINb3zOKjuiAgUkU6IFtMMlZQTl0gY29tbWVudHMgb24gVlBMUyBN SUINCg0KDQpTaG91bGQgbm90IHRoZXJlIGJlIG9iamVjdHMgdG8gZGlzdGluZ3Vpc2ggYmV0d2Vl biBxdWFsaWZpZWQgYW5kIA0KdW5xdWFsaWZpZWQNCmxlYXJuaW5nIG1ldGhvZHMgZm9yIFZpcnR1 YWwgc3dpdGNoIGluc3RhbmNlcyA/DQoNClJlZmVyaW5nIHRvIDQuMix3aWxsIGl0IGJlIHBvc3Np YmxlIHRvIGtlZXAgbGFiZWwgaW5mb3JtYXRpb24gdGhyb3VnaCANCkJSSURHRQ0KTUlCIHdpdGgg cmVzcGVjdCB0byBsZWFybmluZyBwcm9jZXNzZXMgKGFzIGl0IG1pZ2h0IG1hcCB0byBpbnRlcmZh Y2VzIG9yDQpsYWJlbC5SaWdodCA/KVdoYXQgYWJvdXQgYSB0YWJsZSByZWxhdGVkIHRvIE1hYyBs ZWFybmluZyBpbiB0aGlzIE1JQiANCml0c2VsZg0KPw0KDQpKaW4ubGl6aG9uZzogTWFjIGxlYXJu aW5nIHBhcmFtZXRlcnMgY2FuIGJlIHB1dCBpbiB0aGUgQlJJREdFIE1JQiwgZm9yIA0KYnJpZGdl DQptb2R1bGUgcGVyZm9ybXMgdGhlIE1hYyBsZWFybmluZyBjYXBhYmlsaXRpZXMuIFdoaWxlIGxh YmVsIGluZm9ybWF0aW9uIGNhbiANCmJlDQpwdXQgaW4gdGhlIHB3VGFibGUgZGVzY3JpYmVkIGlu IFtQVy1NSUJdLiBNYXliZSBCUklER0UgTUlCIGNhbiBiZSBjaGFuZ2VkIA0KdG8gDQphIGJyaWRn ZSB0YWJsZSBpbiBbVlBMUy1NSUJdLCBhbmQgaXMgbm90IG5lY2Vzc2FyeSB0byBiZSBhIHNlcGVy YXRlIE1JQi4NCg0KDQpQbHMuIHNlZSBvdGhlciBjb21tZW50cyBiZWxvdyBzdGFydGluZyB3aXRo IEpULg0KDQpyZ2RzLA0KLS1KYXlhbnRhDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBTaGFuZSBBbWFudGUgW21haWx0bzpzaGFuZUBjYXN0bGVwb2ludC5uZXRdDQpTZW50OiBT YXR1cmRheSwgSnVseSAwOCwgMjAwNiA3OjQyIFBNDQpUbzogbDJ2cG5AaWV0Zi5vcmcNClN1Ympl Y3Q6IEZ3ZDogW0wyVlBOXSBjb21tZW50cyBvbiBWUExTIE1JQg0KDQoNCkZvcndhcmRpbmcgdG8g dGhlIGxpc3Qgb24gYmVoYWxmIG9mIEFuaWwuDQoNCi1zaGFuZQ0KDQoNCkJlZ2luIGZvcndhcmRl ZCBtZXNzYWdlOg0KPiBGcm9tOiBhbmlsckBhY2N0b24uY29tDQo+IERhdGU6IEp1bHkgNywgMjAw NiAxMDo1Mjo1NSBBTSBNRFQNCj4gVG86IFNoYW5lIEFtYW50ZSA8c2hhbmVAY2FzdGxlcG9pbnQu bmV0PiwgdG5hZGVhdUBjaXNjby5jb20NCj4gU3ViamVjdDogRndkOiBbTDJWUE5dIGNvbW1lbnRz IG9uIFZQTFMgTUlCDQo+DQo+IFNoYW5lLCBUb20sDQo+DQo+IEZvciBzb21lIHJlYXNvbiwgbXkg bWFpbCBib3VuY2VzIG9mZiB0aGUgbDJ2cG4gbGlzdC4NCj4NCj4gUGxlYXNlIGZvcndhcmQgaXQg aWYgeW91IGNvdWxkLCBmb3IgY29uc2lkZXJhdGlvbiBhdCB0aGUgbWVldGluZy4NCj4NCj4gUmVn YXJkcywNCj4gQW5pbA0KPg0KPiAtLS0tLSBGb3J3YXJkZWQgYnkgQW5pbCBSaWpoc2luZ2hhbmkv QWNjdG9uVVMgb24gMDcvMDcvMjAwNiAxMjozOQ0KPiBQTSAtLS0tLQ0KPg0KPiAgICAgICAgICAg ICAgICAgICAgIEFuaWwNCj4gICAgICAgICAgICAgICAgICAgICBSaWpoc2luZ2hhbmkgICAgICAg ICBUbzogICAgIHRuYWRlYXVAY2lzY28uY29tDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgY2M6ICAgICBsMnZwbkBpZXRmLm9yZw0KPiAgICAgICAgICAgICAgICAg ICAgIDA3LzA1LzIwMDYgICAgICAgICAgIFN1YmplY3Q6ICAgICBjb21tZW50cyBvbg0KPiBWUExT IE1JQihEb2N1bWVudCBsaW5rOiBBbmlsIFJpamhzaW5naGFuaSkNCj4gICAgICAgICAgICAgICAg ICAgICAwMToyNyBQTQ0KPg0KPg0KPg0KPg0KPg0KPiBUb20sDQo+DQo+IEkgd2FzIHByZXBhcmlu ZyB0byBzZW5kIGluIGEgY29udHJpYnV0aW9uIGZvciBWUExTIE1JQiwgYmVmb3JlIEkNCj4gc2F3 IHlvdXJzDQo+IG9uIHRoZSBhZ2VuZGEuDQo+DQo+IFNvbWUgaW5pdGlhbCBjb21tZW50cy9xdWVz dGlvbnMgb24gdGhlIE1JQjoNCj4NCj4gLSB0YWJsZSBvZiBjb250ZW50cyBlaXRoZXIgbm90IHVw ZGF0ZWQsIG9yIHNvbWUgcGllY2Ugb2YgdGhlIE1JQg0KPiBtaXNzaW5nPw0KPiAocGFnZSBudW1i ZXJzKQ0KPiAtIEkgYXNzdW1lIHRoaXMgb25seSBjb252ZXJzIHRoZSBMRFAgbWV0aG9kOyBpZiBz byBwZXJoYXBzIG1lbnRpb24gaW4NCj4gYWJzdHJhY3QNCj4gLSBuZWVkIGFuIG9wdGlvbmFsIHN0 YXRpYyB0YWJsZSB0byBtYW51YWxseSBjb25maWd1cmUgVlBMUyBwZWVycw0KPiAtIHdoYXQgZm9y bXMgb2YgYXV0by1kaXNjb3ZlcnkgaW4gdnBsc1B3QmluZEJpbmRUeXBlLCBjYW4gdGhlc2UgYmUN Cj4gbGlzdGVkDQo+IGFzIHR5cGVzPw0KPiAtIHZwbHNNYWNMZWFybmluZzogd2h5IGlzIHRoaXMg bmVlZGVkPyAoY29ycmVzcG9uZGluZyBmdW5jdGlvbiBub3QNCj4gZGVzY3JpYmVkIGluIFZQTFMg ZG9jdW1lbnQpDQo+IC0gdnBsc0Rpc2NhcmRVbmtub3duRGVzdDogd2h5IG5lZWRlZD8gKGRpdHRv KQ0KPiAtIHZwbE1hY0FnaW5nOiB3aHkgbmVlZGVkPyAoZGl0dG8pDQoNCkpUOkkgZ3Vlc3MgdGhl c2UgY29ycmVzcG9uZCB0byBzZWN0aW9ucyA0LjIsNi4yLDkuMSBldGMuDQpkcmFmdC1pZXRmLWwy dnBuLXZwbHMtbGRwLTA4LnR4dC4NCg0KPiAtIG9iamVjdCBuZWVkZWQgZm9yIFZQTFMgTVRVDQo+ IC0gb2JqZWN0IG5lZWRlZCBmb3IgaW5mb3JtYXRpb24gb24gSFZQTFMgU3Bva2UgY29ubmVjdGlv biAoZWcsDQo+IGNvcnJlbGF0aW9uDQo+IHRvIFEtaW4tUSkNCkpUOklzIHRoZXJlIGFueXRoaW5n IHNwZWNpYWwgIG5lZWRlZCBmb3IgSFZQTFMgYXJjaGl0ZWN1cmUgYXMgdGhlIHNwb2tlcw0Kd2ls bCBmb2xsb3cgbm9ybWFsIEwyIHRlY2hub2xpZ2llcyBhbmQgd2lsbCBrZWVwIHRoZSByZWxhdGVk IGluZm9ybWF0aW9uIA0KaW4NCmFscmVhZHkgZGV2ZWxvcGVkIE1JQnMgZm9yIHRoZW0gPw0KDQpK aW4ubGl6aG9uZzpJdCBpcyBuZWNlc3NhcnkgdG8gYWRkIFNQT0tFIHByb3BlcnR5IHRvIHRoZSBN SUIuIFRoZXJlIGFyZSANCnNvbWUNCm90aGVyIHByb3BlcnRpZXMgdGhhdCBzcGVjaWFsIGZvciBW UExTIGFuZCBjYW4gbm90IGJlIGRlc2NyaWJlZCBpbiANCltQVy1NSUJdLiBGb3INCmluc3RhbmNl LCBwdyBiYWNrdXAgaW5mb3JtYXRpb24sIHB3IFNUUCBpbmZvcm1hdGlvbiwgcHcgU05PT1BJTkcg DQppbmZvcm1hdGlvbiwgZXRjLg0KU28gaW4gW1ZQTFMtTUlCXSwgYWRkaXRpb25hbCBwdyBpbmZv cm1hdGlvbiBzaG91bGQgYmUgYWRkZWQsIGFuZCBhIA0KbDJ2cG5Qd1RhYmxlDQptYXkgYmUgbmVl ZGVkLg0KDQo+IC0gb2JqZWN0IHRvIGNvcnJlbGF0ZSB0aGUgaW50ZXJmYWNlIG9uIHdoaWNoIGEg VlBMUyBpbnN0YW5jZSBpcw0KPiBydW5uaW5nDQo+IHdvdWxkIGJlIHVzZWZ1bCwgd2hpY2ggaW4g dHVybiB0aWVzIGludG8gTUFDIGFkZHJlc3MgYmFzZWQgb24gaWZUYWJsZQ0KPiAtIHVwLWZyb250 IHRleHQgdG8gZGVzY3JpYmUgcmVsYXRpb25zaGlwIHRvIGlmVGFibGUgKGluIGFkZGl0aW9uIHRv DQo+IEJyaWRnZQ0KPiBNSUIgYW5kIFBXIE1JQikNCj4gLSB0cmFwcyBmb3IgaGlnaC13YXRlciBh bmQgbG93LW1hdGVyIG1hcms6IHN1Z2dlc3QgcmVtb3ZpbmcgdGhlc2UNCj4gKHRoZXJlDQo+IGlz bid0IHN1Y2ggYSB0aGluZyBpbiBCcmlkZ2UgTUlCIGVpdGhlcikNCj4NCj4gUmVnYXJkcywNCj4g QW5pbA0KPg0KPg0KPg0KPg0KPg0KPiAgICAgICAgICAgICAgICAgICAgIFNoYW5lIEFtYW50ZQ0K PiAgICAgICAgICAgICAgICAgICAgIDxzaGFuZUBjYXN0bGVwICAgICAgIFRvOiAgICAgbDJ2cG5A aWV0Zi5vcmcNCj4gICAgICAgICAgICAgICAgICAgICBvaW50Lm5ldD4gICAgICAgICAgICBjYzoN Cj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTdWJqZWN0OiAgICAg TDJWUE4gQWdlbmRhDQo+IGZvciBJRVRGIDY2DQo+ICAgICAgICAgICAgICAgICAgICAgMDcvMDUv MjAwNg0KPiAgICAgICAgICAgICAgICAgICAgIDExOjE3IEFNDQo+DQo+DQo+DQo+DQo+DQo+DQo+ IFRoZSBhZ2VuZGEgZm9yIHRoZSB1cGNvbWluZyBtZWV0aW5nIGluIE1vbnRyZWFsIGlzIGxvY2F0 ZWQgaGVyZSwgKGFuZA0KPiBpbi1saW5lIGJlbG93KToNCj4gaHR0cDovL3d3dzMuaWV0Zi5vcmcv cHJvY2VlZGluZ3MvMDZqdWwvYWdlbmRhL2wydnBuLnR4dA0KPg0KPiBGb3IgdGhvc2Ugd2hvIGFy ZSBwcmVzZW50aW5nIGF0IHRoZSB1cGNvbWluZyBtZWV0aW5nLCBwbGVhc2UgZS1tYWlsDQo+IHlv dXINCj4gc2xpZGVzIHRvIFZhY2ggJiBJIGJ5IG5vIGxhdGVyIHRoYW4gbm9vbiBFU1Qgb24gSnVs eSAxMi4NCj4NCj4gVGhhbmtzLA0KPg0KPiAtc2hhbmUgJiBWYWNoDQo+DQo+DQo+IC0tLWN1dCBo ZXJlLS0tDQo+DQo+IElFVEYgNjY6IExheWVyIDIgVmlydHVhbCBQcml2YXRlIE5ldHdvcmsgV0cg KGwydnBuKSBBZ2VuZGENCj4NCj4gVGh1cnNkYXksIEp1bHkgMTMsIDIwMDYsIDE1MTAtMTYxMA0K PiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+DQo+IENoYWlyczogVmFjaCBL b21wZWxsYQ0KPiAgICAgICAgICBTaGFuZSBBbWFudGUNCj4NCj4gMSkgQWRtaW5pc3RyaXZpYQ0K PiAgICAgLSBNYWlsaW5nIGxpc3Q6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dl Yi9sMnZwbi8NCj4gaW5kZXguaHRtbA0KPiAgICAgLSBTY3JpYmU/DQo+ICAgICAtIEJsdWUgU2hl ZXRzDQo+ICAgICAtIEFnZW5kYSBCYXNoaW5nDQo+DQo+IDIpIFdHIFN0YXR1cyBhbmQgVXBkYXRl DQo+ICAgICBDaGFpcnMNCj4gICAgIDEwIG1pbnMNCj4NCj4gMykgVmlydHVhbCBQcml2YXRlIExh biBTZXJ2aWNlcyAoVlBMUykgTWFuYWdlbWVudCBJbmZvcm1hdGlvbiBCYXNlDQo+IGh0dHA6Ly93 d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LW5hZGVhdS1sMnZwbi12cGxzLW1pYi0w MC50eHQNCj4gICAgIFRvbSBOYWRlYXUgKHRuYWRlYXVAY2lzY28uY29tKQ0KPiAgICAgMTAgbWlu cw0KPg0KPiA0KSBQSU0gU25vb3Bpbmcgb3ZlciBWUExTDQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWhlbWlnZS1zZXJiZXN0LWwydnBuLXZwbHMtDQo+IHBpbS1z bm9vcGluZy0wMS50eHQNCj4NCj4gICAgIFZlbnUgSGVtaWdlICh2ZW51LmhlbWlnZUBhbGNhdGVs LmNvbSkNCj4gICAgIDEwIG1pbnMNCj4NCj4gNSkgTWVldGluZyBDbG9zZXMNCj4NCj4NCj4NCj4N Cj4NCj4NCg0KDQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgZWxlY3Ryb25pYyBt ZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgDQp0byB0aGlzIG1lc3NhZ2UgYXJlIGludGVuZGVk IGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpYW5kIA0KbWF5IGNvbnRh aW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24uIElmIHlvdSBhcmUgbm90 IHRoZSANCmludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIG9yIA0K YWRtaW5pc3RyYXRvckB0YXRhZWx4c2kuY28uaW4NCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2Vj dXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyAN CnNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwg Y29tbXVuaWNhdGlvbiBpcyANCmNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBh cmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIA0KYXJlIG5vdCBwZXJtaXR0ZWQg dG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byANCm90aGVy cy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25m aWRlbnRpYWwgYW5kIGludGVuZGVkIA0Kc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlk dWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gDQpJZiB5b3UgaGF2ZSBy ZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Ig b2YgDQp0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJl IHRob3NlIG9mIHRoZSANCmluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVu IHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSANCnN5c3RlbS4N Cg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlv biBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVy J3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwu IFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5 IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBj b21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21p dHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhl IHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNz ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlm eSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0 aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVz c2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNw YW0gc3lzdGVtLg0K --=_alternative 00087312482571A6_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5JdCBtYXkgYmUgbW9yZSBvcHRpbWl6ZWQgdG8gbWVyZ2Ug VlBXUyBhbmQgVlBMUyB0bw0Kb25lIE1JQi48L3R0PjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTI+PHR0PlBscy4gc2VlIG15IGNvbW1lbnRzIGJlbG93IHN0YXJ0aW5nIHdpdGggSmluLmxp emhvbmcuPC90dD48L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjwv Zm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPkpheWFudGEg VGV3YXJpICZsdDtqYXlhbnRhQHRhdGFlbHhzaS5jby5pbiZndDs8L2I+PC9mb250Pg0KPGJyPg0K PHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMDYtMDctMDkgMDE6MzY8L2ZvbnQ+ DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgytW8/sjLo7oNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZx dW90OydTaGFuZSBBbWFudGUnJnF1b3Q7ICZsdDtzaGFuZUBjYXN0bGVwb2ludC5uZXQmZ3Q7LA0K Jmx0O2wydnBuQGlldGYub3JnJmd0OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ILOty82jug0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg1vfM4qO6DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtSRTogW0wyVlBOXSBjb21tZW50cyBvbiBWUExTIE1JQjwvZm9udD48L3RhYmxlPg0K PGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+U2hvdWxkIG5vdCB0aGVyZSBiZSBvYmpl Y3RzIHRvIGRpc3Rpbmd1aXNoIGJldHdlZW4NCnF1YWxpZmllZCBhbmQgdW5xdWFsaWZpZWQ8YnI+ DQpsZWFybmluZyBtZXRob2RzIGZvciBWaXJ0dWFsIHN3aXRjaCBpbnN0YW5jZXMgPzxicj4NCjxi cj4NClJlZmVyaW5nIHRvIDQuMix3aWxsIGl0IGJlIHBvc3NpYmxlIHRvIGtlZXAgbGFiZWwgaW5m b3JtYXRpb24gdGhyb3VnaCBCUklER0U8YnI+DQpNSUIgd2l0aCByZXNwZWN0IHRvIGxlYXJuaW5n IHByb2Nlc3NlcyAoYXMgaXQgbWlnaHQgbWFwIHRvIGludGVyZmFjZXMgb3I8YnI+DQpsYWJlbC5S aWdodCA/KVdoYXQgYWJvdXQgYSB0YWJsZSByZWxhdGVkIHRvIE1hYyBsZWFybmluZyBpbiB0aGlz IE1JQiBpdHNlbGY8YnI+DQo/PGJyPg0KPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0 dD48Yj5KaW4ubGl6aG9uZzo8L2I+IE1hYyBsZWFybmluZyBwYXJhbWV0ZXJzIGNhbiBiZQ0KcHV0 IGluIHRoZSBCUklER0UgTUlCLCBmb3IgYnJpZGdlPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yPjx0dD5tb2R1bGUgcGVyZm9ybXMgdGhlIE1hYyBsZWFybmluZyBjYXBhYmlsaXRpZXMuIFdo aWxlDQpsYWJlbCBpbmZvcm1hdGlvbiBjYW4gYmU8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXpl PTI+PHR0PnB1dCBpbiB0aGUgcHdUYWJsZSBkZXNjcmliZWQgaW4gW1BXLU1JQl0uIE1heWJlIEJS SURHRQ0KTUlCIGNhbiBiZSBjaGFuZ2VkIHRvIDwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9 Mj48dHQ+YSBicmlkZ2UgdGFibGUgaW4gW1ZQTFMtTUlCXSwgYW5kIGlzIG5vdCBuZWNlc3NhcnkN CnRvIGJlIGEgc2VwZXJhdGUgTUlCLjwvdHQ+PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9 Mj48dHQ+PGJyPg0KUGxzLiBzZWUgb3RoZXIgY29tbWVudHMgYmVsb3cgc3RhcnRpbmcgd2l0aCBK VC48YnI+DQo8YnI+DQpyZ2RzLDxicj4NCi0tSmF5YW50YTxicj4NCjxicj4NCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogU2hhbmUgQW1hbnRlIFttYWlsdG86c2hhbmVAY2Fz dGxlcG9pbnQubmV0XTxicj4NClNlbnQ6IFNhdHVyZGF5LCBKdWx5IDA4LCAyMDA2IDc6NDIgUE08 YnI+DQpUbzogbDJ2cG5AaWV0Zi5vcmc8YnI+DQpTdWJqZWN0OiBGd2Q6IFtMMlZQTl0gY29tbWVu dHMgb24gVlBMUyBNSUI8YnI+DQo8YnI+DQo8YnI+DQpGb3J3YXJkaW5nIHRvIHRoZSBsaXN0IG9u IGJlaGFsZiBvZiBBbmlsLjxicj4NCjxicj4NCi1zaGFuZTxicj4NCjxicj4NCjxicj4NCkJlZ2lu IGZvcndhcmRlZCBtZXNzYWdlOjxicj4NCiZndDsgRnJvbTogYW5pbHJAYWNjdG9uLmNvbTxicj4N CiZndDsgRGF0ZTogSnVseSA3LCAyMDA2IDEwOjUyOjU1IEFNIE1EVDxicj4NCiZndDsgVG86IFNo YW5lIEFtYW50ZSAmbHQ7c2hhbmVAY2FzdGxlcG9pbnQubmV0Jmd0OywgdG5hZGVhdUBjaXNjby5j b208YnI+DQomZ3Q7IFN1YmplY3Q6IEZ3ZDogW0wyVlBOXSBjb21tZW50cyBvbiBWUExTIE1JQjxi cj4NCiZndDs8YnI+DQomZ3Q7IFNoYW5lLCBUb20sPGJyPg0KJmd0Ozxicj4NCiZndDsgRm9yIHNv bWUgcmVhc29uLCBteSBtYWlsIGJvdW5jZXMgb2ZmIHRoZSBsMnZwbiBsaXN0Ljxicj4NCiZndDs8 YnI+DQomZ3Q7IFBsZWFzZSBmb3J3YXJkIGl0IGlmIHlvdSBjb3VsZCwgZm9yIGNvbnNpZGVyYXRp b24gYXQgdGhlIG1lZXRpbmcuPGJyPg0KJmd0Ozxicj4NCiZndDsgUmVnYXJkcyw8YnI+DQomZ3Q7 IEFuaWw8YnI+DQomZ3Q7PGJyPg0KJmd0OyAtLS0tLSBGb3J3YXJkZWQgYnkgQW5pbCBSaWpoc2lu Z2hhbmkvQWNjdG9uVVMgb24gMDcvMDcvMjAwNiAxMjozOTxicj4NCiZndDsgUE0gLS0tLS08YnI+ DQomZ3Q7PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCkFuaWw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw Ow0KUmlqaHNpbmdoYW5pICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBUbzogJm5ic3A7ICZu YnNwOyB0bmFkZWF1QGNpc2NvLmNvbTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7Y2M6DQombmJzcDsgJm5ic3A7IGwydnBuQGlldGYub3JnPGJyPg0KJmd0OyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsNCjA3LzA1LzIwMDYgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBT dWJqZWN0OiAmbmJzcDsgJm5ic3A7IGNvbW1lbnRzDQpvbjxicj4NCiZndDsgVlBMUyBNSUIoRG9j dW1lbnQgbGluazogQW5pbCBSaWpoc2luZ2hhbmkpPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCjAx OjI3IFBNPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8 YnI+DQomZ3Q7IFRvbSw8YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIHdhcyBwcmVwYXJpbmcgdG8gc2Vu ZCBpbiBhIGNvbnRyaWJ1dGlvbiBmb3IgVlBMUyBNSUIsIGJlZm9yZSBJPGJyPg0KJmd0OyBzYXcg eW91cnM8YnI+DQomZ3Q7IG9uIHRoZSBhZ2VuZGEuPGJyPg0KJmd0Ozxicj4NCiZndDsgU29tZSBp bml0aWFsIGNvbW1lbnRzL3F1ZXN0aW9ucyBvbiB0aGUgTUlCOjxicj4NCiZndDs8YnI+DQomZ3Q7 IC0gdGFibGUgb2YgY29udGVudHMgZWl0aGVyIG5vdCB1cGRhdGVkLCBvciBzb21lIHBpZWNlIG9m IHRoZSBNSUI8YnI+DQomZ3Q7IG1pc3Npbmc/PGJyPg0KJmd0OyAocGFnZSBudW1iZXJzKTxicj4N CiZndDsgLSBJIGFzc3VtZSB0aGlzIG9ubHkgY29udmVycyB0aGUgTERQIG1ldGhvZDsgaWYgc28g cGVyaGFwcyBtZW50aW9uDQppbjxicj4NCiZndDsgYWJzdHJhY3Q8YnI+DQomZ3Q7IC0gbmVlZCBh biBvcHRpb25hbCBzdGF0aWMgdGFibGUgdG8gbWFudWFsbHkgY29uZmlndXJlIFZQTFMgcGVlcnM8 YnI+DQomZ3Q7IC0gd2hhdCBmb3JtcyBvZiBhdXRvLWRpc2NvdmVyeSBpbiB2cGxzUHdCaW5kQmlu ZFR5cGUsIGNhbiB0aGVzZSBiZTxicj4NCiZndDsgbGlzdGVkPGJyPg0KJmd0OyBhcyB0eXBlcz88 YnI+DQomZ3Q7IC0gdnBsc01hY0xlYXJuaW5nOiB3aHkgaXMgdGhpcyBuZWVkZWQ/IChjb3JyZXNw b25kaW5nIGZ1bmN0aW9uIG5vdDxicj4NCiZndDsgZGVzY3JpYmVkIGluIFZQTFMgZG9jdW1lbnQp PGJyPg0KJmd0OyAtIHZwbHNEaXNjYXJkVW5rbm93bkRlc3Q6IHdoeSBuZWVkZWQ/IChkaXR0byk8 YnI+DQomZ3Q7IC0gdnBsTWFjQWdpbmc6IHdoeSBuZWVkZWQ/IChkaXR0byk8YnI+DQo8YnI+DQpK VDpJIGd1ZXNzIHRoZXNlIGNvcnJlc3BvbmQgdG8gc2VjdGlvbnMgNC4yLDYuMiw5LjEgZXRjLjxi cj4NCmRyYWZ0LWlldGYtbDJ2cG4tdnBscy1sZHAtMDgudHh0Ljxicj4NCjxicj4NCiZndDsgLSBv YmplY3QgbmVlZGVkIGZvciBWUExTIE1UVTxicj4NCiZndDsgLSBvYmplY3QgbmVlZGVkIGZvciBp bmZvcm1hdGlvbiBvbiBIVlBMUyBTcG9rZSBjb25uZWN0aW9uIChlZyw8YnI+DQomZ3Q7IGNvcnJl bGF0aW9uPGJyPg0KJmd0OyB0byBRLWluLVEpPGJyPg0KSlQ6SXMgdGhlcmUgYW55dGhpbmcgc3Bl Y2lhbCAmbmJzcDtuZWVkZWQgZm9yIEhWUExTIGFyY2hpdGVjdXJlIGFzIHRoZQ0Kc3Bva2VzPGJy Pg0Kd2lsbCBmb2xsb3cgbm9ybWFsIEwyIHRlY2hub2xpZ2llcyBhbmQgd2lsbCBrZWVwIHRoZSBy ZWxhdGVkIGluZm9ybWF0aW9uDQppbjxicj4NCmFscmVhZHkgZGV2ZWxvcGVkIE1JQnMgZm9yIHRo ZW0gPzwvdHQ+PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+PGI+SmluLmxpemhv bmc6PC9iPkl0IGlzIG5lY2Vzc2FyeSB0byBhZGQgU1BPS0UgcHJvcGVydHkNCnRvIHRoZSBNSUIu IFRoZXJlIGFyZSBzb21lPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5vdGhlciBw cm9wZXJ0aWVzIHRoYXQgc3BlY2lhbCBmb3IgVlBMUyBhbmQgY2FuIG5vdA0KYmUgZGVzY3JpYmVk IGluIFtQVy1NSUJdLiBGb3I8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0Pmluc3Rh bmNlLCBwdyBiYWNrdXAgaW5mb3JtYXRpb24sIHB3IFNUUCBpbmZvcm1hdGlvbiwNCnB3IFNOT09Q SU5HIGluZm9ybWF0aW9uLCBldGMuPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5T byBpbiBbVlBMUy1NSUJdLCBhZGRpdGlvbmFsIHB3IGluZm9ybWF0aW9uIHNob3VsZA0KYmUgYWRk ZWQsIGFuZCBhIGwydnBuUHdUYWJsZTwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+ bWF5IGJlIG5lZWRlZC48L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0Pjxicj4NCiZn dDsgLSBvYmplY3QgdG8gY29ycmVsYXRlIHRoZSBpbnRlcmZhY2Ugb24gd2hpY2ggYSBWUExTIGlu c3RhbmNlIGlzPGJyPg0KJmd0OyBydW5uaW5nPGJyPg0KJmd0OyB3b3VsZCBiZSB1c2VmdWwsIHdo aWNoIGluIHR1cm4gdGllcyBpbnRvIE1BQyBhZGRyZXNzIGJhc2VkIG9uIGlmVGFibGU8YnI+DQom Z3Q7IC0gdXAtZnJvbnQgdGV4dCB0byBkZXNjcmliZSByZWxhdGlvbnNoaXAgdG8gaWZUYWJsZSAo aW4gYWRkaXRpb24gdG88YnI+DQomZ3Q7IEJyaWRnZTxicj4NCiZndDsgTUlCIGFuZCBQVyBNSUIp PGJyPg0KJmd0OyAtIHRyYXBzIGZvciBoaWdoLXdhdGVyIGFuZCBsb3ctbWF0ZXIgbWFyazogc3Vn Z2VzdCByZW1vdmluZyB0aGVzZTxicj4NCiZndDsgKHRoZXJlPGJyPg0KJmd0OyBpc24ndCBzdWNo IGEgdGhpbmcgaW4gQnJpZGdlIE1JQiBlaXRoZXIpPGJyPg0KJmd0Ozxicj4NCiZndDsgUmVnYXJk cyw8YnI+DQomZ3Q7IEFuaWw8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7 PGJyPg0KJmd0Ozxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpTaGFuZSBBbWFudGU8YnI+DQomZ3Q7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOw0KJmx0O3NoYW5lQGNhc3RsZXAgJm5ic3A7ICZuYnNwOyAmbmJzcDsgVG86 ICZuYnNwOyAmbmJzcDsgbDJ2cG5AaWV0Zi5vcmc8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0Kb2lu dC5uZXQmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y2M6PGJy Pg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtTdWJqZWN0Og0KJm5ic3A7 ICZuYnNwOyBMMlZQTiBBZ2VuZGE8YnI+DQomZ3Q7IGZvciBJRVRGIDY2PGJyPg0KJmd0OyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsNCjA3LzA1LzIwMDY8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KMTE6MTcgQU08YnI+ DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8 YnI+DQomZ3Q7IFRoZSBhZ2VuZGEgZm9yIHRoZSB1cGNvbWluZyBtZWV0aW5nIGluIE1vbnRyZWFs IGlzIGxvY2F0ZWQgaGVyZSwgKGFuZDxicj4NCiZndDsgaW4tbGluZSBiZWxvdyk6PGJyPg0KJmd0 OyBodHRwOi8vd3d3My5pZXRmLm9yZy9wcm9jZWVkaW5ncy8wNmp1bC9hZ2VuZGEvbDJ2cG4udHh0 PGJyPg0KJmd0Ozxicj4NCiZndDsgRm9yIHRob3NlIHdobyBhcmUgcHJlc2VudGluZyBhdCB0aGUg dXBjb21pbmcgbWVldGluZywgcGxlYXNlIGUtbWFpbDxicj4NCiZndDsgeW91cjxicj4NCiZndDsg c2xpZGVzIHRvIFZhY2ggJmFtcDsgSSBieSBubyBsYXRlciB0aGFuIG5vb24gRVNUIG9uIEp1bHkg MTIuPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhhbmtzLDxicj4NCiZndDs8YnI+DQomZ3Q7IC1zaGFu ZSAmYW1wOyBWYWNoPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IC0tLWN1dCBoZXJlLS0t PGJyPg0KJmd0Ozxicj4NCiZndDsgSUVURiA2NjogTGF5ZXIgMiBWaXJ0dWFsIFByaXZhdGUgTmV0 d29yayBXRyAobDJ2cG4pIEFnZW5kYTxicj4NCiZndDs8YnI+DQomZ3Q7IFRodXJzZGF5LCBKdWx5 IDEzLCAyMDA2LCAxNTEwLTE2MTA8YnI+DQomZ3Q7ID09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT08YnI+DQomZ3Q7PGJyPg0KJmd0OyBDaGFpcnM6IFZhY2ggS29tcGVsbGE8YnI+DQom Z3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtTaGFuZSBBbWFudGU8YnI+DQom Z3Q7PGJyPg0KJmd0OyAxKSBBZG1pbmlzdHJpdmlhPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IC0g TWFpbGluZyBsaXN0OiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbDJ2cG4v PGJyPg0KJmd0OyBpbmRleC5odG1sPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IC0gU2NyaWJlPzxi cj4NCiZndDsgJm5ic3A7ICZuYnNwOyAtIEJsdWUgU2hlZXRzPGJyPg0KJmd0OyAmbmJzcDsgJm5i c3A7IC0gQWdlbmRhIEJhc2hpbmc8YnI+DQomZ3Q7PGJyPg0KJmd0OyAyKSBXRyBTdGF0dXMgYW5k IFVwZGF0ZTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBDaGFpcnM8YnI+DQomZ3Q7ICZuYnNwOyAm bmJzcDsgMTAgbWluczxicj4NCiZndDs8YnI+DQomZ3Q7IDMpIFZpcnR1YWwgUHJpdmF0ZSBMYW4g U2VydmljZXMgKFZQTFMpIE1hbmFnZW1lbnQgSW5mb3JtYXRpb24gQmFzZTxicj4NCiZndDsgaHR0 cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbmFkZWF1LWwydnBuLXZwbHMt bWliLTAwLnR4dDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBUb20gTmFkZWF1ICh0bmFkZWF1QGNp c2NvLmNvbSk8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgMTAgbWluczxicj4NCiZndDs8YnI+DQom Z3Q7IDQpIFBJTSBTbm9vcGluZyBvdmVyIFZQTFM8YnI+DQomZ3Q7IGh0dHA6Ly93d3cuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWhlbWlnZS1zZXJiZXN0LWwydnBuLXZwbHMtPGJyPg0K Jmd0OyBwaW0tc25vb3BpbmctMDEudHh0PGJyPg0KJmd0Ozxicj4NCiZndDsgJm5ic3A7ICZuYnNw OyBWZW51IEhlbWlnZSAodmVudS5oZW1pZ2VAYWxjYXRlbC5jb20pPGJyPg0KJmd0OyAmbmJzcDsg Jm5ic3A7IDEwIG1pbnM8YnI+DQomZ3Q7PGJyPg0KJmd0OyA1KSBNZWV0aW5nIENsb3Nlczxicj4N CiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxi cj4NCjxicj4NCjxicj4NClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBlbGVjdHJv bmljIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cw0KdG8gdGhpcyBtZXNzYWdlIGFyZSBpbnRl bmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKWFuZA0KbWF5IGNv bnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24uIElmIHlvdSBhcmUg bm90IHRoZQ0KaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgb3Ig YWRtaW5pc3RyYXRvckB0YXRhZWx4c2kuY28uaW48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4N ClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWlu ZWQgaW4gdGhpcyBtYWlsDQppcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2Fu aXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24NCmlzIGNvbmZpZGVudGlhbC4gUmVjaXBp ZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kNCmFuZCBh cmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5p Y2F0aW9uIHRvDQpvdGhlcnMuPGJyPg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0 dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQNCnNvbGVseSBmb3IgdGhl IHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNz ZWQuDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3Rp ZnkgdGhlIG9yaWdpbmF0b3Igb2YNCnRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGlu IHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwNCnNlbmRlci48YnI+DQpU aGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUg QW50aS1TcGFtIHN5c3RlbS48YnI+DQo8L3R0PjwvZm9udD4NCjxicj4NCjxicj48cHJlPg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpU RSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5i c3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWls Jm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7 c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21t dW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNw O25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21h aW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1p dHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29m Jm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMm bmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQm bmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJz cDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29m Jm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJz cDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lv dSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5i c3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9y Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7 ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Ro b3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZu YnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNw O3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNw YW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 00087312482571A6_=-- From l2vpn-bounces@ietf.org Mon Jul 10 16:06:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G021Z-0008Ih-CG; Mon, 10 Jul 2006 16:06:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G021W-0008IA-Ff; Mon, 10 Jul 2006 16:06:30 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G021W-0004mU-EB; Mon, 10 Jul 2006 16:06:30 -0400 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=willow.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G01la-00080y-O3; Mon, 10 Jul 2006 15:50:10 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k6AJo1QC021414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Jul 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G01lZ-0001VG-Lc; Mon, 10 Jul 2006 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: Mon, 10 Jul 2006 15:50:01 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: l2vpn@ietf.org Subject: I-D ACTION:draft-ietf-l2vpn-vpws-iw-oam-01.txt X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 2 Virtual Private Networks Working Group of the IETF. Title : OAM Procedures for VPWS Interworking Author(s) : M. Aissaoui, et al. Filename : draft-ietf-l2vpn-vpws-iw-oam-01.txt Pages : 24 Date : 2006-7-10 This draft proposes OAM procedures for the Ethernet interworking, IP interworking and FR-ATM interworking Virtual Private Wire Service (VPWS). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpws-iw-oam-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-l2vpn-vpws-iw-oam-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-l2vpn-vpws-iw-oam-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-7-10131104.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l2vpn-vpws-iw-oam-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l2vpn-vpws-iw-oam-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-7-10131104.I-D@ietf.org> --OtherAccess-- --NextPart-- From l2vpn-bounces@ietf.org Tue Jul 11 20:26:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0SYs-0001wN-MN; Tue, 11 Jul 2006 20:26:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0SYr-0001wI-H7 for l2vpn@ietf.org; Tue, 11 Jul 2006 20:26:41 -0400 Received: from hostreea2.alcatel.com ([143.209.238.162] helo=audl953.usa.alcatel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0SYq-0003Ua-6c for l2vpn@ietf.org; Tue, 11 Jul 2006 20:26:41 -0400 Received: from mvrelay.mv.usa.alcatel.com (mvrelay.mv.usa.alcatel.com [128.251.10.15]) by audl953.usa.alcatel.com (ALCANET) with ESMTP id k6C0QdvD000521 for ; Tue, 11 Jul 2006 19:26:39 -0500 Received: from rmedirattapc (localhost [127.0.0.1]) by mvrelay.mv.usa.alcatel.com (8.12.10/8.12.10) with SMTP id k6C0R7RA020439 for ; Tue, 11 Jul 2006 17:27:07 -0700 (PDT) From: "Rohit Mediratta" To: Date: Tue, 11 Jul 2006 17:27:26 -0700 Message-ID: <04e501c6a549$f5010c00$87dffea9@eng.timetra.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: Importance: Normal X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Subject: RE: [L2VPN] comments on VPLS MIB X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rohit.mediratta@alcatel.com List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org Hi, Please find my comments inline starting with "Rohit:" Regards, Rohit > > Tom, > > I was preparing to send in a contribution for VPLS MIB, before I > saw yours > on the agenda. > > Some initial comments/questions on the MIB: > > - table of contents either not updated, or some piece of the MIB > missing? > (page numbers) > - I assume this only convers the LDP method; if so perhaps mention in > abstract > - need an optional static table to manually configure VPLS peers Rohit: Why would this configuration not be in the PWE3 MIB ? > - what forms of auto-discovery in vplsPwBindBindType, can these be > listed > as types? > - vplsMacLearning: why is this needed? (corresponding function not > described in VPLS document) > - vplsDiscardUnknownDest: why needed? (ditto) > - vplMacAging: why needed? (ditto) Rohit: I believe the above should be included as pointed out in the previous email. > - object needed for VPLS MTU > - object needed for information on HVPLS Spoke connection (eg, > correlation > to Q-in-Q) > - object to correlate the interface on which a VPLS instance is > running > would be useful, which in turn ties into MAC address based on ifTable > - up-front text to describe relationship to ifTable (in addition to > Bridge > MIB and PW MIB) > - traps for high-water and low-mater mark: suggest removing these > (there isn't such a thing in Bridge MIB either) Rohit: This is a useful notification feature from a provider perspective. Does anyone disagree ? > > Regards, > Anil > > > > > > Shane Amante > oint.net> cc: > Subject: L2VPN Agenda > for IETF 66 > 07/05/2006 > 11:17 AM > > > > > > > The agenda for the upcoming meeting in Montreal is located here, (and > in-line below): > http://www3.ietf.org/proceedings/06jul/agenda/l2vpn.txt > > For those who are presenting at the upcoming meeting, please e-mail > your > slides to Vach & I by no later than noon EST on July 12. > > Thanks, > > -shane & Vach > > > ---cut here--- > > IETF 66: Layer 2 Virtual Private Network WG (l2vpn) Agenda > > Thursday, July 13, 2006, 1510-1610 > ================================== > > Chairs: Vach Kompella > Shane Amante > > 1) Administrivia > - Mailing list: http://www.ietf.org/mail-archive/web/l2vpn/ > index.html > - Scribe? > - Blue Sheets > - Agenda Bashing > > 2) WG Status and Update > Chairs > 10 mins > > 3) Virtual Private Lan Services (VPLS) Management Information Base > http://www.ietf.org/internet-drafts/draft-nadeau-l2vpn-vpls-mib-00.txt > Tom Nadeau (tnadeau@cisco.com) > 10 mins > > 4) PIM Snooping over VPLS > http://www.ietf.org/internet-drafts/draft-hemige-serbest-l2vpn-vpls- > pim-snooping-01.txt > > Venu Hemige (venu.hemige@alcatel.com) > 10 mins > > 5) Meeting Closes > > > > > > From l2vpn-bounces@ietf.org Thu Jul 13 09:19:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G116G-00053L-Ti; Thu, 13 Jul 2006 09:19:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G116F-00053G-9b for l2vpn@ietf.org; Thu, 13 Jul 2006 09:19:27 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G116E-0003XD-FL for l2vpn@ietf.org; Thu, 13 Jul 2006 09:19:27 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 13 Jul 2006 09:19:25 -0400 X-IronPort-AV: i="4.06,237,1149480000"; d="scan'208,217"; a="92639930:sNHT51557864" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6DDJPtd027172; Thu, 13 Jul 2006 09:19:25 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6DDJL7v024200; Thu, 13 Jul 2006 09:19:21 -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.1830); Thu, 13 Jul 2006 09:19:21 -0400 Received: from [132.219.12.187] ([10.86.240.224]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Jul 2006 09:19:20 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/alternative; boundary=Apple-Mail-32-543384123 Message-Id: <6303051E-0C5E-4826-A706-D89106AB5DB9@cisco.com> From: "Thomas D. Nadeau" Date: Thu, 13 Jul 2006 09:19:19 -0400 To: jin.lizhong@zte.com.cn X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 13 Jul 2006 13:19:20.0986 (UTC) FILETIME=[F39CAFA0:01C6A67E] DKIM-Signature: a=rsa-sha1; q=dns; l=24810; t=1152796765; x=1153660765; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tnadeau@cisco.com; z=From:=22Thomas=20D.=20Nadeau=22=20 |Subject:Re=3A=20[L2VPN]=20comments=20on=20VPLS=20MIB |To:jin.lizhong@zte.com.cn; X=v=3Dcisco.com=3B=20h=3DDCXwRgfNHs4OD3Pl86jiXNNe8Gg=3D; b=SqXH9gZ2+n46mflDZxKHlKqRtAA8xNimeuzi2BL6SETbZ4QXAGYto69pbtHSkSGeIZObhqal qFe1zQyTfcYvtCck0wvzC9KcgREh0dT4vXEpeH/zMPvsgrfz3j0nwvda; Authentication-Results: rtp-dkim-2.cisco.com; header.From=tnadeau@cisco.com; dkim=pass ( 29 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.3 (/) X-Scan-Signature: 9d7e8d783239e9f0c425c823a9c950ff Cc: l2vpn@ietf.org, 'Shane Amante' Subject: Re: [L2VPN] comments on VPLS MIB X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org --Apple-Mail-32-543384123 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312; delsp=yes; format=flowed > It may be more optimized to merge VPWS and VPLS to one MIB. > > Pls. see my comments below starting with Jin.lizhong. > > > > Jayanta Tewari > 2006-07-09 01:36 > > > =CA=D5=BC=FE=C8=CB=A3=BA "'Shane Amante'" = , =20 > > =B3=AD=CB=CD=A3=BA > =D6=F7=CC=E2=A3=BA RE: [L2VPN] comments on VPLS MIB > > > > Should not there be objects to distinguish between qualified and =20 > unqualified > learning methods for Virtual switch instances ? > > Refering to 4.2,will it be possible to keep label information =20 > through BRIDGE > MIB with respect to learning processes (as it might map to =20 > interfaces or > label.Right ?)What about a table related to Mac learning in this =20 > MIB itself > ? Why do we need to add this? There are already MAC tables in the = native Ethernet MIBs. I would prefer to keep the l2vpn MIB as complicated =20 as possible, and no more. > Jin.lizhong: Mac learning parameters can be put in the BRIDGE MIB, =20 > for bridge > module performs the Mac learning capabilities. While label =20 > information can be > put in the pwTable described in [PW-MIB]. This should actually go in the PW-MPLS-MIIB (if anywhere). L2TPv3 doesn't use labels. > Maybe BRIDGE MIB can be changed to > a bridge table in [VPLS-MIB], and is not necessary to be a seperate =20= > MIB. I don't understand what you are asking for here. Are you saying = that we add a bridge table into the l2vpn mib? > > > Pls. see other comments below starting with JT. > > rgds, > --Jayanta > > -----Original Message----- > From: Shane Amante [mailto:shane@castlepoint.net] > Sent: Saturday, July 08, 2006 7:42 PM > To: l2vpn@ietf.org > Subject: Fwd: [L2VPN] comments on VPLS MIB > > > Forwarding to the list on behalf of Anil. > > -shane > > > Begin forwarded message: > > From: anilr@accton.com > > Date: July 7, 2006 10:52:55 AM MDT > > To: Shane Amante , tnadeau@cisco.com > > Subject: Fwd: [L2VPN] comments on VPLS MIB > > > > Shane, Tom, > > > > For some reason, my mail bounces off the l2vpn list. > > > > Please forward it if you could, for consideration at the meeting. > > > > Regards, > > Anil > > > > ----- Forwarded by Anil Rijhsinghani/AcctonUS on 07/07/2006 12:39 > > PM ----- > > > > Anil > > Rijhsinghani To: tnadeau@cisco.com > > cc: l2vpn@ietf.org > > 07/05/2006 Subject: comments on > > VPLS MIB(Document link: Anil Rijhsinghani) > > 01:27 PM > > > > > > > > > > > > Tom, > > > > I was preparing to send in a contribution for VPLS MIB, before I > > saw yours > > on the agenda. > > > > Some initial comments/questions on the MIB: > > > > - table of contents either not updated, or some piece of the MIB > > missing? > > (page numbers) > > - I assume this only convers the LDP method; if so perhaps =20 > mention in > > abstract > > - need an optional static table to manually configure VPLS peers Please be specific about what you are proposing (i.e.: post SMI = code =20 please). > > - what forms of auto-discovery in vplsPwBindBindType, can these be > > listed > > as types? The assumption that is a box will do more than one type. I don't know of any boxes that support two methods simultaneously. OTOH, I suppose it is informational to list the specific type here. > > - vplsMacLearning: why is this needed? (corresponding function not > > described in VPLS document) > > - vplsDiscardUnknownDest: why needed? (ditto) > > - vplMacAging: why needed? (ditto) These were in one or both (can't remember) of the early proposed l2vpn mibs that I looked at. I am ok with removing these. > JT:I guess these correspond to sections 4.2,6.2,9.1 etc. > draft-ietf-l2vpn-vpls-ldp-08.txt. > > > - object needed for VPLS MTU OK. > > - object needed for information on HVPLS Spoke connection (eg, > > correlation to Q-in-Q) > JT:Is there anything special needed for HVPLS architecure as the =20 > spokes > will follow normal L2 technoligies and will keep the related =20 > information in > already developed MIBs for them ? Can you be more specific on what this is? --Tom > Jin.lizhong:It is necessary to add SPOKE property to the MIB. There =20= > are some > other properties that special for VPLS and can not be described in =20 > [PW-MIB]. For > instance, pw backup information, pw STP information, pw SNOOPING =20 > information, etc. > So in [VPLS-MIB], additional pw information should be added, and a =20 > l2vpnPwTable > may be needed. > > > - object to correlate the interface on which a VPLS instance is > > running > > would be useful, which in turn ties into MAC address based on =20 > ifTable > > - up-front text to describe relationship to ifTable (in addition to > > Bridge > > MIB and PW MIB) > > - traps for high-water and low-mater mark: suggest removing these > > (there > > isn't such a thing in Bridge MIB either) > > > > Regards, > > Anil > > > > > > > > > > > > Shane Amante > > > oint.net> cc: > > Subject: L2VPN Agenda > > for IETF 66 > > 07/05/2006 > > 11:17 AM > > > > > > > > > > > > > > The agenda for the upcoming meeting in Montreal is located here, =20 > (and > > in-line below): > > http://www3.ietf.org/proceedings/06jul/agenda/l2vpn.txt > > > > For those who are presenting at the upcoming meeting, please e-mail > > your > > slides to Vach & I by no later than noon EST on July 12. > > > > Thanks, > > > > -shane & Vach > > > > > > ---cut here--- > > > > IETF 66: Layer 2 Virtual Private Network WG (l2vpn) Agenda > > > > Thursday, July 13, 2006, 1510-1610 > > =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 > > > > Chairs: Vach Kompella > > Shane Amante > > > > 1) Administrivia > > - Mailing list: http://www.ietf.org/mail-archive/web/l2vpn/ > > index.html > > - Scribe? > > - Blue Sheets > > - Agenda Bashing > > > > 2) WG Status and Update > > Chairs > > 10 mins > > > > 3) Virtual Private Lan Services (VPLS) Management Information Base > > http://www.ietf.org/internet-drafts/draft-nadeau-l2vpn-vpls-=20 > mib-00.txt > > Tom Nadeau (tnadeau@cisco.com) > > 10 mins > > > > 4) PIM Snooping over VPLS > > http://www.ietf.org/internet-drafts/draft-hemige-serbest-l2vpn-vpls- > > pim-snooping-01.txt > > > > Venu Hemige (venu.hemige@alcatel.com) > > 10 mins > > > > 5) Meeting Closes > > > > > > > > > > > > > > > The information contained in this electronic message and any =20 > attachments to this message are intended for the exclusive use of =20 > the addressee(s)and may contain confidential or privileged =20 > information. If you are not the intended recipient, please notify =20 > the sender or administrator@tataelxsi.co.in > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this =20 > mail is solely property of the sender's organization. This mail =20 > communication is confidential. Recipients named above are obligated =20= > to maintain secrecy and are not permitted to disclose the contents =20 > of this communication to others. > This email and any files transmitted with it are confidential and =20 > intended solely for the use of the individual or entity to whom =20 > they are addressed. If you have received this email in error please =20= > notify the originator of the message. Any views expressed in this =20 > message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam =20= > system. > > > > -------------------------------------------------------- > > ZTE Information Security Notice: The information contained in this =20 > mail is solely property of the sender's organization. This mail =20 > communication is confidential. Recipients named above are obligated =20= > to maintain secrecy and are not permitted to disclose the contents =20 > of this communication to others. > > This email and any files transmitted with it are confidential and =20 > intended solely for the use of the individual or entity to whom =20 > they are addressed. If you have received this email in error please =20= > notify the originator of the message. Any views expressed in this =20 > message are those of the individual sender. > > This message has been scanned for viruses and Spam by ZTE Anti-Spam =20= > system. > --Apple-Mail-32-543384123 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8
It may be more optimized to merge = VPWS and VPLS to one MIB.

Pls. = see my comments below starting with Jin.lizhong.


Jayanta Tewari <jayanta@tataelxsi.co.in>

2006-07-09 = 01:36

=C2=A0 =C2=A0 = =C2=A0 =C2=A0
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A =C2=A0 =C2=A0 =C2=A0 = =C2=A0"'Shane Amante'" <shane@castlepoint.net>, = <l2vpn@ietf.org> =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =E6=8A=84=E9=80=81=EF=BC=9A =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E4=B8=BB=E9=A2= =98=EF=BC=9A =C2=A0 =C2=A0 =C2=A0 =C2=A0RE: [L2VPN] comments on VPLS = MIB



Should not there be objects to distinguish between = qualified and unqualified
learning methods for Virtual switch = instances ?

Refering to 4.2,will it be possible to keep label = information through BRIDGE
MIB with respect to learning processes = (as it might map to interfaces or
label.Right ?)What about a table = related to Mac learning in this MIB itself
= ?

Why do we = need to add this?=C2=A0 There are already MAC tables in the = native
Ethernet MIBs.=C2=A0 I would prefer to keep the l2vpn = MIB as complicated as possible,
and no more.=C2=A0
Jin.lizhong: Mac learning parameters can be put in = the BRIDGE MIB, for bridge
module = performs the Mac learning capabilities. While label information can = be
put in the pwTable described in = [PW-MIB].

This = should actually go in the PW-MPLS-MIIB (if anywhere).=C2=A0
L2TP= v3 doesn't use labels.

Maybe BRIDGE MIB can be changed to
a bridge table in [VPLS-MIB], and is not necessary to be = a seperate MIB.

I don't = understand what you are asking for here. Are you saying = that=C2=A0
we add a bridge table into the l2vpn = mib?



= Pls. see other comments below starting with JT.

rgds,
= --Jayanta

-----Original Message-----
From: Shane Amante [mailto:shane@castlepoint.net] Sent: Saturday, July 08, 2006 7:42 PM
To: l2vpn@ietf.org
Subject: Fwd: = [L2VPN] comments on VPLS MIB


Forwarding to the list on = behalf of Anil.

-shane


Begin forwarded = message:
> From: anilr@accton.com
> Date: = July 7, 2006 10:52:55 AM MDT
> To: Shane Amante <shane@castlepoint.net>, tnadeau@cisco.com
> = Subject: Fwd: [L2VPN] comments on VPLS MIB
>
> Shane, = Tom,
>
> For some reason, my mail bounces off the l2vpn = list.
>
> Please forward it if you could, for = consideration at the meeting.
>
> Regards,
> = Anil
>
> ----- Forwarded by Anil Rijhsinghani/AcctonUS on = 07/07/2006 12:39
> PM -----
>
> =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Anil
> =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Rijhsinghani =C2=A0= =C2=A0 =C2=A0 =C2=A0 To: =C2=A0 =C2=A0 tnadeau@cisco.com
> =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0cc: =C2=A0 = =C2=A0 l2vpn@ietf.org
> =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = 07/05/2006 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Subject: =C2=A0 =C2=A0 = comments on
> VPLS MIB(Document link: Anil Rijhsinghani)
> = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = 01:27 PM
>
>
>
>
>
> Tom,
= >
> I was preparing to send in a contribution for VPLS MIB, = before I
> saw yours
> on the agenda.
>
> = Some initial comments/questions on the MIB:
>
> - table of = contents either not updated, or some piece of the MIB
> = missing?
> (page numbers)
> - I assume this only convers = the LDP method; if so perhaps mention in
> abstract
> - = need an optional static table to manually configure VPLS = peers

Please be = specific about what you are proposing (i.e.: post SMI code = please).

> - = what forms of auto-discovery in vplsPwBindBindType, can these be
= > listed
> as types?

The = assumption that is a box will do more than one type.
I don't = know of any boxes that support two methods = simultaneously.
OTOH, I suppose it is informational to list = the specific type here.=C2=A0

> - vplsMacLearning: why is this needed? = (corresponding function not
> described in VPLS document)
= > - vplsDiscardUnknownDest: why needed? (ditto)
> - = vplMacAging: why needed? (ditto)

These = were in one or both (can't remember) of the early = proposed
l2vpn mibs that I looked at. =C2=A0 I am ok with = removing these.

JT:I guess these correspond to sections 4.2,6.2,9.1 = etc.
draft-ietf-l2vpn-vpls-ldp-08.txt.

> - object needed = for VPLS MTU

OK.

> - object needed for information = on HVPLS Spoke connection (eg,
> correlation=C2=A0to Q-in-Q)
= JT:Is there anything special =C2=A0needed for HVPLS architecure as the = spokes
will follow normal L2 technoligies and will keep the related = information in
already developed MIBs for them ? =

Can you = be more specific on what this is?

= --Tom



Jin.lizhong:It is necessary to = add SPOKE property to the MIB. There are some
other properties that special for VPLS and can not be = described in [PW-MIB]. For
instance, = pw backup information, pw STP information, pw SNOOPING information, = etc.
So in [VPLS-MIB], additional = pw information should be added, and a l2vpnPwTable
may be needed.

= > - object to correlate the interface on which a VPLS instance is
= > running
> would be useful, which in turn ties into MAC = address based on ifTable
> - up-front text to describe = relationship to ifTable (in addition to
> Bridge
> MIB and = PW MIB)
> - traps for high-water and low-mater mark: suggest = removing these
> (there
> isn't such a thing in Bridge MIB = either)
>
> Regards,
> Anil
>
>
= >
>
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 Shane Amante
> =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <shane@castlep =C2=A0 = =C2=A0 =C2=A0 To: =C2=A0 =C2=A0 l2vpn@ietf.org
> =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 oint.net> =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0cc:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Subject: =C2=A0 =C2=A0 = L2VPN Agenda
> for IETF 66
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 07/05/2006
> =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 11:17 AM
= >
>
>
>
>
>
> The agenda = for the upcoming meeting in Montreal is located here, (and
> = in-line below):
> http://ww= w3.ietf.org/proceedings/06jul/agenda/l2vpn.txt
>
> For = those who are presenting at the upcoming meeting, please e-mail
> = your
> slides to Vach & I by no later than noon EST on July = 12.
>
> Thanks,
>
> -shane & Vach
= >
>
> ---cut here---
>
> IETF 66: Layer 2 = Virtual Private Network WG (l2vpn) Agenda
>
> Thursday, = July 13, 2006, 1510-1610
> =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
= >
> Chairs: Vach Kompella
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Shane Amante
>
> 1) Administrivia
> =C2=A0 =C2=A0= - Mailing list: http://www.ietf.org/m= ail-archive/web/l2vpn/
> index.html
> =C2=A0 =C2=A0 - = Scribe?
> =C2=A0 =C2=A0 - Blue Sheets
> =C2=A0 =C2=A0 - = Agenda Bashing
>
> 2) WG Status and Update
> =C2=A0 = =C2=A0 Chairs
> =C2=A0 =C2=A0 10 mins
>
> 3) = Virtual Private Lan Services (VPLS) Management Information Base
> = http://www.ietf.org/internet-drafts/draft-nadeau-l2vpn-vpls-mib-00.t= xt
> =C2=A0 =C2=A0 Tom Nadeau (tnadeau@cisco.com)
> =C2=A0 = =C2=A0 10 mins
>
> 4) PIM Snooping over VPLS
> http://www.ietf.org/internet-drafts/draft-hemige-serbest-l2vpn-vpls-
> pim-snooping-01.txt
>
> =C2=A0 =C2=A0 Venu = Hemige (venu.hemige@alcatel.com)
= > =C2=A0 =C2=A0 10 mins
>
> 5) Meeting Closes
= >
>
>
>
>
>


The = information contained in this electronic message and any attachments to = this message are intended for the exclusive use of the addressee(s)and = may contain confidential or privileged information. If you are not the = intended recipient, please notify the sender or administrator@tataelxsi.co.i= n



= --------------------------------------------------------
ZTE = Information Security Notice: The information contained in this mail is = solely property of the sender's organization. This mail communication is = confidential. Recipients named above are obligated to maintain secrecy = and are not permitted to disclose the contents of this communication to = others.
This email and any files transmitted with it are = confidential and intended solely for the use of the individual or entity = to whom they are addressed. If you have received this email in error = please notify the originator of the message. Any views expressed in this = message are those of the individual sender.
This message has been = scanned for viruses and Spam by ZTE Anti-Spam system.
 = 

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

=
ZTE=C2=A0Information=C2=A0Security=C2=A0Notice:=C2=A0The=C2=A0information=C2=
=A0contained=C2=A0in=C2=A0this=C2=A0mail=C2=A0is=C2=A0solely=C2=A0property=
=C2=A0of=C2=A0the=C2=A0sender's=C2=A0organization.=C2=A0This=C2=A0mail=C2=A0=
communication=C2=A0is=C2=A0confidential.=C2=A0Recipients=C2=A0named=C2=A0a=
bove=C2=A0are=C2=A0obligated=C2=A0to=C2=A0maintain=C2=A0secrecy=C2=A0and=C2=
=A0are=C2=A0not=C2=A0permitted=C2=A0to=C2=A0disclose=C2=A0the=C2=A0content=
s=C2=A0of=C2=A0this=C2=A0communication=C2=A0to=C2=A0others.

=
This=C2=A0email=C2=A0and=C2=A0any=C2=A0files=C2=A0transmitted=C2=A0with=C2=
=A0it=C2=A0are=C2=A0confidential=C2=A0and=C2=A0intended=C2=A0solely=C2=A0f=
or=C2=A0the=C2=A0use=C2=A0of=C2=A0the=C2=A0individual=C2=A0or=C2=A0entity=C2=
=A0to=C2=A0whom=C2=A0they=C2=A0are=C2=A0addressed.=C2=A0If=C2=A0you=C2=A0h=
ave=C2=A0received=C2=A0this=C2=A0email=C2=A0in=C2=A0error=C2=A0please=C2=A0=
notify=C2=A0the=C2=A0originator=C2=A0of=C2=A0the=C2=A0message.=C2=A0Any=C2=
=A0views=C2=A0expressed=C2=A0in=C2=A0this=C2=A0message=C2=A0are=C2=A0those=
=C2=A0of=C2=A0the=C2=A0individual=C2=A0sender.

=
This=C2=A0message=C2=A0has=C2=A0been=C2=A0scanned=C2=A0for=C2=A0viruses=C2=
=A0and=C2=A0Spam=C2=A0by=C2=A0ZTE=C2=A0Anti-Spam=C2=A0system.

= --Apple-Mail-32-543384123-- From l2vpn-bounces@ietf.org Thu Jul 13 21:03:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1C5Z-0001AQ-FC; Thu, 13 Jul 2006 21:03:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1C5Y-0001AL-AX for l2vpn@ietf.org; Thu, 13 Jul 2006 21:03:28 -0400 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1C5X-0000wD-42 for l2vpn@ietf.org; Thu, 13 Jul 2006 21:03:28 -0400 Received: from [127.0.0.1] (dog.tcb.net [64.78.150.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id 76B9E64352 for ; Thu, 13 Jul 2006 19:03:22 -0600 (MDT) Message-ID: <44B6ED59.6020002@castlepoint.net> Date: Thu, 13 Jul 2006 21:03:21 -0400 From: Shane Amante User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) 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: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: draft-sajassi-l2vpn-vpls-bridge-interop-03 -> WG Doc? X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org Hi Folks, This e-mail initiates a call on whether to make draft-sajassi-l2vpn-vpls-bridge-interop-03 a WG doc in the L2VPN WG. Please indicate to the mailing list whether you do or don't support making this doc a WG draft by no later than Friday, 7/21/2006, 1700 MDT (GMT -6). Thanks! -shane & Vach From l2vpn-bounces@ietf.org Mon Jul 17 00:46:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2L08-0001Tw-EH; Mon, 17 Jul 2006 00:46:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2L07-0001SS-Iw for l2vpn@ietf.org; Mon, 17 Jul 2006 00:46:35 -0400 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2L05-0006tL-AL for l2vpn@ietf.org; Mon, 17 Jul 2006 00:46:35 -0400 Received: from [172.16.15.25] (dsl081-098-224.den1.dsl.speakeasy.net [64.81.98.224]) by dog.tcb.net (Postfix) with ESMTP id BA55D6436B for ; Sun, 16 Jul 2006 22:46:28 -0600 (MDT) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: l2vpn@ietf.org From: Shane Amante Date: Sun, 16 Jul 2006 22:46:31 -0600 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: Draft minutes of L2VPN WG meeting @ IETF 66 (Montreal, Quebec, Canada) X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org Draft meeting minutes of the L2VPN WG Session at IETF 66 have been posted to the following URL: http://www3.ietf.org/proceedings/06jul/minutes/l2vpn.txt Please review and provide corrections no later than Friday, 8/11/2006, 17:00 EDT (UTC -4). In addition to the meeting minutes, all of the presentations have been uploaded to the following URL: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=66 Thanks to Giles Heron, Mohan Nanduri and Mustapha Aissaoui for taking notes! -shane & Vach From l2vpn-bounces@ietf.org Mon Jul 17 02:03:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2MC1-0004e1-FI; Mon, 17 Jul 2006 02:02:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2MC0-0004aP-Di for l2vpn@ietf.org; Mon, 17 Jul 2006 02:02:56 -0400 Received: from [63.113.148.10] (helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2MBy-0000Xg-Um for l2vpn@ietf.org; Mon, 17 Jul 2006 02:02:56 -0400 Received: from gondor.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id XAA14595; Sun, 16 Jul 2006 23:02:43 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6A966.9D80AF72" Date: Mon, 17 Jul 2006 11:32:41 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New I-D : LDP Extensions for Optimized MAC Address Withdrawal in H-VPLS Thread-Index: AcapZp0/pmS5q0/IRXWwodbm/FDWzQ== From: "Dutta, Pranjal" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 913ee11e7c554f7d4da75d500826397e Cc: Shane.Amante@level3.com, vach.kompella@alcatel.com Subject: New I-D : LDP Extensions for Optimized MAC Address Withdrawal in H-VPLS X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C6A966.9D80AF72 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi All, I have submitted a new I-D for review and comments in L2VPN WG. =20 Title : LDP Extensions for Optimized MAC Address Withdrawal in H-VPLS Author(s) : P. Dutta Filename : draft-pdutta-l2vpn-vpls-ldp-mac-opt-00.txt =20 Pages : 8 Date : 2006-7-12=20 =20 This document proposes an extension to MAC address withdrawal in H-VPLS through LDP Address Withdraw Message with empty MAC List as defined in=20 [VPLS-LDP]. This extension optimizes MAC address withdrawal by flushing=20 only those MAC addresses that are affected due to topology change. =20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-pdutta-l2vpn-vpls-ldp-mac-opt- 00.txt =20 =20 Please review and put forward your comments. =20 Thanks, Pranjal Kumar Dutta Lucent Technologies, J P Techno Parks, #3/1 Millers Road, Bangalore - 52, India E-mail: pdutta@lucent.com =20 =20 ------_=_NextPart_001_01C6A966.9D80AF72 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi All,

           &= nbsp;   I have submitted a new I-D for review and comments in L2VPN = WG.

 

      = Title       : LDP Extensions for Optimized MAC Address Withdrawal in = H-VPLS

      Author(s)   : P. Dutta

      Filename    : draft-pdutta-l2vpn-vpls-ldp-mac-opt-00.txt     &= nbsp;  

      = Pages       : 8

      = Date        : 2006-7-12

     

      This document proposes an extension to MAC address withdrawal in = H-VPLS

      through LDP Address Withdraw Message with empty MAC List as defined in =

      [VPLS-LDP]. This extension optimizes MAC address withdrawal by flushing =

      only those MAC addresses that are affected due to topology change. =   

  

A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-pdutta-l2vpn-vpl= s-ldp-mac-opt-00.txt

 

 

Please review and put forward your = comments.

 

Thanks,

Pranjal Kumar = Dutta

Lucent = Technologies,

J P Techno Parks, = #3/1 Millers = Road,

Bangalore – 52, India

E-mail: pdutta@lucent.com=

 

 

------_=_NextPart_001_01C6A966.9D80AF72-- From l2vpn-bounces@ietf.org Mon Jul 17 08:46:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2SUt-0006Gc-L2; Mon, 17 Jul 2006 08:46:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2SUr-0006GU-H1 for l2vpn@ietf.org; Mon, 17 Jul 2006 08:46:49 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2SUq-0005EX-95 for l2vpn@ietf.org; Mon, 17 Jul 2006 08:46:49 -0400 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k6HCkj118695; Mon, 17 Jul 2006 08:46:45 -0400 (EDT) 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, 17 Jul 2006 08:45:57 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB64650B1425FD@zcarhxm1.corp.nortel.com> In-Reply-To: <44B6ED59.6020002@castlepoint.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-sajassi-l2vpn-vpls-bridge-interop-03 -> WG Doc? Thread-Index: Acam4ZKfoDw/XO9UQK6sJoyiirIqWwCvUW5A From: "Florin Balus" To: "Shane Amante" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: RE: draft-sajassi-l2vpn-vpls-bridge-interop-03 -> WG Doc? X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org Yes I support making this a WG document.=20 >-----Original Message----- >From: Shane Amante [mailto:shane@castlepoint.net]=20 >Sent: Thursday, July 13, 2006 9:03 PM >To: l2vpn@ietf.org >Subject: draft-sajassi-l2vpn-vpls-bridge-interop-03 -> WG Doc? > >Hi Folks, > >This e-mail initiates a call on whether to make >draft-sajassi-l2vpn-vpls-bridge-interop-03 a WG doc in the L2VPN WG. > >Please indicate to the mailing list whether you do or don't=20 >support making this doc a WG draft by no later than Friday,=20 >7/21/2006, 1700 MDT (GMT -6). > >Thanks! > >-shane & Vach > > From l2vpn-bounces@ietf.org Mon Jul 17 09:01:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2SjF-0007Lc-FX; Mon, 17 Jul 2006 09:01:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2SjE-0007LS-IV for l2vpn@ietf.org; Mon, 17 Jul 2006 09:01:40 -0400 Received: from ripley.ciena.com ([63.118.34.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2SjD-0005tv-Cl for l2vpn@ietf.org; Mon, 17 Jul 2006 09:01:40 -0400 Received: from mdmail4.ciena.com (HELO mdmxm01.ciena.com) ([63.118.39.26]) by ripley.ciena.com with ESMTP; 17 Jul 2006 09:15:11 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Jul 2006 09:00:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <3C13767EA2F93441AFB13A630204F1B203A347@mamxm02.ciena.com> In-Reply-To: <44B6ED59.6020002@castlepoint.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-sajassi-l2vpn-vpls-bridge-interop-03 -> WG Doc? Thread-Index: Acam4Y/3bWGTal7hQgGp69hAGv17YwCv1mMw From: "Shah, Himanshu" To: "Shane Amante" , X-OriginalArrivalTime: 17 Jul 2006 13:00:30.0845 (UTC) FILETIME=[FBA5DAD0:01C6A9A0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Subject: RE: draft-sajassi-l2vpn-vpls-bridge-interop-03 -> WG Doc? X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org I support this draft to be a working group document. /himanshu > -----Original Message----- > From: Shane Amante [mailto:shane@castlepoint.net] > Sent: Thursday, July 13, 2006 9:03 PM > To: l2vpn@ietf.org > Subject: draft-sajassi-l2vpn-vpls-bridge-interop-03 -> WG Doc? >=20 >=20 > Hi Folks, >=20 > This e-mail initiates a call on whether to make=20 > draft-sajassi-l2vpn-vpls-bridge-interop-03 a WG doc in the L2VPN WG. >=20 > Please indicate to the mailing list whether you do or don't support=20 > making this doc a WG draft by no later than Friday,=20 > 7/21/2006, 1700 MDT=20 > (GMT -6). >=20 > Thanks! >=20 > -shane & Vach >=20 From l2vpn-bounces@ietf.org Mon Jul 17 11:21:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2Uuu-0003wP-5n; Mon, 17 Jul 2006 11:21:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2Uut-0003rr-8P for l2vpn@ietf.org; Mon, 17 Jul 2006 11:21:51 -0400 Received: from howler.tri.sbc.com ([205.173.58.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2Uuq-0005V5-SE for l2vpn@ietf.org; Mon, 17 Jul 2006 11:21:51 -0400 Received: from sbctri.labs.sbc.com (internet-austin-webdmz.labs.sbc.com [144.60.9.139]) by howler.tri.sbc.com (8.13.7/8.12.10) with ESMTP id k6HFLe8e002137; Mon, 17 Jul 2006 10:21:40 -0500 (CDT) Received: from TSMAIL.ad.tri.sbc.com (tsmail.ad.tri.sbc.com [144.60.55.228]) by sbctri.labs.sbc.com (8.13.6/8.12.10) with ESMTP id k6HFLawY018052; Mon, 17 Jul 2006 10:21:40 -0500 (CDT) Received: from TSMAIL2.ad.tri.sbc.com ([144.60.55.226]) by TSMAIL.ad.tri.sbc.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Jul 2006 10:21:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Jul 2006 10:21:35 -0500 Message-ID: <0CED449E95A92A42991EB71B778C17BF033A1811@TSMAIL2.ad.tri.sbc.com> In-Reply-To: <3C13767EA2F93441AFB13A630204F1B203A347@mamxm02.ciena.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-sajassi-l2vpn-vpls-bridge-interop-03 -> WG Doc? Thread-Index: Acam4Y/3bWGTal7hQgGp69hAGv17YwCv1mMwAATwZoA= From: "Serbest, Yetik" To: "Shah, Himanshu" , "Shane Amante" , X-OriginalArrivalTime: 17 Jul 2006 15:21:35.0818 (UTC) FILETIME=[B12A3AA0:01C6A9B4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Subject: RE: draft-sajassi-l2vpn-vpls-bridge-interop-03 -> WG Doc? X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org Me too. -----Original Message----- From: Shah, Himanshu [mailto:hshah@ciena.com]=20 Sent: Monday, July 17, 2006 8:00 AM To: Shane Amante; l2vpn@ietf.org Subject: RE: draft-sajassi-l2vpn-vpls-bridge-interop-03 -> WG Doc? I support this draft to be a working group document. /himanshu > -----Original Message----- > From: Shane Amante [mailto:shane@castlepoint.net] > Sent: Thursday, July 13, 2006 9:03 PM > To: l2vpn@ietf.org > Subject: draft-sajassi-l2vpn-vpls-bridge-interop-03 -> WG Doc? >=20 >=20 > Hi Folks, >=20 > This e-mail initiates a call on whether to make=20 > draft-sajassi-l2vpn-vpls-bridge-interop-03 a WG doc in the L2VPN WG. >=20 > Please indicate to the mailing list whether you do or don't support=20 > making this doc a WG draft by no later than Friday,=20 > 7/21/2006, 1700 MDT=20 > (GMT -6). >=20 > Thanks! >=20 > -shane & Vach >=20 From l2vpn-bounces@ietf.org Mon Jul 17 11:50:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2VN3-0003fc-2G; Mon, 17 Jul 2006 11:50:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2VN1-0003fX-Gt for l2vpn@ietf.org; Mon, 17 Jul 2006 11:50:55 -0400 Received: from [63.113.148.10] (helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2VN0-0000yd-4m for l2vpn@ietf.org; Mon, 17 Jul 2006 11:50:55 -0400 Received: from IBMT41ML by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id IAA26089; Mon, 17 Jul 2006 08:50:51 -0700 (PDT) Message-ID: <002c01c6a9b8$c48bca10$6601a8c0@IBMT41ML> From: "Marc Lasserre" To: References: <44B6ED59.6020002@castlepoint.net> Date: Mon, 17 Jul 2006 17:50:44 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: Re: draft-sajassi-l2vpn-vpls-bridge-interop-03 -> WG Doc? X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org I support making this draft a WG doc. Marc ----- Original Message ----- From: "Shane Amante" To: Sent: Friday, July 14, 2006 3:03 AM Subject: draft-sajassi-l2vpn-vpls-bridge-interop-03 -> WG Doc? > Hi Folks, > > This e-mail initiates a call on whether to make > draft-sajassi-l2vpn-vpls-bridge-interop-03 a WG doc in the L2VPN WG. > > Please indicate to the mailing list whether you do or don't support > making this doc a WG draft by no later than Friday, 7/21/2006, 1700 MDT > (GMT -6). > > Thanks! > > -shane & Vach > > > From l2vpn-bounces@ietf.org Mon Jul 17 14:01:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2XP3-0002pc-S8; Mon, 17 Jul 2006 14:01:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2XP2-0002pU-IO for l2vpn@ietf.org; Mon, 17 Jul 2006 14:01:08 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2XOz-0004Fq-Sz for l2vpn@ietf.org; Mon, 17 Jul 2006 14:01:08 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 17 Jul 2006 11:01:06 -0700 X-IronPort-AV: i="4.06,251,1149490800"; d="scan'208"; a="306243037:sNHT84128320" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6HI13Jt014549; Mon, 17 Jul 2006 11:01:03 -0700 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 k6HI107P021072; Mon, 17 Jul 2006 11:01:03 -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.1830); Mon, 17 Jul 2006 14:00:58 -0400 Received: from [10.83.15.53] ([10.83.15.53]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Jul 2006 14:00:56 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <19377DC7-D634-409C-BAC6-263994958DFB@cisco.com> Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Date: Mon, 17 Jul 2006 14:00:58 -0400 To: Shane Amante X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 17 Jul 2006 18:00:57.0434 (UTC) FILETIME=[F4550BA0:01C6A9CA] DKIM-Signature: a=rsa-sha1; q=dns; l=7979; t=1153159263; x=1154023263; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tnadeau@cisco.com; z=From:=22Thomas=20D.=20Nadeau=22=20 |Subject:Re=3A=20Draft=20minutes=20of=20L2VPN=20WG=20meeting=20@=20IETF=2066=20(M ontreal,=20Quebec,=20Canada)=3A=20L2VPN=20MIB; X=v=3Dcisco.com=3B=20h=3DuewgUE7wYok1yStjEU96yNyO/R4=3D; b=A655Lt59+4txKa0ShZu8S6vnpaQNE1OArk2cTeRaTVyPmPi65bVUaeiJIryNPH0OkwKY5I96 0y8xAlWuxmuQ87ISh9YryDqSiao8ZsYTl8fQfZARta3MTZSavUfXh32J; Authentication-Results: sj-dkim-8.cisco.com; header.From=tnadeau@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Cc: l2vpn@ietf.org Subject: Re: Draft minutes of L2VPN WG meeting @ IETF 66 (Montreal, Quebec, Canada): L2VPN MIB X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org I wanted to chime in on the discussion that took place at the meeting RE: the L2VPN MIB, as I was unable to attend. In response to the comments listed at the link below which Shane provided, and start with "TDN:" 3) Virtual Private Lan Services (VPLS) Management Information Base http://www.ietf.org/internet-drafts/draft-nadeau-l2vpn-vpls-mib-00.txt Rohit Medirrata (rohit.mediratta@alcatel.com) Presentation: + Scope of the MIB: limited to VPLS as per VPLS-LDP draft. Does not have VPLS-BGP, yet. + List of Tables: - vplsConfigTable contains VPLS-wide parameters. Config table has e.g. timeout for how long before you time out a MAC. - vplsPwBindTable contains PW configuration. Bind table would be e.g. "PW is spoke" or "PW is mesh". + MIB Module Architecture: - VPLS MIB sits on top of both PW MIB and Bridge MIB. - PW MIB sits on top of MPLS-MIB/PSN-MIB. * VPLS MIB is a service specific MIB. So need PW MIB and PSN MIB too. Question mark on BRIDGE MIB. Not sure if MAC addresses will be in BRIDGE MIB or in an additional table in the VPLS MIB. Looking for WG consensus on that... + MIB usage. To configure VPLS service, need 3 tables: - vplsConfigTable: indexed by vplsIndex - pwTable: indexed by PW index; and, - vplsPwBindTable: uses both indexes. * PW bind table required because there are multiple PWs per VPLS. Binds from VPLS config table to PW table (from PW MIB). + Future enhancements: - Where to store MAC addresses and related information? Bridge MIB or VPLS MIB? Constraint on BRIDGE MIB is qualified vs qualified learning. - VPLS MTU (need a VPLS-wide MTU as well as PW MTU) - Not convinced we need to be able to disable MAC learning, or to discard unknown destination addresses. TDN: I agree, and this seems more of a proprietary feature to me. - Need some way to configure MAC aging. - Need to be able to configure max MACs to learn, number learned so far, etc. - Also, no definition of how to handle multicast frames. Would be nice to have options to config IGMP and/or PIM snooping. TDN: I want to avoid adding that stuff if we can. I want the L2VPN MIB to focus on the basics of L2 VPN. - Requirement to modify PWE3 MIB so PW can terminate on a VSI rather than on an AC, so need to talk to PWE3 WG about that. - No way of provisioning primary/standby PWs. - Bind table: * Also good if we could configure PW as spoke or mesh. * MAC address limit may be per VPLS rather than per PW, so may remove that object. - Do we merge this with VPWS or IPLS MIBs? TDN: Specifically which MIB modules are you referring to? For VPWS, the PWE3 MIBs already handle this, so there is no reason to merge anything. Discussion: * Giles Heron - Concerned that we're putting feature specific stuff into the doc. If different vendors do e.g. MAC limiting in different ways then is it OK to put it at PW level or at VPLS instance level etc.? The protocol drafts don't talk about this so why put it in the MIB? Or, should we put this in enterprise MIBs? I'd like to see what others think about this. TDN: We tried to keep the MIB as simple as possible although a few things one could consider feature-specific did creep in. * Vach Kompella - It is hard to draw the line between objects, but it is a good thing to have a standard. If not, make it Informational. TDN: I totally object to making a MIB module Informational. * Bruno R. - Some of the data plane objects might be common to VPLS-LDP and VPLS-BGP. Haven't read in detail so don't know if it's really specific to LDP. If so, then could we separate out the common parts so they can be re-used for VPLS-BGP in future? * Rohit - Sure, something to consider. * Kireeti Kompella - Need per AC as well as per PW stuff. Have had requests, for example, to only allow one IP per AC (to ensure there's a router there). Two things going on: 1) VPLS standard that says how to do VPLS signalling; and, 2) VPLS MIB that has features in that are implementation specific. That's not necessary for interop, yet has become part of a proposed standard. So people say "do you support this RFC"? Local implementation things shouldn't become part of proposed standard. So maybe could have normative and non-normative stuff. Not sure if that can be done in the same document. Not necessarily an enterprise MIB, but at least a separate RFC with different status. Really a question for the AD. TDN: There is already per-AC configuration/mgmt using the framework provided by the PWE3 MIBs. Please look at that and tell us if that is insufficient. * Mark Townsley (as AD) - Don't understand split of doc into normative and non-normative. Came up in another WG today. Don't think we have a process. So would have to split docs. If consensus of group is that implementation specific stuff shouldn't be on standards track then should split it up. TDN: I think there is precedence for doing this already: normative stuff based on specific standards documents goes in the standards track MIB module, and everything else goes in vendor-proprietary MIBs (informative). * Vach - I would throw everything in there. If people think all that stuff is a good thing to have in a standard, then that's good. If not, then we'll take that stuff out and decide whether to make it informational. The problem at that point is you can't put the objects in the standard table, so you have to put them in another one. TDN: I would prefer to keep things as simple as possible. This makes it more likely to interoperate, as well as pass through the jungle of IETF MIB approval process. * Andrew Dolganow - There is a compliance statement in the MIB which could be used and keep both in the same document. TDN: The compliance statements have largely been used in two forms for the past dozen or so standards-based MIBs I have been involved in: read-only and read-write. Doing much more than that makes the MIB extremely complex to specify. Thus, I would strongly advise against using the conformance statements as a means to filter out "everything" as Vach said above. Lets keep it as simple as possible, and no simpler. * Mark - I'll do some homework on this. Don't want to saddle WG with splitting docs/MIBs if there's no need. * Kireeti - If there's consensus that this is important then, let's put them in, but not if different vendors do stuff in different ways. * Mark - seems like we're agreeing, but we need to figure out the details. * Bill Fenner - You can use the compliance statement to manage mandatory and optional objects in the same MIB. If it's on a device that can do "foo" then this group is required to manage the foo. All in descriptive text, not machine readable. One big MIB with optional sections to manage features you may or may not be able to do is OK. TDN: It is frankly easier to just use the module construct as a filtering mechanism for this rather than the compliance statements. The latter can be rater cumbersome to construct, especially if you need a read- only and read-write flavor for each. * Mark - There's no issue about stuff that is pseudo-vendor specific being in a standard doc? * Bill - It's feature specific, not vendor specific. TDN: One last question that I meant to pose to the WG that was not raised as far as the meeting minutes were concerned is whether or not to make this MIB read-only or read-write. Given the significant effort needed to make the MIB properly read-write, as well as the lack of support for read-write MIB objects by vendors (most people today seem to use XML or CLI-based configuration) I would like to ask the Chairs that there be sufficient consensus from the WG before we go down this road. TDN: Also, should draft-nadeau-l2vpn-vpls-mib-00.txt become an L2 VPN WG document? --Tom From l2vpn-bounces@ietf.org Mon Jul 17 17:23:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2aZ5-0005ez-Lm; Mon, 17 Jul 2006 17:23:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2aZ4-0005et-6T for l2vpn@ietf.org; Mon, 17 Jul 2006 17:23:42 -0400 Received: from mgw2.noc.ntt.com ([210.160.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2aZ2-0004Qc-K7 for l2vpn@ietf.org; Mon, 17 Jul 2006 17:23:42 -0400 Received: from mop2.noc.ntt.com by mgw2.noc.ntt.com (NTT-Com MailSV) with ESMTP id k6HLNaOg009734 for ; Tue, 18 Jul 2006 06:23:36 +0900 (JST) Received: from mip1.noc.ntt.com (mvi2.noc.ntt.com) by mop2.noc.ntt.com (NTT-Com MailSV) with ESMTP id <0J2K00MS0GRC80@ntt.com> for l2vpn@ietf.org; Tue, 18 Jul 2006 06:23:36 +0900 (JST) Date: Tue, 18 Jul 2006 06:23:34 +0900 From: "Yuji KAMITE" In-reply-to: <44B6ED59.6020002@castlepoint.net> To: l2vpn@ietf.org Message-id: <0d5901c6a9e7$42bb52b0$8bfa320a@araoa.ntt.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: RE: draft-sajassi-l2vpn-vpls-bridge-interop-03 -> WG Doc? X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org I support it. > -----Original Message----- > From: Shane Amante [mailto:shane@castlepoint.net] > Sent: Friday, July 14, 2006 10:03 AM > To: l2vpn@ietf.org > Subject: draft-sajassi-l2vpn-vpls-bridge-interop-03 -> WG Doc? > > > Hi Folks, > > This e-mail initiates a call on whether to make > draft-sajassi-l2vpn-vpls-bridge-interop-03 a WG doc in the L2VPN WG. > > Please indicate to the mailing list whether you do or don't support > making this doc a WG draft by no later than Friday, > 7/21/2006, 1700 MDT > (GMT -6). > > Thanks! > > -shane & Vach > From l2vpn-bounces@ietf.org Mon Jul 17 19:26:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2cUG-0001Uh-0E; Mon, 17 Jul 2006 19:26:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2cUE-0001Uc-HH for l2vpn@ietf.org; Mon, 17 Jul 2006 19:26:50 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2cUE-0004sO-Fh for l2vpn@ietf.org; Mon, 17 Jul 2006 19:26:50 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G2c3O-0001OY-O5 for l2vpn@ietf.org; Mon, 17 Jul 2006 18:59:08 -0400 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k6HMx1f18278 for ; Mon, 17 Jul 2006 18:59:02 -0400 (EDT) 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, 17 Jul 2006 18:59:01 -0400 Message-ID: <183DD1B052A11A40B76125E42F1CBAAB065C1BD0@zcarhxm1.corp.nortel.com> In-Reply-To: <44B6ED59.6020002@castlepoint.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-sajassi-l2vpn-vpls-bridge-interop-03 -> WG Doc? Thread-Index: Acam4hcZDszcdaAfQKGezOUnKKwvFwDEl/Sw From: "Dinesh Mohan" To: X-Spam-Score: -2.6 (--) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: RE: draft-sajassi-l2vpn-vpls-bridge-interop-03 -> WG Doc? X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org I support this draft to be a WG draft. Regards, Dinesh -----Original Message----- From: Shane Amante [mailto:shane@castlepoint.net]=20 Sent: Thursday, July 13, 2006 9:03 PM To: l2vpn@ietf.org Subject: draft-sajassi-l2vpn-vpls-bridge-interop-03 -> WG Doc? Hi Folks, This e-mail initiates a call on whether to make draft-sajassi-l2vpn-vpls-bridge-interop-03 a WG doc in the L2VPN WG. Please indicate to the mailing list whether you do or don't support making this doc a WG draft by no later than Friday, 7/21/2006, 1700 MDT (GMT -6). Thanks! -shane & Vach From l2vpn-bounces@ietf.org Thu Jul 20 16:39:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3fIt-00073B-Jp; Thu, 20 Jul 2006 16:39:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3fIs-00070z-A4 for l2vpn@ietf.org; Thu, 20 Jul 2006 16:39:26 -0400 Received: from [64.171.8.242] (helo=note-back.accton.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3f9L-0006Om-EN for l2vpn@ietf.org; Thu, 20 Jul 2006 16:29:36 -0400 To: l2vpn@ietf.org Bcc: X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: anilr@accton.com Date: Thu, 20 Jul 2006 16:39:48 -0400 X-MIMETrack: Serialize by Router on note_back/AcctonUS(Release 5.0.2c |February 2, 2000) at 07/20/2006 01:22:28 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Score: 0.3 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Subject: Re: Draft minutes of L2VPN WG meeting @ IETF 66 (Montreal, Quebec, Canada) X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org This document discusses interoperability issues with standards-based customer bridging which likely needs to be resolved for different vendors equipment to work together. It would be a useful WG document. Is it intended as an informational or standard document? I would note that it appears to be a work in progress. Mention is made of several interoperability issues which are not addressed one way or another, e.g. how should various "slow" 802 protocols be dealt with? The answer may be different for different existing protocols, and may be different for unrecognized protocols. In addition, reference is made to non-standard mechanisms, one example being a partial-mesh method that is not part of the base VPLS architecture. I would suggest such issues be resolved before putting them in a WG document, i.e, either bring partial meshing into VPLS or remove reference to it. Regards, Anil Shane Amante cc: Subject: Draft minutes of L2VPN WG meeting @ IETF 66 (Montreal, 07/17/2006 Quebec, Canada) 12:46 AM Draft meeting minutes of the L2VPN WG Session at IETF 66 have been posted to the following URL: http://www3.ietf.org/proceedings/06jul/minutes/l2vpn.txt Please review and provide corrections no later than Friday, 8/11/2006, 17:00 EDT (UTC -4). In addition to the meeting minutes, all of the presentations have been uploaded to the following URL: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=66 Thanks to Giles Heron, Mohan Nanduri and Mustapha Aissaoui for taking notes! -shane & Vach From l2vpn-bounces@ietf.org Thu Jul 20 17:13:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3fpL-0006yr-BH; Thu, 20 Jul 2006 17:12:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3fpK-0006yc-Ou for l2vpn@ietf.org; Thu, 20 Jul 2006 17:12:58 -0400 Received: from hostreea2.alcatel.com ([143.209.238.162] helo=audl953.usa.alcatel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3fpJ-0007Yu-EV for l2vpn@ietf.org; Thu, 20 Jul 2006 17:12:58 -0400 Received: from mvrelay.mv.usa.alcatel.com (mvrelay.mv.usa.alcatel.com [128.251.10.15]) by audl953.usa.alcatel.com (ALCANET) with ESMTP id k6KLCt6p008198; Thu, 20 Jul 2006 16:12:56 -0500 Received: from vkompellaxp (localhost [127.0.0.1]) by mvrelay.mv.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id k6KLDNRA019062; Thu, 20 Jul 2006 14:13:24 -0700 (PDT) From: "Vach Kompella" To: , Date: Thu, 20 Jul 2006 14:10:52 -0700 Message-ID: <080501c6ac40$fc3a2030$cab816ac@eng.timetra.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-reply-to: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Importance: Normal X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Subject: draft-sajassi-l2vpn-vpls-bridge-interop-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: , Errors-To: l2vpn-bounces@ietf.org Hi Anil, I assume the draft you are referring to is draft-sajassi-l2vpn-vpls-bridge-interop-03. Thanks for your comments. Please see below for clarifications on the purpose of this draft. -Vach=20 > -----Original Message----- > From: anilr@accton.com [mailto:anilr@accton.com]=20 > Sent: Thursday, July 20, 2006 1:40 PM > To: l2vpn@ietf.org > Subject: Re: Draft minutes of L2VPN WG meeting @ IETF 66=20 > (Montreal, Quebec,Canada) >=20 >=20 >=20 > This document discusses interoperability issues with=20 > standards-based customer bridging which likely needs to be=20 > resolved for different vendors equipment to work together. It=20 > would be a useful WG document. >=20 > Is it intended as an informational or standard document? It is not a standards track document. It will be an informational document. >=20 > I would note that it appears to be a work in progress.=20 All working group documents are still work-in-progress. > Mention is made of several interoperability issues which are=20 > not addressed one way or another, e.g. how should various=20 > "slow" 802 protocols be dealt with? The answer may be=20 > different for different existing protocols, and may be=20 > different for unrecognized protocols. This draft will only capture the issues, and may also include the complexities of the problems such as those you mention, but will not present solutions for them. >=20 > In addition, reference is made to non-standard mechanisms,=20 > one example being a partial-mesh method that is not part of=20 > the base VPLS architecture. I would suggest such issues be=20 > resolved before putting them in a WG document, i.e, either=20 > bring partial meshing into VPLS or remove reference to it. The draft attempts to capture the ways in which a VPLS is not a perfect emulation of ethernet bridging. Solutions that are presented for these issues do not invalidate the status of this draft, since it refers to the basic VPLS solutions. The partial mesh issue, for example, is noted as a potential issue for VPLS, and is hence a perfect candidate for inclusion in this draft. >=20 > Regards, > Anil >=20 >=20 From l2vpn-bounces@ietf.org Sun Jul 23 16:07:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4kE4-0004Cc-2y; Sun, 23 Jul 2006 16:06:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4kE1-0004CN-Vf for l2vpn@ietf.org; Sun, 23 Jul 2006 16:06:53 -0400 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4kE0-0008TQ-Oh for l2vpn@ietf.org; Sun, 23 Jul 2006 16:06:53 -0400 Received: from [172.16.15.25] (dsl081-098-224.den1.dsl.speakeasy.net [64.81.98.224]) by dog.tcb.net (Postfix) with ESMTP id 7E09D64365 for ; Sun, 23 Jul 2006 14:06:48 -0600 (MDT) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <834399BB-324F-426B-A8F9-708549D228AE@castlepoint.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: l2vpn@ietf.org From: Shane Amante Date: Sun, 23 Jul 2006 14:06:50 -0600 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: draft-sajassi-l2vpn-vpls-bridge-interop-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: , Errors-To: l2vpn-bounces@ietf.org This e-mail indicates the end of the call to make the aforementioned I-D a l2vpn WG draft. Since a significant number of folks recommended this become a WG doc, would the authors please re-publish the draft with the following title, as soon as possible? draft-ietf-l2vpn-vpls-bridge-interop-00 Thanks! -shane & Vach From l2vpn-bounces@ietf.org Sun Jul 23 16:23:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4kUH-0004Wg-2O; Sun, 23 Jul 2006 16:23:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4kUF-0004WT-RK for l2vpn@ietf.org; Sun, 23 Jul 2006 16:23:39 -0400 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4kUE-0002OU-Jo for l2vpn@ietf.org; Sun, 23 Jul 2006 16:23:39 -0400 Received: from [172.16.15.25] (dsl081-098-224.den1.dsl.speakeasy.net [64.81.98.224]) by dog.tcb.net (Postfix) with ESMTP id 6875064365 for ; Sun, 23 Jul 2006 14:23:34 -0600 (MDT) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <06437196-9939-489F-9E27-9D4F1CF5EF6B@castlepoint.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: l2vpn@ietf.org From: Shane Amante Date: Sun, 23 Jul 2006 14:23:36 -0600 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: draft-hemige-serbest-l2vpn-vpls-pim-snooping-01 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org At IETF 66 in Montreal, a substantial number of people at the L2VPN WG meeting agreed to make draft-hemige-serbest-l2vpn-vpls-pim- snooping-01 a L2VPN WG doc. This e-mail begins a call on whether to make this I-D a WG doc within the L2VPN WG. Please indicate to the mailing list whether you do or do not support making this doc a WG draft by no later than Friday, 8/4/2006, 1700 MDT (GMT -6). This draft specifies two procedures for optimizing multicast data traffic within the VPLS cloud when customers use PIM between CE's: 1) PIM snooping (requiring Join Suppression be disabled at CE's); and, 2) PIM proxy on PE's, (when Join Suppression can't/won't be disabled at CE's). As noted in the past, this document is intended to eventually be published as Informational RFC. This draft has been around for a while and presented at several previous L2VPN WG meetings. Thanks! -shane & Vach From l2vpn-bounces@ietf.org Sun Jul 23 20:20:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4oBD-0008VS-Nf; Sun, 23 Jul 2006 20:20:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4oBC-0008Sk-AD for l2vpn@ietf.org; Sun, 23 Jul 2006 20:20:14 -0400 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4oBB-0006yb-IG for l2vpn@ietf.org; Sun, 23 Jul 2006 20:20:14 -0400 Received: from [172.16.15.25] (dsl081-098-224.den1.dsl.speakeasy.net [64.81.98.224]) by dog.tcb.net (Postfix) with ESMTP id B0109642E2; Sun, 23 Jul 2006 18:20:08 -0600 (MDT) In-Reply-To: <75B2A84D9323BC4CA3977CF378CE75EB01BB4180@xmb-sjc-21e.amer.cisco.com> References: <75B2A84D9323BC4CA3977CF378CE75EB01BB4180@xmb-sjc-21e.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Shane Amante Date: Sun, 23 Jul 2006 18:20:11 -0600 To: Ali Sajassi (sajassi) X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: f560cc438c8be83d0aa5c816c29b481c Cc: l2vpn@ietf.org Subject: Re: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05 [FrameworkReview] X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org Hi Ali, Please see below. On Jun 23, 2006, at 12:09 AM, Ali Sajassi (sajassi) wrote: > Shane, > > Thank you for your detailed comments. Please refer to our replies in > line. We will incorporate the ones agreed upon in the next rev. of the > document. > > Regards, > Ali & Dinesh > >> -----Original Message----- >> From: Shane Amante [mailto:shane@castlepoint.net] >> Sent: Sunday, April 09, 2006 9:41 PM >> To: l2vpn@ietf.org >> Subject: Re: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05 >> [FrameworkReview] >> >> Ali, Dinesh, et. al, >> >> As stated in an earlier e-mail, below are the comments >> relating to the Framework section(s). >> >> =================================================================== >> SUBSTANTIATIVE: >> =================================================================== >> >> Section 1: >> I understand the intent to have a comprehensive set of OAM >> reqmt's, but I'm not sure why the L2VPN WG specifically needs >> to take on the breadth of what this statement suggests, >> specifically "a reference model for OAM layering and >> furthermore emphasizes the importance of proper independent >> layering in design and development of OAM functionality across ..." >> Wouldn't proper OAM layering be a topic more suitable for the >> Ops Area? >> ---snip--- >> This document provides a description and a reference model >> for OAM layering and furthermore emphasizes the importance of >> proper independent layering in design and development of OAM >> functionality across L2VPN services, Pseudo Wires (PWs) and >> Public Switched Network (PSN) tunnels. >> ---snip--- >> > > In VPLS because the native Ethernet service is transported over PWs > and > PSN tunnels, it is important to identify the interaction among these > different layers and identify how the failure in PW or PSN transport > layers can impact VPLS service layer and that is why we have > established > this OAM layering model. Also, in the previous discussions, we were > asked to identify the impact of PW and PSN layer failure on VPLS > service > layer. If in addition to L2VPN WG, you would like to present this > layering to Ops area, then please make such recommendation. Perhaps some word-smithing might alleviate this concern. How about this: ---snip--- This document provides a description and reference model for OAM as it relates to L2VPN services, which are comprised of Pseudo Wires (PWs) and Public Switched Network (PSN) tunnels. ---snip--- I'm not sure you need to mention OAM layering or its importance in this paragraph, because that is captured by the phrase "description and reference model for OAM" in the sentence above. It is also captured in much detail throughout the framework portion of the document. >> Section 3.3 (MEPs and MIPs) >> It would be *extremely* useful to address this comment, as it >> relates to "Scalability" of VPLS OAM, in Sections 6 (& 7). >> Specifically, in a mp2p environment like VPLS, it would be >> useful to assert some guidelines as it relates to the number >> of ME's per service instance per PE, (particularly for the >> "sink PE" that is a receiver of n(n-1)/2 ME messages). >> ---snip--- >> A ME is a point-to-point association between a pair of MEPs >> and represents a monitored entity. For example, in a VPLS >> service which involves n CEs, all the MEs associated with the >> VPLS service in the customer OAM domain (i.e. from CE to CE) >> can be considered to be part of a VPLS MEG, where the n-point >> MEG consists of a maximum of n(n-1)/2 MEs. >> ---snip--- >> > > Accept. We will add a sentence or two to indicate that a MEP on a PE > will receive messages from (n-1) other MEPs (on the same or other PEs > for the same ME group). OK. >> Section 4.1.1 (VPLS as Bridged LAN Service) thru 4.1.3 (VPLS as (V) >> LAN >> Emulation): >> I'm not sure I'm comfortable with these sections. >> Specifically, I think what you're describing in Section 4.1.1 >> is VPLS operates as a peer-layer to the native (Ethernet) >> service-layer. In Section 4.1.2, I think you are attempting >> to describe VPLS as a peer-layer as well as a client-layer to >> an underlying MPLS or IP substrate. Finally, I think in >> Section 4.1.3, you're finally up to VPLS as a service-layer >> in its own right. Is that correct? > > No, that is not correct. The intention of this section is to describe > different interpretation of VPLS as reflected in some of the drafts > and > L2VPN framework document because it is important to first clarify what > VPLS refers to, before identifying what OAM tools needed for it. > Section > 4.1.1 is the most common definition for VPLS (e.g., as an end-to-end > multipoint Ethernet service over different types of network). However, > section 4.1.2 and section 4.1.3 talks about different definitions of > VPLS - e.g., as a network where it support multiple of service > instances > and as a LAN emulation part which only contains full mesh of PWs along > with its forwarders and talks about the fact that OAM for those are > handled differently. So, the intention of this section is to clarify > what we mean by VPLS (which is section 4.1.1) and correspondingly what > OAM tools are needed for it. Thanks for providing some context around these sections. A few things might help to be clarified: 1) In 4.1.2, you state that this is out-of-scope for this document; however, it would be useful to state that Sections 4.1.1 and 4.1.3 are what is being addressed by later sections of this OAM document. 2) In Section 4.1.1, it's stated that: ---snip--- To check the end-to-end service integrity, service level OAM mechanisms are needed. ---snip--- I'm not comfortable with the words "service level" as they stand above. Is it referring to the VPLS service level, (e.g.: VPLS-LDP/ VPLS-BGP signaling, VPLS Forwarders as defined in L2VPN framework, etc.) or to the IEEE 802.1 service level or both? Is there another L2VPN (or PWE3) document to which you can provide a pointer as to a definition of 'service layer'? (See the next comment for more context about a suggestion I have to hopefully address this comment). >> If so, then I think we need to be careful in Sections 4.1.1 and >> 4.1.2 when referring the native Ethernet service-layer >> (particularly in the context of the access-layer networks), >> that this is out-of-scope for this work product (and the IETF). > > That is not the case. Please refer to section 11 of vpls-ldp draft. Section 11 of VPLS-LDP states the following: ---snip--- The details regarding bridge operation for MTU-s and PE-rs (e.g., encapsulation format for Q-in-Q messages, customer's Ethernet control protocol handling, etc.) are outside of the scope of this document and they are covered in [802.1ad]. However, the relevant part is the interaction between the bridge module and the MPLS/IP PWs in the PE-rs, which behaves just as in a regular VPLS. ---snip--- The above section from VPLS-LDP states that bridging operation for the MTU-s and PE-rs are outside its scope, but that the interaction between the bridge module and MPLS/IP PWs in the PE-rs are important. I believe this sentence applies to Section 4.1.1 and, subsequently, the OAM requirements section, specifically as it relates to protocols we may create or augment to address OAM of VPLS/ VPWS services. Perhaps it's useful to 'borrow' this paragraph from VPLS-LDP in order to clarify that the 'service-layer' to which you refer in the "VPLS as a Bridged LAN service" section relates directly to this interaction. Because the introduction to Section 6 (VPLS Service OAM Requirements) has a reference back to Section 4.1.1: ---snip--- These requirements are applicable to VPLS as a Bridged LAN service, as described in Section 4.1.1. Further, the performance metrics used in requirements are based on [MEF10] and [RFC2544]. ---snip--- ... I think it's important that you clarify the service-layer. In addition, in Section 6, it would useful to state that although the Framework may provide a comprehensive OAM solution set, the requirements for a L2VPN-defined OAM _protocol suite_ will be a subset of the Framework (along the lines of what VPLS-LDP says) related to those aspects of L2VPN protocols, signaling, etc. previously defined, owned & maintained by the L2VPN WG. >> In addition, in Section 4.1.2, there's a vague statement >> with respect to OAM mechanisms at the "network level". The >> way the current sentence is phrased, I believe you are saying >> that network-layer OAM mechanisms are required; however, it's >> not in our charter to solve MPLS-layer OAM. (Note, to be >> fair, you do say in Section 4.2.1 that OAM at the >> transport-layer is out-of-scope of this doc, but perhaps >> copying/moving that statement up to here would be useful)? >> ---snip--- >> To check the network >> integrity regardless of the network topology, network level >> OAM mechanisms are needed for the VPLS networks. >> ---snip--- >> Related to the last comment, the words "network level" is >> IMO vague. >> Perhaps it would be better to state that it refers to >> network-layer protocols such as MPLS, GRE/IP or L2TPv3? >> > > O.K., we will add a sentence or two to clarify it further. > > >> Section 4.2.2: >> It doesn't look like the lines in the diagram in Figure 4, >> for A, B & C are properly aligned. You should fix them. >> > > Great! We will do that. > >> Section 4.2.3: >> Again, it doesn't look like the diagram in Figure 5 is >> properly aligned with the scenarios depicted in A, B & C. >> > > It looks pretty align to us, but we will search for mis-alignment. If > you can point out expilictly what is misaligned, it would help. > >> Section 4.2.3: >> In general, this section says that it is 'expected' that MEPs >> and MIPs will be implemented into various components of the >> VPLS architecture, (VPLS forwarder/briding modules). Are you >> discussing the OAM framework here, or do these 'expected' >> details surrounding an eventual implementation which would >> mean these would translate into MUSTs or SHOULDs in the >> reqmt's sections? (I'm trying to seek clarity of what you're >> intent is with these statements, because I don't see anything >> related to MEPs and MIPs in the reqmt's section). >> > > Our intention here is to satisfy your previous request as to show the > MEPs and MIPs relate to L2VPN framework. OK. >> Section 4.2.3: >> (D) depicts both MEPs and MIPs, however this sentence only >> discusses expectations around MEPs ... what about the MIPs in >> Scenario (D)? >> ---snip--- >> (D) represents the MEPs and MIPs >> visible within the service provider domain. These MEPs are >> expected to be implemented in the bridge module/VPLS >> forwarder of a PE device, as per the [L2VPN-FRWK]. >> ---snip--- >> > > Agreed. We will clarify it by adding MIPs to the above sentence: > "These > MEPs and MIPs are expected ..." OK. >> Section 4.2.3: >> In which components of the VPLS architecture do you expect >> the MEPs and MIPs in (E) to be implemented? >> > > Agreed. We will clarify this by indicating that the MIPs for (E) would > exist when you have an Ethernet access network (e.g., section 11 of > vpld-ldp draft). OK. >> Section 4.2.4: >> What about VPLS-BGP? What identifiers are used for it, since >> it doesn't use PW-id's? >> > > PW-ids are used in VPLS-BGP but instead they are signaled via BGP > and we > don't care about what signaling mechanism is used. VPLS-LDP uses PWid's. VPLS-BGP uses a demultiplexor label defined as (Label Block + VE ID - VE Block Offset). Perhaps it would useful to clarify that you are referring to the demultiplexor label, in order to be less specific as to one protocol or the other? Alternatively, clarify that with VPLS-BGP it would be what's stated above. >> Section 4.2.4: >> ---snip--- >> Both PW-ids and VLAN tags for a given VPLS instance are >> associated with a Service Identifier (e.g., VPN identifier). >> ---snip--- >> Which identifier do you have in mind, i.e.: VPLS-ID in >> l2vpn-signaling? >> > > By PW-id, it is meant the associated MPLS label. OK. >> Section 5: >> Diagrams aren't aligned Figure 6, VPWS Reference Model. >> > > We must complement you for your keen eyes :-) We will fix it. > > >> Section 5.2: >> What are you trying to say here? >> ---snip--- >> In common scenarios, it could or simply a point-to-point >> interface of certain type. The core network connecting PEs >> can be IP, MPLS, etc. >> ---snip--- >> > > The statement ought to be: "In common scenarios, it could simply be a > point-to-point ... Such as Ethernet PHY" and we will change it. > >> Section 5.2: >> To which network types are you referring? Can you somehow >> reference back to the heterogenous & homogeneous terminology >> introduced in the aforementioned section? >> ---snip--- >> Therefore, it is important that the OAM mechanisms can be >> applied to all these network types. >> ---snip--- >> > > We will change the sentence to "Therefore, it is important that OAM > mechanisms can be applied to different network types some of which > mentioned above" > > >> Section 5.2.1: >> Diagrams in Figure 7 are not aligned properly, and I believe >> you're missing a > describing the right-most end-point in the >> diagram. >> > > Right, We will fix it. > > >> Section 5.2.2: >> Diagrams in Figure 8a & 8b are not aligned properly, and I >> believe you're missing a > describing the right-most >> end-point in the diagram. >> > > That's fine, we'll fix it. > >> Section 5.2.2: >> ---snip--- >> "The service provider is responsible to monitor the PW ME" >> "... the monitoring requirements across the AC ME are minimal." >> ---snip--- >> What is the "PW ME" and "AC ME"? The term "ME" hasn't been >> defined as it related specifically to PW's or AC's. >> Furthermore, does ME refer to the NSP, or some other >> function/layer of VPWS? >> > > Section 1.1 has a clear definition of ME which one can apply to any > types of entity such as service, PW, AC, etc. OK. >> Section 5.2.2: >> ---snip--- >> The >> distinction between Figure 8b (C) and (D) is that (C) MEs >> have MEPs at CE and PEs and have no MIPs while (D) MEs have >> MEPs at CEs and PEs and likely MIPs in between, thereby >> having a visibility to Operator network. >> ---snip--- >> Can you clarify this part of the sentence: "(C) MEs have >> MEPs at CE and PEs and have no MIPs" ... specifically, it's >> not clear at all >> (e.g.: to which devices or components of VPWS) where MEPs and >> MIPs are applicable. >> Can you also clarify the second half of that sentence >> "(D) MEs have MEPs at CEs and PEs and likely MIPs in between, >> thereby having a visibility to Operator network." ... again, >> it's not clear where (e.g.: >> to which devices or components of VPWS) MEPs are MIPs are >> applicable. I think it's just the way you're phrasing it, so >> perhaps re-phrasing in a better way would be good. >> > > We belive the phrasing is causing some confusion to you and we will > further clarify it as: "The distinction between Figure 8(b)-C, and > 8(b)-D is that in (C), MEs have MEPs at CEs and at Pes, and have no > MIPs. While in (D) MEs have MEPs at CEs and at PEs and furthermore, > MIPs > may be present in between the MEPs; thereby providing visibility of > the > network to the operator." OK. [---snipped for brevity---] >> =================================================================== >> EDITORIAL: >> =================================================================== [---snip---] >> 5.2: >> ---snip--- >> As an example, the access network between CE and PE on one >> side can be Ethernet bridged network, ATM network, etc. >> ---snip--- >> s/be Ethernet bridged network/be an Ethernet bridged/ > > Reject. It is intended to say "bridged network" as defined in IEEE > standards I was just asking to insert an 'an' into your sentence. I'm not clear on why you would reject that change? [---snipped to end---] Thanks, -shane From l2vpn-bounces@ietf.org Mon Jul 24 09:34:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G50Zg-0005OZ-Ef; Mon, 24 Jul 2006 09:34:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G50Zf-0005OP-Kf for l2vpn@ietf.org; Mon, 24 Jul 2006 09:34:19 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G50Ze-00080o-6X for l2vpn@ietf.org; Mon, 24 Jul 2006 09:34:19 -0400 Received: from bemail01.netfr.alcatel.fr (bemail01.netfr.alcatel.fr [155.132.251.32]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k6ODYDwg024977 for ; Mon, 24 Jul 2006 15:34:15 +0200 In-Reply-To: <06437196-9939-489F-9E27-9D4F1CF5EF6B@castlepoint.net> To: l2vpn@ietf.org X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Emmanuel.Desmet@alcatel.be Date: Mon, 24 Jul 2006 15:34:12 +0200 X-MIMETrack: Serialize by Router on BEMAIL01/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 07/24/2006 15:34:14 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: Re: draft-hemige-serbest-l2vpn-vpls-pim-snooping-01 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org Positive support for WG I-D, @+ manu Shane Amante cc: Subject: draft-hemige-serbest-l2vpn-vpls-pim-snooping-01 23/07/2006 22:23 At IETF 66 in Montreal, a substantial number of people at the L2VPN WG meeting agreed to make draft-hemige-serbest-l2vpn-vpls-pim- snooping-01 a L2VPN WG doc. This e-mail begins a call on whether to make this I-D a WG doc within the L2VPN WG. Please indicate to the mailing list whether you do or do not support making this doc a WG draft by no later than Friday, 8/4/2006, 1700 MDT (GMT -6). This draft specifies two procedures for optimizing multicast data traffic within the VPLS cloud when customers use PIM between CE's: 1) PIM snooping (requiring Join Suppression be disabled at CE's); and, 2) PIM proxy on PE's, (when Join Suppression can't/won't be disabled at CE's). As noted in the past, this document is intended to eventually be published as Informational RFC. This draft has been around for a while and presented at several previous L2VPN WG meetings. Thanks! -shane & Vach From l2vpn-bounces@ietf.org Mon Jul 24 09:38:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G50dy-0007KX-6w; Mon, 24 Jul 2006 09:38:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G50dw-0007KS-RU for l2vpn@ietf.org; Mon, 24 Jul 2006 09:38:44 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G50dv-0008RU-DN for l2vpn@ietf.org; Mon, 24 Jul 2006 09:38:44 -0400 Received: from gbmail02.netfr.alcatel.fr (gbmail02.netfr.alcatel.fr [155.132.251.26]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k6ODcgHP028480 for ; Mon, 24 Jul 2006 15:38:42 +0200 In-Reply-To: To: l2vpn@ietf.org X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Matthew.Bocci@alcatel.co.uk Date: Mon, 24 Jul 2006 14:38:29 +0100 X-MIMETrack: Serialize by Router on GBMAIL02/GB/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 07/24/2006 14:38:42 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Subject: Re: draft-hemige-serbest-l2vpn-vpls-pim-snooping-01 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org I support making this a WG ID. Matthew Emmanuel DESMET/BE/ALCATEL @ALCATEL To l2vpn@ietf.org 24/07/2006 14:34 cc Subject Re: draft-hemige-serbest-l2vpn-vpls-pim -snooping-01 Positive support for WG I-D, @+ manu Shane Amante cc: Subject: draft-hemige-serbest-l2vpn-vpls-pim-snooping-01 23/07/2006 22:23 At IETF 66 in Montreal, a substantial number of people at the L2VPN WG meeting agreed to make draft-hemige-serbest-l2vpn-vpls-pim- snooping-01 a L2VPN WG doc. This e-mail begins a call on whether to make this I-D a WG doc within the L2VPN WG. Please indicate to the mailing list whether you do or do not support making this doc a WG draft by no later than Friday, 8/4/2006, 1700 MDT (GMT -6). This draft specifies two procedures for optimizing multicast data traffic within the VPLS cloud when customers use PIM between CE's: 1) PIM snooping (requiring Join Suppression be disabled at CE's); and, 2) PIM proxy on PE's, (when Join Suppression can't/won't be disabled at CE's). As noted in the past, this document is intended to eventually be published as Informational RFC. This draft has been around for a while and presented at several previous L2VPN WG meetings. Thanks! -shane & Vach From l2vpn-bounces@ietf.org Mon Jul 24 17:20:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G57qj-0001E1-Od; Mon, 24 Jul 2006 17:20:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G57qi-0001Dw-ON for l2vpn@ietf.org; Mon, 24 Jul 2006 17:20:24 -0400 Received: from mx1.alcatel.com ([192.75.23.73] helo=smtp1.ca.alcatel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G57qh-0000Hl-FA for l2vpn@ietf.org; Mon, 24 Jul 2006 17:20:24 -0400 Received: from CAOTTN03357 (caottvpn-238-008.ca.alcatel.com [138.120.238.8]) by smtp1.ca.alcatel.com (ALCANET) with ESMTP id k6OLK8lE022282; Mon, 24 Jul 2006 16:20:08 -0500 From: "Mustapha Aissaoui" To: "'Shane Amante'" , Date: Mon, 24 Jul 2006 17:20:10 -0400 Message-ID: <003601c6af66$f4556540$08ee788a@ad3.ad.alcatel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <06437196-9939-489F-9E27-9D4F1CF5EF6B@castlepoint.net> Thread-index: AcaulhNfxySOB6ewSZuyb3c6FMcvQgAp8J1Q X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Scanned-By: MIMEDefang 2.51 on 138.120.252.74 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Subject: RE: draft-hemige-serbest-l2vpn-vpls-pim-snooping-01 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org I support this becoming a WG document. Mustapha. > -----Original Message----- > From: Shane Amante [mailto:shane@castlepoint.net] > Sent: Sunday, July 23, 2006 4:24 PM > To: l2vpn@ietf.org > Subject: draft-hemige-serbest-l2vpn-vpls-pim-snooping-01 > > At IETF 66 in Montreal, a substantial number of people at the > L2VPN WG meeting agreed to make draft-hemige-serbest-l2vpn-vpls-pim- > snooping-01 a L2VPN WG doc. This e-mail begins a call on > whether to make this I-D a WG doc within the L2VPN WG. > Please indicate to the mailing list whether you do or do not > support making this doc a WG draft by no later than Friday, > 8/4/2006, 1700 MDT (GMT -6). > > This draft specifies two procedures for optimizing multicast > data traffic within the VPLS cloud when customers use PIM > between CE's: 1) PIM snooping (requiring Join Suppression be > disabled at CE's); and, > 2) PIM proxy on PE's, (when Join Suppression can't/won't be > disabled at CE's). As noted in the past, this document is > intended to eventually be published as Informational RFC. > > This draft has been around for a while and presented at > several previous L2VPN WG meetings. > > Thanks! > > -shane & Vach > > From l2vpn-bounces@ietf.org Mon Jul 24 17:26:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G57wo-0004cr-Ae; Mon, 24 Jul 2006 17:26:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G57wm-0004XQ-A0 for l2vpn@ietf.org; Mon, 24 Jul 2006 17:26:40 -0400 Received: from hicks.ciena.com ([63.118.34.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G57wk-000109-33 for l2vpn@ietf.org; Mon, 24 Jul 2006 17:26:40 -0400 Received: from mdmail4.ciena.com (HELO mdmxm01.ciena.com) ([63.118.39.26]) by hicks.ciena.com with ESMTP; 24 Jul 2006 17:45:57 -0400 X-IronPort-AV: i="4.07,176,1151899200"; d="scan'208"; a="60191430:sNHT26886416" Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 24 Jul 2006 17:25:09 -0400 Message-ID: <3C13767EA2F93441AFB13A630204F1B203A379@mamxm02.ciena.com> In-Reply-To: <06437196-9939-489F-9E27-9D4F1CF5EF6B@castlepoint.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-hemige-serbest-l2vpn-vpls-pim-snooping-01 Thread-Index: AcaulhHmUTXUNIE5SL6Blzucyck/TgA0YLbg From: "Shah, Himanshu" To: "Shane Amante" , X-OriginalArrivalTime: 24 Jul 2006 21:25:23.0571 (UTC) FILETIME=[AC694430:01C6AF67] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Subject: RE: draft-hemige-serbest-l2vpn-vpls-pim-snooping-01 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org I support this draft to become a WG doc. > -----Original Message----- > From: Shane Amante [mailto:shane@castlepoint.net] > Sent: Sunday, July 23, 2006 4:24 PM > To: l2vpn@ietf.org > Subject: draft-hemige-serbest-l2vpn-vpls-pim-snooping-01 >=20 >=20 > At IETF 66 in Montreal, a substantial number of people at the L2VPN =20 > WG meeting agreed to make draft-hemige-serbest-l2vpn-vpls-pim-=20 > snooping-01 a L2VPN WG doc. This e-mail begins a call on whether to =20 > make this I-D a WG doc within the L2VPN WG. Please indicate to the =20 > mailing list whether you do or do not support making this doc a WG =20 > draft by no later than Friday, 8/4/2006, 1700 MDT (GMT -6). >=20 > This draft specifies two procedures for optimizing multicast data =20 > traffic within the VPLS cloud when customers use PIM between=20 > CE's: 1) =20 > PIM snooping (requiring Join Suppression be disabled at CE's); and, =20 > 2) PIM proxy on PE's, (when Join Suppression can't/won't be disabled =20 > at CE's). As noted in the past, this document is intended to =20 > eventually be published as Informational RFC. >=20 > This draft has been around for a while and presented at several =20 > previous L2VPN WG meetings. >=20 > Thanks! >=20 > -shane & Vach >=20 From l2vpn-bounces@ietf.org Mon Jul 24 18:48:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G59Dy-0001kR-FL; Mon, 24 Jul 2006 18:48:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G59Dx-0001kM-QG for l2vpn@ietf.org; Mon, 24 Jul 2006 18:48:29 -0400 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G59Dw-0002Vu-Fa for l2vpn@ietf.org; Mon, 24 Jul 2006 18:48:29 -0400 Received: by ug-out-1314.google.com with SMTP id m2so2592556uge for ; Mon, 24 Jul 2006 15:48:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=pF8CWc3Txycqsh4VUE0qQNO+Sz92GbCIFUE4dr7+yHjIjeC84enhQdGPBF/Wo7Jb7WX5G8C8xfE2cVZVLexWrMlZlKmOwO9CAi0MyO+sufpruwRFKmvWDO/oT52Ozrk1j/33h92Ig297Ytu2LgUDILD6Nw6vX3EbyKx25aeOUQ8= Received: by 10.78.151.15 with SMTP id y15mr2035928hud; Mon, 24 Jul 2006 15:48:26 -0700 (PDT) Received: by 10.78.172.7 with HTTP; Mon, 24 Jul 2006 15:48:26 -0700 (PDT) Message-ID: Date: Mon, 24 Jul 2006 15:48:26 -0700 From: "Ray Qiu" To: "Shane Amante" In-Reply-To: <06437196-9939-489F-9E27-9D4F1CF5EF6B@castlepoint.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2862_5068751.1153781306446" References: <06437196-9939-489F-9E27-9D4F1CF5EF6B@castlepoint.net> X-Spam-Score: 0.5 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: l2vpn@ietf.org Subject: Re: draft-hemige-serbest-l2vpn-vpls-pim-snooping-01 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org ------=_Part_2862_5068751.1153781306446 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I support this draft to become a WG document. Thanks, Ray On 7/23/06, Shane Amante wrote: > > At IETF 66 in Montreal, a substantial number of people at the L2VPN > WG meeting agreed to make draft-hemige-serbest-l2vpn-vpls-pim- > snooping-01 a L2VPN WG doc. This e-mail begins a call on whether to > make this I-D a WG doc within the L2VPN WG. Please indicate to the > mailing list whether you do or do not support making this doc a WG > draft by no later than Friday, 8/4/2006, 1700 MDT (GMT -6). > > This draft specifies two procedures for optimizing multicast data > traffic within the VPLS cloud when customers use PIM between CE's: 1) > PIM snooping (requiring Join Suppression be disabled at CE's); and, > 2) PIM proxy on PE's, (when Join Suppression can't/won't be disabled > at CE's). As noted in the past, this document is intended to > eventually be published as Informational RFC. > > This draft has been around for a while and presented at several > previous L2VPN WG meetings. > > Thanks! > > -shane & Vach > > ------=_Part_2862_5068751.1153781306446 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I support this draft to become a WG document.
 
Thanks,
Ray

 
On 7/23/06, Shane Amante <shane@castlepoint.net> wrote:
At IETF 66 in Montreal, a substantial number of people at the L2VPN
WG meeting agreed to make draft-hemige-serbest-l2vpn-vpls-pim-
snooping-01 a L2VPN WG doc.  This e-mail begins a call on whether to
make this I-D a WG doc within the L2VPN WG.  Please indicate to the
mailing list whether you do or do not support making this doc a WG
draft by no later than Friday, 8/4/2006, 1700 MDT (GMT -6).

This draft specifies two procedures for optimizing multicast data
traffic within the VPLS cloud when customers use PIM between CE's: 1)
PIM snooping (requiring Join Suppression be disabled at CE's); and,
2) PIM proxy on PE's, (when Join Suppression can't/won't be disabled
at CE's).  As noted in the past, this document is intended to
eventually be published as Informational RFC.

This draft has been around for a while and presented at several
previous L2VPN WG meetings.

Thanks!

-shane & Vach


------=_Part_2862_5068751.1153781306446-- From l2vpn-bounces@ietf.org Mon Jul 24 21:28:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Bip-0003Os-Es; Mon, 24 Jul 2006 21:28:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Bio-0003On-PQ for l2vpn@ietf.org; Mon, 24 Jul 2006 21:28:30 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Bim-00028n-0W for l2vpn@ietf.org; Mon, 24 Jul 2006 21:28:30 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2X00AHKRIAY6@szxga02-in.huawei.com> for l2vpn@ietf.org; Tue, 25 Jul 2006 09:44:34 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2X00GW9RIAUQ@szxga02-in.huawei.com> for l2vpn@ietf.org; Tue, 25 Jul 2006 09:44:34 +0800 (CST) Received: from c50408 ([10.111.12.53]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J2X00C0SR94H4@szxml04-in.huawei.com> for l2vpn@ietf.org; Tue, 25 Jul 2006 09:39:05 +0800 (CST) Date: Tue, 25 Jul 2006 09:27:34 +0800 From: Cao Wei To: Shane Amante , l2vpn@ietf.org Message-id: <00d201c6af89$81b45fa0$350c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <06437196-9939-489F-9E27-9D4F1CF5EF6B@castlepoint.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Subject: Re: draft-hemige-serbest-l2vpn-vpls-pim-snooping-01 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org Support this draft become a WG doc. ----- Original Message ----- From: "Shane Amante" To: Sent: Monday, July 24, 2006 4:23 AM Subject: draft-hemige-serbest-l2vpn-vpls-pim-snooping-01 > At IETF 66 in Montreal, a substantial number of people at the L2VPN > WG meeting agreed to make draft-hemige-serbest-l2vpn-vpls-pim- > snooping-01 a L2VPN WG doc. This e-mail begins a call on whether to > make this I-D a WG doc within the L2VPN WG. Please indicate to the > mailing list whether you do or do not support making this doc a WG > draft by no later than Friday, 8/4/2006, 1700 MDT (GMT -6). > > This draft specifies two procedures for optimizing multicast data > traffic within the VPLS cloud when customers use PIM between CE's: 1) > PIM snooping (requiring Join Suppression be disabled at CE's); and, > 2) PIM proxy on PE's, (when Join Suppression can't/won't be disabled > at CE's). As noted in the past, this document is intended to > eventually be published as Informational RFC. > > This draft has been around for a while and presented at several > previous L2VPN WG meetings. > > Thanks! > > -shane & Vach > > From l2vpn-bounces@ietf.org Mon Jul 24 23:20:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5DT9-00076q-Er; Mon, 24 Jul 2006 23:20:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5DT7-00076l-KY for l2vpn@ietf.org; Mon, 24 Jul 2006 23:20:25 -0400 Received: from hostree9f.alcatel.com ([143.209.238.159] helo=audl952.usa.alcatel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5DT6-0006CR-AD for l2vpn@ietf.org; Mon, 24 Jul 2006 23:20:25 -0400 Received: from mvrelay.mv.usa.alcatel.com (mvrelay.mv.usa.alcatel.com [128.251.10.15]) by audl952.usa.alcatel.com (ALCANET) with ESMTP id k6P3KK7N029309; Mon, 24 Jul 2006 22:20:21 -0500 Received: from vkompellaxp (localhost [127.0.0.1]) by mvrelay.mv.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id k6P3Kmx9007058; Mon, 24 Jul 2006 20:20:49 -0700 (PDT) From: "Vach Kompella" To: "'Shane Amante'" , Date: Mon, 24 Jul 2006 20:20:25 -0700 Message-ID: <023701c6af99$45d59480$cab816ac@eng.timetra.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-reply-to: <06437196-9939-489F-9E27-9D4F1CF5EF6B@castlepoint.net> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Importance: Normal X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Subject: RE: draft-hemige-serbest-l2vpn-vpls-pim-snooping-01 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org Support making it a WG doc. -Vach=20 > -----Original Message----- > From: Shane Amante [mailto:shane@castlepoint.net]=20 > Sent: Sunday, July 23, 2006 1:24 PM > To: l2vpn@ietf.org > Subject: draft-hemige-serbest-l2vpn-vpls-pim-snooping-01 >=20 >=20 > At IETF 66 in Montreal, a substantial number of people at the L2VPN =20 > WG meeting agreed to make draft-hemige-serbest-l2vpn-vpls-pim-=20 > snooping-01 a L2VPN WG doc. This e-mail begins a call on whether to =20 > make this I-D a WG doc within the L2VPN WG. Please indicate to the =20 > mailing list whether you do or do not support making this doc a WG =20 > draft by no later than Friday, 8/4/2006, 1700 MDT (GMT -6). >=20 > This draft specifies two procedures for optimizing multicast data =20 > traffic within the VPLS cloud when customers use PIM between=20 > CE's: 1) =20 > PIM snooping (requiring Join Suppression be disabled at CE's); and, =20 > 2) PIM proxy on PE's, (when Join Suppression can't/won't be disabled =20 > at CE's). As noted in the past, this document is intended to =20 > eventually be published as Informational RFC. >=20 > This draft has been around for a while and presented at several =20 > previous L2VPN WG meetings. >=20 > Thanks! >=20 > -shane & Vach >=20 From l2vpn-bounces@ietf.org Tue Jul 25 12:58:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5QEb-0006HZ-0C; Tue, 25 Jul 2006 12:58:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5QEa-0006HU-5h for l2vpn@ietf.org; Tue, 25 Jul 2006 12:58:16 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5QEX-00073j-R8 for l2vpn@ietf.org; Tue, 25 Jul 2006 12:58:16 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 25 Jul 2006 09:58:13 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6PGwD6D021556; Tue, 25 Jul 2006 09:58:13 -0700 Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6PGwC2D014317; Tue, 25 Jul 2006 09:58:13 -0700 (PDT) Received: from [171.69.52.191] (dhcp-171-69-52-191.cisco.com [171.69.52.191]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id JAA27010; Tue, 25 Jul 2006 09:57:22 -0700 (PDT) In-Reply-To: <06437196-9939-489F-9E27-9D4F1CF5EF6B@castlepoint.net> References: <06437196-9939-489F-9E27-9D4F1CF5EF6B@castlepoint.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <173F50EB-C2C5-4244-B856-8C056A5B4A71@cisco.com> Content-Transfer-Encoding: 7bit From: Yiqun Cai Date: Tue, 25 Jul 2006 09:57:05 -0700 To: Shane Amante X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=1401; t=1153846693; x=1154710693; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ycai@cisco.com; z=From:Yiqun=20Cai=20 |Subject:Re=3A=20draft-hemige-serbest-l2vpn-vpls-pim-snooping-01; X=v=3Dcisco.com=3B=20h=3DCu2BjVaTge8Jwgi62uXztCTHYkU=3D; b=acQ1rjCibgYjYs+mEY1bzgerD0RWHXDJk6yWXiaPHjHT8Sfb3FxwTZWIkGynNnw8yKDO61y5 kEvmt0WQ/BQmgNV2RAhCWImsHkAA0yLaTg1Ce7REIIlA4QqiUmWSZYOP; Authentication-Results: sj-dkim-1.cisco.com; header.From=ycai@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: l2vpn@ietf.org Subject: Re: draft-hemige-serbest-l2vpn-vpls-pim-snooping-01 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org A large part of the draft describes the function and behavior of PIM snooping/proxy that is not specific to VPLS. IMO, the specification is more suited for PIM or mboned WG. Therefore, I suggest we separate this draft into two, and then discuss whether we should adopt the work to use PIM snooping/proxy to solve multicast in VPLS. Thanks. On Jul 23, 2006, at 1:23 PM, Shane Amante wrote: > At IETF 66 in Montreal, a substantial number of people at the L2VPN > WG meeting agreed to make draft-hemige-serbest-l2vpn-vpls-pim- > snooping-01 a L2VPN WG doc. This e-mail begins a call on whether > to make this I-D a WG doc within the L2VPN WG. Please indicate to > the mailing list whether you do or do not support making this doc a > WG draft by no later than Friday, 8/4/2006, 1700 MDT (GMT -6). > > This draft specifies two procedures for optimizing multicast data > traffic within the VPLS cloud when customers use PIM between CE's: > 1) PIM snooping (requiring Join Suppression be disabled at CE's); > and, 2) PIM proxy on PE's, (when Join Suppression can't/won't be > disabled at CE's). As noted in the past, this document is intended > to eventually be published as Informational RFC. > > This draft has been around for a while and presented at several > previous L2VPN WG meetings. > > Thanks! > > -shane & Vach -- Yiqun From l2vpn-bounces@ietf.org Tue Jul 25 14:17:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5RTb-0004cB-Ki; Tue, 25 Jul 2006 14:17:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5RTZ-0004c0-TA for l2vpn@ietf.org; Tue, 25 Jul 2006 14:17:49 -0400 Received: from [64.171.8.242] (helo=note-back.accton.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5RTY-0002KY-G2 for l2vpn@ietf.org; Tue, 25 Jul 2006 14:17:49 -0400 To: "Thomas D. Nadeau" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: anilr@accton.com Date: Tue, 25 Jul 2006 14:28:08 -0400 X-MIMETrack: Serialize by Router on note-back/AcctonUS(Release 5.0.8 |June 18, 2001) at 07/25/2006 11:17:58 AM MIME-Version: 1.0 Content-type: text/plain; charset=big5 Content-transfer-encoding: base64 X-Spam-Score: 1.2 (+) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: l2vpn@ietf.org, 'Shane Amante' Subject: Re: [L2VPN] comments on VPLS MIB X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org DQpUb20sDQoNCkluIHJlc3BvbnNlIHRvIHlvdXIgcmVxdWVzdCBmb3Igc3BlY2lmaWMgb2JqZWN0 cywgcGxlYXNlIHNlZSBmb2xsb3dpbmcNCm1hcmtlZCAibmV3Ii4NCg0KVnBsc0NvbmZpZ0VudHJ5 IDo6PQ0KICBTRVFVRU5DRSB7DQogICAgdnBsc0luZGV4ICAgICAgICAgICAgICAgICAgICAgICAg VW5zaWduZWQzMiwNCiAgIC0tIGV4aXN0aW5nIHN0dWZmIC0tDQogICAgdnBsc01lc2hQZWVyQ291 bnQgICAgICAgICAgICAgICAgQ291bnRlciwgLS0gbmV3DQogICAgdnBsc1Nwb2tlUGVlckNvdW50 ICAgICAgICAgICAgICAgQ291bnRlciwgLS0gbmV3DQogICAgdnBsc1NlcnZpY2VUeXBlICAgICAg ICAgICAgICAgICAgSU5URUdFUiwgLS0gbmV3DQogICAgdnBsc010dSAgICAgICAgICAgICAgICAg ICAgICAgICAgVW5zaWduZWQzMiwgLS0gbmV3DQogICAgdnBsc1Jvd1N0YXR1cyAgICAgICAgICAg ICAgICAgICAgUm93U3RhdHVzDQogICAgfQ0KDQp2cGxzTWVzaFBlZXJDb3VudCBPQkpFQ1QtVFlQ RQ0KICAgIFNZTlRBWCAgICAgICAgICBDb3VudGVyDQogICAgTUFYLUFDQ0VTUyAgICAgIHJlYWQt b25seQ0KICAgIFNUQVRVUyAgICAgICAgICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAg ICAgICJUaGlzIG9iamVjdCBzcGVjaWZpZXMgdGhlIG51bWJlciBvZiBtZXNoIHBlZXJzDQogICAg ICAgICBwcmVzZW50IGluIHRoaXMgdnBscyBpbnN0YW5jZS4iDQogICAgOjo9IHsgdnBsc0NvbmZp Z0VudHJ5IDEyIH0NCg0KdnBsc1Nwb2tlUGVlckNvdW50IE9CSkVDVC1UWVBFDQogICAgU1lOVEFY ICAgICAgICAgIENvdW50ZXINCiAgICBNQVgtQUNDRVNTICAgICAgcmVhZC1vbmx5DQogICAgU1RB VFVTICAgICAgICAgIGN1cnJlbnQNCiAgICBERVNDUklQVElPTg0KICAgICAgICAgIlRoaXMgb2Jq ZWN0IHNwZWNpZmllcyB0aGUgbnVtYmVyIG9mIHNwb2tlIHBlZXJzDQogICAgICAgICBwcmVzZW50 IGluIHRoaXMgdnBscyBpbnN0YW5jZS4iDQogICAgOjo9IHsgdnBsc0NvbmZpZ0VudHJ5IDEzIH0N Cg0KdnBsc1NlcnZpY2VUeXBlIE9CSkVDVC1UWVBFDQogICAgU1lOVEFYICAgICAgICAgIElOVEVH RVIgew0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICB2bGFuICAgICAgICAoMSksDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgIGV0aGVybmV0ICAgICgyKQ0KICAgICAgICAgICAgICAg ICAgICAgfQ0KICAgIE1BWC1BQ0NFU1MgICAgICByZWFkLW9ubHkNCiAgICBTVEFUVVMgICAgICAg ICAgY3VycmVudA0KICAgIERFU0NSSVBUSU9ODQogICAgICAgICAiVGhpcyBvYmplY3Qgc3BlY2lm aWVzIHRoZSB0eXBlIG9mIHNlcnZpY2UgYmVpbmcNCiAgICAgICAgIGVtdWxhdGVkIGJ5IHRoaXMg dnBscyBpbnN0YW5jZS4iDQogICAgOjo9IHsgdnBsc0NvbmZpZ0VudHJ5IDE0IH0NCg0KdnBsc010 dSBPQkpFQ1QtVFlQRQ0KICAgIFNZTlRBWCAgICAgICAgICBVbnNpZ25lZDMyICg2NC4uMTUxOCkN CiAgICBNQVgtQUNDRVNTICAgICAgcmVhZC1jcmVhdGUNCiAgICBTVEFUVVMgICAgICAgICAgY3Vy cmVudA0KICAgIERFU0NSSVBUSU9ODQogICAgICAgICAiVGhpcyBvYmplY3Qgc3BlY2lmaWVzIHRo ZSBNVFUgb2YgdGhpcyB2cGxzIGluc3RhbmNlLiINCiAgICBERUZWQUwgICAgICAgICAgeyAxNTE4 IH0NCiAgICA6Oj0geyB2cGxzQ29uZmlnRW50cnkgMTUgfQ0KDQoNClZwbHNQd0JpbmRFbnRyeSA6 Oj0NCiAgICBTRVFVRU5DRSB7DQogICAgICAgIHZwbHNQd0luZGV4ICAgICAgICAgICAgICAgICAg ICAgUHdJbmRleFR5cGUsDQogICAgICAgIC0tIGV4aXN0aW5nIHN0dWZmIC0tDQogICAgICAgIHZw bHNQd1R5cGUgICAgICAgICAgICAgICAgICAgICAgSU5URUdFUiwgLS0gbmV3DQogICAgICAgIHZw bHNQd0JpbmRSb3dTdGF0dXMgICAgICAgICAgICAgUm93U3RhdHVzDQogICAgfQ0KDQp2cGxzUHdU eXBlICAgT0JKRUNULVRZUEUNCiAgICAgU1lOVEFYICAgICAgICAgIElOVEVHRVIgew0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBtZXNoICAoMSksDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHNwb2tlICgyKQ0KICAgICAgICAgICAgICAgICAgICAgfQ0KICAgICBNQVgtQUNDRVNT ICAgICAgcmVhZC1jcmVhdGUNCiAgICAgU1RBVFVTICAgICAgICAgIGN1cnJlbnQNCiAgICAgREVT Q1JJUFRJT04NCiAgICAgICAgICAiVGhlIHZhbHVlIG9mIHRoaXMgb2JqZWN0IGluZGljYXRlcw0K ICAgICAgICAgICB3aGV0aGVyIHRoZSBQc2V1ZG8gV2lyZSBpcyBvZiB0eXBlIG1lc2ggb3Igc3Bv a2UuIg0KICAgICBERUZWQUwgICAgICAgeyAwIH0NCiAgICA6Oj0geyB2cGxzUHdCaW5kRW50cnkg MiB9DQoNClJlZ2FyZHMsDQpBbmlsDQo= From l2vpn-bounces@ietf.org Tue Jul 25 14:23:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5RZS-0005YG-QL; Tue, 25 Jul 2006 14:23:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5RZR-0005YB-QF for l2vpn@ietf.org; Tue, 25 Jul 2006 14:23:53 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5RZP-0003p8-8L for l2vpn@ietf.org; Tue, 25 Jul 2006 14:23:53 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 25 Jul 2006 14:23:51 -0400 X-IronPort-AV: i="4.07,180,1151899200"; d="scan'208"; a="93863259:sNHT26499282" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6PINos3021212; Tue, 25 Jul 2006 14:23:50 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6PINo7t011369; Tue, 25 Jul 2006 14:23:50 -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.1830); Tue, 25 Jul 2006 14:23:50 -0400 Received: from [161.44.71.206] ([161.44.71.206]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 14:23:49 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Date: Tue, 25 Jul 2006 14:24:04 -0400 To: anilr@accton.com X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 25 Jul 2006 18:23:50.0030 (UTC) FILETIME=[79C492E0:01C6B017] DKIM-Signature: a=rsa-sha1; q=dns; l=2875; t=1153851830; x=1154715830; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tnadeau@cisco.com; z=From:=22Thomas=20D.=20Nadeau=22=20 |Subject:Re=3A=20[L2VPN]=20comments=20on=20VPLS=20MIB |To:anilr@accton.com; X=v=3Dcisco.com=3B=20h=3DaE9xbCbC9/+M23g+rFuPPbKkDa8=3D; b=gq0hXUQNiqrEv68F8mDQ1aacBSY4NlopnN/+cPgTNnY5OPVZI3qOew02tKdOUgyF4jCDxBje ECsjHvxRi4MpkFZOc39luMteuRJJmK9QXL9C1REvOFRe10oFplJPMbwV; Authentication-Results: rtp-dkim-1.cisco.com; header.From=tnadeau@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: l2vpn@ietf.org, 'Shane Amante' Subject: Re: [L2VPN] comments on VPLS MIB X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org On Jul 25, 2006, at 2:28 PM, anilr@accton.com wrote: > > Tom, > > In response to your request for specific objects, please see following > marked "new". > > VplsConfigEntry ::= > SEQUENCE { > vplsIndex Unsigned32, > -- existing stuff -- > vplsMeshPeerCount Counter, -- new > vplsSpokePeerCount Counter, -- new > vplsServiceType INTEGER, -- new > vplsMtu Unsigned32, -- new > vplsRowStatus RowStatus > } This is the configuration section. Why would we put status-related objects in this section? > > vplsMeshPeerCount OBJECT-TYPE > SYNTAX Counter > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This object specifies the number of mesh peers > present in this vpls instance." > ::= { vplsConfigEntry 12 } > > vplsSpokePeerCount OBJECT-TYPE > SYNTAX Counter > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This object specifies the number of spoke peers > present in this vpls instance." > ::= { vplsConfigEntry 13 } > > vplsServiceType OBJECT-TYPE > SYNTAX INTEGER { > vlan (1), > ethernet (2) > } > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This object specifies the type of service being > emulated by this vpls instance." > ::= { vplsConfigEntry 14 } > > vplsMtu OBJECT-TYPE > SYNTAX Unsigned32 (64..1518) > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "This object specifies the MTU of this vpls instance." > DEFVAL { 1518 } > ::= { vplsConfigEntry 15 } > > > VplsPwBindEntry ::= > SEQUENCE { > vplsPwIndex PwIndexType, > -- existing stuff -- > vplsPwType INTEGER, -- new > vplsPwBindRowStatus RowStatus > } > > vplsPwType OBJECT-TYPE > SYNTAX INTEGER { > mesh (1), > spoke (2) > } > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The value of this object indicates > whether the Pseudo Wire is of type mesh or spoke." > DEFVAL { 0 } > ::= { vplsPwBindEntry 2 } This was originally in one of the MIBs we merged in, but was removed because it was felt that this was more of a convenience than anything else. Also, how do you describe a partial-mesh? --Tom > > Regards, > Anil From l2vpn-bounces@ietf.org Tue Jul 25 14:31:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5RhA-0002iR-A2; Tue, 25 Jul 2006 14:31:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Rh9-0002g0-2p for l2vpn@ietf.org; Tue, 25 Jul 2006 14:31:51 -0400 Received: from [64.171.8.242] (helo=note-back.accton.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Rh7-0006OU-N2 for l2vpn@ietf.org; Tue, 25 Jul 2006 14:31:51 -0400 To: "Vach Kompella" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: anilr@accton.com Date: Tue, 25 Jul 2006 14:42:10 -0400 X-MIMETrack: Serialize by Router on note-back/AcctonUS(Release 5.0.8 |June 18, 2001) at 07/25/2006 11:31:59 AM MIME-Version: 1.0 Content-type: text/plain; charset=big5 Content-transfer-encoding: base64 X-Spam-Score: 1.2 (+) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: l2vpn@ietf.org Subject: Re: draft-sajassi-l2vpn-vpls-bridge-interop-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: , Errors-To: l2vpn-bounces@ietf.org DQpWYWNoLA0KDQpUaGFua3MgZm9yIHlvdXIgcmVzcG9uc2UuIEkgaGF2ZSBhIGNvbW1lbnQgb24g b25lIG9mIHlvdXIgYW5zd2Vycy4NCg0KPj4gTWVudGlvbiBpcyBtYWRlIG9mIHNldmVyYWwgaW50 ZXJvcGVyYWJpbGl0eSBpc3N1ZXMgd2hpY2ggYXJlDQo+PiBub3QgYWRkcmVzc2VkIG9uZSB3YXkg b3IgYW5vdGhlciwgZS5nLiBob3cgc2hvdWxkIHZhcmlvdXMNCj4+ICJzbG93IiA4MDIgcHJvdG9j b2xzIGJlIGRlYWx0IHdpdGg/IFRoZSBhbnN3ZXIgbWF5IGJlDQo+PiBkaWZmZXJlbnQgZm9yIGRp ZmZlcmVudCBleGlzdGluZyBwcm90b2NvbHMsIGFuZCBtYXkgYmUNCj4+IGRpZmZlcmVudCBmb3Ig dW5yZWNvZ25pemVkIHByb3RvY29scy4NCj4NCj4gVGhpcyBkcmFmdCB3aWxsIG9ubHkgY2FwdHVy ZSB0aGUgaXNzdWVzLCBhbmQgbWF5IGFsc28gaW5jbHVkZSB0aGUNCj4gY29tcGxleGl0aWVzIG9m IHRoZSBwcm9ibGVtcyBzdWNoIGFzIHRob3NlIHlvdSBtZW50aW9uLCBidXQgd2lsbA0KPiBub3Qg cHJlc2VudCBzb2x1dGlvbnMgZm9yIHRoZW0uDQoNCldoeSBpcyB0aGlzPyBJdCBzZWVtcyB0byBt ZSB0aGF0IGRpZmZlcmVudCB2ZW5kb3JzJyBoYW5kbGluZyBvZg0KaW50ZXJvcGVyYWJpbGl0eSBp c3N1ZXMgd2l0aCBsZWdhY3kgZXF1aXBtZW50IHRoZSBzYW1lIHdheSB3b3VsZCBhbGxvdyB0aGVt DQp0byB3b3JrIHRvZ2V0aGVyIHRvIGludGVyY29ubmVjdCBpbiBhIG1vcmUgc2VhbWxlc3MgbWFu bmVyIHRoYW4gb3RoZXJ3aXNlLg0KDQpJZiBhIHByb3RvY29sIGlzIGhhbmRsZWQgb25lIHdheSBi eSBhIFZQTFMgbm9kZSBhbmQgYSBkaWZmZXJlbnQgd2F5IGJ5IGl0cw0KcGVlciBhdCB0aGUgb3Ro ZXIgZW5kIG9mIHRoZSBwc2V1ZG93aXJlLCB0aGF0IGRvZXNuJ3Qgc291bmQgbGlrZSBpdCB3b3Vs ZA0KYmUgaGVhbHRoeSBmb3IgdGhlIHByb3RvY29sLiBUaGF0IHByb2JsZW0gY291bGQgb2YgY291 cnNlIGJlIGF2ZXJ0ZWQgYnkNCnVzaW5nIGVxdWlwbWVudCBmcm9tIHRoZSBzYW1lIHZlbmRvciBp biBhbnkgZ2l2ZW4gVlBMUyBpbnN0YW5jZSwgYnV0IEkNCnN1c3BlY3QgdGhhdCdzIGEgcmVzdHJp Y3Rpb24geW91IGRvbid0IHdhbnQuDQoNClJlZ2FyZHMsDQpBbmlsDQo= From l2vpn-bounces@ietf.org Tue Jul 25 14:45:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Rue-00081S-Sg; Tue, 25 Jul 2006 14:45:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Rud-0007zE-Io for l2vpn@ietf.org; Tue, 25 Jul 2006 14:45:47 -0400 Received: from [64.171.8.242] (helo=note-back.accton.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Ruc-0000kD-22 for l2vpn@ietf.org; Tue, 25 Jul 2006 14:45:47 -0400 To: "Thomas D. Nadeau" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: anilr@accton.com Date: Tue, 25 Jul 2006 14:56:06 -0400 X-MIMETrack: Serialize by Router on note-back/AcctonUS(Release 5.0.8 |June 18, 2001) at 07/25/2006 11:45:55 AM MIME-Version: 1.0 Content-type: text/plain; charset=big5 Content-transfer-encoding: base64 X-Spam-Score: 1.2 (+) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: l2vpn@ietf.org, 'Shane Amante' Subject: Re: [L2VPN] comments on VPLS MIB X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org DQpUb20sDQoNClRoZSBjb25maWcgdGFibGUgYXMgeW91IGhhdmUgaXQgaGFzIGEgY291cGxlIHN0 YXR1cyBvYmplY3RzIGluDQp2cGxzT3BlclN0YXR1cyBhbmQgdnBsc1ZwbklkLiBQZXJoYXBzIGl0 IGNhbiBiZSBicm9rZW4gdXAgaW50byBzdGF0dXMgYW5kDQpjb25maWcgdGFibGVzPyBUaGF0LCBv ciBwZXJoYXBzIHNpbXBseSByZW5hbWUgaXQgc28gdGhhdCBpdCBjYW4gY29udGFpbg0KcmVhZC1v bmx5IGFzIHdlbGwgYXMgcmVhZC13cml0ZSBlbnRyaWVzLg0KDQpSZSBob3cgdG8gaW5kaWNhdGUg d2hldGhlciBpdCdzIGEgcGFydGlhbC1tZXNoIHBzZXVkb3dpcmU6IGFzIGZhciBhcyBJDQpjb3Vs ZCBnYXRoZXIgZnJvbSBWYWNoJ3MgYW5zd2VyLCB0aGF0IGlzIG5vdCBwYXJ0IG9mIHRoZSBiYXNp YyBWUExTDQphcmNoaXRlY3R1cmUuIFRoaXMgbGVhZHMgbWUgdG8gYmVsaWV2ZSBpdCdzIGEgdmVu ZG9yLXNwZWNpZmljIGlzc3VlLCBvciBkbw0KSSBub3QgdW5kZXJzdGFuZCB0aGUgaXNzdWUgY29y cmVjdGx5PyBPbmUgd2F5IHRvIGRlYWwgd2l0aCB0aGlzIHNvcnQgb2YNCnRoaW5nIHdlJ3ZlIHVz ZWQgaW4gSUVURiBNSUJzIEkndmUgd3JpdHRlbiBpbiB0aGUgcGFzdCBpcyB0byBhZGQgYW4NCmVu dW1lcmF0aW9uIG9mICdvdGhlcicgKEknbSBwcmV0dHkgc3VyZSB3ZSBkaWQgdGhhdCBpbiBSRkMx NDkzLCBCcmlkZ2UNCk1JQikuDQoNClJlZ2FyZHMsDQpBbmlsDQoNCg0KDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAg ICAgICAgICAgICJUaG9tYXMgRC4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAg ICAgICAgICAgICAgIE5hZGVhdSIgICAgICAgICAgICAgIFRvOiAgICAgYW5pbHJAYWNjdG9uLmNv bSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAg ICAgICAgICAgICAgICAgIDx0bmFkZWF1QGNpc2NvICAgICAgIGNjOiAgICAgbDJ2cG5AaWV0Zi5v cmcsICInU2hhbmUgQW1hbnRlJyIgPHNoYW5lQGNhc3RsZXBvaW50Lm5ldD4gICAgICAgICAgDQog ICAgICAgICAgICAgICAgICAgIC5jb20+ICAgICAgICAgICAgICAgIFN1YmplY3Q6ICAgICBSZTog W0wyVlBOXSBjb21tZW50cyBvbiBWUExTIE1JQiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgDQogICAgICAgICAgICAgICAgICAgIDA3LzI1LzIwMDYgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgDQogICAgICAgICAgICAgICAgICAgIDAyOjI0IFBNICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgDQoNCg0KDQoNCg0KT24gSnVsIDI1LCAyMDA2LCBhdCAyOjI4IFBNLCBh bmlsckBhY2N0b24uY29tIHdyb3RlOg0KDQo+DQo+IFRvbSwNCj4NCj4gSW4gcmVzcG9uc2UgdG8g eW91ciByZXF1ZXN0IGZvciBzcGVjaWZpYyBvYmplY3RzLCBwbGVhc2Ugc2VlIGZvbGxvd2luZw0K PiBtYXJrZWQgIm5ldyIuDQo+DQo+IFZwbHNDb25maWdFbnRyeSA6Oj0NCj4gICBTRVFVRU5DRSB7 DQo+ICAgICB2cGxzSW5kZXggICAgICAgICAgICAgICAgICAgICAgICBVbnNpZ25lZDMyLA0KPiAg ICAtLSBleGlzdGluZyBzdHVmZiAtLQ0KPiAgICAgdnBsc01lc2hQZWVyQ291bnQgICAgICAgICAg ICAgICAgQ291bnRlciwgLS0gbmV3DQo+ICAgICB2cGxzU3Bva2VQZWVyQ291bnQgICAgICAgICAg ICAgICBDb3VudGVyLCAtLSBuZXcNCj4gICAgIHZwbHNTZXJ2aWNlVHlwZSAgICAgICAgICAgICAg ICAgIElOVEVHRVIsIC0tIG5ldw0KPiAgICAgdnBsc010dSAgICAgICAgICAgICAgICAgICAgICAg ICAgVW5zaWduZWQzMiwgLS0gbmV3DQo+ICAgICB2cGxzUm93U3RhdHVzICAgICAgICAgICAgICAg ICAgICBSb3dTdGF0dXMNCj4gICAgIH0NCg0KICAgICAgICAgICBUaGlzIGlzIHRoZSBjb25maWd1 cmF0aW9uIHNlY3Rpb24uIFdoeSB3b3VsZCB3ZQ0KcHV0IHN0YXR1cy1yZWxhdGVkIG9iamVjdHMg aW4gdGhpcyBzZWN0aW9uPw0KDQo+DQo+IHZwbHNNZXNoUGVlckNvdW50IE9CSkVDVC1UWVBFDQo+ ICAgICBTWU5UQVggICAgICAgICAgQ291bnRlcg0KPiAgICAgTUFYLUFDQ0VTUyAgICAgIHJlYWQt b25seQ0KPiAgICAgU1RBVFVTICAgICAgICAgIGN1cnJlbnQNCj4gICAgIERFU0NSSVBUSU9ODQo+ ICAgICAgICAgICJUaGlzIG9iamVjdCBzcGVjaWZpZXMgdGhlIG51bWJlciBvZiBtZXNoIHBlZXJz DQo+ICAgICAgICAgIHByZXNlbnQgaW4gdGhpcyB2cGxzIGluc3RhbmNlLiINCj4gICAgIDo6PSB7 IHZwbHNDb25maWdFbnRyeSAxMiB9DQo+DQo+IHZwbHNTcG9rZVBlZXJDb3VudCBPQkpFQ1QtVFlQ RQ0KPiAgICAgU1lOVEFYICAgICAgICAgIENvdW50ZXINCj4gICAgIE1BWC1BQ0NFU1MgICAgICBy ZWFkLW9ubHkNCj4gICAgIFNUQVRVUyAgICAgICAgICBjdXJyZW50DQo+ICAgICBERVNDUklQVElP Tg0KPiAgICAgICAgICAiVGhpcyBvYmplY3Qgc3BlY2lmaWVzIHRoZSBudW1iZXIgb2Ygc3Bva2Ug cGVlcnMNCj4gICAgICAgICAgcHJlc2VudCBpbiB0aGlzIHZwbHMgaW5zdGFuY2UuIg0KPiAgICAg Ojo9IHsgdnBsc0NvbmZpZ0VudHJ5IDEzIH0NCj4NCj4gdnBsc1NlcnZpY2VUeXBlIE9CSkVDVC1U WVBFDQo+ICAgICBTWU5UQVggICAgICAgICAgSU5URUdFUiB7DQo+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgdmxhbiAgICAgICAgKDEpLA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGV0aGVybmV0ICAgICgyKQ0KPiAgICAgICAgICAgICAgICAgICAgICB9DQo+ICAgICBNQVgt QUNDRVNTICAgICAgcmVhZC1vbmx5DQo+ICAgICBTVEFUVVMgICAgICAgICAgY3VycmVudA0KPiAg ICAgREVTQ1JJUFRJT04NCj4gICAgICAgICAgIlRoaXMgb2JqZWN0IHNwZWNpZmllcyB0aGUgdHlw ZSBvZiBzZXJ2aWNlIGJlaW5nDQo+ICAgICAgICAgIGVtdWxhdGVkIGJ5IHRoaXMgdnBscyBpbnN0 YW5jZS4iDQo+ICAgICA6Oj0geyB2cGxzQ29uZmlnRW50cnkgMTQgfQ0KPg0KPiB2cGxzTXR1IE9C SkVDVC1UWVBFDQo+ICAgICBTWU5UQVggICAgICAgICAgVW5zaWduZWQzMiAoNjQuLjE1MTgpDQo+ ICAgICBNQVgtQUNDRVNTICAgICAgcmVhZC1jcmVhdGUNCj4gICAgIFNUQVRVUyAgICAgICAgICBj dXJyZW50DQo+ICAgICBERVNDUklQVElPTg0KPiAgICAgICAgICAiVGhpcyBvYmplY3Qgc3BlY2lm aWVzIHRoZSBNVFUgb2YgdGhpcyB2cGxzIGluc3RhbmNlLiINCj4gICAgIERFRlZBTCAgICAgICAg ICB7IDE1MTggfQ0KPiAgICAgOjo9IHsgdnBsc0NvbmZpZ0VudHJ5IDE1IH0NCj4NCj4NCj4gVnBs c1B3QmluZEVudHJ5IDo6PQ0KPiAgICAgU0VRVUVOQ0Ugew0KPiAgICAgICAgIHZwbHNQd0luZGV4 ICAgICAgICAgICAgICAgICAgICAgUHdJbmRleFR5cGUsDQo+ICAgICAgICAgLS0gZXhpc3Rpbmcg c3R1ZmYgLS0NCj4gICAgICAgICB2cGxzUHdUeXBlICAgICAgICAgICAgICAgICAgICAgIElOVEVH RVIsIC0tIG5ldw0KPiAgICAgICAgIHZwbHNQd0JpbmRSb3dTdGF0dXMgICAgICAgICAgICAgUm93 U3RhdHVzDQo+ICAgICB9DQo+DQo+IHZwbHNQd1R5cGUgICBPQkpFQ1QtVFlQRQ0KPiAgICAgIFNZ TlRBWCAgICAgICAgICBJTlRFR0VSIHsNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICBt ZXNoICAoMSksDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3Bva2UgKDIpDQo+ICAg ICAgICAgICAgICAgICAgICAgIH0NCj4gICAgICBNQVgtQUNDRVNTICAgICAgcmVhZC1jcmVhdGUN Cj4gICAgICBTVEFUVVMgICAgICAgICAgY3VycmVudA0KPiAgICAgIERFU0NSSVBUSU9ODQo+ICAg ICAgICAgICAiVGhlIHZhbHVlIG9mIHRoaXMgb2JqZWN0IGluZGljYXRlcw0KPiAgICAgICAgICAg IHdoZXRoZXIgdGhlIFBzZXVkbyBXaXJlIGlzIG9mIHR5cGUgbWVzaCBvciBzcG9rZS4iDQo+ICAg ICAgREVGVkFMICAgICAgIHsgMCB9DQo+ICAgICA6Oj0geyB2cGxzUHdCaW5kRW50cnkgMiB9DQoN CiAgICAgICAgICAgVGhpcyB3YXMgb3JpZ2luYWxseSBpbiBvbmUgb2YgdGhlIE1JQnMgd2UgbWVy Z2VkIGluLCBidXQNCndhcyByZW1vdmVkIGJlY2F1c2UgaXQgd2FzIGZlbHQgdGhhdCB0aGlzIHdh cyBtb3JlIG9mIGENCmNvbnZlbmllbmNlIHRoYW4gYW55dGhpbmcgZWxzZS4gIEFsc28sIGhvdyBk byB5b3UgZGVzY3JpYmUNCmEgcGFydGlhbC1tZXNoPw0KDQogICAgICAgICAgIC0tVG9tDQoNCg0K Pg0KPiBSZWdhcmRzLA0KPiBBbmlsDQoNCg0K From l2vpn-bounces@ietf.org Tue Jul 25 15:28:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5SZs-0004U2-8L; Tue, 25 Jul 2006 15:28:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5SZq-0004Tq-Tt for l2vpn@ietf.org; Tue, 25 Jul 2006 15:28:22 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5SZn-0000lg-Av for l2vpn@ietf.org; Tue, 25 Jul 2006 15:28:22 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 25 Jul 2006 12:28:16 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.07,180,1151910000"; d="scan'208"; a="33337251:sNHT27961160" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6PJSGVD022239; Tue, 25 Jul 2006 15:28:16 -0400 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 k6PJSFdm001156; Tue, 25 Jul 2006 15:28:16 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 15:27:25 -0400 Received: from [161.44.71.206] ([161.44.71.206]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 15:27:25 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9C0AC916-69EA-4844-BD06-C826006D5B4D@cisco.com> Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Date: Tue, 25 Jul 2006 15:27:40 -0400 To: anilr@accton.com X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 25 Jul 2006 19:27:25.0062 (UTC) FILETIME=[5BB44260:01C6B020] DKIM-Signature: a=rsa-sha1; q=dns; l=4923; t=1153855696; x=1154719696; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tnadeau@cisco.com; z=From:=22Thomas=20D.=20Nadeau=22=20 |Subject:Re=3A=20[L2VPN]=20comments=20on=20VPLS=20MIB |To:anilr@accton.com; X=v=3Dcisco.com=3B=20h=3DqIeyPg671i8vQoR8TVBllZziPDI=3D; b=W11U8dSAxmvfT8eegZVkPQnyO8dHrqYtS/vglGVaz/genhVsLzJEw39x57x+8tmbSWH/T/+S FtxBUpfNMVvVe1YE5xIRFvWmLgdEJ/3c3oSDUkY3EqVAMVpKj6ZuBlOd; Authentication-Results: rtp-dkim-1.cisco.com; header.From=tnadeau@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: l2vpn@ietf.org, 'Shane Amante' Subject: Re: [L2VPN] comments on VPLS MIB X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org On Jul 25, 2006, at 2:56 PM, anilr@accton.com wrote: > > Tom, > > The config table as you have it has a couple status objects in > vplsOperStatus and vplsVpnId. Traditionally Oper and Admin status objects are together. I don't see how VpnID is not a configuration object. > Perhaps it can be broken up into status and > config tables? That, or perhaps simply rename it so that it can > contain > read-only as well as read-write entries. Yes. This is a good idea. > Re how to indicate whether it's a partial-mesh pseudowire: as far as I > could gather from Vach's answer, that is not part of the basic VPLS > architecture. Agreed; I made this same point in my response to the meeting minutes last week when I made the case for leaving it out. > This leads me to believe it's a vendor-specific issue, or do > I not understand the issue correctly? The issue is that it is not formally part of the protocol specifications, and therefore is in a gray area. Since this document is supposed to some day be a WG document, then it would be okay to add such objects as long as there as WG consensus to do so. > One way to deal with this sort of > thing we've used in IETF MIBs I've written in the past is to add an > enumeration of 'other' (I'm pretty sure we did that in RFC1493, Bridge > MIB). We could do that. Although 'other' often leads to interop issues, so I prefer to avoid it if possible. --Tom > > Regards, > Anil > > > > > "Thomas D. > Nadeau" To: anilr@accton.com > "'Shane Amante'" > .com> Subject: Re: [L2VPN] > comments on VPLS MIB > > 07/25/2006 > 02:24 PM > > > > > > > > On Jul 25, 2006, at 2:28 PM, anilr@accton.com wrote: > >> >> Tom, >> >> In response to your request for specific objects, please see >> following >> marked "new". >> >> VplsConfigEntry ::= >> SEQUENCE { >> vplsIndex Unsigned32, >> -- existing stuff -- >> vplsMeshPeerCount Counter, -- new >> vplsSpokePeerCount Counter, -- new >> vplsServiceType INTEGER, -- new >> vplsMtu Unsigned32, -- new >> vplsRowStatus RowStatus >> } > > This is the configuration section. Why would we > put status-related objects in this section? > >> >> vplsMeshPeerCount OBJECT-TYPE >> SYNTAX Counter >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "This object specifies the number of mesh peers >> present in this vpls instance." >> ::= { vplsConfigEntry 12 } >> >> vplsSpokePeerCount OBJECT-TYPE >> SYNTAX Counter >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "This object specifies the number of spoke peers >> present in this vpls instance." >> ::= { vplsConfigEntry 13 } >> >> vplsServiceType OBJECT-TYPE >> SYNTAX INTEGER { >> vlan (1), >> ethernet (2) >> } >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "This object specifies the type of service being >> emulated by this vpls instance." >> ::= { vplsConfigEntry 14 } >> >> vplsMtu OBJECT-TYPE >> SYNTAX Unsigned32 (64..1518) >> MAX-ACCESS read-create >> STATUS current >> DESCRIPTION >> "This object specifies the MTU of this vpls instance." >> DEFVAL { 1518 } >> ::= { vplsConfigEntry 15 } >> >> >> VplsPwBindEntry ::= >> SEQUENCE { >> vplsPwIndex PwIndexType, >> -- existing stuff -- >> vplsPwType INTEGER, -- new >> vplsPwBindRowStatus RowStatus >> } >> >> vplsPwType OBJECT-TYPE >> SYNTAX INTEGER { >> mesh (1), >> spoke (2) >> } >> MAX-ACCESS read-create >> STATUS current >> DESCRIPTION >> "The value of this object indicates >> whether the Pseudo Wire is of type mesh or spoke." >> DEFVAL { 0 } >> ::= { vplsPwBindEntry 2 } > > This was originally in one of the MIBs we merged in, but > was removed because it was felt that this was more of a > convenience than anything else. Also, how do you describe > a partial-mesh? > > --Tom > > >> >> Regards, >> Anil > > From l2vpn-bounces@ietf.org Tue Jul 25 19:19:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5WBH-0003Gd-3V; Tue, 25 Jul 2006 19:19:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5WBF-0003Et-HR for l2vpn@ietf.org; Tue, 25 Jul 2006 19:19:13 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5WBD-0007V0-6V for l2vpn@ietf.org; Tue, 25 Jul 2006 19:19:13 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 25 Jul 2006 16:19:10 -0700 X-IronPort-AV: i="4.07,181,1151910000"; d="scan'208"; a="1841757497:sNHT24821714" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6PNJAi1022296; Tue, 25 Jul 2006 16:19:10 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6PNJA2F024611; Tue, 25 Jul 2006 16:19:10 -0700 (PDT) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Jul 2006 16:19:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 25 Jul 2006 16:19:08 -0700 Message-ID: <75B2A84D9323BC4CA3977CF378CE75EB01DC33E5@xmb-sjc-21e.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-sajassi-l2vpn-vpls-bridge-interop-03? Thread-Index: AcawGKkdoAKx7UiTTCifqsxv5SVQ/AAJRDPw From: "Ali Sajassi \(sajassi\)" To: , "Vach Kompella" X-OriginalArrivalTime: 25 Jul 2006 23:19:10.0074 (UTC) FILETIME=[BBBCB5A0:01C6B040] DKIM-Signature: a=rsa-sha1; q=dns; l=677; t=1153869550; x=1154733550; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sajassi@cisco.com; z=From:=22Ali=20Sajassi=20\(sajassi\)=22=20 |Subject:RE=3A=20draft-sajassi-l2vpn-vpls-bridge-interop-03?; X=v=3Dcisco.com=3B=20h=3D5U+Ua0D9Y2AetWy67AyM8iLfJAQ=3D; b=HJNCcnUGbNk14eYgpZEoEZfRMU2IuUHWLeo/JJ4prZrH04sX4I9plY4CkdMyBU1IKsaEY2Zr ESbTP7a+mKuudIJzvCj5lcCZffTW3U97W/kQ/hM/NPDGqwCLwdQp/Ogr; Authentication-Results: sj-dkim-1.cisco.com; header.From=sajassi@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: l2vpn@ietf.org Subject: RE: draft-sajassi-l2vpn-vpls-bridge-interop-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: , Errors-To: l2vpn-bounces@ietf.org Anil, > Mention is made of several interoperability issues which are not=20 > addressed one way or another, e.g. how should various "slow" 802=20 > protocols be dealt with? The answer may be different for different=20 > existing protocols, and may be different for unrecognized=20 > protocols. Please refer to section 4.2 of the draft that talks about how different customer bridge protocols should be handled by the PE using the 802.1ad bridge module as the front-end model for interfacing with customer interfaces. The idea in here is to show how some of the IEEE work can be leveraged to address some of these bridge interoperability issues. -Ali From l2vpn-bounces@ietf.org Wed Jul 26 20:29:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5tkd-0002F6-Dq; Wed, 26 Jul 2006 20:29:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5tkb-0002EQ-WF; Wed, 26 Jul 2006 20:29:18 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5pqw-0005R9-Od; Wed, 26 Jul 2006 16:19:34 -0400 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=oak.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G5pOM-0008FI-Iz; Wed, 26 Jul 2006 15:50:08 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k6QJo2p0006458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Jul 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G5pOM-0001KE-0L; Wed, 26 Jul 2006 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, 26 Jul 2006 15:50:02 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: l2vpn@ietf.org Subject: I-D ACTION:draft-ietf-l2vpn-vpls-bridge-interop-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: , Errors-To: l2vpn-bounces@ietf.org --NextPart Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by oak.neustar.com id k6QJo2p0006458 A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. This draft is a work item of the Layer 2 Virtual Private Networks Working= Group of the IETF. Title : VPLS Interoperability with CE Bridges=20 Author(s) : A. Sajassi, et al. Filename : draft-ietf-l2vpn-vpls-bridge-interop-00.txt Pages : 19 Date : 2006-7-26 =09 One of the main motivations behind VPLS is its ability to provide=20 connectivity not only among customer routers and servers/hosts but=20 also among customer bridges. If only connectivity among customer IP=20 routers/hosts was desired, then IPLS solution [IPLS] could have been=20 used. The strength of the VPLS solution is that it can provide=20 connectivity to both bridge and non-bridge types of CE devices. VPLS=20 is expected to deliver the same level of service that current=20 enterprise users are accustomed to from their own enterprise bridged=20 networks today or the same level of service that they receive from=20 their Ethernet Service Providers using IEEE 802.1ad-based networks=20 [P802.1ad] (or its predecessor =96 QinQ-based network).=20 =20 When CE devices are IEEE bridges, then there are certain issues and=20 challenges that need to be accounted for in a VPLS network. Majority=20 of these issues have currently been addressed in IEEE 802.1ad=20 standard for provider bridges and they need to be addressed for VPLS=20 networks. This draft discusses these issues and wherever possible,=20 the recommended solutions to these issues.=20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-bridge-interop-= 00.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of th= e message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the usern= ame "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-l2vpn-vpls-bridge-interop-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-l2vpn-vpls-bridge-interop-00.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-7-26133948.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l2vpn-vpls-bridge-interop-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l2vpn-vpls-bridge-interop-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-7-26133948.I-D@ietf.org> --OtherAccess-- --NextPart-- From l2vpn-bounces@ietf.org Mon Jul 31 00:58:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7PrK-00052e-4w; Mon, 31 Jul 2006 00:58:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7PrJ-00052Z-GY for l2vpn@ietf.org; Mon, 31 Jul 2006 00:58:29 -0400 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7PrJ-0001Z5-2d for l2vpn@ietf.org; Mon, 31 Jul 2006 00:58:29 -0400 Received: from [127.0.0.1] (dog.tcb.net [64.78.150.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id AAE7A64352 for ; Sun, 30 Jul 2006 22:58:24 -0600 (MDT) Message-ID: <44CD8DEF.50303@castlepoint.net> Date: Sun, 30 Jul 2006 22:58:23 -0600 From: Shane Amante User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) 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: ff03b0075c3fc728d7d60a15b4ee1ad2 Subject: draft-ietf-l2vpn-vpls-mcast-reqts-02 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org Yuji, et. al, Below are some comments & questions I have related to your I-D. In addition, I have a number of fairly minor editorial nits, which I will mail to you separately. Thank you for your work on this. -shane ---cut here--- In Section 4.1.2: - A solution SHOULD support IP multicast of customers with the care of their Layer-3 multicast routing state. I'm not clear on what you mean by "with the care of". Do you mean something along the lines of "by observing their Layer-3 multicast routing protocols/state"? Also, in section 4.1.2: - In a solution, Layer-2 control frames (e.g., BPDU, 802.1ag CFM) SHOULD be flooded to all PE/CEs in a common VPLS instance. A solution SHOULD NOT change or limit the flooding scope to remote PE/CEs in terms of end-point reachability. Just so I am clear on why the first sentence above says "SHOULD" and not "MUST" is because the SP, at its discretion, may filter Layer-2 control frames, (for example, on it's PE's or other network infrastructure elements)? In Section 5.4, I'm not clear on what you mean by the second sentence in the following paragraph: Multicast specific characteristics that may be monitored are, for instance, multicast statistics per stream, delay and latency time (time to start receiving a multicast group traffic across the VPN). You can also see about variation in delivery time of a multicast packet to different destination. In the second sentence it does not sound like you are speaking about jitter (a.k.a.: delay variation) for packets inside one multicast stream from a single source PE to a single receiver PE. Correct? Instead, you're looking to compare the difference in one-way delay (for a single multicast group/stream?) from a single source PE to multiple receiver PE's? If so, could you please clarify this? In Section 5.10, I think the following paragraph needs some word-smithing to make it more clear. Can you change the following from this: However, a multicast VPLS, by nature, is the one which allows to pick up individually customer's multicast and unicast logically in order to solve resource waste issue. Thus this point will bring some customers more or less a new concern that they might have complicated situations in case of failure in either unicast or multicast only. to this: A multicast VPLS solution may decouple the path that a customer's unicast and multicast traffic follow through a SP's Backbone, in order to provide the most optimal path for mutlicast data traffic. This may cause concern among some multicast VPLS customers who desire that, during a failure in the SP's network, both unicast and multicast traffic fail concurrently. Also, in Section 5.10, I'm not clear what you mean by the following statements: Note that how serious this issue is depends on each customer's stance in Ethernet operation. For example, if all CEs are IP routers i.e., if VPLS is provided for LAN Routing application, such the customer might not need to care about it because both connectivity is assured in IP layer. Are you trying to say that if the CE routers are running an IGP (e.g.: OSPF/IS-IS) and a multicast routing protocol, (e.g.: PIM), then liveness of both the unicast and multicast paths will be "adequately" detected by the CE's? Assuming that is the case, you may also want to point out above that this doesn't guarantee that unicast and multicast traffic are not guaranteed to follow the same path in the SP's Backbone network, but does mitigate this issue to some degree. In Section 6.5.1, Also it MAY be possible: o with an IP multicast group and/or channel granularity Do you mean "with a _customer_ IP multicast group and/or channel granularity"? In Section 6.5.4, I would suggest rewording the following paragraph FROM: In particular, such mechanisms SHOULD be able to detect multicast failure quickly on par with unicast cases. It needs to obviate the cases where multicast has been in failure for long time while unicast remains alive; such a situation, in many cases, might end up in complicated troubles in customer applications which use a combination of them. TO: In particular, such mechanisms SHOULD be able to detect a multicast failure quickly, (on par with unicast cases). It also should avoid situations where multicast traffic has been in a failure state for a relatively long time while unicast traffic remains operational. If such a situation were to occur, it would end up causing problems with customer applications that depend on a combination of unicast and multicast forwarding. Also, in Section 6.5.4, I would suggest rewording the following paragraph FROM: However, in multicast, as there are many receivers pertaining to a particular unidirectional traffic, possibly the number of potential detecting points also grows, which will raise scalability concern. Consequently, a fault detection solution SHOULD scale well with consideration of key metrics described in section 6.1.2. TO: With multicast, there may be many receivers associated with a particular mulitcast stream/group. As the number of receivers increases, the number of places (typically nearest the receivers) required to detect a fault will increase proportionately. This raises concerns over the scalability of fault detection in large multicast deployments. Consequently, a fault detection solution SHOULD scale well; in particular, a solution should consider key metrics for scalability as described in section 6.1.2.