From nobody Tue Apr 1 01:14:22 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7DD1A7021; Tue, 1 Apr 2014 01:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.119 X-Spam-Level: X-Spam-Status: No, score=-3.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id td6zwdIblYU2; Tue, 1 Apr 2014 01:14:13 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.163]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6981A701F; Tue, 1 Apr 2014 01:14:11 -0700 (PDT) Received: from [195.245.230.51:20699] by server-3.bemta-3.messagelabs.com id E7/0E-05289-F457A335; Tue, 01 Apr 2014 08:14:07 +0000 X-Env-Sender: Frederic.Jounay@orange.ch X-Msg-Ref: server-3.tower-33.messagelabs.com!1396340044!4333725!2 X-Originating-IP: [213.55.206.8] X-StarScan-Received: X-StarScan-Version: 6.11.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1919 invoked from network); 1 Apr 2014 08:14:06 -0000 Received: from unknown (HELO chbbochs054.orange.ch) (213.55.206.8) by server-3.tower-33.messagelabs.com with RC4-SHA encrypted SMTP; 1 Apr 2014 08:14:06 -0000 Received: from CHCROCHC051.orange.ch ([fe80:0000:0000:0000:704b:3a68:12.14.247.83]) by chbbochs054.orange.ch ([172.25.9.54]) with mapi; Tue, 1 Apr 2014 10:12:28 +0200 From: =?iso-8859-1?Q?Jounay_Fr=E9d=E9ric?= To: "adrian@olddog.co.uk" , "draft-ietf-pwe3-p2mp-pw-requirements.all@tools.ietf.org" , 'Danny McPherson' Date: Tue, 1 Apr 2014 10:12:26 +0200 Thread-Topic: [PWE3] Danny McPherson's Rtg-Dir review of draft-ietf-pwe3-p2mp-pw-requirements Thread-Index: Ac9M/iD4IE2H4j8CQBCtnHo5w4RK/wAf9e/Q Message-ID: <78046FD1C8FE0345AFBC11640A8DF6E201864A00807C@CHCROCHC051.orange.ch> References: <022001cf4cfe$25fd5fc0$71f81f40$@olddog.co.uk> In-Reply-To: <022001cf4cfe$25fd5fc0$71f81f40$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/a0g007B7QDAkbMpE6eBVn-XX_38 Cc: "rtg-dir@ietf.org" , "pwe3@ietf.org" Subject: Re: [PWE3] Danny McPherson's Rtg-Dir review of draft-ietf-pwe3-p2mp-pw-requirements X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 08:14:18 -0000 Hi Adrian, Danny, All, Thank you for this new review. Please find below [FJ] how we intend to address the comments in a new versi= on If all co-authors agree, we will update with Yuji the new version BR, Fred =20 -----Original Message----- From: pwe3 [mailto:pwe3-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Monday, 31 March 2014 18:28 To: draft-ietf-pwe3-p2mp-pw-requirements.all@tools.ietf.org Cc: rtg-dir@ietf.org; pwe3@ietf.org Subject: [PWE3] Danny McPherson's Rtg-Dir review of draft-ietf-pwe3-p2mp-pw= -requirements draft-ietf-pwe3-p2mp-pw-requirements Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related draf= ts as they pass through IETF last call and IESG review, and sometimes on sp= ecial request. The purpose of the review is to provide assistance to the R= outing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other comments tha= t you receive, and strive to resolve them through discussion or by updating= the draft as appropriate. =20 =20 Document: http://tools.ietf.org/html/draft-ietf-pwe3-p2mp-pw-requirements-0= 7 Reviewer: Danny McPherson Review Date: March 31, 2014 Intended Status: Informational Document Overview: This document presents a set of requirements and a frame= work for providing a P2MP PWs over MPLS PSNs. A P2MP PW is a mechanism tha= t emulates the essential attributes of a P2MP telecommunications service su= ch as a P2MP ATM VC over a PSN. The I-D describes the general architecture= for P2MP PWs with a reference model, discusses data encapsulation, and out= lines specific requirements for setup and maintenance of P2MP PWs, with a f= ocus only on Single-Segment PWs. This version was lasted updated in Februa= ry of 2014, although it has existed as a PWE3 WG document since March 2009,= and as an individual contribution (draft-jounay-pwe3-p2mp-pw-requirements)= since February of 2007. Among other applications, it provides primitives = that can be employed for Virtual Private LAN and Virtual Private Multicast = services, such as those specified in the L2VPN WG. =20 I have no substantial concerns with this document. There are several comme= nts and nits below.=20 1. I am not sure if from an IPR perspective the claims regarding IPR that a= pparently no longer apply to this version of the document need to be explic= itly acknowledged as such by the relevant co-authors? Nits =3D=3D=3D General: 1. Only single-segment PWs are addressed, not multi-segment PWs. I underst= and why this is the case currently although I wonder if the requirement aki= n to "a single NMS" such as provided in S.4 should be conveyed forward? I = suppose it should simply be out of scope. [FJ] Indeed this section was meaningful when MS-PW was considered. I don't = see the added value of this chapter in the case SS-PW. I'd suggest to remov= e the section 4 "Manageability considerations"=20 2. In order to align with descriptive text in S3.1 it might be useful if th= e Reference Model in Figure 1 depicted where root and leaf PEs reside in th= e topology, and perhaps also that multiple CEs could be downstream from a s= ingle leaf PE (the latter point Farrel made in his AD review as well, IIRC)= . [FJ] I agree with the proposal to show 2 CEs behinf one Leaf PE, as descri= bed in http://tools.ietf.org/html/draft-ietf-pwe3-p2mp-pw-requirements-00 .= =20 I'd suggest we add ROOT and LEAF, as follows |<-----------P2MP PW -------------->| Native | = | Native ROOT Service | |<----P2MP PSN tunnel --->| | Service = LEAF V (AC) V V = V V (AC) V =20 --- S 3.2:=20 - A single P2MP PSN tunnel MUST be able to serve more than one P2MP PW traffi= c in an aggregated way, i.e., multiplexing - "not destined to Leaf PE at the service layer." reads a bit odd and ambiguo= us, might use a bit of expansion. =20 [FJ] we might rephrase it. "but using this P2MP LSP would imply non-Leaf PEs (i.e. not part of the P2M= P PW) to receive unwanted traffic" --- S 3.4.6:=20 - "In the example depicted below, a standby P2MP PW is used to protect the ac= tive P2MP." -- might consider adding a "PW" after the last P2MP in this se= ntence. [FJ] agreed "In the example depicted below, a standby P2MP PW is used to protect the ac= tive P2MP PW." =20 - It might be useful to identify the "leaf" and "root" layer in Figure 3 & 4 = as well. [FJ] agreed to add ROOT at the top and LEAF at the bottom of the figures. (= I'd prefer this solution than adding new acronyms in the Terminology sectio= n. _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From nobody Tue Apr 1 04:37:10 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B72A81A7006; Tue, 1 Apr 2014 04:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOcOzCIZ6i39; Tue, 1 Apr 2014 04:36:58 -0700 (PDT) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 799441A6FF0; Tue, 1 Apr 2014 04:36:58 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id i13so9272550qae.19 for ; Tue, 01 Apr 2014 04:36:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=U8oChl3DTrBZyBBp0qZ5pq1PiOftWiE2KlWxdm0qWV4=; b=ZzfOlSQA/KQixJpBKcKJKfbIGj3bI3jrCdvADT3JqjU2E1yWY1xuEA949AjfDKstsM A1qkYQvB9JMMkq8d+FBRTLZ4c0HrYh610pTwWPHU3Mxcr9VraeOlj7tkO/b0rzceh/no uMRb2rHoCqTKnILXFXDqYM/RduasMYpSth9MX7e8G6LWjwzMGFvP41kCYyhqtUX475wY mHgARW+qmicbsGKmxkUjFnGq6ezrYw8sWDOkYj0RRouFu4EdKVzGcAfFWhkQB5hyEVXm y+HjW4mYs2YFT/9e1rE+SvzByypFMuWLV1Ngpq58mxPjjaXZYRhqnVH9rcR+azVhyexT JqNA== X-Received: by 10.140.20.36 with SMTP id 33mr15040874qgi.37.1396352214863; Tue, 01 Apr 2014 04:36:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.205.69 with HTTP; Tue, 1 Apr 2014 04:36:34 -0700 (PDT) In-Reply-To: <78046FD1C8FE0345AFBC11640A8DF6E201864A00807C@CHCROCHC051.orange.ch> References: <022001cf4cfe$25fd5fc0$71f81f40$@olddog.co.uk> <78046FD1C8FE0345AFBC11640A8DF6E201864A00807C@CHCROCHC051.orange.ch> From: "Andrew G. Malis" Date: Tue, 1 Apr 2014 07:36:34 -0400 Message-ID: To: =?ISO-8859-1?Q?Jounay_Fr=E9d=E9ric?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/j6j3wVw1Dy8xETTHRCjKG4UYqfQ Cc: "pwe3@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-pwe3-p2mp-pw-requirements.all@tools.ietf.org" , Danny McPherson Subject: Re: [PWE3] Danny McPherson's Rtg-Dir review of draft-ietf-pwe3-p2mp-pw-requirements X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 11:37:01 -0000 Fred, Thanks! Also don't forget to address Adrian's comments from March 13, and Brian Carpenter's comments from March 18. Cheers, Andy On Tue, Apr 1, 2014 at 4:12 AM, Jounay Fr=E9d=E9ric wrote: > Hi Adrian, Danny, All, > > Thank you for this new review. > Please find below [FJ] how we intend to address the comments in a new ver= sion > If all co-authors agree, we will update with Yuji the new version > > BR, > Fred > > -----Original Message----- > From: pwe3 [mailto:pwe3-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: Monday, 31 March 2014 18:28 > To: draft-ietf-pwe3-p2mp-pw-requirements.all@tools.ietf.org > Cc: rtg-dir@ietf.org; pwe3@ietf.org > Subject: [PWE3] Danny McPherson's Rtg-Dir review of draft-ietf-pwe3-p2mp-= pw-requirements > > draft-ietf-pwe3-p2mp-pw-requirements > > Hello, > I have been selected as the Routing Directorate reviewer for this draft. > > The Routing Directorate seeks to review all routing or routing-related dr= afts as they pass through IETF last call and IESG review, and sometimes on = special request. The purpose of the review is to provide assistance to the= Routing ADs. > For more information about the Routing Directorate, please see > > http://www.ietf.org/iesg/directorate/routing.html > > Although these comments are primarily for the use of the Routing ADs, it = would be helpful if you could consider them along with any other comments t= hat you receive, and strive to resolve them through discussion or by updati= ng the draft as appropriate. > > Document: http://tools.ietf.org/html/draft-ietf-pwe3-p2mp-pw-requirements= -07 > > Reviewer: Danny McPherson > Review Date: March 31, 2014 > Intended Status: Informational > > Document Overview: This document presents a set of requirements and a fra= mework for providing a P2MP PWs over MPLS PSNs. A P2MP PW is a mechanism t= hat emulates the essential attributes of a P2MP telecommunications service = such as a P2MP ATM VC over a PSN. The I-D describes the general architectu= re for P2MP PWs with a reference model, discusses data encapsulation, and o= utlines specific requirements for setup and maintenance of P2MP PWs, with a= focus only on Single-Segment PWs. This version was lasted updated in Febr= uary of 2014, although it has existed as a PWE3 WG document since March 200= 9, and as an individual contribution (draft-jounay-pwe3-p2mp-pw-requirement= s) since February of 2007. Among other applications, it provides primitive= s that can be employed for Virtual Private LAN and Virtual Private Multicas= t services, such as those specified in the L2VPN WG. > > > I have no substantial concerns with this document. There are several com= ments and nits below. > > 1. I am not sure if from an IPR perspective the claims regarding IPR that= apparently no longer apply to this version of the document need to be expl= icitly acknowledged as such by the relevant co-authors? > > > Nits > =3D=3D=3D > > General: > > 1. Only single-segment PWs are addressed, not multi-segment PWs. I under= stand why this is the case currently although I wonder if the requirement a= kin to "a single NMS" such as provided in S.4 should be conveyed forward? = I suppose it should simply be out of scope. > [FJ] Indeed this section was meaningful when MS-PW was considered. I don'= t see the added value of this chapter in the case SS-PW. I'd suggest to rem= ove the section 4 "Manageability considerations" > > 2. In order to align with descriptive text in S3.1 it might be useful if = the Reference Model in Figure 1 depicted where root and leaf PEs reside in = the topology, and perhaps also that multiple CEs could be downstream from a= single leaf PE (the latter point Farrel made in his AD review as well, IIR= C). > [FJ] I agree with the proposal to show 2 CEs behinf one Leaf PE, as desc= ribed in http://tools.ietf.org/html/draft-ietf-pwe3-p2mp-pw-requirements-00= . > I'd suggest we add ROOT and LEAF, as follows > |<-----------P2MP PW -------------->= | > Native | = | Native > ROOT Service | |<----P2MP PSN tunnel --->| | Service = LEAF > V (AC) V V = V V (AC) V > > > > --- > S 3.2: > > - > A single P2MP PSN tunnel MUST be able to serve more than one P2MP PW traf= fic in an aggregated way, i.e., multiplexing > > - > "not destined to Leaf PE at the service layer." reads a bit odd and ambig= uous, might use a bit of expansion. > [FJ] we might rephrase it. > "but using this P2MP LSP would imply non-Leaf PEs (i.e. not part of the P= 2MP PW) to > receive unwanted traffic" > > --- > S 3.4.6: > > - > "In the example depicted below, a standby P2MP PW is used to protect the = active P2MP." -- might consider adding a "PW" after the last P2MP in this = sentence. > [FJ] agreed > "In the example depicted below, a standby P2MP PW is used to protect the = active P2MP PW." > > - > It might be useful to identify the "leaf" and "root" layer in Figure 3 & = 4 as well. > [FJ] agreed to add ROOT at the top and LEAF at the bottom of the figures.= (I'd prefer this solution than adding new acronyms in the Terminology sect= ion. > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From nobody Tue Apr 1 05:45:08 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4BB1A06BE for ; Tue, 1 Apr 2014 05:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.519 X-Spam-Level: X-Spam-Status: No, score=-1.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OswM5uIua5ph for ; Tue, 1 Apr 2014 05:45:04 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.174]) by ietfa.amsl.com (Postfix) with ESMTP id 715961A06C2 for ; Tue, 1 Apr 2014 05:45:03 -0700 (PDT) Received: from [195.245.230.51:3461] by server-14.bemta-3.messagelabs.com id 57/FA-30903-BC4BA335; Tue, 01 Apr 2014 12:44:59 +0000 X-Env-Sender: Frederic.Jounay@orange.ch X-Msg-Ref: server-7.tower-33.messagelabs.com!1396356298!4364758!3 X-Originating-IP: [213.55.206.8] X-StarScan-Received: X-StarScan-Version: 6.11.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7940 invoked from network); 1 Apr 2014 12:44:59 -0000 Received: from unknown (HELO chbbochs054.orange.ch) (213.55.206.8) by server-7.tower-33.messagelabs.com with RC4-SHA encrypted SMTP; 1 Apr 2014 12:44:59 -0000 Received: from CHCROCHC051.orange.ch ([fe80:0000:0000:0000:704b:3a68:12.14.247.83]) by chbbochs054.orange.ch ([172.25.9.54]) with mapi; Tue, 1 Apr 2014 14:44:40 +0200 From: =?iso-8859-1?Q?Jounay_Fr=E9d=E9ric?= To: "adrian@olddog.co.uk" , "draft-ietf-pwe3-p2mp-pw-requirements.all@tools.ietf.org" Date: Tue, 1 Apr 2014 14:44:39 +0200 Thread-Topic: [PWE3] AD review of draft-ietf-pwe3-p2mp-pw-requirements Thread-Index: Ac8+yi8VySw+Un7gRPmVXQov6Hu5pQO1edgA Message-ID: <78046FD1C8FE0345AFBC11640A8DF6E201864A00816F@CHCROCHC051.orange.ch> References: <1f5201cf3eca$eba049a0$c2e0dce0$@olddog.co.uk> In-Reply-To: <1f5201cf3eca$eba049a0$c2e0dce0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/r_1OXzS4-D3Hzu6Gxiz-ZoYDIAE Cc: "pwe3@ietf.org" Subject: Re: [PWE3] AD review of draft-ietf-pwe3-p2mp-pw-requirements X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 12:45:05 -0000 Hi Adrian, Sorry for this very late reply! Please find below [FJ] the way we intend to address your points in a new ve= rsion BR, Fred -----Original Message----- From: pwe3 [mailto:pwe3-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Thursday, 13 March 2014 15:46 To: draft-ietf-pwe3-p2mp-pw-requirements.all@tools.ietf.org Cc: pwe3@ietf.org Subject: [PWE3] AD review of draft-ietf-pwe3-p2mp-pw-requirements Hi, I have done my usual review as AD in support of the publication request for= this document. This is now a very solid document : all credit to the autho= rs and to Stewart's guidance. As I have only a few minor nits with the text (shown below) I will start th= e IETF last call and raise the issues there. You can address them together = with any other points that are raised during the last call. Thanks for the work, Adrian =3D=3D=3D PSN needs to be expanded in the title, Abstract, and Introduction. [FJ] Ok, I understand, replace PSNs by Packet Switch Networks Please check for other acronyms like OAM. [FJ] I'd suggest to replace "OAM" by "monitoring" --- Since this is not a protocol specification, the RFC 2119 language does not = apply in the way described in RFC 2119. I suggest you replace Section 1.3 w= ith something like... Although this is a requirements specification not a protocol=20 specification, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and=20 "OPTIONAL" in this document are to be interpreted to apply to=20 protocol solutions designed to meet these requirements as described in [RFC2119] . [FJ] Ok thanks --- I have a question about the architecture and model shown in Figure 1. Can the P2MP PW branch at an egress PE by having multiple attached ACs lead= ing to different CEs? Perhaps this does not count as a branch in the PW, but it is a branch in th= e service. [FJ] Correct. Initially we mixed the network enabler (PW) and the service. = That's the reason why we split the service definition (VPMS) in a separate = L2VPN draft http://tools.ietf.org/id/draft-ietf-l2vpn-vpms-frmwk-requirements-05.txt In other words we could show 2 CEs behind a Leaf PE, but the replication wi= ll be done statically if we talk about VPMS (PW to several ACs), or based o= n MAC forwarding for VPLS (PW-VSI-ACs) --- In Section 3.2 s/P-to-MP MPLS LSP/P2MP MPLS LSP/ [FJ] Ok --- Section 3.4.2 has... The Root PE and Leaf PEs of a P2MP PW MUST be configured with the same PW type as defined in [RFC4446] for P2P PW. In case of a different type, a PE MUST abort attempts to establish the P2MP PW. That seems a little drastic. Do you mean "MUST abort attempts to attach the= leaf PE to the PW"? [FJ] I'd suggest indeed to clarify=20 "SHOULD abort attempts to attach the leaf PE to the P2MP PW" Similarly in 3.4.3. MUST support mechanisms to reject attempts to establish the P2MP SS-PW. =3D=3D> SHOULD support mechanisms to reject attempts to attach the leaf PE to the P2MP PW=20 --- Section 4 might usefully refer back to the discussion of OAM. [FJ] as proposed in my previous email, I suggest to remove the section4, si= nce MS-PW is out of scope --- Section 5 is fine, but it is interesting to consider A solution MUST NOT allow a P2MP PW to be established to PEs that do not support P2MP PW functionality. It MUST have a mechanism to report an error for incompatible PEs. Does an egress PE even need to know that it is attached to a P2MP PW rather= than a P2P PW? [FJ] this is related to the fact that the P2MP PW gets a specific identifie= r (e.g. new FW) this requirement is referring to section 3.4.1 The P2MP PW MUST be uniquely identified. This unique P2MP PW identifier MUST be used for all signaling procedures related to this PW (PW setup, monitoring, etc). _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From nobody Tue Apr 1 20:32:05 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DAFB1A00C3 for ; Tue, 1 Apr 2014 20:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsi58hr-6nC7 for ; Tue, 1 Apr 2014 20:32:02 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA481A00BE for ; Tue, 1 Apr 2014 20:32:02 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFE11533; Wed, 02 Apr 2014 03:31:57 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 2 Apr 2014 04:31:04 +0100 Received: from SZXEMA407-HUB.china.huawei.com (10.82.72.39) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 2 Apr 2014 04:31:57 +0100 Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.41]) by SZXEMA407-HUB.china.huawei.com ([10.82.72.39]) with mapi id 14.03.0158.001; Wed, 2 Apr 2014 11:31:44 +0800 From: Jiangyuanlong To: "pwe3@ietf.org" Thread-Topic: New Version Notification for draft-jiang-pwe3-mc-pon-02.txt Thread-Index: AQHPTiJdkxc0QoAc+UKdmZNjolL0spr9qOTg Date: Wed, 2 Apr 2014 03:31:43 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B5A6F158D@szxema506-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.76.118] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/xZ-eREAWoMzaY2uf_WRJpNjj_ug Subject: [PWE3] FW: New Version Notification for draft-jiang-pwe3-mc-pon-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 03:32:04 -0000 SGkgY29sbGVhZ3VlcywNCiANCldlIGhhZCB1cGRhdGVkIHRoZSBkcmFmdCB0byBhIG5ldyByZXZp c2lvbi4gVGhlIG1haW4gdXBkYXRlcyBpbmNsdWRlOg0KMS4JQWRkIG1vcmUgYXBwbGljYXRpb24g c2NlbmFyaW9zLCBzdWNoIGFzIE1TTyBhbmQgRFNMOw0KMi4JQWRkIHN1cHBvcnQgdG8gYSBkZXBs b3ltZW50IHNjZW5hcmlvIG9mIHBhcnRseSBwcm90ZWN0aW9uIHJhaXNlZCBieSBzb21lIHNlcnZp Y2UgcHJvdmlkZXJzOw0KMy4JQWRkIENoZW5iaW4gYW5kIFlpbWluIHRvIG91ciBjby1hdXRob3Jz Ow0KNC4gIFN1YnN0YW50aWFsIGVkaXRvcmlhbCBjaGFuZ2VzLiANCg0KUGxlYXNlIGZlZWRiYWNr IHlvdSBvcGluaW9ucyBvbiB0aGlzIHZlcnNpb24uIFRoYW5rcyENCg0KUmVnYXJkcywNCll1YW5s b25nDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogV2VkbmVz ZGF5LCBBcHJpbCAwMiwgMjAxNCAxMToxOSBBTQ0KVG86IFlpbWluIFNoZW47IEx1b3lvbmcgKERl bm5pcyk7IENoZW5nYmluIFNoZW47IENoZW5nYmluIFNoZW47IEVkd2luIE1hbGxldHRlOyBZaW1p biBTaGVuOyBFZHdpbiBNYWxsZXR0ZTsgSmlhbmd5dWFubG9uZzsgSmlhbmd5dWFubG9uZzsgTHVv eW9uZyAoRGVubmlzKQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFm dC1qaWFuZy1wd2UzLW1jLXBvbi0wMi50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJh ZnQtamlhbmctcHdlMy1tYy1wb24tMDIudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0 dGVkIGJ5IFl1YW5sb25nIEppYW5nIGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnku DQoNCk5hbWU6CQlkcmFmdC1qaWFuZy1wd2UzLW1jLXBvbg0KUmV2aXNpb246CTAyDQpUaXRsZToJ CU11bHRpLWNoYXNzaXMgUE9OIFByb3RlY3Rpb24gaW4gTVBMUw0KRG9jdW1lbnQgZGF0ZToJMjAx NC0wNC0wMg0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMTUNClVSTDog ICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1qaWFu Zy1wd2UzLW1jLXBvbi0wMi50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1qaWFuZy1wd2UzLW1jLXBvbi8NCkh0bWxpemVkOiAgICAgICBo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1qaWFuZy1wd2UzLW1jLXBvbi0wMg0KRGlm ZjogICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWppYW5n LXB3ZTMtbWMtcG9uLTAyDQoNCkFic3RyYWN0Og0KICAgTVBMUyBpcyBiZWluZyBkZXBsb3llZCBk ZWVwZXIgaW50byBvcGVyYXRvciBuZXR3b3Jrcywgb2Z0ZW4gdG8gb3INCiAgIHBhc3QgdGhlIGFj Y2VzcyBuZXR3b3JrIG5vZGUuIFNlcGFyYXRlbHkgbmV0d29yayBhY2Nlc3Mgbm9kZXMgc3VjaCBh cw0KICAgUE9OIE9MVHMgaGF2ZSBldm9sdmVkIHRvIHN1cHBvcnQgZmlyc3QtbWlsZSBhY2Nlc3Mg cHJvdGVjdGlvbiwgd2hlcmUNCiAgIG9uZSBvciBtb3JlIHBoeXNpY2FsIE9MVHMgcHJvdmlkZSBm aXJzdC1taWxlIGRpdmVyc2l0eSB0byB0aGUNCiAgIGN1c3RvbWVyIGVkZ2UuIE11bHRpLWhvbWlu ZyBzdXBwb3J0IGlzIG5lZWRlZCBvbiB0aGUgTVBMUy1lbmFibGVkIFBPTg0KICAgT0xUIHRvIHBy b3ZpZGUgcmVzaWxpZW5jeSBmb3IgcHJvdmlkZWQgc2VydmljZXMuICBUaGlzIGRvY3VtZW50DQog ICBkZXNjcmliZXMgdGhlIG11bHRpLWNoYXNzaXMgUE9OIHByb3RlY3Rpb24gYXJjaGl0ZWN0dXJl IGluIE1QTFMgYW5kDQogICBhbHNvIHByb3Bvc2VzIHRoZSBJQ0NQIGV4dGVuc2lvbiB0byBzdXBw b3J0IGl0Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhh dCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlz c2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBh dCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Wed Apr 2 08:17:48 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 353961A09A8 for ; Tue, 1 Apr 2014 13:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.182 X-Spam-Level: * X-Spam-Status: No, score=1.182 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CSXXjxbMFChc for ; Tue, 1 Apr 2014 13:35:27 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 00B431A06BC for ; Tue, 1 Apr 2014 13:35:26 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s31KZLKB009208; Tue, 1 Apr 2014 21:35:21 +0100 Received: from 950129200 (13.17.90.92.rev.sfr.net [92.90.17.13]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s31KZJnq009186 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 1 Apr 2014 21:35:20 +0100 From: "Adrian Farrel" To: "=?iso-8859-1?Q?'Jounay_Fr=E9d=E9ric'?=" , , Date: Tue, 1 Apr 2014 21:35:19 +0100 Message-ID: <03a601cf4de9$e70818e0$b5184aa0$@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac9N6d9//rrcMue/QOykKn25Lm64jw== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20604.002 X-TM-AS-Result: No--26.497-10.0-31-10 X-imss-scan-details: No--26.497-10.0-31-10 X-TMASE-MatchedRID: SPXcha2wtZwyILr4PJc84Zs6sZ5vv7JIL0W1btd8e567vYqkCS0dLyse SAhqf1rRjm39dGqS3EnC5qeIz1BfLRsb25VnKbHqFyCVjv7dlo5s2M2McsO4c7xygpRxo4691kq yrcMalqUJr7cROZw/Euln+pgUTqXBJKelhEebHIoef9c7rUhRis7MWnfHypaGVo6mn+xXmdVA8J ZETQujwnRylc22tUP9KDkR2MDyn9yZ7u9J1wO1FAGkCPmxxtsmAKUSAotbeK1IcJTn2HkqsVHug oq79gL3sp5O052MzLqnvg2KCDOgGMXTAxA0oGwPme+eAhDE8eG8IZRb58AS8JN3sInxtjDTzVE3 gQTykCpI7YhsiSUzzKoVAx6sG8NJ7nuvY9DN2ad6dw/Z0kaNjIiceOuNnLyWZg1i2wTmScMIjen 4m7yaqlmmz7LVVfOpdn5HTOCw5bg96zU47uG0L08QNHBMjhQJF8HvX707rXPLpOrhPJsejx9fNW A7SFWqRJWmeOMHa+QBEmLMXrtRo82jQFciNcCtRHLWdqSGmxbvnOSC+jk4DqytfdfXBswyu2rcU 2ygxCD1gF7PCEF9bkrF3QU4ybvDj1mbw6/tKms8MXho6UtjB0qXm4MPqTr2ngIgpj8eDcBjZ/Fz 4gCyG/oA9r2LThYYKrauXd3MZDUD/dHyT/Xh7Q== Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/hVV5Mj0vumH3-QAbH4N2PFNsp2s X-Mailman-Approved-At: Wed, 02 Apr 2014 08:17:45 -0700 Cc: pwe3@ietf.org Subject: Re: [PWE3] AD review of draft-ietf-pwe3-p2mp-pw-requirements X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: afarrel@juniper.net List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 20:35:30 -0000 Hi Fred, This is all good with me. Looking forward to the new revision when it is posted. Thanks, Adrian > -----Original Message----- > From: Jounay Fr=E9d=E9ric [mailto:Frederic.Jounay@orange.ch] > Sent: 01 April 2014 13:45 > To: adrian@olddog.co.uk; draft-ietf-pwe3-p2mp-pw- > requirements.all@tools.ietf.org > Cc: pwe3@ietf.org; Andrew G. Malis (agmalis@gmail.com) > Subject: RE: [PWE3] AD review of draft-ietf-pwe3-p2mp-pw-requirements >=20 > Hi Adrian, >=20 > Sorry for this very late reply! > Please find below [FJ] the way we intend to address your points in a = new version >=20 > BR, > Fred >=20 > -----Original Message----- > From: pwe3 [mailto:pwe3-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: Thursday, 13 March 2014 15:46 > To: draft-ietf-pwe3-p2mp-pw-requirements.all@tools.ietf.org > Cc: pwe3@ietf.org > Subject: [PWE3] AD review of draft-ietf-pwe3-p2mp-pw-requirements >=20 > Hi, >=20 > I have done my usual review as AD in support of the publication = request for this > document. This is now a very solid document : all credit to the = authors and to > Stewart's guidance. >=20 > As I have only a few minor nits with the text (shown below) I will = start the IETF > last call and raise the issues there. You can address them together = with any other > points that are raised during the last call. >=20 > Thanks for the work, > Adrian >=20 > =3D=3D=3D >=20 > PSN needs to be expanded in the title, Abstract, and Introduction. > [FJ] Ok, I understand, replace PSNs by Packet Switch Networks >=20 > Please check for other acronyms like OAM. > [FJ] I'd suggest to replace "OAM" by "monitoring" > --- >=20 > Since this is not a protocol specification, the RFC 2119 language does = not apply in > the way described in RFC 2119. I suggest you replace Section 1.3 with something > like... >=20 > Although this is a requirements specification not a protocol > specification, the key words "MUST", "MUST NOT", "REQUIRED", = "SHALL", > "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted to apply to > protocol solutions designed to meet these requirements as described > in [RFC2119] . > [FJ] Ok thanks >=20 > --- >=20 > I have a question about the architecture and model shown in Figure 1. > Can the P2MP PW branch at an egress PE by having multiple attached ACs = leading > to different CEs? >=20 > Perhaps this does not count as a branch in the PW, but it is a branch = in the > service. > [FJ] Correct. Initially we mixed the network enabler (PW) and the = service. That's > the reason why we split the service definition (VPMS) in a separate = L2VPN draft > = http://tools.ietf.org/id/draft-ietf-l2vpn-vpms-frmwk-requirements-05.txt > In other words we could show 2 CEs behind a Leaf PE, but the = replication will be > done statically if we talk about VPMS (PW to several ACs), or based on = MAC > forwarding for VPLS (PW-VSI-ACs) >=20 > --- >=20 > In Section 3.2 >=20 > s/P-to-MP MPLS LSP/P2MP MPLS LSP/ > [FJ] Ok > --- >=20 > Section 3.4.2 has... >=20 > The Root PE and Leaf PEs of a P2MP PW MUST be configured with the > same PW type as defined in [RFC4446] for P2P PW. In case of a > different type, a PE MUST abort attempts to establish the P2MP PW. >=20 > That seems a little drastic. Do you mean "MUST abort attempts to = attach the leaf > PE to the PW"? > [FJ] I'd suggest indeed to clarify > "SHOULD abort attempts to attach the leaf PE to the P2MP PW" >=20 > Similarly in 3.4.3. > MUST support mechanisms to reject attempts to > establish the P2MP SS-PW. > =3D=3D> > SHOULD support mechanisms to reject attempts to > attach the leaf PE to the P2MP PW >=20 > --- >=20 > Section 4 might usefully refer back to the discussion of OAM. > [FJ] as proposed in my previous email, I suggest to remove the = section4, since > MS-PW is out of scope > --- >=20 > Section 5 is fine, but it is interesting to consider >=20 > A solution MUST NOT allow a P2MP PW to be established to PEs that = do > not support P2MP PW functionality. It MUST have a mechanism to > report an error for incompatible PEs. >=20 > Does an egress PE even need to know that it is attached to a P2MP PW = rather > than a P2P PW? > [FJ] this is related to the fact that the P2MP PW gets a specific = identifier (e.g. new > FW) > this requirement is referring to section 3.4.1 > The P2MP PW MUST be uniquely identified. This unique P2MP PW > identifier MUST be used for all signaling procedures related to = this > PW (PW setup, monitoring, etc). >=20 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From nobody Fri Apr 4 10:52:36 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49E131A0235 for ; Fri, 4 Apr 2014 10:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXZABdmLbUoW for ; Fri, 4 Apr 2014 10:52:31 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id B183C1A0452 for ; Fri, 4 Apr 2014 10:52:27 -0700 (PDT) X-AuditID: c618062d-b7fbd8e000003171-ae-533eef04942d Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id AD.23.12657.40FEE335; Fri, 4 Apr 2014 19:42:28 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0174.001; Fri, 4 Apr 2014 13:52:21 -0400 From: Gregory Mirsky To: "draft-ietf-pwe3-vccv-for-gal@tools.ietf.org" , "pwe3@ietf.org" Thread-Topic: [PWE3] WG Last Call for draft-ietf-pwe3-vccv-for-gal-01.txt Thread-Index: AQHPT6uzkKHgUgZGSECCh4/w7tmWNpsBuIUw Date: Fri, 4 Apr 2014 17:52:21 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B78DEC6@eusaamb103.ericsson.se> References: <07F7D7DED63154409F13298786A2ADC9043D1F4A@EXRAD5.ad.rad.co.il> <227FF1F3-72B8-4B44-A89D-BF4ED3902435@cisco.com> <5E889EDF-82C4-4B32-BBBA-D5C8AE3A5A2A@lucidvision.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B78DEC6eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUyuXRPrC7Le7tgg/0LZSwWPDjDatH3aQuL A5PHkiU/mTy+XP7MFsAUxWWTkpqTWZZapG+XwJWx+fBNtoIZU5kr7syayNjAeKGLuYuRk0NC wERi8ZH/TBC2mMSFe+vZuhi5OIQEjjJKPNjXAeUsY5Q4/fIMI0gVm4CRxIuNPewgCRGBFkaJ e7fns4IkhAU8JNq+3WIHsUUEPCVm7tjCAmEbSXR+vwwWZxFQkTizu48NxOYV8JW4cH4lM8SG s8wSfz+8BhrEwcEpECgxsdUPpIYR6KTvp9aAnccsIC5x68l8qFMFJJbsOQ/1gqjEy8f/WCFs RYl9/dPZIerzJdpuN7NA7BKUODnzCcsERpFZSEbNQlI2C0nZLKArmAU0Jdbv0ocoUZSY0v2Q HcLWkGidM5cdWXwBI/sqRo7S4tSy3HQjg02MwBg6JsGmu4Nxz0vLQ4zSHCxK4rxf3joHCQmk J5akZqemFqQWxReV5qQWH2Jk4uCUamBcuvTZgd0i/Gyp6yxu6J5jV1VrszDWUjYx1O9mX3E4 7d7xqKO+exQVjdm3qL7klIrUnyViK7nivMP1Pbf/VK6pnbjp+PHUqZ1y3bqvG96xlPL8Kp18 fqXbXNPUj+xHN0x1+Mnx4drnV4kdVyzO/WtWDzojwBnxTXWX6fK9z6+9lOjnnzI5Z1eWEktx RqKhFnNRcSIAmoZCzG8CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/mcJXykdI8Vr7saHdFaYVhkhGl8A Subject: [PWE3] FW: WG Last Call for draft-ietf-pwe3-vccv-for-gal-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 17:52:35 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B78DEC6eusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBBdXRob3JzLCBldC4gYWwsDQppbiBMb25kb24gd2XigJl2ZSBkaXNjdXNzZWQgd29yayBv biB0aGUgVkNDViBDb250cm9sIENoYW5uZWwgVHlwZSA0LiBJIHRob3VnaHQgdGhhdCB0aGVzZSBj b21tZW50cyBmcm9tIGxvbmcgYWdvIG1heSBiZSBoZWxwZnVsIGluIHlvdXIgd29yayBvbiB0aGUg bmV4dCB2ZXJzaW9uIG9mIHRoZSBkb2N1bWVudC4NCg0KICAgICAgICAgICAgICAgIFJlZ2FyZHMs DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEdyZWcNCg0KLS0tLS0tLS0tLSBGb3J3 YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0tDQpGcm9tOiBHcmVnb3J5IE1pcnNreSA8Z3JlZ29yeS5t aXJza3lAZXJpY3Nzb24uY29tPG1haWx0bzpncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb20+Pg0K RGF0ZTogVHVlLCBNYXkgMjksIDIwMTIgYXQgMTE6NTQgQU0NClN1YmplY3Q6IFJlOiBbUFdFM10g V0cgTGFzdCBDYWxsIGZvciBkcmFmdC1pZXRmLXB3ZTMtdmNjdi1mb3ItZ2FsLTAxLnR4dA0KVG86 IFRob21hcyBOYWRlYXUgPHRuYWRlYXVAbHVjaWR2aXNpb24uY29tPG1haWx0bzp0bmFkZWF1QGx1 Y2lkdmlzaW9uLmNvbT4+DQpDYzogQ2FybG9zIFBpZ25hdGFybyA8Y3BpZ25hdGFAY2lzY28uY29t PG1haWx0bzpjcGlnbmF0YUBjaXNjby5jb20+PiwgWWFha292IFN0ZWluIDx5YWFrb3Zfc0ByYWQu Y29tPG1haWx0bzp5YWFrb3Zfc0ByYWQuY29tPj4sICJwd2UzQGlldGYub3JnPG1haWx0bzpwd2Uz QGlldGYub3JnPiIgPHB3ZTNAaWV0Zi5vcmc8bWFpbHRvOnB3ZTNAaWV0Zi5vcmc+Pg0KDQpEZWFy IFRvbSwNCmFwb2xvZ2llcyBhbmQgcGxlYXNlIGZpbmQgbXkgY29tbWVudHMgYmVsb3cgKHNvbWUg aWYgbm90IG1vc3QgbWlnaHQgZHVwbGljYXRlIHdoYXQgYWxyZWFkeSB3YXMgbm90ZWQgYnkgWWFh Y292IGFuZCBDYXJsb3MpOg0KDQogICogICBBYnN0cmFjdCAiVGhpcyBkb2N1bWVudCBkZXNjcmli ZXMgYSB1bmlmaWVkIG1vZGUgb2Ygb3BlcmF0aW9uIGZvciBWaXJ0dWFsIENpcmN1aXQgQ29ubmVj dGl2aXR5IFZlcmlmaWNhdGlvbiAoVkNDVikgLi4uIiBJTUhPLCBhZ3JlZW1lbnQgb2YgV0cgZGlz Y3Vzc2lvbiBpbiBQYXJpcyB3YXMgdG8gbGltaXQgZG9jdW1lbnQgc2NvcGUgdG8gaW50cm9kdWN0 aW9uIG9mIENvbnRyb2wgQ2hhbm5lbCBUeXBlIDQgZm9yIFBXIFZDQ1YgYW5kIGFkZHJlc3MgdW5p ZmllZCBvcGVyYXRpb24gb2YgQ0MgVkNDViBpbiBSRkMgNTA4NWJpcy4NCiAgKiAgICBBYnN0cmFj dCAiVGhlIG9sZGVyIHR5cGVzIHdpbGwgcmVtYWluIG9wdGlvbmFsLiIgSU1ITywgdGhlIFdHIGFn cmVlZCB0byBvYnNvbGV0ZSBUeXBlIDIgQ0MgUFcgVkNDVi4NCiAgKiAgIEludHJvZHVjdGlvbiAi VGhpcyBkb2N1bWVudCBhbmQgdGhlIGltcGxlbWVudGF0aW9uIHN1cnZleSBjb25jbHVkZWQgLi4u IjoNCg0KICAgICAqICAgIlRoaXMgZG9jdW1lbnQiIGFzIEEgVW5pZmllZCBDb250cm9sIENoYW5u ZWwgZm9yIFBzZXVkb3dpcmVzPw0KICAgICAqICAgQmVzaWRlcywgSSBiZWxpZXZlIHRoYXQgaWYg dGhlIGFjY2VwdGFuY2Ugb2YgTWFuZGF0b3J5IFVzZSBvZiBDb250cm9sIFdvcmQgZm9yIFBXRTMg RW5jYXBzdWxhdGlvbnMgd2lsbCBtYWtlIGRyYWZ0LWlldGYtcHdlMy12Y2N2LWZvci1nYWwtIHVu bmVjZXNzYXJ5LiBSZWZlcmVuY2UgdG8gdGhlIGltcGxlbWVudGF0aW9uIHN1cnZleSBkcmFmdC1p ZXRmLXB3ZTMtdmNjdi1pbXBsLXN1cnZleS1yZXN1bHRzLTAwIGlzIG1pc3NpbmcuDQogICAgICog ICBJIGRvbid0IHNlZSB0aGF0IHRoZSAiVGhlIFBzZXVkb3dpcmUgKFBXKSAmIFZpcnR1YWwgQ2ly Y3VpdCBDb25uZWN0aXZpdHkgVmVyaWZpY2F0aW9uIChWQ0NWKSBJbXBsZW1lbnRhdGlvbiBTdXJ2 ZXkgUmVzdWx0cyIgbWFkZSBzdWdnZXN0ZWQgY29uY2x1c2lvbi4NCg0KICAqICAgSW50cm9kdWN0 aW9uICIuLi4gdGhlIElUVS1UIGFuZCBJRVRGIGhhdmUgc2V0IG91dCB0byBlbmhhbmNlIE1QTFMg dG8gbWFrZSBpdCBzdWl0YWJsZSBhcyBhbiBvcHRpY2FsIHRyYW5zcG9ydCBwcm90b2NvbCAuLi4i IFBlcmhhcHMgc2hvdWxkIGJlICJwYWNrZXQgdHJhbnNwb3J0Ii4NCiAgKiAgIEludHJvZHVjdGlv biAiSW4gb3JkZXIgdG8gc3VwcG9ydCBWQ0NWIHdoZW4gYW4gTVBMUy1UUCBQU04gaXMgaW4gdXNl LCB0aGUgR0FMLUFDSCBoYWQgdG8gYmUgY3JlYXRlZCAuLi4iIEctQUNoIHdhcyBjcmVhdGVkIGZv ciBNUExTLVRQIExTUCwgbm90IFBXLiBQVyBWQ0NWIHdoZW4gUFNOIGlzIE1QTFMtVFAgY2FuIHVz ZSBhbnkgb2YgZGVzY3JpYmVkIGluIFJGQyA1MDg1IGNvbnRyb2wgY2hhbm5lbCB0eXBlcy4NCiAg KiAgIEludHJvZHVjdGlvbiAiVGhpcyBkb2N1bWVudCBkZWZpbmVzIHR3byBtb2RlcyBvZiBvcGVy YXRpb24gb2YgVkNDViAuLi4iIFdoZXJlIHRoZSBkb2N1bWVudCBsZWF2ZXMgQ0MgVHlwZSAzPyBJ c24ndCBpdCB2YWxpZCBtb2RlIG9mIFBXIFZDQ1Ygb3BlcmF0aW9uIHRoYXQgdGhlIFBXRTMgV0cg ZGVjaWRlZCB0byBrZWVwPw0KICAqICAgSW50cm9kdWN0aW9uICJJbiBlaXRoZXIgY2FzZSwgaXQg d2lsbCBiZSBtYW5kYXRvcnkgdG8gaW1wbGVtZW50IGFuZCB1c2UgdGhhdCBtb2RlIHVuZGVyIHRo YXQgc2NlbmFyaW8uIiBBZ2FpbiwgdGhpcyBjb25jbHVzaW9uIGlzIG5vdCBpbiBzeW5jIHdpdGgg d2hhdCB3YXMgYWdyZWVkIGF0IFBXRTMgV0cgbWVldGluZyBpbiBQYXJpcy4NCiAgKiAgIFNlY3Rp b24gMiAiLi4uIEFzc29jaWF0ZWQgQ2hhbm5lbCBUeXBlcyBvZiAyMSwgMDcsIG9yIDU3IGFyZSBh bGxvd2VkIiBGaXJzdGx5LCBpdCBzaG91bGQgYmUgIjB4MDAyMSwgMHgwMDcsIG9yIDB4MDA1NyIu IFNlY29uZGx5LCB3aHkgMHgwMDBBLCAweDAwMEIsIDB4MDAwQywgMHgwMDBELCAweDAwMEUsIDB4 MDAyMiwgMHgwMDIzLCAweDAwMjQsIDB4MDAyNSwgMHgwMDI2LCAweDAwMjcsIGFuZCAweDAwNTgg d291bGQgbm90IGJlIGxpc3RlZCBhcyB2YWxpZCBBQ0ggdHlwZXM/DQogICogICBTZWN0aW9uIDMg IkluIHRoZSBjYXNlIG9mIG11bHRpLXNlZ21lbnQgcHNldWRvLXdpcmVzLCB0aGUgUFcgTGFiZWwg VFRMIE1VU1QgYmUgc2V0IHRvIHRoZSBjb3JyZWN0IHZhbHVlIHRvIHJlYWNoIHRoZSBpbnRlbmRl ZCBkZXN0aW5hdGlvbiBQRSBhcyBkZXNjcmliZWQgaW4gW1JGQzYwNzM8aHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvcmZjNjA3Mz5dIiBUaGlzIHNlZW1zIHRvIGV4Y2x1ZGUgVkNDViBDQyBUeXBl IDMgZnJvbSBiZWluZyB1c2VkIGluIGNvbmp1bmN0aW9uIHdpdGggR0FMIGV2ZW4gdGhvdWdoIFNl Y3Rpb24gNS4xLjMgb2YgUkZDIDUwODUgZXhwbGljaXRseSBhbGxvd3MgY29tYmluYXRpb24gb2Yg UFcgVkNDViBDb250cm9sIENoYW5uZWxzIFR5cGUgMSBhbmQgVHlwZSAzLg0KICAqICAgU2VjdGlv biAzICJUaGUgR0FMIGZpZWxkIC4uLiIgR2VuZXJpYyBBc3NvY2lhdGVkIENoYW5uZWwgTGFiZWwg KEdBTCkgaXMgbm90IGEgZmllbGQgYnV0IHBhcnQgb2YgTVBMUyBsYWJlbCBzdGFjayBlbnRyeS4g V2hhdCBhcmUgdmFsdWVzIG9mIG90aGVyIGZpZWxkcyBvZiB0aGUgbGFiZWwgc3RhY2sgZW50cnkg d2l0aCB0aGUgR0FMIC0gVEMsIFMsIFRUTD8NCiAgKiAgIFNlY3Rpb24gMyAiVGhlIGZpcnN0IG5p YmJsZSBvZiB0aGUgbmV4dCBmaWVsZCBpcyBzZXQgdG8gMDAwMWIgLi4uIiBEb2VzIHRoYXQgaW1w bHkgdGhhdCBHQUwgTVVTVCBiZSBCT1MgbGFiZWwgYW5kIHRodXMgUz0xPw0KICAqICAgU2VjdGlv biA0ICJJZiB0aGUgYy1iaXQgaXMgbm90IHNldCwgaW5kaWNhdGluZyB0aGF0IHRoZSBjb250cm9s IHdvcmQgaXMgbm90IGluIHVzZSwgdHlwZSA0IE1VU1QgYmUgYWR2ZXJ0aXNlZCwgYW5kIHR5cGUg MSBNVVNUIE5PVCBiZSBhZHZlcnRpc2VkLiIgSSB0aGluayB0aGF0IHdoZXRoZXIgVHlwZSA0IE1V U1QsU0hBTEwgb3IgTUFZIGJlIGFkdmVydGlzZWQgKGRvIG5vdCBmb3JnZXQgVHlwZSAzKSwgc2hv dWxkIGJlIGFkZHJlc3NlZCBpbiBSRkMgNTA4NWJpcy4NCiAgICBSZWdhcmRzLA0KICAgICAgICBH cmVnDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogVGhvbWFzIE5hZGVh dSBbbWFpbHRvOnRuYWRlYXVAbHVjaWR2aXNpb24uY29tPG1haWx0bzp0bmFkZWF1QGx1Y2lkdmlz aW9uLmNvbT5dDQpTZW50OiBUdWVzZGF5LCBNYXkgMjksIDIwMTIgNTo1NCBBTQ0KVG86IEdyZWdv cnkgTWlyc2t5DQpDYzogQ2FybG9zIFBpZ25hdGFybzsgWWFha292IFN0ZWluOyBwd2UzQGlldGYu b3JnPG1haWx0bzpwd2UzQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSZTogW1BXRTNdIFdHIExhc3Qg Q2FsbCBmb3IgZHJhZnQtaWV0Zi1wd2UzLXZjY3YtZm9yLWdhbC0wMS50eHQNCg0KDQpHZW5lcmlj IHN0YXRlbWVudHMgbGlrZSB0aGlzIGFyZSBub3QgdXNlZnVsIGF0IHRoaXMgcG9pbnQgaW4gdGhl IHByb2Nlc3M7IHBsZWFzZSBiZSBzcGVjaWZpYyBhbmQgd2hhdCB5b3Ugb2JqZWN0IHRvIGFuZCB3 aGF0IGNoYW5nZXMgeW91IHByb3Bvc2UgdG8gY29ycmVjdCB0aGVtLiBUaGlzIHdpbGwgYWxsb3cg dGhlIFdHIHRvIGRpc2N1c3MgYW55IGNoYW5nZXMgb24gdGhlIGxpc3QgaWYgdGhleSBhcmUgbWFq b3IuIFdoYXQgd2Ugd2FudCB0byBhdm9pZCBpcyBtYWtpbmcgY2hhbmdlcyBvbiB0aGUgc2FtZSBp c3N1ZSBtdWx0aXBsZSB0aW1lcyBkdWUgdG8gbXVsdGlwbGUgY29uZmxpY3RpbmcgY2hhbmdlIHJl cXVlc3RzLCBvciBhdHRlbXB0aW5nIHRvIGZpeCBnZW5lcmljIGNvbW1lbnRzLg0KDQotLVRvbQ0K DQpEbyBub3Qgc3VwcG9ydCBhcyBpbiB0aGUgY3VycmVudCBmb3JtIGRvY3VtZW50IGdvZXMgYmV5 b25kIG1lcmUgZGVmaW5pdGlvbiBvZiB0aGUgbmV3IENvbnRyb2wgQ2hhbm5lbCB0eXBlIGZvciBW Q0NWLg0KQW5kIGNvbmN1ciB3aXRoIGNvbmNlcm5zIGV4cHJlc3NlZCBieSBZYWFjb3YgYW5kIENh cmxvcy4NCg0KICAgIFJlZ2FyZHMsDQogICAgICAgIEdyZWcNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCkZyb206IHB3ZTMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cHdlMy1i b3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOnB3ZTMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cHdl My1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIENhcmxvcyBQaWduYXRhcm8NClNlbnQ6 IEZyaWRheSwgTWF5IDI1LCAyMDEyIDc6MTUgQU0NClRvOiBZYWFrb3YgU3RlaW47IHB3ZTNAaWV0 Zi5vcmc8bWFpbHRvOnB3ZTNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1BXRTNdIFdHIExhc3Qg Q2FsbCBmb3IgZHJhZnQtaWV0Zi1wd2UzLXZjY3YtZm9yLWdhbC0wMS50eHQNClBXRTNlcnMsDQoN CkkgdG9vIGhhdmUgc3Ryb25nIGNvbmNlcm5zIGFib3V0IHRoaXMgZG9jdW1lbnQgYmVpbmcgV0dM Q2VkLg0KDQpBIG1ldGEtY29uY2VybiBjZW50ZXJzIGFyb3VuZCB0aGUgc2NvcGUgb2YgdGhpcyBk b2N1bWVudC4gTXkgdW5kZXJzdGFuZGluZyAoYW5kIHBsZWFzZSBjb3JyZWN0IHRoaXMgd2l0aCBh IGNpdGF0aW9uIGlmIEkgYW0gaW5jb3JyZWN0KSBpcyB0aGF0IHRoZXJlIHdhcyBjb25zZW5zdXMg Zm9yIHRoaXMgZG9jdW1lbnQgdG8gZGVmaW5lIGEgbmV3IENDIFR5cGUgNCB1c2luZyBHQUwsIGJ1 dCB0aGVyZSB3YXMgbm90IGNvbnNlbnN1cyB0byBoYXZlIHRoaXMgZG9jdW1lbnQgcmVkZWZpbmUg YWxsIENvbnRyb2wgQ2hhbm5lbHMgYW5kIHRoZWlyIHJlcXVpcmVtZW50IGxldmVscyAoaS5lLiwg ZGVwcmVjYXRpbmcgb3IgY3JlYXRpbmcgcnVsZXMgb2YgdXNlKS4NCg0KRnJvbSB0aGUgbWludXRl cyBhdCBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cvcHdlMy9taW51dGVzIHdlIGNhbiBzZWUgdGhh dDoNCg0KICAgICAgICAgIDIwPGh0dHA6Ly90b29scy5pZXRmLm9yZy93Zy9wd2UzL21pbnV0ZXMj c2VjdGlvbi0yMD4gbWluIC0gR2VuZXJhbCBkaXNjdXNzaW9uIG9uIFZDQ1YgZm9yIEdBTA0KDQog ICAgICAgICAgVGhlcmUgYXBwZWFyIHRvIGJlIHR3byBzZXBhcmF0ZSBpc3N1ZXMgb24gdGhlIHRh YmxlOg0KDQogICAgICAgICAgMTxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cvcHdlMy9taW51dGVz I3NlY3Rpb24tMT4uIFZDQ1Ygc3VwcG9ydCBmb3IgYSBQVyBhc3NvY2lhdGVkIGNoYW5uZWwgdGhh dCB1c2VzIHRoZSBHQUwgYXMgYW4NCg0KICAgICAgICAgIGFsZXJ0IG1lY2hhbmlzbXMgKFZDQ1Yg VHlwZSA0KS4gVGhpcyBpcyByZWFsbHkgdGhlIHN1YmplY3Qgb2YgdGhlIGRyYWZ0Lg0KDQogICAg ICAgICAgMjxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cvcHdlMy9taW51dGVzI3NlY3Rpb24tMj4u IFdoYXQgdG8gZG8gYWJvdXQgbGVnYWN5IG1vZGVzLCBwYXJ0aWN1bGFybHkgcm91dGVyIGFsZXJ0 IGFuZCBUVEwNCg0KICAgICAgICAgIGV4cGlyeS4gVGhpcyBpcyBhIHNlcGFyYXRlIGlzc3VlIHJl Z2FyZGluZyB0aGUgcHJvZ3Jlc3Mgb2YgUkZDNTA4NTxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bD9yZXBvc2l0b3J5PWh0dHA6Ly90b29scy5pZXRmLm9yZyZyZmM9NTA4NT4NCg0KICAgICAgICAg IChvciBzb21lIGZ1dHVyZSBSRkMpIHRvIEludGVybmV0IFN0YW5kYXJkIHN0YXR1cy4NCg0KQW5k IHRoaXMgSS1EIHNob3VsZCBvbmx5IGRlYWwgd2l0aCBpc3N1ZSAjMSBidXQgbm90ICMyLiBUaGlz IGlzIGFsc28gY2xlYXIgZnJvbSB0aGUgZmlsZW5hbWUgInZjY3YtZm9yLWdhbCIsIHdoaWNoIHdh cyBjaGFuZ2VkIGZyb20gdGhlICJ2Y2N2LTIiIG9mIHRoZSBpbmRpdmlkdWFsIHN1Ym1pc3Npb24g dG8gbWFrZSB2ZXJ5IGV4cGxpY2l0bHkgY2xlYXIgdGhpcyBzY29wZS4NCg0KSG93ZXZlciwgdGhl IHRpdGxlIG9mIHRoaXMgSS1EIGlzIHN0aWxsICJVbmlmaWVkIENvbnRyb2wgQ2hhbm5lbCIuDQoN CkFkZGl0aW9uYWxseSBJIHdvdWxkIGxpa2UgdG8gaGlnaGxpZ2h0IGluIGFncmVlbWVudCB0d28g aXNzdWVzIHRoYXQgWWFha292IGJyb3VnaHQgdXAuDQoNCk9uIE1heSAyNSwgMjAxMiwgYXQgODow OSBBTSwgWWFha292IFN0ZWluIHdyb3RlOg0KDQoNCk15IGNvbW1lbnRzLiBNb3N0IGFyZSBlZGl0 b3JpYWwgKHNvbWUgb2YgdGhlIGRvY3VtZW50IHNlZW1zIHRvIGhhdmUgYmVlbiB3cml0dGVuIGlu IGhhc3RlKQ0KDQpJIGJlbGlldmUgdGhhdCB0aGUgbnVtYmVyIG9mIGVkaXRvcmlhbCBpc3N1ZXMg YWN0dWFsbHkgYW1vdW50IHRvIHRlY2huaWNhbCBjb25jZXJucy4gRm9yIGV4YW1wbGUsIHRoZSBU aXRsZSwgQWJzdHJhY3QsIGFuZCBJbnRyb2R1Y3Rpb24gc3BlYWsgb2YgdGhpbmdzIGluIHRoZSBz Y29wZSBvZiBhIDUwODViaXMuIE1vcmVvdmVyLCB0aGUgSW50cm9kdWN0aW9uIHJlcGVhdHMgRmln dXJlcyAxIGFuZCAyIGFuZCB0aGUgQWNyb255bXMgZXZlbiByZXBlYXRzIHVudXNlZCBvbmVzIChM MlNTLCBMQ0NFIGFyZSBtZWFuaW5nbGVzcyBhbmQgdW51c2VkIGluIHRoaXMgZG9jKS4NCg0KRnJv bSBteSBwZXJzcGVjdGl2ZSwgdGhlIGNvbGxlY3Rpb24gb2YgdGhlc2UgZWRpdG9yaWFscyBhbW91 bnQgdG8gYSBibG9ja2luZyBjb21tZW50Lg0KDQoNCg0KDQoNCg0KDQogIElmIHRoZSBjLWJpdCBp cyBzZXQsDQoNCiAgaW5kaWNhdGluZyB0aGUgdXNlIG9mIHRoZSBjb250cm9sIHdvcmQsIHR5cGUg MSBNVVNUIGJlIGFkdmVydGlzZWQNCg0KICBhbmQgdHlwZSA0IE1VU1QgTk9UIGJlIGFkdmVydGlz ZWQuDQoNCg0KDQpBbHRob3VnaCBJIHBlcnNvbmFsbHkgcHJlZmVyIHVzaW5nIHR5cGUgMSBpZiB0 aGVyZSBJUyBhIENXLA0KDQoNCg0KSSBkbyBub3QgcmVjYWxsIGhlYXJpbmcgV0cgY29uc2Vuc3Vz IG9uIHRoaXMuDQoNCg0KDQpUaGlzIHN0YXRlbWVudCBnb2VzIGZ1cnRoZXIgdGhhbiA1MDg1Lg0K DQoNCg0KSSB3b3VsZCBsaWtlIHRvIHNlZSBwZW9wbGUgZXhwbGljaXRseSBleHByZXNzIHN1cHBv cnQgZm9yIHRoaXMuDQoNCg0KDQoNCg0KICBJZiB0aGUgYy1iaXQgaXMgbm90IHNldCwNCg0KICBp bmRpY2F0aW5nIHRoYXQgdGhlIGNvbnRyb2wgd29yZCBpcyBub3QgaW4gdXNlLCB0eXBlIDQgTVVT VA0KDQoNCg0KICBiZSBhZHZlcnRpc2VkLCBhbmQgdHlwZSAxIE1VU1QgTk9UIGJlIGFkdmVydGlz ZWQuDQoNClNvcnJ5LCBidXQgSSBzdHJvbmdseSBkaXNhZ3JlZSBoZXJlISEhISEhISEhISENCg0K QnkgYSBzaG93IG9mIGhhbmRzIGF0IHRoZSBsYXN0IG1lZXRpbmcgcGVvcGxlIGFncmVlZCB0aGF0 IHJvdXRlciBhbGVydCBjb3VsZCBiZSBlbGltaW5hdGVkLg0KDQpIb3dldmVyLCBpdCB3YXMgTk9U IGFncmVlZCB0aGF0IFRUTCBleHBpcnkgd2FzIHRvIGJlIGVsaW1pbmF0ZWQg4oCTIHF1aXRlIHRo ZSBjb250cmFyeSENCg0KU28sIHdpdGhvdXQgQ1cgdGhlcmUgYXJlIDIgb3B0aW9ucyDigJMgdGhl IHByZXNlbnRseSBhdmFpbGFibGUgYW5kIGRlcGxveWVkIG9uZSBvZiB1c2luZyBUVEwNCg0KYW5k IHRoaXMgbmV3IG9uZS4NCg0KDQoNClRoZSByZXF1aXJlbWVudCB0byBzdXBwb3J0IHRoaXMgbW9k ZSBPTkxZIGhhcyBOT1QgcmVjZWl2ZWQgY29uc2Vuc3VzIGZyb20gdGhlIFdHLg0KDQoNClNpbWls YXJseSwgdGhpcyBzZWVtcyB0byBjb250cmFkaWN0IHRoZSBhY3R1YWwgZG9jdW1lbnQgc2NvcGUu IFdlIGRpc2N1c3NlZCB0aGUgYmVzdCBhcHByb2FjaCBmb3IgInVuaWZpY2F0aW9uIiBpbiBQYXJp cyBhbmQgc3Vic2VxdWVudGx5IG9uIGVtYWlsLCBhbmQgaXQgaXMgY2xvc2VyIHRvIGRvaW5nIGEg NTA4NWJpcyB0aGFuIGhhdmluZyBhIGRvY3VtZW50IHRoYXQgZG9lcyBub3QgdXBkYXRlIHRvIHJl ZGVmaW5lLiBJIG9iamVjdCB0byBWQ0NWLWZvci1HQUwgZ29pbmcgYmV5b25kIFZDQ1YgZm9yIEdB TC4NCg0KQXMgaXQgc3RhbmRzLCBJIGRvIG5vdCBzdXBwb3J0IHRoaXMgZG9jdW1lbnQgbW92ZSBm b3J3YXJkIGFzIGlzLg0KDQpUaGFua3MsDQoNCi0tIENhcmxvcy4NCg0KDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpwd2UzIG1haWxpbmcgbGlzdA0K cHdlM0BpZXRmLm9yZzxtYWlsdG86cHdlM0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vcHdlMw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpwd2UzIG1haWxpbmcgbGlzdA0KcHdlM0BpZXRmLm9yZzxtYWls dG86cHdlM0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cHdlMw0KDQo= --_000_7347100B5761DC41A166AC17F22DF1121B78DEC6eusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjwhLS1baWYgIW1zb10+ PHN0eWxlPnZcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCm9cOioge2JlaGF2aW9y OnVybCgjZGVmYXVsdCNWTUwpO30NCndcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30N Ci5zaGFwZSB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KPC9zdHlsZT48IVtlbmRpZl0t LT48c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAw IDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsN CglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxl IERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFs DQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNl dGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24g VGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4u SFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVk IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQ cmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTE5 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0K CXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFo b21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyog TGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTkxNjgyMDY5NTsN Cgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTU4OTA2MDQ7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXci Ow0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxl dmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVs Nw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9s DQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RGVhciBBdXRob3JzLCBldC4gYWwsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmluIExvbmRvbiB3ZeKAmXZlIGRpc2N1c3NlZCB3 b3JrIG9uIHRoZSBWQ0NWIENvbnRyb2wgQ2hhbm5lbCBUeXBlIDQuIEkgdGhvdWdodCB0aGF0IHRo ZXNlIGNvbW1lbnRzIGZyb20gbG9uZyBhZ28gbWF5IGJlIGhlbHBmdWwgaW4geW91ciB3b3JrIG9u IHRoZSBuZXh0IHZlcnNpb24NCiBvZiB0aGUgZG9jdW1lbnQuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBHcmVnPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4tLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNz YWdlIC0tLS0tLS0tLS08YnI+DQpGcm9tOiA8Yj5HcmVnb3J5IE1pcnNreTwvYj4gJmx0OzxhIGhy ZWY9Im1haWx0bzpncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb20iPmdyZWdvcnkubWlyc2t5QGVy aWNzc29uLmNvbTwvYT4mZ3Q7PGJyPg0KRGF0ZTogVHVlLCBNYXkgMjksIDIwMTIgYXQgMTE6NTQg QU08YnI+DQpTdWJqZWN0OiBSZTogW1BXRTNdIFdHIExhc3QgQ2FsbCBmb3IgZHJhZnQtaWV0Zi1w d2UzLXZjY3YtZm9yLWdhbC0wMS50eHQ8YnI+DQpUbzogVGhvbWFzIE5hZGVhdSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnRuYWRlYXVAbHVjaWR2aXNpb24uY29tIj50bmFkZWF1QGx1Y2lkdmlzaW9uLmNv bTwvYT4mZ3Q7PGJyPg0KQ2M6IENhcmxvcyBQaWduYXRhcm8gJmx0OzxhIGhyZWY9Im1haWx0bzpj cGlnbmF0YUBjaXNjby5jb20iPmNwaWduYXRhQGNpc2NvLmNvbTwvYT4mZ3Q7LCBZYWFrb3YgU3Rl aW4gJmx0OzxhIGhyZWY9Im1haWx0bzp5YWFrb3Zfc0ByYWQuY29tIj55YWFrb3Zfc0ByYWQuY29t PC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpwd2UzQGlldGYub3JnIj5wd2UzQGlldGYu b3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnB3ZTNAaWV0Zi5vcmciPnB3ZTNAaWV0 Zi5vcmc8L2E+Jmd0Ozxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPkRlYXIgVG9tLDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPmFwb2xv Z2llcyBhbmQgcGxlYXNlIGZpbmQgbXkgY29tbWVudHMgYmVsb3cgKHNvbWUgaWYgbm90IG1vc3Qg bWlnaHQgZHVwbGljYXRlIHdoYXQgYWxyZWFkeSB3YXMgbm90ZWQgYnkgWWFhY292IGFuZCBDYXJs b3MpOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1 ZSI+QWJzdHJhY3QgJnF1b3Q7VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSB1bmlmaWVkIG1vZGUg b2Ygb3BlcmF0aW9uIGZvciBWaXJ0dWFsJm5ic3A7Q2lyY3VpdCBDb25uZWN0aXZpdHkgVmVyaWZp Y2F0aW9uIChWQ0NWKSAuLi4mcXVvdDsgSU1ITywgYWdyZWVtZW50IG9mIFdHIGRpc2N1c3Npb24g aW4gUGFyaXMgd2FzIHRvIGxpbWl0IGRvY3VtZW50IHNjb3BlIHRvIGludHJvZHVjdGlvbg0KIG9m IENvbnRyb2wgQ2hhbm5lbCBUeXBlIDQgZm9yIFBXIFZDQ1YgYW5kIGFkZHJlc3MgdW5pZmllZCBv cGVyYXRpb24gb2YgQ0MgVkNDViBpbiBSRkMgNTA4NWJpcy48L3NwYW4+PG86cD48L286cD48L2xp PjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6Ymx1ZSI+Jm5ic3A7QWJzdHJhY3QgJnF1b3Q7VGhlIG9sZGVyIHR5cGVzIHdpbGwg cmVtYWluIG9wdGlvbmFsLiZxdW90OyBJTUhPLCB0aGUgV0cgYWdyZWVkIHRvIG9ic29sZXRlIFR5 cGUgMiBDQyBQVyBWQ0NWLjwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5JbnRy b2R1Y3Rpb24gJnF1b3Q7VGhpcyBkb2N1bWVudCBhbmQgdGhlIGltcGxlbWVudGF0aW9uIHN1cnZl eSBjb25jbHVkZWQgLi4uJnF1b3Q7Ojwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjx1bCB0 eXBlPSJkaXNjIj4NCjx1bCB0eXBlPSJjaXJjbGUiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt c28tbGlzdDpsMCBsZXZlbDIgbGZvMSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4mcXVvdDtUaGlz IGRvY3VtZW50JnF1b3Q7IGFzIEEgVW5pZmllZCBDb250cm9sIENoYW5uZWwgZm9yIFBzZXVkb3dp cmVzPw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1s aXN0OmwwIGxldmVsMiBsZm8xIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPkJlc2lkZXMsIEkgYmVs aWV2ZSB0aGF0IGlmIHRoZSBhY2NlcHRhbmNlIG9mIE1hbmRhdG9yeSBVc2Ugb2YgQ29udHJvbCBX b3JkIGZvciBQV0UzIEVuY2Fwc3VsYXRpb25zIHdpbGwgbWFrZSBkcmFmdC1pZXRmLXB3ZTMtdmNj di1mb3ItZ2FsLSB1bm5lY2Vzc2FyeS4gUmVmZXJlbmNlIHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBz dXJ2ZXkgZHJhZnQtaWV0Zi1wd2UzLXZjY3YtaW1wbC1zdXJ2ZXktcmVzdWx0cy0wMA0KIGlzIG1p c3NpbmcuPC9zcGFuPjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1s aXN0OmwwIGxldmVsMiBsZm8xIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPkkgZG9uJ3Qgc2VlIHRo YXQgdGhlICZxdW90O1RoZSBQc2V1ZG93aXJlIChQVykgJmFtcDsgVmlydHVhbCBDaXJjdWl0IENv bm5lY3Rpdml0eSBWZXJpZmljYXRpb24gKFZDQ1YpIEltcGxlbWVudGF0aW9uIFN1cnZleSBSZXN1 bHRzJnF1b3Q7IG1hZGUgc3VnZ2VzdGVkIGNvbmNsdXNpb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9s aT48L3VsPg0KPC91bD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+SW50cm9kdWN0 aW9uICZxdW90Oy4uLiB0aGUgSVRVLVQmbmJzcDthbmQgSUVURiBoYXZlIHNldCBvdXQgdG8gZW5o YW5jZSBNUExTIHRvIG1ha2UgaXQgc3VpdGFibGUgYXMgYW4mbmJzcDtvcHRpY2FsIHRyYW5zcG9y dCBwcm90b2NvbCAuLi4mcXVvdDsgUGVyaGFwcyBzaG91bGQgYmUgJnF1b3Q7cGFja2V0IHRyYW5z cG9ydCZxdW90Oy48L3NwYW4+PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+SW50cm9kdWN0 aW9uICZxdW90O0luIG9yZGVyIHRvIHN1cHBvcnQgVkNDViB3aGVuIGFuIE1QTFMtVFAgUFNOIGlz IGluIHVzZSwgdGhlIEdBTC1BQ0ggaGFkIHRvIGJlIGNyZWF0ZWQ8L3NwYW4+Jm5ic3A7PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6Ymx1ZSI+Li4uJnF1b3Q7IEctQUNoIHdhcyBjcmVhdGVkIGZvciBNUExTLVRQDQog TFNQLCBub3QgUFcuIFBXIFZDQ1Ygd2hlbiBQU04gaXMgTVBMUy1UUCBjYW4gdXNlIGFueSBvZiBk ZXNjcmliZWQgaW4gUkZDIDUwODUgY29udHJvbCBjaGFubmVsIHR5cGVzLjwvc3Bhbj48bzpwPjwv bzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+ DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibHVlIj5JbnRyb2R1Y3Rpb24gJnF1b3Q7VGhpcyBkb2N1bWVudCBk ZWZpbmVzIHR3byBtb2RlcyBvZiBvcGVyYXRpb24gb2YgVkNDViAuLi4mcXVvdDsgV2hlcmUgdGhl IGRvY3VtZW50IGxlYXZlcyBDQyBUeXBlIDM/IElzbid0IGl0IHZhbGlkIG1vZGUgb2YgUFcgVkND ViBvcGVyYXRpb24gdGhhdCB0aGUgUFdFMyBXRyBkZWNpZGVkIHRvIGtlZXA/PC9zcGFuPjxvOnA+ PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8x Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPkludHJvZHVjdGlvbiAmcXVvdDtJbiBlaXRoZXIgY2Fz ZSwgaXQgd2lsbCBiZSBtYW5kYXRvcnkgdG8gaW1wbGVtZW50IGFuZCB1c2UgdGhhdCBtb2RlIHVu ZGVyIHRoYXQmbmJzcDtzY2VuYXJpby4mcXVvdDsgQWdhaW4sIHRoaXMgY29uY2x1c2lvbiBpcyBu b3QgaW4gc3luYyB3aXRoIHdoYXQgd2FzIGFncmVlZCBhdCBQV0UzIFdHIG1lZXRpbmcgaW4gUGFy aXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0 OmwwIGxldmVsMSBsZm8xIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPlNlY3Rpb24gMiAmcXVvdDsu Li4gQXNzb2NpYXRlZCBDaGFubmVsIFR5cGVzIG9mIDIxLCAwNywgb3IgNTcgYXJlIGFsbG93ZWQm cXVvdDsgRmlyc3RseSwgaXQgc2hvdWxkIGJlICZxdW90OzB4MDAyMSwgMHgwMDcsIG9yIDB4MDA1 NyZxdW90Oy4gU2Vjb25kbHksIHdoeSAweDAwMEEsIDB4MDAwQiwgMHgwMDBDLCAweDAwMEQsIDB4 MDAwRSwgMHgwMDIyLCAweDAwMjMsIDB4MDAyNCwgMHgwMDI1LA0KIDB4MDAyNiwgMHgwMDI3LCBh bmQgMHgwMDU4IHdvdWxkIG5vdCBiZSBsaXN0ZWQgYXMgdmFsaWQgQUNIIHR5cGVzPzwvc3Bhbj48 bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEg bGZvMSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5TZWN0aW9uIDMgJnF1b3Q7SW4gdGhlIGNhc2Ug b2YgbXVsdGktc2VnbWVudCBwc2V1ZG8td2lyZXMsIHRoZSBQVyBMYWJlbCBUVEwgTVVTVCBiZSBz ZXQgdG8gdGhlIGNvcnJlY3QgdmFsdWUgdG8gcmVhY2ggdGhlIGludGVuZGVkIGRlc3RpbmF0aW9u IFBFIGFzIGRlc2NyaWJlZCBpbiBbPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv cmZjNjA3MyIgdGFyZ2V0PSJfYmxhbmsiIHRpdGxlPSImcXVvdDtTZWdtZW50ZWQgUHNldWRvd2ly ZSZxdW90OyI+UkZDNjA3MzwvYT5dJnF1b3Q7DQogVGhpcyBzZWVtcyB0byBleGNsdWRlIFZDQ1Yg Q0MgVHlwZSAzIGZyb20gYmVpbmcgdXNlZCBpbiBjb25qdW5jdGlvbiB3aXRoIEdBTCBldmVuIHRo b3VnaCBTZWN0aW9uIDUuMS4zIG9mIFJGQyA1MDg1IGV4cGxpY2l0bHkgYWxsb3dzIGNvbWJpbmF0 aW9uIG9mIFBXIFZDQ1YgQ29udHJvbCBDaGFubmVscyBUeXBlIDEgYW5kIFR5cGUgMy48L3NwYW4+ PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzEiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+U2VjdGlvbiAzICZxdW90O1RoZSBHQUwgZmll bGQgLi4uJnF1b3Q7IEdlbmVyaWMgQXNzb2NpYXRlZCBDaGFubmVsIExhYmVsIChHQUwpIGlzIG5v dCBhIGZpZWxkIGJ1dCBwYXJ0IG9mIE1QTFMgbGFiZWwgc3RhY2sgZW50cnkuIFdoYXQgYXJlIHZh bHVlcyBvZiBvdGhlciBmaWVsZHMgb2YgdGhlJm5ic3A7bGFiZWwgc3RhY2sgZW50cnkgd2l0aCB0 aGUgR0FMJm5ic3A7LSBUQywgUywNCiBUVEw/PC9zcGFuPjxvOnA+PC9vOnA+PC9saT48bGkgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsdWUiPlNlY3Rpb24gMyAmcXVvdDtUaGUgZmlyc3QgbmliYmxlIG9mIHRoZSBuZXh0IGZpZWxk IGlzIHNldCB0byAwMDAxYiAuLi4mcXVvdDsgRG9lcyB0aGF0IGltcGx5IHRoYXQgR0FMIE1VU1Qg YmUgQk9TIGxhYmVsIGFuZCB0aHVzIFM9MT88L3NwYW4+PG86cD48L286cD48L2xpPjxsaSBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 Ymx1ZSI+U2VjdGlvbiA0ICZxdW90O0lmIHRoZSBjLWJpdCBpcyBub3Qgc2V0LCBpbmRpY2F0aW5n IHRoYXQgdGhlIGNvbnRyb2wgd29yZCBpcyBub3QgaW4gdXNlLCB0eXBlIDQgTVVTVCBiZSBhZHZl cnRpc2VkLCBhbmQgdHlwZSAxIE1VU1QgTk9UIGJlIGFkdmVydGlzZWQuJnF1b3Q7IEkgdGhpbmsg dGhhdCB3aGV0aGVyIFR5cGUgNCBNVVNULFNIQUxMIG9yIE1BWSBiZSBhZHZlcnRpc2VkDQogKGRv IG5vdCBmb3JnZXQgVHlwZSAzKSwgc2hvdWxkIGJlIGFkZHJlc3NlZCBpbiBSRkMgNTA4NWJpcy48 L3NwYW4+PG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibHVlIj4mbmJzcDsmbmJzcDsmbmJzcDsgUmVnYXJkcyw8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgR3JlZzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQt YWxpZ246Y2VudGVyIj4NCjxociBzaXplPSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+IFRob21hcyBOYWRlYXUgW21haWx0bzo8YSBocmVmPSJtYWlsdG86dG5h ZGVhdUBsdWNpZHZpc2lvbi5jb20iIHRhcmdldD0iX2JsYW5rIj50bmFkZWF1QGx1Y2lkdmlzaW9u LmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgTWF5IDI5LCAyMDEyIDU6NTQg QU08YnI+DQo8Yj5Ubzo8L2I+IEdyZWdvcnkgTWlyc2t5PGJyPg0KPGI+Q2M6PC9iPiBDYXJsb3Mg UGlnbmF0YXJvOyBZYWFrb3YgU3RlaW47IDxhIGhyZWY9Im1haWx0bzpwd2UzQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+DQpwd2UzQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFtQV0UzXSBXRyBMYXN0IENhbGwgZm9yIGRyYWZ0LWlldGYtcHdlMy12 Y2N2LWZvci1nYWwtMDEudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R2VuZXJpYyBzdGF0ZW1lbnRzIGxpa2UgdGhpcyBhcmUg bm90IHVzZWZ1bCBhdCB0aGlzIHBvaW50IGluIHRoZSBwcm9jZXNzOyBwbGVhc2UgYmUgc3BlY2lm aWMgYW5kIHdoYXQgeW91IG9iamVjdCB0byBhbmQgd2hhdCBjaGFuZ2VzIHlvdSBwcm9wb3NlIHRv IGNvcnJlY3QgdGhlbS4gVGhpcyB3aWxsIGFsbG93IHRoZSBXRyB0byBkaXNjdXNzIGFueSBjaGFu Z2VzIG9uIHRoZSBsaXN0IGlmIHRoZXkgYXJlIG1ham9yLg0KIFdoYXQgd2Ugd2FudCB0byBhdm9p ZCBpcyBtYWtpbmcgY2hhbmdlcyBvbiB0aGUgc2FtZSBpc3N1ZSBtdWx0aXBsZSB0aW1lcyBkdWUg dG8gbXVsdGlwbGUgY29uZmxpY3RpbmcgY2hhbmdlIHJlcXVlc3RzLCBvciBhdHRlbXB0aW5nIHRv IGZpeCBnZW5lcmljIGNvbW1lbnRzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLVRvbTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPkRvIG5v dCBzdXBwb3J0IGFzIGluIHRoZSBjdXJyZW50IGZvcm0gZG9jdW1lbnQgZ29lcyBiZXlvbmQgbWVy ZSBkZWZpbml0aW9uIG9mIHRoZSBuZXcgQ29udHJvbCBDaGFubmVsIHR5cGUgZm9yIFZDQ1YuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 Ymx1ZSI+QW5kIGNvbmN1ciB3aXRoIGNvbmNlcm5zIGV4cHJlc3NlZCBieSBZYWFjb3YgYW5kIENh cmxvcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyA8 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibHVlIj4NClJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPg0KR3JlZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBjbGFzcz0iTXNv Tm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhyIHNp emU9IjIiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KPGEgaHJlZj0ibWFpbHRvOnB3ZTMtYm91bmNlc0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnB3ZTMtYm91bmNlc0BpZXRmLm9yZzwvYT4gW21haWx0bzo8 YSBocmVmPSJtYWlsdG86cHdlMy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cHdl My1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Q2FybG9zIFBpZ25h dGFybzxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIE1heSAyNSwgMjAxMiA3OjE1IEFNPGJyPg0K PGI+VG86PC9iPiBZYWFrb3YgU3RlaW47IDxhIGhyZWY9Im1haWx0bzpwd2UzQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+cHdlM0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IFtQV0UzXSBXRyBMYXN0IENhbGwgZm9yIGRyYWZ0LWlldGYtcHdlMy12Y2N2LWZvci1nYWwtMDEu dHh0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBX RTNlcnMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkkgdG9vIGhhdmUgc3Ryb25nIGNvbmNlcm5zIGFib3V0IHRoaXMgZG9jdW1lbnQgYmVpbmcg V0dMQ2VkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5BIG1ldGEtY29uY2VybiBjZW50ZXJzIGFyb3VuZCB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1 bWVudC4gTXkgdW5kZXJzdGFuZGluZyAoYW5kIHBsZWFzZSBjb3JyZWN0IHRoaXMgd2l0aCBhIGNp dGF0aW9uIGlmIEkgYW0gaW5jb3JyZWN0KSBpcyB0aGF0IHRoZXJlIHdhcyBjb25zZW5zdXMgZm9y IHRoaXMgZG9jdW1lbnQgdG8gZGVmaW5lIGEgbmV3IENDIFR5cGUgNCB1c2luZyBHQUwsIGJ1dCB0 aGVyZSB3YXMgbm90DQogY29uc2Vuc3VzIHRvIGhhdmUgdGhpcyBkb2N1bWVudCByZWRlZmluZSBh bGwgQ29udHJvbCBDaGFubmVscyBhbmQgdGhlaXIgcmVxdWlyZW1lbnQgbGV2ZWxzIChpLmUuLCBk ZXByZWNhdGluZyBvciBjcmVhdGluZyBydWxlcyBvZiB1c2UpLiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gcm9tIHRoZSBtaW51dGVz IGF0Jm5ic3A7PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL3B3ZTMvbWludXRlcyIg dGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9yZy93Zy9wd2UzL21pbnV0ZXM8L2E+ Jm5ic3A7d2UgY2FuIHNlZSB0aGF0OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHBy ZSBzdHlsZT0id29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxh IG5hbWU9IjEzNzk5ZjMxN2QwN2M0ZGZfc2VjdGlvbi0yMCI+PC9hPjxhIGhyZWY9Imh0dHA6Ly90 b29scy5pZXRmLm9yZy93Zy9wd2UzL21pbnV0ZXMjc2VjdGlvbi0yMCIgdGFyZ2V0PSJfYmxhbmsi PjxiPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZSI+MjA8L3NwYW4+PC9iPjwvYT48 Yj4gbWluIC0gR2VuZXJhbCBkaXNjdXNzaW9uIG9uIFZDQ1YgZm9yIEdBTDwvYj48bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZXJlIGFw cGVhciB0byBiZSB0d28gc2VwYXJhdGUgaXNzdWVzIG9uIHRoZSB0YWJsZTo8bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIG5hbWU9IjEz Nzk5ZjMxN2QwN2M0ZGZfc2VjdGlvbi0xIj48L2E+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYu b3JnL3dnL3B3ZTMvbWludXRlcyNzZWN0aW9uLTEiIHRhcmdldD0iX2JsYW5rIj48Yj48c3BhbiBz dHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmUiPjE8L3NwYW4+PC9iPjwvYT48Yj4uIFZDQ1Ygc3Vw cG9ydCBmb3IgYSBQVyBhc3NvY2lhdGVkIGNoYW5uZWwgdGhhdCB1c2VzIHRoZSBHQUwgYXMgYW48 L2I+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBhbGVydCBtZWNoYW5pc21zIChWQ0NWIFR5cGUgNCkuIFRoaXMgaXMgcmVhbGx5IHRoZSBz dWJqZWN0IG9mIHRoZSBkcmFmdC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIG5hbWU9IjEzNzk5ZjMxN2QwN2M0ZGZfc2VjdGlvbi0y Ij48L2E+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL3B3ZTMvbWludXRlcyNzZWN0 aW9uLTIiIHRhcmdldD0iX2JsYW5rIj48Yj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5v bmUiPjI8L3NwYW4+PC9iPjwvYT48Yj4uIFdoYXQgdG8gZG8gYWJvdXQgbGVnYWN5IG1vZGVzLCBw YXJ0aWN1bGFybHkgcm91dGVyIGFsZXJ0IGFuZCBUVEw8L2I+PG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBleHBpcnkuIFRoaXMgaXMgYSBz ZXBhcmF0ZSBpc3N1ZSByZWdhcmRpbmcgdGhlIHByb2dyZXNzIG9mIDxhIGhyZWY9Imh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sP3JlcG9zaXRvcnk9aHR0cDovL3Rvb2xzLmlldGYub3JnJmFtcDty ZmM9NTA4NSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjojNDQwMDg4Ij5SRkM1 MDg1PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IChvciBzb21lIGZ1dHVyZSBSRkMpIHRvIEludGVybmV0IFN0YW5kYXJk IHN0YXR1cy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QW5kIHRoaXMgSS1EIHNob3VsZCBvbmx5IGRlYWwgd2l0aCBpc3N1ZSAj MSBidXQgbm90ICMyLiBUaGlzIGlzIGFsc28gY2xlYXIgZnJvbSB0aGUgZmlsZW5hbWUgJnF1b3Q7 dmNjdi1mb3ItZ2FsJnF1b3Q7LCB3aGljaCB3YXMgY2hhbmdlZCBmcm9tIHRoZSAmcXVvdDt2Y2N2 LTImcXVvdDsgb2YgdGhlIGluZGl2aWR1YWwgc3VibWlzc2lvbiB0byBtYWtlIHZlcnkgZXhwbGlj aXRseSBjbGVhciB0aGlzIHNjb3BlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3dldmVyLCB0aGUgdGl0bGUgb2YgdGhpcyBJLUQgaXMgc3Rp bGwgJnF1b3Q7VW5pZmllZCBDb250cm9sIENoYW5uZWwmcXVvdDsuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFkZGl0aW9uYWxseSBJIHdvdWxk IGxpa2UgdG8gaGlnaGxpZ2h0IGluIGFncmVlbWVudCB0d28gaXNzdWVzIHRoYXQgWWFha292IGJy b3VnaHQgdXAuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biBNYXkgMjUsIDIwMTIsIGF0IDg6MDkgQU0sIFlhYWtvdiBTdGVpbiB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk15IGNvbW1lbnRzLiBNb3N0IGFyZSBlZGl0b3JpYWwgKHNv bWUgb2YgdGhlIGRvY3VtZW50IHNlZW1zIHRvIGhhdmUgYmVlbiB3cml0dGVuIGluIGhhc3RlKTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SSBiZWxpZXZlIHRoYXQgdGhlIG51bWJlciBvZiBlZGl0b3JpYWwgaXNzdWVzIGFjdHVhbGx5 IGFtb3VudCB0byB0ZWNobmljYWwgY29uY2VybnMuIEZvciBleGFtcGxlLCB0aGUgVGl0bGUsIEFi c3RyYWN0LCBhbmQgSW50cm9kdWN0aW9uIHNwZWFrIG9mIHRoaW5ncyBpbiB0aGUgc2NvcGUgb2Yg YSA1MDg1YmlzLiBNb3Jlb3ZlciwgdGhlIEludHJvZHVjdGlvbiByZXBlYXRzIEZpZ3VyZXMgMSBh bmQgMiBhbmQgdGhlDQogQWNyb255bXMgZXZlbiByZXBlYXRzIHVudXNlZCBvbmVzIChMMlNTLCBM Q0NFIGFyZSBtZWFuaW5nbGVzcyBhbmQgdW51c2VkIGluIHRoaXMgZG9jKS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RnJvbSBteSBwZXJzcGVj dGl2ZSwgdGhlIGNvbGxlY3Rpb24gb2YgdGhlc2UgZWRpdG9yaWFscyBhbW91bnQgdG8gYSBibG9j a2luZyBjb21tZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6OS4wcHQiPiZu YnNwOyBJZiB0aGUgYy1iaXQgaXMgc2V0LDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOIiBzdHls ZT0iZm9udC1zaXplOjkuMHB0Ij4mbmJzcDsgaW5kaWNhdGluZyB0aGUgdXNlIG9mIHRoZSBjb250 cm9sIHdvcmQsIHR5cGUgMSBNVVNUIGJlIGFkdmVydGlzZWQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n PSJFTiIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdCI+Jm5ic3A7IGFuZCB0eXBlIDQgTVVTVCBOT1Qg YmUgYWR2ZXJ0aXNlZC48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QWx0aG91Z2ggSSBwZXJzb25hbGx5IHBy ZWZlciB1c2luZyB0eXBlIDEgaWYgdGhlcmUgSVMgYSBDVyw8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBk byBub3QgcmVjYWxsIGhlYXJpbmcgV0cgY29uc2Vuc3VzIG9uIHRoaXMuPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPlRoaXMgc3RhdGVtZW50IGdvZXMgZnVydGhlciB0aGFuIDUwODUuPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkkgd291bGQgbGlrZSB0byBzZWUgcGVvcGxlIGV4cGxpY2l0bHkgZXhwcmVzcyBzdXBwb3J0 IGZvciB0aGlzLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n PSJFTiIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdCI+Jm5ic3A7IElmIHRoZSBjLWJpdCBpcyBub3Qg c2V0LDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0Ij4m bmJzcDsgaW5kaWNhdGluZyB0aGF0IHRoZSBjb250cm9sIHdvcmQgaXMgbm90IGluIHVzZSwgdHlw ZSA0IE1VU1Q8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0Ij4mbmJzcDsgYmUgYWR2ZXJ0aXNlZCwgYW5kIHR5cGUgMSBNVVNUIE5PVCBi ZSBhZHZlcnRpc2VkLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+U29ycnksIGJ1dCBJIHN0cm9uZ2x5IGRpc2FncmVlIGhlcmUh ISEhISEhISEhITwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+QnkgYSBzaG93IG9mIGhhbmRzIGF0IHRoZSBsYXN0IG1lZXRpbmcg cGVvcGxlIGFncmVlZCB0aGF0IHJvdXRlciBhbGVydCBjb3VsZCBiZSBlbGltaW5hdGVkLjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+SG93ZXZlciwgaXQgd2FzIE5PVCBhZ3JlZWQgdGhhdCBUVEwgZXhwaXJ5IHdhcyB0byBiZSBl bGltaW5hdGVkIOKAkyBxdWl0ZSB0aGUgY29udHJhcnkhPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i RU4iIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Tbywgd2l0aG91dCBDVyB0 aGVyZSBhcmUgMiBvcHRpb25zIOKAkyB0aGUgcHJlc2VudGx5IGF2YWlsYWJsZSBhbmQgZGVwbG95 ZWQgb25lIG9mIHVzaW5nIFRUTDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+ PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+YW5kIHRoaXMgbmV3IG9uZS48L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+VGhlIHJlcXVpcmVtZW50IHRvIHN1cHBvcnQgdGhpcyBtb2RlIE9OTFkgaGFzIE5PVCBy ZWNlaXZlZCBjb25zZW5zdXMgZnJvbSB0aGUgV0cuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TaW1pbGFybHks IHRoaXMgc2VlbXMgdG8gY29udHJhZGljdCB0aGUgYWN0dWFsIGRvY3VtZW50IHNjb3BlLiBXZSBk aXNjdXNzZWQgdGhlIGJlc3QgYXBwcm9hY2ggZm9yICZxdW90O3VuaWZpY2F0aW9uJnF1b3Q7IGlu IFBhcmlzIGFuZCBzdWJzZXF1ZW50bHkgb24gZW1haWwsIGFuZCBpdCBpcyBjbG9zZXIgdG8gZG9p bmcgYSA1MDg1YmlzIHRoYW4gaGF2aW5nIGEgZG9jdW1lbnQgdGhhdCBkb2VzIG5vdCB1cGRhdGUg dG8gcmVkZWZpbmUuDQogSSBvYmplY3QgdG8gVkNDVi1mb3ItR0FMIGdvaW5nIGJleW9uZCBWQ0NW IGZvciBHQUwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkFzIGl0IHN0YW5kcywgSSBkbyBub3Qgc3VwcG9ydCB0aGlzIGRvY3VtZW50IG1vdmUg Zm9yd2FyZCBhcyBpcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4tLSBDYXJsb3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQpwd2UzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9 Im1haWx0bzpwd2UzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cHdlM0BpZXRmLm9yZzwvYT48 YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3B3ZTMi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3B3 ZTM8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnB3ZTMg bWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnB3ZTNAaWV0Zi5vcmciPnB3ZTNAaWV0 Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9wd2UzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9wd2UzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_7347100B5761DC41A166AC17F22DF1121B78DEC6eusaamb103erics_-- From nobody Thu Apr 10 13:06:20 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1D81A03DE for ; Thu, 10 Apr 2014 13:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pUbs1XRr7xhz for ; Thu, 10 Apr 2014 13:06:17 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) by ietfa.amsl.com (Postfix) with ESMTP id A31921A03CE for ; Thu, 10 Apr 2014 13:06:17 -0700 (PDT) Received: by mail-qg0-f51.google.com with SMTP id q108so4422237qgd.38 for ; Thu, 10 Apr 2014 13:06:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=KUVqTE/9mw2rYowleT3nK9b6qWBInUcSStzliWlgFPw=; b=QYPFo1+MSAzskWk4kdDaKA/QbKf/ujHTjK21/XtQV9zDp72NvvXPI+GR7H5wRS0pN2 VwnWEg7KQAq9/L4pINpiYIKLeLCR6OB4/UNJh09K2hQwexYLovsX1We2O31YklZrIhn+ m+ib+PCu7Tvh1NsQ8HCnLpJSzjI+HS0NIdHpvWSUoRn96J3B2dPeNoiYYFMtBqhn1OeR tDt7GPBlDPzFCe6UjVKG3ykDv6zI3uEkk5xO3wNPkTAwjeTvBxEkRKjqjrJ+TwVx/RTB VeK/aha0OO94cv3PsEPTfGw1CqBXyMQiJScU+xl58JHLcEBtFMkvXVPGLREoyByENnH4 DbBQ== X-Received: by 10.140.108.166 with SMTP id j35mr1933349qgf.76.1397160376407; Thu, 10 Apr 2014 13:06:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.205.69 with HTTP; Thu, 10 Apr 2014 13:05:56 -0700 (PDT) In-Reply-To: <20140410170359.12268.41197.idtracker@ietfa.amsl.com> References: <20140410170359.12268.41197.idtracker@ietfa.amsl.com> From: "Andrew G. Malis" Date: Thu, 10 Apr 2014 16:05:56 -0400 Message-ID: To: "pwe3@ietf.org" Content-Type: multipart/alternative; boundary=001a113a6ddaee1c7a04f6b5bfc7 Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/BIHevflEZREDvtU2rLqmdsppQI8 Subject: [PWE3] Fwd: New Non-WG Mailing List: Tofoo -- Discussion list for Tunneling over Foo (with)in IP networks (TOFOO) X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 20:06:19 -0000 --001a113a6ddaee1c7a04f6b5bfc7 Content-Type: text/plain; charset=ISO-8859-1 There's no explicit indication that MPLS tunnels and/or pseudowires will be included in this list, but you might want to subscribe just in case. Cheers, Andy ---------- Forwarded message ---------- From: IETF Secretariat Date: Thu, Apr 10, 2014 at 1:03 PM Subject: New Non-WG Mailing List: Tofoo -- Discussion list for Tunneling over Foo (with)in IP networks (TOFOO) To: IETF Announcement List Cc: mls.ietf@gmail.com, tofoo@ietf.org A new IETF non-working group email list has been created. List address: tofoo@ietf.org Archive: http://www.ietf.org/mail-archive/web/tofoo/ To subscribe: https://www.ietf.org/mailman/listinfo/tofoo Purpose: Tunneling data across IP-based networks can use a variety of existing encapsulation schemes, such as, GRE [RFC2784], IP-in-IP [RFC2003] and IPsec tunnels [RFC4301] or proposed encapsulation schemes that are based on carrying traffic over UDP. The demand for using tunnels in data centers and across the Internet is increasing also due to network virtualization. A number of known issues have been raised around using tunnels, discussions about applicability of these issues are ongoing and a number of solutions to cope with, for instance, congestion control or congestion control sensitivity, are being discussed. The intention of this list is to bring together tunnel protocol designers/implementers, network operators, and the different areas in the IETF to discuss the ways forward. For additional information, please contact the list administrators. --001a113a6ddaee1c7a04f6b5bfc7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
There's no explicit indication that MPLS tunnels and/o= r pseudowires will be included in this list, but you might want to subscrib= e just in case.

Cheers,
Andy

---------- Forwarded message ----------
From: IETF Secretariat <ietf-secretariat@ietf.org>
Date: Thu, Apr= 10, 2014 at 1:03 PM
Subject: New Non-WG Mailing List: Tofoo -- Discussion list for Tunneling ov= er Foo (with)in IP networks (TOFOO)
To: IETF Announcement List <ietf-announce@ietf.org>
Cc: = mls.ietf@gmail.com, tofoo@ietf.org


A new IETF non-working group email list has been created.

List address: tofoo@ietf.org
Archive: http://www.ietf.org/mail-archive/web/tofoo/
To subscribe: https://www.ietf.org/mailman/listinfo/tofoo

Purpose:

Tunneling data across IP-based networks can use a variety of existing encap= sulation schemes, such as, GRE [RFC2784], IP-in-IP [RFC2003] and IPsec tunn= els [RFC4301] or proposed encapsulation schemes that are based on carrying = traffic over UDP.
The demand for using tunnels in data centers and across the Internet is inc= reasing also due to network virtualization.
A number of known issues have been raised around using tunnels, discussions= about applicability of these issues are ongoing and a number of solutions = to cope with, for instance, congestion control or congestion control sensit= ivity, are being discussed.
The intention of this list is to bring together tunnel protocol designers/i= mplementers, network operators, and the different areas in the IETF to disc= uss the ways forward.

For additional information, please contact the list administrators.


--001a113a6ddaee1c7a04f6b5bfc7-- From nobody Sun Apr 20 02:31:13 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 051A41A010A for ; Sun, 20 Apr 2014 02:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.9 X-Spam-Level: X-Spam-Status: No, score=0.9 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hmwO60GCwtv for ; Sun, 20 Apr 2014 02:31:07 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) by ietfa.amsl.com (Postfix) with ESMTP id 7628F1A0101 for ; Sun, 20 Apr 2014 02:31:06 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id 10so2464501lbg.35 for ; Sun, 20 Apr 2014 02:31:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NbL3WhitCY/CXtUe37dm7zFsdWra2BtSCbLTu0I5VuQ=; b=B1pT7ku5Ubo9MOlb8N5FF3bGnsdwblPe1LGmmY5YGeKlvm8vOzSQiBLTE55hV8bG5r z1Aiz7P3JLT+Cy7ZqwjZ1yCG/kwh47dkpyZU8MAK0ytKnpsXjAAm6k/XWgukv7upACUe 19HPvK62TXYOtaFkXbctksVx9Yzm3nxgbVY12qCY1C37Ji4+X1krruIlU1WdBejrKZxx ZMyWu7spgv2Xt1LHE1ejUeY+lxnqO1N4V3IEjJTCAfC4W88rmN2yZcWMqXStoRcqrrG7 bqZW+tXrSwv2VGhS/4Ijl5uypiREtnNAiN1VMopBFvpaUBqRKlSaBYvb4CUGe31bjNxZ vpIg== MIME-Version: 1.0 X-Received: by 10.152.246.43 with SMTP id xt11mr970323lac.34.1397986261294; Sun, 20 Apr 2014 02:31:01 -0700 (PDT) Received: by 10.114.2.110 with HTTP; Sun, 20 Apr 2014 02:31:01 -0700 (PDT) In-Reply-To: References: Date: Sun, 20 Apr 2014 12:31:01 +0300 Message-ID: From: Binny Jeshan To: "Samer Salam (ssalam)" Content-Type: multipart/alternative; boundary=001a1133a77481626304f7760a3b Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/HFPvBErttBN3zTnRwQhqMZzdi68 Cc: "Ali Sajassi \(sajassi\)" , "tnadeau@brocade.com" , "Luca Martini \(lmartini\)" , "matthew.bocci@alcatel-lucent.co.uk" , "pwe3@ietf.org" Subject: Re: [PWE3] Questions relating to draft-ietf-pwe3-iccp-15. X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2014 09:31:11 -0000 --001a1133a77481626304f7760a3b Content-Type: text/plain; charset=UTF-8 Hi Samer, I have few questions now. 1) How many MAX redundant Groups can be possible between two Peers? [Binny]: In my understanding one RG configured in a PE can cater many instances of Applications. for example, one can associate a mLACP Aggregation bundle t1 and t2 to be a part of Redundant group 1. Please clarify and confirm. 2) As i understand from this draft, applications send their TLV's to the peer through the ICCP channel. Which means mLACP Application Data Message would look like -> ICC Header (6.1.1) with Type 0x703+ mLACP SystemConfig Tlv (type 0032 - section 7.2.3) . Is this understanding correct that the stack order looks like Ethernet + IP + LDP Header + ICCP header + Application TLVs. If my understanding in (1) was right, then How different Application Instances are distinuguished in the Packets received. (for example mLACP may have two MC-LAG instances that its managing) - but the ICC header will have only one RG ID but the following TLV could belong to one of the application instances running on top of the RG. How to demultiplex that. I see a reference to ROID. Section 4.3 " That allows *separate systems in an RG **to use a common handle* to reference the protected entity" . This draft does not define how exactly the ROID bytes will be encoded, as far as i read. This leaves interop malfunction also, various options to code the ROID. one option could ROID = But im left unclear where i will fit this ROID in each type of packet sent by the application 3) How do i exactly code the ROID? can you please standardize that > Comment please. 4) Why ROID is not mentioned to be a Part of EVERY TLV or atleast have a Application Header or something like that to carry it ? Thanks, Binny. Aricent. On 31 March 2014 23:15, Samer Salam (ssalam) wrote: > Hi Binny, > > From: Binny Jeshan > Date: Thursday, 20 March, 2014 3:12 AM > To: "Luca Martini (lmartini)" , Samer Salam < > ssalam@cisco.com>, "Ali Sajassi (sajassi)" , " > matthew.bocci@alcatel-lucent.co.uk" , > "satoru.matsushima@gmail.com" , " > tnadeau@brocade.com" > Cc: "pwe3@ietf.org" > Subject: Questions relating to draft-ietf-pwe3-iccp-15. > > Hello, > > I came across this when reading this draft. > http://tools.ietf.org/html/draft-ietf-pwe3-iccp-15 > > 1) > Section 7.2.5. > mLACP Port Config TLV says, > - Flags > > Valid values are: > > -i. Synchronized (0x01) > > Indicates that the sender has concluded transmitting all > member link port configurations for a given Aggregator. > > Shouldn't this be stating it as "given Port" ? > > >>> Aggregator is the term used by the IEEE 802.1AX standard to refer to > the Ethernet "bundle", so it is correct as is. > > > 2) I am not able to spot mail archives of this topic in the PWE3 group . > Did I do a limited search or a wrong directory search? please direct me to > the right mail archive where I can see discussion emails about this draft > so that I can know more details from it for better understanding. > > > >>>> What type of information are you looking for? The draft is quite > detailed and self-explanatory. If you have questions, please post them. > > Regards, > Samer > > I am new to this Topic of mLACP and its aggregation. I may have more > queries later on. > > Thanks, > Binny > > Aricent, India. > --001a1133a77481626304f7760a3b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Samer,

I have few questions now.

1) How many MAX redundant Groups can be possible betw= een two Peers?=C2=A0
[Binny]: In my understanding one RG configur= ed in a PE can cater many instances of Applications. for example, one can a= ssociate a mLACP Aggregation bundle t1 and t2 =C2=A0to be a part of Redunda= nt group 1. Please clarify =C2=A0and confirm.

2) As i understand from this draft, applications send t= heir TLV's to the peer through the ICCP channel. Which means mLACP Appl= ication Data Message would look like -> ICC Header (6.1.1) =C2=A0with Ty= pe 0x703+ mLACP SystemConfig Tlv (type 0032 - section 7.2.3) . Is this unde= rstanding correct that the stack order looks like Ethernet + IP + LDP Heade= r + ICCP header + Application TLVs.

If my understanding in (1) was right, then How differen= t Application Instances are distinuguished in the Packets received. (for ex= ample mLACP may have two MC-LAG instances that its managing) - but the ICC = header will have only one RG ID but the following TLV could belong to one o= f the application instances running on top of the RG. =C2=A0How to demultip= lex that.=C2=A0

I =C2=A0see a reference to ROID. Section 4.3 " That allows separate systems= in an RG=C2=A0to use a common handle to reference the protected entity" .=C2=A0=
This draft does not def= ine how exactly the ROID bytes will be encoded, as far as i read. This leav= es interop malfunction also, various options to code the ROID. one option c= ould=C2=A0
ROID =3D =C2=A0<= /div>
But im left unclea= r where i will fit this ROID in each type of packet sent by the application=

<= font color=3D"#000000">3) How do i exactly code the ROID? can you please st= andardize that > Comment please.
4) Why ROID is not mentioned to be a Part of EVERY TLV or atleast have a = Application Header or something like that to carry it ?=C2=A0

Thanks,
Binny.
Aricent.
<= br>


On 31 March 2014 23:15, Samer Salam (ssalam) <ssalam@cisco.com> wrote:
Hi Binny,

From: Binny Jeshan <binnyjeshan@gmail.com>= ;
Date: Thursday, 20 March, 2014 3:12= AM
To: "Luca Martini (lmartini)&q= uot; <lmartini@c= isco.com>, Samer Salam <ssalam@cisco.com>, "Ali Sajassi (sajassi)" &l= t;sajassi@cisco.com<= /a>>, "matthew.bocci@alcatel-lucent.co.uk" <matthew.bocci@alcatel-luc= ent.co.uk>, "satoru.matsushima@gmail.com" <sator= u.matsushima@gmail.com>, "tnadeau@brocade.com" <tnadeau@brocade.com>
Cc: "pwe3@ietf.org" <pwe3@ietf.org>
Subject: Questions relating to draf= t-ietf-pwe3-iccp-15.

Hello,

I came across this when reading this draft. http://tools.ietf.org/html/draft-ietf-pwe3-iccp-15

1)
Section 7.2.5. mLACP Port Config TLV says,
- Flags

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Valid values are:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -i. Sync= hronized (0x01)

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Indicates that the sender has concluded transmitting all =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 member link port configurations for= a given Aggregator.

Shouldn't this be stating it as "given Port" ?

>>> Aggregator is the term used by the IEEE 802.1AX standard = to refer to the Ethernet "bundle", so it is correct as is.=C2=A0<= /div>


2) I am not able to spot mail archives of this topic in the PWE3= group . Did I do a limited search or a wrong directory search? please dire= ct me to the right mail archive where I can see discussion emails about thi= s draft so that I can know more details from it for better understanding.


>>>> What type of information are you looking= for? The draft is quite detailed and self-explanatory. If you have questio= ns, please post them.=C2=A0

Regards,
Samer

I am new to this Topic of mLACP and its aggregation. I may have = more queries later on.

Thanks,
Binny

Aricent, India.

--001a1133a77481626304f7760a3b-- From nobody Wed Apr 23 23:29:30 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1A01A07A8; Wed, 23 Apr 2014 23:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3FaILBJZpNC; Wed, 23 Apr 2014 23:29:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0341A079C; Wed, 23 Apr 2014 23:29:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140424062926.31688.36473.idtracker@ietfa.amsl.com> Date: Wed, 23 Apr 2014 23:29:26 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/e0kgllhyVAQNN-WOZqkuBHO6vVE Cc: pwe3@ietf.org Subject: [PWE3] I-D Action: draft-ietf-pwe3-iccp-stp-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 06:29:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF. Title : STP Application of ICCP Authors : Mingui Zhang Huafeng Wen Jie Hu Filename : draft-ietf-pwe3-iccp-stp-01.txt Pages : 19 Date : 2014-04-23 Abstract: Inter-Chassis Communication Protocol (ICCP) supports the inter- chassis redundancy mechanism which achieves high network availability. In this document, the PEs in a Redundant Group (RG) running ICCP are used to offer multi-homed connectivity to Spanning Tree Protocol (STP) networks. The ICCP TLVs for the STP application are defined, therefore PEs from the RG can make use of these TLVs to synchronize the state and configuration data of the STP network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pwe3-iccp-stp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pwe3-iccp-stp-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-pwe3-iccp-stp-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 24 20:27:20 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA4CA1A02F9 for ; Thu, 24 Apr 2014 20:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_10_20=0.093, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtrnSs-Za89t for ; Thu, 24 Apr 2014 20:27:17 -0700 (PDT) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) by ietfa.amsl.com (Postfix) with ESMTP id A0DC21A02F4 for ; Thu, 24 Apr 2014 20:27:17 -0700 (PDT) Received: by mail-qg0-f45.google.com with SMTP id a108so3493375qge.32 for ; Thu, 24 Apr 2014 20:27:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=4PQoSmijLX6Sjl4heKnL1p1eP1Xj6b065dWr4gLelnM=; b=lc18V2Cy6Z5e5VoUs0Z7V7/sX8Imw0PHlpxNv2eUWliRrGxZXwSMuGCR8j5cNyvETi iG5LlQ9wcADVyesAQVgl1NFUbmac/2YOuCV0NLluGzCE33aK+W9WSgNhlFRxQwxvqVAd olUzaM2/d6oJ11xY1dUzlwZFRVs2380O9wZb6KUJ6X/UIdn28LlV+r2UXKnFG2eq6bvt BpXbwUjQp2hdzUJSZd7FRtSCUVhbi+nktAwsyMlbHkFkSGDT4D1XK9lFY3n6XLFwe5B4 W62wtOpd0RhFppQPRDAiBzYqf+KgPZ1nVQNBFhy8k8S+ZVCBwucx1wfpbQTaMywGQaE3 QHfg== X-Received: by 10.224.131.132 with SMTP id x4mr8039346qas.97.1398396431163; Thu, 24 Apr 2014 20:27:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.205.69 with HTTP; Thu, 24 Apr 2014 20:26:51 -0700 (PDT) From: "Andrew G. Malis" Date: Fri, 25 Apr 2014 11:26:51 +0800 Message-ID: To: "pwe3@ietf.org" Content-Type: multipart/alternative; boundary=001a11c2dd1c88e53004f7d58a2a Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/CFYzyGepkav-7Nosx3jUaF4rzpI Subject: [PWE3] PWE3 WG last call for draft-ietf-pwe3-iccp-stp-01 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 03:27:19 -0000 --001a11c2dd1c88e53004f7d58a2a Content-Type: text/plain; charset=UTF-8 This email begins a two week working group last call for http://tools.ietf.org/html/draft-ietf-pwe3-iccp-stp-01 . Please review the draft and post any comments to the PWE3 list. This working group last call will end on Friday May 9, 2014. Thanks, Andy and Matthew --001a11c2dd1c88e53004f7d58a2a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This email begins a two week working group=C2=A0last=C2=A0call=C2= =A0for=C2=A0http://tools.ietf.org/html/draft-ietf-pwe3-iccp-stp-01 .

Please review the draft and post any comments to the=C2= =A0PWE3= =C2=A0list.

This working group=C2=A0last=C2=A0call=C2=A0will end= on Friday May 9, 2014.

Thanks,
Andy and Matthew

=
--001a11c2dd1c88e53004f7d58a2a-- From nobody Thu Apr 24 20:29:42 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81F691A02F9 for ; Thu, 24 Apr 2014 20:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPoO1uEiugl5 for ; Thu, 24 Apr 2014 20:29:38 -0700 (PDT) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) by ietfa.amsl.com (Postfix) with ESMTP id E95EF1A02F4 for ; Thu, 24 Apr 2014 20:29:37 -0700 (PDT) Received: by mail-qg0-f41.google.com with SMTP id j107so2821395qga.14 for ; Thu, 24 Apr 2014 20:29:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=kfNsWAmC+KlXeXdrTkFI1k/frozJ/fhMNGlPLTPr6BY=; b=NDkEUO6shZ1CenSAvSS35f4OPj3oAAJkpSNajUdg3Q+DaDsYFUVH4ANmsLkBU9QaiN kO2ra7M5qa8ptXEaSjjvfBG3pZg+XP2HUC6yHy/whTtxKEgYmbtUMFw7WbsBfIa6x4a3 EuA9XfcBdHhaINUTMPqjGLQZ5EgCdysvH/HIPHbaBZp80XvNrIG51mFdzoapCyI7vfat 0x/RuP+nf8R5rQxYPpIkBrI6lN0rx618bv34KN2rh0zV6owO9bF1m1vLzz6//odA+13Y fFhKYxTs0QNosr65/26WtgyNvzs6k1pSZZq9N+wf5IXBUUa1TcmcfG3XVEb8jSxC54ac 8n8g== X-Received: by 10.140.96.68 with SMTP id j62mr7804865qge.5.1398396571594; Thu, 24 Apr 2014 20:29:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.205.69 with HTTP; Thu, 24 Apr 2014 20:29:11 -0700 (PDT) From: "Andrew G. Malis" Date: Fri, 25 Apr 2014 11:29:11 +0800 Message-ID: To: "pwe3@ietf.org" Content-Type: multipart/alternative; boundary=001a113ab056e7d33d04f7d592d9 Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/v_rV46ykvUv0A-NG-JMKznrCMjA Subject: [PWE3] IPR and implementation poll for draft-ietf-pwe3-iccp-stp X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 03:29:39 -0000 --001a113ab056e7d33d04f7d592d9 Content-Type: text/plain; charset=UTF-8 This is an IPR and implementation poll for http://tools.ietf.org/html/draft-ietf-pwe3-iccp-stp-01 , which is currently in WG last call. Are you aware of any IPR that applies to draft-ietf-pwe3-iccp-stp? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? Note that there are currently no IPR disclosures in the IETF datatracker. If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. The response needs to be sent to the PWE3 WG mailing list. The document will not advance to the next stage until a response has been received from each author and each contributor. If you are on the PWE3 WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. In addition, the IESG routinely asks for implementation information on a draft it is reviewing for publication. If you are aware of any implementations of this draft (yours or others), please let me know. You may respond to the list, or just to me if you prefer. If you wish for any information to remain confidential, let me know and I'll anonymize it in the document's IESG writeup. Thanks, Andy --001a113ab056e7d33d04f7d592d9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is an IPR and implementation poll for=C2=A0
ht= tp://tools.ietf.org/html/draft-ietf-pwe3-iccp-stp-01 , which is=C2=A0
currently in WG last call.

Are you aware of any IPR that applies to draft-ietf-pwe= 3-iccp-stp?

If so, has this IPR been disclosed in = compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 537= 8 for more details)? Note that there
are currently no IPR disclosures in the IETF datatracker.
If you are listed as a document author or contributor please r= espond
to this email regardless of whether or not you are aware o= f any
relevant IPR. The response needs to be sent to the PWE3 WG mailing
list. The document will not advance to the next stage until a respon= se
has been received from each author and each contributor.

If you are on the PWE3 WG email list but are not listed= as an author
or contributor, then please explicitly respond only= if you are aware
of any IPR that has not yet been disclosed in c= onformance with IETF
rules.

In addition, the IESG routinely asks f= or implementation information on
a draft it is reviewing for publ= ication. If you are aware of any
implementations of this draft (y= ours or others), please let me know.
You may respond to the list, or just to me if you prefer. If you wish<= /div>
for any information to remain confidential, let me know and I'= ;ll
anonymize it in the document's IESG writeup.

Thanks,
Andy
--001a113ab056e7d33d04f7d592d9-- From nobody Thu Apr 24 23:17:00 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB3681A035C for ; Thu, 24 Apr 2014 23:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iy2lBYXQtnbv for ; Thu, 24 Apr 2014 23:16:55 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC881A02F9 for ; Thu, 24 Apr 2014 23:16:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDM04649; Fri, 25 Apr 2014 06:16:47 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 25 Apr 2014 07:15:46 +0100 Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 25 Apr 2014 07:16:46 +0100 Received: from NKGEML508-MBX.china.huawei.com ([169.254.7.73]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Fri, 25 Apr 2014 14:16:40 +0800 From: Mingui Zhang To: "pwe3@ietf.org" Thread-Topic: [PWE3] IPR and implementation poll for draft-ietf-pwe3-iccp-stp Thread-Index: AQHPYDaax0HdcnxlGUWSTnLjRUv1upsh2RDw Date: Fri, 25 Apr 2014 06:16:38 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E7336DFBDA@nkgeml508-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.175] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/hii_wswosNlCIaORxg21oFbmtwU Subject: Re: [PWE3] IPR and implementation poll for draft-ietf-pwe3-iccp-stp X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 06:16:57 -0000 SSdtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgaXMgYXBwbGljYWJsZSB0byB0aGlzIGRyYWZ0 Lg0KDQpUaGFua3MsDQpNaW5ndWkNCg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJv bTogcHdlMyBbbWFpbHRvOnB3ZTMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFuZHJl dyBHLiBNYWxpcw0KPlNlbnQ6IEZyaWRheSwgQXByaWwgMjUsIDIwMTQgMTE6MjkgQU0NCj5Ubzog cHdlM0BpZXRmLm9yZw0KPlN1YmplY3Q6IFtQV0UzXSBJUFIgYW5kIGltcGxlbWVudGF0aW9uIHBv bGwgZm9yIGRyYWZ0LWlldGYtcHdlMy1pY2NwLXN0cA0KPg0KPlRoaXMgaXMgYW4gSVBSIGFuZCBp bXBsZW1lbnRhdGlvbiBwb2xsIGZvcg0KPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtcHdlMy1pY2NwLXN0cC0wMSAsIHdoaWNoIGlzDQo+Y3VycmVudGx5IGluIFdHIGxhc3Qg Y2FsbC4NCj4NCj5BcmUgeW91IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIGRyYWZ0 LWlldGYtcHdlMy1pY2NwLXN0cD8NCj4NCj5JZiBzbywgaGFzIHRoaXMgSVBSIGJlZW4gZGlzY2xv c2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcw0KPihzZWUgUkZDcyAzOTc5LCA0 ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpPyBOb3RlIHRoYXQgdGhlcmUNCj5h cmUgY3VycmVudGx5IG5vIElQUiBkaXNjbG9zdXJlcyBpbiB0aGUgSUVURiBkYXRhdHJhY2tlci4N Cj4NCj5JZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmlidXRv ciBwbGVhc2UgcmVzcG9uZA0KPnRvIHRoaXMgZW1haWwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9y IG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueQ0KPnJlbGV2YW50IElQUi4gVGhlIHJlc3BvbnNlIG5l ZWRzIHRvIGJlIHNlbnQgdG8gdGhlIFBXRTMgV0cgbWFpbGluZw0KPmxpc3QuIFRoZSBkb2N1bWVu dCB3aWxsIG5vdCBhZHZhbmNlIHRvIHRoZSBuZXh0IHN0YWdlIHVudGlsIGEgcmVzcG9uc2UNCj5o YXMgYmVlbiByZWNlaXZlZCBmcm9tIGVhY2ggYXV0aG9yIGFuZCBlYWNoIGNvbnRyaWJ1dG9yLg0K Pg0KPklmIHlvdSBhcmUgb24gdGhlIFBXRTMgV0cgZW1haWwgbGlzdCBidXQgYXJlIG5vdCBsaXN0 ZWQgYXMgYW4gYXV0aG9yDQo+b3IgY29udHJpYnV0b3IsIHRoZW4gcGxlYXNlIGV4cGxpY2l0bHkg cmVzcG9uZCBvbmx5IGlmIHlvdSBhcmUgYXdhcmUNCj5vZiBhbnkgSVBSIHRoYXQgaGFzIG5vdCB5 ZXQgYmVlbiBkaXNjbG9zZWQgaW4gY29uZm9ybWFuY2Ugd2l0aCBJRVRGDQo+cnVsZXMuDQo+DQo+ SW4gYWRkaXRpb24sIHRoZSBJRVNHIHJvdXRpbmVseSBhc2tzIGZvciBpbXBsZW1lbnRhdGlvbiBp bmZvcm1hdGlvbiBvbg0KPmEgZHJhZnQgaXQgaXMgcmV2aWV3aW5nIGZvciBwdWJsaWNhdGlvbi4g SWYgeW91IGFyZSBhd2FyZSBvZiBhbnkNCj5pbXBsZW1lbnRhdGlvbnMgb2YgdGhpcyBkcmFmdCAo eW91cnMgb3Igb3RoZXJzKSwgcGxlYXNlIGxldCBtZSBrbm93Lg0KPllvdSBtYXkgcmVzcG9uZCB0 byB0aGUgbGlzdCwgb3IganVzdCB0byBtZSBpZiB5b3UgcHJlZmVyLiBJZiB5b3Ugd2lzaA0KPmZv ciBhbnkgaW5mb3JtYXRpb24gdG8gcmVtYWluIGNvbmZpZGVudGlhbCwgbGV0IG1lIGtub3cgYW5k IEknbGwNCj5hbm9ueW1pemUgaXQgaW4gdGhlIGRvY3VtZW50J3MgSUVTRyB3cml0ZXVwLg0KPg0K PlRoYW5rcywNCj5BbmR5DQo= From nobody Fri Apr 25 10:13:56 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BCF21A06A3 for ; Fri, 25 Apr 2014 10:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdNIrIVeY-mw for ; Fri, 25 Apr 2014 10:13:50 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) by ietfa.amsl.com (Postfix) with ESMTP id 50A8F1A06AA for ; Fri, 25 Apr 2014 10:13:48 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id 10so3305119lbg.11 for ; Fri, 25 Apr 2014 10:13:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nuGt5KQOAhtTi0o5NmBubd+9YAqnDEjTMdbsw7LIxvU=; b=X9o+4k322QVcNoeV6QpQECpMC2iPAMx/VOOsLZSnpFdrwMzTd9fQ1fDYP5WoJ0LPvN b+81BqL/ut6Dpogk4sq4ddR6FaMTW+Lnyr+1mED87Xy+TuTuuGlV4rR7ygWMJeZf1/jm ND9eCbBs18m50O6DFJXkpDBVYWmYdSxij0K6MNdAfe9iqfypspsmEWVl/CA8dv7YrqMj D+F9VCfit+KRVODhdSH8LMzXnp+Cetm7kpaIr3k4sVVkbJfABPOgo2gwcq+VMkO51j7z Q8ww4OcftPh/jO7zP3C67oRZIpqN+OYgKQ855/YDRNY9fKejQlKDIF6/dG7iHyEMqBBG Dg5g== MIME-Version: 1.0 X-Received: by 10.112.205.35 with SMTP id ld3mr6059481lbc.1.1398446021122; Fri, 25 Apr 2014 10:13:41 -0700 (PDT) Received: by 10.114.2.110 with HTTP; Fri, 25 Apr 2014 10:13:40 -0700 (PDT) In-Reply-To: References: Date: Fri, 25 Apr 2014 20:13:40 +0300 Message-ID: From: Binny Jeshan To: "Samer Salam (ssalam)" Content-Type: multipart/alternative; boundary=001a11c3d864539e8804f7e116aa Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/voBp9iDNSyEz0jP0uke6kSHJoq8 Cc: "Ali Sajassi \(sajassi\)" , "tnadeau@brocade.com" , "Luca Martini \(lmartini\)" , "matthew.bocci@alcatel-lucent.co.uk" , "pwe3@ietf.org" Subject: Re: [PWE3] Questions relating to draft-ietf-pwe3-iccp-15. X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 17:13:52 -0000 --001a11c3d864539e8804f7e116aa Content-Type: text/plain; charset=UTF-8 Dear Authors, all, A gentle reminder. Thanks. On 20 April 2014 12:31, Binny Jeshan wrote: > Hi Samer, > > I have few questions now. > > 1) How many MAX redundant Groups can be possible between two Peers? > [Binny]: In my understanding one RG configured in a PE can cater many > instances of Applications. for example, one can associate a mLACP > Aggregation bundle t1 and t2 to be a part of Redundant group 1. Please > clarify and confirm. > > 2) As i understand from this draft, applications send their TLV's to the > peer through the ICCP channel. Which means mLACP Application Data Message > would look like -> ICC Header (6.1.1) with Type 0x703+ mLACP SystemConfig > Tlv (type 0032 - section 7.2.3) . Is this understanding correct that the > stack order looks like Ethernet + IP + LDP Header + ICCP header + > Application TLVs. > > If my understanding in (1) was right, then How different Application > Instances are distinuguished in the Packets received. (for example mLACP > may have two MC-LAG instances that its managing) - but the ICC header will > have only one RG ID but the following TLV could belong to one of the > application instances running on top of the RG. How to demultiplex that. > > I see a reference to ROID. Section 4.3 " That allows *separate systems > in an RG **to use a common handle* to reference the protected entity" . > This draft does not define how exactly the ROID bytes will be encoded, as > far as i read. This leaves interop malfunction also, various options to > code the ROID. one option could > ROID = > But im left unclear where i will fit this ROID in each type of packet sent > by the application > > 3) How do i exactly code the ROID? can you please standardize that > > Comment please. > 4) Why ROID is not mentioned to be a Part of EVERY TLV or atleast have a > Application Header or something like that to carry it ? > > Thanks, > Binny. > Aricent. > > > > On 31 March 2014 23:15, Samer Salam (ssalam) wrote: > >> Hi Binny, >> >> From: Binny Jeshan >> Date: Thursday, 20 March, 2014 3:12 AM >> To: "Luca Martini (lmartini)" , Samer Salam < >> ssalam@cisco.com>, "Ali Sajassi (sajassi)" , " >> matthew.bocci@alcatel-lucent.co.uk" , >> "satoru.matsushima@gmail.com" , " >> tnadeau@brocade.com" >> Cc: "pwe3@ietf.org" >> Subject: Questions relating to draft-ietf-pwe3-iccp-15. >> >> Hello, >> >> I came across this when reading this draft. >> http://tools.ietf.org/html/draft-ietf-pwe3-iccp-15 >> >> 1) >> Section 7.2.5. >> mLACP Port Config TLV says, >> - Flags >> >> Valid values are: >> >> -i. Synchronized (0x01) >> >> Indicates that the sender has concluded transmitting all >> member link port configurations for a given Aggregator. >> >> Shouldn't this be stating it as "given Port" ? >> >> >>> Aggregator is the term used by the IEEE 802.1AX standard to refer >> to the Ethernet "bundle", so it is correct as is. >> >> >> 2) I am not able to spot mail archives of this topic in the PWE3 group >> . Did I do a limited search or a wrong directory search? please direct me >> to the right mail archive where I can see discussion emails about this >> draft so that I can know more details from it for better understanding. >> >> >> >>>> What type of information are you looking for? The draft is quite >> detailed and self-explanatory. If you have questions, please post them. >> >> Regards, >> Samer >> >> I am new to this Topic of mLACP and its aggregation. I may have more >> queries later on. >> >> Thanks, >> Binny >> >> Aricent, India. >> > > --001a11c3d864539e8804f7e116aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Authors, all,

A gentle reminder.= =C2=A0

Thanks.


On 20 April 2014 12:31, Binny Jeshan = <binnyjeshan@gmail.com> wrote:
Hi Samer,

I have few questions now.

1) How many MAX redund= ant Groups can be possible between two Peers?=C2=A0
[Binny]: In my understanding one RG configured in a PE can cater many = instances of Applications. for example, one can associate a mLACP Aggregati= on bundle t1 and t2 =C2=A0to be a part of Redundant group 1. Please clarify= =C2=A0and confirm.

2) As i understand from this draft, applications send t= heir TLV's to the peer through the ICCP channel. Which means mLACP Appl= ication Data Message would look like -> ICC Header (6.1.1) =C2=A0with Ty= pe 0x703+ mLACP SystemConfig Tlv (type 0032 - section 7.2.3) . Is this unde= rstanding correct that the stack order looks like Ethernet + IP + LDP Heade= r + ICCP header + Application TLVs.

If my understanding in (1) was right, then How differen= t Application Instances are distinuguished in the Packets received. (for ex= ample mLACP may have two MC-LAG instances that its managing) - but the ICC = header will have only one RG ID but the following TLV could belong to one o= f the application instances running on top of the RG. =C2=A0How to demultip= lex that.=C2=A0

I =C2=A0see a reference to ROID. Section 4.3 " That allows separate systems in an RG=C2=A0to use a common handle to ref= erence the protected entity" .=C2=A0
This draft does not define how exactly t= he ROID bytes will be encoded, as far as i read. This leaves interop malfun= ction also, various options to code the ROID. one option could=C2=A0=
ROID =3D =C2=A0
But im left unclear where i will fit this ROID in ea= ch type of packet sent by the application

3) How do i exactly code the ROID? can you please standardize that &g= t; Comment please.
4) Why ROID is = not mentioned to be a Part of EVERY TLV or atleast have a Application Heade= r or something like that to carry it ?=C2=A0

Thanks,
Binny.
Aricent.
<= br>


On 31 March 2014 23:15, Samer Sal= am (ssalam) <ssalam@cisco.com> wrote:
Hi Binny,

From: Binny Jeshan <binnyjeshan@gmail.com>= ;
Date: Thursday, 20 March, 2014 3:12= AM
To: "Luca Martini (lmartini)&q= uot; <lmartini@c= isco.com>, Samer Salam <ssalam@cisco.com>, "Ali Sajassi (sajassi)" &l= t;sajassi@cisco.com<= /a>>, "matthew.bocci@alcatel-lucent.co.uk" <matthew.bocci@alcatel-luc= ent.co.uk>, "satoru.matsushima@gmail.com" <sator= u.matsushima@gmail.com>, "tnadeau@brocade.com" <tnadeau@brocade.com>
Cc: "pwe3@ietf.org" <pwe3@ietf.org>
Subject: Questions relating to draf= t-ietf-pwe3-iccp-15.

Hello,

I came across this when reading this draft. http://tools.ietf.org/html/draft-ietf-pwe3-iccp-15

1)
Section 7.2.5. mLACP Port Config TLV says,
- Flags

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Valid values are:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -i. Sync= hronized (0x01)

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Indicates that the sender has concluded transmitting all =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 member link port configurations for= a given Aggregator.

Shouldn't this be stating it as "given Port" ?

>>> Aggregator is the term used by the IEEE 802.1AX standard = to refer to the Ethernet "bundle", so it is correct as is.=C2=A0<= /div>


2) I am not able to spot mail archives of this topic in the PWE3= group . Did I do a limited search or a wrong directory search? please dire= ct me to the right mail archive where I can see discussion emails about thi= s draft so that I can know more details from it for better understanding.


>>>> What type of information are you looking= for? The draft is quite detailed and self-explanatory. If you have questio= ns, please post them.=C2=A0

Regards,
Samer

I am new to this Topic of mLACP and its aggregation. I may have = more queries later on.

Thanks,
Binny

Aricent, India.


--001a11c3d864539e8804f7e116aa-- From nobody Wed Apr 30 02:52:06 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D040A1A08B5 for ; Wed, 30 Apr 2014 02:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6RsvjrP3nNO for ; Wed, 30 Apr 2014 02:51:52 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 774A01A08B0 for ; Wed, 30 Apr 2014 02:51:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDR18124; Wed, 30 Apr 2014 09:51:49 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 30 Apr 2014 10:50:45 +0100 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 30 Apr 2014 10:51:43 +0100 Received: from NKGEML503-MBS.china.huawei.com ([169.254.6.2]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Wed, 30 Apr 2014 17:51:40 +0800 From: Wenhuafeng To: "pwe3@ietf.org" Thread-Topic: [PWE3] IPR and implementation poll for draft-ietf-pwe3-iccp-stp Thread-Index: AQHPYDabxTLAgBtheUCmbxLTEzc/tZshVUsAgAh5hSI= Date: Wed, 30 Apr 2014 09:51:40 +0000 Message-ID: References: , <4552F0907735844E9204A62BBDD325E7336DFBDA@nkgeml508-mbx.china.huawei.com> In-Reply-To: <4552F0907735844E9204A62BBDD325E7336DFBDA@nkgeml508-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.175] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/cAPob4Yf911BMnPohmj2ajSbZeU Subject: Re: [PWE3] IPR and implementation poll for draft-ietf-pwe3-iccp-stp X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 09:52:02 -0000 I'm not aware of any IPR related to this draft. Thanks, Huafeng Wen >-----Original Message----- >From: pwe3 [mailto:pwe3-bounces@ietf.org] On Behalf Of Andrew G. Malis >Sent: Friday, April 25, 2014 11:29 AM >To: pwe3@ietf.org >Subject: [PWE3] IPR and implementation poll for draft-ietf-pwe3-iccp-stp > >This is an IPR and implementation poll for >http://tools.ietf.org/html/draft-ietf-pwe3-iccp-stp-01 , which is >currently in WG last call. > >Are you aware of any IPR that applies to draft-ietf-pwe3-iccp-stp? > >If so, has this IPR been disclosed in compliance with IETF IPR rules >(see RFCs 3979, 4879, 3669 and 5378 for more details)? Note that there >are currently no IPR disclosures in the IETF datatracker. > >If you are listed as a document author or contributor please respond >to this email regardless of whether or not you are aware of any >relevant IPR. The response needs to be sent to the PWE3 WG mailing >list. The document will not advance to the next stage until a response >has been received from each author and each contributor. > >If you are on the PWE3 WG email list but are not listed as an author >or contributor, then please explicitly respond only if you are aware >of any IPR that has not yet been disclosed in conformance with IETF >rules. > >In addition, the IESG routinely asks for implementation information on >a draft it is reviewing for publication. If you are aware of any >implementations of this draft (yours or others), please let me know. >You may respond to the list, or just to me if you prefer. If you wish >for any information to remain confidential, let me know and I'll >anonymize it in the document's IESG writeup. > >Thanks, >Andy _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3= From nobody Wed Apr 30 12:40:01 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3EEE1A889A for ; Wed, 30 Apr 2014 12:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id etTKV2R7kTm3 for ; Wed, 30 Apr 2014 12:39:53 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 8B3A01A888B for ; Wed, 30 Apr 2014 12:39:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19326; q=dns/txt; s=iport; t=1398886791; x=1400096391; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=ovc/ZpaybcabSywt9BfB/pIYqLSznYbbMorP6trlnVM=; b=ik+vh5qgJ1uCefe5BYsbSuvb8JBpvyU2gASUFDmD/XvHGDCqHXgmby1E CtHLtdtmkpSUjrjIh1JQtgqD7m7VsqZx/g/m0VkeJd8trZolRENKPkfHn WF2fTplrtjl768KVz4KvDLW7nGD3gQ4WhMvSJevOvpTXrE9i0VwUeBuG3 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAHxQYVOtJV2a/2dsb2JhbABZgkIjIU9Xu0qJAIEhFnSCJQEBAQMBJ1ISAQgRAwECKCgRFAkIAgQOBYgtAwkIAQzCSw2GUBeMOoE/BwEBPhEGAQaEMwSVM4IDgXGBPItVhVqDMYFpCRci X-IronPort-AV: E=Sophos;i="4.97,960,1389744000"; d="scan'208,217";a="321547706" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 30 Apr 2014 19:39:50 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s3UJdoWJ000918 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Apr 2014 19:39:50 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Wed, 30 Apr 2014 14:39:49 -0500 From: "Samer Salam (ssalam)" To: Binny Jeshan Thread-Topic: Questions relating to draft-ietf-pwe3-iccp-15. Thread-Index: AQHPRCTshILx7+E75Ue8IOC3z2bFjpr7kjgAgB8vzICAD+wPAA== Date: Wed, 30 Apr 2014 19:39:49 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [161.44.210.114] Content-Type: multipart/alternative; boundary="_000_CF869CAA2933Bssalamciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/Sk4IqVliYeJ0ALfr4zNFCDvS50Y Cc: "Ali Sajassi \(sajassi\)" , "tnadeau@brocade.com" , "Luca Martini \(lmartini\)" , "matthew.bocci@alcatel-lucent.co.uk" , "pwe3@ietf.org" Subject: Re: [PWE3] Questions relating to draft-ietf-pwe3-iccp-15. X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 19:39:59 -0000 --_000_CF869CAA2933Bssalamciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Binny, Please find responses inline at [s1] From: Binny Jeshan > Date: Sunday, 20 April, 2014 2:31 AM To: Samer Salam > Cc: "Luca Martini (lmartini)" >, "Ali Sajassi (sajassi)" >, = "matthew.bocci@alcatel-lucent.co.uk" >, "satoru.matsushima@gmail.com= " >, "tnade= au@brocade.com" >, "pwe3@ietf.org" > Subject: Re: Questions relating to draft-ietf-pwe3-iccp-15. Hi Samer, I have few questions now. 1) How many MAX redundant Groups can be possible between two Peers? [Binny]: In my understanding one RG configured in a PE can cater many insta= nces of Applications. for example, one can associate a mLACP Aggregation bu= ndle t1 and t2 to be a part of Redundant group 1. Please clarify and conf= irm. [s1] Typically, between two PEs, a single Redundancy Group is sufficient. I= ndeed, it is possible to associate multiple bundle interfaces with the same= group. Usually, multiple RGs are employed if you need to logically group 3= or more PEs into subsets. E.g. PE1, PE2, PE3. On PE1, you may have an RG w= ith PE2 and another RG with PE3 to perform flexible grouping. 2) As i understand from this draft, applications send their TLV's to the pe= er through the ICCP channel. Which means mLACP Application Data Message wou= ld look like -> ICC Header (6.1.1) with Type 0x703+ mLACP SystemConfig Tlv= (type 0032 - section 7.2.3) . Is this understanding correct that the stack= order looks like Ethernet + IP + LDP Header + ICCP header + Application TL= Vs. [s1] Correct. If my understanding in (1) was right, then How different Application Instan= ces are distinuguished in the Packets received. (for example mLACP may have= two MC-LAG instances that its managing) - but the ICC header will have onl= y one RG ID but the following TLV could belong to one of the application in= stances running on top of the RG. How to demultiplex that. [s1] You are mixing up two things here: each application has a single insta= nce in a given RG. That is, there is one mLCAP client application of ICCP. = This application is managing both MC-LAG instances (in your example). The w= ay by which one MC-LAG is distinguished from the other is by the ROID or Ag= gregator ID. I see a reference to ROID. Section 4.3 " That allows separate systems in a= n RG to use a common handle to reference the protected entity" . This draft does not define how exactly the ROID bytes will be encoded, as f= ar as i read. This leaves interop malfunction also, various options to code= the ROID. one option could ROID =3D But im left unclear where i will fit this ROID in each type of packet sent = by the application [s1] The only requirement for interoperability between systems is that all = PEs in the RG use the same ROID numeric value for the same protected entity= . If an implementation wishes to encode semantics in the ROID, that's fine,= and out of scope of the draft. 3) How do i exactly code the ROID? can you please standardize that > Commen= t please. [s1] The semantics of the ROID is irrelevant for interoperability, that's w= hy it was not standardized. All what is required is that it matches on the = PEs. You can have it set by configuration, for example. 4) Why ROID is not mentioned to be a Part of EVERY TLV or atleast have a Ap= plication Header or something like that to carry it ? [s1] It is treated as part of the configuration data, and hence it does not= change dynamically during the lifespan of the application connection. If i= t does change, then this is handled as if the object is deleted and a new c= reated. This allows you to safely reset the associated state machines. Regards, Samer Thanks, Binny. Aricent. On 31 March 2014 23:15, Samer Salam (ssalam) > wrote: Hi Binny, From: Binny Jeshan > Date: Thursday, 20 March, 2014 3:12 AM To: "Luca Martini (lmartini)" >, Samer Salam >, "Ali Sajassi (= sajassi)" >, "matthew.bocci@alc= atel-lucent.co.uk" >, "satoru= .matsushima@gmail.com" >, "tnadeau@brocade.com" > Cc: "pwe3@ietf.org" > Subject: Questions relating to draft-ietf-pwe3-iccp-15. Hello, I came across this when reading this draft. http://tools.ietf.org/html/draf= t-ietf-pwe3-iccp-15 1) Section 7.2.5. mLACP Port Config TLV says, - Flags Valid values are: -i. Synchronized (0x01) Indicates that the sender has concluded transmitting all member link port configurations for a given Aggregator. Shouldn't this be stating it as "given Port" ? >>> Aggregator is the term used by the IEEE 802.1AX standard to refer to th= e Ethernet "bundle", so it is correct as is. 2) I am not able to spot mail archives of this topic in the PWE3 group . Di= d I do a limited search or a wrong directory search? please direct me to th= e right mail archive where I can see discussion emails about this draft so = that I can know more details from it for better understanding. >>>> What type of information are you looking for? The draft is quite detai= led and self-explanatory. If you have questions, please post them. Regards, Samer I am new to this Topic of mLACP and its aggregation. I may have more querie= s later on. Thanks, Binny Aricent, India. --_000_CF869CAA2933Bssalamciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <86EE00A347D5754489C0EC8ADC277812@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Binny,

Please find responses inline at [s1]
From: Binny Jeshan <binnyjeshan@gmail.com>
Date: Sunday, 20 April, 2014 2:31 A= M
To: Samer Salam <ssalam@cisco.com>
Cc: "Luca Martini (lmartini)&q= uot; <lmartini@cisco.com>, = "Ali Sajassi (sajassi)" <= sajassi@cisco.com>, "matthew.bocci@alcatel-lucent.co.uk" <matthew.bocci@al= catel-lucent.co.uk>, "satoru.matsushima@gmail.com" <satoru.matsushima@gmail.com>, "tnadeau@brocade.com" <tnadeau@brocade.com>, &q= uot;pwe3@ietf.org" <pwe3@ietf.org>
Subject: Re: Questions relating to = draft-ietf-pwe3-iccp-15.

Hi Samer,

I have few questions now.

1) How many MAX redundant Groups can be possible between two Peers?&nb= sp;
[Binny]: In my understanding one RG configured in a PE can cater many = instances of Applications. for example, one can associate a mLACP Aggregati= on bundle t1 and t2  to be a part of Redundant group 1. Please clarify=  and confirm.

[s1] Typically, between two PEs, a single Redundancy Group is sufficie= nt. Indeed, it is possible to associate multiple bundle interfaces with the= same group. Usually, multiple RGs are employed if you need to logically gr= oup 3 or more PEs into subsets. E.g. PE1, PE2, PE3. On PE1, you may have an RG with PE2 and another RG wit= h PE3 to perform flexible grouping.
  

2) As i understand from this draft, applications send their TLV's to t= he peer through the ICCP channel. Which means mLACP Application Data Messag= e would look like -> ICC Header (6.1.1)  with Type 0x703+ mLACP= SystemConfig Tlv (type 0032 - section 7.2.3) . Is this understanding correct that the stack order looks like Ethernet &= #43; IP + LDP Header + ICCP header + Application TLVs.

[s1] Correct.

If my understanding in (1) was right, then How different Application I= nstances are distinuguished in the Packets received. (for example mLACP may= have two MC-LAG instances that its managing) - but the ICC header will hav= e only one RG ID but the following TLV could belong to one of the application instances running on top of the= RG.  How to demultiplex that. 

[s1] You are mixing up two things here: each application has a single = instance in a given RG. That is, there is one mLCAP client application of I= CCP. This application is managing both MC-LAG instances (in your example). = The way by which one MC-LAG is distinguished from the other is by the ROID or Aggregator ID. 

I  see a reference to ROID. Section 4.3 " That allows separate systems in an RG to use a common handle to reference the protected e= ntity" . 
This draft does not def= ine how exactly the ROID bytes will be encoded, as far as i read. This leav= es interop malfunction also, various options to code the ROID. one option c= ould 
ROID =3D  <= /div>
But im left unclear whe= re i will fit this ROID in each type of packet sent by the application

[s1] The only requirement for interoperability between systems is that= all PEs in the RG use the same ROID numeric value for the same protected e= ntity. If an implementation wishes to encode semantics in the ROID, that's = fine, and out of scope of the draft. 

3) How do i exactly code the ROID? can you ple= ase standardize that > Comment please.

[s1] The semantics of the ROID is irrelevant for interoperability, tha= t's why it was not standardized. All what is required is that it matches on= the PEs. You can have it set by configuration, for example.

4) Why ROID is not mentioned to be a Part of E= VERY TLV or atleast have a Application Header or something like that to car= ry it ? 

[s1] It is treated as part of the configuration data, and hence it doe= s not change dynamically during the lifespan of the application connection.= If it does change, then this is handled as if the object is deleted and a = new created. This allows you to safely reset the associated state machines. 

Regards,
Samer

Thanks,
Binny.
Aricent.



On 31 March 2014 23:15, Samer Salam (ssalam) <ssalam@cisco.com<= /a>> wrote:
Hi Binny,

From: Binny Jeshan <binnyjeshan@gmail.com>= ;
Date: Thursday, 20 March, 2014 3:12= AM
To: "Luca Martini (lmartini)&q= uot; <lmartini@c= isco.com>, Samer Salam <ssalam@cisco.com>, "Ali Sajassi (sajassi)" &l= t;sajassi@cisco.com<= /a>>, "matthew.bocci@alcatel-lucent.co.uk" <matthew.bocci@alcatel-luc= ent.co.uk>, "satoru.matsushima@gmail.com" <sator= u.matsushima@gmail.com>, "tnadeau@brocade.com" <tnadeau@brocade.com>
Cc: "pwe3@ietf.org" <pwe3@ietf.org>
Subject: Questions relating to draf= t-ietf-pwe3-iccp-15.

Hello,

I came across this when reading this draft. http://tools.ietf.org/html/draft-ietf-pwe3-iccp-15

1)
Section 7.2.5. mLACP Port Config TLV says,
- Flags

       Valid values are:

            -i. Sync= hronized (0x01)

            &nb= sp;   Indicates that the sender has concluded transmitting all             &nb= sp;   member link port configurations for= a given Aggregator.

Shouldn't this be stating it as "given Port" ? =

>>> Aggregator is the term used by the IEEE 802.1AX standard = to refer to the Ethernet "bundle", so it is correct as is. <= /div>


2) I am not able to spot mail archives of this topic in the PWE3= group . Did I do a limited search or a wrong directory search? please dire= ct me to the right mail archive where I can see discussion emails about thi= s draft so that I can know more details from it for better understanding.


>>>> What type of information are you looking= for? The draft is quite detailed and self-explanatory. If you have questio= ns, please post them. 

Regards,
Samer

I am new to this Topic of mLACP and its aggregation. I may have = more queries later on.

Thanks,
Binny

Aricent, India.

 --_000_CF869CAA2933Bssalamciscocom_-- From nobody Wed Apr 30 13:59:45 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E82AA1A0776 for ; Wed, 30 Apr 2014 13:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yYVVW-oovI4S for ; Wed, 30 Apr 2014 13:59:40 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2091A06DB for ; Wed, 30 Apr 2014 13:59:40 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id q58so2222611wes.20 for ; Wed, 30 Apr 2014 13:59:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:mime-version:to:cc:from:subject:date:content-type; bh=WpgCJX0zjXcp4n173idE53C+jN40xBZlf4My1k2hsjU=; b=F+sbNzH0Sd1MFTcDIp9FCgI/U2Vm+R83pdDV9rZFQYCer4Q1d+IfaNziip+RXIfIQc RYtSBmiyCv2CeBZzEqr2wwif2/ifB4YjLox67WXGcg2iqn+rtBYA1fwqLslGEgnSpFLM qWaJxb8ijqmOdG5eoZDqVJJ5bcPE99ElgNiReeHAKxzPcuDcEAXDTcAVgmIGPXlbaQTN TBvszpneA1GYEk5lPTQJ7c8etEsOYA6zZ/q55LuzdfPcSXy7NPJr+JM0woLtk1BA5RTL X0w/A+/7tIJ8NnXJKyXsZLx+TAwMSK+BP5Q9gygp7hCiromvvj55P769xKOlIoc78Onh 3YMA== X-Received: by 10.194.59.226 with SMTP id c2mr5803002wjr.6.1398891578246; Wed, 30 Apr 2014 13:59:38 -0700 (PDT) Received: from [10.0.0.8] ([109.64.114.4]) by mx.google.com with ESMTPSA id lj15sm5978299wic.13.2014.04.30.13.59.35 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 30 Apr 2014 13:59:37 -0700 (PDT) Message-ID: <53616439.efcdb40a.339b.ffffd9bf@mx.google.com> MIME-Version: 1.0 To: "Samer Salam (ssalam)" From: Binny Jeshan Date: Wed, 30 Apr 2014 23:58:14 +0300 Content-Type: multipart/alternative; boundary="_EEA1C136-502D-46EA-B3BC-E7EF9037D718_" Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/ryhcXqHDX4fUaogWQHK-V3otvvE Cc: "Ali Sajassi \(sajassi\)" , "tnadeau@brocade.com" , "Luca Martini \(lmartini\)" , "matthew.bocci@alcatel-lucent.co.uk" , "pwe3@ietf.org" Subject: Re: [PWE3] Questions relating to draft-ietf-pwe3-iccp-15. X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 20:59:43 -0000 --_EEA1C136-502D-46EA-B3BC-E7EF9037D718_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hi Samer, To the last question I had, I am still left unclear & with a feeling that i= t would be good to have a ROID that is always a part of the application dat= a message so that at the receiving end demultiplexing becomes better especi= ally when multiple bundles or applications use the ICCP channel. The packet= information would look a bit more informative in that case, and also helps= a bit more for implementation. In mc-lag case, if I don't have a ROID carried in every application data pa= cket, I'd be required to inspect aggregator or port configuration data for = demultiplexing that packet to the right bundle, which is not so good. Had I= encoded a,ROID something like 32bit RG ID + 32 bit aggregator ID / bundle = unique id, and sent this on the very top of the application message, things= get more nicer. I'd kindly suggest to adding ROID in this way of usage, as because the curr= ent ROID advertisement in just one of the packets seems not showing ease. P= lease consider, and feedback. Regards, Binny. Sent from Nokia Lumia. -----Original Message----- From: "Samer Salam (ssalam)" Sent: =E2=80=8E30-=E2=80=8E04-=E2=80=8E2014 10:39 PM To: "Binny Jeshan" Cc: "Luca Martini (lmartini)" ; "Ali Sajassi (sajassi)"= ; "matthew.bocci@alcatel-lucent.co.uk" ; "satoru.matsushima@gmail.com" ; "tnadeau@brocade.com" ; "pwe3@ietf.org" Subject: Re: Questions relating to draft-ietf-pwe3-iccp-15. Hi Binny, Please find responses inline at [s1] From: Binny Jeshan Date: Sunday, 20 April, 2014 2:31 AM To: Samer Salam Cc: "Luca Martini (lmartini)" , "Ali Sajassi (sajassi)"= , "matthew.bocci@alcatel-lucent.co.uk" , "satoru.matsushima@gmail.com" , "tnadeau@brocade.com" , "pwe3@ietf.org" Subject: Re: Questions relating to draft-ietf-pwe3-iccp-15. Hi Samer,=20 I have few questions now. 1) How many MAX redundant Groups can be possible between two Peers?=20 [Binny]: In my understanding one RG configured in a PE can cater many insta= nces of Applications. for example, one can associate a mLACP Aggregation bu= ndle t1 and t2 to be a part of Redundant group 1. Please clarify and conf= irm. [s1] Typically, between two PEs, a single Redundancy Group is sufficient. I= ndeed, it is possible to associate multiple bundle interfaces with the same= group. Usually, multiple RGs are employed if you need to logically group 3= or more PEs into subsets. E.g. PE1, PE2, PE3. On PE1, you may have an RG w= ith PE2 and another RG with PE3 to perform flexible grouping. =20 2) As i understand from this draft, applications send their TLV's to the pe= er through the ICCP channel. Which means mLACP Application Data Message wou= ld look like -> ICC Header (6.1.1) with Type 0x703+ mLACP SystemConfig Tlv= (type 0032 - section 7.2.3) . Is this understanding correct that the stack= order looks like Ethernet + IP + LDP Header + ICCP header + Application TL= Vs. [s1] Correct. If my understanding in (1) was right, then How different Application Instan= ces are distinuguished in the Packets received. (for example mLACP may have= two MC-LAG instances that its managing) - but the ICC header will have onl= y one RG ID but the following TLV could belong to one of the application in= stances running on top of the RG. How to demultiplex that.=20 [s1] You are mixing up two things here: each application has a single insta= nce in a given RG. That is, there is one mLCAP client application of ICCP. = This application is managing both MC-LAG instances (in your example). The w= ay by which one MC-LAG is distinguished from the other is by the ROID or Ag= gregator ID.=20 I see a reference to ROID. Section 4.3 " That allows separate systems in a= n RG to use a common handle to reference the protected entity" .=20 This draft does not define how exactly the ROID bytes will be encoded, as f= ar as i read. This leaves interop malfunction also, various options to code= the ROID. one option could=20 ROID =3D =20 But im left unclear where i will fit this ROID in each type of packet sent = by the application [s1] The only requirement for interoperability between systems is that all = PEs in the RG use the same ROID numeric value for the same protected entity= . If an implementation wishes to encode semantics in the ROID, that's fine,= and out of scope of the draft.=20 3) How do i exactly code the ROID? can you please standardize that > Commen= t please. [s1] The semantics of the ROID is irrelevant for interoperability, that's w= hy it was not standardized. All what is required is that it matches on the = PEs. You can have it set by configuration, for example. 4) Why ROID is not mentioned to be a Part of EVERY TLV or atleast have a Ap= plication Header or something like that to carry it ?=20 [s1] It is treated as part of the configuration data, and hence it does not= change dynamically during the lifespan of the application connection. If i= t does change, then this is handled as if the object is deleted and a new c= reated. This allows you to safely reset the associated state machines.=20 Regards, Samer Thanks, Binny. Aricent. On 31 March 2014 23:15, Samer Salam (ssalam) wrote: Hi Binny, From: Binny Jeshan Date: Thursday, 20 March, 2014 3:12 AM To: "Luca Martini (lmartini)" , Samer Salam , "Ali Sajassi (sajassi)" , "matthew.bocci@alcate= l-lucent.co.uk" , "satoru.matsushima@gm= ail.com" , "tnadeau@brocade.com" Cc: "pwe3@ietf.org" Subject: Questions relating to draft-ietf-pwe3-iccp-15. Hello, I came across this when reading this draft. http://tools.ietf.org/html/draf= t-ietf-pwe3-iccp-15 1)=20 Section 7.2.5. mLACP Port Config TLV says, - Flags Valid values are: -i. Synchronized (0x01) Indicates that the sender has concluded transmitting all member link port configurations for a given Aggregator. Shouldn't this be stating it as "given Port" ?=20 >>> Aggregator is the term used by the IEEE 802.1AX standard to refer to th= e Ethernet "bundle", so it is correct as is.=20 2) I am not able to spot mail archives of this topic in the PWE3 group . Di= d I do a limited search or a wrong directory search? please direct me to th= e right mail archive where I can see discussion emails about this draft so = that I can know more details from it for better understanding. >>>> What type of information are you looking for? The draft is quite detai= led and self-explanatory. If you have questions, please post them.=20 Regards, Samer I am new to this Topic of mLACP and its aggregation. I may have more querie= s later on. Thanks, Binny Aricent, India.= --_EEA1C136-502D-46EA-B3BC-E7EF9037D718_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Hi Samer,
To the last question I had, I am still left unclear & with a feel= ing that it would be good to have a ROID that is always a part of the appli= cation data message so that at the receiving end demultiplexing becomes bet= ter especially when multiple bundles or applications use the ICCP channel. = The packet information would look a bit more informative in that case, and = also helps a bit more for implementation.

In mc-lag case, if I don't= have a ROID carried in every application data packet, I'd be required to i= nspect aggregator or port configuration data for demultiplexing that packet= to the right bundle, which is not so good. Had I encoded a,ROID something = like 32bit RG ID + 32 bit aggregator ID / bundle unique id, and sent this o= n the very top of the application message, things get more nicer.

I'= d kindly suggest to adding ROID in this way of usage, as because the curren= t ROID advertisement in just one of the packets seems not showing ease. Ple= ase consider, and feedback.

Regards,
Binny.

Sent from Noki= a Lumia.
From: Samer Salam (ssalam)
Sent: =E2=80=8E30-=E2=80=8E04-=E2=80=8E2014 10:39 PMTo: Binny Jeshan
Cc: Luca Martini (lmartini= ); Ali Sajassi (sajassi); matthew.bocci@alcatel-luc= ent.co.uk; satoru.matsus= hima@gmail.com; tnadeau@brocade.= com; pwe3@ietf.org
Subject: Re: Questions relating to draft-ietf-pwe3-iccp-15.

=
Hi Binny,

Please find responses inline at [s1]
From: Binny Jeshan <binnyjeshan@gmail.com>
Dat= e: Sunday, 20 April, 2014 2:31 AM
To: Samer Salam <ssalam@ci= sco.com>
Cc: "Luca Marti= ni (lmartini)" <lmartini@cisco.com= >, "Ali Sajassi (sajassi)" <= sajassi@cisco.com>, "matthew.bocci@alcatel-lucent.co.uk" <matthew.bocci@alcatel-lucent.co.uk>, "= satoru.matsushima@gmail.com<= /A>" <satoru.matsushima@g= mail.com>, "tnadeau@brocade.c= om" <tnadeau@brocade.com&= gt;, "pwe3@ietf.org" <pwe3@ietf.org>
Subject: Re: Questions relating to draft-ietf-pwe3-iccp-15.
<= /DIV>

Hi Samer,=20

I have few questions now.

1) How many MAX redundant Groups can be possible between two Peers?&nb= sp;
[Binny]: In my understanding one RG configured in a PE can cater many = instances of Applications. for example, one can associate a mLACP Aggregati= on bundle t1 and t2  to be a part of Redundant group 1. Please clarify=  and confirm.

[s1] Typically, between two PEs, a single Redundancy Group is sufficie= nt. Indeed, it is possible to associate multiple bundle interfaces with the= same group. Usually, multiple RGs are employed if you need to logically gr= oup 3 or more PEs into subsets. E.g. PE1, PE2, PE3. On PE1, you may have an= RG with PE2 and another RG with PE3 to perform flexible grouping.
  

2) As i understand from this draft, applications send their TLV's to t= he peer through the ICCP channel. Which means mLACP Application Data Messag= e would look like -> ICC Header (6.1.1)  with Type 0x703+ mLACP Sys= temConfig Tlv (type 0032 - section 7.2.3) . Is this understanding correct t= hat the stack order looks like Ethernet + IP + LDP Header + ICCP header + A= pplication TLVs.

[s1] Correct.

If my understanding in (1) was right, then How different Application I= nstances are distinuguished in the Packets received. (for example mLACP may= have two MC-LAG instances that its managing) - but the ICC header will hav= e only one RG ID but the following TLV could belong to one of the applicati= on instances running on top of the RG.  How to demultiplex that. =

[s1] You are mixing up two things here: each application has a single = instance in a given RG. That is, there is one mLCAP client application of I= CCP. This application is managing both MC-LAG instances (in your example). = The way by which one MC-LAG is distinguished from the other is by the ROID = or Aggregator ID. 

I  see a reference to ROID. Section 4.3 " That allows separate systems in an RG to use a comm= on handle to reference the protected entity" . 
This draft does not = define how exactly the ROID bytes will be encoded, as far as i read. This l= eaves interop malfunction also, various options to code the ROID. one optio= n could 
ROID =3D  
But im left unclear = where i will fit this ROID in each type of packet sent by the application

[s1] The only requirement for interoperability between systems is that= all PEs in the RG use the same ROID numeric value for the same protected e= ntity. If an implementation wishes to encode semantics in the ROID, that's = fine, and out of scope of the draft. 

3) How do i exactly code the ROID? can you pleas= e standardize that > Comment please.

[s1] The semantics of the ROID is irrelevant for interoperability, tha= t's why it was not standardized. All what is required is that it matches on= the PEs. You can have it set by configuration, for example.

4) Why ROID is not mentioned to be a Part of EVE= RY TLV or atleast have a Application Header or something like that to carry= it ? 

[s1] It is treated as part of the configuration data, and hence it doe= s not change dynamically during the lifespan of the application connection.= If it does change, then this is handled as if the object is deleted and a = new created. This allows you to safely reset the associated state machines.=  

Regards,
Samer

Thanks,
Binny.
Aricent.



On 31 March 2014 23:15, Samer Salam (ssalam) <ssalam@c= isco.com> wrote:
Hi Binny,

From:= Binny Jeshan <binnyjeshan@gmail.com>
D= ate: Thursday, 20 March, 2014 3:12 AM
To: "Luca Martini (lmartini)" <lmartini@cisco.com>, Samer Salam <ssalam@cisco.com>, "= Ali Sajassi (sajassi)" <sajassi@cisco.com>, "matthew.bocci@alcatel-lucent.co.uk" <matthew.= bocci@alcatel-lucent.co.uk>, "satoru.matsushima@gmail.com" <satoru.matsushima@gmail.c= om>, "tnadeau= @brocade.com" <tnadeau@brocade.com>
Cc: "pwe3@ietf.org" <= ;pwe3@ietf.org>
= Subject: Questions relating to dra= ft-ietf-pwe3-iccp-15.

Hello,

I came across this when reading this draft. http://tools.ietf.org/= html/draft-ietf-pwe3-iccp-15

1)
Section = 7.2.5. mLACP Port Config TLV says,
- Flags

       Valid values= are:

          &n= bsp; -i. Synchronized (0x01)

      &nb= sp;         Indicates that the send= er has concluded transmitting all
      &n= bsp;         member link port confi= gurations for a given Aggregator.

Shouldn't this be stating it as "given Port" ?

>>> Aggregator is the term used by the IEEE 802.1AX standard = to refer to the Ethernet "bundle", so it is correct as is. 


2) I am not able to spot mail archives of this topic in the PWE3= group . Did I do a limited search or a wrong directory search? please dire= ct me to the right mail archive where I can see discussion emails about thi= s draft so that I can know more details from it for better understanding.


>>>> What type of information are you looking= for? The draft is quite detailed and self-explanatory. If you have questio= ns, please post them. 

Regards,
Samer

I am new to this Topic of mLACP and its aggregation. I may have = more queries later on.

Thanks,
Binny

Aricent, India.

= --_EEA1C136-502D-46EA-B3BC-E7EF9037D718_-- From nobody Wed Apr 30 14:39:56 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E0C1A0852 for ; Wed, 30 Apr 2014 14:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.551 X-Spam-Level: X-Spam-Status: No, score=-14.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9rq5NwMhW-t for ; Wed, 30 Apr 2014 14:39:50 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 17BC31A066A for ; Wed, 30 Apr 2014 14:39:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27802; q=dns/txt; s=iport; t=1398893988; x=1400103588; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=v4nPNR3W0s5aI9KdToLTXRH2fnnxXQCJuuiyhvLrBAs=; b=EWdsX4F6yZta0C9F6JjEkraCGI6IeFRrNYiJuKy3/KMvBf3M/FNB9ZW4 hGYc4d20IapSSitwOn4WhrzaXIrsI7kKSo+pAwYN5dIIDoQeHC56ii3Ka NLrWaaFdY1hTCCMx1l3+iPKiaxxpwQ7cp7CI/fwrJmWcB2eg20+gwS0IR E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQFAFFsYVOtJV2d/2dsb2JhbABPCoJCIyFPV7tLiQCBIRZ0giUBAQEDASdAEhIBCBEDAQEBIQcoERQJCAIEDgWILQMJCAEMwyANhlAXjDqBOwQHAQE+BwoGAQaEMwSVM4IDgXGBPItVhVqDMYFpCRci X-IronPort-AV: E=Sophos;i="4.97,960,1389744000"; d="scan'208,217";a="318521081" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 30 Apr 2014 21:39:47 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s3ULdlr2001740 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Apr 2014 21:39:47 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Wed, 30 Apr 2014 16:39:46 -0500 From: "Samer Salam (ssalam)" To: Binny Jeshan Thread-Topic: Questions relating to draft-ietf-pwe3-iccp-15. Thread-Index: AQHPZLbnhILx7+E75Ue8IOC3z2bFjpsqjnEA Date: Wed, 30 Apr 2014 21:39:46 +0000 Message-ID: In-Reply-To: <53616439.efcdb40a.339b.ffffd9bf@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [161.44.210.114] Content-Type: multipart/alternative; boundary="_000_CF86BA4D293A3ssalamciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/ZlZ6vtNhX3Db-mbQXroM4TN3XIg Cc: "Ali Sajassi \(sajassi\)" , "tnadeau@brocade.com" , "Luca Martini \(lmartini\)" , "matthew.bocci@alcatel-lucent.co.uk" , "pwe3@ietf.org" Subject: Re: [PWE3] Questions relating to draft-ietf-pwe3-iccp-15. X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 21:39:53 -0000 --_000_CF86BA4D293A3ssalamciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Binny, There's a one-to-one mapping between the ROID and the Aggregator ID. There = were two reasons why the Aggregator ID was passed in lieu of the ROID: * The ROID is 8 bytes, whereas the Aggregator ID is 2 bytes. Hence, it = is more efficient encoding on the wire. * To the mLACP application, the Aggregator ID is a native identifier (u= sed to identify the bundle per 802.1AX) You can have a translation table that simply maps one to the other. Regards, Samer From: Binny Jeshan > Date: Wednesday, 30 April, 2014 1:58 PM To: Samer Salam > Cc: "Luca Martini (lmartini)" >, "Ali Sajassi (sajassi)" >, = "matthew.bocci@alcatel-lucent.co.uk" >, "satoru.matsushima@gmail.com= " >, "tnade= au@brocade.com" >, "pwe3@ietf.org" > Subject: RE: Questions relating to draft-ietf-pwe3-iccp-15. Hi Samer, To the last question I had, I am still left unclear & with a feeling that i= t would be good to have a ROID that is always a part of the application dat= a message so that at the receiving end demultiplexing becomes better especi= ally when multiple bundles or applications use the ICCP channel. The packet= information would look a bit more informative in that case, and also helps= a bit more for implementation. In mc-lag case, if I don't have a ROID carried in every application data pa= cket, I'd be required to inspect aggregator or port configuration data for = demultiplexing that packet to the right bundle, which is not so good. Had I= encoded a,ROID something like 32bit RG ID + 32 bit aggregator ID / bundle = unique id, and sent this on the very top of the application message, things= get more nicer. I'd kindly suggest to adding ROID in this way of usage, as because the curr= ent ROID advertisement in just one of the packets seems not showing ease. P= lease consider, and feedback. Regards, Binny. Sent from Nokia Lumia. ________________________________ From: Samer Salam (ssalam) Sent: ?30-?04-?2014 10:39 PM To: Binny Jeshan Cc: Luca Martini (lmartini); Ali Sajassi (sajass= i); matthew.bocci@alcatel-lucent.co.uk; satoru.matsushima@gmail.com; tnadeau@brocade.com; pw= e3@ietf.org Subject: Re: Questions relating to draft-ietf-pwe3-iccp-15. Hi Binny, Please find responses inline at [s1] From: Binny Jeshan > Date: Sunday, 20 April, 2014 2:31 AM To: Samer Salam > Cc: "Luca Martini (lmartini)" >, "Ali Sajassi (sajassi)" >, = "matthew.bocci@alcatel-lucent.co.uk" >, "satoru.matsushima@gmail.com= " >, "tnade= au@brocade.com" >, "pwe3@ietf.org" > Subject: Re: Questions relating to draft-ietf-pwe3-iccp-15. Hi Samer, I have few questions now. 1) How many MAX redundant Groups can be possible between two Peers? [Binny]: In my understanding one RG configured in a PE can cater many insta= nces of Applications. for example, one can associate a mLACP Aggregation bu= ndle t1 and t2 to be a part of Redundant group 1. Please clarify and conf= irm. [s1] Typically, between two PEs, a single Redundancy Group is sufficient. I= ndeed, it is possible to associate multiple bundle interfaces with the same= group. Usually, multiple RGs are employed if you need to logically group 3= or more PEs into subsets. E.g. PE1, PE2, PE3. On PE1, you may have an RG w= ith PE2 and another RG with PE3 to perform flexible grouping. 2) As i understand from this draft, applications send their TLV's to the pe= er through the ICCP channel. Which means mLACP Application Data Message wou= ld look like -> ICC Header (6.1.1) with Type 0x703+ mLACP SystemConfig Tlv= (type 0032 - section 7.2.3) . Is this understanding correct that the stack= order looks like Ethernet + IP + LDP Header + ICCP header + Application TL= Vs. [s1] Correct. If my understanding in (1) was right, then How different Application Instan= ces are distinuguished in the Packets received. (for example mLACP may have= two MC-LAG instances that its managing) - but the ICC header will have onl= y one RG ID but the following TLV could belong to one of the application in= stances running on top of the RG. How to demultiplex that. [s1] You are mixing up two things here: each application has a single insta= nce in a given RG. That is, there is one mLCAP client application of ICCP. = This application is managing both MC-LAG instances (in your example). The w= ay by which one MC-LAG is distinguished from the other is by the ROID or Ag= gregator ID. I see a reference to ROID. Section 4.3 " That allows separate systems in a= n RG to use a common handle to reference the protected entity" . This draft does not define how exactly the ROID bytes will be encoded, as f= ar as i read. This leaves interop malfunction also, various options to code= the ROID. one option could ROID =3D But im left unclear where i will fit this ROID in each type of packet sent = by the application [s1] The only requirement for interoperability between systems is that all = PEs in the RG use the same ROID numeric value for the same protected entity= . If an implementation wishes to encode semantics in the ROID, that's fine,= and out of scope of the draft. 3) How do i exactly code the ROID? can you please standardize that > Commen= t please. [s1] The semantics of the ROID is irrelevant for interoperability, that's w= hy it was not standardized. All what is required is that it matches on the = PEs. You can have it set by configuration, for example. 4) Why ROID is not mentioned to be a Part of EVERY TLV or atleast have a Ap= plication Header or something like that to carry it ? [s1] It is treated as part of the configuration data, and hence it does not= change dynamically during the lifespan of the application connection. If i= t does change, then this is handled as if the object is deleted and a new c= reated. This allows you to safely reset the associated state machines. Regards, Samer Thanks, Binny. Aricent. On 31 March 2014 23:15, Samer Salam (ssalam) > wrote: Hi Binny, From: Binny Jeshan > Date: Thursday, 20 March, 2014 3:12 AM To: "Luca Martini (lmartini)" >, Samer Salam >, "Ali Sajassi (= sajassi)" >, "matthew.bocci@alc= atel-lucent.co.uk" >, "satoru= .matsushima@gmail.com" >, "tnadeau@brocade.com" > Cc: "pwe3@ietf.org" > Subject: Questions relating to draft-ietf-pwe3-iccp-15. Hello, I came across this when reading this draft. http://tools.ietf.org/html/draf= t-ietf-pwe3-iccp-15 1) Section 7.2.5. mLACP Port Config TLV says, - Flags Valid values are: -i. Synchronized (0x01) Indicates that the sender has concluded transmitting all member link port configurations for a given Aggregator. Shouldn't this be stating it as "given Port" ? >>> Aggregator is the term used by the IEEE 802.1AX standard to refer to th= e Ethernet "bundle", so it is correct as is. 2) I am not able to spot mail archives of this topic in the PWE3 group . Di= d I do a limited search or a wrong directory search? please direct me to th= e right mail archive where I can see discussion emails about this draft so = that I can know more details from it for better understanding. >>>> What type of information are you looking for? The draft is quite detai= led and self-explanatory. If you have questions, please post them. Regards, Samer I am new to this Topic of mLACP and its aggregation. I may have more querie= s later on. Thanks, Binny Aricent, India. --_000_CF86BA4D293A3ssalamciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <277CC08D5B1B2D4881EED1CAE538DF9B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Binny,
There's a one-to-one mapping between the ROID and the Aggregator ID. T= here were two reasons why the Aggregator ID was passed in lieu of the ROID:=
  • The ROID is 8 bytes, whereas the Aggregator ID is 2 bytes. Hence, it is= more efficient encoding on the wire.
  • To the mLACP application, the= Aggregator ID is a native identifier (used to identify the bundle per 802.= 1AX) 
 You can have a translation table that simply maps one to the oth= er.

Regards,
Samer

From: Binny Jeshan <binnyjeshan@gmail.com>
Date: Wednesday, 30 April, 2014 1:5= 8 PM
To: Samer Salam <ssalam@cisco.com>
Cc: "Luca Martini (lmartini)&q= uot; <lmartini@cisco.com>, = "Ali Sajassi (sajassi)" <= sajassi@cisco.com>, "matthew.bocci@alcatel-lucent.co.uk" <matthew.bocci@al= catel-lucent.co.uk>, "satoru.matsushima@gmail.com" <satoru.matsushima@gmail.com>, "tnadeau@brocade.com" <tnadeau@brocade.com>, &q= uot;pwe3@ietf.org" <pwe3@ietf.org>
Subject: RE: Questions relating to = draft-ietf-pwe3-iccp-15.

Hi Samer,
To the last question I had, I am still left unclear & with a feeling th= at it would be good to have a ROID that is always a part of the application= data message so that at the receiving end demultiplexing becomes better es= pecially when multiple bundles or applications use the ICCP channel. The packet information would look a bit more informa= tive in that case, and also helps a bit more for implementation.

In mc-lag case, if I don't have a ROID carried in every application data pa= cket, I'd be required to inspect aggregator or port configuration data for = demultiplexing that packet to the right bundle, which is not so good. Had I= encoded a,ROID something like 32bit RG ID + 32 bit aggregator ID / bundle unique id, and sent this on the = very top of the application message, things get more nicer.

I'd kindly suggest to adding ROID in this way of usage, as because the curr= ent ROID advertisement in just one of the packets seems not showing ease. P= lease consider, and feedback.

Regards,
Binny.

Sent from Nokia Lumia.
From: = Samer Salam (ssalam)
Sent: = ?30-?04-?2014 10:39 PM
To: = Binny Jeshan
Cc: = Luca Martini (lmartini); Ali Sajassi (sajassi); matthew.bocci@alcatel-lucent.co.uk; satoru.matsushima@gmail.com; tna= deau@brocade.com; pwe3@ietf.org
Subject: = Re: Questions relating to draft-ietf-pwe3-iccp-15.

Hi Binny,

Please find responses inline at [s1]
From: Binny Jeshan <binnyjeshan@gmail.com>
Date: Sunday, 20 April, 2014 2:31 = AM
To: Samer Salam <ssalam@cisco.com>
Cc: "Luca Martini (lmartini)&= quot; <lmartini@cisco.com>,= "Ali Sajassi (sajassi)" <sajassi@cisco.com>, "matthew.bocci@alcatel-lucent.co.uk" <matthew.bocci@al= catel-lucent.co.uk>, "satoru.matsushima@gmail.com" <satoru.matsushima@gmail.com>, "tnadeau@brocade.com" <tnadeau@brocade.com>, &q= uot;pwe3@ietf.org" <pwe3@ietf.org>
Subject: Re: Questions relating to= draft-ietf-pwe3-iccp-15.

Hi Samer,

I have few questions now.

1) How many MAX redundant Groups can be possible between two Peers?&nb= sp;
[Binny]: In my understanding one RG configured in a PE can cater many = instances of Applications. for example, one can associate a mLACP Aggregati= on bundle t1 and t2  to be a part of Redundant group 1. Please clarify=  and confirm.

[s1] Typically, between two PEs, a single Redundancy Group is sufficie= nt. Indeed, it is possible to associate multiple bundle interfaces with the= same group. Usually, multiple RGs are employed if you need to logically gr= oup 3 or more PEs into subsets. E.g. PE1, PE2, PE3. On PE1, you may have an RG with PE2 and another RG wit= h PE3 to perform flexible grouping.
  

2) As i understand from this draft, applications send their TLV's to t= he peer through the ICCP channel. Which means mLACP Application Data Messag= e would look like -> ICC Header (6.1.1)  with Type 0x703+ mLACP= SystemConfig Tlv (type 0032 - section 7.2.3) . Is this understanding correct that the stack order looks like Ethernet &= #43; IP + LDP Header + ICCP header + Application TLVs.

[s1] Correct.

If my understanding in (1) was right, then How different Application I= nstances are distinuguished in the Packets received. (for example mLACP may= have two MC-LAG instances that its managing) - but the ICC header will hav= e only one RG ID but the following TLV could belong to one of the application instances running on top of the= RG.  How to demultiplex that. 

[s1] You are mixing up two things here: each application has a single = instance in a given RG. That is, there is one mLCAP client application of I= CCP. This application is managing both MC-LAG instances (in your example). = The way by which one MC-LAG is distinguished from the other is by the ROID or Aggregator ID. 

I  see a reference to ROID. Section 4.3 " That allows separate systems in an RG to use a common handle to reference the protecte= d entity" . 
This draft does not = define how exactly the ROID bytes will be encoded, as far as i read. This l= eaves interop malfunction also, various options to code the ROID. one optio= n could 
ROID =3D  
But im left unclear = where i will fit this ROID in each type of packet sent by the application

[s1] The only requirement for interoperability between systems is that= all PEs in the RG use the same ROID numeric value for the same protected e= ntity. If an implementation wishes to encode semantics in the ROID, that's = fine, and out of scope of the draft. 

3) How do i exactly code the ROID? can you ple= ase standardize that > Comment please.

[s1] The semantics of the ROID is irrelevant for interoperability, tha= t's why it was not standardized. All what is required is that it matches on= the PEs. You can have it set by configuration, for example.

4) Why ROID is not mentioned to be a Part of E= VERY TLV or atleast have a Application Header or something like that to car= ry it ? 

[s1] It is treated as part of the configuration data, and hence it doe= s not change dynamically during the lifespan of the application connection.= If it does change, then this is handled as if the object is deleted and a = new created. This allows you to safely reset the associated state machines. 

Regards,
Samer

Thanks,
Binny.
Aricent.



On 31 March 2014 23:15, Samer Salam (ssalam) <ssalam@cisco.com<= /a>> wrote:
Hi Binny,

From: Binny Jeshan <binnyjeshan@gmail.com&g= t;
Date: Thursday, 20 March, 2014 3:1= 2 AM
To: "Luca Martini (lmartini)&= quot; <lmartini@= cisco.com>, Samer Salam <ssalam@cisco.com>, "Ali Sajassi (sajassi)" <sajassi@cisco.c= om>, "matthew.bocci@alcatel-lucent.co.uk" <matthew.bocci@= alcatel-lucent.co.uk>, "sat= oru.matsushima@gmail.com" <satoru.matsushima@gmail.com>, "tnadeau@brocade.com" <tnadeau@broca= de.com>
Cc: "pwe3@ietf.org" <pwe3@ietf.org>
Subject: Questions relating to dra= ft-ietf-pwe3-iccp-15.

Hello,

I came across this when reading this draft. http://tools.ietf.org/html/draft-ietf-pwe3-iccp-15

1)
Section 7.2.5. mLACP Port Config TLV says,
- Flags

       Valid values are:

            -i. Sync= hronized (0x01)

            &nb= sp;   Indicates that the sender has concluded transmitting all             &nb= sp;   member link port configurations for= a given Aggregator.

Shouldn't this be stating it as "given Port" ? =

>>> Aggregator is the term used by the IEEE 802.1AX standard = to refer to the Ethernet "bundle", so it is correct as is. <= /div>


2) I am not able to spot mail archives of this topic in the PWE3= group . Did I do a limited search or a wrong directory search? please dire= ct me to the right mail archive where I can see discussion emails about thi= s draft so that I can know more details from it for better understanding.


>>>> What type of information are you looking= for? The draft is quite detailed and self-explanatory. If you have questio= ns, please post them. 

Regards,
Samer

I am new to this Topic of mLACP and its aggregation. I may have = more queries later on.

Thanks,
Binny

Aricent, India.

 --_000_CF86BA4D293A3ssalamciscocom_--