From DanielC@orckit.com Wed Jun 1 07:25:22 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36875E0879 for ; Wed, 1 Jun 2011 07:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.204 X-Spam-Level: X-Spam-Status: No, score=-1.204 tagged_above=-999 required=5 tests=[AWL=-1.394, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxBNzPdxt+4M for ; Wed, 1 Jun 2011 07:25:21 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by ietfa.amsl.com (Postfix) with ESMTP id C59FAE088E for ; Wed, 1 Jun 2011 07:25:19 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Subject: RE: L2vpn Digest, Vol 84, Issue 6 Date: Wed, 1 Jun 2011 17:25:17 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA081306C8B012@tlvmail1> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: L2vpn Digest, Vol 84, Issue 6 Thread-Index: AcwZe7oN2ueN9XN6QA+dJtKK8FE30gEYLpMgAGTUh3A= References: From: "Daniel Cohn" To: "Sam Cao" , X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 14:25:22 -0000 Hi Sam, thanks for the feedback and please see my comments inline with = [DC]. Let me know if anything is still not clear. Regards, Daniel -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of Sam Cao Sent: Sunday, May 29, 2011 12:23 PM To: l2vpn@ietf.org Subject: =B4=F0=B8=B4: L2vpn Digest, Vol 84, Issue 6 Daniel, Today I read your draft and have some questions.=20 1) In Figure 2, "VSI Root PW" is used for frames originated from Root = ACs. Is it available for both AC1 on PE1 and AC3 (Root AC) on PE2? For = example, if one unknown unicast originated from AC1, it is carried via VSI root = PW and broadcasted to AC3 and AC4. Is it right? One unknown unicast = originated from AC3 is also carried via VSI Root PW. [DC] That is correct. Root/leaf PW selection is based solely upon source = AC type. 2) AC E-Tree Type. In your draft, it is just locally configured. If so, = Root PW and Leaf PW are always established while VSI has been configured, = right? PE selected the correct PW to send frames upon local configuration, is = it right? [DC] Right. 3) In 5.2.1, VSI E-Tree encoding. There are two VSI E-Tree types, one is E-Tree Root VSI, and one is E-Tree Leaf VSI. If so, in figure 2, if one = VSI is attached both Root ACs and Leaf ACs, what is its type?=20 [DC] The VSI E-Tree type is a parameter of the PW that interconnects the = PEs, not of the entire VSI. So in figure 2, the VSI root PW is signaled = with E-Tree Root VSI type, and the VSI leaf PW is signaled with E-Tree = Leaf VSI type. 4) Can you tell me the usage of VSI E-Tree identifier? Is it useful to establish PW? " pair", I guess = we have to separate one VSI into two VSIs, one is Root VSI and one is Leaf = VSI, but if so, it is not reasonable to establish just 2 PWs in Figure 2. = Root AC and Leaf AC can not attach to same VSI. [DC] As explained in the previous comment - there is only one VSI per PE = for a VPLS, and this VSI is interconnected to VSIs in other PEs via two = PWs. There are two ways to support E-Tree, I believe, one on data plane and = one on control plane. I also uploaded one draft on this "http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/". Would you please share some comments?=20 [DC] I reviewed your draft but I need your help in understanding some of = the concepts. I will write to you soon with questions. Yuqun (Sam) Cao Mobile: +86-18959186587 E-mail: Yuqun.cao@gmail.com=20 =20 -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: l2vpn-bounces@ietf.org = [mailto:l2vpn-bounces@ietf.org] =B4=FA=B1=ED l2vpn-request@ietf.org =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA5=D4=C224=C8=D5 3:00 =CA=D5=BC=FE=C8=CB: l2vpn@ietf.org =D6=F7=CC=E2: L2vpn Digest, Vol 84, Issue 6 If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to=20 https://www.ietf.org/mailman/listinfo/l2vpn Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send L2vpn mailing list submissions to l2vpn@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/l2vpn or, via email, send a message with subject or body 'help' to l2vpn-request@ietf.org You can reach the person managing the list at l2vpn-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of L2vpn digest..." Today's Topics: 1. Seeking feedback on I-D "Extension to LDP-VPLS for E-Tree Using Two PW" new revision (Daniel Cohn) ---------------------------------------------------------------------- Message: 1 Date: Mon, 23 May 2011 20:28:49 +0300 From: "Daniel Cohn" To: Subject: Seeking feedback on I-D "Extension to LDP-VPLS for E-Tree Using Two PW" new revision Message-ID: <44F4E579A764584EA9BDFD07D0CA081306C0D78B@tlvmail1> Content-Type: text/plain; charset=3D"us-ascii" Hi L2VPNers, We (the authors) uploaded a new revision of the "Extension to LDP-VPLS for E-Tree Using Two PW" at http://tools.ietf.org/id/draft-ram-l2vpn-ldp-vpls-etree-2pw-02.txt The main change from the previous revision is the use of new interface parameters TLVs (VSI E-Tree type and VSI E-Tree identifier) to identify root and leaf PWs, rather than defining new PW types. This is a result from feedback we received when we presented the draft at IETF 80. We are seeking more feedback from the mailing list, and would be grateful if you could review the document and post comments on the mailing list or directly to the authors. Regards, Daniel ------------------------------ _______________________________________________ L2vpn mailing list L2vpn@ietf.org https://www.ietf.org/mailman/listinfo/l2vpn End of L2vpn Digest, Vol 84, Issue 6 ************************************ From yuqun.cao@gmail.com Thu Jun 2 19:01:01 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4CC1E06FC for ; Thu, 2 Jun 2011 19:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.756 X-Spam-Level: X-Spam-Status: No, score=0.756 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZAIdsIF3-PN for ; Thu, 2 Jun 2011 19:01:01 -0700 (PDT) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by ietfa.amsl.com (Postfix) with ESMTP id 16598E06CF for ; Thu, 2 Jun 2011 19:01:01 -0700 (PDT) Received: by pxi20 with SMTP id 20so1053444pxi.27 for ; Thu, 02 Jun 2011 19:01:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:from:to:references:subject:date :mime-version:content-type:content-transfer-encoding:x-priority :x-msmail-priority:x-mailer:disposition-notification-to:x-mimeole; bh=8sN4pGeysVxApmoiGyPBQaVm7nPj7qnVLQ1jmvRE+WA=; b=T1cpK5/3FeoO7o6/o0EEMsfdbpezfrvvQaKk1YYPGHa77f5Fi9ZaOXHZ93xSjdfCvZ bMOdxudG8k+kRblpimbDW9kW0xcvC2J+Bb4V+5tPQEx/dB4zUKHGFDqKG9ayzZUip6CX akf+jo0X1HE/HOQ5rC2pnEsc6hbM06bL38MD0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:disposition-notification-to:x-mimeole; b=mGFD0jyXRc7RTQ66Hbv6uYzLTHD5sHlB3fVQZH15WPEru4XqsbW9Jpu4LIhqWsOJo2 dlffyFQDr7mB0T1o4yI4/HaAUpT1IxejiusmMfQz2b4zIanZqYYb7nP55hzTUOKoK2rp pDP5YuTPk8b4ka7V6o8vebrp1otY8NElDnbXM= Received: by 10.68.36.170 with SMTP id r10mr521221pbj.504.1307066460594; Thu, 02 Jun 2011 19:01:00 -0700 (PDT) Received: from R01842 ([110.90.119.113]) by mx.google.com with ESMTPS id y2sm1023488pbg.72.2011.06.02.19.00.42 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Jun 2011 19:00:58 -0700 (PDT) Message-ID: <61DB25F71DCD46898D8CC7B836545E63@ruijie.com.cn> From: "Sam Cao" To: "Daniel Cohn" , References: <44F4E579A764584EA9BDFD07D0CA081306C8B012@tlvmail1> Subject: Re: L2vpn Digest, Vol 84, Issue 6 Date: Fri, 3 Jun 2011 09:57:42 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4657 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 02:01:01 -0000 SGkgRGFuaWVsLA0KDQpUaGFuayB5b3UgdmVyeSBtdWNoIGZvciB5b3VyIGNvbW1lbnRzLiBJIHVu ZGVyc3Rvb2QgeW91ciBkZXNpZ24sIGFuZCBoYXZlIDMgbW9yZSBxdWVzdGlvbnMsDQoNCjEpIFR3 byBQV3MgYXJlIGFsd2F5cyBlc3RhYmxpc2hlZCBhbmQgbmVjZXNzYXJ5IHNpbmNlIEFDIEUtVHJl ZSBUeXBlIGlzIGxvY2FsbHkgY29uZmlndXJlZCANCiAgIGluIGFueSBjYXNlLiBJIGFncmVlIChZ b3VyIGFuc3dlciB0byBteSBRMikuIEJ1dCBhcyB5b3Uga25vdywgbW9zdCBtZW1iZXJzIG9mIG9u ZSBFLVRyZWUgDQogICBpbnN0YW5jZSBhcmUgTGVhZiBmb3IgbW9zdCBFLVRyZWUgY2FzZXMsIGlm IHNvLCBhdCBsZWFzdCA1MCUgUFcgaXMgdXNlbGVzcy4gSW4gYWRkdGlvbiwgDQogICBpZiB3ZSBu ZWVkIHRvIGltcGxlbWVudCBGYXN0IFJlUm91dGluZyAoUFcgYmFja3VwKSwgbW9yZSB1c2Vsc3Mg UFcgYXJlIGVzdGFibGlzaGVkLiANCiAgIEhvdyB0byBzb2x2ZSB0aGlzPyBBcyB5b3Uga29udywg Um9vdC1MZWFmLU1peGVkIGlzIG9ubHkgYSBzbWFsbCBwcm9wb3J0aW9uIG9mIEUtVHJlZSBtZW1i ZXJzLiANCjIpIFRoZSBWU0kgRS1UcmVlIHR5cGUgaXMgYSBwYXJhbWV0ZXIgb2YgdGhlIFBXIHRo YXQgaW50ZXJjb25uZWN0cyB0aGUgUEVzLCB5b3Ugc2FpZC4gV2hhdCBpcyANCiAgIHRoZSBwdXJw b3NlPyANCjMpIFRoZSB0aGlyZCwgSSBnYXZlIG9uZSBleGFtcGxlLCBpdCBjYW4gbWFrZSBteXNl bGYgdW5kZXJzdG9vZC4gU3VwcG9zZSB0d28gUEVzLCBzYXkgUEUxIGFuZCBQRTIsIGJlbG9uZ3MN CiAgIHRvIG9uZSBFLVRyZWUgaW5zdGFuY2UsIHdoZXJlIFBFMSBhcmUgYm91bmQgYSBSb290IEFD IGFuZCBhIExlYWYgQUMsIGFuZCBQRTIgYXJlIG9ubHkgYm91bmQNCiAgIGEgTGVhZCBBQy4NCg0K ICAgICAgICAgICAgICAgICAgIDwtLS0tLS0tLS0tLS0tLUUtVHJlZS0tLS0tLS0tLS0tLS0tPg0K ICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0rICAgICAgICAgICAgICArLS0tLS0tLS0tKw0K ICAgICAgICAgICAgICAgICAgIHwgICBQRTEgICB8ICAgICAgICAgICAgICB8ICAgUEUyICAgfA0K ICAgKy0tLSsgICAgICAgICAgIHwgICstLS0rICB8ICAgICAgICAgICAgICB8ICArLS0tKyAgfA0K ICAgfENFMSstLS0tQUMxLS0tLSstLSsgICB8ICB8ICAgICAgICAgICAgICB8ICB8ICAgfCAgfCAN CiAgICstLS0rIChSb290IEFDKSB8ICB8IFYgfCAgfCAgICAgICAgICAgICAgfCAgfCBWIHwgIHwN CiAgICAgICAgICAgICAgICAgICB8ICB8IFMgKy0tKy0tLS0tLVBXLS0tLS0tKy0tKyBTIHwgIHwN CiAgICstLS0rICAgICAgICAgICB8ICB8IEkgfCAgfCAgICAgICAgICAgICAgfCAgfCBJIHwgIHwg ICAgICAgICAgICstLS0rDQogICB8Q0UyKy0tLS1BQzItLS0tKy0tKyAgIHwgIHwgICAgICAgICAg ICAgIHwgIHwgICArLS0rLS0tLUFDNC0tLS0rQ0U0fA0KICAgKy0tLSsgKExlYWYgQUMpIHwgICst LS0rICB8ICAgICAgICAgICAgICB8ICArLS0tKyAgfCAoTGVhZiBBQykgKy0tLSsNCiAgICAgICAg ICAgICAgICAgICArLS0tLS0tLS0tKyAgICAgICAgICAgICAgKy0tLS0tLS0tLSsNCiAgIA0KICBJ biB0aGlzIGNhc2UsIDIgUFdzIGFyZSBlc3RhYmxpc2hlZCwgSSBhZ3JlZSB0aGF0IGl0IGlzIHJl YXNvbmFibGUuIEFueSBmcmFtZXMgYXJlIHRyYW5zbWl0dGVkIA0KICBmcm9tIEFDNCB0byAgUEUx IHZpYSBTcG9rZSBQVywgdGhlbiBQRTEgdHJhbnNtaXQgdGhlIGZyYW1lcyB0byBBQzEgKFJvb3Qg QUMpLCBub3QgQUMyLiBJZiBBQzENCiAgZ29lcyBkb3duLCAyIFBXcyBzdGlsbCBleGlzdCwgYW5k IG5vdyBmcmFtZXMgZnJvbSBBQzQgc3RpbGwgYXJlIHRyYW5zbWl0dGVkIGZyb20gQUM0IHRvIFBF MSB2aWEgDQogIFNwb2tlIFBXLiBPbiBQRTEgc2lkZSwgUEUgZm91bmQgdGhhdCB0aGVyZSBpcyBu byBSb290IEFDIGFuZCBkaWNhcmQgdGhlIGZyYW1lcy4gSXMgdGhpcyBjb3JyZWN0PyANCiAgSWYg c28sIHdlIHdpbGwgaGF2ZSBvbmUgcHJvYmxlbTogYm90aCBQRXMgYXJlIGF0dGFjaGVkIHRvIFNw b2tlIEFDLCBidXQgZ2FyYmFnZSBmcmFtZXMgYXJlIA0KICByYW5zbWl0dGVkIHZpYSBTcG9rZSBQ Vy4gDQoNCg0KICBFLVRyZWUgbmVlZHMgZXh0ZW5zaW9uIHRvIGN1cnJlbnQgc3RhbmRhcmQsIGFu ZCBJIHByZWZlciB0byBleHRlbmQgb24gY29udHJvbCBwbGFuZSBzaW5jZSBpdCBpcyANCiAgY2xl YXIgZm9yIHVzZXIuIFNvcnJ5IGZvciBzbyBtYW55IHF1ZXN0aW9ucy4NCg0KU2FtDQoNCg0KLS0t LS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJEYW5pZWwgQ29obiIgPERhbmllbENA b3Jja2l0LmNvbT4NClRvOiAiU2FtIENhbyIgPHl1cXVuLmNhb0BnbWFpbC5jb20+OyA8bDJ2cG5A aWV0Zi5vcmc+DQpTZW50OiBXZWRuZXNkYXksIEp1bmUgMDEsIDIwMTEgMTA6MjUgUE0NClN1Ympl Y3Q6IFJFOiBMMnZwbiBEaWdlc3QsIFZvbCA4NCwgSXNzdWUgNg0KDQoNCkhpIFNhbSwgdGhhbmtz IGZvciB0aGUgZmVlZGJhY2sgYW5kIHBsZWFzZSBzZWUgbXkgY29tbWVudHMgaW5saW5lIHdpdGgg W0RDXS4gTGV0IG1lIGtub3cgaWYgYW55dGhpbmcgaXMgc3RpbGwgbm90IGNsZWFyLg0KDQpSZWdh cmRzLA0KDQpEYW5pZWwNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGwydnBu LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgU2FtIENhbw0KU2VudDogU3VuZGF5LCBNYXkgMjksIDIwMTEgMTI6MjMgUE0NClRvOiBs MnZwbkBpZXRmLm9yZw0KU3ViamVjdDogtPC4tDogTDJ2cG4gRGlnZXN0LCBWb2wgODQsIElzc3Vl IDYNCg0KRGFuaWVsLA0KDQpUb2RheSBJIHJlYWQgeW91ciBkcmFmdCBhbmQgaGF2ZSBzb21lIHF1 ZXN0aW9ucy4gDQoNCjEpIEluIEZpZ3VyZSAyLCAiVlNJIFJvb3QgUFciIGlzIHVzZWQgZm9yIGZy YW1lcyBvcmlnaW5hdGVkIGZyb20gUm9vdCBBQ3MuDQpJcyBpdCBhdmFpbGFibGUgZm9yIGJvdGgg QUMxIG9uIFBFMSBhbmQgQUMzIChSb290IEFDKSBvbiBQRTI/IEZvciBleGFtcGxlLA0KaWYgb25l IHVua25vd24gdW5pY2FzdCBvcmlnaW5hdGVkIGZyb20gQUMxLCBpdCBpcyBjYXJyaWVkIHZpYSBW U0kgcm9vdCBQVw0KYW5kIGJyb2FkY2FzdGVkIHRvIEFDMyBhbmQgQUM0LiBJcyBpdCByaWdodD8g T25lIHVua25vd24gdW5pY2FzdCBvcmlnaW5hdGVkDQpmcm9tIEFDMyBpcyBhbHNvIGNhcnJpZWQg dmlhIFZTSSBSb290IFBXLg0KDQpbRENdIFRoYXQgaXMgY29ycmVjdC4gUm9vdC9sZWFmIFBXIHNl bGVjdGlvbiBpcyBiYXNlZCBzb2xlbHkgdXBvbiBzb3VyY2UgQUMgdHlwZS4NCg0KMikgQUMgRS1U cmVlIFR5cGUuIEluIHlvdXIgZHJhZnQsIGl0IGlzIGp1c3QgbG9jYWxseSBjb25maWd1cmVkLiBJ ZiBzbywgUm9vdA0KUFcgYW5kIExlYWYgUFcgYXJlIGFsd2F5cyBlc3RhYmxpc2hlZCB3aGlsZSBW U0kgaGFzIGJlZW4gY29uZmlndXJlZCwgcmlnaHQ/DQpQRSBzZWxlY3RlZCB0aGUgY29ycmVjdCBQ VyB0byBzZW5kIGZyYW1lcyB1cG9uIGxvY2FsIGNvbmZpZ3VyYXRpb24sIGlzIGl0DQpyaWdodD8N Cg0KW0RDXSBSaWdodC4NCg0KMykgSW4gNS4yLjEsIFZTSSBFLVRyZWUgZW5jb2RpbmcuIFRoZXJl IGFyZSB0d28gVlNJIEUtVHJlZSB0eXBlcywgb25lIGlzDQpFLVRyZWUgUm9vdCBWU0ksIGFuZCBv bmUgaXMgRS1UcmVlIExlYWYgVlNJLiBJZiBzbywgaW4gZmlndXJlIDIsIGlmIG9uZSBWU0kNCmlz IGF0dGFjaGVkIGJvdGggUm9vdCBBQ3MgYW5kIExlYWYgQUNzLCB3aGF0IGlzIGl0cyB0eXBlPyAN Cg0KW0RDXSBUaGUgVlNJIEUtVHJlZSB0eXBlIGlzIGEgcGFyYW1ldGVyIG9mIHRoZSBQVyB0aGF0 IGludGVyY29ubmVjdHMgdGhlIFBFcywgbm90IG9mIHRoZSBlbnRpcmUgVlNJLiBTbyBpbiBmaWd1 cmUgMiwgdGhlIFZTSSByb290IFBXIGlzIHNpZ25hbGVkIHdpdGggRS1UcmVlIFJvb3QgVlNJIHR5 cGUsIGFuZCB0aGUgVlNJIGxlYWYgUFcgaXMgc2lnbmFsZWQgd2l0aCBFLVRyZWUgTGVhZiBWU0kg dHlwZS4NCg0KNCkgQ2FuIHlvdSB0ZWxsIG1lIHRoZSB1c2FnZSBvZiBWU0kgRS1UcmVlIGlkZW50 aWZpZXI/IElzIGl0IHVzZWZ1bCB0bw0KZXN0YWJsaXNoIFBXPyAiPFZTSSBFLVRyZWUgdHlwZSwg VlNJIEUtVHJlZSBpZGVudGlmaWVyPiBwYWlyIiwgSSBndWVzcyB3ZQ0KaGF2ZSB0byBzZXBhcmF0 ZSBvbmUgVlNJIGludG8gdHdvIFZTSXMsIG9uZSBpcyBSb290IFZTSSBhbmQgb25lIGlzIExlYWYg VlNJLA0KYnV0IGlmIHNvLCBpdCBpcyBub3QgcmVhc29uYWJsZSB0byBlc3RhYmxpc2gganVzdCAy IFBXcyBpbiBGaWd1cmUgMi4gUm9vdCBBQw0KYW5kIExlYWYgQUMgY2FuIG5vdCBhdHRhY2ggdG8g c2FtZSBWU0kuDQoNCltEQ10gQXMgZXhwbGFpbmVkIGluIHRoZSBwcmV2aW91cyBjb21tZW50IC0g dGhlcmUgaXMgb25seSBvbmUgVlNJIHBlciBQRSBmb3IgYSBWUExTLCBhbmQgdGhpcyBWU0kgaXMg aW50ZXJjb25uZWN0ZWQgdG8gVlNJcyBpbiBvdGhlciBQRXMgdmlhIHR3byBQV3MuDQoNClRoZXJl IGFyZSB0d28gd2F5cyB0byBzdXBwb3J0IEUtVHJlZSwgSSBiZWxpZXZlLCBvbmUgb24gZGF0YSBw bGFuZSBhbmQgb25lDQpvbiBjb250cm9sIHBsYW5lLiBJIGFsc28gdXBsb2FkZWQgb25lIGRyYWZ0 IG9uIHRoaXMNCiJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWNhby1sMnZw bi12cGxzLWV0cmVlLyIuIFdvdWxkIHlvdQ0KcGxlYXNlIHNoYXJlIHNvbWUgY29tbWVudHM/IA0K DQpbRENdIEkgcmV2aWV3ZWQgeW91ciBkcmFmdCBidXQgSSBuZWVkIHlvdXIgaGVscCBpbiB1bmRl cnN0YW5kaW5nIHNvbWUgb2YgdGhlIGNvbmNlcHRzLiBJIHdpbGwgd3JpdGUgdG8geW91IHNvb24g d2l0aCBxdWVzdGlvbnMuDQoNCll1cXVuIChTYW0pIENhbw0KTW9iaWxlOiArODYtMTg5NTkxODY1 ODcNCkUtbWFpbDogWXVxdW4uY2FvQGdtYWlsLmNvbSANCiANCi0tLS0t08q8/tStvP4tLS0tLQ0K t6K8/sjLOiBsMnZwbi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRm Lm9yZ10gtPqx7Q0KbDJ2cG4tcmVxdWVzdEBpZXRmLm9yZw0Kt6LLzcqxvOQ6IDIwMTHE6jXUwjI0 yNUgMzowMA0KytW8/sjLOiBsMnZwbkBpZXRmLm9yZw0K1vfM4jogTDJ2cG4gRGlnZXN0LCBWb2wg ODQsIElzc3VlIDYNCg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBkaWdlc3Qgd2l0aG91dCBh bGwgdGhlIGluZGl2aWR1YWwgbWVzc2FnZQ0KYXR0YWNobWVudHMgeW91IHdpbGwgbmVlZCB0byB1 cGRhdGUgeW91ciBkaWdlc3Qgb3B0aW9ucyBpbiB5b3VyIGxpc3QNCnN1YnNjcmlwdGlvbi4gIFRv IGRvIHNvLCBnbyB0byANCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9s MnZwbg0KDQpDbGljayB0aGUgJ1Vuc3Vic2NyaWJlIG9yIGVkaXQgb3B0aW9ucycgYnV0dG9uLCBs b2cgaW4sIGFuZCBzZXQgIkdldA0KTUlNRSBvciBQbGFpbiBUZXh0IERpZ2VzdHM/IiB0byBNSU1F LiAgWW91IGNhbiBzZXQgdGhpcyBvcHRpb24NCmdsb2JhbGx5IGZvciBhbGwgdGhlIGxpc3QgZGln ZXN0cyB5b3UgcmVjZWl2ZSBhdCB0aGlzIHBvaW50Lg0KDQoNCg0KU2VuZCBMMnZwbiBtYWlsaW5n IGxpc3Qgc3VibWlzc2lvbnMgdG8NCmwydnBuQGlldGYub3JnDQoNClRvIHN1YnNjcmliZSBvciB1 bnN1YnNjcmliZSB2aWEgdGhlIFdvcmxkIFdpZGUgV2ViLCB2aXNpdA0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sMnZwbg0Kb3IsIHZpYSBlbWFpbCwgc2VuZCBhIG1lc3Nh Z2Ugd2l0aCBzdWJqZWN0IG9yIGJvZHkgJ2hlbHAnIHRvDQpsMnZwbi1yZXF1ZXN0QGlldGYub3Jn DQoNCllvdSBjYW4gcmVhY2ggdGhlIHBlcnNvbiBtYW5hZ2luZyB0aGUgbGlzdCBhdA0KbDJ2cG4t b3duZXJAaWV0Zi5vcmcNCg0KV2hlbiByZXBseWluZywgcGxlYXNlIGVkaXQgeW91ciBTdWJqZWN0 IGxpbmUgc28gaXQgaXMgbW9yZSBzcGVjaWZpYw0KdGhhbiAiUmU6IENvbnRlbnRzIG9mIEwydnBu IGRpZ2VzdC4uLiINCg0KDQpUb2RheSdzIFRvcGljczoNCg0KICAgMS4gU2Vla2luZyBmZWVkYmFj ayBvbiBJLUQgIkV4dGVuc2lvbiB0byBMRFAtVlBMUyBmb3IgRS1UcmVlDQogICAgICBVc2luZyBU d28gUFciIG5ldyByZXZpc2lvbiAoRGFuaWVsIENvaG4pDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpN ZXNzYWdlOiAxDQpEYXRlOiBNb24sIDIzIE1heSAyMDExIDIwOjI4OjQ5ICswMzAwDQpGcm9tOiAi RGFuaWVsIENvaG4iIDxEYW5pZWxDQG9yY2tpdC5jb20+DQpUbzogPGwydnBuQGlldGYub3JnPg0K U3ViamVjdDogU2Vla2luZyBmZWVkYmFjayBvbiBJLUQgIkV4dGVuc2lvbiB0byBMRFAtVlBMUyBm b3IgRS1UcmVlDQpVc2luZyBUd28gUFciIG5ldyByZXZpc2lvbg0KTWVzc2FnZS1JRDogPDQ0RjRF NTc5QTc2NDU4NEVBOUJERkQwN0QwQ0EwODEzMDZDMEQ3OEJAdGx2bWFpbDE+DQpDb250ZW50LVR5 cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9InVzLWFzY2lpIg0KDQpIaSBMMlZQTmVycywNCg0KV2Ug KHRoZSBhdXRob3JzKSB1cGxvYWRlZCBhIG5ldyByZXZpc2lvbiBvZiB0aGUgIkV4dGVuc2lvbiB0 byBMRFAtVlBMUw0KZm9yIEUtVHJlZSBVc2luZyBUd28gUFciIGF0DQpodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaWQvZHJhZnQtcmFtLWwydnBuLWxkcC12cGxzLWV0cmVlLTJwdy0wMi50eHQNCg0KVGhl IG1haW4gY2hhbmdlIGZyb20gdGhlIHByZXZpb3VzIHJldmlzaW9uIGlzIHRoZSB1c2Ugb2YgbmV3 IGludGVyZmFjZQ0KcGFyYW1ldGVycyBUTFZzIChWU0kgRS1UcmVlIHR5cGUgYW5kIFZTSSBFLVRy ZWUgaWRlbnRpZmllcikgdG8gaWRlbnRpZnkNCnJvb3QgYW5kIGxlYWYgUFdzLCByYXRoZXIgdGhh biBkZWZpbmluZyBuZXcgUFcgdHlwZXMuIFRoaXMgaXMgYSByZXN1bHQNCmZyb20gZmVlZGJhY2sg d2UgcmVjZWl2ZWQgd2hlbiB3ZSBwcmVzZW50ZWQgdGhlIGRyYWZ0IGF0IElFVEYgODAuDQoNCldl IGFyZSBzZWVraW5nIG1vcmUgZmVlZGJhY2sgZnJvbSB0aGUgbWFpbGluZyBsaXN0LCBhbmQgd291 bGQgYmUNCmdyYXRlZnVsIGlmIHlvdSBjb3VsZCByZXZpZXcgdGhlIGRvY3VtZW50IGFuZCBwb3N0 IGNvbW1lbnRzIG9uIHRoZQ0KbWFpbGluZyBsaXN0IG9yIGRpcmVjdGx5IHRvIHRoZSBhdXRob3Jz Lg0KDQpSZWdhcmRzLA0KDQpEYW5pZWwNCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpMMnZwbiBtYWlsaW5nIGxpc3QNCkwydnBuQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2wydnBuDQoNCg0KRW5kIG9mIEwydnBuIERpZ2VzdCwgVm9sIDg0 LCBJc3N1ZSA2DQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0K From internet-drafts@ietf.org Tue Jun 7 03:07:28 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6913611E80C0; Tue, 7 Jun 2011 03:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, FUZZY_VLIUM=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nE9g7I2-2C8D; Tue, 7 Jun 2011 03:07:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0810511E80BB; Tue, 7 Jun 2011 03:07:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-l2vpn-ldp-vpls-broadcast-exten-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110607100728.26133.23929.idtracker@ietfa.amsl.com> Date: Tue, 07 Jun 2011 03:07:28 -0700 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 10:07:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Layer 2 Virtual Private Networks Work= ing Group of the IETF. Title : Extension to LDP-VPLS for Ethernet Broadcast and Multica= st Author(s) : Simon Delord Raymond Key Frederic Jounay Yuji Kamite Zhihua Liu Manuel Paul Ruediger Kunze Mach(Guoyi) Chen Lizhong Jin Filename : draft-ietf-l2vpn-ldp-vpls-broadcast-exten-02.txt Pages : 20 Date : 2011-06-07 This document proposes a simple extension to LDP-VPLS to improve bandwidth efficiency for Ethernet broadcast/multicast traffic within a carrier's network. It makes use of unidirectional point-to-multipoint PseudoWires to minimise payload frame duplication on physical links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-ldp-vpls-broadcast-ext= en-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-l2vpn-ldp-vpls-broadcast-exte= n-02.txt From raymond.key@hotmail.com Tue Jun 7 03:32:14 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A622E11E80F0 for ; Tue, 7 Jun 2011 03:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PeYku7cIBBT4 for ; Tue, 7 Jun 2011 03:32:14 -0700 (PDT) Received: from snt0-omc4-s15.snt0.hotmail.com (snt0-omc4-s15.snt0.hotmail.com [65.55.90.218]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD00228003 for ; Tue, 7 Jun 2011 03:32:14 -0700 (PDT) Received: from SNT123-W33 ([65.55.90.200]) by snt0-omc4-s15.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 Jun 2011 03:32:13 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_caf42c62-be15-490d-815f-abb4f6057ab3_" X-Originating-IP: [122.107.153.185] From: Raymond Key Sender: To: Subject: draft-ietf-l2vpn-ldp-vpls-broadcast-exten Date: Tue, 7 Jun 2011 21:02:13 +1030 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 07 Jun 2011 10:32:13.0669 (UTC) FILETIME=[2A4A0950:01CC24FE] X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 10:32:14 -0000 --_caf42c62-be15-490d-815f-abb4f6057ab3_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi L2VPN working group=2C =20 We have received some feedback via private email=2C now update the document= to 02-revision=2C only a few minor changes. http://tools.ietf.org/html/draft-ietf-l2vpn-ldp-vpls-broadcast-exten-02 =20 The authors would like to have your review again before we request working = group last call. Please post comments on mailing list or talk to us direct= . =20 Thanks a lot=2C Raymond Key = --_caf42c62-be15-490d-815f-abb4f6057ab3_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi L2VPN working group=2C
=3B
We have received some feedback via private email=2C now update the document= to 02-revision=2C only a few minor changes.
http://tools.ietf.= org/html/draft-ietf-l2vpn-ldp-vpls-broadcast-exten-02
=3B
The authors would like to have your review again before we request working = group last call. =3B Please post comments =3Bon mailing list or tal= k to us direct.
=3B
Thanks a lot=2C
Raymond Key
=3B
= --_caf42c62-be15-490d-815f-abb4f6057ab3_-- From DanielC@orckit.com Wed Jun 8 23:27:19 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4556921F84E3 for ; Wed, 8 Jun 2011 23:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.19 X-Spam-Level: X-Spam-Status: No, score=0.19 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obtI1ZCxHDMy for ; Wed, 8 Jun 2011 23:27:18 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by ietfa.amsl.com (Postfix) with ESMTP id C4DDF21F84DE for ; Wed, 8 Jun 2011 23:27:17 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Subject: RE: L2vpn Digest, Vol 84, Issue 6 Date: Thu, 9 Jun 2011 09:27:14 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA081306CF2D45@tlvmail1> In-reply-to: <61DB25F71DCD46898D8CC7B836545E63@ruijie.com.cn> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: L2vpn Digest, Vol 84, Issue 6 Thread-Index: AcwhkldVSl4e7qEOQ3GJoEPYsjKA5wE2RZDw References: <44F4E579A764584EA9BDFD07D0CA081306C8B012@tlvmail1> <61DB25F71DCD46898D8CC7B836545E63@ruijie.com.cn> From: "Daniel Cohn" To: "Sam Cao" , X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 06:27:19 -0000 Hi Sam, see answers inline with [DC] -----Original Message----- From: Sam Cao [mailto:yuqun.cao@gmail.com]=20 Sent: Friday, June 03, 2011 4:58 AM To: Daniel Cohn; l2vpn@ietf.org Subject: Re: L2vpn Digest, Vol 84, Issue 6 Hi Daniel, Thank you very much for your comments. I understood your design, and = have 3 more questions, 1) Two PWs are always established and necessary since AC E-Tree Type is = locally configured=20 in any case. I agree (Your answer to my Q2). But as you know, most = members of one E-Tree=20 instance are Leaf for most E-Tree cases, if so, at least 50% PW is = useless. In addtion,=20 if we need to implement Fast ReRouting (PW backup), more uselss PW = are established.=20 How to solve this? As you konw, Root-Leaf-Mixed is only a small = proportion of E-Tree members.=20 [DC] Even when all ACs in one PE are leaf type, the root PW is still = required. This is because traffic received by this PE which originated = in a source AC, gets transmitted in a root PE, no matter what the = destination AC is.=20 2) The VSI E-Tree type is a parameter of the PW that interconnects the = PEs, you said. What is=20 the purpose?=20 [DC] This is the parameter that identifies root/leaf PW, i.e. by looking = at this parameter the PE can tell whether packets coming thru this PW = should be treated as originating in source or destination AC. 3) The third, I gave one example, it can make myself understood. Suppose = two PEs, say PE1 and PE2, belongs to one E-Tree instance, where PE1 are bound a Root AC and a Leaf AC, = and PE2 are only bound a Lead AC. <--------------E-Tree--------------> +---------+ +---------+ | PE1 | | PE2 | +---+ | +---+ | | +---+ | |CE1+----AC1----+--+ | | | | | |=20 +---+ (Root AC) | | V | | | | V | | | | S +--+------PW------+--+ S | | +---+ | | I | | | | I | | +---+ |CE2+----AC2----+--+ | | | | +--+----AC4----+CE4| +---+ (Leaf AC) | +---+ | | +---+ | (Leaf AC) +---+ +---------+ +---------+ =20 In this case, 2 PWs are established, I agree that it is reasonable. = Any frames are transmitted=20 from AC4 to PE1 via Spoke PW, then PE1 transmit the frames to AC1 = (Root AC), not AC2. If AC1 goes down, 2 PWs still exist, and now frames from AC4 still are = transmitted from AC4 to PE1 via=20 Spoke PW. On PE1 side, PE found that there is no Root AC and dicard = the frames. Is this correct?=20 If so, we will have one problem: both PEs are attached to Spoke AC, = but garbage frames are=20 ransmitted via Spoke PW.=20 [DC] I don't understand how this is different from a non-etree scenario = where the destination AC is down and multicast PDUs are transmitted all = the way until the last PE, which discards the frame upon finding that = the destination AC is down. Can u explain?=20 E-Tree needs extension to current standard, and I prefer to extend on = control plane since it is=20 clear for user. Sorry for so many questions. [DC] As I said I will get back to you soon with questions on your = proposal. Sorry for the delay. Sam ----- Original Message -----=20 From: "Daniel Cohn" To: "Sam Cao" ; Sent: Wednesday, June 01, 2011 10:25 PM Subject: RE: L2vpn Digest, Vol 84, Issue 6 Hi Sam, thanks for the feedback and please see my comments inline with = [DC]. Let me know if anything is still not clear. Regards, Daniel -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of Sam Cao Sent: Sunday, May 29, 2011 12:23 PM To: l2vpn@ietf.org Subject: =B4=F0=B8=B4: L2vpn Digest, Vol 84, Issue 6 Daniel, Today I read your draft and have some questions.=20 1) In Figure 2, "VSI Root PW" is used for frames originated from Root = ACs. Is it available for both AC1 on PE1 and AC3 (Root AC) on PE2? For = example, if one unknown unicast originated from AC1, it is carried via VSI root = PW and broadcasted to AC3 and AC4. Is it right? One unknown unicast = originated from AC3 is also carried via VSI Root PW. [DC] That is correct. Root/leaf PW selection is based solely upon source = AC type. 2) AC E-Tree Type. In your draft, it is just locally configured. If so, = Root PW and Leaf PW are always established while VSI has been configured, = right? PE selected the correct PW to send frames upon local configuration, is = it right? [DC] Right. 3) In 5.2.1, VSI E-Tree encoding. There are two VSI E-Tree types, one is E-Tree Root VSI, and one is E-Tree Leaf VSI. If so, in figure 2, if one = VSI is attached both Root ACs and Leaf ACs, what is its type?=20 [DC] The VSI E-Tree type is a parameter of the PW that interconnects the = PEs, not of the entire VSI. So in figure 2, the VSI root PW is signaled = with E-Tree Root VSI type, and the VSI leaf PW is signaled with E-Tree = Leaf VSI type. 4) Can you tell me the usage of VSI E-Tree identifier? Is it useful to establish PW? " pair", I guess = we have to separate one VSI into two VSIs, one is Root VSI and one is Leaf = VSI, but if so, it is not reasonable to establish just 2 PWs in Figure 2. = Root AC and Leaf AC can not attach to same VSI. [DC] As explained in the previous comment - there is only one VSI per PE = for a VPLS, and this VSI is interconnected to VSIs in other PEs via two = PWs. There are two ways to support E-Tree, I believe, one on data plane and = one on control plane. I also uploaded one draft on this "http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/". Would you please share some comments?=20 [DC] I reviewed your draft but I need your help in understanding some of = the concepts. I will write to you soon with questions. Yuqun (Sam) Cao Mobile: +86-18959186587 E-mail: Yuqun.cao@gmail.com=20 =20 -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: l2vpn-bounces@ietf.org = [mailto:l2vpn-bounces@ietf.org] =B4=FA=B1=ED l2vpn-request@ietf.org =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA5=D4=C224=C8=D5 3:00 =CA=D5=BC=FE=C8=CB: l2vpn@ietf.org =D6=F7=CC=E2: L2vpn Digest, Vol 84, Issue 6 If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to=20 https://www.ietf.org/mailman/listinfo/l2vpn Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send L2vpn mailing list submissions to l2vpn@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/l2vpn or, via email, send a message with subject or body 'help' to l2vpn-request@ietf.org You can reach the person managing the list at l2vpn-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of L2vpn digest..." Today's Topics: 1. Seeking feedback on I-D "Extension to LDP-VPLS for E-Tree Using Two PW" new revision (Daniel Cohn) ---------------------------------------------------------------------- Message: 1 Date: Mon, 23 May 2011 20:28:49 +0300 From: "Daniel Cohn" To: Subject: Seeking feedback on I-D "Extension to LDP-VPLS for E-Tree Using Two PW" new revision Message-ID: <44F4E579A764584EA9BDFD07D0CA081306C0D78B@tlvmail1> Content-Type: text/plain; charset=3D"us-ascii" Hi L2VPNers, We (the authors) uploaded a new revision of the "Extension to LDP-VPLS for E-Tree Using Two PW" at http://tools.ietf.org/id/draft-ram-l2vpn-ldp-vpls-etree-2pw-02.txt The main change from the previous revision is the use of new interface parameters TLVs (VSI E-Tree type and VSI E-Tree identifier) to identify root and leaf PWs, rather than defining new PW types. This is a result from feedback we received when we presented the draft at IETF 80. We are seeking more feedback from the mailing list, and would be grateful if you could review the document and post comments on the mailing list or directly to the authors. Regards, Daniel ------------------------------ _______________________________________________ L2vpn mailing list L2vpn@ietf.org https://www.ietf.org/mailman/listinfo/l2vpn End of L2vpn Digest, Vol 84, Issue 6 ************************************ From yuqun.cao@gmail.com Thu Jun 9 00:06:43 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16E991F0C38 for ; Thu, 9 Jun 2011 00:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.943 X-Spam-Level: X-Spam-Status: No, score=0.943 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1+3IHe0-UiO for ; Thu, 9 Jun 2011 00:06:42 -0700 (PDT) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by ietfa.amsl.com (Postfix) with ESMTP id 16CA621F8479 for ; Thu, 9 Jun 2011 00:06:42 -0700 (PDT) Received: by pxi20 with SMTP id 20so957242pxi.27 for ; Thu, 09 Jun 2011 00:06:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:from:to:references:subject:date :mime-version:content-type:content-transfer-encoding:x-priority :x-msmail-priority:x-mailer:disposition-notification-to:x-mimeole; bh=77JRKTcznl16Be3kqaNG1Ki70pE6jPQGYphwt94qRCg=; b=SjQScgljCLliEKaFR4h9d/JJUwy5SutoSw2YgzfBM5Vm87pjrb5akb+5Nm/hd8YgJ+ CmNmVjkGVrxTkpv/uwFEVDz7mLNu5AltZ4Rd+6v5SvKORbeR9Fjw+lIgxQmgTwT/C/hr cEdEOgNQKqSTZ1V5zOK2Jsz8TcvmUTHwkVvy4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:disposition-notification-to:x-mimeole; b=s9fRZE4U8mdcu+YcHBGCKATQ0iqTqgVlj9vdLY/QtU57kFEASj6M0uAR3ECFFlp5u8 IGi7W/btLN5cfQlUwoBWYi4u+9BAdP1Xrsjizx7XkbSqZCBssoQWxI1B/K4SSg05ERMp /FkIvcXGBqC8f4ruE9EyMuuro8EUaPGqfKZ4g= Received: by 10.68.51.228 with SMTP id n4mr126866pbo.381.1307603201680; Thu, 09 Jun 2011 00:06:41 -0700 (PDT) Received: from R01842 ([110.90.119.113]) by mx.google.com with ESMTPS id i7sm1179462pbj.10.2011.06.09.00.06.15 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 09 Jun 2011 00:06:39 -0700 (PDT) Message-ID: From: "Sam Cao" To: "Daniel Cohn" , References: <44F4E579A764584EA9BDFD07D0CA081306C8B012@tlvmail1> <61DB25F71DCD46898D8CC7B836545E63@ruijie.com.cn> <44F4E579A764584EA9BDFD07D0CA081306CF2D45@tlvmail1> Subject: Re: L2vpn Digest, Vol 84, Issue 6 Date: Thu, 9 Jun 2011 15:05:16 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4657 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 07:06:43 -0000 RGFuaWVsLA0KDQpJIHVuZGVyc3Rvb2QgeW91ciBhbnN3ZXIuIEkgYXNrZWQgdGhlIGZpcnN0IDIg cXVlc3Rpb25zIGluIG9yZGVyIHRvIGZ1bGx5IHVuZGVyc3RhbmQgeW91ciBpZGVhLg0KTm93IHdl IGNhbiBvbmx5IGZvY3VzIG9uIG15IGxhc3QgcXVlc3Rpb24uDQoNCkZpcnN0LCBmb3IgYSBub24t ZXRyZWUgc2NlbmFyaW8sIGFsbCBQRXMgaW4gVlBMUyBpbnN0YW5jZSBhcmUgZXF1YWwsIGFuZCBv bmUgUFcgaXMgZW5vdWdoIChSZWZlciANCnRvIFJGQyA2MDc0KS4gSWYgUFcgaXMgVVAsIG9uZSBQ RSBTSE9VTEQgc2VuZCBtdWx0aWNhc3QvYnJvYWRjYXN0L3Vua25vd24gdW5pY2F0IHZpYSB0aGUg UFcsIGl0IA0KbWFrZXMgc2Vuc2UuIEJ1dCBmb3IgZXRyZWUgc2NlbmFyaW8sIHdlIFNIT1VMRCBi cmVhayBjb21tdW5pY2F0aW9uIGJldHdlZW4gTGVhZnMuIElmIHdlIGtub3cgdGhhdCANCnRoZSBw ZWVyIGlzIGJvdW5kIG9ubHkgTGVhZnMgKFJvb3QgTGVhZiBnb2VzIGRvd24sIHRoYXQgbWVhbnMg b25seSBvbmUgTGVhZiBBQyBpcyBib3VuZCksIHdoeSB3ZSANCnN0aWxsIHNlbmQgdGhlIHBhY2tl dCBhbnMgd2FpdCB0aGUgcGVlciBkaXNjYXJkcyBpdD8gU28sIG1heWJlIHdlIG5lZWQgdG8gZmlu ZCBvbmUgd2F5IHRvIGltcHJvdmUgDQp0aGlzIHNvbHV0aW9uLiBJcyBpdCBjbGVhciBub3c/IFdo YXQgSSBtZWFuIGlzLCBub24tZXRyZWUgaXMgYSBkaWZmZXJlbnQgY2FzZS4NCg0KRGFuaWVsLCB0 aGFuayB5b3UgdmVyeSBtdWNoIGZvciB5b3VyIHRpbWUuIA0KDQpTYW0NCg0KDQotLS0tLSBPcmln aW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkRhbmllbCBDb2huIiA8RGFuaWVsQ0BvcmNraXQu Y29tPg0KVG86ICJTYW0gQ2FvIiA8eXVxdW4uY2FvQGdtYWlsLmNvbT47IDxsMnZwbkBpZXRmLm9y Zz4NClNlbnQ6IFRodXJzZGF5LCBKdW5lIDA5LCAyMDExIDI6MjcgUE0NClN1YmplY3Q6IFJFOiBM MnZwbiBEaWdlc3QsIFZvbCA4NCwgSXNzdWUgNg0KDQoNCkhpIFNhbSwgc2VlIGFuc3dlcnMgaW5s aW5lIHdpdGggW0RDXQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogU2FtIENh byBbbWFpbHRvOnl1cXVuLmNhb0BnbWFpbC5jb21dIA0KU2VudDogRnJpZGF5LCBKdW5lIDAzLCAy MDExIDQ6NTggQU0NClRvOiBEYW5pZWwgQ29objsgbDJ2cG5AaWV0Zi5vcmcNClN1YmplY3Q6IFJl OiBMMnZwbiBEaWdlc3QsIFZvbCA4NCwgSXNzdWUgNg0KDQpIaSBEYW5pZWwsDQoNClRoYW5rIHlv dSB2ZXJ5IG11Y2ggZm9yIHlvdXIgY29tbWVudHMuIEkgdW5kZXJzdG9vZCB5b3VyIGRlc2lnbiwg YW5kIGhhdmUgMyBtb3JlIHF1ZXN0aW9ucywNCg0KMSkgVHdvIFBXcyBhcmUgYWx3YXlzIGVzdGFi bGlzaGVkIGFuZCBuZWNlc3Nhcnkgc2luY2UgQUMgRS1UcmVlIFR5cGUgaXMgbG9jYWxseSBjb25m aWd1cmVkIA0KICAgaW4gYW55IGNhc2UuIEkgYWdyZWUgKFlvdXIgYW5zd2VyIHRvIG15IFEyKS4g QnV0IGFzIHlvdSBrbm93LCBtb3N0IG1lbWJlcnMgb2Ygb25lIEUtVHJlZSANCiAgIGluc3RhbmNl IGFyZSBMZWFmIGZvciBtb3N0IEUtVHJlZSBjYXNlcywgaWYgc28sIGF0IGxlYXN0IDUwJSBQVyBp cyB1c2VsZXNzLiBJbiBhZGR0aW9uLCANCiAgIGlmIHdlIG5lZWQgdG8gaW1wbGVtZW50IEZhc3Qg UmVSb3V0aW5nIChQVyBiYWNrdXApLCBtb3JlIHVzZWxzcyBQVyBhcmUgZXN0YWJsaXNoZWQuIA0K ICAgSG93IHRvIHNvbHZlIHRoaXM/IEFzIHlvdSBrb253LCBSb290LUxlYWYtTWl4ZWQgaXMgb25s eSBhIHNtYWxsIHByb3BvcnRpb24gb2YgRS1UcmVlIG1lbWJlcnMuIA0KDQpbRENdIEV2ZW4gd2hl biBhbGwgQUNzIGluIG9uZSBQRSBhcmUgbGVhZiB0eXBlLCB0aGUgcm9vdCBQVyBpcyBzdGlsbCBy ZXF1aXJlZC4gVGhpcyBpcyBiZWNhdXNlIHRyYWZmaWMgcmVjZWl2ZWQgYnkgdGhpcyBQRSB3aGlj aCBvcmlnaW5hdGVkIGluIGEgc291cmNlIEFDLCBnZXRzIHRyYW5zbWl0dGVkIGluIGEgcm9vdCBQ RSwgbm8gbWF0dGVyIHdoYXQgdGhlIGRlc3RpbmF0aW9uIEFDIGlzLiANCg0KMikgVGhlIFZTSSBF LVRyZWUgdHlwZSBpcyBhIHBhcmFtZXRlciBvZiB0aGUgUFcgdGhhdCBpbnRlcmNvbm5lY3RzIHRo ZSBQRXMsIHlvdSBzYWlkLiBXaGF0IGlzIA0KICAgdGhlIHB1cnBvc2U/IA0KDQpbRENdIFRoaXMg aXMgdGhlIHBhcmFtZXRlciB0aGF0IGlkZW50aWZpZXMgcm9vdC9sZWFmIFBXLCBpLmUuIGJ5IGxv b2tpbmcgYXQgdGhpcyBwYXJhbWV0ZXIgdGhlIFBFIGNhbiB0ZWxsIHdoZXRoZXIgcGFja2V0cyBj b21pbmcgdGhydSB0aGlzIFBXIHNob3VsZCBiZSB0cmVhdGVkIGFzIG9yaWdpbmF0aW5nIGluIHNv dXJjZSBvciBkZXN0aW5hdGlvbiBBQy4NCg0KMykgVGhlIHRoaXJkLCBJIGdhdmUgb25lIGV4YW1w bGUsIGl0IGNhbiBtYWtlIG15c2VsZiB1bmRlcnN0b29kLiBTdXBwb3NlIHR3byBQRXMsIHNheSBQ RTEgYW5kIFBFMiwgYmVsb25ncw0KICAgdG8gb25lIEUtVHJlZSBpbnN0YW5jZSwgd2hlcmUgUEUx IGFyZSBib3VuZCBhIFJvb3QgQUMgYW5kIGEgTGVhZiBBQywgYW5kIFBFMiBhcmUgb25seSBib3Vu ZA0KICAgYSBMZWFkIEFDLg0KDQogICAgICAgICAgICAgICAgICAgPC0tLS0tLS0tLS0tLS0tRS1U cmVlLS0tLS0tLS0tLS0tLS0+DQogICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLSsgICAgICAg ICAgICAgICstLS0tLS0tLS0rDQogICAgICAgICAgICAgICAgICAgfCAgIFBFMSAgIHwgICAgICAg ICAgICAgIHwgICBQRTIgICB8DQogICArLS0tKyAgICAgICAgICAgfCAgKy0tLSsgIHwgICAgICAg ICAgICAgIHwgICstLS0rICB8DQogICB8Q0UxKy0tLS1BQzEtLS0tKy0tKyAgIHwgIHwgICAgICAg ICAgICAgIHwgIHwgICB8ICB8IA0KICAgKy0tLSsgKFJvb3QgQUMpIHwgIHwgViB8ICB8ICAgICAg ICAgICAgICB8ICB8IFYgfCAgfA0KICAgICAgICAgICAgICAgICAgIHwgIHwgUyArLS0rLS0tLS0t UFctLS0tLS0rLS0rIFMgfCAgfA0KICAgKy0tLSsgICAgICAgICAgIHwgIHwgSSB8ICB8ICAgICAg ICAgICAgICB8ICB8IEkgfCAgfCAgICAgICAgICAgKy0tLSsNCiAgIHxDRTIrLS0tLUFDMi0tLS0r LS0rICAgfCAgfCAgICAgICAgICAgICAgfCAgfCAgICstLSstLS0tQUM0LS0tLStDRTR8DQogICAr LS0tKyAoTGVhZiBBQykgfCAgKy0tLSsgIHwgICAgICAgICAgICAgIHwgICstLS0rICB8IChMZWFm IEFDKSArLS0tKw0KICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0rICAgICAgICAgICAgICAr LS0tLS0tLS0tKw0KICAgDQogIEluIHRoaXMgY2FzZSwgMiBQV3MgYXJlIGVzdGFibGlzaGVkLCBJ IGFncmVlIHRoYXQgaXQgaXMgcmVhc29uYWJsZS4gQW55IGZyYW1lcyBhcmUgdHJhbnNtaXR0ZWQg DQogIGZyb20gQUM0IHRvICBQRTEgdmlhIFNwb2tlIFBXLCB0aGVuIFBFMSB0cmFuc21pdCB0aGUg ZnJhbWVzIHRvIEFDMSAoUm9vdCBBQyksIG5vdCBBQzIuIElmIEFDMQ0KICBnb2VzIGRvd24sIDIg UFdzIHN0aWxsIGV4aXN0LCBhbmQgbm93IGZyYW1lcyBmcm9tIEFDNCBzdGlsbCBhcmUgdHJhbnNt aXR0ZWQgZnJvbSBBQzQgdG8gUEUxIHZpYSANCiAgU3Bva2UgUFcuIE9uIFBFMSBzaWRlLCBQRSBm b3VuZCB0aGF0IHRoZXJlIGlzIG5vIFJvb3QgQUMgYW5kIGRpY2FyZCB0aGUgZnJhbWVzLiBJcyB0 aGlzIGNvcnJlY3Q/IA0KICBJZiBzbywgd2Ugd2lsbCBoYXZlIG9uZSBwcm9ibGVtOiBib3RoIFBF cyBhcmUgYXR0YWNoZWQgdG8gU3Bva2UgQUMsIGJ1dCBnYXJiYWdlIGZyYW1lcyBhcmUgDQogIHJh bnNtaXR0ZWQgdmlhIFNwb2tlIFBXLiANCg0KW0RDXSBJIGRvbid0IHVuZGVyc3RhbmQgaG93IHRo aXMgaXMgZGlmZmVyZW50IGZyb20gYSBub24tZXRyZWUgc2NlbmFyaW8gd2hlcmUgdGhlIGRlc3Rp bmF0aW9uIEFDIGlzIGRvd24gYW5kIG11bHRpY2FzdCBQRFVzIGFyZSB0cmFuc21pdHRlZCBhbGwg dGhlIHdheSB1bnRpbCB0aGUgbGFzdCBQRSwgd2hpY2ggZGlzY2FyZHMgdGhlIGZyYW1lIHVwb24g ZmluZGluZyB0aGF0IHRoZSBkZXN0aW5hdGlvbiBBQyBpcyBkb3duLiBDYW4gdSBleHBsYWluPyAN Cg0KICBFLVRyZWUgbmVlZHMgZXh0ZW5zaW9uIHRvIGN1cnJlbnQgc3RhbmRhcmQsIGFuZCBJIHBy ZWZlciB0byBleHRlbmQgb24gY29udHJvbCBwbGFuZSBzaW5jZSBpdCBpcyANCiAgY2xlYXIgZm9y IHVzZXIuIFNvcnJ5IGZvciBzbyBtYW55IHF1ZXN0aW9ucy4NCg0KW0RDXSBBcyBJIHNhaWQgSSB3 aWxsIGdldCBiYWNrIHRvIHlvdSBzb29uIHdpdGggcXVlc3Rpb25zIG9uIHlvdXIgcHJvcG9zYWwu IFNvcnJ5IGZvciB0aGUgZGVsYXkuDQoNClNhbQ0KDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2Ug LS0tLS0gDQpGcm9tOiAiRGFuaWVsIENvaG4iIDxEYW5pZWxDQG9yY2tpdC5jb20+DQpUbzogIlNh bSBDYW8iIDx5dXF1bi5jYW9AZ21haWwuY29tPjsgPGwydnBuQGlldGYub3JnPg0KU2VudDogV2Vk bmVzZGF5LCBKdW5lIDAxLCAyMDExIDEwOjI1IFBNDQpTdWJqZWN0OiBSRTogTDJ2cG4gRGlnZXN0 LCBWb2wgODQsIElzc3VlIDYNCg0KDQpIaSBTYW0sIHRoYW5rcyBmb3IgdGhlIGZlZWRiYWNrIGFu ZCBwbGVhc2Ugc2VlIG15IGNvbW1lbnRzIGlubGluZSB3aXRoIFtEQ10uIExldCBtZSBrbm93IGlm IGFueXRoaW5nIGlzIHN0aWxsIG5vdCBjbGVhci4NCg0KUmVnYXJkcywNCg0KRGFuaWVsDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBsMnZwbi1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFNhbSBDYW8NClNlbnQ6 IFN1bmRheSwgTWF5IDI5LCAyMDExIDEyOjIzIFBNDQpUbzogbDJ2cG5AaWV0Zi5vcmcNClN1Ympl Y3Q6ILTwuLQ6IEwydnBuIERpZ2VzdCwgVm9sIDg0LCBJc3N1ZSA2DQoNCkRhbmllbCwNCg0KVG9k YXkgSSByZWFkIHlvdXIgZHJhZnQgYW5kIGhhdmUgc29tZSBxdWVzdGlvbnMuIA0KDQoxKSBJbiBG aWd1cmUgMiwgIlZTSSBSb290IFBXIiBpcyB1c2VkIGZvciBmcmFtZXMgb3JpZ2luYXRlZCBmcm9t IFJvb3QgQUNzLg0KSXMgaXQgYXZhaWxhYmxlIGZvciBib3RoIEFDMSBvbiBQRTEgYW5kIEFDMyAo Um9vdCBBQykgb24gUEUyPyBGb3IgZXhhbXBsZSwNCmlmIG9uZSB1bmtub3duIHVuaWNhc3Qgb3Jp Z2luYXRlZCBmcm9tIEFDMSwgaXQgaXMgY2FycmllZCB2aWEgVlNJIHJvb3QgUFcNCmFuZCBicm9h ZGNhc3RlZCB0byBBQzMgYW5kIEFDNC4gSXMgaXQgcmlnaHQ/IE9uZSB1bmtub3duIHVuaWNhc3Qg b3JpZ2luYXRlZA0KZnJvbSBBQzMgaXMgYWxzbyBjYXJyaWVkIHZpYSBWU0kgUm9vdCBQVy4NCg0K W0RDXSBUaGF0IGlzIGNvcnJlY3QuIFJvb3QvbGVhZiBQVyBzZWxlY3Rpb24gaXMgYmFzZWQgc29s ZWx5IHVwb24gc291cmNlIEFDIHR5cGUuDQoNCjIpIEFDIEUtVHJlZSBUeXBlLiBJbiB5b3VyIGRy YWZ0LCBpdCBpcyBqdXN0IGxvY2FsbHkgY29uZmlndXJlZC4gSWYgc28sIFJvb3QNClBXIGFuZCBM ZWFmIFBXIGFyZSBhbHdheXMgZXN0YWJsaXNoZWQgd2hpbGUgVlNJIGhhcyBiZWVuIGNvbmZpZ3Vy ZWQsIHJpZ2h0Pw0KUEUgc2VsZWN0ZWQgdGhlIGNvcnJlY3QgUFcgdG8gc2VuZCBmcmFtZXMgdXBv biBsb2NhbCBjb25maWd1cmF0aW9uLCBpcyBpdA0KcmlnaHQ/DQoNCltEQ10gUmlnaHQuDQoNCjMp IEluIDUuMi4xLCBWU0kgRS1UcmVlIGVuY29kaW5nLiBUaGVyZSBhcmUgdHdvIFZTSSBFLVRyZWUg dHlwZXMsIG9uZSBpcw0KRS1UcmVlIFJvb3QgVlNJLCBhbmQgb25lIGlzIEUtVHJlZSBMZWFmIFZT SS4gSWYgc28sIGluIGZpZ3VyZSAyLCBpZiBvbmUgVlNJDQppcyBhdHRhY2hlZCBib3RoIFJvb3Qg QUNzIGFuZCBMZWFmIEFDcywgd2hhdCBpcyBpdHMgdHlwZT8gDQoNCltEQ10gVGhlIFZTSSBFLVRy ZWUgdHlwZSBpcyBhIHBhcmFtZXRlciBvZiB0aGUgUFcgdGhhdCBpbnRlcmNvbm5lY3RzIHRoZSBQ RXMsIG5vdCBvZiB0aGUgZW50aXJlIFZTSS4gU28gaW4gZmlndXJlIDIsIHRoZSBWU0kgcm9vdCBQ VyBpcyBzaWduYWxlZCB3aXRoIEUtVHJlZSBSb290IFZTSSB0eXBlLCBhbmQgdGhlIFZTSSBsZWFm IFBXIGlzIHNpZ25hbGVkIHdpdGggRS1UcmVlIExlYWYgVlNJIHR5cGUuDQoNCjQpIENhbiB5b3Ug dGVsbCBtZSB0aGUgdXNhZ2Ugb2YgVlNJIEUtVHJlZSBpZGVudGlmaWVyPyBJcyBpdCB1c2VmdWwg dG8NCmVzdGFibGlzaCBQVz8gIjxWU0kgRS1UcmVlIHR5cGUsIFZTSSBFLVRyZWUgaWRlbnRpZmll cj4gcGFpciIsIEkgZ3Vlc3Mgd2UNCmhhdmUgdG8gc2VwYXJhdGUgb25lIFZTSSBpbnRvIHR3byBW U0lzLCBvbmUgaXMgUm9vdCBWU0kgYW5kIG9uZSBpcyBMZWFmIFZTSSwNCmJ1dCBpZiBzbywgaXQg aXMgbm90IHJlYXNvbmFibGUgdG8gZXN0YWJsaXNoIGp1c3QgMiBQV3MgaW4gRmlndXJlIDIuIFJv b3QgQUMNCmFuZCBMZWFmIEFDIGNhbiBub3QgYXR0YWNoIHRvIHNhbWUgVlNJLg0KDQpbRENdIEFz IGV4cGxhaW5lZCBpbiB0aGUgcHJldmlvdXMgY29tbWVudCAtIHRoZXJlIGlzIG9ubHkgb25lIFZT SSBwZXIgUEUgZm9yIGEgVlBMUywgYW5kIHRoaXMgVlNJIGlzIGludGVyY29ubmVjdGVkIHRvIFZT SXMgaW4gb3RoZXIgUEVzIHZpYSB0d28gUFdzLg0KDQpUaGVyZSBhcmUgdHdvIHdheXMgdG8gc3Vw cG9ydCBFLVRyZWUsIEkgYmVsaWV2ZSwgb25lIG9uIGRhdGEgcGxhbmUgYW5kIG9uZQ0Kb24gY29u dHJvbCBwbGFuZS4gSSBhbHNvIHVwbG9hZGVkIG9uZSBkcmFmdCBvbiB0aGlzDQoiaHR0cDovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1jYW8tbDJ2cG4tdnBscy1ldHJlZS8iLiBXb3Vs ZCB5b3UNCnBsZWFzZSBzaGFyZSBzb21lIGNvbW1lbnRzPyANCg0KW0RDXSBJIHJldmlld2VkIHlv dXIgZHJhZnQgYnV0IEkgbmVlZCB5b3VyIGhlbHAgaW4gdW5kZXJzdGFuZGluZyBzb21lIG9mIHRo ZSBjb25jZXB0cy4gSSB3aWxsIHdyaXRlIHRvIHlvdSBzb29uIHdpdGggcXVlc3Rpb25zLg0KDQpZ dXF1biAoU2FtKSBDYW8NCk1vYmlsZTogKzg2LTE4OTU5MTg2NTg3DQpFLW1haWw6IFl1cXVuLmNh b0BnbWFpbC5jb20gDQogDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogbDJ2cG4tYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmddILT6se0NCmwydnBuLXJl cXVlc3RAaWV0Zi5vcmcNCreiy83KsbzkOiAyMDExxOo11MIyNMjVIDM6MDANCsrVvP7IyzogbDJ2 cG5AaWV0Zi5vcmcNCtb3zOI6IEwydnBuIERpZ2VzdCwgVm9sIDg0LCBJc3N1ZSA2DQoNCklmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgZGlnZXN0IHdpdGhvdXQgYWxsIHRoZSBpbmRpdmlkdWFsIG1l c3NhZ2UNCmF0dGFjaG1lbnRzIHlvdSB3aWxsIG5lZWQgdG8gdXBkYXRlIHlvdXIgZGlnZXN0IG9w dGlvbnMgaW4geW91ciBsaXN0DQpzdWJzY3JpcHRpb24uICBUbyBkbyBzbywgZ28gdG8gDQoNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbDJ2cG4NCg0KQ2xpY2sgdGhlICdV bnN1YnNjcmliZSBvciBlZGl0IG9wdGlvbnMnIGJ1dHRvbiwgbG9nIGluLCBhbmQgc2V0ICJHZXQN Ck1JTUUgb3IgUGxhaW4gVGV4dCBEaWdlc3RzPyIgdG8gTUlNRS4gIFlvdSBjYW4gc2V0IHRoaXMg b3B0aW9uDQpnbG9iYWxseSBmb3IgYWxsIHRoZSBsaXN0IGRpZ2VzdHMgeW91IHJlY2VpdmUgYXQg dGhpcyBwb2ludC4NCg0KDQoNClNlbmQgTDJ2cG4gbWFpbGluZyBsaXN0IHN1Ym1pc3Npb25zIHRv DQpsMnZwbkBpZXRmLm9yZw0KDQpUbyBzdWJzY3JpYmUgb3IgdW5zdWJzY3JpYmUgdmlhIHRoZSBX b3JsZCBXaWRlIFdlYiwgdmlzaXQNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbDJ2cG4NCm9yLCB2aWEgZW1haWwsIHNlbmQgYSBtZXNzYWdlIHdpdGggc3ViamVjdCBvciBi b2R5ICdoZWxwJyB0bw0KbDJ2cG4tcmVxdWVzdEBpZXRmLm9yZw0KDQpZb3UgY2FuIHJlYWNoIHRo ZSBwZXJzb24gbWFuYWdpbmcgdGhlIGxpc3QgYXQNCmwydnBuLW93bmVyQGlldGYub3JnDQoNCldo ZW4gcmVwbHlpbmcsIHBsZWFzZSBlZGl0IHlvdXIgU3ViamVjdCBsaW5lIHNvIGl0IGlzIG1vcmUg c3BlY2lmaWMNCnRoYW4gIlJlOiBDb250ZW50cyBvZiBMMnZwbiBkaWdlc3QuLi4iDQoNCg0KVG9k YXkncyBUb3BpY3M6DQoNCiAgIDEuIFNlZWtpbmcgZmVlZGJhY2sgb24gSS1EICJFeHRlbnNpb24g dG8gTERQLVZQTFMgZm9yIEUtVHJlZQ0KICAgICAgVXNpbmcgVHdvIFBXIiBuZXcgcmV2aXNpb24g KERhbmllbCBDb2huKQ0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KTWVzc2FnZTogMQ0KRGF0ZTogTW9u LCAyMyBNYXkgMjAxMSAyMDoyODo0OSArMDMwMA0KRnJvbTogIkRhbmllbCBDb2huIiA8RGFuaWVs Q0BvcmNraXQuY29tPg0KVG86IDxsMnZwbkBpZXRmLm9yZz4NClN1YmplY3Q6IFNlZWtpbmcgZmVl ZGJhY2sgb24gSS1EICJFeHRlbnNpb24gdG8gTERQLVZQTFMgZm9yIEUtVHJlZQ0KVXNpbmcgVHdv IFBXIiBuZXcgcmV2aXNpb24NCk1lc3NhZ2UtSUQ6IDw0NEY0RTU3OUE3NjQ1ODRFQTlCREZEMDdE MENBMDgxMzA2QzBENzhCQHRsdm1haWwxPg0KQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFy c2V0PSJ1cy1hc2NpaSINCg0KSGkgTDJWUE5lcnMsDQoNCldlICh0aGUgYXV0aG9ycykgdXBsb2Fk ZWQgYSBuZXcgcmV2aXNpb24gb2YgdGhlICJFeHRlbnNpb24gdG8gTERQLVZQTFMNCmZvciBFLVRy ZWUgVXNpbmcgVHdvIFBXIiBhdA0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LXJhbS1s MnZwbi1sZHAtdnBscy1ldHJlZS0ycHctMDIudHh0DQoNClRoZSBtYWluIGNoYW5nZSBmcm9tIHRo ZSBwcmV2aW91cyByZXZpc2lvbiBpcyB0aGUgdXNlIG9mIG5ldyBpbnRlcmZhY2UNCnBhcmFtZXRl cnMgVExWcyAoVlNJIEUtVHJlZSB0eXBlIGFuZCBWU0kgRS1UcmVlIGlkZW50aWZpZXIpIHRvIGlk ZW50aWZ5DQpyb290IGFuZCBsZWFmIFBXcywgcmF0aGVyIHRoYW4gZGVmaW5pbmcgbmV3IFBXIHR5 cGVzLiBUaGlzIGlzIGEgcmVzdWx0DQpmcm9tIGZlZWRiYWNrIHdlIHJlY2VpdmVkIHdoZW4gd2Ug cHJlc2VudGVkIHRoZSBkcmFmdCBhdCBJRVRGIDgwLg0KDQpXZSBhcmUgc2Vla2luZyBtb3JlIGZl ZWRiYWNrIGZyb20gdGhlIG1haWxpbmcgbGlzdCwgYW5kIHdvdWxkIGJlDQpncmF0ZWZ1bCBpZiB5 b3UgY291bGQgcmV2aWV3IHRoZSBkb2N1bWVudCBhbmQgcG9zdCBjb21tZW50cyBvbiB0aGUNCm1h aWxpbmcgbGlzdCBvciBkaXJlY3RseSB0byB0aGUgYXV0aG9ycy4NCg0KUmVnYXJkcywNCg0KRGFu aWVsDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTDJ2cG4gbWFpbGluZyBsaXN0 DQpMMnZwbkBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9s MnZwbg0KDQoNCkVuZCBvZiBMMnZwbiBEaWdlc3QsIFZvbCA4NCwgSXNzdWUgNg0KKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqDQoNCg== From wwwrun@rfc-editor.org Fri Jun 10 10:27:35 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7D1F11E8152; Fri, 10 Jun 2011 10:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.408 X-Spam-Level: X-Spam-Status: No, score=-102.408 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-sIys3-v-Dh; Fri, 10 Jun 2011 10:27:35 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 5EED411E8151; Fri, 10 Jun 2011 10:27:35 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 4BB7D98C51B; Fri, 10 Jun 2011 10:27:35 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 6246 on Virtual Private LAN Service (VPLS) Interoperability with Customer Edge (CE) Bridges From: rfc-editor@rfc-editor.org Message-Id: <20110610172735.4BB7D98C51B@rfc-editor.org> Date: Fri, 10 Jun 2011 10:27:35 -0700 (PDT) Cc: l2vpn@ietf.org, rfc-editor@rfc-editor.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 17:27:36 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6246 Title: Virtual Private LAN Service (VPLS) Interoperability with Customer Edge (CE) Bridges Author: A. Sajassi, Ed., F. Brockners, D. Mohan, Ed., Y. Serbest Status: Informational Stream: IETF Date: June 2011 Mailbox: sajassi@cisco.com, fbrockne@cisco.com, dinmohan@hotmail.com, yetik_serbest@labs.att.com Pages: 20 Characters: 51024 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-l2vpn-vpls-bridge-interop-06.txt URL: http://www.rfc-editor.org/rfc/rfc6246.txt One of the main motivations behind Virtual Private LAN Service (VPLS) is its ability to provide connectivity not only among customer routers and servers/hosts but also among customer IEEE bridges. VPLS is expected to deliver the same level of service that current enterprise users are accustomed to from their own enterprise bridged networks or their Ethernet Service Providers. When customer edge (CE) devices are IEEE bridges, then there are certain issues and challenges that need to be accounted for in a VPLS network. The majority of these issues have been addressed in the IEEE 802.1ad standard for provider bridges and they can be leveraged for VPLS networks. This document extends the provider edge (PE) model described in RFC 4664 based on IEEE 802.1ad bridge module, and it illustrates a clear demarcation between the IEEE bridge module and IETF LAN emulation module. By doing so, it shows that the majority of interoperability issues with CE bridges can be delegated to the 802.1ad bridge module, thus removing the burden on the IETF LAN emulation module within a VPLS PE. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Layer 2 Virtual Private Networks Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From sboutros@cisco.com Mon Jun 13 11:22:50 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EDBA11E816A for ; Mon, 13 Jun 2011 11:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdQ1CdsiHUgp for ; Mon, 13 Jun 2011 11:22:50 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id E18F511E813F for ; Mon, 13 Jun 2011 11:22:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sboutros@cisco.com; l=236; q=dns/txt; s=iport; t=1307989369; x=1309198969; h=date:to:from:subject:cc:mime-version:message-id; bh=xA2qmy+xYj70uxfg5KZMJvvmQzf4PhDtezP1ybloDic=; b=DwUIgsUOxD1q1yZh80gNMje5TUIYzKUgIHZKTOwAkTO+jnMUkOjuGVb7 D/bfvXDiKnLZ3IVW5ViGCb3YEke1oXrWn2UbR92qFffBYQ1M2nXQ4U3Tm e7AM3XUCSt+GltL+q4m8Evt/eqeBu3csNoX4a3sni5LaIuO4N/tk41nMr 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUIAO1U9k2rRDoI/2dsb2JhbABSh1yQLo4kd6pPnWaGJASHDY5/iyU X-IronPort-AV: E=Sophos;i="4.65,359,1304294400"; d="scan'208";a="336056529" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 13 Jun 2011 18:22:36 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5DIMaTM017510; Mon, 13 Jun 2011 18:22:36 GMT Received: from xfe-sjc-222.amer.cisco.com ([128.107.191.87]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 Jun 2011 11:22:35 -0700 Received: from sboutros-wxp02.ciswco.com ([10.21.125.42]) by xfe-sjc-222.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 Jun 2011 11:22:35 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 13 Jun 2011 11:22:33 -0700 To: florin.balus@alcatel-lucent.com From: Sami Boutros Subject: http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-ldp-mac-opt-03 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 13 Jun 2011 18:22:35.0610 (UTC) FILETIME=[DE5AFBA0:01CC29F6] Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 18:22:50 -0000 Hi Florin, Are you folks planning to refresh the draft? Will you still keep the PE-ID TLV? or will the draft be updated to remove the PE-ID TLV and use the parameter TLV with the N Bit for the H-VPLS case? Thanks, Sami From florin.balus@alcatel-lucent.com Mon Jun 13 11:31:25 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D45EE21F846B for ; Mon, 13 Jun 2011 11:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HAIoVOn647Ty for ; Mon, 13 Jun 2011 11:31:25 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id E1C4A21F8468 for ; Mon, 13 Jun 2011 11:31:24 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p5DIVJ6d027391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Jun 2011 13:31:20 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p5DIVJ9T013986 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 13 Jun 2011 13:31:19 -0500 Received: from USNAVSXCHMBSC3.ndc.alcatel-lucent.com ([135.3.39.144]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Mon, 13 Jun 2011 13:31:19 -0500 From: "Balus, Florin Stelian (Florin)" To: Sami Boutros Date: Mon, 13 Jun 2011 13:31:17 -0500 Subject: RE: http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-ldp-mac-opt-03 Thread-Topic: http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-ldp-mac-opt-03 Thread-Index: Acwp9upTl3ET1+khS6K8w2+M34NCiwAAISpA Message-ID: <2073A6C5467C99478898544C6EBA3F4602B9EEAB2B@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 18:31:25 -0000 Hi Sami, Timely question: we will be reviewing the updated draft between authors and= we plan to send it out early next week.=20 And yes as per our slides presented some time ago we plan to consolidate th= e procedures and keep the Parameter TLV. You should see an update going out to the list once we submit it, likely Mo= nday.=20 Thanks, Florin -----Original Message----- From: Sami Boutros [mailto:sboutros@cisco.com]=20 Sent: Monday, June 13, 2011 11:23 AM To: Balus, Florin Stelian (Florin) Cc: l2vpn@ietf.org Subject: http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-ldp-mac-opt-03 Hi Florin, Are you folks planning to refresh the draft? Will you still keep the PE-ID TLV? or will the draft be updated to=20 remove the PE-ID TLV and use the parameter TLV with the N Bit for the=20 H-VPLS case? Thanks, Sami From giles.heron@gmail.com Mon Jun 13 16:07:37 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0096B228011 for ; Mon, 13 Jun 2011 16:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.643 X-Spam-Level: X-Spam-Status: No, score=-0.643 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, SARE_MLB_Stock6=1.56] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPWmZY2TpI-K for ; Mon, 13 Jun 2011 16:07:35 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 91A58228010 for ; Mon, 13 Jun 2011 16:07:31 -0700 (PDT) Received: by wyb29 with SMTP id 29so4069561wyb.31 for ; Mon, 13 Jun 2011 16:07:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:user-agent:date:subject:from:to:cc:message-id :thread-topic:thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=QIo8lAPM64cMxt7RQnDXFib7L9wSOBPl5fWsjYcJaf8=; b=UGdbrCFQ9NEgz9Y+zPuzW/JDqXNp62KHo2XxqW0CtrJpaNPKiRK/eXWCjA1nSzoZo0 XiP5PcGxpMSZAi11LEt10KD+19o6rX8jFVCP7hL0MY3QWAKv4njBKOTNUo1kMPiih9pA InPhiV4GjsX6wg0C2cEoqM5j5kA3FlophOWyo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=GMM8udN7mLDOihwgUdVI164aCw6H2IqhQubh82dkWZoNblQTxOorUZ9Ef771Q/oUZL mdMLsBsCZv/aaNXDn1J+BpBNe6T2j+hq1qZuVcAGu6+OxW+G4W8Ku8Qql041L1HV19eF mQ29NK8uziaYFxKsLd/95ZEEcsnVLooxqHGI8= Received: by 10.217.7.72 with SMTP id z50mr5369287wes.60.1308006450519; Mon, 13 Jun 2011 16:07:30 -0700 (PDT) Received: from [10.55.91.184] (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id k70sm3181487weq.6.2011.06.13.16.07.23 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 13 Jun 2011 16:07:27 -0700 (PDT) User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Tue, 14 Jun 2011 00:08:02 +0100 Subject: Re: Draft of new L2VPN WG Charter From: Giles Heron To: "Bitar, Nabil N" , Benson Schliesser , "Shah, Himanshu" , Thomas Nadeau Message-ID: Thread-Topic: Draft of new L2VPN WG Charter Thread-Index: AcvvtA2JzqTxhFkJSFamDqHmBDPKfwAAiwePAAI/U3QHTQhEmQdK2Z4p In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 23:07:37 -0000 So in the absence of any follow-up to Nabil=B9s email we=B9d like to propose that we adopt the charter as below. The only modifications from the charter Giles posted at the start of this thread are: 1) fixed the 2011 date on VPMS Auto-Discovery to 2012 (as spotted by Ben) 2) changed E-Tree from =B3technology=B2 to =B3service=B2 (as suggested by Yuanlong) 3) we=B9ve pushed the E-VPN solution and OAM/MIB milestones back a year, in response to Joel=B9s comment about deferring these. The main area of debate seems to have been the second sentence: =B3It will also address requirements driven by cloud computing services and data centers as they apply to Layer-2 VPN services.=B2 Unless there=B9s any strong objection to this sentence that garners some degree of consensus we propose to leave it in. We=B9d like to wrap this up in the next couple of weeks, so let=B9s bring any debate to a close by Friday 24th June and then move forward. Those with sharp eyes will notice that the first of our new deadlines are fast approaching! Giles & Nabil The L2VPN working group is responsible for defining and specifying a limited number of solutions for supporting provider-provisioned Layer-2 Virtual Private Networks (L2VPNs). It will also address requirements driven by cloud computing services and data centers as they apply to Layer-2 VPN services. Layer-2 VPNs defined by L2VPN operate over pseudowires (PWs) as defined by the PWE3 WG or over MPLS PSN tunnels. A L2VPN emulates a "native" service over a PSN that is adequately faithful to, but may not be entirely indistinguishable from the native service itself. Further, following in the "edge-to-edge" nature of the service, the L2VPN WG will not define any mechanisms which exert control over the underlying PSN. When necessary it may, however, recommend or require the use of existing PSN QoS and path control mechanisms between the PEs which provide the L2VPN connectivity. Layer-2 VPNs comprise the following: 1. Virtual Private LAN Service (VPLS) -- A Layer-2 service that emulates a switched Ethernet (V)LAN across an MPLS PSN. 2. Virtual Private Wire Service (VPWS) -- A Layer-2 service that provides point-to-point connectivity for a variety of link layers, including Frame Relay, ATM, Ethernet, PPP, etc., across an MPLS PSN. 3. Virtual Private Multicast Service (VPMS) -- A Layer-2 service that provides point-to-multipoint connectivity for a variety of link layers across an MPLS PSN. 4. IP-only L2VPN =AD An IP-only service over an MPLS PSN. The WG will address two specific types of IP-only L2VPN: a) Point-to-point Layer-2 VPN. This service is similar to VPWS, but also supports heterogenous Attachment Circuits at either end of a single point-to-point service. b) Multipoint-to-multipoint Layer-2 VPN. This service is similar to VPLS, but learns IP and MAC address bindings from ARPs and broadcast/multicast IP packets. 5. Ethernet VPN (E-VPN) - A Layer-2 service that emulates an Ethernet (V)LAN across an MPLS PSN. E-VPN supports load-sharing across multiple connections from a Layer-2 site to an L2VPN service, and also supports control plane distribution of MAC addresses and IP to MAC address bindings in the VPN. E-VPN is primarily targeted to support large-scale L2VPNs with resiliency requirements not satisfied by other L2VPN solutions. 6. E-Tree =AD a Layer-2 service defined by the MEF, which provides connectivity between one or more =B3root=B2 nodes and one or more =B3leaf=B2 nodes, with the restriction that leaves may only communicate with roots (and not with each other). L2VPNs will make use of existing IETF specified mechanisms unless there are technical reasons why the existing mechanisms are insufficient or unnecessary. The L2VPN WG is responsible for specification of the discovery and membership of PEs participating in a Layer-2 VPN as well as the membership of CE devices for a specific instance of an L2VPN. The L2VPN WG will provide extensions of existing protocols that will be discussed in protocol-specific WGs. In particular, the L2VPN WG may define extensions to pseudowire management mechanisms for VPLS. Those extensions will be reviewed by the PWE3 WG to ensure they are aligned with the overall design/architecture of PWE3. The L2VPN WG will not define new encapsulations, control, or resiliency mechanisms specifically related to pseudowires. Furthermore, when the L2VPN solution is based on PWs, the L2VPN WG will not define protocol inter-working between an L2VPN and native service Layer-2 OAM or resiliency mechanisms. The L2VPN WG may define how to operate native service-layer control, OAM or resiliency mechanisms on top of an L2VPN. In addition, it may define native data plane and/or control plane interworking between an L2VPN and an associated native Layer-2 service. The L2VPN WG scope includes the following: 1. Discovery of PEs participating in a Layer-2 VPN and the associated topology required for connectivity of the VPLS, VPWS, VPMS or E-VPN service. 2. Signaling of information related to the discovery and membership of PEs within a L2VPN. These procedures must use PWE3 control and management procedures, or define requirements for extensions of PWE3 protocols to suit the needs of an L2VPN, when the L2VPN operates over PWs. Once those requirements have been reviewed by the L2VPN WG, they should be provided to the PWE3 WG to derive solutions. 3. MIBs for Layer-2 VPN solutions. 4. Specification of requirements, framework and solutions that facilitate Operations Administration and Management (OAM) of any type of L2VPN. 5. Mechanisms to permit optimization of multicast data traffic within an L2VPN. 6. If transport does not involve PWs, mechanisms that support load-balancing/multipathing between PEs interconnecting a Layer-2 service using an L2VPN across the MPLS PSN. 7. requirements for the multi-homing of CEs to several VPLS or E-VPN PEs, inclusive of active/backup and active/active (load-sharing) configurations. Based on these requirements define VPLS or E-VPN control plane solutions for achieving fast convergence after failure of an active path in the PSN or on the AC side. 8. Enhancements to increase the scalability of the Control Plane and Data Plane of L2VPN PE nodes, and of core nodes that provide transport services for L2VPN. 9. Requirements and solutions for Auto-Discovery and Signaling of Inter-AS L2VPNs, in addition to Inter-AS solutions for multicast-optimized L2VPNs. 10. Requirements and solutions for supporting "E-Tree" services using VPLS.=20 11. Extensions to L2VPN protocols and RFCs necessary to create an MPLS Transport Profile (MPLS-TP). The work on the MPLS TP will be coordinated between four primary working groups (MPLS, PWE3, L2VPN and CCAMP) that are chartered to do MPLS TP work. Milestones: Done Submit an I-D describing MIB for VPLS Done Submit an I-D describing MIB for VPWS Done Submit an I-D on OAM requirements for VPLS Done Submit an I-D on OAM requirements for VPWS Done Submit L2 requirements to IESG for publication as Informational RFC Done Submit L2 framework to IESG for publication as Informational RF= C Done Identify VPLS and VPWS solutions for the WG Done Submit VPLS solution documents to IESG Done Submit VPWS solution documents to IESG Done Submit Auto-Discovery and Signaling for Intra-AS and Inter-AS VPLS and VPWS Layer-2 VPNs Jul 2011 Submit IP-only L2VPN solution documents to IESG Jul 2011 Submit OAM solutions for VPWS to IESG Jul 2011 Submit OAM solutions for VPLS to IESG Jul 2011 Submit signaling solution for multicast-optimized VPLS to IESG Jul 2011 Submit I-D on Virtual Private Multicast Service (VPMS) requirements to IESG Jul 2011 Submit MIB for VPLS to IESG Jul 2011 Submit MIB for VPWS to IESG Nov 2011 Submit scalability solutions for VPLS Data-Plane to IESG Nov 2011 Submit scalability solutions for VPLS Control-Plane to IESG Mar 2012 Submit MIB for IP-only L2VPN to IESG Mar 2012 Submit OAM solutions for IP-only L2VPN to IESG Mar 2012 Submit Auto-Discovery solution for VPMS to IESG Mar 2012 Submit VPLS service convergence improvement solutions to IESG Mar 2012 Submit VPLS multi-homing solutions to IESG Mar 2012 Submit E-Tree documents to IESG Mar 2012 Submit E-VPN requirements/framework to IESG Jul 2013 Submit E-VPN solution to IESG Nov 2013 Submit E-VPN MIB/OAM to IESG On 08/05/2011 16:34, "Bitar, Nabil N" wrote: > Hi, > As we are working to firming up the charter, I think it will be good to > address the questions raised in this thread. I am hearing question about = the > intention of that second sentence mentioned more than opposition to it. > We are still addressing provider-provisioned L2VPN. However, nothing rest= ricts > the environment that this gets used in. For instance, if there is value t= o > expand l2vpn such as VPLS into the data center, would that be excluded? I= am > not judging that there is value or not. If there are new requirements tha= t > drive additional solutions, should they be excluded? > In addition, Data center and data center interconnects in a cloud could > bring requirements to interconnect technologies that we had not looked at > before in the l2vpn WG. Certainly, a data center layer2 network can be b= ased > on Trill or 802.1aq as examples which we had not covered before in additi= on to > 802.1ad or PBB . If there are requirements to interconnect data center= s > using these technologies, l2vpn-solutions may be needed (and if needed dr= afts > will show up). These are examples and are not to restrict the types of > requirements. There are already drafts driven from data center and cloud > viewpoint that have been brought in by folks. Could we live without the > sentence in question? Probably yes. However, calling out explicitly that > solutions that address data center and cloud requirements as they apply t= o > l2vpn are within the l2vpn WG charter adds more clarity to what we could = be > taking on upfront. We all know based on industry activities, that is an a= rea > of interest, and there have been already drafts brought to the l2vpn WG d= riven > by that although some were not layer2-based. For that reason also, I thin= k > calling it out as in the draft charter points out that only L2 will be > addressed by the l2vpn WG, which may seem like calling out the obvious. >=20 > Thanks, > Nabil >=20 > On 3/31/11 12:18 PM, "Benson Schliesser" wrote: >=20 >> Speaking as ARMD co-chair: Solution development is not in our charter, = but >> analysis of existing solutions (and identification of gaps) is. If we >> identify gaps, then ARMD might be re-chartered to develop solutions =AD or= we >> might send our requirements into other WGs for development. This is TBD >> pending our work on the Problem Statement. >>=20 >> Speaking personally: I don=B9t have any objection to L2VPN working on data >> center solutions. If somebody deploys e.g. VPLS inside an enterprise >> network, provider data center, provider metro network, etc, I think thes= e are >> all valid use-cases. This is why I asked my question about the 2nd sent= ence >> =AD it seems redundant. >>=20 >> Cheers, >> -Benson >>=20 >>=20 >> On 3/31/11 10:21 AM, "Shah, Himanshu" wrote: >>=20 >>> My understanding is that, as a first step, the problem >>> scope needs to be understood. Solutions, if any required, >>> could follow only after the problem is well understood. >>> Solutions are part of ARMD charter but only after first step >>> is completed. >>>=20 >>> Although, it appears that L2VPN group has already acknowledged >>> and understood the problem well enough to propose solutions?? >>>=20 >>> /himanshu >>>=20 >>>=20 >>> -----Original Message----- >>> From: l2vpn-bounces@ietf.org on behalf of Thomas Nadeau >>> Sent: Thu 3/31/2011 10:57 AM >>> To: Giles Heron >>> Cc: l2vpn@ietf.org >>> Subject: Re: Draft of new L2VPN WG Charter >>>=20 >>>=20 >>> On Mar 31, 2011, at 10:49 AM, Giles Heron wrote: >>>=20 >>>> Hi Benson, >>>>=20 >>>> This would be provider-provisioned L2VPN environments (whether data-ce= ntre >>>> interconnect, or scaling of a large multi-tenant data-centre). >>>>=20 >>>> Personally I'm not sure we need the sentence there, but others were ke= en to >>>> mention the data-centre requirements. >>>=20 >>> I think that is meant to explicitly field requirements for solu= tions >>> that come from ARMD/etc... into the WG, since they cannot build their o= wn >>> solutions. While that isn't implicitly handled in the existing charter= , I >>> do not know either. >>>=20 >>> --Tom >>>=20 >>>=20 >>>>=20 >>>> Giles >>>>=20 >>>> On 31/03/2011 15:37, "Benson Schliesser" wrote: >>>>=20 >>>>> Hi, Giles. >>>>>=20 >>>>> I have a clarifying question about the first paragraph: What is the >>>>> purpose >>>>> of the 2nd sentence, bringing cloud and DC requirements into the mix? >>>>> Assuming this is meant to include non-provider L2VPN environments (li= ke >>>>> enterprise data centers), then why not just remove the phrase >>>>> "provider-provisioned" from the first sentence? Otherwise, it seems >>>>> redundant. >>>>>=20 >>>>> This is a real question, not a suggestion at this time. >>>>>=20 >>>>> Thanks, >>>>> -Benson >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 3/18/11 1:21 PM, "Giles Heron" wrote: >>>>>=20 >>>>>> OK - looks like the attachment didn't come through as intended. My >>>>>> apologies. >>>>>>=20 >>>>>> Text inline: >>>>>>=20 >>>>>> ---------------- >>>>>>=20 >>>>>> The L2VPN working group is responsible for defining and specifying a >>>>>> limited number of solutions for supporting provider-provisioned Laye= r-2 >>>>>> Virtual Private Networks (L2VPNs). It will also address requirements >>>>>> driven >>>>>> by cloud computing services and data centers as they apply to Layer-= 2 >>>>>> VPN services. >>>>>>=20 >>>>>> Layer-2 VPNs defined by L2VPN operate over pseudowires (PWs) as >>>>>> defined by the PWE3 WG or over MPLS PSN tunnels. A L2VPN emulates a >>>>>> "native" service over a PSN that is adequately faithful to, but may = not >>>>>> be entirely indistinguishable from the native service itself. Furthe= r, >>>>>> following in the "edge-to-edge" nature of the service, the L2VPN WG= will >>>>>> not define any mechanisms which exert control over the underlying PS= N. >>>>>> When necessary it may, however, recommend or require the use of exis= ting >>>>>> PSN QoS and path control mechanisms between the PEs which provide th= e >>>>>> L2VPN connectivity. >>>>>>=20 >>>>>> Layer-2 VPNs comprise the following: >>>>>>=20 >>>>>> 1. Virtual Private LAN Service (VPLS) -- A Layer-2 service that emul= ates >>>>>> a switched Ethernet (V)LAN across an MPLS Packet Switched Network (P= SN). >>>>>>=20 >>>>>> 2. Virtual Private Wire Service (VPWS) -- A Layer-2 service that >>>>>> provides point-to-point connectivity for a variety of link layers, >>>>>> including Frame Relay, ATM, Ethernet, PPP, etc., across an MPLS PSN. >>>>>>=20 >>>>>> 3. Virtual Private Multicast Service (VPMS) -- A Layer-2 service tha= t >>>>>> provides point-to-multipoint connectivity for a variety of link >>>>>> layers across an MPLS PSN. >>>>>>=20 >>>>>> 4. IP-only L2VPN - An IP-only service over an MPLS PSN. The WG will >>>>>> address two specific types of IP-only L2VPN: >>>>>>=20 >>>>>> a) Point-to-point Layer-2 VPN. This service is similar to VPWS, but= also >>>>>> supports heterogenous Attachment Circuits at either end of a single >>>>>> point-to-point service. >>>>>>=20 >>>>>> b) Multipoint-to-multipoint Layer-2 VPN. This service is similar to >>>>>> VPLS, >>>>>> but learns IP and MAC address bindings from ARPs and broadcast/multi= cast >>>>>> IP packets. >>>>>>=20 >>>>>> 5. Ethernet VPN (E-VPN) - A Layer-2 technology that emulates an >>>>>> Ethernet (V)LAN across an MPLS PSN. E-VPN supports load-sharing acro= ss >>>>>> multiple connections from a Layer-2 site to an L2VPN service, and al= so >>>>>> supports control plane distribution of MAC addresses and IP to MAC >>>>>> address >>>>>> bindings in the VPN. E-VPN is primarily targeted to support large-sc= ale >>>>>> L2VPNs with resiliency requirements not satisfied by other L2VPN >>>>>> solutions. >>>>>>=20 >>>>>> 6. E-Tree - a Layer-2 technology defined by the MEF, which provides >>>>>> connectivity between one or more "root" nodes and one or more >>>>>> "leaf" nodes, with the restriction that leaves may only communicate >>>>>> with roots (and not with each other). >>>>>>=20 >>>>>> L2VPNs will make use of existing IETF specified mechanisms unless th= ere >>>>>> are technical reasons why the existing mechanisms are insufficient o= r >>>>>> unnecessary. >>>>>>=20 >>>>>> The L2VPN WG is responsible for specification of the discovery and >>>>>> membership of PEs participating in a Layer-2 VPN as well as the >>>>>> membership of CE devices for a specific instance of an L2VPN. >>>>>>=20 >>>>>> The L2VPN WG will provide extensions of existing protocols that will= be >>>>>> discussed in protocol-specific WGs. In particular, the L2VPN WG >>>>>> may define extensions to pseudowire management mechanisms for VPLS. >>>>>> Those extensions will be reviewed by the PWE3 WG to ensure they are >>>>>> aligned with the overall design/architecture of PWE3. >>>>>>=20 >>>>>> The L2VPN WG will not define new encapsulations, control, or resilie= ncy >>>>>> mechanisms specifically related to pseudowires. Furthermore, when th= e >>>>>> L2VPN solution is based on PWs, the L2VPN WG will not define protoco= l >>>>>> inter-working between an L2VPN and native service Layer-2 OAM or >>>>>> resiliency mechanisms. The L2VPN WG may define how to operate native >>>>>> service-layer control, OAM or resiliency mechanisms on top of an L2V= PN. >>>>>> In addition, it may define native data plane and/or control plane >>>>>> interworking between an L2VPN and an associated native Layer-2 servi= ce. >>>>>>=20 >>>>>> The L2VPN WG scope includes the following: >>>>>>=20 >>>>>> 1. Discovery of PEs participating in a Layer-2 VPN and the associate= d >>>>>> topology required for connectivity of the VPLS, VPWS, VPMS or E-VPN >>>>>> service. >>>>>>=20 >>>>>> 2. Signaling of information related to the discovery and membership = of >>>>>> PEs within a L2VPN. These procedures must use PWE3 control and >>>>>> management procedures, or define requirements for extensions of PWE3 >>>>>> protocols to suit the needs of an L2VPN, when the L2VPN operates ove= r >>>>>> PWs. Once those requirements have been reviewed by the L2VPN WG, the= y >>>>>> should be provided to the PWE3 WG to derive solutions. >>>>>>=20 >>>>>> 3. MIBs for Layer-2 VPN solutions. >>>>>>=20 >>>>>> 4. Specification of requirements, framework and solutions that >>>>>> facilitate Operations Administration and Management (OAM) of any typ= e of >>>>>> L2VPN. >>>>>>=20 >>>>>> 5. Mechanisms to permit optimization of multicast data traffic withi= n >>>>>> an L2VPN. >>>>>>=20 >>>>>> 6. If transport does not involve PWs, mechanisms that support >>>>>> load-balancing/multipathing between PEs interconnecting a Layer-2 >>>>>> service using an L2VPN across the MPLS PSN. >>>>>>=20 >>>>>> 7. requirements for the multi-homing of CEs to several VPLS or >>>>>> E-VPN PEs, inclusive of active/backup and active/active (load-sharin= g) >>>>>> configurations. Based on these requirements define VPLS or E-VPN con= trol >>>>>> plane solutions for achieving fast convergence after failure of an a= ctive >>>>>> path in the PSN or on the AC side. >>>>>>=20 >>>>>> 8. Enhancements to increase the scalability of the Control Plane and >>>>>> Data Plane of L2VPN PE nodes, and of core nodes that provide transpo= rt >>>>>> services for L2VPN. >>>>>>=20 >>>>>> 9. Requirements and solutions for Auto-Discovery and Signaling of >>>>>> Inter-AS L2VPNs, in addition to Inter-AS solutions for >>>>>> multicast-optimized >>>>>> L2VPNs. >>>>>>=20 >>>>>> 10. Requirements and solutions for supporting "E-Tree" services usin= g >>>>>> VPLS. >>>>>>=20 >>>>>> 11. Extensions to L2VPN protocols and RFCs necessary to create an MP= LS >>>>>> Transport Profile (MPLS-TP). The work on the MPLS TP will be coordin= ated >>>>>> between four primary working groups (MPLS, PWE3, L2VPN and CCAMP) th= at >>>>>> are >>>>>> chartered to do MPLS TP work. >>>>>>=20 >>>>>> Milestones: >>>>>>=20 >>>>>> Done Submit an I-D describing MIB for VPLS >>>>>> Done Submit an I-D describing MIB for VPWS >>>>>> Done Submit an I-D on OAM requirements for VPLS >>>>>> Done Submit an I-D on OAM requirements for VPWS >>>>>> Done Submit L2 requirements to IESG for publication as >>>>>> Informational >>>>>> RFC >>>>>> Done Submit L2 framework to IESG for publication as Informati= onal >>>>>> RFC >>>>>> Done Identify VPLS and VPWS solutions for the WG >>>>>> Done Submit VPLS solution documents to IESG >>>>>> Done Submit VPWS solution documents to IESG >>>>>> Done Submit Auto-Discovery and Signaling for Intra-AS and Int= er-AS >>>>>> VPLS and VPWS Layer-2 VPNs >>>>>> Jul 2011 Submit IP-only L2VPN solution documents to IESG >>>>>> Jul 2011 Submit OAM solutions for VPWS to IESG >>>>>> Jul 2011 Submit OAM solutions for VPLS to IESG >>>>>> Jul 2011 Submit signaling solution for multicast-optimized VPLS t= o >>>>>> IESG >>>>>> Jul 2011 Submit I-D on Virtual Private Multicast Service (VPMS) >>>>>> requirements to IESG >>>>>> Jul 2011 Submit MIB for VPLS to IESG >>>>>> Jul 2011 Submit MIB for VPWS to IESG >>>>>> Nov 2011 Submit scalability solutions for VPLS Data-Plane to IESG >>>>>> Nov 2011 Submit scalability solutions for VPLS Control-Plane to I= ESG >>>>>> Mar 2012 Submit MIB for IP-only L2VPN to IESG >>>>>> Mar 2012 Submit OAM solutions for IP-only L2VPN to IESG >>>>>> Mar 2012 Submit Auto-Discovery solution for VPMS to IESG >>>>>> Mar 2012 Submit VPLS service convergence improvement solutions to= IESG >>>>>> Mar 2012 Submit VPLS multi-homing solutions to IESG >>>>>> Mar 2012 Submit E-Tree documents to IESG >>>>>> Mar 2012 Submit E-VPN requirements/framework to IESG >>>>>> Jul 2012 Submit E-VPN solution to IESG >>>>>> Nov 2012 Submit E-VPN MIB/OAM to IESG >>>>>>=20 >>>>>> ----------------- >>>>>>=20 >>>>>> On 18/03/2011 17:41, "Giles Heron" wrote: >>>>>>=20 >>>>>>> We plan to re-charter the L2VPN WG - primarily to bring E-VPN and E= -Tree >>>>>>> in-scope. >>>>>>>=20 >>>>>>> Please find attached a draft charter for discussion both on this li= st >>>>>>> and at >>>>>>> IETF 80 in Prague. >>>>>>>=20 >>>>>>> Nabil and Giles >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>=20 >=20 > --------------------------------------------- > Nabil Bitar, PhD > Principal Member of Technical Staff > Packet Network Technology > Verizon Corporate Network and Technology >=20 > 60 Sylvan Road > Waltham, MA 02451 > Office Phone: (781) 466-2161 >=20 From internet-drafts@ietf.org Thu Jun 16 20:58:37 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1B0911E8168; Thu, 16 Jun 2011 20:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9J8r9fwJPwrB; Thu, 16 Jun 2011 20:58:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6CDE11E810C; Thu, 16 Jun 2011 20:58:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-l2vpn-vpls-macflush-ld-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110617035835.1997.62409.idtracker@ietfa.amsl.com> Date: Thu, 16 Jun 2011 20:58:35 -0700 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 03:58:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Layer 2 Virtual Private Networks Work= ing Group of the IETF. Title : MAC Flush Loop Detection in VPLS Author(s) : Paul Kwok Pranjal Kumar Dutta Filename : draft-ietf-l2vpn-vpls-macflush-ld-01.txt Pages : 9 Date : 2011-06-16 MAC Address Withdrawal is a mechanism described in [RFC4762] to remove or unlearn MAC addresses that have been dynamically learned, for faster convergence. Failure of mechanisms that control loop free connectivity (e.g Split Horizon) among VPLS PE nodes may cause MAC Address Withdrawal messages looping among those nodes, leading to Denial of Service (DoS) or complete failure of control plane in the PE nodes. This document describes a mechanism to detect and prevent loops of MAC Address Withdrawal messages in a VPLS PE node on such failures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-macflush-ld-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-macflush-ld-01.txt From internet-drafts@ietf.org Fri Jun 17 07:23:58 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 383A511E8112; Fri, 17 Jun 2011 07:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-RH6p+LAU4R; Fri, 17 Jun 2011 07:23:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8FAD11E809C; Fri, 17 Jun 2011 07:23:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-l2vpn-arp-mediation-17.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110617142357.4836.27907.idtracker@ietfa.amsl.com> Date: Fri, 17 Jun 2011 07:23:57 -0700 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 14:23:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Layer 2 Virtual Private Networks Work= ing Group of the IETF. Title : ARP Mediation for IP Interworking of Layer 2 VPN Author(s) : Himanshu Shah Eric Rosen Giles Heron Vach Kompella Filename : draft-ietf-l2vpn-arp-mediation-17.txt Pages : 33 Date : 2011-06-15 The Virtual Private Wire Service (VPWS) [RFC4664] provides point-to-point connections between pairs of Customer Edge (CE) devices. It does so by binding two Attachment Circuits (each connecting a CE device with a Provider Edge, PE, device) to a pseudowire (connecting the two PEs). In general, the Attachment Circuits must be of the same technology (e.g., both Ethernet, both ATM), and the pseudowire must carry the frames of that technology. However, if it is known that the frames' payload consists solely of IP datagrams, it is possible to provide a point-to-point connection in which the pseudowire connects Attachment Circuits of different technologies. This requires the PEs to perform a function known as "ARP Mediation". ARP Mediation refers to the process of resolving Layer 2 addresses when different resolution protocols are used on either Attachment Circuit. The methods described in this document are applicable even when the CEs run a routing protocol between them, as long as the routing protocol runs over IP. = A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-arp-mediation-17.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-l2vpn-arp-mediation-17.txt From martin.pels@ams-ix.net Sat Jun 18 06:34:35 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B81F221F8646 for ; Sat, 18 Jun 2011 06:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2i6DOdr3RIK for ; Sat, 18 Jun 2011 06:34:35 -0700 (PDT) Received: from deliverix.ams-ix.net (deliverix.ams-ix.net [IPv6:2001:67c:1a8:101::248]) by ietfa.amsl.com (Postfix) with ESMTP id F064221F8645 for ; Sat, 18 Jun 2011 06:34:34 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at ams-ix.net Received: from fizzix (nemix0.ipv6.ams-ix.net [IPv6:2001:67c:1a8:120::4]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by deliverix.ams-ix.net (Postfix) with ESMTPSA id 3200715E4C; Sat, 18 Jun 2011 15:34:30 +0200 (CEST) Date: Sat, 18 Jun 2011 15:34:29 +0200 From: Martin Pels To: Xu Xiaohu Subject: Re: New Version Notification for draft-xu-virtual-subnet-04 Message-ID: <20110618153429.7df88f02@fizzix> In-Reply-To: <004601cbbb95$b2fd3150$91626e0a@china.huawei.com> References: <004601cbbb95$b2fd3150$91626e0a@china.huawei.com> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.22.0; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2011 13:34:35 -0000 Hi Xiaohu, On Mon, 24 Jan 2011 15:09:53 +0800 Xu Xiaohu wrote: > Hi all, > > An updated version of Virtual Subnet > (http://tools.ietf.org/html/draft-xu-virtual-subnet-04) has been > submitted. > > One major change is to describe the inter-subnet communication > mechanism in more details, especially in the case where VRRP is > deployed in the CE network. For more details, please see > http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-xu-virtual-subnet > -04.txt > > Any comments are welcome. I have a couple of questions and comments. Section 3.4: * Can you elaborate on how active-active multi-homing would work in the PE-CE broadcast domain? Obviously, the VRRP Master and Slave cannot advertise the virtual Router MAC address concurrently, since this would cause rapid station movement of said MAC address. So in this scenario the active-active multi-homing would be unidirectional only, with the Slave PE sourcing the traffic destined for the CE from its local MAC address rather than the Virtual Router MAC address. Correct? * In case of a VRRP transition remote PEs will continue to send traffic to the old VRRP Master until the new Master creates CE host routes for all local CEs, and the old Master withdraws them. In order to facilitate a quick transition there should be a mechanism to do this without having to wait for each CE to send an ARP request. Section 3.5: * If a CE moves to a different VPN site it may still have an ARP cache filled with IP addresses mapped to the MAC address of the PE of the original VPN site. Would this not cause a lot of flooding, due to the CE sourcing frames with the MAC address of its old PE as their destination? Section 5: * Considering the impending IPv4 depletion, it would be wise to make IPv6 CE support an intrinsic part of this solution, rather than deferring it to a future document. Kind regards, Martin Pels From xuxh@huawei.com Sun Jun 19 21:13:34 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA3D911E80E5 for ; Sun, 19 Jun 2011 21:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.81 X-Spam-Level: X-Spam-Status: No, score=-3.81 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXRQCWJmA68Z for ; Sun, 19 Jun 2011 21:13:34 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 98AE911E809F for ; Sun, 19 Jun 2011 21:13:33 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LN2008I8MEFRY@szxga04-in.huawei.com> for l2vpn@ietf.org; Mon, 20 Jun 2011 12:13:27 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LN200KS1MEFQF@szxga04-in.huawei.com> for l2vpn@ietf.org; Mon, 20 Jun 2011 12:13:27 +0800 (CST) Received: from x41208c ([10.110.98.57]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LN20096JMEE0X@szxml04-in.huawei.com> for l2vpn@ietf.org; Mon, 20 Jun 2011 12:13:27 +0800 (CST) Date: Mon, 20 Jun 2011 12:23:44 +0800 From: Xu Xiaohu Subject: re: New Version Notification for draft-xu-virtual-subnet-04 In-reply-to: <20110618153429.7df88f02@fizzix> To: 'Martin Pels' Message-id: <008601cc2f01$d8af6d70$8a0e4850$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=gb2312 Content-language: zh-cn Content-transfer-encoding: quoted-printable Thread-index: AcwtvJL8rERSazXxRdqvdeOMborGPgBQcwgg References: <004601cbbb95$b2fd3150$91626e0a@china.huawei.com> <20110618153429.7df88f02@fizzix> Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 04:13:35 -0000 Hi Martin, Thanks a lot for your valuable comments. Please see my reply inline. > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: Martin Pels [mailto:martin.pels@ams-ix.net] > =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA6=D4=C218=C8=D5 21:34 > =CA=D5=BC=FE=C8=CB: Xu Xiaohu > =B3=AD=CB=CD: l2vpn@ietf.org > =D6=F7=CC=E2: Re: New Version Notification for = draft-xu-virtual-subnet-04 >=20 > Hi Xiaohu, >=20 > On Mon, 24 Jan 2011 15:09:53 +0800 > Xu Xiaohu wrote: >=20 > > Hi all, > > > > An updated version of Virtual Subnet > > (http://tools.ietf.org/html/draft-xu-virtual-subnet-04) has been > > submitted. > > > > One major change is to describe the inter-subnet communication > > mechanism in more details, especially in the case where VRRP is > > deployed in the CE network. For more details, please see > > http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-xu-virtual= -subnet > > -04.txt > > > > Any comments are welcome. >=20 > I have a couple of questions and comments. >=20 > Section 3.4: >=20 > * Can you elaborate on how active-active multi-homing would work in = the > PE-CE broadcast domain? >=20 > Obviously, the VRRP Master and Slave cannot advertise the virtual > Router MAC address concurrently, since this would cause rapid = station > movement of said MAC address. So in this scenario the active-active > multi-homing would be unidirectional only, with the Slave PE = sourcing > the traffic destined for the CE from its local MAC address rather > than the Virtual Router MAC address. Correct? The active-active multi-homing is available for the incoming traffic of = a multi-homed site. For more details, please see page 10 of my latest .PPT = as follows: http://www.nanog.org/meetings/nanog52/presentations/Wednesday/XU-Virtual%= 20S ubnet(for%20NANOG52)v1.0.pdf > * In case of a VRRP transition remote PEs will continue to send = traffic > to the old VRRP Master until the new Master creates CE host routes > for all local CEs, and the old Master withdraws them. In order to > facilitate a quick transition there should be a mechanism to do this > without having to wait for each CE to send an ARP request. Actually the VRRP master and the VRRP slaver could advertise CE host = routes simultaneously. > Section 3.5: >=20 > * If a CE moves to a different VPN site it may still have an ARP cache > filled with IP addresses mapped to the MAC address of the PE of the > original VPN site. Would this not cause a lot of flooding, due to = the > CE sourcing frames with the MAC address of its old PE as their > destination? Yes, your observation is correct. There does need more detailed consideration and description on this point. How about running VRRP on = the PE routers at any time? In this way, both the old PE router and the new = PE router could return the same Virtual MAC in their own ARP responses.=20 > Section 5: >=20 > * Considering the impending IPv4 depletion, it would be wise to make > IPv6 CE support an intrinsic part of this solution, rather than > deferring it to a future document. Good suggestion. After we have reached a rough consensus on the = IPv4-based solution, I will put more effort into the IPv6-based solution. Thanks again for your insightful comments. Best regards, Xiaohu > Kind regards, > Martin Pels From internet-drafts@ietf.org Thu Jun 23 21:48:49 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0B711E819D; Thu, 23 Jun 2011 21:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxWyxgNBwRAF; Thu, 23 Jun 2011 21:48:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDE9D11E80AB; Thu, 23 Jun 2011 21:48:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-l2vpn-vpls-ldp-mac-opt-04.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110624044848.15692.90318.idtracker@ietfa.amsl.com> Date: Thu, 23 Jun 2011 21:48:48 -0700 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 04:48:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Layer 2 Virtual Private Networks Work= ing Group of the IETF. Title : LDP Extensions for Optimized MAC Address Withdrawal in H= -VPLS Author(s) : Pranjal Kumar Dutta Florin Balus Olen Stokes Geraldine Calvignac Filename : draft-ietf-l2vpn-vpls-ldp-mac-opt-04.txt Pages : 18 Date : 2011-06-23 [RFC4762] describes a mechanism to remove or unlearn MAC addresses that have been dynamically learned in a VPLS Instance for faster convergence on topology change. The procedure also removes MAC addresses in the VPLS that do not require relearning due to such topology change. This document defines an enhancement to the MAC Address Withdrawal procedure with empty MAC List [RFC4762], which enables a Provider Edge(PE) device to remove only the MAC addresses that need to be relearned. Additional extensions to [RFC4762] MAC Withdrawal procedures are specified to provide optimized MAC flushing for the PBB-VPLS specified in [PBB-VPLS Model]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-ldp-mac-opt-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-ldp-mac-opt-04.txt From prvs=9156060f75=hshah@ciena.com Fri Jun 24 14:30:15 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CFB811E8175 for ; Fri, 24 Jun 2011 14:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.826 X-Spam-Level: X-Spam-Status: No, score=-0.826 tagged_above=-999 required=5 tests=[AWL=-0.121, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_MLB_Stock6=1.56] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-vt6KZPqXAl for ; Fri, 24 Jun 2011 14:30:13 -0700 (PDT) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) by ietfa.amsl.com (Postfix) with ESMTP id 6945F11E80D6 for ; Fri, 24 Jun 2011 14:30:13 -0700 (PDT) Received: from pps.filterd (m0001124 [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.14.3/8.14.3) with SMTP id p5OLU7Q3018022; Fri, 24 Jun 2011 17:30:08 -0400 Received: from mdwexght01.ciena.com (LIN1-118-36-28.ciena.com [63.118.36.28]) by mx0b-00103a01.pphosted.com with ESMTP id x51wr03j7-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 24 Jun 2011 17:30:07 -0400 Received: from MDWEXGMB02.ciena.com ([::1]) by MDWEXGHT01.ciena.com ([::1]) with mapi; Fri, 24 Jun 2011 17:30:02 -0400 From: "Shah, Himanshu" To: Giles Heron , "Bitar, Nabil N" , Benson Schliesser , Thomas Nadeau Content-Class: urn:content-classes:message Date: Fri, 24 Jun 2011 17:30:00 -0400 Subject: RE: Draft of new L2VPN WG Charter Thread-Topic: Draft of new L2VPN WG Charter Thread-Index: AcvvtA2JzqTxhFkJSFamDqHmBDPKfwAAiwePAAI/U3QHTQhEmQdK2Z4pAiWKgsA= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-10.0.0.1412-6.500.1024-18220.002 x-tm-as-result: No--34.135600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.148, 0.0.0000 definitions=2011-06-24_07:2011-06-24, 2011-06-24, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1106240186 Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 21:30:15 -0000 Giles/Nabil - Nabil's email (at the bottom of this email) did not address one of points I had raised. This relates to specific sentence in charter (5) text " and also supports control plane distribution of MAC addresses and IP to M= AC address bindings in the VPN." As I had indicated before on the mailing list, control plane distribution o= f MAC to IP binding is not NEW and was already introduced 7 to 8 years ago by proposed solutions related to charter (4). By explicitly mentioning this item in the charter (5) gives impression that a new concept is being developed or introduced, which is not the case. This needs to be corrected. Thanks, himanshu -----Original Message----- From: Giles Heron [mailto:giles.heron@gmail.com] Sent: Monday, June 13, 2011 7:08 PM To: Bitar, Nabil N; Benson Schliesser; Shah, Himanshu; Thomas Nadeau Cc: l2vpn@ietf.org Subject: Re: Draft of new L2VPN WG Charter So in the absence of any follow-up to Nabil=B9s email we=B9d like to propos= e that we adopt the charter as below. The only modifications from the charter Giles posted at the start of this thread are: 1) fixed the 2011 date on VPMS Auto-Discovery to 2012 (as spotted by Ben) 2) changed E-Tree from =B3technology=B2 to =B3service=B2 (as suggested by Y= uanlong) 3) we=B9ve pushed the E-VPN solution and OAM/MIB milestones back a year, in response to Joel=B9s comment about deferring these. The main area of debate seems to have been the second sentence: =B3It will also address requirements driven by cloud computing services and data centers as they apply to Layer-2 VPN services.=B2 Unless there=B9s any strong objection to this sentence that garners some degree of consensus we propose to leave it in. We=B9d like to wrap this up in the next couple of weeks, so let=B9s bring a= ny debate to a close by Friday 24th June and then move forward. Those with sharp eyes will notice that the first of our new deadlines are fast approaching! Giles & Nabil The L2VPN working group is responsible for defining and specifying a limited number of solutions for supporting provider-provisioned Layer-2 Virtual Private Networks (L2VPNs). It will also address requirements driven by cloud computing services and data centers as they apply to Layer-2 VPN services. Layer-2 VPNs defined by L2VPN operate over pseudowires (PWs) as defined by the PWE3 WG or over MPLS PSN tunnels. A L2VPN emulates a "native" service over a PSN that is adequately faithful to, but may not be entirely indistinguishable from the native service itself. Further, following in the "edge-to-edge" nature of the service, the L2VPN WG will not define any mechanisms which exert control over the underlying PSN. When necessary it may, however, recommend or require the use of existing PSN QoS and path control mechanisms between the PEs which provide the L2VPN connectivity. Layer-2 VPNs comprise the following: 1. Virtual Private LAN Service (VPLS) -- A Layer-2 service that emulates a switched Ethernet (V)LAN across an MPLS PSN. 2. Virtual Private Wire Service (VPWS) -- A Layer-2 service that provides point-to-point connectivity for a variety of link layers, including Frame Relay, ATM, Ethernet, PPP, etc., across an MPLS PSN. 3. Virtual Private Multicast Service (VPMS) -- A Layer-2 service that provides point-to-multipoint connectivity for a variety of link layers across an MPLS PSN. 4. IP-only L2VPN =AD An IP-only service over an MPLS PSN. The WG will address two specific types of IP-only L2VPN: a) Point-to-point Layer-2 VPN. This service is similar to VPWS, but also supports heterogenous Attachment Circuits at either end of a single point-to-point service. b) Multipoint-to-multipoint Layer-2 VPN. This service is similar to VPLS, but learns IP and MAC address bindings from ARPs and broadcast/multicast IP packets. 5. Ethernet VPN (E-VPN) - A Layer-2 service that emulates an Ethernet (V)LAN across an MPLS PSN. E-VPN supports load-sharing across multiple connections from a Layer-2 site to an L2VPN service, and also supports control plane distribution of MAC addresses and IP to MAC address bindings in the VPN. E-VPN is primarily targeted to support large-scale L2VPNs with resiliency requirements not satisfied by other L2VPN solutions. 6. E-Tree =AD a Layer-2 service defined by the MEF, which provides connectivity between one or more =B3root=B2 nodes and one or more =B3leaf=B2 nodes, with the restriction that leaves may only communicate with roots (and not with each other). L2VPNs will make use of existing IETF specified mechanisms unless there are technical reasons why the existing mechanisms are insufficient or unnecessary. The L2VPN WG is responsible for specification of the discovery and membership of PEs participating in a Layer-2 VPN as well as the membership of CE devices for a specific instance of an L2VPN. The L2VPN WG will provide extensions of existing protocols that will be discussed in protocol-specific WGs. In particular, the L2VPN WG may define extensions to pseudowire management mechanisms for VPLS. Those extensions will be reviewed by the PWE3 WG to ensure they are aligned with the overall design/architecture of PWE3. The L2VPN WG will not define new encapsulations, control, or resiliency mechanisms specifically related to pseudowires. Furthermore, when the L2VPN solution is based on PWs, the L2VPN WG will not define protocol inter-working between an L2VPN and native service Layer-2 OAM or resiliency mechanisms. The L2VPN WG may define how to operate native service-layer control, OAM or resiliency mechanisms on top of an L2VPN. In addition, it may define native data plane and/or control plane interworking between an L2VPN and an associated native Layer-2 service. The L2VPN WG scope includes the following: 1. Discovery of PEs participating in a Layer-2 VPN and the associated topology required for connectivity of the VPLS, VPWS, VPMS or E-VPN service. 2. Signaling of information related to the discovery and membership of PEs within a L2VPN. These procedures must use PWE3 control and management procedures, or define requirements for extensions of PWE3 protocols to suit the needs of an L2VPN, when the L2VPN operates over PWs. Once those requirements have been reviewed by the L2VPN WG, they should be provided to the PWE3 WG to derive solutions. 3. MIBs for Layer-2 VPN solutions. 4. Specification of requirements, framework and solutions that facilitate Operations Administration and Management (OAM) of any type of L2VPN. 5. Mechanisms to permit optimization of multicast data traffic within an L2VPN. 6. If transport does not involve PWs, mechanisms that support load-balancing/multipathing between PEs interconnecting a Layer-2 service using an L2VPN across the MPLS PSN. 7. requirements for the multi-homing of CEs to several VPLS or E-VPN PEs, inclusive of active/backup and active/active (load-sharing) configurations. Based on these requirements define VPLS or E-VPN control plane solutions for achieving fast convergence after failure of an active path in the PSN or on the AC side. 8. Enhancements to increase the scalability of the Control Plane and Data Plane of L2VPN PE nodes, and of core nodes that provide transport services for L2VPN. 9. Requirements and solutions for Auto-Discovery and Signaling of Inter-AS L2VPNs, in addition to Inter-AS solutions for multicast-optimized L2VPNs. 10. Requirements and solutions for supporting "E-Tree" services using VPLS. 11. Extensions to L2VPN protocols and RFCs necessary to create an MPLS Transport Profile (MPLS-TP). The work on the MPLS TP will be coordinated between four primary working groups (MPLS, PWE3, L2VPN and CCAMP) that are chartered to do MPLS TP work. Milestones: Done Submit an I-D describing MIB for VPLS Done Submit an I-D describing MIB for VPWS Done Submit an I-D on OAM requirements for VPLS Done Submit an I-D on OAM requirements for VPWS Done Submit L2 requirements to IESG for publication as Informational RFC Done Submit L2 framework to IESG for publication as Informational RF= C Done Identify VPLS and VPWS solutions for the WG Done Submit VPLS solution documents to IESG Done Submit VPWS solution documents to IESG Done Submit Auto-Discovery and Signaling for Intra-AS and Inter-AS VPLS and VPWS Layer-2 VPNs Jul 2011 Submit IP-only L2VPN solution documents to IESG Jul 2011 Submit OAM solutions for VPWS to IESG Jul 2011 Submit OAM solutions for VPLS to IESG Jul 2011 Submit signaling solution for multicast-optimized VPLS to IESG Jul 2011 Submit I-D on Virtual Private Multicast Service (VPMS) requirements to IESG Jul 2011 Submit MIB for VPLS to IESG Jul 2011 Submit MIB for VPWS to IESG Nov 2011 Submit scalability solutions for VPLS Data-Plane to IESG Nov 2011 Submit scalability solutions for VPLS Control-Plane to IESG Mar 2012 Submit MIB for IP-only L2VPN to IESG Mar 2012 Submit OAM solutions for IP-only L2VPN to IESG Mar 2012 Submit Auto-Discovery solution for VPMS to IESG Mar 2012 Submit VPLS service convergence improvement solutions to IESG Mar 2012 Submit VPLS multi-homing solutions to IESG Mar 2012 Submit E-Tree documents to IESG Mar 2012 Submit E-VPN requirements/framework to IESG Jul 2013 Submit E-VPN solution to IESG Nov 2013 Submit E-VPN MIB/OAM to IESG On 08/05/2011 16:34, "Bitar, Nabil N" wrote: > Hi, > As we are working to firming up the charter, I think it will be good to > address the questions raised in this thread. I am hearing question about = the > intention of that second sentence mentioned more than opposition to it. > We are still addressing provider-provisioned L2VPN. However, nothing rest= ricts > the environment that this gets used in. For instance, if there is value t= o > expand l2vpn such as VPLS into the data center, would that be excluded? I= am > not judging that there is value or not. If there are new requirements tha= t > drive additional solutions, should they be excluded? > In addition, Data center and data center interconnects in a cloud could > bring requirements to interconnect technologies that we had not looked at > before in the l2vpn WG. Certainly, a data center layer2 network can be b= ased > on Trill or 802.1aq as examples which we had not covered before in additi= on to > 802.1ad or PBB . If there are requirements to interconnect data center= s > using these technologies, l2vpn-solutions may be needed (and if needed dr= afts > will show up). These are examples and are not to restrict the types of > requirements. There are already drafts driven from data center and cloud > viewpoint that have been brought in by folks. Could we live without the > sentence in question? Probably yes. However, calling out explicitly that > solutions that address data center and cloud requirements as they apply t= o > l2vpn are within the l2vpn WG charter adds more clarity to what we could = be > taking on upfront. We all know based on industry activities, that is an a= rea > of interest, and there have been already drafts brought to the l2vpn WG d= riven > by that although some were not layer2-based. For that reason also, I thin= k > calling it out as in the draft charter points out that only L2 will be > addressed by the l2vpn WG, which may seem like calling out the obvious. > > Thanks, > Nabil > > On 3/31/11 12:18 PM, "Benson Schliesser" wrote: > >> Speaking as ARMD co-chair: Solution development is not in our charter, = but >> analysis of existing solutions (and identification of gaps) is. If we >> identify gaps, then ARMD might be re-chartered to develop solutions =AD = or we >> might send our requirements into other WGs for development. This is TBD >> pending our work on the Problem Statement. >> >> Speaking personally: I don=B9t have any objection to L2VPN working on da= ta >> center solutions. If somebody deploys e.g. VPLS inside an enterprise >> network, provider data center, provider metro network, etc, I think thes= e are >> all valid use-cases. This is why I asked my question about the 2nd sent= ence >> =AD it seems redundant. >> >> Cheers, >> -Benson >> >> >> On 3/31/11 10:21 AM, "Shah, Himanshu" wrote: >> >>> My understanding is that, as a first step, the problem >>> scope needs to be understood. Solutions, if any required, >>> could follow only after the problem is well understood. >>> Solutions are part of ARMD charter but only after first step >>> is completed. >>> >>> Although, it appears that L2VPN group has already acknowledged >>> and understood the problem well enough to propose solutions?? >>> >>> /himanshu >>> >>> >>> -----Original Message----- >>> From: l2vpn-bounces@ietf.org on behalf of Thomas Nadeau >>> Sent: Thu 3/31/2011 10:57 AM >>> To: Giles Heron >>> Cc: l2vpn@ietf.org >>> Subject: Re: Draft of new L2VPN WG Charter >>> >>> >>> On Mar 31, 2011, at 10:49 AM, Giles Heron wrote: >>> >>>> Hi Benson, >>>> >>>> This would be provider-provisioned L2VPN environments (whether data-ce= ntre >>>> interconnect, or scaling of a large multi-tenant data-centre). >>>> >>>> Personally I'm not sure we need the sentence there, but others were ke= en to >>>> mention the data-centre requirements. >>> >>> I think that is meant to explicitly field requirements for solu= tions >>> that come from ARMD/etc... into the WG, since they cannot build their o= wn >>> solutions. While that isn't implicitly handled in the existing charter= , I >>> do not know either. >>> >>> --Tom >>> >>> >>>> >>>> Giles >>>> >>>> On 31/03/2011 15:37, "Benson Schliesser" wrote: >>>> >>>>> Hi, Giles. >>>>> >>>>> I have a clarifying question about the first paragraph: What is the >>>>> purpose >>>>> of the 2nd sentence, bringing cloud and DC requirements into the mix? >>>>> Assuming this is meant to include non-provider L2VPN environments (li= ke >>>>> enterprise data centers), then why not just remove the phrase >>>>> "provider-provisioned" from the first sentence? Otherwise, it seems >>>>> redundant. >>>>> >>>>> This is a real question, not a suggestion at this time. >>>>> >>>>> Thanks, >>>>> -Benson >>>>> >>>>> >>>>> >>>>> On 3/18/11 1:21 PM, "Giles Heron" wrote: >>>>> >>>>>> OK - looks like the attachment didn't come through as intended. My >>>>>> apologies. >>>>>> >>>>>> Text inline: >>>>>> >>>>>> ---------------- >>>>>> >>>>>> The L2VPN working group is responsible for defining and specifying a >>>>>> limited number of solutions for supporting provider-provisioned Laye= r-2 >>>>>> Virtual Private Networks (L2VPNs). It will also address requirements >>>>>> driven >>>>>> by cloud computing services and data centers as they apply to Layer-= 2 >>>>>> VPN services. >>>>>> >>>>>> Layer-2 VPNs defined by L2VPN operate over pseudowires (PWs) as >>>>>> defined by the PWE3 WG or over MPLS PSN tunnels. A L2VPN emulates a >>>>>> "native" service over a PSN that is adequately faithful to, but may = not >>>>>> be entirely indistinguishable from the native service itself. Furthe= r, >>>>>> following in the "edge-to-edge" nature of the service, the L2VPN WG= will >>>>>> not define any mechanisms which exert control over the underlying PS= N. >>>>>> When necessary it may, however, recommend or require the use of exis= ting >>>>>> PSN QoS and path control mechanisms between the PEs which provide th= e >>>>>> L2VPN connectivity. >>>>>> >>>>>> Layer-2 VPNs comprise the following: >>>>>> >>>>>> 1. Virtual Private LAN Service (VPLS) -- A Layer-2 service that emul= ates >>>>>> a switched Ethernet (V)LAN across an MPLS Packet Switched Network (P= SN). >>>>>> >>>>>> 2. Virtual Private Wire Service (VPWS) -- A Layer-2 service that >>>>>> provides point-to-point connectivity for a variety of link layers, >>>>>> including Frame Relay, ATM, Ethernet, PPP, etc., across an MPLS PSN. >>>>>> >>>>>> 3. Virtual Private Multicast Service (VPMS) -- A Layer-2 service tha= t >>>>>> provides point-to-multipoint connectivity for a variety of link >>>>>> layers across an MPLS PSN. >>>>>> >>>>>> 4. IP-only L2VPN - An IP-only service over an MPLS PSN. The WG will >>>>>> address two specific types of IP-only L2VPN: >>>>>> >>>>>> a) Point-to-point Layer-2 VPN. This service is similar to VPWS, but= also >>>>>> supports heterogenous Attachment Circuits at either end of a single >>>>>> point-to-point service. >>>>>> >>>>>> b) Multipoint-to-multipoint Layer-2 VPN. This service is similar to >>>>>> VPLS, >>>>>> but learns IP and MAC address bindings from ARPs and broadcast/multi= cast >>>>>> IP packets. >>>>>> >>>>>> 5. Ethernet VPN (E-VPN) - A Layer-2 technology that emulates an >>>>>> Ethernet (V)LAN across an MPLS PSN. E-VPN supports load-sharing acro= ss >>>>>> multiple connections from a Layer-2 site to an L2VPN service, and al= so >>>>>> supports control plane distribution of MAC addresses and IP to MAC >>>>>> address >>>>>> bindings in the VPN. E-VPN is primarily targeted to support large-sc= ale >>>>>> L2VPNs with resiliency requirements not satisfied by other L2VPN >>>>>> solutions. >>>>>> >>>>>> 6. E-Tree - a Layer-2 technology defined by the MEF, which provides >>>>>> connectivity between one or more "root" nodes and one or more >>>>>> "leaf" nodes, with the restriction that leaves may only communicate >>>>>> with roots (and not with each other). >>>>>> >>>>>> L2VPNs will make use of existing IETF specified mechanisms unless th= ere >>>>>> are technical reasons why the existing mechanisms are insufficient o= r >>>>>> unnecessary. >>>>>> >>>>>> The L2VPN WG is responsible for specification of the discovery and >>>>>> membership of PEs participating in a Layer-2 VPN as well as the >>>>>> membership of CE devices for a specific instance of an L2VPN. >>>>>> >>>>>> The L2VPN WG will provide extensions of existing protocols that will= be >>>>>> discussed in protocol-specific WGs. In particular, the L2VPN WG >>>>>> may define extensions to pseudowire management mechanisms for VPLS. >>>>>> Those extensions will be reviewed by the PWE3 WG to ensure they are >>>>>> aligned with the overall design/architecture of PWE3. >>>>>> >>>>>> The L2VPN WG will not define new encapsulations, control, or resilie= ncy >>>>>> mechanisms specifically related to pseudowires. Furthermore, when th= e >>>>>> L2VPN solution is based on PWs, the L2VPN WG will not define protoco= l >>>>>> inter-working between an L2VPN and native service Layer-2 OAM or >>>>>> resiliency mechanisms. The L2VPN WG may define how to operate native >>>>>> service-layer control, OAM or resiliency mechanisms on top of an L2V= PN. >>>>>> In addition, it may define native data plane and/or control plane >>>>>> interworking between an L2VPN and an associated native Layer-2 servi= ce. >>>>>> >>>>>> The L2VPN WG scope includes the following: >>>>>> >>>>>> 1. Discovery of PEs participating in a Layer-2 VPN and the associate= d >>>>>> topology required for connectivity of the VPLS, VPWS, VPMS or E-VPN >>>>>> service. >>>>>> >>>>>> 2. Signaling of information related to the discovery and membership = of >>>>>> PEs within a L2VPN. These procedures must use PWE3 control and >>>>>> management procedures, or define requirements for extensions of PWE3 >>>>>> protocols to suit the needs of an L2VPN, when the L2VPN operates ove= r >>>>>> PWs. Once those requirements have been reviewed by the L2VPN WG, the= y >>>>>> should be provided to the PWE3 WG to derive solutions. >>>>>> >>>>>> 3. MIBs for Layer-2 VPN solutions. >>>>>> >>>>>> 4. Specification of requirements, framework and solutions that >>>>>> facilitate Operations Administration and Management (OAM) of any typ= e of >>>>>> L2VPN. >>>>>> >>>>>> 5. Mechanisms to permit optimization of multicast data traffic withi= n >>>>>> an L2VPN. >>>>>> >>>>>> 6. If transport does not involve PWs, mechanisms that support >>>>>> load-balancing/multipathing between PEs interconnecting a Layer-2 >>>>>> service using an L2VPN across the MPLS PSN. >>>>>> >>>>>> 7. requirements for the multi-homing of CEs to several VPLS or >>>>>> E-VPN PEs, inclusive of active/backup and active/active (load-sharin= g) >>>>>> configurations. Based on these requirements define VPLS or E-VPN con= trol >>>>>> plane solutions for achieving fast convergence after failure of an a= ctive >>>>>> path in the PSN or on the AC side. >>>>>> >>>>>> 8. Enhancements to increase the scalability of the Control Plane and >>>>>> Data Plane of L2VPN PE nodes, and of core nodes that provide transpo= rt >>>>>> services for L2VPN. >>>>>> >>>>>> 9. Requirements and solutions for Auto-Discovery and Signaling of >>>>>> Inter-AS L2VPNs, in addition to Inter-AS solutions for >>>>>> multicast-optimized >>>>>> L2VPNs. >>>>>> >>>>>> 10. Requirements and solutions for supporting "E-Tree" services usin= g >>>>>> VPLS. >>>>>> >>>>>> 11. Extensions to L2VPN protocols and RFCs necessary to create an MP= LS >>>>>> Transport Profile (MPLS-TP). The work on the MPLS TP will be coordin= ated >>>>>> between four primary working groups (MPLS, PWE3, L2VPN and CCAMP) th= at >>>>>> are >>>>>> chartered to do MPLS TP work. >>>>>> >>>>>> Milestones: >>>>>> >>>>>> Done Submit an I-D describing MIB for VPLS >>>>>> Done Submit an I-D describing MIB for VPWS >>>>>> Done Submit an I-D on OAM requirements for VPLS >>>>>> Done Submit an I-D on OAM requirements for VPWS >>>>>> Done Submit L2 requirements to IESG for publication as >>>>>> Informational >>>>>> RFC >>>>>> Done Submit L2 framework to IESG for publication as Informati= onal >>>>>> RFC >>>>>> Done Identify VPLS and VPWS solutions for the WG >>>>>> Done Submit VPLS solution documents to IESG >>>>>> Done Submit VPWS solution documents to IESG >>>>>> Done Submit Auto-Discovery and Signaling for Intra-AS and Int= er-AS >>>>>> VPLS and VPWS Layer-2 VPNs >>>>>> Jul 2011 Submit IP-only L2VPN solution documents to IESG >>>>>> Jul 2011 Submit OAM solutions for VPWS to IESG >>>>>> Jul 2011 Submit OAM solutions for VPLS to IESG >>>>>> Jul 2011 Submit signaling solution for multicast-optimized VPLS t= o >>>>>> IESG >>>>>> Jul 2011 Submit I-D on Virtual Private Multicast Service (VPMS) >>>>>> requirements to IESG >>>>>> Jul 2011 Submit MIB for VPLS to IESG >>>>>> Jul 2011 Submit MIB for VPWS to IESG >>>>>> Nov 2011 Submit scalability solutions for VPLS Data-Plane to IESG >>>>>> Nov 2011 Submit scalability solutions for VPLS Control-Plane to I= ESG >>>>>> Mar 2012 Submit MIB for IP-only L2VPN to IESG >>>>>> Mar 2012 Submit OAM solutions for IP-only L2VPN to IESG >>>>>> Mar 2012 Submit Auto-Discovery solution for VPMS to IESG >>>>>> Mar 2012 Submit VPLS service convergence improvement solutions to= IESG >>>>>> Mar 2012 Submit VPLS multi-homing solutions to IESG >>>>>> Mar 2012 Submit E-Tree documents to IESG >>>>>> Mar 2012 Submit E-VPN requirements/framework to IESG >>>>>> Jul 2012 Submit E-VPN solution to IESG >>>>>> Nov 2012 Submit E-VPN MIB/OAM to IESG >>>>>> >>>>>> ----------------- >>>>>> >>>>>> On 18/03/2011 17:41, "Giles Heron" wrote: >>>>>> >>>>>>> We plan to re-charter the L2VPN WG - primarily to bring E-VPN and E= -Tree >>>>>>> in-scope. >>>>>>> >>>>>>> Please find attached a draft charter for discussion both on this li= st >>>>>>> and at >>>>>>> IETF 80 in Prague. >>>>>>> >>>>>>> Nabil and Giles >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >> > > --------------------------------------------- > Nabil Bitar, PhD > Principal Member of Technical Staff > Packet Network Technology > Verizon Corporate Network and Technology > > 60 Sylvan Road > Waltham, MA 02451 > Office Phone: (781) 466-2161 > From list_work@beckhaus-net.de Fri Jun 24 19:48:44 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 246C811E8078 for ; Fri, 24 Jun 2011 19:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.357 X-Spam-Level: X-Spam-Status: No, score=0.357 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, SARE_MLB_Stock6=1.56] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZExek6qRlBft for ; Fri, 24 Jun 2011 19:48:42 -0700 (PDT) Received: from wp062.webpack.hosteurope.de (wp062.webpack.hosteurope.de [IPv6:2a01:488:42::50ed:8445]) by ietfa.amsl.com (Postfix) with ESMTP id 8969011E8072 for ; Fri, 24 Jun 2011 19:48:41 -0700 (PDT) Received: from p579dd1db.dip.t-dialin.net ([87.157.209.219] helo=[192.168.3.38]); authenticated by wp062.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) id 1QaIvA-00040r-IP; Sat, 25 Jun 2011 04:48:32 +0200 References: In-Reply-To: Mime-Version: 1.0 (iPad Mail 8J3) Content-Type: text/plain; charset=utf-8 Message-Id: <6913AB9D-4EC0-4F43-B31C-E02B12171FCC@beckhaus-net.de> Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (8J3) From: Thomas Beckhaus Subject: Re: [L2VPN] Re: Draft of new L2VPN WG Charter Date: Sat, 25 Jun 2011 04:48:29 +0200 To: Giles Heron , "nabil.n.bitar@verizon.com" X-bounce-key: webpack.hosteurope.de; list_work@beckhaus-net.de; 1308970121; 46ed4c27; Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2011 02:48:44 -0000 Giles, Nabil, in contrast to the other topics in the charter, the sentence in "Layer-2 VPN= " topic 5 "and also supports control plane distribution of MAC addresses and= IP to MAC address bindings" describes a solution and not a requirement. I t= hink, the flexibility in the area of the solution is covered by the addition= al text of the charter. I think there is no need to mention it explicit. Thomas Am 14.06.2011 um 01:08 schrieb Giles Heron : > So in the absence of any follow-up to Nabil=E2=80=99s email we=E2=80=99d l= ike to propose > that we adopt the charter as below. >=20 > The only modifications from the charter Giles posted at the start of this > thread are: > 1) fixed the 2011 date on VPMS Auto-Discovery to 2012 (as spotted by Ben) > 2) changed E-Tree from =E2=80=9Ctechnology=E2=80=9D to =E2=80=9Cservice=E2= =80=9D (as suggested by Yuanlong) > 3) we=E2=80=99ve pushed the E-VPN solution and OAM/MIB milestones back a y= ear, in > response to Joel=E2=80=99s comment about deferring these. >=20 > The main area of debate seems to have been the second sentence: >=20 > =E2=80=9CIt will also address requirements driven by cloud computing servi= ces and > data centers as they apply to Layer-2 VPN services.=E2=80=9D >=20 > Unless there=E2=80=99s any strong objection to this sentence that garners s= ome > degree of consensus we propose to leave it in. >=20 > We=E2=80=99d like to wrap this up in the next couple of weeks, so let=E2=80= =99s bring any > debate to a close by Friday 24th June and then move forward. Those with > sharp eyes will notice that the first of our new deadlines are fast > approaching! >=20 > Giles & Nabil >=20 >=20 > The L2VPN working group is responsible for defining and specifying a > limited number of solutions for supporting provider-provisioned Layer-2 > Virtual Private Networks (L2VPNs). It will also address requirements drive= n > by cloud computing services and data centers as they apply to Layer-2 > VPN services. >=20 > Layer-2 VPNs defined by L2VPN operate over pseudowires (PWs) as > defined by the PWE3 WG or over MPLS PSN tunnels. A L2VPN emulates a > "native" service over a PSN that is adequately faithful to, but may not > be entirely indistinguishable from the native service itself. Further, > following in the "edge-to-edge" nature of the service, the L2VPN WG will > not define any mechanisms which exert control over the underlying PSN. > When necessary it may, however, recommend or require the use of existing > PSN QoS and path control mechanisms between the PEs which provide the > L2VPN connectivity. >=20 > Layer-2 VPNs comprise the following: >=20 > 1. Virtual Private LAN Service (VPLS) -- A Layer-2 service that emulates > a switched Ethernet (V)LAN across an MPLS PSN. >=20 > 2. Virtual Private Wire Service (VPWS) -- A Layer-2 service that > provides point-to-point connectivity for a variety of link layers, > including Frame Relay, ATM, Ethernet, PPP, etc., across an MPLS PSN. >=20 > 3. Virtual Private Multicast Service (VPMS) -- A Layer-2 service that > provides point-to-multipoint connectivity for a variety of link > layers across an MPLS PSN. >=20 > 4. IP-only L2VPN =E2=80=93 An IP-only service over an MPLS PSN. The WG wi= ll > address two specific types of IP-only L2VPN: >=20 > a) Point-to-point Layer-2 VPN. This service is similar to VPWS, but also > supports heterogenous Attachment Circuits at either end of a single > point-to-point service. >=20 > b) Multipoint-to-multipoint Layer-2 VPN. This service is similar to VPLS,= > but learns IP and MAC address bindings from ARPs and broadcast/multicast > IP packets. >=20 > 5. Ethernet VPN (E-VPN) - A Layer-2 service that emulates an > Ethernet (V)LAN across an MPLS PSN. E-VPN supports load-sharing across > multiple connections from a Layer-2 site to an L2VPN service, and also > supports control plane distribution of MAC addresses and IP to MAC address= > bindings in the VPN. E-VPN is primarily targeted to support large-scale > L2VPNs with resiliency requirements not satisfied by other L2VPN solutions= . >=20 > 6. E-Tree =E2=80=93 a Layer-2 service defined by the MEF, which provides > connectivity between one or more =E2=80=9Croot=E2=80=9D nodes and one or m= ore > =E2=80=9Cleaf=E2=80=9D nodes, with the restriction that leaves may only co= mmunicate > with roots (and not with each other). >=20 > L2VPNs will make use of existing IETF specified mechanisms unless there > are technical reasons why the existing mechanisms are insufficient or > unnecessary. >=20 > The L2VPN WG is responsible for specification of the discovery and > membership of PEs participating in a Layer-2 VPN as well as the > membership of CE devices for a specific instance of an L2VPN. >=20 > The L2VPN WG will provide extensions of existing protocols that will be > discussed in protocol-specific WGs. In particular, the L2VPN WG > may define extensions to pseudowire management mechanisms for VPLS. > Those extensions will be reviewed by the PWE3 WG to ensure they are > aligned with the overall design/architecture of PWE3. >=20 > The L2VPN WG will not define new encapsulations, control, or resiliency > mechanisms specifically related to pseudowires. Furthermore, when the > L2VPN solution is based on PWs, the L2VPN WG will not define protocol > inter-working between an L2VPN and native service Layer-2 OAM or > resiliency mechanisms. The L2VPN WG may define how to operate native > service-layer control, OAM or resiliency mechanisms on top of an L2VPN. > In addition, it may define native data plane and/or control plane > interworking between an L2VPN and an associated native Layer-2 service. >=20 > The L2VPN WG scope includes the following: >=20 > 1. Discovery of PEs participating in a Layer-2 VPN and the associated > topology required for connectivity of the VPLS, VPWS, VPMS or E-VPN > service. >=20 > 2. Signaling of information related to the discovery and membership of > PEs within a L2VPN. These procedures must use PWE3 control and > management procedures, or define requirements for extensions of PWE3 > protocols to suit the needs of an L2VPN, when the L2VPN operates over > PWs. Once those requirements have been reviewed by the L2VPN WG, they > should be provided to the PWE3 WG to derive solutions. >=20 > 3. MIBs for Layer-2 VPN solutions. >=20 > 4. Specification of requirements, framework and solutions that > facilitate Operations Administration and Management (OAM) of any type of > L2VPN. >=20 > 5. Mechanisms to permit optimization of multicast data traffic within > an L2VPN. >=20 > 6. If transport does not involve PWs, mechanisms that support > load-balancing/multipathing between PEs interconnecting a Layer-2 > service using an L2VPN across the MPLS PSN. >=20 > 7. requirements for the multi-homing of CEs to several VPLS or > E-VPN PEs, inclusive of active/backup and active/active (load-sharing) > configurations. Based on these requirements define VPLS or E-VPN control > plane solutions for achieving fast convergence after failure of an active > path in the PSN or on the AC side. >=20 > 8. Enhancements to increase the scalability of the Control Plane and > Data Plane of L2VPN PE nodes, and of core nodes that provide transport > services for L2VPN. >=20 > 9. Requirements and solutions for Auto-Discovery and Signaling of > Inter-AS L2VPNs, in addition to Inter-AS solutions for multicast-optimized= > L2VPNs. >=20 > 10. Requirements and solutions for supporting "E-Tree" services using > VPLS.=20 >=20 > 11. Extensions to L2VPN protocols and RFCs necessary to create an MPLS > Transport Profile (MPLS-TP). The work on the MPLS TP will be coordinated > between four primary working groups (MPLS, PWE3, L2VPN and CCAMP) that are= > chartered to do MPLS TP work. >=20 > Milestones: >=20 > Done Submit an I-D describing MIB for VPLS > Done Submit an I-D describing MIB for VPWS > Done Submit an I-D on OAM requirements for VPLS > Done Submit an I-D on OAM requirements for VPWS > Done Submit L2 requirements to IESG for publication as Informationa= l > RFC > Done Submit L2 framework to IESG for publication as Informational R= FC > Done Identify VPLS and VPWS solutions for the WG > Done Submit VPLS solution documents to IESG > Done Submit VPWS solution documents to IESG > Done Submit Auto-Discovery and Signaling for Intra-AS and Inter-AS > VPLS > and VPWS Layer-2 VPNs > Jul 2011 Submit IP-only L2VPN solution documents to IESG > Jul 2011 Submit OAM solutions for VPWS to IESG > Jul 2011 Submit OAM solutions for VPLS to IESG > Jul 2011 Submit signaling solution for multicast-optimized VPLS to IESG= > Jul 2011 Submit I-D on Virtual Private Multicast Service (VPMS) > requirements > to IESG > Jul 2011 Submit MIB for VPLS to IESG > Jul 2011 Submit MIB for VPWS to IESG > Nov 2011 Submit scalability solutions for VPLS Data-Plane to IESG > Nov 2011 Submit scalability solutions for VPLS Control-Plane to IESG > Mar 2012 Submit MIB for IP-only L2VPN to IESG > Mar 2012 Submit OAM solutions for IP-only L2VPN to IESG > Mar 2012 Submit Auto-Discovery solution for VPMS to IESG > Mar 2012 Submit VPLS service convergence improvement solutions to IESG > Mar 2012 Submit VPLS multi-homing solutions to IESG > Mar 2012 Submit E-Tree documents to IESG > Mar 2012 Submit E-VPN requirements/framework to IESG > Jul 2013 Submit E-VPN solution to IESG > Nov 2013 Submit E-VPN MIB/OAM to IESG >=20 >=20 > On 08/05/2011 16:34, "Bitar, Nabil N" wrote: >=20 >> Hi, >> As we are working to firming up the charter, I think it will be good to >> address the questions raised in this thread. I am hearing question about t= he >> intention of that second sentence mentioned more than opposition to it. >> We are still addressing provider-provisioned L2VPN. However, nothing rest= ricts >> the environment that this gets used in. For instance, if there is value t= o >> expand l2vpn such as VPLS into the data center, would that be excluded? I= am >> not judging that there is value or not. If there are new requirements tha= t >> drive additional solutions, should they be excluded? >> In addition, Data center and data center interconnects in a cloud could= >> bring requirements to interconnect technologies that we had not looked at= >> before in the l2vpn WG. Certainly, a data center layer2 network can be b= ased >> on Trill or 802.1aq as examples which we had not covered before in additi= on to >> 802.1ad or PBB . If there are requirements to interconnect data center= s >> using these technologies, l2vpn-solutions may be needed (and if needed dr= afts >> will show up). These are examples and are not to restrict the types of >> requirements. There are already drafts driven from data center and cloud >> viewpoint that have been brought in by folks. Could we live without the >> sentence in question? Probably yes. However, calling out explicitly that >> solutions that address data center and cloud requirements as they apply t= o >> l2vpn are within the l2vpn WG charter adds more clarity to what we could b= e >> taking on upfront. We all know based on industry activities, that is an a= rea >> of interest, and there have been already drafts brought to the l2vpn WG d= riven >> by that although some were not layer2-based. For that reason also, I thin= k >> calling it out as in the draft charter points out that only L2 will be >> addressed by the l2vpn WG, which may seem like calling out the obvious. >>=20 >> Thanks, >> Nabil >>=20 >> On 3/31/11 12:18 PM, "Benson Schliesser" wrote: >>=20 >>> Speaking as ARMD co-chair: Solution development is not in our charter, b= ut >>> analysis of existing solutions (and identification of gaps) is. If we >>> identify gaps, then ARMD might be re-chartered to develop solutions =E2=80= =93 or we >>> might send our requirements into other WGs for development. This is TBD= >>> pending our work on the Problem Statement. >>>=20 >>> Speaking personally: I don=E2=80=99t have any objection to L2VPN working= on data >>> center solutions. If somebody deploys e.g. VPLS inside an enterprise >>> network, provider data center, provider metro network, etc, I think thes= e are >>> all valid use-cases. This is why I asked my question about the 2nd sent= ence >>> =E2=80=93 it seems redundant. >>>=20 >>> Cheers, >>> -Benson >>>=20 >>>=20 >>> On 3/31/11 10:21 AM, "Shah, Himanshu" wrote: >>>=20 >>>> My understanding is that, as a first step, the problem >>>> scope needs to be understood. Solutions, if any required, >>>> could follow only after the problem is well understood. >>>> Solutions are part of ARMD charter but only after first step >>>> is completed. >>>>=20 >>>> Although, it appears that L2VPN group has already acknowledged >>>> and understood the problem well enough to propose solutions?? >>>>=20 >>>> /himanshu >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: l2vpn-bounces@ietf.org on behalf of Thomas Nadeau >>>> Sent: Thu 3/31/2011 10:57 AM >>>> To: Giles Heron >>>> Cc: l2vpn@ietf.org >>>> Subject: Re: Draft of new L2VPN WG Charter >>>>=20 >>>>=20 >>>> On Mar 31, 2011, at 10:49 AM, Giles Heron wrote: >>>>=20 >>>>> Hi Benson, >>>>>=20 >>>>> This would be provider-provisioned L2VPN environments (whether data-ce= ntre >>>>> interconnect, or scaling of a large multi-tenant data-centre). >>>>>=20 >>>>> Personally I'm not sure we need the sentence there, but others were ke= en to >>>>> mention the data-centre requirements. >>>>=20 >>>> I think that is meant to explicitly field requirements for solut= ions >>>> that come from ARMD/etc... into the WG, since they cannot build their o= wn >>>> solutions. While that isn't implicitly handled in the existing charter= , I >>>> do not know either. >>>>=20 >>>> --Tom >>>>=20 >>>>=20 >>>>>=20 >>>>> Giles >>>>>=20 >>>>> On 31/03/2011 15:37, "Benson Schliesser" wrote: >>>>>=20 >>>>>> Hi, Giles. >>>>>>=20 >>>>>> I have a clarifying question about the first paragraph: What is the >>>>>> purpose >>>>>> of the 2nd sentence, bringing cloud and DC requirements into the mix?= >>>>>> Assuming this is meant to include non-provider L2VPN environments (li= ke >>>>>> enterprise data centers), then why not just remove the phrase >>>>>> "provider-provisioned" from the first sentence? Otherwise, it seems >>>>>> redundant. >>>>>>=20 >>>>>> This is a real question, not a suggestion at this time. >>>>>>=20 >>>>>> Thanks, >>>>>> -Benson >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 3/18/11 1:21 PM, "Giles Heron" wrote: >>>>>>=20 >>>>>>> OK - looks like the attachment didn't come through as intended. My >>>>>>> apologies. >>>>>>>=20 >>>>>>> Text inline: >>>>>>>=20 >>>>>>> ---------------- >>>>>>>=20 >>>>>>> The L2VPN working group is responsible for defining and specifying a= >>>>>>> limited number of solutions for supporting provider-provisioned Laye= r-2 >>>>>>> Virtual Private Networks (L2VPNs). It will also address requirements= >>>>>>> driven >>>>>>> by cloud computing services and data centers as they apply to Layer-= 2 >>>>>>> VPN services. >>>>>>>=20 >>>>>>> Layer-2 VPNs defined by L2VPN operate over pseudowires (PWs) as >>>>>>> defined by the PWE3 WG or over MPLS PSN tunnels. A L2VPN emulates a >>>>>>> "native" service over a PSN that is adequately faithful to, but may n= ot >>>>>>> be entirely indistinguishable from the native service itself. Furthe= r, >>>>>>> following in the "edge-to-edge" nature of the service, the L2VPN WG= will >>>>>>> not define any mechanisms which exert control over the underlying PS= N. >>>>>>> When necessary it may, however, recommend or require the use of exis= ting >>>>>>> PSN QoS and path control mechanisms between the PEs which provide th= e >>>>>>> L2VPN connectivity. >>>>>>>=20 >>>>>>> Layer-2 VPNs comprise the following: >>>>>>>=20 >>>>>>> 1. Virtual Private LAN Service (VPLS) -- A Layer-2 service that emul= ates >>>>>>> a switched Ethernet (V)LAN across an MPLS Packet Switched Network (P= SN). >>>>>>>=20 >>>>>>> 2. Virtual Private Wire Service (VPWS) -- A Layer-2 service that >>>>>>> provides point-to-point connectivity for a variety of link layers, >>>>>>> including Frame Relay, ATM, Ethernet, PPP, etc., across an MPLS PSN.= >>>>>>>=20 >>>>>>> 3. Virtual Private Multicast Service (VPMS) -- A Layer-2 service tha= t >>>>>>> provides point-to-multipoint connectivity for a variety of link >>>>>>> layers across an MPLS PSN. >>>>>>>=20 >>>>>>> 4. IP-only L2VPN - An IP-only service over an MPLS PSN. The WG will= >>>>>>> address two specific types of IP-only L2VPN: >>>>>>>=20 >>>>>>> a) Point-to-point Layer-2 VPN. This service is similar to VPWS, but= also >>>>>>> supports heterogenous Attachment Circuits at either end of a single >>>>>>> point-to-point service. >>>>>>>=20 >>>>>>> b) Multipoint-to-multipoint Layer-2 VPN. This service is similar to= >>>>>>> VPLS, >>>>>>> but learns IP and MAC address bindings from ARPs and broadcast/multi= cast >>>>>>> IP packets. >>>>>>>=20 >>>>>>> 5. Ethernet VPN (E-VPN) - A Layer-2 technology that emulates an >>>>>>> Ethernet (V)LAN across an MPLS PSN. E-VPN supports load-sharing acro= ss >>>>>>> multiple connections from a Layer-2 site to an L2VPN service, and al= so >>>>>>> supports control plane distribution of MAC addresses and IP to MAC >>>>>>> address >>>>>>> bindings in the VPN. E-VPN is primarily targeted to support large-sc= ale >>>>>>> L2VPNs with resiliency requirements not satisfied by other L2VPN >>>>>>> solutions. >>>>>>>=20 >>>>>>> 6. E-Tree - a Layer-2 technology defined by the MEF, which provides >>>>>>> connectivity between one or more "root" nodes and one or more >>>>>>> "leaf" nodes, with the restriction that leaves may only communicate >>>>>>> with roots (and not with each other). >>>>>>>=20 >>>>>>> L2VPNs will make use of existing IETF specified mechanisms unless th= ere >>>>>>> are technical reasons why the existing mechanisms are insufficient o= r >>>>>>> unnecessary. >>>>>>>=20 >>>>>>> The L2VPN WG is responsible for specification of the discovery and >>>>>>> membership of PEs participating in a Layer-2 VPN as well as the >>>>>>> membership of CE devices for a specific instance of an L2VPN. >>>>>>>=20 >>>>>>> The L2VPN WG will provide extensions of existing protocols that will= be >>>>>>> discussed in protocol-specific WGs. In particular, the L2VPN WG >>>>>>> may define extensions to pseudowire management mechanisms for VPLS. >>>>>>> Those extensions will be reviewed by the PWE3 WG to ensure they are >>>>>>> aligned with the overall design/architecture of PWE3. >>>>>>>=20 >>>>>>> The L2VPN WG will not define new encapsulations, control, or resilie= ncy >>>>>>> mechanisms specifically related to pseudowires. Furthermore, when th= e >>>>>>> L2VPN solution is based on PWs, the L2VPN WG will not define protoco= l >>>>>>> inter-working between an L2VPN and native service Layer-2 OAM or >>>>>>> resiliency mechanisms. The L2VPN WG may define how to operate native= >>>>>>> service-layer control, OAM or resiliency mechanisms on top of an L2V= PN. >>>>>>> In addition, it may define native data plane and/or control plane >>>>>>> interworking between an L2VPN and an associated native Layer-2 servi= ce. >>>>>>>=20 >>>>>>> The L2VPN WG scope includes the following: >>>>>>>=20 >>>>>>> 1. Discovery of PEs participating in a Layer-2 VPN and the associate= d >>>>>>> topology required for connectivity of the VPLS, VPWS, VPMS or E-VPN >>>>>>> service. >>>>>>>=20 >>>>>>> 2. Signaling of information related to the discovery and membership o= f >>>>>>> PEs within a L2VPN. These procedures must use PWE3 control and >>>>>>> management procedures, or define requirements for extensions of PWE3= >>>>>>> protocols to suit the needs of an L2VPN, when the L2VPN operates ove= r >>>>>>> PWs. Once those requirements have been reviewed by the L2VPN WG, the= y >>>>>>> should be provided to the PWE3 WG to derive solutions. >>>>>>>=20 >>>>>>> 3. MIBs for Layer-2 VPN solutions. >>>>>>>=20 >>>>>>> 4. Specification of requirements, framework and solutions that >>>>>>> facilitate Operations Administration and Management (OAM) of any typ= e of >>>>>>> L2VPN. >>>>>>>=20 >>>>>>> 5. Mechanisms to permit optimization of multicast data traffic withi= n >>>>>>> an L2VPN. >>>>>>>=20 >>>>>>> 6. If transport does not involve PWs, mechanisms that support >>>>>>> load-balancing/multipathing between PEs interconnecting a Layer-2 >>>>>>> service using an L2VPN across the MPLS PSN. >>>>>>>=20 >>>>>>> 7. requirements for the multi-homing of CEs to several VPLS or >>>>>>> E-VPN PEs, inclusive of active/backup and active/active (load-sharin= g) >>>>>>> configurations. Based on these requirements define VPLS or E-VPN con= trol >>>>>>> plane solutions for achieving fast convergence after failure of an a= ctive >>>>>>> path in the PSN or on the AC side. >>>>>>>=20 >>>>>>> 8. Enhancements to increase the scalability of the Control Plane and= >>>>>>> Data Plane of L2VPN PE nodes, and of core nodes that provide transpo= rt >>>>>>> services for L2VPN. >>>>>>>=20 >>>>>>> 9. Requirements and solutions for Auto-Discovery and Signaling of >>>>>>> Inter-AS L2VPNs, in addition to Inter-AS solutions for >>>>>>> multicast-optimized >>>>>>> L2VPNs. >>>>>>>=20 >>>>>>> 10. Requirements and solutions for supporting "E-Tree" services usin= g >>>>>>> VPLS. >>>>>>>=20 >>>>>>> 11. Extensions to L2VPN protocols and RFCs necessary to create an MP= LS >>>>>>> Transport Profile (MPLS-TP). The work on the MPLS TP will be coordin= ated >>>>>>> between four primary working groups (MPLS, PWE3, L2VPN and CCAMP) th= at >>>>>>> are >>>>>>> chartered to do MPLS TP work. >>>>>>>=20 >>>>>>> Milestones: >>>>>>>=20 >>>>>>> Done Submit an I-D describing MIB for VPLS >>>>>>> Done Submit an I-D describing MIB for VPWS >>>>>>> Done Submit an I-D on OAM requirements for VPLS >>>>>>> Done Submit an I-D on OAM requirements for VPWS >>>>>>> Done Submit L2 requirements to IESG for publication as >>>>>>> Informational >>>>>>> RFC >>>>>>> Done Submit L2 framework to IESG for publication as Informati= onal >>>>>>> RFC >>>>>>> Done Identify VPLS and VPWS solutions for the WG >>>>>>> Done Submit VPLS solution documents to IESG >>>>>>> Done Submit VPWS solution documents to IESG >>>>>>> Done Submit Auto-Discovery and Signaling for Intra-AS and Int= er-AS >>>>>>> VPLS and VPWS Layer-2 VPNs >>>>>>> Jul 2011 Submit IP-only L2VPN solution documents to IESG >>>>>>> Jul 2011 Submit OAM solutions for VPWS to IESG >>>>>>> Jul 2011 Submit OAM solutions for VPLS to IESG >>>>>>> Jul 2011 Submit signaling solution for multicast-optimized VPLS t= o >>>>>>> IESG >>>>>>> Jul 2011 Submit I-D on Virtual Private Multicast Service (VPMS) >>>>>>> requirements to IESG >>>>>>> Jul 2011 Submit MIB for VPLS to IESG >>>>>>> Jul 2011 Submit MIB for VPWS to IESG >>>>>>> Nov 2011 Submit scalability solutions for VPLS Data-Plane to IESG= >>>>>>> Nov 2011 Submit scalability solutions for VPLS Control-Plane to I= ESG >>>>>>> Mar 2012 Submit MIB for IP-only L2VPN to IESG >>>>>>> Mar 2012 Submit OAM solutions for IP-only L2VPN to IESG >>>>>>> Mar 2012 Submit Auto-Discovery solution for VPMS to IESG >>>>>>> Mar 2012 Submit VPLS service convergence improvement solutions to= IESG >>>>>>> Mar 2012 Submit VPLS multi-homing solutions to IESG >>>>>>> Mar 2012 Submit E-Tree documents to IESG >>>>>>> Mar 2012 Submit E-VPN requirements/framework to IESG >>>>>>> Jul 2012 Submit E-VPN solution to IESG >>>>>>> Nov 2012 Submit E-VPN MIB/OAM to IESG >>>>>>>=20 >>>>>>> ----------------- >>>>>>>=20 >>>>>>> On 18/03/2011 17:41, "Giles Heron" wrote: >>>>>>>=20 >>>>>>>> We plan to re-charter the L2VPN WG - primarily to bring E-VPN and E= -Tree >>>>>>>> in-scope. >>>>>>>>=20 >>>>>>>> Please find attached a draft charter for discussion both on this li= st >>>>>>>> and at >>>>>>>> IETF 80 in Prague. >>>>>>>>=20 >>>>>>>> Nabil and Giles >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>=20 >> --------------------------------------------- >> Nabil Bitar, PhD >> Principal Member of Technical Staff >> Packet Network Technology >> Verizon Corporate Network and Technology >>=20 >> 60 Sylvan Road >> Waltham, MA 02451 >> Office Phone: (781) 466-2161 >>=20 >=20 >=20 >=20 From xuxh@huawei.com Fri Jun 24 20:24:45 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D64511E80A4 for ; Fri, 24 Jun 2011 20:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[AWL=0.388, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_MLB_Stock6=1.56, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npBjz+bhX+GH for ; Fri, 24 Jun 2011 20:24:42 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 892F611E809E for ; Fri, 24 Jun 2011 20:24:34 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LNB003W8TGVM5@szxga03-in.huawei.com> for l2vpn@ietf.org; Sat, 25 Jun 2011 11:24:31 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LNB00BPVTGV61@szxga03-in.huawei.com> for l2vpn@ietf.org; Sat, 25 Jun 2011 11:24:31 +0800 (CST) Received: from x41208c ([10.110.98.57]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LNB0072YTGUJ4@szxml06-in.huawei.com> for l2vpn@ietf.org; Sat, 25 Jun 2011 11:24:31 +0800 (CST) Date: Sat, 25 Jun 2011 11:34:56 +0800 From: Xu Xiaohu Subject: =?UTF-8?Q?=E7=AD=94=E5=A4=8D:_Draft_of_new_L2VPN_WG_Charte?= =?UTF-8?Q?r?= In-reply-to: To: "'Shah, Himanshu'" , 'Giles Heron' , "'Bitar, Nabil N'" , 'Benson Schliesser' , 'Thomas Nadeau' Message-id: <001b01cc32e8$db2c3250$918496f0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=UTF-8 Content-language: zh-cn Content-transfer-encoding: quoted-printable Thread-index: AcvvtA2JzqTxhFkJSFamDqHmBDPKfwAAiwePAAI/U3QHTQhEmQdK2Z4pAiWKgsAADJjnoA== References: Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2011 03:24:45 -0000 I have the same feeling. IMHO, IPLS and E-VPN are two alternative = solutions for "routing" VPLS which supports the distribution of MAC = addresses on the control plane, especially the former is LDP-based while = the latter is BGP-based. Best regards, Xiaohu > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: l2vpn-bounces@ietf.org = [mailto:l2vpn-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Shah, > Himanshu > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2011=E5=B9=B46=E6=9C=8825=E6=97=A5 5:30 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Giles Heron; Bitar, Nabil N; Benson = Schliesser; Thomas Nadeau > =E6=8A=84=E9=80=81: l2vpn@ietf.org > =E4=B8=BB=E9=A2=98: RE: Draft of new L2VPN WG Charter >=20 > Giles/Nabil - >=20 > Nabil's email (at the bottom of this email) did not address one of = points > I had raised. >=20 > This relates to specific sentence in charter (5) text > " and also supports control plane distribution of MAC addresses and IP = to MAC > address > bindings in the VPN." >=20 > As I had indicated before on the mailing list, control plane = distribution of > MAC to IP binding is not NEW and was already introduced 7 to 8 years = ago by > proposed solutions related to charter (4). >=20 > By explicitly mentioning this item in the charter (5) gives impression = that > a new concept is being developed or introduced, which is not the case. >=20 > This needs to be corrected. >=20 > Thanks, > himanshu >=20 >=20 >=20 > -----Original Message----- > From: Giles Heron [mailto:giles.heron@gmail.com] > Sent: Monday, June 13, 2011 7:08 PM > To: Bitar, Nabil N; Benson Schliesser; Shah, Himanshu; Thomas Nadeau > Cc: l2vpn@ietf.org > Subject: Re: Draft of new L2VPN WG Charter >=20 > So in the absence of any follow-up to Nabil=C2=B9s email we=C2=B9d = like to propose > that we adopt the charter as below. >=20 > The only modifications from the charter Giles posted at the start of = this > thread are: > 1) fixed the 2011 date on VPMS Auto-Discovery to 2012 (as spotted by = Ben) > 2) changed E-Tree from =C2=B3technology=C2=B2 to =C2=B3service=C2=B2 = (as suggested by Yuanlong) > 3) we=C2=B9ve pushed the E-VPN solution and OAM/MIB milestones back a = year, in > response to Joel=C2=B9s comment about deferring these. >=20 > The main area of debate seems to have been the second sentence: >=20 > =C2=B3It will also address requirements driven by cloud computing = services and > data centers as they apply to Layer-2 VPN services.=C2=B2 >=20 > Unless there=C2=B9s any strong objection to this sentence that garners = some > degree of consensus we propose to leave it in. >=20 > We=C2=B9d like to wrap this up in the next couple of weeks, so = let=C2=B9s bring any > debate to a close by Friday 24th June and then move forward. Those = with > sharp eyes will notice that the first of our new deadlines are fast > approaching! >=20 > Giles & Nabil >=20 >=20 > The L2VPN working group is responsible for defining and specifying a > limited number of solutions for supporting provider-provisioned = Layer-2 > Virtual Private Networks (L2VPNs). It will also address requirements = driven > by cloud computing services and data centers as they apply to Layer-2 > VPN services. >=20 > Layer-2 VPNs defined by L2VPN operate over pseudowires (PWs) as > defined by the PWE3 WG or over MPLS PSN tunnels. A L2VPN emulates a > "native" service over a PSN that is adequately faithful to, but may = not > be entirely indistinguishable from the native service itself. Further, > following in the "edge-to-edge" nature of the service, the L2VPN WG = will > not define any mechanisms which exert control over the underlying PSN. > When necessary it may, however, recommend or require the use of = existing > PSN QoS and path control mechanisms between the PEs which provide the > L2VPN connectivity. >=20 > Layer-2 VPNs comprise the following: >=20 > 1. Virtual Private LAN Service (VPLS) -- A Layer-2 service that = emulates > a switched Ethernet (V)LAN across an MPLS PSN. >=20 > 2. Virtual Private Wire Service (VPWS) -- A Layer-2 service that > provides point-to-point connectivity for a variety of link layers, > including Frame Relay, ATM, Ethernet, PPP, etc., across an MPLS PSN. >=20 > 3. Virtual Private Multicast Service (VPMS) -- A Layer-2 service that > provides point-to-multipoint connectivity for a variety of link > layers across an MPLS PSN. >=20 > 4. IP-only L2VPN =C2=AD An IP-only service over an MPLS PSN. The WG = will > address two specific types of IP-only L2VPN: >=20 > a) Point-to-point Layer-2 VPN. This service is similar to VPWS, but = also > supports heterogenous Attachment Circuits at either end of a single > point-to-point service. >=20 > b) Multipoint-to-multipoint Layer-2 VPN. This service is similar to = VPLS, > but learns IP and MAC address bindings from ARPs and = broadcast/multicast > IP packets. >=20 > 5. Ethernet VPN (E-VPN) - A Layer-2 service that emulates an > Ethernet (V)LAN across an MPLS PSN. E-VPN supports load-sharing across > multiple connections from a Layer-2 site to an L2VPN service, and also > supports control plane distribution of MAC addresses and IP to MAC = address > bindings in the VPN. E-VPN is primarily targeted to support = large-scale > L2VPNs with resiliency requirements not satisfied by other L2VPN = solutions. >=20 > 6. E-Tree =C2=AD a Layer-2 service defined by the MEF, which provides > connectivity between one or more =C2=B3root=C2=B2 nodes and one or = more > =C2=B3leaf=C2=B2 nodes, with the restriction that leaves may only = communicate > with roots (and not with each other). >=20 > L2VPNs will make use of existing IETF specified mechanisms unless = there > are technical reasons why the existing mechanisms are insufficient or > unnecessary. >=20 > The L2VPN WG is responsible for specification of the discovery and > membership of PEs participating in a Layer-2 VPN as well as the > membership of CE devices for a specific instance of an L2VPN. >=20 > The L2VPN WG will provide extensions of existing protocols that will = be > discussed in protocol-specific WGs. In particular, the L2VPN WG > may define extensions to pseudowire management mechanisms for VPLS. > Those extensions will be reviewed by the PWE3 WG to ensure they are > aligned with the overall design/architecture of PWE3. >=20 > The L2VPN WG will not define new encapsulations, control, or = resiliency > mechanisms specifically related to pseudowires. Furthermore, when the > L2VPN solution is based on PWs, the L2VPN WG will not define protocol > inter-working between an L2VPN and native service Layer-2 OAM or > resiliency mechanisms. The L2VPN WG may define how to operate native > service-layer control, OAM or resiliency mechanisms on top of an = L2VPN. > In addition, it may define native data plane and/or control plane > interworking between an L2VPN and an associated native Layer-2 = service. >=20 > The L2VPN WG scope includes the following: >=20 > 1. Discovery of PEs participating in a Layer-2 VPN and the associated > topology required for connectivity of the VPLS, VPWS, VPMS or E-VPN > service. >=20 > 2. Signaling of information related to the discovery and membership of > PEs within a L2VPN. These procedures must use PWE3 control and > management procedures, or define requirements for extensions of PWE3 > protocols to suit the needs of an L2VPN, when the L2VPN operates over > PWs. Once those requirements have been reviewed by the L2VPN WG, they > should be provided to the PWE3 WG to derive solutions. >=20 > 3. MIBs for Layer-2 VPN solutions. >=20 > 4. Specification of requirements, framework and solutions that > facilitate Operations Administration and Management (OAM) of any type = of > L2VPN. >=20 > 5. Mechanisms to permit optimization of multicast data traffic within > an L2VPN. >=20 > 6. If transport does not involve PWs, mechanisms that support > load-balancing/multipathing between PEs interconnecting a Layer-2 > service using an L2VPN across the MPLS PSN. >=20 > 7. requirements for the multi-homing of CEs to several VPLS or > E-VPN PEs, inclusive of active/backup and active/active (load-sharing) > configurations. Based on these requirements define VPLS or E-VPN = control > plane solutions for achieving fast convergence after failure of an = active > path in the PSN or on the AC side. >=20 > 8. Enhancements to increase the scalability of the Control Plane and > Data Plane of L2VPN PE nodes, and of core nodes that provide transport > services for L2VPN. >=20 > 9. Requirements and solutions for Auto-Discovery and Signaling of > Inter-AS L2VPNs, in addition to Inter-AS solutions for = multicast-optimized > L2VPNs. >=20 > 10. Requirements and solutions for supporting "E-Tree" services using > VPLS. >=20 > 11. Extensions to L2VPN protocols and RFCs necessary to create an MPLS > Transport Profile (MPLS-TP). The work on the MPLS TP will be = coordinated > between four primary working groups (MPLS, PWE3, L2VPN and CCAMP) that > are > chartered to do MPLS TP work. >=20 > Milestones: >=20 > Done Submit an I-D describing MIB for VPLS > Done Submit an I-D describing MIB for VPWS > Done Submit an I-D on OAM requirements for VPLS > Done Submit an I-D on OAM requirements for VPWS > Done Submit L2 requirements to IESG for publication as = Informational > RFC > Done Submit L2 framework to IESG for publication as = Informational > RFC > Done Identify VPLS and VPWS solutions for the WG > Done Submit VPLS solution documents to IESG > Done Submit VPWS solution documents to IESG > Done Submit Auto-Discovery and Signaling for Intra-AS and = Inter-AS > VPLS > and VPWS Layer-2 VPNs > Jul 2011 Submit IP-only L2VPN solution documents to IESG > Jul 2011 Submit OAM solutions for VPWS to IESG > Jul 2011 Submit OAM solutions for VPLS to IESG > Jul 2011 Submit signaling solution for multicast-optimized VPLS to = IESG > Jul 2011 Submit I-D on Virtual Private Multicast Service (VPMS) > requirements > to IESG > Jul 2011 Submit MIB for VPLS to IESG > Jul 2011 Submit MIB for VPWS to IESG > Nov 2011 Submit scalability solutions for VPLS Data-Plane to IESG > Nov 2011 Submit scalability solutions for VPLS Control-Plane to = IESG > Mar 2012 Submit MIB for IP-only L2VPN to IESG > Mar 2012 Submit OAM solutions for IP-only L2VPN to IESG > Mar 2012 Submit Auto-Discovery solution for VPMS to IESG > Mar 2012 Submit VPLS service convergence improvement solutions to = IESG > Mar 2012 Submit VPLS multi-homing solutions to IESG > Mar 2012 Submit E-Tree documents to IESG > Mar 2012 Submit E-VPN requirements/framework to IESG > Jul 2013 Submit E-VPN solution to IESG > Nov 2013 Submit E-VPN MIB/OAM to IESG >=20 >=20 > On 08/05/2011 16:34, "Bitar, Nabil N" = wrote: >=20 > > Hi, > > As we are working to firming up the charter, I think it will be good = to > > address the questions raised in this thread. I am hearing question = about the > > intention of that second sentence mentioned more than opposition to = it. > > We are still addressing provider-provisioned L2VPN. However, nothing > restricts > > the environment that this gets used in. For instance, if there is = value to > > expand l2vpn such as VPLS into the data center, would that be = excluded? I am > > not judging that there is value or not. If there are new = requirements that > > drive additional solutions, should they be excluded? > > In addition, Data center and data center interconnects in a cloud = could > > bring requirements to interconnect technologies that we had not = looked at > > before in the l2vpn WG. Certainly, a data center layer2 network can = be > based > > on Trill or 802.1aq as examples which we had not covered before in = addition > to > > 802.1ad or PBB . If there are requirements to interconnect data = centers > > using these technologies, l2vpn-solutions may be needed (and if = needed > drafts > > will show up). These are examples and are not to restrict the types = of > > requirements. There are already drafts driven from data center and = cloud > > viewpoint that have been brought in by folks. Could we live without = the > > sentence in question? Probably yes. However, calling out explicitly = that > > solutions that address data center and cloud requirements as they = apply to > > l2vpn are within the l2vpn WG charter adds more clarity to what we = could be > > taking on upfront. We all know based on industry activities, that is = an area > > of interest, and there have been already drafts brought to the l2vpn = WG > driven > > by that although some were not layer2-based. For that reason also, I = think > > calling it out as in the draft charter points out that only L2 will = be > > addressed by the l2vpn WG, which may seem like calling out the = obvious. > > > > Thanks, > > Nabil > > > > On 3/31/11 12:18 PM, "Benson Schliesser" wrote: > > > >> Speaking as ARMD co-chair: Solution development is not in our = charter, > but > >> analysis of existing solutions (and identification of gaps) is. If = we > >> identify gaps, then ARMD might be re-chartered to develop solutions = =C2=AD or > we > >> might send our requirements into other WGs for development. This = is TBD > >> pending our work on the Problem Statement. > >> > >> Speaking personally: I don=C2=B9t have any objection to L2VPN = working on data > >> center solutions. If somebody deploys e.g. VPLS inside an = enterprise > >> network, provider data center, provider metro network, etc, I think = these > are > >> all valid use-cases. This is why I asked my question about the 2nd = sentence > >> =C2=AD it seems redundant. > >> > >> Cheers, > >> -Benson > >> > >> > >> On 3/31/11 10:21 AM, "Shah, Himanshu" wrote: > >> > >>> My understanding is that, as a first step, the problem > >>> scope needs to be understood. Solutions, if any required, > >>> could follow only after the problem is well understood. > >>> Solutions are part of ARMD charter but only after first step > >>> is completed. > >>> > >>> Although, it appears that L2VPN group has already acknowledged > >>> and understood the problem well enough to propose solutions?? > >>> > >>> /himanshu > >>> > >>> > >>> -----Original Message----- > >>> From: l2vpn-bounces@ietf.org on behalf of Thomas Nadeau > >>> Sent: Thu 3/31/2011 10:57 AM > >>> To: Giles Heron > >>> Cc: l2vpn@ietf.org > >>> Subject: Re: Draft of new L2VPN WG Charter > >>> > >>> > >>> On Mar 31, 2011, at 10:49 AM, Giles Heron wrote: > >>> > >>>> Hi Benson, > >>>> > >>>> This would be provider-provisioned L2VPN environments (whether > data-centre > >>>> interconnect, or scaling of a large multi-tenant data-centre). > >>>> > >>>> Personally I'm not sure we need the sentence there, but others = were > keen to > >>>> mention the data-centre requirements. > >>> > >>> I think that is meant to explicitly field requirements for = solutions > >>> that come from ARMD/etc... into the WG, since they cannot build = their > own > >>> solutions. While that isn't implicitly handled in the existing = charter, I > >>> do not know either. > >>> > >>> --Tom > >>> > >>> > >>>> > >>>> Giles > >>>> > >>>> On 31/03/2011 15:37, "Benson Schliesser" = wrote: > >>>> > >>>>> Hi, Giles. > >>>>> > >>>>> I have a clarifying question about the first paragraph: What is = the > >>>>> purpose > >>>>> of the 2nd sentence, bringing cloud and DC requirements into the = mix? > >>>>> Assuming this is meant to include non-provider L2VPN = environments (like > >>>>> enterprise data centers), then why not just remove the phrase > >>>>> "provider-provisioned" from the first sentence? Otherwise, it = seems > >>>>> redundant. > >>>>> > >>>>> This is a real question, not a suggestion at this time. > >>>>> > >>>>> Thanks, > >>>>> -Benson > >>>>> > >>>>> > >>>>> > >>>>> On 3/18/11 1:21 PM, "Giles Heron" wrote: > >>>>> > >>>>>> OK - looks like the attachment didn't come through as intended. = My > >>>>>> apologies. > >>>>>> > >>>>>> Text inline: > >>>>>> > >>>>>> ---------------- > >>>>>> > >>>>>> The L2VPN working group is responsible for defining and = specifying a > >>>>>> limited number of solutions for supporting provider-provisioned = Layer-2 > >>>>>> Virtual Private Networks (L2VPNs). It will also address = requirements > >>>>>> driven > >>>>>> by cloud computing services and data centers as they apply to = Layer-2 > >>>>>> VPN services. > >>>>>> > >>>>>> Layer-2 VPNs defined by L2VPN operate over pseudowires (PWs) as > >>>>>> defined by the PWE3 WG or over MPLS PSN tunnels. A L2VPN = emulates > a > >>>>>> "native" service over a PSN that is adequately faithful to, but = may not > >>>>>> be entirely indistinguishable from the native service itself. = Further, > >>>>>> following in the "edge-to-edge" nature of the service, the = L2VPN WG > will > >>>>>> not define any mechanisms which exert control over the = underlying > PSN. > >>>>>> When necessary it may, however, recommend or require the use of > existing > >>>>>> PSN QoS and path control mechanisms between the PEs which = provide > the > >>>>>> L2VPN connectivity. > >>>>>> > >>>>>> Layer-2 VPNs comprise the following: > >>>>>> > >>>>>> 1. Virtual Private LAN Service (VPLS) -- A Layer-2 service that = emulates > >>>>>> a switched Ethernet (V)LAN across an MPLS Packet Switched = Network > (PSN). > >>>>>> > >>>>>> 2. Virtual Private Wire Service (VPWS) -- A Layer-2 service = that > >>>>>> provides point-to-point connectivity for a variety of link = layers, > >>>>>> including Frame Relay, ATM, Ethernet, PPP, etc., across an MPLS = PSN. > >>>>>> > >>>>>> 3. Virtual Private Multicast Service (VPMS) -- A Layer-2 = service that > >>>>>> provides point-to-multipoint connectivity for a variety of link > >>>>>> layers across an MPLS PSN. > >>>>>> > >>>>>> 4. IP-only L2VPN - An IP-only service over an MPLS PSN. The WG = will > >>>>>> address two specific types of IP-only L2VPN: > >>>>>> > >>>>>> a) Point-to-point Layer-2 VPN. This service is similar to = VPWS, but also > >>>>>> supports heterogenous Attachment Circuits at either end of a = single > >>>>>> point-to-point service. > >>>>>> > >>>>>> b) Multipoint-to-multipoint Layer-2 VPN. This service is = similar to > >>>>>> VPLS, > >>>>>> but learns IP and MAC address bindings from ARPs and > broadcast/multicast > >>>>>> IP packets. > >>>>>> > >>>>>> 5. Ethernet VPN (E-VPN) - A Layer-2 technology that emulates an > >>>>>> Ethernet (V)LAN across an MPLS PSN. E-VPN supports load-sharing > across > >>>>>> multiple connections from a Layer-2 site to an L2VPN service, = and also > >>>>>> supports control plane distribution of MAC addresses and IP to = MAC > >>>>>> address > >>>>>> bindings in the VPN. E-VPN is primarily targeted to support = large-scale > >>>>>> L2VPNs with resiliency requirements not satisfied by other = L2VPN > >>>>>> solutions. > >>>>>> > >>>>>> 6. E-Tree - a Layer-2 technology defined by the MEF, which = provides > >>>>>> connectivity between one or more "root" nodes and one or more > >>>>>> "leaf" nodes, with the restriction that leaves may only = communicate > >>>>>> with roots (and not with each other). > >>>>>> > >>>>>> L2VPNs will make use of existing IETF specified mechanisms = unless > there > >>>>>> are technical reasons why the existing mechanisms are = insufficient or > >>>>>> unnecessary. > >>>>>> > >>>>>> The L2VPN WG is responsible for specification of the discovery = and > >>>>>> membership of PEs participating in a Layer-2 VPN as well as the > >>>>>> membership of CE devices for a specific instance of an L2VPN. > >>>>>> > >>>>>> The L2VPN WG will provide extensions of existing protocols that = will be > >>>>>> discussed in protocol-specific WGs. In particular, the L2VPN WG > >>>>>> may define extensions to pseudowire management mechanisms for > VPLS. > >>>>>> Those extensions will be reviewed by the PWE3 WG to ensure they = are > >>>>>> aligned with the overall design/architecture of PWE3. > >>>>>> > >>>>>> The L2VPN WG will not define new encapsulations, control, or = resiliency > >>>>>> mechanisms specifically related to pseudowires. Furthermore, = when > the > >>>>>> L2VPN solution is based on PWs, the L2VPN WG will not define = protocol > >>>>>> inter-working between an L2VPN and native service Layer-2 OAM = or > >>>>>> resiliency mechanisms. The L2VPN WG may define how to operate > native > >>>>>> service-layer control, OAM or resiliency mechanisms on top of = an > L2VPN. > >>>>>> In addition, it may define native data plane and/or control = plane > >>>>>> interworking between an L2VPN and an associated native Layer-2 > service. > >>>>>> > >>>>>> The L2VPN WG scope includes the following: > >>>>>> > >>>>>> 1. Discovery of PEs participating in a Layer-2 VPN and the = associated > >>>>>> topology required for connectivity of the VPLS, VPWS, VPMS or = E-VPN > >>>>>> service. > >>>>>> > >>>>>> 2. Signaling of information related to the discovery and = membership of > >>>>>> PEs within a L2VPN. These procedures must use PWE3 control and > >>>>>> management procedures, or define requirements for extensions of > PWE3 > >>>>>> protocols to suit the needs of an L2VPN, when the L2VPN = operates over > >>>>>> PWs. Once those requirements have been reviewed by the L2VPN = WG, > they > >>>>>> should be provided to the PWE3 WG to derive solutions. > >>>>>> > >>>>>> 3. MIBs for Layer-2 VPN solutions. > >>>>>> > >>>>>> 4. Specification of requirements, framework and solutions that > >>>>>> facilitate Operations Administration and Management (OAM) of = any > type of > >>>>>> L2VPN. > >>>>>> > >>>>>> 5. Mechanisms to permit optimization of multicast data traffic = within > >>>>>> an L2VPN. > >>>>>> > >>>>>> 6. If transport does not involve PWs, mechanisms that support > >>>>>> load-balancing/multipathing between PEs interconnecting a = Layer-2 > >>>>>> service using an L2VPN across the MPLS PSN. > >>>>>> > >>>>>> 7. requirements for the multi-homing of CEs to several VPLS or > >>>>>> E-VPN PEs, inclusive of active/backup and active/active = (load-sharing) > >>>>>> configurations. Based on these requirements define VPLS or = E-VPN > control > >>>>>> plane solutions for achieving fast convergence after failure of = an active > >>>>>> path in the PSN or on the AC side. > >>>>>> > >>>>>> 8. Enhancements to increase the scalability of the Control = Plane and > >>>>>> Data Plane of L2VPN PE nodes, and of core nodes that provide > transport > >>>>>> services for L2VPN. > >>>>>> > >>>>>> 9. Requirements and solutions for Auto-Discovery and Signaling = of > >>>>>> Inter-AS L2VPNs, in addition to Inter-AS solutions for > >>>>>> multicast-optimized > >>>>>> L2VPNs. > >>>>>> > >>>>>> 10. Requirements and solutions for supporting "E-Tree" services = using > >>>>>> VPLS. > >>>>>> > >>>>>> 11. Extensions to L2VPN protocols and RFCs necessary to create = an > MPLS > >>>>>> Transport Profile (MPLS-TP). The work on the MPLS TP will be > coordinated > >>>>>> between four primary working groups (MPLS, PWE3, L2VPN and > CCAMP) that > >>>>>> are > >>>>>> chartered to do MPLS TP work. > >>>>>> > >>>>>> Milestones: > >>>>>> > >>>>>> Done Submit an I-D describing MIB for VPLS > >>>>>> Done Submit an I-D describing MIB for VPWS > >>>>>> Done Submit an I-D on OAM requirements for VPLS > >>>>>> Done Submit an I-D on OAM requirements for VPWS > >>>>>> Done Submit L2 requirements to IESG for publication as > >>>>>> Informational > >>>>>> RFC > >>>>>> Done Submit L2 framework to IESG for publication as > Informational > >>>>>> RFC > >>>>>> Done Identify VPLS and VPWS solutions for the WG > >>>>>> Done Submit VPLS solution documents to IESG > >>>>>> Done Submit VPWS solution documents to IESG > >>>>>> Done Submit Auto-Discovery and Signaling for Intra-AS = and > Inter-AS > >>>>>> VPLS and VPWS Layer-2 VPNs > >>>>>> Jul 2011 Submit IP-only L2VPN solution documents to IESG > >>>>>> Jul 2011 Submit OAM solutions for VPWS to IESG > >>>>>> Jul 2011 Submit OAM solutions for VPLS to IESG > >>>>>> Jul 2011 Submit signaling solution for multicast-optimized = VPLS to > >>>>>> IESG > >>>>>> Jul 2011 Submit I-D on Virtual Private Multicast Service = (VPMS) > >>>>>> requirements to IESG > >>>>>> Jul 2011 Submit MIB for VPLS to IESG > >>>>>> Jul 2011 Submit MIB for VPWS to IESG > >>>>>> Nov 2011 Submit scalability solutions for VPLS Data-Plane to = IESG > >>>>>> Nov 2011 Submit scalability solutions for VPLS Control-Plane = to > IESG > >>>>>> Mar 2012 Submit MIB for IP-only L2VPN to IESG > >>>>>> Mar 2012 Submit OAM solutions for IP-only L2VPN to IESG > >>>>>> Mar 2012 Submit Auto-Discovery solution for VPMS to IESG > >>>>>> Mar 2012 Submit VPLS service convergence improvement = solutions > to IESG > >>>>>> Mar 2012 Submit VPLS multi-homing solutions to IESG > >>>>>> Mar 2012 Submit E-Tree documents to IESG > >>>>>> Mar 2012 Submit E-VPN requirements/framework to IESG > >>>>>> Jul 2012 Submit E-VPN solution to IESG > >>>>>> Nov 2012 Submit E-VPN MIB/OAM to IESG > >>>>>> > >>>>>> ----------------- > >>>>>> > >>>>>> On 18/03/2011 17:41, "Giles Heron" = wrote: > >>>>>> > >>>>>>> We plan to re-charter the L2VPN WG - primarily to bring E-VPN = and > E-Tree > >>>>>>> in-scope. > >>>>>>> > >>>>>>> Please find attached a draft charter for discussion both on = this list > >>>>>>> and at > >>>>>>> IETF 80 in Prague. > >>>>>>> > >>>>>>> Nabil and Giles > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> > >> > > > > --------------------------------------------- > > Nabil Bitar, PhD > > Principal Member of Technical Staff > > Packet Network Technology > > Verizon Corporate Network and Technology > > > > 60 Sylvan Road > > Waltham, MA 02451 > > Office Phone: (781) 466-2161 > > >=20 >=20 From PazP@orckit.com Mon Jun 27 11:58:10 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3C521F85CF for ; Mon, 27 Jun 2011 11:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4DKmIprz-OI for ; Mon, 27 Jun 2011 11:58:08 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by ietfa.amsl.com (Postfix) with ESMTP id 27D8921F857B for ; Mon, 27 Jun 2011 11:58:00 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC34FC.747BE072" Subject: Questions/suggestions regarding "draft-ietf-l2vpn-vpls-ldp-mac-opt-04.txt" Date: Mon, 27 Jun 2011 22:00:16 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA081306D5FDF9@tlvmail1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Questions/suggestions regarding "draft-ietf-l2vpn-vpls-ldp-mac-opt-04.txt" Thread-Index: Acw0/HPT745glR8OSlCBLXMopSr9YA== From: "Paz Pentelka" To: X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 08:40:15 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC34FC.747BE072 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Authors, =20 Following review of "draft-ietf-l2vpn-vpls-ldp-mac-opt-04.txt " I have a couple of questions/suggestions -=20 =20 1 - According to 4.1.2 Note that if a MAC Flush TLV is not understood by a receiver then it=20 may result in undesired action. For example if a MAC Flush Parameters=20 TLV is received with N=3D1 and receiver does not understand that TLV=20 then it would result in flushing of all MACs learned in the VSI=20 except the ones learned over the PW. The MAC Flush TLV SHOULD be=20 placed after the existing TLVs in MAC Flush message in [RFC4762 ]. =20 =20 =20 I would like to propose a solution to avoid the undesired flushing at PEs implementing [RFC4762] that are not supporting the new optimization - if PE-1 (according to the diagram below) can send MAC Flush Parameters TLV but doesn't send MAC Address TLV, there will not be incorrect flushing. =20 2- In a case where the primary spoke PW is down (according to the diagram below), there can be a case in which there are many other PWs connected between the 2 PEs that are down (due to physical link down for instance). In this case, is there a way to send MAC flush for different PW's/VPLS's with a single LDP MAC message (for better messaging scalability)? Such option can be defined using sub-TLVs, for example. =20 =20 PE-1 PE-3=20 +--------+ +--------+ | | | |=20 | -- | | -- | =20 Customer Site 1 | / \ |------------------| / \ |-> CE-1 /------| \ s/ | | \S / | =20 \ primary spoke PW | -- | /------| -- | =20 \ / +--------+ / +--------+ =20 \ (MTU-s)/ | \ / |=20 +--------+/ | \ / |=20 | | | \ / | =20 | -- | | \ / |=20 | / \ | | H-VPLS Full Mesh Core|=20 | \S / | | / \ |=20 | -- | | / \ | =20 /+--------+\ | / \ |=20 / backup spoke PW | / \ |=20 / \ +--------+ \--------+--------+ =20 CE-2 \ | | | | =20 Customer Site 2 \------| -- | | -- | =20 | / \ |------------------| / \ |-> | \s / | | \S / | =20 | -- | | -- | =20 +--------+ +--------+ PE-2 PE-4=20 =20 Thanks in advance, Paz. =20 ------_=_NextPart_001_01CC34FC.747BE072 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear = Authors,

Following review of “draft-ietf-l2vpn-vpls-ldp= -mac-opt-04.txt” I have a couple of = questions/suggestions -

1 - = According to 4.1.2

Note that if a MAC Flush TLV is not = understood by a receiver then it

may result in undesired action. For = example if a MAC Flush Parameters

TLV is received with = N=3D1 and receiver does not understand that TLV

then it would result in = flushing of all MACs learned in the VSI

except the ones learned = over the PW. The MAC Flush TLV SHOULD be

placed after the = existing TLVs in MAC Flush message in [RFC4762]. = ;

I would like = to propose a solution to avoid the undesired flushing at PEs = implementing [RFC4762] that are not supporting the new optimization = – if PE-1 (according to the diagram below) can send MAC Flush = Parameters TLV but doesn’t send MAC Address TLV, there will not be = incorrect flushing.

2- In a case = where the primary spoke PW is down (according to the diagram below), = there can be a case in which there are many other PWs connected between = the 2 PEs that are down (due to physical link down for instance). In = this case, is there a way to send MAC flush for different = PW’s/VPLS’s with a single LDP MAC message (for better = messaging scalability)? Such option can be defined using sub-TLVs, for = example.

     =
;            =
            &=
nbsp;   =
PE-1           &nb=
sp;           &nbs=
p; PE-3 =

        &nb=
sp;           &nbs=
p;          +--------+&=
nbsp;           &n=
bsp;     =
+--------+          &nb=
sp; =

        &nb=
sp;           &nbs=
p;          | &nbs=
p;      =
|            =
      =
|        | =

        &nb=
sp;           &nbs=
p;          | &nbs=
p; --   =
|            =
      |   --   |  =

   Customer Site =
1        =
     |  /  \  =
|------------------|  /  \  |->  =

     CE-1   =
;            =
/------|  \ s/  =
|            =
      |  \S /  |  =

       \ &n=
bsp;   primary spoke PW  |   --   =
|           =
/------|   --   |  =

        \&n=
bsp;            =
/        =
+--------+          =
/       +--------+  =

        &nb=
sp;\    =
(MTU-s)/           =
;   |    =
\        =
/            =
 | =

        &nb=
sp; +--------+/         =
;      |     =
\      =
/            =
  | =

        &nb=
sp; |        =
|            =
    |      \    =
/            =
   |  =

        &nb=
sp; |   --   =
|            =
    |       \  =
/            =
    | =

        &nb=
sp; |  /  \  =
|            =
    |      H-VPLS Full Mesh =
Core| =

        &nb=
sp; |  \S /  =
|            =
    |       / =
\            =
     | =

        &nb=
sp; |   --   =
|            =
    |      /   =
\            =
    |  =

        &nb=
sp;/+--------+\       =
        |    =
 /     =
\            =
   | =

        /&n=
bsp;    backup spoke =
PW       |    =
/       =
\            =
  | =

       / &n=
bsp;            =
\        =
+--------+         =
\--------+--------+  =

      CE-2  =
;           =
\       =
|        =
|            =
      =
|        |  =

   Customer Site =
2      \------|  --    =
|            =
      |  --    |  =

        &nb=
sp;           &nbs=
p;          | /  =
\   |------------------| /  \   |->  =

        &nb=
sp;           &nbs=
p;          | \s =
/   =
|            =
      | \S /   |  =

        &nb=
sp;           &nbs=
p;          |  =
--    |   =
            &=
nbsp;  |  --    |  =

        &nb=
sp;           &nbs=
p;          +--------+&=
nbsp;           &n=
bsp;     =
+--------+           =

        &nb=
sp;           &nbs=
p;            =
;PE-2           &n=
bsp;           &nb=
sp; PE-4

Thanks in =
advance,

Paz.

------_=_NextPart_001_01CC34FC.747BE072-- From chen.ran@zte.com.cn Wed Jun 29 01:55:37 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1A69E802F for ; Wed, 29 Jun 2011 01:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.485 X-Spam-Level: X-Spam-Status: No, score=-99.485 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, MIME_BASE64_TEXT=1.753, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJ4sUZyXGdho for ; Wed, 29 Jun 2011 01:55:36 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 7EDD4228018 for ; Wed, 29 Jun 2011 01:55:35 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 4864577109098; Wed, 29 Jun 2011 16:52:09 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 51452.577109098; Wed, 29 Jun 2011 16:55:19 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p5T8tHQ3007488 for ; Wed, 29 Jun 2011 16:55:17 +0800 (GMT-8) (envelope-from chen.ran@zte.com.cn) To: l2vpn@ietf.org Subject: Re: Questions/suggestions regarding "draft-ietf-l2vpn-vpls-ldp-mac-opt-04.txt" (Paz Pentelka) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: chen.ran@zte.com.cn Date: Wed, 29 Jun 2011 16:55:09 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-06-29 16:55:18, Serialize complete at 2011-06-29 16:55:18 Content-Type: multipart/alternative; boundary="=_alternative 0030D05C482578BE_=" X-MAIL: mse01.zte.com.cn p5T8tHQ3007488 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 08:55:37 -0000 This is a multipart message in MIME format. --=_alternative 0030D05C482578BE_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgYWxso6wNClBsZWFzZSBzZWUgdGhlIGNvbW1lbnRzIGlubGluZSBiZWxvdy4NCg0KUmVnYXJk cywNClJhbg0KDQpsMnZwbi1yZXF1ZXN0QGlldGYub3JnIA0KU2VudCBieTogbDJ2cG4tYm91bmNl c0BpZXRmLm9yZw0KMjAxMS0wNi0yOSAwMzowMA0KUGxlYXNlIHJlc3BvbmQgdG8NCmwydnBuQGll dGYub3JnDQoNCg0KVG8NCmwydnBuQGlldGYub3JnDQpjYw0KDQpTdWJqZWN0DQpMMnZwbiBEaWdl c3QsIFZvbCA4NSwgSXNzdWUgMTQNCg0KDQoNCg0KDQoNCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgZGlnZXN0IHdpdGhvdXQgYWxsIHRoZSBpbmRpdmlkdWFsIG1lc3NhZ2UNCmF0dGFjaG1lbnRz IHlvdSB3aWxsIG5lZWQgdG8gdXBkYXRlIHlvdXIgZGlnZXN0IG9wdGlvbnMgaW4geW91ciBsaXN0 DQpzdWJzY3JpcHRpb24uICBUbyBkbyBzbywgZ28gdG8gDQoNCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbDJ2cG4NCg0KQ2xpY2sgdGhlICdVbnN1YnNjcmliZSBvciBlZGl0 IG9wdGlvbnMnIGJ1dHRvbiwgbG9nIGluLCBhbmQgc2V0ICJHZXQNCk1JTUUgb3IgUGxhaW4gVGV4 dCBEaWdlc3RzPyIgdG8gTUlNRS4gIFlvdSBjYW4gc2V0IHRoaXMgb3B0aW9uDQpnbG9iYWxseSBm b3IgYWxsIHRoZSBsaXN0IGRpZ2VzdHMgeW91IHJlY2VpdmUgYXQgdGhpcyBwb2ludC4NCg0KDQoN ClNlbmQgTDJ2cG4gbWFpbGluZyBsaXN0IHN1Ym1pc3Npb25zIHRvDQogICAgICAgICAgICAgICAg IGwydnBuQGlldGYub3JnDQoNClRvIHN1YnNjcmliZSBvciB1bnN1YnNjcmliZSB2aWEgdGhlIFdv cmxkIFdpZGUgV2ViLCB2aXNpdA0KICAgICAgICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2wydnBuDQpvciwgdmlhIGVtYWlsLCBzZW5kIGEgbWVzc2FnZSB3 aXRoIHN1YmplY3Qgb3IgYm9keSAnaGVscCcgdG8NCiAgICAgICAgICAgICAgICAgbDJ2cG4tcmVx dWVzdEBpZXRmLm9yZw0KDQpZb3UgY2FuIHJlYWNoIHRoZSBwZXJzb24gbWFuYWdpbmcgdGhlIGxp c3QgYXQNCiAgICAgICAgICAgICAgICAgbDJ2cG4tb3duZXJAaWV0Zi5vcmcNCg0KV2hlbiByZXBs eWluZywgcGxlYXNlIGVkaXQgeW91ciBTdWJqZWN0IGxpbmUgc28gaXQgaXMgbW9yZSBzcGVjaWZp Yw0KdGhhbiAiUmU6IENvbnRlbnRzIG9mIEwydnBuIGRpZ2VzdC4uLiINCg0KDQpUb2RheSdzIFRv cGljczoNCg0KICAgMS4gUXVlc3Rpb25zL3N1Z2dlc3Rpb25zIHJlZ2FyZGluZw0KICAgICAgImRy YWZ0LWlldGYtbDJ2cG4tdnBscy1sZHAtbWFjLW9wdC0wNC50eHQiIChQYXogUGVudGVsa2EpDQoN Cg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KDQpNZXNzYWdlOiAxDQpEYXRlOiBNb24sIDI3IEp1biAyMDExIDIy OjAwOjE2ICswMzAwDQpGcm9tOiAiUGF6IFBlbnRlbGthIiA8UGF6UEBvcmNraXQuY29tPg0KVG86 IDxMMnZwbkBpZXRmLm9yZz4NClN1YmplY3Q6IFF1ZXN0aW9ucy9zdWdnZXN0aW9ucyByZWdhcmRp bmcNCiAgICAgICAgICAgICAgICAgImRyYWZ0LWlldGYtbDJ2cG4tdnBscy1sZHAtbWFjLW9wdC0w NC50eHQiDQpNZXNzYWdlLUlEOiA8NDRGNEU1NzlBNzY0NTg0RUE5QkRGRDA3RDBDQTA4MTMwNkQ1 RkRGOUB0bHZtYWlsMT4NCkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD0idXMtYXNj aWkiDQoNCkRlYXIgQXV0aG9ycywNCg0KIA0KDQpGb2xsb3dpbmcgcmV2aWV3IG9mICJkcmFmdC1p ZXRmLWwydnBuLXZwbHMtbGRwLW1hYy1vcHQtMDQudHh0DQo8aHR0cDovL3BvdGFyb28ubmV0L2ll dGYvaWRyZWYvZHJhZnQtaWV0Zi1sMnZwbi12cGxzLWxkcC1tYWMtb3B0L3JmY21hcmsNCnVwP3Jl cG9zaXRvcnk9L2F3YXkvaWV0ZiZ1cmw9L2F3YXkvaWV0Zi9hbGwtaWRzL2RyYWZ0LWlldGYtbDJ2 cG4tdnBscy1sZA0KcC1tYWMtb3B0LTA0LnR4dD4gIiBJIGhhdmUgYSBjb3VwbGUgb2YgcXVlc3Rp b25zL3N1Z2dlc3Rpb25zIC0gDQoNCiANCg0KMSAtIEFjY29yZGluZyB0byA0LjEuMg0KDQpOb3Rl IHRoYXQgaWYgYSBNQUMgRmx1c2ggVExWIGlzIG5vdCB1bmRlcnN0b29kIGJ5IGEgcmVjZWl2ZXIg dGhlbiBpdCANCg0KbWF5IHJlc3VsdCBpbiB1bmRlc2lyZWQgYWN0aW9uLiBGb3IgZXhhbXBsZSBp ZiBhIE1BQyBGbHVzaCBQYXJhbWV0ZXJzIA0KDQpUTFYgaXMgcmVjZWl2ZWQgd2l0aCBOPTEgYW5k IHJlY2VpdmVyIGRvZXMgbm90IHVuZGVyc3RhbmQgdGhhdCBUTFYgDQoNCnRoZW4gaXQgd291bGQg cmVzdWx0IGluIGZsdXNoaW5nIG9mIGFsbCBNQUNzIGxlYXJuZWQgaW4gdGhlIFZTSSANCg0KZXhj ZXB0IHRoZSBvbmVzIGxlYXJuZWQgb3ZlciB0aGUgUFcuIFRoZSBNQUMgRmx1c2ggVExWIFNIT1VM RCBiZSANCg0KcGxhY2VkIGFmdGVyIHRoZSBleGlzdGluZyBUTFZzIGluIE1BQyBGbHVzaCBtZXNz YWdlIGluIFtSRkM0NzYyDQo8aHR0cDovL3BvdGFyb28ubmV0L2lldGYvaWRyZWYvZHJhZnQtaWV0 Zi1sMnZwbi12cGxzLWxkcC1tYWMtb3B0LyNyZWYtUkYNCkM0NzYyPiBdLiANCg0KIA0KDQogDQoN Ckkgd291bGQgbGlrZSB0byBwcm9wb3NlIGEgc29sdXRpb24gdG8gYXZvaWQgdGhlIHVuZGVzaXJl ZCBmbHVzaGluZyBhdA0KUEVzIGltcGxlbWVudGluZyBbUkZDNDc2Ml0gdGhhdCBhcmUgbm90IHN1 cHBvcnRpbmcgdGhlIG5ldyBvcHRpbWl6YXRpb24NCi0gaWYgUEUtMSAoYWNjb3JkaW5nIHRvIHRo ZSBkaWFncmFtIGJlbG93KSBjYW4gc2VuZCBNQUMgRmx1c2ggUGFyYW1ldGVycw0KVExWIGJ1dCBk b2Vzbid0IHNlbmQgTUFDIEFkZHJlc3MgVExWLCB0aGVyZSB3aWxsIG5vdCBiZSBpbmNvcnJlY3QN CmZsdXNoaW5nLg0KDQpbUmFuXUkgdGhpbmsgd2Ugc2hvdWxkIGNhcnJ5IHRoZSBNQUMgYWRkcmVz cyBUTFYgaW4gdGhlIE1BQyBGbHVzaCANClBhcmVtZXRlcnMuDQpBY3R1YWxseSBkcmFmdC1pZXRm LWwydnBuLXZwbHMtbGRwLW1hYy1vcHQtMDQgc3RhdGVzOlRoZSBNQUMgRmx1c2ggVExWIA0KU0hP VUxEIGJlDQpwbGFjZWQgYWZ0ZXIgdGhlIGV4aXN0aW5nIFRMVnMgaW4gTUFDIEZsdXNoIG1lc3Nh Z2UgaW4gW1JGQzQ3NjJdLg0KTWF5YmUgd2UgY2FuIHVzZSBhIExEUCBjYXBhYmlsaXR5IG1lY2hu aXNtIHRvIHNsb3ZlIHRoaXMgcHJvYnJlbS4NCg0KDQoyLSBJbiBhIGNhc2Ugd2hlcmUgdGhlIHBy aW1hcnkgc3Bva2UgUFcgaXMgZG93biAoYWNjb3JkaW5nIHRvIHRoZQ0KZGlhZ3JhbSBiZWxvdyks IHRoZXJlIGNhbiBiZSBhIGNhc2UgaW4gd2hpY2ggdGhlcmUgYXJlIG1hbnkgb3RoZXIgUFdzDQpj b25uZWN0ZWQgYmV0d2VlbiB0aGUgMiBQRXMgdGhhdCBhcmUgZG93biAoZHVlIHRvIHBoeXNpY2Fs IGxpbmsgZG93biBmb3INCmluc3RhbmNlKS4gSW4gdGhpcyBjYXNlLCBpcyB0aGVyZSBhIHdheSB0 byBzZW5kIE1BQyBmbHVzaCBmb3IgZGlmZmVyZW50DQpQVydzL1ZQTFMncyB3aXRoIGEgc2luZ2xl IExEUCBNQUMgbWVzc2FnZSAoZm9yIGJldHRlciBtZXNzYWdpbmcNCnNjYWxhYmlsaXR5KT8gU3Vj aCBvcHRpb24gY2FuIGJlIGRlZmluZWQgdXNpbmcgc3ViLVRMVnMsIGZvciBleGFtcGxlLg0KW1Jh bl0gIElNTywgaW4gdGhpcyBjYXNlLCBpdCBjYW4gYmUgYWNoaXZlZCBieSBjYXJyaW5nIG11dGkt RkVDIHRsdiBpbiB0aGUgDQpNQUMgZmx1c2ggbWVzc2FnZS4NCiANCg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgUEUtMSAgICAgICAgICAgICAgICAgICAgICAgICBQRS0zIA0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLSsgICAgICAgICAgICAgICAgICAr LS0tLS0tLS0rDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICB8ICAg ICAgICAgICAgICAgICAgfCAgICAgICAgfCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8ICAgLS0gICB8ICAgICAgICAgICAgICAgICAgfCAgIC0tICAgfCANCiAgIEN1c3RvbWVyIFNp dGUgMSAgICAgICAgICAgICB8ICAvICBcICB8LS0tLS0tLS0tLS0tLS0tLS0tfCAgLyAgXCAgfC0+ DQoNCiAgICAgQ0UtMSAgICAgICAgICAgICAgIC8tLS0tLS18ICBcIHMvICB8ICAgICAgICAgICAg ICAgICAgfCAgXFMgLyAgfCANCiAgICAgICBcICAgICBwcmltYXJ5IHNwb2tlIFBXICB8ICAgLS0g ICB8ICAgICAgICAgICAvLS0tLS0tfCAgIC0tICAgfCANCiAgICAgICAgXCAgICAgICAgICAgICAv ICAgICAgICArLS0tLS0tLS0rICAgICAgICAgIC8gICAgICAgKy0tLS0tLS0tKyANCiAgICAgICAg IFwgICAgKE1UVS1zKS8gICAgICAgICAgICAgIHwgICAgXCAgICAgICAgLyAgICAgICAgICAgICB8 IA0KICAgICAgICAgICstLS0tLS0tLSsvICAgICAgICAgICAgICAgfCAgICAgXCAgICAgIC8gICAg ICAgICAgICAgIHwgDQogICAgICAgICAgfCAgICAgICAgfCAgICAgICAgICAgICAgICB8ICAgICAg XCAgICAvICAgICAgICAgICAgICAgfCANCiAgICAgICAgICB8ICAgLS0gICB8ICAgICAgICAgICAg ICAgIHwgICAgICAgXCAgLyAgICAgICAgICAgICAgICB8IA0KICAgICAgICAgIHwgIC8gIFwgIHwg ICAgICAgICAgICAgICAgfCAgICAgIEgtVlBMUyBGdWxsIE1lc2ggQ29yZXwgDQogICAgICAgICAg fCAgXFMgLyAgfCAgICAgICAgICAgICAgICB8ICAgICAgIC8gXCAgICAgICAgICAgICAgICAgfCAN CiAgICAgICAgICB8ICAgLS0gICB8ICAgICAgICAgICAgICAgIHwgICAgICAvICAgXCAgICAgICAg ICAgICAgICB8IA0KICAgICAgICAgLystLS0tLS0tLStcICAgICAgICAgICAgICAgfCAgICAgLyAg ICAgXCAgICAgICAgICAgICAgIHwgDQogICAgICAgIC8gICAgIGJhY2t1cCBzcG9rZSBQVyAgICAg ICB8ICAgIC8gICAgICAgXCAgICAgICAgICAgICAgfCANCiAgICAgICAvICAgICAgICAgICAgICBc ICAgICAgICArLS0tLS0tLS0rICAgICAgICAgXC0tLS0tLS0tKy0tLS0tLS0tKyANCiAgICAgIENF LTIgICAgICAgICAgICAgXCAgICAgICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICAgfCAgICAg ICAgfCANCiAgIEN1c3RvbWVyIFNpdGUgMiAgICAgIFwtLS0tLS18ICAtLSAgICB8ICAgICAgICAg ICAgICAgICAgfCAgLS0gICAgfCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IC8g IFwgICB8LS0tLS0tLS0tLS0tLS0tLS0tfCAvICBcICAgfC0+DQoNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8IFxzIC8gICB8ICAgICAgICAgICAgICAgICAgfCBcUyAvICAgfCANCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAtLSAgICB8ICAgICAgICAgICAgICAgICAg fCAgLS0gICAgfCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0rICAg ICAgICAgICAgICAgICAgKy0tLS0tLS0tKw0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBQRS0yICAgICAgICAgICAgICAgICAgICAgICAgIFBFLTQgDQogDQpUaGFua3MgaW4gYWR2 YW5jZSwNClBhei4NCg0KIA0KDQotLS0tLS0tLS0tLS0tLSBuZXh0IHBhcnQgLS0tLS0tLS0tLS0t LS0NCkFuIEhUTUwgYXR0YWNobWVudCB3YXMgc2NydWJiZWQuLi4NClVSTDogPA0KaHR0cDovL3d3 dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2wydnBuL2F0dGFjaG1lbnRzLzIwMTEwNjI3Lzgy YzVhYmUxL2F0dGFjaG1lbnQuaHRtDQo+DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTDJ2 cG4gbWFpbGluZyBsaXN0DQpMMnZwbkBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9sMnZwbg0KDQoNCkVuZCBvZiBMMnZwbiBEaWdlc3QsIFZvbCA4NSwgSXNz dWUgMTQNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0KDQo= --=_alternative 0030D05C482578BE_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8cD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZT48dHQ+SGkgYWxso6w8L3R0PjwvZm9udD4NCjxw Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlPjx0dD5QbGVhc2Ugc2VlIHRoZSBjb21tZW50cyBpbmxp bmUgYmVsb3cuPC90dD48L2ZvbnQ+DQo8cD4NCjxwPjxmb250IHNpemU9MiBjb2xvcj1ibHVlPjx0 dD5SZWdhcmRzLDwvdHQ+PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWU+PHR0PlJh bjwvdHQ+PC9mb250Pjxmb250IHNpemU9Mj48dHQ+PGJyPg0KPC90dD48L2ZvbnQ+DQo8dGFibGUg d2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM1JT48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+PGI+bDJ2cG4tcmVxdWVzdEBpZXRmLm9yZzwvYj4NCjwvZm9udD4N Cjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+U2VudCBieTogbDJ2cG4tYm91bmNl c0BpZXRmLm9yZzwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDEx LTA2LTI5IDAzOjAwPC9mb250Pg0KPHRhYmxlIGJvcmRlcj4NCjx0ciB2YWxpZ249dG9wPg0KPHRk IGJnY29sb3I9d2hpdGU+DQo8ZGl2IGFsaWduPWNlbnRlcj48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+UGxlYXNlIHJlc3BvbmQgdG88YnI+DQpsMnZwbkBpZXRmLm9yZzwvZm9udD48L2Rp dj48L3RhYmxlPg0KPGJyPg0KPHRkIHdpZHRoPTY0JT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRy IHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj5UbzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+bDJ2cG5AaWV0Zi5vcmc8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYg YWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPmNjPC9mb250PjwvZGl2 Pg0KPHRkPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj5TdWJqZWN0PC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj5MMnZwbiBEaWdlc3QsIFZvbCA4NSwgSXNzdWUgMTQ8L2Zv bnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwv dGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTI+PHR0Pklm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZGlnZXN0IHdpdGhvdXQgYWxsIHRoZSBpbmRpdmlkdWFs DQptZXNzYWdlPGJyPg0KYXR0YWNobWVudHMgeW91IHdpbGwgbmVlZCB0byB1cGRhdGUgeW91ciBk aWdlc3Qgb3B0aW9ucyBpbiB5b3VyIGxpc3Q8YnI+DQpzdWJzY3JpcHRpb24uICZuYnNwO1RvIGRv IHNvLCBnbyB0byA8YnI+DQo8YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2wydnBuPGJyPg0KPGJyPg0KQ2xpY2sgdGhlICdVbnN1YnNjcmliZSBvciBlZGl0IG9wdGlv bnMnIGJ1dHRvbiwgbG9nIGluLCBhbmQgc2V0ICZxdW90O0dldDxicj4NCk1JTUUgb3IgUGxhaW4g VGV4dCBEaWdlc3RzPyZxdW90OyB0byBNSU1FLiAmbmJzcDtZb3UgY2FuIHNldCB0aGlzIG9wdGlv bjxicj4NCmdsb2JhbGx5IGZvciBhbGwgdGhlIGxpc3QgZGlnZXN0cyB5b3UgcmVjZWl2ZSBhdCB0 aGlzIHBvaW50Ljxicj4NCjxicj4NCjxicj4NCjxicj4NClNlbmQgTDJ2cG4gbWFpbGluZyBsaXN0 IHN1Ym1pc3Npb25zIHRvPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsNCmwydnBuQGlldGYub3JnPGJyPg0KPGJyPg0KVG8gc3Vic2Ny aWJlIG9yIHVuc3Vic2NyaWJlIHZpYSB0aGUgV29ybGQgV2lkZSBXZWIsIHZpc2l0PGJyPg0KICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbDJ2cG48YnI+DQpvciwgdmlhIGVt YWlsLCBzZW5kIGEgbWVzc2FnZSB3aXRoIHN1YmplY3Qgb3IgYm9keSAnaGVscCcgdG88YnI+DQog Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0K bDJ2cG4tcmVxdWVzdEBpZXRmLm9yZzxicj4NCjxicj4NCllvdSBjYW4gcmVhY2ggdGhlIHBlcnNv biBtYW5hZ2luZyB0aGUgbGlzdCBhdDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpsMnZwbi1vd25lckBpZXRmLm9yZzxicj4NCjxi cj4NCldoZW4gcmVwbHlpbmcsIHBsZWFzZSBlZGl0IHlvdXIgU3ViamVjdCBsaW5lIHNvIGl0IGlz IG1vcmUgc3BlY2lmaWM8YnI+DQp0aGFuICZxdW90O1JlOiBDb250ZW50cyBvZiBMMnZwbiBkaWdl c3QuLi4mcXVvdDs8YnI+DQo8YnI+DQo8YnI+DQpUb2RheSdzIFRvcGljczo8YnI+DQo8YnI+DQog Jm5ic3A7IDEuIFF1ZXN0aW9ucy9zdWdnZXN0aW9ucyByZWdhcmRpbmc8YnI+DQogJm5ic3A7ICZu YnNwOyAmbmJzcDsmcXVvdDtkcmFmdC1pZXRmLWwydnBuLXZwbHMtbGRwLW1hYy1vcHQtMDQudHh0 JnF1b3Q7DQooUGF6IFBlbnRlbGthKTxicj4NCjxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+ DQo8YnI+DQpNZXNzYWdlOiAxPGJyPg0KRGF0ZTogTW9uLCAyNyBKdW4gMjAxMSAyMjowMDoxNiAr MDMwMDxicj4NCkZyb206ICZxdW90O1BheiBQZW50ZWxrYSZxdW90OyAmbHQ7UGF6UEBvcmNraXQu Y29tJmd0Ozxicj4NClRvOiAmbHQ7TDJ2cG5AaWV0Zi5vcmcmZ3Q7PGJyPg0KU3ViamVjdDogUXVl c3Rpb25zL3N1Z2dlc3Rpb25zIHJlZ2FyZGluZzxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQomcXVvdDtkcmFmdC1pZXRmLWwydnBu LXZwbHMtbGRwLW1hYy1vcHQtMDQudHh0JnF1b3Q7PGJyPg0KTWVzc2FnZS1JRDogJmx0OzQ0RjRF NTc5QTc2NDU4NEVBOUJERkQwN0QwQ0EwODEzMDZENUZERjlAdGx2bWFpbDEmZ3Q7PGJyPg0KQ29u dGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PSZxdW90O3VzLWFzY2lpJnF1b3Q7PGJyPg0K PGJyPg0KRGVhciBBdXRob3JzLDxicj4NCjxicj4NCiA8YnI+DQo8YnI+DQpGb2xsb3dpbmcgcmV2 aWV3IG9mICZxdW90O2RyYWZ0LWlldGYtbDJ2cG4tdnBscy1sZHAtbWFjLW9wdC0wNC50eHQ8YnI+ DQombHQ7aHR0cDovL3BvdGFyb28ubmV0L2lldGYvaWRyZWYvZHJhZnQtaWV0Zi1sMnZwbi12cGxz LWxkcC1tYWMtb3B0L3JmY21hcms8YnI+DQp1cD9yZXBvc2l0b3J5PS9hd2F5L2lldGYmYW1wO3Vy bD0vYXdheS9pZXRmL2FsbC1pZHMvZHJhZnQtaWV0Zi1sMnZwbi12cGxzLWxkPGJyPg0KcC1tYWMt b3B0LTA0LnR4dCZndDsgJnF1b3Q7IEkgaGF2ZSBhIGNvdXBsZSBvZiBxdWVzdGlvbnMvc3VnZ2Vz dGlvbnMgLQ0KPGJyPg0KPGJyPg0KIDxicj4NCjxicj4NCjEgLSBBY2NvcmRpbmcgdG8gNC4xLjI8 YnI+DQo8YnI+DQpOb3RlIHRoYXQgaWYgYSBNQUMgRmx1c2ggVExWIGlzIG5vdCB1bmRlcnN0b29k IGJ5IGEgcmVjZWl2ZXIgdGhlbiBpdCA8YnI+DQo8YnI+DQptYXkgcmVzdWx0IGluIHVuZGVzaXJl ZCBhY3Rpb24uIEZvciBleGFtcGxlIGlmIGEgTUFDIEZsdXNoIFBhcmFtZXRlcnMgPGJyPg0KPGJy Pg0KVExWIGlzIHJlY2VpdmVkIHdpdGggTj0xIGFuZCByZWNlaXZlciBkb2VzIG5vdCB1bmRlcnN0 YW5kIHRoYXQgVExWIDxicj4NCjxicj4NCnRoZW4gaXQgd291bGQgcmVzdWx0IGluIGZsdXNoaW5n IG9mIGFsbCBNQUNzIGxlYXJuZWQgaW4gdGhlIFZTSSA8YnI+DQo8YnI+DQpleGNlcHQgdGhlIG9u ZXMgbGVhcm5lZCBvdmVyIHRoZSBQVy4gVGhlIE1BQyBGbHVzaCBUTFYgU0hPVUxEIGJlIDxicj4N Cjxicj4NCnBsYWNlZCBhZnRlciB0aGUgZXhpc3RpbmcgVExWcyBpbiBNQUMgRmx1c2ggbWVzc2Fn ZSBpbiBbUkZDNDc2Mjxicj4NCiZsdDtodHRwOi8vcG90YXJvby5uZXQvaWV0Zi9pZHJlZi9kcmFm dC1pZXRmLWwydnBuLXZwbHMtbGRwLW1hYy1vcHQvI3JlZi1SRjxicj4NCkM0NzYyJmd0OyBdLiAm bmJzcDsgPGJyPg0KPGJyPg0KIDxicj4NCjxicj4NCiA8YnI+DQo8YnI+DQpJIHdvdWxkIGxpa2Ug dG8gcHJvcG9zZSBhIHNvbHV0aW9uIHRvIGF2b2lkIHRoZSB1bmRlc2lyZWQgZmx1c2hpbmcgYXQ8 YnI+DQpQRXMgaW1wbGVtZW50aW5nIFtSRkM0NzYyXSB0aGF0IGFyZSBub3Qgc3VwcG9ydGluZyB0 aGUgbmV3IG9wdGltaXphdGlvbjxicj4NCi0gaWYgUEUtMSAoYWNjb3JkaW5nIHRvIHRoZSBkaWFn cmFtIGJlbG93KSBjYW4gc2VuZCBNQUMgRmx1c2ggUGFyYW1ldGVyczxicj4NClRMViBidXQgZG9l c24ndCBzZW5kIE1BQyBBZGRyZXNzIFRMViwgdGhlcmUgd2lsbCBub3QgYmUgaW5jb3JyZWN0PGJy Pg0KZmx1c2hpbmcuPGJyPg0KPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJs dWU+PHR0PltSYW5dSSB0aGluayB3ZSBzaG91bGQgY2FycnkgdGhlIE1BQyBhZGRyZXNzDQpUTFYg aW4gdGhlIE1BQyBGbHVzaCBQYXJlbWV0ZXJzLjwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBjb2xvcj1ibHVlPjx0dD5BY3R1YWxseSBkcmFmdC1pZXRmLWwydnBuLXZwbHMtbGRwLW1hYy1v cHQtMDQNCnN0YXRlczpUaGUgTUFDIEZsdXNoIFRMViBTSE9VTEQgYmU8YnI+DQpwbGFjZWQgYWZ0 ZXIgdGhlIGV4aXN0aW5nIFRMVnMgaW4gTUFDIEZsdXNoIG1lc3NhZ2UgaW4gWzwvdHQ+PC9mb250 PjxhIGhyZWY9aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDc2Mj48Zm9udCBzaXplPTIg Y29sb3I9Ymx1ZT48dHQ+PHU+UkZDNDc2MjwvdT48L3R0PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0y IGNvbG9yPWJsdWU+PHR0Pl0uPGJyPg0KTWF5YmUgd2UgY2FuIHVzZSBhIExEUCBjYXBhYmlsaXR5 IG1lY2huaXNtIHRvIHNsb3ZlIHRoaXMgcHJvYnJlbS48L3R0PjwvZm9udD4NCjxicj4NCjxicj48 Zm9udCBzaXplPTI+PHR0Pjxicj4NCjItIEluIGEgY2FzZSB3aGVyZSB0aGUgcHJpbWFyeSBzcG9r ZSBQVyBpcyBkb3duIChhY2NvcmRpbmcgdG8gdGhlPGJyPg0KZGlhZ3JhbSBiZWxvdyksIHRoZXJl IGNhbiBiZSBhIGNhc2UgaW4gd2hpY2ggdGhlcmUgYXJlIG1hbnkgb3RoZXIgUFdzPGJyPg0KY29u bmVjdGVkIGJldHdlZW4gdGhlIDIgUEVzIHRoYXQgYXJlIGRvd24gKGR1ZSB0byBwaHlzaWNhbCBs aW5rIGRvd24gZm9yPGJyPg0KaW5zdGFuY2UpLiBJbiB0aGlzIGNhc2UsIGlzIHRoZXJlIGEgd2F5 IHRvIHNlbmQgTUFDIGZsdXNoIGZvciBkaWZmZXJlbnQ8YnI+DQpQVydzL1ZQTFMncyB3aXRoIGEg c2luZ2xlIExEUCBNQUMgbWVzc2FnZSAoZm9yIGJldHRlciBtZXNzYWdpbmc8YnI+DQpzY2FsYWJp bGl0eSk/IFN1Y2ggb3B0aW9uIGNhbiBiZSBkZWZpbmVkIHVzaW5nIHN1Yi1UTFZzLCBmb3IgZXhh bXBsZS48YnI+DQo8L3R0PjwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZT48dHQ+W1Jhbl0g Jm5ic3A7SU1PLCBpbiB0aGlzIGNhc2UsDQo8L3R0PjwvZm9udD48Zm9udCBzaXplPTEgY29sb3I9 Ymx1ZT5pdCBjYW4gYmUgYWNoaXZlZCBieSBjYXJyaW5nIG11dGktRkVDDQp0bHYgaW4gdGhlIE1B QyBmbHVzaCBtZXNzYWdlLjwvZm9udD48Zm9udCBzaXplPTI+PHR0Pjxicj4NCiA8YnI+DQo8YnI+ DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBQRS0xICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBQRS0zIDxicj4NCiAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgKy0tLS0tLS0tKyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsr LS0tLS0tLS0rPGJyPg0KPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJz cDsgJm5ic3A7DQombmJzcDsgJm5ic3A7fCA8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7IC0tICZuYnNwOyB8ICZuYnNwOyAmbmJz cDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5i c3A7IC0tICZuYnNwOyB8ICZuYnNwOzxicj4NCiAmbmJzcDsgQ3VzdG9tZXIgU2l0ZSAxICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7Lw0KJm5ic3A7XCAm bmJzcDt8LS0tLS0tLS0tLS0tLS0tLS0tfCAmbmJzcDsvICZuYnNwO1wgJm5ic3A7fC0mZ3Q7PGJy Pg0KPGJyPg0KICZuYnNwOyAmbmJzcDsgQ0UtMSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgLy0tLS0tLXwNCiZuYnNwO1wgcy8gJm5ic3A7fCAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDt8 ICZuYnNwO1xTIC8gJm5ic3A7fCAmbmJzcDs8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgXCAm bmJzcDsgJm5ic3A7IHByaW1hcnkgc3Bva2UgUFcgJm5ic3A7fCAmbmJzcDsgLS0NCiZuYnNwOyB8 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgLy0tLS0tLXwgJm5ic3A7IC0tICZu YnNwOyB8DQombmJzcDs8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7XCAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KLyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsrLS0tLS0tLS0rICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsvDQom bmJzcDsgJm5ic3A7ICZuYnNwOyArLS0tLS0tLS0rICZuYnNwOzxicj4NCiAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgXCAmbmJzcDsgJm5ic3A7KE1UVS1zKS8gJm5ic3A7ICZuYnNwOyAmbmJz cDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwO1wgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7Lw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgfCA8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOystLS0tLS0t LSsvICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAm bmJzcDsgJm5ic3A7IFwgJm5ic3A7ICZuYnNwOyAmbmJzcDsvICZuYnNwOyAmbmJzcDsNCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8IDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOw0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5i c3A7ICZuYnNwO1wNCiZuYnNwOyAmbmJzcDsvICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOzxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7fCAmbmJzcDsgLS0gJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFwg Jm5ic3A7LyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO3wgPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNw Oy8gJm5ic3A7XCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwO0gtVlBMUyBGdWxsDQpNZXNo IENvcmV8IDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDtc UyAvICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC8gXCAmbmJzcDsgJm5ic3A7DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8IDxicj4NCiAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgLS0gJm5ic3A7IHwgJm5ic3A7ICZuYnNw OyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJz cDsgJm5ic3A7LyAmbmJzcDsgXCAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAvKy0tLS0tLS0tK1wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5i c3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgLyAmbmJzcDsgJm5ic3A7IFwgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyB8IDxicj4NCiAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsvICZuYnNwOyAmbmJzcDsgYmFja3VwIHNwb2tlIFBXICZuYnNwOyAm bmJzcDsNCiZuYnNwOyB8ICZuYnNwOyAmbmJzcDsvICZuYnNwOyAmbmJzcDsgJm5ic3A7IFwgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwO3wgPGJyPg0KICZu YnNwOyAmbmJzcDsgJm5ic3A7IC8gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7XA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Ky0tLS0tLS0tKyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgXC0tLS0tLS0tKy0tLS0tLS0tKw0KJm5ic3A7PGJyPg0K ICZuYnNwOyAmbmJzcDsgJm5ic3A7Q0UtMiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBcICZuYnNwOw0KJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOzxicj4N CiAmbmJzcDsgQ3VzdG9tZXIgU2l0ZSAyICZuYnNwOyAmbmJzcDsgJm5ic3A7XC0tLS0tLXwgJm5i c3A7LS0gJm5ic3A7ICZuYnNwO3wNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDstLQ0KJm5ic3A7ICZuYnNwO3wgJm5i c3A7PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyB8IC8gJm5ic3A7XCAmbmJzcDsgfC0tLS0tLS0tLS0tLS0tLS0tLXwNCi8gJm5ic3A7XCAmbmJz cDsgfC0mZ3Q7PGJyPg0KPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyB8IFxzIC8gJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCBcUyAvICZuYnNwOyB8ICZuYnNw Ozxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg fCAmbmJzcDstLSAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOy0tICZuYnNwOyAmbmJzcDt8 DQombmJzcDs8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICstLS0tLS0tLSsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Ky0tLS0tLS0tKzxicj4NCjxicj4NCiAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFBFLTIgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFBFLTQgPGJyPg0KIDxicj4NClRoYW5rcyBpbiBhZHZhbmNl LDxicj4NClBhei48YnI+DQo8YnI+DQogPGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0tLS0gbmV4dCBw YXJ0IC0tLS0tLS0tLS0tLS0tPGJyPg0KQW4gSFRNTCBhdHRhY2htZW50IHdhcyBzY3J1YmJlZC4u Ljxicj4NClVSTDogJmx0O2h0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9sMnZw bi9hdHRhY2htZW50cy8yMDExMDYyNy84MmM1YWJlMS9hdHRhY2htZW50Lmh0bSZndDs8YnI+DQo8 YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQo8YnI+DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkwydnBuIG1haWxpbmcg bGlzdDxicj4NCkwydnBuQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9sMnZwbjxicj4NCjxicj4NCjxicj4NCkVuZCBvZiBMMnZwbiBEaWdlc3QsIFZv bCA4NSwgSXNzdWUgMTQ8YnI+DQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq PGJyPg0KPGJyPg0KPC90dD48L2ZvbnQ+DQo= --=_alternative 0030D05C482578BE_=-- From PazP@orckit.com Wed Jun 29 07:50:03 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 911BF21F8489 for ; Wed, 29 Jun 2011 07:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3eSTEhWLVE7 for ; Wed, 29 Jun 2011 07:50:00 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6D91521F844C for ; Wed, 29 Jun 2011 07:49:59 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC366C.22D7CF89" Subject: RE: Questions/suggestions regarding"draft-ietf-l2vpn-vpls-ldp-mac-opt-04.txt" (Paz Pentelka) Date: Wed, 29 Jun 2011 17:52:15 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA081306DD0E46@tlvmail1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Questions/suggestions regarding"draft-ietf-l2vpn-vpls-ldp-mac-opt-04.txt" (Paz Pentelka) Thread-Index: Acw2Oqt2dd4eFILAQvO2dWqAmCJLDgAIFuwAAAMN4EAAANGRYAAAMuQwAAAf0sA= From: "Paz Pentelka" To: X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 14:50:03 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC366C.22D7CF89 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Hi, Thanks Ran for your response. Please see below my comments Paz. From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of chen.ran@zte.com.cn Sent: Wednesday, June 29, 2011 11:55 AM To: l2vpn@ietf.org Subject: Re: Questions/suggestions regarding"draft-ietf-l2vpn-vpls-ldp-mac-opt-04.txt" (Paz Pentelka) Hi all$B!$(J Please see the comments inline below. Regards, Ran l2vpn-request@ietf.org Sent by: l2vpn-bounces@ietf.org 2011-06-29 03:00 Please respond to l2vpn@ietf.org To l2vpn@ietf.org cc Subject L2vpn Digest, Vol 85, Issue 14 ---------------------------------------------------------------------- Message: 1 Date: Mon, 27 Jun 2011 22:00:16 +0300 From: "Paz Pentelka" To: Subject: Questions/suggestions regarding "draft-ietf-l2vpn-vpls-ldp-mac-opt-04.txt" Message-ID: <44F4E579A764584EA9BDFD07D0CA081306D5FDF9@tlvmail1> Content-Type: text/plain; charset="us-ascii" Dear Authors, Following review of "draft-ietf-l2vpn-vpls-ldp-mac-opt-04.txt > " I have a couple of questions/suggestions - 1 - According to 4.1.2 Note that if a MAC Flush TLV is not understood by a receiver then it may result in undesired action. For example if a MAC Flush Parameters TLV is received with N=1 and receiver does not understand that TLV then it would result in flushing of all MACs learned in the VSI except the ones learned over the PW. The MAC Flush TLV SHOULD be placed after the existing TLVs in MAC Flush message in [RFC4762 > ]. I would like to propose a solution to avoid the undesired flushing at PEs implementing [RFC4762] that are not supporting the new optimization - if PE-1 (according to the diagram below) can send MAC Flush Parameters TLV but doesn't send MAC Address TLV, there will not be incorrect flushing. [Ran]I think we should carry the MAC address TLV in the MAC Flush Paremeters. Actually draft-ietf-l2vpn-vpls-ldp-mac-opt-04 states:The MAC Flush TLV SHOULD be placed after the existing TLVs in MAC Flush message in [RFC4762 ]. Maybe we can use a LDP capability mechnism to slove this probrem. [Paz] That appears to be a good solution too. Are you planning to add this support in the next revision? 2- In a case where the primary spoke PW is down (according to the diagram below), there can be a case in which there are many other PWs connected between the 2 PEs that are down (due to physical link down for instance). In this case, is there a way to send MAC flush for different PW's/VPLS's with a single LDP MAC message (for better messaging scalability)? Such option can be defined using sub-TLVs, for example. [Ran] IMO, in this case, it can be achived by carring muti-FEC tlv in the MAC flush message. [Paz] Currently in RFC 4762 there seems to be no support for multiple FEC TLVs in the same MAC address withdrawal message, as follows: $B!H(JThe MAC Address Withdraw Message contains a FEC TLV (to identify the VPLS affected), a MAC Address TLV, and optional parameters.$B!H(J I would like to suggest instead using PW grouping capabilities, already defined in RFC 4447, to signal MAC address withdrawal on multiple PWs using a single FEC TLV. This has the additional advantage of being more scalable. What do you think? ------_=_NextPart_001_01CC366C.22D7CF89 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit

Hi,

Thanks Ran for your response.

Please see below my comments

Paz.

From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of chen.ran@zte.com.cn
Sent: Wednesday, June 29, 2011 11:55 AM
To: l2vpn@ietf.org
Subject: Re: Questions/suggestions re garding"draft-ietf-l2vpn-vpls-ldp-mac-opt-04.txt" (Paz Pentelka)

Hi all$B!$(B

Please see the comments inline below.

Regards,

Ran

l2vpn-request@ietf.org
Sent by: l2vpn-bounces@ietf.org

2011-06-29 03:00

Please respond to
l2vpn@ietf.org

To	l2vpn@ietf.org
cc
Subject	L2vpn Digest, Vol 85, Issue 14

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

Message: 1
Date: Mon, 27 Jun 2011 22:00:16 +0300
From: "Paz Pentelka" <PazP@orckit.com>
To: <L2vpn@ietf.org>
Subject: Questions/suggestions regarding
"draft-ietf-l2vpn-vpls-ldp-mac-opt-04.txt"
Message-ID: <44F4E579A764584EA9BDFD07D0CA081306D5FDF9@tlvmail1>
Content-Type: text/plain; charset="us-ascii"

Dear Authors,

Following review of "draft-ietf-l2vpn-vpls-ldp-mac-opt-04.txt
<http://potaroo.net/ietf/idref/draft-ietf-l2vpn-vpls-ldp-mac-opt/rfcmark up?repository=/away/ietf&url=/away/ietf/all-ids/draft-ietf-l2vpn-vpls-ld p-mac-opt-04.txt> " I have a couple of questions/suggestions -

1 - According to 4.1.2

Note that if a MAC Flush TLV is not understood by a receiver then it

may result in undesired action. For example if a MAC Flush Parameters

TLV is received with N=1 and receiver does not understand that TLV

then it would result in flushing of all MACs learned in the VSI

except the ones learned over the PW. The MAC Flush TLV SHOULD be

placed after the existing TLVs in MAC Flush message in [RFC4762
<http://potaroo.net/ietf/idref/draft-ietf-l2vpn-vpls-ldp-mac-opt/#ref-RF C4762> ].

I would like to propose a solution to avoid the undesired flushing at
PEs implementing [RFC4762] that are not supporting the new optimization
- if PE-1 (according to the diagram below) can send MAC Flush Parameters
TLV bu t doesn't send MAC Address TLV, there will not be incorrect
flushing.

[Ran]I think we should carry the MAC address TLV in the MAC Flush Paremeters.
Actually draft-ietf-l2vpn-vpls-ldp-mac-opt-04 states:The MAC Flush TLV SHOULD be
placed after the existing TLVs in MAC Flush message in [RFC4762].
Maybe we can use a LDP capability mechnism to slove this probrem.

[Paz] That appears to be a good solution too. Are you planning to add this support in the next revision?

2- In a case where the primary spoke PW is down (according to the
diagram below), there can be a case in which there are many other PWs
connected between the 2 PEs that are down (due to physical link down for
instance). In this case, is there a way to send MAC flush for different
PW's/VPLS's with a single LDP MAC message (for better messaging
scalability)? Such option can be defined using sub-TLVs, for example.
[Ran] IMO, in this case, it can be achived by carring muti-FEC tlv in the MAC flush message.

[Paz] Currently in RFC 4762 there seems to be no support for multiple FEC TLVs in the same MAC address withdrawal message, as follows:

$B!H(BThe MAC Address Withdraw Message contains a FEC TLV (to identify the

VPLS affected), a MAC Address TLV, and optional parameters.$B!H(B

I would like to suggest instead using PW grouping capabilities, already defined in RFC 4447, to signal MAC address withdrawal on multiple

PWs using a single FEC TLV. This has the additional advantage of being more scalable. What do you think?

------_=_NextPart_001_01CC366C.22D7CF89-- From chen.ran@zte.com.cn Wed Jun 29 21:43:21 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 475EB11E8100; Wed, 29 Jun 2011 21:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.035 X-Spam-Level: X-Spam-Status: No, score=-97.035 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNLeGuJoSBKT; Wed, 29 Jun 2011 21:43:20 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id A7DE611E80C8; Wed, 29 Jun 2011 21:43:15 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 131322397131170; Thu, 30 Jun 2011 12:39:46 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 18917.2844121636; Thu, 30 Jun 2011 12:42:53 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p5U4guvH083617; Thu, 30 Jun 2011 12:42:56 +0800 (GMT-8) (envelope-from chen.ran@zte.com.cn) In-Reply-To: <44F4E579A764584EA9BDFD07D0CA081306DD0E46@tlvmail1> To: "Paz Pentelka" Subject: RE: RE: Questions/suggestions regarding"draft-ietf-l2vpn-vpls-ldp-mac-opt-04.txt" (Paz Pentelka) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: chen.ran@zte.com.cn Date: Thu, 30 Jun 2011 12:42:48 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-06-30 12:42:58, Serialize complete at 2011-06-30 12:42:58 Content-Type: multipart/alternative; boundary="=_alternative 0019B77F482578BF_=" X-MAIL: mse02.zte.com.cn p5U4guvH083617 Cc: L2vpn@ietf.org, l2vpn-bounces@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 04:43:21 -0000 This is a multipart message in MIME format. --=_alternative 0019B77F482578BF_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgUGF6IGFuZCBhbGwsDQpQbGVhc2Ugc2VlIGJlbG93Lg0KDQpSZWdhcmRzLA0KUmFuDQoNCg0K DQoiUGF6IFBlbnRlbGthIiA8UGF6UEBvcmNraXQuY29tPiANCreivP7IyzogIGwydnBuLWJvdW5j ZXNAaWV0Zi5vcmcNCjIwMTEtMDYtMjkgMjI6NTINCg0KytW8/sjLDQo8TDJ2cG5AaWV0Zi5vcmc+ DQqzrcvNDQoNCtb3zOINClJFOiBRdWVzdGlvbnMvc3VnZ2VzdGlvbnMgDQpyZWdhcmRpbmciZHJh ZnQtaWV0Zi1sMnZwbi12cGxzLWxkcC1tYWMtb3B0LTA0LnR4dCIgKFBheiBQZW50ZWxrYSkNCg0K DQoNCg0KDQoNCkhpLA0KIA0KVGhhbmtzIFJhbiBmb3IgeW91ciByZXNwb25zZS4NCiANClBsZWFz ZSBzZWUgYmVsb3cgbXkgY29tbWVudHMNCiANClBhei4NCiANCiANCiANCkZyb206IGwydnBuLWJv dW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgDQpjaGVuLnJhbkB6dGUuY29tLmNuDQpTZW50OiBXZWRuZXNkYXksIEp1bmUgMjksIDIwMTEg MTE6NTUgQU0NClRvOiBsMnZwbkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFF1ZXN0aW9ucy9zdWdn ZXN0aW9ucyByZSANCmdhcmRpbmciZHJhZnQtaWV0Zi1sMnZwbi12cGxzLWxkcC1tYWMtb3B0LTA0 LnR4dCIgKFBheiBQZW50ZWxrYSkNCiANCkhpIGFsbKOsIA0KUGxlYXNlIHNlZSB0aGUgY29tbWVu dHMgaW5saW5lIGJlbG93LiANClJlZ2FyZHMsIA0KUmFuDQoNCmwydnBuLXJlcXVlc3RAaWV0Zi5v cmcgDQpTZW50IGJ5OiBsMnZwbi1ib3VuY2VzQGlldGYub3JnIA0KMjAxMS0wNi0yOSAwMzowMCAN Cg0KDQpQbGVhc2UgcmVzcG9uZCB0bw0KbDJ2cG5AaWV0Zi5vcmcNCg0KDQoNClRvDQpsMnZwbkBp ZXRmLm9yZyANCmNjDQoNClN1YmplY3QNCkwydnBuIERpZ2VzdCwgVm9sIDg1LCBJc3N1ZSAxNA0K IA0KDQoNCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpNZXNzYWdlOiAxDQpEYXRlOiBNb24sIDI3 IEp1biAyMDExIDIyOjAwOjE2ICswMzAwDQpGcm9tOiAiUGF6IFBlbnRlbGthIiA8UGF6UEBvcmNr aXQuY29tPg0KVG86IDxMMnZwbkBpZXRmLm9yZz4NClN1YmplY3Q6IFF1ZXN0aW9ucy9zdWdnZXN0 aW9ucyByZWdhcmRpbmcNCiAgICAgICAgICAgICAgICAiZHJhZnQtaWV0Zi1sMnZwbi12cGxzLWxk cC1tYWMtb3B0LTA0LnR4dCINCk1lc3NhZ2UtSUQ6IDw0NEY0RTU3OUE3NjQ1ODRFQTlCREZEMDdE MENBMDgxMzA2RDVGREY5QHRsdm1haWwxPg0KQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFy c2V0PSJ1cy1hc2NpaSINCg0KRGVhciBBdXRob3JzLA0KDQoNCg0KRm9sbG93aW5nIHJldmlldyBv ZiAiZHJhZnQtaWV0Zi1sMnZwbi12cGxzLWxkcC1tYWMtb3B0LTA0LnR4dA0KPGh0dHA6Ly9wb3Rh cm9vLm5ldC9pZXRmL2lkcmVmL2RyYWZ0LWlldGYtbDJ2cG4tdnBscy1sZHAtbWFjLW9wdC9yZmNt YXJrDQp1cD9yZXBvc2l0b3J5PS9hd2F5L2lldGYmdXJsPS9hd2F5L2lldGYvYWxsLWlkcy9kcmFm dC1pZXRmLWwydnBuLXZwbHMtbGQNCnAtbWFjLW9wdC0wNC50eHQ+ICIgSSBoYXZlIGEgY291cGxl IG9mIHF1ZXN0aW9ucy9zdWdnZXN0aW9ucyAtIA0KDQoNCg0KMSAtIEFjY29yZGluZyB0byA0LjEu Mg0KDQpOb3RlIHRoYXQgaWYgYSBNQUMgRmx1c2ggVExWIGlzIG5vdCB1bmRlcnN0b29kIGJ5IGEg cmVjZWl2ZXIgdGhlbiBpdCANCg0KbWF5IHJlc3VsdCBpbiB1bmRlc2lyZWQgYWN0aW9uLiBGb3Ig ZXhhbXBsZSBpZiBhIE1BQyBGbHVzaCBQYXJhbWV0ZXJzIA0KDQpUTFYgaXMgcmVjZWl2ZWQgd2l0 aCBOPTEgYW5kIHJlY2VpdmVyIGRvZXMgbm90IHVuZGVyc3RhbmQgdGhhdCBUTFYgDQoNCnRoZW4g aXQgd291bGQgcmVzdWx0IGluIGZsdXNoaW5nIG9mIGFsbCBNQUNzIGxlYXJuZWQgaW4gdGhlIFZT SSANCg0KZXhjZXB0IHRoZSBvbmVzIGxlYXJuZWQgb3ZlciB0aGUgUFcuIFRoZSBNQUMgRmx1c2gg VExWIFNIT1VMRCBiZSANCg0KcGxhY2VkIGFmdGVyIHRoZSBleGlzdGluZyBUTFZzIGluIE1BQyBG bHVzaCBtZXNzYWdlIGluIFtSRkM0NzYyDQo8aHR0cDovL3BvdGFyb28ubmV0L2lldGYvaWRyZWYv ZHJhZnQtaWV0Zi1sMnZwbi12cGxzLWxkcC1tYWMtb3B0LyNyZWYtUkYNCkM0NzYyPiBdLiAgIA0K DQoNCkkgd291bGQgbGlrZSB0byBwcm9wb3NlIGEgc29sdXRpb24gdG8gYXZvaWQgdGhlIHVuZGVz aXJlZCBmbHVzaGluZyBhdA0KUEVzIGltcGxlbWVudGluZyBbUkZDNDc2Ml0gdGhhdCBhcmUgbm90 IHN1cHBvcnRpbmcgdGhlIG5ldyBvcHRpbWl6YXRpb24NCi0gaWYgUEUtMSAoYWNjb3JkaW5nIHRv IHRoZSBkaWFncmFtIGJlbG93KSBjYW4gc2VuZCBNQUMgRmx1c2ggUGFyYW1ldGVycw0KVExWIGJ1 IHQgZG9lc24ndCBzZW5kIE1BQyBBZGRyZXNzIFRMViwgdGhlcmUgd2lsbCBub3QgYmUgaW5jb3Jy ZWN0DQpmbHVzaGluZy4NCg0KW1Jhbl1JIHRoaW5rIHdlIHNob3VsZCBjYXJyeSB0aGUgTUFDIGFk ZHJlc3MgVExWIGluIHRoZSBNQUMgRmx1c2ggDQpQYXJlbWV0ZXJzLiANCkFjdHVhbGx5IGRyYWZ0 LWlldGYtbDJ2cG4tdnBscy1sZHAtbWFjLW9wdC0wNCBzdGF0ZXM6VGhlIE1BQyBGbHVzaCBUTFYg DQpTSE9VTEQgYmUNCnBsYWNlZCBhZnRlciB0aGUgZXhpc3RpbmcgVExWcyBpbiBNQUMgRmx1c2gg bWVzc2FnZSBpbiBbUkZDNDc2Ml0uDQpNYXliZSB3ZSBjYW4gdXNlIGEgTERQIGNhcGFiaWxpdHkg bWVjaG5pc20gdG8gc2xvdmUgdGhpcyBwcm9icmVtLiANCltQYXpdIFRoYXQgYXBwZWFycyB0byBi ZSBhIGdvb2Qgc29sdXRpb24gdG9vLiBBcmUgeW91IHBsYW5uaW5nIHRvIGFkZCB0aGlzIA0Kc3Vw cG9ydCBpbiB0aGUgbmV4dCByZXZpc2lvbj8gDQogW1Jhbl1JIGFtIHNvcnJ5o6xJIGFtIG5vdCB0 aGUgYXV0aG9yo6xJIGp1c3QgZ2l2ZSBzb21lIGNvbWVudHMuICCjuqOpDQoNCjItIEluIGEgY2Fz ZSB3aGVyZSB0aGUgcHJpbWFyeSBzcG9rZSBQVyBpcyBkb3duIChhY2NvcmRpbmcgdG8gdGhlDQpk aWFncmFtIGJlbG93KSwgdGhlcmUgY2FuIGJlIGEgY2FzZSBpbiB3aGljaCB0aGVyZSBhcmUgbWFu eSBvdGhlciBQV3MNCmNvbm5lY3RlZCBiZXR3ZWVuIHRoZSAyIFBFcyB0aGF0IGFyZSBkb3duIChk dWUgdG8gcGh5c2ljYWwgbGluayBkb3duIGZvcg0KaW5zdGFuY2UpLiBJbiB0aGlzIGNhc2UsIGlz IHRoZXJlIGEgd2F5IHRvIHNlbmQgTUFDIGZsdXNoIGZvciBkaWZmZXJlbnQNClBXJ3MvVlBMUydz IHdpdGggYSBzaW5nbGUgTERQIE1BQyBtZXNzYWdlIChmb3IgYmV0dGVyIG1lc3NhZ2luZw0Kc2Nh bGFiaWxpdHkpPyBTdWNoIG9wdGlvbiBjYW4gYmUgZGVmaW5lZCB1c2luZyBzdWItVExWcywgZm9y IGV4YW1wbGUuDQpbUmFuXSAgSU1PLCBpbiB0aGlzIGNhc2UsIGl0IGNhbiBiZSBhY2hpdmVkIGJ5 IGNhcnJpbmcgbXV0aS1GRUMgdGx2IGluIHRoZSANCk1BQyBmbHVzaCBtZXNzYWdlLg0KDQpbUGF6 XSBDdXJyZW50bHkgaW4gUkZDIDQ3NjIgdGhlcmUgc2VlbXMgdG8gYmUgbm8gc3VwcG9ydCBmb3Ig bXVsdGlwbGUgRkVDIA0KVExWcyBpbiB0aGUgc2FtZSBNQUMgYWRkcmVzcyB3aXRoZHJhd2FsIG1l c3NhZ2UsIGFzIGZvbGxvd3M6DQogDQqhsFRoZSBNQUMgQWRkcmVzcyBXaXRoZHJhdyBNZXNzYWdl IGNvbnRhaW5zIGEgRkVDIFRMViAodG8gaWRlbnRpZnkgdGhlDQogICBWUExTIGFmZmVjdGVkKSwg YSBNQUMgQWRkcmVzcyBUTFYsIGFuZCBvcHRpb25hbCBwYXJhbWV0ZXJzLqGwDQogW1Jhbl1ZZXMg o6xJIG1lYW4gdGhhdCBtYXliZSB3ZSBjYW4gZG8gc29tZSBleHRlbnNpb25zLg0KDQpJIHdvdWxk IGxpa2UgdG8gc3VnZ2VzdCBpbnN0ZWFkIHVzaW5nIFBXIGdyb3VwaW5nIGNhcGFiaWxpdGllcywg YWxyZWFkeSANCmRlZmluZWQgaW4gUkZDIDQ0NDcsIHRvIHNpZ25hbCBNQUMgYWRkcmVzcyB3aXRo ZHJhd2FsIG9uIG11bHRpcGxlIA0KUFdzIHVzaW5nIGEgc2luZ2xlIEZFQyBUTFYuIFRoaXMgaGFz IHRoZSBhZGRpdGlvbmFsIGFkdmFudGFnZSBvZiBiZWluZyANCm1vcmUgc2NhbGFibGUuIFdoYXQg ZG8geW91IHRoaW5rPw0KDQogW1Jhbl1DdXJyZW50bHksIGluIFJGQzQ3NjIsIEkgZG8gbm90IHRo aW5rIHRoZSBHcm91cGluZyBJRCBmaWVsZC9QVyANCkdyb3VwaW5nIElEIFRMViAgaXMgY2Fycmll ZCBpbiBNQUMgd2l0aGRyYXcgbWVzc2FnZS4NCiBJZiB0aGUgUFcgZ3JvdXBpbmcgY2FwYWJpbGl0 aWVzIGFyZSB1c2VkICwgSG93IHRvIGRpdmlkZSB0aGUgZ3JvdXA/IA0KDQoNCg== --=_alternative 0019B77F482578BF_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSM4MDAwMDAgZmFjZT0iQ2FsaWJyaSI+SGkgUGF6IGFu ZCBhbGwsPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jODAwMDAwIGZhY2U9IkNhbGli cmkiPlBsZWFzZSBzZWUgYmVsb3cuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBjb2xv cj0jODAwMDAwIGZhY2U9IkNhbGlicmkiPlJlZ2FyZHMsPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBjb2xvcj0jODAwMDAwIGZhY2U9IkNhbGlicmkiPlJhbjwvZm9udD4NCjxicj4NCjxicj4NCjxi cj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzUlPjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj4mcXVvdDtQYXogUGVudGVsa2EmcXVvdDsN CiZsdDtQYXpQQG9yY2tpdC5jb20mZ3Q7PC9iPiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPreivP7IyzogJm5ic3A7bDJ2cG4tYm91bmNlc0BpZXRmLm9yZzwvZm9u dD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDExLTA2LTI5IDIyOjUyPC9m b250Pg0KPHRkIHdpZHRoPTY0JT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+ DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K 1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZs dDtMMnZwbkBpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYg YWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9k aXY+DQo8dGQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJFOiBRdWVzdGlvbnMvc3VnZ2VzdGlvbnMgJm5ic3A7ICZu YnNwOw0KJm5ic3A7ICZuYnNwO3JlZ2FyZGluZyZxdW90O2RyYWZ0LWlldGYtbDJ2cG4tdnBscy1s ZHAtbWFjLW9wdC0wNC50eHQmcXVvdDsNCihQYXogUGVudGVsa2EpPC9mb250PjwvdGFibGU+DQo8 YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwv dGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0i Q2FsaWJyaSI+SGksPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9 IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBm YWNlPSJDYWxpYnJpIj5UaGFua3MgUmFuIGZvciB5b3VyIHJlc3BvbnNlLjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+UGxlYXNlIHNlZSBi ZWxvdyBteSBjb21tZW50czwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBm YWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5 N2QgZmFjZT0iQ2FsaWJyaSI+UGF6LjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFm NDk3ZCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9y PSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBj b2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0iVGFob21hIj48Yj5Gcm9tOjwvYj4gPC9mb250PjxhIGhyZWY9Im1haWx0bzpsMnZw bi1ib3VuY2VzQGlldGYub3JnIj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEi Pjx1PmwydnBuLWJvdW5jZXNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFj ZT0iVGFob21hIj4NCjwvZm9udD48YSBocmVmPSJtYWlsdG86W21haWx0bzpsMnZwbi1ib3VuY2Vz QGlldGYub3JnXSI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVGFob21hIj48dT5bbWFp bHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmddPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZh Y2U9IlRhaG9tYSI+DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPjwvZm9udD48YSBocmVmPW1haWx0bzpj aGVuLnJhbkB6dGUuY29tLmNuPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+ PHU+Y2hlbi5yYW5AenRlLmNvbS5jbjwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJU YWhvbWEiPjxiPjxicj4NClNlbnQ6PC9iPiBXZWRuZXNkYXksIEp1bmUgMjksIDIwMTEgMTE6NTUg QU08Yj48YnI+DQpUbzo8L2I+IDwvZm9udD48YSBocmVmPW1haWx0bzpsMnZwbkBpZXRmLm9yZz48 Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1PmwydnBuQGlldGYub3JnPC91 PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+PGI+PGJyPg0KU3ViamVjdDo8 L2I+IFJlOiBRdWVzdGlvbnMvc3VnZ2VzdGlvbnMgcmUgZ2FyZGluZyZxdW90O2RyYWZ0LWlldGYt bDJ2cG4tdnBscy1sZHAtbWFjLW9wdC0wNC50eHQmcXVvdDsNCihQYXogUGVudGVsa2EpPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+DQo8cD48 Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj5IaSBhbGyjrDwvZm9udD48 Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTMg Y29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj5QbGVhc2Ugc2VlIHRoZSBjb21tZW50cyBpbmxp bmUNCmJlbG93LjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9udD4N CjxwPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPlJlZ2FyZHMsPC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjxwPjxmb250IHNp emU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPlJhbjwvZm9udD4NCjxwPg0KPHRhYmxl IHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD00NyU+PGEgaHJlZj0ibWFp bHRvOmwydnBuLXJlcXVlc3RAaWV0Zi5vcmciPjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9 IkFyaWFsIj48Yj48dT5sMnZwbi1yZXF1ZXN0QGlldGYub3JnPC91PjwvYj48L2ZvbnQ+PC9hPjxm b250IHNpemU9MSBmYWNlPSJBcmlhbCI+DQo8YnI+DQpTZW50IGJ5OiA8L2ZvbnQ+PGEgaHJlZj0i bWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmciPjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZh Y2U9IkFyaWFsIj48dT5sMnZwbi1ib3VuY2VzQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQg c2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9 IkFyaWFsIj4yMDExLTA2LTI5IDAzOjAwPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNl cmlmIj4NCjwvZm9udD4NCjxwPg0KPGJyPg0KPHRhYmxlIGJvcmRlcj00IHdpZHRoPTEwMCU+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0xMDAlIGJnY29sb3I9d2hpdGU+DQo8ZGl2IGFsaWdu PWNlbnRlcj48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPlBsZWFzZSByZXNwb25kIHRvPC9mb250 Pjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj48dT48YnI+DQo8L3U+PC9mb250 PjxhIGhyZWY9bWFpbHRvOmwydnBuQGlldGYub3JnPjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZh Y2U9IkFyaWFsIj48dT5sMnZwbkBpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjwvZGl2PjwvdGFibGU+ DQo8YnI+DQo8dGQgd2lkdGg9NTIlPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZCB3aWR0aD0xOSU+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBm YWNlPSJBcmlhbCI+VG88L2ZvbnQ+PC9kaXY+DQo8dGQgd2lkdGg9ODAlPjxhIGhyZWY9bWFpbHRv OmwydnBuQGlldGYub3JnPjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj48dT5s MnZwbkBpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlm Ij4NCjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9u dCBzaXplPTEgZmFjZT0iQXJpYWwiPmNjPC9mb250PjwvZGl2Pg0KPHRkPg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+U3Vi amVjdDwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPkwydnBuIERp Z2VzdCwgVm9sIDg1LCBJc3N1ZSAxNDwvZm9udD48L3RhYmxlPg0KPGJyPjxmb250IHNpemU9MyBm YWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+DQo8cD4NCjxicj4NCjx0YWJsZSB3aWR0aD0x MDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9NTAlPg0KPHRkIHdpZHRoPTUwJT48L3Rh YmxlPg0KPGJyPjwvdGFibGU+DQo8cD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJy Pg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLTxicj4NCjxicj4NCk1lc3NhZ2U6IDE8YnI+DQpEYXRlOiBNb24sIDI3 IEp1biAyMDExIDIyOjAwOjE2ICswMzAwPGJyPg0KRnJvbTogJnF1b3Q7UGF6IFBlbnRlbGthJnF1 b3Q7ICZsdDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86UGF6UEBvcmNraXQuY29tPjxmb250IHNpemU9 MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1PlBhelBAb3Jja2l0LmNvbTwvdT48L2Zv bnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7PGJyPg0KVG86ICZsdDs8 L2ZvbnQ+PGEgaHJlZj1tYWlsdG86TDJ2cG5AaWV0Zi5vcmc+PGZvbnQgc2l6ZT0zIGNvbG9yPWJs dWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+TDJ2cG5AaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9u dCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0Ozxicj4NClN1YmplY3Q6IFF1ZXN0aW9ucy9z dWdnZXN0aW9ucyByZWdhcmRpbmc8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3 Ij48YnI+DQogPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2Zv bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJDb3VyaWVy IE5ldyI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9u dD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBOZXciPg0KPC9mb250Pjxmb250IHNpemU9MyBm YWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIg TmV3Ij4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250 Pjxmb250IHNpemU9MyBmYWNlPSJDb3VyaWVyIE5ldyI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh Y2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBO ZXciPg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+ PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+Jm5ic3A7JnF1b3Q7ZHJhZnQtaWV0Zi1sMnZwbi12cGxzLWxkcC1tYWMt b3B0LTA0LnR4dCZxdW90Ozxicj4NCk1lc3NhZ2UtSUQ6ICZsdDs0NEY0RTU3OUE3NjQ1ODRFQTlC REZEMDdEMENBMDgxMzA2RDVGREY5QHRsdm1haWwxJmd0Ozxicj4NCkNvbnRlbnQtVHlwZTogdGV4 dC9wbGFpbjsgY2hhcnNldD0mcXVvdDt1cy1hc2NpaSZxdW90Ozxicj4NCjxicj4NCkRlYXIgQXV0 aG9ycyw8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpGb2xsb3dpbmcgcmV2aWV3IG9mICZxdW90O2Ry YWZ0LWlldGYtbDJ2cG4tdnBscy1sZHAtbWFjLW9wdC0wNC50eHQ8YnI+DQombHQ7PC9mb250Pjxh IGhyZWY9Imh0dHA6Ly9wb3Rhcm9vLm5ldC9pZXRmL2lkcmVmL2RyYWZ0LWlldGYtbDJ2cG4tdnBs cy1sZHAtbWFjLW9wdC9yZmNtYXJrJTBidXA/cmVwb3NpdG9yeT0vYXdheS9pZXRmJmFtcDt1cmw9 L2F3YXkvaWV0Zi9hbGwtaWRzL2RyYWZ0LWlldGYtbDJ2cG4tdnBscy1sZCUwYnAtbWFjLW9wdC0w NC50eHQiPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1Pmh0dHA6 Ly9wb3Rhcm9vLm5ldC9pZXRmL2lkcmVmL2RyYWZ0LWlldGYtbDJ2cG4tdnBscy1sZHAtbWFjLW9w dC9yZmNtYXJrPGJyPg0KdXA/cmVwb3NpdG9yeT0vYXdheS9pZXRmJmFtcDt1cmw9L2F3YXkvaWV0 Zi9hbGwtaWRzL2RyYWZ0LWlldGYtbDJ2cG4tdnBscy1sZDxicj4NCnAtbWFjLW9wdC0wNC50eHQ8 L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0OyAmcXVvdDsN CkkgaGF2ZSBhIGNvdXBsZSBvZiBxdWVzdGlvbnMvc3VnZ2VzdGlvbnMgLSA8YnI+DQo8YnI+DQo8 YnI+DQo8YnI+DQoxIC0gQWNjb3JkaW5nIHRvIDQuMS4yPGJyPg0KPGJyPg0KTm90ZSB0aGF0IGlm IGEgTUFDIEZsdXNoIFRMViBpcyBub3QgdW5kZXJzdG9vZCBieSBhIHJlY2VpdmVyIHRoZW4gaXQg PGJyPg0KPGJyPg0KbWF5IHJlc3VsdCBpbiB1bmRlc2lyZWQgYWN0aW9uLiBGb3IgZXhhbXBsZSBp ZiBhIE1BQyBGbHVzaCBQYXJhbWV0ZXJzIDxicj4NCjxicj4NClRMViBpcyByZWNlaXZlZCB3aXRo IE49MSBhbmQgcmVjZWl2ZXIgZG9lcyBub3QgdW5kZXJzdGFuZCB0aGF0IFRMViA8YnI+DQo8YnI+ DQp0aGVuIGl0IHdvdWxkIHJlc3VsdCBpbiBmbHVzaGluZyBvZiBhbGwgTUFDcyBsZWFybmVkIGlu IHRoZSBWU0kgPGJyPg0KPGJyPg0KZXhjZXB0IHRoZSBvbmVzIGxlYXJuZWQgb3ZlciB0aGUgUFcu IFRoZSBNQUMgRmx1c2ggVExWIFNIT1VMRCBiZSA8YnI+DQo8YnI+DQpwbGFjZWQgYWZ0ZXIgdGhl IGV4aXN0aW5nIFRMVnMgaW4gTUFDIEZsdXNoIG1lc3NhZ2UgaW4gW1JGQzQ3NjI8YnI+DQombHQ7 PC9mb250PjxhIGhyZWY9Imh0dHA6Ly9wb3Rhcm9vLm5ldC9pZXRmL2lkcmVmL2RyYWZ0LWlldGYt bDJ2cG4tdnBscy1sZHAtbWFjLW9wdC8jcmVmLVJGf0M0NzYyIj48Zm9udCBzaXplPTMgY29sb3I9 Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5odHRwOi8vcG90YXJvby5uZXQvaWV0Zi9pZHJlZi9k cmFmdC1pZXRmLWwydnBuLXZwbHMtbGRwLW1hYy1vcHQvI3JlZi1SRjxicj4NCkM0NzYyPC91Pjwv Zm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZndDsgXS4gPC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MyBm YWNlPSJzYW5zLXNlcmlmIj4NCjxicj4NCjxicj4NCjxicj4NCkkgd291bGQgbGlrZSB0byBwcm9w b3NlIGEgc29sdXRpb24gdG8gYXZvaWQgdGhlIHVuZGVzaXJlZCBmbHVzaGluZyBhdDxicj4NClBF cyBpbXBsZW1lbnRpbmcgW1JGQzQ3NjJdIHRoYXQgYXJlIG5vdCBzdXBwb3J0aW5nIHRoZSBuZXcg b3B0aW1pemF0aW9uPGJyPg0KLSBpZiBQRS0xIChhY2NvcmRpbmcgdG8gdGhlIGRpYWdyYW0gYmVs b3cpIGNhbiBzZW5kIE1BQyBGbHVzaCBQYXJhbWV0ZXJzPGJyPg0KVExWIGJ1IHQgZG9lc24ndCBz ZW5kIE1BQyBBZGRyZXNzIFRMViwgdGhlcmUgd2lsbCBub3QgYmUgaW5jb3JyZWN0PGJyPg0KZmx1 c2hpbmcuPGJyPg0KPC9mb250Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2Vy aWYiPjxicj4NCltSYW5dSSB0aGluayB3ZSBzaG91bGQgY2FycnkgdGhlIE1BQyBhZGRyZXNzIFRM ViBpbiB0aGUgTUFDIEZsdXNoIFBhcmVtZXRlcnMuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJz YW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNl cmlmIj48YnI+DQpBY3R1YWxseSBkcmFmdC1pZXRmLWwydnBuLXZwbHMtbGRwLW1hYy1vcHQtMDQg c3RhdGVzOlRoZSBNQUMgRmx1c2ggVExWDQpTSE9VTEQgYmU8YnI+DQpwbGFjZWQgYWZ0ZXIgdGhl IGV4aXN0aW5nIFRMVnMgaW4gTUFDIEZsdXNoIG1lc3NhZ2UgaW4gWzwvZm9udD48YSBocmVmPWh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQ3NjI+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUg ZmFjZT0ic2Fucy1zZXJpZiI+PHU+UkZDNDc2MjwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBj b2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPl0uPGJyPg0KTWF5YmUgd2UgY2FuIHVzZSBhIExE UCBjYXBhYmlsaXR5IG1lY2huaXNtIHRvIHNsb3ZlIHRoaXMgcHJvYnJlbS48L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xv cj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPltQYXpdIFRoYXQgYXBwZWFycyB0byBiZQ0KYSBnb29k IHNvbHV0aW9uIHRvby4gQXJlIHlvdSBwbGFubmluZyB0byBhZGQgdGhpcyBzdXBwb3J0IGluIHRo ZSBuZXh0IHJldmlzaW9uPw0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jODAwMDAw IGZhY2U9IkNhbGlicmkiPiZuYnNwO1tSYW5dSSBhbSBzb3JyeaOsSQ0KYW0gbm90IHRoZSBhdXRo b3KjrEkganVzdCBnaXZlIHNvbWUgY29tZW50cy4gJm5ic3A7o7qjqTwvZm9udD4NCjxicj48Zm9u dCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KMi0gSW4gYSBjYXNlIHdoZXJlIHRoZSBw cmltYXJ5IHNwb2tlIFBXIGlzIGRvd24gKGFjY29yZGluZyB0byB0aGU8YnI+DQpkaWFncmFtIGJl bG93KSwgdGhlcmUgY2FuIGJlIGEgY2FzZSBpbiB3aGljaCB0aGVyZSBhcmUgbWFueSBvdGhlciBQ V3M8YnI+DQpjb25uZWN0ZWQgYmV0d2VlbiB0aGUgMiBQRXMgdGhhdCBhcmUgZG93biAoZHVlIHRv IHBoeXNpY2FsIGxpbmsgZG93biBmb3I8YnI+DQppbnN0YW5jZSkuIEluIHRoaXMgY2FzZSwgaXMg dGhlcmUgYSB3YXkgdG8gc2VuZCBNQUMgZmx1c2ggZm9yIGRpZmZlcmVudDxicj4NClBXJ3MvVlBM UydzIHdpdGggYSBzaW5nbGUgTERQIE1BQyBtZXNzYWdlIChmb3IgYmV0dGVyIG1lc3NhZ2luZzxi cj4NCnNjYWxhYmlsaXR5KT8gU3VjaCBvcHRpb24gY2FuIGJlIGRlZmluZWQgdXNpbmcgc3ViLVRM VnMsIGZvciBleGFtcGxlLjwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5z LXNlcmlmIj48YnI+DQpbUmFuXSA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0i Q291cmllciBOZXciPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJz YW5zLXNlcmlmIj5JTU8sDQppbiB0aGlzIGNhc2UsIDwvZm9udD48Zm9udCBzaXplPTEgY29sb3I9 Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj5pdCBjYW4gYmUNCmFjaGl2ZWQgYnkgY2FycmluZyBtdXRp LUZFQyB0bHYgaW4gdGhlIE1BQyBmbHVzaCBtZXNzYWdlLjwvZm9udD48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+PGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZh Y2U9InNhbnMtc2VyaWYiPjxicj4NCltQYXpdIEN1cnJlbnRseSBpbiBSRkMgNDc2MiB0aGVyZSBz ZWVtcyB0byBiZSBubyBzdXBwb3J0IGZvciBtdWx0aXBsZSBGRUMNClRMVnMgaW4gdGhlIHNhbWUg TUFDIGFkZHJlc3Mgd2l0aGRyYXdhbCBtZXNzYWdlLCBhcyBmb2xsb3dzOjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+obBUaGUgTUFDIEFk ZHJlc3MgV2l0aGRyYXcNCk1lc3NhZ2UgY29udGFpbnMgPGI+PHU+YTwvdT48L2I+IEZFQyBUTFYg KHRvIGlkZW50aWZ5IHRoZTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBm YWNlPSJDYWxpYnJpIj4mbmJzcDsgJm5ic3A7VlBMUyBhZmZlY3RlZCksDQphIE1BQyBBZGRyZXNz IFRMViwgYW5kIG9wdGlvbmFsIHBhcmFtZXRlcnMuobA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBj b2xvcj0jODAwMDAwIGZhY2U9IkNhbGlicmkiPltSYW5dWWVzDQqjrEkgbWVhbiB0aGF0IG1heWJl IHdlIGNhbiBkbyBzb21lIGV4dGVuc2lvbnMuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9 MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPkkgd291bGQgbGlrZSB0byBzdWdnZXN0IGlu c3RlYWQNCnVzaW5nIFBXIGdyb3VwaW5nIGNhcGFiaWxpdGllcywgYWxyZWFkeSBkZWZpbmVkIGlu IFJGQyA0NDQ3LCB0byBzaWduYWwNCk1BQyBhZGRyZXNzIHdpdGhkcmF3YWwgb24gbXVsdGlwbGUg PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPlBX cyB1c2luZyBhIHNpbmdsZSBGRUMgVExWLg0KVGhpcyBoYXMgdGhlIGFkZGl0aW9uYWwgYWR2YW50 YWdlIG9mIGJlaW5nIG1vcmUgc2NhbGFibGUuIFdoYXQgZG8geW91IHRoaW5rPzwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzgwMDAwMCBmYWNlPSJDYWxpYnJpIj4mbmJzcDtb UmFuXUN1cnJlbnRseSwgaW4NClJGQzQ3NjIsIEkgZG8gbm90IHRoaW5rIHRoZSBHcm91cGluZyBJ RCBmaWVsZC9QVyBHcm91cGluZyBJRCBUTFYgJm5ic3A7aXMNCmNhcnJpZWQgaW4gTUFDIHdpdGhk cmF3IG1lc3NhZ2UuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jODAwMDAwIGZhY2U9 IkNhbGlicmkiPiZuYnNwO0lmIHRoZSBQVyBncm91cGluZw0KY2FwYWJpbGl0aWVzIGFyZSB1c2Vk ICwgSG93IHRvIGRpdmlkZSB0aGUgZ3JvdXA/IDwvZm9udD4NCjxicj4NCjxicj4NCg== --=_alternative 0019B77F482578BF_=--