From nobody Mon Oct 5 03:27:10 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8625E1A1AE8 for ; Mon, 5 Oct 2015 03:27:08 -0700 (PDT) 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=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, 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 cWYwsDPgxsZ1 for ; Mon, 5 Oct 2015 03:27:07 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B22631A1AE6 for ; Mon, 5 Oct 2015 03:27:06 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 0FECE22C07D for ; Mon, 5 Oct 2015 12:27:05 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.31]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id E922F35C045 for ; Mon, 5 Oct 2015 12:27:04 +0200 (CEST) Received: from [10.193.71.204] (10.168.234.5) by OPEXCLILM22.corporate.adroot.infra.ftgroup (10.114.31.31) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 5 Oct 2015 12:27:04 +0200 To: "pce@ietf.org" From: Organization: Orange Message-ID: <8450_1444040825_56125078_8450_1292_1_56125078.50803@orange.com> Date: Mon, 5 Oct 2015 12:27:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.168.234.5] X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.9.8.131516 Archived-At: Subject: [Pce] Building the PCE Agenda for IETF 95 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: 'JP Vasseur' , Julien Meuric , Daniel King List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 10:27:08 -0000 Dear PCE WG, The IETF preliminary agenda is available (https://datatracker.ietf.org/meeting/94/agenda.html). The PCE session is _tentatively_ scheduled on Monday from 3:20 to 4:50 pm. Supposing you have issues that _really_ require a slot to progress, please send a request to the chairs and secretary, including: - the topic to discuss, - the expected duration, - the name of the presenter, - the rationale for requesting some face to face time, as opposed to using the mailing list, i.e., the output you expect from your slot. Best regards, JP & Julien _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From nobody Tue Oct 6 17:13:12 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD8A1B2C36 for ; Tue, 6 Oct 2015 17:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] 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 gJAEVYAov8XH for ; Tue, 6 Oct 2015 17:13:10 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47B231B2C31 for ; Tue, 6 Oct 2015 17:13:10 -0700 (PDT) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id t9709j3g036925 for ; Tue, 6 Oct 2015 20:13:10 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049297.ppops.net-00191d01. with ESMTP id 1xabr0qxvt-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 06 Oct 2015 20:13:09 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t970D84b005055 for ; Tue, 6 Oct 2015 20:13:08 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t970D3Ni005015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 6 Oct 2015 20:13:03 -0400 Received: from MISOUT7MSGHUBAH.ITServices.sbc.com (MISOUT7MSGHUBAH.itservices.sbc.com [130.9.129.152]) by mlpi409.sfdc.sbc.com (RSA Interceptor) for ; Wed, 7 Oct 2015 00:12:50 GMT Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.138]) by MISOUT7MSGHUBAH.ITServices.sbc.com ([130.9.129.152]) with mapi id 14.03.0248.002; Tue, 6 Oct 2015 20:12:49 -0400 From: "BRUNGARD, DEBORAH A" To: "pce@ietf.org" Thread-Topic: New Co-Chair for PCE Thread-Index: AdEAlOYsUi+2kzQVRYG1wrbeEgyejA== Date: Wed, 7 Oct 2015 00:12:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.90.76] Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C85273EA5AMISOUT7MSGUSRDE_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-10-07_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1510070001 Archived-At: Subject: [Pce] New Co-Chair for PCE X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 00:13:11 -0000 --_000_F64C10EAA68C8044B33656FA214632C85273EA5AMISOUT7MSGUSRDE_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Please welcome Jon Hardwick as a 3rd co-chair for PCE! Thanks, Deborah --_000_F64C10EAA68C8044B33656FA214632C85273EA5AMISOUT7MSGUSRDE_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
Please welcome Jon Hardwick as a 3rd co-chair for PCE!
 
Thanks,
Deborah
 
 
 --_000_F64C10EAA68C8044B33656FA214632C85273EA5AMISOUT7MSGUSRDE_-- From nobody Tue Oct 6 21:25:55 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91C9C1A88F2; Tue, 6 Oct 2015 21:25:53 -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 uKElXuZo4_sd; Tue, 6 Oct 2015 21:25:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 50AF71A88D2; Tue, 6 Oct 2015 21:25:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151007042552.13383.25553.idtracker@ietfa.amsl.com> Date: Tue, 06 Oct 2015 21:25:52 -0700 Archived-At: Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-pcep-service-aware-08.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 04:25:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Extensions to the Path Computation Element Communication Protocol (PCEP) to compute service aware Label Switched Path (LSP). Authors : Dhruv Dhody Qin Wu Vishwas Manral Zafar Ali Kenji Kumaki Filename : draft-ietf-pce-pcep-service-aware-08.txt Pages : 26 Date : 2015-10-06 Abstract: In certain networks like financial information network (stock/ commodity trading) and enterprises using cloud based applications, Latency (delay), Latency Variation (jitter) and Packet Loss are becoming key requirements for path computation along with other constraints and metrics. These metrics are associated with the Service Level Agreement (SLA) between customers and service providers. The Link Bandwidth Utilization (the total bandwidth of a link in current use for the forwarding) is another important factor to consider during path computation. IGP Traffic Engineering (TE) Metric extensions describes mechanisms with which network performance information is distributed via OSPF and IS-IS respectively. The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. This document describes the extension to PCEP to carry Latency, Latency Variation, Packet Loss, and Link Bandwidth Utilization as constraints for end to end path computation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-service-aware/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-pce-pcep-service-aware-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-service-aware-08 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 Tue Oct 6 21:38:25 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D24041A8919 for ; Tue, 6 Oct 2015 21:38:23 -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 M9_YA0_Q-G5t for ; Tue, 6 Oct 2015 21:38:20 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C1AF1A890E for ; Tue, 6 Oct 2015 21:38:20 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYL36804; Wed, 07 Oct 2015 04:38:18 +0000 (GMT) Received: from BLREML406-HUB.china.huawei.com (10.20.4.43) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 7 Oct 2015 05:38:17 +0100 Received: from BLREML509-MBX.china.huawei.com ([169.254.7.243]) by BLREML406-HUB.china.huawei.com ([10.20.4.43]) with mapi id 14.03.0235.001; Wed, 7 Oct 2015 10:08:12 +0530 From: Dhruv Dhody To: "pce@ietf.org" Thread-Topic: [Pce] I-D Action: draft-ietf-pce-pcep-service-aware-08.txt Thread-Index: AQHRALhGk5d3+Pv2oECUkkVYilI5o55fb75g Date: Wed, 7 Oct 2015 04:38:12 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B8C41DE68@BLREML509-MBX.china.huawei.com> References: <20151007042552.13383.25553.idtracker@ietfa.amsl.com> In-Reply-To: <20151007042552.13383.25553.idtracker@ietfa.amsl.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.244.252] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Pce] I-D Action: draft-ietf-pce-pcep-service-aware-08.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 04:38:24 -0000 Hi WG,=20 Following changes are made in this version -=20 https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pce-pcep-service-aware-08 - Metric Value Encoding aligned to float (as described earlier on the maili= ng list) - Added reference to the TEAS draft (draft-ietf-teas-te-express-path) (hmm,= not sure how I missed that earlier) - Clarifications in the IANA section Status: Ready for WG LC Regards, Dhruv (on behalf of co-authors/contributors)=20 > -----Original Message----- > From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: 07 October 2015 09:56 > To: i-d-announce@ietf.org > Cc: pce@ietf.org > Subject: [Pce] I-D Action: draft-ietf-pce-pcep-service-aware-08.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Path Computation Element Working Group = of > the IETF. >=20 > Title : Extensions to the Path Computation Element > Communication Protocol (PCEP) to compute service aware Label Switched Pat= h > (LSP). > Authors : Dhruv Dhody > Qin Wu > Vishwas Manral > Zafar Ali > Kenji Kumaki > Filename : draft-ietf-pce-pcep-service-aware-08.txt > Pages : 26 > Date : 2015-10-06 >=20 > Abstract: > In certain networks like financial information network (stock/ > commodity trading) and enterprises using cloud based applications, > Latency (delay), Latency Variation (jitter) and Packet Loss are > becoming key requirements for path computation along with other > constraints and metrics. These metrics are associated with the > Service Level Agreement (SLA) between customers and service > providers. The Link Bandwidth Utilization (the total bandwidth of a > link in current use for the forwarding) is another important factor > to consider during path computation. >=20 > IGP Traffic Engineering (TE) Metric extensions describes mechanisms > with which network performance information is distributed via OSPF > and IS-IS respectively. The Path Computation Element Communication > Protocol (PCEP) provides mechanisms for Path Computation Elements > (PCEs) to perform path computations in response to Path Computation > Clients (PCCs) requests. This document describes the extension to > PCEP to carry Latency, Latency Variation, Packet Loss, and Link > Bandwidth Utilization as constraints for end to end path computation. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-service-aware/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-pce-pcep-service-aware-08 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pce-pcep-service-aware-08 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From nobody Tue Oct 6 21:48:23 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAC451A892B; Tue, 6 Oct 2015 21:48:21 -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 9aFkTdM4vPKc; Tue, 6 Oct 2015 21:48:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B0DD81A891A; Tue, 6 Oct 2015 21:48:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151007044820.28727.36579.idtracker@ietfa.amsl.com> Date: Tue, 06 Oct 2015 21:48:20 -0700 Archived-At: Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-stateful-sync-optimizations-03.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 04:48:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE Authors : Edward Crabbe Ina Minei Jan Medved Robert Varga Xian Zhang Dhruv Dhody Filename : draft-ietf-pce-stateful-sync-optimizations-03.txt Pages : 23 Date : 2015-10-06 Abstract: A stateful Path Computation Element (PCE) has access to not only the information disseminated by the network's Interior Gateway Protocol (IGP), but also the set of active paths and their reserved resources for its computation. The additional Label Switched Path (LSP) state information allows the PCE to compute constrained paths while considering individual LSPs and their interactions. This requires a reliable state synchronization mechanism between the PCE and the network, PCE and path computation clients (PCCs), and between cooperating PCEs. The basic mechanism for state synchronization is part of the stateful PCE specification. This draft presents motivations for optimizations to the base state synchronization procedure and specifies the required Path Computation Element Communication Protocol (PCEP) extensions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-sync-optimizations/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-pce-stateful-sync-optimizations-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-stateful-sync-optimizations-03 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 Tue Oct 6 21:58:00 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3129B1A891E; Tue, 6 Oct 2015 21:57:59 -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 n9_9dMuTN_yj; Tue, 6 Oct 2015 21:57:57 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 361D41A893B; Tue, 6 Oct 2015 21:57:56 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CCD83766; Wed, 07 Oct 2015 04:57:54 +0000 (GMT) Received: from BLREML405-HUB.china.huawei.com (10.20.4.41) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 7 Oct 2015 05:57:53 +0100 Received: from BLREML509-MBX.china.huawei.com ([169.254.7.243]) by BLREML405-HUB.china.huawei.com ([10.20.4.41]) with mapi id 14.03.0235.001; Wed, 7 Oct 2015 10:27:50 +0530 From: Dhruv Dhody To: "'JP Vasseur'" , "julien.meuric@orange.com" , Jonathan Hardwick Thread-Topic: [Pce] I-D Action: draft-ietf-pce-stateful-sync-optimizations-03.txt Thread-Index: AQHRALtsHkfyFxus3kWagOFLWr/SwJ5fda1w Date: Wed, 7 Oct 2015 04:57:50 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B8C41DE94@BLREML509-MBX.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.244.252] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "pce@ietf.org" , "draft-ietf-pce-stateful-sync-optimizations@ietf.org" Subject: [Pce] FW: I-D Action: draft-ietf-pce-stateful-sync-optimizations-03.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 04:57:59 -0000 Hi Chairs,=20 This version refreshes the expired draft (no changes made in the content).= =20 The WG LC [1] was issued last year on -01. The -02 update [2] handled all t= he comments made during the last call.=20 [1] https://mailarchive.ietf.org/arch/msg/pce/PcJ5gBy2uqWAmilDKMqVjQyl6Ss [2] https://mailarchive.ietf.org/arch/msg/pce/MYVoNouTERYgfRlGPxhcGycKoy0 Regards, Dhruv (on behalf of co-authors/contributors) > -----Original Message----- > From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: 07 October 2015 10:18 > To: i-d-announce@ietf.org > Cc: pce@ietf.org > Subject: [Pce] I-D Action: draft-ietf-pce-stateful-sync-optimizations-03.= txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Path Computation Element Working Group = of > the IETF. >=20 > Title : Optimizations of Label Switched Path State > Synchronization Procedures for a Stateful PCE > Authors : Edward Crabbe > Ina Minei > Jan Medved > Robert Varga > Xian Zhang > Dhruv Dhody > Filename : draft-ietf-pce-stateful-sync-optimizations-03.txt > Pages : 23 > Date : 2015-10-06 >=20 > Abstract: > A stateful Path Computation Element (PCE) has access to not only the > information disseminated by the network's Interior Gateway Protocol > (IGP), but also the set of active paths and their reserved resources > for its computation. The additional Label Switched Path (LSP) state > information allows the PCE to compute constrained paths while > considering individual LSPs and their interactions. This requires a > reliable state synchronization mechanism between the PCE and the > network, PCE and path computation clients (PCCs), and between > cooperating PCEs. The basic mechanism for state synchronization is > part of the stateful PCE specification. This draft presents > motivations for optimizations to the base state synchronization > procedure and specifies the required Path Computation Element > Communication Protocol (PCEP) extensions. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-sync-optimizatio= ns/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-pce-stateful-sync-optimizations-03 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pce-stateful-sync- > optimizations-03 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From nobody Wed Oct 7 09:24:06 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6BC1ACDE1 for ; Wed, 7 Oct 2015 09:23:54 -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 aF2XH4EOL6ab for ; Wed, 7 Oct 2015 09:23:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 633C11ACDE6 for ; Wed, 7 Oct 2015 09:23:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151007162352.18418.45629.idtracker@ietfa.amsl.com> Date: Wed, 07 Oct 2015 09:23:52 -0700 From: IETF Secretariat Archived-At: Subject: [Pce] Milestones changed for pce WG X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 16:23:54 -0000 Changed milestone "Submit the PCEP MIB to the IESG to be considered as a Proposed Standard", resolved as "Done". URL: https://datatracker.ietf.org/wg/pce/charter/ From nobody Thu Oct 8 09:44:42 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2030F1A914A; Thu, 8 Oct 2015 09:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 53CNl4iq6nGd; Thu, 8 Oct 2015 09:44:36 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF1171A911E; Thu, 8 Oct 2015 09:44:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11922; q=dns/txt; s=iport; t=1444322676; x=1445532276; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=8EcTOpydKjyg8mgdhXNVDRxEpcmYITtXu5ilnFMCv4M=; b=WnyUOVWIRYcufz4iwEVELrHEufdb3A3jloTSqggYb7QdXmDt7CpAHKfC fEd4Tc89XifCi0A8iNbYh8Qyfu+isyOZ+JxU+cBB6Ntl1+q1K6EWpCbnb jzJxHnUHrq+I9uqfJhWWrK8e8HU8S2n/0wo9yo7lclQBO5FrBBsFbmVPi E=; X-Files: smime.p7s : 3862 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CHAwB7nBZW/4QNJK1eglpNVG4GvUIOgVoXAQmCcoIKNUoCgUw4FAEBAQEBAQGBCoQmAQEBAwEBAQEgSwsFCwIBCBgnAwICAiULFBECBA4FDgyIDAgNrwKUIAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEhnOCEIJuhQkEB4JpMYEUBZYKAYJMgWGIaoFYljODbgEfAUOEAnGGZoEGAQEB X-IronPort-AV: E=Sophos;i="5.17,655,1437436800"; d="p7s'?scan'208,217";a="35754362" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-6.cisco.com with ESMTP; 08 Oct 2015 16:44:35 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t98GiZ6K018523 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 8 Oct 2015 16:44:35 GMT Received: from xch-rcd-009.cisco.com (173.37.102.19) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 8 Oct 2015 11:44:34 -0500 Received: from xch-rcd-009.cisco.com ([173.37.102.19]) by XCH-RCD-009.cisco.com ([173.37.102.19]) with mapi id 15.00.1104.000; Thu, 8 Oct 2015 11:44:34 -0500 From: "JP Vasseur (jvasseur)" To: "BRUNGARD, DEBORAH A" Thread-Topic: [Detnet] detnet is approved as a new Working Group Thread-Index: AQHRAeicydnHAZHyhEaMZUyUv8xV/g== Date: Thu, 8 Oct 2015 16:44:34 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.61.194] Content-Type: multipart/signed; boundary="Apple-Mail=_8D152582-56D3-4571-B073-3DA5E7768084"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Cc: "detnet@ietf.org" , "pce@ietf.org" Subject: Re: [Pce] [Detnet] detnet is approved as a new Working Group X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2015 16:44:41 -0000 --Apple-Mail=_8D152582-56D3-4571-B073-3DA5E7768084 Content-Type: multipart/alternative; boundary="Apple-Mail=_5ACF8287-4074-4928-8F82-BF116751D7CB" --Apple-Mail=_5ACF8287-4074-4928-8F82-BF116751D7CB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear AD, Delighted to work with Detnet ! We will undoubtedly have interactions = related to path computations architectures, protocols, ... Thanks, JP. > On Oct 1, 2015, at 12:52 PM, BRUNGARD, DEBORAH A = wrote: >=20 > Hi detnet fans, > =20 > Great news - on today=E2=80=99s IESG call, we got approval for detnet = as a new Working Group. > =20 > I have a few nits to fix on the charter and then you will see the = formal announcement. > =20 > Your new WG Chairs will be familiar faces as they were your BoF = Chairs: Lou Berger and Pat Thaler. Thanks Lou and Pat for taking on this = responsibility! > =20 > You are on the schedule to meet at the next IETF. > =20 > Wish you success- > Deborah > =20 > =20 > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet = --Apple-Mail=_5ACF8287-4074-4928-8F82-BF116751D7CB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear AD,

Delighted to work with Detnet ! We will undoubtedly have = interactions related to path computations architectures, protocols, = ...

Thanks,

JP.

On = Oct 1, 2015, at 12:52 PM, BRUNGARD, DEBORAH A <db3546@att.com> = wrote:

Hi detnet fans,
 
Great news - on today=E2=80=99s = IESG call, we got approval for detnet as a new Working Group.
 
I have a few nits to fix on the = charter and then you will see the formal announcement.
 
Your new WG Chairs will be = familiar faces as they were your BoF Chairs: Lou Berger and Pat Thaler. = Thanks Lou and Pat for taking on this responsibility!
 
You are on the schedule to meet = at the next IETF.
 
Wish = you success-
Deborah
 
 
_______________________________________________
detnet mailing list
detnet@ietf.org
https://www.ietf.org/mailman/listinfo/detnet

= --Apple-Mail=_5ACF8287-4074-4928-8F82-BF116751D7CB-- --Apple-Mail=_8D152582-56D3-4571-B073-3DA5E7768084 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHjCCBTAw ggQYoAMCAQICEQDVs65XZh59t2IXVyBjHIr6MA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNDExMjQwMDAwMDBaFw0xNTExMjQyMzU5NTla MCMxITAfBgkqhkiG9w0BCQEWEmp2YXNzZXVyQGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMnOoDwgfyigTrGJQkL+oeRZ/jELtw6kVKr5mYh1odj7ez8u8cPbZVsgvuLu UKGl6qjUjPd0kYgUR49lQynBhdY98L6MGHLTCtp6GIn4Ux3Kfk5lZvU/hgDveiDYbQNkYvjL2B1m vrr+lM/0E1b1qLNxRhePGy3GT0pSgi3wKfhEmUwMXayHZ3Vly0ugYH4idrBPcsBL9WNBDi7BYVCE ntzv2QVuB6fLuddurd+HAvJs7HT7NFwkS8O3sGhAmAz94yXsml9XtJEePaI0EzgXueK3bYUnYvPF rg44+v20UlVaY1+6vQYecBOXjxlOsprD+YKtGqaKew/Q7LMl4q3B070CAwEAAaOCAegwggHkMB8G A1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBS6q/3WoBmfGTrzbfUh6da/ TnTZwDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYL KwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEB MCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoGA1UdHwRTMFEw T6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEFBQcwAoZJaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMB0GA1Ud EQQWMBSBEmp2YXNzZXVyQGNpc2NvLmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAVU6J5QAmIVAp5ErX b2t86SQefahFFBTZOdnkl//UAqsyDrxaLBLGylM4Ve8sm1UwXO645rwT+UGPBYdOI6JSMAjYgDtd DUzfASU2za3L08OSrF0uaDWc2NpTNn80jGIH5CdP/IC8op6r2ee8P9vOOyFtqz57q4SIOT/qZmNR YA2XWO1mxl3kM6UVTf37lPxkJa3FBg5U8S702Cw9wyM1oUn3DUnmhf16hDdxYYaFzIaEmTQk9QRd 5xxwTcoBMaJufdhmwwoCdWW2RmWmrNUORzYkt6Fp/Lv5KjNsOK7PLuU1VnvFqOeMj1jzWi6twhJp RfAuAqj912Sj0ykTBvWtLjCCBeYwggPOoAMCAQICEGqb4Tg7/ytrnwHV2binUlYwDQYJKoZIhvcN AQEMBQAwgYUxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMSswKQYDVQQDEyJDT01PRE8g UlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTEzMDExMDAwMDAwMFoXDTI4MDEwOTIzNTk1 OVowgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNB IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAvrOeV6wodnVAFsc4A5jTxhh2IVDzJXkLTLWg0X06WD6cpzEup/Y0 dtmEatrQPTRI5Or1u6zf+bGBSyD9aH95dDSmeny1nxdlYCeXIoymMv6pQHJGNcIDpFDIMypVpVSR sivlJTRENf+RKwrB6vcfWlP8dSsE3Rfywq09N0ZfxcBa39V0wsGtkGWC+eQKiz4pBZYKjrc5NOpG 9qrxpZxyb4o4yNNwTqzaaPpGRqXB7IMjtf7tTmU2jqPMLxFNe1VXj9XB1rHvbRikw8lBoNoSWY66 nJN/VCJv5ym6Q0mdCbDKCMPybTjoNCQuelc0IAaO4nLUXk0BOSxSxt8kCvsUtQIDAQABo4IBPDCC ATgwHwYDVR0jBBgwFoAUu69+Aj36pvE8hI6t7jiY7NkyMtQwHQYDVR0OBBYEFIKvbIz4xf6WYXzo Hz0rcUhexIvAMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgw BgYEVR0gADBMBgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9S U0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDBxBggrBgEFBQcBAQRlMGMwOwYIKwYBBQUHMAKG L2h0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1JTQUFkZFRydXN0Q0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wDQYJKoZIhvcNAQEMBQADggIBAHhcsoEoNE88 7l9Wzp+XVuyPomsX9vP2SQgG1NgvNc3fQP7TcePo7EIMERoh42awGGsma65u/ITse2hKZHzT0CBx huhb6txM1n/y78e/4ZOs0j8CGpfb+SJA3GaBQ+394k+z3ZByWPQedXLL1OdK8aRINTsjk/H5Ns77 zwbjOKkDamxlpZ4TKSDMKVmU/PUWNMKSTvtlenlxBhh7ETrN543j/Q6qqgCWgWuMAXijnRglp9fy adqGOncjZjaaSOGTTFB+E2pvOUtY+hPebuPtTbq7vODqzCM6ryEhNhzf+enm0zlpXK7q332nXttN tjv7VFNYG+I31gnMrwfHM5tdhYF/8v5UY5g2xANPECTQdu9vWPoqNSGDt87b3gXb1AiGGaI06vzg kejL580ul+9hz9D0S0U4jkhJiA7EuTecP/CFtR72uYRBcunwwH3fciPjviDDAI9SnC/2aPY8ydeh zuZutLbZdRJ5PDEJM/1tyZR2niOYihZ+FCbtf3D9mB12D4ln9icgc7CwaxpNSCPt8i/GqK2HsOgk L3VYnwtx7cJUmpvVdZ4ognzgXtgtdk3ShrtOS1iAN2ZBXFiRmjVzmehoMof06r1xub+85hFQzVxZ x5/bRaTKTlL8YXLI8nAbR9HWdFqzcOoB/hxfEyIQpx9/s81rgzdEZOofSlZHynoSMYIDujCCA7YC AQEwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8g UlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEA1bOuV2Yefbdi F1cgYxyK+jAJBgUrDgMCGgUAoIIB4TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNTEwMDgxNjQ0MzJaMCMGCSqGSIb3DQEJBDEWBBT3n+WvgkcTu4CBk4T+erCko94q XzCBvgYJKwYBBAGCNxAEMYGwMIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9 MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFp bCBDQQIRANWzrldmHn23YhdXIGMcivowgcAGCyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQG EwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYD VQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANWzrldmHn23YhdXIGMcivowDQYJKoZIhvcN AQEBBQAEggEAYBhGXe0xAdK67eZypC1DhkXSAwUsZPWb5i8DHGmP5rS3ARE//E29Akk2LaKnhcCW d2hIIVefHBEH7gkT5hK6crbw5+QXt50OtNjSmeqHvSajFPE1LnCC4E3X8a/7lCxKV1P7Al4miGOk +yNmKpEgujAOWZz2NgBhspypnqdQ3642u/ijitqjxaEQe/cV82DMtQ5juO8eFtKWe39GR0vUc3zC ZLvtWqvimfopfEBH1tfjNoC0Srh4aSHir6jC87rU3GnxrwUuQhdJO5ZdMDJIcUNg3zKJFiRAa6Ls B8DO0cwsJM0Sv9+NTVkhNtLOK1DOb8vw89TuuHkOlIHaFXRyCQAAAAAAAA== --Apple-Mail=_8D152582-56D3-4571-B073-3DA5E7768084-- From nobody Thu Oct 8 09:54:41 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5C21AC3D2 for ; Thu, 8 Oct 2015 09:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 QLGJtFHnvGoJ for ; Thu, 8 Oct 2015 09:54:39 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23F431AC3CE for ; Thu, 8 Oct 2015 09:54:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11404; q=dns/txt; s=iport; t=1444323279; x=1445532879; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=FDc7DcIk8NDw/60HDHf3H6VSOfDjEl6xXJ+56aIAayA=; b=FVBEOERJwWHLyngr2NRKXFRYXhGmn0mCwzvo/ZSvMfpvKAFYrkYIJeN6 6pPsQ3m82DhrkQRllFhge39Ffh5KsveSueTaCeatv8nOYvxpyk5yVA/+u 2RfAxQZLkk4ILjseRWdYDEu2rvdBXeVgFJPBfpkmJTCN+29cuCOYV++QW c=; X-Files: smime.p7s : 3862 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BXAwCZnhZW/4YNJK1eglpNVG4GvUIOgVoXAQmCcoIKfwKBTDgUAQEBAQEBAYEKhCYBAQEDAQEBAWsQCwIBCBgnBwIlCxQRAgQTDogYCA3DLgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEhnOCEIJuhQkLgxqBFAWSUIM6AYJMgWGIaoFYhDqVZwEfAUOEAnGGZoEGAQEB X-IronPort-AV: E=Sophos;i="5.17,655,1437436800"; d="p7s'?scan'208,217";a="35718849" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-5.cisco.com with ESMTP; 08 Oct 2015 16:54:38 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t98Gsc8e008149 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 8 Oct 2015 16:54:38 GMT Received: from xch-rcd-009.cisco.com (173.37.102.19) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 8 Oct 2015 11:54:37 -0500 Received: from xch-rcd-009.cisco.com ([173.37.102.19]) by XCH-RCD-009.cisco.com ([173.37.102.19]) with mapi id 15.00.1104.000; Thu, 8 Oct 2015 11:54:37 -0500 From: "JP Vasseur (jvasseur)" To: "pce@ietf.org" , "BRUNGARD, DEBORAH A" Thread-Topic: [Pce] New Co-Chair for PCE Thread-Index: AQHRAeoDn3MC8/6fi0uaqP3tuDPGlA== Date: Thu, 8 Oct 2015 16:54:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.61.194] Content-Type: multipart/signed; boundary="Apple-Mail=_E3C3CD11-8582-46B7-B2E6-AC785A52F333"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [Pce] New Co-Chair for PCE X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2015 16:54:40 -0000 --Apple-Mail=_E3C3CD11-8582-46B7-B2E6-AC785A52F333 Content-Type: multipart/alternative; boundary="Apple-Mail=_E064B929-A6B6-419C-B22A-C1753886BA20" --Apple-Mail=_E064B929-A6B6-419C-B22A-C1753886BA20 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear WG, Join us welcoming Jon as our 3rd co-chair ! Just wanted to take the opportunity to tell you that we do have (too) = many draft in our backlog (sorry about that !) and we will be clearing = it in the few few weeks. Thanks. JP, Julien and Jon. > On Oct 6, 2015, at 4:12 PM, BRUNGARD, DEBORAH A = wrote: >=20 > Hi, > =20 > Please welcome Jon Hardwick as a 3rd co-chair for PCE! > =20 > Thanks, > Deborah > =20 > =20 > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce = --Apple-Mail=_E064B929-A6B6-419C-B22A-C1753886BA20 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear WG,

Join us welcoming Jon as our 3rd co-chair !

Just wanted to take the = opportunity to tell you that we do have (too) many draft in our backlog = (sorry about that !) and we will be clearing it in the few few = weeks.

Thanks.

JP, Julien and Jon.

On = Oct 6, 2015, at 4:12 PM, BRUNGARD, DEBORAH A <db3546@att.com> = wrote:

Hi,
 
Please welcome Jon Hardwick as a = 3rd co-chair for PCE!
 
Thanks,
Deborah
 
 
_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

= --Apple-Mail=_E064B929-A6B6-419C-B22A-C1753886BA20-- --Apple-Mail=_E3C3CD11-8582-46B7-B2E6-AC785A52F333 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHjCCBTAw ggQYoAMCAQICEQDVs65XZh59t2IXVyBjHIr6MA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNDExMjQwMDAwMDBaFw0xNTExMjQyMzU5NTla MCMxITAfBgkqhkiG9w0BCQEWEmp2YXNzZXVyQGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMnOoDwgfyigTrGJQkL+oeRZ/jELtw6kVKr5mYh1odj7ez8u8cPbZVsgvuLu UKGl6qjUjPd0kYgUR49lQynBhdY98L6MGHLTCtp6GIn4Ux3Kfk5lZvU/hgDveiDYbQNkYvjL2B1m vrr+lM/0E1b1qLNxRhePGy3GT0pSgi3wKfhEmUwMXayHZ3Vly0ugYH4idrBPcsBL9WNBDi7BYVCE ntzv2QVuB6fLuddurd+HAvJs7HT7NFwkS8O3sGhAmAz94yXsml9XtJEePaI0EzgXueK3bYUnYvPF rg44+v20UlVaY1+6vQYecBOXjxlOsprD+YKtGqaKew/Q7LMl4q3B070CAwEAAaOCAegwggHkMB8G A1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBS6q/3WoBmfGTrzbfUh6da/ TnTZwDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYL KwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEB MCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoGA1UdHwRTMFEw T6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEFBQcwAoZJaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMB0GA1Ud EQQWMBSBEmp2YXNzZXVyQGNpc2NvLmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAVU6J5QAmIVAp5ErX b2t86SQefahFFBTZOdnkl//UAqsyDrxaLBLGylM4Ve8sm1UwXO645rwT+UGPBYdOI6JSMAjYgDtd DUzfASU2za3L08OSrF0uaDWc2NpTNn80jGIH5CdP/IC8op6r2ee8P9vOOyFtqz57q4SIOT/qZmNR YA2XWO1mxl3kM6UVTf37lPxkJa3FBg5U8S702Cw9wyM1oUn3DUnmhf16hDdxYYaFzIaEmTQk9QRd 5xxwTcoBMaJufdhmwwoCdWW2RmWmrNUORzYkt6Fp/Lv5KjNsOK7PLuU1VnvFqOeMj1jzWi6twhJp RfAuAqj912Sj0ykTBvWtLjCCBeYwggPOoAMCAQICEGqb4Tg7/ytrnwHV2binUlYwDQYJKoZIhvcN AQEMBQAwgYUxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMSswKQYDVQQDEyJDT01PRE8g UlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTEzMDExMDAwMDAwMFoXDTI4MDEwOTIzNTk1 OVowgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNB IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAvrOeV6wodnVAFsc4A5jTxhh2IVDzJXkLTLWg0X06WD6cpzEup/Y0 dtmEatrQPTRI5Or1u6zf+bGBSyD9aH95dDSmeny1nxdlYCeXIoymMv6pQHJGNcIDpFDIMypVpVSR sivlJTRENf+RKwrB6vcfWlP8dSsE3Rfywq09N0ZfxcBa39V0wsGtkGWC+eQKiz4pBZYKjrc5NOpG 9qrxpZxyb4o4yNNwTqzaaPpGRqXB7IMjtf7tTmU2jqPMLxFNe1VXj9XB1rHvbRikw8lBoNoSWY66 nJN/VCJv5ym6Q0mdCbDKCMPybTjoNCQuelc0IAaO4nLUXk0BOSxSxt8kCvsUtQIDAQABo4IBPDCC ATgwHwYDVR0jBBgwFoAUu69+Aj36pvE8hI6t7jiY7NkyMtQwHQYDVR0OBBYEFIKvbIz4xf6WYXzo Hz0rcUhexIvAMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgw BgYEVR0gADBMBgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9S U0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDBxBggrBgEFBQcBAQRlMGMwOwYIKwYBBQUHMAKG L2h0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1JTQUFkZFRydXN0Q0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wDQYJKoZIhvcNAQEMBQADggIBAHhcsoEoNE88 7l9Wzp+XVuyPomsX9vP2SQgG1NgvNc3fQP7TcePo7EIMERoh42awGGsma65u/ITse2hKZHzT0CBx huhb6txM1n/y78e/4ZOs0j8CGpfb+SJA3GaBQ+394k+z3ZByWPQedXLL1OdK8aRINTsjk/H5Ns77 zwbjOKkDamxlpZ4TKSDMKVmU/PUWNMKSTvtlenlxBhh7ETrN543j/Q6qqgCWgWuMAXijnRglp9fy adqGOncjZjaaSOGTTFB+E2pvOUtY+hPebuPtTbq7vODqzCM6ryEhNhzf+enm0zlpXK7q332nXttN tjv7VFNYG+I31gnMrwfHM5tdhYF/8v5UY5g2xANPECTQdu9vWPoqNSGDt87b3gXb1AiGGaI06vzg kejL580ul+9hz9D0S0U4jkhJiA7EuTecP/CFtR72uYRBcunwwH3fciPjviDDAI9SnC/2aPY8ydeh zuZutLbZdRJ5PDEJM/1tyZR2niOYihZ+FCbtf3D9mB12D4ln9icgc7CwaxpNSCPt8i/GqK2HsOgk L3VYnwtx7cJUmpvVdZ4ognzgXtgtdk3ShrtOS1iAN2ZBXFiRmjVzmehoMof06r1xub+85hFQzVxZ x5/bRaTKTlL8YXLI8nAbR9HWdFqzcOoB/hxfEyIQpx9/s81rgzdEZOofSlZHynoSMYIDujCCA7YC AQEwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8g UlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEA1bOuV2Yefbdi F1cgYxyK+jAJBgUrDgMCGgUAoIIB4TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNTEwMDgxNjU0MzRaMCMGCSqGSIb3DQEJBDEWBBTbGqu0tJ0hKaDPYjiFoHSHUGtc KjCBvgYJKwYBBAGCNxAEMYGwMIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9 MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFp bCBDQQIRANWzrldmHn23YhdXIGMcivowgcAGCyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQG EwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYD VQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANWzrldmHn23YhdXIGMcivowDQYJKoZIhvcN AQEBBQAEggEARkZ7Dh/yAgvYtyDVV6yVAIadwlhqa3IhBWQhymAocPRDnO6n39RKWHbO7Im8hcH8 cfiEImVBg8ncTWdRXQrjHKMIseEYv+5bnjcdGtdlTfUGtupHEfghRe9DyPiwXDeUtp2HS1AJBrpd IKkf/uPzqe3wdhokc+NoyxfAur5NTom0nlxh6i68+4FbeiNT+AUnDglACB6hko6VMXcDzYnN7asA 7oP357ZCDUr2/SlpYsAa3GxjwavzVeoQQuEcP1/bLOxwrO/d7PgkRHOH9Rn9YQD2hYYCMopAx/yb +yOjUgpQIYxUJpbUdvBXfNANg6FeHG/5LWtdbUXzTwA5XmuWkAAAAAAAAA== --Apple-Mail=_E3C3CD11-8582-46B7-B2E6-AC785A52F333-- From nobody Thu Oct 8 15:57:51 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BAF41AD069 for ; Thu, 8 Oct 2015 15:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 mrgBVHOewMnl for ; Thu, 8 Oct 2015 15:57:48 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F2041AD068 for ; Thu, 8 Oct 2015 15:57:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6948; q=dns/txt; s=iport; t=1444345068; x=1445554668; h=from:to:subject:date:message-id:mime-version; bh=8C4l/KRdV1VMbTE36y9o3GUUnmgKW0pISkM2MRBxA+s=; b=dvePfoWrJLO5+JNUTkbBVRvhGpjjrVw18t1IOmN9LJVILr4mA7bmPCLX oIijNyfoKn5PjqVrluUutJ8KlF/rD1w8b6MPDXjN7pQiourMWVwOAJ5/T hDO02RuU50sq6ifjGQea1A2MCdi41q1mAcXX1mcdZ/WmXqaCVTJO/1uK1 k=; X-Files: smime.p7s : 3862 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AYBAAl9BZW/5BdJa1egyaBSL1PDoFagxOCCoJWOBQBAQEBAQEBfwuEHRCBCwELAUQwJwQhiCCfM6QWAQEBAQEBBAEBAQEBAQEBARmGc4IQixyBFAWSUIM6AYJMgWGIaoFYhDqReYNuAR8BQ4QCh1WBBgEBAQ X-IronPort-AV: E=Sophos;i="5.17,656,1437436800"; d="p7s'?scan'208,217";a="39627343" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Oct 2015 22:57:47 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t98Mvltc029149 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 8 Oct 2015 22:57:47 GMT Received: from xch-rcd-009.cisco.com (173.37.102.19) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 8 Oct 2015 17:57:46 -0500 Received: from xch-rcd-009.cisco.com ([173.37.102.19]) by XCH-RCD-009.cisco.com ([173.37.102.19]) with mapi id 15.00.1104.000; Thu, 8 Oct 2015 17:57:45 -0500 From: "JP Vasseur (jvasseur)" To: "pce@ietf.org" Thread-Topic: PCE WG Last Call - draft-ietf-pce-pceps-04 Thread-Index: AQHRAhy/vjVtoYVB9EuMfjvTSIqVgQ== Date: Thu, 8 Oct 2015 22:57:45 +0000 Message-ID: <1BA0067B-53A9-4F11-87B6-41F1C9C60AF9@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.61.194] Content-Type: multipart/signed; boundary="Apple-Mail=_81077FD5-8475-49C6-98C0-62364D8F1629"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: [Pce] PCE WG Last Call - draft-ietf-pce-pceps-04 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2015 22:57:49 -0000 --Apple-Mail=_81077FD5-8475-49C6-98C0-62364D8F1629 Content-Type: multipart/alternative; boundary="Apple-Mail=_8F065DA6-36A8-42E8-9510-5FFAC2230B65" --Apple-Mail=_8F065DA6-36A8-42E8-9510-5FFAC2230B65 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear WG,=20 This starts a 2-week WG Last Call on draft-ietf-pce-pceps-04, ending on = Oct 23 at noon ET. Please send your comments to the authors and copy the = list. Thanks. JP, Julien and Jon.= --Apple-Mail=_8F065DA6-36A8-42E8-9510-5FFAC2230B65 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Dear WG, 

This starts a 2-week WG Last Call on draft-ietf-pce-pceps-04, ending on Oct 23 at noon ET. Please send your comments to the authors and copy the list.

Thanks.

JP, Julien and Jon.
--Apple-Mail=_8F065DA6-36A8-42E8-9510-5FFAC2230B65-- --Apple-Mail=_81077FD5-8475-49C6-98C0-62364D8F1629 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHjCCBTAw ggQYoAMCAQICEQDVs65XZh59t2IXVyBjHIr6MA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNDExMjQwMDAwMDBaFw0xNTExMjQyMzU5NTla MCMxITAfBgkqhkiG9w0BCQEWEmp2YXNzZXVyQGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMnOoDwgfyigTrGJQkL+oeRZ/jELtw6kVKr5mYh1odj7ez8u8cPbZVsgvuLu UKGl6qjUjPd0kYgUR49lQynBhdY98L6MGHLTCtp6GIn4Ux3Kfk5lZvU/hgDveiDYbQNkYvjL2B1m vrr+lM/0E1b1qLNxRhePGy3GT0pSgi3wKfhEmUwMXayHZ3Vly0ugYH4idrBPcsBL9WNBDi7BYVCE ntzv2QVuB6fLuddurd+HAvJs7HT7NFwkS8O3sGhAmAz94yXsml9XtJEePaI0EzgXueK3bYUnYvPF rg44+v20UlVaY1+6vQYecBOXjxlOsprD+YKtGqaKew/Q7LMl4q3B070CAwEAAaOCAegwggHkMB8G A1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBS6q/3WoBmfGTrzbfUh6da/ TnTZwDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYL KwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEB MCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoGA1UdHwRTMFEw T6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEFBQcwAoZJaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMB0GA1Ud EQQWMBSBEmp2YXNzZXVyQGNpc2NvLmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAVU6J5QAmIVAp5ErX b2t86SQefahFFBTZOdnkl//UAqsyDrxaLBLGylM4Ve8sm1UwXO645rwT+UGPBYdOI6JSMAjYgDtd DUzfASU2za3L08OSrF0uaDWc2NpTNn80jGIH5CdP/IC8op6r2ee8P9vOOyFtqz57q4SIOT/qZmNR YA2XWO1mxl3kM6UVTf37lPxkJa3FBg5U8S702Cw9wyM1oUn3DUnmhf16hDdxYYaFzIaEmTQk9QRd 5xxwTcoBMaJufdhmwwoCdWW2RmWmrNUORzYkt6Fp/Lv5KjNsOK7PLuU1VnvFqOeMj1jzWi6twhJp RfAuAqj912Sj0ykTBvWtLjCCBeYwggPOoAMCAQICEGqb4Tg7/ytrnwHV2binUlYwDQYJKoZIhvcN AQEMBQAwgYUxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMSswKQYDVQQDEyJDT01PRE8g UlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTEzMDExMDAwMDAwMFoXDTI4MDEwOTIzNTk1 OVowgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNB IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAvrOeV6wodnVAFsc4A5jTxhh2IVDzJXkLTLWg0X06WD6cpzEup/Y0 dtmEatrQPTRI5Or1u6zf+bGBSyD9aH95dDSmeny1nxdlYCeXIoymMv6pQHJGNcIDpFDIMypVpVSR sivlJTRENf+RKwrB6vcfWlP8dSsE3Rfywq09N0ZfxcBa39V0wsGtkGWC+eQKiz4pBZYKjrc5NOpG 9qrxpZxyb4o4yNNwTqzaaPpGRqXB7IMjtf7tTmU2jqPMLxFNe1VXj9XB1rHvbRikw8lBoNoSWY66 nJN/VCJv5ym6Q0mdCbDKCMPybTjoNCQuelc0IAaO4nLUXk0BOSxSxt8kCvsUtQIDAQABo4IBPDCC ATgwHwYDVR0jBBgwFoAUu69+Aj36pvE8hI6t7jiY7NkyMtQwHQYDVR0OBBYEFIKvbIz4xf6WYXzo Hz0rcUhexIvAMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgw BgYEVR0gADBMBgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9S U0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDBxBggrBgEFBQcBAQRlMGMwOwYIKwYBBQUHMAKG L2h0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1JTQUFkZFRydXN0Q0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wDQYJKoZIhvcNAQEMBQADggIBAHhcsoEoNE88 7l9Wzp+XVuyPomsX9vP2SQgG1NgvNc3fQP7TcePo7EIMERoh42awGGsma65u/ITse2hKZHzT0CBx huhb6txM1n/y78e/4ZOs0j8CGpfb+SJA3GaBQ+394k+z3ZByWPQedXLL1OdK8aRINTsjk/H5Ns77 zwbjOKkDamxlpZ4TKSDMKVmU/PUWNMKSTvtlenlxBhh7ETrN543j/Q6qqgCWgWuMAXijnRglp9fy adqGOncjZjaaSOGTTFB+E2pvOUtY+hPebuPtTbq7vODqzCM6ryEhNhzf+enm0zlpXK7q332nXttN tjv7VFNYG+I31gnMrwfHM5tdhYF/8v5UY5g2xANPECTQdu9vWPoqNSGDt87b3gXb1AiGGaI06vzg kejL580ul+9hz9D0S0U4jkhJiA7EuTecP/CFtR72uYRBcunwwH3fciPjviDDAI9SnC/2aPY8ydeh zuZutLbZdRJ5PDEJM/1tyZR2niOYihZ+FCbtf3D9mB12D4ln9icgc7CwaxpNSCPt8i/GqK2HsOgk L3VYnwtx7cJUmpvVdZ4ognzgXtgtdk3ShrtOS1iAN2ZBXFiRmjVzmehoMof06r1xub+85hFQzVxZ x5/bRaTKTlL8YXLI8nAbR9HWdFqzcOoB/hxfEyIQpx9/s81rgzdEZOofSlZHynoSMYIDujCCA7YC AQEwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8g UlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEA1bOuV2Yefbdi F1cgYxyK+jAJBgUrDgMCGgUAoIIB4TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNTEwMDgyMjU3NDRaMCMGCSqGSIb3DQEJBDEWBBSj+179yAVG8VjXbiuqIOvuJeNH vjCBvgYJKwYBBAGCNxAEMYGwMIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9 MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFp bCBDQQIRANWzrldmHn23YhdXIGMcivowgcAGCyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQG EwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYD VQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANWzrldmHn23YhdXIGMcivowDQYJKoZIhvcN AQEBBQAEggEAoMIbyxEPHghAD8r4Jjb3Q3n44HVRVqGJo48EI2+nV28lVLDhdMU7KUzzmbEFmxFZ Qorb/XF3dyaLY8IO3OuNSmJpeiN38nPQxYpwb7NwSDhdvihPYeyphCbRXdHN4Mn4Y5vlpu1R/Ods ONf24yBdww3L9JGjLnfuX2talDEYrhPOhAcM8mhmLFJ4OyigABIJliRryb2sexBDVpcJKJDPPH5E hXUw9kMgyNRrnojuOL1rg7jfUKmWc4tYzh+S60Wz/olcLK3+gukxsSjESuPg79YB0V0E7CwcncQT evrs2ZtetjxyfYPQ9SnA9OGSlfIjBGnFzEBoT7GiPYrpSe31qQAAAAAAAA== --Apple-Mail=_81077FD5-8475-49C6-98C0-62364D8F1629-- From nobody Fri Oct 9 05:05:24 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78AF31B3944; Fri, 9 Oct 2015 05:05:23 -0700 (PDT) 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=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, 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 NFF_1e-2emKp; Fri, 9 Oct 2015 05:05:22 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBF531B397D; Fri, 9 Oct 2015 05:04:05 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 4AFEC2AC240; Fri, 9 Oct 2015 14:04:04 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.31]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 2B2B8C801D; Fri, 9 Oct 2015 14:04:04 +0200 (CEST) Received: from [10.193.71.204] (10.168.234.5) by OPEXCLILM22.corporate.adroot.infra.ftgroup (10.114.31.31) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 9 Oct 2015 14:04:03 +0200 To: , From: Organization: Orange Message-ID: <4439_1444392244_5617AD34_4439_7180_1_5617AD33.3000309@orange.com> Date: Fri, 9 Oct 2015 14:04:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.168.234.5] X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.10.9.112417 Archived-At: Cc: "pce@ietf.org" , teas@ietf.org Subject: [Pce] Home for "PCE as Central Controller" X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2015 12:05:23 -0000 Dear authors of PCE-CC I-Ds, We are following up on Lou's (very last minute ;-) ) comment during the PCE meeting in Prague. The TEAS WG has just endorsed as WG item the "ACTN" work, (quoting the requirement I-D) "so as to facilitate network programmability, automation, efficient resource sharing, and end-to-end virtual service aware connectivity and network function virtualization services". A significant part of the PCE-CC proposal may fall under this umbrella. As a result, we would like to see the related requirements/use-cases/architecture discussed first within TEAS, the PCE WG remaining (obviously) in charge of any identified PCEP extensions. Feel free to contacts the PCE and/or TEAS chairs if some clarifications on the respective charters of the WGs are needed. Thanks, Jon, JP & Julien _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From nobody Fri Oct 9 08:59:48 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5902B1B455A for ; Fri, 9 Oct 2015 08:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 EiIAJndWzavv for ; Fri, 9 Oct 2015 08:59:41 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0118.outbound.protection.outlook.com [65.55.169.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C40841B4561 for ; Fri, 9 Oct 2015 08:59:40 -0700 (PDT) Received: from DM2PR02MB1356.namprd02.prod.outlook.com (10.161.143.13) by DM2PR02MB1356.namprd02.prod.outlook.com (10.161.143.13) with Microsoft SMTP Server (TLS) id 15.1.286.20; Fri, 9 Oct 2015 15:59:37 +0000 Received: from DM2PR02MB1356.namprd02.prod.outlook.com ([10.161.143.13]) by DM2PR02MB1356.namprd02.prod.outlook.com ([10.161.143.13]) with mapi id 15.01.0286.019; Fri, 9 Oct 2015 15:59:37 +0000 From: Jonathan Hardwick To: Girish Birajdar Thread-Topic: comments on draft-ietf-pce-pce-initiated-lsp Thread-Index: AQHQ/Gy4iN8ZpNURgU+tcN9wJBH9PJ5jXX+A Date: Fri, 9 Oct 2015 15:59:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jonathan.Hardwick@metaswitch.com; x-originating-ip: [217.43.17.249] x-microsoft-exchange-diagnostics: 1; DM2PR02MB1356; 5:IczQvL6r/PTOk4iEkjdxJAVH0M5fQM0AUKH4WQTuElQ2LxaKrApt1boh9vndppVbEO5VTBi8705gxaOcpzB8X4RHU8TcgCl7zY2lbAn9FcuNI1pYJNSudX+nahYxCYs+crcDx/OVAQ8XGmpT7KWeOg==; 24:nDnO6684kCSFmsnDQdMpE5LE0RAJQIONlUQ69a2iE/yX+HnzZQes3ETkRZp60T4fOof6szbe49fB1cnC8gUQtAQSr4gh1ipHipXyNgL4xck=; 20:np60glGr3C7Oo7cASzYPJktuQuIGmPgs/iLj2E1mHVdKkgGImSCsXF/LiyF5lQrYN32kTyW/6TSU31ghHbIl7w== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR02MB1356; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(3002001); SRVR:DM2PR02MB1356; BCL:0; PCL:0; RULEID:; SRVR:DM2PR02MB1356; x-forefront-prvs: 0724FCD4CD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(51914003)(189002)(5002640100001)(122556002)(5004730100002)(19580395003)(101416001)(46102003)(76176999)(64706001)(106356001)(19580405001)(106116001)(99286002)(50986999)(105586002)(19300405004)(40100003)(54356999)(110136002)(189998001)(15975445007)(86362001)(5007970100001)(102836002)(5001960100002)(2900100001)(92566002)(66066001)(33656002)(19625215002)(16236675004)(5003600100002)(2950100001)(87936001)(77096005)(230783001)(74316001)(1411001)(10400500002)(11100500001)(81156007)(5001920100001)(76576001)(5008740100001)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR02MB1356; H:DM2PR02MB1356.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM2PR02MB135605989E11D65FB0A515C084340DM2PR02MB1356namp_" MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2015 15:59:37.0469 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR02MB1356 Archived-At: Cc: "pce@ietf.org" Subject: Re: [Pce] comments on draft-ietf-pce-pce-initiated-lsp X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2015 15:59:46 -0000 --_000_DM2PR02MB135605989E11D65FB0A515C084340DM2PR02MB1356namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgR2lyaXNoDQoNClRoYW5rcyBmb3IgdGhlIGNvbW1lbnQuICBJIHRoaW5rIHlvdXIgcG9pbnRz IGFyZSB2YWxpZC4gIFdlIHdpbGwgYWRkIGEgY2xhcmlmeWluZyBwYXNzYWdlIHRvIHRoZSBuZXh0 IHZlcnNpb24gb2YgZHJhZnQtaWV0Zi1wY2Utc2VnbWVudC1yb3V0aW5nIHRvIGFkZHJlc3MgdGhp cy4NCg0KQmVzdCByZWdhcmRzDQpKb24gKGFzIGNvLWF1dGhvciBvZiBkcmFmdC1pZXRmLXBjZS1z ZWdtZW50LXJvdXRpbmcpDQoNCg0KRnJvbTogR2lyaXNoIEJpcmFqZGFyIFttYWlsdG86Z2lyaXNo MTM0QGdtYWlsLmNvbV0NClNlbnQ6IDAxIE9jdG9iZXIgMjAxNSAxODoxNQ0KVG86IGRyYWZ0LWll dGYtcGNlLXBjZS1pbml0aWF0ZWQtbHNwQGlldGYub3JnDQpDYzogZHJhZnQtaWV0Zi1wY2Utc2Vn bWVudC1yb3V0aW5nQGlldGYub3JnDQpTdWJqZWN0OiBjb21tZW50cyBvbiBkcmFmdC1pZXRmLXBj ZS1wY2UtaW5pdGlhdGVkLWxzcA0KDQpBdXRob3JzLA0KVGhpcyBjb21tZW50IGlzIHNwZWNpZmlj IHRvIExTUCBpbml0aWF0ZSBtZXNzYWdlIGFuZCBNU0QgdmFsdWUgc3BlY2lmaWVkIGluIGRyYWZ0 LWlldGYtcGNlLXNlZ21lbnQtcm91dGluZy4NCg0KZHJhZnQtaWV0Zi1wY2Utc2VnbWVudC1yb3V0 aW5nICI1LjEuMS4xLiAgRXhjaGFuZ2luZyBTUiBDYXBhYmlsaXR5IC4uLg0KQW4gTVNEIHZhbHVl IG9mIHplcm8gbWVhbnMgdGhhdCBhIFBDQyBkb2VzDQogICBub3QgaW1wb3NlIGFueSBkZWZhdWx0 IGxpbWl0YXRpb24gb24gdGhlIG51bWJlciBvZiBTSURzIGluY2x1ZGVkIGluDQogICBhbnkgU1It VEUgcGF0aCBjb21pbmcgZnJvbSBQQ0UiDQoNCmRyYWZ0LWlldGYtcGNlLXBjZS1pbml0aWF0ZWQt bHNwIGRvZXMgbm90IG1lbnRpb24gTVNELiBJcyBpdCBwb3NzaWJsZSB0byBjb3ZlciBmZXcgZXJy b3IgY2FzZXMgdGhhdCBtaWdodCBoYXZlIHdoZW4gUENFUCBzZXNzaW9uIGhhcyBNU0Q9MCBhbmQg TFNQIEluaXRpYXRlIG1lc3NhZ2Ugc2VuZHMgdW5hY2NlcHRhYmxlIGxhYmVsLXN0YWNrIHNpemU/ DQpJTU8sIHdoZW4gUENDIHJlY2VpdmVzIGEgTFNQIEluaXRpYXRlIE1lc3NhZ2UgdGhhdCBleGNl ZWRzIGl0cyBzdGFjay1zaXplIGxpbWl0LCBhbiBlcnJvciBtZXNzYWdlIHRoYXQgc3BlY2lmaWVz IGFjY2VwdGFibGUgTVNEIHZhbHVlIHdvdWxkIGJlIHVzZWZ1bC4NCg0KUmVnYXJkcywNCkdpcmlz aA0KDQo= --_000_DM2PR02MB135605989E11D65FB0A515C084340DM2PR02MB1356namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw cmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZv cm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1M UHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hh ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZv cm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tR0I7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcy LjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSIjMDU2M0Mx IiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPkhpIEdpcmlzaDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+VGhhbmtzIGZvciB0aGUgY29tbWVudC4mbmJzcDsgSSB0aGluayB5b3VyIHBvaW50cyBh cmUgdmFsaWQuJm5ic3A7IFdlIHdpbGwgYWRkIGEgY2xhcmlmeWluZyBwYXNzYWdlIHRvIHRoZSBu ZXh0IHZlcnNpb24gb2YgZHJhZnQtaWV0Zi1wY2Utc2VnbWVudC1yb3V0aW5nDQogdG8gYWRkcmVz cyB0aGlzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+QmVzdCByZWdh cmRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkpvbiAoYXMg Y28tYXV0aG9yIG9mIGRyYWZ0LWlldGYtcGNlLXNlZ21lbnQtcm91dGluZyk8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZy b206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gR2lyaXNoIEJpcmFq ZGFyIFttYWlsdG86Z2lyaXNoMTM0QGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiAwMSBP Y3RvYmVyIDIwMTUgMTg6MTU8YnI+DQo8Yj5Ubzo8L2I+IGRyYWZ0LWlldGYtcGNlLXBjZS1pbml0 aWF0ZWQtbHNwQGlldGYub3JnPGJyPg0KPGI+Q2M6PC9iPiBkcmFmdC1pZXRmLXBjZS1zZWdtZW50 LXJvdXRpbmdAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gY29tbWVudHMgb24gZHJhZnQt aWV0Zi1wY2UtcGNlLWluaXRpYXRlZC1sc3A8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+QXV0aG9y cyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo aXMgY29tbWVudCBpcyBzcGVjaWZpYyB0byBMU1AgaW5pdGlhdGUgbWVzc2FnZSBhbmQgTVNEIHZh bHVlIHNwZWNpZmllZCBpbiBkcmFmdC1pZXRmLXBjZS1zZWdtZW50LXJvdXRpbmcuPGJyPg0KPGJy Pg0KZHJhZnQtaWV0Zi1wY2Utc2VnbWVudC1yb3V0aW5nICZxdW90OzUuMS4xLjEuJm5ic3A7IEV4 Y2hhbmdpbmcgU1IgQ2FwYWJpbGl0eSAuLi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5BbiBNU0QgdmFsdWUg b2YgemVybyBtZWFucyB0aGF0IGEgUENDIGRvZXM8YnI+DQombmJzcDsmbmJzcDsgbm90IGltcG9z ZSBhbnkgZGVmYXVsdCBsaW1pdGF0aW9uIG9uIHRoZSBudW1iZXIgb2YgU0lEcyBpbmNsdWRlZCBp bjxicj4NCiZuYnNwOyZuYnNwOyBhbnkgU1ItVEUgcGF0aCBjb21pbmcgZnJvbSBQQ0UmcXVvdDs8 bzpwPjwvbzpwPjwvcD4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWYiPmRyYWZ0LWlldGYtcGNlLXBjZS1pbml0aWF0ZWQtbHNwIGRvZXMg bm90IG1lbnRpb24gTVNELiBJcyBpdCBwb3NzaWJsZSB0byBjb3ZlciBmZXcgZXJyb3IgY2FzZXMg dGhhdCBtaWdodCBoYXZlIHdoZW4gUENFUCBzZXNzaW9uIGhhcyBNU0Q9MCBhbmQgTFNQIEluaXRp YXRlIG1lc3NhZ2Ugc2VuZHMgdW5hY2NlcHRhYmxlIGxhYmVsLXN0YWNrIHNpemU/PGJyPklNTywg d2hlbiBQQ0MgcmVjZWl2ZXMgYSBMU1AgSW5pdGlhdGUgTWVzc2FnZSB0aGF0IGV4Y2VlZHMgaXRz IHN0YWNrLXNpemUgbGltaXQsIGFuIGVycm9yIG1lc3NhZ2UgdGhhdCBzcGVjaWZpZXMgYWNjZXB0 YWJsZSBNU0QgdmFsdWUgd291bGQgYmUgdXNlZnVsLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0K PHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp ZiI+UmVnYXJkcyw8YnI+R2lyaXNoPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DM2PR02MB135605989E11D65FB0A515C084340DM2PR02MB1356namp_-- From nobody Fri Oct 9 18:24:43 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD561B51AF for ; Fri, 9 Oct 2015 18:24:43 -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 LfPtzmziQtBV for ; Fri, 9 Oct 2015 18:24:41 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B48841B51AE for ; Fri, 9 Oct 2015 18:24:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CCJ01796; Sat, 10 Oct 2015 01:24:39 +0000 (GMT) Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sat, 10 Oct 2015 02:24:38 +0100 Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.78]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0235.001; Sat, 10 Oct 2015 09:24:31 +0800 From: "Zhangxian (Xian)" To: PCE WG List Thread-Topic: New Version Notification for draft-minei-pce-association-group-03.txt Thread-Index: AQHRAvnb2N21bqTC90+j9b8YhIF5IJ5j7fVQ Date: Sat, 10 Oct 2015 01:24:31 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.104.209] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Pce] FW: New Version Notification for draft-minei-pce-association-group-03.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2015 01:24:43 -0000 SGksIEFsbCwgDQoNCiAgICBXZSBoYXZlIHVwZGF0ZWQgdGhpcyBkcmFmdCwgaW5jbHVkaW5nOiAN Cg0KMSkgYWRkcmVzc2luZyBjb21tZW50cyByZWNlaXZlZCBkdXJpbmcgbGFzdCBJRVRGIHNlc3Np b24vbWFpbGluZyBsaXN0ICh0aGFuayBmb3IgdGhvc2Ugd2hvIGNvbW1lbnRlZCEpOw0KMikgYWRk aW5nIGVycm9yIGhhbmRsaW5nIHRleHRzOyANCg0KICAgUGxlYXNlIGRvIHJldmlldyBhbmQgY29t bWVudCENCg0KVGhhbmsgeW91LCANCg0KWGlhbiAmIEluYSAoIG9uIGJlaGFsZiBvZiBhbGwgYXV0 aG9ycykNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiAyMDE1 5bm0MTDmnIgxMOaXpSA5OjIwDQpUbzogU2l2YSBTaXZhYmFsYW47IFlvc3VrZSBUYW5ha2E7IFpo YW5neGlhbiAoWGlhbik7IEhhcmloYXJhbiBBbmFudGhha3Jpc2huYW47IEVkd2FyZCBDcmFiYmU7 IEluYSBNaW5laQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1t aW5laS1wY2UtYXNzb2NpYXRpb24tZ3JvdXAtMDMudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJ LUQsIGRyYWZ0LW1pbmVpLXBjZS1hc3NvY2lhdGlvbi1ncm91cC0wMy50eHQNCmhhcyBiZWVuIHN1 Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgWGlhbiBaaGFuZyBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVU RiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtbWluZWktcGNlLWFzc29jaWF0aW9uLWdyb3Vw DQpSZXZpc2lvbjoJMDMNClRpdGxlOgkJUENFUCBFeHRlbnNpb25zIGZvciBFc3RhYmxpc2hpbmcg UmVsYXRpb25zaGlwcyBCZXR3ZWVuIFNldHMgb2YgTFNQcw0KRG9jdW1lbnQgZGF0ZToJMjAxNS0x MC0xMA0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMTMNClVSTDogICAg ICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbWluZWkt cGNlLWFzc29jaWF0aW9uLWdyb3VwLTAzLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1pbmVpLXBjZS1hc3NvY2lhdGlvbi1ncm91cC8N Ckh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWluZWkt cGNlLWFzc29jaWF0aW9uLWdyb3VwLTAzDQpEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LW1pbmVpLXBjZS1hc3NvY2lhdGlvbi1ncm91cC0wMw0K DQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgaW50cm9kdWNlcyBhIGdlbmVyaWMgbWVjaGFu aXNtIHRvIGNyZWF0ZSBhIGdyb3VwaW5nIG9mDQogICBMU1BzIGluIHRoZSBjb250ZXh0IG9mIGEg UENFLiAgVGhpcyBncm91cGluZyBjYW4gdGhlbiBiZSB1c2VkIHRvDQogICBkZWZpbmUgYXNzb2Np YXRpb25zIGJldHdlZW4gc2V0cyBvZiBMU1BzIG9yIGJldHdlZW4gYSBzZXQgb2YgTFNQcyBhbmQN CiAgIGEgc2V0IG9mIGF0dHJpYnV0ZXMgKHN1Y2ggYXMgY29uZmlndXJhdGlvbiBwYXJhbWV0ZXJz IG9yIGJlaGF2aW9ycyksDQogICBhbmQgaXMgZXF1YWxseSBhcHBsaWNhYmxlIHRvIHRoZSBhY3Rp dmUgYW5kIHBhc3NpdmUgbW9kZXMgb2YgYQ0KICAgc3RhdGVmdWwgUENFIGFzIHdlbGwgYXMgYSBz dGF0ZWxlc3MgUENFLg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ug bm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBv ZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZh aWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Sat Oct 10 13:24:46 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2FA41A1A9F; Sat, 10 Oct 2015 13:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 9y6lI0dylgFf; Sat, 10 Oct 2015 13:24:44 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 139B61A1A86; Sat, 10 Oct 2015 13:24:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9214; q=dns/txt; s=iport; t=1444508684; x=1445718284; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=sPHk/9L1lgLpcvaS7QDFX0I7p2QilZMFbIv1IBLCuWM=; b=YrKt3c1zkyhjWFkuSjtK8vnp74haWjxLoo6+vYGxld9gwWg5aPSB8B5H v1ghnvA8y0QnSE6+aVxtuskYN/iFFn1jqtGgJRvFWGXCYzC+cBYlxT5jq aGYMez9VwEvmMyKSeg4IXZ7DFJW0kxA+L3owaPYPD4wroo5XuUC9gncYD w=; X-Files: smime.p7s : 3862 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CBAwDHchlW/5xdJa1egyZUbga9ZA6BWhcMgnCCCn8CgSA4FAEBAQEBAQGBCoQmAQEBAwEBAQFrCwUHBAIBCBEEAQEBJwcCJQsUCQgCBA4FDogYCA0DwzQBAQEBAQEBAQEBAQEBAQEBAQEBAQEXhnOCEIJuhQ0HBgODEYEUBYc4hwaEFoM/AYJNgWFqiAGBWEiDco0piEcBHwFDhAJxhmSBBgEBAQ X-IronPort-AV: E=Sophos;i="5.17,664,1437436800"; d="p7s'?scan'208";a="196652544" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-8.cisco.com with ESMTP; 10 Oct 2015 20:24:43 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t9AKOhJK012486 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 10 Oct 2015 20:24:43 GMT Received: from xch-rcd-009.cisco.com (173.37.102.19) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 10 Oct 2015 15:24:34 -0500 Received: from xch-rcd-009.cisco.com ([173.37.102.19]) by XCH-RCD-009.cisco.com ([173.37.102.19]) with mapi id 15.00.1104.000; Sat, 10 Oct 2015 15:24:34 -0500 From: "JP Vasseur (jvasseur)" To: Dhruv Dhody Thread-Topic: [Pce] I-D Action: draft-ietf-pce-stateful-sync-optimizations-03.txt Thread-Index: AQHRA5mt5L6aFsQejUOHo3zbj1a0Tw== Date: Sat, 10 Oct 2015 20:24:33 +0000 Message-ID: References: <23CE718903A838468A8B325B80962F9B8C41DE94@BLREML509-MBX.china.huawei.com> In-Reply-To: <23CE718903A838468A8B325B80962F9B8C41DE94@BLREML509-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.223.169] Content-Type: multipart/signed; boundary="Apple-Mail=_44A7EE00-9E15-4C19-A6EE-B5F29B1DA3B0"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Cc: "pce@ietf.org" , JP Vasseur , "draft-ietf-pce-stateful-sync-optimizations@ietf.org" Subject: Re: [Pce] I-D Action: draft-ietf-pce-stateful-sync-optimizations-03.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2015 20:24:46 -0000 --Apple-Mail=_44A7EE00-9E15-4C19-A6EE-B5F29B1DA3B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks Dhruv. > On Oct 6, 2015, at 8:57 PM, Dhruv Dhody = wrote: >=20 > Hi Chairs,=20 >=20 > This version refreshes the expired draft (no changes made in the = content).=20 > The WG LC [1] was issued last year on -01. The -02 update [2] handled = all the comments made during the last call.=20 >=20 > [1] = https://mailarchive.ietf.org/arch/msg/pce/PcJ5gBy2uqWAmilDKMqVjQyl6Ss > [2] = https://mailarchive.ietf.org/arch/msg/pce/MYVoNouTERYgfRlGPxhcGycKoy0 >=20 > Regards, > Dhruv (on behalf of co-authors/contributors) >=20 >> -----Original Message----- >> From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of internet- >> drafts@ietf.org >> Sent: 07 October 2015 10:18 >> To: i-d-announce@ietf.org >> Cc: pce@ietf.org >> Subject: [Pce] I-D Action: = draft-ietf-pce-stateful-sync-optimizations-03.txt >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Path Computation Element Working = Group of >> the IETF. >>=20 >> Title : Optimizations of Label Switched Path State >> Synchronization Procedures for a Stateful PCE >> Authors : Edward Crabbe >> Ina Minei >> Jan Medved >> Robert Varga >> Xian Zhang >> Dhruv Dhody >> Filename : = draft-ietf-pce-stateful-sync-optimizations-03.txt >> Pages : 23 >> Date : 2015-10-06 >>=20 >> Abstract: >> A stateful Path Computation Element (PCE) has access to not only = the >> information disseminated by the network's Interior Gateway Protocol >> (IGP), but also the set of active paths and their reserved = resources >> for its computation. The additional Label Switched Path (LSP) = state >> information allows the PCE to compute constrained paths while >> considering individual LSPs and their interactions. This requires = a >> reliable state synchronization mechanism between the PCE and the >> network, PCE and path computation clients (PCCs), and between >> cooperating PCEs. The basic mechanism for state synchronization is >> part of the stateful PCE specification. This draft presents >> motivations for optimizations to the base state synchronization >> procedure and specifies the required Path Computation Element >> Communication Protocol (PCEP) extensions. >>=20 >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> = https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-sync-optimization= s/ >>=20 >> There's also a htmlized version available at: >> = https://tools.ietf.org/html/draft-ietf-pce-stateful-sync-optimizations-03 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pce-stateful-sync- >> optimizations-03 >>=20 >>=20 >> 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. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> Pce mailing list >> Pce@ietf.org >> https://www.ietf.org/mailman/listinfo/pce >=20 > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce --Apple-Mail=_44A7EE00-9E15-4C19-A6EE-B5F29B1DA3B0 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHjCCBTAw ggQYoAMCAQICEQDVs65XZh59t2IXVyBjHIr6MA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNDExMjQwMDAwMDBaFw0xNTExMjQyMzU5NTla MCMxITAfBgkqhkiG9w0BCQEWEmp2YXNzZXVyQGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMnOoDwgfyigTrGJQkL+oeRZ/jELtw6kVKr5mYh1odj7ez8u8cPbZVsgvuLu UKGl6qjUjPd0kYgUR49lQynBhdY98L6MGHLTCtp6GIn4Ux3Kfk5lZvU/hgDveiDYbQNkYvjL2B1m vrr+lM/0E1b1qLNxRhePGy3GT0pSgi3wKfhEmUwMXayHZ3Vly0ugYH4idrBPcsBL9WNBDi7BYVCE ntzv2QVuB6fLuddurd+HAvJs7HT7NFwkS8O3sGhAmAz94yXsml9XtJEePaI0EzgXueK3bYUnYvPF rg44+v20UlVaY1+6vQYecBOXjxlOsprD+YKtGqaKew/Q7LMl4q3B070CAwEAAaOCAegwggHkMB8G A1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBS6q/3WoBmfGTrzbfUh6da/ TnTZwDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYL KwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEB MCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoGA1UdHwRTMFEw T6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEFBQcwAoZJaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMB0GA1Ud EQQWMBSBEmp2YXNzZXVyQGNpc2NvLmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAVU6J5QAmIVAp5ErX b2t86SQefahFFBTZOdnkl//UAqsyDrxaLBLGylM4Ve8sm1UwXO645rwT+UGPBYdOI6JSMAjYgDtd DUzfASU2za3L08OSrF0uaDWc2NpTNn80jGIH5CdP/IC8op6r2ee8P9vOOyFtqz57q4SIOT/qZmNR YA2XWO1mxl3kM6UVTf37lPxkJa3FBg5U8S702Cw9wyM1oUn3DUnmhf16hDdxYYaFzIaEmTQk9QRd 5xxwTcoBMaJufdhmwwoCdWW2RmWmrNUORzYkt6Fp/Lv5KjNsOK7PLuU1VnvFqOeMj1jzWi6twhJp RfAuAqj912Sj0ykTBvWtLjCCBeYwggPOoAMCAQICEGqb4Tg7/ytrnwHV2binUlYwDQYJKoZIhvcN AQEMBQAwgYUxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMSswKQYDVQQDEyJDT01PRE8g UlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTEzMDExMDAwMDAwMFoXDTI4MDEwOTIzNTk1 OVowgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNB IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAvrOeV6wodnVAFsc4A5jTxhh2IVDzJXkLTLWg0X06WD6cpzEup/Y0 dtmEatrQPTRI5Or1u6zf+bGBSyD9aH95dDSmeny1nxdlYCeXIoymMv6pQHJGNcIDpFDIMypVpVSR sivlJTRENf+RKwrB6vcfWlP8dSsE3Rfywq09N0ZfxcBa39V0wsGtkGWC+eQKiz4pBZYKjrc5NOpG 9qrxpZxyb4o4yNNwTqzaaPpGRqXB7IMjtf7tTmU2jqPMLxFNe1VXj9XB1rHvbRikw8lBoNoSWY66 nJN/VCJv5ym6Q0mdCbDKCMPybTjoNCQuelc0IAaO4nLUXk0BOSxSxt8kCvsUtQIDAQABo4IBPDCC ATgwHwYDVR0jBBgwFoAUu69+Aj36pvE8hI6t7jiY7NkyMtQwHQYDVR0OBBYEFIKvbIz4xf6WYXzo Hz0rcUhexIvAMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgw BgYEVR0gADBMBgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9S U0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDBxBggrBgEFBQcBAQRlMGMwOwYIKwYBBQUHMAKG L2h0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1JTQUFkZFRydXN0Q0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wDQYJKoZIhvcNAQEMBQADggIBAHhcsoEoNE88 7l9Wzp+XVuyPomsX9vP2SQgG1NgvNc3fQP7TcePo7EIMERoh42awGGsma65u/ITse2hKZHzT0CBx huhb6txM1n/y78e/4ZOs0j8CGpfb+SJA3GaBQ+394k+z3ZByWPQedXLL1OdK8aRINTsjk/H5Ns77 zwbjOKkDamxlpZ4TKSDMKVmU/PUWNMKSTvtlenlxBhh7ETrN543j/Q6qqgCWgWuMAXijnRglp9fy adqGOncjZjaaSOGTTFB+E2pvOUtY+hPebuPtTbq7vODqzCM6ryEhNhzf+enm0zlpXK7q332nXttN tjv7VFNYG+I31gnMrwfHM5tdhYF/8v5UY5g2xANPECTQdu9vWPoqNSGDt87b3gXb1AiGGaI06vzg kejL580ul+9hz9D0S0U4jkhJiA7EuTecP/CFtR72uYRBcunwwH3fciPjviDDAI9SnC/2aPY8ydeh zuZutLbZdRJ5PDEJM/1tyZR2niOYihZ+FCbtf3D9mB12D4ln9icgc7CwaxpNSCPt8i/GqK2HsOgk L3VYnwtx7cJUmpvVdZ4ognzgXtgtdk3ShrtOS1iAN2ZBXFiRmjVzmehoMof06r1xub+85hFQzVxZ x5/bRaTKTlL8YXLI8nAbR9HWdFqzcOoB/hxfEyIQpx9/s81rgzdEZOofSlZHynoSMYIDujCCA7YC AQEwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8g UlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEA1bOuV2Yefbdi F1cgYxyK+jAJBgUrDgMCGgUAoIIB4TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNTEwMTAyMDI0NDBaMCMGCSqGSIb3DQEJBDEWBBRuRVrTyycuASMCmJNnWEQCY/AQ ATCBvgYJKwYBBAGCNxAEMYGwMIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9 MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFp bCBDQQIRANWzrldmHn23YhdXIGMcivowgcAGCyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQG EwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYD VQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANWzrldmHn23YhdXIGMcivowDQYJKoZIhvcN AQEBBQAEggEAwKRxQ4LJONMJ1S6QivojRrrbRpJhMlcK3n1up9FRXVxnpJeQzloh6Qyt5KjojS0N Gt+RKXukv21bZXYfJzM3iPypyWXtd/RxuCIC8uzmqYqn5b45tjkePhs+P1SBwb9xl3llBH46qhtC nxsQZFVJBDN5K9F8o8lOrhqrzF/FQKaabhB076kniv27K3B8FigtOiddIorBhvDEnDkcMP1guSfG rbkgq4fqyMxNiY+WdmBUeS6Z9di4h3gsCjBnqxgknPgMWAM2eq1Zr+B+D99zKqCFheDm7CFb7ipg TKLGPSitrheM52QpFInL/m94sgxsXuCcyBVkhpu5880tGzDLfAAAAAAAAA== --Apple-Mail=_44A7EE00-9E15-4C19-A6EE-B5F29B1DA3B0-- From nobody Sun Oct 11 22:58:45 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C90031A00E7; Sun, 11 Oct 2015 22:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 Df3HyYZMrWbY; Sun, 11 Oct 2015 22:58:41 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F2AE1A00D8; Sun, 11 Oct 2015 22:58:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CCK68263; Mon, 12 Oct 2015 05:58:38 +0000 (GMT) Received: from BLREML405-HUB.china.huawei.com (10.20.4.41) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 12 Oct 2015 06:58:37 +0100 Received: from BLREML509-MBX.china.huawei.com ([169.254.7.243]) by BLREML405-HUB.china.huawei.com ([10.20.4.41]) with mapi id 14.03.0235.001; Mon, 12 Oct 2015 11:28:33 +0530 From: Dhruv Dhody To: "draft-ietf-pce-segment-routing@ietf.org" , "draft-ietf-pce-stateful-pce@tools.ietf.org" Thread-Topic: Query on Usage of LSP Identifier TLV in SR Thread-Index: AdEEswV5Hp/XsRTiRVyYCjyiKol6/Q== Date: Mon, 12 Oct 2015 05:58:32 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B8C421A83@BLREML509-MBX.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.244.252] Content-Type: multipart/alternative; boundary="_000_23CE718903A838468A8B325B80962F9B8C421A83BLREML509MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "pce@ietf.org" , "pce-chairs@tools.ietf.org" Subject: [Pce] Query on Usage of LSP Identifier TLV in SR X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 05:58:43 -0000 --_000_23CE718903A838468A8B325B80962F9B8C421A83BLREML509MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Authors, In the stateful PCE draft [1], it says - The LSP Identifiers TLV MUST be included in the LSP object in PCRpt messages for RSVP-signaled LSPs. The SR draft [2] did not mention anything about LSP Identifier TLV. And in implementations that I am aware of, SR-TE LSP still uses the LSP-Ide= ntifier TLV. Is that correct? (I personally think so!!) If yes, do you think there is a need to update - - [1] to say all LSPs (and not just RSVP-signaled). - Or [2] to say that LSP-Identifier TLV are also applicable to SR and = MUST be included. Thanks! Dhruv [1] https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-11#section-7.3.= 1 [2] http://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing/ --_000_23CE718903A838468A8B325B80962F9B8C421A83BLREML509MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Authors,

 

In the stateful PCE draft [1], it says –=

The LSP= Identifiers TLV MUST be included in the LSP object in PCRpt

message= s for RSVP-signaled LSPs.

 

The SR draft [2] did not mention anything about LSP= Identifier TLV.

And in implementations that I am aware of, SR-TE LS= P still uses the LSP-Identifier TLV. Is that correct? (I personally think s= o!!)

 

If yes, do you think there is a need to update R= 11;

-      [1] to say all LSPs (and not just RSVP-sign= aled).

-      Or [2] to say that LSP-Identifier TLV are a= lso applicable to SR and MUST be included.

 

Thanks!

Dhruv

 

 

[1] https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-11#section-7.3.1

[2] http://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing/

 

--_000_23CE718903A838468A8B325B80962F9B8C421A83BLREML509MBXchi_-- From nobody Mon Oct 12 01:03:06 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4C721A8782 for ; Mon, 12 Oct 2015 01:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.794 X-Spam-Level: X-Spam-Status: No, score=-1.794 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, 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 WfBNNurDp7W0 for ; Mon, 12 Oct 2015 01:03:03 -0700 (PDT) Received: from r-mail1.rd.orange.com (r-mail1.rd.orange.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 3299F1A877F for ; Mon, 12 Oct 2015 01:03:03 -0700 (PDT) Received: from r-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 49335A441D1 for ; Mon, 12 Oct 2015 10:03:07 +0200 (CEST) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by r-mail1.rd.orange.com (Postfix) with ESMTP id 42ECAA441C8 for ; Mon, 12 Oct 2015 10:03:07 +0200 (CEST) Received: from [10.193.71.204] (10.193.71.204) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.224.2; Mon, 12 Oct 2015 10:03:01 +0200 To: References: <8450_1444040825_56125078_8450_1292_1_56125078.50803@orange.com> From: Julien Meuric Organization: Orange Message-ID: <561B6935.50701@orange.com> Date: Mon, 12 Oct 2015 10:03:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <8450_1444040825_56125078_8450_1292_1_56125078.50803@orange.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Pce] Building the PCE Agenda for IETF 94 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Julien Meuric , 'JP Vasseur' , Jonathan Hardwick , Daniel King List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 08:03:04 -0000 Hi all, FYI, the PCE session is now scheduled on Tuesday, from 5:10 to 6:40 pm, right before the social event. By the way, Yokohama meeting is number 94: sorry for the typo in the previous e-mail. Regards, Jon, JP & Julien Oct. 05, 2015 - julien.meuric@orange.com: > Dear PCE WG, > > The IETF preliminary agenda is available > (https://datatracker.ietf.org/meeting/94/agenda.html). The PCE session > is _tentatively_ scheduled on Monday from 3:20 to 4:50 pm. Supposing > you have issues that _really_ require a slot to progress, please send > a request to the chairs and secretary, including: > - the topic to discuss, > - the expected duration, > - the name of the presenter, > - the rationale for requesting some face to face time, as opposed to > using the mailing list, i.e., the output you expect from your slot. > > Best regards, > > JP & Julien From nobody Mon Oct 12 10:04:45 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53EEC1A8957 for ; Mon, 12 Oct 2015 10:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 H3GkzwO4rMAP for ; Mon, 12 Oct 2015 10:04:41 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4851A1A8956 for ; Mon, 12 Oct 2015 10:04:41 -0700 (PDT) Received: by igbkq10 with SMTP id kq10so75640830igb.0 for ; Mon, 12 Oct 2015 10:04:40 -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=uXhtC7obpTmsOa43vMG4Rar09ljEb5wjkIi6rNYuSuA=; b=I4Xqkv1XvFYzzTm2SjEUvGlob/6lTkINCtEkjsqFLBFDNnqkIki5oo7Nl62/kCRlLZ 0XBvA604KZMOljtUk3L5BdD/VDD2gMf9DsaXePC51A6WPytF67gxkE9fKh6ddHiAW2RG k8uakW/Syx0otYWvvS4xDpy0UA8oSv7jHQd4QWDVTlFdToVH4IAoQlT4DQKhxm+qlLPf eemojq64f5At6U7soE3YpXaT8zJ6eis5ebmyNjoKimbpwvIxOqA796VsruInTaZ41PIk S26aqBLlP/ilguDPqKFv4I5zsJVjAx0ndUtNui0QYbEGUZrmyt1u9U0K7zE0iUvgYCKX TM+A== MIME-Version: 1.0 X-Received: by 10.50.111.226 with SMTP id il2mr1641441igb.61.1444669480564; Mon, 12 Oct 2015 10:04:40 -0700 (PDT) Received: by 10.64.86.233 with HTTP; Mon, 12 Oct 2015 10:04:40 -0700 (PDT) In-Reply-To: References: Date: Mon, 12 Oct 2015 10:04:40 -0700 Message-ID: From: Girish Birajdar To: Jonathan Hardwick Content-Type: multipart/alternative; boundary=047d7b41443a34fdd90521eb5311 Archived-At: Cc: "pce@ietf.org" Subject: Re: [Pce] comments on draft-ietf-pce-pce-initiated-lsp X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 17:04:43 -0000 --047d7b41443a34fdd90521eb5311 Content-Type: text/plain; charset=UTF-8 Hi Jon, I am back tracking a bit to elaborate the issue. A PCC at PE device advertises MSD based on its data plane capability. Network service instances can use PCReq to create a LSP. Since PE will add labels to identify the service instance, LSP with maximum stack-size is not acceptable. In such cases the PCRequest should specify the MSD metric values less than the MSD in Open message. Current draft says PCE should error if MSD metric is received for session that has non-zero MSD value. This should be addressed in pce-segment-routing draft. Example: PE device send MSD=10 in Open message. While setting up LSP For a service instance that uses 2 inner labels, the PCReq should specify MSD=8 (hop-count can not be used for stack-size constraint in seg-routing). Second issue (original email): My understanding is a management tool action will make the (Controller) PCE to send PCInit message to PCC at PE device. The draft does not preclude processing of PCInit message by (management) PCC. The (management) PCC will advertise pce-initiate-lsp support and MSD=0? The pce-intiated-lsp draft should clarify how MSD value are specified by (management)PCC. Thanks, Girish On Fri, Oct 9, 2015 at 8:59 AM, Jonathan Hardwick < Jonathan.Hardwick@metaswitch.com> wrote: > Hi Girish > > > > Thanks for the comment. I think your points are valid. We will add a > clarifying passage to the next version of draft-ietf-pce-segment-routing to > address this. > > > > Best regards > > Jon (as co-author of draft-ietf-pce-segment-routing) > > > > > > *From:* Girish Birajdar [mailto:girish134@gmail.com] > *Sent:* 01 October 2015 18:15 > *To:* draft-ietf-pce-pce-initiated-lsp@ietf.org > *Cc:* draft-ietf-pce-segment-routing@ietf.org > *Subject:* comments on draft-ietf-pce-pce-initiated-lsp > > > > Authors, > > This comment is specific to LSP initiate message and MSD value specified > in draft-ietf-pce-segment-routing. > > draft-ietf-pce-segment-routing "5.1.1.1. Exchanging SR Capability ... > > An MSD value of zero means that a PCC does > not impose any default limitation on the number of SIDs included in > any SR-TE path coming from PCE" > > draft-ietf-pce-pce-initiated-lsp does not mention MSD. Is it possible to cover few error cases that might have when PCEP session has MSD=0 and LSP Initiate message sends unacceptable label-stack size? > IMO, when PCC receives a LSP Initiate Message that exceeds its stack-size limit, an error message that specifies acceptable MSD value would be useful. > > Regards, > Girish > > > --047d7b41443a34fdd90521eb5311 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Jon,

I am back tracking a bit to= elaborate the issue.

A PCC at PE device advertises MSD based on its= data plane capability. Network service instances can use PCReq to create a= LSP. Since PE will add labels to identify the service instance, LSP with m= aximum stack-size is not acceptable. In such cases the PCRequest should spe= cify the MSD metric values less than the MSD in Open message. Current draft= says PCE should error if MSD metric is received for session that has non-z= ero MSD value. This should be addressed in pce-segment-routing draft.
Example:
PE device send MSD=3D10 in Open message.
While setting up LSP For a service instance that uses 2 inner l= abels, the PCReq should specify MSD=3D8 (hop-count can not be used for stac= k-size constraint in seg-routing).

Second issue (original= email):
My understanding is a management tool action will make the (Con= troller) PCE to send PCInit message to PCC at PE device. The draft does not= preclude processing of PCInit message by (management) PCC. The (management= ) PCC will advertise pce-initiate-lsp support and MSD=3D0? The pce-intiated= -lsp draft should clarify how MSD value are specified by (management)PCC.
Thanks,
Girish


On Fri, Oct 9, 2= 015 at 8:59 AM, Jonathan Hardwick <Jonathan.Hardwick@metasw= itch.com> wrote:

Hi Girish

=C2=A0

Thanks for the comment.=C2=A0 I think= your points are valid.=C2=A0 We will add a clarifying passage to the next = version of draft-ietf-pce-segment-routing to address this.

=C2=A0

Best regards

Jon (as co-author of draft-ietf-pce-s= egment-routing)

=C2=A0

=C2=A0

From: = Girish Birajdar [mailto:girish134@gmail.com]
Sent: 01 October 2015 18:15
To: draft-ietf-pce-pce-initiated-lsp@ietf.org
Cc: draft-ietf-pce-segment-routing@ietf.org
Subject: comments on draft-ietf-pce-pce-initiated-lsp<= /span>

=C2=A0

Authors,

This comment is specific to LSP initiate message and= MSD value specified in draft-ietf-pce-segment-routing.

draft-ietf-pce-segment-routing "5.1.1.1.=C2=A0 Exchanging SR Capabilit= y ...

An MSD value of zero = means that a PCC does
=C2=A0=C2=A0 not impose any default limitation on the number of SIDs includ= ed in
=C2=A0=C2=A0 any SR-TE path coming from PCE"

draft-ietf-pc=
e-pce-initiated-lsp does not mention MSD. Is it possible to cover few error=
 cases that might have when PCEP session has MSD=3D0 and LSP Initiate messa=
ge sends unacceptable label-stack size?
IMO, when PCC receives a LSP Ini=
tiate Message that exceeds its stack-size limit, an error message that spec=
ifies acceptable MSD value would be useful.
Regards,
G=
irish

=C2=A0


--047d7b41443a34fdd90521eb5311-- From nobody Mon Oct 12 12:03:10 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 597901B349E; Mon, 12 Oct 2015 12:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 Eke9mTgx0KMi; Mon, 12 Oct 2015 12:03:07 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C444E1B3493; Mon, 12 Oct 2015 12:03:07 -0700 (PDT) Received: by igbni9 with SMTP id ni9so44075353igb.1; Mon, 12 Oct 2015 12:03:07 -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=2R+LjQ42G6so1HNcgo9bSsZgqJ281BHEngOKT9Hft7o=; b=GZTUMWCNxfMJ7fXwNj2+zwazwrX8WUxmW4pryNMk3n2CzxPMGGlqpfL8aXjhNmJIYX BKv4OSjVTILTzXAFkIIAlzMBP8LCqNeI8HChWk+KKSa5CIyHBIDJWewow5AAgmMAQ4I1 /viCB3BjBveDOZ/lpAub4btkc+hH64Ji4QaXoECXi5v+1bPuzsYP3ZoAGUxIOkigLEvo fTEgKBYrjhQNw1+t75yf4nVMfq82fEBA8EKwFgUXgIsOcqNnGnJt9/93VC83lz3QoCXk mN2fdkbdLRX6thcqhfwWphY+eQdOU5bN28ghUXDuI6fszvAeWmdP2E9EiCP+P/PK3eKT L46w== MIME-Version: 1.0 X-Received: by 10.50.45.33 with SMTP id j1mr13452491igm.61.1444676587207; Mon, 12 Oct 2015 12:03:07 -0700 (PDT) Received: by 10.64.86.233 with HTTP; Mon, 12 Oct 2015 12:03:07 -0700 (PDT) In-Reply-To: <23CE718903A838468A8B325B80962F9B8C421A83@BLREML509-MBX.china.huawei.com> References: <23CE718903A838468A8B325B80962F9B8C421A83@BLREML509-MBX.china.huawei.com> Date: Mon, 12 Oct 2015 12:03:07 -0700 Message-ID: From: Girish Birajdar To: Dhruv Dhody Content-Type: multipart/alternative; boundary=089e0122f016cbc2c90521ecfaf8 Archived-At: Cc: "pce@ietf.org" , "draft-ietf-pce-stateful-pce@tools.ietf.org" , "pce-chairs@tools.ietf.org" , "draft-ietf-pce-segment-routing@ietf.org" Subject: Re: [Pce] Query on Usage of LSP Identifier TLV in SR X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 19:03:09 -0000 --089e0122f016cbc2c90521ecfaf8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable piggy backing on Dhruv email ... During PCUpdate for SR LSP - MBB process mentioned in draft-tanaka-pce-stateful-pce-mbb applicable? The MBB draft has expired, will it be incorporated in stateful-pce draft? Thanks, Girish On Sun, Oct 11, 2015 at 10:58 PM, Dhruv Dhody wrote: > Hi Authors, > > > > In the stateful PCE draft [1], it says =E2=80=93 > > The LSP Identifiers TLV MUST be included in the LSP object in PCRpt > > messages for RSVP-signaled LSPs. > > > > The SR draft [2] did not mention anything about LSP Identifier TLV. > > And in implementations that I am aware of, SR-TE LSP still uses the > LSP-Identifier TLV. Is that correct? (I personally think so!!) > > > > If yes, do you think there is a need to update =E2=80=93 > > - [1] to say all LSPs (and not just RSVP-signaled). > > - Or [2] to say that LSP-Identifier TLV are also applicable to SR > and MUST be included. > > > > Thanks! > > Dhruv > > > > > > [1] > https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-11#section-7.3.1 > > [2] http://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing/ > > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > --089e0122f016cbc2c90521ecfaf8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

piggy backing on Dhruv email ...<= br>
During PCUpdate for SR LSP -=C2=A0 MBB process mentioned in draft-ta= naka-pce-stateful-pce-mbb applicable? The MBB draft has expired, will it be= incorporated in stateful-pce draft?

Thanks,
Girish

On Sun, O= ct 11, 2015 at 10:58 PM, Dhruv Dhody <dhruv.dhody@huawei.com><= /span> wrote:

Hi Authors,

=C2=A0

In the stateful PCE draft [1], it says =E2=80=93=

The LSP= Identifiers TLV MUST be included in the LSP object in PCRpt<= /span>

message= s for RSVP-signaled LSPs.

=C2=A0

The SR draft [2] did not mention anything about LSP= Identifier TLV.

And in implementations that I am aware of, SR-TE LS= P still uses the LSP-Identifier TLV. Is that correct? (I personally think s= o!!)

=C2=A0

If yes, do you think there is a need to update =E2= =80=93

-= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [1] to say all LSPs (and not just RSVP-signale= d).

-= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Or [2] to say that LSP-Identifier TLV are also= applicable to SR and MUST be included.

=C2=A0

Thanks!

Dhruv

=C2=A0

=C2=A0

[1] https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-11#section-7.3.1

[2] http://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing/<= u>

=C2=A0


_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce


--089e0122f016cbc2c90521ecfaf8-- From nobody Mon Oct 12 12:55:46 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55BB31B35C0; Mon, 12 Oct 2015 12:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-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 ClSklflKMnbF; Mon, 12 Oct 2015 12:55:41 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0735.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:735]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEB0E1B35C6; Mon, 12 Oct 2015 12:55:40 -0700 (PDT) Received: from DM2PR02MB1356.namprd02.prod.outlook.com (10.161.143.13) by DM2PR02MB1353.namprd02.prod.outlook.com (10.161.142.28) with Microsoft SMTP Server (TLS) id 15.1.293.16; Mon, 12 Oct 2015 19:55:35 +0000 Received: from DM2PR02MB1356.namprd02.prod.outlook.com ([10.161.143.13]) by DM2PR02MB1356.namprd02.prod.outlook.com ([10.161.143.13]) with mapi id 15.01.0286.019; Mon, 12 Oct 2015 19:55:35 +0000 From: Jonathan Hardwick To: "draft-ietf-pce-pcep-domain-sequence@ietf.org" Thread-Topic: Last IPR check for draft-ietf-pce-pcep-domain-sequence Thread-Index: AdEFJzeyN8h2Ah05RWKXCuruMJQJRA== Date: Mon, 12 Oct 2015 19:55:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jonathan.Hardwick@metaswitch.com; x-originating-ip: [217.43.17.249] x-microsoft-exchange-diagnostics: 1; DM2PR02MB1353; 5:hKzIEDP7sN2Fw5CegRYJc3HDZqb1r0oVg6hVHvECGz86gwfnf3w9VAuGCb/+8jwJTvhnwstOtNdUD0ry+zgB8RW+2ayfqS/JQhVVQRcOnNOP8UqubY5VFOQTP5oKqwjucvhDdmPdeQpQ44x7OBzIYg==; 24:QOHpTOSfcwVZC8UejYfoYuNvVGhq6rxTGVE2XEGkoKP03mHPfTdcWBAErR7/b/nEXIUHeOqeBHVQ7nDEBVaX94ULVv6I7GyxN9yRLawibaE=; 20:RvTtDtkFBB9rhARytxKxHUWOkbKYqQJSAVeIWWeSuar6+XzCpLIaLle+TB5BgT/35CgImrHaVypOLydZ1/SkCw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR02MB1353; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001); SRVR:DM2PR02MB1353; BCL:0; PCL:0; RULEID:; SRVR:DM2PR02MB1353; x-forefront-prvs: 0727122FC6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(230783001)(122556002)(2900100001)(40100003)(19625215002)(86362001)(229853001)(5008740100001)(33656002)(74316001)(46102003)(92566002)(106356001)(11100500001)(5003600100002)(19300405004)(5004730100002)(19580395003)(87936001)(5007970100001)(16236675004)(54356999)(50986999)(5001920100001)(77096005)(10400500002)(76576001)(2501003)(5002640100001)(558084003)(64706001)(105586002)(110136002)(450100001)(66066001)(101416001)(189998001)(2351001)(15975445007)(102836002)(99286002)(5001960100002)(81156007)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR02MB1353; H:DM2PR02MB1356.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM2PR02MB13562C500521AD428468685D84310DM2PR02MB1356namp_" MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2015 19:55:34.7022 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR02MB1353 Archived-At: Cc: "pce@ietf.org" Subject: [Pce] Last IPR check for draft-ietf-pce-pcep-domain-sequence X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 19:55:45 -0000 --_000_DM2PR02MB13562C500521AD428468685D84310DM2PR02MB1356namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear authors, Has all IPR that applies to draft-ietf-pce-pcep-domain-sequence been disclo= sed in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669 and 5378 = for more details.) A response from each of you is required. Best regards, Jon, JP & Julien --_000_DM2PR02MB13562C500521AD428468685D84310DM2PR02MB1356namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear authors,

 

Has all IPR that applies to draft-ietf-pce-= pcep-domain-sequence been disclosed in compliance with IETF IPR rules? (See= RFCs 3979, 4879, 3669 and 5378 for more details.)

 

A response from each of you is required.

 

Best regards,

 

Jon, JP & Julien

 

 

--_000_DM2PR02MB13562C500521AD428468685D84310DM2PR02MB1356namp_-- From nobody Mon Oct 12 19:13:46 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8DF1B2F0D; Mon, 12 Oct 2015 19:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 DnImcfP4PSCK; Mon, 12 Oct 2015 19:13:43 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B37D1B2F0C; Mon, 12 Oct 2015 19:13:42 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYS67613; Tue, 13 Oct 2015 02:13:40 +0000 (GMT) Received: from BLREML406-HUB.china.huawei.com (10.20.4.43) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 13 Oct 2015 03:13:38 +0100 Received: from BLREML509-MBX.china.huawei.com ([169.254.7.243]) by BLREML406-HUB.china.huawei.com ([10.20.4.43]) with mapi id 14.03.0235.001; Tue, 13 Oct 2015 07:43:31 +0530 From: Dhruv Dhody To: Jonathan Hardwick , "draft-ietf-pce-pcep-domain-sequence@ietf.org" Thread-Topic: Last IPR check for draft-ietf-pce-pcep-domain-sequence Thread-Index: AdEFJzeyN8h2Ah05RWKXCuruMJQJRAANTQiA Date: Tue, 13 Oct 2015 02:13:30 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B8C42259A@BLREML509-MBX.china.huawei.com> References: In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.244.252] Content-Type: multipart/alternative; boundary="_000_23CE718903A838468A8B325B80962F9B8C42259ABLREML509MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "pce@ietf.org" Subject: Re: [Pce] Last IPR check for draft-ietf-pce-pcep-domain-sequence X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 02:13:45 -0000 --_000_23CE718903A838468A8B325B80962F9B8C42259ABLREML509MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Yes! ALL IPR has been disclosed. http://datatracker.ietf.org/ipr/1690/ Regards, Dhruv From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Jonathan Hardwick Sent: 13 October 2015 01:26 To: draft-ietf-pce-pcep-domain-sequence@ietf.org Cc: pce@ietf.org Subject: [Pce] Last IPR check for draft-ietf-pce-pcep-domain-sequence Dear authors, Has all IPR that applies to draft-ietf-pce-pcep-domain-sequence been disclo= sed in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669 and 5378 = for more details.) A response from each of you is required. Best regards, Jon, JP & Julien --_000_23CE718903A838468A8B325B80962F9B8C42259ABLREML509MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Yes! ALL IPR has been disclosed.

http://datatracker.ietf.org/ipr/1690/

 

Regards,

Dhruv

 

From: Pce [mai= lto:pce-bounces@ietf.org] On Behalf Of Jonathan Hardwick
Sent: 13 October 2015 01:26
To: draft-ietf-pce-pcep-domain-sequence@ietf.org
Cc: pce@ietf.org
Subject: [Pce] Last IPR check for draft-ietf-pce-pcep-domain-sequenc= e

 

Dear authors,

 

Has all IPR that applies to draft-ietf-pce-= pcep-domain-sequence been disclosed in compliance with IETF IPR rules? (See= RFCs 3979, 4879, 3669 and 5378 for more details.)

 

A response from each of you is required.

 

Best regards,

 

Jon, JP & Julien

 

 

--_000_23CE718903A838468A8B325B80962F9B8C42259ABLREML509MBXchi_-- From nobody Mon Oct 12 21:48:02 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCFEA1AD0C8; Mon, 12 Oct 2015 21:47:58 -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 IhJK0PnWwtvw; Mon, 12 Oct 2015 21:47:56 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D0831A1F02; Mon, 12 Oct 2015 21:47:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYS77632; Tue, 13 Oct 2015 04:47:53 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.218.25.36) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 13 Oct 2015 05:47:52 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.220]) by SJCEML703-CHM.china.huawei.com ([169.254.5.225]) with mapi id 14.03.0235.001; Mon, 12 Oct 2015 21:47:49 -0700 From: Quintin zhao To: "jonathan.hardwick@metaswitch.com" , "jpv@cisco.com" , "julien.meuric@orange.com" , Lou Berger , "draft-zhao-pce-central-controller-user-cases@ietf.org" Thread-Topic: Home for "PCE as Central Controller" Thread-Index: AQHRAorOyfhzPPc4IEiTsLEUWrAVs55nDyKg Date: Tue, 13 Oct 2015 04:47:48 +0000 Message-ID: <11208E03C9803E4CB4C3D898F153D6C0390D9AC1@SJCEML701-CHM.china.huawei.com> References: <4439_1444392244_5617AD34_4439_7180_1_5617AD33.3000309@orange.com> In-Reply-To: <4439_1444392244_5617AD34_4439_7180_1_5617AD33.3000309@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.2.43] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "pce@ietf.org" , "teas@ietf.org" Subject: Re: [Pce] Home for "PCE as Central Controller" X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 04:47:59 -0000 RGVhciBKb24sIEpQLCBKdWxpZW4sIGFuZCBMb3UsDQoNClRoYW5rcyBmb3IgeW91ciBzdWdnZXN0 aW9ucyByZWdhcmRpbmcgdGhlIGhvbWUgZm9yICJQQ0UgYXMgQ2VudHJhbCBDb250cm9sbGVyIiBh bmQgd2UgYWdyZWUgd2l0aCB5b3UgdG8gZGlzY3VzcyB0aGUgUENFLUNDIHJlbGF0ZWQgcmVxdWly ZW1lbnRzL3VzZS1jYXNlcy9hcmNoaXRlY3R1cmUgaW4gdGhlIFRFQVMgd29ya2luZyBncm91cCBh bmQgdG8gZGlzY3VzcyB0aGUgUENFLUNDIHJlbGF0ZWQgUENFIGV4dGVuc2lvbnMgaW4gdGhlIFBD RSB3b3JraW5nIGdyb3VwLg0KDQpXZSB3aWxsIGNvbGxhYm9yYXRlIHdpdGggdGhlIGNvLWF1dGhv cnMgb2YgQUNUTiByZWxhdGVkIGRyYWZ0cyB0byBpZGVudGlmeSB0aGUgb3ZlcmxhcHBpbmcgYW5k IGdhcHMgYmV0d2VlbiBBQ1ROIGFuZCBQQ0UtQ0MuIFdlIHdpbGwgcHJlc2VudCB0aGVzZSB0byB0 aGUgVEVBUyB3b3JraW5nIGdyb3VwIGFuZCBoYXZlIGRpc2N1c3Npb25zIG9uIGl0IGR1cmluZyB0 aGUgaW5jb21pbmcgSUVURjk0IG1lZXRpbmcuIA0KDQpUaGFua3MgYWdhaW4gYW5kIHNlZSB5b3Ug aW4gWW9rb2hhbWEhDQoNClF1aW50aW4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IGp1bGllbi5tZXVyaWNAb3JhbmdlLmNvbSBbbWFpbHRvOmp1bGllbi5tZXVyaWNAb3Jhbmdl LmNvbV0gDQpTZW50OiAyMDE15bm0MTDmnIg55pelIDg6MDQNClRvOiBkcmFmdC16aGFvLXBjZS1w Y2VwLWV4dGVuc2lvbi1mb3ItcGNlLWNvbnRyb2xsZXJAaWV0Zi5vcmc7IGRyYWZ0LXpoYW8tcGNl LWNlbnRyYWwtY29udHJvbGxlci11c2VyLWNhc2VzQGlldGYub3JnDQpDYzogcGNlQGlldGYub3Jn OyB0ZWFzQGlldGYub3JnDQpTdWJqZWN0OiBIb21lIGZvciAiUENFIGFzIENlbnRyYWwgQ29udHJv bGxlciINCg0KRGVhciBhdXRob3JzIG9mIFBDRS1DQyBJLURzLA0KDQpXZSBhcmUgZm9sbG93aW5n IHVwIG9uIExvdSdzICh2ZXJ5IGxhc3QgbWludXRlIDstKSApIGNvbW1lbnQgZHVyaW5nIHRoZSBQ Q0UgbWVldGluZyBpbiBQcmFndWUuIFRoZSBURUFTIFdHIGhhcyBqdXN0IGVuZG9yc2VkIGFzIFdH IGl0ZW0gdGhlICJBQ1ROIiB3b3JrLCAocXVvdGluZyB0aGUgcmVxdWlyZW1lbnQgSS1EKSAic28g YXMgdG8gZmFjaWxpdGF0ZSBuZXR3b3JrIHByb2dyYW1tYWJpbGl0eSwgYXV0b21hdGlvbiwgZWZm aWNpZW50IHJlc291cmNlIHNoYXJpbmcsIGFuZCBlbmQtdG8tZW5kIHZpcnR1YWwgc2VydmljZSBh d2FyZSBjb25uZWN0aXZpdHkgYW5kIG5ldHdvcmsgZnVuY3Rpb24gdmlydHVhbGl6YXRpb24gc2Vy dmljZXMiLiBBIHNpZ25pZmljYW50IHBhcnQgb2YgdGhlIFBDRS1DQyBwcm9wb3NhbCBtYXkgZmFs bCB1bmRlciB0aGlzIHVtYnJlbGxhLiBBcyBhIHJlc3VsdCwgd2Ugd291bGQgbGlrZSB0byBzZWUg dGhlIHJlbGF0ZWQgcmVxdWlyZW1lbnRzL3VzZS1jYXNlcy9hcmNoaXRlY3R1cmUgZGlzY3Vzc2Vk IGZpcnN0IHdpdGhpbiBURUFTLCB0aGUgUENFIFdHIHJlbWFpbmluZyAob2J2aW91c2x5KSBpbiBj aGFyZ2Ugb2YgYW55IGlkZW50aWZpZWQgUENFUCBleHRlbnNpb25zLg0KDQpGZWVsIGZyZWUgdG8g Y29udGFjdHMgdGhlIFBDRSBhbmQvb3IgVEVBUyBjaGFpcnMgaWYgc29tZSBjbGFyaWZpY2F0aW9u cyBvbiB0aGUgcmVzcGVjdGl2ZSBjaGFydGVycyBvZiB0aGUgV0dzIGFyZSBuZWVkZWQuDQoNClRo YW5rcywNCg0KSm9uLCBKUCAmIEp1bGllbg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KQ2UgbWVzc2FnZSBldCBz ZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZp ZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlIGRp ZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2 ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyIGEgbCdl eHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExl cyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24s IE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUg YWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KVGhpcyBtZXNzYWdlIGFuZCBp dHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5m b3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90IGJl IGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQpJZiB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCkFzIGVt YWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRo YXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NClRoYW5rIHlvdS4N Cg0K From nobody Mon Oct 12 23:33:05 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C961B2A5C for ; Mon, 12 Oct 2015 23:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 bthsQbZbE_LA for ; Mon, 12 Oct 2015 23:33:02 -0700 (PDT) Received: from villa.puc.rediris.es (villa.puc.rediris.es [IPv6:2001:720:418:ca00::7]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 878D61ACE73 for ; Mon, 12 Oct 2015 23:33:02 -0700 (PDT) Received: from [84.88.62.208] (helo=leo) by villa.puc.rediris.es with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1Zlt8k-0001zJ-5R for pce@ietf.org; Tue, 13 Oct 2015 08:32:54 +0200 Received: from [84.88.61.50] (unknown [84.88.61.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by leo (Postfix) with ESMTPSA id CBD631FE32 for ; Tue, 13 Oct 2015 08:32:46 +0200 (CEST) X-Envelope-From: ramon.casellas@cttc.es To: pce@ietf.org References: From: Ramon Casellas Message-ID: <561CA590.7010709@cttc.es> Date: Tue, 13 Oct 2015 08:32:48 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------070402080302080500030008" X-Spamina-Bogosity: Unsure X-Spamina-Spam-Score: -2.9 (--) X-Spamina-Spam-Report: Content analysis details: (-2.9 points) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: ietf.org] -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0088] 0.0 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [Pce] Last IPR check for draft-ietf-pce-pcep-domain-sequence X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 06:33:04 -0000 This is a multi-part message in MIME format. --------------070402080302080500030008 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit El 12/10/2015 a las 21:55, Jonathan Hardwick escribió: > > Dear authors, > > Has all IPR that applies to draft-ietf-pce-pcep-domain-sequence been > disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879, > 3669 and 5378 for more details.) > Dear Jon, all AFAIK, all IPR has been disclosed (http://datatracker.ietf.org/ipr/1690/) by its owners. I am not aware of any other IPR that applies to the draft. Thanks Ramon --------------070402080302080500030008 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
El 12/10/2015 a las 21:55, Jonathan Hardwick escribió:

Dear authors,

 

Has all IPR that applies to draft-ietf-pce-pcep-domain-sequence been disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669 and 5378 for more details.)

 

Dear Jon, all

AFAIK, all IPR has been disclosed (http://datatracker.ietf.org/ipr/1690/) by its owners. I am not aware of any other IPR that applies to the draft.

Thanks
Ramon

--------------070402080302080500030008-- From nobody Tue Oct 13 02:07:57 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECC641A1EF6; Tue, 13 Oct 2015 02:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.106 X-Spam-Level: X-Spam-Status: No, score=0.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HELO_EQ_FR=0.35, SPF_SOFTFAIL=0.665, T_RP_MATCHES_RCVD=-0.01] 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 7Gl1x-3-KT-k; Tue, 13 Oct 2015 02:07:54 -0700 (PDT) Received: from p-mail2.rd.orange.com (p-mail2.rd.orange.com [161.106.1.3]) by ietfa.amsl.com (Postfix) with ESMTP id 797D41A1EF1; Tue, 13 Oct 2015 02:07:54 -0700 (PDT) Received: from p-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 90CC5E300A4; Tue, 13 Oct 2015 11:07:53 +0200 (CEST) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail2.rd.orange.com (Postfix) with ESMTP id 81C25E30096; Tue, 13 Oct 2015 11:07:53 +0200 (CEST) Received: from [10.193.71.204] (10.193.71.204) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.224.2; Tue, 13 Oct 2015 11:07:52 +0200 To: Girish Birajdar References: <23CE718903A838468A8B325B80962F9B8C421A83@BLREML509-MBX.china.huawei.com> From: Julien Meuric Organization: Orange Message-ID: <561CC9E9.1060401@orange.com> Date: Tue, 13 Oct 2015 11:07:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "draft-ietf-pce-stateful-pce@tools.ietf.org" , "pce@ietf.org" , "draft-ietf-pce-segment-routing@ietf.org" Subject: Re: [Pce] Query on Usage of LSP Identifier TLV in SR X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 09:07:56 -0000 Hi Girish, Due to the very different levels of maturity between stateful-pce and MBB I-Ds, we do not see them merging. MBB I-D was very briefly discussed on the list a while ago, we do not know what the plans of the authors are... Regards, Julien Oct. 12, 2015 - girish134@gmail.com: > > piggy backing on Dhruv email ... > > During PCUpdate for SR LSP - MBB process mentioned in > draft-tanaka-pce-stateful-pce-mbb applicable? The MBB draft has > expired, will it be incorporated in stateful-pce draft? > > Thanks, > Girish > > On Sun, Oct 11, 2015 at 10:58 PM, Dhruv Dhody > wrote: > > Hi Authors, > > In the stateful PCE draft [1], it says – > > The LSP Identifiers TLV MUST be included in the LSP object in PCRpt > > messages for RSVP-signaled LSPs. > > The SR draft [2] did not mention anything about LSP Identifier TLV. > > And in implementations that I am aware of, SR-TE LSP still uses > the LSP-Identifier TLV. Is that correct? (I personally think so!!) > > If yes, do you think there is a need to update – > > -[1] to say all LSPs (and not just RSVP-signaled). > > -Or [2] to say that LSP-Identifier TLV are also applicable to SR > and MUST be included. > > Thanks! > > Dhruv > > [1] > https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-11#section-7.3.1 > > [2] http://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing/ > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From nobody Tue Oct 13 03:40:31 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8D0A1A90F4; Tue, 13 Oct 2015 03:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 gev-rSwMcIRE; Tue, 13 Oct 2015 03:40:22 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39F6D1A90EF; Tue, 13 Oct 2015 03:40:22 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CCM35566; Tue, 13 Oct 2015 10:40:19 +0000 (GMT) Received: from SZXEML434-HUB.china.huawei.com (10.82.67.225) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 13 Oct 2015 11:40:19 +0100 Received: from SZXEML522-MBX.china.huawei.com ([169.254.2.85]) by szxeml434-hub.china.huawei.com ([10.82.67.225]) with mapi id 14.03.0235.001; Tue, 13 Oct 2015 18:39:05 +0800 From: Udayasree palle To: Jonathan Hardwick , "draft-ietf-pce-pcep-domain-sequence@ietf.org" Thread-Topic: Last IPR check for draft-ietf-pce-pcep-domain-sequence Thread-Index: AdEFJzeyN8h2Ah05RWKXCuruMJQJRAAfB0bA Date: Tue, 13 Oct 2015 10:39:04 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.241.144] Content-Type: multipart/alternative; boundary="_000_EFF3DD5FFB75AC4D89158F068C24F4BB41C6019Bszxeml522mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "pce@ietf.org" Subject: Re: [Pce] Last IPR check for draft-ietf-pce-pcep-domain-sequence X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 10:40:30 -0000 --_000_EFF3DD5FFB75AC4D89158F068C24F4BB41C6019Bszxeml522mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes. All IPRs has been disclosed Regards, Udaya From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Jonathan Hardwick Sent: 13 October 2015 01:26 To: draft-ietf-pce-pcep-domain-sequence@ietf.org Cc: pce@ietf.org Subject: [Pce] Last IPR check for draft-ietf-pce-pcep-domain-sequence Dear authors, Has all IPR that applies to draft-ietf-pce-pcep-domain-sequence been disclo= sed in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669 and 5378 = for more details.) A response from each of you is required. Best regards, Jon, JP & Julien --_000_EFF3DD5FFB75AC4D89158F068C24F4BB41C6019Bszxeml522mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes. All IPRs has been= disclosed

 

Regards,

Udaya

 

From: Pce [mai= lto:pce-bounces@ietf.org] On Behalf Of Jonathan Hardwick
Sent: 13 October 2015 01:26
To: draft-ietf-pce-pcep-domain-sequence@ietf.org
Cc: pce@ietf.org
Subject: [Pce] Last IPR check for draft-ietf-pce-pcep-domain-sequenc= e

 

Dear authors,

 

Has all IPR that applies to draft-ietf-pce-= pcep-domain-sequence been disclosed in compliance with IETF IPR rules? (See= RFCs 3979, 4879, 3669 and 5378 for more details.)

 

A response from each of you is required.

 

Best regards,

 

Jon, JP & Julien

 

 

--_000_EFF3DD5FFB75AC4D89158F068C24F4BB41C6019Bszxeml522mbxchi_-- From nobody Tue Oct 13 04:02:26 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B39B61A924A; Tue, 13 Oct 2015 04:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 HhOLz8z-5WuF; Tue, 13 Oct 2015 04:02:18 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E1261A916C; Tue, 13 Oct 2015 04:02:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYT22985; Tue, 13 Oct 2015 11:02:15 +0000 (GMT) Received: from SZXEML432-HUB.china.huawei.com (10.82.67.209) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 13 Oct 2015 12:02:13 +0100 Received: from SZXEML522-MBX.china.huawei.com ([169.254.2.85]) by szxeml432-hub.china.huawei.com ([10.82.67.209]) with mapi id 14.03.0235.001; Tue, 13 Oct 2015 19:02:07 +0800 From: Udayasree palle To: Jonathan Hardwick , "draft-ietf-pce-pcep-domain-sequence@ietf.org" Thread-Topic: Last IPR check for draft-ietf-pce-pcep-domain-sequence Thread-Index: AdEFJzeyN8h2Ah05RWKXCuruMJQJRAAf0/oA Date: Tue, 13 Oct 2015 11:02:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.241.144] Content-Type: multipart/alternative; boundary="_000_EFF3DD5FFB75AC4D89158F068C24F4BB41C601ADszxeml522mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "pce@ietf.org" Subject: Re: [Pce] Last IPR check for draft-ietf-pce-pcep-domain-sequence X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 11:02:24 -0000 --_000_EFF3DD5FFB75AC4D89158F068C24F4BB41C601ADszxeml522mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes . All IPRs has been disclosed http://datatracker.ietf.org/ipr/1690/) Regards, Udaya From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Jonathan Hardwick Sent: 13 October 2015 01:26 To: draft-ietf-pce-pcep-domain-sequence@ietf.org Cc: pce@ietf.org Subject: [Pce] Last IPR check for draft-ietf-pce-pcep-domain-sequence Dear authors, Has all IPR that applies to draft-ietf-pce-pcep-domain-sequence been disclo= sed in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669 and 5378 = for more details.) A response from each of you is required. Best regards, Jon, JP & Julien --_000_EFF3DD5FFB75AC4D89158F068C24F4BB41C601ADszxeml522mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes .= All IPRs has been disclosed http://datatracker.ietf.org/ipr/1690/)=

 

Regards,=

Udaya

=  

From: Pce [mai= lto:pce-bounces@ietf.org] On Behalf Of Jonathan Hardwick
Sent: 13 October 2015 01:26
To: draft-ietf-pce-pcep-domain-sequence@ietf.org
Cc: pce@ietf.org
Subject: [Pce] Last IPR check for draft-ietf-pce-pcep-domain-sequenc= e

 

Dear authors,

 

Has all IPR that applies to draft-ietf-pce-= pcep-domain-sequence been disclosed in compliance with IETF IPR rules? (See= RFCs 3979, 4879, 3669 and 5378 for more details.)

 

A response from each of you is required.

 

Best regards,

 

Jon, JP & Julien

 

 

--_000_EFF3DD5FFB75AC4D89158F068C24F4BB41C601ADszxeml522mbxchi_-- From nobody Tue Oct 13 05:25:18 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6806E1B2FC3; Tue, 13 Oct 2015 05:25:16 -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 dT7fppnIYMY0; Tue, 13 Oct 2015 05:25:15 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA7C31B2FBB; Tue, 13 Oct 2015 05:25:14 -0700 (PDT) Received: by ioii196 with SMTP id i196so18529109ioi.3; Tue, 13 Oct 2015 05:25:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=/JmgQk/G2V4/CRo15ubSy/luakqltBdp9FVVxV7oz9M=; b=AQe+pY06/Ymq+ijahM6A2fCJx2w75QVgq5P4i5+2tn1K8nWgbJW71R3pSgwO/GuUhx ozV8EaozUxAxEVRY8YJN4EFnXyt60MINHBnye0TKNamShC/91n4R2hBLTEKnzjnPz1Bz urC9w7IRjFATlxioH4OMl6uA8X/G/anVZk6tT1Rh5zkFGCTj0I225rT9kLpXUAt5qh7n vwDQyJO9quATT1qu1KE5Uqjs71ciyCuTpKmFPctFjpew0nBUqrqFgXOb2mmJvh3WPXvI CcHNW/lqnBtT1GFWlkALgwQsIHE1Td5sd/Ur0xRKTY4JsrzW9j/9daxmWn4PI0RDnOPC 2/eA== MIME-Version: 1.0 X-Received: by 10.107.17.234 with SMTP id 103mr33973640ior.21.1444739114074; Tue, 13 Oct 2015 05:25:14 -0700 (PDT) Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.103.105 with HTTP; Tue, 13 Oct 2015 05:25:13 -0700 (PDT) In-Reply-To: <561CC9E9.1060401@orange.com> References: <23CE718903A838468A8B325B80962F9B8C421A83@BLREML509-MBX.china.huawei.com> <561CC9E9.1060401@orange.com> Date: Tue, 13 Oct 2015 17:55:13 +0530 X-Google-Sender-Auth: MzV2d98Tp3cNFnAqHJF6XZ8UNzg Message-ID: From: Dhruv Dhody To: Julien Meuric Content-Type: multipart/alternative; boundary=001a113f59d8b006a70521fb8979 Archived-At: Cc: "pce@ietf.org" , "draft-ietf-pce-stateful-pce@tools.ietf.org" , "draft-ietf-pce-segment-routing@ietf.org" Subject: Re: [Pce] Query on Usage of LSP Identifier TLV in SR X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 12:25:16 -0000 --001a113f59d8b006a70521fb8979 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Julien, Girish, Speaking as one of the authors of MBB draft[1], IMHO we need to re-spin the draft based on the generic association draft [2] once it is adopted by the WG. And as Julien said, there won't be any "merging"! BTW the original question in the thread still stands! Regards, Dhruv [1] https://www.ietf.org/archive/id/draft-tanaka-pce-stateful-pce-mbb-03.tx= t [2] https://tools.ietf.org/html/draft-minei-pce-association-group-03 On Tue, Oct 13, 2015 at 2:37 PM, Julien Meuric wrote: > Hi Girish, > > Due to the very different levels of maturity between stateful-pce and MBB > I-Ds, we do not see them merging. MBB I-D was very briefly discussed on t= he > list a while ago, we do not know what the plans of the authors are... > > Regards, > > Julien > > > Oct. 12, 2015 - girish134@gmail.com: > >> >> piggy backing on Dhruv email ... >> >> During PCUpdate for SR LSP - MBB process mentioned in >> draft-tanaka-pce-stateful-pce-mbb applicable? The MBB draft has expired, >> will it be incorporated in stateful-pce draft? >> >> Thanks, >> Girish >> >> On Sun, Oct 11, 2015 at 10:58 PM, Dhruv Dhody > > wrote: >> >> Hi Authors, >> >> In the stateful PCE draft [1], it says =E2=80=93 >> >> The LSP Identifiers TLV MUST be included in the LSP object in PCRpt >> >> messages for RSVP-signaled LSPs. >> >> The SR draft [2] did not mention anything about LSP Identifier TLV. >> >> And in implementations that I am aware of, SR-TE LSP still uses >> the LSP-Identifier TLV. Is that correct? (I personally think so!!) >> >> If yes, do you think there is a need to update =E2=80=93 >> >> -[1] to say all LSPs (and not just RSVP-signaled). >> >> -Or [2] to say that LSP-Identifier TLV are also applicable to SR >> and MUST be included. >> >> Thanks! >> >> Dhruv >> >> [1] >> >> https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-11#section-7.3.1 >> >> [2] http://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing/ >> >> >> _______________________________________________ >> Pce mailing list >> Pce@ietf.org >> https://www.ietf.org/mailman/listinfo/pce >> >> >> >> >> _______________________________________________ >> Pce mailing list >> Pce@ietf.org >> https://www.ietf.org/mailman/listinfo/pce >> > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > --001a113f59d8b006a70521fb8979 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Julien, Girish,=C2=A0

Spe= aking as one of the authors of MBB draft[1], IMHO we need to re-spin the dr= aft based on the generic association draft [2] once it is adopted by the WG= .

And as Julien said, there won't be any "merging"!=C2=A0

BT= W the original question in the thread still stands!=C2=A0

Regards,
<= div class=3D"gmail_default" style=3D"font-family:'trebuchet ms',san= s-serif;color:rgb(76,17,48)">Dhruv

=
[1]=C2=A0https://www.ietf.org= /archive/id/draft-tanaka-pce-stateful-pce-mbb-03.txt
[2]=C2=A0https://tools.ietf.org/html/draft-minei-pce-ass= ociation-group-03

On Tue, Oct 13, 2015 at 2:37 PM, Julien Meuric = <julien.me= uric@orange.com> wrote:
Hi = Girish,

Due to the very different levels of maturity between stateful-pce and MBB I= -Ds, we do not see them merging. MBB I-D was very briefly discussed on the = list a while ago, we do not know what the plans of the authors are...

Regards,

Julien


Oct. 12, 2015 - gi= rish134@gmail.com:

piggy backing on Dhruv email ...

During PCUpdate for SR LSP -=C2=A0 MBB process mentioned in draft-tanaka-pc= e-stateful-pce-mbb applicable? The MBB draft has expired, will it be incorp= orated in stateful-pce draft?

Thanks,
Girish

 On Sun, Oct 11, 2015 at 10:58 PM, Dhruv Dhody <dhruv.dhody@huawei.com <mailto:dhruv.dhody@huawe= i.com>> wrote:

=C2=A0 =C2=A0 Hi Authors,

=C2=A0 =C2=A0 In the stateful PCE draft [1], it says =E2=80=93

=C2=A0 =C2=A0 The LSP Identifiers TLV MUST be included in the LSP object in= PCRpt

=C2=A0 =C2=A0 messages for RSVP-signaled LSPs.

=C2=A0 =C2=A0 The SR draft [2] did not mention anything about LSP Identifie= r TLV.

=C2=A0 =C2=A0 And in implementations that I am aware of, SR-TE LSP still us= es
=C2=A0 =C2=A0 the LSP-Identifier TLV. Is that correct? (I personally think = so!!)

=C2=A0 =C2=A0 If yes, do you think there is a need to update =E2=80=93

=C2=A0 =C2=A0 -[1] to say all LSPs (and not just RSVP-signaled).

 =C2=A0 =C2=A0 -Or [2] to say that LSP-Identifier TLV are also applicable to= SR
=C2=A0 =C2=A0 and MUST be included.

=C2=A0 =C2=A0 Thanks!

=C2=A0 =C2=A0 Dhruv

=C2=A0 =C2=A0 [1]
=C2=A0 =C2=A0 https://tools.= ietf.org/html/draft-ietf-pce-stateful-pce-11#section-7.3.1

=C2=A0 =C2=A0 [2] http://datatracker.= ietf.org/doc/draft-ietf-pce-segment-routing/


=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 Pce mailing list
 =C2=A0 =C2=A0 Pce@ietf.or= g <mailto:Pce@ietf= .org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/pce=




_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

--001a113f59d8b006a70521fb8979-- From nobody Thu Oct 15 18:51:41 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3BB91B29D8; Thu, 15 Oct 2015 18:51:38 -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 ZaWSwfsFTsWK; Thu, 15 Oct 2015 18:51:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BB15C1B29D0; Thu, 15 Oct 2015 18:51:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151016015137.23318.88531.idtracker@ietfa.amsl.com> Date: Thu, 15 Oct 2015 18:51:37 -0700 Archived-At: Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-pcep-stateful-pce-gmpls-04.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 01:51:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Path Computation Element (PCE) Protocol Extensions for Stateful PCE Usage in GMPLS-controlled Networks Authors : Xian Zhang Young Lee Fatai Zhang Ramon Casellas Oscar Gonzalez de Dios Zafar Ali Filename : draft-ietf-pce-pcep-stateful-pce-gmpls-04.txt Pages : 13 Date : 2015-10-15 Abstract: The Path Computation Element (PCE) facilitates Traffic Engineering (TE) based path calculation in large, multi-domain, multi-region, or multi-layer networks. The PCE communication Protocol (PCEP) has been extended to support stateful PCE functions where the PCE retains information about the paths already present in the network, but those extensions are technology-agnostic. This memo provides extensions required for PCEP so as to enable the usage of a stateful PCE capability in GMPLS-controlled networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-stateful-pce-gmpls/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-pce-pcep-stateful-pce-gmpls-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-stateful-pce-gmpls-04 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 Oct 15 19:17:31 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECA8A1B2A6B for ; Thu, 15 Oct 2015 19:17:29 -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 6XWm8QTSKdEp for ; Thu, 15 Oct 2015 19:17:27 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46FDA1B2A54 for ; Thu, 15 Oct 2015 19:17:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CCP56161; Fri, 16 Oct 2015 02:17:25 +0000 (GMT) Received: from SZXEMA414-HUB.china.huawei.com (10.82.72.73) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 16 Oct 2015 03:17:24 +0100 Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.78]) by SZXEMA414-HUB.china.huawei.com ([10.82.72.73]) with mapi id 14.03.0235.001; Fri, 16 Oct 2015 10:17:18 +0800 From: "Zhangxian (Xian)" To: PCE WG List Thread-Topic: [Pce] I-D Action: draft-ietf-pce-pcep-stateful-pce-gmpls-04.txt Thread-Index: AQHRB7VKWyBfTtdx1kaUDAAvjzwG/Z5tW2yA Date: Fri, 16 Oct 2015 02:17:17 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.104.209] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Pce] FW: I-D Action: draft-ietf-pce-pcep-stateful-pce-gmpls-04.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 02:17:30 -0000 SGksIEFsbCwgDQoNCiAgICBUaGUgZHJhZnQgdmVyc2lvbiBpbmNsdWRlcyB0aGUgZm9sbG93aW5n IChtaW5vcikgdXBkYXRlczogIA0KMSkgYWRkaW5nIGEgY2xhcmlmaWNhdGlvbiBzZW50ZW5jZSwg c2VlIFsxXSBmb3IgZGV0YWlsczsNCjIpIGV4cGFuZCB0aGUgdGV4dCBpbiB0aGUgc2VjdXJpdHkg c2VjdGlvbi4gDQoNCiAgIFRoZSBhdXRob3JzIGNvbnNpZGVyIHRoaXMgZHJhZnQgbm93IHN0YWJs ZSBhbmQgcmVhZHkgZm9yIFdHIExDLg0KDQpSZWdhcmRzLA0KWGlhbiBvbiBiZWhhbGYgb2YgYWxs IGF1dGhvcnMNCg0KWzFdOiBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3Bj ZS9FVkR1c002b25Ld1lPMTY3aVdpX0hvc3A3RzQNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IFBjZSBbbWFpbHRvOnBjZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQpTZW50OiAyMDE1xOoxMNTCMTbI1SA5OjUyDQpUbzog aS1kLWFubm91bmNlQGlldGYub3JnDQpDYzogcGNlQGlldGYub3JnDQpTdWJqZWN0OiBbUGNlXSBJ LUQgQWN0aW9uOiBkcmFmdC1pZXRmLXBjZS1wY2VwLXN0YXRlZnVsLXBjZS1nbXBscy0wNC50eHQN Cg0KDQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJ bnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQogVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBv ZiB0aGUgUGF0aCBDb21wdXRhdGlvbiBFbGVtZW50IFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYu DQoNCiAgICAgICAgVGl0bGUgICAgICAgICAgIDogUGF0aCBDb21wdXRhdGlvbiBFbGVtZW50IChQ Q0UpIFByb3RvY29sIEV4dGVuc2lvbnMgZm9yIFN0YXRlZnVsIFBDRSBVc2FnZSBpbiBHTVBMUy1j b250cm9sbGVkIE5ldHdvcmtzDQogICAgICAgIEF1dGhvcnMgICAgICAgICA6IFhpYW4gWmhhbmcN CiAgICAgICAgICAgICAgICAgICAgICAgICAgWW91bmcgTGVlDQogICAgICAgICAgICAgICAgICAg ICAgICAgIEZhdGFpIFpoYW5nDQogICAgICAgICAgICAgICAgICAgICAgICAgIFJhbW9uIENhc2Vs bGFzDQogICAgICAgICAgICAgICAgICAgICAgICAgIE9zY2FyIEdvbnphbGV6IGRlIERpb3MNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgWmFmYXIgQWxpDQoJRmlsZW5hbWUgICAgICAgIDogZHJh ZnQtaWV0Zi1wY2UtcGNlcC1zdGF0ZWZ1bC1wY2UtZ21wbHMtMDQudHh0DQoJUGFnZXMgICAgICAg ICAgIDogMTMNCglEYXRlICAgICAgICAgICAgOiAyMDE1LTEwLTE1DQoNCkFic3RyYWN0Og0KICAg VGhlIFBhdGggQ29tcHV0YXRpb24gRWxlbWVudCAoUENFKSBmYWNpbGl0YXRlcyBUcmFmZmljIEVu Z2luZWVyaW5nDQogICAoVEUpIGJhc2VkIHBhdGggY2FsY3VsYXRpb24gaW4gbGFyZ2UsIG11bHRp LWRvbWFpbiwgbXVsdGktcmVnaW9uLCBvcg0KICAgbXVsdGktbGF5ZXIgbmV0d29ya3MuIFRoZSBQ Q0UgY29tbXVuaWNhdGlvbiBQcm90b2NvbCAoUENFUCkgaGFzIGJlZW4NCiAgIGV4dGVuZGVkIHRv IHN1cHBvcnQgc3RhdGVmdWwgUENFIGZ1bmN0aW9ucyB3aGVyZSB0aGUgUENFIHJldGFpbnMNCiAg IGluZm9ybWF0aW9uIGFib3V0IHRoZSBwYXRocyBhbHJlYWR5IHByZXNlbnQgaW4gdGhlIG5ldHdv cmssIGJ1dA0KICAgdGhvc2UgZXh0ZW5zaW9ucyBhcmUgdGVjaG5vbG9neS1hZ25vc3RpYy4gVGhp cyBtZW1vIHByb3ZpZGVzDQogICBleHRlbnNpb25zIHJlcXVpcmVkIGZvciBQQ0VQIHNvIGFzIHRv IGVuYWJsZSB0aGUgdXNhZ2Ugb2YgYSBzdGF0ZWZ1bA0KICAgUENFIGNhcGFiaWxpdHkgaW4gR01Q TFMtY29udHJvbGxlZCBuZXR3b3Jrcy4NCg0KDQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMg cGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtcGNlLXBjZXAtc3RhdGVmdWwtcGNlLWdtcGxzLw0KDQpUaGVyZSdzIGFsc28g YSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLXBjZS1wY2VwLXN0YXRlZnVsLXBjZS1nbXBscy0wNA0KDQpBIGRpZmYg ZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQpodHRwczovL3d3dy5p ZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1wY2UtcGNlcC1zdGF0ZWZ1bC1wY2UtZ21w bHMtMDQNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0 ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lv biBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpJbnRlcm5ldC1E cmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQpmdHA6Ly9mdHAu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KUGNlIG1haWxpbmcgbGlzdA0KUGNlQGlldGYub3JnDQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BjZQ0K From nobody Fri Oct 16 07:40:47 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B9181B2CA8; Fri, 16 Oct 2015 07:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.894 X-Spam-Level: X-Spam-Status: No, score=-0.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, SPF_SOFTFAIL=0.665, T_RP_MATCHES_RCVD=-0.01] 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 WsnR-l203EyF; Fri, 16 Oct 2015 07:40:42 -0700 (PDT) Received: from p-mail1.rd.orange.com (p-mail1.rd.orange.com [161.106.1.2]) by ietfa.amsl.com (Postfix) with ESMTP id 66D421B2C96; Fri, 16 Oct 2015 07:40:41 -0700 (PDT) Received: from p-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id AF0AC410256; Fri, 16 Oct 2015 16:40:40 +0200 (CEST) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail1.rd.orange.com (Postfix) with ESMTP id 9A54441021E; Fri, 16 Oct 2015 16:40:40 +0200 (CEST) Received: from [10.193.71.204] (10.193.71.204) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.224.2; Fri, 16 Oct 2015 16:40:40 +0200 From: Julien Meuric Organization: Orange To: Message-ID: <56210C68.1080904@orange.com> Date: Fri, 16 Oct 2015 16:40:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "pce@ietf.org" Subject: [Pce] Chair's Review of draft-ietf-pce-stateful-pce-11 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 14:40:44 -0000 Dear authors, To prepare the upcoming move to the IESG, please find below my review of the aforementioned I-D (at last!). _Summary_ Main qualities: - core specification is clear; - wording is smooth, with very few typos; - the manageability and security sections have been included with relevant text. Main issues to point out: - RFC 2119 keywords (picky me, but so is the IESG: ask JP about 5440); - a few corner/error cases; - consistency with existing RFCs (5440, 5886). I also take the opportunity to remind the WG that including codepoint values from existing registries before allocation by the IANA (which can be requested early) is a very bad idea, whatever the WG. _Detailed Comments_ ------ Header --- - The blank line after Ed's name looks strange. If no affiliation is wanted, his name may be moved to the bottom of the list, to avoid association with one of the listed companies. Otherwise, you may use a generic phrase, e.g. "Individual Contributor". ------ Section 1 --- - s/Path Computation Element Protocol/Path Computation Element communication Protocol/ ------ Section 2 --- - "LSP", properly expended in the introduction, should be added somewhere (all the more as IS-IS is mentioned a few times). - s/Stateful PCE: has/Stateful PCE: a PCE that has/ - s/Passive Stateful PCE: uses/Passive Stateful PCE: a stateful PCE that uses/ - s/Active Stateful PCE: is an extension/Active Stateful PCE: an extension/ - s/Delegation: An/Delegation: an/ - s/PCC who owns/PCC which owns/ - s/PCC SHOULD be/PCC should be/ - s/Revocation: An/Revocation: an/ - OLD Redelegation Timeout Interval: when a PCEP session is terminated, a PCC waits for this time period before revoking LSP delegation to a PCE and attempting to redelegate LSPs associated with the terminated PCEP session to an alternate PCE. NEW Redelegation Timeout Interval: the period of time a PCE waits for, when a PCEP session is terminated, before revoking LSP delegation to a PCE and attempting to redelegate LSPs associated with the terminated PCEP session to an alternate PCE. - OLD State Timeout Interval: when a PCEP session is terminated, a PCC waits for this time period before flushing LSP state associated with that PCEP session and reverting to operator-defined default parameters or behaviors. NEW State Timeout Interval: the period of time a PCE waits for, when a PCEP session is terminated, before flushing LSP state associated with that PCEP session and reverting to operator-defined default parameters or behaviors. - OLD Within this document, PCE-PCE communications are described by having the requesting PCE fill the role of a PCC. This provides a saving in documentation without loss of function. NEW Within this document, PCEP communications are described through PCC-PCE relationship. The PCE architecture also supports the PCE-PCE communication, by having the requesting PCE fill the role of a PCC, as usual. ------ Section 3 --- - Section 3.1.3 includes 2 paragraphs "Scale and Performance": they should either be merged, or the old text version should be dropped. - s/which prevents interoperability of a PCE/which limits interoperability of a stateful PCE/ - s/the same PCEP./the same protocol, i.e., PCEP./ ------ Section 4 --- - s/A PCE requests/a PCE requests/ - The reference to draft-sivabalan-pce-disco-stateful makes the reader wonder why is is not part of draft-ietf-pce-stateful-pce itself. Besides, Table 1 also mentions IS-IS and OSPF PCE-CAP-FLAGS sub-TLV, only the allocation section seems to be missing here. Would you talk to the authors (some being common to both I-Ds) of the former to consider using their material as a contribution? A separate document is quite an overhead for allocating 2 bits. ------ Section 5 --- - s/In the PCEP protocol/In PCEP/ - s/The PCEP protocol extensions/The PCEP extensions/ - s/by the operator through/by the operator, e.g., through/ - "PCRpt message can contain": what about "s/can/MAY/"? - s/ISIS/IS-IS/ - s/The PCEP protocol extensions/The PCEP extensions/ - s/it SHOULD generate a PCErr/it MUST generate a PCErr/ [twice] - s/it will terminate/it MUST\SHOULD terminate/ [twice] - s/in this document MAY/in this document may/ - s/SHOULD be generated/MUST be generated/ - s/PCE can still receive/PCE can still accept/ - PLSP-ID is used, while not yet defined nor expended. - s/include an empty ERO/include an empty RRO/ [Along with RFC 5440 (section 7.10), the object sent by a PCC to report to a PCE is an RRO: let us keep it consistent.] - s/in its path/for its path/ [or "as its path"?] - Avoiding "positive acknowledgements for properly received synchronization messages" has scalability benefits in normal situations, but the PCC is blind and may keep on sending PCRpt to dead processes behind up PCEP sessions. Have you consider acknowledgement, possibly using a compression mechanism like the one defined later in the I-D? - When mentioning errors, adding a sentence reminding that RFC 5440 already defines a set of applicable error codes would be valuable. - The sentence about "delegation policy" in section 5.5 is not protocol specification and should be moved to section 9.1 ("Control Function and Policy"). - s/PCE may return/PCE MAY return/ - s/PCE may revoke/PCE MAY revoke/ - s/PCC should react/PCC SHOULD react/ [?] - In section 5.5.1, it is not clear if an empty LSP Update Request with a Delegate flag to 1 is an acceptable way for a PCE to send a delegation acknowledgement: to be clarified. - Section 5.5.1 has a significant break in the middle, it would deserve subsections: e.g., "5.5.2.1 Revoking Explicitly" and "5.5.2.2. Revoking on Timeout" right before "When a PCC's PCEP session with a PCE terminates unexpectedly...". - s/the PCC SHALL flush/the PCC MUST flush/ [correct, but single instance of SHALL in the I-D] - Current text says "The State Timeout Interval SHOULD be greater than or equal to the Redelegation Timeout Interval", but the I-D assumes "MUST": if "MUST" is avoided on purpose, then some text should be added for cases not falling under that "SHOULD". - s/SHOULD return the LSP delegation/MUST return the LSP delegation/ - In section 5.5.3, assuming an LSP was delegated, does the reception by the PCC of a non empty LSP Update Request with a Delegate Flag to 0 trigger an error? - s/to be larger/to be greater/ - s/as recommended/as RECOMMENDED/ or s/as recommended/as MANDATORY/ [depending on the SHOULD/MUST selected above] - At the top of page 18, "and [assuming that] PCEs' decisions are the same" should be added. - Again, in section 5.5.5, 4th paragraph, after "there will be no change in LSP state", "if similar PCEs' decisions" should be added. - s/is larger than/is greater than/ - Section 5.6 requires more RFC 2119 keywords, only a few of them are suggested below. - s/For each LSP, it sends/For each LSP, it MAY send/ - s/could not be set up, the PCC sends/could not be set up, the PCC MUST send/ - s/it also sends/it SHOULD also send/ - s/A PCC sends each LSP State Report/A PCC MUST send each LSP State Report/ - In section 5.6.2, in case of new LSP, the very first message sent by the PCC aims at getting a path. This is clearly the role of a PCReq message, and the I-D extends it to support the LSP object including the delegation flag (section 7.3). However, Figure 8 treats a new LSP the same way as reporting an existing LSP, i.e., using a PCRpt message. In this case, there is an overlap between PCReq and PCRpt, which MUST be resolved because interoperability is at stake. Documenting the delegation of a new LSP deserves some new text and possibly figure, the overlapping specification of the PCRpt should be explicitly precluded. - s/existing LSPs) and LSPs have/existing LSPs). After LSPs have/ - s/For each LSP, it sends/For each LSP, it MAY send/ - s/LSP is up, the PCC sends/LSP is up, the PCC MUST send/ - s/be set up, the PCC sends/be set up, the PCC MUST send/ - s/PCC may choose to compress LSP State/PCC MAY compress LSP State/ - s/A PCC sends each LSP State/A PCC MUST send each LSP state/ - At the end of section 5.6, "SRP-ID-number" is used but not yet defined. At least, SRP should be expended. - s/PCC may choose to compress state/PCC MAY compress state/ - s/the earlier updates/the updates with lower SRP-ID-number/ [Noting that it assumes that the value is incrementing, which is documented only later, in section 7.2.] - s/in a separate draft/in a separate document/ - s/Transport/PCEP Sessions/ ------ Section 6 --- - The terms "mandatory" and "optional" are introduced, but barely used then. It would be better to stick to RFC 2119 keywords (e.g., "REQUIRED" and "OPTIONAL") and actually use them for each object. - The object ordering is defined as mandatory: unfortunately, that would be inconsistent with previous PCEP extensions. I suggest to either drop that sentence, or at least downgrade to a "SHOULD" as a trade-off. - s/// [Per RFC 5440, a report from PCC to PCE is RRO.] - The need for the optional xRO is not well documented. Its proper naming will depend on the associated use that must be clarified. - "SRP" is still not defined. - s/is optional/is OPTIONAL/ - s/the latest one/the one with the highest ID-number/ - s/is mandatory/is REQUIRED/ - The use of the optional xRO is mentioned, but its relationship with the RRO (formerly ERO) is not clear. I suspect some assumptions are made on the way the ERO/RRO are populated; RFC 5440 only says ERO for PCE->PCC and RRO for PCC->PCE. - s/included by the PCC/inlcuded in PCRpt by the PCC/ - The behavior associated to the resource limit per PCC rather looks like a Notifcation than an Error (e.g., in RFC 5440, cancelling a set of pending requests relies on PCNtf). Please consider the use of Notification instead of Error here. - s/that the PCE associates/that the PCC associates/ - s/next LSP. If the PCUpd/next LSP.If the PCUpd/ ------ Section 7 --- - s/defined in this document/defined in that (aforementioned) document/ - s/SHOULD always be/MUST be/ - s/one SPR-id-number/one SRP-ID-number/ - s/SRP-ID/SRP-ID-number/ [3 times] - s/allocated it/allocated to it/ - s/Flags (12 bits):/Flags (12 bits), starting from the least significant bit:/ - s/on a PCRpt message/On a PCRpt or PCReq message/ - s/the S flag/The S flag/ - s/in other PCRpt messages/in other messages/ - "PCE SHOULD remove all state" is written 3 times: I wonder about "MUST". - s/LSP Identifiers/LSP-IDENTIFIERS/ [4 or 5 times] - Texts associated with object definition are incomplete, they rely too much on figures. For example: * s/The type of the TLV/The type (16 bits) of the TLV/ [5 times] * s/IANA and it has a fixed length of/IANA. The length field is 16 bit-long and has a fixed value of/ [3 times] * s/IANA and it has a variable length/IANA. The length field is 16 bit-long and has a variable value/ [2 times] - s/in l following/in the following/ - The paragraph "However, when Gobal Path Protection... (or vice versa)" is not IPv6 specific and should be moved to the end of section 7.3.1. - s/a path's lifetime/an LSP's lifetime/ - It would be nice to elaborate on the reason why the SYMBOLIC-PATH-NAME MUST be included and not SHOULD. - I do not see why SYMBOLIC-PATH-NAME may be included in SRP Object: defining the LSP Object as its single place seems enough and much simpler. ------ Section 8 --- - OLD This document requests that a registry is created to manage the Flags field of the LSP object. NEW This document requests that a new sub-registry, named "LSP ObjectFlag Field", is created within the "Path Computation Element Protocol (PCEP) Numbers" registry to manage the Flag field of the LSP object. - either s/Error-value=9: ERO Object/Error-value=9: xRO Object/ or add an Error-Value for RRO. - As mentioned above, in Error-Type 19, Error-value 4 should be considered in a PCNtf. - OLD This document requests that a registry is created to manage the Flags field in the STATEFUL-PCE-CAPABILITY TLV in the OPEN object. NEW This document requests that a new sub-registry, named "STATEFUL-PCE-CAPABILITY TLVFlag Field", is created within the "Path Computation Element Protocol (PCEP) Numbers" registry to manage the Flag field in the STATEFUL-PCE-CAPABILITY TLV of the PCEP OPEN object (class = 1). - OLD This document requests that a registry is created to manage the value of the LSP error code field in this TLV. NEW This document requests that a new sub-registry, named "LSP-ERROR-CODE TLV Error Code Field", is created within the "Path Computation Element Protocol (PCEP) Numbers" registry to manage the LSP Error code field of the LSP-ERROR-CODE TLV. ------ Section 10 --- - s/session also result in/session also results in/ - Again in section 10.4, the "resource limit exceed" information (Error-value 4 of Error-Type 19) should be considered in a PCNtf. ------ Section 11 --- - Cyril and Ramon might be more than acknowledged since they are mentioned twice. ------ Section 12 --- - For this document, I think the RFC 5226 reference is informative, not normative (an implementer does not need to read it). ------ Best regards, Julien From nobody Sun Oct 18 18:26:26 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6781B2B20; Sun, 18 Oct 2015 18:26:24 -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 S-wPdKyzssgS; Sun, 18 Oct 2015 18:26:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A7B1B2B1E; Sun, 18 Oct 2015 18:26:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019012622.28456.21911.idtracker@ietfa.amsl.com> Date: Sun, 18 Oct 2015 18:26:22 -0700 Archived-At: Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-gmpls-pcep-extensions-11.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 01:26:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : PCEP extensions for GMPLS Authors : Cyril Margaria Oscar Gonzalez de Dios Fatai Zhang Filename : draft-ietf-pce-gmpls-pcep-extensions-11.txt Pages : 38 Date : 2015-10-18 Abstract: This memo provides extensions for the Path Computation Element communication Protocol (PCEP) for the support of GMPLS control plane. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-gmpls-pcep-extensions/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-pce-gmpls-pcep-extensions-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-gmpls-pcep-extensions-11 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 Mon Oct 19 03:18:29 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A20671A88A1; Mon, 19 Oct 2015 03:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 Ba18YGI-NNiP; Mon, 19 Oct 2015 03:18:23 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0130.outbound.protection.outlook.com [65.55.169.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3EF41A889A; Mon, 19 Oct 2015 03:18:22 -0700 (PDT) Received: from DM2PR02MB1356.namprd02.prod.outlook.com (10.161.143.13) by DM2PR02MB1354.namprd02.prod.outlook.com (10.161.143.11) with Microsoft SMTP Server (TLS) id 15.1.300.14; Mon, 19 Oct 2015 10:18:20 +0000 Received: from DM2PR02MB1356.namprd02.prod.outlook.com ([10.161.143.13]) by DM2PR02MB1356.namprd02.prod.outlook.com ([10.161.143.13]) with mapi id 15.01.0300.010; Mon, 19 Oct 2015 10:18:20 +0000 From: Jonathan Hardwick To: "draft-ietf-pce-stateful-sync-optimizations@ietf.org" Thread-Topic: Shepherd's review of draft-ietf-pce-stateful-sync-optimizations-03 Thread-Index: AdEIKFCM/MXbJYqfQi2B63ASoTqDyA== Date: Mon, 19 Oct 2015 10:18:20 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jonathan.Hardwick@metaswitch.com; x-originating-ip: [217.43.17.249] x-microsoft-exchange-diagnostics: 1; DM2PR02MB1354; 5:epz5ke7oaIpLf9Tab88KLzqlivJDsybGDRlx8nNaRvdJ28n4IL56C+6tWCc68v7BX/3n3ICaGQ6oF6qSXfticqDgdlW/iR6sego2XMkDfShpFl4h711IMMS+hNmOdPJeK1CWVZaJ4aJ7REV0S9i7gg==; 24:CKTZHOCMI7RFKpDi7zkodNHqAPY66WL3sj8zIHsb3XeOoVV8QnplZc8Fh2NUJxA/YM/kg9ZFbZG5UP0v9Vw+ZZlmjnrNm5I9aDTaXvOOOzA=; 20:iCNT+3GoIocDl/G95lUQYo1wEyJNmwOyFQESXI64/3cgvahgaOi/NmY3QuBEx7u/q7ob8jbGV6h4vvhPAdQhJQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR02MB1354; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(42673675456677)(108003899814671)(83020558694031); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001); SRVR:DM2PR02MB1354; BCL:0; PCL:0; RULEID:; SRVR:DM2PR02MB1354; x-forefront-prvs: 07349BFAD2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(92566002)(66066001)(50986999)(19625215002)(2351001)(54356999)(19300405004)(2501003)(15975445007)(64706001)(11100500001)(33656002)(101416001)(2900100001)(5008740100001)(5003600100002)(5004730100002)(229853001)(19580395003)(122556002)(40100003)(16236675004)(10400500002)(105586002)(86362001)(450100001)(99286002)(5002640100001)(106356001)(87936001)(102836002)(97736004)(5007970100001)(230783001)(189998001)(74316001)(46102003)(76576001)(77096005)(5001960100002)(110136002)(81156007); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR02MB1354; H:DM2PR02MB1356.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM2PR02MB1356654D2EA1E36F14E9DB6A843A0DM2PR02MB1356namp_" MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2015 10:18:20.1360 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR02MB1354 Archived-At: Cc: "pce@ietf.org" Subject: [Pce] Shepherd's review of draft-ietf-pce-stateful-sync-optimizations-03 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 10:18:28 -0000 --_000_DM2PR02MB1356654D2EA1E36F14E9DB6A843A0DM2PR02MB1356namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi there I have performed a WG Shepherd review of this draft. Generally I found it = a well-written draft with no major issues. There are a few minor issues th= at I think should be resolved. I have divided my comments into three groups: * technical - comments that affect the meaning of the document * editorial - comments that do not affect the meaning but I think w= ould significantly improve the clarity * nits - editorial comments that are minor and obvious. I would like to have at least the technical comments resolved before forwar= ding the document to the IESG. Please could the authors review my comments= and reply either by email or by submitting a new draft version? Best regards Jon Technical s3.2 para 6. "If the PCC attempts to skip state synchronization (i.e., the= SYNC Flag =3D 0 on the first LSP State Report from the PCC as per [I-D.iet= f-pce-stateful-pce])," What if the PCC is synchronizing an empty LSPDB? Then the first message it= sends is LSP State Report with SYNC=3D0 and PLSP-ID=3D0. This is legitima= te and yet the text says to treat it as an error. I think this paragraph s= hould stipulate that the error condition is met only if SYNC=3D0 and PLSP-I= D is not 0. -- s4.2: Please rewrite the following text using RFC 2119 keywords. If a PCC has to force full LSP DB synchronization due to reasons including but not limited: (1) local policy configured at the PCC; (2) no sufficient LSP state caches for incremental update, the PCC can set the D flag to 0. Note a PCC may have to bring down the current session and force a full LSP-DB synchronization with D flag set to 0 in the subsequent open message. I would simply say "The PCC MAY force a full LSP DB synchronization by sett= ing the D flag to zero in the open message." And then later, when you say = this: If a PCC finds out it does not have sufficient information to complete incremental synchronisation after advertising incremental LSP state synchronization capability, it MUST send a PCErr with Error-Type 20 and Error-Value 5 'A PCC indicates to a PCE that it can not complete the state synchronization' (defined in [I-D.ietf-pce-stateful-pce]) and terminate the session. add a sentence: "The PCC SHOULD re-establish the session with the D bit set= to zero in the open message." -- s4.2 "So a PCC needs to remember the LSP state changes that happened when a= n existing PCEP session to a stateful PCE goes down in the hope of doing in= cremental synchronisation when the session is re-established." Even this might not be sufficient as the PCC has no idea how many messages = the PCE managed to process before the session goes down. I think it would = be more correct to say "A PCC needs to remember at least the LSP state chan= ges that happened after an existing PCEP session to a stateful PCE goes dow= n to have any chance of doing incremental synchronisation when the session = is re-established." -- s5.2 Two concerns about the following text: A stateful PCE MAY choose to control the LSP-DB synchronization process. To allow PCE to do so, PCEP speakers MUST set T bit to 1 to indicate this (as described in Section 7). Why are you discussing the T bit here? I thought that the behaviours contr= olled by the F bit and the T bit were logically independent (although simil= ar). Are you saying that the PCE must set the F bit and the PCC set the T = bit for the procedures in section 5 to work? You have written a lot of the= text in the passive voice, which makes it unclear who is supposed to set w= hich bit (see editorial comments below for more specific pointers.) Also, = I think your cross-reference should be to section 6, not 7. -- s8.2 Please rewrite this as a request to IANA to make an allocation from a = specific registry (your text in 8.1 is a good example to copy.) s8.3 ditto. -- s9.2 The manageability section ought to describe requirements on implementa= tions, not requirements on the PCE working group. I think your text ought = to read "An implementation SHOULD allow the operator to view the stateful c= apabilities advertised by each peer, and the current synchronization status= with each peer." (Note that I am not disagreeing with the idea of extendi= ng the PCEP MIB.) Editorial s3.2 para 10: "If state synchronization avoidance is enabled..." This woul= d perhaps fit better alongside para 2, which discusses the other legitimate= reasons to increment the DB-VERSION. s4.1 final para feels superfluous - suggest deleting. s5.1 I like the explanation of why PCC:PCE bandwidth might be limited and I= suggest moving this explanation forwards to s4.1 (s4.1 tries to explain th= e same thing but is not as elegant.). s5.2 "Support of PCE-triggered state synchronization is advertised" - is ad= vertised by whom? Also, I think you mean "initial state synchronization." = Please rewrite in the active voice (for example, "Both PCEP speakers adver= tise their support of PCE-triggered initial state synchronization during se= ssion startup by...") Ditto "If the TRIGGERED-INITIAL-SYNC capability is n= ot advertised" -> "If the PCE has not advertised the TRIGGERED-INITIAL-SYNC= capability" s6.2 "Support of PCE-triggered state synchronization is advertised" - pleas= e use active voice. Nits s3.2 para 4: "the PCE SHOULD ignore it were to receive one" - I think you m= ean "the PCE SHOULD ignore it were it to receive one" --_000_DM2PR02MB1356654D2EA1E36F14E9DB6A843A0DM2PR02MB1356namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi there

 

I have performed a WG Shepherd review of this draft.=   Generally I found it a well-written draft with no major issues. = ; There are a few minor issues that I think should be resolved.<= /p>

 

I have divided my comments into three groups:

·         technical – comments that affect the m= eaning of the document

·         editorial – comments that do not affec= t the meaning but I think would significantly improve the clarity

·         nits – editorial comments that are min= or and obvious.

 

I would like to have at least the technical comments= resolved before forwarding the document to the IESG.  Please could th= e authors review my comments and reply either by email or by submitting a n= ew draft version?

 

Best regards

Jon

 

 

Technical

 

s3.2 para 6.  “If the PCC attempts to ski= p state synchronization (i.e., the SYNC Flag =3D 0 on the first LSP State R= eport from the PCC as per [I-D.ietf-pce-stateful-pce]),”

 

What if the PCC is synchronizing an empty LSPDB?&nbs= p; Then the first message it sends is LSP State Report with SYNC=3D0 and PL= SP-ID=3D0.  This is legitimate and yet the text says to treat it as an= error.  I think this paragraph should stipulate that the error condition is met only if SYNC=3D0 and PLSP-ID is not 0.

 

--

 

s4.2: Please rewrite the following text using RFC 21= 19 keywords. 

 

   If a PCC has to fo= rce full LSP DB

   synchronization du= e to reasons including but not limited: (1) local

   policy configured = at the PCC; (2) no sufficient LSP state caches for

   incremental update= , the PCC can set the D flag to 0.  Note a PCC may

   have to bring down= the current session and force a full LSP-DB

   synchronization wi= th D flag set to 0 in the subsequent open message.

 

I would simply say “The PCC MAY force a full L= SP DB synchronization by setting the D flag to zero in the open message.= 221;  And then later, when you say this:

 

   If a PCC finds out it does not have sufficient informatio=
n to
   complete incremental synchronisation after advertising in=
cremental
   LSP state synchronization capability, it MUST send a PCEr=
r with
   Error-Type 20 and Error-Value 5 'A PCC indicates to a PCE=
 that it can
   not complete the state synchronization' (defined in<=
/o:p>
   [I-D.ietf-pce-stateful-pce]) and terminate the session.

 

add a sentence: “The PCC SHOULD re-establish t= he session with the D bit set to zero in the open message.”

 

--

 

s4.2 “So a PCC needs to remember the LSP state= changes that happened when an existing PCEP session to a stateful PCE goes= down in the hope of doing incremental synchronisation when the session is = re-established.”

 

Even this might not be sufficient as the PCC has no = idea how many messages the PCE managed to process before the session goes d= own.  I think it would be more correct to say “A PCC needs to re= member at least the LSP state changes that happened after an existing PCEP session to a stateful PCE goes down to have any cha= nce of doing incremental synchronisation when the session is re-established= .”

 

--

 

s5.2 Two concerns about the following text:

 

   A stateful PCE MAY choose to control the LSP-DB synchroni=
zation
   process.  To allow PCE to do so, PCEP speakers MUST =
set T bit to 1 to
   indicate this (as described in Section 7).

 


Why are you discussing the T bit here?  I thoug=
ht that the behaviours controlled by the F bit and the T bit were logically=
 independent (although similar).  Are you saying that the PCE must set=
 the F bit and the PCC set the T bit for the
 procedures in section 5 to work?  You have written a lot of the text =
in the passive voice, which makes it unclear who is supposed to set which b=
it (see editorial comments below for more specific pointers.)  Also, I=
 think your cross-reference should be to section
 6, not 7.


 


--


 


s8.2 Please rewrite this as a request to IANA to mak=
e an allocation from a specific registry (your text in 8.1 is a good exampl=
e to copy.)


s8.3 ditto.


 


--


 


s9.2 The manageability section ought to describe req=
uirements on implementations, not requirements on the PCE working group.&nb=
sp; I think your text ought to read “An implementation SHOULD allow t=
he operator to view the stateful capabilities
 advertised by each peer, and the current synchronization status with each =
peer.”  (Note that I am not disagreeing with the idea of extendi=
ng the PCEP MIB.)


 


Editorial


 


s3.2 para 10: “If state synchronization avoida=
nce is enabled…”  This would perhaps fit better alongside =
para 2, which discusses the other legitimate reasons to increment the DB-VE=
RSION.


 


s4.1 final para feels superfluous – suggest de=
leting.


 


s5.1 I like the explanation of why PCC:PCE bandwidth=
 might be limited and I suggest moving this explanation forwards to s4.1 (s=
4.1 tries to explain the same thing but is not as elegant.).


 


s5.2 “Support of PCE-triggered state synchroni=
zation is advertised” – is advertised by whom?  Also, I th=
ink you mean “initial state synchronization.”  Plea=
se rewrite in the active voice (for example, “Both PCEP speakers adve=
rtise
 their support of PCE-triggered initial state synchronization during sessio=
n startup by…”)  Ditto “If the TRIGGERED-INITIAL-SYN=
C capability is not advertised” -> “If the PCE has not adver=
tised the TRIGGERED-INITIAL-SYNC capability”


 


s6.2 “Support of PCE-triggered state synchroni=
zation is advertised” – please use active voice.


 


Nits


 


s3.2 para 4: “the PCE SHOULD ignore it were to=
 receive one” – I think you mean “the PCE SHOULD ignore i=
t were it to receive one”


 
--_000_DM2PR02MB1356654D2EA1E36F14E9DB6A843A0DM2PR02MB1356namp_-- From nobody Mon Oct 19 07:06:13 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 988771A6F9F; Mon, 19 Oct 2015 07:06:04 -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 AHZxeSoKprJS; Mon, 19 Oct 2015 07:06:02 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 035441A6FC0; Mon, 19 Oct 2015 07:06:00 -0700 (PDT) Received: by ioll68 with SMTP id l68so30382182iol.3; Mon, 19 Oct 2015 07:05:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=TmmRObe+zn2ZkYfOgdvg+3idl2WH0O7zV0bUFJcp5hI=; b=dIX0vE1k3E2iHSvxKaL7vCCV/SRMp4I2J4ZeelJcNumKNDO3aLAfUAIUqJ9wrIslP0 9GaoUmlzlknOOTFL+vcBTmYW4Lk2q1zMtcpCGbReGDokyHDViFP1znJOyiHdRMvJvsFg Wxyq4olsiory08510zAB1egnyOb6wJDqbZINxA5tg6PESANyl5f8m+FuB0VgYVXT1HO9 nngIqgWQPlNsmQixS8aJgRl1RTJ6W6gxR5IxtzCiRMWKpTlDWglFzhWSoHixHjadNK+R A4QnBYEnDEKKjGdW2xYEw7q4fxoY0HZlVKcgnvZSk5qhWnL1CeWlQRxfr2wy7HAujMPN F5Mg== MIME-Version: 1.0 X-Received: by 10.107.46.158 with SMTP id u30mr34993982iou.56.1445263558059; Mon, 19 Oct 2015 07:05:58 -0700 (PDT) Received: by 10.107.18.197 with HTTP; Mon, 19 Oct 2015 07:05:57 -0700 (PDT) Date: Mon, 19 Oct 2015 10:05:57 -0400 Message-ID: From: Cyril Margaria To: draft-ietf-pce-stateful-pce@ietf.org, "pce@ietf.org" Content-Type: multipart/alternative; boundary=001a113ac342fc2f41052275a442 Archived-At: Subject: [Pce] Question on draft-ietf-pce-stateful-pce-11 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 14:06:04 -0000 --001a113ac342fc2f41052275a442 Content-Type: text/plain; charset=UTF-8 Dear authors, PCE'ers, Following the comment on the Error-Type 19, Error-value 4 comments (PCNtf), I have the following additional comments/questions regarding section 7.3.3 LSP Error Code TLV: - When should each error code be sent, documents usually describe the specific conditions when an error is sent, here the condition is that the update failed, but the description of the errors is not very specific. - The Value 2 seems redundant with Error-Type 19, Error-value 4, or is this error meant for the PCE to slow down the Update rate? - Value 3 (Too many pending LSP update requests) : What should be the PCE action in that case, should the PCE stop sending the messages, slow down, Could a NOTIFICATION object with a PCC overload state report be used, following RFC5440? In addition should this the number of update request be considered in section 9? - Value 4 (Unacceptable parameters) : How are the not acceptable parameter reported, should the PCE retry with another set of parameters? -Value 5 : What should the PCE do in that case? is it recommended that it stop sending updates? Could you explain why a PCE is not allowed to set LSP parameters on a LSP in admin state down? - Value 6 (LSP preempted): Which kind of preemption (administrative, signaling, other PCE??) Is there a recommended action from the PCE, Should the PCE compute a new Path or is it expected that the delegation is removed? Best regards, Cyril --001a113ac342fc2f41052275a442 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear authors, PCE'ers,

Followi= ng the=C2=A0 comment on the Error-Type 19, Error-value 4 comments (PCNtf), = I have the following additional comments/questions regarding section 7.3.3 = LSP Error Code TLV:
=C2=A0=C2=A0 - When should each error code be sent, = documents usually describe the specific conditions when an error is sent, h= ere the condition is that the update failed, but the description of the err= ors is not very specific.
=C2=A0 - The Value 2 seems redundan= t with Error-Type 19, Error-value 4, or is this error meant for the PCE to = slow down the Update rate?
=C2=A0- Value 3 (Too many pending = LSP update requests) : What should be the PCE action in that case, should t= he PCE stop sending the messages, slow down, Could a NOTIFICATION object wi= th a PCC overload state report be used, following RFC5440? In addition shou= ld this the number of update request be considered in section 9?
<= div>=C2=A0- Value 4 (Unacceptable parameters) : How are the not acceptable = parameter reported, should the PCE retry with another set of parameters?
=C2=A0-Value 5 : What should the PCE do in that case? is it rec= ommended that it stop sending updates? Could you explain why a PCE is not a= llowed to set LSP parameters on a LSP in admin state down?
= =C2=A0- Value 6 (LSP preempted): Which kind of preemption=C2=A0 (administra= tive, signaling, other PCE??) Is there a recommended action from the PCE, S= hould the PCE compute a new Path or is it expected that the delegation is r= emoved?

Best regards,
Cyril
=





=
--001a113ac342fc2f41052275a442-- From nobody Mon Oct 19 09:40:15 2015 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 28DDD1A8A55; Mon, 19 Oct 2015 09:40:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019164013.15613.78596.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 09:40:13 -0700 Archived-At: Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-stateful-pce-12.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 16:40:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : PCEP Extensions for Stateful PCE Authors : Edward Crabbe Ina Minei Jan Medved Robert Varga Filename : draft-ietf-pce-stateful-pce-12.txt Pages : 48 Date : 2015-10-19 Abstract: The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS LSPs via PCEP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-stateful-pce-12 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 Mon Oct 19 09:45:43 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1B001A8A65 for ; Mon, 19 Oct 2015 09:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 YOuM0cmi4o68 for ; Mon, 19 Oct 2015 09:45:40 -0700 (PDT) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37DD41A8A76 for ; Mon, 19 Oct 2015 09:45:39 -0700 (PDT) Received: by qgem9 with SMTP id m9so13937822qge.1 for ; Mon, 19 Oct 2015 09:45:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=olGqap2eIjRU09HbW91OG+xtJFjAWmtmHOIel6dmZZ0=; b=Imeohc3iXGOq02vLCGgjwx1UZpN02VrudtZMhLysEYpVdTIgmMTERwVoPvmwPsUpiu yzwldNlV0Pl4oqsGKzKeivtndS+kO+5DzmBdjrunw6/v7ARAyryN7/o0NmrFKhTT8AvZ KIj709DMchTzuRzWEkzNz2CPnwxMNvWkwNTTQpEt5JdEmSoUDaSUSZ4NRLDBEXJOj2QJ MBabOiJTKm9vtovnuBjLceE4Po4LO/9+fyI092cDjMfj8BabRYcoikxcXl4/ffszDUP0 iftriu0eyU/PHwP7CNXv7KrgMlcQw69xWwknQsnYgwkeJI8ZaFRP8h/66UrMz5rC/QB6 036g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=olGqap2eIjRU09HbW91OG+xtJFjAWmtmHOIel6dmZZ0=; b=K95c6kOCc63mnaQQq34bzlCEKNSJaxywHIZ6S4fLMY7mXsl+oA16t8/4/4G9c1Ebmc qE7dqN2yJM5cYKh7UPOPgMKwKUfVJ5LPLsSO2RGAjWV47TuEGFEnF12Xc1MB34jKbQjv Ns5kI+f4BhPuGJ0SwuNydBsA8XO2U7K15bEhz2LmM0GyZHnkylht56j2K+VBNyaRrd9N yPS2dS6wejz0vJcMqPb+365cWr2WsHwD6C6pXVE+KZ+qFyKbJwbvk1OKxv6aY6XqTrgs jI+0mKqmAdExd4K0gL/Uq/JkuG4ctdWfPxvgYN9A3AnUYraXvuufdv0qDSM5bG1pHGQT 0ENg== X-Gm-Message-State: ALoCoQmAC1ScjBGm6bumEilYdoAFVH1wxfB6myfz9mvtOS3gurde8w3n3WDRVbM5v8MqDXYA37VV MIME-Version: 1.0 X-Received: by 10.140.165.196 with SMTP id l187mr40101771qhl.93.1445273137905; Mon, 19 Oct 2015 09:45:37 -0700 (PDT) Received: by 10.55.142.195 with HTTP; Mon, 19 Oct 2015 09:45:37 -0700 (PDT) In-Reply-To: <20151019164013.15613.78596.idtracker@ietfa.amsl.com> References: <20151019164013.15613.78596.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 09:45:37 -0700 Message-ID: From: Ina Minei To: internet-drafts@ietf.org Content-Type: multipart/alternative; boundary=001a1134f674fd54a5052277dfaf Archived-At: Cc: pce , i-d-announce@ietf.org Subject: Re: [Pce] I-D Action: draft-ietf-pce-stateful-pce-12.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 16:45:42 -0000 --001a1134f674fd54a5052277dfaf Content-Type: text/plain; charset=UTF-8 This is just a version refresh to prevent the draft from expiring, comments will be addressed in version 13. Ina On Mon, Oct 19, 2015 at 9:40 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Path Computation Element Working Group > of the IETF. > > Title : PCEP Extensions for Stateful PCE > Authors : Edward Crabbe > Ina Minei > Jan Medved > Robert Varga > Filename : draft-ietf-pce-stateful-pce-12.txt > Pages : 48 > Date : 2015-10-19 > > Abstract: > The Path Computation Element Communication Protocol (PCEP) provides > mechanisms for Path Computation Elements (PCEs) to perform path > computations in response to Path Computation Clients (PCCs) requests. > > Although PCEP explicitly makes no assumptions regarding the > information available to the PCE, it also makes no provisions for PCE > control of timing and sequence of path computations within and across > PCEP sessions. This document describes a set of extensions to PCEP > to enable stateful control of MPLS-TE and GMPLS LSPs via PCEP. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-12 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-stateful-pce-12 > > > 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/ > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > --001a1134f674fd54a5052277dfaf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is just a version refresh to prevent the draft from e= xpiring, comments will be addressed in version 13.

Ina= =C2=A0

On Mon, Oct 19, 2015 at 9:40 AM, <internet-drafts@ietf.org>= ; wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Path Computation Element Working Gro= up of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= PCEP Extensions for Stateful PCE
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Edwa= rd Crabbe
=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 Ina Minei
=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 Jan Medved
=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 Robert Varga
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-pce-stateful-pce-12.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 48
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-10-19

Abstract:
=C2=A0 =C2=A0The Path Computation Element Communication Protocol (PCEP) pro= vides
=C2=A0 =C2=A0mechanisms for Path Computation Elements (PCEs) to perform pat= h
=C2=A0 =C2=A0computations in response to Path Computation Clients (PCCs) re= quests.

=C2=A0 =C2=A0Although PCEP explicitly makes no assumptions regarding the =C2=A0 =C2=A0information available to the PCE, it also makes no provisions = for PCE
=C2=A0 =C2=A0control of timing and sequence of path computations within and= across
=C2=A0 =C2=A0PCEP sessions.=C2=A0 This document describes a set of extensio= ns to PCEP
=C2=A0 =C2=A0to enable stateful control of MPLS-TE and GMPLS LSPs via PCEP.=


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-= ietf-pce-stateful-pce/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-pc= e-stateful-pce-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2= =3Ddraft-ietf-pce-stateful-pce-12


Please note that it may take a couple of minutes from the time of submissio= n
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/

_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

--001a1134f674fd54a5052277dfaf-- From nobody Mon Oct 19 09:56:26 2015 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C6A501A8A85; Mon, 19 Oct 2015 09:56:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019165623.31126.73598.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 09:56:23 -0700 Archived-At: Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-pce-initiated-lsp-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 16:56:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model Authors : Edward Crabbe Ina Minei Siva Sivabalan Robert Varga Filename : draft-ietf-pce-pce-initiated-lsp-05.txt Pages : 17 Date : 2015-10-19 Abstract: The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. The extensions for stateful PCE provide stateful control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSP) via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. This document describes the creation and deletion of PCE-initiated LSPs under the stateful PCE model. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-pce-initiated-lsp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-pce-pce-initiated-lsp-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pce-initiated-lsp-05 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 Mon Oct 19 09:59:11 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 165DF1A8AAB for ; Mon, 19 Oct 2015 09:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 VImtD1ynqoen for ; Mon, 19 Oct 2015 09:59:07 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 591151A8A95 for ; Mon, 19 Oct 2015 09:59:07 -0700 (PDT) Received: by qgem9 with SMTP id m9so14307471qge.1 for ; Mon, 19 Oct 2015 09:59:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Y1LGNUyrksUVE+jQjVzGmikIdnk5fBWF0PrPX4JIw+U=; b=mhS90Jo5X8dfVq3yA5goEWt4NF2Fo7109J41y59sWbjXDIXuaJBg6MARjhxpQrLTZZ lM1O17dNUeZqxiAJeGnPCd7hJeSlgBaWnwAyp52Zv/v7SS41bWenn7ww/vADdRCaat2S /j7D3j5rJCsIR6ALdkglkfMLRAgsNkh9vOgfKyJgHkvMJUI/X3NjyJPsKHPpXUGke6O4 +K8rgQWP7c1C4f3cVcJn7Or6VxKuuOMSMMvbmBRvbsncpEk0DmqhMuYNfsQIV8IMGSSJ G5SdIkwooOz2QlRIJH9D/Tsz8XCbGPk4RtCFejdBaES+cruMCm7xO4QXVOl2RI9XyggI NLWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=Y1LGNUyrksUVE+jQjVzGmikIdnk5fBWF0PrPX4JIw+U=; b=lhcxb1fhT9UcxEMEOVLc0PKgsuEyD8V3BObKFkNtuJAFaZvLSlkEVYqFr2FCIZFbQu o4FyT0ZAaoI/1Gczl0HUKaUbaqTPrrl5noEm2Ih2XKkNC+q7ZLpsDLGfsBvmd3rt7qr4 hmtEz4bFKObepcY/kBRco+/ObX4YzbfHUESLj2drYhUVrUQYfnHI77KTsDAeO2Weav96 7DF0kYrcEh347aPpuZL8WBsp/2nKLVLIvgE/pnyg3w5lDfrRMvJ0V0OW12OT/FwMqpc5 HGLMSS/nFh5nKS8vg98xhH9Wfi6ky4n2NwLnzLPLRV1sC4ScjRuCrH6NcLGG6vCQ20Pn zlow== X-Gm-Message-State: ALoCoQlhoyak46oFHltnEmJTIIF9xuW4kRRR55OsnDE12QRzLPqhE8KDMOUerdmbL9VpobX9PjAG MIME-Version: 1.0 X-Received: by 10.140.44.11 with SMTP id f11mr37325564qga.80.1445273946413; Mon, 19 Oct 2015 09:59:06 -0700 (PDT) Received: by 10.55.142.195 with HTTP; Mon, 19 Oct 2015 09:59:06 -0700 (PDT) In-Reply-To: <20151019165623.31126.73598.idtracker@ietfa.amsl.com> References: <20151019165623.31126.73598.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 09:59:06 -0700 Message-ID: From: Ina Minei To: pce Content-Type: multipart/alternative; boundary=001a113b41bc2e9017052278103b Archived-At: Subject: Re: [Pce] I-D Action: draft-ietf-pce-pce-initiated-lsp-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 16:59:09 -0000 --001a113b41bc2e9017052278103b Content-Type: text/plain; charset=UTF-8 This is just a version refresh, to prevent the draft from expiring, no changes were made to the draft. On Mon, Oct 19, 2015 at 9:56 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Path Computation Element Working Group > of the IETF. > > Title : PCEP Extensions for PCE-initiated LSP Setup in a > Stateful PCE Model > Authors : Edward Crabbe > Ina Minei > Siva Sivabalan > Robert Varga > Filename : draft-ietf-pce-pce-initiated-lsp-05.txt > Pages : 17 > Date : 2015-10-19 > > Abstract: > The Path Computation Element Communication Protocol (PCEP) provides > mechanisms for Path Computation Elements (PCEs) to perform path > computations in response to Path Computation Clients (PCCs) requests. > > The extensions for stateful PCE provide stateful control of > Multiprotocol Label Switching (MPLS) Traffic Engineering Label > Switched Paths (TE LSP) via PCEP, for a model where the PCC delegates > control over one or more locally configured LSPs to the PCE. This > document describes the creation and deletion of PCE-initiated LSPs > under the stateful PCE model. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-pce-pce-initiated-lsp/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-pce-pce-initiated-lsp-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pce-initiated-lsp-05 > > > 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/ > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > --001a113b41bc2e9017052278103b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is just a version refresh, to prevent the draft from = expiring, no changes were made to the draft.=C2=A0


On Mon, Oct 19, 2015 = at 9:56 AM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Path Computation Element Working Gro= up of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Edwa= rd Crabbe
=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 Ina Minei
=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 Siva Sivabalan
=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 Robert Varga
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-pce-pce-initiated-lsp-05.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 17
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-10-19

Abstract:
=C2=A0 =C2=A0The Path Computation Element Communication Protocol (PCEP) pro= vides
=C2=A0 =C2=A0mechanisms for Path Computation Elements (PCEs) to perform pat= h
=C2=A0 =C2=A0computations in response to Path Computation Clients (PCCs) re= quests.

=C2=A0 =C2=A0The extensions for stateful PCE provide stateful control of =C2=A0 =C2=A0Multiprotocol Label Switching (MPLS) Traffic Engineering Label=
=C2=A0 =C2=A0Switched Paths (TE LSP) via PCEP, for a model where the PCC de= legates
=C2=A0 =C2=A0control over one or more locally configured LSPs to the PCE.= =C2=A0 This
=C2=A0 =C2=A0document describes the creation and deletion of PCE-initiated = LSPs
=C2=A0 =C2=A0under the stateful PCE model.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/d= raft-ietf-pce-pce-initiated-lsp/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-iet= f-pce-pce-initiated-lsp-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?= url2=3Ddraft-ietf-pce-pce-initiated-lsp-05


Please note that it may take a couple of minutes from the time of submissio= n
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/

_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

--001a113b41bc2e9017052278103b-- From nobody Mon Oct 19 10:07:23 2015 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C93AF1A8A99; Mon, 19 Oct 2015 10:07:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019170720.18931.485.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 10:07:20 -0700 Archived-At: Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-stateful-pce-app-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 17:07:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Applicability of a Stateful Path Computation Element (PCE) Authors : Xian Zhang Ina Minei Filename : draft-ietf-pce-stateful-pce-app-05.txt Pages : 25 Date : 2015-10-19 Abstract: A stateful Path Computation Element (PCE) maintains information about Label Switched Path (LSP) characteristics and resource usage within a network in order to provide traffic engineering calculations for its associated Path Computation Clients (PCCs). This document describes general considerations for a stateful PCE deployment and examines its applicability and benefits, as well as its challenges and limitations through a number of use cases. PCE Communication Protocol (PCEP) extensions required for stateful PCE usage are covered in separate documents. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-app/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-app-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-stateful-pce-app-05 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 Mon Oct 19 10:10:38 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0D01A92B4 for ; Mon, 19 Oct 2015 10:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 z2VAHQ5beRLl for ; Mon, 19 Oct 2015 10:10:29 -0700 (PDT) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 873631ACD0F for ; Mon, 19 Oct 2015 10:10:13 -0700 (PDT) Received: by qgbb65 with SMTP id b65so58145766qgb.2 for ; Mon, 19 Oct 2015 10:10:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=8qmwb1mg3qgOK67fN9YRQFrsy0ryfjMi/XByYawG7dU=; b=UfuUnPPp55XNlGH0ciRjAXMChxbd2cB3g1r8TW71vx5IB9JdwX/Nm71T61hcC1Scdm U3ZSMt/vfyWcj1TfoJj5A3tuXSWty/6uYRZqdBntgpd4T2QGKjIToY+1LBDSgG3Y2Kok EPqdPhP+GtrayQJUY8yrxUmrzVRpRpvtltcqANk0RGdCrkOjtNSk8SQrlrUPQseNKqQD czLmNrNThtG65p3rlEvLya96U81rv3FJKKGzRIqlvbTAzKsf1fA5Ga47BS/PWtgf4OxF XkoZ+T9d2Toyi6FH67ZmipoFX0wvueY3rVKQhLZicGc1BblR9EFyMjBk0deBxvgLBHT8 XegQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=8qmwb1mg3qgOK67fN9YRQFrsy0ryfjMi/XByYawG7dU=; b=SWPk52nvR0pEIX8ttCcPrvhyvCAyQN0AbBAsqJA5eYhdq1VR9RFVnrEZ+fj+xXPuzC xYvob90jLNQW/za4Hje+hnQTTBKZvVu5SHhsluyXUfM75WbbpoQnXWSj+owYvvNyCHlf LgPXOXoG+q/465L6QoOVzRKw9HCE9FiAo1LTTtLg+dHuhmswx4HTFk4Rx+2M3mVRAPHa C+krvu/9mPrCckf7ra8zWbRl0cg/TMa2GcHD50KegDf5kqn2lV7KC+CPJPDDVMb+ktRU BvZA2TyJXHUSElkiW4BNAdzKy2DynXoa4EeGPDc98L8Akva8OiYU5FzNjS7PTl+XqhCZ 5S3Q== X-Gm-Message-State: ALoCoQlKI3FZK8ZRumm5f47TEAukBo5F+RTTSkZxL/TALNXcwEU5ul5uoXUqfmmMrOgr+AbHacWM MIME-Version: 1.0 X-Received: by 10.140.147.77 with SMTP id 74mr39141379qht.52.1445274612634; Mon, 19 Oct 2015 10:10:12 -0700 (PDT) Received: by 10.55.142.195 with HTTP; Mon, 19 Oct 2015 10:10:12 -0700 (PDT) In-Reply-To: <20151019170720.18931.485.idtracker@ietfa.amsl.com> References: <20151019170720.18931.485.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 10:10:12 -0700 Message-ID: From: Ina Minei To: pce Content-Type: multipart/alternative; boundary=001a113552f2e429070522783771 Archived-At: Subject: Re: [Pce] I-D Action: draft-ietf-pce-stateful-pce-app-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 17:10:31 -0000 --001a113552f2e429070522783771 Content-Type: text/plain; charset=UTF-8 This is just a version refresh, as the draft is expiring. There has been no content change in this draft for the last 12 months (since October 2014). Ina On Mon, Oct 19, 2015 at 10:07 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Path Computation Element Working Group > of the IETF. > > Title : Applicability of a Stateful Path Computation > Element (PCE) > Authors : Xian Zhang > Ina Minei > Filename : draft-ietf-pce-stateful-pce-app-05.txt > Pages : 25 > Date : 2015-10-19 > > Abstract: > A stateful Path Computation Element (PCE) maintains information about > Label Switched Path (LSP) characteristics and resource usage within a > network in order to provide traffic engineering calculations for its > associated Path Computation Clients (PCCs). This document describes > general considerations for a stateful PCE deployment and examines its > applicability and benefits, as well as its challenges and limitations > through a number of use cases. PCE Communication Protocol (PCEP) > extensions required for stateful PCE usage are covered in separate > documents. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-app/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-app-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-stateful-pce-app-05 > > > 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/ > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > --001a113552f2e429070522783771 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is just a version refresh, as the draft is expiring. = There has been no content change in this draft for the last 12 months (sinc= e October 2014).=C2=A0

Ina=C2=A0

On Mon, Oct 19, 2015 at 10:= 07 AM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Path Computation Element Working Gro= up of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Applicability of a Stateful Path Computation Element (PCE)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Xian= Zhang
=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 Ina Minei
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-pce-stateful-pce-app-05.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 25
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-10-19

Abstract:
=C2=A0 =C2=A0A stateful Path Computation Element (PCE) maintains informatio= n about
=C2=A0 =C2=A0Label Switched Path (LSP) characteristics and resource usage w= ithin a
=C2=A0 =C2=A0network in order to provide traffic engineering calculations f= or its
=C2=A0 =C2=A0associated Path Computation Clients (PCCs).=C2=A0 This documen= t describes
=C2=A0 =C2=A0general considerations for a stateful PCE deployment and exami= nes its
=C2=A0 =C2=A0applicability and benefits, as well as its challenges and limi= tations
=C2=A0 =C2=A0through a number of use cases.=C2=A0 PCE Communication Protoco= l (PCEP)
=C2=A0 =C2=A0extensions required for stateful PCE usage are covered in sepa= rate
=C2=A0 =C2=A0documents.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/dr= aft-ietf-pce-stateful-pce-app/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf= -pce-stateful-pce-app-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?u= rl2=3Ddraft-ietf-pce-stateful-pce-app-05


Please note that it may take a couple of minutes from the time of submissio= n
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/

_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

--001a113552f2e429070522783771-- From nobody Wed Oct 21 02:59:06 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0398F1A1B53 for ; Wed, 21 Oct 2015 02:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.894 X-Spam-Level: X-Spam-Status: No, score=-0.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, SPF_SOFTFAIL=0.665, T_RP_MATCHES_RCVD=-0.01] 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 6IYTcIKDw4GM for ; Wed, 21 Oct 2015 02:59:03 -0700 (PDT) Received: from p-mail1.rd.orange.com (p-mail1.rd.orange.com [161.106.1.2]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1DB1A1B51 for ; Wed, 21 Oct 2015 02:59:03 -0700 (PDT) Received: from p-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6912D7CC005 for ; Wed, 21 Oct 2015 11:59:02 +0200 (CEST) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail1.rd.orange.com (Postfix) with ESMTP id E599741022E for ; Wed, 21 Oct 2015 11:59:01 +0200 (CEST) Received: from [10.193.71.112] (10.193.71.112) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.224.2; Wed, 21 Oct 2015 11:59:01 +0200 To: "pce@ietf.org" From: Olivier Dugeon Organization: Orange Labs Message-ID: <562761E5.8020302@orange.com> Date: Wed, 21 Oct 2015 11:59:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Pce] Questions about PCE Stateful Synchronisation X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2015 09:59:05 -0000 Dear authors of draft-ietf-pce-stateful and draft-ietf-pce-stateful-sync-optimizations, I know that we are in the last miles before publish PCE Stateful draft collection as RFCs, but regarding the chairs' review, I have a global interrogation about synchronisation. Even I-Ds try to avoid it, I'm afraid that there will different cases where de-synchronisation is not avoided between PCCs and PCEs. In particular, in case of problem, not a real failure, more a bug, memory saturation or whatever mal-function could occur on the PCE or PCC side, a PCE could miss a PCRpt message from a PCC or respectively a PCC could miss to send a PCRpt message to a PCE. I'm also afraid, after a long live period (say, several weeks or months) that some orphan LSPs appear in the PCE LSPs database without the possibility to detect them and remove them. To go back in a full sync state, it is then necessary to restart properly the PCEP session, i.e. force a re-synchronisation. But, to do that, you need to discover the problem. That's another topic. So, my question is why do you not have use a similar mechanism to routing protocol, i.e. OSPF, IS-IS or BGP, to periodically send LSPs state from the PCC to the PCE. Using an 'out of date' indication will allow the PCE to remove in its LSP-DB 'out of date' LSPs like OSPF do when it flushes an LSA with ageing equal to 3600 in its TED. What it is sufficient is to add a new statement in draft-ietf-pce-stateful (e.g., in section 9.1. Control Function and Policy) telling that: - the PCC MUST send PCRpt message on a regular basis, before MAX_AGE expire. - the PCE MUST ignore LSPs that are not refresh since a period of time greater than MAX_AGE. Then, two cases are possible: a) MAX_AGE is fixed in the RFC e.g. to 3600 seconds like in OSPF (seems reasonable) b) Negotiate/exchange during PCEP session establishment or when PCRpt message is sent If option (a) is quiet simple but not flexible, it has the great advantage to not introduce new PCEP Object while option (b) need new PCEP Object definition, but provide a greater flexibility. If we agree on the statement above, I think that option (a) is sufficient and just need additional text in current draft while if we want to support option (b), I could work on a new draft. Regards, Olivier -- logo Orange Olivier Dugeon Orange Expert, Future Networks Open Source Referent Orange/IMT/OLN/WTC/IEE/OPEN fixe : +33 2 96 05 28 80 mobile : +33 6 82 90 37 85 olivier.dugeon@orange.com From nobody Wed Oct 21 06:01:42 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 542281A6FB1 for ; Wed, 21 Oct 2015 06:01:40 -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 1hR5OrTnt0Lh for ; Wed, 21 Oct 2015 06:01:38 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7572B1A6FB9 for ; Wed, 21 Oct 2015 06:01:38 -0700 (PDT) Received: by iofz202 with SMTP id z202so56019925iof.2 for ; Wed, 21 Oct 2015 06:01:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=OnywXK82G2T9ue8OMJOBCO1KZyF0a1PcSGQCWHe8+/0=; b=y5TQ0f6zrpGOnbaBgCKHoLHQoWQ+4uZJ9mCWWNtJDq0uiUIyJYvJdeaTLN94UuC9zd Lc86S7ynpOeuaX24OWEPXPqvnYNTcxxoSVjCBCjAu80iS7RONmB8amIyWltwgbU73iWk R1d6IiuM9LMGJM3/L7PMi4Zy+xH8FgvYCh0GXuPAEzOwcHQO7O+trTF+RwpM/Yogaf6G c6g6zqtMPEHRJS0rIUkzm0KxX/KE5NImFyd46M3Y+/9TuHXqAX3twg05o1STsr8cBqya xtKnoAmDJKAt7scsYqkOL6XHoDwYQUWkgHa3mjlohPPMxWNTXh9ySD6wGVSH7xiXlh5H hIJA== MIME-Version: 1.0 X-Received: by 10.107.17.149 with SMTP id 21mr10020419ior.21.1445432497690; Wed, 21 Oct 2015 06:01:37 -0700 (PDT) Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.27.106 with HTTP; Wed, 21 Oct 2015 06:01:37 -0700 (PDT) In-Reply-To: <562761E5.8020302@orange.com> References: <562761E5.8020302@orange.com> Date: Wed, 21 Oct 2015 18:31:37 +0530 X-Google-Sender-Auth: JZZDJ83mH4dvZBxchq87lUb9ggc Message-ID: From: Dhruv Dhody To: Olivier Dugeon Content-Type: multipart/alternative; boundary=001a1140831092603405229cfa13 Archived-At: Cc: "pce@ietf.org" Subject: Re: [Pce] Questions about PCE Stateful Synchronisation X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2015 13:01:40 -0000 --001a1140831092603405229cfa13 Content-Type: text/plain; charset=UTF-8 Hi Olivier, Wanted to bring "PCE triggered re-syncronization" [ https://tools.ietf.org/html/draft-ietf-pce-stateful-sync-optimizations-03#section-6] to your notice. This can be used by a PCE to periodically re-synchronize the database without bringing down the PCEP session. Will this not cover the issue you have in mind? Regards, Dhruv On Wed, Oct 21, 2015 at 3:29 PM, Olivier Dugeon wrote: > Dear authors of draft-ietf-pce-stateful and > draft-ietf-pce-stateful-sync-optimizations, > > I know that we are in the last miles before publish PCE Stateful draft > collection as RFCs, but regarding the chairs' review, I have a global > interrogation about synchronisation. Even I-Ds try to avoid it, I'm afraid > that there will different cases where de-synchronisation is not avoided > between PCCs and PCEs. In particular, in case of problem, not a real > failure, more a bug, memory saturation or whatever mal-function could occur > on the PCE or PCC side, a PCE could miss a PCRpt message from a PCC or > respectively a PCC could miss to send a PCRpt message to a PCE. I'm also > afraid, after a long live period (say, several weeks or months) that some > orphan LSPs appear in the PCE LSPs database without the possibility to > detect them and remove them. > > To go back in a full sync state, it is then necessary to restart properly > the PCEP session, i.e. force a re-synchronisation. But, to do that, you > need to discover the problem. That's another topic. > > So, my question is why do you not have use a similar mechanism to routing > protocol, i.e. OSPF, IS-IS or BGP, to periodically send LSPs state from the > PCC to the PCE. Using an 'out of date' indication will allow the PCE to > remove in its LSP-DB 'out of date' LSPs like OSPF do when it flushes an LSA > with ageing equal to 3600 in its TED. > > What it is sufficient is to add a new statement in draft-ietf-pce-stateful > (e.g., in section 9.1. Control Function and Policy) telling that: > - the PCC MUST send PCRpt message on a regular basis, before MAX_AGE > expire. > - the PCE MUST ignore LSPs that are not refresh since a period of time > greater than MAX_AGE. > > Then, two cases are possible: > a) MAX_AGE is fixed in the RFC e.g. to 3600 seconds like in OSPF (seems > reasonable) > b) Negotiate/exchange during PCEP session establishment or when PCRpt > message is sent > > If option (a) is quiet simple but not flexible, it has the great advantage > to not introduce new PCEP Object while option (b) need new PCEP Object > definition, but provide a greater flexibility. > > If we agree on the statement above, I think that option (a) is sufficient > and just need additional text in current draft while if we want to support > option (b), I could work on a new draft. > > Regards, > > Olivier > -- > logo Orange > > Olivier Dugeon > Orange Expert, Future Networks > Open Source Referent > Orange/IMT/OLN/WTC/IEE/OPEN > > fixe : +33 2 96 05 28 80 > mobile : +33 6 82 90 37 85 > olivier.dugeon@orange.com > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > --001a1140831092603405229cfa13 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Olivier,=C2=A0

Wanted to = bring "PCE triggered re-syncronization" [htt= ps://tools.ietf.org/html/draft-ietf-pce-stateful-sync-optimizations-03#sect= ion-6] to your notice. This can be used by a PCE to periodically re-syn= chronize the database without bringing down the PCEP session.=C2=A0

Will th= is not cover the issue you have in mind?=C2=A0

Regards,
Dhruv


On Wed, Oct 21, 201= 5 at 3:29 PM, Olivier Dugeon <olivier.dugeon@orange.com> wrote:
Dear authors of draft-ietf-pc= e-stateful and draft-ietf-pce-stateful-sync-optimizations,

I know that we are in the last miles before publish PCE Stateful draft coll= ection as RFCs, but regarding the chairs' review, I have a global inter= rogation about synchronisation. Even I-Ds try to avoid it, I'm afraid t= hat there will different cases where de-synchronisation is not avoided betw= een PCCs and PCEs. In particular, in case of problem, not a real failure, m= ore a bug, memory saturation or whatever mal-function could occur on the PC= E or PCC side, a PCE could miss a PCRpt message from a PCC or respectively = a PCC could miss to send a PCRpt message to a PCE. I'm also afraid, aft= er a long live period (say, several weeks or months) that some orphan LSPs = appear in the PCE LSPs database without the possibility to detect them and = remove them.

To go back in a full sync state, it is then necessary to restart properly t= he PCEP session, i.e. force a re-synchronisation. But, to do that, you need= to discover the problem. That's another topic.

So, my question is why do you not have use a similar mechanism to routing p= rotocol, i.e. OSPF, IS-IS or BGP, to periodically send LSPs state from the = PCC to the PCE. Using an 'out of date' indication will allow the PC= E to remove in its LSP-DB 'out of date' LSPs like OSPF do when it f= lushes an LSA with ageing equal to 3600 in its TED.

What it is sufficient is to add a new statement in draft-ietf-pce-stateful = (e.g., in section 9.1.=C2=A0 Control Function and Policy) telling that:
=C2=A0- the PCC MUST send PCRpt message on a regular basis, before MAX_AGE = expire.
=C2=A0- the PCE MUST ignore LSPs that are not refresh since a period of tim= e greater than MAX_AGE.

Then, two cases are possible:
=C2=A0a) MAX_AGE is fixed in the RFC e.g. to 3600 seconds like in OSPF (see= ms reasonable)
=C2=A0b) Negotiate/exchange during PCEP session establishment or when PCRpt= message is sent

If option (a) is quiet simple but not flexible, it has the great advantage = to not introduce new PCEP Object while option (b) need new PCEP Object defi= nition, but provide a greater flexibility.

If we agree on the statement above,=C2=A0 I think that option (a) is suffic= ient and just need additional text in current draft while if we want to sup= port option (b), I could work on a new draft.

Regards,

Olivier
--
logo Orange <http://www.orange.com>

Olivier Dugeon
Orange Expert, Future Networks
Open Source Referent
Orange/IMT/OLN/WTC/IEE/OPEN

fixe : +33 2 96 05 28 80
mobile : +33 6 82 90 37 85
olivier.duge= on@orange.com <mailto:olivier.dugeon@orange.com>

_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

--001a1140831092603405229cfa13-- From nobody Wed Oct 21 07:13:40 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB57E1A88E1 for ; Wed, 21 Oct 2015 07:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.893 X-Spam-Level: X-Spam-Status: No, score=-0.893 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665, T_RP_MATCHES_RCVD=-0.01] 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 8uU3-yS8Ojsp for ; Wed, 21 Oct 2015 07:13:34 -0700 (PDT) Received: from p-mail1.rd.orange.com (p-mail1.rd.orange.com [161.106.1.2]) by ietfa.amsl.com (Postfix) with ESMTP id 383B11A88EC for ; Wed, 21 Oct 2015 07:13:13 -0700 (PDT) Received: from p-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 573D37CC013; Wed, 21 Oct 2015 16:13:12 +0200 (CEST) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail1.rd.orange.com (Postfix) with ESMTP id 3203A7CC003; Wed, 21 Oct 2015 16:13:12 +0200 (CEST) Received: from [10.193.71.112] (10.193.71.112) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.224.2; Wed, 21 Oct 2015 16:13:11 +0200 To: Dhruv Dhody References: <562761E5.8020302@orange.com> From: Olivier Dugeon Organization: Orange Labs Message-ID: <56279D77.7090701@orange.com> Date: Wed, 21 Oct 2015 16:13:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------070301060900060601070702" Archived-At: Cc: "pce@ietf.org" Subject: Re: [Pce] Questions about PCE Stateful Synchronisation X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2015 14:13:37 -0000 --------------070301060900060601070702 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable Hello Dhruv, Thanks pointing me this section, but I read the draft before asking my=20 questions. For me, it is not completely cover this issue, and my answer=20 is Yes and No. Yes, because the mechanism allow such re-synchronization without closing = the PCEP session, but at the price of exchanging PCUpd / PCRpt message=20 when only one PCRpt message is sufficient. It solves the problem of=20 orphan LSP. In this case, I agree that when the PCE asks to update an=20 orphan LSP it gets an error (I suppose as it is not specify in the draft)= =2E An No, because it not solves completely the issue if the PCE is not=20 aware of an LSP. The PCE could not request an update about an LSPs it=20 ignores. So, the only working solution for the PCE is to ask regularly all PCCs=20 to send their complete LSP DB to be sure that it is always synchronized, = but it is a very costly mechanism. In addition, I have some doubt that this mechanism scale well. For large = networks, say more then 1000 PE routers, so more than 1000 PCEP=20 sessions, with a full mesh of TE tunnels (I know it is an extreme case)=20 this increase drastically the exchange between the PCE and PCCs and add=20 extra CPU process for the PCE. The later must parse 1,000,000 tunnels in = its LSPs DB and ask PCCs to refresh them. Or, asks all PCCs to update=20 all their tunnels. In the first case the PCE spent its time to send=20 PCUpd message waiting for the corresponding PCRpt answer and in the=20 second case it spent its time to parse 1000 tunnels each time it asks a=20 PCC for a full refresh. Flood periodically Link State in IGP protocol has proof for a long time=20 that it scale well even in very large network. Why not re-using a=20 similar concept ? And, last but not least, what's happen with LSP tunnels that are=20 configured on router that are not PCEP enable ? There are simply ignored = ? Regards, Olivier Le 21/10/2015 15:01, Dhruv Dhody a =C3=A9crit : > Hi Olivier, > > Wanted to bring "PCE triggered re-syncronization"=20 > [https://tools.ietf.org/html/draft-ietf-pce-stateful-sync-optimizations= -03#section-6]=20 > to your notice. This can be used by a PCE to periodically=20 > re-synchronize the database without bringing down the PCEP session. > > Will this not cover the issue you have in mind? > > Regards, > Dhruv > > > On Wed, Oct 21, 2015 at 3:29 PM, Olivier Dugeon=20 > > wrote: > > Dear authors of draft-ietf-pce-stateful and > draft-ietf-pce-stateful-sync-optimizations, > > I know that we are in the last miles before publish PCE Stateful > draft collection as RFCs, but regarding the chairs' review, I have > a global interrogation about synchronisation. Even I-Ds try to > avoid it, I'm afraid that there will different cases where > de-synchronisation is not avoided between PCCs and PCEs. In > particular, in case of problem, not a real failure, more a bug, > memory saturation or whatever mal-function could occur on the PCE > or PCC side, a PCE could miss a PCRpt message from a PCC or > respectively a PCC could miss to send a PCRpt message to a PCE. > I'm also afraid, after a long live period (say, several weeks or > months) that some orphan LSPs appear in the PCE LSPs database > without the possibility to detect them and remove them. > > To go back in a full sync state, it is then necessary to restart > properly the PCEP session, i.e. force a re-synchronisation. But, > to do that, you need to discover the problem. That's another topic.= > > So, my question is why do you not have use a similar mechanism to > routing protocol, i.e. OSPF, IS-IS or BGP, to periodically send > LSPs state from the PCC to the PCE. Using an 'out of date' > indication will allow the PCE to remove in its LSP-DB 'out of > date' LSPs like OSPF do when it flushes an LSA with ageing equal > to 3600 in its TED. > > What it is sufficient is to add a new statement in > draft-ietf-pce-stateful (e.g., in section 9.1. Control Function > and Policy) telling that: > - the PCC MUST send PCRpt message on a regular basis, before > MAX_AGE expire. > - the PCE MUST ignore LSPs that are not refresh since a period of > time greater than MAX_AGE. > > Then, two cases are possible: > a) MAX_AGE is fixed in the RFC e.g. to 3600 seconds like in OSPF > (seems reasonable) > b) Negotiate/exchange during PCEP session establishment or when > PCRpt message is sent > > If option (a) is quiet simple but not flexible, it has the great > advantage to not introduce new PCEP Object while option (b) need > new PCEP Object definition, but provide a greater flexibility. > > If we agree on the statement above, I think that option (a) is > sufficient and just need additional text in current draft while if > we want to support option (b), I could work on a new draft. > > Regards, > > Olivier > --=20 > logo Orange > > Olivier Dugeon > Orange Expert, Future Networks > Open Source Referent > Orange/IMT/OLN/WTC/IEE/OPEN > > fixe : +33 2 96 05 28 80 > mobile : +33 6 82 90 37 85 > olivier.dugeon@orange.com > > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > --------------070301060900060601070702 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Dhruv,

Thanks pointing me this section, but I read the draft before asking my questions. For me, it is not completely cover this issue, and my answer is Yes and No.

Yes, because the mechanism allow such re-synchronization without closing the PCEP session, but at the price of exchanging PCUpd / PCRpt message when only one PCRpt message is sufficient. It solves the problem of orphan LSP. In this case, I agree that when the PCE asks to update an orphan LSP it gets an error (I suppose as it is not specify in the draft).

An No, because it not solves completely the issue if the PCE is not aware of an LSP. The PCE could not request an update about an LSPs it ignores.

So, the only working solution for the PCE is to ask regularly all PCCs to send their complete LSP DB to be sure that it is always synchronized, but it is a very costly mechanism.

In addition, I have some doubt that this mechanism scale well. For large networks, say more then 1000 PE routers, so more than 1000 PCEP sessions, with a full mesh of TE tunnels (I know it is an extreme case) this increase drastically the exchange between the PCE and PCCs and add extra CPU process for the PCE. The later must parse 1,000,000 tunnels in its LSPs DB and ask PCCs to refresh them. Or, asks all PCCs to update all their tunnels. In the first case the PCE spent its time to send PCUpd message waiting for the corresponding PCRpt answer and in the second case it spent its time to parse 1000 tunnels each time it asks a PCC for a full refresh.

Flood periodically Link State in IGP protocol has proof for a long time that it scale well even in very large network. Why not re-using a similar concept ?

And, last but not least, what's happen with LSP tunnels that are configured on router that are not PCEP enable ? There are simply ignored ?

Regards,

Olivier

Le 21/10/2015 15:01, Dhruv Dhody a =C3=A9crit=C2=A0:
Hi Olivier,=C2=A0

Wanted to bring "PCE triggered re-syncronization" [https://tools.ietf.org/html/draft-ietf-pce-stateful-s= ync-optimizations-03#section-6] to your notice. This can be used by a PCE to periodically re-synchronize the database without bringing down the PCEP session.=C2=A0

Will this not cover the issue you have in mind?=C2=A0

Regards,
Dhruv


On Wed, Oct 21, 2015 at 3:29 PM, Olivier Dugeon <olivier.dugeon@orange.com> wrote:
Dear authors of draft-ietf-pce-stateful and draft-ietf-pce-stateful-sync-optimizations,

I know that we are in the last miles before publish PCE Stateful draft collection as RFCs, but regarding the chairs' review, I have a global interrogation about synchronisation. Even I-Ds try to avoid it, I'm afraid that there will different cases where de-synchronisation is not avoided between PCCs and PCEs. In particular, in case of problem, not a real failure, more a bug, memory saturation or whatever mal-function could occur on the PCE or PCC side, a PCE could miss a PCRpt message from a PCC or respectively a PCC could miss to send a PCRpt message to a PCE. I'm also afraid, after a long live period (say, several weeks or months) that some orphan LSPs appear in the PCE LSPs database without the possibility to detect them and remove them.

To go back in a full sync state, it is then necessary to restart properly the PCEP session, i.e. force a re-synchronisation. But, to do that, you need to discover the problem. That's another topic.

So, my question is why do you not have use a similar mechanism to routing protocol, i.e. OSPF, IS-IS or BGP, to periodically send LSPs state from the PCC to the PCE. Using an 'out of date' indication will allow the PCE to remove in its LSP-DB 'out of date' LSPs like OSPF do when it flushes an LSA with ageing equal to 3600 in its TED.

What it is sufficient is to add a new statement in draft-ietf-pce-stateful (e.g., in section 9.1.=C2=A0 Control Function and Policy) telling that:
=C2=A0- the PCC MUST send PCRpt message on a regular basis, before MAX_AGE expire.
=C2=A0- the PCE MUST ignore LSPs that are not refresh since a= period of time greater than MAX_AGE.

Then, two cases are possible:
=C2=A0a) MAX_AGE is fixed in the RFC e.g. to 3600 seconds lik= e in OSPF (seems reasonable)
=C2=A0b) Negotiate/exchange during PCEP session establishment= or when PCRpt message is sent

If option (a) is quiet simple but not flexible, it has the great advantage to not introduce new PCEP Object while option (b) need new PCEP Object definition, but provide a greater flexibility.

If we agree on the statement above,=C2=A0 I think that option= (a) is sufficient and just need additional text in current draft while if we want to support option (b), I could work on a new draft.

Regards,

Olivier
--
logo Orange <http://www.orange.com>

Olivier Dugeon
Orange Expert, Future Networks
Open Source Referent
Orange/IMT/OLN/WTC/IEE/OPEN

fixe : +33 2 96 05 28 80
mobile : +33 6 82 90 37 85
olivier.dugeon@orange.com <mailto:olivier.dugeon@orange.com>

_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/m= ailman/listinfo/pce


--------------070301060900060601070702-- From nobody Wed Oct 21 21:59:05 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D185E1B2A09 for ; Wed, 21 Oct 2015 21:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 4s4V8fLNHdEQ for ; Wed, 21 Oct 2015 21:59:01 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 103DD1B2A07 for ; Wed, 21 Oct 2015 21:58:59 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CCW34282; Thu, 22 Oct 2015 04:58:58 +0000 (GMT) Received: from BLREML406-HUB.china.huawei.com (10.20.4.43) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 22 Oct 2015 05:58:56 +0100 Received: from BLREML509-MBX.china.huawei.com ([169.254.7.243]) by BLREML406-HUB.china.huawei.com ([10.20.4.43]) with mapi id 14.03.0235.001; Thu, 22 Oct 2015 10:28:48 +0530 From: Dhruv Dhody To: Olivier Dugeon , Dhruv Dhody Thread-Topic: [Pce] Questions about PCE Stateful Synchronisation Thread-Index: AQHRC+cw4fGavtydl0C1oQ73ubgzGZ51jTuAgAAT/4CAAUMBwA== Date: Thu, 22 Oct 2015 04:58:47 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B8C429626@BLREML509-MBX.china.huawei.com> References: <562761E5.8020302@orange.com> <56279D77.7090701@orange.com> In-Reply-To: <56279D77.7090701@orange.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.244.252] Content-Type: multipart/alternative; boundary="_000_23CE718903A838468A8B325B80962F9B8C429626BLREML509MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "pce@ietf.org" Subject: Re: [Pce] Questions about PCE Stateful Synchronisation X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 04:59:05 -0000 --_000_23CE718903A838468A8B325B80962F9B8C429626BLREML509MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgT2xpdmllciwNCg0KSU1ITyBQQ0VQIGlzIG11Y2ggY2xvc2VyIHRvIEJHUCAod2hlbiBjb21w YXJlZCB0byBJR1ApLCBhbmQgaW4gdGhhdCBQQ0UtdHJpZ2dlcmVkIGZ1bGwgcmUtc3luYyBpcyBz aW1pbGFyIHRvIEJHUOKAmXMgcm91dGUtcmVmcmVzaCBtZWNoYW5pc20uIFNvIEkgZ3Vlc3Mgd2Ug YXJlIHJlLXVzaW5nIGEgc2ltaWxhciBjb25jZXB0IHdoaWNoIHNjYWxlcyB3ZWxsIHRvbyA6KQ0K DQpBcyB5b3UgYWxzbyBtZW50aW9uIHRoYXQgc3VjaCBpc3N1ZSBtaWdodCBiZSBzZWVuIG9uIGEg bG9uZyBydW5uaW5nIHNlc3Npb24sIHRoaXMgcmUtc3luYyBpZiBuZWVkZWQsIHdvdWxkIGJlIGFm dGVyIGEgbG9uZyB0aW1lLg0KSU1ITyBzZW5kaW5nIFBDUnB0IHJlcGVhdGVkbHkgc2F5IGF0IGV2 ZXJ5IDM2MDAgc2VjcyBmb3IgYWxsIExTUCB3b3VsZCBiZSBjb3N0bHkgdG9vLg0KDQpJIHdpbGwg bGVhdmUgaXQgdG8gdGhlIGF1dGhvcnMgb2YgdGhlIGJhc2UgZHJhZnQgdG8gYW5zd2VyIHlvdXIg b3RoZXIgcXVlc3Rpb24uIEluIHRoZSBpbXBsZW1lbnRhdGlvbnMgdGhhdCBJIGFtIGF3YXJlIG9m LCB0aGF0IGlzIHRoZSBsb2NhbCBwb2xpY3kgYW5kIHVzdWFsbHkgc2V0IHRvIHJlcG9ydCBhbGwg TFNQcy4NCg0KUmVnYXJkcywNCkRocnV2DQoNCkZyb206IFBjZSBbbWFpbHRvOnBjZS1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgT2xpdmllciBEdWdlb24NClNlbnQ6IDIxIE9jdG9iZXIg MjAxNSAxOTo0Mw0KVG86IERocnV2IERob2R5DQpDYzogcGNlQGlldGYub3JnDQpTdWJqZWN0OiBS ZTogW1BjZV0gUXVlc3Rpb25zIGFib3V0IFBDRSBTdGF0ZWZ1bCBTeW5jaHJvbmlzYXRpb24NCg0K SGVsbG8gRGhydXYsDQoNClRoYW5rcyBwb2ludGluZyBtZSB0aGlzIHNlY3Rpb24sIGJ1dCBJIHJl YWQgdGhlIGRyYWZ0IGJlZm9yZSBhc2tpbmcgbXkgcXVlc3Rpb25zLiBGb3IgbWUsIGl0IGlzIG5v dCBjb21wbGV0ZWx5IGNvdmVyIHRoaXMgaXNzdWUsIGFuZCBteSBhbnN3ZXIgaXMgWWVzIGFuZCBO by4NCg0KWWVzLCBiZWNhdXNlIHRoZSBtZWNoYW5pc20gYWxsb3cgc3VjaCByZS1zeW5jaHJvbml6 YXRpb24gd2l0aG91dCBjbG9zaW5nIHRoZSBQQ0VQIHNlc3Npb24sIGJ1dCBhdCB0aGUgcHJpY2Ug b2YgZXhjaGFuZ2luZyBQQ1VwZCAvIFBDUnB0IG1lc3NhZ2Ugd2hlbiBvbmx5IG9uZSBQQ1JwdCBt ZXNzYWdlIGlzIHN1ZmZpY2llbnQuIEl0IHNvbHZlcyB0aGUgcHJvYmxlbSBvZiBvcnBoYW4gTFNQ LiBJbiB0aGlzIGNhc2UsIEkgYWdyZWUgdGhhdCB3aGVuIHRoZSBQQ0UgYXNrcyB0byB1cGRhdGUg YW4gb3JwaGFuIExTUCBpdCBnZXRzIGFuIGVycm9yIChJIHN1cHBvc2UgYXMgaXQgaXMgbm90IHNw ZWNpZnkgaW4gdGhlIGRyYWZ0KS4NCg0KQW4gTm8sIGJlY2F1c2UgaXQgbm90IHNvbHZlcyBjb21w bGV0ZWx5IHRoZSBpc3N1ZSBpZiB0aGUgUENFIGlzIG5vdCBhd2FyZSBvZiBhbiBMU1AuIFRoZSBQ Q0UgY291bGQgbm90IHJlcXVlc3QgYW4gdXBkYXRlIGFib3V0IGFuIExTUHMgaXQgaWdub3Jlcy4N Cg0KU28sIHRoZSBvbmx5IHdvcmtpbmcgc29sdXRpb24gZm9yIHRoZSBQQ0UgaXMgdG8gYXNrIHJl Z3VsYXJseSBhbGwgUENDcyB0byBzZW5kIHRoZWlyIGNvbXBsZXRlIExTUCBEQiB0byBiZSBzdXJl IHRoYXQgaXQgaXMgYWx3YXlzIHN5bmNocm9uaXplZCwgYnV0IGl0IGlzIGEgdmVyeSBjb3N0bHkg bWVjaGFuaXNtLg0KDQpJbiBhZGRpdGlvbiwgSSBoYXZlIHNvbWUgZG91YnQgdGhhdCB0aGlzIG1l Y2hhbmlzbSBzY2FsZSB3ZWxsLiBGb3IgbGFyZ2UgbmV0d29ya3MsIHNheSBtb3JlIHRoZW4gMTAw MCBQRSByb3V0ZXJzLCBzbyBtb3JlIHRoYW4gMTAwMCBQQ0VQIHNlc3Npb25zLCB3aXRoIGEgZnVs bCBtZXNoIG9mIFRFIHR1bm5lbHMgKEkga25vdyBpdCBpcyBhbiBleHRyZW1lIGNhc2UpIHRoaXMg aW5jcmVhc2UgZHJhc3RpY2FsbHkgdGhlIGV4Y2hhbmdlIGJldHdlZW4gdGhlIFBDRSBhbmQgUEND cyBhbmQgYWRkIGV4dHJhIENQVSBwcm9jZXNzIGZvciB0aGUgUENFLiBUaGUgbGF0ZXIgbXVzdCBw YXJzZSAxLDAwMCwwMDAgdHVubmVscyBpbiBpdHMgTFNQcyBEQiBhbmQgYXNrIFBDQ3MgdG8gcmVm cmVzaCB0aGVtLiBPciwgYXNrcyBhbGwgUENDcyB0byB1cGRhdGUgYWxsIHRoZWlyIHR1bm5lbHMu IEluIHRoZSBmaXJzdCBjYXNlIHRoZSBQQ0Ugc3BlbnQgaXRzIHRpbWUgdG8gc2VuZCBQQ1VwZCBt ZXNzYWdlIHdhaXRpbmcgZm9yIHRoZSBjb3JyZXNwb25kaW5nIFBDUnB0IGFuc3dlciBhbmQgaW4g dGhlIHNlY29uZCBjYXNlIGl0IHNwZW50IGl0cyB0aW1lIHRvIHBhcnNlIDEwMDAgdHVubmVscyBl YWNoIHRpbWUgaXQgYXNrcyBhIFBDQyBmb3IgYSBmdWxsIHJlZnJlc2guDQoNCkZsb29kIHBlcmlv ZGljYWxseSBMaW5rIFN0YXRlIGluIElHUCBwcm90b2NvbCBoYXMgcHJvb2YgZm9yIGEgbG9uZyB0 aW1lIHRoYXQgaXQgc2NhbGUgd2VsbCBldmVuIGluIHZlcnkgbGFyZ2UgbmV0d29yay4gV2h5IG5v dCByZS11c2luZyBhIHNpbWlsYXIgY29uY2VwdCA/DQoNCkFuZCwgbGFzdCBidXQgbm90IGxlYXN0 LCB3aGF0J3MgaGFwcGVuIHdpdGggTFNQIHR1bm5lbHMgdGhhdCBhcmUgY29uZmlndXJlZCBvbiBy b3V0ZXIgdGhhdCBhcmUgbm90IFBDRVAgZW5hYmxlID8gVGhlcmUgYXJlIHNpbXBseSBpZ25vcmVk ID8NCg0KUmVnYXJkcywNCg0KT2xpdmllcg0KTGUgMjEvMTAvMjAxNSAxNTowMSwgRGhydXYgRGhv ZHkgYSDDqWNyaXQgOg0KSGkgT2xpdmllciwNCg0KV2FudGVkIHRvIGJyaW5nICJQQ0UgdHJpZ2dl cmVkIHJlLXN5bmNyb25pemF0aW9uIiBbaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtcGNlLXN0YXRlZnVsLXN5bmMtb3B0aW1pemF0aW9ucy0wMyNzZWN0aW9uLTZdIHRvIHlv dXIgbm90aWNlLiBUaGlzIGNhbiBiZSB1c2VkIGJ5IGEgUENFIHRvIHBlcmlvZGljYWxseSByZS1z eW5jaHJvbml6ZSB0aGUgZGF0YWJhc2Ugd2l0aG91dCBicmluZ2luZyBkb3duIHRoZSBQQ0VQIHNl c3Npb24uDQoNCldpbGwgdGhpcyBub3QgY292ZXIgdGhlIGlzc3VlIHlvdSBoYXZlIGluIG1pbmQ/ DQoNClJlZ2FyZHMsDQpEaHJ1dg0KDQoNCk9uIFdlZCwgT2N0IDIxLCAyMDE1IGF0IDM6MjkgUE0s IE9saXZpZXIgRHVnZW9uIDxvbGl2aWVyLmR1Z2VvbkBvcmFuZ2UuY29tPG1haWx0bzpvbGl2aWVy LmR1Z2VvbkBvcmFuZ2UuY29tPj4gd3JvdGU6DQpEZWFyIGF1dGhvcnMgb2YgZHJhZnQtaWV0Zi1w Y2Utc3RhdGVmdWwgYW5kIGRyYWZ0LWlldGYtcGNlLXN0YXRlZnVsLXN5bmMtb3B0aW1pemF0aW9u cywNCg0KSSBrbm93IHRoYXQgd2UgYXJlIGluIHRoZSBsYXN0IG1pbGVzIGJlZm9yZSBwdWJsaXNo IFBDRSBTdGF0ZWZ1bCBkcmFmdCBjb2xsZWN0aW9uIGFzIFJGQ3MsIGJ1dCByZWdhcmRpbmcgdGhl IGNoYWlycycgcmV2aWV3LCBJIGhhdmUgYSBnbG9iYWwgaW50ZXJyb2dhdGlvbiBhYm91dCBzeW5j aHJvbmlzYXRpb24uIEV2ZW4gSS1EcyB0cnkgdG8gYXZvaWQgaXQsIEknbSBhZnJhaWQgdGhhdCB0 aGVyZSB3aWxsIGRpZmZlcmVudCBjYXNlcyB3aGVyZSBkZS1zeW5jaHJvbmlzYXRpb24gaXMgbm90 IGF2b2lkZWQgYmV0d2VlbiBQQ0NzIGFuZCBQQ0VzLiBJbiBwYXJ0aWN1bGFyLCBpbiBjYXNlIG9m IHByb2JsZW0sIG5vdCBhIHJlYWwgZmFpbHVyZSwgbW9yZSBhIGJ1ZywgbWVtb3J5IHNhdHVyYXRp b24gb3Igd2hhdGV2ZXIgbWFsLWZ1bmN0aW9uIGNvdWxkIG9jY3VyIG9uIHRoZSBQQ0Ugb3IgUEND IHNpZGUsIGEgUENFIGNvdWxkIG1pc3MgYSBQQ1JwdCBtZXNzYWdlIGZyb20gYSBQQ0Mgb3IgcmVz cGVjdGl2ZWx5IGEgUENDIGNvdWxkIG1pc3MgdG8gc2VuZCBhIFBDUnB0IG1lc3NhZ2UgdG8gYSBQ Q0UuIEknbSBhbHNvIGFmcmFpZCwgYWZ0ZXIgYSBsb25nIGxpdmUgcGVyaW9kIChzYXksIHNldmVy YWwgd2Vla3Mgb3IgbW9udGhzKSB0aGF0IHNvbWUgb3JwaGFuIExTUHMgYXBwZWFyIGluIHRoZSBQ Q0UgTFNQcyBkYXRhYmFzZSB3aXRob3V0IHRoZSBwb3NzaWJpbGl0eSB0byBkZXRlY3QgdGhlbSBh bmQgcmVtb3ZlIHRoZW0uDQoNClRvIGdvIGJhY2sgaW4gYSBmdWxsIHN5bmMgc3RhdGUsIGl0IGlz IHRoZW4gbmVjZXNzYXJ5IHRvIHJlc3RhcnQgcHJvcGVybHkgdGhlIFBDRVAgc2Vzc2lvbiwgaS5l LiBmb3JjZSBhIHJlLXN5bmNocm9uaXNhdGlvbi4gQnV0LCB0byBkbyB0aGF0LCB5b3UgbmVlZCB0 byBkaXNjb3ZlciB0aGUgcHJvYmxlbS4gVGhhdCdzIGFub3RoZXIgdG9waWMuDQoNClNvLCBteSBx dWVzdGlvbiBpcyB3aHkgZG8geW91IG5vdCBoYXZlIHVzZSBhIHNpbWlsYXIgbWVjaGFuaXNtIHRv IHJvdXRpbmcgcHJvdG9jb2wsIGkuZS4gT1NQRiwgSVMtSVMgb3IgQkdQLCB0byBwZXJpb2RpY2Fs bHkgc2VuZCBMU1BzIHN0YXRlIGZyb20gdGhlIFBDQyB0byB0aGUgUENFLiBVc2luZyBhbiAnb3V0 IG9mIGRhdGUnIGluZGljYXRpb24gd2lsbCBhbGxvdyB0aGUgUENFIHRvIHJlbW92ZSBpbiBpdHMg TFNQLURCICdvdXQgb2YgZGF0ZScgTFNQcyBsaWtlIE9TUEYgZG8gd2hlbiBpdCBmbHVzaGVzIGFu IExTQSB3aXRoIGFnZWluZyBlcXVhbCB0byAzNjAwIGluIGl0cyBURUQuDQoNCldoYXQgaXQgaXMg c3VmZmljaWVudCBpcyB0byBhZGQgYSBuZXcgc3RhdGVtZW50IGluIGRyYWZ0LWlldGYtcGNlLXN0 YXRlZnVsIChlLmcuLCBpbiBzZWN0aW9uIDkuMS4gIENvbnRyb2wgRnVuY3Rpb24gYW5kIFBvbGlj eSkgdGVsbGluZyB0aGF0Og0KIC0gdGhlIFBDQyBNVVNUIHNlbmQgUENScHQgbWVzc2FnZSBvbiBh IHJlZ3VsYXIgYmFzaXMsIGJlZm9yZSBNQVhfQUdFIGV4cGlyZS4NCiAtIHRoZSBQQ0UgTVVTVCBp Z25vcmUgTFNQcyB0aGF0IGFyZSBub3QgcmVmcmVzaCBzaW5jZSBhIHBlcmlvZCBvZiB0aW1lIGdy ZWF0ZXIgdGhhbiBNQVhfQUdFLg0KDQpUaGVuLCB0d28gY2FzZXMgYXJlIHBvc3NpYmxlOg0KIGEp IE1BWF9BR0UgaXMgZml4ZWQgaW4gdGhlIFJGQyBlLmcuIHRvIDM2MDAgc2Vjb25kcyBsaWtlIGlu IE9TUEYgKHNlZW1zIHJlYXNvbmFibGUpDQogYikgTmVnb3RpYXRlL2V4Y2hhbmdlIGR1cmluZyBQ Q0VQIHNlc3Npb24gZXN0YWJsaXNobWVudCBvciB3aGVuIFBDUnB0IG1lc3NhZ2UgaXMgc2VudA0K DQpJZiBvcHRpb24gKGEpIGlzIHF1aWV0IHNpbXBsZSBidXQgbm90IGZsZXhpYmxlLCBpdCBoYXMg dGhlIGdyZWF0IGFkdmFudGFnZSB0byBub3QgaW50cm9kdWNlIG5ldyBQQ0VQIE9iamVjdCB3aGls ZSBvcHRpb24gKGIpIG5lZWQgbmV3IFBDRVAgT2JqZWN0IGRlZmluaXRpb24sIGJ1dCBwcm92aWRl IGEgZ3JlYXRlciBmbGV4aWJpbGl0eS4NCg0KSWYgd2UgYWdyZWUgb24gdGhlIHN0YXRlbWVudCBh Ym92ZSwgIEkgdGhpbmsgdGhhdCBvcHRpb24gKGEpIGlzIHN1ZmZpY2llbnQgYW5kIGp1c3QgbmVl ZCBhZGRpdGlvbmFsIHRleHQgaW4gY3VycmVudCBkcmFmdCB3aGlsZSBpZiB3ZSB3YW50IHRvIHN1 cHBvcnQgb3B0aW9uIChiKSwgSSBjb3VsZCB3b3JrIG9uIGEgbmV3IGRyYWZ0Lg0KDQpSZWdhcmRz LA0KDQpPbGl2aWVyDQotLQ0KbG9nbyBPcmFuZ2UgPGh0dHA6Ly93d3cub3JhbmdlLmNvbT4NCg0K T2xpdmllciBEdWdlb24NCk9yYW5nZSBFeHBlcnQsIEZ1dHVyZSBOZXR3b3Jrcw0KT3BlbiBTb3Vy Y2UgUmVmZXJlbnQNCk9yYW5nZS9JTVQvT0xOL1dUQy9JRUUvT1BFTg0KDQpmaXhlIDogKzMzIDIg OTYgMDUgMjggODANCm1vYmlsZSA6ICszMyA2IDgyIDkwIDM3IDg1DQpvbGl2aWVyLmR1Z2VvbkBv cmFuZ2UuY29tPG1haWx0bzpvbGl2aWVyLmR1Z2VvbkBvcmFuZ2UuY29tPiA8bWFpbHRvOm9saXZp ZXIuZHVnZW9uQG9yYW5nZS5jb208bWFpbHRvOm9saXZpZXIuZHVnZW9uQG9yYW5nZS5jb20+Pg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KUGNlIG1h aWxpbmcgbGlzdA0KUGNlQGlldGYub3JnPG1haWx0bzpQY2VAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BjZQ0KDQoNCg== --_000_23CE718903A838468A8B325B80962F9B8C429626BLREML509MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0 IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlRyZWJ1Y2hldCBNUyI7 DQoJcGFub3NlLTE6MiAxMSA2IDMgMiAyIDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpVYnVudHU7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg MDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwg ZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7 DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IlRyZWJ1Y2hldCBNUyIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw LjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFy Z2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgT2xpdmllciw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtUcmVi dWNoZXQgTVMmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JTUhP IFBDRVAgaXMgbXVjaCBjbG9zZXIgdG8gQkdQICh3aGVuIGNvbXBhcmVkIHRvIElHUCksIGFuZCBp biB0aGF0IFBDRS10cmlnZ2VyZWQgZnVsbCByZS1zeW5jIGlzIHNpbWlsYXIgdG8gQkdQ4oCZcyBy b3V0ZS1yZWZyZXNoIG1lY2hhbmlzbS4gU28gSSBndWVzcw0KIHdlIGFyZSByZS11c2luZyBhIHNp bWlsYXIgY29uY2VwdCB3aGljaCBzY2FsZXMgd2VsbCB0b28gOik8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtUcmVidWNoZXQgTVMmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5BcyB5b3UgYWxzbyBtZW50aW9uIHRoYXQgc3VjaCBpc3N1ZSBtaWdodCBiZSBzZWVuIG9uIGEg bG9uZyBydW5uaW5nIHNlc3Npb24sIHRoaXMgcmUtc3luYyBpZiBuZWVkZWQsIHdvdWxkIGJlIGFm dGVyIGEgbG9uZyB0aW1lLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VHJl YnVjaGV0IE1TJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SU1I TyBzZW5kaW5nIFBDUnB0IHJlcGVhdGVkbHkgc2F5IGF0IGV2ZXJ5IDM2MDAgc2VjcyBmb3IgYWxs IExTUCB3b3VsZCBiZSBjb3N0bHkgdG9vLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0 IE1TJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB3aWxsIGxl YXZlIGl0IHRvIHRoZSBhdXRob3JzIG9mIHRoZSBiYXNlIGRyYWZ0IHRvIGFuc3dlciB5b3VyIG90 aGVyIHF1ZXN0aW9uLiBJbiB0aGUgaW1wbGVtZW50YXRpb25zIHRoYXQgSSBhbSBhd2FyZSBvZiwg dGhhdCBpcyB0aGUgbG9jYWwgcG9saWN5IGFuZA0KIHVzdWFsbHkgc2V0IHRvIHJlcG9ydCBhbGwg TFNQcy4gJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0 IE1TJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5EaHJ1djxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RyZWJ1Y2hldCBNUyZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBQY2Ug W21haWx0bzpwY2UtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+T2xpdmll ciBEdWdlb248YnI+DQo8Yj5TZW50OjwvYj4gMjEgT2N0b2JlciAyMDE1IDE5OjQzPGJyPg0KPGI+ VG86PC9iPiBEaHJ1diBEaG9keTxicj4NCjxiPkNjOjwvYj4gcGNlQGlldGYub3JnPGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbUGNlXSBRdWVzdGlvbnMgYWJvdXQgUENFIFN0YXRlZnVsIFN5bmNo cm9uaXNhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1VidW50dSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+SGVsbG8gRGhydXYsPGJyPg0KPGJy Pg0KVGhhbmtzIHBvaW50aW5nIG1lIHRoaXMgc2VjdGlvbiwgYnV0IEkgcmVhZCB0aGUgZHJhZnQg YmVmb3JlIGFza2luZyBteSBxdWVzdGlvbnMuIEZvciBtZSwgaXQgaXMgbm90IGNvbXBsZXRlbHkg Y292ZXIgdGhpcyBpc3N1ZSwgYW5kIG15IGFuc3dlciBpcyBZZXMgYW5kIE5vLjxicj4NCjxicj4N ClllcywgYmVjYXVzZSB0aGUgbWVjaGFuaXNtIGFsbG93IHN1Y2ggcmUtc3luY2hyb25pemF0aW9u IHdpdGhvdXQgY2xvc2luZyB0aGUgUENFUCBzZXNzaW9uLCBidXQgYXQgdGhlIHByaWNlIG9mIGV4 Y2hhbmdpbmcgUENVcGQgLyBQQ1JwdCBtZXNzYWdlIHdoZW4gb25seSBvbmUgUENScHQgbWVzc2Fn ZSBpcyBzdWZmaWNpZW50LiBJdCBzb2x2ZXMgdGhlIHByb2JsZW0gb2Ygb3JwaGFuIExTUC4gSW4g dGhpcyBjYXNlLCBJIGFncmVlIHRoYXQgd2hlbiB0aGUNCiBQQ0UgYXNrcyB0byB1cGRhdGUgYW4g b3JwaGFuIExTUCBpdCBnZXRzIGFuIGVycm9yIChJIHN1cHBvc2UgYXMgaXQgaXMgbm90IHNwZWNp ZnkgaW4gdGhlIGRyYWZ0KS48YnI+DQo8YnI+DQpBbiBObywgYmVjYXVzZSBpdCBub3Qgc29sdmVz IGNvbXBsZXRlbHkgdGhlIGlzc3VlIGlmIHRoZSBQQ0UgaXMgbm90IGF3YXJlIG9mIGFuIExTUC4g VGhlIFBDRSBjb3VsZCBub3QgcmVxdWVzdCBhbiB1cGRhdGUgYWJvdXQgYW4gTFNQcyBpdCBpZ25v cmVzLg0KPGJyPg0KPGJyPg0KU28sIHRoZSBvbmx5IHdvcmtpbmcgc29sdXRpb24gZm9yIHRoZSBQ Q0UgaXMgdG8gYXNrIHJlZ3VsYXJseSBhbGwgUENDcyB0byBzZW5kIHRoZWlyIGNvbXBsZXRlIExT UCBEQiB0byBiZSBzdXJlIHRoYXQgaXQgaXMgYWx3YXlzIHN5bmNocm9uaXplZCwgYnV0IGl0IGlz IGEgdmVyeSBjb3N0bHkgbWVjaGFuaXNtLjxicj4NCjxicj4NCkluIGFkZGl0aW9uLCBJIGhhdmUg c29tZSBkb3VidCB0aGF0IHRoaXMgbWVjaGFuaXNtIHNjYWxlIHdlbGwuIEZvciBsYXJnZSBuZXR3 b3Jrcywgc2F5IG1vcmUgdGhlbiAxMDAwIFBFIHJvdXRlcnMsIHNvIG1vcmUgdGhhbiAxMDAwIFBD RVAgc2Vzc2lvbnMsIHdpdGggYSBmdWxsIG1lc2ggb2YgVEUgdHVubmVscyAoSSBrbm93IGl0IGlz IGFuIGV4dHJlbWUgY2FzZSkgdGhpcyBpbmNyZWFzZSBkcmFzdGljYWxseSB0aGUgZXhjaGFuZ2Ug YmV0d2VlbiB0aGUNCiBQQ0UgYW5kIFBDQ3MgYW5kIGFkZCBleHRyYSBDUFUgcHJvY2VzcyBmb3Ig dGhlIFBDRS4gVGhlIGxhdGVyIG11c3QgcGFyc2UgMSwwMDAsMDAwIHR1bm5lbHMgaW4gaXRzIExT UHMgREIgYW5kIGFzayBQQ0NzIHRvIHJlZnJlc2ggdGhlbS4gT3IsIGFza3MgYWxsIFBDQ3MgdG8g dXBkYXRlIGFsbCB0aGVpciB0dW5uZWxzLiBJbiB0aGUgZmlyc3QgY2FzZSB0aGUgUENFIHNwZW50 IGl0cyB0aW1lIHRvIHNlbmQgUENVcGQgbWVzc2FnZSB3YWl0aW5nIGZvcg0KIHRoZSBjb3JyZXNw b25kaW5nIFBDUnB0IGFuc3dlciBhbmQgaW4gdGhlIHNlY29uZCBjYXNlIGl0IHNwZW50IGl0cyB0 aW1lIHRvIHBhcnNlIDEwMDAgdHVubmVscyBlYWNoIHRpbWUgaXQgYXNrcyBhIFBDQyBmb3IgYSBm dWxsIHJlZnJlc2guPGJyPg0KPGJyPg0KRmxvb2QgcGVyaW9kaWNhbGx5IExpbmsgU3RhdGUgaW4g SUdQIHByb3RvY29sIGhhcyBwcm9vZiBmb3IgYSBsb25nIHRpbWUgdGhhdCBpdCBzY2FsZSB3ZWxs IGV2ZW4gaW4gdmVyeSBsYXJnZSBuZXR3b3JrLiBXaHkgbm90IHJlLXVzaW5nIGEgc2ltaWxhciBj b25jZXB0ID88YnI+DQo8YnI+DQpBbmQsIGxhc3QgYnV0IG5vdCBsZWFzdCwgd2hhdCdzIGhhcHBl biB3aXRoIExTUCB0dW5uZWxzIHRoYXQgYXJlIGNvbmZpZ3VyZWQgb24gcm91dGVyIHRoYXQgYXJl IG5vdCBQQ0VQIGVuYWJsZSA/IFRoZXJlIGFyZSBzaW1wbHkgaWdub3JlZCA/PGJyPg0KPGJyPg0K UmVnYXJkcyw8YnI+DQo8YnI+DQpPbGl2aWVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxlIDIxLzEwLzIwMTUgMTU6MDEsIERocnV2IERob2R5IGEg w6ljcml0Jm5ic3A7OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hl dCBNUyZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM0QzExMzAiPkhpIE9saXZp ZXIsJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM0QzExMzAiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojNEMxMTMwIj5XYW50ZWQgdG8gYnJpbmcgJnF1b3Q7UENFIHRyaWdn ZXJlZCByZS1zeW5jcm9uaXphdGlvbiZxdW90OyBbPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtcGNlLXN0YXRlZnVsLXN5bmMtb3B0aW1pemF0aW9ucy0wMyNz ZWN0aW9uLTYiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXBjZS1zdGF0 ZWZ1bC1zeW5jLW9wdGltaXphdGlvbnMtMDMjc2VjdGlvbi02PC9hPl0NCiB0byB5b3VyIG5vdGlj ZS4gVGhpcyBjYW4gYmUgdXNlZCBieSBhIFBDRSB0byBwZXJpb2RpY2FsbHkgcmUtc3luY2hyb25p emUgdGhlIGRhdGFiYXNlIHdpdGhvdXQgYnJpbmdpbmcgZG93biB0aGUgUENFUCBzZXNzaW9uLiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNEMxMTMwIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzRDMTEzMCI+V2lsbCB0aGlzIG5vdCBjb3ZlciB0aGUgaXNzdWUgeW91IGhh dmUgaW4gbWluZD8mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVj aGV0IE1TJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzRDMTEzMCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM0QzExMzAiPlJlZ2FyZHMsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiM0QzExMzAiPkRocnV2PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1RyZWJ1Y2hldCBNUyZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM0QzExMzAi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gV2VkLCBPY3QgMjEsIDIwMTUgYXQgMzoyOSBQTSwgT2xpdmllciBEdWdl b24gJmx0OzxhIGhyZWY9Im1haWx0bzpvbGl2aWVyLmR1Z2VvbkBvcmFuZ2UuY29tIiB0YXJnZXQ9 Il9ibGFuayI+b2xpdmllci5kdWdlb25Ab3JhbmdlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGVhciBhdXRob3JzIG9mIGRyYWZ0LWlldGYt cGNlLXN0YXRlZnVsIGFuZCBkcmFmdC1pZXRmLXBjZS1zdGF0ZWZ1bC1zeW5jLW9wdGltaXphdGlv bnMsPGJyPg0KPGJyPg0KSSBrbm93IHRoYXQgd2UgYXJlIGluIHRoZSBsYXN0IG1pbGVzIGJlZm9y ZSBwdWJsaXNoIFBDRSBTdGF0ZWZ1bCBkcmFmdCBjb2xsZWN0aW9uIGFzIFJGQ3MsIGJ1dCByZWdh cmRpbmcgdGhlIGNoYWlycycgcmV2aWV3LCBJIGhhdmUgYSBnbG9iYWwgaW50ZXJyb2dhdGlvbiBh Ym91dCBzeW5jaHJvbmlzYXRpb24uIEV2ZW4gSS1EcyB0cnkgdG8gYXZvaWQgaXQsIEknbSBhZnJh aWQgdGhhdCB0aGVyZSB3aWxsIGRpZmZlcmVudCBjYXNlcyB3aGVyZSBkZS1zeW5jaHJvbmlzYXRp b24NCiBpcyBub3QgYXZvaWRlZCBiZXR3ZWVuIFBDQ3MgYW5kIFBDRXMuIEluIHBhcnRpY3VsYXIs IGluIGNhc2Ugb2YgcHJvYmxlbSwgbm90IGEgcmVhbCBmYWlsdXJlLCBtb3JlIGEgYnVnLCBtZW1v cnkgc2F0dXJhdGlvbiBvciB3aGF0ZXZlciBtYWwtZnVuY3Rpb24gY291bGQgb2NjdXIgb24gdGhl IFBDRSBvciBQQ0Mgc2lkZSwgYSBQQ0UgY291bGQgbWlzcyBhIFBDUnB0IG1lc3NhZ2UgZnJvbSBh IFBDQyBvciByZXNwZWN0aXZlbHkgYSBQQ0MgY291bGQNCiBtaXNzIHRvIHNlbmQgYSBQQ1JwdCBt ZXNzYWdlIHRvIGEgUENFLiBJJ20gYWxzbyBhZnJhaWQsIGFmdGVyIGEgbG9uZyBsaXZlIHBlcmlv ZCAoc2F5LCBzZXZlcmFsIHdlZWtzIG9yIG1vbnRocykgdGhhdCBzb21lIG9ycGhhbiBMU1BzIGFw cGVhciBpbiB0aGUgUENFIExTUHMgZGF0YWJhc2Ugd2l0aG91dCB0aGUgcG9zc2liaWxpdHkgdG8g ZGV0ZWN0IHRoZW0gYW5kIHJlbW92ZSB0aGVtLjxicj4NCjxicj4NClRvIGdvIGJhY2sgaW4gYSBm dWxsIHN5bmMgc3RhdGUsIGl0IGlzIHRoZW4gbmVjZXNzYXJ5IHRvIHJlc3RhcnQgcHJvcGVybHkg dGhlIFBDRVAgc2Vzc2lvbiwgaS5lLiBmb3JjZSBhIHJlLXN5bmNocm9uaXNhdGlvbi4gQnV0LCB0 byBkbyB0aGF0LCB5b3UgbmVlZCB0byBkaXNjb3ZlciB0aGUgcHJvYmxlbS4gVGhhdCdzIGFub3Ro ZXIgdG9waWMuPGJyPg0KPGJyPg0KU28sIG15IHF1ZXN0aW9uIGlzIHdoeSBkbyB5b3Ugbm90IGhh dmUgdXNlIGEgc2ltaWxhciBtZWNoYW5pc20gdG8gcm91dGluZyBwcm90b2NvbCwgaS5lLiBPU1BG LCBJUy1JUyBvciBCR1AsIHRvIHBlcmlvZGljYWxseSBzZW5kIExTUHMgc3RhdGUgZnJvbSB0aGUg UENDIHRvIHRoZSBQQ0UuIFVzaW5nIGFuICdvdXQgb2YgZGF0ZScgaW5kaWNhdGlvbiB3aWxsIGFs bG93IHRoZSBQQ0UgdG8gcmVtb3ZlIGluIGl0cyBMU1AtREIgJ291dCBvZiBkYXRlJw0KIExTUHMg bGlrZSBPU1BGIGRvIHdoZW4gaXQgZmx1c2hlcyBhbiBMU0Egd2l0aCBhZ2VpbmcgZXF1YWwgdG8g MzYwMCBpbiBpdHMgVEVELjxicj4NCjxicj4NCldoYXQgaXQgaXMgc3VmZmljaWVudCBpcyB0byBh ZGQgYSBuZXcgc3RhdGVtZW50IGluIGRyYWZ0LWlldGYtcGNlLXN0YXRlZnVsIChlLmcuLCBpbiBz ZWN0aW9uIDkuMS4mbmJzcDsgQ29udHJvbCBGdW5jdGlvbiBhbmQgUG9saWN5KSB0ZWxsaW5nIHRo YXQ6PGJyPg0KJm5ic3A7LSB0aGUgUENDIE1VU1Qgc2VuZCBQQ1JwdCBtZXNzYWdlIG9uIGEgcmVn dWxhciBiYXNpcywgYmVmb3JlIE1BWF9BR0UgZXhwaXJlLjxicj4NCiZuYnNwOy0gdGhlIFBDRSBN VVNUIGlnbm9yZSBMU1BzIHRoYXQgYXJlIG5vdCByZWZyZXNoIHNpbmNlIGEgcGVyaW9kIG9mIHRp bWUgZ3JlYXRlciB0aGFuIE1BWF9BR0UuPGJyPg0KPGJyPg0KVGhlbiwgdHdvIGNhc2VzIGFyZSBw b3NzaWJsZTo8YnI+DQombmJzcDthKSBNQVhfQUdFIGlzIGZpeGVkIGluIHRoZSBSRkMgZS5nLiB0 byAzNjAwIHNlY29uZHMgbGlrZSBpbiBPU1BGIChzZWVtcyByZWFzb25hYmxlKTxicj4NCiZuYnNw O2IpIE5lZ290aWF0ZS9leGNoYW5nZSBkdXJpbmcgUENFUCBzZXNzaW9uIGVzdGFibGlzaG1lbnQg b3Igd2hlbiBQQ1JwdCBtZXNzYWdlIGlzIHNlbnQ8YnI+DQo8YnI+DQpJZiBvcHRpb24gKGEpIGlz IHF1aWV0IHNpbXBsZSBidXQgbm90IGZsZXhpYmxlLCBpdCBoYXMgdGhlIGdyZWF0IGFkdmFudGFn ZSB0byBub3QgaW50cm9kdWNlIG5ldyBQQ0VQIE9iamVjdCB3aGlsZSBvcHRpb24gKGIpIG5lZWQg bmV3IFBDRVAgT2JqZWN0IGRlZmluaXRpb24sIGJ1dCBwcm92aWRlIGEgZ3JlYXRlciBmbGV4aWJp bGl0eS48YnI+DQo8YnI+DQpJZiB3ZSBhZ3JlZSBvbiB0aGUgc3RhdGVtZW50IGFib3ZlLCZuYnNw OyBJIHRoaW5rIHRoYXQgb3B0aW9uIChhKSBpcyBzdWZmaWNpZW50IGFuZCBqdXN0IG5lZWQgYWRk aXRpb25hbCB0ZXh0IGluIGN1cnJlbnQgZHJhZnQgd2hpbGUgaWYgd2Ugd2FudCB0byBzdXBwb3J0 IG9wdGlvbiAoYiksIEkgY291bGQgd29yayBvbiBhIG5ldyBkcmFmdC48YnI+DQo8YnI+DQpSZWdh cmRzLDxicj4NCjxicj4NCk9saXZpZXI8YnI+DQotLSA8YnI+DQpsb2dvIE9yYW5nZSAmbHQ7PGEg aHJlZj0iaHR0cDovL3d3dy5vcmFuZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5v cmFuZ2UuY29tPC9hPiZndDs8YnI+DQo8YnI+DQpPbGl2aWVyIER1Z2Vvbjxicj4NCk9yYW5nZSBF eHBlcnQsIEZ1dHVyZSBOZXR3b3Jrczxicj4NCk9wZW4gU291cmNlIFJlZmVyZW50PGJyPg0KT3Jh bmdlL0lNVC9PTE4vV1RDL0lFRS9PUEVOPGJyPg0KPGJyPg0KZml4ZSA6ICYjNDM7MzMgMiA5NiAw NSAyOCA4MDxicj4NCm1vYmlsZSA6ICYjNDM7MzMgNiA4MiA5MCAzNyA4NTxicj4NCjxhIGhyZWY9 Im1haWx0bzpvbGl2aWVyLmR1Z2VvbkBvcmFuZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+b2xpdmll ci5kdWdlb25Ab3JhbmdlLmNvbTwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86b2xpdmll ci5kdWdlb25Ab3JhbmdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm9saXZpZXIuZHVnZW9uQG9yYW5n ZS5jb208L2E+Jmd0Ozxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KUGNlIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0 bzpQY2VAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5QY2VAaWV0Zi5vcmc8L2E+PGJyPg0KPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wY2UiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BjZTwvYT48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_23CE718903A838468A8B325B80962F9B8C429626BLREML509MBXchi_-- From nobody Thu Oct 22 00:34:34 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3BE1A9233; Thu, 22 Oct 2015 00:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.76 X-Spam-Level: X-Spam-Status: No, score=-1.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, 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 NJ8vMwiP_FAT; Thu, 22 Oct 2015 00:34:24 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E5791A90DA; Thu, 22 Oct 2015 00:34:22 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CCW48450; Thu, 22 Oct 2015 07:34:20 +0000 (GMT) Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 22 Oct 2015 08:34:18 +0100 Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.78]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0235.001; Thu, 22 Oct 2015 15:34:11 +0800 From: "Zhangxian (Xian)" To: Jonathan Hardwick , "draft-ietf-pce-stateful-sync-optimizations@ietf.org" Thread-Topic: Shepherd's review of draft-ietf-pce-stateful-sync-optimizations-03 Thread-Index: AdEIKFCM/MXbJYqfQi2B63ASoTqDyAEPmKVA Date: Thu, 22 Oct 2015 07:34:10 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.104.209] Content-Type: multipart/alternative; boundary="_000_C636AF2FA540124E9B9ACB5A6BECCE6B54AD0ED0SZXEMA512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "pce@ietf.org" Subject: Re: [Pce] Shepherd's review of draft-ietf-pce-stateful-sync-optimizations-03 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 07:34:32 -0000 --_000_C636AF2FA540124E9B9ACB5A6BECCE6B54AD0ED0SZXEMA512MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIEpvbiwNCg0KVGhhbmsgeW91IGZvciB0aGUgZGV0YWlsZWQgcmV2aWV3LiBQbGVhc2Ugc2Vl IG15IHJlcGx5IGlubGluZToNCg0KSSB3aWxsIHVwZGF0ZS91cGxvYWQgdGhlIGRyYWZ0IG9uY2Ug d2UgcmVhY2ggYWdyZWVtZW50IG9uIGFsbCBwb2ludHMsIHJpZ2h0IGFmdGVyIHRoZSB1cGxvYWQg cmUtb3BlbmluZy4NCg0KUmVnYXJkcywNClhpYW4NCg0KRnJvbTogSm9uYXRoYW4gSGFyZHdpY2sg W21haWx0bzpKb25hdGhhbi5IYXJkd2lja0BtZXRhc3dpdGNoLmNvbV0NClNlbnQ6IDIwMTXE6jEw 1MIxOcjVIDE4OjE4DQpUbzogZHJhZnQtaWV0Zi1wY2Utc3RhdGVmdWwtc3luYy1vcHRpbWl6YXRp b25zQGlldGYub3JnDQpDYzogcGNlQGlldGYub3JnDQpTdWJqZWN0OiBTaGVwaGVyZCdzIHJldmll dyBvZiBkcmFmdC1pZXRmLXBjZS1zdGF0ZWZ1bC1zeW5jLW9wdGltaXphdGlvbnMtMDMNCg0KSGkg dGhlcmUNCg0KSSBoYXZlIHBlcmZvcm1lZCBhIFdHIFNoZXBoZXJkIHJldmlldyBvZiB0aGlzIGRy YWZ0LiAgR2VuZXJhbGx5IEkgZm91bmQgaXQgYSB3ZWxsLXdyaXR0ZW4gZHJhZnQgd2l0aCBubyBt YWpvciBpc3N1ZXMuICBUaGVyZSBhcmUgYSBmZXcgbWlub3IgaXNzdWVzIHRoYXQgSSB0aGluayBz aG91bGQgYmUgcmVzb2x2ZWQuDQoNCkkgaGF2ZSBkaXZpZGVkIG15IGNvbW1lbnRzIGludG8gdGhy ZWUgZ3JvdXBzOg0KDQoqICAgICAgICAgdGVjaG5pY2FsIKhDIGNvbW1lbnRzIHRoYXQgYWZmZWN0 IHRoZSBtZWFuaW5nIG9mIHRoZSBkb2N1bWVudA0KDQoqICAgICAgICAgZWRpdG9yaWFsIKhDIGNv bW1lbnRzIHRoYXQgZG8gbm90IGFmZmVjdCB0aGUgbWVhbmluZyBidXQgSSB0aGluayB3b3VsZCBz aWduaWZpY2FudGx5IGltcHJvdmUgdGhlIGNsYXJpdHkNCg0KKiAgICAgICAgIG5pdHMgqEMgZWRp dG9yaWFsIGNvbW1lbnRzIHRoYXQgYXJlIG1pbm9yIGFuZCBvYnZpb3VzLg0KDQpJIHdvdWxkIGxp a2UgdG8gaGF2ZSBhdCBsZWFzdCB0aGUgdGVjaG5pY2FsIGNvbW1lbnRzIHJlc29sdmVkIGJlZm9y ZSBmb3J3YXJkaW5nIHRoZSBkb2N1bWVudCB0byB0aGUgSUVTRy4gIFBsZWFzZSBjb3VsZCB0aGUg YXV0aG9ycyByZXZpZXcgbXkgY29tbWVudHMgYW5kIHJlcGx5IGVpdGhlciBieSBlbWFpbCBvciBi eSBzdWJtaXR0aW5nIGEgbmV3IGRyYWZ0IHZlcnNpb24/DQoNCkJlc3QgcmVnYXJkcw0KSm9uDQoN Cg0KVGVjaG5pY2FsDQoNCnMzLjIgcGFyYSA2LiAgobBJZiB0aGUgUENDIGF0dGVtcHRzIHRvIHNr aXAgc3RhdGUgc3luY2hyb25pemF0aW9uIChpLmUuLCB0aGUgU1lOQyBGbGFnID0gMCBvbiB0aGUg Zmlyc3QgTFNQIFN0YXRlIFJlcG9ydCBmcm9tIHRoZSBQQ0MgYXMgcGVyIFtJLUQuaWV0Zi1wY2Ut c3RhdGVmdWwtcGNlXSksobENCg0KV2hhdCBpZiB0aGUgUENDIGlzIHN5bmNocm9uaXppbmcgYW4g ZW1wdHkgTFNQREI/ICBUaGVuIHRoZSBmaXJzdCBtZXNzYWdlIGl0IHNlbmRzIGlzIExTUCBTdGF0 ZSBSZXBvcnQgd2l0aCBTWU5DPTAgYW5kIFBMU1AtSUQ9MC4gIFRoaXMgaXMgbGVnaXRpbWF0ZSBh bmQgeWV0IHRoZSB0ZXh0IHNheXMgdG8gdHJlYXQgaXQgYXMgYW4gZXJyb3IuICBJIHRoaW5rIHRo aXMgcGFyYWdyYXBoIHNob3VsZCBzdGlwdWxhdGUgdGhhdCB0aGUgZXJyb3IgY29uZGl0aW9uIGlz IG1ldCBvbmx5IGlmIFNZTkM9MCBhbmQgUExTUC1JRCBpcyBub3QgMC4NCg0KW1hpYW5dOiBBZ3Jl ZWQuIFdpbGwgdXBkYXRlIGFzOg0KobBJZiB0aGUgUENDIGF0dGVtcHRzIHRvIHNraXAgc3RhdGUg c3luY2hyb25pemF0aW9uLCBieSBzZXR0aW5nIHRoZSBTWU5DIGZsYWcgdG8gMCBhbmQgUExTUC1J RCBzZXQgdG8gbm9uLXplcm8sIGFzIHBlciBbSS1ELmlldGYtcGNlLXN0YXRlZnVsLXBjZV0sobEN Cg0KLS0NCg0KczQuMjogUGxlYXNlIHJld3JpdGUgdGhlIGZvbGxvd2luZyB0ZXh0IHVzaW5nIFJG QyAyMTE5IGtleXdvcmRzLg0KDQogICBJZiBhIFBDQyBoYXMgdG8gZm9yY2UgZnVsbCBMU1AgREIN CiAgIHN5bmNocm9uaXphdGlvbiBkdWUgdG8gcmVhc29ucyBpbmNsdWRpbmcgYnV0IG5vdCBsaW1p dGVkOiAoMSkgbG9jYWwNCiAgIHBvbGljeSBjb25maWd1cmVkIGF0IHRoZSBQQ0M7ICgyKSBubyBz dWZmaWNpZW50IExTUCBzdGF0ZSBjYWNoZXMgZm9yDQogICBpbmNyZW1lbnRhbCB1cGRhdGUsIHRo ZSBQQ0MgY2FuIHNldCB0aGUgRCBmbGFnIHRvIDAuICBOb3RlIGEgUENDIG1heQ0KICAgaGF2ZSB0 byBicmluZyBkb3duIHRoZSBjdXJyZW50IHNlc3Npb24gYW5kIGZvcmNlIGEgZnVsbCBMU1AtREIN CiAgIHN5bmNocm9uaXphdGlvbiB3aXRoIEQgZmxhZyBzZXQgdG8gMCBpbiB0aGUgc3Vic2VxdWVu dCBvcGVuIG1lc3NhZ2UuDQoNCkkgd291bGQgc2ltcGx5IHNheSChsFRoZSBQQ0MgTUFZIGZvcmNl IGEgZnVsbCBMU1AgREIgc3luY2hyb25pemF0aW9uIGJ5IHNldHRpbmcgdGhlIEQgZmxhZyB0byB6 ZXJvIGluIHRoZSBvcGVuIG1lc3NhZ2UuobEgIEFuZCB0aGVuIGxhdGVyLCB3aGVuIHlvdSBzYXkg dGhpczoNCg0KDQogICBJZiBhIFBDQyBmaW5kcyBvdXQgaXQgZG9lcyBub3QgaGF2ZSBzdWZmaWNp ZW50IGluZm9ybWF0aW9uIHRvDQoNCiAgIGNvbXBsZXRlIGluY3JlbWVudGFsIHN5bmNocm9uaXNh dGlvbiBhZnRlciBhZHZlcnRpc2luZyBpbmNyZW1lbnRhbA0KDQogICBMU1Agc3RhdGUgc3luY2hy b25pemF0aW9uIGNhcGFiaWxpdHksIGl0IE1VU1Qgc2VuZCBhIFBDRXJyIHdpdGgNCg0KICAgRXJy b3ItVHlwZSAyMCBhbmQgRXJyb3ItVmFsdWUgNSAnQSBQQ0MgaW5kaWNhdGVzIHRvIGEgUENFIHRo YXQgaXQgY2FuDQoNCiAgIG5vdCBjb21wbGV0ZSB0aGUgc3RhdGUgc3luY2hyb25pemF0aW9uJyAo ZGVmaW5lZCBpbg0KDQogICBbSS1ELmlldGYtcGNlLXN0YXRlZnVsLXBjZV0pIGFuZCB0ZXJtaW5h dGUgdGhlIHNlc3Npb24uDQoNCmFkZCBhIHNlbnRlbmNlOiChsFRoZSBQQ0MgU0hPVUxEIHJlLWVz dGFibGlzaCB0aGUgc2Vzc2lvbiB3aXRoIHRoZSBEIGJpdCBzZXQgdG8gemVybyBpbiB0aGUgb3Bl biBtZXNzYWdlLqGxDQpbWGlhbl06IHBvaW50IHRha2VuLCB3aXRoIHMvb3Blbi9PUEVOIHR3aWNl Lg0KDQotLQ0KDQpzNC4yIKGwU28gYSBQQ0MgbmVlZHMgdG8gcmVtZW1iZXIgdGhlIExTUCBzdGF0 ZSBjaGFuZ2VzIHRoYXQgaGFwcGVuZWQgd2hlbiBhbiBleGlzdGluZyBQQ0VQIHNlc3Npb24gdG8g YSBzdGF0ZWZ1bCBQQ0UgZ29lcyBkb3duIGluIHRoZSBob3BlIG9mIGRvaW5nIGluY3JlbWVudGFs IHN5bmNocm9uaXNhdGlvbiB3aGVuIHRoZSBzZXNzaW9uIGlzIHJlLWVzdGFibGlzaGVkLqGxDQoN CkV2ZW4gdGhpcyBtaWdodCBub3QgYmUgc3VmZmljaWVudCBhcyB0aGUgUENDIGhhcyBubyBpZGVh IGhvdyBtYW55IG1lc3NhZ2VzIHRoZSBQQ0UgbWFuYWdlZCB0byBwcm9jZXNzIGJlZm9yZSB0aGUg c2Vzc2lvbiBnb2VzIGRvd24uICBJIHRoaW5rIGl0IHdvdWxkIGJlIG1vcmUgY29ycmVjdCB0byBz YXkgobBBIFBDQyBuZWVkcyB0byByZW1lbWJlciBhdCBsZWFzdCB0aGUgTFNQIHN0YXRlIGNoYW5n ZXMgdGhhdCBoYXBwZW5lZCBhZnRlciBhbiBleGlzdGluZyBQQ0VQIHNlc3Npb24gdG8gYSBzdGF0 ZWZ1bCBQQ0UgZ29lcyBkb3duIHRvIGhhdmUgYW55IGNoYW5jZSBvZiBkb2luZyBpbmNyZW1lbnRh bCBzeW5jaHJvbmlzYXRpb24gd2hlbiB0aGUgc2Vzc2lvbiBpcyByZS1lc3RhYmxpc2hlZC6hsQ0K DQpbWGlhbl06IHBvaW50IHRha2VuLCB3aXRoIHMvdG8vd2l0aC4NCg0KLS0NCg0KczUuMiBUd28g Y29uY2VybnMgYWJvdXQgdGhlIGZvbGxvd2luZyB0ZXh0Og0KDQoNCiAgIEEgc3RhdGVmdWwgUENF IE1BWSBjaG9vc2UgdG8gY29udHJvbCB0aGUgTFNQLURCIHN5bmNocm9uaXphdGlvbg0KDQogICBw cm9jZXNzLiAgVG8gYWxsb3cgUENFIHRvIGRvIHNvLCBQQ0VQIHNwZWFrZXJzIE1VU1Qgc2V0IFQg Yml0IHRvIDEgdG8NCg0KICAgaW5kaWNhdGUgdGhpcyAoYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24g NykuDQoNCldoeSBhcmUgeW91IGRpc2N1c3NpbmcgdGhlIFQgYml0IGhlcmU/ICBJIHRob3VnaHQg dGhhdCB0aGUgYmVoYXZpb3VycyBjb250cm9sbGVkIGJ5IHRoZSBGIGJpdCBhbmQgdGhlIFQgYml0 IHdlcmUgbG9naWNhbGx5IGluZGVwZW5kZW50IChhbHRob3VnaCBzaW1pbGFyKS4gIEFyZSB5b3Ug c2F5aW5nIHRoYXQgdGhlIFBDRSBtdXN0IHNldCB0aGUgRiBiaXQgYW5kIHRoZSBQQ0Mgc2V0IHRo ZSBUIGJpdCBmb3IgdGhlIHByb2NlZHVyZXMgaW4gc2VjdGlvbiA1IHRvIHdvcms/ICBZb3UgaGF2 ZSB3cml0dGVuIGEgbG90IG9mIHRoZSB0ZXh0IGluIHRoZSBwYXNzaXZlIHZvaWNlLCB3aGljaCBt YWtlcyBpdCB1bmNsZWFyIHdobyBpcyBzdXBwb3NlZCB0byBzZXQgd2hpY2ggYml0IChzZWUgZWRp dG9yaWFsIGNvbW1lbnRzIGJlbG93IGZvciBtb3JlIHNwZWNpZmljIHBvaW50ZXJzLikgIEFsc28s IEkgdGhpbmsgeW91ciBjcm9zcy1yZWZlcmVuY2Ugc2hvdWxkIGJlIHRvIHNlY3Rpb24gNiwgbm90 IDcuDQoNCltYaWFuXTogVGhpcyB0ZXh0IGlzIHdyb25nIGFuZCBpdCBzaG91bGQgcmVmZXIgdG8g dGhlIEYgYml0LiBJbiB2ZXJzaW9uIDAxLCB3ZSB1c2VkIHRoZSBzYW1lIGJpdCAoRikgZm9yIGJv dGggZnVuY3Rpb25zIChTZWN0aW9uIDUgYW5kIDYpLCBidXQgbGF0dGVyIHdlIGRlY2lkZWQgdG8g c2VwYXJhdGUgdGhlbS4gSG93IGFib3V0IHVwZGF0ZSBpdCBhcyBiZWxvdz8NCqGwSW4gb3JkZXIg dG8gYWxsb3cgYSBzdGF0ZWZ1bCBQQ0UgdG8gY29udHJvbCB0aGUgTFNQLURCIHN5bmNocm9uaXph dGlvbiBhZnRlciBlc3RhYmxpc2hpbmcgYSBQQ0VQIHNlc3Npb24sIGJvdGggUENFUCBzcGVha2Vy cyBNVVNUIHNldCBGIGJpdCB0byAxIGluIHRoZSBPUEVOIG1lc3NhZ2UuobENCg0KDQotLQ0KDQpz OC4yIFBsZWFzZSByZXdyaXRlIHRoaXMgYXMgYSByZXF1ZXN0IHRvIElBTkEgdG8gbWFrZSBhbiBh bGxvY2F0aW9uIGZyb20gYSBzcGVjaWZpYyByZWdpc3RyeSAoeW91ciB0ZXh0IGluIDguMSBpcyBh IGdvb2QgZXhhbXBsZSB0byBjb3B5LikNCnM4LjMgZGl0dG8uDQpbWGlhbl06IFN1cmUsIHdpbGwg ZG8uDQoNCk9uZSBpc3N1ZSB0aG91Z2g6IFRoZSBTVEFURUZVTC1QQ0UtQ0FQQUJJTElUWSBUTFYg aXMgZGVmaW5lZCBpbiBkcmFmdC1pZXRmLXBjZS1zdGF0ZWZ1bC1wY2UtMTIsIHRodXMgbm8gcmVn aXN0cnkgeWV0IGJ1dCBiZWluZyByZXF1ZXN0ZWQgdGhlcmUuIEFtIEkgb2sgdG8gd3JpdGUgdGhl IGZvbGxvd2luZyB0ZXh0IHRvIHByb3ZpZGUgYSBsaW5rYWdlPw0KDQqhsFRoZSBTVEFURUZVTC1Q Q0UtQ0FQQUJJTElUWSBUTFYgaXMgZGVmaW5lZCBpbiBbZHJhZnQtaWV0Zi1wY2Utc3RhdGVmdWwt cGNlLTEyXSBhbmQgYSByZWdpc3RyeSBpcyByZXF1ZXN0ZWQgdG8gYmUgY3JlYXRlZCB0byBtYW5h Z2UgdGhlIGZsYWdzIGluIHRoZSBUTFYuICBJQU5BIGlzIHJlcXVlc3RlZCB0byBtYWtlIHRoZSBm b2xsb3dpbmcgYWxsb2NhdGlvbiBpbiB0aGUgYWZvcmVtZW50aW9uZWQgcmVnaXN0cnkuDQqhrQ0K obENCg0KLS0NCg0KczkuMiBUaGUgbWFuYWdlYWJpbGl0eSBzZWN0aW9uIG91Z2h0IHRvIGRlc2Ny aWJlIHJlcXVpcmVtZW50cyBvbiBpbXBsZW1lbnRhdGlvbnMsIG5vdCByZXF1aXJlbWVudHMgb24g dGhlIFBDRSB3b3JraW5nIGdyb3VwLiAgSSB0aGluayB5b3VyIHRleHQgb3VnaHQgdG8gcmVhZCCh sEFuIGltcGxlbWVudGF0aW9uIFNIT1VMRCBhbGxvdyB0aGUgb3BlcmF0b3IgdG8gdmlldyB0aGUg c3RhdGVmdWwgY2FwYWJpbGl0aWVzIGFkdmVydGlzZWQgYnkgZWFjaCBwZWVyLCBhbmQgdGhlIGN1 cnJlbnQgc3luY2hyb25pemF0aW9uIHN0YXR1cyB3aXRoIGVhY2ggcGVlci6hsSAgKE5vdGUgdGhh dCBJIGFtIG5vdCBkaXNhZ3JlZWluZyB3aXRoIHRoZSBpZGVhIG9mIGV4dGVuZGluZyB0aGUgUENF UCBNSUIuKQ0KW1hpYW5dOiBPay4gRXhwYW5kIHRoZSBJbmZvcm1hdGlvbiBhbmQgRGF0YSBNb2Rl bHMgd2l0aCB0aGUgc2VudGVuY2UgcHJvdmlkZWQgdG8gbWFrZSBpdCBtb3JlIGdlbmVyYWwuDQoN CkVkaXRvcmlhbA0KDQpzMy4yIHBhcmEgMTA6IKGwSWYgc3RhdGUgc3luY2hyb25pemF0aW9uIGF2 b2lkYW5jZSBpcyBlbmFibGVkoa2hsSAgVGhpcyB3b3VsZCBwZXJoYXBzIGZpdCBiZXR0ZXIgYWxv bmdzaWRlIHBhcmEgMiwgd2hpY2ggZGlzY3Vzc2VzIHRoZSBvdGhlciBsZWdpdGltYXRlIHJlYXNv bnMgdG8gaW5jcmVtZW50IHRoZSBEQi1WRVJTSU9OLg0KW1hpYW5dOiBwb2ludCB0YWtlbi4NCg0K czQuMSBmaW5hbCBwYXJhIGZlZWxzIHN1cGVyZmx1b3VzIKhDIHN1Z2dlc3QgZGVsZXRpbmcuDQpb WGlhbl06IG9rLg0KczUuMSBJIGxpa2UgdGhlIGV4cGxhbmF0aW9uIG9mIHdoeSBQQ0M6UENFIGJh bmR3aWR0aCBtaWdodCBiZSBsaW1pdGVkIGFuZCBJIHN1Z2dlc3QgbW92aW5nIHRoaXMgZXhwbGFu YXRpb24gZm9yd2FyZHMgdG8gczQuMSAoczQuMSB0cmllcyB0byBleHBsYWluIHRoZSBzYW1lIHRo aW5nIGJ1dCBpcyBub3QgYXMgZWxlZ2FudC4pLg0KW1hpYW5dOiBTZWN0aW9uIDQgYW5kIDUgdXNl ZCB0byBvbmUuIFNvIHdoZW4gc3BsaXR0aW5nLCB3ZSBhbHNvIHB1dCBlbXBoYXNpcyBvbiBkaWZm ZXJlbnQgYXNwZWN0cy4gU2VjdGlvbiA0IGZvY3VzZXMgb24gdGhlIG5lZWQgb2YgZGVsdGEgc3lu Yy4gZHJpdmVuIGJ5IHNtYWxsIGNoYW5nZXMgb2YgTFNQLURCLiBUaGlzIHByb2JhYmx5IGhhcyB3 aWRlciB1dGlsaXR5LiBTZWN0aW9uIDUgZm9jdXNlcyBvbiB0aGUgY29uc3RyYWludHMgYSBwYXJ0 aWN1bGFyIG5ldHdvcmsgbWF5IGhhdmUgKG9wdGljYWwgYXMgdGhlIG1haW4gdXNlIGNhc2UpIHNv IGFzIHRvIGFsbG93IGZvciBQQ0UgY29udHJvbCBvZiBpbml0aWFsIHN5bmMuICBPZiBjb3Vyc2Us IGltcGxlbWVudGF0aW9ucyBvbiBib3RoIGhlbHAgYmV0dGVyIGFkZHJlc3MgdGhlIG9wdGljYWwg bmV0d29yayBDQyBjb25zdHJhaW50cy4gU28gSSBkbyBub3QgcmVhbGx5IHdhbnQgdG8gbW92ZSB0 aGUgd2hvbGUgc2VudGVuY2UgdXAsIGJ1dCB0byBhZGRyZXNzIHlvdXIgY29tbWVudCwgSSBzdWdn ZXN0IHRvIGFkZCBzb21ldGhpbmcgbGlrZSAoZS5nLiwgaW4tYmFuZCBjb250cm9sIGNoYW5uZWwg Zm9yIG9wdGljYWwgdHJhbnNwb3J0IG5ldHdvcmtzKSBpbiBTZWN0aW9uIDQuDQoNCnM1LjIgobBT dXBwb3J0IG9mIFBDRS10cmlnZ2VyZWQgc3RhdGUgc3luY2hyb25pemF0aW9uIGlzIGFkdmVydGlz ZWShsSCoQyBpcyBhZHZlcnRpc2VkIGJ5IHdob20/ICBBbHNvLCBJIHRoaW5rIHlvdSBtZWFuIKGw aW5pdGlhbCBzdGF0ZSBzeW5jaHJvbml6YXRpb24uobEgIFBsZWFzZSByZXdyaXRlIGluIHRoZSBh Y3RpdmUgdm9pY2UgKGZvciBleGFtcGxlLCChsEJvdGggUENFUCBzcGVha2VycyBhZHZlcnRpc2Ug dGhlaXIgc3VwcG9ydCBvZiBQQ0UtdHJpZ2dlcmVkIGluaXRpYWwgc3RhdGUgc3luY2hyb25pemF0 aW9uIGR1cmluZyBzZXNzaW9uIHN0YXJ0dXAgYnmhraGxKSAgRGl0dG8gobBJZiB0aGUgVFJJR0dF UkVELUlOSVRJQUwtU1lOQyBjYXBhYmlsaXR5IGlzIG5vdCBhZHZlcnRpc2VkobEgLT4gobBJZiB0 aGUgUENFIGhhcyBub3QgYWR2ZXJ0aXNlZCB0aGUgVFJJR0dFUkVELUlOSVRJQUwtU1lOQyBjYXBh YmlsaXR5obENCnM2LjIgobBTdXBwb3J0IG9mIFBDRS10cmlnZ2VyZWQgc3RhdGUgc3luY2hyb25p emF0aW9uIGlzIGFkdmVydGlzZWShsSCoQyBwbGVhc2UgdXNlIGFjdGl2ZSB2b2ljZS4NCg0KW1hp YW5dOiBQb2ludCB0YWtlbjsgd2lsbCBiZSBtb3JlIGV4cGxpY2l0IGluIHRoZSBuZXh0IHVwZGF0 ZS4NCg0KTml0cw0KDQpzMy4yIHBhcmEgNDogobB0aGUgUENFIFNIT1VMRCBpZ25vcmUgaXQgd2Vy ZSB0byByZWNlaXZlIG9uZaGxIKhDIEkgdGhpbmsgeW91IG1lYW4gobB0aGUgUENFIFNIT1VMRCBp Z25vcmUgaXQgd2VyZSBpdCB0byByZWNlaXZlIG9uZaGxDQoNCltYaWFuXTogYWNjZXB0ZWQuDQoN Cg== --_000_C636AF2FA540124E9B9ACB5A6BECCE6B54AD0ED0SZXEMA512MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, Jon,

 

Thank you for the detailed review. Plea= se see my reply inline:

 

I will update/upload the draft once we reach agreement on all points, right after the upload re-opening.<= /p>

 

Regards,
Xian

 

From: Jonathan Hardwick [mailto:Jonathan.Hardwick@metaswitc= h.com]
Sent: 2015=C4=EA10=D4=C219=C8=D5 18:18
To: draft-ietf-pce-stateful-sync-optimizations@ietf.org
Cc: pce@ietf.org
Subject: Shepherd's review of draft-ietf-pce-stateful-sync-optimizat= ions-03

 

Hi there

 

I have performed a WG Shepherd = review of this draft.  Generally I found it a well-written draft with = no major issues.  There are a few minor issues that I think should be = resolved.

 

I have divided my comments into= three groups:

=A1=A4         technical =A8C comments that affect the meaning= of the document

=A1=A4         editorial =A8C comments that do not affect the = meaning but I think would significantly improve the clarity

=A1=A4         nits =A8C editorial comments that are minor and= obvious.

 

I would like to have at least t= he technical comments resolved before forwarding the document to the IESG.&= nbsp; Please could the authors review my comments and reply either by email= or by submitting a new draft version?

 

Best regards<= /p>

Jon

 

 

Technical<= /u>

 

s3.2 para 6.  =A1=B0If the PCC attempts to skip state synchronization (i.e., the SYNC Flag = =3D 0 on the first LSP State Report from the PCC as per [I-D.ietf-pce-stateful-pce]),=A1=B1

 

What if the PCC is synchronizin= g an empty LSPDB?  Then the first message it sends is LSP State Report= with SYNC=3D0 and PLSP-ID=3D0.  This is legitimate and yet the text s= ays to treat it as an error.  I think this paragraph should stipulate that the error condition is met only if SYNC=3D0 and PLSP= -ID is not 0.

 

[Xian]: Ag= reed. Will update as:

=A1=B0If the PCC = attempts to skip state synchronization, by setting the SYNC flag to 0 and P= LSP-ID set to non-zero, as per [I-D.ietf-pce-stateful-pce],=A1=B1

 

--

 

s4.2: Please rewrite the follow= ing text using RFC 2119 keywords. 

 

   If a PCC has to force full LSP= DB

   synchronization due to reasons= including but not limited: (1) local

   policy configured at the PCC; = (2) no sufficient LSP state caches for

   incremental update, the PCC ca= n set the D flag to 0.  Note a PCC may

   have to bring down the current= session and force a full LSP-DB

   synchronization with D flag se= t to 0 in the subsequent open message.

 

I would simply say =A1=B0The PCC MAY force a full LSP DB synchronization by setting the D flag t= o zero in the open message.=A1=B1  And then later, when you say this:

 

   If a PCC finds out it does not have =
sufficient information to
   complete incremental synchronisation=
 after advertising incremental
   LSP state synchronization capability=
, it MUST send a PCErr with
   Error-Type 20 and Error-Value 5 'A P=
CC indicates to a PCE that it can
   not complete the state synchronizati=
on' (defined in
   [I-D.ietf-pce-stateful-pce]) and ter=
minate the session.

 

add a sentence: =A1=B0The PCC SHOULD re-establish the session with the D bit set to zero in the = open message.=A1= =B1

[Xian]: po= int taken, with s/open/OPEN twice.

 

--

 

s4.2 =A1=B0So a PCC n= eeds to remember the LSP state changes that happened when an existing PCEP = session to a stateful PCE goes down in the hope of doing incremental synchronisation when the session is re-established.=A1=B1

 

Even this might not be sufficie= nt as the PCC has no idea how many messages the PCE managed to process befo= re the session goes down.  I think it would be more correct to say =A1=B0A PCC needs to remember at least the LSP state changes that= happened after an existing PCEP session to a stateful PCE goes down to hav= e any chance of doing incremental synchronisation when the session is re-established.=A1=B1

 

[Xian]: po= int taken, with s/to/with.

 

--

 

s5.2 Two concerns about the fol= lowing text:

 

   A stateful PCE MAY choose to control=
 the LSP-DB synchronization
   process.  To allow PCE to do so=
, PCEP speakers MUST set T bit to 1 to
   indicate this (as described in Secti=
on 7).

 

Why are you discussing the T bi= t here?  I thought that the behaviours controlled by the F bit and the= T bit were logically independent (although similar).  Are you saying = that the PCE must set the F bit and the PCC set the T bit for the procedures in section 5 to work?  You have written = a lot of the text in the passive voice, which makes it unclear who is suppo= sed to set which bit (see editorial comments below for more specific pointe= rs.)  Also, I think your cross-reference should be to section 6, not 7.

 

[Xian]: Th= is text is wrong and it should refer to the F bit. In version 01, we used t= he same bit (F) for both functions (Section 5 and 6), but latter we decided= to separate them. How about update it as below?

=A1=B0In order to= allow a stateful PCE to control the LSP-DB synchronization after establish= ing a PCEP session, both PCEP speakers MUST set F bit to 1 in the OPEN message.=A1=B1

 = ;

 = ;

--

 

s8.2 Please rewrite this as a r= equest to IANA to make an allocation from a specific registry (your text in= 8.1 is a good example to copy.)

s8.3 ditto.

[Xian]: Su= re, will do.

 = ;

One issue = though: The STATEFUL-PCE-CAPABILITY TLV is defined in draft-ietf-pce-statef= ul-pce-12, thus no registry yet but being requested there. Am I ok to write= the following text to provide a linkage?

 = ;

=A1=B0The STATEFU= L-PCE-CAPABILITY TLV is defined in [draft-ietf-pce-stateful-pce-12] and a r= egistry is requested to be created to manage the flags in the TLV.  IANA is requested to make the following allocation= in the aforementioned registry.

=A1=AD=

=A1=B1=

 

--

 

s9.2 The manageability section = ought to describe requirements on implementations, not requirements on the = PCE working group.  I think your text ought to read =A1=B0An implementation SHOULD allow the operator to view the sta= teful capabilities advertised by each peer, and the current synchronization= status with each peer.=A1=B1  (Note that I am not disagreeing with the idea of extending the PCEP MIB.)<= o:p>

[Xian]: Ok= . Expand the Information and Data Models with the sentence provided to make= it more general.

 

Editorial<= /u>

 

s3.2 para 10: =A1=B0I= f state synchronization avoidance is enabled=A1=AD=A1=B1  This would perhaps fit better alongside para 2, which discusses the other = legitimate reasons to increment the DB-VERSION.

[Xian]: po= int taken.

 

s4.1 final para feels superfluo= us =A8C suggest deleting.

[Xian]: ok= .

s5.1 I like the explanation of = why PCC:PCE bandwidth might be limited and I suggest moving this explanatio= n forwards to s4.1 (s4.1 tries to explain the same thing but is not as eleg= ant.).

[Xian]: Se= ction 4 and 5 used to one. So when splitting, we also put emphasis on diffe= rent aspects. Section 4 focuses on the need of delta sync. driven by small = changes of LSP-DB. This probably has wider utility. Section 5 focuses on the constraints a particular network may hav= e (optical as the main use case) so as to allow for PCE control of initial = sync.  Of course, implementations on both help better address the opti= cal network CC constraints. So I do not really want to move the whole sentence up, but to address your comment, I = suggest to add something like (e.g., in-band control channel for optical tr= ansport networks) in Section 4.

 

s5.2 =A1=B0Support of= PCE-triggered state synchronization is advertised=A1=B1 =A8C is advertised by whom?  Also, I think you mean =A1=B0initial state synchroniz= ation.=A1=B1  Please rewrite in the active voice (for example, =A1= =B0Both PCEP speakers advertise their support o= f PCE-triggered initial state synchronization during session startup by=A1=AD=A1=B1)  Ditto =A1=B0If the TRIGGERED-INITIAL-SYNC capability is not adve= rtised=A1=B1 -> =A1=B0If the PCE has not advertised the TRIGGERED-INITIAL-SYNC ca= pability=A1=B1

s6.2 =A1=B0Support of= PCE-triggered state synchronization is advertised=A1=B1 =A8C please use active voice.

 

[Xian]: Po= int taken; will be more explicit in the next update.

 = ;

Nits

 

s3.2 para 4: =A1=B0t= he PCE SHOULD ignore it were to receive one=A1=B1 =A8C I think you mean =A1=B0the PCE SHOULD ignore it were it to receive one=A1=B1

 = ;

[Xian]: ac= cepted.

 

--_000_C636AF2FA540124E9B9ACB5A6BECCE6B54AD0ED0SZXEMA512MBSchi_-- From nobody Thu Oct 22 04:20:33 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78EEB1A1BAF for ; Thu, 22 Oct 2015 04:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.804 X-Spam-Level: X-Spam-Status: No, score=-0.804 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 W727btX1mxmf for ; Thu, 22 Oct 2015 04:20:26 -0700 (PDT) Received: from mail.hq.sk (hq.sk [81.89.59.181]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8ED1A1B5B for ; Thu, 22 Oct 2015 04:20:24 -0700 (PDT) Received: from [172.16.4.98] (46.229.239.158.host.vnet.sk [46.229.239.158]) by mail.hq.sk (Postfix) with ESMTPSA id 1B483243AD1; Thu, 22 Oct 2015 13:20:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1445512822; bh=ba7bJJyXCBSqysaBFgkU3ZktF+gPshNJuJ1U8sGCtBQ=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=ZrdWkAbq02sfE9udL7geIXYm3rDF8XmF5u4UfwQsT88GFhq4+pWnkSX0s8RUXyCQj 0MlRevppf7SgMd9fiSsuUQq1QCi4oLxurwt7+OKccCRv4UYekbKjW6XKYxZ+fiyWBu /iSsv4/TmVgN9Ka1eYOqKBdYAvdS56mtnG4SmxHo= To: Dhruv Dhody , Olivier Dugeon , Dhruv Dhody References: <562761E5.8020302@orange.com> <56279D77.7090701@orange.com> <23CE718903A838468A8B325B80962F9B8C429626@BLREML509-MBX.china.huawei.com> From: Robert Varga Message-ID: <5628C674.7030906@hq.sk> Date: Thu, 22 Oct 2015 13:20:20 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <23CE718903A838468A8B325B80962F9B8C429626@BLREML509-MBX.china.huawei.com> Content-Type: multipart/alternative; boundary="------------070900000909080005040600" Archived-At: Cc: "pce@ietf.org" Subject: Re: [Pce] Questions about PCE Stateful Synchronisation X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 11:20:31 -0000 This is a multi-part message in MIME format. --------------070900000909080005040600 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hello, I competely agree with Dhruv. Design goal for stateful extension was to minimize control plane overhead for the usual case of steady state, so that PCE resources (which talks typically to many head end nodes) are used towards resolving failures. This concern was always the first one raised by both PCE and PCC implementations I talked to. The resynchronization mechanism proposed is meant to be used as a background maintenance task, which 'scrubs' the TED and takes a back seat to recovering the network when LSPs churn. This cannot be done if the PCCs re-publish the same steady state over and over -- for a network of 1M LSPs with 1 hour refresh that amounts to ~278 PCRpt/s just to maintain steady state. PCE implementations I have talked to have found this mechanism sufficient to maintain enough consistency to keep operating even in face of such bugs not being caught by QA. Anyway, the specification does not prohibit this behavior on PCC part and if a need arises for the PCE to request this functionality, it can be negotiated as a separate extension at session startup. Bye, Robert On 10/22/2015 06:58 AM, Dhruv Dhody wrote: > > Hi Olivier, > > IMHO PCEP is much closer to BGP (when compared to IGP), and in that > PCE-triggered full re-sync is similar to BGP’s route-refresh > mechanism. So I guess we are re-using a similar concept which scales > well too :) > > As you also mention that such issue might be seen on a long running > session, this re-sync if needed, would be after a long time. > > IMHO sending PCRpt repeatedly say at every 3600 secs for all LSP would > be costly too. > > I will leave it to the authors of the base draft to answer your other > question. In the implementations that I am aware of, that is the local > policy and usually set to report all LSPs. > > Regards, > > Dhruv > > *From:*Pce [mailto:pce-bounces@ietf.org] *On Behalf Of *Olivier Dugeon > *Sent:* 21 October 2015 19:43 > *To:* Dhruv Dhody > *Cc:* pce@ietf.org > *Subject:* Re: [Pce] Questions about PCE Stateful Synchronisation > > Hello Dhruv, > > Thanks pointing me this section, but I read the draft before asking my > questions. For me, it is not completely cover this issue, and my > answer is Yes and No. > > Yes, because the mechanism allow such re-synchronization without > closing the PCEP session, but at the price of exchanging PCUpd / PCRpt > message when only one PCRpt message is sufficient. It solves the > problem of orphan LSP. In this case, I agree that when the PCE asks to > update an orphan LSP it gets an error (I suppose as it is not specify > in the draft). > > An No, because it not solves completely the issue if the PCE is not > aware of an LSP. The PCE could not request an update about an LSPs it > ignores. > > So, the only working solution for the PCE is to ask regularly all PCCs > to send their complete LSP DB to be sure that it is always > synchronized, but it is a very costly mechanism. > > In addition, I have some doubt that this mechanism scale well. For > large networks, say more then 1000 PE routers, so more than 1000 PCEP > sessions, with a full mesh of TE tunnels (I know it is an extreme > case) this increase drastically the exchange between the PCE and PCCs > and add extra CPU process for the PCE. The later must parse 1,000,000 > tunnels in its LSPs DB and ask PCCs to refresh them. Or, asks all PCCs > to update all their tunnels. In the first case the PCE spent its time > to send PCUpd message waiting for the corresponding PCRpt answer and > in the second case it spent its time to parse 1000 tunnels each time > it asks a PCC for a full refresh. > > Flood periodically Link State in IGP protocol has proof for a long > time that it scale well even in very large network. Why not re-using a > similar concept ? > > And, last but not least, what's happen with LSP tunnels that are > configured on router that are not PCEP enable ? There are simply ignored ? > > Regards, > > Olivier > > Le 21/10/2015 15:01, Dhruv Dhody a écrit : > > Hi Olivier, > > Wanted to bring "PCE triggered re-syncronization" > [https://tools.ietf.org/html/draft-ietf-pce-stateful-sync-optimizations-03#section-6] > to your notice. This can be used by a PCE to periodically > re-synchronize the database without bringing down the PCEP session. > > Will this not cover the issue you have in mind? > > Regards, > > Dhruv > > On Wed, Oct 21, 2015 at 3:29 PM, Olivier Dugeon > > wrote: > > Dear authors of draft-ietf-pce-stateful and > draft-ietf-pce-stateful-sync-optimizations, > > I know that we are in the last miles before publish PCE Stateful > draft collection as RFCs, but regarding the chairs' review, I have > a global interrogation about synchronisation. Even I-Ds try to > avoid it, I'm afraid that there will different cases where > de-synchronisation is not avoided between PCCs and PCEs. In > particular, in case of problem, not a real failure, more a bug, > memory saturation or whatever mal-function could occur on the PCE > or PCC side, a PCE could miss a PCRpt message from a PCC or > respectively a PCC could miss to send a PCRpt message to a PCE. > I'm also afraid, after a long live period (say, several weeks or > months) that some orphan LSPs appear in the PCE LSPs database > without the possibility to detect them and remove them. > > To go back in a full sync state, it is then necessary to restart > properly the PCEP session, i.e. force a re-synchronisation. But, > to do that, you need to discover the problem. That's another topic. > > So, my question is why do you not have use a similar mechanism to > routing protocol, i.e. OSPF, IS-IS or BGP, to periodically send > LSPs state from the PCC to the PCE. Using an 'out of date' > indication will allow the PCE to remove in its LSP-DB 'out of > date' LSPs like OSPF do when it flushes an LSA with ageing equal > to 3600 in its TED. > > What it is sufficient is to add a new statement in > draft-ietf-pce-stateful (e.g., in section 9.1. Control Function > and Policy) telling that: > - the PCC MUST send PCRpt message on a regular basis, before > MAX_AGE expire. > - the PCE MUST ignore LSPs that are not refresh since a period of > time greater than MAX_AGE. > > Then, two cases are possible: > a) MAX_AGE is fixed in the RFC e.g. to 3600 seconds like in OSPF > (seems reasonable) > b) Negotiate/exchange during PCEP session establishment or when > PCRpt message is sent > > If option (a) is quiet simple but not flexible, it has the great > advantage to not introduce new PCEP Object while option (b) need > new PCEP Object definition, but provide a greater flexibility. > > If we agree on the statement above, I think that option (a) is > sufficient and just need additional text in current draft while if > we want to support option (b), I could work on a new draft. > > Regards, > > Olivier > -- > logo Orange > > Olivier Dugeon > Orange Expert, Future Networks > Open Source Referent > Orange/IMT/OLN/WTC/IEE/OPEN > > fixe : +33 2 96 05 28 80 > mobile : +33 6 82 90 37 85 > olivier.dugeon@orange.com > > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce --------------070900000909080005040600 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Hello,

I competely agree with Dhruv.

Design goal for stateful extension was to minimize control plane overhead for the usual case of steady state, so that PCE resources (which talks typically to many head end nodes) are used towards resolving failures. This concern was always the first one raised by both PCE and PCC implementations I talked to.

The resynchronization mechanism proposed is meant to be used as a background maintenance task, which 'scrubs' the TED and takes a back seat to recovering the network when LSPs churn. This cannot be done if the PCCs re-publish the same steady state over and over -- for a network of 1M LSPs with 1 hour refresh that amounts to ~278 PCRpt/s just to maintain steady state. PCE implementations I have talked to have found this mechanism sufficient to maintain enough consistency to keep operating even in face of such bugs not being caught by QA.

Anyway, the specification does not prohibit this behavior on PCC part and if a need arises for the PCE to request this functionality, it can be negotiated as a separate extension at session startup.

Bye,
Robert

On 10/22/2015 06:58 AM, Dhruv Dhody wrote:

Hi Olivier,

 

IMHO PCEP is much closer to BGP (when compared to IGP), and in that PCE-triggered full re-sync is similar to BGP’s route-refresh mechanism. So I guess we are re-using a similar concept which scales well too :)

 

As you also mention that such issue might be seen on a long running session, this re-sync if needed, would be after a long time.

IMHO sending PCRpt repeatedly say at every 3600 secs for all LSP would be costly too.

 

I will leave it to the authors of the base draft to answer your other question. In the implementations that I am aware of, that is the local policy and usually set to report all LSPs.  

 

Regards,

Dhruv

 

From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Olivier Dugeon
Sent: 21 October 2015 19:43
To: Dhruv Dhody
Cc: pce@ietf.org
Subject: Re: [Pce] Questions about PCE Stateful Synchronisation

 

Hello Dhruv,

Thanks pointing me this section, but I read the draft before asking my questions. For me, it is not completely cover this issue, and my answer is Yes and No.

Yes, because the mechanism allow such re-synchronization without closing the PCEP session, but at the price of exchanging PCUpd / PCRpt message when only one PCRpt message is sufficient. It solves the problem of orphan LSP. In this case, I agree that when the PCE asks to update an orphan LSP it gets an error (I suppose as it is not specify in the draft).

An No, because it not solves completely the issue if the PCE is not aware of an LSP. The PCE could not request an update about an LSPs it ignores.

So, the only working solution for the PCE is to ask regularly all PCCs to send their complete LSP DB to be sure that it is always synchronized, but it is a very costly mechanism.

In addition, I have some doubt that this mechanism scale well. For large networks, say more then 1000 PE routers, so more than 1000 PCEP sessions, with a full mesh of TE tunnels (I know it is an extreme case) this increase drastically the exchange between the PCE and PCCs and add extra CPU process for the PCE. The later must parse 1,000,000 tunnels in its LSPs DB and ask PCCs to refresh them. Or, asks all PCCs to update all their tunnels. In the first case the PCE spent its time to send PCUpd message waiting for the corresponding PCRpt answer and in the second case it spent its time to parse 1000 tunnels each time it asks a PCC for a full refresh.

Flood periodically Link State in IGP protocol has proof for a long time that it scale well even in very large network. Why not re-using a similar concept ?

And, last but not least, what's happen with LSP tunnels that are configured on router that are not PCEP enable ? There are simply ignored ?

Regards,

Olivier

Le 21/10/2015 15:01, Dhruv Dhody a écrit :

Hi Olivier, 

 

Wanted to bring "PCE triggered re-syncronization" [https://tools.ietf.org/html/draft-ietf-pce-stateful-sync-optimizations-03#section-6] to your notice. This can be used by a PCE to periodically re-synchronize the database without bringing down the PCEP session. 

 

Will this not cover the issue you have in mind? 

 

Regards,

Dhruv

 

 

On Wed, Oct 21, 2015 at 3:29 PM, Olivier Dugeon <olivier.dugeon@orange.com> wrote:

Dear authors of draft-ietf-pce-stateful and draft-ietf-pce-stateful-sync-optimizations,

I know that we are in the last miles before publish PCE Stateful draft collection as RFCs, but regarding the chairs' review, I have a global interrogation about synchronisation. Even I-Ds try to avoid it, I'm afraid that there will different cases where de-synchronisation is not avoided between PCCs and PCEs. In particular, in case of problem, not a real failure, more a bug, memory saturation or whatever mal-function could occur on the PCE or PCC side, a PCE could miss a PCRpt message from a PCC or respectively a PCC could miss to send a PCRpt message to a PCE. I'm also afraid, after a long live period (say, several weeks or months) that some orphan LSPs appear in the PCE LSPs database without the possibility to detect them and remove them.

To go back in a full sync state, it is then necessary to restart properly the PCEP session, i.e. force a re-synchronisation. But, to do that, you need to discover the problem. That's another topic.

So, my question is why do you not have use a similar mechanism to routing protocol, i.e. OSPF, IS-IS or BGP, to periodically send LSPs state from the PCC to the PCE. Using an 'out of date' indication will allow the PCE to remove in its LSP-DB 'out of date' LSPs like OSPF do when it flushes an LSA with ageing equal to 3600 in its TED.

What it is sufficient is to add a new statement in draft-ietf-pce-stateful (e.g., in section 9.1.  Control Function and Policy) telling that:
 - the PCC MUST send PCRpt message on a regular basis, before MAX_AGE expire.
 - the PCE MUST ignore LSPs that are not refresh since a period of time greater than MAX_AGE.

Then, two cases are possible:
 a) MAX_AGE is fixed in the RFC e.g. to 3600 seconds like in OSPF (seems reasonable)
 b) Negotiate/exchange during PCEP session establishment or when PCRpt message is sent

If option (a) is quiet simple but not flexible, it has the great advantage to not introduce new PCEP Object while option (b) need new PCEP Object definition, but provide a greater flexibility.

If we agree on the statement above,  I think that option (a) is sufficient and just need additional text in current draft while if we want to support option (b), I could work on a new draft.

Regards,

Olivier
--
logo Orange <http://www.orange.com>

Olivier Dugeon
Orange Expert, Future Networks
Open Source Referent
Orange/IMT/OLN/WTC/IEE/OPEN

fixe : +33 2 96 05 28 80
mobile : +33 6 82 90 37 85
olivier.dugeon@orange.com <mailto:olivier.dugeon@orange.com>

_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

 

 



_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

--------------070900000909080005040600-- From nobody Thu Oct 22 04:29:34 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63A4F1A1BE4; Thu, 22 Oct 2015 04:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.804 X-Spam-Level: X-Spam-Status: No, score=-0.804 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 9wI5vrqLl3XS; Thu, 22 Oct 2015 04:29:32 -0700 (PDT) Received: from mail.hq.sk (hq.sk [81.89.59.181]) by ietfa.amsl.com (Postfix) with ESMTP id 30E911A1BEC; Thu, 22 Oct 2015 04:29:32 -0700 (PDT) Received: from [172.16.4.98] (46.229.239.158.host.vnet.sk [46.229.239.158]) by mail.hq.sk (Postfix) with ESMTPSA id 6B809243AD1; Thu, 22 Oct 2015 13:29:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1445513371; bh=UuhWh/jp+8wZG8i48oCBJ4AxCScYmUtXuzy7tua/wWw=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=QFzvXf21aSGxfNjawRHDYAWNzLiRO4ke4MqovciXDNDbrZpb4gdwF+qxKla4MY+xq 3U0E9w4lztcrZGsrBA3E1DxVa254gDp5ChiLZA4jbLzOenb90aQ87UEHUuij3OeNlS LyaPDjM1FPls2zoaNXiEGEE3vD8bXIi4cGUzSVOw= To: Dhruv Dhody , "draft-ietf-pce-segment-routing@ietf.org" , "draft-ietf-pce-stateful-pce@tools.ietf.org" References: <23CE718903A838468A8B325B80962F9B8C421A83@BLREML509-MBX.china.huawei.com> From: Robert Varga Message-ID: <5628C89B.3000404@hq.sk> Date: Thu, 22 Oct 2015 13:29:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <23CE718903A838468A8B325B80962F9B8C421A83@BLREML509-MBX.china.huawei.com> Content-Type: multipart/alternative; boundary="------------010606040102010704040803" Archived-At: Cc: "pce@ietf.org" , "pce-chairs@tools.ietf.org" Subject: Re: [Pce] Query on Usage of LSP Identifier TLV in SR X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 11:29:33 -0000 This is a multi-part message in MIME format. --------------010606040102010704040803 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 10/12/2015 07:58 AM, Dhruv Dhody wrote: > > Hi Authors, > > In the stateful PCE draft [1], it says – > > The LSP Identifiers TLV MUST be included in the LSP object in PCRpt > > messages for RSVP-signaled LSPs. > > The SR draft [2] did not mention anything about LSP Identifier TLV. > > And in implementations that I am aware of, SR-TE LSP still uses the > LSP-Identifier TLV. Is that correct? (I personally think so!!) > > If yes, do you think there is a need to update – > > -[1] to say all LSPs (and not just RSVP-signaled). > > -Or [2] to say that LSP-Identifier TLV are also applicable to SR and > MUST be included. > The wording in stateful draft is meant to proscribe behavior for RSVP (as that is what RFC5440 assumes), while allowing different setup mechanisms (https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-setup-type/) specify their own LSP identifier format. In this spirit I think the SR draft should be updated to explicitly state that SR reuses the same identifier format as RSVP (or whatever is appropriate). Bye, Robert --------------010606040102010704040803 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 10/12/2015 07:58 AM, Dhruv Dhody wrote:

Hi Authors,

 

In the stateful PCE draft [1], it says –

The LSP Identifiers TLV MUST be included in the LSP object in PCRpt

messages for RSVP-signaled LSPs.

 

The SR draft [2] did not mention anything about LSP Identifier TLV.

And in implementations that I am aware of, SR-TE LSP still uses the LSP-Identifier TLV. Is that correct? (I personally think so!!)

 

If yes, do you think there is a need to update –

-      [1] to say all LSPs (and not just RSVP-signaled).

-      Or [2] to say that LSP-Identifier TLV are also applicable to SR and MUST be included.

 


The wording in stateful draft is meant to proscribe behavior for RSVP (as that is what RFC5440 assumes), while allowing different setup mechanisms (https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-setup-type/) specify their own LSP identifier format.

In this spirit I think the SR draft should be updated to explicitly state that SR reuses the same identifier format as RSVP (or whatever is appropriate).

Bye,
Robert

--------------010606040102010704040803-- From nobody Thu Oct 22 05:03:05 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0663D1A86F1; Thu, 22 Oct 2015 05:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-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 T3Ik-5GL31GB; Thu, 22 Oct 2015 05:02:57 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0778.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::778]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCFEE1A8859; Thu, 22 Oct 2015 05:02:55 -0700 (PDT) Received: from DM2PR02MB1356.namprd02.prod.outlook.com (10.161.143.13) by DM2PR02MB1354.namprd02.prod.outlook.com (10.161.143.11) with Microsoft SMTP Server (TLS) id 15.1.300.14; Thu, 22 Oct 2015 12:02:36 +0000 Received: from DM2PR02MB1356.namprd02.prod.outlook.com ([10.161.143.13]) by DM2PR02MB1356.namprd02.prod.outlook.com ([10.161.143.13]) with mapi id 15.01.0300.010; Thu, 22 Oct 2015 12:02:36 +0000 From: Jonathan Hardwick To: "Zhangxian (Xian)" , "draft-ietf-pce-stateful-sync-optimizations@ietf.org" Thread-Topic: Shepherd's review of draft-ietf-pce-stateful-sync-optimizations-03 Thread-Index: AdEIKFCM/MXbJYqfQi2B63ASoTqDyAEPmKVAABadSCA= Date: Thu, 22 Oct 2015 12:02:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jonathan.Hardwick@metaswitch.com; x-originating-ip: [2620:104:4001:73:1419:e5d7:eafc:5ef4] x-microsoft-exchange-diagnostics: 1; DM2PR02MB1354; 5:4qUi/Re7pi6+G10NFOmQxAM/kBIafulMa2UD5cRA9F2hGDZbuV6RxHT7MBQOSivD6KxiIKA/YTUbmJlIgJq79U/afQpdGY5R6pwFJ+ddVRs6drlPXAeaoB28EFzyxUeXQsi3LJS2tK5AxhXc/5wbtA==; 24:BlM9bwOcb7Yg92PsnLZyr7a1nvnc6g0h001wXu+mT/g0NPhQHdUYsUFT0pNgCHl6CHJinCz8d4RB883d+i1zk0p60eteULyDWV9A14K+HcU=; 20:SX1kfxWPq67p3UD0s/Ge3bZRgyBXOyOv0VyKiopHkCeoz/pTNRL/OmxfLHuP42evpurgLIXPFIKaBAqwCWPTmw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR02MB1354; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(102215026); SRVR:DM2PR02MB1354; BCL:0; PCL:0; RULEID:; SRVR:DM2PR02MB1354; x-forefront-prvs: 0737B96801 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(66654002)(189002)(52604005)(199003)(189998001)(19580395003)(106356001)(76576001)(105586002)(230783001)(64706001)(87936001)(99286002)(2501003)(5004730100002)(11100500001)(10400500002)(5007970100001)(46102003)(122556002)(92566002)(40100003)(19300405004)(5008740100001)(19580405001)(2900100001)(15975445007)(77096005)(5001920100001)(102836002)(2950100001)(5003600100002)(5001770100001)(76176999)(97736004)(81156007)(101416001)(54356999)(50986999)(19625215002)(86362001)(74316001)(5002640100001)(33656002)(16236675004)(5001960100002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR02MB1354; H:DM2PR02MB1356.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM2PR02MB135612125019E2BB959170B884270DM2PR02MB1356namp_" MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Oct 2015 12:02:35.9558 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR02MB1354 Archived-At: Cc: "pce@ietf.org" Subject: Re: [Pce] Shepherd's review of draft-ietf-pce-stateful-sync-optimizations-03 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 12:03:04 -0000 --_000_DM2PR02MB135612125019E2BB959170B884270DM2PR02MB1356namp_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Hi Xian Many thanks for taking my comments on board. Please see [JEH] below for co= nfirmation. Best regards Jon From: Zhangxian (Xian) [mailto:zhang.xian@huawei.com] Sent: 22 October 2015 08:34 To: Jonathan Hardwick ; draft-ietf-pce-st= ateful-sync-optimizations@ietf.org Cc: pce@ietf.org Subject: RE: Shepherd's review of draft-ietf-pce-stateful-sync-optimization= s-03 Hi, Jon, Thank you for the detailed review. Please see my reply inline: I will update/upload the draft once we reach agreement on all points, right= after the upload re-opening. Regards, Xian From: Jonathan Hardwick [mailto:Jonathan.Hardwick@metaswitch.com] Sent: 2015=1B$BG/=1B(B10=1B$B7n=1B(B19=1B$BF|=1B(B 18:18 To: draft-ietf-pce-stateful-sync-optimizations@ietf.org Cc: pce@ietf.org Subject: Shepherd's review of draft-ietf-pce-stateful-sync-optimizations-03 Hi there I have performed a WG Shepherd review of this draft. Generally I found it = a well-written draft with no major issues. There are a few minor issues th= at I think should be resolved. I have divided my comments into three groups: * technical - comments that affect the meaning of the document * editorial - comments that do not affect the meaning but I think w= ould significantly improve the clarity * nits - editorial comments that are minor and obvious. I would like to have at least the technical comments resolved before forwar= ding the document to the IESG. Please could the authors review my comments= and reply either by email or by submitting a new draft version? Best regards Jon Technical s3.2 para 6. =1B$B!H=1B(BIf the PCC attempts to skip state synchronization= (i.e., the SYNC Flag =3D 0 on the first LSP State Report from the PCC as p= er [I-D.ietf-pce-stateful-pce]),=1B$B!I=1B(B What if the PCC is synchronizing an empty LSPDB? Then the first message it= sends is LSP State Report with SYNC=3D0 and PLSP-ID=3D0. This is legitima= te and yet the text says to treat it as an error. I think this paragraph s= hould stipulate that the error condition is met only if SYNC=3D0 and PLSP-I= D is not 0. [Xian]: Agreed. Will update as: =1B$B!H=1B(BIf the PCC attempts to skip state synchronization, by setting t= he SYNC flag to 0 and PLSP-ID set to non-zero, as per [I-D.ietf-pce-statefu= l-pce],=1B$B!I=1B(B -- s4.2: Please rewrite the following text using RFC 2119 keywords. If a PCC has to force full LSP DB synchronization due to reasons including but not limited: (1) local policy configured at the PCC; (2) no sufficient LSP state caches for incremental update, the PCC can set the D flag to 0. Note a PCC may have to bring down the current session and force a full LSP-DB synchronization with D flag set to 0 in the subsequent open message. I would simply say =1B$B!H=1B(BThe PCC MAY force a full LSP DB synchronizat= ion by setting the D flag to zero in the open message.=1B$B!I=1B(B And the= n later, when you say this: If a PCC finds out it does not have sufficient information to complete incremental synchronisation after advertising incremental LSP state synchronization capability, it MUST send a PCErr with Error-Type 20 and Error-Value 5 'A PCC indicates to a PCE that it can not complete the state synchronization' (defined in [I-D.ietf-pce-stateful-pce]) and terminate the session. add a sentence: =1B$B!H=1B(BThe PCC SHOULD re-establish the session with th= e D bit set to zero in the open message.=1B$B!I=1B(B [Xian]: point taken, with s/open/OPEN twice. -- s4.2 =1B$B!H=1B(BSo a PCC needs to remember the LSP state changes that happ= ened when an existing PCEP session to a stateful PCE goes down in the hope = of doing incremental synchronisation when the session is re-established.=1B= $B!I=1B(B Even this might not be sufficient as the PCC has no idea how many messages = the PCE managed to process before the session goes down. I think it would = be more correct to say =1B$B!H=1B(BA PCC needs to remember at least the LSP= state changes that happened after an existing PCEP session to a stateful P= CE goes down to have any chance of doing incremental synchronisation when t= he session is re-established.=1B$B!I=1B(B [Xian]: point taken, with s/to/with. -- s5.2 Two concerns about the following text: A stateful PCE MAY choose to control the LSP-DB synchronization process. To allow PCE to do so, PCEP speakers MUST set T bit to 1 to indicate this (as described in Section 7). Why are you discussing the T bit here? I thought that the behaviours contr= olled by the F bit and the T bit were logically independent (although simil= ar). Are you saying that the PCE must set the F bit and the PCC set the T = bit for the procedures in section 5 to work? You have written a lot of the= text in the passive voice, which makes it unclear who is supposed to set w= hich bit (see editorial comments below for more specific pointers.) Also, = I think your cross-reference should be to section 6, not 7. [Xian]: This text is wrong and it should refer to the F bit. In version 01,= we used the same bit (F) for both functions (Section 5 and 6), but latter = we decided to separate them. How about update it as below? =1B$B!H=1B(BIn order to allow a stateful PCE to control the LSP-DB synchron= ization after establishing a PCEP session, both PCEP speakers MUST set F bi= t to 1 in the OPEN message.=1B$B!I=1B(B [JEH] OK, looks good. -- s8.2 Please rewrite this as a request to IANA to make an allocation from a = specific registry (your text in 8.1 is a good example to copy.) s8.3 ditto. [Xian]: Sure, will do. One issue though: The STATEFUL-PCE-CAPABILITY TLV is defined in draft-ietf-= pce-stateful-pce-12, thus no registry yet but being requested there. Am I o= k to write the following text to provide a linkage? =1B$B!H=1B(BThe STATEFUL-PCE-CAPABILITY TLV is defined in [draft-ietf-pce-s= tateful-pce-12] and a registry is requested to be created to manage the fla= gs in the TLV. IANA is requested to make the following allocation in the a= forementioned registry. =1B$B!D=1B(B =1B$B!I=1B(B [JEH] Thanks. This proposed text looks good. -- s9.2 The manageability section ought to describe requirements on implementa= tions, not requirements on the PCE working group. I think your text ought = to read =1B$B!H=1B(BAn implementation SHOULD allow the operator to view the= stateful capabilities advertised by each peer, and the current synchroniza= tion status with each peer.=1B$B!I=1B(B (Note that I am not disagreeing wi= th the idea of extending the PCEP MIB.) [Xian]: Ok. Expand the Information and Data Models with the sentence provid= ed to make it more general. Editorial s3.2 para 10: =1B$B!H=1B(BIf state synchronization avoidance is enabled=1B$= B!D!I=1B(B This would perhaps fit better alongside para 2, which discusses= the other legitimate reasons to increment the DB-VERSION. [Xian]: point taken. s4.1 final para feels superfluous - suggest deleting. [Xian]: ok. s5.1 I like the explanation of why PCC:PCE bandwidth might be limited and I= suggest moving this explanation forwards to s4.1 (s4.1 tries to explain th= e same thing but is not as elegant.). [Xian]: Section 4 and 5 used to one. So when splitting, we also put emphasi= s on different aspects. Section 4 focuses on the need of delta sync. driven= by small changes of LSP-DB. This probably has wider utility. Section 5 foc= uses on the constraints a particular network may have (optical as the main = use case) so as to allow for PCE control of initial sync. Of course, imple= mentations on both help better address the optical network CC constraints. = So I do not really want to move the whole sentence up, but to address your = comment, I suggest to add something like (e.g., in-band control channel for= optical transport networks) in Section 4. [JEH] That=1B$B!G=1B(Bs OK, thanks. s5.2 =1B$B!H=1B(BSupport of PCE-triggered state synchronization is advertis= ed=1B$B!I=1B(B - is advertised by whom? Also, I think you mean =1B$B!H=1B(= Binitial state synchronization.=1B$B!I=1B(B Please rewrite in the active v= oice (for example, =1B$B!H=1B(BBoth PCEP speakers advertise their support o= f PCE-triggered initial state synchronization during session startup by=1B$= B!D!I=1B(B) Ditto =1B$B!H=1B(BIf the TRIGGERED-INITIAL-SYNC capability is = not advertised=1B$B!I=1B(B -> =1B$B!H=1B(BIf the PCE has not advertised the= TRIGGERED-INITIAL-SYNC capability=1B$B!I=1B(B s6.2 =1B$B!H=1B(BSupport of PCE-triggered state synchronization is advertis= ed=1B$B!I=1B(B - please use active voice. [Xian]: Point taken; will be more explicit in the next update. Nits s3.2 para 4: =1B$B!H=1B(Bthe PCE SHOULD ignore it were to receive one=1B$B!= I=1B(B - I think you mean =1B$B!H=1B(Bthe PCE SHOULD ignore it were it to r= eceive one=1B$B!I=1B(B [Xian]: accepted. --_000_DM2PR02MB135612125019E2BB959170B884270DM2PR02MB1356namp_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

Hi Xian

 

Many thanks for taking my comments on board.  Please see [JEH] be= low for confirmation.

 

Best regards

Jon

 

From: Zhangxian (Xian) [mailto:zhang.xian@huawei.com]
Sent: 22 October 2015 08:34
To: Jonathan Hardwick <Jonathan.Hardwick@metaswitch.com>; draf= t-ietf-pce-stateful-sync-optimizations@ietf.org
Cc: pce@ietf.org
Subject: RE: Shepherd's review of draft-ietf-pce-stateful-sync-optim= izations-03

 

Hi, Jon,

 

Thank you for the detailed review. Plea= se see my reply inline:

 

I will update/upload the draft once we = reach agreement on all points, right after the upload re-opening.

 

Regards,
Xian

 

From: Jo= nathan Hardwick [mailto= :Jonathan.Hardwick@metaswitch.com]
Sent: 2015=1B$BG/=1B(B10=1B$B7n=1B(B19=1B$BF|=1B(B 18:18
To: draft-ietf-pce-stateful-sync-optimizations@ietf.org
Cc: pce@ietf.org
Subject: Shepherd's review of draft-ietf-pce-stateful-sync-optimizat= ions-03

 

Hi there

 

I have performed a WG Shepherd review of this draft.=   Generally I found it a well-written draft with no major issues. = ; There are a few minor issues that I think should be resolved.<= /p>

 

I have divided my comments into three groups:

·      &= nbsp;  technical – comments that affect the meaning of the document

·      &= nbsp;  editorial – comments that do not affect the meaning but I thin= k would significantly improve the clarity

·      &= nbsp;  nits – editorial comments that are minor and obvious.

 

I would like to have at least the technical comments= resolved before forwarding the document to the IESG.  Please could th= e authors review my comments and reply either by email or by submitting a n= ew draft version?

 

Best regards

Jon

 

 

Technical

 

s3.2 para 6.  =1B$B!H=1B(BIf the PCC attempts to skip state synchronization (i.e.,= the SYNC Flag =3D 0 on the first LSP State Report from the PCC as per [I-D= .ietf-pce-stateful-pce]),= =1B$B!I=1B(B

 

What if the PCC is synchronizing an empty LSPDB?&nbs= p; Then the first message it sends is LSP State Report with SYNC=3D0 and PL= SP-ID=3D0.  This is legitimate and yet the text says to treat it as an= error.  I think this paragraph should stipulate that the error condition is met only if SYNC=3D0 and PLSP-ID is not 0.

 

[Xian]: Agreed. Will upda= te as:

=1B$B!H=1B(BIf the PCC attempts = to skip state synchronization, by setting the SYNC flag to 0 and PLSP-ID se= t to non-zero, as per [I-D.ietf-pce-stateful-pce],=1B$B!I=1B(B

 

--

 

s4.2: Please rewrite the following text using RFC 21= 19 keywords. 

 

   If a PCC has to force full LSP DB=

   synchronization due to reasons including but = not limited: (1) local

   policy configured at the PCC; (2) no sufficie= nt LSP state caches for

   incremental update, the PCC can set the D fla= g to 0.  Note a PCC may

   have to bring down the current session and fo= rce a full LSP-DB

   synchronization with D flag set to 0 in the s= ubsequent open message.

 

I would simply say =1B$B!H=1B(BThe PCC MAY force a full LSP DB synchronization by setti= ng the D flag to zero in the open message.=1B$B!I=1B(B  And then later, when you say thi= s:

 

   If a PCC finds out it does not have sufficient informatio=
n to
   complete incremental synchronisation after advertising in=
cremental
   LSP state synchronization capability, it MUST send a PCEr=
r with
   Error-Type 20 and Error-Value 5 'A PCC indicates to a PCE=
 that it can
   not complete the state synchronization' (defined in<=
/o:p>
   [I-D.ietf-pce-stateful-pce]) and terminate the session.

 

add a sentence: =1B$B!H=1B(BThe PCC SHOULD re-establish the session with the D bit s= et to zero in the open message.=1B$B!I=1B(B

[Xian]: point taken, with= s/open/OPEN twice.

 

--

 

s4.2 =1B$B!H=1B(BSo a PCC needs to remember the LSP state changes that= happened when an existing PCEP session to a stateful PCE goes down in the = hope of doing incremental synchronisation when the session is re-established.=1B$B!I=1B(B

 

Even this might not be sufficient as the PCC has no = idea how many messages the PCE managed to process before the session goes d= own.  I think it would be more correct to say =1B$B!H=1B(BA PCC = needs to remember at least the LSP state changes that happened after an exi= sting PCEP session to a stateful PCE goes down to have any chance of doing = incremental synchronisation when the session is re-established.=1B$B!I= =1B(B

 

[Xian]: point taken, with= s/to/with.

 

--

 

s5.2 Two concerns about the following text:

 

   A stateful PCE MAY choose to control the LSP-DB synchroni=
zation
   process.  To allow PCE to do so, PCEP speakers MUST =
set T bit to 1 to
   indicate this (as described in Section 7).

 


Why are you discussing the T bit here?  I thoug=
ht that the behaviours controlled by the F bit and the T bit were logically=
 independent (although similar).  Are you saying that the PCE must set=
 the F bit and the PCC set the T bit for the
 procedures in section 5 to work?  You have written a lot of the text =
in the passive voice, which makes it unclear who is supposed to set which b=
it (see editorial comments below for more specific pointers.)  Also, I=
 think your cross-reference should be to section
 6, not 7.


 


[Xian]: This text is wron=
g and it should refer to the F bit. In version 01, we used the same bit (F)=
 for both functions (Section 5 and 6), but latter we decided to separate th=
em. How about update it as below?


=1B$B!H=1B(BIn order to allow a =
stateful PCE to control the LSP-DB synchronization after establishing a PCE=
P session, both PCEP speakers MUST set F bit to 1 in
 the OPEN message.=1B$B!I=1B(B


 <=
/p>

[JEH] OK, looks good.<=
o:p>


 <=
/p>

--


 


s8.2 Please rewrite this as a request to IANA to mak=
e an allocation from a specific registry (your text in 8.1 is a good exampl=
e to copy.)


s8.3 ditto.


[Xian]: Sure, will do. 


 <=
/p>

One issue though: The STA=
TEFUL-PCE-CAPABILITY TLV is defined in draft-ietf-pce-stateful-pce-12, thus=
 no registry yet but being requested there. Am I ok to write the following =
text to provide a linkage?


 <=
/p>

=1B$B!H=1B(BThe STATEFUL-PCE-CAP=
ABILITY TLV is defined in [draft-ietf-pce-stateful-pce-12] and a registry i=
s requested to be created to manage the flags in the
 TLV.  IANA is requested to make the following allocation in the afore=
mentioned registry.


=1B$B!D=1B(B


=1B$B!I=1B(B


[JEH] Thanks.  Th=
is proposed text looks good.


 


--


 


s9.2 The manageability section ought to describe req=
uirements on implementations, not requirements on the PCE working group.&nb=
sp; I think your text ought to read
=1B$B!H=1B(BAn imp=
lementation SHOULD allow the operator to view the stateful capabilities adv=
ertised by each peer, and the current synchronization status with each peer=
.=1B$B!I=1B(B =
;
 (Note that I am not disagreeing with the idea of extending the PCEP MIB.)<=
o:p>


[Xian]: Ok. Expand the In=
formation and Data Models with the sentence provided to make it more genera=
l.


 


Editorial


 


s3.2 para 10: 
=1B$B!H=1B(BIf state synchronization avoidance is enabled=1B$B!D!I=1B(B  This wo=
uld perhaps fit better alongside para 2, which discusses the other legitima=
te reasons to increment the DB-VERSION.


[Xian]: point taken.


 


s4.1 final para feels superfluous 
– suggest deleting.


[Xian]: ok.


s5.1 I like the explanation of why PCC:PCE bandwidth=
 might be limited and I suggest moving this explanation forwards to s4.1 (s=
4.1 tries to explain the same thing but is not as elegant.).


[Xian]: Section 4 and 5 u=
sed to one. So when splitting, we also put emphasis on different aspects. S=
ection 4 focuses on the need of delta sync. driven by small changes of LSP-=
DB. This probably has wider utility.
 Section 5 focuses on the constraints a particular network may have (optica=
l as the main use case) so as to allow for PCE control of initial sync.&nbs=
p; Of course, implementations on both help better address the optical netwo=
rk CC constraints. So I do not really
 want to move the whole sentence up, but to address your comment, I suggest=
 to add something like (e.g., in-band control channel for optical transport=
 networks) in Section 4.


 


[JEH] That=1B$B!G=1B(B=
s OK, thanks.


 


 


s5.2 =1B$B!H=1B(BSupport of PCE-triggered state synchronization is adv=
ertised=1B$B!I=1B(B
– is =
advertised by whom?  Also, I think you mean
=1B$B!H=1B(Bini=
tial state synchronization.=1B$B!I=1B(B  Please rewrite in the active voice (for exa=
mple,
=1B$B!H=1B(BBoth P=
CEP speakers advertise their support of PCE-triggered initial state synchro=
nization during session startup by=1B$B!D!I=1B(B)  Ditto
=1B$B!H=1B(BIf the=
 TRIGGERED-INITIAL-SYNC capability is not advertised=1B$B!I=1B(B ->
=1B$B!H=1B(BIf the=
 PCE has not advertised the TRIGGERED-INITIAL-SYNC capability=1B$B!I=1B(B


s6.2 =1B$B!H=1B(BSupport of PCE-triggered state synchronization is adv=
ertised=1B$B!I=1B(B
– ple=
ase use active voice.


 


[Xian]: Point taken; will=
 be more explicit in the next update.


 <=
/p>

Nits


 


s3.2 para 4: =1B$B!H=1B(Bthe PCE SHOULD ignore it were to receive one<=
span lang=3D"ZH-CN" style=3D"font-family:SimSun">=1B$B!I=1B(B
– I t=
hink you mean 
=1B$B!H=1B(Bthe PCE SHOULD ignore it were it to receive one=1B$B!I=1B(B


 <=
/p>

[Xian]: accepted.<=
o:p>


 
--_000_DM2PR02MB135612125019E2BB959170B884270DM2PR02MB1356namp_-- From nobody Thu Oct 22 09:09:50 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 067161B3982 for ; Thu, 22 Oct 2015 09:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] 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 v29lo-lpEtIo for ; Thu, 22 Oct 2015 09:09:34 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D4491B3994 for ; Thu, 22 Oct 2015 09:09:33 -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 t9MG97Sf002312; Thu, 22 Oct 2015 17:09:07 +0100 Received: from 950129200 ([62.173.23.104]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id t9MG8vuO001984 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 22 Oct 2015 17:09:01 +0100 From: "Adrian Farrel" To: "'Robert Varga'" , "'Dhruv Dhody'" , "'Olivier Dugeon'" , "'Dhruv Dhody'" References: <562761E5.8020302@orange.com> <56279D77.7090701@orange.com> <23CE718903A838468A8B325B80962F9B8C429626@BLREML509-MBX.china.huawei.com> <5628C674.7030906@hq.sk> In-Reply-To: <5628C674.7030906@hq.sk> Date: Thu, 22 Oct 2015 17:08:47 +0100 Message-ID: <03fd01d10ce3$f9652540$ec2f6fc0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03FE_01D10CEC.5B2E4830" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKX2VTJ/o+Id/hJrUuntUF5Yh68cgHfeweKAdfnas4BarHYFwJ4A81lnK1CUHA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-21896.000 X-TM-AS-Result: No--27.223-10.0-31-10 X-imss-scan-details: No--27.223-10.0-31-10 X-TMASE-MatchedRID: Xxz90/Ib/ZhbJCKOm3VRCbYXhr68jbY+uEworDHWZ6bv/Djx8CKFr1dT SKNGq5eT7bzFTf/STMpor4yxPAz7WYfGLZ++QpQzccmoKU9lHiw/H4pb4un6/TUTwzZ6EGbDAmY a7Cmd//8cRhEjx02trrmR+C0l9vjVUAjrAJWsTe8NF4UFTdBj+myX/1vBuVp2ZNUDHbPZ5K1/Lx 6iMAc0GDS0YiQyjCbqQr2qXCJMSV9y4VFP6muDhiNGK7UC7ElMT3TQpiAmIlUyYbGi6vQrCxhe7 AkzOIpcNA4kPXMXcBJH4a2iJdV4Mbtq3FNsoMQgRJWmeOMHa+Rw/+ihHRzmFeFJlfMJdoZdJAM2 0RFs/Ztqmil5cxqvLai4iJ+LRwVc2sEGsaoEZ+UwEhHW5KVAzzfsQwKpJqvCc3XcexRcc5wfANB WEvV8wNZy5qKS93ZaI0cHLI6lhgIF15s6prCIu0klF5L0lQHcZ+M1RPx3UL63gtIv3WABOAVgf1 XK2LQGp8pDLp9CdcKOjIrMSa2sR8LiFiL0BG1uBNbOkII96c0UwYivlc/8grpBWhZD1OEAVXRGX YVNxfxJEm9eDiZf8U0IfQOJvRLRMDmYaN/e0lZwYQF1tiJ1WjoJhoC9wcJdvRhxlI/eWfR1kH68 Hcm2sBnsS71Oo/HwLi5PDX0qWHqC7C2rJeUToRSX1u8BLtZA4GpBZjuLIR72Uyif+nXmW9Xri2O rBiANZB7FaQ6KQ99+7Kf/40Ni0rj0igGiOeKh2b991ey+JifHQGahEVxSmD5TLHtDcbb2QB6GK3 I68kLQ/iDYfR6VyxajTXkge2WQ/AhWqJHNMESbKItl61J/yZUdXE/WGn0FSlnU38LCY8v3vguvm Elg+sxhy2JWmN8lZMcN9p0yql0AUOvmr34kCcDeFF8hvmaebiy6tKP7yws= Archived-At: Cc: pce@ietf.org Subject: Re: [Pce] Questions about PCE Stateful Synchronisation X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 16:09:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03FE_01D10CEC.5B2E4830 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Just to pitch in and agree a bit more. =20 Since we're running PCEP over TCP, the loss of a message appears to be = due to an implementation malfunction. As Dhruv says, this puts PCEP in = the same s BGP. It's true that can implementation glitches can happen = (with some people's code ;-) but consider how BGP spots a route that has = not been advertised and what it does about it. =20 Now, if we are really concerned, we could consider some form of = redundancy check across all LSPs between a PCE and PCC. For example, the = PCE could send a synch summary request, PCC could hash across all LSPs = (using some set of fields) and send the result in a synch summary = response, and the PCE could use this to check whether its set of LSPs = matches those it knows about. If the hash fails the PCE would need to do = a complete resynch because neither it nor the PCC can know which LSPs = are out of synch. =20 However, before doing this, we might like to consider how often this = sort of out of synch condition might occur. =20 Ciao, Adrian -- Read my latest... Tales from the Wood - Eighteen new fairy tales http://www.feedaread.com/books/Tales-from-the-Wood-9781786100924.aspx http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924 Or buy from me direct. =20 =20 =20 From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Robert Varga Sent: 22 October 2015 12:20 To: Dhruv Dhody; Olivier Dugeon; Dhruv Dhody Cc: pce@ietf.org Subject: Re: [Pce] Questions about PCE Stateful Synchronisation =20 Hello, I competely agree with Dhruv. Design goal for stateful extension was to minimize control plane = overhead for the usual case of steady state, so that PCE resources = (which talks typically to many head end nodes) are used towards = resolving failures. This concern was always the first one raised by both = PCE and PCC implementations I talked to. The resynchronization mechanism proposed is meant to be used as a = background maintenance task, which 'scrubs' the TED and takes a back = seat to recovering the network when LSPs churn. This cannot be done if = the PCCs re-publish the same steady state over and over -- for a network = of 1M LSPs with 1 hour refresh that amounts to ~278 PCRpt/s just to = maintain steady state. PCE implementations I have talked to have found = this mechanism sufficient to maintain enough consistency to keep = operating even in face of such bugs not being caught by QA. Anyway, the specification does not prohibit this behavior on PCC part = and if a need arises for the PCE to request this functionality, it can = be negotiated as a separate extension at session startup. Bye, Robert On 10/22/2015 06:58 AM, Dhruv Dhody wrote: Hi Olivier, =20 IMHO PCEP is much closer to BGP (when compared to IGP), and in that = PCE-triggered full re-sync is similar to BGP=E2=80=99s route-refresh = mechanism. So I guess we are re-using a similar concept which scales = well too :) =20 As you also mention that such issue might be seen on a long running = session, this re-sync if needed, would be after a long time.=20 IMHO sending PCRpt repeatedly say at every 3600 secs for all LSP would = be costly too.=20 =20 I will leave it to the authors of the base draft to answer your other = question. In the implementations that I am aware of, that is the local = policy and usually set to report all LSPs. =20 =20 Regards, Dhruv =20 From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Olivier Dugeon Sent: 21 October 2015 19:43 To: Dhruv Dhody Cc: pce@ietf.org Subject: Re: [Pce] Questions about PCE Stateful Synchronisation =20 Hello Dhruv, Thanks pointing me this section, but I read the draft before asking my = questions. For me, it is not completely cover this issue, and my answer = is Yes and No. Yes, because the mechanism allow such re-synchronization without closing = the PCEP session, but at the price of exchanging PCUpd / PCRpt message = when only one PCRpt message is sufficient. It solves the problem of = orphan LSP. In this case, I agree that when the PCE asks to update an = orphan LSP it gets an error (I suppose as it is not specify in the = draft). An No, because it not solves completely the issue if the PCE is not = aware of an LSP. The PCE could not request an update about an LSPs it = ignores.=20 So, the only working solution for the PCE is to ask regularly all PCCs = to send their complete LSP DB to be sure that it is always synchronized, = but it is a very costly mechanism. In addition, I have some doubt that this mechanism scale well. For large = networks, say more then 1000 PE routers, so more than 1000 PCEP = sessions, with a full mesh of TE tunnels (I know it is an extreme case) = this increase drastically the exchange between the PCE and PCCs and add = extra CPU process for the PCE. The later must parse 1,000,000 tunnels in = its LSPs DB and ask PCCs to refresh them. Or, asks all PCCs to update = all their tunnels. In the first case the PCE spent its time to send = PCUpd message waiting for the corresponding PCRpt answer and in the = second case it spent its time to parse 1000 tunnels each time it asks a = PCC for a full refresh. Flood periodically Link State in IGP protocol has proof for a long time = that it scale well even in very large network. Why not re-using a = similar concept ? And, last but not least, what's happen with LSP tunnels that are = configured on router that are not PCEP enable ? There are simply ignored = ? Regards, Olivier Le 21/10/2015 15:01, Dhruv Dhody a =C3=A9crit : Hi Olivier,=20 =20 Wanted to bring "PCE triggered re-syncronization" = [https://tools.ietf.org/html/draft-ietf-pce-stateful-sync-optimizations-0= 3#section-6] to your notice. This can be used by a PCE to periodically = re-synchronize the database without bringing down the PCEP session.=20 =20 Will this not cover the issue you have in mind?=20 =20 Regards, Dhruv =20 =20 On Wed, Oct 21, 2015 at 3:29 PM, Olivier Dugeon = wrote: Dear authors of draft-ietf-pce-stateful and = draft-ietf-pce-stateful-sync-optimizations, I know that we are in the last miles before publish PCE Stateful draft = collection as RFCs, but regarding the chairs' review, I have a global = interrogation about synchronisation. Even I-Ds try to avoid it, I'm = afraid that there will different cases where de-synchronisation is not = avoided between PCCs and PCEs. In particular, in case of problem, not a = real failure, more a bug, memory saturation or whatever mal-function = could occur on the PCE or PCC side, a PCE could miss a PCRpt message = from a PCC or respectively a PCC could miss to send a PCRpt message to a = PCE. I'm also afraid, after a long live period (say, several weeks or = months) that some orphan LSPs appear in the PCE LSPs database without = the possibility to detect them and remove them. To go back in a full sync state, it is then necessary to restart = properly the PCEP session, i.e. force a re-synchronisation. But, to do = that, you need to discover the problem. That's another topic. So, my question is why do you not have use a similar mechanism to = routing protocol, i.e. OSPF, IS-IS or BGP, to periodically send LSPs = state from the PCC to the PCE. Using an 'out of date' indication will = allow the PCE to remove in its LSP-DB 'out of date' LSPs like OSPF do = when it flushes an LSA with ageing equal to 3600 in its TED. What it is sufficient is to add a new statement in = draft-ietf-pce-stateful (e.g., in section 9.1. Control Function and = Policy) telling that: - the PCC MUST send PCRpt message on a regular basis, before MAX_AGE = expire. - the PCE MUST ignore LSPs that are not refresh since a period of time = greater than MAX_AGE. Then, two cases are possible: a) MAX_AGE is fixed in the RFC e.g. to 3600 seconds like in OSPF (seems = reasonable) b) Negotiate/exchange during PCEP session establishment or when PCRpt = message is sent If option (a) is quiet simple but not flexible, it has the great = advantage to not introduce new PCEP Object while option (b) need new = PCEP Object definition, but provide a greater flexibility. If we agree on the statement above, I think that option (a) is = sufficient and just need additional text in current draft while if we = want to support option (b), I could work on a new draft. Regards, Olivier --=20 logo Orange Olivier Dugeon Orange Expert, Future Networks Open Source Referent Orange/IMT/OLN/WTC/IEE/OPEN fixe : +33 2 96 05 28 80 mobile : +33 6 82 90 37 85 olivier.dugeon@orange.com _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce =20 =20 _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce =20 ------=_NextPart_000_03FE_01D10CEC.5B2E4830 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Just to pitch in and agree a = bit more.

 

Since we're running PCEP over = TCP, the loss of a message appears to be due to an implementation = malfunction. As Dhruv says, this puts PCEP in the same s BGP. It's true = that can implementation glitches can happen (with some people's code ;-) = but consider how BGP spots a route that has not been advertised and what = it does about it.

 

Now, if we are really = concerned, we could consider some form of redundancy check across all = LSPs between a PCE and PCC. For example, the PCE could send a synch = summary request, PCC could hash across all LSPs (using some set of = fields) and send the result in a synch summary response, and the PCE = could use this to check whether its set of LSPs matches those it knows = about. If the hash fails the PCE would need to do a complete resynch = because neither it nor the PCC can know which LSPs are out of = synch.

 

However, before doing this, we = might like to consider how often this sort of out of synch condition = might occur.

 

Ciao,

Adrian

--

Read my = latest...

Tales from the Wood - Eighteen = new fairy tales

http://www.feedaread.com/books/Tal= es-from-the-Wood-9781786100924.aspx

http://www.amazon.co.uk/Tales-Wood= -Adrian-Farrel/dp/1786100924

Or buy from me = direct.

 

 

 

From: = Pce [mailto:pce-bounces@ietf.org] On Behalf Of Robert = Varga
Sent: 22 October 2015 12:20
To: Dhruv Dhody; = Olivier Dugeon; Dhruv Dhody
Cc: = pce@ietf.org
Subject: Re: [Pce] Questions about PCE Stateful = Synchronisation

 

Hello,

I = competely agree with Dhruv.

Design goal for stateful extension = was to minimize control plane overhead for the usual case of steady = state, so that PCE resources (which talks typically to many head end = nodes) are used towards resolving failures. This concern was always the = first one raised by both PCE and PCC implementations I talked = to.

The resynchronization mechanism proposed is meant to be used = as a background maintenance task, which 'scrubs' the TED and takes a = back seat to recovering the network when LSPs churn. This cannot be done = if the PCCs re-publish the same steady state over and over -- for a = network of 1M LSPs with 1 hour refresh that amounts to ~278 PCRpt/s just = to maintain steady state. PCE implementations I have talked to have = found this mechanism sufficient to maintain enough consistency to keep = operating even in face of such bugs not being caught by = QA.

Anyway, the specification does not prohibit this behavior on = PCC part and if a need arises for the PCE to request this functionality, = it can be negotiated as a separate extension at session = startup.

Bye,
Robert

On 10/22/2015 06:58 AM, Dhruv = Dhody wrote:

Hi = Olivier,

 

IMHO PCEP is much = closer to BGP (when compared to IGP), and in that PCE-triggered full = re-sync is similar to BGP=E2=80=99s route-refresh mechanism. So I guess = we are re-using a similar concept which scales well too = :)

 

As you also mention = that such issue might be seen on a long running session, this re-sync if = needed, would be after a long time.

IMHO sending PCRpt = repeatedly say at every 3600 secs for all LSP would be costly too. =

 

I will leave it to = the authors of the base draft to answer your other question. In the = implementations that I am aware of, that is the local policy and usually = set to report all LSPs.  

 

Regards,

Dhruv

 

From: Pce [mailto:pce-bounces@ietf.org] = On Behalf Of Olivier Dugeon
Sent: 21 October 2015 = 19:43
To: Dhruv Dhody
Cc: pce@ietf.org
Subject: Re: = [Pce] Questions about PCE Stateful = Synchronisation

 

Hello Dhruv,

Thanks = pointing me this section, but I read the draft before asking my = questions. For me, it is not completely cover this issue, and my answer = is Yes and No.

Yes, because the mechanism allow such = re-synchronization without closing the PCEP session, but at the price of = exchanging PCUpd / PCRpt message when only one PCRpt message is = sufficient. It solves the problem of orphan LSP. In this case, I agree = that when the PCE asks to update an orphan LSP it gets an error (I = suppose as it is not specify in the draft).

An No, because it not = solves completely the issue if the PCE is not aware of an LSP. The PCE = could not request an update about an LSPs it ignores.

So, the = only working solution for the PCE is to ask regularly all PCCs to send = their complete LSP DB to be sure that it is always synchronized, but it = is a very costly mechanism.

In addition, I have some doubt that = this mechanism scale well. For large networks, say more then 1000 PE = routers, so more than 1000 PCEP sessions, with a full mesh of TE tunnels = (I know it is an extreme case) this increase drastically the exchange = between the PCE and PCCs and add extra CPU process for the PCE. The = later must parse 1,000,000 tunnels in its LSPs DB and ask PCCs to = refresh them. Or, asks all PCCs to update all their tunnels. In the = first case the PCE spent its time to send PCUpd message waiting for the = corresponding PCRpt answer and in the second case it spent its time to = parse 1000 tunnels each time it asks a PCC for a full = refresh.

Flood periodically Link State in IGP protocol has proof = for a long time that it scale well even in very large network. Why not = re-using a similar concept ?

And, last but not least, what's = happen with LSP tunnels that are configured on router that are not PCEP = enable ? There are simply ignored = ?

Regards,

Olivier

Le 21/10/2015 15:01, Dhruv Dhody a = =C3=A9crit :

Hi Olivier, 

 

Wanted to bring "PCE triggered = re-syncronization" [https://tools.ietf.org/html/draft-ietf-pce-stateful-s= ync-optimizations-03#section-6] to your notice. This can be used by = a PCE to periodically re-synchronize the database without bringing down = the PCEP session. 

 

Will this not cover the issue you have in = mind? 

 

Regards,

Dhruv

 

 

On Wed, = Oct 21, 2015 at 3:29 PM, Olivier Dugeon <olivier.dugeon@orange.com> = wrote:

Dear authors of = draft-ietf-pce-stateful and = draft-ietf-pce-stateful-sync-optimizations,

I know that we are in = the last miles before publish PCE Stateful draft collection as RFCs, but = regarding the chairs' review, I have a global interrogation about = synchronisation. Even I-Ds try to avoid it, I'm afraid that there will = different cases where de-synchronisation is not avoided between PCCs and = PCEs. In particular, in case of problem, not a real failure, more a bug, = memory saturation or whatever mal-function could occur on the PCE or PCC = side, a PCE could miss a PCRpt message from a PCC or respectively a PCC = could miss to send a PCRpt message to a PCE. I'm also afraid, after a = long live period (say, several weeks or months) that some orphan LSPs = appear in the PCE LSPs database without the possibility to detect them = and remove them.

To go back in a full sync state, it is then = necessary to restart properly the PCEP session, i.e. force a = re-synchronisation. But, to do that, you need to discover the problem. = That's another topic.

So, my question is why do you not have use = a similar mechanism to routing protocol, i.e. OSPF, IS-IS or BGP, to = periodically send LSPs state from the PCC to the PCE. Using an 'out of = date' indication will allow the PCE to remove in its LSP-DB 'out of = date' LSPs like OSPF do when it flushes an LSA with ageing equal to 3600 = in its TED.

What it is sufficient is to add a new statement in = draft-ietf-pce-stateful (e.g., in section 9.1.  Control Function = and Policy) telling that:
 - the PCC MUST send PCRpt message on = a regular basis, before MAX_AGE expire.
 - the PCE MUST ignore = LSPs that are not refresh since a period of time greater than = MAX_AGE.

Then, two cases are possible:
 a) MAX_AGE is = fixed in the RFC e.g. to 3600 seconds like in OSPF (seems = reasonable)
 b) Negotiate/exchange during PCEP session = establishment or when PCRpt message is sent

If option (a) is = quiet simple but not flexible, it has the great advantage to not = introduce new PCEP Object while option (b) need new PCEP Object = definition, but provide a greater flexibility.

If we agree on the = statement above,  I think that option (a) is sufficient and just = need additional text in current draft while if we want to support option = (b), I could work on a new draft.

Regards,

Olivier
-- =
logo Orange <http://www.orange.com>

Olivier = Dugeon
Orange Expert, Future Networks
Open Source = Referent
Orange/IMT/OLN/WTC/IEE/OPEN

fixe : +33 2 96 05 28 = 80
mobile : +33 6 82 90 37 85
olivier.dugeon@orange.com <mailto:olivier.dugeon@orange.com>

______________= _________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

 

 




_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/m=
ailman/listinfo/pce

 

------=_NextPart_000_03FE_01D10CEC.5B2E4830-- From nobody Sun Oct 25 06:08:07 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505DA1B2E8B; Sun, 25 Oct 2015 06:08:05 -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 oIOt50TzDRfP; Sun, 25 Oct 2015 06:08:03 -0700 (PDT) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 305A91B2E89; Sun, 25 Oct 2015 06:08:03 -0700 (PDT) Received: by igdg1 with SMTP id g1so42854544igd.1; Sun, 25 Oct 2015 06:08:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=LH1JEBboPOvqIxl8fUcX/6zz4+n2hMO1j8KjJBhxZQ8=; b=Dfgggw4Ad/Z3xwWjEOtflRf/XBnlxhCNK8fe8sMtRrvbcuBCT5IBpf+WT044rBiG4b 0AaDrVrdL/7Pyw223AOc4BU4a1iWnqrik4fUu5Iz6uLqRv3y4tB52dsfuvVgSd/oHDNB GRo7bAveDx+smIcehn4wFA5vEcndx0g4GVXwRTMqQE43EVE6wnc5zuW+Opt/jw2zO/6h JpusUmvoV4gaW7GkLIjYNN7q14RJMk2rdvuO3eHWKZwQ2FanT5ObFKI79B3oZnBLUmvk d6nBn53VbfVs9ojYDU6z3TrzoOyOCAy0htnJEAAlTW8X51WhA6TA5gBJrpMYUXIhGIKf N51w== MIME-Version: 1.0 X-Received: by 10.50.62.110 with SMTP id x14mr12717888igr.33.1445778482403; Sun, 25 Oct 2015 06:08:02 -0700 (PDT) Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.27.106 with HTTP; Sun, 25 Oct 2015 06:08:02 -0700 (PDT) In-Reply-To: <5628C89B.3000404@hq.sk> References: <23CE718903A838468A8B325B80962F9B8C421A83@BLREML509-MBX.china.huawei.com> <5628C89B.3000404@hq.sk> Date: Sun, 25 Oct 2015 18:38:02 +0530 X-Google-Sender-Auth: 98xF3ZKffH_He4wfRTB1m9rF3fE Message-ID: From: Dhruv Dhody To: Robert Varga Content-Type: multipart/alternative; boundary=047d7bdc15b8de1e1b0522ed8876 Archived-At: Cc: "pce@ietf.org" , "pce-chairs@tools.ietf.org" , "draft-ietf-pce-stateful-pce@tools.ietf.org" , "draft-ietf-pce-segment-routing@ietf.org" Subject: Re: [Pce] Query on Usage of LSP Identifier TLV in SR X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2015 13:08:05 -0000 --047d7bdc15b8de1e1b0522ed8876 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Robert, I agree, can the SR draft authors confirm (and make an update in the next revision)? Regards, Dhruv On Thu, Oct 22, 2015 at 4:59 PM, Robert Varga wrote: > On 10/12/2015 07:58 AM, Dhruv Dhody wrote: > > Hi Authors, > > > > In the stateful PCE draft [1], it says =E2=80=93 > > The LSP Identifiers TLV MUST be included in the LSP object in PCRpt > > messages for RSVP-signaled LSPs. > > > > The SR draft [2] did not mention anything about LSP Identifier TLV. > > And in implementations that I am aware of, SR-TE LSP still uses the > LSP-Identifier TLV. Is that correct? (I personally think so!!) > > > > If yes, do you think there is a need to update =E2=80=93 > > - [1] to say all LSPs (and not just RSVP-signaled). > > - Or [2] to say that LSP-Identifier TLV are also applicable to SR > and MUST be included. > > > > > The wording in stateful draft is meant to proscribe behavior for RSVP (as > that is what RFC5440 assumes), while allowing different setup mechanisms = ( > https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-setup-type/) specify > their own LSP identifier format. > > In this spirit I think the SR draft should be updated to explicitly state > that SR reuses the same identifier format as RSVP (or whatever is > appropriate). > > Bye, > Robert > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > --047d7bdc15b8de1e1b0522ed8876 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Robert,=C2=A0

I agree, can the SR draft authors confirm (and make an upda= te in the next revision)?=C2=A0

= Regards,
Dhruv

On Thu, Oct 22, 2015 at 4:59 PM, Robert Varga <nite@hq.sk> wrote:
=20 =20 =20
On 10/12/2015 07:58 AM, Dhruv Dhody wrote:
=20 =20 =20

Hi Authors,

=C2=A0

In the stateful PCE draft [1], it says =E2=80=93

The LSP Identifiers TLV MUST be included in the LSP object in PCRpt

messages for RSVP-signaled LSPs.

=C2=A0

The SR draft [2] did not mention anything about LSP Identifier TLV.

And in implementations that I am aware of, SR-TE LSP still uses the LSP-Identifier TLV. Is that correct? (I personally think so!!)=

=C2=A0

If yes, do you think there is a need to update =E2=80=93

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [1] to say all LSPs (and not just RSVP-signaled).

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Or [2] to say that LSP-Identifier TLV are also applicable to SR and MUST be included.

=C2=A0


 The wording in stateful draft is meant to proscribe behavior for RSVP (as that is what RFC5440 assumes), while allowing different setup mechanisms (https://datatracker.ietf.org/doc/draft-ietf-pce-lsp= -setup-type/) specify their own LSP identifier format.

In this spirit I think the SR draft should be updated to explicitly state that SR reuses the same identifier format as RSVP (or whatever is appropriate).

Bye,
Robert


_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce


--047d7bdc15b8de1e1b0522ed8876-- From nobody Mon Oct 26 02:10:11 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9B11B3933; Mon, 26 Oct 2015 02:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 5pBYfH-5uOvf; Mon, 26 Oct 2015 02:10:07 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E7AE1B392A; Mon, 26 Oct 2015 02:10:06 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BZH03393; Mon, 26 Oct 2015 09:10:04 +0000 (GMT) Received: from SZXEML425-HUB.china.huawei.com (10.82.67.180) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 26 Oct 2015 09:10:02 +0000 Received: from szxeml561-mbx.china.huawei.com ([169.254.5.196]) by szxeml425-hub.china.huawei.com ([10.82.67.180]) with mapi id 14.03.0235.001; Mon, 26 Oct 2015 17:09:04 +0800 From: Venugopal Reddy K To: "draft-dhody-pce-stateful-pce-auto-bandwidth@ietf.org" , pce Thread-Topic: Few queries regarding draft-dhody-pce-stateful-pce-auto-bandwidth-06 draft Thread-Index: AdEPzfMTZejSeas9TDmsv5D0lyT51Q== Date: Mon, 26 Oct 2015 09:09:03 +0000 Message-ID: <10376B02BC561F4185654159EF7900204FCA1956@szxeml561-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.245.112] Content-Type: multipart/alternative; boundary="_000_10376B02BC561F4185654159EF7900204FCA1956szxeml561mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Pce] Few queries regarding draft-dhody-pce-stateful-pce-auto-bandwidth-06 draft X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2015 09:10:10 -0000 --_000_10376B02BC561F4185654159EF7900204FCA1956szxeml561mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Authors, I have few queries regarding draft-dhody-pce-stateful-pce-auto-bandwidth-06= . 1. We have Overflow-Count, Overflow-Threshold and Underflow-Count, Un= derflow-Threshold to expedite the process of PCC adjusting the bandwidth in= stead of waiting for Adjustment-Interval when an abrupt change in bandwidth= usage occurs. Similarly, we have Report-Flow-Threshold value for a PCC to = report for PCE adjusting bandwidth model instead of waiting for Report-Inte= rval. Can we know if there is rationale behind having different method for = PCC controlling bandwidth adjustment and PCE controlling bandwidth adjustme= nt for this case? Why not have the similar mechanism for it ? 2. Once auto-bandwidth adjustment is enabled for an LSP, Couldn't fin= d any way to disable auto adjustment feature for an LSP. It would be good t= o have a means to disable adjustment without bringing the LSP down. Also, = changing auto-bandwidth adjustment mode from PCC to PCE or vice versa witho= ut LSP down. Could you please clarify. Thanks :) Regards, Venu --_000_10376B02BC561F4185654159EF7900204FCA1956szxeml561mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Authors,

 

I have few queries regarding draft-dhody-pce-statefu= l-pce-auto-bandwidth-06.

 

1.     &= nbsp; We have Overflow-Count, Overflow-Threshold and Unde= rflow-Count, Underflow-Threshold to expedite the process of PCC adjusting t= he bandwidth instead of waiting for Adjustment-Interval when an abrupt chan= ge in bandwidth usage occurs. Similarly, we have Report-Flow-Threshold value for a PCC to report for PCE adjusting = bandwidth model instead of waiting for Report-Interval. Can we know if ther= e is rationale behind having different method for PCC controlling bandwidth= adjustment and PCE controlling bandwidth adjustment for this case? Why not have the similar mechanism for= it ?

 

2.     &= nbsp; Once auto-bandwidth adjustment is enabled for an LS= P, Couldn’t find any way to disable auto adjustment feature for an LS= P. It would be good to have a means to disable adjustment without bringing = the LSP down.  Also, changing auto-bandwidth adjustment mode from PCC to PCE or vice versa without LSP down.=

 

Could you please clarify.

 

Thanks J

 

Regards,

Venu

--_000_10376B02BC561F4185654159EF7900204FCA1956szxeml561mbxchi_-- From nobody Mon Oct 26 14:11:07 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BEB61A1A7F for ; Mon, 26 Oct 2015 14:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 2qCxfjDFNnuD for ; Mon, 26 Oct 2015 14:11:01 -0700 (PDT) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E83241A1A86 for ; Mon, 26 Oct 2015 14:11:00 -0700 (PDT) Received: by ykba4 with SMTP id a4so191857231ykb.3 for ; Mon, 26 Oct 2015 14:11:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3Kw5xhz6QsqvcLNW9vDMxu1EcMBr4LLaNkG39aO+qKk=; b=nrImvffziXZuGTYtuuUNFPUQrMMHE5J6R3YDOpYgvlnxTykqLUaZwOFzWJSNhmt2gf rK934th6K24yySG8w/WdjPD3Z5WN4NjVRQx1iej/5Aah2bc/C8wRIEJmpL31u0dz/St/ gXqC/E0caTS/Td+Nj7e54AJO1P7OlxWpzaMMdiUjPlqsYjpyw9EW+AYxGHYtR88/GGTP oUflZfCVlAiaOJRVWC5xQNk4wg7GgxYAzNZEin4yz9627PtCWeK7GnYnSD2deuDGY/C4 Wpc76KWca1iQS9p8m1qihaWkuUNqv+m/b152NheCpFy/U8gQpJJ+vCYizjqNgS4lQt5j mVrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3Kw5xhz6QsqvcLNW9vDMxu1EcMBr4LLaNkG39aO+qKk=; b=EJCCRBP31cgwGo/ZoBH7+eRQEhjfYJcxdJeIVypgY0X+OIRlC2bSe04cXPoAU+b+hS JUavm+fXhrhY4ktFsiO0QvuEjSmRkUk+kvFGL2uyqoGBzNfBYRttcZBnK3q+rI2CtmSP Xn2C3b8dAERPyYQV06nwyoA0TR8vB7X03FE4dQUoIUy700hGw1BVlr03HlZ4disTTTzK Lyaj3LrTwwIX9g1THG/m6KdWsKm7Gq55C+DJzk6/Ibt6VwzdFowaiArOgHR0GsKOU7XM 4AeFLcsNefyY/fS2BYRpUYmElG+cuCsPAodNzAVXmr8mt6DiItDHvV93otTBtt3jLvCH o3vQ== X-Gm-Message-State: ALoCoQmEx6BF48M+E8dvgKZipUEJXbbHJ2fSmWQlJhdW3r6w6OWk/qVwUqE9SWGREjesIjyOhNFL MIME-Version: 1.0 X-Received: by 10.129.109.215 with SMTP id i206mr22734956ywc.50.1445893860010; Mon, 26 Oct 2015 14:11:00 -0700 (PDT) Received: by 10.37.107.195 with HTTP; Mon, 26 Oct 2015 14:10:59 -0700 (PDT) In-Reply-To: <56210C68.1080904@orange.com> References: <56210C68.1080904@orange.com> Date: Mon, 26 Oct 2015 14:10:59 -0700 Message-ID: From: Ina Minei To: Julien Meuric Content-Type: multipart/alternative; boundary=001a114dcae6e8f94a05230865b3 Archived-At: Cc: draft-ietf-pce-stateful-pce@ietf.org, "pce@ietf.org" Subject: Re: [Pce] Chair's Review of draft-ietf-pce-stateful-pce-11 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2015 21:11:06 -0000 --001a114dcae6e8f94a05230865b3 Content-Type: text/plain; charset=UTF-8 Julien, Thank you for the detailed review, please find answers inline below ###. I have incorporated the overwhelming majority of the comments, explained the reason for not incorporating a couple of them, and am still working with the co-authors on a couple of items marked "pending", which we will close on shortly. Two questions and one ask 1. Forward references to SRP object and SRP-ID - there are several in the comments, though the relevant section is always mentioned. How should such forward references be addressed? 2. Section 7 - s/defined in this document/defined in that (aforementioned) document/ The comment was not clear to me. The intention is for the flags to be set as explained for the new objects we are defining here, can you clarify the comment? 3. Can you please review the comments that were not incorporated and let us know if you agree? Thank you, Ina On Fri, Oct 16, 2015 at 7:40 AM, Julien Meuric wrote: > Dear authors, > > To prepare the upcoming move to the IESG, please find below my review of > the aforementioned I-D (at last!). > > _Summary_ > > Main qualities: > - core specification is clear; > - wording is smooth, with very few typos; > - the manageability and security sections have been included with relevant > text. > Main issues to point out: > - RFC 2119 keywords (picky me, but so is the IESG: ask JP about 5440); > - a few corner/error cases; > - consistency with existing RFCs (5440, 5886). > I also take the opportunity to remind the WG that including codepoint > values from existing registries before allocation by the IANA (which can be > requested early) is a very bad idea, whatever the WG. > > _Detailed Comments_ > ------ > Header > --- > - The blank line after Ed's name looks strange. If no affiliation is > wanted, his name may be moved to the bottom of the list, to avoid > association with one of the listed companies. Otherwise, you may use a > generic phrase, e.g. "Individual Contributor". > ### Done > ------ > Section 1 > --- > - s/Path Computation Element Protocol/Path Computation Element > communication Protocol/ > ### Done > ------ > Section 2 > --- > - "LSP", properly expended in the introduction, should be added somewhere > (all the more as IS-IS is mentioned a few times). > ### Added in terminology, with reference to 3031. > - s/Stateful PCE: has/Stateful PCE: a PCE that has/ > - s/Passive Stateful PCE: uses/Passive Stateful PCE: a stateful PCE that > uses/ > ### Done > - s/Active Stateful PCE: is an extension/Active Stateful PCE: an extension/ > ### Replaced as "an Active Stateful PCE that may issue recommendations... - s/Delegation: An/Delegation: an/ > - s/PCC who owns/PCC which owns/ > - s/PCC SHOULD be/PCC should be/ > - s/Revocation: An/Revocation: an/ > ### Done > > - OLD > Redelegation Timeout Interval: when a PCEP session is terminated, a PCC > waits for this time period before revoking LSP delegation to a PCE and > attempting to redelegate LSPs associated with the terminated PCEP session > to an alternate PCE. > NEW > Redelegation Timeout Interval: the period of time a PCE waits for, when a > PCEP session is terminated, before revoking LSP delegation to a PCE and > attempting to redelegate LSPs associated with the terminated PCEP session > to an alternate PCE. > ### Done > > - OLD > State Timeout Interval: when a PCEP session is terminated, a PCC waits for > this time period before flushing LSP state associated with that PCEP > session and reverting to operator-defined default parameters or behaviors. > NEW > State Timeout Interval: the period of time a PCE waits for, when a PCEP > session is terminated, before flushing LSP state associated with that PCEP > session and reverting to operator-defined default parameters or behaviors. > ### Done > - OLD > Within this document, PCE-PCE communications are described by having the > requesting PCE fill the role of a PCC. This provides a saving in > documentation without loss of function. > NEW > Within this document, PCEP communications are described through PCC-PCE > relationship. The PCE architecture also supports the PCE-PCE communication, > by having the requesting PCE fill the role of a PCC, as usual. > ### Done > ------ > Section 3 > --- > - Section 3.1.3 includes 2 paragraphs "Scale and Performance": they should > either be merged, or the old text version should be dropped. > ### Done, new text below: o Scale & Performance: configuration operations often have transactional semantics which are typically heavyweight and often require processing of additional configuration portions beyond the state being directly acted upon, with corresponding cost in CPU cycles, negatively impacting both PCC stability LSP update rate capacity. > - s/which prevents interoperability of a PCE/which limits interoperability > of a stateful PCE/ > - s/the same PCEP./the same protocol, i.e., PCEP./ > ### done > ------ > Section 4 > --- > - s/A PCE requests/a PCE requests/ > ### Done > - The reference to draft-sivabalan-pce-disco-stateful makes the reader > wonder why is is not part of draft-ietf-pce-stateful-pce itself. Besides, > Table 1 also mentions IS-IS and OSPF PCE-CAP-FLAGS sub-TLV, only the > allocation section seems to be missing here. Would you talk to the authors > (some being common to both I-Ds) of the former to consider using their > material as a contribution? A separate document is quite an overhead for > allocating 2 bits. > ### I don't think discovery should be part of the base draft. Several reasons: a) 5440 does not include discovery, b) the base spec is already quite large, we want to keep only the core function and c) the discovery draft is expired. I cleaned up table 1 and added the following text instead of the reference to the draft: Old text [I-D.sivabalan-pce-disco-stateful] defines the extensions needed to support autodiscovery of stateful PCEs when using OSPF ([RFC5088]) or IS-IS ([RFC5089]) for PCE discovery. New text Similarly to [RFC5440], no assumption is made about the discovery method used by a PCC to discover a set of PCEs (e.g., via static configuration or dynamic discovery) and on the algorithm used to select a PCE. Extensions needed to support autodiscovery will be defined in a separate document. ------ > Section 5 > --- > - s/In the PCEP protocol/In PCEP/ > - s/The PCEP protocol extensions/The PCEP extensions/ > - s/by the operator through/by the operator, e.g., through/ > - "PCRpt message can contain": what about "s/can/MAY/"? > - s/ISIS/IS-IS/ > - s/The PCEP protocol extensions/The PCEP extensions/ > - s/it SHOULD generate a PCErr/it MUST generate a PCErr/ [twice] > ### Done > - s/it will terminate/it MUST\SHOULD terminate/ [twice] > ### I replaced with SHOULD > - s/in this document MAY/in this document may/ > - s/SHOULD be generated/MUST be generated/ > - s/PCE can still receive/PCE can still accept/ > ### Done > - PLSP-ID is used, while not yet defined nor expended. > ### Added reference > - s/include an empty ERO/include an empty RRO/ [Along with RFC 5440 > (section 7.10), the object sent by a PCC to report to a PCE is an RRO: let > us keep it consistent.] ### XXX Pending > - s/in its path/for its path/ [or "as its path"?] > ### Done > - Avoiding "positive acknowledgements for properly received > synchronization messages" has scalability benefits in normal situations, > but the PCC is blind and may keep on sending PCRpt to dead processes behind > up PCEP sessions. Have you consider acknowledgement, possibly using a > compression mechanism like the one defined later in the I-D? > ### XXX Pending > - When mentioning errors, adding a sentence reminding that RFC 5440 > already defines a set of applicable error codes would be valuable. > ### XXX Pending > - The sentence about "delegation policy" in section 5.5 is not protocol > specification and should be moved to section 9.1 ("Control Function and > Policy"). > ### Done. Good point, moved. > - s/PCE may return/PCE MAY return/ > - s/PCE may revoke/PCE MAY revoke/ > - s/PCC should react/PCC SHOULD react/ [?] > ### Done > - In section 5.5.1, it is not clear if an empty LSP Update Request with a > Delegate flag to 1 is an acceptable way for a PCE to send a delegation > acknowledgement: to be clarified. > ### XXX Pending > - Section 5.5.1 has a significant break in the middle, it would deserve > subsections: e.g., "5.5.2.1 Revoking Explicitly" and "5.5.2.2. Revoking on > Timeout" right before "When a PCC's PCEP session with a PCE terminates > unexpectedly...". > ### Done > - s/the PCC SHALL flush/the PCC MUST flush/ [correct, but single instance > of SHALL in the I-D] > ### Done > - Current text says "The State Timeout Interval SHOULD be greater than or > equal to the Redelegation Timeout Interval", but the I-D assumes "MUST": if > "MUST" is avoided on purpose, then some text should be added for cases not > falling under that "SHOULD". > ### Done > - s/SHOULD return the LSP delegation/MUST return the LSP delegation/ > ### This should remain SHOULD. The nice way to do it is to return it explicitly, but it may choose to wait until the next update and return the delegation then by not setting the delegate flag. > - In section 5.5.3, assuming an LSP was delegated, does the reception by > the PCC of a non empty LSP Update Request with a Delegate Flag to 0 trigger > an error? > ### XXX Pending > - s/to be larger/to be greater/ > ### Done - s/as recommended/as RECOMMENDED/ or s/as recommended/as MANDATORY/ > [depending on the SHOULD/MUST selected above] > ### Done - At the top of page 18, "and [assuming that] PCEs' decisions are the same" > should be added. > ### The comment is not clear - I am assuming you refer to the text "assuming that the state timeout... ' on page 17, changed to: " and assuming that the primary and redundant PCEs take similar decisions, this" > - Again, in section 5.5.5, 4th paragraph, after "there will be no change > in LSP state", "if similar PCEs' decisions" should be added. > ### Done "and assuming that the standby PCE takes similar decisions as the failed PCE" > - s/is larger than/is greater than/ > - Section 5.6 requires more RFC 2119 keywords, only a few of them are > suggested below. > - s/For each LSP, it sends/For each LSP, it MAY send/ > - s/could not be set up, the PCC sends/could not be set up, the PCC MUST > send/ > - s/it also sends/it SHOULD also send/ > - s/A PCC sends each LSP State Report/A PCC MUST send each LSP State > Report/ > ### Done > - In section 5.6.2, in case of new LSP, the very first message sent by the > PCC aims at getting a path. This is clearly the role of a PCReq message, > and the I-D extends it to support the LSP object including the delegation > flag (section 7.3). However, Figure 8 treats a new LSP the same way as > reporting an existing LSP, i.e., using a PCRpt message. In this case, there > is an overlap between PCReq and PCRpt, which MUST be resolved because > interoperability is at stake. Documenting the delegation of a new LSP > deserves some new text and possibly figure, the overlapping specification > of the PCRpt should be explicitly precluded. > ### This is historical confusion in the figure, from the time when initiation was rolled up in the same document. I modified the figure so it is clear this is for updating parameters only. > - s/existing LSPs) and LSPs have/existing LSPs). After LSPs have/ > - s/For each LSP, it sends/For each LSP, it MAY send/ > - s/LSP is up, the PCC sends/LSP is up, the PCC MUST send/ > - s/be set up, the PCC sends/be set up, the PCC MUST send/ > - s/PCC may choose to compress LSP State/PCC MAY compress LSP State/ > - s/A PCC sends each LSP State/A PCC MUST send each LSP state/ > ### Done > - At the end of section 5.6, "SRP-ID-number" is used but not yet defined. > At least, SRP should be expended. > ### It was referenced and explained earlier in 5.6. > - s/PCC may choose to compress state/PCC MAY compress state/ > - s/the earlier updates/the updates with lower SRP-ID-number/ [Noting that > it assumes that the value is incrementing, which is documented only later, > in section 7.2.] > ### Added reference > - s/in a separate draft/in a separate document/ > - s/Transport/PCEP Sessions/ > ### Done > ------ > Section 6 > --- > - The terms "mandatory" and "optional" are introduced, but barely used > then. It would be better to stick to RFC 2119 keywords (e.g., "REQUIRED" > and "OPTIONAL") and actually use them for each object. > - The object ordering is defined as mandatory: unfortunately, that would > be inconsistent with previous PCEP extensions. I suggest to either drop > that sentence, or at least downgrade to a "SHOULD" as a trade-off. > ### Done. > - s/// [Per RFC 5440, a report > from PCC to PCE is RRO.] > ### XXX Pending > - The need for the optional xRO is not well documented. Its proper naming > will depend on the associated use that must be clarified. > - "SRP" is still not defined. > ### Isn't it enough to reference the section in which it is defined? > - s/is optional/is OPTIONAL/ > - s/the latest one/the one with the highest ID-number/ > - s/is mandatory/is REQUIRED/ > ### Done > - The use of the optional xRO is mentioned, but its relationship with the > RRO (formerly ERO) is not clear. I suspect some assumptions are made on the > way the ERO/RRO are populated; RFC 5440 only says ERO for PCE->PCC and RRO > for PCC->PCE. > ### XXX Pending > - s/included by the PCC/inlcuded in PCRpt by the PCC/ > ### Done > - The behavior associated to the resource limit per PCC rather looks like > a Notifcation than an Error (e.g., in RFC 5440, cancelling a set of pending > requests relies on PCNtf). Please consider the use of Notification instead > of Error here. > ### XXX Pending > - s/that the PCE associates/that the PCC associates/ > - s/next LSP. If the PCUpd/next LSP.If the PCUpd/ > ------ > ### Done > Section 7 > --- > - s/defined in this document/defined in that (aforementioned) document/ > ### Unclear comment, the intention was for the flags to be set as explained for the new objects in this document, not for anything in 5440. > - s/SHOULD always be/MUST be/ > - s/one SPR-id-number/one SRP-ID-number/ > - s/SRP-ID/SRP-ID-number/ [3 times] > - s/allocated it/allocated to it/ > - s/Flags (12 bits):/Flags (12 bits), starting from the least significant > bit:/ > ### Done > - s/on a PCRpt message/On a PCRpt or PCReq message/ > ### We don't support delegation through a PCReq message > - s/the S flag/The S flag/ > - s/in other PCRpt messages/in other messages/ > ### Done > - "PCE SHOULD remove all state" is written 3 times: I wonder about "MUST". > ### SHOULD is the correct operation, the PCE is free to choose to keep state around for as long as it wishes. The 3 removal statements refer to different scenarios. > - s/LSP Identifiers/LSP-IDENTIFIERS/ [4 or 5 times] > ### Done > - Texts associated with object definition are incomplete, they rely too > much on figures. For example: > * s/The type of the TLV/The type (16 bits) of the TLV/ [5 times] * s/IANA and it has a fixed length of/IANA. The length field is 16 > bit-long and has a fixed value of/ [3 times] > * s/IANA and it has a variable length/IANA. The length field is 16 > bit-long and has a variable value/ [2 times] > ### Done - s/in l following/in the following/ > ### Done - The paragraph "However, when Gobal Path Protection... (or vice versa)" is > not IPv6 specific and should be moved to the end of section 7.3.1. > ### Done. Also added a MUST keyword > - s/a path's lifetime/an LSP's lifetime/ > ### Done > - It would be nice to elaborate on the reason why the SYMBOLIC-PATH-NAME > MUST be included and not SHOULD. > - I do not see why SYMBOLIC-PATH-NAME may be included in SRP Object: > defining the LSP Object as its single place seems enough and much simpler. > ### XXX Pending > ------ > Section 8 > --- > - OLD > This document requests that a registry is created to manage the Flags > field of the LSP object. > NEW > This document requests that a new sub-registry, named "LSP ObjectFlag > Field", is created within the "Path Computation Element Protocol (PCEP) > Numbers" registry to manage the Flag field of the LSP object. > ### Done > > - either s/Error-value=9: ERO Object/Error-value=9: xRO Object/ or add an > Error-Value for RRO. > ### Done > - As mentioned above, in Error-Type 19, Error-value 4 should be considered > in a PCNtf. > ### XXX Pending > > - OLD > This document requests that a registry is created to manage the Flags > field in the STATEFUL-PCE-CAPABILITY TLV in the OPEN object. > NEW > This document requests that a new sub-registry, named > "STATEFUL-PCE-CAPABILITY TLVFlag Field", is created within the "Path > Computation Element Protocol (PCEP) Numbers" registry to manage the Flag > field in the STATEFUL-PCE-CAPABILITY TLV of the PCEP OPEN object (class = > 1). > ### Done > > - OLD > This document requests that a registry is created to manage the value of > the LSP error code field in this TLV. > NEW > This document requests that a new sub-registry, named "LSP-ERROR-CODE TLV > Error Code Field", is created within the "Path Computation Element Protocol > (PCEP) Numbers" registry to manage the LSP Error code field of the > LSP-ERROR-CODE TLV. > ### Done > ------ > Section 10 > --- > - s/session also result in/session also results in/ > ### Done > - Again in section 10.4, the "resource limit exceed" information > (Error-value 4 of Error-Type 19) should be considered in a PCNtf. > ### XXX Pending > ------ > > Section 11 > --- > - Cyril and Ramon might be more than acknowledged since they are mentioned > twice. > ### Done :-) > ------ > Section 12 > --- > - For this document, I think the RFC 5226 reference is informative, not > normative (an implementer does not need to read it). > ### done > ------ > > Best regards, > > Julien > > --001a114dcae6e8f94a05230865b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Julien,=C2=A0

Thank you for the detaile= d review, please find answers inline below ###.=C2=A0 I have incorporated t= he overwhelming majority of the comments, explained the reason for not inco= rporating a couple of them, and am still working with the co-authors on a c= ouple of items marked "pending", which we will close on shortly.<= /div>

Two questions and one ask
1. Forward referenc= es to SRP object and SRP-ID - there are several in the comments, though the= relevant section is always mentioned. How should such forward references b= e addressed?
2. Section 7 - s/defined in this document/defined in that (= aforementioned) document/
The comment was not clear to me. The intention= is for the flags to be set as explained for the new objects we are definin= g here, can you clarify the comment?
3. Can you please review the comme= nts that were not incorporated and let us know if you agree?

Thank you,=C2=A0

Ina=C2=A0<= /div>

On Fri, Oct = 16, 2015 at 7:40 AM, Julien Meuric <julien.meuric@orange.com>= ; wrote:
Dear authors,

To prepare the upcoming move to the IESG, please find below my review of th= e aforementioned I-D (at last!).

_Summary_

Main qualities:
- core specification is clear;
- wording is smooth, with very few typos;
- the manageability and security sections have been included with relevant = text.
Main issues to point out:
- RFC 2119 keywords (picky me, but so is the IESG: ask JP about 5440);
- a few corner/error cases;
- consistency with existing RFCs (5440, 5886).
I also take the opportunity to remind the WG that including codepoint value= s from existing registries before allocation by the IANA (which can be requ= ested early) is a very bad idea, whatever the WG.

_Detailed Comments_
------
Header
---
- The blank line after Ed's name looks strange. If no affiliation is wa= nted, his name may be moved to the bottom of the list, to avoid association= with one of the listed companies. Otherwise, you may use a generic phrase,= e.g. "Individual Contributor".

### Done
=C2=A0
------
Section 1
---
- s/Path Computation Element Protocol/Path Computation Element communicatio= n Protocol/

### Done=C2=A0
------
Section 2
---
- "LSP", properly expended in the introduction, should be added s= omewhere (all the more as IS-IS is mentioned a few times).
=
### Added in terminology, with reference to 3031.=C2=A0
=C2= =A0
- s/Stateful PCE: has/Stateful PCE: a PCE that has/
- s/Passive Stateful PCE: uses/Passive Stateful PCE: a stateful PCE that us= es/
### Done =C2=A0
- s/Active Stateful PCE: is an extension/Active Stateful PCE: an extension/=
=C2=A0### Replaced as "an Active Stateful PCE th= at may issue recommendations...=C2=A0

- s/Delegation: An/Delegation: an/
- s/PCC who owns/PCC which owns/
- s/PCC SHOULD be/PCC should be/
- s/Revocation: An/Revocation: an/
### Done =C2=A0

- OLD
Redelegation Timeout Interval: when a PCEP session is terminated, a PCC wai= ts for this time period before revoking LSP delegation to a PCE and attempt= ing to redelegate LSPs associated with the terminated PCEP session to an al= ternate PCE.
=C2=A0 NEW
Redelegation Timeout Interval: the period of time a PCE waits for, when a P= CEP session is terminated, before revoking LSP delegation to a PCE and atte= mpting to redelegate LSPs associated with the terminated PCEP session to an= alternate PCE.
### Done=C2=A0

- OLD
State Timeout Interval: when a PCEP session is terminated, a PCC waits for = this time period before flushing LSP state associated with that PCEP sessio= n and reverting to operator-defined default parameters or behaviors.
=C2=A0 NEW
State Timeout Interval: the period of time a PCE waits for, when a PCEP ses= sion is terminated, before flushing LSP state associated with that PCEP ses= sion and reverting to operator-defined default parameters or behaviors.
=
### Done=C2=A0
=C2=A0
- OLD
Within this document, PCE-PCE communications are described by having the re= questing PCE fill the role of a PCC. This provides a saving in documentatio= n without loss of function.
=C2=A0 NEW
Within this document, PCEP communications are described through PCC-PCE rel= ationship. The PCE architecture also supports the PCE-PCE communication, by= having the requesting PCE fill the role of a PCC, as usual.
### Done
=C2=A0
------
Section 3
---
- Section 3.1.3 includes 2 paragraphs "Scale and Performance": th= ey should either be merged, or the old text version should be dropped.
<= /blockquote>
### Done, new text below:
 o  Scale & Perform=
ance: configuration operations often have
      transactional semantics which are typically heavyweight and often
      require processing of additional configuration portions beyond the
      state being directly acted upon, with corresponding cost in CPU
      cycles, negatively impacting both PCC stability LSP update rate
      capacity.

=C2=A0
- s/which prevents interoperability of a PCE/which limits interoperability = of a stateful PCE/
- s/the same PCEP./the same protocol, i.e., PCEP./
###= done =C2=A0

=C2=A0
------
Section 4
---
- s/A PCE requests/a PCE requests/
### Done
= =C2=A0
- The reference to draft-sivabalan-pce-disco-stateful makes the reader wond= er why is is not part of draft-ietf-pce-stateful-pce itself. Besides, Table= 1 also mentions IS-IS and OSPF PCE-CAP-FLAGS sub-TLV, only the allocation = section seems to be missing here. Would you talk to the authors (some being= common to both I-Ds) of the former to consider using their material as a c= ontribution? A separate document is quite an overhead for allocating 2 bits= .

### I don't think discovery shoul= d be part of the base draft. Several reasons: a) 5440 does not include disc= overy, b) the base spec is already quite large, we want to keep only the co= re function and =C2=A0c) the discovery draft is expired. I cleaned up table= 1 and added the following text instead of the reference to the draft:
Old text=C2=A0
[I-D.sivabalan-pce=
-disco-stateful] defines the extensions needed to   suppo=
rt autodiscovery of stateful PCEs when using OSPF ([RFC5088]) or IS-IS ([RFC5089]) for PCE discovery.
New text
Similarly to [RFC5440], no assump=
tion is made about the discovery method used by a PCC to =
discover a set of PCEs (e.g., via static configuration or=
 dynamic discovery) and on the algorithm used to select a=
 PCE.  Extensions needed to support autodiscovery will be defined in a separate document.=C2=A0
------
Section 5
---
- s/In the PCEP protocol/In PCEP/
- s/The PCEP protocol extensions/The PCEP extensions/
- s/by the operator through/by the operator, e.g., through/
- "PCRpt message can contain": what about "s/can/MAY/"?=
- s/ISIS/IS-IS/
- s/The PCEP protocol extensions/The PCEP extensions/
- s/it SHOULD generate a PCErr/it MUST generate a PCErr/=C2=A0 [twice]
<= /blockquote>
### Done
=C2=A0
- s/it will terminate/it MUST\SHOULD terminate/=C2=A0 [twice]
### I replaced with SHOULD
=C2=A0
- s/in this document MAY/in this document may/
- s/SHOULD be generated/MUST be generated/
- s/PCE can still receive/PCE can still accept/
### Do= ne
=C2=A0
- PLSP-ID is used, while not yet defined nor expended.
### Added reference
=C2=A0
- s/include an empty ERO/include an empty RRO/ [Along with RFC 5440 (sectio= n 7.10), the object sent by a PCC to report to a PCE is an RRO: let us keep= it consistent.]
### XXX Pending
=C2=A0
- s/in its path/for its path/=C2=A0 [or "as its path"?]
### Done
=C2=A0
- Avoiding "positive acknowledgements for properly received synchroniz= ation messages" has scalability benefits in normal situations, but the= PCC is blind and may keep on sending PCRpt to dead processes behind up PCE= P sessions. Have you consider acknowledgement, possibly using a compression= mechanism like the one defined later in the I-D?
### = XXX Pending=C2=A0


=C2=A0
- When mentioning errors, adding a sentence reminding that RFC 5440 already= defines a set of applicable error codes would be valuable.
### XXX Pending

=C2=A0
- The sentence about "delegation policy" in section 5.5 is not pr= otocol specification and should be moved to section 9.1 ("Control Func= tion and Policy").
### Done. Good point, moved.= =C2=A0
=C2=A0
- s/PCE may return/PCE MAY return/
- s/PCE may revoke/PCE MAY revoke/
- s/PCC should react/PCC SHOULD react/=C2=A0 [?]
### D= one=C2=A0
=C2=A0
- In section 5.5.1, it is not clear if an empty LSP Update Request with a D= elegate flag to 1 is an acceptable way for a PCE to send a delegation ackno= wledgement: to be clarified.=C2=A0
### XXX Pending
=C2=A0
- Section 5.5.1 has a significant break in the middle, it would deserve sub= sections: e.g., "5.5.2.1 Revoking Explicitly" and "5.5.2.2. = Revoking on Timeout" right before "When a PCC's PCEP session = with a PCE terminates unexpectedly...".
### Done = =C2=A0
=C2=A0
- s/the PCC SHALL flush/the P= CC MUST flush/=C2=A0 [correct, but single instance of SHALL in the I-D]
=
### Done=C2=A0
=C2=A0
- Current text says "The State Timeout Interval SHOULD be greater than= or equal to the Redelegation Timeout Interval", but the I-D assumes &= quot;MUST": if "MUST" is avoided on purpose, then some text = should be added for cases not falling under that "SHOULD".
### Done =C2=A0
=C2=A0
- s/SHOULD return the LSP delegation/MUST return the LSP delegation/
### This should remain SHOULD. The nice way to do it is to r= eturn it explicitly, but it may choose to wait until the next update and re= turn the delegation then by not setting the delegate flag.=C2=A0
= =C2=A0
- In section 5.5.3, assuming an LSP was delegated, does the reception by th= e PCC of a non empty LSP Update Request with a Delegate Flag to 0 trigger a= n error?
### XXX Pending=C2=A0
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex"> - s/to be larger/to be greater/
### Done=C2=A0

- s/as recommended/as RECOMMENDED/ or s/as recommended/as MANDATORY/=C2=A0 = [depending on the SHOULD/MUST selected above]
### Done= =C2=A0

- At the top of page 18, "and [assuming that] PCEs' decisions are = the same" should be added.
### The comment is not= clear - I am assuming you refer to the text "assuming that the state = timeout... ' on page 17, changed to: " and assuming that the prima= ry and redundant PCEs take similar decisions, this"
=C2=A0
- Again, in section 5.5.5, 4th paragraph, after "there will be no chan= ge in LSP state", "if similar PCEs' decisions" should be= added.
### Done "and assuming that the standby P= CE takes similar decisions as the failed PCE"=C2=A0
=C2=A0
- s/is larger than/is greater than/
- Section 5.6 requires more RFC 2119 keywords, only a few of them are sugge= sted below.
- s/For each LSP, it sends/For each LSP, it MAY send/
- s/could not be set up, the PCC sends/could not be set up, the PCC MUST se= nd/
- s/it also sends/it SHOULD also send/
- s/A PCC sends each LSP State Report/A PCC MUST send each LSP State Report= /
### Done =C2=A0

=C2=A0
- In section 5.6.2, in case of new LSP, the very first message sent by the = PCC aims at getting a path. This is clearly the role of a PCReq message, an= d the I-D extends it to support the LSP object including the delegation fla= g (section 7.3). However, Figure 8 treats a new LSP the same way as reporti= ng an existing LSP, i.e., using a PCRpt message. In this case, there is an = overlap between PCReq and PCRpt, which MUST be resolved because interoperab= ility is at stake. Documenting the delegation of a new LSP deserves some ne= w text and possibly figure, the overlapping specification of the PCRpt shou= ld be explicitly precluded.
### This is historical con= fusion in the figure, from the time when initiation was rolled up in the sa= me document. I modified the figure so it is clear this is for updating para= meters only. =C2=A0

=C2=A0
= - s/existing LSPs) and LSPs have/existing LSPs). After LSPs have/
- s/For each LSP, it sends/For each LSP, it MAY send/
- s/LSP is up, the PCC sends/LSP is up, the PCC MUST send/
- s/be set up, the PCC sends/be set up, the PCC MUST send/
- s/PCC may choose to compress LSP State/PCC MAY compress LSP State/
- s/A PCC sends each LSP State/A PCC MUST send each LSP state/
### Done
=C2=A0
- At the end of section 5.6, "SRP-ID-number" is used but not yet = defined. At least, SRP should be expended.
### It was = referenced and explained earlier in 5.6.
=C2=A0
- s/PCC may choose to compress state/PCC MAY compress state/
- s/the earlier updates/the updates with lower SRP-ID-number/ [Noting that = it assumes that the value is incrementing, which is documented only later, = in section 7.2.]=C2=A0
### Added reference
= =C2=A0
- s/in a separate draft/in a separate document/
- s/Transport/PCEP Sessions/
### Done=C2=A0
------
Section 6
---
- The terms "mandatory" and "optional" are introduced, = but barely used then. It would be better to stick to RFC 2119 keywords (e.g= ., "REQUIRED" and "OPTIONAL") and actually use them for= each object.
- The object ordering is defined as mandatory: unfortunately, that would be= inconsistent with previous PCEP extensions. I suggest to either drop that = sentence, or at least downgrade to a "SHOULD" as a trade-off.
=
### Done.=C2=A0
=C2=A0
- s/<ERO><attribute-list>/<RRO><attribute-list>/ [P= er RFC 5440, a report from PCC to PCE is RRO.]
### XXX= Pending=C2=A0
=C2=A0
- The need for the optional xRO is not well documented. Its proper naming w= ill depend on the associated use that must be clarified.
- "SRP" is still not defined.
### Isn't = it enough to reference the section in which it is defined?
=C2=A0=
- s/is optional/is OPTIONAL/
- s/the latest one/the one with the highest ID-number/
- s/is mandatory/is REQUIRED/
### Done
=C2= =A0
- The use of the optional xRO is mentioned, but its relationship with the R= RO (formerly ERO) is not clear. I suspect some assumptions are made on the = way the ERO/RRO are populated; RFC 5440 only says ERO for PCE->PCC and R= RO for PCC->PCE.
### XXX Pending
=C2=A0
- s/included by the PCC/inlcuded in PCRpt by the PCC/
= ### Done =C2=A0
- The behavior associated to the resource limit per PCC rather looks like a= Notifcation than an Error (e.g., in RFC 5440, cancelling a set of pending = requests relies on PCNtf). Please consider the use of Notification instead = of Error here.
### XXX Pending
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex"> - s/that the PCE associates/that the PCC associates/
- s/next LSP. If the PCUpd/next LSP.<lineBreak>If the PCUpd/
------
### Done =C2=A0
Section 7
---
- s/defined in this document/defined in that (aforementioned) document/
=
### Unclear comment, the intention was for the flags to b= e set as explained for the new objects in this document, not for anything i= n 5440.
=C2=A0
- s/SHOULD always be/MUST be/
- s/one SPR-id-number/one SRP-ID-number/
- s/SRP-ID/SRP-ID-number/=C2=A0 [3 times]
- s/allocated it/allocated to it/
- s/Flags (12 bits):/Flags (12 bits), starting from the least significant b= it:/
### Done
=C2=A0
- s/on a PCRpt message/On a PCRpt or PCReq message/
##= # We don't support delegation through a PCReq message
=C2=A0<= /div>
- s/the S flag/The S flag/
- s/in other PCRpt messages/in other messages/
### Don= e
=C2=A0
- "PCE SHOULD remove all state" is written 3 times: I wonder abou= t "MUST".
### SHOULD is the correct operatio= n, the PCE is free to choose to keep state around for as long as it wishes.= The 3 removal statements refer to different scenarios.=C2=A0
=C2= =A0
- s/LSP Identifiers/LSP-IDENTIFIERS/=C2=A0 [4 or 5 times]
<= div>### Done
=C2=A0
- Texts associated with object definition are incomplete, they rely too muc= h on figures. For example:
=C2=A0 =C2=A0 * s/The type of the TLV/The type (16 bits) of the TLV/=C2=A0 = [5 times]
=C2=A0 =C2=A0 * s/IANA and it has a fixed length of/IANA. The length field = is 16 bit-long and has a fixed value of/=C2=A0 [3 times]
=C2=A0 =C2=A0 * s/IANA and it has a variable length/IANA. The length field = is 16 bit-long and has a variable value/=C2=A0 [2 times]
### Done =C2=A0

- s/= in l following/in the following/
### Done=C2=A0
<= div>

- The paragraph "However, when Gobal Path Protection... (or vice versa= )" is not IPv6 specific and should be moved to the end of section 7.3.= 1.
### Done. Also added a MUST keyword
=C2= =A0
- s/a path's lifetime/an LSP's lifetime/
### D= one
=C2=A0
- It would be nice to elaborate on the reason why the SYMBOLIC-PATH-NAME MU= ST be included and not SHOULD.
- I do not see why SYMBOLIC-PATH-NAME may be included in SRP Object: defini= ng the LSP Object as its single place seems enough and much simpler.

### XXX =C2=A0Pending
------
Section 8
---
- OLD
This document requests that a registry is created to manage the Flags field= of the LSP object.
=C2=A0 NEW
This document requests that a new sub-registry, named "LSP ObjectFlag = Field", is created within the "Path Computation Element Protocol = (PCEP) Numbers" registry to manage the Flag field of the LSP object.
### Done =C2=A0

- either s/Error-value=3D9: ERO Object/Error-value=3D9: xRO Object/=C2=A0 o= r add an Error-Value for RRO.
### Done=C2=A0
=C2=A0
- As mentioned above, in Error-Type 19, Error-value 4 should be considered = in a PCNtf.
### XXX Pending=C2=A0

- OLD
This document requests that a registry is created to manage the Flags field= in the STATEFUL-PCE-CAPABILITY TLV in the OPEN object.
=C2=A0 =C2=A0NEW
This document requests that a new sub-registry, named "STATEFUL-PCE-CA= PABILITY TLVFlag Field", is created within the "Path Computation = Element Protocol (PCEP) Numbers" registry to manage the Flag field in = the STATEFUL-PCE-CAPABILITY TLV of the PCEP OPEN object (class =3D 1).
<= /blockquote>
### Done =C2=A0

- OLD
This document requests that a registry is created to manage the value of th= e LSP error code field in this TLV.
=C2=A0 NEW
This document requests that a new sub-registry, named "LSP-ERROR-CODE = TLV Error Code Field", is created within the "Path Computation El= ement Protocol (PCEP) Numbers" registry to manage the LSP Error code f= ield of the LSP-ERROR-CODE TLV.
### Done=C2=A0
=C2=A0
------
Section 10
---
- s/session also result in/session also results in/
##= # Done=C2=A0
=C2=A0
- Again in section 10.4, the "resource limit exceed" information = (Error-value 4 of Error-Type 19) should be considered in a PCNtf.
### XXX Pending=C2=A0
------

=C2=A0
Section 11
---
- Cyril and Ramon might be more than acknowledged since they are mentioned = twice.
### Done :-)=C2=A0
------
Section 12
---
- For this document, I think the RFC 5226 reference is informative, not nor= mative (an implementer does not need to read it).
### = done
=C2=A0
------

Best regards,

Julien


--001a114dcae6e8f94a05230865b3-- From nobody Mon Oct 26 14:16:32 2015 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 67F5C1A1A91; Mon, 26 Oct 2015 14:16:30 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.7.1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20151026211630.11261.85059.idtracker@ietfa.amsl.com> Date: Mon, 26 Oct 2015 14:16:30 -0700 Archived-At: Cc: pce@ietf.org, draft-ietf-pce-pcep-domain-sequence@ietf.org, pce-chairs@ietf.org Subject: [Pce] Last Call: (Standard Representation of Domain-Sequence) to Experimental RFC X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2015 21:16:30 -0000 The IESG has received a request from the Path Computation Element WG (pce) to consider the following document: - 'Standard Representation of Domain-Sequence' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-11-09. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The ability to compute shortest constrained Traffic Engineering Label Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains has been identified as a key requirement. In this context, a domain is a collection of network elements within a common sphere of address management or path computational responsibility such as an Interior Gateway Protocol (IGP) area or an Autonomous System (AS). This document specifies a standard representation and encoding of a Domain-Sequence, which is defined as an ordered sequence of domains traversed to reach the destination domain to be used by Path Computation Elements (PCEs) to compute inter-domain constrained shortest paths across a predetermined sequence of domains . This document also defines new subobjects to be used to encode domain identifiers. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-domain-sequence/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-domain-sequence/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/1690/ From nobody Mon Oct 26 14:57:06 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 814471A1C03 for ; Mon, 26 Oct 2015 14:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.194 X-Spam-Level: X-Spam-Status: No, score=-3.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, 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 eDE1173_5RoO for ; Mon, 26 Oct 2015 14:57:04 -0700 (PDT) Received: from r-mail1.rd.orange.com (r-mail1.rd.orange.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 000491A1C02 for ; Mon, 26 Oct 2015 14:57:03 -0700 (PDT) Received: from r-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 43372A44259 for ; Mon, 26 Oct 2015 22:57:08 +0100 (CET) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by r-mail1.rd.orange.com (Postfix) with ESMTP id 3C8AAA44258 for ; Mon, 26 Oct 2015 22:57:08 +0100 (CET) Received: from [10.193.116.76] (10.193.116.76) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.224.2; Mon, 26 Oct 2015 22:57:02 +0100 From: Julien Meuric References: <8450_1444040825_56125078_8450_1292_1_56125078.50803@orange.com> <561B6935.50701@orange.com> To: Organization: Orange Message-ID: <562EA1AE.5000608@orange.com> Date: Mon, 26 Oct 2015 22:57:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <561B6935.50701@orange.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Pce] Building the PCE Agenda for IETF 94 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Julien Meuric , 'JP Vasseur' , Jonathan Hardwick , Daniel King List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2015 21:57:05 -0000 Dear all, The PCE agenda is on line (https://www.ietf.org/proceedings/94/agenda/agenda-94-pce). If you have a slot, please send your slides to the chairs and secretary by Sunday, noting that your allocated duration may differ from your original request. Regards, Jon, JP & Julien Oct. 12, 2015 - Julien Meuric: > Hi all, > > FYI, the PCE session is now scheduled on Tuesday, from 5:10 to 6:40 > pm, right before the social event. > > By the way, Yokohama meeting is number 94: sorry for the typo in the > previous e-mail. > > Regards, > > Jon, JP & Julien > > > Oct. 05, 2015 - julien.meuric@orange.com: >> Dear PCE WG, >> >> The IETF preliminary agenda is available >> (https://datatracker.ietf.org/meeting/94/agenda.html). The PCE >> session is _tentatively_ scheduled on Monday from 3:20 to 4:50 pm. >> Supposing you have issues that _really_ require a slot to progress, >> please send a request to the chairs and secretary, including: >> - the topic to discuss, >> - the expected duration, >> - the name of the presenter, >> - the rationale for requesting some face to face time, as opposed to >> using the mailing list, i.e., the output you expect from your slot. >> >> Best regards, >> >> JP & Julien > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > From nobody Tue Oct 27 00:23:22 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD3B1B36F6; Tue, 27 Oct 2015 00:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 J_idwDsmDPw0; Tue, 27 Oct 2015 00:23:17 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F231C1B36F7; Tue, 27 Oct 2015 00:23:16 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BZJ00991; Tue, 27 Oct 2015 07:23:15 +0000 (GMT) Received: from BLREML406-HUB.china.huawei.com (10.20.4.43) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 27 Oct 2015 07:23:14 +0000 Received: from BLREML509-MBX.china.huawei.com ([169.254.7.243]) by BLREML406-HUB.china.huawei.com ([10.20.4.43]) with mapi id 14.03.0235.001; Tue, 27 Oct 2015 12:53:04 +0530 From: Dhruv Dhody To: Venugopal Reddy K Thread-Topic: Few queries regarding draft-dhody-pce-stateful-pce-auto-bandwidth-06 draft Thread-Index: AdEPzfMTZejSeas9TDmsv5D0lyT51QApgOiw Date: Tue, 27 Oct 2015 07:23:04 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B8C42D184@BLREML509-MBX.china.huawei.com> References: <10376B02BC561F4185654159EF7900204FCA1956@szxeml561-mbx.china.huawei.com> In-Reply-To: <10376B02BC561F4185654159EF7900204FCA1956@szxeml561-mbx.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.244.252] Content-Type: multipart/alternative; boundary="_000_23CE718903A838468A8B325B80962F9B8C42D184BLREML509MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "draft-dhody-pce-stateful-pce-auto-bandwidth@ietf.org" , pce Subject: Re: [Pce] Few queries regarding draft-dhody-pce-stateful-pce-auto-bandwidth-06 draft X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 07:23:20 -0000 --_000_23CE718903A838468A8B325B80962F9B8C42D184BLREML509MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Venu, Thanks for reading the draft and posting queries. See inline... From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Venugopal Reddy K Sent: 26 October 2015 14:39 To: draft-dhody-pce-stateful-pce-auto-bandwidth@ietf.org; pce Subject: [Pce] Few queries regarding draft-dhody-pce-stateful-pce-auto-band= width-06 draft Dear Authors, I have few queries regarding draft-dhody-pce-stateful-pce-auto-bandwidth-06= . 1. We have Overflow-Count, Overflow-Threshold and Underflow-Count, Un= derflow-Threshold to expedite the process of PCC adjusting the bandwidth in= stead of waiting for Adjustment-Interval when an abrupt change in bandwidth= usage occurs. Similarly, we have Report-Flow-Threshold value for a PCC to = report for PCE adjusting bandwidth model instead of waiting for Report-Inte= rval. Can we know if there is rationale behind having different method for = PCC controlling bandwidth adjustment and PCE controlling bandwidth adjustme= nt for this case? Why not have the similar mechanism for it ? [Dhruv]: Are you asking why we don't have a "Report-Flow-Count" (similar to= Underflow and overflow-count)? Hmm, I guess "Report-Flow-Count" can be add= ed, it is a good suggestion. This would indicate how many times consecutively, the percentage or absolut= e difference between the current bandwidth sample and the current bandwidth= reservation should be greater than or equal to the report-flow-threshold v= alue, for all the bandwidth samples collected so far to be reported to the = PCE immediately. 2. Once auto-bandwidth adjustment is enabled for an LSP, Couldn't fin= d any way to disable auto adjustment feature for an LSP. It would be good t= o have a means to disable adjustment without bringing the LSP down. Also, = changing auto-bandwidth adjustment mode from PCC to PCE or vice versa witho= ut LSP down. [Dhruv]: I think this could be useful, will discuss with my co-authors and = add mechanism for this in future revision. Regards, Dhruv Could you please clarify. Thanks :) Regards, Venu --_000_23CE718903A838468A8B325B80962F9B8C42D184BLREML509MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Venu,

 

Thanks for reading the draft and post= ing queries.

 

See inline…

 

From: Pce [mai= lto:pce-bounces@ietf.org] On Behalf Of Venugopal Reddy K
Sent: 26 October 2015 14:39
To: draft-dhody-pce-stateful-pce-auto-bandwidth@ietf.org; pce
Subject: [Pce] Few queries regarding draft-dhody-pce-stateful-pce-au= to-bandwidth-06 draft

 

Dear Authors,

 

I have few queries regarding draft-dhody-pce-statefu= l-pce-auto-bandwidth-06.

 

1.     &= nbsp; We have Overflow-Count, Overflow-Threshold and Unde= rflow-Count, Underflow-Threshold to expedite the process of PCC adjusting t= he bandwidth instead of waiting for Adjustment-Interval when an abrupt chan= ge in bandwidth usage occurs. Similarly, we have Report-Flow-Threshold value for a PCC to report for PCE adjusting = bandwidth model instead of waiting for Report-Interval. Can we know if ther= e is rationale behind having different method for PCC controlling bandwidth= adjustment and PCE controlling bandwidth adjustment for this case? Why not have the similar mechanism for= it ?

 

 

[Dhruv]: Are you askin= g why we don’t have a “Report-Flow-Count” (similar to Und= erflow and overflow-count)? Hmm, I guess “Report-Flow-Count” ca= n be added, it is a good suggestion.

This would indicate ho= w many times consecutively, the percentage or absolute difference between t= he current bandwidth sample and the current bandwidth reservation should be= greater than or equal to the report-flow-threshold value, for all the bandwidth samples collected so far to be reported to th= e PCE immediately.

 

2.     &= nbsp; Once auto-bandwidth adjustment is enabled for an LS= P, Couldn’t find any way to disable auto adjustment feature for an LS= P. It would be good to have a means to disable adjustment without bringing = the LSP down.  Also, changing auto-bandwidth adjustment mode from PCC to PCE or vice versa without LSP down.=

 

[Dhruv]: I think this = could be useful, will discuss with my co-authors and add mechanism for this= in future revision.   

 

Regards,

Dhruv

 

Could you please clarify.

 

Thanks J

 

Regards,

Venu

--_000_23CE718903A838468A8B325B80962F9B8C42D184BLREML509MBXchi_-- From nobody Tue Oct 27 02:17:09 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 030D01A1B40; Tue, 27 Oct 2015 02:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 EyH1SCfzDBcy; Tue, 27 Oct 2015 02:17:03 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26D161A1B3C; Tue, 27 Oct 2015 02:17:02 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BZK12327; Tue, 27 Oct 2015 09:16:59 +0000 (GMT) Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 27 Oct 2015 09:16:57 +0000 Received: from SZXEMA504-MBX.china.huawei.com ([169.254.7.36]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0235.001; Tue, 27 Oct 2015 17:16:53 +0800 From: Zhenghaomian To: "'ccamp@ietf.org'" , "pce@ietf.org" , "TEAS WG" Thread-Topic: =?utf-8?B?SW5pdGlhbCB2ZXJzaW9uIGZvciBsaWFpc29uIHRleHQgLy/nrZTlpI06IENB?= =?utf-8?B?TEwgRk9SIFZPTFVOVEVFUiAtICBOZXcgTGlhaXNvbiBTdGF0ZW1lbnQsICJB?= =?utf-8?B?Y2hpZXZpbmcgUGFja2V0IE5ldHdvcmsgT3B0aW1pemF0aW9uIHVzaW5nIERX?= =?utf-8?Q?DM_Interfaces"?= Thread-Index: AdEQlwg0nBSjolVUTpmgrTvatjXCNA== Date: Tue, 27 Oct 2015 09:16:52 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.57.78.114] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "david.sinicrope@ericsson.com" Subject: [Pce] =?utf-8?q?Initial_version_for_liaison_text_//=E7=AD=94?= =?utf-8?q?=E5=A4=8D=3A_CALL_FOR_VOLUNTEER_-__New_Liaison_Statement=2C_=22?= =?utf-8?q?Achieving_Packet_Network_Optimization_using_DWDM_Interfaces=22?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 09:17:07 -0000 SGksIEFsbCwNCg0KQWZ0ZXIgcmV2aWV3aW5nIHRoZSBsaWFpc29uIGFuZCBkb2N1bWVudCBmcm9t IEJCRiwgd2Ugd291bGQgbGlrZSB0byBwcm92aWRlIHRoZSBmb2xsb3dpbmcgdGV4dCBhcyBhbiBp bml0aWFsIHZlcnNpb24gZm9yIHJlc3BvbnNlLiBQbGVhc2UgaGVscCByZXZpZXcsIHlvdXIgY29t bWVudHMgYXJlIGhpZ2hseSB3ZWxjb21lZC4gDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT1mb3IgZGlzY3Vzc2lvbj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQ0KVGhlIHdvcmtpbmcgZ3JvdXBzIGluIElFVEYgcm91dGluZyBhcmVh IHdvdWxkIGxpa2UgdG8gdGhhbmsgeW91IGZvciBzZW5kaW5nIHRoaXMgbGlhaXNvbi4gV2UgbXVj aCBhcHByZWNpYXRlIEJCRiBvbiB0aGUgZWZmb3J0IG9mIHBhY2tldCBvdmVyIG9wdGljYWwsIGFu ZCBzZW5kaW5nIHRoZSBkb2N1bWVudCB0byBJRVRGIENDQU1QLCBURUFTIGFuZCBQQ0UgV0dzIGZv ciByZXZpZXcuIFRoaXMgcHJvamVjdCBkZWZpbmVzIGEgc2V0IG9mIGNvbnRyb2wgcGxhbmUgcmVx dWlyZW1lbnRzIHRoYXQgdGhlIFBoeXNpY2FsbHkgU2VwYXJhdGVkIE1vZGVsIHNob3VsZCBiZSBz YXRpc2ZpZWQuIFdlIGFyZSBnZW5lcmFsbHkgZmluZSBhYm91dCB0aGUgY29udGVudCwgd2l0aCBz b21lIG1pbm9yIHN1Z2dlc3Rpb25zIGxpc3RlZCBhcyBmb2xsb3cgZm9yIHlvdXIgcmVmZXJlbmNl OiANCg0K4oCiIFdoZW4gcmVmZXJyaW5nIHRvIFBDRSBhbmQgcmVsYXRlZCBpc3N1ZXMsIGUuZy4s IGluIFtSLTI2XSBhbmQgW1ItMjddLCBpdCBzZWVtcyBvbmx5IHN0YXRlbGVzcyBQQ0UgKFJGQzQ2 NTUpIGFuZCBjb3JyZXNwb25kaW5nIFBDRVAgKFJGQzU1MjApIGFyZSBpbmNsdWRlZCBpbiB0aGUg Y3VycmVudCB2ZXJzaW9uLiBBcyBJRVRGIFBDRSB3b3JraW5nIGdyb3VwIGlzIGludmVzdGlnYXRp bmcgb24gc3RhdGVmdWwgUENFLCBQQ0UgSW5pdGlhdGlvbiBhbmQgUENFIGFzIGEgQ2VudHJhbCBD b250cm9sbGVyLCB3aGljaCBhcmUgcGxhbm5lZCB0byBiZSBwdWJsaXNoZWQgaW4gdGhlIGZ1dHVy ZSwgaXQgaXMgYmV0dGVyIHRvIHNwZWNpZnkgd2hpY2gga2luZCBvZiBQQ0UgaXMgbm93IHJlZmVy cmVkIGJ5IHRoaXMgZG9jdW1lbnRzLiBNb3Jlb3ZlciwgUkZDIDU2MjMsIFBDRS1iYXNlZCBpbnRl ci1sYXllciBNUExTIGFuZCBHTVBMUyBUcmFmZmljIEVuZ2luZWVyaW5nLCBtYXkgYmUgYSBnb29k IHJlZmVyZW5jZSBmb3IgdGhpcyBkb2N1bWVudC4gDQrigKIgSW4gc2VjdGlvbiA0LjQgd2hlbiB0 YWxraW5nIGFib3V0IFNETiwgT3BlbmZsb3cgaXMgbWVudGlvbmVkIGFzIGEgc3RhbmRhcmQgcHJv dG9jb2wgdG8gaW50ZXJhY3QgYmV0d2VlbiBwYWNrZXQgbm9kZXMgYW5kIERXRE0gbm9kZXMuIFdl IHdvdWxkIGxpa2UgdG8gc3VnZ2VzdCBhZGQgUENFIFByb3RvY29sIChQQ0VQKSBhcyBhbm90aGVy IGV4YW1wbGUsIGFzIGl0IGlzIGN1cnJlbnRseSB1c2VkIGluIElFVEYuIEJlc2lkZXMsIGl0IGlz IHN1Z2dlc3QgdG8gcmVmZXJlbmNlIHRvIFJGQyAzNDEzIGFib3V0IFNOTVAsIGFuZCBSRkMgNDIw OCBhYm91dCBHTVBMUyBVTkkuIA0K4oCiIEluIHNlY3Rpb24gNC41LCBbUi0zNl0gaXMgbm90IGNs ZWFyIHdoZXRoZXIgdG8gYmUgYXBwbGllZCB0byB0aGUgbm9ydGgtYm91bmQgb2YgU0ROIGNvbnRy b2xsZXIsIG9yIGJldHdlZW4gdGhlIHBhY2tldCBORSBhbmQgU0ROIGNvbnRyb2xsZXIuIFdlIHBy ZWZlciB0aGUgbGF0dGVyIG9uZS4gDQoNCkl0IHNlZW1zIHRvIHVzIHRoZSByZXF1aXJlbWVudHMg cHJvcG9zZWQgaW4gdGhlIGN1cnJlbnQgZG9jdW1lbnQgY291bGQgYmUgYWRkcmVzc2VkIGJ5IHRo ZSByZWZlcmVuY2VkIFJGQ3MgZGVmaW5lZCBmb3IgR01QTFMsIHNvIHdlIHdvdWxkIGxpa2UgdG8g bWFrZSBzdXJlIGlmIHlvdSBoYXZlIGlkZW50aWZpZWQgYW55IGdhcHMsIHdoaWNoIG5lZWQgYW4g dXBkYXRlIG9uIEdNUExTIHRvIHNhdGlzZnkgdGhlc2UgcmVxdWlyZW1lbnRzLiBJRVRGIENDQU1Q IGlzIGRpc2N1c3NpbmcgdG8gZGVmaW5lIGEgZnJhbWV3b3JrIGZvciBNYW5hZ2VtZW50IGFuZCBD b250cm9sIG9mIERXRE0gb3B0aWNhbCBpbnRlcmZhY2UgcGFyYW1ldGVycyBhbmQgR01QTFMgcHJv dG9jb2xzIHRoYXQgbmVlZCB0byBiZSB1cGRhdGVkLCB3aGljaCBtaWdodCBiZSByZWxldmFudCB0 byB5b3VyIHByb2plY3QsIGJ1dCB0aGlzIHdvcmsgaW4gQ0NBTVAgaXMgc3RpbGwgaW4gaW5kaXZp ZHVhbCBkcmFmdHMgc3RhZ2UuIFdlIHdvdWxkIGxpa2UgdG8gcmVjZWl2ZSB5b3VyIGlucHV0LiAN Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQ0KDQpUaGFua3MuDQoNCkJlc3Qgd2lzaGVzLA0KSGFvbWlhbg0KDQotLS0tLemCruS7tuWOn+S7 ti0tLS0tDQrlj5Hku7bkuro6IFpoZW5naGFvbWlhbiANCuWPkemAgeaXtumXtDogMjAxNeW5tDEw 5pyIMjHml6UgMTE6MTENCuaUtuS7tuS6ujogRGFuaWVsZSBDZWNjYXJlbGxpOyBGYXRhaSBaaGFu Zw0K5oqE6YCBOiBjY2FtcEBpZXRmLm9yZw0K5Li76aKYOiDnrZTlpI06IENBTEwgRk9SIFZPTFVO VEVFUiAtIE5ldyBMaWFpc29uIFN0YXRlbWVudCwgIkFjaGlldmluZyBQYWNrZXQgTmV0d29yayBP cHRpbWl6YXRpb24gdXNpbmcgRFdETSBJbnRlcmZhY2VzIg0KDQpEYW5pZWxlLCBGYXRhaSBhbmQg QWxsLA0KDQpJIHdvdWxkIGxpa2UgdG8gdm9sdW50ZWVyIGZvciBnZW5lcmF0aW5nIHRoZSByZXNw b25zZSBsaWFpc29uLCBhcyB0aGUgdG9waWMgaXMgaGlnaGx5IHJlbGF0ZWQgdG8gbXkgcmVzZWFy Y2ggd29yay4gSSB3aWxsIHJldmlldyB0aGUgZG9jdW1lbnQgYW5kIHNoYXJlIG15IGNvbW1lbnRz IGVhcmx5IG5leHQgd2Vlay4gUGxlYXNlIGFsc28gZmVlbCBmcmVlIHRvIHNoYXJlIHlvdXIgb3Bp bmlvbiwgdGhhbmtzLiANCg0KQmVzdCB3aXNoZXMsDQpIYW9taWFuDQoNCi0tLS0t6YKu5Lu25Y6f 5Lu2LS0tLS0NCuWPkeS7tuS6ujogQ0NBTVAgW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3Jn XSDku6PooaggRGFuaWVsZSBDZWNjYXJlbGxpDQrlj5HpgIHml7bpl7Q6IDIwMTXlubQxMOaciDIw 5pelIDIzOjQ2DQrmlLbku7bkuro6IENDQU1QIChjY2FtcEBpZXRmLm9yZykNCuS4u+mimDogW0ND QU1QXSBDQUxMIEZPUiBWT0xVTlRFRVIgLSBOZXcgTGlhaXNvbiBTdGF0ZW1lbnQsICJBY2hpZXZp bmcgUGFja2V0IE5ldHdvcmsgT3B0aW1pemF0aW9uIHVzaW5nIERXRE0gSW50ZXJmYWNlcyINCg0K V0csDQoNCldlIHJlY2VpdmVkIHRoaXMgbGlhaXNvbiBmcm9tIEJCRiBvbiBQYWNrZXQtT3B0aWNh bCBpbnRlZ3JhdGlvbi4gDQpJJ20gY29weWluZyB0aGUgbGlua3MgdG8gbGlhaXNvbiBhbmQgYXR0 YWNobWVudCBoZXJlIGZvciB5b3VyIGNvbnZlbmllbmNlDQpMaWFpc29uOiAgaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9saWFpc29uLzE0MzIvDQpBdHRhY2htZW50OiBodHRwczovL3d3dy5p ZXRmLm9yZy9saWIvZHQvZG9jdW1lbnRzL0xJQUlTT04vbGlhaXNvbi0yMDE1LTEwLTE2LWJyb2Fk YmFuZC1mb3J1bS1ydGctY2NhbXAtdGVhcy1hY2hpZXZpbmctcGFja2V0LW5ldHdvcmstb3B0aW1p emF0aW9uLXVzaW5nLWR3ZG0taW50ZXJmYWNlcy1hdHRhY2htZW50LTEucGRmDQoNCldlJ2QgcmVh bGx5IGxpa2UgMSBvciAyIHZvbHVudGVlcnMgaW50ZXJlc3RlZCBpbiB0aGUgdG9waWMgdG8gZHJh ZnQgYW4gYW5zd2VyIHRvIHRoZSBsaWFpc29uIGJlZm9yZSB0aGUgbWVldGluZyBpbiBZb2tvaGFt YSBzbyB0byBiZSBhYmxlIHRvIGRpc2N1c3MgaXQgb24gdGhlIGxpc3QgYW5kIHJlcGx5IGR1cmlu ZyBvciBpbW1lZGlhdGVseSBhZnRlciB0aGUgbWVldGluZy4NCg0KUGxlYXNlIGNvbnNpZGVyIHZv bHVudGVlcmluZy4NClRoYW5rcw0KRmF0YWkgJiBEYW5pZWxlDQoNCj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gRnJvbTogTGlhaXNvbiBTdGF0ZW1lbnQgTWFuYWdlbWVudCBUb29sIFtt YWlsdG86bHNtdEBpZXRmLm9yZ10NCj4gU2VudDogdmVuZXJkw6wgMTYgb3R0b2JyZSAyMDE1IDIy OjA1DQo+IFRvOiBkYjM1NDZAYXR0LmNvbTsgdmJlZXJhbUBqdW5pcGVyLm5ldDsgYWthdGxhc0Bn bWFpbC5jb207IA0KPiBhcmV0YW5hQGNpc2NvLmNvbTsgbGJlcmdlckBsYWJuLm5ldDsgemhhbmdm YXRhaUBodWF3ZWkuY29tOyBEYW5pZWxlIA0KPiBDZWNjYXJlbGxpDQo+IENjOiBBbHZhcm8gUmV0 YW5hOyBEZWJvcmFoIEJydW5nYXJkOyBEYXZpZCBTaW5pY3JvcGU7IEZhdGFpIFpoYW5nOyANCj4g QWxpYSBBdGxhczsgVmlzaG51IFBhdmFuIEJlZXJhbTsgVGhlIElFVEYgQ2hhaXI7IERhbmllbGUg Q2VjY2FyZWxsaTsgDQo+IExvdSBCZXJnZXI7IENvbW1vbiBDb250cm9sIGFuZCBNZWFzdXJlbWVu dCBQbGFuZSBEaXNjdXNzaW9uIExpc3Q7IA0KPiBtaWNoYWVsLmZhcmdhbm9AY2VudHVyeWxpbmsu Y29tOyBUcmFmZmljIEVuZ2luZWVyaW5nIEFyY2hpdGVjdHVyZSBhbmQgDQo+IFNpZ25hbGluZyBE aXNjdXNzaW9uIExpc3QNCj4gU3ViamVjdDogTmV3IExpYWlzb24gU3RhdGVtZW50LCAiQWNoaWV2 aW5nIFBhY2tldCBOZXR3b3JrIE9wdGltaXphdGlvbiANCj4gdXNpbmcgRFdETSBJbnRlcmZhY2Vz Ig0KPiANCj4gVGl0bGU6IEFjaGlldmluZyBQYWNrZXQgTmV0d29yayBPcHRpbWl6YXRpb24gdXNp bmcgRFdETSBJbnRlcmZhY2VzIA0KPiBTdWJtaXNzaW9uIERhdGU6IDIwMTUtMTAtMTYgVVJMIG9m IHRoZSBJRVRGIFdlYiBwYWdlOg0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2xpYWlz b24vMTQzMi8NCj4gUGxlYXNlIHJlcGx5IGJ5IDIwMTUtMTEtMDgNCj4gRnJvbTogIChEYXZpZCBT aW5pY3JvcGUgPGRhdmlkLnNpbmljcm9wZUBlcmljc3Nvbi5jb20+KQ0KPiBUbzogICh2YmVlcmFt QGp1bmlwZXIubmV0LCBsYmVyZ2VyQGxhYm4ubmV0LCBha2F0bGFzQGdtYWlsLmNvbSwgDQo+IGFy ZXRhbmFAY2lzY28uY29tLCBkYjM1NDZAYXR0LmNvbSwgZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNz c29uLmNvbSwNCj4gemhhbmdmYXRhaUBodWF3ZWkuY29tKQ0KPiBDYzoNCj4gUmVzcG9uc2UgQ29u dGFjdHM6IG1pY2hhZWwuZmFyZ2Fub0BjZW50dXJ5bGluay5jb20gVGVjaG5pY2FsIENvbnRhY3Rz Og0KPiBQdXJwb3NlOiBGb3IgY29tbWVudA0KPiANCj4gQm9keTogRGVhciBJRVRGIFJvdXRpbmcg QXJlYSBhbmQgV29ya2luZyBHcm91cCBMZWFkZXJzOg0KPiANCj4gQXMgcHJldmlvdXNseSBjb21t dW5pY2F0ZWQsIHdlIGhhdmUgYmVlbiB3b3JraW5nIG9uIGEgcHJvamVjdCBlbnRpdGxlZCANCj4g 4oCcQWNoaWV2aW5nIFBhY2tldCBOZXR3b3JrIE9wdGltaXphdGlvbiB1c2luZyBEV0RNIEludGVy ZmFjZXPigJ0gYW5kIGFyZSANCj4gcmVmZXJlbmNpbmcgd29yayBiZWluZyBkb25lIGJ5IElFVEYg Q0NBTVAgYW5kIFRFQVMgaW4gdGhpcyBhcmVhLiBXZSANCj4gYXJlIHBsZWFzZWQgdG8gcmVwb3J0 IHRoYXQgd2UgaGF2ZSBtYWRlIHNpZ25pZmljYW50IHByb2dyZXNzIHRvd2FyZHMgDQo+IGNvbXBs ZXRpb24gb2Ygb3VyIHNwZWNpZmljYXRpb25zLiBTcGVjaWZpY2FsbHksDQo+IA0KPiBvIFRSLTMx OSBCYXNlLCDigJxBY2hpZXZpbmcgUGFja2V0IE5ldHdvcmsgT3B0aW1pemF0aW9uIHVzaW5nIERX RE0gDQo+IEludGVyZmFjZXPigJ0sIHdhcyBwdWJsaXNoZWQgSnVuZSAyMDE1IG8gVFItMzE5IFBh cnQgQSwg4oCcQWNoaWV2aW5nIA0KPiBQYWNrZXQgTmV0d29yayBPcHRpbWl6YXRpb24gdXNpbmcg RFdETSBJbnRlcmZhY2VzIOKAkyBQaHlzaWNhbGx5IA0KPiBJbnRlZ3JhdGVkIE1vZGVs4oCdLCB3 YXMgcHVibGlzaGVkIEp1bmUgMjAxNQ0KPiANCj4gV1QtMzE5IFBhcnQgQiwgQWNoaWV2aW5nIFBh Y2tldCBOZXR3b3JrIE9wdGltaXphdGlvbiB1c2luZyBEV0RNIA0KPiBJbnRlcmZhY2VzIOKAkyBQ aHlzaWNhbGx5IFNlcGFyYXRlZCwgTG9naWNhbGx5IFNlcGFyYXRlZCwgaXMgdW5kZXJnb2luZyAN Cj4gU3RyYXcgQmFsbG90IChzaW1pbGFyIHRvIElFVEYgV0cgTGFzdCBDYWxsKSwgYW5kIHdlIGFy ZSBhdHRhY2hpbmcgaXQgZm9yIHlvdXIgcmV2aWV3IGFuZCBjb21tZW50Lg0KPiANCj4gT3VyIGJh bGxvdCBwZXJpb2QgY2xvc2VzIG9uIE5vdmVtYmVyIDgsIDIwMTUuIElmIGl0IGlzIGF0IGFsbCAN Cj4gcG9zc2libGUsIHdlIHdvdWxkIGFwcHJlY2lhdGUgYW5kIGxvb2sgZm9yd2FyZCB0byBhbnkg aW5wdXQgaW4gdGltZSANCj4gZm9yIG91ciBiYWxsb3QgY2xvc2UuIFRoZSBuZXh0IG1lZXRpbmcg b2YgQkJGIG9jY3VycyBOb3ZlbWJlciAxNiwgDQo+IDIwMTUuIEEgc2NoZWR1bGUgb2Ygb3VyIGZ1 dHVyZSBtZWV0aW5ncyBhcHBlYXJzIGJlbG93Lg0KPiANCj4gV2Ugd2FudCB0byBleHByZXNzIG91 ciBhcHByZWNpYXRpb24gZm9yIHlvdXIgY29udGludWVkIGNvbnNpZGVyYXRpb24gDQo+IG9mIHRo aXMgaW1wb3J0YW50IHRvcGljLg0KPiANCj4gU2luY2VyZWx5LA0KPiBNaWNoYWVsIEZhcmdhbm8s DQo+IEJyb2FkYmFuZCBGb3J1bSBUZWNobmljYWwgQ29tbWl0dGVlIENoYWlyDQo+IA0KPiBEYXRl IG9mIFVwY29taW5nIEJyb2FkYmFuZCBGb3J1bSBNZWV0aW5ncyBEQVRFUyBMT0NBVElPTiBOb3Zl bWJlciAxNiDigJMgDQo+IDIwLCAyMDE1IFB1ZXJ0byBWYWxsYXJ0YSwgTWV4aWNvIEZlYnJ1YXJ5 IDEg4oCTIDUsIDIwMTYgQXNpYSBQYWMgDQo+IChwcmVjaXNlIGxvY2F0aW9uIFRCRCkNCj4gDQo+ IE5vdGU6IEEgbGlzdCBvZiB1cGNvbWluZyBtZWV0aW5ncyBjYW4gYWxzbyBiZSBmb3VuZCBhdCAN Cj4gaHR0cDovL3d3dy5icm9hZGJhbmRmb3J1bS4NCj4gb3JnL21lZXRpbmdzL3VwY29taW5nbWVl dGluZ3NhdGFnbGFuY2UucGhwDQo+IA0KPiBBdHRhY2htZW50czoNCj4gwqcgV1QtMzE5IFBhcnQg QiBTdHJhdyBCYWxsb3QgVGV4dCAoYmJmMjAxNS4wNzEuMDcpDQo+IEF0dGFjaG1lbnRzOg0KPiAN Cj4gICAgIEF0dGFjaG1lbnQNCj4gICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2xpYi9kdC9kb2N1 bWVudHMvTElBSVNPTi9saWFpc29uLTIwMTUtMTAtMTYtDQo+IGJyb2FkYmFuZC1mb3J1bS1ydGct Y2NhbXAtdGVhcy1hY2hpZXZpbmctcGFja2V0LW5ldHdvcmstb3B0aW1pemF0aW9uLQ0KPiB1c2lu Zy1kd2RtLWludGVyZmFjZXMtYXR0YWNobWVudC0xLnBkZg0KPiANCj4gICAgIFN0YXRlbWVudA0K PiAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbGliL2R0L2RvY3VtZW50cy9MSUFJU09OL2xpYWlz b24tMjAxNS0xMC0xNi0NCj4gYnJvYWRiYW5kLWZvcnVtLXJ0Zy1jY2FtcC10ZWFzLWFjaGlldmlu Zy1wYWNrZXQtbmV0d29yay1vcHRpbWl6YXRpb24tDQo+IHVzaW5nLWR3ZG0taW50ZXJmYWNlcy1h dHRhY2htZW50LTIucGRmDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpDQ0FNUCBtYWlsaW5nIGxpc3QNCkNDQU1QQGlldGYub3JnDQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQo= From nobody Thu Oct 29 03:56:07 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB651B2D1B for ; Thu, 29 Oct 2015 03:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.17 X-Spam-Level: X-Spam-Status: No, score=-0.17 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, SPF_SOFTFAIL=0.665, T_RP_MATCHES_RCVD=-0.01] 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 EJImv03n4GYf for ; Thu, 29 Oct 2015 03:56:05 -0700 (PDT) Received: from p-mail2.rd.orange.com (p-mail2.rd.orange.com [161.106.1.3]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE181B2D18 for ; Thu, 29 Oct 2015 03:56:04 -0700 (PDT) Received: from p-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8E03FE300A7; Thu, 29 Oct 2015 11:56:03 +0100 (CET) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail2.rd.orange.com (Postfix) with ESMTP id D8278E300A1; Thu, 29 Oct 2015 11:56:02 +0100 (CET) Received: from [10.193.71.204] (10.193.71.204) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.224.2; Thu, 29 Oct 2015 11:56:02 +0100 To: Ina Minei References: <20151019165623.31126.73598.idtracker@ietfa.amsl.com> From: Julien Meuric Organization: Orange Message-ID: <5631FB42.40209@orange.com> Date: Thu, 29 Oct 2015 11:56:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit Archived-At: Cc: pce Subject: Re: [Pce] I-D Action: draft-ietf-pce-pce-initiated-lsp-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2015 10:56:06 -0000 Hi Ina,

Please note that there are pending questions on this I-D: https://mailarchive.ietf.org/arch/msg/pce/wn4gGwZnTZS53pbyg1eCHw3YMVE

Thanks,

Julien


Oct. 19, 2015 - inaminei@google.com:
This is just a version refresh, to prevent the draft from expiring, no changes were made to the draft. 


On Mon, Oct 19, 2015 at 9:56 AM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Path Computation Element Working Group of the IETF.

        Title           : PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model
        Authors         : Edward Crabbe
                          Ina Minei
                          Siva Sivabalan
                          Robert Varga
        Filename        : draft-ietf-pce-pce-initiated-lsp-05.txt
        Pages           : 17
        Date            : 2015-10-19

Abstract:
   The Path Computation Element Communication Protocol (PCEP) provides
   mechanisms for Path Computation Elements (PCEs) to perform path
   computations in response to Path Computation Clients (PCCs) requests.

   The extensions for stateful PCE provide stateful control of
   Multiprotocol Label Switching (MPLS) Traffic Engineering Label
   Switched Paths (TE LSP) via PCEP, for a model where the PCC delegates
   control over one or more locally configured LSPs to the PCE.  This
   document describes the creation and deletion of PCE-initiated LSPs
   under the stateful PCE model.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-pce-initiated-lsp/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-pce-pce-initiated-lsp-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pce-initiated-lsp-05


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/

_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce



_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

From nobody Sat Oct 31 20:27:55 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 862E71ACEC3; Sat, 31 Oct 2015 20:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, 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 tqV4qf1ij03Z; Sat, 31 Oct 2015 20:27:47 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13CD01ACE08; Sat, 31 Oct 2015 20:27:45 -0700 (PDT) X-AuditID: c1b4fb25-f79a26d00000149a-21-563586b0bb3a Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 0D.1E.05274.0B685365; Sun, 1 Nov 2015 04:27:44 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.238]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0248.002; Sun, 1 Nov 2015 04:27:06 +0100 From: Daniele Ceccarelli To: Zhenghaomian , "'ccamp@ietf.org'" , "pce@ietf.org" , TEAS WG Thread-Topic: =?utf-8?B?SW5pdGlhbCB2ZXJzaW9uIGZvciBsaWFpc29uIHRleHQgLy/nrZTlpI06IENB?= =?utf-8?B?TEwgRk9SIFZPTFVOVEVFUiAtICBOZXcgTGlhaXNvbiBTdGF0ZW1lbnQsICJB?= =?utf-8?B?Y2hpZXZpbmcgUGFja2V0IE5ldHdvcmsgT3B0aW1pemF0aW9uIHVzaW5nIERX?= =?utf-8?Q?DM_Interfaces"?= Thread-Index: AdEQlwg0nBSjolVUTpmgrTvatjXCNADvVDxA Date: Sun, 1 Nov 2015 03:27:05 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE4812AC1963@ESESSMB301.ericsson.se> References: In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_4A1562797D64E44993C5CBF38CF1BE4812AC1963ESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIIsWRmVeSWpSXmKPExsUyM2K7nO6GNtMwgxNn+SyezLnBYtF0/wa7 ReuPHSwWX/dlObB4tBx5y+qxZMlPpgCmKC6blNSczLLUIn27BK6MH7fnsxYs2MNccbdpJ1sD 440NzF2MnBwSAiYSCx4eZIWwxSQu3FvP1sXIxSEkcJhRYuHa81DOYkaJN3d3MHYxcnCwCVhJ PDnkAxIXEehklNh/aRMziCMs0MEk8bp9MStUhkniwLrn7CBzRQSMJA7unwe2g0VARWL9vPVM IDavgK/Ez9WnGEFsIYFQiflfp4DdxCkQJrHl0USwGkYBWYkJuxeB1TALiEvcejKfCeJWAYkl e85D/SAq8fLxP6gflCRWbL8EVZ8vMfn6cTaIXYISJ2c+YZnAKDILyahZSMpmISmbBfQos4Cm xPpd+hAlihJTuh+yQ9gaEq1z5rIjiy9gZF/FKFqcWpyUm25krJdalJlcXJyfp5eXWrKJERhx B7f8Vt3BePmN4yFGAQ5GJR7eDfymYUKsiWXFlbmHGCU4mJVEeBfFA4V4UxIrq1KL8uOLSnNS iw8xSnOwKInzNjM9CBUSSE8sSc1OTS1ILYLJMnFwSjUwVibXdd+ZtveK3PI5C/geTXH3VNa4 kTMh+pbmEt7TCnUGwV4Hm8W/vtqern1NNbZFTmuy45kNhe3TSm4rTuflMM88Pq+J43HSmod1 DRf28Nplx878qd5q83/Z2rVHKw5qRnP++JiXYPt+Z5DafFvnK5f+PW1lELlxcvo6btnDcXvP i1+eX7giW4mlOCPRUIu5qDgRAORk/KO0AgAA Archived-At: Subject: Re: [Pce] =?utf-8?q?Initial_version_for_liaison_text_//=E7=AD=94?= =?utf-8?q?=E5=A4=8D=3A_CALL_FOR_VOLUNTEER_-__New_Liaison_Statement=2C_=22?= =?utf-8?q?Achieving_Packet_Network_Optimization_using_DWDM_Interfaces=22?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2015 03:27:52 -0000 --_000_4A1562797D64E44993C5CBF38CF1BE4812AC1963ESESSMB301erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSGFvbWlhbiwgYWxsLA0KDQoNCg0KVGhhbmtzIGZvciBzdGFydGluZyBwdXR0aW5nIHRvZ2V0 aGVyIHRoZSByZXBseS4gUGxlYXNlIGZpbmQgc29tZSB1cGRhdGVkIHByb3Bvc2FscyBmcm9tIG15 IHNpZGUuDQoNCg0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KVGhlIHdvcmtpbmcg Z3JvdXBzIGluIElFVEYgcm91dGluZyBhcmVhIHdvdWxkIGxpa2UgdG8gdGhhbmsgeW91IGZvciBz ZW5kaW5nIHRoaXMgbGlhaXNvbi4gV2UgbXVjaCBhcHByZWNpYXRlIEJCRiBvbiB0aGUgZWZmb3J0 IG9mIHBhY2tldCBvdmVyIG9wdGljYWwsIGFuZCBzZW5kaW5nIHRoZSBkb2N1bWVudCB0byBJRVRG IENDQU1QLCBURUFTIGFuZCBQQ0UgV0dzIGZvciByZXZpZXcuIFRoaXMgcHJvamVjdCBkZWZpbmVz IGEgc2V0IG9mIGNvbnRyb2wgcGxhbmUgcmVxdWlyZW1lbnRzIHRoYXQgdGhlIFBoeXNpY2FsbHkg U2VwYXJhdGVkIE1vZGVsIHNob3VsZCBiZSBzYXRpc2ZpZWQuIFdlIGhhdmUgc29tZSBxdWVzdGlv bnMgYW5kIGNvbW1lbnRzOg0KDQoNCg0KUXVlc3Rpb25zOg0KDQrCtyAgICAgICAgIEl0IGlzIG5v dCBjbGVhciB0byB1cyBob3cgdGhlIGNvbW11bmljYXRpb24gYmV0d2VlbiB0aGUgcGFja2V0IGxh eWVyIGFuZCB0aGUgb3B0aWNhbCBsYXllciBvY2N1cnMuIEUuZy4gY29udHJvbCBjaGFubmVscywg c2lnbmFsaW5nIGFuZCBzbyBvbi4NCg0KwrcgICAgICAgICBXZSB3b3VsZCBsaWtlIHRvIHNlZSBz b21lIG1vcmUgZGV0YWlscyBvbiB0aGUgbWFuYWdlbWVudCBhc3BlY3RzIGJldHdlZW4gdGhlIHBh Y2tldCBkb21haW4gYW5kIHRoZSBvcHRpY2FsIGRvbWFpbi4NCg0KQ29tbWVudHM6DQoNCsK3ICAg ICAgICAgV2hlbiByZWZlcnJpbmcgdG8gUENFIGFuZCByZWxhdGVkIGlzc3VlcywgZS5nLiwgaW4g W1ItMjZdIGFuZCBbUi0yN10sIGl0IHNlZW1zIG9ubHkgc3RhdGVsZXNzIFBDRSAoUkZDNDY1NSkg YW5kIGNvcnJlc3BvbmRpbmcgUENFUCAoUkZDNTUyMCkgYXJlIGluY2x1ZGVkIGluIHRoZSBjdXJy ZW50IHZlcnNpb24uIEFzIElFVEYgUENFIHdvcmtpbmcgZ3JvdXAgaXMgaW52ZXN0aWdhdGluZyBv biBzdGF0ZWZ1bCBQQ0UsIFBDRSBJbml0aWF0aW9uIGFuZCBQQ0UgYXMgYSBDZW50cmFsIENvbnRy b2xsZXIsIHdoaWNoIGFyZSBwbGFubmVkIHRvIGJlIHB1Ymxpc2hlZCBpbiB0aGUgZnV0dXJlLCBp dCBpcyBiZXR0ZXIgdG8gc3BlY2lmeSB3aGljaCBraW5kIG9mIFBDRSBpcyBub3cgcmVmZXJyZWQg YnkgdGhpcyBkb2N1bWVudHMuIE1vcmVvdmVyLCBSRkMgNTYyMywgUENFLWJhc2VkIGludGVyLWxh eWVyIE1QTFMgYW5kIEdNUExTIFRyYWZmaWMgRW5naW5lZXJpbmcsIG1heSBiZSBhIGdvb2QgcmVm ZXJlbmNlIGZvciB0aGlzIGRvY3VtZW50Lg0KDQrCtyAgICAgICAgIEluIHNlY3Rpb24gNC40IHdo ZW4gdGFsa2luZyBhYm91dCBTRE4sIE9wZW5mbG93IGlzIG1lbnRpb25lZCBhcyBhIHN0YW5kYXJk IHByb3RvY29sIHRvIGludGVyYWN0IGJldHdlZW4gcGFja2V0IG5vZGVzIGFuZCBEV0RNIG5vZGVz LiBXZSB3b3VsZCBsaWtlIHRvIHN1Z2dlc3QgYWRkIFBDRSBQcm90b2NvbCAoUENFUCkgYXMgYW5v dGhlciBleGFtcGxlLCBhcyBpdCBpcyBjdXJyZW50bHkgdXNlZCBpbiBJRVRGLiBCZXNpZGVzLCBp dCBpcyBzdWdnZXN0IHRvIHJlZmVyZW5jZSB0byBSRkMgMzQxMyBhYm91dCBTTk1QLCBhbmQgUkZD IDQyMDggYWJvdXQgR01QTFMgVU5JLg0KDQrCtyAgICAgICAgIEluIHNlY3Rpb24gNC41LCBbUi0z Nl0gaXMgbm90IGNsZWFyIHdoZXRoZXIgdG8gYmUgYXBwbGllZCB0byB0aGUgbm9ydGgtYm91bmQg b2YgU0ROIGNvbnRyb2xsZXIsIG9yIGJldHdlZW4gdGhlIHBhY2tldCBORSBhbmQgU0ROIGNvbnRy b2xsZXIuIFdlIHByZWZlciB0aGUgbGF0dGVyIG9uZS4NCg0KDQoNCkl0IHNlZW1zIHRvIHVzIHRo ZSByZXF1aXJlbWVudHMgcHJvcG9zZWQgaW4gdGhlIGN1cnJlbnQgZG9jdW1lbnQgY291bGQgYmUg YWRkcmVzc2VkIGJ5IHRoZSByZWZlcmVuY2VkIFJGQ3MgZGVmaW5lZCBmb3IgR01QTFMsIHNvIHdl IHdvdWxkIGxpa2UgdG8gbWFrZSBzdXJlIGlmIHlvdSBoYXZlIGlkZW50aWZpZWQgYW55IGdhcHMs IHdoaWNoIG5lZWQgYW4gdXBkYXRlIG9uIEdNUExTL1BDRVAgdG8gc2F0aXNmeSB0aGVzZSByZXF1 aXJlbWVudHMuIElFVEYgQ0NBTVAgaXMgZGlzY3Vzc2luZyB0byBkZWZpbmUgYSBmcmFtZXdvcmsg Zm9yIE1hbmFnZW1lbnQgYW5kIENvbnRyb2wgb2YgRFdETSBvcHRpY2FsIGludGVyZmFjZSBwYXJh bWV0ZXJzIGFuZCBHTVBMUyBwcm90b2NvbHMgdGhhdCBuZWVkIHRvIGJlIHVwZGF0ZWQsIHdoaWNo IG1pZ2h0IGJlIHJlbGV2YW50IHRvIHlvdXIgcHJvamVjdCwgYnV0IHRoaXMgd29yayBpbiBDQ0FN UCBpcyBzdGlsbCBpbiBpbmRpdmlkdWFsIGRyYWZ0cyBzdGFnZS4gV2Ugd291bGQgbGlrZSB0byBy ZWNlaXZlIHlvdXIgaW5wdXQuDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KDQoN ClRoYW5rcw0KDQpEYW5pZWxlDQoNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoN Cj4gRnJvbTogQ0NBTVAgW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgWmhlbmdoYW9taWFuDQoNCj4gU2VudDogbWFydGVkw6wgMjcgb3R0b2JyZSAyMDE1IDE4OjE3 DQoNCj4gVG86ICdjY2FtcEBpZXRmLm9yZyc7IHBjZUBpZXRmLm9yZzsgVEVBUyBXRw0KDQo+IFN1 YmplY3Q6IFtDQ0FNUF0gSW5pdGlhbCB2ZXJzaW9uIGZvciBsaWFpc29uIHRleHQgLy/nrZTlpI06 IENBTEwgRk9SDQoNCj4gVk9MVU5URUVSIC0gTmV3IExpYWlzb24gU3RhdGVtZW50LCAiQWNoaWV2 aW5nIFBhY2tldCBOZXR3b3JrDQoNCj4gT3B0aW1pemF0aW9uIHVzaW5nIERXRE0gSW50ZXJmYWNl cyINCg0KPg0KDQo+IEhpLCBBbGwsDQoNCj4NCg0KPiBBZnRlciByZXZpZXdpbmcgdGhlIGxpYWlz b24gYW5kIGRvY3VtZW50IGZyb20gQkJGLCB3ZSB3b3VsZCBsaWtlIHRvIHByb3ZpZGUNCg0KPiB0 aGUgZm9sbG93aW5nIHRleHQgYXMgYW4gaW5pdGlhbCB2ZXJzaW9uIGZvciByZXNwb25zZS4gUGxl YXNlIGhlbHAgcmV2aWV3LCB5b3VyDQoNCj4gY29tbWVudHMgYXJlIGhpZ2hseSB3ZWxjb21lZC4N Cg0KPg0KDQo+ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT1mb3INCg0KPiBk aXNjdXNzaW9uPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 DQoNCj4gVGhlIHdvcmtpbmcgZ3JvdXBzIGluIElFVEYgcm91dGluZyBhcmVhIHdvdWxkIGxpa2Ug dG8gdGhhbmsgeW91IGZvciBzZW5kaW5nDQoNCj4gdGhpcyBsaWFpc29uLiBXZSBtdWNoIGFwcHJl Y2lhdGUgQkJGIG9uIHRoZSBlZmZvcnQgb2YgcGFja2V0IG92ZXIgb3B0aWNhbCwgYW5kDQoNCj4g c2VuZGluZyB0aGUgZG9jdW1lbnQgdG8gSUVURiBDQ0FNUCwgVEVBUyBhbmQgUENFIFdHcyBmb3Ig cmV2aWV3LiBUaGlzDQoNCj4gcHJvamVjdCBkZWZpbmVzIGEgc2V0IG9mIGNvbnRyb2wgcGxhbmUg cmVxdWlyZW1lbnRzIHRoYXQgdGhlIFBoeXNpY2FsbHkNCg0KPiBTZXBhcmF0ZWQgTW9kZWwgc2hv dWxkIGJlIHNhdGlzZmllZC4gV2UgYXJlIGdlbmVyYWxseSBmaW5lIGFib3V0IHRoZQ0KDQo+IGNv bnRlbnQsIHdpdGggc29tZSBtaW5vciBzdWdnZXN0aW9ucyBsaXN0ZWQgYXMgZm9sbG93IGZvciB5 b3VyIHJlZmVyZW5jZToNCg0KPg0KDQo+IOKAoiBXaGVuIHJlZmVycmluZyB0byBQQ0UgYW5kIHJl bGF0ZWQgaXNzdWVzLCBlLmcuLCBpbiBbUi0yNl0gYW5kIFtSLTI3XSwgaXQNCg0KPiBzZWVtcyBv bmx5IHN0YXRlbGVzcyBQQ0UgKFJGQzQ2NTUpIGFuZCBjb3JyZXNwb25kaW5nIFBDRVAgKFJGQzU1 MjApIGFyZQ0KDQo+IGluY2x1ZGVkIGluIHRoZSBjdXJyZW50IHZlcnNpb24uIEFzIElFVEYgUENF IHdvcmtpbmcgZ3JvdXAgaXMgaW52ZXN0aWdhdGluZyBvbg0KDQo+IHN0YXRlZnVsIFBDRSwgUENF IEluaXRpYXRpb24gYW5kIFBDRSBhcyBhIENlbnRyYWwgQ29udHJvbGxlciwgd2hpY2ggYXJlIHBs YW5uZWQNCg0KPiB0byBiZSBwdWJsaXNoZWQgaW4gdGhlIGZ1dHVyZSwgaXQgaXMgYmV0dGVyIHRv IHNwZWNpZnkgd2hpY2gga2luZCBvZiBQQ0UgaXMgbm93DQoNCj4gcmVmZXJyZWQgYnkgdGhpcyBk b2N1bWVudHMuIE1vcmVvdmVyLCBSRkMgNTYyMywgUENFLWJhc2VkIGludGVyLWxheWVyDQoNCj4g TVBMUyBhbmQgR01QTFMgVHJhZmZpYyBFbmdpbmVlcmluZywgbWF5IGJlIGEgZ29vZCByZWZlcmVu Y2UgZm9yIHRoaXMNCg0KPiBkb2N1bWVudC4NCg0KPiDigKIgSW4gc2VjdGlvbiA0LjQgd2hlbiB0 YWxraW5nIGFib3V0IFNETiwgT3BlbmZsb3cgaXMgbWVudGlvbmVkIGFzIGENCg0KPiBzdGFuZGFy ZCBwcm90b2NvbCB0byBpbnRlcmFjdCBiZXR3ZWVuIHBhY2tldCBub2RlcyBhbmQgRFdETSBub2Rl cy4gV2UNCg0KPiB3b3VsZCBsaWtlIHRvIHN1Z2dlc3QgYWRkIFBDRSBQcm90b2NvbCAoUENFUCkg YXMgYW5vdGhlciBleGFtcGxlLCBhcyBpdCBpcw0KDQo+IGN1cnJlbnRseSB1c2VkIGluIElFVEYu IEJlc2lkZXMsIGl0IGlzIHN1Z2dlc3QgdG8gcmVmZXJlbmNlIHRvIFJGQyAzNDEzIGFib3V0DQoN Cj4gU05NUCwgYW5kIFJGQyA0MjA4IGFib3V0IEdNUExTIFVOSS4NCg0KPiDigKIgSW4gc2VjdGlv biA0LjUsIFtSLTM2XSBpcyBub3QgY2xlYXIgd2hldGhlciB0byBiZSBhcHBsaWVkIHRvIHRoZSBu b3J0aC1ib3VuZA0KDQo+IG9mIFNETiBjb250cm9sbGVyLCBvciBiZXR3ZWVuIHRoZSBwYWNrZXQg TkUgYW5kIFNETiBjb250cm9sbGVyLiBXZSBwcmVmZXINCg0KPiB0aGUgbGF0dGVyIG9uZS4NCg0K Pg0KDQo+IEl0IHNlZW1zIHRvIHVzIHRoZSByZXF1aXJlbWVudHMgcHJvcG9zZWQgaW4gdGhlIGN1 cnJlbnQgZG9jdW1lbnQgY291bGQgYmUNCg0KPiBhZGRyZXNzZWQgYnkgdGhlIHJlZmVyZW5jZWQg UkZDcyBkZWZpbmVkIGZvciBHTVBMUywgc28gd2Ugd291bGQgbGlrZSB0bw0KDQo+IG1ha2Ugc3Vy ZSBpZiB5b3UgaGF2ZSBpZGVudGlmaWVkIGFueSBnYXBzLCB3aGljaCBuZWVkIGFuIHVwZGF0ZSBv biBHTVBMUw0KDQo+IHRvIHNhdGlzZnkgdGhlc2UgcmVxdWlyZW1lbnRzLiBJRVRGIENDQU1QIGlz IGRpc2N1c3NpbmcgdG8gZGVmaW5lIGENCg0KPiBmcmFtZXdvcmsgZm9yIE1hbmFnZW1lbnQgYW5k IENvbnRyb2wgb2YgRFdETSBvcHRpY2FsIGludGVyZmFjZQ0KDQo+IHBhcmFtZXRlcnMgYW5kIEdN UExTIHByb3RvY29scyB0aGF0IG5lZWQgdG8gYmUgdXBkYXRlZCwgd2hpY2ggbWlnaHQgYmUNCg0K PiByZWxldmFudCB0byB5b3VyIHByb2plY3QsIGJ1dCB0aGlzIHdvcmsgaW4gQ0NBTVAgaXMgc3Rp bGwgaW4gaW5kaXZpZHVhbCBkcmFmdHMNCg0KPiBzdGFnZS4gV2Ugd291bGQgbGlrZSB0byByZWNl aXZlIHlvdXIgaW5wdXQuDQoNCj4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PQ0KDQo+ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNCj4NCg0KPiBUaGFua3MuDQoNCj4NCg0KPiBC ZXN0IHdpc2hlcywNCg0KPiBIYW9taWFuDQoNCj4NCg0KPiAtLS0tLemCruS7tuWOn+S7ti0tLS0t DQoNCj4g5Y+R5Lu25Lq6OiBaaGVuZ2hhb21pYW4NCg0KPiDlj5HpgIHml7bpl7Q6IDIwMTXlubQx MOaciDIx5pelIDExOjExDQoNCj4g5pS25Lu25Lq6OiBEYW5pZWxlIENlY2NhcmVsbGk7IEZhdGFp IFpoYW5nDQoNCj4g5oqE6YCBOiBjY2FtcEBpZXRmLm9yZzxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+ DQoNCj4g5Li76aKYOiDnrZTlpI06IENBTEwgRk9SIFZPTFVOVEVFUiAtIE5ldyBMaWFpc29uIFN0 YXRlbWVudCwgIkFjaGlldmluZw0KDQo+IFBhY2tldCBOZXR3b3JrIE9wdGltaXphdGlvbiB1c2lu ZyBEV0RNIEludGVyZmFjZXMiDQoNCj4NCg0KPiBEYW5pZWxlLCBGYXRhaSBhbmQgQWxsLA0KDQo+ DQoNCj4gSSB3b3VsZCBsaWtlIHRvIHZvbHVudGVlciBmb3IgZ2VuZXJhdGluZyB0aGUgcmVzcG9u c2UgbGlhaXNvbiwgYXMgdGhlIHRvcGljIGlzDQoNCj4gaGlnaGx5IHJlbGF0ZWQgdG8gbXkgcmVz ZWFyY2ggd29yay4gSSB3aWxsIHJldmlldyB0aGUgZG9jdW1lbnQgYW5kIHNoYXJlIG15DQoNCj4g Y29tbWVudHMgZWFybHkgbmV4dCB3ZWVrLiBQbGVhc2UgYWxzbyBmZWVsIGZyZWUgdG8gc2hhcmUg eW91ciBvcGluaW9uLA0KDQo+IHRoYW5rcy4NCg0KPg0KDQo+IEJlc3Qgd2lzaGVzLA0KDQo+IEhh b21pYW4NCg0KPg0KDQo+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCg0KPiDlj5Hku7bkuro6IEND QU1QIFttYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIERhbmllbGUgQ2VjY2Fy ZWxsaQ0KDQo+IOWPkemAgeaXtumXtDogMjAxNeW5tDEw5pyIMjDml6UgMjM6NDYNCg0KPiDmlLbk u7bkuro6IENDQU1QIChjY2FtcEBpZXRmLm9yZzxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+KQ0KDQo+ IOS4u+mimDogW0NDQU1QXSBDQUxMIEZPUiBWT0xVTlRFRVIgLSBOZXcgTGlhaXNvbiBTdGF0ZW1l bnQsICJBY2hpZXZpbmcNCg0KPiBQYWNrZXQgTmV0d29yayBPcHRpbWl6YXRpb24gdXNpbmcgRFdE TSBJbnRlcmZhY2VzIg0KDQo+DQoNCj4gV0csDQoNCj4NCg0KPiBXZSByZWNlaXZlZCB0aGlzIGxp YWlzb24gZnJvbSBCQkYgb24gUGFja2V0LU9wdGljYWwgaW50ZWdyYXRpb24uDQoNCj4gSSdtIGNv cHlpbmcgdGhlIGxpbmtzIHRvIGxpYWlzb24gYW5kIGF0dGFjaG1lbnQgaGVyZSBmb3IgeW91ciBj b252ZW5pZW5jZQ0KDQo+IExpYWlzb246ICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2xp YWlzb24vMTQzMi8NCg0KPiBBdHRhY2htZW50OiBodHRwczovL3d3dy5pZXRmLm9yZy9saWIvZHQv ZG9jdW1lbnRzL0xJQUlTT04vbGlhaXNvbi0yMDE1LTxodHRwczovL3d3dy5pZXRmLm9yZy9saWIv ZHQvZG9jdW1lbnRzL0xJQUlTT04vbGlhaXNvbi0yMDE1LTEwLTE2LWJyb2FkYmFuZC1mb3J1bS1y dGctY2NhbXAtdGVhcy1hY2hpZXZpbmctcGFja2V0LW5ldHdvcmstb3B0aW1pemF0aW9uLXVzaW5n LWR3ZG0taW50ZXJmYWNlcy1hdHRhY2htZW50LTEucGRmPg0KDQo+IDEwLTE2LWJyb2FkYmFuZC1m b3J1bS1ydGctY2NhbXAtdGVhcy1hY2hpZXZpbmctcGFja2V0LW5ldHdvcmstPGh0dHBzOi8vd3d3 LmlldGYub3JnL2xpYi9kdC9kb2N1bWVudHMvTElBSVNPTi9saWFpc29uLTIwMTUtMTAtMTYtYnJv YWRiYW5kLWZvcnVtLXJ0Zy1jY2FtcC10ZWFzLWFjaGlldmluZy1wYWNrZXQtbmV0d29yay1vcHRp bWl6YXRpb24tdXNpbmctZHdkbS1pbnRlcmZhY2VzLWF0dGFjaG1lbnQtMS5wZGY+DQoNCj4gb3B0 aW1pemF0aW9uLXVzaW5nLWR3ZG0taW50ZXJmYWNlcy1hdHRhY2htZW50LTEucGRmPGh0dHBzOi8v d3d3LmlldGYub3JnL2xpYi9kdC9kb2N1bWVudHMvTElBSVNPTi9saWFpc29uLTIwMTUtMTAtMTYt YnJvYWRiYW5kLWZvcnVtLXJ0Zy1jY2FtcC10ZWFzLWFjaGlldmluZy1wYWNrZXQtbmV0d29yay1v cHRpbWl6YXRpb24tdXNpbmctZHdkbS1pbnRlcmZhY2VzLWF0dGFjaG1lbnQtMS5wZGY+DQoNCj4N Cg0KPiBXZSdkIHJlYWxseSBsaWtlIDEgb3IgMiB2b2x1bnRlZXJzIGludGVyZXN0ZWQgaW4gdGhl IHRvcGljIHRvIGRyYWZ0IGFuIGFuc3dlciB0bw0KDQo+IHRoZSBsaWFpc29uIGJlZm9yZSB0aGUg bWVldGluZyBpbiBZb2tvaGFtYSBzbyB0byBiZSBhYmxlIHRvIGRpc2N1c3MgaXQgb24gdGhlDQoN Cj4gbGlzdCBhbmQgcmVwbHkgZHVyaW5nIG9yIGltbWVkaWF0ZWx5IGFmdGVyIHRoZSBtZWV0aW5n Lg0KDQo+DQoNCj4gUGxlYXNlIGNvbnNpZGVyIHZvbHVudGVlcmluZy4NCg0KPiBUaGFua3MNCg0K PiBGYXRhaSAmIERhbmllbGUNCg0KPg0KDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cg0KPiA+IEZyb206IExpYWlzb24gU3RhdGVtZW50IE1hbmFnZW1lbnQgVG9vbCBbbWFpbHRvOmxz bXRAaWV0Zi5vcmddDQoNCj4gPiBTZW50OiB2ZW5lcmTDrCAxNiBvdHRvYnJlIDIwMTUgMjI6MDUN Cg0KPiA+IFRvOiBkYjM1NDZAYXR0LmNvbTxtYWlsdG86ZGIzNTQ2QGF0dC5jb20+OyB2YmVlcmFt QGp1bmlwZXIubmV0PG1haWx0bzp2YmVlcmFtQGp1bmlwZXIubmV0PjsgYWthdGxhc0BnbWFpbC5j b208bWFpbHRvOmFrYXRsYXNAZ21haWwuY29tPjsNCg0KPiA+IGFyZXRhbmFAY2lzY28uY29tPG1h aWx0bzphcmV0YW5hQGNpc2NvLmNvbT47IGxiZXJnZXJAbGFibi5uZXQ8bWFpbHRvOmxiZXJnZXJA bGFibi5uZXQ+OyB6aGFuZ2ZhdGFpQGh1YXdlaS5jb208bWFpbHRvOnpoYW5nZmF0YWlAaHVhd2Vp LmNvbT47IERhbmllbGUNCg0KPiA+IENlY2NhcmVsbGkNCg0KPiA+IENjOiBBbHZhcm8gUmV0YW5h OyBEZWJvcmFoIEJydW5nYXJkOyBEYXZpZCBTaW5pY3JvcGU7IEZhdGFpIFpoYW5nOw0KDQo+ID4g QWxpYSBBdGxhczsgVmlzaG51IFBhdmFuIEJlZXJhbTsgVGhlIElFVEYgQ2hhaXI7IERhbmllbGUg Q2VjY2FyZWxsaTsNCg0KPiA+IExvdSBCZXJnZXI7IENvbW1vbiBDb250cm9sIGFuZCBNZWFzdXJl bWVudCBQbGFuZSBEaXNjdXNzaW9uIExpc3Q7DQoNCj4gPiBtaWNoYWVsLmZhcmdhbm9AY2VudHVy eWxpbmsuY29tPG1haWx0bzptaWNoYWVsLmZhcmdhbm9AY2VudHVyeWxpbmsuY29tPjsgVHJhZmZp YyBFbmdpbmVlcmluZyBBcmNoaXRlY3R1cmUgYW5kDQoNCj4gPiBTaWduYWxpbmcgRGlzY3Vzc2lv biBMaXN0DQoNCj4gPiBTdWJqZWN0OiBOZXcgTGlhaXNvbiBTdGF0ZW1lbnQsICJBY2hpZXZpbmcg UGFja2V0IE5ldHdvcmsgT3B0aW1pemF0aW9uDQoNCj4gPiB1c2luZyBEV0RNIEludGVyZmFjZXMi DQoNCj4gPg0KDQo+ID4gVGl0bGU6IEFjaGlldmluZyBQYWNrZXQgTmV0d29yayBPcHRpbWl6YXRp b24gdXNpbmcgRFdETSBJbnRlcmZhY2VzDQoNCj4gPiBTdWJtaXNzaW9uIERhdGU6IDIwMTUtMTAt MTYgVVJMIG9mIHRoZSBJRVRGIFdlYiBwYWdlOg0KDQo+ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9saWFpc29uLzE0MzIvDQoNCj4gPiBQbGVhc2UgcmVwbHkgYnkgMjAxNS0xMS0wOA0K DQo+ID4gRnJvbTogIChEYXZpZCBTaW5pY3JvcGUgPGRhdmlkLnNpbmljcm9wZUBlcmljc3Nvbi5j b208bWFpbHRvOmRhdmlkLnNpbmljcm9wZUBlcmljc3Nvbi5jb20+PikNCg0KPiA+IFRvOiAgKHZi ZWVyYW1AanVuaXBlci5uZXQ8bWFpbHRvOnZiZWVyYW1AanVuaXBlci5uZXQ+LCBsYmVyZ2VyQGxh Ym4ubmV0PG1haWx0bzpsYmVyZ2VyQGxhYm4ubmV0PiwgYWthdGxhc0BnbWFpbC5jb208bWFpbHRv OmFrYXRsYXNAZ21haWwuY29tPiwNCg0KPiA+IGFyZXRhbmFAY2lzY28uY29tPG1haWx0bzphcmV0 YW5hQGNpc2NvLmNvbT4sIGRiMzU0NkBhdHQuY29tPG1haWx0bzpkYjM1NDZAYXR0LmNvbT4sIGRh bmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb208bWFpbHRvOmRhbmllbGUuY2VjY2FyZWxsaUBl cmljc3Nvbi5jb20+LA0KDQo+ID4gemhhbmdmYXRhaUBodWF3ZWkuY29tPG1haWx0bzp6aGFuZ2Zh dGFpQGh1YXdlaS5jb20+KQ0KDQo+ID4gQ2M6DQoNCj4gPiBSZXNwb25zZSBDb250YWN0czogbWlj aGFlbC5mYXJnYW5vQGNlbnR1cnlsaW5rLmNvbTxtYWlsdG86bWljaGFlbC5mYXJnYW5vQGNlbnR1 cnlsaW5rLmNvbT4gVGVjaG5pY2FsIENvbnRhY3RzOg0KDQo+ID4gUHVycG9zZTogRm9yIGNvbW1l bnQNCg0KPiA+DQoNCj4gPiBCb2R5OiBEZWFyIElFVEYgUm91dGluZyBBcmVhIGFuZCBXb3JraW5n IEdyb3VwIExlYWRlcnM6DQoNCj4gPg0KDQo+ID4gQXMgcHJldmlvdXNseSBjb21tdW5pY2F0ZWQs IHdlIGhhdmUgYmVlbiB3b3JraW5nIG9uIGEgcHJvamVjdCBlbnRpdGxlZA0KDQo+ID4g4oCcQWNo aWV2aW5nIFBhY2tldCBOZXR3b3JrIE9wdGltaXphdGlvbiB1c2luZyBEV0RNIEludGVyZmFjZXPi gJ0gYW5kIGFyZQ0KDQo+ID4gcmVmZXJlbmNpbmcgd29yayBiZWluZyBkb25lIGJ5IElFVEYgQ0NB TVAgYW5kIFRFQVMgaW4gdGhpcyBhcmVhLiBXZQ0KDQo+ID4gYXJlIHBsZWFzZWQgdG8gcmVwb3J0 IHRoYXQgd2UgaGF2ZSBtYWRlIHNpZ25pZmljYW50IHByb2dyZXNzIHRvd2FyZHMNCg0KPiA+IGNv bXBsZXRpb24gb2Ygb3VyIHNwZWNpZmljYXRpb25zLiBTcGVjaWZpY2FsbHksDQoNCj4gPg0KDQo+ ID4gbyBUUi0zMTkgQmFzZSwg4oCcQWNoaWV2aW5nIFBhY2tldCBOZXR3b3JrIE9wdGltaXphdGlv biB1c2luZyBEV0RNDQoNCj4gPiBJbnRlcmZhY2Vz4oCdLCB3YXMgcHVibGlzaGVkIEp1bmUgMjAx NSBvIFRSLTMxOSBQYXJ0IEEsIOKAnEFjaGlldmluZw0KDQo+ID4gUGFja2V0IE5ldHdvcmsgT3B0 aW1pemF0aW9uIHVzaW5nIERXRE0gSW50ZXJmYWNlcyDigJMgUGh5c2ljYWxseQ0KDQo+ID4gSW50 ZWdyYXRlZCBNb2RlbOKAnSwgd2FzIHB1Ymxpc2hlZCBKdW5lIDIwMTUNCg0KPiA+DQoNCj4gPiBX VC0zMTkgUGFydCBCLCBBY2hpZXZpbmcgUGFja2V0IE5ldHdvcmsgT3B0aW1pemF0aW9uIHVzaW5n IERXRE0NCg0KPiA+IEludGVyZmFjZXMg4oCTIFBoeXNpY2FsbHkgU2VwYXJhdGVkLCBMb2dpY2Fs bHkgU2VwYXJhdGVkLCBpcyB1bmRlcmdvaW5nDQoNCj4gPiBTdHJhdyBCYWxsb3QgKHNpbWlsYXIg dG8gSUVURiBXRyBMYXN0IENhbGwpLCBhbmQgd2UgYXJlIGF0dGFjaGluZyBpdCBmb3IgeW91cg0K DQo+IHJldmlldyBhbmQgY29tbWVudC4NCg0KPiA+DQoNCj4gPiBPdXIgYmFsbG90IHBlcmlvZCBj bG9zZXMgb24gTm92ZW1iZXIgOCwgMjAxNS4gSWYgaXQgaXMgYXQgYWxsDQoNCj4gPiBwb3NzaWJs ZSwgd2Ugd291bGQgYXBwcmVjaWF0ZSBhbmQgbG9vayBmb3J3YXJkIHRvIGFueSBpbnB1dCBpbiB0 aW1lDQoNCj4gPiBmb3Igb3VyIGJhbGxvdCBjbG9zZS4gVGhlIG5leHQgbWVldGluZyBvZiBCQkYg b2NjdXJzIE5vdmVtYmVyIDE2LA0KDQo+ID4gMjAxNS4gQSBzY2hlZHVsZSBvZiBvdXIgZnV0dXJl IG1lZXRpbmdzIGFwcGVhcnMgYmVsb3cuDQoNCj4gPg0KDQo+ID4gV2Ugd2FudCB0byBleHByZXNz IG91ciBhcHByZWNpYXRpb24gZm9yIHlvdXIgY29udGludWVkIGNvbnNpZGVyYXRpb24NCg0KPiA+ IG9mIHRoaXMgaW1wb3J0YW50IHRvcGljLg0KDQo+ID4NCg0KPiA+IFNpbmNlcmVseSwNCg0KPiA+ IE1pY2hhZWwgRmFyZ2FubywNCg0KPiA+IEJyb2FkYmFuZCBGb3J1bSBUZWNobmljYWwgQ29tbWl0 dGVlIENoYWlyDQoNCj4gPg0KDQo+ID4gRGF0ZSBvZiBVcGNvbWluZyBCcm9hZGJhbmQgRm9ydW0g TWVldGluZ3MgREFURVMgTE9DQVRJT04NCg0KPiBOb3ZlbWJlciAxNiDigJMNCg0KPiA+IDIwLCAy MDE1IFB1ZXJ0byBWYWxsYXJ0YSwgTWV4aWNvIEZlYnJ1YXJ5IDEg4oCTIDUsIDIwMTYgQXNpYSBQ YWMNCg0KPiA+IChwcmVjaXNlIGxvY2F0aW9uIFRCRCkNCg0KPiA+DQoNCj4gPiBOb3RlOiBBIGxp c3Qgb2YgdXBjb21pbmcgbWVldGluZ3MgY2FuIGFsc28gYmUgZm91bmQgYXQNCg0KPiA+IGh0dHA6 Ly93d3cuYnJvYWRiYW5kZm9ydW0uDQoNCj4gPiBvcmcvbWVldGluZ3MvdXBjb21pbmdtZWV0aW5n c2F0YWdsYW5jZS5waHANCg0KPiA+DQoNCj4gPiBBdHRhY2htZW50czoNCg0KPiA+IMKnIFdULTMx OSBQYXJ0IEIgU3RyYXcgQmFsbG90IFRleHQgKGJiZjIwMTUuMDcxLjA3KQ0KDQo+ID4gQXR0YWNo bWVudHM6DQoNCj4gPg0KDQo+ID4gICAgIEF0dGFjaG1lbnQNCg0KPiA+ICAgICBodHRwczovL3d3 dy5pZXRmLm9yZy9saWIvZHQvZG9jdW1lbnRzL0xJQUlTT04vbGlhaXNvbi0yMDE1LTEwLTE2LQ0K DQo+ID4gYnJvYWRiYW5kLWZvcnVtLXJ0Zy1jY2FtcC10ZWFzLWFjaGlldmluZy1wYWNrZXQtbmV0 d29yay1vcHRpbWl6YXRpb24tDQoNCj4gPiB1c2luZy1kd2RtLWludGVyZmFjZXMtYXR0YWNobWVu dC0xLnBkZg0KDQo+ID4NCg0KPiA+ICAgICBTdGF0ZW1lbnQNCg0KPiA+ICAgICBodHRwczovL3d3 dy5pZXRmLm9yZy9saWIvZHQvZG9jdW1lbnRzL0xJQUlTT04vbGlhaXNvbi0yMDE1LTEwLTE2LQ0K DQo+ID4gYnJvYWRiYW5kLWZvcnVtLXJ0Zy1jY2FtcC10ZWFzLWFjaGlldmluZy1wYWNrZXQtbmV0 d29yay1vcHRpbWl6YXRpb24tDQoNCj4gPiB1c2luZy1kd2RtLWludGVyZmFjZXMtYXR0YWNobWVu dC0yLnBkZg0KDQo+DQoNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCg0KPiBDQ0FNUCBtYWlsaW5nIGxpc3QNCg0KPiBDQ0FNUEBpZXRmLm9yZzxtYWls dG86Q0NBTVBAaWV0Zi5vcmc+DQoNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9jY2FtcA0KDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQoNCj4gQ0NBTVAgbWFpbGluZyBsaXN0DQoNCj4gQ0NBTVBAaWV0Zi5vcmc8bWFpbHRv OkNDQU1QQGlldGYub3JnPg0KDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vY2NhbXANCg== --_000_4A1562797D64E44993C5CBF38CF1BE4812AC1963ESESSMB301erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiTVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Ok1pbmdMaVU7DQoJcGFub3NlLTE6MiAyIDUg OSAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Ok1pbmdMaVU7DQoJcGFu b3NlLTE6MiAyIDUgOSAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNh bGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBNUyBHb3RoaWMiOw0KCXBhbm9zZS0xOjIgMTEgNiA5 IDcgMiA1IDggMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATWluZ0xpVSI7DQoJ cGFub3NlLTE6MiAyIDUgOSAwIDAgMCAwIDAgMDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hh ciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEx LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnAuTXNvQWNldGF0 ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29u IFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzky LjBwdDsNCgltYXJnaW46NzAuODVwdCAxMjkuNzVwdCA3MC44NXB0IDEyOS43cHQ7fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICov DQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxNTg2NDU1NjUzOw0KCW1zby1saXN0LXR5cGU6aHli cmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo2MDUzMjIyNTYgNjc2OTg2ODkgNjc2OTg2OTEg Njc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2 OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciLCJzZXJpZiI7fQ0KQGxpc3QgbDA6bGV2ZWwz DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Iiwic2VyaWYiO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZl bDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyIsInNlcmlmIjt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207 fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkhpIEhhb21pYW4sIGFsbCw8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+VGhhbmtzIGZvciBzdGFydGluZyBwdXR0aW5nIHRvZ2V0aGVyIHRo ZSByZXBseS4gUGxlYXNlIGZpbmQgc29tZSB1cGRhdGVkIHByb3Bvc2FscyBmcm9tIG15IHNpZGUu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPj09PT09PT09PT09PT09PT09PT09PT09PT09 PTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhlIHdvcmtpbmcgZ3Jv dXBzIGluIElFVEYgcm91dGluZyBhcmVhIHdvdWxkIGxpa2UgdG8gdGhhbmsgeW91IGZvciBzZW5k aW5nIHRoaXMgbGlhaXNvbi4gV2UgbXVjaCBhcHByZWNpYXRlIEJCRiBvbiB0aGUgZWZmb3J0IG9m IHBhY2tldCBvdmVyIG9wdGljYWwsIGFuZCBzZW5kaW5nIHRoZSBkb2N1bWVudCB0byBJRVRGIEND QU1QLCBURUFTIGFuZCBQQ0UgV0dzIGZvciByZXZpZXcuIFRoaXMgcHJvamVjdA0KIGRlZmluZXMg YSBzZXQgb2YgY29udHJvbCBwbGFuZSByZXF1aXJlbWVudHMgdGhhdCB0aGUgUGh5c2ljYWxseSBT ZXBhcmF0ZWQgTW9kZWwgc2hvdWxkIGJlIHNhdGlzZmllZC4gV2UgaGF2ZSBzb21lIHF1ZXN0aW9u cyBhbmQgY29tbWVudHM6DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+UXVlc3Rpb25z OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4N CjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTeW1ib2wiPjxz cGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5JdCBpcyBu b3QgY2xlYXIgdG8gdXMgaG93IHRoZSBjb21tdW5pY2F0aW9uIGJldHdlZW4gdGhlIHBhY2tldCBs YXllciBhbmQgdGhlIG9wdGljYWwgbGF5ZXIgb2NjdXJzLiBFLmcuIGNvbnRyb2wgY2hhbm5lbHMs IHNpZ25hbGluZyBhbmQgc28gb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxp c3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBz dHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3Nw YW4+PCFbZW5kaWZdPldlIHdvdWxkIGxpa2UgdG8gc2VlIHNvbWUgbW9yZSBkZXRhaWxzIG9uIHRo ZSBtYW5hZ2VtZW50IGFzcGVjdHMgYmV0d2VlbiB0aGUgcGFja2V0IGRvbWFpbiBhbmQgdGhlIG9w dGljYWwgZG9tYWluLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Q29t bWVudHM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm bzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJv bCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBw dCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPldo ZW4gcmVmZXJyaW5nIHRvIFBDRSBhbmQgcmVsYXRlZCBpc3N1ZXMsIGUuZy4sIGluIFtSLTI2XSBh bmQgW1ItMjddLCBpdCBzZWVtcyBvbmx5IHN0YXRlbGVzcyBQQ0UgKFJGQzQ2NTUpIGFuZCBjb3Jy ZXNwb25kaW5nIFBDRVAgKFJGQzU1MjApIGFyZSBpbmNsdWRlZCBpbiB0aGUgY3VycmVudCB2ZXJz aW9uLiBBcyBJRVRGIFBDRSB3b3JraW5nIGdyb3VwIGlzIGludmVzdGlnYXRpbmcgb24gc3RhdGVm dWwNCiBQQ0UsIFBDRSBJbml0aWF0aW9uIGFuZCBQQ0UgYXMgYSBDZW50cmFsIENvbnRyb2xsZXIs IHdoaWNoIGFyZSBwbGFubmVkIHRvIGJlIHB1Ymxpc2hlZCBpbiB0aGUgZnV0dXJlLCBpdCBpcyBi ZXR0ZXIgdG8gc3BlY2lmeSB3aGljaCBraW5kIG9mIFBDRSBpcyBub3cgcmVmZXJyZWQgYnkgdGhp cyBkb2N1bWVudHMuIE1vcmVvdmVyLCBSRkMgNTYyMywgUENFLWJhc2VkIGludGVyLWxheWVyIE1Q TFMgYW5kIEdNUExTIFRyYWZmaWMgRW5naW5lZXJpbmcsDQogbWF5IGJlIGEgZ29vZCByZWZlcmVu Y2UgZm9yIHRoaXMgZG9jdW1lbnQuIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1s aXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4g c3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9z cGFuPjwhW2VuZGlmXT5JbiBzZWN0aW9uIDQuNCB3aGVuIHRhbGtpbmcgYWJvdXQgU0ROLCBPcGVu ZmxvdyBpcyBtZW50aW9uZWQgYXMgYSBzdGFuZGFyZCBwcm90b2NvbCB0byBpbnRlcmFjdCBiZXR3 ZWVuIHBhY2tldCBub2RlcyBhbmQgRFdETSBub2Rlcy4gV2Ugd291bGQgbGlrZSB0byBzdWdnZXN0 IGFkZCBQQ0UgUHJvdG9jb2wgKFBDRVApIGFzIGFub3RoZXIgZXhhbXBsZSwgYXMgaXQgaXMgY3Vy cmVudGx5IHVzZWQNCiBpbiBJRVRGLiBCZXNpZGVzLCBpdCBpcyBzdWdnZXN0IHRvIHJlZmVyZW5j ZSB0byBSRkMgMzQxMyBhYm91dCBTTk1QLCBhbmQgUkZDIDQyMDggYWJvdXQgR01QTFMgVU5JLg0K PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0K PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+PHNw YW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkluIHNlY3Rp b24gNC41LCBbUi0zNl0gaXMgbm90IGNsZWFyIHdoZXRoZXIgdG8gYmUgYXBwbGllZCB0byB0aGUg bm9ydGgtYm91bmQgb2YgU0ROIGNvbnRyb2xsZXIsIG9yIGJldHdlZW4gdGhlIHBhY2tldCBORSBh bmQgU0ROIGNvbnRyb2xsZXIuIFdlIHByZWZlciB0aGUgbGF0dGVyIG9uZS4NCjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij5JdCBzZWVtcyB0byB1cyB0aGUgcmVxdWlyZW1lbnRzIHByb3Bv c2VkIGluIHRoZSBjdXJyZW50IGRvY3VtZW50IGNvdWxkIGJlIGFkZHJlc3NlZCBieSB0aGUgcmVm ZXJlbmNlZCBSRkNzIGRlZmluZWQgZm9yIEdNUExTLCBzbyB3ZSB3b3VsZCBsaWtlIHRvIG1ha2Ug c3VyZSBpZiB5b3UgaGF2ZSBpZGVudGlmaWVkIGFueSBnYXBzLCB3aGljaCBuZWVkIGFuIHVwZGF0 ZSBvbiBHTVBMUy9QQ0VQIHRvIHNhdGlzZnkNCiB0aGVzZSByZXF1aXJlbWVudHMuIElFVEYgQ0NB TVAgaXMgZGlzY3Vzc2luZyB0byBkZWZpbmUgYSBmcmFtZXdvcmsgZm9yIE1hbmFnZW1lbnQgYW5k IENvbnRyb2wgb2YgRFdETSBvcHRpY2FsIGludGVyZmFjZSBwYXJhbWV0ZXJzIGFuZCBHTVBMUyBw cm90b2NvbHMgdGhhdCBuZWVkIHRvIGJlIHVwZGF0ZWQsIHdoaWNoIG1pZ2h0IGJlIHJlbGV2YW50 IHRvIHlvdXIgcHJvamVjdCwgYnV0IHRoaXMgd29yayBpbiBDQ0FNUCBpcyBzdGlsbCBpbiBpbmRp dmlkdWFsDQogZHJhZnRzIHN0YWdlLiBXZSB3b3VsZCBsaWtlIHRvIHJlY2VpdmUgeW91ciBpbnB1 dC4gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij49PT09PT09PT09PT09 PT09PT09PT09PT09PT09PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoYW5rcyA8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkRhbmllbGU8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgRnJvbTogQ0NBTVAgW21haWx0bzpjY2FtcC1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgWmhlbmdoYW9taWFuPC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyBTZW50OiBtYXJ0ZWTDrCAyNyBvdHRvYnJlIDIwMTUgMTg6MTc8L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFRvOiAnY2NhbXBAaWV0Zi5vcmcnOyBwY2VA aWV0Zi5vcmc7IFRFQVMgV0c8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFN1Ympl Y3Q6IFtDQ0FNUF0gSW5pdGlhbCB2ZXJzaW9uIGZvciBsaWFpc29uIHRleHQgLy88c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7nrZTlpI08L3NwYW4+OiBDQUxM IEZPUjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgVk9MVU5URUVSIC0gTmV3IExp YWlzb24gU3RhdGVtZW50LCAmcXVvdDtBY2hpZXZpbmcgUGFja2V0IE5ldHdvcms8L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IE9wdGltaXphdGlvbiB1c2luZyBEV0RNIEludGVyZmFj ZXMmcXVvdDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgSGksIEFsbCw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7IDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgQWZ0ZXIgcmV2aWV3aW5n IHRoZSBsaWFpc29uIGFuZCBkb2N1bWVudCBmcm9tIEJCRiwgd2Ugd291bGQgbGlrZSB0byBwcm92 aWRlPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyB0aGUgZm9sbG93aW5nIHRleHQg YXMgYW4gaW5pdGlhbCB2ZXJzaW9uIGZvciByZXNwb25zZS4gUGxlYXNlIGhlbHAgcmV2aWV3LCB5 b3VyPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBjb21tZW50cyBhcmUgaGlnaGx5 IHdlbGNvbWVkLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09Zm9yPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBkaXNjdXNzaW9uPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyBUaGUgd29ya2luZyBncm91cHMgaW4gSUVURiByb3V0aW5nIGFy ZWEgd291bGQgbGlrZSB0byB0aGFuayB5b3UgZm9yIHNlbmRpbmc8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7IHRoaXMgbGlhaXNvbi4gV2UgbXVjaCBhcHByZWNpYXRlIEJCRiBvbiB0 aGUgZWZmb3J0IG9mIHBhY2tldCBvdmVyIG9wdGljYWwsIGFuZDwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgc2VuZGluZyB0aGUgZG9jdW1lbnQgdG8gSUVURiBDQ0FNUCwgVEVBUyBh bmQgUENFIFdHcyBmb3IgcmV2aWV3LiBUaGlzPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyBwcm9qZWN0IGRlZmluZXMgYSBzZXQgb2YgY29udHJvbCBwbGFuZSByZXF1aXJlbWVudHMg dGhhdCB0aGUgUGh5c2ljYWxseTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgU2Vw YXJhdGVkIE1vZGVsIHNob3VsZCBiZSBzYXRpc2ZpZWQuIFdlIGFyZSBnZW5lcmFsbHkgZmluZSBh Ym91dCB0aGU8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGNvbnRlbnQsIHdpdGgg c29tZSBtaW5vciBzdWdnZXN0aW9ucyBsaXN0ZWQgYXMgZm9sbG93IGZvciB5b3VyIHJlZmVyZW5j ZTo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsg4oCiIFdoZW4gcmVmZXJyaW5nIHRvIFBDRSBhbmQgcmVsYXRlZCBpc3N1 ZXMsIGUuZy4sIGluIFtSLTI2XSBhbmQgW1ItMjddLCBpdDwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgc2VlbXMgb25seSBzdGF0ZWxlc3MgUENFIChSRkM0NjU1KSBhbmQgY29ycmVz cG9uZGluZyBQQ0VQIChSRkM1NTIwKSBhcmU8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7IGluY2x1ZGVkIGluIHRoZSBjdXJyZW50IHZlcnNpb24uIEFzIElFVEYgUENFIHdvcmtpbmcg Z3JvdXAgaXMgaW52ZXN0aWdhdGluZyBvbjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgc3RhdGVmdWwgUENFLCBQQ0UgSW5pdGlhdGlvbiBhbmQgUENFIGFzIGEgQ2VudHJhbCBDb250 cm9sbGVyLCB3aGljaCBhcmUgcGxhbm5lZDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgdG8gYmUgcHVibGlzaGVkIGluIHRoZSBmdXR1cmUsIGl0IGlzIGJldHRlciB0byBzcGVjaWZ5 IHdoaWNoIGtpbmQgb2YgUENFIGlzIG5vdzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgcmVmZXJyZWQgYnkgdGhpcyBkb2N1bWVudHMuIE1vcmVvdmVyLCBSRkMgNTYyMywgUENFLWJh c2VkIGludGVyLWxheWVyPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBNUExTIGFu ZCBHTVBMUyBUcmFmZmljIEVuZ2luZWVyaW5nLCBtYXkgYmUgYSBnb29kIHJlZmVyZW5jZSBmb3Ig dGhpczwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgZG9jdW1lbnQuPC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyDigKIgSW4gc2VjdGlvbiA0LjQgd2hlbiB0YWxraW5n IGFib3V0IFNETiwgT3BlbmZsb3cgaXMgbWVudGlvbmVkIGFzIGE8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7IHN0YW5kYXJkIHByb3RvY29sIHRvIGludGVyYWN0IGJldHdlZW4gcGFj a2V0IG5vZGVzIGFuZCBEV0RNIG5vZGVzLiBXZTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgd291bGQgbGlrZSB0byBzdWdnZXN0IGFkZCBQQ0UgUHJvdG9jb2wgKFBDRVApIGFzIGFu b3RoZXIgZXhhbXBsZSwgYXMgaXQgaXM8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 IGN1cnJlbnRseSB1c2VkIGluIElFVEYuIEJlc2lkZXMsIGl0IGlzIHN1Z2dlc3QgdG8gcmVmZXJl bmNlIHRvIFJGQyAzNDEzIGFib3V0PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBT Tk1QLCBhbmQgUkZDIDQyMDggYWJvdXQgR01QTFMgVU5JLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsg4oCiIEluIHNlY3Rpb24gNC41LCBbUi0zNl0gaXMgbm90IGNsZWFyIHdoZXRo ZXIgdG8gYmUgYXBwbGllZCB0byB0aGUgbm9ydGgtYm91bmQ8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7IG9mIFNETiBjb250cm9sbGVyLCBvciBiZXR3ZWVuIHRoZSBwYWNrZXQgTkUg YW5kIFNETiBjb250cm9sbGVyLiBXZSBwcmVmZXI8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7IHRoZSBsYXR0ZXIgb25lLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBJdCBzZWVtcyB0byB1cyB0aGUgcmVx dWlyZW1lbnRzIHByb3Bvc2VkIGluIHRoZSBjdXJyZW50IGRvY3VtZW50IGNvdWxkIGJlPC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBhZGRyZXNzZWQgYnkgdGhlIHJlZmVyZW5jZWQg UkZDcyBkZWZpbmVkIGZvciBHTVBMUywgc28gd2Ugd291bGQgbGlrZSB0bzwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgbWFrZSBzdXJlIGlmIHlvdSBoYXZlIGlkZW50aWZpZWQgYW55 IGdhcHMsIHdoaWNoIG5lZWQgYW4gdXBkYXRlIG9uIEdNUExTPC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyB0byBzYXRpc2Z5IHRoZXNlIHJlcXVpcmVtZW50cy4gSUVURiBDQ0FNUCBp cyBkaXNjdXNzaW5nIHRvIGRlZmluZSBhPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyBmcmFtZXdvcmsgZm9yIE1hbmFnZW1lbnQgYW5kIENvbnRyb2wgb2YgRFdETSBvcHRpY2FsIGlu dGVyZmFjZTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgcGFyYW1ldGVycyBhbmQg R01QTFMgcHJvdG9jb2xzIHRoYXQgbmVlZCB0byBiZSB1cGRhdGVkLCB3aGljaCBtaWdodCBiZTwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgcmVsZXZhbnQgdG8geW91ciBwcm9qZWN0 LCBidXQgdGhpcyB3b3JrIGluIENDQU1QIGlzIHN0aWxsIGluIGluZGl2aWR1YWwgZHJhZnRzPC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBzdGFnZS4gV2Ugd291bGQgbGlrZSB0byBy ZWNlaXZlIHlvdXIgaW5wdXQuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBUaGFua3MuPC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7IEJlc3Qgd2lzaGVzLDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgSGFv bWlhbjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyAtLS0tLTxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpNaW5nTGlVIj7p gq7ku7bljp/ku7Y8L3NwYW4+LS0tLS08L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 IDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpNaW5nTGlVIj7lj5Hku7bkuro8L3NwYW4+OiBaaGVu Z2hhb21pYW48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxzcGFuIHN0eWxlPSJm b250LWZhbWlseTpNaW5nTGlVIj7lj5HpgIHml7bpl7Q8L3NwYW4+OiAyMDE1PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+5bm0PC9zcGFuPjEwPHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+5pyIPC9zcGFuPjIxPHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+5pelPC9zcGFuPiAxMTox MTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+5pS25Lu25Lq6PC9zcGFuPjogRGFuaWVsZSBDZWNj YXJlbGxpOyBGYXRhaSBaaGFuZzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+5oqE6YCBPC9zcGFu PjogPGEgaHJlZj0ibWFpbHRvOmNjYW1wQGlldGYub3JnIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3 aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5jY2FtcEBpZXRmLm9yZzwvc3Bhbj48L2E+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7kuLs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5Ok1pbmdMaVUiPumimDwvc3Bhbj46DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 TVMgR290aGljJnF1b3Q7Ij7nrZTlpI08L3NwYW4+OiBDQUxMIEZPUiBWT0xVTlRFRVIgLSBOZXcg TGlhaXNvbiBTdGF0ZW1lbnQsICZxdW90O0FjaGlldmluZzwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgUGFja2V0IE5ldHdvcmsgT3B0aW1pemF0aW9uIHVzaW5nIERXRE0gSW50ZXJm YWNlcyZxdW90OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBEYW5pZWxlLCBGYXRhaSBhbmQgQWxsLDwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyBJIHdvdWxkIGxpa2UgdG8gdm9sdW50ZWVyIGZvciBnZW5lcmF0aW5nIHRoZSByZXNwb25zZSBs aWFpc29uLCBhcyB0aGUgdG9waWMgaXM8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 IGhpZ2hseSByZWxhdGVkIHRvIG15IHJlc2VhcmNoIHdvcmsuIEkgd2lsbCByZXZpZXcgdGhlIGRv Y3VtZW50IGFuZCBzaGFyZSBteTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgY29t bWVudHMgZWFybHkgbmV4dCB3ZWVrLiBQbGVhc2UgYWxzbyBmZWVsIGZyZWUgdG8gc2hhcmUgeW91 ciBvcGluaW9uLDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgdGhhbmtzLjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyBCZXN0IHdpc2hlcyw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IEhh b21pYW48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgLS0tLS08c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6TWluZ0xpVSI+ 6YKu5Lu25Y6f5Lu2PC9zcGFuPi0tLS0tPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyA8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6TWluZ0xpVSI+5Y+R5Lu25Lq6PC9zcGFuPjogQ0NB TVAgWzxhIGhyZWY9Im1haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0i Y29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+bWFpbHRvOmNjYW1wLWJvdW5j ZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPl0NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtN UyBHb3RoaWMmcXVvdDsiPuS7o+ihqDwvc3Bhbj4gRGFuaWVsZSBDZWNjYXJlbGxpPC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6TWluZ0xp VSI+5Y+R6YCB5pe26Ze0PC9zcGFuPjogMjAxNTxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtNUyBHb3RoaWMmcXVvdDsiPuW5tDwvc3Bhbj4xMDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtNUyBHb3RoaWMmcXVvdDsiPuaciDwvc3Bhbj4yMDxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuaXpTwvc3Bhbj4gMjM6NDY8L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7IDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3Ro aWMmcXVvdDsiPuaUtuS7tuS6ujwvc3Bhbj46IENDQU1QICg8YSBocmVmPSJtYWlsdG86Y2NhbXBA aWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpu b25lIj5jY2FtcEBpZXRmLm9yZzwvc3Bhbj48L2E+KTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+ 5Li7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpNaW5nTGlVIj7popg8L3NwYW4+OiBb Q0NBTVBdIENBTEwgRk9SIFZPTFVOVEVFUiAtIE5ldyBMaWFpc29uIFN0YXRlbWVudCwgJnF1b3Q7 QWNoaWV2aW5nPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBQYWNrZXQgTmV0d29y ayBPcHRpbWl6YXRpb24gdXNpbmcgRFdETSBJbnRlcmZhY2VzJnF1b3Q7PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyA8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFdH LDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyBXZSByZWNlaXZlZCB0aGlzIGxpYWlzb24gZnJvbSBCQkYgb24gUGFja2V0 LU9wdGljYWwgaW50ZWdyYXRpb24uPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBJ J20gY29weWluZyB0aGUgbGlua3MgdG8gbGlhaXNvbiBhbmQgYXR0YWNobWVudCBoZXJlIGZvciB5 b3VyIGNvbnZlbmllbmNlPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBMaWFpc29u OiZuYnNwOyA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2xpYWlzb24vMTQz Mi8iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUi Pmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbGlhaXNvbi8xNDMyLzwvc3Bhbj48L2E+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBBdHRhY2htZW50OiA8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9saWIvZHQvZG9jdW1lbnRzL0xJQUlTT04vbGlhaXNvbi0yMDE1LTEw LTE2LWJyb2FkYmFuZC1mb3J1bS1ydGctY2NhbXAtdGVhcy1hY2hpZXZpbmctcGFja2V0LW5ldHdv cmstb3B0aW1pemF0aW9uLXVzaW5nLWR3ZG0taW50ZXJmYWNlcy1hdHRhY2htZW50LTEucGRmIj4N CjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRw czovL3d3dy5pZXRmLm9yZy9saWIvZHQvZG9jdW1lbnRzL0xJQUlTT04vbGlhaXNvbi0yMDE1LTwv c3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbGliL2R0L2RvY3VtZW50cy9MSUFJU09OL2xpYWlzb24tMjAxNS0xMC0xNi1i cm9hZGJhbmQtZm9ydW0tcnRnLWNjYW1wLXRlYXMtYWNoaWV2aW5nLXBhY2tldC1uZXR3b3JrLW9w dGltaXphdGlvbi11c2luZy1kd2RtLWludGVyZmFjZXMtYXR0YWNobWVudC0xLnBkZiI+PHNwYW4g c3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPiZndDsNCiAxMC0x Ni1icm9hZGJhbmQtZm9ydW0tcnRnLWNjYW1wLXRlYXMtYWNoaWV2aW5nLXBhY2tldC1uZXR3b3Jr LTwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbGliL2R0L2RvY3VtZW50cy9MSUFJU09OL2xpYWlzb24tMjAxNS0xMC0x Ni1icm9hZGJhbmQtZm9ydW0tcnRnLWNjYW1wLXRlYXMtYWNoaWV2aW5nLXBhY2tldC1uZXR3b3Jr LW9wdGltaXphdGlvbi11c2luZy1kd2RtLWludGVyZmFjZXMtYXR0YWNobWVudC0xLnBkZiI+PHNw YW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPiZndDsNCiBv cHRpbWl6YXRpb24tdXNpbmctZHdkbS1pbnRlcmZhY2VzLWF0dGFjaG1lbnQtMS5wZGY8L3NwYW4+ PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyBXZSdkIHJlYWxseSBsaWtlIDEgb3IgMiB2b2x1bnRlZXJzIGludGVy ZXN0ZWQgaW4gdGhlIHRvcGljIHRvIGRyYWZ0IGFuIGFuc3dlciB0bzwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgdGhlIGxpYWlzb24gYmVmb3JlIHRoZSBtZWV0aW5nIGluIFlva29o YW1hIHNvIHRvIGJlIGFibGUgdG8gZGlzY3VzcyBpdCBvbiB0aGU8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7IGxpc3QgYW5kIHJlcGx5IGR1cmluZyBvciBpbW1lZGlhdGVseSBhZnRl ciB0aGUgbWVldGluZy48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgUGxlYXNlIGNvbnNpZGVyIHZvbHVudGVlcmluZy48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFRoYW5rczwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgRmF0YWkgJmFtcDsgRGFuaWVsZTwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyAmZ3Q7IEZyb206IExpYWlzb24gU3RhdGVtZW50IE1hbmFnZW1lbnQgVG9vbCBbPGEgaHJlZj0i bWFpbHRvOmxzbXRAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQt ZGVjb3JhdGlvbjpub25lIj5tYWlsdG86bHNtdEBpZXRmLm9yZzwvc3Bhbj48L2E+XTwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBTZW50OiB2ZW5lcmTDrCAxNiBvdHRvYnJl IDIwMTUgMjI6MDU8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgVG86IDxh IGhyZWY9Im1haWx0bzpkYjM1NDZAYXR0LmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3Rl eHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmRiMzU0NkBhdHQuY29tPC9zcGFuPjwvYT47DQo8YSBo cmVmPSJtYWlsdG86dmJlZXJhbUBqdW5pcGVyLm5ldCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRv d3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPnZiZWVyYW1AanVuaXBlci5uZXQ8L3NwYW4+PC9h PjsNCjxhIGhyZWY9Im1haWx0bzpha2F0bGFzQGdtYWlsLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9y OndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmFrYXRsYXNAZ21haWwuY29tPC9zcGFu PjwvYT47PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IDxhIGhyZWY9Im1h aWx0bzphcmV0YW5hQGNpc2NvLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4 dC1kZWNvcmF0aW9uOm5vbmUiPmFyZXRhbmFAY2lzY28uY29tPC9zcGFuPjwvYT47DQo8YSBocmVm PSJtYWlsdG86bGJlcmdlckBsYWJuLm5ldCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7 dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmxiZXJnZXJAbGFibi5uZXQ8L3NwYW4+PC9hPjsNCjxhIGhy ZWY9Im1haWx0bzp6aGFuZ2ZhdGFpQGh1YXdlaS5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5k b3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj56aGFuZ2ZhdGFpQGh1YXdlaS5jb208L3NwYW4+ PC9hPjsgRGFuaWVsZTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBDZWNj YXJlbGxpPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IENjOiBBbHZhcm8g UmV0YW5hOyBEZWJvcmFoIEJydW5nYXJkOyBEYXZpZCBTaW5pY3JvcGU7IEZhdGFpIFpoYW5nOzwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBBbGlhIEF0bGFzOyBWaXNobnUg UGF2YW4gQmVlcmFtOyBUaGUgSUVURiBDaGFpcjsgRGFuaWVsZSBDZWNjYXJlbGxpOzwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBMb3UgQmVyZ2VyOyBDb21tb24gQ29udHJv bCBhbmQgTWVhc3VyZW1lbnQgUGxhbmUgRGlzY3Vzc2lvbiBMaXN0OzwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgJmd0OyA8YSBocmVmPSJtYWlsdG86bWljaGFlbC5mYXJnYW5vQGNl bnR1cnlsaW5rLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0 aW9uOm5vbmUiPm1pY2hhZWwuZmFyZ2Fub0BjZW50dXJ5bGluay5jb208L3NwYW4+PC9hPjsgVHJh ZmZpYyBFbmdpbmVlcmluZyBBcmNoaXRlY3R1cmUgYW5kPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyAmZ3Q7IFNpZ25hbGluZyBEaXNjdXNzaW9uIExpc3Q8L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgU3ViamVjdDogTmV3IExpYWlzb24gU3RhdGVtZW50LCAm cXVvdDtBY2hpZXZpbmcgUGFja2V0IE5ldHdvcmsgT3B0aW1pemF0aW9uPC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IHVzaW5nIERXRE0gSW50ZXJmYWNlcyZxdW90OzwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgJmd0OyBUaXRsZTogQWNoaWV2aW5nIFBhY2tldCBOZXR3b3JrIE9wdGltaXph dGlvbiB1c2luZyBEV0RNIEludGVyZmFjZXM8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7ICZndDsgU3VibWlzc2lvbiBEYXRlOiAyMDE1LTEwLTE2IFVSTCBvZiB0aGUgSUVURiBXZWIg cGFnZTo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgPGEgaHJlZj0iaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9saWFpc29uLzE0MzIvIj4NCjxzcGFuIHN0eWxlPSJj b2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2xpYWlzb24vMTQzMi88L3NwYW4+PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgJmd0OyBQbGVhc2UgcmVwbHkgYnkgMjAxNS0xMS0wODwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBGcm9tOiZuYnNwOyAoRGF2aWQgU2luaWNyb3BlICZs dDs8YSBocmVmPSJtYWlsdG86ZGF2aWQuc2luaWNyb3BlQGVyaWNzc29uLmNvbSI+PHNwYW4gc3R5 bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmRhdmlkLnNpbmljcm9w ZUBlcmljc3Nvbi5jb208L3NwYW4+PC9hPiZndDspPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyAmZ3Q7IFRvOiZuYnNwOyAoPGEgaHJlZj0ibWFpbHRvOnZiZWVyYW1AanVuaXBlci5u ZXQiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj52 YmVlcmFtQGp1bmlwZXIubmV0PC9zcGFuPjwvYT4sDQo8YSBocmVmPSJtYWlsdG86bGJlcmdlckBs YWJuLm5ldCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5v bmUiPmxiZXJnZXJAbGFibi5uZXQ8L3NwYW4+PC9hPiwNCjxhIGhyZWY9Im1haWx0bzpha2F0bGFz QGdtYWlsLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9u Om5vbmUiPmFrYXRsYXNAZ21haWwuY29tPC9zcGFuPjwvYT4sPC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzphcmV0YW5hQGNpc2NvLmNvbSI+PHNw YW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmFyZXRhbmFA Y2lzY28uY29tPC9zcGFuPjwvYT4sDQo8YSBocmVmPSJtYWlsdG86ZGIzNTQ2QGF0dC5jb20iPjxz cGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5kYjM1NDZA YXR0LmNvbTwvc3Bhbj48L2E+LA0KPGEgaHJlZj0ibWFpbHRvOmRhbmllbGUuY2VjY2FyZWxsaUBl cmljc3Nvbi5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlv bjpub25lIj5kYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tPC9zcGFuPjwvYT4sPC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzp6aGFuZ2Zh dGFpQGh1YXdlaS5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3Jh dGlvbjpub25lIj56aGFuZ2ZhdGFpQGh1YXdlaS5jb208L3NwYW4+PC9hPik8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgQ2M6PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyAmZ3Q7IFJlc3BvbnNlIENvbnRhY3RzOiA8YSBocmVmPSJtYWlsdG86bWljaGFlbC5m YXJnYW5vQGNlbnR1cnlsaW5rLmNvbSI+DQo8c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0 ZXh0LWRlY29yYXRpb246bm9uZSI+bWljaGFlbC5mYXJnYW5vQGNlbnR1cnlsaW5rLmNvbTwvc3Bh bj48L2E+IFRlY2huaWNhbCBDb250YWN0czo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7ICZndDsgUHVycG9zZTogRm9yIGNvbW1lbnQ8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgQm9keTog RGVhciBJRVRGIFJvdXRpbmcgQXJlYSBhbmQgV29ya2luZyBHcm91cCBMZWFkZXJzOjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgJmd0OyBBcyBwcmV2aW91c2x5IGNvbW11bmljYXRlZCwgd2UgaGF2ZSBiZWVuIHdv cmtpbmcgb24gYSBwcm9qZWN0IGVudGl0bGVkPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyAmZ3Q7IOKAnEFjaGlldmluZyBQYWNrZXQgTmV0d29yayBPcHRpbWl6YXRpb24gdXNpbmcg RFdETSBJbnRlcmZhY2Vz4oCdIGFuZCBhcmU8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7ICZndDsgcmVmZXJlbmNpbmcgd29yayBiZWluZyBkb25lIGJ5IElFVEYgQ0NBTVAgYW5kIFRF QVMgaW4gdGhpcyBhcmVhLiBXZTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0 OyBhcmUgcGxlYXNlZCB0byByZXBvcnQgdGhhdCB3ZSBoYXZlIG1hZGUgc2lnbmlmaWNhbnQgcHJv Z3Jlc3MgdG93YXJkczwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBjb21w bGV0aW9uIG9mIG91ciBzcGVjaWZpY2F0aW9ucy4gU3BlY2lmaWNhbGx5LDwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgJmd0OyBvIFRSLTMxOSBCYXNlLCDigJxBY2hpZXZpbmcgUGFja2V0IE5ldHdvcmsgT3B0aW1p emF0aW9uIHVzaW5nIERXRE08L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsg SW50ZXJmYWNlc+KAnSwgd2FzIHB1Ymxpc2hlZCBKdW5lIDIwMTUgbyBUUi0zMTkgUGFydCBBLCDi gJxBY2hpZXZpbmc8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgUGFja2V0 IE5ldHdvcmsgT3B0aW1pemF0aW9uIHVzaW5nIERXRE0gSW50ZXJmYWNlcyDigJMgUGh5c2ljYWxs eTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBJbnRlZ3JhdGVkIE1vZGVs 4oCdLCB3YXMgcHVibGlzaGVkIEp1bmUgMjAxNTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBXVC0zMTkg UGFydCBCLCBBY2hpZXZpbmcgUGFja2V0IE5ldHdvcmsgT3B0aW1pemF0aW9uIHVzaW5nIERXRE08 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgSW50ZXJmYWNlcyDigJMgUGh5 c2ljYWxseSBTZXBhcmF0ZWQsIExvZ2ljYWxseSBTZXBhcmF0ZWQsIGlzIHVuZGVyZ29pbmc8L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgU3RyYXcgQmFsbG90IChzaW1pbGFy IHRvIElFVEYgV0cgTGFzdCBDYWxsKSwgYW5kIHdlIGFyZSBhdHRhY2hpbmcgaXQgZm9yIHlvdXI8 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHJldmlldyBhbmQgY29tbWVudC48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7ICZndDsgT3VyIGJhbGxvdCBwZXJpb2QgY2xvc2VzIG9uIE5vdmVtYmVyIDgs IDIwMTUuIElmIGl0IGlzIGF0IGFsbDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg Jmd0OyBwb3NzaWJsZSwgd2Ugd291bGQgYXBwcmVjaWF0ZSBhbmQgbG9vayBmb3J3YXJkIHRvIGFu eSBpbnB1dCBpbiB0aW1lPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IGZv ciBvdXIgYmFsbG90IGNsb3NlLiBUaGUgbmV4dCBtZWV0aW5nIG9mIEJCRiBvY2N1cnMgTm92ZW1i ZXIgMTYsPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IDIwMTUuIEEgc2No ZWR1bGUgb2Ygb3VyIGZ1dHVyZSBtZWV0aW5ncyBhcHBlYXJzIGJlbG93LjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgJmd0OyBXZSB3YW50IHRvIGV4cHJlc3Mgb3VyIGFwcHJlY2lhdGlvbiBmb3IgeW91ciBjb250 aW51ZWQgY29uc2lkZXJhdGlvbjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0 OyBvZiB0aGlzIGltcG9ydGFudCB0b3BpYy48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgU2luY2VyZWx5 LDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBNaWNoYWVsIEZhcmdhbm8s PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IEJyb2FkYmFuZCBGb3J1bSBU ZWNobmljYWwgQ29tbWl0dGVlIENoYWlyPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyAmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IERhdGUgb2YgVXBj b21pbmcgQnJvYWRiYW5kIEZvcnVtIE1lZXRpbmdzIERBVEVTIExPQ0FUSU9OPC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBOb3ZlbWJlciAxNiDigJM8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7ICZndDsgMjAsIDIwMTUgUHVlcnRvIFZhbGxhcnRhLCBNZXhpY28gRmVi cnVhcnkgMSDigJMgNSwgMjAxNiBBc2lhIFBhYzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgJmd0OyAocHJlY2lzZSBsb2NhdGlvbiBUQkQpPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyAmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IE5v dGU6IEEgbGlzdCBvZiB1cGNvbWluZyBtZWV0aW5ncyBjYW4gYWxzbyBiZSBmb3VuZCBhdDwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyA8YSBocmVmPSJodHRwOi8vd3d3LmJy b2FkYmFuZGZvcnVtIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRp b246bm9uZSI+aHR0cDovL3d3dy5icm9hZGJhbmRmb3J1bTwvc3Bhbj48L2E+LjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBvcmcvbWVldGluZ3MvdXBjb21pbmdtZWV0aW5n c2F0YWdsYW5jZS5waHA8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgQXR0YWNobWVudHM6PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IMKnIFdULTMxOSBQYXJ0IEIgU3RyYXcgQmFs bG90IFRleHQgKGJiZjIwMTUuMDcxLjA3KTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgJmd0OyBBdHRhY2htZW50czo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZn dDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgQXR0YWNobWVudDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9s aWIvZHQvZG9jdW1lbnRzL0xJQUlTT04vbGlhaXNvbi0yMDE1LTEwLTE2LSI+DQo8c3BhbiBzdHls ZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbGliL2R0L2RvY3VtZW50cy9MSUFJU09OL2xpYWlzb24tMjAxNS0xMC0xNi08L3NwYW4+ PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBicm9hZGJhbmQtZm9y dW0tcnRnLWNjYW1wLXRlYXMtYWNoaWV2aW5nLXBhY2tldC1uZXR3b3JrLW9wdGltaXphdGlvbi08 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgdXNpbmctZHdkbS1pbnRlcmZh Y2VzLWF0dGFjaG1lbnQtMS5wZGY8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZn dDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgU3RhdGVtZW50PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2xp Yi9kdC9kb2N1bWVudHMvTElBSVNPTi9saWFpc29uLTIwMTUtMTAtMTYtIj4NCjxzcGFuIHN0eWxl PSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL3d3dy5pZXRm Lm9yZy9saWIvZHQvZG9jdW1lbnRzL0xJQUlTT04vbGlhaXNvbi0yMDE1LTEwLTE2LTwvc3Bhbj48 L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IGJyb2FkYmFuZC1mb3J1 bS1ydGctY2NhbXAtdGVhcy1hY2hpZXZpbmctcGFja2V0LW5ldHdvcmstb3B0aW1pemF0aW9uLTwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyB1c2luZy1kd2RtLWludGVyZmFj ZXMtYXR0YWNobWVudC0yLnBkZjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg Q0NBTVAgbWFpbGluZyBsaXN0PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8YSBo cmVmPSJtYWlsdG86Q0NBTVBAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0 O3RleHQtZGVjb3JhdGlvbjpub25lIj5DQ0FNUEBpZXRmLm9yZzwvc3Bhbj48L2E+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2NjYW1wIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0 LWRlY29yYXRpb246bm9uZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9j Y2FtcDwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgQ0NBTVAgbWFpbGluZyBsaXN0PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyA8YSBocmVmPSJtYWlsdG86Q0NBTVBAaWV0Zi5vcmciPjxzcGFuIHN0eWxl PSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5DQ0FNUEBpZXRmLm9yZzwv c3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wIj48c3BhbiBzdHlsZT0iY29s b3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9jY2FtcDwvc3Bhbj48L2E+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_4A1562797D64E44993C5CBF38CF1BE4812AC1963ESESSMB301erics_-- From nobody Sat Oct 31 21:45:09 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C76031B5EA8; Sat, 31 Oct 2015 21:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 BYmJjjERZXyc; Sat, 31 Oct 2015 21:44:56 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39BA71B5EA4; Sat, 31 Oct 2015 21:44:55 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BZP81258; Sun, 01 Nov 2015 04:44:52 +0000 (GMT) Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sun, 1 Nov 2015 04:42:40 +0000 Received: from SZXEMA504-MBX.china.huawei.com ([169.254.7.36]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0235.001; Sun, 1 Nov 2015 12:42:35 +0800 From: Zhenghaomian To: Daniele Ceccarelli , "'ccamp@ietf.org'" , "pce@ietf.org" , TEAS WG Thread-Topic: =?utf-8?B?SW5pdGlhbCB2ZXJzaW9uIGZvciBsaWFpc29uIHRleHQgLy/nrZTlpI06IENB?= =?utf-8?B?TEwgRk9SIFZPTFVOVEVFUiAtICBOZXcgTGlhaXNvbiBTdGF0ZW1lbnQsICJB?= =?utf-8?B?Y2hpZXZpbmcgUGFja2V0IE5ldHdvcmsgT3B0aW1pemF0aW9uIHVzaW5nIERX?= =?utf-8?Q?DM_Interfaces"?= Thread-Index: AdEQlwg0nBSjolVUTpmgrTvatjXCNADvVDxAAALBOGA= Date: Sun, 1 Nov 2015 04:42:34 +0000 Message-ID: References: <4A1562797D64E44993C5CBF38CF1BE4812AC1963@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE4812AC1963@ESESSMB301.ericsson.se> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.194.187.168] Content-Type: multipart/alternative; boundary="_000_E0C26CAA2504C84093A49B2CAC3261A438CE2607SZXEMA504MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Pce] =?utf-8?b?562U5aSNOiBJbml0aWFsIHZlcnNpb24gZm9yIGxpYWlzb24g?= =?utf-8?q?text_//=E7=AD=94=E5=A4=8D=3A_CALL_FOR_VOLUNTEER_-__New_Liaison_?= =?utf-8?q?Statement=2C_=22Achieving_Packet_Network_Optimization_using_DWD?= =?utf-8?q?M_Interfaces=22?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2015 04:45:04 -0000 --_000_E0C26CAA2504C84093A49B2CAC3261A438CE2607SZXEMA504MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIERhbmllbGUsDQoNCkluY29ycG9yYXRlIERocnV24oCZcyBuaXQsIHRoZSBQQ0VQIFJG QyBuby4gaXMgY29ycmVjdGVkIHRvIFJGQyA1NDQwLiAgRnVydGhlciBjb21tZW50cyB3ZWxjb21l ZOKYug0KDQoNCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNClRoZSB3b3JraW5nIGdy b3VwcyBpbiBJRVRGIHJvdXRpbmcgYXJlYSB3b3VsZCBsaWtlIHRvIHRoYW5rIHlvdSBmb3Igc2Vu ZGluZyB0aGlzIGxpYWlzb24uIFdlIG11Y2ggYXBwcmVjaWF0ZSBCQkYgb24gdGhlIGVmZm9ydCBv ZiBwYWNrZXQgb3ZlciBvcHRpY2FsLCBhbmQgc2VuZGluZyB0aGUgZG9jdW1lbnQgdG8gSUVURiBD Q0FNUCwgVEVBUyBhbmQgUENFIFdHcyBmb3IgcmV2aWV3LiBUaGlzIHByb2plY3QgZGVmaW5lcyBh IHNldCBvZiBjb250cm9sIHBsYW5lIHJlcXVpcmVtZW50cyB0aGF0IHRoZSBQaHlzaWNhbGx5IFNl cGFyYXRlZCBNb2RlbCBzaG91bGQgYmUgc2F0aXNmaWVkLiBXZSBoYXZlIHNvbWUgcXVlc3Rpb25z IGFuZCBjb21tZW50czoNCg0KDQoNClF1ZXN0aW9uczoNCg0KwrcgICAgICAgICBJdCBpcyBub3Qg Y2xlYXIgdG8gdXMgaG93IHRoZSBjb21tdW5pY2F0aW9uIGJldHdlZW4gdGhlIHBhY2tldCBsYXll ciBhbmQgdGhlIG9wdGljYWwgbGF5ZXIgb2NjdXJzLiBFLmcuIGNvbnRyb2wgY2hhbm5lbHMsIHNp Z25hbGluZyBhbmQgc28gb24uDQoNCsK3ICAgICAgICAgV2Ugd291bGQgbGlrZSB0byBzZWUgc29t ZSBtb3JlIGRldGFpbHMgb24gdGhlIG1hbmFnZW1lbnQgYXNwZWN0cyBiZXR3ZWVuIHRoZSBwYWNr ZXQgZG9tYWluIGFuZCB0aGUgb3B0aWNhbCBkb21haW4uDQoNCkNvbW1lbnRzOg0KDQrCtyAgICAg ICAgIFdoZW4gcmVmZXJyaW5nIHRvIFBDRSBhbmQgcmVsYXRlZCBpc3N1ZXMsIGUuZy4sIGluIFtS LTI2XSBhbmQgW1ItMjddLCBpdCBzZWVtcyBvbmx5IHN0YXRlbGVzcyBQQ0UgKFJGQzQ2NTUpIGFu ZCBjb3JyZXNwb25kaW5nIFBDRVAgKFJGQzU0NDApIGFyZSBpbmNsdWRlZCBpbiB0aGUgY3VycmVu dCB2ZXJzaW9uLiBBcyBJRVRGIFBDRSB3b3JraW5nIGdyb3VwIGlzIGludmVzdGlnYXRpbmcgb24g c3RhdGVmdWwgUENFLCBQQ0UgSW5pdGlhdGlvbiBhbmQgUENFIGFzIGEgQ2VudHJhbCBDb250cm9s bGVyLCB3aGljaCBhcmUgcGxhbm5lZCB0byBiZSBwdWJsaXNoZWQgaW4gdGhlIGZ1dHVyZSwgaXQg aXMgYmV0dGVyIHRvIHNwZWNpZnkgd2hpY2gga2luZCBvZiBQQ0UgaXMgbm93IHJlZmVycmVkIGJ5 IHRoaXMgZG9jdW1lbnRzLiBNb3Jlb3ZlciwgUkZDIDU2MjMsIFBDRS1iYXNlZCBpbnRlci1sYXll ciBNUExTIGFuZCBHTVBMUyBUcmFmZmljIEVuZ2luZWVyaW5nLCBtYXkgYmUgYSBnb29kIHJlZmVy ZW5jZSBmb3IgdGhpcyBkb2N1bWVudC4NCg0KwrcgICAgICAgICBJbiBzZWN0aW9uIDQuNCB3aGVu IHRhbGtpbmcgYWJvdXQgU0ROLCBPcGVuZmxvdyBpcyBtZW50aW9uZWQgYXMgYSBzdGFuZGFyZCBw cm90b2NvbCB0byBpbnRlcmFjdCBiZXR3ZWVuIHBhY2tldCBub2RlcyBhbmQgRFdETSBub2Rlcy4g V2Ugd291bGQgbGlrZSB0byBzdWdnZXN0IGFkZCBQQ0UgUHJvdG9jb2wgKFBDRVApIGFzIGFub3Ro ZXIgZXhhbXBsZSwgYXMgaXQgaXMgY3VycmVudGx5IHVzZWQgaW4gSUVURi4gQmVzaWRlcywgaXQg aXMgc3VnZ2VzdCB0byByZWZlcmVuY2UgdG8gUkZDIDM0MTMgYWJvdXQgU05NUCwgYW5kIFJGQyA0 MjA4IGFib3V0IEdNUExTIFVOSS4NCg0KwrcgICAgICAgICBJbiBzZWN0aW9uIDQuNSwgW1ItMzZd IGlzIG5vdCBjbGVhciB3aGV0aGVyIHRvIGJlIGFwcGxpZWQgdG8gdGhlIG5vcnRoLWJvdW5kIG9m IFNETiBjb250cm9sbGVyLCBvciBiZXR3ZWVuIHRoZSBwYWNrZXQgTkUgYW5kIFNETiBjb250cm9s bGVyLiBXZSBwcmVmZXIgdGhlIGxhdHRlciBvbmUuDQoNCg0KDQpJdCBzZWVtcyB0byB1cyB0aGUg cmVxdWlyZW1lbnRzIHByb3Bvc2VkIGluIHRoZSBjdXJyZW50IGRvY3VtZW50IGNvdWxkIGJlIGFk ZHJlc3NlZCBieSB0aGUgcmVmZXJlbmNlZCBSRkNzIGRlZmluZWQgZm9yIEdNUExTLCBzbyB3ZSB3 b3VsZCBsaWtlIHRvIG1ha2Ugc3VyZSBpZiB5b3UgaGF2ZSBpZGVudGlmaWVkIGFueSBnYXBzLCB3 aGljaCBuZWVkIGFuIHVwZGF0ZSBvbiBHTVBMUy9QQ0VQIHRvIHNhdGlzZnkgdGhlc2UgcmVxdWly ZW1lbnRzLiBJRVRGIENDQU1QIGlzIGRpc2N1c3NpbmcgdG8gZGVmaW5lIGEgZnJhbWV3b3JrIGZv ciBNYW5hZ2VtZW50IGFuZCBDb250cm9sIG9mIERXRE0gb3B0aWNhbCBpbnRlcmZhY2UgcGFyYW1l dGVycyBhbmQgR01QTFMgcHJvdG9jb2xzIHRoYXQgbmVlZCB0byBiZSB1cGRhdGVkLCB3aGljaCBt aWdodCBiZSByZWxldmFudCB0byB5b3VyIHByb2plY3QsIGJ1dCB0aGlzIHdvcmsgaW4gQ0NBTVAg aXMgc3RpbGwgaW4gaW5kaXZpZHVhbCBkcmFmdHMgc3RhZ2UuIFdlIHdvdWxkIGxpa2UgdG8gcmVj ZWl2ZSB5b3VyIGlucHV0Lg0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNCg0KVGhh bmtzLg0KDQpCZXN0IHdpc2hlcywNCkhhb21pYW4NCg0K5Y+R5Lu25Lq6OiBEYW5pZWxlIENlY2Nh cmVsbGkgW21haWx0bzpkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tXQ0K5Y+R6YCB5pe2 6Ze0OiAyMDE15bm0MTHmnIgx5pelIDExOjI3DQrmlLbku7bkuro6IFpoZW5naGFvbWlhbjsgJ2Nj YW1wQGlldGYub3JnJzsgcGNlQGlldGYub3JnOyBURUFTIFdHDQrkuLvpopg6IFJFOiBJbml0aWFs IHZlcnNpb24gZm9yIGxpYWlzb24gdGV4dCAvL+etlOWkjTogQ0FMTCBGT1IgVk9MVU5URUVSIC0g TmV3IExpYWlzb24gU3RhdGVtZW50LCAiQWNoaWV2aW5nIFBhY2tldCBOZXR3b3JrIE9wdGltaXph dGlvbiB1c2luZyBEV0RNIEludGVyZmFjZXMiDQoNCg0KSGkgSGFvbWlhbiwgYWxsLA0KDQoNCg0K VGhhbmtzIGZvciBzdGFydGluZyBwdXR0aW5nIHRvZ2V0aGVyIHRoZSByZXBseS4gUGxlYXNlIGZp bmQgc29tZSB1cGRhdGVkIHByb3Bvc2FscyBmcm9tIG15IHNpZGUuDQoNCg0KDQo9PT09PT09PT09 PT09PT09PT09PT09PT09PT0NCg0KVGhlIHdvcmtpbmcgZ3JvdXBzIGluIElFVEYgcm91dGluZyBh cmVhIHdvdWxkIGxpa2UgdG8gdGhhbmsgeW91IGZvciBzZW5kaW5nIHRoaXMgbGlhaXNvbi4gV2Ug bXVjaCBhcHByZWNpYXRlIEJCRiBvbiB0aGUgZWZmb3J0IG9mIHBhY2tldCBvdmVyIG9wdGljYWws IGFuZCBzZW5kaW5nIHRoZSBkb2N1bWVudCB0byBJRVRGIENDQU1QLCBURUFTIGFuZCBQQ0UgV0dz IGZvciByZXZpZXcuIFRoaXMgcHJvamVjdCBkZWZpbmVzIGEgc2V0IG9mIGNvbnRyb2wgcGxhbmUg cmVxdWlyZW1lbnRzIHRoYXQgdGhlIFBoeXNpY2FsbHkgU2VwYXJhdGVkIE1vZGVsIHNob3VsZCBi ZSBzYXRpc2ZpZWQuIFdlIGhhdmUgc29tZSBxdWVzdGlvbnMgYW5kIGNvbW1lbnRzOg0KDQoNCg0K UXVlc3Rpb25zOg0KDQrCtyAgICAgICAgIEl0IGlzIG5vdCBjbGVhciB0byB1cyBob3cgdGhlIGNv bW11bmljYXRpb24gYmV0d2VlbiB0aGUgcGFja2V0IGxheWVyIGFuZCB0aGUgb3B0aWNhbCBsYXll ciBvY2N1cnMuIEUuZy4gY29udHJvbCBjaGFubmVscywgc2lnbmFsaW5nIGFuZCBzbyBvbi4NCg0K wrcgICAgICAgICBXZSB3b3VsZCBsaWtlIHRvIHNlZSBzb21lIG1vcmUgZGV0YWlscyBvbiB0aGUg bWFuYWdlbWVudCBhc3BlY3RzIGJldHdlZW4gdGhlIHBhY2tldCBkb21haW4gYW5kIHRoZSBvcHRp Y2FsIGRvbWFpbi4NCg0KQ29tbWVudHM6DQoNCsK3ICAgICAgICAgV2hlbiByZWZlcnJpbmcgdG8g UENFIGFuZCByZWxhdGVkIGlzc3VlcywgZS5nLiwgaW4gW1ItMjZdIGFuZCBbUi0yN10sIGl0IHNl ZW1zIG9ubHkgc3RhdGVsZXNzIFBDRSAoUkZDNDY1NSkgYW5kIGNvcnJlc3BvbmRpbmcgUENFUCAo UkZDNTUyMCkgYXJlIGluY2x1ZGVkIGluIHRoZSBjdXJyZW50IHZlcnNpb24uIEFzIElFVEYgUENF IHdvcmtpbmcgZ3JvdXAgaXMgaW52ZXN0aWdhdGluZyBvbiBzdGF0ZWZ1bCBQQ0UsIFBDRSBJbml0 aWF0aW9uIGFuZCBQQ0UgYXMgYSBDZW50cmFsIENvbnRyb2xsZXIsIHdoaWNoIGFyZSBwbGFubmVk IHRvIGJlIHB1Ymxpc2hlZCBpbiB0aGUgZnV0dXJlLCBpdCBpcyBiZXR0ZXIgdG8gc3BlY2lmeSB3 aGljaCBraW5kIG9mIFBDRSBpcyBub3cgcmVmZXJyZWQgYnkgdGhpcyBkb2N1bWVudHMuIE1vcmVv dmVyLCBSRkMgNTYyMywgUENFLWJhc2VkIGludGVyLWxheWVyIE1QTFMgYW5kIEdNUExTIFRyYWZm aWMgRW5naW5lZXJpbmcsIG1heSBiZSBhIGdvb2QgcmVmZXJlbmNlIGZvciB0aGlzIGRvY3VtZW50 Lg0KDQrCtyAgICAgICAgIEluIHNlY3Rpb24gNC40IHdoZW4gdGFsa2luZyBhYm91dCBTRE4sIE9w ZW5mbG93IGlzIG1lbnRpb25lZCBhcyBhIHN0YW5kYXJkIHByb3RvY29sIHRvIGludGVyYWN0IGJl dHdlZW4gcGFja2V0IG5vZGVzIGFuZCBEV0RNIG5vZGVzLiBXZSB3b3VsZCBsaWtlIHRvIHN1Z2dl c3QgYWRkIFBDRSBQcm90b2NvbCAoUENFUCkgYXMgYW5vdGhlciBleGFtcGxlLCBhcyBpdCBpcyBj dXJyZW50bHkgdXNlZCBpbiBJRVRGLiBCZXNpZGVzLCBpdCBpcyBzdWdnZXN0IHRvIHJlZmVyZW5j ZSB0byBSRkMgMzQxMyBhYm91dCBTTk1QLCBhbmQgUkZDIDQyMDggYWJvdXQgR01QTFMgVU5JLg0K DQrCtyAgICAgICAgIEluIHNlY3Rpb24gNC41LCBbUi0zNl0gaXMgbm90IGNsZWFyIHdoZXRoZXIg dG8gYmUgYXBwbGllZCB0byB0aGUgbm9ydGgtYm91bmQgb2YgU0ROIGNvbnRyb2xsZXIsIG9yIGJl dHdlZW4gdGhlIHBhY2tldCBORSBhbmQgU0ROIGNvbnRyb2xsZXIuIFdlIHByZWZlciB0aGUgbGF0 dGVyIG9uZS4NCg0KDQoNCkl0IHNlZW1zIHRvIHVzIHRoZSByZXF1aXJlbWVudHMgcHJvcG9zZWQg aW4gdGhlIGN1cnJlbnQgZG9jdW1lbnQgY291bGQgYmUgYWRkcmVzc2VkIGJ5IHRoZSByZWZlcmVu Y2VkIFJGQ3MgZGVmaW5lZCBmb3IgR01QTFMsIHNvIHdlIHdvdWxkIGxpa2UgdG8gbWFrZSBzdXJl IGlmIHlvdSBoYXZlIGlkZW50aWZpZWQgYW55IGdhcHMsIHdoaWNoIG5lZWQgYW4gdXBkYXRlIG9u IEdNUExTL1BDRVAgdG8gc2F0aXNmeSB0aGVzZSByZXF1aXJlbWVudHMuIElFVEYgQ0NBTVAgaXMg ZGlzY3Vzc2luZyB0byBkZWZpbmUgYSBmcmFtZXdvcmsgZm9yIE1hbmFnZW1lbnQgYW5kIENvbnRy b2wgb2YgRFdETSBvcHRpY2FsIGludGVyZmFjZSBwYXJhbWV0ZXJzIGFuZCBHTVBMUyBwcm90b2Nv bHMgdGhhdCBuZWVkIHRvIGJlIHVwZGF0ZWQsIHdoaWNoIG1pZ2h0IGJlIHJlbGV2YW50IHRvIHlv dXIgcHJvamVjdCwgYnV0IHRoaXMgd29yayBpbiBDQ0FNUCBpcyBzdGlsbCBpbiBpbmRpdmlkdWFs IGRyYWZ0cyBzdGFnZS4gV2Ugd291bGQgbGlrZSB0byByZWNlaXZlIHlvdXIgaW5wdXQuDQoNCj09 PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KDQoNClRoYW5rcw0KDQpEYW5pZWxlDQoNCg0K DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCj4gRnJvbTogQ0NBTVAgW21haWx0bzpj Y2FtcC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgWmhlbmdoYW9taWFuDQoNCj4gU2Vu dDogbWFydGVkw6wgMjcgb3R0b2JyZSAyMDE1IDE4OjE3DQoNCj4gVG86ICdjY2FtcEBpZXRmLm9y Zyc7IHBjZUBpZXRmLm9yZzxtYWlsdG86cGNlQGlldGYub3JnPjsgVEVBUyBXRw0KDQo+IFN1Ympl Y3Q6IFtDQ0FNUF0gSW5pdGlhbCB2ZXJzaW9uIGZvciBsaWFpc29uIHRleHQgLy/nrZTlpI06IENB TEwgRk9SDQoNCj4gVk9MVU5URUVSIC0gTmV3IExpYWlzb24gU3RhdGVtZW50LCAiQWNoaWV2aW5n IFBhY2tldCBOZXR3b3JrDQoNCj4gT3B0aW1pemF0aW9uIHVzaW5nIERXRE0gSW50ZXJmYWNlcyIN Cg0KPg0KDQo+IEhpLCBBbGwsDQoNCj4NCg0KPiBBZnRlciByZXZpZXdpbmcgdGhlIGxpYWlzb24g YW5kIGRvY3VtZW50IGZyb20gQkJGLCB3ZSB3b3VsZCBsaWtlIHRvIHByb3ZpZGUNCg0KPiB0aGUg Zm9sbG93aW5nIHRleHQgYXMgYW4gaW5pdGlhbCB2ZXJzaW9uIGZvciByZXNwb25zZS4gUGxlYXNl IGhlbHAgcmV2aWV3LCB5b3VyDQoNCj4gY29tbWVudHMgYXJlIGhpZ2hseSB3ZWxjb21lZC4NCg0K Pg0KDQo+ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT1mb3INCg0KPiBkaXNj dXNzaW9uPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoN Cj4gVGhlIHdvcmtpbmcgZ3JvdXBzIGluIElFVEYgcm91dGluZyBhcmVhIHdvdWxkIGxpa2UgdG8g dGhhbmsgeW91IGZvciBzZW5kaW5nDQoNCj4gdGhpcyBsaWFpc29uLiBXZSBtdWNoIGFwcHJlY2lh dGUgQkJGIG9uIHRoZSBlZmZvcnQgb2YgcGFja2V0IG92ZXIgb3B0aWNhbCwgYW5kDQoNCj4gc2Vu ZGluZyB0aGUgZG9jdW1lbnQgdG8gSUVURiBDQ0FNUCwgVEVBUyBhbmQgUENFIFdHcyBmb3IgcmV2 aWV3LiBUaGlzDQoNCj4gcHJvamVjdCBkZWZpbmVzIGEgc2V0IG9mIGNvbnRyb2wgcGxhbmUgcmVx dWlyZW1lbnRzIHRoYXQgdGhlIFBoeXNpY2FsbHkNCg0KPiBTZXBhcmF0ZWQgTW9kZWwgc2hvdWxk IGJlIHNhdGlzZmllZC4gV2UgYXJlIGdlbmVyYWxseSBmaW5lIGFib3V0IHRoZQ0KDQo+IGNvbnRl bnQsIHdpdGggc29tZSBtaW5vciBzdWdnZXN0aW9ucyBsaXN0ZWQgYXMgZm9sbG93IGZvciB5b3Vy IHJlZmVyZW5jZToNCg0KPg0KDQo+IOKAoiBXaGVuIHJlZmVycmluZyB0byBQQ0UgYW5kIHJlbGF0 ZWQgaXNzdWVzLCBlLmcuLCBpbiBbUi0yNl0gYW5kIFtSLTI3XSwgaXQNCg0KPiBzZWVtcyBvbmx5 IHN0YXRlbGVzcyBQQ0UgKFJGQzQ2NTUpIGFuZCBjb3JyZXNwb25kaW5nIFBDRVAgKFJGQzU1MjAp IGFyZQ0KDQo+IGluY2x1ZGVkIGluIHRoZSBjdXJyZW50IHZlcnNpb24uIEFzIElFVEYgUENFIHdv cmtpbmcgZ3JvdXAgaXMgaW52ZXN0aWdhdGluZyBvbg0KDQo+IHN0YXRlZnVsIFBDRSwgUENFIElu aXRpYXRpb24gYW5kIFBDRSBhcyBhIENlbnRyYWwgQ29udHJvbGxlciwgd2hpY2ggYXJlIHBsYW5u ZWQNCg0KPiB0byBiZSBwdWJsaXNoZWQgaW4gdGhlIGZ1dHVyZSwgaXQgaXMgYmV0dGVyIHRvIHNw ZWNpZnkgd2hpY2gga2luZCBvZiBQQ0UgaXMgbm93DQoNCj4gcmVmZXJyZWQgYnkgdGhpcyBkb2N1 bWVudHMuIE1vcmVvdmVyLCBSRkMgNTYyMywgUENFLWJhc2VkIGludGVyLWxheWVyDQoNCj4gTVBM UyBhbmQgR01QTFMgVHJhZmZpYyBFbmdpbmVlcmluZywgbWF5IGJlIGEgZ29vZCByZWZlcmVuY2Ug Zm9yIHRoaXMNCg0KPiBkb2N1bWVudC4NCg0KPiDigKIgSW4gc2VjdGlvbiA0LjQgd2hlbiB0YWxr aW5nIGFib3V0IFNETiwgT3BlbmZsb3cgaXMgbWVudGlvbmVkIGFzIGENCg0KPiBzdGFuZGFyZCBw cm90b2NvbCB0byBpbnRlcmFjdCBiZXR3ZWVuIHBhY2tldCBub2RlcyBhbmQgRFdETSBub2Rlcy4g V2UNCg0KPiB3b3VsZCBsaWtlIHRvIHN1Z2dlc3QgYWRkIFBDRSBQcm90b2NvbCAoUENFUCkgYXMg YW5vdGhlciBleGFtcGxlLCBhcyBpdCBpcw0KDQo+IGN1cnJlbnRseSB1c2VkIGluIElFVEYuIEJl c2lkZXMsIGl0IGlzIHN1Z2dlc3QgdG8gcmVmZXJlbmNlIHRvIFJGQyAzNDEzIGFib3V0DQoNCj4g U05NUCwgYW5kIFJGQyA0MjA4IGFib3V0IEdNUExTIFVOSS4NCg0KPiDigKIgSW4gc2VjdGlvbiA0 LjUsIFtSLTM2XSBpcyBub3QgY2xlYXIgd2hldGhlciB0byBiZSBhcHBsaWVkIHRvIHRoZSBub3J0 aC1ib3VuZA0KDQo+IG9mIFNETiBjb250cm9sbGVyLCBvciBiZXR3ZWVuIHRoZSBwYWNrZXQgTkUg YW5kIFNETiBjb250cm9sbGVyLiBXZSBwcmVmZXINCg0KPiB0aGUgbGF0dGVyIG9uZS4NCg0KPg0K DQo+IEl0IHNlZW1zIHRvIHVzIHRoZSByZXF1aXJlbWVudHMgcHJvcG9zZWQgaW4gdGhlIGN1cnJl bnQgZG9jdW1lbnQgY291bGQgYmUNCg0KPiBhZGRyZXNzZWQgYnkgdGhlIHJlZmVyZW5jZWQgUkZD cyBkZWZpbmVkIGZvciBHTVBMUywgc28gd2Ugd291bGQgbGlrZSB0bw0KDQo+IG1ha2Ugc3VyZSBp ZiB5b3UgaGF2ZSBpZGVudGlmaWVkIGFueSBnYXBzLCB3aGljaCBuZWVkIGFuIHVwZGF0ZSBvbiBH TVBMUw0KDQo+IHRvIHNhdGlzZnkgdGhlc2UgcmVxdWlyZW1lbnRzLiBJRVRGIENDQU1QIGlzIGRp c2N1c3NpbmcgdG8gZGVmaW5lIGENCg0KPiBmcmFtZXdvcmsgZm9yIE1hbmFnZW1lbnQgYW5kIENv bnRyb2wgb2YgRFdETSBvcHRpY2FsIGludGVyZmFjZQ0KDQo+IHBhcmFtZXRlcnMgYW5kIEdNUExT IHByb3RvY29scyB0aGF0IG5lZWQgdG8gYmUgdXBkYXRlZCwgd2hpY2ggbWlnaHQgYmUNCg0KPiBy ZWxldmFudCB0byB5b3VyIHByb2plY3QsIGJ1dCB0aGlzIHdvcmsgaW4gQ0NBTVAgaXMgc3RpbGwg aW4gaW5kaXZpZHVhbCBkcmFmdHMNCg0KPiBzdGFnZS4gV2Ugd291bGQgbGlrZSB0byByZWNlaXZl IHlvdXIgaW5wdXQuDQoNCj4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQ0KDQo+ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09DQoNCj4NCg0KPiBUaGFua3MuDQoNCj4NCg0KPiBCZXN0 IHdpc2hlcywNCg0KPiBIYW9taWFuDQoNCj4NCg0KPiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQoN Cj4g5Y+R5Lu25Lq6OiBaaGVuZ2hhb21pYW4NCg0KPiDlj5HpgIHml7bpl7Q6IDIwMTXlubQxMOac iDIx5pelIDExOjExDQoNCj4g5pS25Lu25Lq6OiBEYW5pZWxlIENlY2NhcmVsbGk7IEZhdGFpIFpo YW5nDQoNCj4g5oqE6YCBOiBjY2FtcEBpZXRmLm9yZzxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+DQoN Cj4g5Li76aKYOiDnrZTlpI06IENBTEwgRk9SIFZPTFVOVEVFUiAtIE5ldyBMaWFpc29uIFN0YXRl bWVudCwgIkFjaGlldmluZw0KDQo+IFBhY2tldCBOZXR3b3JrIE9wdGltaXphdGlvbiB1c2luZyBE V0RNIEludGVyZmFjZXMiDQoNCj4NCg0KPiBEYW5pZWxlLCBGYXRhaSBhbmQgQWxsLA0KDQo+DQoN Cj4gSSB3b3VsZCBsaWtlIHRvIHZvbHVudGVlciBmb3IgZ2VuZXJhdGluZyB0aGUgcmVzcG9uc2Ug bGlhaXNvbiwgYXMgdGhlIHRvcGljIGlzDQoNCj4gaGlnaGx5IHJlbGF0ZWQgdG8gbXkgcmVzZWFy Y2ggd29yay4gSSB3aWxsIHJldmlldyB0aGUgZG9jdW1lbnQgYW5kIHNoYXJlIG15DQoNCj4gY29t bWVudHMgZWFybHkgbmV4dCB3ZWVrLiBQbGVhc2UgYWxzbyBmZWVsIGZyZWUgdG8gc2hhcmUgeW91 ciBvcGluaW9uLA0KDQo+IHRoYW5rcy4NCg0KPg0KDQo+IEJlc3Qgd2lzaGVzLA0KDQo+IEhhb21p YW4NCg0KPg0KDQo+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCg0KPiDlj5Hku7bkuro6IENDQU1Q IFttYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIERhbmllbGUgQ2VjY2FyZWxs aQ0KDQo+IOWPkemAgeaXtumXtDogMjAxNeW5tDEw5pyIMjDml6UgMjM6NDYNCg0KPiDmlLbku7bk uro6IENDQU1QIChjY2FtcEBpZXRmLm9yZzxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+KQ0KDQo+IOS4 u+mimDogW0NDQU1QXSBDQUxMIEZPUiBWT0xVTlRFRVIgLSBOZXcgTGlhaXNvbiBTdGF0ZW1lbnQs ICJBY2hpZXZpbmcNCg0KPiBQYWNrZXQgTmV0d29yayBPcHRpbWl6YXRpb24gdXNpbmcgRFdETSBJ bnRlcmZhY2VzIg0KDQo+DQoNCj4gV0csDQoNCj4NCg0KPiBXZSByZWNlaXZlZCB0aGlzIGxpYWlz b24gZnJvbSBCQkYgb24gUGFja2V0LU9wdGljYWwgaW50ZWdyYXRpb24uDQoNCj4gSSdtIGNvcHlp bmcgdGhlIGxpbmtzIHRvIGxpYWlzb24gYW5kIGF0dGFjaG1lbnQgaGVyZSBmb3IgeW91ciBjb252 ZW5pZW5jZQ0KDQo+IExpYWlzb246ICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2xpYWlz b24vMTQzMi8NCg0KPiBBdHRhY2htZW50OiBodHRwczovL3d3dy5pZXRmLm9yZy9saWIvZHQvZG9j dW1lbnRzL0xJQUlTT04vbGlhaXNvbi0yMDE1LTxodHRwczovL3d3dy5pZXRmLm9yZy9saWIvZHQv ZG9jdW1lbnRzL0xJQUlTT04vbGlhaXNvbi0yMDE1LTEwLTE2LWJyb2FkYmFuZC1mb3J1bS1ydGct Y2NhbXAtdGVhcy1hY2hpZXZpbmctcGFja2V0LW5ldHdvcmstb3B0aW1pemF0aW9uLXVzaW5nLWR3 ZG0taW50ZXJmYWNlcy1hdHRhY2htZW50LTEucGRmPg0KDQo+IDEwLTE2LWJyb2FkYmFuZC1mb3J1 bS1ydGctY2NhbXAtdGVhcy1hY2hpZXZpbmctcGFja2V0LW5ldHdvcmstPGh0dHBzOi8vd3d3Lmll dGYub3JnL2xpYi9kdC9kb2N1bWVudHMvTElBSVNPTi9saWFpc29uLTIwMTUtMTAtMTYtYnJvYWRi YW5kLWZvcnVtLXJ0Zy1jY2FtcC10ZWFzLWFjaGlldmluZy1wYWNrZXQtbmV0d29yay1vcHRpbWl6 YXRpb24tdXNpbmctZHdkbS1pbnRlcmZhY2VzLWF0dGFjaG1lbnQtMS5wZGY+DQoNCj4gb3B0aW1p emF0aW9uLXVzaW5nLWR3ZG0taW50ZXJmYWNlcy1hdHRhY2htZW50LTEucGRmPGh0dHBzOi8vd3d3 LmlldGYub3JnL2xpYi9kdC9kb2N1bWVudHMvTElBSVNPTi9saWFpc29uLTIwMTUtMTAtMTYtYnJv YWRiYW5kLWZvcnVtLXJ0Zy1jY2FtcC10ZWFzLWFjaGlldmluZy1wYWNrZXQtbmV0d29yay1vcHRp bWl6YXRpb24tdXNpbmctZHdkbS1pbnRlcmZhY2VzLWF0dGFjaG1lbnQtMS5wZGY+DQoNCj4NCg0K PiBXZSdkIHJlYWxseSBsaWtlIDEgb3IgMiB2b2x1bnRlZXJzIGludGVyZXN0ZWQgaW4gdGhlIHRv cGljIHRvIGRyYWZ0IGFuIGFuc3dlciB0bw0KDQo+IHRoZSBsaWFpc29uIGJlZm9yZSB0aGUgbWVl dGluZyBpbiBZb2tvaGFtYSBzbyB0byBiZSBhYmxlIHRvIGRpc2N1c3MgaXQgb24gdGhlDQoNCj4g bGlzdCBhbmQgcmVwbHkgZHVyaW5nIG9yIGltbWVkaWF0ZWx5IGFmdGVyIHRoZSBtZWV0aW5nLg0K DQo+DQoNCj4gUGxlYXNlIGNvbnNpZGVyIHZvbHVudGVlcmluZy4NCg0KPiBUaGFua3MNCg0KPiBG YXRhaSAmIERhbmllbGUNCg0KPg0KDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0K PiA+IEZyb206IExpYWlzb24gU3RhdGVtZW50IE1hbmFnZW1lbnQgVG9vbCBbbWFpbHRvOmxzbXRA aWV0Zi5vcmddDQoNCj4gPiBTZW50OiB2ZW5lcmTDrCAxNiBvdHRvYnJlIDIwMTUgMjI6MDUNCg0K PiA+IFRvOiBkYjM1NDZAYXR0LmNvbTxtYWlsdG86ZGIzNTQ2QGF0dC5jb20+OyB2YmVlcmFtQGp1 bmlwZXIubmV0PG1haWx0bzp2YmVlcmFtQGp1bmlwZXIubmV0PjsgYWthdGxhc0BnbWFpbC5jb208 bWFpbHRvOmFrYXRsYXNAZ21haWwuY29tPjsNCg0KPiA+IGFyZXRhbmFAY2lzY28uY29tPG1haWx0 bzphcmV0YW5hQGNpc2NvLmNvbT47IGxiZXJnZXJAbGFibi5uZXQ8bWFpbHRvOmxiZXJnZXJAbGFi bi5uZXQ+OyB6aGFuZ2ZhdGFpQGh1YXdlaS5jb208bWFpbHRvOnpoYW5nZmF0YWlAaHVhd2VpLmNv bT47IERhbmllbGUNCg0KPiA+IENlY2NhcmVsbGkNCg0KPiA+IENjOiBBbHZhcm8gUmV0YW5hOyBE ZWJvcmFoIEJydW5nYXJkOyBEYXZpZCBTaW5pY3JvcGU7IEZhdGFpIFpoYW5nOw0KDQo+ID4gQWxp YSBBdGxhczsgVmlzaG51IFBhdmFuIEJlZXJhbTsgVGhlIElFVEYgQ2hhaXI7IERhbmllbGUgQ2Vj Y2FyZWxsaTsNCg0KPiA+IExvdSBCZXJnZXI7IENvbW1vbiBDb250cm9sIGFuZCBNZWFzdXJlbWVu dCBQbGFuZSBEaXNjdXNzaW9uIExpc3Q7DQoNCj4gPiBtaWNoYWVsLmZhcmdhbm9AY2VudHVyeWxp bmsuY29tPG1haWx0bzptaWNoYWVsLmZhcmdhbm9AY2VudHVyeWxpbmsuY29tPjsgVHJhZmZpYyBF bmdpbmVlcmluZyBBcmNoaXRlY3R1cmUgYW5kDQoNCj4gPiBTaWduYWxpbmcgRGlzY3Vzc2lvbiBM aXN0DQoNCj4gPiBTdWJqZWN0OiBOZXcgTGlhaXNvbiBTdGF0ZW1lbnQsICJBY2hpZXZpbmcgUGFj a2V0IE5ldHdvcmsgT3B0aW1pemF0aW9uDQoNCj4gPiB1c2luZyBEV0RNIEludGVyZmFjZXMiDQoN Cj4gPg0KDQo+ID4gVGl0bGU6IEFjaGlldmluZyBQYWNrZXQgTmV0d29yayBPcHRpbWl6YXRpb24g dXNpbmcgRFdETSBJbnRlcmZhY2VzDQoNCj4gPiBTdWJtaXNzaW9uIERhdGU6IDIwMTUtMTAtMTYg VVJMIG9mIHRoZSBJRVRGIFdlYiBwYWdlOg0KDQo+ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9saWFpc29uLzE0MzIvDQoNCj4gPiBQbGVhc2UgcmVwbHkgYnkgMjAxNS0xMS0wOA0KDQo+ ID4gRnJvbTogIChEYXZpZCBTaW5pY3JvcGUgPGRhdmlkLnNpbmljcm9wZUBlcmljc3Nvbi5jb208 bWFpbHRvOmRhdmlkLnNpbmljcm9wZUBlcmljc3Nvbi5jb20+PikNCg0KPiA+IFRvOiAgKHZiZWVy YW1AanVuaXBlci5uZXQ8bWFpbHRvOnZiZWVyYW1AanVuaXBlci5uZXQ+LCBsYmVyZ2VyQGxhYm4u bmV0PG1haWx0bzpsYmVyZ2VyQGxhYm4ubmV0PiwgYWthdGxhc0BnbWFpbC5jb208bWFpbHRvOmFr YXRsYXNAZ21haWwuY29tPiwNCg0KPiA+IGFyZXRhbmFAY2lzY28uY29tPG1haWx0bzphcmV0YW5h QGNpc2NvLmNvbT4sIGRiMzU0NkBhdHQuY29tPG1haWx0bzpkYjM1NDZAYXR0LmNvbT4sIGRhbmll bGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb208bWFpbHRvOmRhbmllbGUuY2VjY2FyZWxsaUBlcmlj c3Nvbi5jb20+LA0KDQo+ID4gemhhbmdmYXRhaUBodWF3ZWkuY29tPG1haWx0bzp6aGFuZ2ZhdGFp QGh1YXdlaS5jb20+KQ0KDQo+ID4gQ2M6DQoNCj4gPiBSZXNwb25zZSBDb250YWN0czogbWljaGFl bC5mYXJnYW5vQGNlbnR1cnlsaW5rLmNvbTxtYWlsdG86bWljaGFlbC5mYXJnYW5vQGNlbnR1cnls aW5rLmNvbT4gVGVjaG5pY2FsIENvbnRhY3RzOg0KDQo+ID4gUHVycG9zZTogRm9yIGNvbW1lbnQN Cg0KPiA+DQoNCj4gPiBCb2R5OiBEZWFyIElFVEYgUm91dGluZyBBcmVhIGFuZCBXb3JraW5nIEdy b3VwIExlYWRlcnM6DQoNCj4gPg0KDQo+ID4gQXMgcHJldmlvdXNseSBjb21tdW5pY2F0ZWQsIHdl IGhhdmUgYmVlbiB3b3JraW5nIG9uIGEgcHJvamVjdCBlbnRpdGxlZA0KDQo+ID4g4oCcQWNoaWV2 aW5nIFBhY2tldCBOZXR3b3JrIE9wdGltaXphdGlvbiB1c2luZyBEV0RNIEludGVyZmFjZXPigJ0g YW5kIGFyZQ0KDQo+ID4gcmVmZXJlbmNpbmcgd29yayBiZWluZyBkb25lIGJ5IElFVEYgQ0NBTVAg YW5kIFRFQVMgaW4gdGhpcyBhcmVhLiBXZQ0KDQo+ID4gYXJlIHBsZWFzZWQgdG8gcmVwb3J0IHRo YXQgd2UgaGF2ZSBtYWRlIHNpZ25pZmljYW50IHByb2dyZXNzIHRvd2FyZHMNCg0KPiA+IGNvbXBs ZXRpb24gb2Ygb3VyIHNwZWNpZmljYXRpb25zLiBTcGVjaWZpY2FsbHksDQoNCj4gPg0KDQo+ID4g byBUUi0zMTkgQmFzZSwg4oCcQWNoaWV2aW5nIFBhY2tldCBOZXR3b3JrIE9wdGltaXphdGlvbiB1 c2luZyBEV0RNDQoNCj4gPiBJbnRlcmZhY2Vz4oCdLCB3YXMgcHVibGlzaGVkIEp1bmUgMjAxNSBv IFRSLTMxOSBQYXJ0IEEsIOKAnEFjaGlldmluZw0KDQo+ID4gUGFja2V0IE5ldHdvcmsgT3B0aW1p emF0aW9uIHVzaW5nIERXRE0gSW50ZXJmYWNlcyDigJMgUGh5c2ljYWxseQ0KDQo+ID4gSW50ZWdy YXRlZCBNb2RlbOKAnSwgd2FzIHB1Ymxpc2hlZCBKdW5lIDIwMTUNCg0KPiA+DQoNCj4gPiBXVC0z MTkgUGFydCBCLCBBY2hpZXZpbmcgUGFja2V0IE5ldHdvcmsgT3B0aW1pemF0aW9uIHVzaW5nIERX RE0NCg0KPiA+IEludGVyZmFjZXMg4oCTIFBoeXNpY2FsbHkgU2VwYXJhdGVkLCBMb2dpY2FsbHkg U2VwYXJhdGVkLCBpcyB1bmRlcmdvaW5nDQoNCj4gPiBTdHJhdyBCYWxsb3QgKHNpbWlsYXIgdG8g SUVURiBXRyBMYXN0IENhbGwpLCBhbmQgd2UgYXJlIGF0dGFjaGluZyBpdCBmb3IgeW91cg0KDQo+ IHJldmlldyBhbmQgY29tbWVudC4NCg0KPiA+DQoNCj4gPiBPdXIgYmFsbG90IHBlcmlvZCBjbG9z ZXMgb24gTm92ZW1iZXIgOCwgMjAxNS4gSWYgaXQgaXMgYXQgYWxsDQoNCj4gPiBwb3NzaWJsZSwg d2Ugd291bGQgYXBwcmVjaWF0ZSBhbmQgbG9vayBmb3J3YXJkIHRvIGFueSBpbnB1dCBpbiB0aW1l DQoNCj4gPiBmb3Igb3VyIGJhbGxvdCBjbG9zZS4gVGhlIG5leHQgbWVldGluZyBvZiBCQkYgb2Nj dXJzIE5vdmVtYmVyIDE2LA0KDQo+ID4gMjAxNS4gQSBzY2hlZHVsZSBvZiBvdXIgZnV0dXJlIG1l ZXRpbmdzIGFwcGVhcnMgYmVsb3cuDQoNCj4gPg0KDQo+ID4gV2Ugd2FudCB0byBleHByZXNzIG91 ciBhcHByZWNpYXRpb24gZm9yIHlvdXIgY29udGludWVkIGNvbnNpZGVyYXRpb24NCg0KPiA+IG9m IHRoaXMgaW1wb3J0YW50IHRvcGljLg0KDQo+ID4NCg0KPiA+IFNpbmNlcmVseSwNCg0KPiA+IE1p Y2hhZWwgRmFyZ2FubywNCg0KPiA+IEJyb2FkYmFuZCBGb3J1bSBUZWNobmljYWwgQ29tbWl0dGVl IENoYWlyDQoNCj4gPg0KDQo+ID4gRGF0ZSBvZiBVcGNvbWluZyBCcm9hZGJhbmQgRm9ydW0gTWVl dGluZ3MgREFURVMgTE9DQVRJT04NCg0KPiBOb3ZlbWJlciAxNiDigJMNCg0KPiA+IDIwLCAyMDE1 IFB1ZXJ0byBWYWxsYXJ0YSwgTWV4aWNvIEZlYnJ1YXJ5IDEg4oCTIDUsIDIwMTYgQXNpYSBQYWMN Cg0KPiA+IChwcmVjaXNlIGxvY2F0aW9uIFRCRCkNCg0KPiA+DQoNCj4gPiBOb3RlOiBBIGxpc3Qg b2YgdXBjb21pbmcgbWVldGluZ3MgY2FuIGFsc28gYmUgZm91bmQgYXQNCg0KPiA+IGh0dHA6Ly93 d3cuYnJvYWRiYW5kZm9ydW0uDQoNCj4gPiBvcmcvbWVldGluZ3MvdXBjb21pbmdtZWV0aW5nc2F0 YWdsYW5jZS5waHANCg0KPiA+DQoNCj4gPiBBdHRhY2htZW50czoNCg0KPiA+IMKnIFdULTMxOSBQ YXJ0IEIgU3RyYXcgQmFsbG90IFRleHQgKGJiZjIwMTUuMDcxLjA3KQ0KDQo+ID4gQXR0YWNobWVu dHM6DQoNCj4gPg0KDQo+ID4gICAgIEF0dGFjaG1lbnQNCg0KPiA+ICAgICBodHRwczovL3d3dy5p ZXRmLm9yZy9saWIvZHQvZG9jdW1lbnRzL0xJQUlTT04vbGlhaXNvbi0yMDE1LTEwLTE2LQ0KDQo+ ID4gYnJvYWRiYW5kLWZvcnVtLXJ0Zy1jY2FtcC10ZWFzLWFjaGlldmluZy1wYWNrZXQtbmV0d29y ay1vcHRpbWl6YXRpb24tDQoNCj4gPiB1c2luZy1kd2RtLWludGVyZmFjZXMtYXR0YWNobWVudC0x LnBkZg0KDQo+ID4NCg0KPiA+ICAgICBTdGF0ZW1lbnQNCg0KPiA+ICAgICBodHRwczovL3d3dy5p ZXRmLm9yZy9saWIvZHQvZG9jdW1lbnRzL0xJQUlTT04vbGlhaXNvbi0yMDE1LTEwLTE2LQ0KDQo+ ID4gYnJvYWRiYW5kLWZvcnVtLXJ0Zy1jY2FtcC10ZWFzLWFjaGlldmluZy1wYWNrZXQtbmV0d29y ay1vcHRpbWl6YXRpb24tDQoNCj4gPiB1c2luZy1kd2RtLWludGVyZmFjZXMtYXR0YWNobWVudC0y LnBkZg0KDQo+DQoNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCg0KPiBDQ0FNUCBtYWlsaW5nIGxpc3QNCg0KPiBDQ0FNUEBpZXRmLm9yZzxtYWlsdG86 Q0NBTVBAaWV0Zi5vcmc+DQoNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9jY2FtcA0KDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQoNCj4gQ0NBTVAgbWFpbGluZyBsaXN0DQoNCj4gQ0NBTVBAaWV0Zi5vcmc8bWFpbHRvOkND QU1QQGlldGYub3JnPg0KDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v Y2NhbXANCg== --_000_E0C26CAA2504C84093A49B2CAC3261A438CE2607SZXEMA504MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNUyBHb3RoaWMiOw0KCXBhbm9zZS0xOjIgMTEgNiA5 IDcgMiA1IDggMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6TWluZ0xpVTsNCglwYW5v c2UtMToyIDIgNSA5IDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNh bWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBh bm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToi XEBNaW5nTGlVIjsNCglwYW5vc2UtMToyIDIgNSA5IDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IlxATVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4 IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bh bi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxp Lk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6Iue6r+aWh+acrCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNv QWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IuaJueaz qOahhuaWh+acrCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30N CnNwYW4uQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi57qv5paH5pysIENoYXIiOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazrnuq/mlofmnKw7DQoJZm9udC1mYW1pbHk6 5a6L5L2TO30NCnNwYW4uQ2hhcjANCgl7bXNvLXN0eWxlLW5hbWU6IuaJueazqOahhuaWh+acrCBD aGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms65om55rOo5qGG 5paH5pysOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KcC5QbGFpblRl eHQsIGxpLlBsYWluVGV4dCwgZGl2LlBsYWluVGV4dA0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4g VGV4dCI7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5 bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7fQ0KcC5CYWxsb29uVGV4dCwgbGkuQmFsbG9vblRleHQsIGRpdi5CYWxsb29uVGV4dA0K CXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IjsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpz cGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0 IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjUNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDEyOS43 NXB0IDcwLjg1cHQgMTI5LjdwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE1 ODY0NTU2NTM7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz OjYwNTMyMjI1NiA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2 NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6 bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZl bDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9t OjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBEYW5pZWxlLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+SW5jb3Jwb3JhdGUgRGhydXbigJlzIG5pdCwg dGhlIFBDRVAgUkZDIG5vLiBpcyBjb3JyZWN0ZWQgdG8gUkZDIDU0NDAuICZuYnNwO0Z1cnRoZXIg Y29tbWVudHMgd2VsY29tZWQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj5KPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj49 PT09PT09PT09PT09PT09PT09PT09PT09PT08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIHdvcmtpbmcgZ3JvdXBzIGlu IElFVEYgcm91dGluZyBhcmVhIHdvdWxkIGxpa2UgdG8gdGhhbmsgeW91IGZvciBzZW5kaW5nIHRo aXMgbGlhaXNvbi4gV2UgbXVjaCBhcHByZWNpYXRlIEJCRiBvbiB0aGUgZWZmb3J0IG9mIHBhY2tl dCBvdmVyIG9wdGljYWwsIGFuZCBzZW5kaW5nIHRoZSBkb2N1bWVudCB0byBJRVRGIENDQU1QLCBU RUFTIGFuZCBQQ0UgV0dzIGZvciByZXZpZXcuDQogVGhpcyBwcm9qZWN0IGRlZmluZXMgYSBzZXQg b2YgY29udHJvbCBwbGFuZSByZXF1aXJlbWVudHMgdGhhdCB0aGUgUGh5c2ljYWxseSBTZXBhcmF0 ZWQgTW9kZWwgc2hvdWxkIGJlIHNhdGlzZmllZC4gV2UgaGF2ZSBzb21lIHF1ZXN0aW9ucyBhbmQg Y29tbWVudHM6DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlF1ZXN0aW9uczo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPg0KPCFb aWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTpT eW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6 Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlm XT48c3BhbiBsYW5nPSJFTi1VUyI+SXQgaXMgbm90IGNsZWFyIHRvIHVzIGhvdyB0aGUgY29tbXVu aWNhdGlvbiBiZXR3ZWVuIHRoZSBwYWNrZXQgbGF5ZXIgYW5kIHRoZSBvcHRpY2FsIGxheWVyIG9j Y3Vycy4gRS5nLiBjb250cm9sIGNoYW5uZWxzLCBzaWduYWxpbmcgYW5kIHNvIG9uLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQo8 IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9u dDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5k aWZdPjxzcGFuIGxhbmc9IkVOLVVTIj5XZSB3b3VsZCBsaWtlIHRvIHNlZSBzb21lIG1vcmUgZGV0 YWlscyBvbiB0aGUgbWFuYWdlbWVudCBhc3BlY3RzIGJldHdlZW4gdGhlIHBhY2tldCBkb21haW4g YW5kIHRoZSBvcHRpY2FsIGRvbWFpbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Q29tbWVudHM6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4NCjwhW2lmICFz dXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9s Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0 ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNw YW4gbGFuZz0iRU4tVVMiPldoZW4gcmVmZXJyaW5nIHRvIFBDRSBhbmQgcmVsYXRlZCBpc3N1ZXMs IGUuZy4sIGluIFtSLTI2XSBhbmQgW1ItMjddLCBpdCBzZWVtcyBvbmx5IHN0YXRlbGVzcyBQQ0Ug KFJGQzQ2NTUpIGFuZCBjb3JyZXNwb25kaW5nIFBDRVAgKFJGQzU0NDApIGFyZSBpbmNsdWRlZCBp biB0aGUgY3VycmVudCB2ZXJzaW9uLiBBcyBJRVRGIFBDRSB3b3JraW5nIGdyb3VwIGlzDQogaW52 ZXN0aWdhdGluZyBvbiBzdGF0ZWZ1bCBQQ0UsIFBDRSBJbml0aWF0aW9uIGFuZCBQQ0UgYXMgYSBD ZW50cmFsIENvbnRyb2xsZXIsIHdoaWNoIGFyZSBwbGFubmVkIHRvIGJlIHB1Ymxpc2hlZCBpbiB0 aGUgZnV0dXJlLCBpdCBpcyBiZXR0ZXIgdG8gc3BlY2lmeSB3aGljaCBraW5kIG9mIFBDRSBpcyBu b3cgcmVmZXJyZWQgYnkgdGhpcyBkb2N1bWVudHMuIE1vcmVvdmVyLCBSRkMgNTYyMywgUENFLWJh c2VkIGludGVyLWxheWVyIE1QTFMgYW5kDQogR01QTFMgVHJhZmZpYyBFbmdpbmVlcmluZywgbWF5 IGJlIGEgZ29vZCByZWZlcmVuY2UgZm9yIHRoaXMgZG9jdW1lbnQuIDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7 dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3Vw cG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+ PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAm cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFu IGxhbmc9IkVOLVVTIj5JbiBzZWN0aW9uIDQuNCB3aGVuIHRhbGtpbmcgYWJvdXQgU0ROLCBPcGVu ZmxvdyBpcyBtZW50aW9uZWQgYXMgYSBzdGFuZGFyZCBwcm90b2NvbCB0byBpbnRlcmFjdCBiZXR3 ZWVuIHBhY2tldCBub2RlcyBhbmQgRFdETSBub2Rlcy4gV2Ugd291bGQgbGlrZSB0byBzdWdnZXN0 IGFkZCBQQ0UgUHJvdG9jb2wgKFBDRVApIGFzIGFub3RoZXIgZXhhbXBsZSwgYXMgaXQNCiBpcyBj dXJyZW50bHkgdXNlZCBpbiBJRVRGLiBCZXNpZGVzLCBpdCBpcyBzdWdnZXN0IHRvIHJlZmVyZW5j ZSB0byBSRkMgMzQxMyBhYm91dCBTTk1QLCBhbmQgUkZDIDQyMDggYWJvdXQgR01QTFMgVU5JLg0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBs Zm8yIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0 eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bh bj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiPkluIHNlY3Rpb24gNC41LCBbUi0zNl0gaXMg bm90IGNsZWFyIHdoZXRoZXIgdG8gYmUgYXBwbGllZCB0byB0aGUgbm9ydGgtYm91bmQgb2YgU0RO IGNvbnRyb2xsZXIsIG9yIGJldHdlZW4gdGhlIHBhY2tldCBORSBhbmQgU0ROIGNvbnRyb2xsZXIu IFdlIHByZWZlciB0aGUgbGF0dGVyIG9uZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+SXQg c2VlbXMgdG8gdXMgdGhlIHJlcXVpcmVtZW50cyBwcm9wb3NlZCBpbiB0aGUgY3VycmVudCBkb2N1 bWVudCBjb3VsZCBiZSBhZGRyZXNzZWQgYnkgdGhlIHJlZmVyZW5jZWQgUkZDcyBkZWZpbmVkIGZv ciBHTVBMUywgc28gd2Ugd291bGQgbGlrZSB0byBtYWtlIHN1cmUgaWYgeW91IGhhdmUgaWRlbnRp ZmllZCBhbnkgZ2Fwcywgd2hpY2ggbmVlZCBhbiB1cGRhdGUgb24gR01QTFMvUENFUA0KIHRvIHNh dGlzZnkgdGhlc2UgcmVxdWlyZW1lbnRzLiBJRVRGIENDQU1QIGlzIGRpc2N1c3NpbmcgdG8gZGVm aW5lIGEgZnJhbWV3b3JrIGZvciBNYW5hZ2VtZW50IGFuZCBDb250cm9sIG9mIERXRE0gb3B0aWNh bCBpbnRlcmZhY2UgcGFyYW1ldGVycyBhbmQgR01QTFMgcHJvdG9jb2xzIHRoYXQgbmVlZCB0byBi ZSB1cGRhdGVkLCB3aGljaCBtaWdodCBiZSByZWxldmFudCB0byB5b3VyIHByb2plY3QsIGJ1dCB0 aGlzIHdvcmsgaW4gQ0NBTVAgaXMgc3RpbGwNCiBpbiBpbmRpdmlkdWFsIGRyYWZ0cyBzdGFnZS4g V2Ugd291bGQgbGlrZSB0byByZWNlaXZlIHlvdXIgaW5wdXQuIDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj49PT09PT09PT09 PT09PT09PT09PT09PT09PT09PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+VGhh bmtzLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj5CZXN0IHdpc2hl cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+SGFvbWlhbjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk65a6L5L2TIj7lj5Hku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTrl rovkvZMiPiBEYW5pZWxlIENlY2NhcmVsbGkgW21haWx0bzpkYW5pZWxlLmNlY2NhcmVsbGlAZXJp Y3Nzb24uY29tXQ0KPGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OuWui+S9kyI+5Y+R6YCB5pe26Ze0PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3Nw YW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk65a6L5L2TIj4gMjAxNTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTrlrovkvZMiPuW5tDxzcGFuIGxhbmc9IkVOLVVTIj4xMTwvc3Bhbj7m nIg8c3BhbiBsYW5nPSJFTi1VUyI+MTwvc3Bhbj7ml6U8c3BhbiBsYW5nPSJFTi1VUyI+DQogMTE6 Mjc8YnI+DQo8L3NwYW4+PGI+5pS25Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9i PjxzcGFuIGxhbmc9IkVOLVVTIj4gWmhlbmdoYW9taWFuOyAnY2NhbXBAaWV0Zi5vcmcnOyBwY2VA aWV0Zi5vcmc7IFRFQVMgV0c8YnI+DQo8L3NwYW4+PGI+5Li76aKYPHNwYW4gbGFuZz0iRU4tVVMi Pjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gUkU6IEluaXRpYWwgdmVyc2lvbiBmb3Ig bGlhaXNvbiB0ZXh0IC8vPC9zcGFuPuetlOWkjTxzcGFuIGxhbmc9IkVOLVVTIj46IENBTEwgRk9S IFZPTFVOVEVFUiAtIE5ldyBMaWFpc29uIFN0YXRlbWVudCwgJnF1b3Q7QWNoaWV2aW5nIFBhY2tl dCBOZXR3b3JrIE9wdGltaXphdGlvbiB1c2luZyBEV0RNIEludGVyZmFjZXMmcXVvdDs8bzpwPjwv bzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+SGkgSGFvbWlhbiwgYWxsLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmtzIGZvciBzdGFydGluZyBwdXR0aW5nIHRvZ2V0 aGVyIHRoZSByZXBseS4gUGxlYXNlIGZpbmQgc29tZSB1cGRhdGVkIHByb3Bvc2FscyBmcm9tIG15 IHNpZGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj49PT09PT09PT09PT09PT09PT09PT09PT09 PT08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1VUyI+VGhlIHdvcmtpbmcgZ3JvdXBzIGluIElFVEYgcm91dGluZyBhcmVhIHdvdWxk IGxpa2UgdG8gdGhhbmsgeW91IGZvciBzZW5kaW5nIHRoaXMgbGlhaXNvbi4gV2UgbXVjaCBhcHBy ZWNpYXRlIEJCRiBvbiB0aGUgZWZmb3J0IG9mIHBhY2tldCBvdmVyIG9wdGljYWwsIGFuZCBzZW5k aW5nIHRoZSBkb2N1bWVudCB0byBJRVRGIENDQU1QLCBURUFTIGFuZCBQQ0UgV0dzIGZvciByZXZp ZXcuDQogVGhpcyBwcm9qZWN0IGRlZmluZXMgYSBzZXQgb2YgY29udHJvbCBwbGFuZSByZXF1aXJl bWVudHMgdGhhdCB0aGUgUGh5c2ljYWxseSBTZXBhcmF0ZWQgTW9kZWwgc2hvdWxkIGJlIHNhdGlz ZmllZC4gV2UgaGF2ZSBzb21lIHF1ZXN0aW9ucyBhbmQgY29tbWVudHM6DQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g bGFuZz0iRU4tVVMiPlF1ZXN0aW9uczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O3RleHQtaW5kZW50Oi0xOC4w cHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28t bGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyI+SXQg aXMgbm90IGNsZWFyIHRvIHVzIGhvdyB0aGUgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIHRoZSBwYWNr ZXQgbGF5ZXIgYW5kIHRoZSBvcHRpY2FsIGxheWVyIG9jY3Vycy4gRS5nLiBjb250cm9sIGNoYW5u ZWxzLCBzaWduYWxpbmcgYW5kIHNvIG9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7dGV4dC1pbmRlbnQ6LTE4 LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1z by1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIj5X ZSB3b3VsZCBsaWtlIHRvIHNlZSBzb21lIG1vcmUgZGV0YWlscyBvbiB0aGUgbWFuYWdlbWVudCBh c3BlY3RzIGJldHdlZW4gdGhlIHBhY2tldCBkb21haW4gYW5kIHRoZSBvcHRpY2FsIGRvbWFpbi48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n PSJFTi1VUyI+Q29tbWVudHM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21z by1saXN0OmwwIGxldmVsMSBsZm8yIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6 SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8 L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiPldoZW4gcmVm ZXJyaW5nIHRvIFBDRSBhbmQgcmVsYXRlZCBpc3N1ZXMsIGUuZy4sIGluIFtSLTI2XSBhbmQgW1It MjddLCBpdCBzZWVtcyBvbmx5IHN0YXRlbGVzcyBQQ0UgKFJGQzQ2NTUpIGFuZCBjb3JyZXNwb25k aW5nIFBDRVAgKFJGQzU1MjApIGFyZSBpbmNsdWRlZCBpbiB0aGUgY3VycmVudCB2ZXJzaW9uLiBB cyBJRVRGIFBDRSB3b3JraW5nIGdyb3VwIGlzDQogaW52ZXN0aWdhdGluZyBvbiBzdGF0ZWZ1bCBQ Q0UsIFBDRSBJbml0aWF0aW9uIGFuZCBQQ0UgYXMgYSBDZW50cmFsIENvbnRyb2xsZXIsIHdoaWNo IGFyZSBwbGFubmVkIHRvIGJlIHB1Ymxpc2hlZCBpbiB0aGUgZnV0dXJlLCBpdCBpcyBiZXR0ZXIg dG8gc3BlY2lmeSB3aGljaCBraW5kIG9mIFBDRSBpcyBub3cgcmVmZXJyZWQgYnkgdGhpcyBkb2N1 bWVudHMuIE1vcmVvdmVyLCBSRkMgNTYyMywgUENFLWJhc2VkIGludGVyLWxheWVyIE1QTFMgYW5k DQogR01QTFMgVHJhZmZpYyBFbmdpbmVlcmluZywgbWF5IGJlIGEgZ29vZCByZWZlcmVuY2UgZm9y IHRoaXMgZG9jdW1lbnQuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28t bGlzdDpsMCBsZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Okln bm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9z cGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIj5JbiBzZWN0aW9u IDQuNCB3aGVuIHRhbGtpbmcgYWJvdXQgU0ROLCBPcGVuZmxvdyBpcyBtZW50aW9uZWQgYXMgYSBz dGFuZGFyZCBwcm90b2NvbCB0byBpbnRlcmFjdCBiZXR3ZWVuIHBhY2tldCBub2RlcyBhbmQgRFdE TSBub2Rlcy4gV2Ugd291bGQgbGlrZSB0byBzdWdnZXN0IGFkZCBQQ0UgUHJvdG9jb2wgKFBDRVAp IGFzIGFub3RoZXIgZXhhbXBsZSwgYXMgaXQNCiBpcyBjdXJyZW50bHkgdXNlZCBpbiBJRVRGLiBC ZXNpZGVzLCBpdCBpcyBzdWdnZXN0IHRvIHJlZmVyZW5jZSB0byBSRkMgMzQxMyBhYm91dCBTTk1Q LCBhbmQgUkZDIDQyMDggYWJvdXQgR01QTFMgVU5JLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDt0ZXh0LWlu ZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4NCjwhW2lmICFzdXBwb3J0TGlz dHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0i RU4tVVMiPkluIHNlY3Rpb24gNC41LCBbUi0zNl0gaXMgbm90IGNsZWFyIHdoZXRoZXIgdG8gYmUg YXBwbGllZCB0byB0aGUgbm9ydGgtYm91bmQgb2YgU0ROIGNvbnRyb2xsZXIsIG9yIGJldHdlZW4g dGhlIHBhY2tldCBORSBhbmQgU0ROIGNvbnRyb2xsZXIuIFdlIHByZWZlciB0aGUgbGF0dGVyIG9u ZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+SXQgc2VlbXMgdG8gdXMgdGhlIHJlcXVpcmVt ZW50cyBwcm9wb3NlZCBpbiB0aGUgY3VycmVudCBkb2N1bWVudCBjb3VsZCBiZSBhZGRyZXNzZWQg YnkgdGhlIHJlZmVyZW5jZWQgUkZDcyBkZWZpbmVkIGZvciBHTVBMUywgc28gd2Ugd291bGQgbGlr ZSB0byBtYWtlIHN1cmUgaWYgeW91IGhhdmUgaWRlbnRpZmllZCBhbnkgZ2Fwcywgd2hpY2ggbmVl ZCBhbiB1cGRhdGUgb24gR01QTFMvUENFUA0KIHRvIHNhdGlzZnkgdGhlc2UgcmVxdWlyZW1lbnRz LiBJRVRGIENDQU1QIGlzIGRpc2N1c3NpbmcgdG8gZGVmaW5lIGEgZnJhbWV3b3JrIGZvciBNYW5h Z2VtZW50IGFuZCBDb250cm9sIG9mIERXRE0gb3B0aWNhbCBpbnRlcmZhY2UgcGFyYW1ldGVycyBh bmQgR01QTFMgcHJvdG9jb2xzIHRoYXQgbmVlZCB0byBiZSB1cGRhdGVkLCB3aGljaCBtaWdodCBi ZSByZWxldmFudCB0byB5b3VyIHByb2plY3QsIGJ1dCB0aGlzIHdvcmsgaW4gQ0NBTVAgaXMgc3Rp bGwNCiBpbiBpbmRpdmlkdWFsIGRyYWZ0cyBzdGFnZS4gV2Ugd291bGQgbGlrZSB0byByZWNlaXZl IHlvdXIgaW5wdXQuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIGxhbmc9IkVOLVVTIj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIGxhbmc9IkVOLVVTIj5UaGFua3MgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkRhbmllbGU8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g bGFuZz0iRU4tVVMiPiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0 OyBGcm9tOiBDQ0FNUCBbPGEgaHJlZj0ibWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmciPm1h aWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIFpoZW5naGFvbWlh bjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh bmc9IkVOLVVTIj4mZ3Q7IFNlbnQ6IG1hcnRlZMOsIDI3IG90dG9icmUgMjAxNSAxODoxNzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO LVVTIj4mZ3Q7IFRvOiAnY2NhbXBAaWV0Zi5vcmcnOyA8YSBocmVmPSJtYWlsdG86cGNlQGlldGYu b3JnIj4NCnBjZUBpZXRmLm9yZzwvYT47IFRFQVMgV0c8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBTdWJqZWN0OiBb Q0NBTVBdIEluaXRpYWwgdmVyc2lvbiBmb3IgbGlhaXNvbiB0ZXh0IC8vPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuetlOWkjTwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+OiBDQUxMIEZPUjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IFZPTFVOVEVFUiAtIE5ldyBM aWFpc29uIFN0YXRlbWVudCwgJnF1b3Q7QWNoaWV2aW5nIFBhY2tldCBOZXR3b3JrPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi PiZndDsgT3B0aW1pemF0aW9uIHVzaW5nIERXRE0gSW50ZXJmYWNlcyZxdW90OzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4m Z3Q7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IGxhbmc9IkVOLVVTIj4mZ3Q7IEhpLCBBbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsg QWZ0ZXIgcmV2aWV3aW5nIHRoZSBsaWFpc29uIGFuZCBkb2N1bWVudCBmcm9tIEJCRiwgd2Ugd291 bGQgbGlrZSB0byBwcm92aWRlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgdGhlIGZvbGxvd2luZyB0ZXh0IGFzIGFu IGluaXRpYWwgdmVyc2lvbiBmb3IgcmVzcG9uc2UuIFBsZWFzZSBoZWxwIHJldmlldywgeW91cjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj4mZ3Q7IGNvbW1lbnRzIGFyZSBoaWdobHkgd2VsY29tZWQuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsg PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZndDsgPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PWZvcjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj4mZ3Q7IGRpc2N1c3Npb249PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBUaGUgd29ya2luZyBncm91cHMgaW4gSUVURiBy b3V0aW5nIGFyZWEgd291bGQgbGlrZSB0byB0aGFuayB5b3UgZm9yIHNlbmRpbmc8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+ Jmd0OyB0aGlzIGxpYWlzb24uIFdlIG11Y2ggYXBwcmVjaWF0ZSBCQkYgb24gdGhlIGVmZm9ydCBv ZiBwYWNrZXQgb3ZlciBvcHRpY2FsLCBhbmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBzZW5kaW5nIHRoZSBkb2N1 bWVudCB0byBJRVRGIENDQU1QLCBURUFTIGFuZCBQQ0UgV0dzIGZvciByZXZpZXcuIFRoaXM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+Jmd0OyBwcm9qZWN0IGRlZmluZXMgYSBzZXQgb2YgY29udHJvbCBwbGFuZSByZXF1aXJl bWVudHMgdGhhdCB0aGUgUGh5c2ljYWxseTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IFNlcGFyYXRlZCBNb2RlbCBz aG91bGQgYmUgc2F0aXNmaWVkLiBXZSBhcmUgZ2VuZXJhbGx5IGZpbmUgYWJvdXQgdGhlPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4t VVMiPiZndDsgY29udGVudCwgd2l0aCBzb21lIG1pbm9yIHN1Z2dlc3Rpb25zIGxpc3RlZCBhcyBm b2xsb3cgZm9yIHlvdXIgcmVmZXJlbmNlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IOKA oiBXaGVuIHJlZmVycmluZyB0byBQQ0UgYW5kIHJlbGF0ZWQgaXNzdWVzLCBlLmcuLCBpbiBbUi0y Nl0gYW5kIFtSLTI3XSwgaXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBzZWVtcyBvbmx5IHN0YXRlbGVzcyBQQ0Ug KFJGQzQ2NTUpIGFuZCBjb3JyZXNwb25kaW5nIFBDRVAgKFJGQzU1MjApIGFyZTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4m Z3Q7IGluY2x1ZGVkIGluIHRoZSBjdXJyZW50IHZlcnNpb24uIEFzIElFVEYgUENFIHdvcmtpbmcg Z3JvdXAgaXMgaW52ZXN0aWdhdGluZyBvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IHN0YXRlZnVsIFBDRSwgUENF IEluaXRpYXRpb24gYW5kIFBDRSBhcyBhIENlbnRyYWwgQ29udHJvbGxlciwgd2hpY2ggYXJlIHBs YW5uZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBsYW5nPSJFTi1VUyI+Jmd0OyB0byBiZSBwdWJsaXNoZWQgaW4gdGhlIGZ1dHVyZSwgaXQgaXMg YmV0dGVyIHRvIHNwZWNpZnkgd2hpY2gga2luZCBvZiBQQ0UgaXMgbm93PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsg cmVmZXJyZWQgYnkgdGhpcyBkb2N1bWVudHMuIE1vcmVvdmVyLCBSRkMgNTYyMywgUENFLWJhc2Vk IGludGVyLWxheWVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgTVBMUyBhbmQgR01QTFMgVHJhZmZpYyBFbmdpbmVl cmluZywgbWF5IGJlIGEgZ29vZCByZWZlcmVuY2UgZm9yIHRoaXM8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBkb2N1 bWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBsYW5nPSJFTi1VUyI+Jmd0OyDigKIgSW4gc2VjdGlvbiA0LjQgd2hlbiB0YWxraW5nIGFib3V0 IFNETiwgT3BlbmZsb3cgaXMgbWVudGlvbmVkIGFzIGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBzdGFuZGFyZCBw cm90b2NvbCB0byBpbnRlcmFjdCBiZXR3ZWVuIHBhY2tldCBub2RlcyBhbmQgRFdETSBub2Rlcy4g V2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1VUyI+Jmd0OyB3b3VsZCBsaWtlIHRvIHN1Z2dlc3QgYWRkIFBDRSBQcm90b2NvbCAo UENFUCkgYXMgYW5vdGhlciBleGFtcGxlLCBhcyBpdCBpczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IGN1cnJlbnRs eSB1c2VkIGluIElFVEYuIEJlc2lkZXMsIGl0IGlzIHN1Z2dlc3QgdG8gcmVmZXJlbmNlIHRvIFJG QyAzNDEzIGFib3V0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgU05NUCwgYW5kIFJGQyA0MjA4IGFib3V0IEdNUExT IFVOSS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBsYW5nPSJFTi1VUyI+Jmd0OyDigKIgSW4gc2VjdGlvbiA0LjUsIFtSLTM2XSBpcyBub3QgY2xl YXIgd2hldGhlciB0byBiZSBhcHBsaWVkIHRvIHRoZSBub3J0aC1ib3VuZDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7 IG9mIFNETiBjb250cm9sbGVyLCBvciBiZXR3ZWVuIHRoZSBwYWNrZXQgTkUgYW5kIFNETiBjb250 cm9sbGVyLiBXZSBwcmVmZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyB0aGUgbGF0dGVyIG9uZS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+ Jmd0OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBsYW5nPSJFTi1VUyI+Jmd0OyBJdCBzZWVtcyB0byB1cyB0aGUgcmVxdWlyZW1lbnRzIHByb3Bv c2VkIGluIHRoZSBjdXJyZW50IGRvY3VtZW50IGNvdWxkIGJlPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgYWRkcmVz c2VkIGJ5IHRoZSByZWZlcmVuY2VkIFJGQ3MgZGVmaW5lZCBmb3IgR01QTFMsIHNvIHdlIHdvdWxk IGxpa2UgdG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBtYWtlIHN1cmUgaWYgeW91IGhhdmUgaWRlbnRpZmllZCBh bnkgZ2Fwcywgd2hpY2ggbmVlZCBhbiB1cGRhdGUgb24gR01QTFM8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyB0byBz YXRpc2Z5IHRoZXNlIHJlcXVpcmVtZW50cy4gSUVURiBDQ0FNUCBpcyBkaXNjdXNzaW5nIHRvIGRl ZmluZSBhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gbGFuZz0iRU4tVVMiPiZndDsgZnJhbWV3b3JrIGZvciBNYW5hZ2VtZW50IGFuZCBDb250cm9s IG9mIERXRE0gb3B0aWNhbCBpbnRlcmZhY2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBwYXJhbWV0ZXJzIGFuZCBH TVBMUyBwcm90b2NvbHMgdGhhdCBuZWVkIHRvIGJlIHVwZGF0ZWQsIHdoaWNoIG1pZ2h0IGJlPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RU4tVVMiPiZndDsgcmVsZXZhbnQgdG8geW91ciBwcm9qZWN0LCBidXQgdGhpcyB3b3JrIGluIEND QU1QIGlzIHN0aWxsIGluIGluZGl2aWR1YWwgZHJhZnRzPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgc3RhZ2UuIFdl IHdvdWxkIGxpa2UgdG8gcmVjZWl2ZSB5b3VyIGlucHV0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7ID09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1V UyI+Jmd0OyA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IFRoYW5rcy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0 OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1VUyI+Jmd0OyBCZXN0IHdpc2hlcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBIYW9taWFuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4t VVMiPiZndDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgLS0tLS08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5Ok1pbmdMaVUiPumCruS7tuWOn+S7tjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+LS0tLS08 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n PSJFTi1VUyI+Jmd0OyA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5Ok1pbmdMaVUiPuWP keS7tuS6ujwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+OiBaaGVuZ2hhb21pYW48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+ Jmd0OyA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5Ok1pbmdMaVUiPuWPkemAgeaXtumX tDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+OiAyMDE1PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuW5tDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+MTA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90 OyI+5pyIPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4yMTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7ml6U8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPg0KIDExOjExPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuaUtuS7tuS6ujwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+OiBEYW5pZWxlIENlY2NhcmVsbGk7IEZhdGFpIFpoYW5nPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuaKhOmAgTwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+Og0KPGEgaHJlZj0ibWFpbHRvOmNjYW1wQGlldGYub3Jn Ij48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+Y2Nh bXBAaWV0Zi5vcmc8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IDwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7kuLs8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5Ok1pbmdMaVUiPumimDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+Og0KPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuetlOWk jTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+OiBDQUxMIEZPUiBWT0xVTlRFRVIgLSBOZXcgTGlh aXNvbiBTdGF0ZW1lbnQsICZxdW90O0FjaGlldmluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IFBhY2tldCBOZXR3 b3JrIE9wdGltaXphdGlvbiB1c2luZyBEV0RNIEludGVyZmFjZXMmcXVvdDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0 OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1VUyI+Jmd0OyBEYW5pZWxlLCBGYXRhaSBhbmQgQWxsLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj4mZ3Q7IEkgd291bGQgbGlrZSB0byB2b2x1bnRlZXIgZm9yIGdlbmVyYXRpbmcgdGhl IHJlc3BvbnNlIGxpYWlzb24sIGFzIHRoZSB0b3BpYyBpczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IGhpZ2hseSBy ZWxhdGVkIHRvIG15IHJlc2VhcmNoIHdvcmsuIEkgd2lsbCByZXZpZXcgdGhlIGRvY3VtZW50IGFu ZCBzaGFyZSBteTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IGNvbW1lbnRzIGVhcmx5IG5leHQgd2Vlay4gUGxlYXNl IGFsc28gZmVlbCBmcmVlIHRvIHNoYXJlIHlvdXIgb3Bpbmlvbiw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyB0aGFu a3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g bGFuZz0iRU4tVVMiPiZndDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgQmVzdCB3aXNoZXMsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZn dDsgSGFvbWlhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IC0tLS0tPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTpNaW5nTGlVIj7pgq7ku7bljp/ku7Y8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPi0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTpNaW5nTGlVIj7lj5Hku7bkuro8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjogQ0NBTVAg WzxhIGhyZWY9Im1haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29s b3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+bWFpbHRvOmNjYW1wLWJvdW5jZXNA aWV0Zi5vcmc8L3NwYW4+PC9hPl0NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7TVMgR290aGljJnF1b3Q7Ij7ku6Pooag8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPiBEYW5p ZWxlIENlY2NhcmVsbGk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5Ok1pbmdMaVUiPuWPkemAgeaXtumXtDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+OiAyMDE1 PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuW5 tDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+MTA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+5pyIPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4y MDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7m l6U8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPg0KIDIzOjQ2PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuaUtuS7tuS6 ujwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+OiBDQ0FNUCAoPGEgaHJlZj0ibWFpbHRvOmNjYW1w QGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246 bm9uZSI+Y2NhbXBAaWV0Zi5vcmc8L3NwYW4+PC9hPik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyA8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+5Li7PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTpNaW5nTGlVIj7popg8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjogW0NDQU1QXSBDQUxMIEZPUiBWT0xVTlRFRVIgLSBOZXcgTGlhaXNvbiBTdGF0ZW1lbnQs ICZxdW90O0FjaGlldmluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IFBhY2tldCBOZXR3b3JrIE9wdGltaXphdGlv biB1c2luZyBEV0RNIEludGVyZmFjZXMmcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyA8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0 OyBXRyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBsYW5nPSJFTi1VUyI+Jmd0OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBXZSByZWNlaXZlZCB0aGlzIGxpYWlz b24gZnJvbSBCQkYgb24gUGFja2V0LU9wdGljYWwgaW50ZWdyYXRpb24uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsg SSdtIGNvcHlpbmcgdGhlIGxpbmtzIHRvIGxpYWlzb24gYW5kIGF0dGFjaG1lbnQgaGVyZSBmb3Ig eW91ciBjb252ZW5pZW5jZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IExpYWlzb246Jm5ic3A7IDxhIGhyZWY9Imh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbGlhaXNvbi8xNDMyLyI+DQo8c3BhbiBzdHlsZT0i Y29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9saWFpc29uLzE0MzIvPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBBdHRhY2ht ZW50OiA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9saWIvZHQvZG9jdW1lbnRzL0xJQUlT T04vbGlhaXNvbi0yMDE1LTEwLTE2LWJyb2FkYmFuZC1mb3J1bS1ydGctY2NhbXAtdGVhcy1hY2hp ZXZpbmctcGFja2V0LW5ldHdvcmstb3B0aW1pemF0aW9uLXVzaW5nLWR3ZG0taW50ZXJmYWNlcy1h dHRhY2htZW50LTEucGRmIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVj b3JhdGlvbjpub25lIj5odHRwczovL3d3dy5pZXRmLm9yZy9saWIvZHQvZG9jdW1lbnRzL0xJQUlT T04vbGlhaXNvbi0yMDE1LTwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL2xpYi9kdC9kb2N1bWVudHMvTElBSVNPTi9saWFpc29uLTIwMTUtMTAtMTYtYnJv YWRiYW5kLWZvcnVtLXJ0Zy1jY2FtcC10ZWFzLWFjaGlldmluZy1wYWNrZXQtbmV0d29yay1vcHRp bWl6YXRpb24tdXNpbmctZHdkbS1pbnRlcmZhY2VzLWF0dGFjaG1lbnQtMS5wZGYiPjxzcGFuIHN0 eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj4mZ3Q7DQogMTAtMTYt YnJvYWRiYW5kLWZvcnVtLXJ0Zy1jY2FtcC10ZWFzLWFjaGlldmluZy1wYWNrZXQtbmV0d29yay08 L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9saWIvZHQv ZG9jdW1lbnRzL0xJQUlTT04vbGlhaXNvbi0yMDE1LTEwLTE2LWJyb2FkYmFuZC1mb3J1bS1ydGct Y2NhbXAtdGVhcy1hY2hpZXZpbmctcGFja2V0LW5ldHdvcmstb3B0aW1pemF0aW9uLXVzaW5nLWR3 ZG0taW50ZXJmYWNlcy1hdHRhY2htZW50LTEucGRmIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93 dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+Jmd0Ow0KIG9wdGltaXphdGlvbi11c2luZy1kd2Rt LWludGVyZmFjZXMtYXR0YWNobWVudC0xLnBkZjwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RU4tVVMiPiZndDsgV2UnZCByZWFsbHkgbGlrZSAxIG9yIDIgdm9sdW50ZWVycyBpbnRlcmVzdGVk IGluIHRoZSB0b3BpYyB0byBkcmFmdCBhbiBhbnN3ZXIgdG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyB0aGUgbGlh aXNvbiBiZWZvcmUgdGhlIG1lZXRpbmcgaW4gWW9rb2hhbWEgc28gdG8gYmUgYWJsZSB0byBkaXNj dXNzIGl0IG9uIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IGxpc3QgYW5kIHJlcGx5IGR1cmluZyBvciBpbW1l ZGlhdGVseSBhZnRlciB0aGUgbWVldGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBQ bGVhc2UgY29uc2lkZXIgdm9sdW50ZWVyaW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IFRoYW5rczxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVT Ij4mZ3Q7IEZhdGFpICZhbXA7IERhbmllbGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAm Z3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgJmd0OyBGcm9tOiBM aWFpc29uIFN0YXRlbWVudCBNYW5hZ2VtZW50IFRvb2wgWzxhIGhyZWY9Im1haWx0bzpsc210QGll dGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9u ZSI+bWFpbHRvOmxzbXRAaWV0Zi5vcmc8L3NwYW4+PC9hPl08bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAmZ3Q7IFNl bnQ6IHZlbmVyZMOsIDE2IG90dG9icmUgMjAxNSAyMjowNTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7ICZndDsgVG86 IDxhIGhyZWY9Im1haWx0bzpkYjM1NDZAYXR0LmNvbSI+DQo8c3BhbiBzdHlsZT0iY29sb3I6d2lu ZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+ZGIzNTQ2QGF0dC5jb208L3NwYW4+PC9hPjsg PGEgaHJlZj0ibWFpbHRvOnZiZWVyYW1AanVuaXBlci5uZXQiPg0KPHNwYW4gc3R5bGU9ImNvbG9y OndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPnZiZWVyYW1AanVuaXBlci5uZXQ8L3Nw YW4+PC9hPjsNCjxhIGhyZWY9Im1haWx0bzpha2F0bGFzQGdtYWlsLmNvbSI+PHNwYW4gc3R5bGU9 ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmFrYXRsYXNAZ21haWwuY29t PC9zcGFuPjwvYT47PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgJmd0OyA8YSBocmVmPSJtYWlsdG86YXJldGFuYUBj aXNjby5jb20iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9u Om5vbmUiPmFyZXRhbmFAY2lzY28uY29tPC9zcGFuPjwvYT47DQo8YSBocmVmPSJtYWlsdG86bGJl cmdlckBsYWJuLm5ldCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0 aW9uOm5vbmUiPmxiZXJnZXJAbGFibi5uZXQ8L3NwYW4+PC9hPjsNCjxhIGhyZWY9Im1haWx0bzp6 aGFuZ2ZhdGFpQGh1YXdlaS5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQt ZGVjb3JhdGlvbjpub25lIj56aGFuZ2ZhdGFpQGh1YXdlaS5jb208L3NwYW4+PC9hPjsgRGFuaWVs ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh bmc9IkVOLVVTIj4mZ3Q7ICZndDsgQ2VjY2FyZWxsaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7ICZndDsgQ2M6IEFs dmFybyBSZXRhbmE7IERlYm9yYWggQnJ1bmdhcmQ7IERhdmlkIFNpbmljcm9wZTsgRmF0YWkgWmhh bmc7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g bGFuZz0iRU4tVVMiPiZndDsgJmd0OyBBbGlhIEF0bGFzOyBWaXNobnUgUGF2YW4gQmVlcmFtOyBU aGUgSUVURiBDaGFpcjsgRGFuaWVsZSBDZWNjYXJlbGxpOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7ICZndDsgTG91 IEJlcmdlcjsgQ29tbW9uIENvbnRyb2wgYW5kIE1lYXN1cmVtZW50IFBsYW5lIERpc2N1c3Npb24g TGlzdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBsYW5nPSJFTi1VUyI+Jmd0OyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzptaWNoYWVsLmZhcmdhbm9A Y2VudHVyeWxpbmsuY29tIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVj b3JhdGlvbjpub25lIj5taWNoYWVsLmZhcmdhbm9AY2VudHVyeWxpbmsuY29tPC9zcGFuPjwvYT47 IFRyYWZmaWMgRW5naW5lZXJpbmcgQXJjaGl0ZWN0dXJlIGFuZDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7ICZndDsg U2lnbmFsaW5nIERpc2N1c3Npb24gTGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7ICZndDsgU3ViamVjdDogTmV3 IExpYWlzb24gU3RhdGVtZW50LCAmcXVvdDtBY2hpZXZpbmcgUGFja2V0IE5ldHdvcmsgT3B0aW1p emF0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gbGFuZz0iRU4tVVMiPiZndDsgJmd0OyB1c2luZyBEV0RNIEludGVyZmFjZXMmcXVvdDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+Jmd0OyAmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgJmd0OyBUaXRsZTogQWNoaWV2aW5nIFBhY2tl dCBOZXR3b3JrIE9wdGltaXphdGlvbiB1c2luZyBEV0RNIEludGVyZmFjZXM8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0 OyAmZ3Q7IFN1Ym1pc3Npb24gRGF0ZTogMjAxNS0xMC0xNiBVUkwgb2YgdGhlIElFVEYgV2ViIHBh Z2U6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g bGFuZz0iRU4tVVMiPiZndDsgJmd0OyA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2xpYWlzb24vMTQzMi8iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1k ZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbGlhaXNvbi8xNDMy Lzwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgJmd0OyBQbGVhc2UgcmVwbHkgYnkgMjAxNS0xMS0w ODxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh bmc9IkVOLVVTIj4mZ3Q7ICZndDsgRnJvbTombmJzcDsgKERhdmlkIFNpbmljcm9wZSAmbHQ7PGEg aHJlZj0ibWFpbHRvOmRhdmlkLnNpbmljcm9wZUBlcmljc3Nvbi5jb20iPjxzcGFuIHN0eWxlPSJj b2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5kYXZpZC5zaW5pY3JvcGVAZXJp Y3Nzb24uY29tPC9zcGFuPjwvYT4mZ3Q7KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7ICZndDsgVG86Jm5ic3A7ICg8 YSBocmVmPSJtYWlsdG86dmJlZXJhbUBqdW5pcGVyLm5ldCI+PHNwYW4gc3R5bGU9ImNvbG9yOndp bmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPnZiZWVyYW1AanVuaXBlci5uZXQ8L3NwYW4+ PC9hPiwNCjxhIGhyZWY9Im1haWx0bzpsYmVyZ2VyQGxhYm4ubmV0Ij48c3BhbiBzdHlsZT0iY29s b3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+bGJlcmdlckBsYWJuLm5ldDwvc3Bh bj48L2E+LA0KPGEgaHJlZj0ibWFpbHRvOmFrYXRsYXNAZ21haWwuY29tIj48c3BhbiBzdHlsZT0i Y29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+YWthdGxhc0BnbWFpbC5jb208 L3NwYW4+PC9hPiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzphcmV0YW5hQGNp c2NvLmNvbSI+DQo8c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246 bm9uZSI+YXJldGFuYUBjaXNjby5jb208L3NwYW4+PC9hPiwNCjxhIGhyZWY9Im1haWx0bzpkYjM1 NDZAYXR0LmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9u Om5vbmUiPmRiMzU0NkBhdHQuY29tPC9zcGFuPjwvYT4sDQo8YSBocmVmPSJtYWlsdG86ZGFuaWVs ZS5jZWNjYXJlbGxpQGVyaWNzc29uLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7 dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmRhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb208L3Nw YW4+PC9hPiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzp6aGFuZ2ZhdGFpQGh1 YXdlaS5jb20iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9u Om5vbmUiPnpoYW5nZmF0YWlAaHVhd2VpLmNvbTwvc3Bhbj48L2E+KTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7ICZn dDsgQ2M6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gbGFuZz0iRU4tVVMiPiZndDsgJmd0OyBSZXNwb25zZSBDb250YWN0czogPGEgaHJlZj0ibWFp bHRvOm1pY2hhZWwuZmFyZ2Fub0BjZW50dXJ5bGluay5jb20iPg0KPHNwYW4gc3R5bGU9ImNvbG9y OndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPm1pY2hhZWwuZmFyZ2Fub0BjZW50dXJ5 bGluay5jb208L3NwYW4+PC9hPiBUZWNobmljYWwgQ29udGFjdHM6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgJmd0 OyBQdXJwb3NlOiBGb3IgY29tbWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7ICZndDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAm Z3Q7IEJvZHk6IERlYXIgSUVURiBSb3V0aW5nIEFyZWEgYW5kIFdvcmtpbmcgR3JvdXAgTGVhZGVy czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1VUyI+Jmd0OyAmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgJmd0OyBBcyBwcmV2aW91c2x5IGNv bW11bmljYXRlZCwgd2UgaGF2ZSBiZWVuIHdvcmtpbmcgb24gYSBwcm9qZWN0IGVudGl0bGVkPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RU4tVVMiPiZndDsgJmd0OyDigJxBY2hpZXZpbmcgUGFja2V0IE5ldHdvcmsgT3B0aW1pemF0aW9u IHVzaW5nIERXRE0gSW50ZXJmYWNlc+KAnSBhbmQgYXJlPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgJmd0OyByZWZl cmVuY2luZyB3b3JrIGJlaW5nIGRvbmUgYnkgSUVURiBDQ0FNUCBhbmQgVEVBUyBpbiB0aGlzIGFy ZWEuIFdlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gbGFuZz0iRU4tVVMiPiZndDsgJmd0OyBhcmUgcGxlYXNlZCB0byByZXBvcnQgdGhhdCB3ZSBo YXZlIG1hZGUgc2lnbmlmaWNhbnQgcHJvZ3Jlc3MgdG93YXJkczxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7ICZndDsg Y29tcGxldGlvbiBvZiBvdXIgc3BlY2lmaWNhdGlvbnMuIFNwZWNpZmljYWxseSw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+ Jmd0OyAmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgJmd0OyBvIFRSLTMxOSBCYXNlLCDigJxBY2hpZXZpbmcg UGFja2V0IE5ldHdvcmsgT3B0aW1pemF0aW9uIHVzaW5nIERXRE08bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAmZ3Q7 IEludGVyZmFjZXPigJ0sIHdhcyBwdWJsaXNoZWQgSnVuZSAyMDE1IG8gVFItMzE5IFBhcnQgQSwg 4oCcQWNoaWV2aW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgJmd0OyBQYWNrZXQgTmV0d29yayBPcHRpbWl6YXRp b24gdXNpbmcgRFdETSBJbnRlcmZhY2VzIOKAkyBQaHlzaWNhbGx5PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgJmd0 OyBJbnRlZ3JhdGVkIE1vZGVs4oCdLCB3YXMgcHVibGlzaGVkIEp1bmUgMjAxNTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4m Z3Q7ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAmZ3Q7IFdULTMxOSBQYXJ0IEIsIEFjaGlldmluZyBQYWNr ZXQgTmV0d29yayBPcHRpbWl6YXRpb24gdXNpbmcgRFdETTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7ICZndDsgSW50 ZXJmYWNlcyDigJMgUGh5c2ljYWxseSBTZXBhcmF0ZWQsIExvZ2ljYWxseSBTZXBhcmF0ZWQsIGlz IHVuZGVyZ29pbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAmZ3Q7IFN0cmF3IEJhbGxvdCAoc2ltaWxhciB0byBJ RVRGIFdHIExhc3QgQ2FsbCksIGFuZCB3ZSBhcmUgYXR0YWNoaW5nIGl0IGZvciB5b3VyPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4t VVMiPiZndDsgcmV2aWV3IGFuZCBjb21tZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7ICZndDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+ Jmd0OyAmZ3Q7IE91ciBiYWxsb3QgcGVyaW9kIGNsb3NlcyBvbiBOb3ZlbWJlciA4LCAyMDE1LiBJ ZiBpdCBpcyBhdCBhbGw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAmZ3Q7IHBvc3NpYmxlLCB3ZSB3b3VsZCBhcHBy ZWNpYXRlIGFuZCBsb29rIGZvcndhcmQgdG8gYW55IGlucHV0IGluIHRpbWU8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0 OyAmZ3Q7IGZvciBvdXIgYmFsbG90IGNsb3NlLiBUaGUgbmV4dCBtZWV0aW5nIG9mIEJCRiBvY2N1 cnMgTm92ZW1iZXIgMTYsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgJmd0OyAyMDE1LiBBIHNjaGVkdWxlIG9mIG91 ciBmdXR1cmUgbWVldGluZ3MgYXBwZWFycyBiZWxvdy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAmZ3Q7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4t VVMiPiZndDsgJmd0OyBXZSB3YW50IHRvIGV4cHJlc3Mgb3VyIGFwcHJlY2lhdGlvbiBmb3IgeW91 ciBjb250aW51ZWQgY29uc2lkZXJhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7ICZndDsgb2YgdGhpcyBpbXBv cnRhbnQgdG9waWMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7ICZndDsgU2luY2Vy ZWx5LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IGxhbmc9IkVOLVVTIj4mZ3Q7ICZndDsgTWljaGFlbCBGYXJnYW5vLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7ICZn dDsgQnJvYWRiYW5kIEZvcnVtIFRlY2huaWNhbCBDb21taXR0ZWUgQ2hhaXI8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0 OyAmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gbGFuZz0iRU4tVVMiPiZndDsgJmd0OyBEYXRlIG9mIFVwY29taW5nIEJyb2FkYmFuZCBGb3J1 bSBNZWV0aW5ncyBEQVRFUyBMT0NBVElPTjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IE5vdmVtYmVyIDE2IOKAkzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj4mZ3Q7ICZndDsgMjAsIDIwMTUgUHVlcnRvIFZhbGxhcnRhLCBNZXhpY28gRmVicnVh cnkgMSDigJMgNSwgMjAxNiBBc2lhIFBhYzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7ICZndDsgKHByZWNpc2UgbG9j YXRpb24gVEJEKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAmZ3Q7IE5vdGU6IEEg bGlzdCBvZiB1cGNvbWluZyBtZWV0aW5ncyBjYW4gYWxzbyBiZSBmb3VuZCBhdDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4m Z3Q7ICZndDsgPGEgaHJlZj0iaHR0cDovL3d3dy5icm9hZGJhbmRmb3J1bSI+DQo8c3BhbiBzdHls ZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cDovL3d3dy5icm9h ZGJhbmRmb3J1bTwvc3Bhbj48L2E+LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7ICZndDsgb3JnL21lZXRpbmdzL3Vw Y29taW5nbWVldGluZ3NhdGFnbGFuY2UucGhwPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgJmd0OzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4m Z3Q7ICZndDsgQXR0YWNobWVudHM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgJmd0OyDCpyBXVC0zMTkgUGFydCBC IFN0cmF3IEJhbGxvdCBUZXh0IChiYmYyMDE1LjA3MS4wNyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAmZ3Q7IEF0 dGFjaG1lbnRzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IEF0dGFjaG1lbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2xpYi9kdC9kb2N1bWVu dHMvTElBSVNPTi9saWFpc29uLTIwMTUtMTAtMTYtIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5k b3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL3d3dy5pZXRmLm9yZy9saWIvZHQv ZG9jdW1lbnRzL0xJQUlTT04vbGlhaXNvbi0yMDE1LTEwLTE2LTwvc3Bhbj48L2E+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi PiZndDsgJmd0OyBicm9hZGJhbmQtZm9ydW0tcnRnLWNjYW1wLXRlYXMtYWNoaWV2aW5nLXBhY2tl dC1uZXR3b3JrLW9wdGltaXphdGlvbi08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAmZ3Q7IHVzaW5nLWR3ZG0taW50 ZXJmYWNlcy1hdHRhY2htZW50LTEucGRmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgJmd0OzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7 ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU3RhdGVtZW50PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9s aWIvZHQvZG9jdW1lbnRzL0xJQUlTT04vbGlhaXNvbi0yMDE1LTEwLTE2LSI+DQo8c3BhbiBzdHls ZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbGliL2R0L2RvY3VtZW50cy9MSUFJU09OL2xpYWlzb24tMjAxNS0xMC0xNi08L3NwYW4+ PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IGxhbmc9IkVOLVVTIj4mZ3Q7ICZndDsgYnJvYWRiYW5kLWZvcnVtLXJ0Zy1jY2FtcC10ZWFzLWFj aGlldmluZy1wYWNrZXQtbmV0d29yay1vcHRpbWl6YXRpb24tPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgJmd0OyB1 c2luZy1kd2RtLWludGVyZmFjZXMtYXR0YWNobWVudC0yLnBkZjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO LVVTIj4mZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZndDsgQ0NBTVAgbWFpbGluZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPGEgaHJlZj0i bWFpbHRvOkNDQU1QQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0 LWRlY29yYXRpb246bm9uZSI+Q0NBTVBAaWV0Zi5vcmc8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7 IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXAiPg0K PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXA8L3NwYW4+PC9hPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVT Ij4mZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RU4tVVMiPiZndDsgQ0NBTVAgbWFpbGluZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPGEgaHJlZj0ibWFp bHRvOkNDQU1QQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRl Y29yYXRpb246bm9uZSI+Q0NBTVBAaWV0Zi5vcmc8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IDxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXAiPg0KPHNw YW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXA8L3NwYW4+PC9hPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E0C26CAA2504C84093A49B2CAC3261A438CE2607SZXEMA504MBXchi_-- From nobody Sat Oct 31 23:39:27 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3B01B6A11; Sat, 31 Oct 2015 23:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 VewWv0bQkTia; Sat, 31 Oct 2015 23:39:23 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D46EC1B6A0F; Sat, 31 Oct 2015 23:39:22 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CDI94352; Sun, 01 Nov 2015 06:39:20 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sun, 1 Nov 2015 06:39:19 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.20]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0235.001; Sun, 1 Nov 2015 14:39:11 +0800 From: Lizhenbin To: "spring@ietf.org" , "pce@ietf.org" Thread-Topic: Solicit Comments on draft-li-spring-tunnel-segment-00 and draft-li-pce-tunnel-segment-00 Thread-Index: AdEUbsVrrzrcOCTPSMquLzMmIS+Jkw== Date: Sun, 1 Nov 2015 06:39:10 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D8CA5EE97@nkgeml506-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.194.186.148] Content-Type: multipart/alternative; boundary="_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D8CA5EE97nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "Chenxia \(D\)" , "Wunan \(Eric\)" Subject: [Pce] Solicit Comments on draft-li-spring-tunnel-segment-00 and draft-li-pce-tunnel-segment-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2015 06:39:25 -0000 --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D8CA5EE97nkgeml506mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgRm9sa3MsDQoNCldlIHByb3Bvc2VzIHR3byBkcmFmdHMgb24gdGhlIG5ldyB0eXBlIG9mIHNl Z21lbnQgaW4gdGhlIHNlZ21lbnQgcm91dGluZzogZHJhZnQtbGktc3ByaW5nLXR1bm5lbC1zZWdt ZW50LTAwIGFuZCBkcmFmdC1saS1wY2UtdHVubmVsLXNlZ21lbnQtMDAuDQoNCi0tIGRyYWZ0LWxp LXNwcmluZy10dW5uZWwtc2VnbWVudC0wMCBwcm9wb3NlcyB0aGUgcG9zc2libGUgdXNlY2FzZXMg c3VjaCBhcyByZWR1Y2UgU0lEIHN0YWNrIGRlcHRoIG9mIFNSIHBhdGgsIHNwYW4gdGhlIG5vbi1T UiBkb21haW4gb3IgcHJvdmlkZSBkaWZmZXJlbnRpYXRlZCBzZXJ2aWNlcy4gVGhpcyBkb2N1bWVu dCBhbHNvIHByb3Bvc2VzIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlIGFkamFjZW5jeSBzZWdt ZW50IGFuZCB0aGUgdHVubmVsIHNlZ21lbnQuIFRoZXNlIHdvcmsgd2lsbCBoZWxwIHRvIHVuZGVy c3RhbmQgdGhlIG5lY2Vzc2l0eSBhbmQgYWR2YW50YWdlcyBvZiB0dW5uZWwgc2VnbWVudCBpbiBz b21lIGFwcGxpY2F0aW9uIHNjZW5hcmlvcy4gVGhlbiB3ZSBkZWZpbmUgdGhlIGZvcndhcmRpbmcg bWVjaGFuaXNtIGFuZCBwcm90b2NvbCBleHRlbnNpb25zIHJlcXVpcmVtZW50cyBvbiB0dW5uZWwg c2VnbWVudC4NCg0KLS0gZHJhZnQtbGktcGNlLXR1bm5lbC1zZWdtZW50LTAwIHByb3Bvc2VzIHRo ZSBwb3NzYmlsZSBQQ0VQIHByb3RvY29sIGV4dGVuc2lvbnMgZm9yIHRoZSB0dW5uZWwgc2VnbWVu dCBiYXNlZCBvbiBkcmFmdC1saS1zcHJpbmctdHVubmVsLXNlZ21lbnQtMDAuIFRoZSBwcm90b2Nv bCBleHRlbnNpb25zIGFyZSBpbnRyb2R1Y2VkIGZvciB0d28gZGlmZmVyZW50IGFwcGxpY2F0aW9u czogMS4gUENFUCBleHRlbnNpb3NuIGZyb20gUENDIHRvIFBDRTsgMi4gUENFUCBleHRlbnNpb25z IGZyb20gUENFIHRvIFBDQy4NCg0KDQoNCkhvcGUgeW91IGNvdWxkIGhhdmUgaW50ZXJlc3QgaW4g dGhlc2UgZHJhZnRzLCBoZWxwIHJldmlldyBvciByZWZpbmUuIFlvdSBjb21tZW50cyB3aWxsIGJl IGFwcHJlY2lhdGVkLg0KDQoNCg0KDQoNCg0KDQpUaGFua3MgJiBSZWdhcmRzLA0KDQpaaGVuYmlu IChSb2JpbikNCg== --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D8CA5EE97nkgeml506mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Folks,

We proposes two drafts on the new type of segment in the segment ro= uting: draft-li-spring-tunnel-segment-00 and draft-li-pce-tunnel-segment-00= .

-- draft-li-spring-tunnel-segment-00 proposes the possible usecases such= as reduce SID stack depth of SR path, span the non-SR domain or provide di= fferentiated services. This document also proposes the difference between t= he adjacency segment and the tunnel segment. These work will help to understand the necessity and advantages o= f tunnel segment in some application scenarios. Then we define the forwardi= ng mechanism and protocol extensions requirements on tunnel segment.

-- draft-li-pce-tunnel-segment-00 proposes the possbile PCEP protocol ex= tensions for the tunnel segment based on draft-li-spring-tunnel-segment-00.= The protocol extensions are introduced for two different applications: 1. = PCEP extensiosn from PCC to PCE; 2. PCEP extensions from PCE to PCC.

 

Hope you could have interest in these drafts, help review or refine= . You comments will be appreciated.

 

 

 

Thanks & Regards,

Zhenbin (Robin)

--_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D8CA5EE97nkgeml506mbxchi_--