From filippo.cugini@cnit.it Mon Jan 10 02:38:10 2011 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A458728C12A for ; Mon, 10 Jan 2011 02:38:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.696 X-Spam-Level: * X-Spam-Status: No, score=1.696 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E7L7JkTkKLJk for ; Mon, 10 Jan 2011 02:38:09 -0800 (PST) Received: from sssup.it (ms01.sssup.it [193.205.80.99]) by core3.amsl.com (Postfix) with ESMTP id 64F6B28C0ED for ; Mon, 10 Jan 2011 02:38:08 -0800 (PST) Received: from [10.30.2.203] (HELO Platini) by sssup.it (CommuniGate Pro SMTP 5.3.10) with SMTP id 66034967; Mon, 10 Jan 2011 11:40:19 +0100 Message-ID: <43DC3936A56A476C97A97313C9AB9A8A@Platini> From: "Filippo Cugini" To: Date: Mon, 10 Jan 2011 11:40:19 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005F_01CBB0BB.28A906D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Cc: Francesco Paolucci , a.giorgetti@sssup.it Subject: [Pce] Questions on draft-king-pce-hierarchy-fwk X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 10:38:10 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_005F_01CBB0BB.28A906D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Authors, all, a couple of comments/questions=20 - particularly in the context of a single service provider, the view of = child domains as vertices might not be so effective.=20 For example, if domains are routing Areas, no TE info can be really used = at the parent PCE and the optimal solution is achieved only through path = computation flooding, with possible scaling issues (as in BRPC = flooding). Maybe the case of a single service provider (which is also not affected = by confidentiality issues) could be addressed using a different = hierarchical solution. What do you think about it? - In Sect 5.8.4, the possible use of PCNtf is indicated.=20 As suggested, a mechanism to configure refresh intervals should be = introduced. =20 In addition, for example when the H-PCE TED needs to be re-built (e.g., = upon faults), a mechanism to enable the H-PCE to solicit/request domain = connectivity info might be required. Nothing against the use of PCNtf or new PCEP messages to carry = reachability and link TE info, just wondering if this will tend to = reproduce a routing protocol within PCEP.=20 This point will become more relevant in case of a larger amount of TE = info to carry, i.e., with reference to the previous point, if a mesh of = virtual intra-domain TE links between border nodes will be eventually = enabled for some scenarios (e.g., single service provider).=20 Thank you Filippo ------=_NextPart_000_005F_01CBB0BB.28A906D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Authors, all,
a couple of comments/questions =
 
- particularly in the context of a = single service=20 provider, the view of child domains as vertices might not be so = effective.=20
For example, if domains are routing = Areas, no TE=20 info can be really used at the parent PCE and the optimal solution = is=20 achieved only through path computation flooding, = with possible=20 scaling issues (as in BRPC flooding).
Maybe the case of a single service = provider (which is also=20 not affected by confidentiality issues) could be=20 addressed using a different hierarchical solution.
What do you think about it?
 
-  In = Sect 5.8.4, the=20 possible use of PCNtf is indicated.=20
As suggested, a mechanism to configure = refresh=20 intervals should be introduced.   
In addition, for example when the = H-PCE TED=20 needs to be re-built (e.g., upon faults), a mechanism to enable the = H-PCE=20 to solicit/request domain connectivity info might be=20 required.
Nothing against the use of PCNtf or new = PCEP=20 messages to carry reachability and link TE info, just wondering if this=20 will tend to reproduce a routing protocol within = PCEP. 
This point will become more = relevant in=20 case of a larger amount of TE info to carry, i.e., with = reference to=20 the previous point, if a mesh of virtual intra-domain TE links = between=20 border nodes will be eventually enabled for = some scenarios=20 (e.g., single service provider).
 
Thank you
  Filippo
 
 
 
------=_NextPart_000_005F_01CBB0BB.28A906D0-- From ramon.casellas@cttc.es Wed Jan 19 02:46:11 2011 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AB953A6FCC for ; Wed, 19 Jan 2011 02:46:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+Rj54w8FQaD for ; Wed, 19 Jan 2011 02:46:09 -0800 (PST) Received: from Scorpius.cttc.es (scorpius.cttc.es [84.88.62.197]) by core3.amsl.com (Postfix) with ESMTP id 862373A6FA9 for ; Wed, 19 Jan 2011 02:46:07 -0800 (PST) Received: from castor (postfix@castor.cttc.es [84.88.62.196]) by Scorpius.cttc.es (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p0JAmSUj003481 for ; Wed, 19 Jan 2011 11:48:33 +0100 Received: from [84.88.61.50] (pcrcasellas.cttc.es [84.88.61.50]) by castor (Postfix) with ESMTP id DDC702FC270 for ; Wed, 19 Jan 2011 11:48:33 +0100 (CET) Message-ID: <4D36C1D2.5050504@cttc.es> Date: Wed, 19 Jan 2011 11:49:54 +0100 From: Ramon Casellas Organization: CTTC User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: pce@ietf.org References: <43DC3936A56A476C97A97313C9AB9A8A@Platini> In-Reply-To: <43DC3936A56A476C97A97313C9AB9A8A@Platini> Content-Type: multipart/alternative; boundary="------------030607030209070003070907" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (castor); Wed, 19 Jan 2011 11:48:33 +0100 (CET) X-Scanned-By: MIMEDefang 2.67 on 84.88.62.197 Subject: Re: [Pce] Questions on draft-king-pce-hierarchy-fwk X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 10:46:11 -0000 This is a multi-part message in MIME format. --------------030607030209070003070907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Filippo, all, Some comments and subjective views inline. I guess Dan / other draft author can give you a better (or different) answer but, for what is worth, here's mine On 10/01/2011 11:40, Filippo Cugini wrote: > Authors, all, > > - particularly in the context of a single service provider, the view > of child domains as vertices might not be so effective. > For example, if domains are routing Areas, no TE info can be really > used at the parent PCE and the optimal solution is achieved only > through path computation flooding, with possible scaling issues (as in > BRPC flooding). > Maybe the case of a single service provider (which is also not > affected by confidentiality issues) could be addressed using a > different hierarchical solution. > Personally, I am open to other TED aggregation schemes, where the topology of a child domain is more detailed than a simple node, specially in the case of intra-carrier and inter-domain (e.g. areas within an AS or vendor boundaries) although as seen in past mails it is clearly not a consensus. I see no particular reason why a p-pce would not be able to construct more detailed (yet abstracted) child topologies, even if the two step-process "determine domain sequence" + "expand intra-domain" is kept and it helps the p-pce to carry out a better domain chain selection. In a quite straightforward manner we considered a "one star topology per domain" with limited extensions. I understand some opponents view in the difficulty of mapping all TE link attributes into virtual parent topologies and it's true that most academic work only focuses on reduced aspects such as bandwidth and delay. Although both the framework and the companion protocol extensions document are somehow targeted to the scenario you mention (child domains as vertices), I think that they seem to be both open/generic enough to accommodate other approaches in which the child domains are more detailed than a simple "node representation", maybe with some tweaks. However, as detailed below, allowing for flexible aggregation mechanisms opens new issues. > - In Sect 5.8.4, the possible use of PCNtf is indicated. > As suggested, a mechanism to configure refresh intervals should be > introduced. In theory, with the "one vertex per domain", it does not seem necessary to consider refreshes beyond the straightforward approach of sending a PCNtf "when there is a change in the interdomain link", although nothing prevents you from adding better refresh policies. However, if/when considering more complex topology aggregation mechanisms, refresh intervals are in my view, only one part of the problem, bound to the mechanism by which a c-pce aggregates a topology towards the parent, which I would guess is not subject to standardization, (yet?). The mechanism would need to include i) the process by which a graph G is "transformed" into graph H, usually with less number of vertices/edges ii) how graph H is communicated to the p-pce and how refreshes are managed iii) how a "path" in graph H is mapped back to graph G I think only ii) should be addressed by PCE wg.Existing implementations seem to either enable a OSPF-TE adjacency between p-pce and c-pce or wrap OSPF-TE TLVs / InterAS opaques in PCNtf messages > In addition, for example when the H-PCE TED needs to be re-built > (e.g., upon faults), a mechanism to enable the H-PCE > to solicit/request domain connectivity info might be required. > Nothing against the use of PCNtf or new PCEP messages to carry > reachability and link TE info, just wondering if this will tend to > reproduce a routing protocol within PCEP. I am not sure. On the one hand, the PCNtf is straightforward enough to use and implement, and the simplicity of decoupling the p-pce from the c-pce, not requiring the existence of an OSPF-TE adjacency and limiting the interaction c-pec / h-pce to the PCEP/TCP session seems a "nice to have". On the other hand, it is easy and dangerous to re-invent the wheel with PCNtfs being the new "wrapper" for OSPF-TE. > This point will become more relevant in case of a larger amount of TE > info to carry, i.e., with reference to the previous point, if a mesh > of virtual intra-domain TE links between border nodes will > be eventually enabled for some scenarios (e.g., single service provider). Agreed. I guess my point is that current drafts do not (necessarily) preclude better (for some definition of better, even if they are just to somehow convey the fact that a transit domain may not provide connectivity to all potential neighbor domains) aggregation mechanisms, and although the whole actual process by which a child-PCE "summarizes" a domain should not be subject to standardization, the c-pce p-pce communication may be and PCNtf wrappers are not optimal and for those cases a dedicated OSPF-TE adjacency with the parent may be more effective. Thanks for reading and best regards, Ramon -- Ramon Casellas, Ph.D. Research Associate - Optical Networking Area --http://wikiona.cttc.es CTTC - Centre Tecnològic de Telecomunicacions de Catalunya, PMT Ed B4 Av. Carl Friedrich Gauss 7 08860 Castelldefels (Barcelona) - Spain Tel.: +34 93 645 29 16 -- Fax. +34 93 645 29 01 --------------030607030209070003070907 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Filippo, all,

Some comments and subjective views inline. I guess Dan / other draft author can give you a better (or different) answer but, for what is worth, here's mine


On 10/01/2011 11:40, Filippo Cugini wrote:
Authors, all,

 - particularly in the context of a single service provider, the view of child domains as vertices might not be so effective.
For example, if domains are routing Areas, no TE info can be really used at the parent PCE and the optimal solution is achieved only through path computation flooding, with possible scaling issues (as in BRPC flooding).
Maybe the case of a single service provider (which is also not affected by confidentiality issues) could be addressed using a different hierarchical solution.


Personally, I am open to other TED aggregation schemes, where the topology of a child domain is more detailed than a simple node, specially in the case of intra-carrier and  inter-domain (e.g. areas within an AS or vendor boundaries) although as seen in past mails it is clearly not a consensus. I see no particular reason why a p-pce would not be able to construct more detailed (yet abstracted) child topologies, even if the two step-process "determine domain sequence" + "expand intra-domain" is kept and it helps the p-pce to carry out a better domain chain selection. In a quite straightforward manner we considered a  "one star topology per domain" with limited extensions. I understand some opponents view in the difficulty of mapping all TE link attributes into virtual parent topologies and it's true that most academic work only focuses on reduced aspects such as bandwidth and delay. 

Although both the framework and the companion protocol extensions document are somehow targeted to the scenario you mention (child domains as vertices), I think that they seem to be both open/generic enough to accommodate other approaches in which the child domains are more detailed than a simple "node representation", maybe with some tweaks.

However, as detailed below, allowing for flexible aggregation mechanisms opens new issues.


 
-  In Sect 5.8.4, the possible use of PCNtf is indicated.
As suggested, a mechanism to configure refresh intervals should be introduced.  
In theory, with the "one vertex per domain", it does not seem necessary to consider refreshes beyond the straightforward approach of sending a PCNtf "when there is a change in the interdomain link", although nothing prevents you from adding better refresh policies.

However, if/when considering more complex topology aggregation mechanisms, refresh intervals are in my view, only one part of the problem, bound to the mechanism by which a c-pce aggregates a topology towards the parent, which I would guess is not subject to standardization, (yet?). The mechanism would need to include
i) the process by which a graph G is "transformed" into graph H, usually with less number of vertices/edges
ii) how graph H is communicated to the p-pce and how refreshes are managed
iii) how a "path" in graph H is mapped back to graph G

I think only ii) should be addressed by PCE wg.Existing implementations seem to either enable a OSPF-TE adjacency between p-pce and c-pce or wrap OSPF-TE TLVs / InterAS opaques in PCNtf messages

In addition, for example when the H-PCE TED needs to be re-built (e.g., upon faults), a mechanism to enable the H-PCE to solicit/request domain connectivity info might be required.
Nothing against the use of PCNtf or new PCEP messages to carry reachability and link TE info, just wondering if this will tend to reproduce a routing protocol within PCEP.
I am not sure. On the one hand, the PCNtf is straightforward enough to use and implement, and the simplicity of decoupling the p-pce from the c-pce, not requiring the existence of an OSPF-TE adjacency and limiting the interaction c-pec / h-pce to the PCEP/TCP session seems a "nice to have". On the other hand, it is easy and dangerous to re-invent the wheel with PCNtfs being the new "wrapper" for OSPF-TE.

This point will become more relevant in case of a larger amount of TE info to carry, i.e., with reference to the previous point, if a mesh of virtual intra-domain TE links between border nodes will be eventually enabled for some scenarios (e.g., single service provider).

Agreed. I guess my point is that current drafts do not (necessarily) preclude better (for some definition of better, even if they are just to somehow convey the fact that a transit domain may not provide connectivity to all potential neighbor domains) aggregation mechanisms, and although the whole actual process by which a child-PCE "summarizes" a domain should not be subject to standardization, the c-pce p-pce communication may be and PCNtf wrappers are not optimal and for those cases a dedicated OSPF-TE adjacency with the parent may be more effective.

Thanks for reading and best regards,
Ramon
-- 
Ramon Casellas, Ph.D. 
Research Associate - Optical Networking Area -- http://wikiona.cttc.es
CTTC - Centre Tecnològic de Telecomunicacions de Catalunya, PMT Ed B4
Av. Carl Friedrich Gauss 7 08860 Castelldefels (Barcelona) - Spain
Tel.: +34 93 645 29 16 -- Fax. +34 93 645 29 01
--------------030607030209070003070907-- From Adrian.Farrel@huawei.com Wed Jan 19 06:01:45 2011 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E9E93A6F30; Wed, 19 Jan 2011 06:01:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.541 X-Spam-Level: X-Spam-Status: No, score=-105.541 tagged_above=-999 required=5 tests=[AWL=1.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id odtP5p87BPYr; Wed, 19 Jan 2011 06:01:43 -0800 (PST) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id C2B843A712B; Wed, 19 Jan 2011 06:01:43 -0800 (PST) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LF900547WFBZN@usaga03-in.huawei.com>; Wed, 19 Jan 2011 08:04:23 -0600 (CST) Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LF900JX1WF9G9@usaga03-in.huawei.com>; Wed, 19 Jan 2011 08:04:23 -0600 (CST) Date: Wed, 19 Jan 2011 14:04:20 +0000 From: Adrian Farrel To: mpls@ietf.org, 'CCAMP' , pce@ietf.org Message-id: <070501cbb7e1$c6436020$52ca2060$@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Outlook 14.0 Content-type: text/plain; charset=us-ascii Content-language: en-gb Content-transfer-encoding: 7BIT Thread-index: Acu34bm7+lB0frMlTquX736g5RjMjQ== Cc: l2vpn@ietf.org, itu-t-liaisons@iab.org, rtg-bfd@ietf.org, pwe3@ietf.org, opsawg@ietf.org Subject: [Pce] Proposed liaison response on ITU-T Optical transport Network Work Plan X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian.Farrel@huawei.com List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 14:01:45 -0000 Hi, We received a liaison "SG15 OTNT standardization work plan" which you can see at https://datatracker.ietf.org/documents/LIAISON/file1054.pdf The document they would like us to review is "Draft Revised Optical Transport Networks & Technologies Standardization Work Plan, Issue 13" visible at https://datatracker.ietf.org/documents/LIAISON/file1055.pdf The liaison is addressed CCAMP, PCE, and MPLS, but it falls to me as liaison on the Optical Control Plane to respond. I am copying this email to BFD, OPSAWG, PWE3, and L2VPN as those WGs are explicitly mentioned in the document. A response is requested by February 1, 2011. Here is a draft of what I plan to send. Please send me any comments by January 28. Thanks, Adrian === The IETF thanks you for your liaison COM15-LS204-E received on 2010-06-24 titled "SG15 OTNT standardization work plan", and thanks you for sharing your plans. We have reviewed the document and have a number of comments. In general, it is becoming less and less clear that the title of this document is accurate! SG15 now embraces a number of non-optical transport technologies including Ethernet and MPLS-TP. Although those packet-based technologies can be transmitted over optical links, they are not limited to that medium. Maybe your document should be titled "Transport Networks & Technologies Standardization Work Plan" or maybe you should remove the non-optical material. The scope text in Section 5 and 5.1 might also need revision. The IETF has not position of this, but simply draws the matter to your attention. Table 5-1 We would like to suggest the inclusion of the MPLS Working Group in this table as that working group is responsible for many elements of the support of Ethernet "carrier-class" pseudowires over MPLS and MPLS-TP networks. Section 5.6.1 begins: "MPLS OAM was originally standardized by ITU-T SG13 (Q.5/13)." Although the section goes on to list IETF standardization of MPLS OAM, it may be considered that this first sentence implies that the ITU-T developed MPLS OAM before any MPLS OAM had been developed within the IETF. This would, of course, be a misrepresentation. Therefore, we suggest that you change this first sentence to read: "Within the ITU-T, MPLS OAM was originally standardized by SG13 (Q.5/13)." Table 5-3 Architectural Aspects of MPLS-TP Add RFC 5921, RFC 5950, RFC 5960 Equipment Functional Characteristics of MPLS-TP Add RFC 5960 OAM and Protection Switching of MPLS-TP Add RFC 5860 Management Aspects of MPLS Add RFC 4221 Management Aspects of MPLS-TP Add RFC 5950, RFC 5951 Performance of ATM Add RFC 3116 Performance of MPLS Add RFC 5695 Table 7-1-2 draft-ietf-mpls-tp-framework is now RFC 5921 draft-ietf-mpls-tp-nm-req is now RFC 5951 draft-ietf-mpls-tp-survive-fwk reached revision -06 and has been approved for publication as an RFC draft-ietf-mpls-tp-oam-framework reached revision -10 and has been approved for publication as an RFC draft-ietf-mpls-tp-nm-framework is now RFC 5950 draft-ietf-mpls-tp-rosetta-stone has reached revision -03 draft-ietf-mpls-tp-data-plane is now RFC 5960 draft-ietf-mpls-tp-identifiers has reached revision -03 draft-ietf-mpls-tp-ach-tlv is now abandoned draft-ietf-ccamp-mpls-tp-cp-framework has reached revision -05 Further relevant Internet-Drafts and RFCs can be found at: http://datatracker.ietf.org/wg/ccamp/ http://datatracker.ietf.org/wg/mpls http://datatracker.ietf.org/wg/pwe3 http://datatracker.ietf.org/wg/bfd http://datatracker.ietf.org/wg/pce Table 7-4-2 draft-ietf-gmpls-ason-routing-ospf is now RFC 5787 Table 7-8 should inherit changes to Table 7-1-2 and be updated according to the document status available at the IETF working group pages as listed above. Table 8-1 entry 3. Please be aware of the work on impairment-aware routing in the CCAMP and PCE working groups. (It may be your intention that this is covered under entry 5.) Annex A might usefully refer readers to RFC 4397 and draft-ietf-mpls-tp-rosetta-stone that provide terminology mapping and have been jointly developed by IETF and ITU-T experts. We would welcome it if you shared any future revisions of this work plan with us. Adrian Farrel IETF Liaison to the IETF on the Optical Control Plane Routing Area Director From daniel@olddog.co.uk Fri Jan 21 14:28:12 2011 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 468353A684B for ; Fri, 21 Jan 2011 14:28:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.315 X-Spam-Level: X-Spam-Status: No, score=-102.315 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gK6WtEVIm2Rf for ; Fri, 21 Jan 2011 14:28:07 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by core3.amsl.com (Postfix) with ESMTP id DB2393A6AA9 for ; Fri, 21 Jan 2011 14:28:05 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id p0LMUfv7023027; Fri, 21 Jan 2011 22:30:42 GMT Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id p0LMUe15023022; Fri, 21 Jan 2011 22:30:41 GMT From: "Daniel King" To: Date: Fri, 21 Jan 2011 22:30:37 -0000 Message-ID: <006501cbb9ba$d40e3e70$7c2abb50$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0066_01CBB9BA.D40EDAB0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Acu5uIVMyXHo/Q3rQn2eTqCbJ6pJEQ== Content-language: en-gb Cc: msiva@cisco.com, qzhao@huawei.com Subject: [Pce] New Version of draft-zhao-pce-pcep-inter-domain-p2mp-procedures X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 22:28:12 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0066_01CBB9BA.D40EDAB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi All, We have created a new version of draft-zhao-pce-pcep-inter-domain-p2mp-procedures (07). http://www.ietf.org/id/draft-zhao-pce-pcep-inter-domain-p2mp-procedures-07.t xt This version was created to fix a number of minor edits, raise the issue of manageability and help facilitate protection scenarios discussed during IETF 79 in Beijing. The draft update includes: 8. Protection Section This section is used to highlight issues discussed in Beijing. Thanks to JP and all for your questions. We expect this topic to require more discussion and one scenario is that it should be addressed in separate document. The whole protection topic (not just for P2MP and multi-domain) will require a much more detailed analyses and we will follow-up on the various issues with a separate email/discussion. 9. Manageability Considerations Obviously management of inter-domain P2MP path computations potentially raise a number issues and we have begun to document them. Each sub-areas will require further deliberation so please feel free to comment and make suggestions. Finally, the authors would like to request working group adoption of this draft. Thanks! Quintin ------=_NextPart_000_0066_01CBB9BA.D40EDAB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = All,

 

We have created a new version of = draft-zhao-pce-pcep-inter-domain-p2mp-procedures (07).

 

http://www.ietf.org/id/draft-zhao-pce-pcep-inter-domain-p2= mp-procedures-07.txt

 

This version = was created to fix a number of minor edits, raise the issue of  = manageability and help facilitate protection scenarios discussed during = IETF 79 in Beijing. The draft update includes:

 

8. = Protection Section

This section is = used to highlight issues discussed in Beijing. Thanks to JP and all for = your questions. We expect this topic to require more discussion and one = scenario is that it should be addressed in separate document. The whole = protection topic (not just for P2MP and multi-domain) will require a = much more detailed analyses and we will follow-up on the various issues = with a separate email/discussion.  

 

9.  = Manageability Considerations

Obviously management of inter-domain P2MP path = computations potentially raise a number issues and we have begun to = document them. Each sub-areas will require further deliberation so = please feel free to comment and make suggestions.

Finally, the = authors would like to request working group adoption of this draft. =

 

Thanks!        =       =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;  

Quintin

------=_NextPart_000_0066_01CBB9BA.D40EDAB0-- From Christian.Kaas-Petersen@tieto.com Wed Jan 26 11:43:35 2011 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 180DC3A6886 for ; Wed, 26 Jan 2011 11:43:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSNRg8s4bJFG for ; Wed, 26 Jan 2011 11:43:34 -0800 (PST) Received: from ebb06.tieto.com (ebb06.tieto.com [131.207.168.38]) by core3.amsl.com (Postfix) with ESMTP id 071CF3A687D for ; Wed, 26 Jan 2011 11:43:33 -0800 (PST) X-AuditID: 83cfa826-b7ca6ae000000a25-fd-4d407a191302 Received: from FIHGA-EXHUB01.eu.tieto.com ( [131.207.136.34]) by ebb06.tieto.com (SMTP Mailer) with SMTP id 44.E0.02597.91A704D4; Wed, 26 Jan 2011 21:46:34 +0200 (EET) Received: from EXMB02.eu.tieto.com ([169.254.1.182]) by FIHGA-EXHUB01.eu.tieto.com ([131.207.136.34]) with mapi; Wed, 26 Jan 2011 21:46:33 +0200 From: To: Date: Wed, 26 Jan 2011 21:46:32 +0200 Thread-Topic: LABEL-SET as object and TLV in pcep-extensions-01 Thread-Index: AQHLvZG7LdP1rbwVv0ilsRa7Kaxhqw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [Pce] LABEL-SET as object and TLV in pcep-extensions-01 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 19:43:35 -0000 Reading the draft-ietf-pce-gmpls-pcep-extensions-01 document, the definitio= n and use of LABEL-REQUEST, LABEL-SET, and SUGGESTED-LABEL-SET need further=20 clarification. The clarification concerns the said items being both object= s=20 and TLVs. I'll consider LABEL-SET in detail. LABEL-SET as an object is specified in section 2.5, but half-way through the section, LABEL-SET is referred to as a TLV appearing in the ERO object (and so LABEL-SET is a TLV of an RSVP object). Further=20 LABEL-SET is also a TLV specified in section 2.4.2.5, where it appears in the new Generalized endpoint Object Type for the END-POINTS object. Therefore I should like to have the following clarified= . In a PCReq, LABEL-SET can appear both as a PCEP object in its own right, an= d as a PCEP TLV in the END-POINTS object, when the END-POINTS object is the new Generalized endpoint Object Type. It is not clear to me, what difference it makes to the semantics of the PCReq, whether LABEL-SET appears as an object, as a TLV in END-POINTS, or indeed can appear in both places. It is not clearly stated in the draft, but I think the LABEL-SET can appear in a PCRep as a PCEP object listing useable labels for the path returned. What is stated is that the LABEL-SET can appear as a TLV being part of the ERO returned. If LABEL-SET indeed can be returned as a separate object= , the syntax for the appearing at the beginning of chapter 2 should be updated to reflect that. Because LABEL-SET is added as a new object, this should be added to the IANA considerations, section 5.1. I am not fully clear as to whether all the above observations for the LABEL-SET are equally applicable to LABEL-REQUEST and SUGGESTED-LABEL-SET, but also these two are introduced both as objects and TLVs. Also correct the packet layout in sections 2.2 and 2.3 such that it is clear Traffic Spec and Min Traffic Spec can be seen having =20 variable size. Christian= From ramon.casellas@cttc.es Thu Jan 27 06:41:49 2011 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E83793A689D for ; Thu, 27 Jan 2011 06:41:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPNUTM-k4WG3 for ; Thu, 27 Jan 2011 06:41:48 -0800 (PST) Received: from Scorpius.cttc.es (scorpius.cttc.es [84.88.62.197]) by core3.amsl.com (Postfix) with ESMTP id 23FD73A6899 for ; Thu, 27 Jan 2011 06:41:47 -0800 (PST) Received: from castor (postfix@castor.cttc.es [84.88.62.196]) by Scorpius.cttc.es (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p0REiUfa011570 for ; Thu, 27 Jan 2011 15:44:35 +0100 Received: from [84.88.61.50] (pcrcasellas.cttc.es [84.88.61.50]) by castor (Postfix) with ESMTP id A2DC42FC25F; Thu, 27 Jan 2011 15:44:37 +0100 (CET) Message-ID: <4D418532.1010804@cttc.es> Date: Thu, 27 Jan 2011 15:46:10 +0100 From: Ramon Casellas Organization: CTTC User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: pce@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (castor); Thu, 27 Jan 2011 15:44:37 +0100 (CET) X-Scanned-By: MIMEDefang 2.67 on 84.88.62.197 Subject: Re: [Pce] LABEL-SET as object and TLV in pcep-extensions-01 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 14:41:50 -0000 Dear Christian, PCErs Thank you for your comments, this is indeed one of the open issues in the draft. Please see inline for some of my views. On 26/01/2011 20:46, Christian.Kaas-Petersen@tieto.com wrote: > Reading the draft-ietf-pce-gmpls-pcep-extensions-01 document, the definition > and use of LABEL-REQUEST, LABEL-SET, and SUGGESTED-LABEL-SET need further > clarification. We have had some discussions about this in the past, and I am afraid we still don't have a consensus. The main problem with the LABEL_SET object (and to some extent with SUGGESTED_LABEL and UPSTREAM_LABEL) is that the semantics are slightly different depending of the context. Let me explain, and apologies if this is well-known, it is clear that in MPLS-TE (or GMPLS PSC, etc) labels are, by definition, local to a link between two nodes. A LABEL_SET defines which labels are usable in that scope. However, when deploying GMPLS for WSON (and other swcap such as PBB-TE) there are technological constraints such as the Wavelength Continuity Constraint. With this in mind, the LABEL_SET in WSON has been "abused" to imply which labels are usable end to end. (e.g. the LABELSET includes which labels are usable and it is trimmed by nodes along the path, or re-expanded when a regenerator / converter is used. Lack of LABELSET is typically assumed as a failure to find continuous wavelengths. However, in MPLS lack of LABEL_SET implies that any label is ok). Since the GMPLS extensions need to apply at all layers, we have seemingly opposite concepts: on the one hand, MPLS defines a label as local to a link representing a FEC, WSON a label is implicitly a wavelength, end-to-end within a transparent segment without converters. Things can get much worse :) when considering translucent networks where the label has to remain constant along one or more transparent segments. If we assume that, regardless of how it is encoded (TLV, top level object, etc) , in a PCEP request the LABEL_SET is supposed to convey constraints in the path computation, and in a PCEP response it is supposed to convey attributes, without knowledge of the swcap the request applies to, or with extra assumptions, it is not possible to know what the constraints apply to. > LABEL-SET as an object is specified in section 2.5, but half-way > through the section, LABEL-SET is referred to as a TLV appearing in the > ERO object (and so LABEL-SET is a TLV of an RSVP object). Further In my opinion, this is indeed a problem with the draft in its current form, but I haven't yet reported to Editors about this. I am unsure how a variable sized object such as the ERO can include TLVs. At what point does the parser stop parsing subobjects to start parsing TLVs?, the first TLV would be wrongly parsed as a (possibly unknown) sub-object. The intended use as I suggested then was as RSVP ERO sub-object, not as TLV. FWIW, I am a proponent of LABEL_SET as top level object, also ENDPOINTS TLV since we need to convey info say.e.g about tunability of an interface, and, additionally, as a new ERO subobject. > In a PCReq, LABEL-SET can appear both as a PCEP object in its own right, and as > a PCEP TLV in the END-POINTS object, when the END-POINTS object is the new > Generalized endpoint Object Type. It is not clear to me, what difference > it makes to the semantics of the PCReq, whether LABEL-SET appears as > an object, as a TLV in END-POINTS, or indeed can appear in both places. > As you point out, there is still a lot of work to do in this area. My (subjective) view is as follows: Request a) - a LABEL_SET within ENDPOINTS (as TLV) applies at that endpoint and swcap and constraints the endpoint. The direct use case would be transceiver tunability b) - a LABEL_SET within a request (not exactly within a PCReq, although people commonly refer to objects within a PCReq) was defined to cover the case of "the labels that apply to the end-to-end path" and "only consider these labels for wavelenght allocation" c) - a LABEL_SET within a SVEC tuple could (To be done, for further study) convey constraints that apply to all involved requests, in line with previous bullet. Response d) - a LABEL_SET as a new ERO sub-object (not as TLV) as I suggested would be the only meaningful way that a PCE could restrain the use of a set of labels in a link along the path. RSVP-TE could easily generate the outgoing Labelset object directly while processing the ERO sub-object. This would extend the "explicit label control", to support "explicit labelset control": a new sub-object would be needed that would constrain the possible labels in the scope of the link that the subobject applies to, unambiguously. e) - a LABEL_SET as a top level object (within the path attributes) would convey the initial outgoing LABEL_SET for the LSP. Whether this refers to the end to end path or just a hop, we don't know, and that's dependent on the context. > It is not clearly stated in the draft, but I think the LABEL-SET can appear > in a PCRep as a PCEP object listing useable labels for the path returned. This is in line with what I just mentioned. We used to add a LABEL_SET top level object such as this extension in WSON, implying b) and e) but it was not completely satisfactory. It was clear that "Usable labels for the path" implies label continuity constraint or some other related constraint that does not necessarily apply to local labels and all swcap that the PCEP extensions for GMPLS should cover. In other words, a _Path_ LABEL_SET does not make sense if labels can change. If you consider all switching capabilities generically, what would a LABEL_SET mean in a response within a PCRep? the set of usable labels for the "first hop"?, for the "transparent segment"?, for the "end to end path"? However, for maximum flexibility we would like to be able to constrain and convey information about resources for cases such as WSON. How do you extend PCEP to support the use cases of WSON / LSC while remaining generic for say, PSC or MPLS-TP? that's what we would like to cover with the draft. Thank you for your comments clearly highlighting that more work is needed in this area :) Corrections and comments more than welcome. Best regards, Ramon -- Ramon Casellas, Ph.D. Research Associate - Optical Networking Area -- http://wikiona.cttc.es CTTC - Centre Tecnològic de Telecomunicacions de Catalunya, PMT Ed B4 Av. Carl Friedrich Gauss 7 08860 Castelldefels (Barcelona) - Spain Tel.: +34 93 645 29 16 -- Fax. +34 93 645 29 01 From zhangfatai@huawei.com Sun Jan 30 22:31:24 2011 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A06D73A6B90 for ; Sun, 30 Jan 2011 22:31:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.144 X-Spam-Level: X-Spam-Status: No, score=-1.144 tagged_above=-999 required=5 tests=[AWL=1.597, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id biH5Fy45U+8A for ; Sun, 30 Jan 2011 22:31:18 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 1A4263A6B98 for ; Sun, 30 Jan 2011 22:31:13 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LFV005P7JJ40W@szxga04-in.huawei.com> for pce@ietf.org; Mon, 31 Jan 2011 14:33:04 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LFV0021XJJ4H5@szxga04-in.huawei.com> for pce@ietf.org; Mon, 31 Jan 2011 14:33:04 +0800 (CST) Received: from z41162a ([10.70.76.157]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LFV00KUDJJ3GL@szxml06-in.huawei.com> for pce@ietf.org; Mon, 31 Jan 2011 14:33:04 +0800 (CST) Date: Mon, 31 Jan 2011 14:33:03 +0800 From: Fatai Zhang To: Ramon Casellas , pce@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: multipart/alternative; boundary="Boundary_(ID_CJTQb5Iqd1mk7gaIQPO01Q)" X-Priority: 3 X-MSMail-priority: Normal References: <4D418532.1010804@cttc.es> Subject: Re: [Pce] LABEL-SET as object and TLV in pcep-extensions-01 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 06:31:24 -0000 This is a multi-part message in MIME format. --Boundary_(ID_CJTQb5Iqd1mk7gaIQPO01Q) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: base64 SGkgUmFtb24gYW5kIENocmlzdGlhbiwNCg0KSSBhZ3JlZSB3aXRoIFJhbW9uIHRoYXQgd2Ugc2hv dWxkIHJlZmluZSB0aGUgZGVzY3JpcHRpb24gb24gdGhlIExhYmVsIGZvcm1hdCAgKExlYmVsLExh YmVsX1NldCwgU3VnZ2VzdGVkX0xhYmVsKSAgYmFzZWQgb24gdGhlIGRpZmZlcmVudCBjYXNlcyAg aW4gUENSZXEgYW5kIFBDUmVwIG1lc3NhZ2VzIChlLmcuIEVuZHBvaW50cywgRTJFIGNvbnN0cmFp bnQsIEVSTywgU1ZFQykuDQoNCg0KDQpUaGFua3MNCiANCkZhdGFpDQogDQpIdWF3ZWkgVGVjaG5v bG9naWVzIENvLiwgTFRELg0KSHVhd2VpIEJhc2UsIEJhbnRpYW4sIExvbmdnYW5nLA0KU2hlbnpo ZW4gNTE4MTI5IFAuUi5DaGluYQ0KVGVsOiArODYtNzU1LTI4OTcyOTEyDQpGYXg6ICs4Ni03NTUt Mjg5NzI5MzUNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJSYW1vbiBD YXNlbGxhcyIgPHJhbW9uLmNhc2VsbGFzQGN0dGMuZXM+DQpUbzogPHBjZUBpZXRmLm9yZz4NClNl bnQ6IFRodXJzZGF5LCBKYW51YXJ5IDI3LCAyMDExIDEwOjQ2IFBNDQpTdWJqZWN0OiBSZTogW1Bj ZV0gTEFCRUwtU0VUIGFzIG9iamVjdCBhbmQgVExWIGluIHBjZXAtZXh0ZW5zaW9ucy0wMQ0KDQoN CkRlYXIgQ2hyaXN0aWFuLCBQQ0Vycw0KDQpUaGFuayB5b3UgZm9yIHlvdXIgY29tbWVudHMsIHRo aXMgaXMgaW5kZWVkIG9uZSBvZiB0aGUgb3BlbiBpc3N1ZXMgaW4gDQp0aGUgZHJhZnQuIFBsZWFz ZSBzZWUgaW5saW5lIGZvciBzb21lIG9mIG15IHZpZXdzLg0KDQoNCg0KT24gMjYvMDEvMjAxMSAy MDo0NiwgQ2hyaXN0aWFuLkthYXMtUGV0ZXJzZW5AdGlldG8uY29tIHdyb3RlOg0KDQo+IFJlYWRp bmcgdGhlIGRyYWZ0LWlldGYtcGNlLWdtcGxzLXBjZXAtZXh0ZW5zaW9ucy0wMSBkb2N1bWVudCwg dGhlIGRlZmluaXRpb24NCj4gYW5kIHVzZSBvZiBMQUJFTC1SRVFVRVNULCBMQUJFTC1TRVQsIGFu ZCBTVUdHRVNURUQtTEFCRUwtU0VUIG5lZWQgZnVydGhlcg0KPiBjbGFyaWZpY2F0aW9uLg0KDQoN CldlIGhhdmUgaGFkIHNvbWUgZGlzY3Vzc2lvbnMgYWJvdXQgdGhpcyBpbiB0aGUgcGFzdCwgYW5k IEkgYW0gYWZyYWlkIHdlIA0Kc3RpbGwgZG9uJ3QgaGF2ZSBhIGNvbnNlbnN1cy4gVGhlIG1haW4g cHJvYmxlbSB3aXRoIHRoZSBMQUJFTF9TRVQgb2JqZWN0IA0KKGFuZCB0byBzb21lIGV4dGVudCB3 aXRoIFNVR0dFU1RFRF9MQUJFTCBhbmQgVVBTVFJFQU1fTEFCRUwpIGlzIHRoYXQgdGhlIA0Kc2Vt YW50aWNzIGFyZSBzbGlnaHRseSBkaWZmZXJlbnQgZGVwZW5kaW5nIG9mIHRoZSBjb250ZXh0LiBM ZXQgbWUgDQpleHBsYWluLCBhbmQgYXBvbG9naWVzIGlmIHRoaXMgaXMgd2VsbC1rbm93biwNCml0 IGlzIGNsZWFyIHRoYXQgaW4gTVBMUy1URSAob3IgR01QTFMgUFNDLCBldGMpIGxhYmVscyBhcmUs IGJ5IA0KZGVmaW5pdGlvbiwgbG9jYWwgdG8gYSBsaW5rIGJldHdlZW4gdHdvIG5vZGVzLiBBIExB QkVMX1NFVCBkZWZpbmVzIHdoaWNoIA0KbGFiZWxzIGFyZSB1c2FibGUgaW4gdGhhdCBzY29wZS4g SG93ZXZlciwgd2hlbiBkZXBsb3lpbmcgR01QTFMgZm9yIFdTT04gDQooYW5kIG90aGVyIHN3Y2Fw IHN1Y2ggYXMgUEJCLVRFKSB0aGVyZSBhcmUgdGVjaG5vbG9naWNhbCBjb25zdHJhaW50cyANCnN1 Y2ggYXMgdGhlIFdhdmVsZW5ndGggQ29udGludWl0eSBDb25zdHJhaW50LiBXaXRoIHRoaXMgaW4g bWluZCwgdGhlIA0KTEFCRUxfU0VUIGluIFdTT04gaGFzIGJlZW4gImFidXNlZCIgdG8gaW1wbHkg d2hpY2ggbGFiZWxzIGFyZSB1c2FibGUgZW5kIA0KdG8gZW5kLiAoZS5nLiB0aGUgTEFCRUxTRVQg aW5jbHVkZXMgd2hpY2ggbGFiZWxzIGFyZSB1c2FibGUgYW5kIGl0IGlzIA0KdHJpbW1lZCBieSBu b2RlcyBhbG9uZyB0aGUgcGF0aCwgb3IgcmUtZXhwYW5kZWQgd2hlbiBhIHJlZ2VuZXJhdG9yIC8g DQpjb252ZXJ0ZXIgaXMgdXNlZC4gTGFjayBvZiBMQUJFTFNFVCBpcyB0eXBpY2FsbHkgYXNzdW1l ZCBhcyBhIGZhaWx1cmUgdG8gDQpmaW5kIGNvbnRpbnVvdXMgd2F2ZWxlbmd0aHMuIEhvd2V2ZXIs IGluIE1QTFMgbGFjayBvZiBMQUJFTF9TRVQgaW1wbGllcyANCnRoYXQgYW55IGxhYmVsIGlzIG9r KS4NCg0KU2luY2UgdGhlIEdNUExTIGV4dGVuc2lvbnMgbmVlZCB0byBhcHBseSBhdCBhbGwgbGF5 ZXJzLCB3ZSBoYXZlIA0Kc2VlbWluZ2x5IG9wcG9zaXRlIGNvbmNlcHRzOiBvbiB0aGUgb25lIGhh bmQsIE1QTFMgZGVmaW5lcyBhIGxhYmVsIGFzIA0KbG9jYWwgdG8gYSBsaW5rIHJlcHJlc2VudGlu ZyBhIEZFQywgV1NPTiBhIGxhYmVsIGlzIGltcGxpY2l0bHkgYSANCndhdmVsZW5ndGgsIGVuZC10 by1lbmQgd2l0aGluIGEgdHJhbnNwYXJlbnQgc2VnbWVudCB3aXRob3V0IGNvbnZlcnRlcnMuIA0K VGhpbmdzIGNhbiBnZXQgbXVjaCB3b3JzZSA6KSB3aGVuIGNvbnNpZGVyaW5nIHRyYW5zbHVjZW50 IG5ldHdvcmtzIHdoZXJlIA0KdGhlIGxhYmVsIGhhcyB0byByZW1haW4gY29uc3RhbnQgYWxvbmcg b25lIG9yIG1vcmUgdHJhbnNwYXJlbnQgc2VnbWVudHMuIA0KSWYgd2UgYXNzdW1lIHRoYXQsIHJl Z2FyZGxlc3Mgb2YgaG93IGl0IGlzIGVuY29kZWQgKFRMViwgdG9wIGxldmVsIA0Kb2JqZWN0LCBl dGMpICwgaW4gYSBQQ0VQIHJlcXVlc3QgdGhlIExBQkVMX1NFVCBpcyBzdXBwb3NlZCB0byBjb252 ZXkgDQpjb25zdHJhaW50cyBpbiB0aGUgcGF0aCBjb21wdXRhdGlvbiwgYW5kIGluIGEgUENFUCBy ZXNwb25zZSBpdCBpcyANCnN1cHBvc2VkIHRvIGNvbnZleSBhdHRyaWJ1dGVzLCB3aXRob3V0IGtu b3dsZWRnZSBvZiB0aGUgc3djYXAgdGhlIA0KcmVxdWVzdCBhcHBsaWVzIHRvLCBvciB3aXRoIGV4 dHJhIGFzc3VtcHRpb25zLCBpdCBpcyBub3QgcG9zc2libGUgdG8gDQprbm93IHdoYXQgdGhlIGNv bnN0cmFpbnRzIGFwcGx5IHRvLg0KDQoNCj4gTEFCRUwtU0VUIGFzIGFuIG9iamVjdCBpcyBzcGVj aWZpZWQgaW4gc2VjdGlvbiAyLjUsIGJ1dCBoYWxmLXdheQ0KPiB0aHJvdWdoIHRoZSBzZWN0aW9u LCBMQUJFTC1TRVQgaXMgcmVmZXJyZWQgdG8gYXMgYSBUTFYgYXBwZWFyaW5nIGluIHRoZQ0KPiBF Uk8gb2JqZWN0IChhbmQgc28gTEFCRUwtU0VUIGlzIGEgVExWIG9mIGFuIFJTVlAgb2JqZWN0KS4g IEZ1cnRoZXINCg0KSW4gbXkgb3BpbmlvbiwgdGhpcyBpcyBpbmRlZWQgYSBwcm9ibGVtIHdpdGgg dGhlIGRyYWZ0IGluIGl0cyBjdXJyZW50IA0KZm9ybSwgYnV0IEkgaGF2ZW4ndCB5ZXQgcmVwb3J0 ZWQgdG8gRWRpdG9ycyBhYm91dCB0aGlzLiBJIGFtIHVuc3VyZSBob3cgDQphIHZhcmlhYmxlIHNp emVkIG9iamVjdCBzdWNoIGFzIHRoZSBFUk8gY2FuIGluY2x1ZGUgVExWcy4gQXQgd2hhdCBwb2lu dCANCmRvZXMgdGhlIHBhcnNlciBzdG9wIHBhcnNpbmcgc3Vib2JqZWN0cyB0byBzdGFydCBwYXJz aW5nIFRMVnM/LCB0aGUgDQpmaXJzdCBUTFYgd291bGQgYmUgd3JvbmdseSBwYXJzZWQgYXMgYSAo cG9zc2libHkgdW5rbm93bikgc3ViLW9iamVjdC4gDQpUaGUgaW50ZW5kZWQgdXNlIGFzIEkgc3Vn Z2VzdGVkIHRoZW4gd2FzIGFzIFJTVlAgRVJPIHN1Yi1vYmplY3QsIG5vdCBhcyANClRMVi4NCg0K RldJVywgSSBhbSBhIHByb3BvbmVudCBvZiBMQUJFTF9TRVQgYXMgdG9wIGxldmVsIG9iamVjdCwg YWxzbyAgRU5EUE9JTlRTIA0KVExWIHNpbmNlIHdlIG5lZWQgdG8gY29udmV5IGluZm8gc2F5LmUu ZyBhYm91dCB0dW5hYmlsaXR5IG9mIGFuIA0KaW50ZXJmYWNlLCBhbmQsIGFkZGl0aW9uYWxseSwg YXMgYSBuZXcgRVJPIHN1Ym9iamVjdC4NCg0KPiBJbiBhIFBDUmVxLCBMQUJFTC1TRVQgY2FuIGFw cGVhciBib3RoIGFzIGEgUENFUCBvYmplY3QgaW4gaXRzIG93biByaWdodCwgYW5kIGFzDQo+IGEg UENFUCBUTFYgaW4gdGhlIEVORC1QT0lOVFMgb2JqZWN0LCB3aGVuIHRoZSBFTkQtUE9JTlRTIG9i amVjdCBpcyB0aGUgbmV3DQo+IEdlbmVyYWxpemVkIGVuZHBvaW50IE9iamVjdCBUeXBlLiAgSXQg aXMgbm90IGNsZWFyIHRvIG1lLCB3aGF0IGRpZmZlcmVuY2UNCj4gaXQgbWFrZXMgdG8gdGhlIHNl bWFudGljcyBvZiB0aGUgUENSZXEsIHdoZXRoZXIgTEFCRUwtU0VUIGFwcGVhcnMgYXMNCj4gYW4g b2JqZWN0LCBhcyBhIFRMViBpbiBFTkQtUE9JTlRTLCBvciBpbmRlZWQgY2FuIGFwcGVhciBpbiBi b3RoIHBsYWNlcy4NCj4NCg0KQXMgeW91IHBvaW50IG91dCwgdGhlcmUgaXMgc3RpbGwgYSBsb3Qg b2Ygd29yayB0byBkbyBpbiB0aGlzIGFyZWEuIE15IA0KKHN1YmplY3RpdmUpIHZpZXcgaXMgYXMg Zm9sbG93czoNCg0KUmVxdWVzdA0KDQphKSAtIGEgTEFCRUxfU0VUIHdpdGhpbiBFTkRQT0lOVFMg KGFzIFRMVikgYXBwbGllcyBhdCB0aGF0IGVuZHBvaW50IGFuZCANCnN3Y2FwIGFuZCBjb25zdHJh aW50cyB0aGUgZW5kcG9pbnQuIFRoZSBkaXJlY3QgdXNlIGNhc2Ugd291bGQgYmUgDQp0cmFuc2Nl aXZlciB0dW5hYmlsaXR5DQoNCmIpIC0gYSBMQUJFTF9TRVQgd2l0aGluIGEgcmVxdWVzdCAobm90 IGV4YWN0bHkgd2l0aGluIGEgUENSZXEsIGFsdGhvdWdoIA0KcGVvcGxlIGNvbW1vbmx5IHJlZmVy IHRvIG9iamVjdHMgd2l0aGluIGEgUENSZXEpIHdhcyBkZWZpbmVkIHRvIGNvdmVyIA0KdGhlIGNh c2Ugb2YgInRoZSBsYWJlbHMgdGhhdCBhcHBseSB0byB0aGUgZW5kLXRvLWVuZCBwYXRoIiBhbmQg Im9ubHkgDQpjb25zaWRlciB0aGVzZSBsYWJlbHMgZm9yIHdhdmVsZW5naHQgYWxsb2NhdGlvbiIN Cg0KYykgLSBhIExBQkVMX1NFVCB3aXRoaW4gYSBTVkVDIHR1cGxlIGNvdWxkIChUbyBiZSBkb25l LCBmb3IgZnVydGhlciANCnN0dWR5KSBjb252ZXkgY29uc3RyYWludHMgdGhhdCBhcHBseSB0byBh bGwgaW52b2x2ZWQgcmVxdWVzdHMsIGluIGxpbmUgDQp3aXRoIHByZXZpb3VzIGJ1bGxldC4NCg0K DQpSZXNwb25zZQ0KDQpkKSAtIGEgTEFCRUxfU0VUIGFzIGEgbmV3IEVSTyBzdWItb2JqZWN0ICAo bm90IGFzIFRMVikgYXMgSSBzdWdnZXN0ZWQgDQp3b3VsZCBiZSB0aGUgb25seSBtZWFuaW5nZnVs IHdheSB0aGF0IGEgUENFIGNvdWxkIHJlc3RyYWluIHRoZSB1c2Ugb2YgYSANCnNldCBvZiBsYWJl bHMgaW4gYSBsaW5rIGFsb25nIHRoZSBwYXRoLiBSU1ZQLVRFIGNvdWxkIGVhc2lseSBnZW5lcmF0 ZSANCnRoZSBvdXRnb2luZyBMYWJlbHNldCBvYmplY3QgZGlyZWN0bHkgd2hpbGUgcHJvY2Vzc2lu ZyB0aGUgRVJPIA0Kc3ViLW9iamVjdC4gVGhpcyB3b3VsZCBleHRlbmQgdGhlICJleHBsaWNpdCBs YWJlbCBjb250cm9sIiwgdG8gc3VwcG9ydCANCiJleHBsaWNpdCBsYWJlbHNldCBjb250cm9sIjog YSBuZXcgc3ViLW9iamVjdCB3b3VsZCBiZSBuZWVkZWQgdGhhdCB3b3VsZCANCmNvbnN0cmFpbiB0 aGUgcG9zc2libGUgbGFiZWxzIGluIHRoZSBzY29wZSBvZiB0aGUgbGluayB0aGF0IHRoZSANCnN1 Ym9iamVjdCBhcHBsaWVzIHRvLCB1bmFtYmlndW91c2x5Lg0KDQplKSAtIGEgTEFCRUxfU0VUIGFz IGEgdG9wIGxldmVsIG9iamVjdCAod2l0aGluIHRoZSBwYXRoIGF0dHJpYnV0ZXMpIA0Kd291bGQg Y29udmV5IHRoZSBpbml0aWFsIG91dGdvaW5nIExBQkVMX1NFVCBmb3IgdGhlIExTUC4gV2hldGhl ciB0aGlzIA0KcmVmZXJzIHRvIHRoZSBlbmQgdG8gZW5kIHBhdGggb3IganVzdCBhIGhvcCwgd2Ug ZG9uJ3Qga25vdywgYW5kIHRoYXQncyANCmRlcGVuZGVudCBvbiB0aGUgY29udGV4dC4NCg0KPiBJ dCBpcyBub3QgY2xlYXJseSBzdGF0ZWQgaW4gdGhlIGRyYWZ0LCBidXQgSSB0aGluayB0aGUgTEFC RUwtU0VUIGNhbiBhcHBlYXINCj4gaW4gYSBQQ1JlcCBhcyBhIFBDRVAgb2JqZWN0IGxpc3Rpbmcg dXNlYWJsZSBsYWJlbHMgZm9yIHRoZSBwYXRoIHJldHVybmVkLg0KVGhpcyBpcyBpbiBsaW5lIHdp dGggd2hhdCBJIGp1c3QgbWVudGlvbmVkLiBXZSB1c2VkIHRvIGFkZCBhIExBQkVMX1NFVCANCnRv cCBsZXZlbCBvYmplY3Qgc3VjaCBhcyB0aGlzIGV4dGVuc2lvbiBpbiBXU09OLCBpbXBseWluZyBi KSBhbmQgZSkgYnV0IA0KaXQgd2FzIG5vdCBjb21wbGV0ZWx5IHNhdGlzZmFjdG9yeS4NCkl0IHdh cyBjbGVhciB0aGF0ICJVc2FibGUgbGFiZWxzIGZvciB0aGUgcGF0aCIgaW1wbGllcyBsYWJlbCBj b250aW51aXR5IA0KY29uc3RyYWludCBvciBzb21lIG90aGVyIHJlbGF0ZWQgY29uc3RyYWludCB0 aGF0IGRvZXMgbm90IG5lY2Vzc2FyaWx5IA0KYXBwbHkgdG8gbG9jYWwgbGFiZWxzIGFuZCBhbGwg c3djYXAgdGhhdCB0aGUgUENFUCBleHRlbnNpb25zIGZvciBHTVBMUyANCnNob3VsZCBjb3Zlci4g IEluIG90aGVyIHdvcmRzLCBhIF9QYXRoXyBMQUJFTF9TRVQgZG9lcyBub3QgbWFrZSBzZW5zZSBp ZiANCmxhYmVscyBjYW4gY2hhbmdlLiBJZiB5b3UgY29uc2lkZXIgYWxsIHN3aXRjaGluZyBjYXBh YmlsaXRpZXMgDQpnZW5lcmljYWxseSwgd2hhdCB3b3VsZCBhIExBQkVMX1NFVCBtZWFuIGluIGEg cmVzcG9uc2Ugd2l0aGluIGEgUENSZXA/IA0KdGhlIHNldCBvZiB1c2FibGUgbGFiZWxzIGZvciB0 aGUgImZpcnN0IGhvcCI/LCBmb3IgdGhlICJ0cmFuc3BhcmVudCANCnNlZ21lbnQiPywgZm9yIHRo ZSAiZW5kIHRvIGVuZCBwYXRoIj8NCg0KSG93ZXZlciwgZm9yIG1heGltdW0gZmxleGliaWxpdHkg d2Ugd291bGQgbGlrZSB0byBiZSBhYmxlIHRvIGNvbnN0cmFpbiANCmFuZCBjb252ZXkgaW5mb3Jt YXRpb24gYWJvdXQgcmVzb3VyY2VzIGZvciBjYXNlcyBzdWNoIGFzIFdTT04uIEhvdyBkbyANCnlv dSBleHRlbmQgUENFUCB0byBzdXBwb3J0IHRoZSB1c2UgY2FzZXMgb2YgV1NPTiAvIExTQyB3aGls ZSByZW1haW5pbmcgDQpnZW5lcmljIGZvciBzYXksIFBTQyBvciBNUExTLVRQPyB0aGF0J3Mgd2hh dCB3ZSB3b3VsZCBsaWtlIHRvIGNvdmVyIHdpdGggDQp0aGUgZHJhZnQuDQoNCg0KVGhhbmsgeW91 IGZvciB5b3VyIGNvbW1lbnRzIGNsZWFybHkgaGlnaGxpZ2h0aW5nIHRoYXQgbW9yZSB3b3JrIGlz IA0KbmVlZGVkIGluIHRoaXMgYXJlYSA6KQ0KDQpDb3JyZWN0aW9ucyBhbmQgY29tbWVudHMgbW9y ZSB0aGFuIHdlbGNvbWUuDQoNCg0KQmVzdCByZWdhcmRzLA0KDQpSYW1vbg0KDQoNCg0KLS0gDQpS YW1vbiBDYXNlbGxhcywgUGguRC4NClJlc2VhcmNoIEFzc29jaWF0ZSAtIE9wdGljYWwgTmV0d29y a2luZyBBcmVhIC0tIGh0dHA6Ly93aWtpb25hLmN0dGMuZXMNCkNUVEMgLSBDZW50cmUgVGVjbm9s 8mdpYyBkZSBUZWxlY29tdW5pY2FjaW9ucyBkZSBDYXRhbHVueWEsIFBNVCBFZCBCNA0KQXYuIENh cmwgRnJpZWRyaWNoIEdhdXNzIDcgMDg4NjAgQ2FzdGVsbGRlZmVscyAoQmFyY2Vsb25hKSAtIFNw YWluDQpUZWwuOiArMzQgOTMgNjQ1IDI5IDE2IC0tIEZheC4gKzM0IDkzIDY0NSAyOSAwMQ0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KUGNlIG1haWxp bmcgbGlzdA0KUGNlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3BjZQ0K --Boundary_(ID_CJTQb5Iqd1mk7gaIQPO01Q) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDYuMDAuMjkwMC42MDQ5IiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFE Pg0KPEJPRFk+DQo8RElWPjxGT05UIGZhY2U9Q2FsaWJyaT48L0ZPTlQ+PEZPTlQgZmFjZT1DYWxp YnJpIGNvbG9yPSMwMDAwODA+SGkgUmFtb24gYW5kIA0KQ2hyaXN0aWFuLDwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgZmFjZT1DYWxpYnJpIGNvbG9yPSMwMDAwODA+PC9GT05UPiZuYnNwOzwvRElW Pg0KPERJVj48Rk9OVCBmYWNlPUNhbGlicmkgY29sb3I9IzAwMDA4MD5JIGFncmVlIHdpdGggUmFt b24gdGhhdCB3ZSBzaG91bGQgcmVmaW5lIA0KdGhlIGRlc2NyaXB0aW9uIG9uIHRoZSBMYWJlbCBm b3JtYXQmbmJzcDsgKExlYmVsLExhYmVsX1NldCwgDQpTdWdnZXN0ZWRfTGFiZWwpJm5ic3A7Jm5i c3A7YmFzZWQgb24gdGhlIGRpZmZlcmVudCBjYXNlcyZuYnNwOyZuYnNwO2luIFBDUmVxIGFuZCAN ClBDUmVwIG1lc3NhZ2VzIChlLmcuIEVuZHBvaW50cywgRTJFIGNvbnN0cmFpbnQsIEVSTywgU1ZF QykuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUNhbGlicmkgY29sb3I9IzAwMDA4MD48 L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Q2FsaWJyaSBjb2xvcj0jMDAwMDgw PjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1DYWxpYnJpIGNvbG9yPSMwMDAw ODA+PC9GT05UPjxGT05UIGZhY2U9Q2FsaWJyaSANCmNvbG9yPSMwMDAwODA+PC9GT05UPjxGT05U IGZhY2U9Q2FsaWJyaSBjb2xvcj0jMDAwMDgwPjwvRk9OVD48QlI+PEZPTlQgDQpmYWNlPUNhbGli cmkgY29sb3I9IzAwMDA4MD5UaGFua3M8QlI+Jm5ic3A7PEJSPkZhdGFpPEJSPiZuYnNwOzxCUj5I dWF3ZWkgDQpUZWNobm9sb2dpZXMgQ28uLCBMVEQuPEJSPkh1YXdlaSBCYXNlLCBCYW50aWFuLCBM b25nZ2FuZyw8QlI+U2hlbnpoZW4gNTE4MTI5IA0KUC5SLkNoaW5hPEJSPlRlbDogKzg2LTc1NS0y ODk3MjkxMjxCUj5GYXg6ICs4Ni03NTUtMjg5NzI5MzU8QlI+PC9GT05UPjwvRElWPg0KPERJVj48 Rk9OVCBmYWNlPUNhbGlicmk+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSA8L0ZPTlQ+DQo8 RElWPjxGT05UIGZhY2U9Q2FsaWJyaT5Gcm9tOiAiUmFtb24gQ2FzZWxsYXMiICZsdDs8L0ZPTlQ+ PEEgDQpocmVmPSJtYWlsdG86cmFtb24uY2FzZWxsYXNAY3R0Yy5lcyI+PEZPTlQgZmFjZT1DYWxp YnJpIA0KY29sb3I9IzAwMDAwMD5yYW1vbi5jYXNlbGxhc0BjdHRjLmVzPC9GT05UPjwvQT48Rk9O VCANCmZhY2U9Q2FsaWJyaT4mZ3Q7PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUNhbGli cmk+VG86ICZsdDs8L0ZPTlQ+PEEgaHJlZj0ibWFpbHRvOnBjZUBpZXRmLm9yZyI+PEZPTlQgDQpm YWNlPUNhbGlicmkgY29sb3I9IzAwMDAwMD5wY2VAaWV0Zi5vcmc8L0ZPTlQ+PC9BPjxGT05UIA0K ZmFjZT1DYWxpYnJpPiZndDs8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Q2FsaWJyaT5T ZW50OiBUaHVyc2RheSwgSmFudWFyeSAyNywgMjAxMSAxMDo0NiBQTTwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgZmFjZT1DYWxpYnJpPlN1YmplY3Q6IFJlOiBbUGNlXSBMQUJFTC1TRVQgYXMgb2Jq ZWN0IGFuZCBUTFYgaW4gDQpwY2VwLWV4dGVuc2lvbnMtMDE8L0ZPTlQ+PC9ESVY+PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9Q2FsaWJyaT48QlI+PC9GT05UPjwvRElWPjxGT05UIGZhY2U9Q2FsaWJy aT5EZWFyIENocmlzdGlhbiwgDQpQQ0VyczxCUj48QlI+VGhhbmsgeW91IGZvciB5b3VyIGNvbW1l bnRzLCB0aGlzIGlzIGluZGVlZCBvbmUgb2YgdGhlIG9wZW4gaXNzdWVzIA0KaW4gPEJSPnRoZSBk cmFmdC4gUGxlYXNlIHNlZSBpbmxpbmUgZm9yIHNvbWUgb2YgbXkgdmlld3MuPEJSPjxCUj48QlI+ PEJSPk9uIA0KMjYvMDEvMjAxMSAyMDo0NiwgPC9GT05UPjxBIA0KaHJlZj0ibWFpbHRvOkNocmlz dGlhbi5LYWFzLVBldGVyc2VuQHRpZXRvLmNvbSI+PEZPTlQgZmFjZT1DYWxpYnJpIA0KY29sb3I9 IzAwMDAwMD5DaHJpc3RpYW4uS2Fhcy1QZXRlcnNlbkB0aWV0by5jb208L0ZPTlQ+PC9BPjxGT05U IGZhY2U9Q2FsaWJyaT4gDQp3cm90ZTo8QlI+PEJSPiZndDsgUmVhZGluZyB0aGUgZHJhZnQtaWV0 Zi1wY2UtZ21wbHMtcGNlcC1leHRlbnNpb25zLTAxIGRvY3VtZW50LCANCnRoZSBkZWZpbml0aW9u PEJSPiZndDsgYW5kIHVzZSBvZiBMQUJFTC1SRVFVRVNULCBMQUJFTC1TRVQsIGFuZCANClNVR0dF U1RFRC1MQUJFTC1TRVQgbmVlZCBmdXJ0aGVyPEJSPiZndDsgY2xhcmlmaWNhdGlvbi48QlI+PEJS PjxCUj5XZSBoYXZlIGhhZCANCnNvbWUgZGlzY3Vzc2lvbnMgYWJvdXQgdGhpcyBpbiB0aGUgcGFz dCwgYW5kIEkgYW0gYWZyYWlkIHdlIDxCUj5zdGlsbCBkb24ndCBoYXZlIA0KYSBjb25zZW5zdXMu IFRoZSBtYWluIHByb2JsZW0gd2l0aCB0aGUgTEFCRUxfU0VUIG9iamVjdCA8QlI+KGFuZCB0byBz b21lIGV4dGVudCANCndpdGggU1VHR0VTVEVEX0xBQkVMIGFuZCBVUFNUUkVBTV9MQUJFTCkgaXMg dGhhdCB0aGUgPEJSPnNlbWFudGljcyBhcmUgc2xpZ2h0bHkgDQpkaWZmZXJlbnQgZGVwZW5kaW5n IG9mIHRoZSBjb250ZXh0LiBMZXQgbWUgPEJSPmV4cGxhaW4sIGFuZCBhcG9sb2dpZXMgaWYgdGhp cyBpcyANCndlbGwta25vd24sPEJSPml0IGlzIGNsZWFyIHRoYXQgaW4gTVBMUy1URSAob3IgR01Q TFMgUFNDLCBldGMpIGxhYmVscyBhcmUsIGJ5IA0KPEJSPmRlZmluaXRpb24sIGxvY2FsIHRvIGEg bGluayBiZXR3ZWVuIHR3byBub2Rlcy4gQSBMQUJFTF9TRVQgZGVmaW5lcyB3aGljaCANCjxCUj5s YWJlbHMgYXJlIHVzYWJsZSBpbiB0aGF0IHNjb3BlLiBIb3dldmVyLCB3aGVuIGRlcGxveWluZyBH TVBMUyBmb3IgV1NPTiANCjxCUj4oYW5kIG90aGVyIHN3Y2FwIHN1Y2ggYXMgUEJCLVRFKSB0aGVy ZSBhcmUgdGVjaG5vbG9naWNhbCBjb25zdHJhaW50cyANCjxCUj5zdWNoIGFzIHRoZSBXYXZlbGVu Z3RoIENvbnRpbnVpdHkgQ29uc3RyYWludC4gV2l0aCB0aGlzIGluIG1pbmQsIHRoZSANCjxCUj5M QUJFTF9TRVQgaW4gV1NPTiBoYXMgYmVlbiAiYWJ1c2VkIiB0byBpbXBseSB3aGljaCBsYWJlbHMg YXJlIHVzYWJsZSBlbmQgDQo8QlI+dG8gZW5kLiAoZS5nLiB0aGUgTEFCRUxTRVQgaW5jbHVkZXMg d2hpY2ggbGFiZWxzIGFyZSB1c2FibGUgYW5kIGl0IGlzIA0KPEJSPnRyaW1tZWQgYnkgbm9kZXMg YWxvbmcgdGhlIHBhdGgsIG9yIHJlLWV4cGFuZGVkIHdoZW4gYSByZWdlbmVyYXRvciAvIA0KPEJS PmNvbnZlcnRlciBpcyB1c2VkLiBMYWNrIG9mIExBQkVMU0VUIGlzIHR5cGljYWxseSBhc3N1bWVk IGFzIGEgZmFpbHVyZSB0byANCjxCUj5maW5kIGNvbnRpbnVvdXMgd2F2ZWxlbmd0aHMuIEhvd2V2 ZXIsIGluIE1QTFMgbGFjayBvZiBMQUJFTF9TRVQgaW1wbGllcyANCjxCUj50aGF0IGFueSBsYWJl bCBpcyBvaykuPEJSPjxCUj5TaW5jZSB0aGUgR01QTFMgZXh0ZW5zaW9ucyBuZWVkIHRvIGFwcGx5 IGF0IA0KYWxsIGxheWVycywgd2UgaGF2ZSA8QlI+c2VlbWluZ2x5IG9wcG9zaXRlIGNvbmNlcHRz OiBvbiB0aGUgb25lIGhhbmQsIE1QTFMgDQpkZWZpbmVzIGEgbGFiZWwgYXMgPEJSPmxvY2FsIHRv IGEgbGluayByZXByZXNlbnRpbmcgYSBGRUMsIFdTT04gYSBsYWJlbCBpcyANCmltcGxpY2l0bHkg YSA8QlI+d2F2ZWxlbmd0aCwgZW5kLXRvLWVuZCB3aXRoaW4gYSB0cmFuc3BhcmVudCBzZWdtZW50 IHdpdGhvdXQgDQpjb252ZXJ0ZXJzLiA8QlI+VGhpbmdzIGNhbiBnZXQgbXVjaCB3b3JzZSA6KSB3 aGVuIGNvbnNpZGVyaW5nIHRyYW5zbHVjZW50IA0KbmV0d29ya3Mgd2hlcmUgPEJSPnRoZSBsYWJl bCBoYXMgdG8gcmVtYWluIGNvbnN0YW50IGFsb25nIG9uZSBvciBtb3JlIA0KdHJhbnNwYXJlbnQg c2VnbWVudHMuIDxCUj5JZiB3ZSBhc3N1bWUgdGhhdCwgcmVnYXJkbGVzcyBvZiBob3cgaXQgaXMg ZW5jb2RlZCANCihUTFYsIHRvcCBsZXZlbCA8QlI+b2JqZWN0LCBldGMpICwgaW4gYSBQQ0VQIHJl cXVlc3QgdGhlIExBQkVMX1NFVCBpcyBzdXBwb3NlZCANCnRvIGNvbnZleSA8QlI+Y29uc3RyYWlu dHMgaW4gdGhlIHBhdGggY29tcHV0YXRpb24sIGFuZCBpbiBhIFBDRVAgcmVzcG9uc2UgaXQgaXMg DQo8QlI+c3VwcG9zZWQgdG8gY29udmV5IGF0dHJpYnV0ZXMsIHdpdGhvdXQga25vd2xlZGdlIG9m IHRoZSBzd2NhcCB0aGUgDQo8QlI+cmVxdWVzdCBhcHBsaWVzIHRvLCBvciB3aXRoIGV4dHJhIGFz c3VtcHRpb25zLCBpdCBpcyBub3QgcG9zc2libGUgdG8gDQo8QlI+a25vdyB3aGF0IHRoZSBjb25z dHJhaW50cyBhcHBseSB0by48QlI+PEJSPjxCUj4mZ3Q7IExBQkVMLVNFVCBhcyBhbiBvYmplY3Qg DQppcyBzcGVjaWZpZWQgaW4gc2VjdGlvbiAyLjUsIGJ1dCBoYWxmLXdheTxCUj4mZ3Q7IHRocm91 Z2ggdGhlIHNlY3Rpb24sIExBQkVMLVNFVCANCmlzIHJlZmVycmVkIHRvIGFzIGEgVExWIGFwcGVh cmluZyBpbiB0aGU8QlI+Jmd0OyBFUk8gb2JqZWN0IChhbmQgc28gTEFCRUwtU0VUIGlzIA0KYSBU TFYgb2YgYW4gUlNWUCBvYmplY3QpLiZuYnNwOyBGdXJ0aGVyPEJSPjxCUj5JbiBteSBvcGluaW9u LCB0aGlzIGlzIGluZGVlZCBhIA0KcHJvYmxlbSB3aXRoIHRoZSBkcmFmdCBpbiBpdHMgY3VycmVu dCA8QlI+Zm9ybSwgYnV0IEkgaGF2ZW4ndCB5ZXQgcmVwb3J0ZWQgdG8gDQpFZGl0b3JzIGFib3V0 IHRoaXMuIEkgYW0gdW5zdXJlIGhvdyA8QlI+YSB2YXJpYWJsZSBzaXplZCBvYmplY3Qgc3VjaCBh cyB0aGUgRVJPIA0KY2FuIGluY2x1ZGUgVExWcy4gQXQgd2hhdCBwb2ludCA8QlI+ZG9lcyB0aGUg cGFyc2VyIHN0b3AgcGFyc2luZyBzdWJvYmplY3RzIHRvIA0Kc3RhcnQgcGFyc2luZyBUTFZzPywg dGhlIDxCUj5maXJzdCBUTFYgd291bGQgYmUgd3JvbmdseSBwYXJzZWQgYXMgYSAocG9zc2libHkg DQp1bmtub3duKSBzdWItb2JqZWN0LiA8QlI+VGhlIGludGVuZGVkIHVzZSBhcyBJIHN1Z2dlc3Rl ZCB0aGVuIHdhcyBhcyBSU1ZQIEVSTyANCnN1Yi1vYmplY3QsIG5vdCBhcyA8QlI+VExWLjxCUj48 QlI+RldJVywgSSBhbSBhIHByb3BvbmVudCBvZiBMQUJFTF9TRVQgYXMgdG9wIA0KbGV2ZWwgb2Jq ZWN0LCBhbHNvJm5ic3A7IEVORFBPSU5UUyA8QlI+VExWIHNpbmNlIHdlIG5lZWQgdG8gY29udmV5 IGluZm8gc2F5LmUuZyANCmFib3V0IHR1bmFiaWxpdHkgb2YgYW4gPEJSPmludGVyZmFjZSwgYW5k LCBhZGRpdGlvbmFsbHksIGFzIGEgbmV3IEVSTyANCnN1Ym9iamVjdC48QlI+PEJSPiZndDsgSW4g YSBQQ1JlcSwgTEFCRUwtU0VUIGNhbiBhcHBlYXIgYm90aCBhcyBhIFBDRVAgb2JqZWN0IGluIA0K aXRzIG93biByaWdodCwgYW5kIGFzPEJSPiZndDsgYSBQQ0VQIFRMViBpbiB0aGUgRU5ELVBPSU5U UyBvYmplY3QsIHdoZW4gdGhlIA0KRU5ELVBPSU5UUyBvYmplY3QgaXMgdGhlIG5ldzxCUj4mZ3Q7 IEdlbmVyYWxpemVkIGVuZHBvaW50IE9iamVjdCBUeXBlLiZuYnNwOyBJdCANCmlzIG5vdCBjbGVh ciB0byBtZSwgd2hhdCBkaWZmZXJlbmNlPEJSPiZndDsgaXQgbWFrZXMgdG8gdGhlIHNlbWFudGlj cyBvZiB0aGUgDQpQQ1JlcSwgd2hldGhlciBMQUJFTC1TRVQgYXBwZWFycyBhczxCUj4mZ3Q7IGFu IG9iamVjdCwgYXMgYSBUTFYgaW4gRU5ELVBPSU5UUywgDQpvciBpbmRlZWQgY2FuIGFwcGVhciBp biBib3RoIHBsYWNlcy48QlI+Jmd0OzxCUj48QlI+QXMgeW91IHBvaW50IG91dCwgdGhlcmUgaXMg DQpzdGlsbCBhIGxvdCBvZiB3b3JrIHRvIGRvIGluIHRoaXMgYXJlYS4gTXkgPEJSPihzdWJqZWN0 aXZlKSB2aWV3IGlzIGFzIA0KZm9sbG93czo8QlI+PEJSPlJlcXVlc3Q8QlI+PEJSPmEpIC0gYSBM QUJFTF9TRVQgd2l0aGluIEVORFBPSU5UUyAoYXMgVExWKSANCmFwcGxpZXMgYXQgdGhhdCBlbmRw b2ludCBhbmQgPEJSPnN3Y2FwIGFuZCBjb25zdHJhaW50cyB0aGUgZW5kcG9pbnQuIFRoZSBkaXJl Y3QgDQp1c2UgY2FzZSB3b3VsZCBiZSA8QlI+dHJhbnNjZWl2ZXIgdHVuYWJpbGl0eTxCUj48QlI+ YikgLSBhIExBQkVMX1NFVCB3aXRoaW4gYSANCnJlcXVlc3QgKG5vdCBleGFjdGx5IHdpdGhpbiBh IFBDUmVxLCBhbHRob3VnaCA8QlI+cGVvcGxlIGNvbW1vbmx5IHJlZmVyIHRvIA0Kb2JqZWN0cyB3 aXRoaW4gYSBQQ1JlcSkgd2FzIGRlZmluZWQgdG8gY292ZXIgPEJSPnRoZSBjYXNlIG9mICJ0aGUg bGFiZWxzIHRoYXQgDQphcHBseSB0byB0aGUgZW5kLXRvLWVuZCBwYXRoIiBhbmQgIm9ubHkgPEJS PmNvbnNpZGVyIHRoZXNlIGxhYmVscyBmb3Igd2F2ZWxlbmdodCANCmFsbG9jYXRpb24iPEJSPjxC Uj5jKSAtIGEgTEFCRUxfU0VUIHdpdGhpbiBhIFNWRUMgdHVwbGUgY291bGQgKFRvIGJlIGRvbmUs IGZvciANCmZ1cnRoZXIgPEJSPnN0dWR5KSBjb252ZXkgY29uc3RyYWludHMgdGhhdCBhcHBseSB0 byBhbGwgaW52b2x2ZWQgcmVxdWVzdHMsIGluIA0KbGluZSA8QlI+d2l0aCBwcmV2aW91cyBidWxs ZXQuPEJSPjxCUj48QlI+UmVzcG9uc2U8QlI+PEJSPmQpIC0gYSBMQUJFTF9TRVQgYXMgYSANCm5l dyBFUk8gc3ViLW9iamVjdCZuYnNwOyAobm90IGFzIFRMVikgYXMgSSBzdWdnZXN0ZWQgPEJSPndv dWxkIGJlIHRoZSBvbmx5IA0KbWVhbmluZ2Z1bCB3YXkgdGhhdCBhIFBDRSBjb3VsZCByZXN0cmFp biB0aGUgdXNlIG9mIGEgPEJSPnNldCBvZiBsYWJlbHMgaW4gYSANCmxpbmsgYWxvbmcgdGhlIHBh dGguIFJTVlAtVEUgY291bGQgZWFzaWx5IGdlbmVyYXRlIDxCUj50aGUgb3V0Z29pbmcgTGFiZWxz ZXQgDQpvYmplY3QgZGlyZWN0bHkgd2hpbGUgcHJvY2Vzc2luZyB0aGUgRVJPIDxCUj5zdWItb2Jq ZWN0LiBUaGlzIHdvdWxkIGV4dGVuZCB0aGUgDQoiZXhwbGljaXQgbGFiZWwgY29udHJvbCIsIHRv IHN1cHBvcnQgPEJSPiJleHBsaWNpdCBsYWJlbHNldCBjb250cm9sIjogYSBuZXcgDQpzdWItb2Jq ZWN0IHdvdWxkIGJlIG5lZWRlZCB0aGF0IHdvdWxkIDxCUj5jb25zdHJhaW4gdGhlIHBvc3NpYmxl IGxhYmVscyBpbiB0aGUgDQpzY29wZSBvZiB0aGUgbGluayB0aGF0IHRoZSA8QlI+c3Vib2JqZWN0 IGFwcGxpZXMgdG8sIHVuYW1iaWd1b3VzbHkuPEJSPjxCUj5lKSAtIA0KYSBMQUJFTF9TRVQgYXMg YSB0b3AgbGV2ZWwgb2JqZWN0ICh3aXRoaW4gdGhlIHBhdGggYXR0cmlidXRlcykgPEJSPndvdWxk IGNvbnZleSANCnRoZSBpbml0aWFsIG91dGdvaW5nIExBQkVMX1NFVCBmb3IgdGhlIExTUC4gV2hl dGhlciB0aGlzIDxCUj5yZWZlcnMgdG8gdGhlIGVuZCANCnRvIGVuZCBwYXRoIG9yIGp1c3QgYSBo b3AsIHdlIGRvbid0IGtub3csIGFuZCB0aGF0J3MgPEJSPmRlcGVuZGVudCBvbiB0aGUgDQpjb250 ZXh0LjxCUj48QlI+Jmd0OyBJdCBpcyBub3QgY2xlYXJseSBzdGF0ZWQgaW4gdGhlIGRyYWZ0LCBi dXQgSSB0aGluayB0aGUgDQpMQUJFTC1TRVQgY2FuIGFwcGVhcjxCUj4mZ3Q7IGluIGEgUENSZXAg YXMgYSBQQ0VQIG9iamVjdCBsaXN0aW5nIHVzZWFibGUgbGFiZWxzIA0KZm9yIHRoZSBwYXRoIHJl dHVybmVkLjxCUj5UaGlzIGlzIGluIGxpbmUgd2l0aCB3aGF0IEkganVzdCBtZW50aW9uZWQuIFdl IHVzZWQgdG8gDQphZGQgYSBMQUJFTF9TRVQgPEJSPnRvcCBsZXZlbCBvYmplY3Qgc3VjaCBhcyB0 aGlzIGV4dGVuc2lvbiBpbiBXU09OLCBpbXBseWluZyBiKSANCmFuZCBlKSBidXQgPEJSPml0IHdh cyBub3QgY29tcGxldGVseSBzYXRpc2ZhY3RvcnkuPEJSPkl0IHdhcyBjbGVhciB0aGF0ICJVc2Fi bGUgDQpsYWJlbHMgZm9yIHRoZSBwYXRoIiBpbXBsaWVzIGxhYmVsIGNvbnRpbnVpdHkgPEJSPmNv bnN0cmFpbnQgb3Igc29tZSBvdGhlciANCnJlbGF0ZWQgY29uc3RyYWludCB0aGF0IGRvZXMgbm90 IG5lY2Vzc2FyaWx5IDxCUj5hcHBseSB0byBsb2NhbCBsYWJlbHMgYW5kIGFsbCANCnN3Y2FwIHRo YXQgdGhlIFBDRVAgZXh0ZW5zaW9ucyBmb3IgR01QTFMgPEJSPnNob3VsZCBjb3Zlci4mbmJzcDsg SW4gb3RoZXIgd29yZHMsIA0KYSBfUGF0aF8gTEFCRUxfU0VUIGRvZXMgbm90IG1ha2Ugc2Vuc2Ug aWYgPEJSPmxhYmVscyBjYW4gY2hhbmdlLiBJZiB5b3UgY29uc2lkZXIgDQphbGwgc3dpdGNoaW5n IGNhcGFiaWxpdGllcyA8QlI+Z2VuZXJpY2FsbHksIHdoYXQgd291bGQgYSBMQUJFTF9TRVQgbWVh biBpbiBhIA0KcmVzcG9uc2Ugd2l0aGluIGEgUENSZXA/IDxCUj50aGUgc2V0IG9mIHVzYWJsZSBs YWJlbHMgZm9yIHRoZSAiZmlyc3QgaG9wIj8sIGZvciANCnRoZSAidHJhbnNwYXJlbnQgPEJSPnNl Z21lbnQiPywgZm9yIHRoZSAiZW5kIHRvIGVuZCBwYXRoIj88QlI+PEJSPkhvd2V2ZXIsIGZvciAN Cm1heGltdW0gZmxleGliaWxpdHkgd2Ugd291bGQgbGlrZSB0byBiZSBhYmxlIHRvIGNvbnN0cmFp biA8QlI+YW5kIGNvbnZleSANCmluZm9ybWF0aW9uIGFib3V0IHJlc291cmNlcyBmb3IgY2FzZXMg c3VjaCBhcyBXU09OLiBIb3cgZG8gPEJSPnlvdSBleHRlbmQgUENFUCANCnRvIHN1cHBvcnQgdGhl IHVzZSBjYXNlcyBvZiBXU09OIC8gTFNDIHdoaWxlIHJlbWFpbmluZyA8QlI+Z2VuZXJpYyBmb3Ig c2F5LCBQU0MgDQpvciBNUExTLVRQPyB0aGF0J3Mgd2hhdCB3ZSB3b3VsZCBsaWtlIHRvIGNvdmVy IHdpdGggPEJSPnRoZSANCmRyYWZ0LjxCUj48QlI+PEJSPlRoYW5rIHlvdSBmb3IgeW91ciBjb21t ZW50cyBjbGVhcmx5IGhpZ2hsaWdodGluZyB0aGF0IG1vcmUgDQp3b3JrIGlzIDxCUj5uZWVkZWQg aW4gdGhpcyBhcmVhIDopPEJSPjxCUj5Db3JyZWN0aW9ucyBhbmQgY29tbWVudHMgbW9yZSB0aGFu IA0Kd2VsY29tZS48QlI+PEJSPjxCUj5CZXN0IHJlZ2FyZHMsPEJSPjxCUj5SYW1vbjxCUj48QlI+ PEJSPjxCUj4tLSA8QlI+UmFtb24gDQpDYXNlbGxhcywgUGguRC48QlI+UmVzZWFyY2ggQXNzb2Np YXRlIC0gT3B0aWNhbCBOZXR3b3JraW5nIEFyZWEgLS0gPC9GT05UPjxBIA0KaHJlZj0iaHR0cDov L3dpa2lvbmEuY3R0Yy5lcyI+PEZPTlQgZmFjZT1DYWxpYnJpIA0KY29sb3I9IzAwMDAwMD5odHRw Oi8vd2lraW9uYS5jdHRjLmVzPC9GT05UPjwvQT48QlI+PEZPTlQgZmFjZT1DYWxpYnJpPkNUVEMg LSANCkNlbnRyZSBUZWNub2zyZ2ljIGRlIFRlbGVjb211bmljYWNpb25zIGRlIENhdGFsdW55YSwg UE1UIEVkIEI0PEJSPkF2LiBDYXJsIA0KRnJpZWRyaWNoIEdhdXNzIDcgMDg4NjAgQ2FzdGVsbGRl ZmVscyAoQmFyY2Vsb25hKSAtIFNwYWluPEJSPlRlbC46ICszNCA5MyA2NDUgMjkgDQoxNiAtLSBG YXguICszNCA5MyA2NDUgMjkgDQowMTxCUj48QlI+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188QlI+UGNlIG1haWxpbmcgDQpsaXN0PEJSPjwvRk9OVD48QSBo cmVmPSJtYWlsdG86UGNlQGlldGYub3JnIj48Rk9OVCBmYWNlPUNhbGlicmkgDQpjb2xvcj0jMDAw MDAwPlBjZUBpZXRmLm9yZzwvRk9OVD48L0E+PEJSPjxBIA0KaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wY2UiPjxGT05UIGZhY2U9Q2FsaWJyaSANCmNvbG9yPSMw MDAwMDA+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wY2U8L0ZPTlQ+PC9B PjxCUj48L0JPRFk+PC9IVE1MPg0K --Boundary_(ID_CJTQb5Iqd1mk7gaIQPO01Q)-- From Adrian.Farrel@huawei.com Mon Jan 31 04:46:19 2011 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEC9B3A6BEC; Mon, 31 Jan 2011 04:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.218 X-Spam-Level: X-Spam-Status: No, score=-103.218 tagged_above=-999 required=5 tests=[AWL=-1.418, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s71+ngA3MBkK; Mon, 31 Jan 2011 04:46:18 -0800 (PST) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 0737B3A6BF0; Mon, 31 Jan 2011 04:46:18 -0800 (PST) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LFW002UP0YJHX@usaga01-in.huawei.com>; Mon, 31 Jan 2011 04:49:32 -0800 (PST) Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LFW00GBZ0YHV7@usaga01-in.huawei.com>; Mon, 31 Jan 2011 04:49:31 -0800 (PST) Date: Mon, 31 Jan 2011 12:49:30 +0000 From: Adrian Farrel To: statements@ietf.org, greg.jones@itu.int Message-id: <053201cbc145$4ec727d0$ec557770$@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Outlook 14.0 Content-type: text/plain; charset=us-ascii Content-language: en-gb Content-transfer-encoding: 7BIT Thread-index: AcvBRUUBwyLJKIqtQ8+sYanHj6pLeA== Cc: koike.yoshinori@lab.ntt.co.jp, itu-t-liaisons@iab.org, pce@ietf.org, 'CCAMP' , mpls@ietf.org Subject: [Pce] Liaison to SG15 : Comments on SG15 OTNT standardization work plan X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian.Farrel@huawei.com List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 12:46:19 -0000 From: IETF To: ITU-T SG15 (Attention Q3/15) Point of Contact: Greg Jones (greg.jones@itu.int) Cc: Yoshinori Koike (koike.yoshinori@lab.ntt.co.jp) CCAMP Working Group (ccamp@ietf.org) PCE Working Group (pce@ietf.org) MPLS Working Group (mpls@ietf.org) IETF ITU-T Liaisons (itu-t-liaisons@iab.org) Reply To: Adrian Farrel X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B79563A6B34 for ; Mon, 31 Jan 2011 05:20:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBvf4-MVtuDl for ; Mon, 31 Jan 2011 05:20:43 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id D4F4A3A6BFE for ; Mon, 31 Jan 2011 05:20:42 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p0VDNrkm014709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 31 Jan 2011 14:23:53 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p0VDNqi8005960; Mon, 31 Jan 2011 14:23:52 +0100 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Jan 2011 14:23:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 31 Jan 2011 14:23:51 +0100 Message-ID: In-Reply-To: <4D418532.1010804@cttc.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] LABEL-SET as object and TLV in pcep-extensions-01 Thread-Index: Acu+MMXTpRDz8vHYTbOPv990qqKgegDEM4LA References: <4D418532.1010804@cttc.es> From: "Margaria, Cyril (NSN - DE/Munich)" To: "ext Ramon Casellas" , X-OriginalArrivalTime: 31 Jan 2011 13:23:52.0870 (UTC) FILETIME=[1AA12460:01CBC14A] Subject: Re: [Pce] LABEL-SET as object and TLV in pcep-extensions-01 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 13:20:44 -0000 Hi all,=20 I also agree that works is needed to clarify the Label set object scope and procedure,=20 Please see inline for some of my comments > -----Original Message----- > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of > ext Ramon Casellas > Sent: Thursday, January 27, 2011 3:46 PM > To: pce@ietf.org > Subject: Re: [Pce] LABEL-SET as object and TLV in pcep-extensions-01 >=20 > Dear Christian, PCErs >=20 > Thank you for your comments, this is indeed one of the open issues in > the draft. Please see inline for some of my views. >=20 >=20 >=20 > On 26/01/2011 20:46, Christian.Kaas-Petersen@tieto.com wrote: >=20 > > Reading the draft-ietf-pce-gmpls-pcep-extensions-01 document, the > definition > > and use of LABEL-REQUEST, LABEL-SET, and SUGGESTED-LABEL-SET need > further > > clarification. >=20 >=20 > We have had some discussions about this in the past, and I am afraid we > still don't have a consensus. The main problem with the LABEL_SET > object > (and to some extent with SUGGESTED_LABEL and UPSTREAM_LABEL) is that > the > semantics are slightly different depending of the context. Let me > explain, and apologies if this is well-known, > it is clear that in MPLS-TE (or GMPLS PSC, etc) labels are, by > definition, local to a link between two nodes. A LABEL_SET defines > which > labels are usable in that scope. However, when deploying GMPLS for WSON > (and other swcap such as PBB-TE) there are technological constraints > such as the Wavelength Continuity Constraint. With this in mind, the > LABEL_SET in WSON has been "abused" to imply which labels are usable > end > to end. (e.g. the LABELSET includes which labels are usable and it is > trimmed by nodes along the path, or re-expanded when a regenerator / > converter is used. Lack of LABELSET is typically assumed as a failure > to > find continuous wavelengths. However, in MPLS lack of LABEL_SET implies > that any label is ok). I do not fully agree here, I do notsee WSON abusing the LABEL_SET:=20 In WSON the label set is ustill pdated by each node along the path=20 to reflect the link-local label that can be allocated by a node. Label switching constraint do apply, but as you stated 3R allow to=20 have a different label set. >=20 > Since the GMPLS extensions need to apply at all layers, we have > seemingly opposite concepts: on the one hand, MPLS defines a label as > local to a link representing a FEC, WSON a label is implicitly a > wavelength, end-to-end within a transparent segment without converters. > Things can get much worse :) when considering translucent networks > where > the label has to remain constant along one or more transparent > segments. > If we assume that, regardless of how it is encoded (TLV, top level > object, etc) , in a PCEP request the LABEL_SET is supposed to convey > constraints in the path computation, and in a PCEP response it is > supposed to convey attributes, without knowledge of the swcap the > request applies to, or with extra assumptions, it is not possible to > know what the constraints apply to. >=20 I do agree, The LABEL_SET in the PCReq restricts the label to be=20 allocated (if any) by the PCE along the path This is more restrictive=20 than the LABEL_SET seen in signaling, it make sense as a kind of policy=20 input . For instance in WSON context using specific wavelength range=20 because of optical/modulation format quality policy, or because of=20 network-wide label allocation policy. The presence of the LABE_SET should not imply that the label has to be=20 the same end-to-end. The indication that the route should use a single=20 label end-to-end should use another attribute, which is open for discussion. >=20 > > LABEL-SET as an object is specified in section 2.5, but half-way > > through the section, LABEL-SET is referred to as a TLV appearing in > the > > ERO object (and so LABEL-SET is a TLV of an RSVP object). Further >=20 > In my opinion, this is indeed a problem with the draft in its current > form, but I haven't yet reported to Editors about this. I am unsure how > a variable sized object such as the ERO can include TLVs. At what point > does the parser stop parsing subobjects to start parsing TLVs?, the > first TLV would be wrongly parsed as a (possibly unknown) sub-object. > The intended use as I suggested then was as RSVP ERO sub-object, not as > TLV. >=20 The text does not describe the LABEL-SET as ERO sub-object, it specify : "Any label included in the ERO object on the response must comply with the restrictions stated in the LABEL SET,". This apply to the labels in ERO. I think this could be rephrased to avoid reader confusion. Having the LABEL-SET as ERO sub-object should be discussed in the context of ccamp WG. > > It is not clearly stated in the draft, but I think the LABEL-SET can > appear > > in a PCRep as a PCEP object listing useable labels for the path > returned. > This is in line with what I just mentioned. We used to add a LABEL_SET > top level object such as this extension in WSON, implying b) and e) but > it was not completely satisfactory. > It was clear that "Usable labels for the path" implies label continuity > constraint or some other related constraint that does not necessarily > apply to local labels and all swcap that the PCEP extensions for GMPLS > should cover. In other words, a _Path_ LABEL_SET does not make sense > if > labels can change. If you consider all switching capabilities > generically, what would a LABEL_SET mean in a response within a PCRep? > the set of usable labels for the "first hop"?, for the "transparent > segment"?, for the "end to end path"? > The draft should be revised to indicate that the LABEL-SET is allowed in the respons,=20 That each label-set TLV should be scoped by the corresponding label request and is=20 significant for the first HOP of the layer. =20 Best regards,=20 Cyril From ramon.casellas@cttc.es Mon Jan 31 06:03:30 2011 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E66C63A6BED for ; Mon, 31 Jan 2011 06:03:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVOiNTyTrM6r for ; Mon, 31 Jan 2011 06:03:30 -0800 (PST) Received: from Scorpius.cttc.es (scorpius.cttc.es [84.88.62.197]) by core3.amsl.com (Postfix) with ESMTP id 8C7B53A6B32 for ; Mon, 31 Jan 2011 06:03:29 -0800 (PST) Received: from castor (postfix@castor.cttc.es [84.88.62.196]) by Scorpius.cttc.es (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p0VE6Nqf008372; Mon, 31 Jan 2011 15:06:28 +0100 Received: from [84.88.61.50] (pcrcasellas.cttc.es [84.88.61.50]) by castor (Postfix) with ESMTP id 3B63A2FC27B; Mon, 31 Jan 2011 15:06:30 +0100 (CET) Message-ID: <4D46C248.1010903@cttc.es> Date: Mon, 31 Jan 2011 15:08:08 +0100 From: Ramon Casellas Organization: CTTC User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.14) Gecko/20110123 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: "Margaria, Cyril (NSN - DE/Munich)" References: <4D418532.1010804@cttc.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (castor); Mon, 31 Jan 2011 15:06:30 +0100 (CET) X-Scanned-By: MIMEDefang 2.67 on 84.88.62.197 Cc: pce@ietf.org Subject: Re: [Pce] LABEL-SET as object and TLV in pcep-extensions-01 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 14:03:31 -0000 Cyril, all Please see inline On 31/01/2011 14:23, Margaria, Cyril (NSN - DE/Munich) wrote: > I do not fully agree here, I do notsee WSON abusing the LABEL_SET: > In WSON the label set is ustill pdated by each node along the path > to reflect the link-local label that can be allocated by a node. > Label switching constraint do apply, but as you stated 3R allow to > have a different label set. > Probably I should have written it better :) : "abused" in the sense that, although perfectly valid, is used (and almost mandatory) to obtain the end-to-end labels, although some may (questionably/arguably) object that it was not the initial spirit of the LABEL_SET given its local nature in "MPLS-TE". In any case, we are in line in this aspect, it was basically "background". > > The presence of the LABE_SET should not imply that the label has to be > the same end-to-end. The indication that the route should use a single > label end-to-end should use another attribute, which is open for > discussion. > Good point. A LABEL_SET within a request applies to all links along the path, and not necessarily assume end-to-end uniqueness (WCC). So a LABEL_SET within a request is a constraint that applies to all links of all the paths of the corresponding response, right? > > The text does not describe the LABEL-SET as ERO sub-object, it specify : > "Any label included in the ERO object on the response must comply with > therestrictions stated in the LABEL SET,". No it does not :) ... I replied to the original question mentioning the TLV within an ERO (Christian's comment was "What is stated is that the LABEL-SET can appear as a TLV being part of the ERO returned"). I have not actually found that text in the draft (?) but I meant that is IMHO wrong (not being able to see the boundary between subobjects and TLVs while parsing) , and that I understand that the way to have the "TLV" within the ERO would be by means of a new sub-object. Such "LABEL_SET sub-object" was my own suggestion (not currently in draft). . > Having the LABEL-SET as ERO sub-object should be discussed in the > context of ccamp WG. > fully agree Thanks R. From Christian.Kaas-Petersen@tieto.com Mon Jan 31 06:15:00 2011 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BBB43A6C07 for ; Mon, 31 Jan 2011 06:15:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Uqt6C0dUdDS for ; Mon, 31 Jan 2011 06:14:59 -0800 (PST) Received: from ebb06.tieto.com (ebb06.tieto.com [131.207.168.38]) by core3.amsl.com (Postfix) with ESMTP id 39F0C3A6C05 for ; Mon, 31 Jan 2011 06:14:59 -0800 (PST) X-AuditID: 83cfa826-b7b3cae000000161-5b-4d46c4a4d9ff Received: from FIVLA-EXHUB02.eu.tieto.com ( [131.207.136.42]) by ebb06.tieto.com (SMTP Mailer) with SMTP id 59.9F.00353.4A4C64D4; Mon, 31 Jan 2011 16:18:12 +0200 (EET) Received: from EXMB02.eu.tieto.com ([169.254.1.182]) by FIVLA-EXHUB02.eu.tieto.com ([131.207.136.42]) with mapi; Mon, 31 Jan 2011 16:18:12 +0200 From: To: Date: Mon, 31 Jan 2011 16:15:15 +0200 Thread-Topic: [Pce] LABEL-SET as object and TLV in pcep-extensions-01 Thread-Index: AcvBUBwP1/sB83i+RviLy+dqiBmE+gAASvuZ Message-ID: References: <4D418532.1010804@cttc.es> , <4D46C248.1010903@cttc.es> In-Reply-To: <4D46C248.1010903@cttc.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [Pce] LABEL-SET as object and TLV in pcep-extensions-01 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 14:15:00 -0000 Just for clarification: I misinterpreted the sentence in sec 2.5 "Any label= included ..." to mean the LABEL-SET was included in the ERO. Sorry for the confusion. Christian > > The text does not describe the LABEL-SET as ERO sub-object, it specify : > "Any label included in the ERO object on the response must comply with > therestrictions stated in the LABEL SET,". No it does not :) ... I replied to the original question mentioning the TLV within an ERO (Christian's comment was "What is stated is that the LABEL-SET can appear as a TLV being part of the ERO returned"). I have not actually found that text in the draft (?)=