From nobody Mon Jun 1 11:59:59 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 84E8D1B3161; Mon, 1 Jun 2015 11:59:57 -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 U4vkdTqnfjQY; Mon, 1 Jun 2015 11:59:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9411B315D; Mon, 1 Jun 2015 11:59:55 -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.0.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150601185955.1603.57980.idtracker@ietfa.amsl.com> Date: Mon, 01 Jun 2015 11:59:55 -0700 Archived-At: Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-wson-rwa-ext-02.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, 01 Jun 2015 18:59:57 -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 Extension for WSON Routing and Wavelength Assignment Authors : Young Lee Ramon Casellas Filename : draft-ietf-pce-wson-rwa-ext-02.txt Pages : 26 Date : 2015-06-01 Abstract: This document provides the Path Computation Element communication Protocol (PCEP) extensions for the support of Routing and Wavelength Assignment (RWA) in Wavelength Switched Optical Networks (WSON). Lightpath provisioning in WSONs requires a routing and wavelength assignment (RWA) process. From a path computation perspective, wavelength assignment is the process of determining which wavelength can be used on each hop of a path and forms an additional routing constraint to optical light path computation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-wson-rwa-ext/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-pce-wson-rwa-ext-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-wson-rwa-ext-02 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 Jun 1 12:24:08 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 98C2A1B310A for ; Mon, 1 Jun 2015 12:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.21 X-Spam-Level: X-Spam-Status: No, score=-3.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, 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 5ds2VgpDEsNl for ; Mon, 1 Jun 2015 12:24:05 -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 8255B1B31E8 for ; Mon, 1 Jun 2015 12:24:00 -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 BWU87519; Mon, 01 Jun 2015 19:23:58 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 1 Jun 2015 20:23:58 +0100 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0158.001; Mon, 1 Jun 2015 12:23:48 -0700 From: Leeyoung To: "pce@ietf.org" Thread-Topic: [Pce] I-D Action: draft-ietf-pce-wson-rwa-ext-02.txt Thread-Index: AQHQnJ0zh1CPxGtIME66ubno1PZZBZ2YAW1g Date: Mon, 1 Jun 2015 19:23:47 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729CCF5A9@dfweml706-chm> References: <20150601185955.1603.57980.idtracker@ietfa.amsl.com> In-Reply-To: <20150601185955.1603.57980.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.128] 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-wson-rwa-ext-02.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, 01 Jun 2015 19:24:07 -0000 Hi, The major updates made with this revision are summarized as follows:=20 - Included the encoding mechanism using LSP attribute TLVs/ERO (as defined = in draft-margaria-ccamp-lsp-attribute-ero) for encoding of wavelength assig= nments in a PCRep message. (This was a pending issue, waiting for the menti= oned draft to mature, which is now in RFC Editor's Queue).=20 - Client Signal Information encoding to refer to draft-ietf-ccamp-rwa-wson-= encode (from draft-ietf-inter-layer-ext) to eliminate the dependency on the= work that is outdated.=20 - Add IANA section with details.=20 If you have any comments/concerns, please express them to the list.=20 Thanks. Young (on behalf of other co-authors) -----Original Message----- From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.o= rg Sent: Monday, June 01, 2015 2:00 PM To: i-d-announce@ietf.org Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-wson-rwa-ext-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Path Computation Element Working Group of= the IETF. Title : PCEP Extension for WSON Routing and Wavelength As= signment Authors : Young Lee Ramon Casellas Filename : draft-ietf-pce-wson-rwa-ext-02.txt Pages : 26 Date : 2015-06-01 Abstract: This document provides the Path Computation Element communication Protocol (PCEP) extensions for the support of Routing and Wavelength Assignment (RWA) in Wavelength Switched Optical Networks (WSON). Lightpath provisioning in WSONs requires a routing and wavelength assignment (RWA) process. From a path computation perspective, wavelength assignment is the process of determining which wavelength can be used on each hop of a path and forms an additional routing constraint to optical light path computation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-wson-rwa-ext/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-pce-wson-rwa-ext-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pce-wson-rwa-ext-02 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 From nobody Tue Jun 2 00:31: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 E2D2B1ACDCD for ; Tue, 2 Jun 2015 00:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 IJKVskG2DhKl for ; Tue, 2 Jun 2015 00:29:08 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 033561ACEFD for ; Tue, 2 Jun 2015 00:29:07 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id A88B735251878 for ; Tue, 2 Jun 2015 07:29:03 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id t527T3xk008574 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 2 Jun 2015 07:29:04 GMT Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.164]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Tue, 2 Jun 2015 03:29:04 -0400 From: "Shah, Jaishal (Jaishal)" To: "pce@ietf.org" Thread-Topic: Clarification regarding path in PCReport and PCUpdate Thread-Index: AdCdBcGH73y+60JkTM6J6XH94/zvGg== Date: Tue, 2 Jun 2015 07:29:02 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_EB3B6B95EF049545B844F55DE2F1B6E2CF535B2AUS70UWXCHMBA04z_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Tue, 02 Jun 2015 00:31:06 -0700 Subject: [Pce] Clarification regarding path in PCReport and PCUpdate 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, 02 Jun 2015 07:29:10 -0000 --_000_EB3B6B95EF049545B844F55DE2F1B6E2CF535B2AUS70UWXCHMBA04z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, As per draft-ietf-stateful-pce-11 A PCC sending PCRpt to PCE should have following format ::=3D [] Where: ::=3D [] is as per RFC 5440. ::=3D[] [] [] [] Now, as per RFC 5440, is part of PCReply and for a PCReply= with ERO can have just BW, Metric-list. LSPA and IRO are to be included in PCReply as per 5440 in case of unsuccess= ful So, does the understanding that PCReport attribute list can have only these= objects hold true ? Also I believe these objects would follow the rules for PCReply. Eg P-bit, Bound-bit, Compute-bit etc ho= ld no significance in these objects in PCReport Same will be the case for PCUpdate I believe. It would be great some clarification is shared on this. --_000_EB3B6B95EF049545B844F55DE2F1B6E2CF535B2AUS70UWXCHMBA04z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

As per draft-ietf-stateful-pce-11

A PCC sending PCRpt to PCE should have following format

   <state-report> ::=3D [<SRP>]=

         &nbs= p;            <LS= P>

         &nbs= p;            <pa= th>

Where:

   <path>::=3D <ERO><attribute-li= st>[<RRO>]

 

<attribute-list> is as per RFC 5440. <attribute-list>::=3D[<LSPA>] [<BANDWIDTH>] [<metric-= list>] [<IRO>]

 

Now, as per RFC 5440, <attribute-list> is part of PC= Reply and for a PCReply with ERO can have just BW, Metric-list.<= /span>

LSPA and IRO are to be included in PCReply as per 5440 in = case of unsuccessful

 

So, does the understanding that PCReport attribute list ca= n have only these objects hold true ? Also I believe these objects

would follow the rules for PCReply. Eg P-bit, Bound-bit, C= ompute-bit etc hold no significance in these objects in PCReport=

Same will be the case for PCUpdate I believe.

 

= It would be great some clarification is shared on this.

--_000_EB3B6B95EF049545B844F55DE2F1B6E2CF535B2AUS70UWXCHMBA04z_-- From nobody Tue Jun 2 00:42:08 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 C67B61A872E for ; Tue, 2 Jun 2015 00:42:06 -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 IaXdkltOiIdV for ; Tue, 2 Jun 2015 00:42:04 -0700 (PDT) Received: from navarro.puc.rediris.es (navarro.puc.rediris.es [IPv6:2001:720:418:ca01::131]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B580B1AD068 for ; Tue, 2 Jun 2015 00:42:03 -0700 (PDT) Received: from [84.88.62.208] (helo=leo) by navarro.puc.rediris.es with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1Yzgpi-0000vO-DU for pce@ietf.org; Tue, 02 Jun 2015 09:42:01 +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 7F5EF1FD05 for ; Tue, 2 Jun 2015 09:41:53 +0200 (CEST) X-Envelope-From: ramon.casellas@cttc.es Message-ID: <556D5E3A.4090509@cttc.es> Date: Tue, 02 Jun 2015 09:41:46 +0200 From: Ramon Casellas User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: pce@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------080907030701090704080300" 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.0000] 0.0 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [Pce] Clarification regarding path in PCReport and PCUpdate 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, 02 Jun 2015 07:42:07 -0000 This is a multi-part message in MIME format. --------------080907030701090704080300 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Jaishal For what is worth, there was some discussion about this in the past, and some thoughts are reflected in https://tools.ietf.org/html/draft-many-pce-pcep-bcp-01#section-4.1.5 In short, IMHO, "attribute-list" goes beyond RFC5440, should take into account other RFC extensions and it would be great if attributes could be unified across requests and replies (both in stateless and stateful aspects) either being used as constraints or as path attributes In particular, in that draft the idea is to unify "attributes" and add RRO as another attribute. the RBNF would be: ::= [] in PCReq ::= | | ::= ::= [] [] in PCRep ::= [] [] ( | ) [] -- Note: should clarify P2MP attributes. P2MP response -- also includes endpoint-path-pair-list. TBD ::= ::= [] PCRpt ::= ::= PCUpd ::= You may want to check the draft for details, Just 2 cents, hope it helps a bit. Still, it is not 100% clear how all extensions can be integrated and unified in a comprehensive and in a non-ambiguous way. Ramon El 02/06/2015 a las 9:29, Shah, Jaishal (Jaishal) escribió: > > Hi All, > > As per draft-ietf-stateful-pce-11 > > A PCC sending PCRpt to PCE should have following format > > ::= [] > > > > > > Where: > > ::= [] > > is as per RFC 5440. ::=[] > [] [] [] > > Now, as per RFC 5440, is part of PCReply and for a > PCReply with ERO can have just BW, Metric-list. > > LSPA and IRO are to be included in PCReply as per 5440 in case of > unsuccessful > > So, does the understanding that PCReport attribute list can have only > these objects hold true ? Also I believe these objects > > would follow the rules for PCReply. Eg P-bit, Bound-bit, Compute-bit > etc hold no significance in these objects in PCReport > > Same will be the case for PCUpdate I believe. > > It would be great some clarification is shared on this. > > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce --------------080907030701090704080300 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi Jaishal

For what is worth, there was some discussion about this in the past, and some thoughts are reflected in

https://tools.ietf.org/html/draft-many-pce-pcep-bcp-01#section-4.1.5

In short, IMHO, "attribute-list" goes beyond RFC5440, should take into account other RFC extensions and it would be great if attributes could be unified across requests and replies (both in stateless and stateful aspects) either being used as constraints or as path attributes

In particular, in that draft the idea is to unify "attributes" and add RRO as another attribute.

the RBNF would be: 
  <path>      ::= <ERO> [<attributes>]


in PCReq
   <request>          ::= <expansion> |
                          <p2p_computation> |
                          <p2mp_computation>

   <expansion>        ::= <RP><PATH-KEY>

   <p2p_computation>  ::= <RP><ENDPOINTS>
                         [<LSP>]
                         [<attributes>]

in PCRep

   <response>  ::= <RP> [<monitoring>] [<LSP>]
                  (<success> | <failure>) [<monitoring-metrics>]


   -- Note: should clarify P2MP attributes. P2MP response
   -- also includes endpoint-path-pair-list. TBD

   <success>   ::= <path-list>

   <failure>   ::= <NO-PATH> [<attributes>]

PCRpt
 <solicited-report>   ::= <SRP> <LSP> <path>

   <unsolicited-report> ::= <LSP> <path>

PCUpd
   <update-request> ::= <SRP>
                        <LSP>
                        <path>


You may want to check the draft for details,
Just 2 cents, hope it helps a bit. Still, it is not 100% clear how all extensions can be integrated and unified in a comprehensive and in a non-ambiguous way.
Ramon



El 02/06/2015 a las 9:29, Shah, Jaishal (Jaishal) escribió:

Hi All,

 

As per draft-ietf-stateful-pce-11

A PCC sending PCRpt to PCE should have following format

   <state-report> ::= [<SRP>]

                      <LSP>

                      <path>

Where:

   <path>::= <ERO><attribute-list>[<RRO>]

 

<attribute-list> is as per RFC 5440. <attribute-list>::=[<LSPA>] [<BANDWIDTH>] [<metric-list>] [<IRO>]

 

Now, as per RFC 5440, <attribute-list> is part of PCReply and for a PCReply with ERO can have just BW, Metric-list.

LSPA and IRO are to be included in PCReply as per 5440 in case of unsuccessful

 

So, does the understanding that PCReport attribute list can have only these objects hold true ? Also I believe these objects

would follow the rules for PCReply. Eg P-bit, Bound-bit, Compute-bit etc hold no significance in these objects in PCReport

Same will be the case for PCUpdate I believe.

 

It would be great some clarification is shared on this.



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

--------------080907030701090704080300-- From nobody Tue Jun 2 12:22:37 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 B83C71B2AEE for ; Tue, 2 Jun 2015 12:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 4GmRitLrGxok for ; Tue, 2 Jun 2015 12:22:34 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 A8DF91B2AE5 for ; Tue, 2 Jun 2015 12:22:33 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 243EB187C260E for ; Tue, 2 Jun 2015 19:22:28 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id t52JMUi4023792 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 2 Jun 2015 19:22:30 GMT Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.164]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Tue, 2 Jun 2015 15:22:30 -0400 From: "Shah, Jaishal (Jaishal)" To: "pce@ietf.org" Thread-Topic: Clarification regarding path in PCReport and PCUpdate Thread-Index: AdCdBcGH73y+60JkTM6J6XH94/zvGgAYaCow Date: Tue, 2 Jun 2015 19:22:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_EB3B6B95EF049545B844F55DE2F1B6E2CF53605BUS70UWXCHMBA04z_" MIME-Version: 1.0 Archived-At: Subject: Re: [Pce] Clarification regarding path in PCReport and PCUpdate 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, 02 Jun 2015 19:22:36 -0000 --_000_EB3B6B95EF049545B844F55DE2F1B6E2CF53605BUS70UWXCHMBA04z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Ramon for your reply. So if I understand it correctly, attributes is a broadly used term. In PCRe= q it is the set of constraints to be satisfied in order to bring up the lsp= path and in PCReport it is the attributes of the path itself. Then in case of specific active stateful PCC-PCE interaction, for lsps whic= h are synced to PCE at connection setup, PCE will only have the PCReport sent from the PCC. Later on it may delegate= the lsp and allow it to be updated by PCE. How is PCE suppose to know the original set of constraints needed for the l= sp while updating the lsp? PCReport only has the current state of the lsp path (bw, metric etc), whereas setup of the lsp path could have different constraints used to brin= g up that path. I don't believe draft-ietf-stateful-pce clarifies that. Hope I can get som= e clarification on this. Regards, Jaishal From: Shah, Jaishal (Jaishal) Sent: Tuesday, June 02, 2015 12:29 AM To: 'pce@ietf.org' Subject: Clarification regarding path in PCReport and PCUp= date Hi All, As per draft-ietf-stateful-pce-11 A PCC sending PCRpt to PCE should have following format ::=3D [] Where: ::=3D [] is as per RFC 5440. ::=3D[] [] [] [] Now, as per RFC 5440, is part of PCReply and for a PCReply= with ERO can have just BW, Metric-list. LSPA and IRO are to be included in PCReply as per 5440 in case of unsuccess= ful So, does the understanding that PCReport attribute list can have only these= objects hold true ? Also I believe these objects would follow the rules for PCReply. Eg P-bit, Bound-bit, Compute-bit etc ho= ld no significance in these objects in PCReport Same will be the case for PCUpdate I believe. It would be great some clarification is shared on this. --_000_EB3B6B95EF049545B844F55DE2F1B6E2CF53605BUS70UWXCHMBA04z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Ramon for your reply.

 

So if I understand it correctly, attributes is a broadly u= sed term. In PCReq it is the set of constraints to be satisfied in order to= bring up the lsp path

and in PCReport it is the attributes of the path itself.

 

Then in case of specific active stateful PCC-PCE interacti= on, for lsps which are synced to PCE at connection setup,=

PCE will only have the PCReport sent from the PCC. Later o= n it may delegate the lsp and allow it to be updated by PCE.

How is PCE suppose to know the original set of constraints= needed for the lsp while updating the lsp?

PCReport only has the current state of the lsp path (bw, m= etric etc),

whereas setup of the lsp path could have different constra= ints used to bring up that path.

 

I don’t believe  draft-ietf-stateful-pce clarif= ies that. Hope I can get some clarification on this.

 

Regards,

Jaishal

 

From: Shah, Ja= ishal (Jaishal)
Sent: Tuesday, June 02, 2015 12:29 AM
To: 'pce@ietf.org'
Subject: Clarification regarding path <attribute-list> in PCRe= port and PCUpdate

 

Hi All,

 

As per draft-ietf-stateful-pce-11

A PCC sending PCRpt to PCE should have following format

   <state-report> ::=3D [<SRP>]=

         &nbs= p;            <LS= P>

         &nbs= p;            <pa= th>

Where:

   <path>::=3D <ERO><attribute-li= st>[<RRO>]

 

<attribute-list> is as per RFC 5440. <attribute-l= ist>::=3D[<LSPA>] [<BANDWIDTH>] [<metric-list>] [<I= RO>]

 

Now, as per RFC 5440, <attribute-list> is part of PC= Reply and for a PCReply with ERO can have just BW, Metric-list.<= /span>

LSPA and IRO are to be included in PCReply as per 5440 in = case of unsuccessful

 

So, does the understanding that PCReport attribute list ca= n have only these objects hold true ? Also I believe these objects

would follow the rules for PCReply. Eg P-bit, Bound-bit, C= ompute-bit etc hold no significance in these objects in PCReport=

Same will be the case for PCUpdate I believe.

 

= It would be great some clarification is shared on this.

--_000_EB3B6B95EF049545B844F55DE2F1B6E2CF53605BUS70UWXCHMBA04z_-- From nobody Wed Jun 10 00:34: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 23FD41AC43A for ; Wed, 10 Jun 2015 00:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 O6lzUhkgOQLh for ; Wed, 10 Jun 2015 00:33: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 B24FE1AC434 for ; Wed, 10 Jun 2015 00:33:53 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BXF00018; Wed, 10 Jun 2015 07:33:52 +0000 (GMT) Received: from SZXEML428-HUB.china.huawei.com (10.82.67.183) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 10 Jun 2015 08:32:51 +0100 Received: from szxeml561-mbx.china.huawei.com ([169.254.5.64]) by szxeml428-hub.china.huawei.com ([10.82.67.183]) with mapi id 14.03.0158.001; Wed, 10 Jun 2015 15:32:07 +0800 From: Venugopal Reddy K To: pce , "inaminei@google.com" Thread-Topic: Few comments/queries on draft-ietf-pce-pce-initiated-lsp-04 Thread-Index: AdCjT4xvj1BlUKqBR8qnFF/EsjI9dg== Date: Wed, 10 Jun 2015 07:32:06 +0000 Message-ID: <10376B02BC561F4185654159EF7900204593E90C@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.146.97] Content-Type: multipart/alternative; boundary="_000_10376B02BC561F4185654159EF7900204593E90Cszxeml561mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Pce] Few comments/queries on draft-ietf-pce-pce-initiated-lsp-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: Wed, 10 Jun 2015 07:33:59 -0000 --_000_10376B02BC561F4185654159EF7900204593E90Cszxeml561mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Everyone! Have few comments/queries on draft-ietf-pce-pce-initiated-lsp-04. Could you= please clarify on below points: Section 6 In case of PCEP session failure, control over PCE-initiated LSPs reverts to the PCC at the expiration of the redelegation timeout. At this point, the LSP is an "orphan" until the expiration of the State Timeout timer. To obtain control of a PCE-initiated LSP, a PCE (either the original or one of its backups) sends a PCInitiate message, including just the SRP and LSP objects, and carrying the PLSP-ID of the LSP it wants to take control of 1. In case of Backup PCE, what is the trigger point to send PCInitiat= e message to take control of orphan PCE-initiated LSP? I am wondering how d= oes a backup PCE come to know that some LSPs are orphaned? 2. Another option would be, if PCC takes charge and delegate the orph= aned PCE initiated LSPs to backup PCE based on the local policy? Response will be appreciated. Thanks a lot. Regards, Venu --_000_10376B02BC561F4185654159EF7900204593E90Cszxeml561mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Everyone!

 

Have few comments/quer= ies on draft-ietf-pce-pce-initiated-lsp-04. Could you please clarify on bel= ow points:

 

=
  Section 6
=
  In case of PCEP se=
ssion failure, control over PCE-initiated LSPs

   reverts to the PCC at the expiration of the redelegation= timeout.  At

   this point, the LSP is an "orphan" until the e= xpiration of the State

   Timeout timer.  To obtain control of a PCE-initiate= d LSP, a PCE

   (either the original or one of its backups) = sends a PCInitiate

   message, including just the SRP and LSP objects, and car= rying the

   PLSP-ID of the LSP it wants to take control of

1.&= nbsp;      In case of Bac= kup PCE, what is the trigger point to send PCInitiate message to take contr= ol of orphan PCE-initiated LSP? I am wondering how does a backup PCE come t= o know that some LSPs are orphaned?

 

2.&= nbsp;      Another option= would be, if PCC takes charge and delegate the orphaned PCE initiated LSPs= to backup PCE based on the local policy?

 

Response will be appre= ciated.

 

Thanks a lot.

 

Regards,

Venu=

 

--_000_10376B02BC561F4185654159EF7900204593E90Cszxeml561mbxchi_-- From nobody Wed Jun 10 08:04: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 05B5A1A8777 for ; Wed, 10 Jun 2015 08:04:33 -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 HujjSVVY_9wd for ; Wed, 10 Jun 2015 08:04:30 -0700 (PDT) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::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 A44FC1B2B80 for ; Wed, 10 Jun 2015 08:03:58 -0700 (PDT) Received: by qcej9 with SMTP id j9so18314088qce.1 for ; Wed, 10 Jun 2015 08:03:58 -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=I6hPeNeW+3WN0O1bqEdTZkL3EHHKc08SXsXpD5WOQvU=; b=zL9eHy4eOOuSB5dKD43pFGVOoLNN/vawzFz2N1ZKV5XN86KeiSCOa0xY6Q6xaLUBuN CIjz55fJcfcswHmC/UONh0ZQfksfdWVighgLYKWOkxXTK0H23Ls0i4lcFld/UOb37DGX FaQYRxoV4BtuNB4yAMqr4yq9z7bOO94toPSGgWZuFYEhnJCXpxMicZ6l5kUUxHCqUAIw 1i3B5DNnv3H+yusx4U9Q+xfzxLWLlsO9rDqx0hMIQEOu9XiquNsL9bOWYVq/uJfUNqJV P8uIChUAd80/7/kI3ItF9sT/yxWBdCnm4U+SKHcHBrYWeUmUXjTLuT/YgP6JgN7dTqKj 1YGQ== MIME-Version: 1.0 X-Received: by 10.55.17.133 with SMTP id 5mr3267076qkr.18.1433948637949; Wed, 10 Jun 2015 08:03:57 -0700 (PDT) Received: by 10.229.34.132 with HTTP; Wed, 10 Jun 2015 08:03:57 -0700 (PDT) In-Reply-To: <10376B02BC561F4185654159EF7900204593E90C@szxeml561-mbx.china.huawei.com> References: <10376B02BC561F4185654159EF7900204593E90C@szxeml561-mbx.china.huawei.com> Date: Wed, 10 Jun 2015 11:03:57 -0400 Message-ID: From: Cyril Margaria To: Venugopal Reddy K Content-Type: multipart/alternative; boundary=001a114712c630f63705182b2fa3 Archived-At: Cc: pce Subject: Re: [Pce] Few comments/queries on draft-ietf-pce-pce-initiated-lsp-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: Wed, 10 Jun 2015 15:04:33 -0000 --001a114712c630f63705182b2fa3 Content-Type: text/plain; charset=UTF-8 Hi, On 10 June 2015 at 03:32, Venugopal Reddy K wrote: > Hi, Everyone! > > > > Have few comments/queries on draft-ietf-pce-pce-initiated-lsp-04. Could > you please clarify on below points: > > > > Section 6 > > In case of PCEP session failure, control over PCE-initiated LSPs > > reverts to the PCC at the expiration of the redelegation timeout. At > > this point, the LSP is an "orphan" until the expiration of the State > > Timeout timer. To obtain control of a PCE-initiated LSP, a PCE > > (either the original or one of its backups) sends a PCInitiate > > message, including just the SRP and LSP objects, and carrying the > > PLSP-ID of the LSP it wants to take control of > > 1. In case of Backup PCE, what is the trigger point to send > PCInitiate message to take control of orphan PCE-initiated LSP? I am > wondering how does a backup PCE come to know that some LSPs are orphaned? > I see two scenarios : 1) Another PCEP Session is up , in that case it seems to imply that the PCE(s) keep track of the LSPs it can manage and the liveliness of the other PCEs. 2) There is no other PCEP session, the PCC reconnects to another PCE, in this case the PCE can try to take ownership of the Initiated, not delegated LSPs While I believe 1) is an interesting architecture, I do not think the protocol procedures should put such constraint to the PCE implementation, so the second option you propose should be allowed. > > > 2. Another option would be, if PCC takes charge and delegate the > orphaned PCE initiated LSPs to backup PCE based on the local policy? > > > I think this should be allowed, the text could be : In case of PCEP session failure, control over PCE-initiated LSPs reverts to the PCC at the expiration of the redelegation timeout. At this point, the PCC MAY delegate the LSP to another PCE. the LSP is an "orphan" until the expiration of the State Timeout timer. Some coordination between PCEs is still needed, for the original PCE to regain control over that LSP the current PCE must forfeit control over that LSP. In addition there is no Error to indicate to the PCE that he can't have the delegation back, this should be added , for instance 24,4 LSP instantiation error, Requested delegation rejected, another PCE has the delegation. (ideally allow the optional inclusion of the other PCE SPEAKER-IDENTITY-ID for troubleshooting. it should be subject to security policies) > Response will be appreciated. > > > > Thanks a lot. > > > > Regards, > > Venu > > > > Regards, Cyril > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > --001a114712c630f63705182b2fa3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

On 10 June 2015 at 03:32, Venugopal Reddy K <<= a href=3D"mailto:venugopalreddyk@huawei.com" target=3D"_blank">venugopalred= dyk@huawei.com> wrote:

Hi, Everyone!

=C2=A0

Have few commen= ts/queries on draft-ietf-pce-pce-initiated-lsp-04. Could you please clarify= on below points:

=C2=A0

=C2=A0 Section 6
=C2=A0=C2=A0In case of PCEP session failure, control over PCE-initiated=
 LSPs

=C2=A0=C2=A0 reverts to the PCC at the expiration of the redelegation= timeout.=C2=A0 At

=C2=A0=C2=A0 this point, the LSP is an "orphan" until the e= xpiration of the State

=C2=A0=C2=A0 Timeout timer.=C2=A0 To obtain control of a PCE-initiate= d LSP, a PCE

=C2=A0=C2=A0 (either the original or one of its backups) sends a PCInitiate

=C2=A0=C2=A0 message, including just the SRP and LSP objects, and car= rying the

=C2=A0=C2=A0 PLSP-ID of the LSP it wants to take control of=

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 In case of= Backup PCE, what is the trigger point to send PCInitiate message to take c= ontrol of orphan PCE-initiated LSP? I am wondering how does a backup PCE co= me to know that some LSPs are orphaned?

=
I see two scenarios :
=C2=A0 1) Anoth= er PCEP Session is up , in that case it seems to imply that the PCE(s) keep= track of the LSPs it can manage and the liveliness of the other PCEs.
= =C2=A0=C2=A0 2) There is no other PCEP session, the PCC reconnects to anoth= er PCE, in this case the PCE can try to take ownership of the Initiated, no= t delegated LSPs

=C2=A0While I believe 1) is an interesting archite= cture, I do not think the protocol procedures should put such constraint to= the PCE implementation, so the second option you propose should be allowed= .
=C2=A0
=C2=A0

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Another op= tion would be, if PCC takes charge and delegate the orphaned PCE initiated = LSPs to backup PCE based on the local policy?

=C2=A0

I think this should be allowed, the text could be :
= 
In case of PCEP session failure, control over PC=
E-initiated LSPs
reverts to the PCC at the expiration of the redelegation timeout.  At
this point, the PCC MAY delegate the LSP to another PCE. the LSP is an &quo=
t;orphan" until the expiration of the State
Timeout timer.

Some coordination between PCEs is still= needed, for the original PCE to regain control over that LSP the current P= CE must forfeit control over that LSP.

In addition there= is no Error to indicate to the PCE that he can't have the delegation b= ack, this should be added , for instance 24,4 
LSP insta=
ntiation error, Requested delegation rejected, another PCE has the delegati=
on. (ideally allow the optional inclusion of the other PCE SPEAKER-IDENTITY=
-ID for troubleshooting. it should be subject to security policies)
=
=C2=A0

Response will b= e appreciated.

=C2=A0

Thanks a lot.

=C2=A0

Regards,=

Venu<= /u>

=C2=A0


Regards,
=C2=A0Cyril
=C2=A0
____________________________= ___________________
Pce mailing list
Pce@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/pce


--001a114712c630f63705182b2fa3-- From nobody Fri Jun 12 07:04:01 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 8B0511A90C8 for ; Fri, 12 Jun 2015 07:03:50 -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 NhlZdw1VT0NP for ; Fri, 12 Jun 2015 07:03:43 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28FD21AC409 for ; Fri, 12 Jun 2015 07:03:43 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 8874518C829 for ; Fri, 12 Jun 2015 16:03:41 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.31]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 6B716238055 for ; Fri, 12 Jun 2015 16:03:41 +0200 (CEST) Received: from [10.193.71.204] (10.168.234.1) by OPEXCLILM22.corporate.adroot.infra.ftgroup (10.114.31.31) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 12 Jun 2015 16:03:41 +0200 Message-ID: <4715_1434117821_557AE6BD_4715_441_1_557AE6BC.1060803@orange.com> Date: Fri, 12 Jun 2015 16:03:40 +0200 From: Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "pce@ietf.org" References: <20150611183132.19747.75036.idtracker@ietfa.amsl.com> In-Reply-To: <20150611183132.19747.75036.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20150611183132.19747.75036.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.168.234.1] X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.6.2.75418 Archived-At: Subject: [Pce] Fwd: IESG Statement on Internet Draft Authorship 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, 12 Jun 2015 14:03:50 -0000 Hi. In case some of you missed it. Julien -------- Message transféré -------- Date : Thu, 11 Jun 2015 11:31:32 -0700 De : The IESG The IESG has received some reports of IETF participants having been listed as document authors on drafts without their consent ("surprised authorship"). In some cases, the surprised authors had never seen the draft that surprised them. It appears that some draft authors think that including other participants as authors is a way to show support for the concepts in the document and gain acceptance for those concepts. This may be thought of as especially useful if the additional authors are established IETF participants. Adding names of IETF participants who did not actually work on a proposal might seem to be a low-risk way of demonstrating "support", but this is very clearly not an acceptable practice: no one should ever be added to the list of authors on a draft unless that person has consented to it and has contributed significantly to the development of the draft. The practice of adding surprised authors is - not in line with the IETF culture, where it's the technical issues that matter, not who the authors or supporters are; - unethical, as it is wrong to claim support from someone who has not consented to it; - misleading in terms of support; and - problematic in terms of IPR disclosures (BCPs 78 and 79). To emphasize this last point, the person submitting an Internet-Draft is asserting that "This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79". A submitter who has not discussed this with all the listed authors cannot make that claim, and this can cause procedural and legal problems later. All authors need to be aware of the ​RFC Editor's statement on authorship [1], especially as it relates to responsibility for the document's contents. The IESG strongly recommends that all drafts have explicit permission from all authors to have their names listed before the draft is submitted. If you feel that you are impacted by the above issues, please talk to your Area Director or contact the IESG by ​sending email to . As the administrator of the I-D repository (regardless of the source or intended stream for the draft), the IESG will handle each case of disputed authorship on a case-by-base basis. All reports will be investigated, and substantiated claims will be met with corrective actions. The default corrective action will be the replacement of the offending draft with a "disputed authorship" tombstone. Such a tombstone would: - Be published as a successor to the offending draft, - Have the offended IETF participant listed as the only author, - Will state "The author listed on this tombstone Internet-Draft has stated that he/she should not have been listed as an author on the previous version. The IETF considers being added as an author without one's permission as unethical. The default behaviour of the IESG in such cases is to approve replacement of the offending draft with this tombstone. Please direct any queries to the author listed here." [1] http://www.rfc-editor.org/pipermail/rfc-interest/2015-May/008869.html _________________________________________________________________________________________________________________________ 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 Mon Jun 15 22:58: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 D90731B3249 for ; Mon, 15 Jun 2015 22:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.01 X-Spam-Level: X-Spam-Status: No, score=-1.01 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_46=0.6, 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 pTvm7amx7Pz5 for ; Mon, 15 Jun 2015 22:58:40 -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 755C51B3240 for ; Mon, 15 Jun 2015 22:58:39 -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 BXK59040; Tue, 16 Jun 2015 05:58:36 +0000 (GMT) Received: from SZXEML430-HUB.china.huawei.com (10.82.67.185) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 16 Jun 2015 06:58:35 +0100 Received: from szxeml561-mbx.china.huawei.com ([169.254.5.64]) by szxeml430-hub.china.huawei.com ([10.82.67.185]) with mapi id 14.03.0158.001; Tue, 16 Jun 2015 13:57:27 +0800 From: Venugopal Reddy K To: pce , "inaminei@google.com" Thread-Topic: [Pce] Few comments/queries on draft-ietf-pce-pce-initiated-lsp-04 Thread-Index: AdCjT4xvj1BlUKqBR8qnFF/EsjI9dv//+CSA//a2VlA= Date: Tue, 16 Jun 2015 05:57:26 +0000 Message-ID: <10376B02BC561F4185654159EF7900204593EB44@szxeml561-mbx.china.huawei.com> References: <10376B02BC561F4185654159EF7900204593E90C@szxeml561-mbx.china.huawei.com> In-Reply-To: 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_10376B02BC561F4185654159EF7900204593EB44szxeml561mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Cyril Margaria Subject: Re: [Pce] Few comments/queries on draft-ietf-pce-pce-initiated-lsp-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: Tue, 16 Jun 2015 05:58:43 -0000 --_000_10376B02BC561F4185654159EF7900204593EB44szxeml561mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClJlcXVlc3QgYXV0aG9ycyB0byBsZXQgdXMga25vdyB5b3VyIHZpZXcgYWJvdXQgaXQu DQoNClRoYW5rcy4NClZlbnUNCg0KRnJvbTogQ3lyaWwgTWFyZ2FyaWEgW21haWx0bzpjeXJpbC5t YXJnYXJpYUBnbWFpbC5jb21dDQpTZW50OiAyMDE15bm0NuaciDEw5pelIDIwOjM0DQpUbzogVmVu dWdvcGFsIFJlZGR5IEsNCkNjOiBwY2U7IGluYW1pbmVpQGdvb2dsZS5jb20NClN1YmplY3Q6IFJl OiBbUGNlXSBGZXcgY29tbWVudHMvcXVlcmllcyBvbiBkcmFmdC1pZXRmLXBjZS1wY2UtaW5pdGlh dGVkLWxzcC0wNA0KDQpIaSwNCg0KT24gMTAgSnVuZSAyMDE1IGF0IDAzOjMyLCBWZW51Z29wYWwg UmVkZHkgSyA8dmVudWdvcGFscmVkZHlrQGh1YXdlaS5jb208bWFpbHRvOnZlbnVnb3BhbHJlZGR5 a0BodWF3ZWkuY29tPj4gd3JvdGU6DQpIaSwgRXZlcnlvbmUhDQoNCkhhdmUgZmV3IGNvbW1lbnRz L3F1ZXJpZXMgb24gZHJhZnQtaWV0Zi1wY2UtcGNlLWluaXRpYXRlZC1sc3AtMDQuIENvdWxkIHlv dSBwbGVhc2UgY2xhcmlmeSBvbiBiZWxvdyBwb2ludHM6DQoNCg0KICBTZWN0aW9uIDYNCg0KICBJ biBjYXNlIG9mIFBDRVAgc2Vzc2lvbiBmYWlsdXJlLCBjb250cm9sIG92ZXIgUENFLWluaXRpYXRl ZCBMU1BzDQogICByZXZlcnRzIHRvIHRoZSBQQ0MgYXQgdGhlIGV4cGlyYXRpb24gb2YgdGhlIHJl ZGVsZWdhdGlvbiB0aW1lb3V0LiAgQXQNCiAgIHRoaXMgcG9pbnQsIHRoZSBMU1AgaXMgYW4gIm9y cGhhbiIgdW50aWwgdGhlIGV4cGlyYXRpb24gb2YgdGhlIFN0YXRlDQogICBUaW1lb3V0IHRpbWVy LiAgVG8gb2J0YWluIGNvbnRyb2wgb2YgYSBQQ0UtaW5pdGlhdGVkIExTUCwgYSBQQ0UNCiAgIChl aXRoZXIgdGhlIG9yaWdpbmFsIG9yIG9uZSBvZiBpdHMgYmFja3Vwcykgc2VuZHMgYSBQQ0luaXRp YXRlDQogICBtZXNzYWdlLCBpbmNsdWRpbmcganVzdCB0aGUgU1JQIGFuZCBMU1Agb2JqZWN0cywg YW5kIGNhcnJ5aW5nIHRoZQ0KICAgUExTUC1JRCBvZiB0aGUgTFNQIGl0IHdhbnRzIHRvIHRha2Ug Y29udHJvbCBvZg0KDQoxLiAgICAgICBJbiBjYXNlIG9mIEJhY2t1cCBQQ0UsIHdoYXQgaXMgdGhl IHRyaWdnZXIgcG9pbnQgdG8gc2VuZCBQQ0luaXRpYXRlIG1lc3NhZ2UgdG8gdGFrZSBjb250cm9s IG9mIG9ycGhhbiBQQ0UtaW5pdGlhdGVkIExTUD8gSSBhbSB3b25kZXJpbmcgaG93IGRvZXMgYSBi YWNrdXAgUENFIGNvbWUgdG8ga25vdyB0aGF0IHNvbWUgTFNQcyBhcmUgb3JwaGFuZWQ/DQpJIHNl ZSB0d28gc2NlbmFyaW9zIDoNCiAgMSkgQW5vdGhlciBQQ0VQIFNlc3Npb24gaXMgdXAgLCBpbiB0 aGF0IGNhc2UgaXQgc2VlbXMgdG8gaW1wbHkgdGhhdCB0aGUgUENFKHMpIGtlZXAgdHJhY2sgb2Yg dGhlIExTUHMgaXQgY2FuIG1hbmFnZSBhbmQgdGhlIGxpdmVsaW5lc3Mgb2YgdGhlIG90aGVyIFBD RXMuDQogICAyKSBUaGVyZSBpcyBubyBvdGhlciBQQ0VQIHNlc3Npb24sIHRoZSBQQ0MgcmVjb25u ZWN0cyB0byBhbm90aGVyIFBDRSwgaW4gdGhpcyBjYXNlIHRoZSBQQ0UgY2FuIHRyeSB0byB0YWtl IG93bmVyc2hpcCBvZiB0aGUgSW5pdGlhdGVkLCBub3QgZGVsZWdhdGVkIExTUHMNCg0KIFdoaWxl IEkgYmVsaWV2ZSAxKSBpcyBhbiBpbnRlcmVzdGluZyBhcmNoaXRlY3R1cmUsIEkgZG8gbm90IHRo aW5rIHRoZSBwcm90b2NvbCBwcm9jZWR1cmVzIHNob3VsZCBwdXQgc3VjaCBjb25zdHJhaW50IHRv IHRoZSBQQ0UgaW1wbGVtZW50YXRpb24sIHNvIHRoZSBzZWNvbmQgb3B0aW9uIHlvdSBwcm9wb3Nl IHNob3VsZCBiZSBhbGxvd2VkLg0KDQpZZXMuIExldCB1cyBrbm93IGF1dGhvcnMgdmlldyBhYm91 dCBpdC4NCg0KDQoyLiAgICAgICBBbm90aGVyIG9wdGlvbiB3b3VsZCBiZSwgaWYgUENDIHRha2Vz IGNoYXJnZSBhbmQgZGVsZWdhdGUgdGhlIG9ycGhhbmVkIFBDRSBpbml0aWF0ZWQgTFNQcyB0byBi YWNrdXAgUENFIGJhc2VkIG9uIHRoZSBsb2NhbCBwb2xpY3k/DQoNCg0KSSB0aGluayB0aGlzIHNo b3VsZCBiZSBhbGxvd2VkLCB0aGUgdGV4dCBjb3VsZCBiZSA6DQoNCkluIGNhc2Ugb2YgUENFUCBz ZXNzaW9uIGZhaWx1cmUsIGNvbnRyb2wgb3ZlciBQQ0UtaW5pdGlhdGVkIExTUHMNCg0KcmV2ZXJ0 cyB0byB0aGUgUENDIGF0IHRoZSBleHBpcmF0aW9uIG9mIHRoZSByZWRlbGVnYXRpb24gdGltZW91 dC4gIEF0DQoNCnRoaXMgcG9pbnQsIHRoZSBQQ0MgTUFZIGRlbGVnYXRlIHRoZSBMU1AgdG8gYW5v dGhlciBQQ0UuIHRoZSBMU1AgaXMgYW4gIm9ycGhhbiIgdW50aWwgdGhlIGV4cGlyYXRpb24gb2Yg dGhlIFN0YXRlDQoNClRpbWVvdXQgdGltZXIuDQoNClNvbWUgY29vcmRpbmF0aW9uIGJldHdlZW4g UENFcyBpcyBzdGlsbCBuZWVkZWQsIGZvciB0aGUgb3JpZ2luYWwgUENFIHRvIHJlZ2FpbiBjb250 cm9sIG92ZXIgdGhhdCBMU1AgdGhlIGN1cnJlbnQgUENFIG11c3QgZm9yZmVpdCBjb250cm9sIG92 ZXIgdGhhdCBMU1AuDQpJbiBhZGRpdGlvbiB0aGVyZSBpcyBubyBFcnJvciB0byBpbmRpY2F0ZSB0 byB0aGUgUENFIHRoYXQgaGUgY2FuJ3QgaGF2ZSB0aGUgZGVsZWdhdGlvbiBiYWNrLCB0aGlzIHNo b3VsZCBiZSBhZGRlZCAsIGZvciBpbnN0YW5jZSAyNCw0DQoNCkxTUCBpbnN0YW50aWF0aW9uIGVy cm9yLCBSZXF1ZXN0ZWQgZGVsZWdhdGlvbiByZWplY3RlZCwgYW5vdGhlciBQQ0UgaGFzIHRoZSBk ZWxlZ2F0aW9uLiAoaWRlYWxseSBhbGxvdyB0aGUgb3B0aW9uYWwgaW5jbHVzaW9uIG9mIHRoZSBv dGhlciBQQ0UgU1BFQUtFUi1JREVOVElUWS1JRCBmb3IgdHJvdWJsZXNob290aW5nLiBpdCBzaG91 bGQgYmUgc3ViamVjdCB0byBzZWN1cml0eSBwb2xpY2llcykNCg0KDQpZZXMuIEkgYmVsaWV2ZSBk cmFmdCBkb2VzbuKAmXQgYWRkcmVzcyBpdC4gQWNjb3JkaW5nIHRvIGRyYWZ0LCBQQ0MgY2Fubm90 IHJldm9rZSB0aGUgZGVsZWdhdGlvbiBmb3IgUENFIGluaXRpYXRlZCBMU1BzIGZvciBhbiBhY3Rp dmUgUENFUCBzZXNzaW9uLiBTbywgaWYgdGhlIG9yaWdpbmFsIFBDRSBpcyBVUCBhbmQgaGFkIHRv IHRha2UgdGhlIGNvbnRyb2wgYmFjayBvZiBpdHMgb3duIGluaXRpYXRlZCBMU1BzKGZyb20gYmFj a3VwIFBDRSksIGl0IG1pZ2h0IG5vdCBiZSBwb3NzaWJsZSB3aXRob3V0IHNvbWUgY29vcmRpbmF0 aW9uIGJldHdlZW4gYm90aCBQQ0VzKGVpdGhlciB0aHJvdWdoIGluLWJhbmQgb3Igb3V0LW9mLWJh bmQgbWVjaGFuaXNtcykuDQpBbm90aGVyIG9wdGlvbiB3b3VsZCBiZSwgUENDIGNhbiBpZGVudGlm eSB0aGUgb3JpZ2luYWwgUENFIGZyb20gUENFIFNQRUFLRVItSURFTlRJVFktSUQgb2YgaW5pdGlh dGVkIExTUChhdCBjcmVhdGUgdGltZSkuIEFueSB0aW1lIG9yaWdpbmFsIFBDRSB0cmllcyB0byB0 YWtlIGNvbnRyb2wsIFBDQyBtYXkgY2hvb3NlIHRvIGVpdGhlciByZXZva2UgY29udHJvbCBvZiBM U1AgZnJvbSBiYWNrdXAgUENFIGFuZCBkZWxlZ2F0ZSBiYWNrIHRvIG9yaWdpbmFsIFBDRSBPciBt YXkgc2VuZCBQQ0VyciB3aXRoIOKAnHJlcXVlc3RlZCBkZWxlZ2F0aW9uIHJlamVjdGVk4oCdLg0K DQpSZXF1ZXN0IGF1dGhvcnMgb3BpbmlvbiBhYm91dCBpdC4NCg0KDQpSZXNwb25zZSB3aWxsIGJl IGFwcHJlY2lhdGVkLg0KDQpUaGFua3MgYSBsb3QuDQoNClJlZ2FyZHMsDQpWZW51DQoNCg0KUmVn YXJkcywNCiBDeXJpbA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KUGNlIG1haWxpbmcgbGlzdA0KUGNlQGlldGYub3JnPG1haWx0bzpQY2VAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BjZQ0KDQo= --_000_10376B02BC561F4185654159EF7900204593EB44szxeml561mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNv bnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcHJlDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0 ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvTGlzdFBhcmFn cmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0 eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJ bWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iLCJzZXJpZiI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFt ZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1h cmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM5NDM2MzQi PkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojOTQzNjM0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6Izk0MzYzNCI+UmVxdWVzdCBhdXRob3JzIHRvIGxldCB1cyBrbm93IHlvdXIgdmlldyBh Ym91dCBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Izk0MzYzNCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiM5NDM2MzQiPlRoYW5rcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Izk0MzYzNCI+ VmVudTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4gQ3lyaWwgTWFyZ2FyaWEgW21haWx0bzpjeXJpbC5tYXJnYXJpYUBn bWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMjAxNTwvc3Bhbj48c3BhbiBsYW5nPSJaSC1D TiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TIj7lubQ8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjY8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kyI+5pyIPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4xMDwvc3Bhbj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TIj7ml6U8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPg0KIDIwOjM0PGJyPg0KPGI+VG86PC9iPiBWZW51Z29wYWwgUmVk ZHkgSzxicj4NCjxiPkNjOjwvYj4gcGNlOyBpbmFtaW5laUBnb29nbGUuY29tPGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBbUGNlXSBGZXcgY29tbWVudHMvcXVlcmllcyBvbiBkcmFmdC1pZXRmLXBj ZS1wY2UtaW5pdGlhdGVkLWxzcC0wNDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SGksIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IDEwIEp1bmUgMjAxNSBhdCAwMzozMiwgVmVudWdvcGFsIFJlZGR5IEsgJmx0OzxhIGhyZWY9Im1h aWx0bzp2ZW51Z29wYWxyZWRkeWtAaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZlbnVnb3Bh bHJlZGR5a0BodWF3ZWkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PkhpLCBFdmVyeW9uZSE8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5I YXZlIGZldyBjb21tZW50cy9xdWVyaWVzIG9uIGRyYWZ0LWlldGYtcGNlLXBjZS1pbml0aWF0ZWQt bHNwLTA0LiBDb3VsZCB5b3UgcGxlYXNlIGNsYXJpZnkgb24gYmVsb3cgcG9pbnRzOjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwcmUgc3R5bGU9Im1hcmdp bi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2Jh Y2tncm91bmQtcG9zaXRpb24teDowJTtiYWNrZ3JvdW5kLXBvc2l0aW9uLXk6MCU7YmFja2dyb3Vu ZC1hdHRhY2htZW50OnNjcm9sbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6 YmxhY2siPiZuYnNwOyBTZWN0aW9uIDY8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5 bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJl YWstYWxsO2JhY2tncm91bmQtcG9zaXRpb24teDowJTtiYWNrZ3JvdW5kLXBvc2l0aW9uLXk6MCU7 YmFja2dyb3VuZC1hdHRhY2htZW50OnNjcm9sbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwO0luIGNhc2Ugb2YgUENFUCBzZXNzaW9uIGZhaWx1 cmUsIGNvbnRyb2wgb3ZlciBQQ0UtaW5pdGlhdGVkIExTUHM8L3NwYW4+PG86cD48L286cD48L3By ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt YXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFs bDtiYWNrZ3JvdW5kLXBvc2l0aW9uLXg6MCU7YmFja2dyb3VuZC1wb3NpdGlvbi15OjAlO2JhY2tn cm91bmQtYXR0YWNobWVudDpzY3JvbGwiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyByZXZlcnRzIHRvIHRoZSBQQ0MgYXQgdGhlIGV4cGlyYXRpb24gb2YgdGhlIHJlZGVsZWdh dGlvbiB0aW1lb3V0LiZuYnNwOyBBdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjcu OXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtiYWNrZ3JvdW5kLXBv c2l0aW9uLXg6MCU7YmFja2dyb3VuZC1wb3NpdGlvbi15OjAlO2JhY2tncm91bmQtYXR0YWNobWVu dDpzY3JvbGwiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyB0aGlzIHBvaW50 LCB0aGUgTFNQIGlzIGFuICZxdW90O29ycGhhbiZxdW90OyB1bnRpbCB0aGUgZXhwaXJhdGlvbiBv ZiB0aGUgU3RhdGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3Jv dW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7YmFja2dyb3VuZC1wb3NpdGlvbi14OjAl O2JhY2tncm91bmQtcG9zaXRpb24teTowJTtiYWNrZ3JvdW5kLWF0dGFjaG1lbnQ6c2Nyb2xsIj4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgVGltZW91dCB0aW1lci4mbmJzcDsg VG8gb2J0YWluIGNvbnRyb2wgb2YgYSBQQ0UtaW5pdGlhdGVkIExTUCwgYSBQQ0U8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVh azpicmVhay1hbGw7YmFja2dyb3VuZC1wb3NpdGlvbi14OjAlO2JhY2tncm91bmQtcG9zaXRpb24t eTowJTtiYWNrZ3JvdW5kLWF0dGFjaG1lbnQ6c2Nyb2xsIj4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDsgKGVpdGhlciB0aGUgb3JpZ2luYWwgb3Igb25lIG9mDQo8c3BhbiBzdHls ZT0iYmFja2dyb3VuZDp5ZWxsb3ciPml0cyBiYWNrdXBzPC9zcGFuPikgc2VuZHMgYSBQQ0luaXRp YXRlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZG REY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JhY2tncm91bmQtcG9zaXRpb24teDowJTtiYWNrZ3Jv dW5kLXBvc2l0aW9uLXk6MCU7YmFja2dyb3VuZC1hdHRhY2htZW50OnNjcm9sbCI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IG1lc3NhZ2UsIGluY2x1ZGluZyBqdXN0IHRoZSBT UlAgYW5kIExTUCBvYmplY3RzLCBhbmQgY2FycnlpbmcgdGhlPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21h cmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxs O2JhY2tncm91bmQtcG9zaXRpb24teDowJTtiYWNrZ3JvdW5kLXBvc2l0aW9uLXk6MCU7YmFja2dy b3VuZC1hdHRhY2htZW50OnNjcm9sbCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7IFBMU1AtSUQgb2YgdGhlIExTUCBpdCB3YW50cyB0byB0YWtlIGNvbnRyb2wgb2Y8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+MS48L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+SW4gY2FzZSBvZiBCYWNrdXAgUENFLCB3aGF0IGlzIHRoZSB0cmlnZ2VyIHBvaW50IHRvIHNl bmQgUENJbml0aWF0ZSBtZXNzYWdlIHRvIHRha2UgY29udHJvbCBvZiBvcnBoYW4gUENFLWluaXRp YXRlZCBMU1A/IEkgYW0gd29uZGVyaW5nIGhvdyBkb2VzIGEgYmFja3VwIFBDRSBjb21lIHRvIGtu b3cgdGhhdCBzb21lIExTUHMgYXJlIG9ycGhhbmVkPw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHNlZSB0d28gc2Nl bmFyaW9zIDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOyAxKSBBbm90aGVyIFBDRVAgU2Vzc2lvbiBpcyB1cCAsIGluIHRoYXQgY2FzZSBp dCBzZWVtcyB0byBpbXBseSB0aGF0IHRoZSBQQ0Uocykga2VlcCB0cmFjayBvZiB0aGUgTFNQcyBp dCBjYW4gbWFuYWdlIGFuZCB0aGUgbGl2ZWxpbmVzcyBvZiB0aGUgb3RoZXIgUENFcy48YnI+DQom bmJzcDsmbmJzcDsgMikgVGhlcmUgaXMgbm8gb3RoZXIgUENFUCBzZXNzaW9uLCB0aGUgUENDIHJl Y29ubmVjdHMgdG8gYW5vdGhlciBQQ0UsIGluIHRoaXMgY2FzZSB0aGUgUENFIGNhbiB0cnkgdG8g dGFrZSBvd25lcnNoaXAgb2YgdGhlIEluaXRpYXRlZCwgbm90IGRlbGVnYXRlZCBMU1BzDQo8YnI+ DQo8YnI+DQombmJzcDtXaGlsZSBJIGJlbGlldmUgMSkgaXMgYW4gaW50ZXJlc3RpbmcgYXJjaGl0 ZWN0dXJlLCBJIGRvIG5vdCB0aGluayB0aGUgcHJvdG9jb2wgcHJvY2VkdXJlcyBzaG91bGQgcHV0 IHN1Y2ggY29uc3RyYWludCB0byB0aGUgUENFIGltcGxlbWVudGF0aW9uLCBzbyB0aGUgc2Vjb25k IG9wdGlvbiB5b3UgcHJvcG9zZSBzaG91bGQgYmUgYWxsb3dlZC48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojRTM2 QzBBIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6Izk0MzYzNCI+WWVzLiBMZXQgdXMga25vdyBhdXRob3JzIHZpZXcg YWJvdXQgaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjQuOHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6 Izk0MzYzNCI+Jm5ic3A7IDxvOnA+DQo8L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdp bi1sZWZ0OjQuOHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Mi48L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QW5v dGhlciBvcHRpb24gd291bGQgYmUsIGlmIFBDQyB0YWtlcyBjaGFyZ2UgYW5kIGRlbGVnYXRlIHRo ZSBvcnBoYW5lZCBQQ0UgaW5pdGlhdGVkIExTUHMgdG8gYmFja3VwIFBDRSBiYXNlZCBvbiB0aGUg bG9jYWwgcG9saWN5Pw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1s ZWZ0OjQuOHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB0aGlzIHNob3VsZCBi ZSBhbGxvd2VkLCB0aGUgdGV4dCBjb3VsZCBiZSA6IDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHByZT5JbiBjYXNlIG9mIFBDRVAgc2Vzc2lvbiBmYWlsdXJlLCBjb250cm9sIG92ZXIg UENFLWluaXRpYXRlZCBMU1BzPG86cD48L286cD48L3ByZT4NCjxwcmU+cmV2ZXJ0cyB0byB0aGUg UENDIGF0IHRoZSBleHBpcmF0aW9uIG9mIHRoZSByZWRlbGVnYXRpb24gdGltZW91dC4mbmJzcDsg QXQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50aGlzIHBvaW50LCB0aGUgUENDIE1BWSBkZWxlZ2F0 ZSB0aGUgTFNQIHRvIGFub3RoZXIgUENFLiB0aGUgTFNQIGlzIGFuICZxdW90O29ycGhhbiZxdW90 OyB1bnRpbCB0aGUgZXhwaXJhdGlvbiBvZiB0aGUgU3RhdGU8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT5UaW1lb3V0IHRpbWVyLiA8bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlNvbWUgY29vcmRpbmF0aW9uIGJldHdlZW4g UENFcyBpcyBzdGlsbCBuZWVkZWQsIGZvciB0aGUgb3JpZ2luYWwgUENFIHRvIHJlZ2FpbiBjb250 cm9sIG92ZXIgdGhhdCBMU1AgdGhlIGN1cnJlbnQgUENFIG11c3QgZm9yZmVpdCBjb250cm9sIG92 ZXIgdGhhdCBMU1AuDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkluIGFkZGl0aW9uIHRoZXJlIGlzIG5vIEVycm9yIHRvIGluZGljYXRlIHRvIHRo ZSBQQ0UgdGhhdCBoZSBjYW4ndCBoYXZlIHRoZSBkZWxlZ2F0aW9uIGJhY2ssIHRoaXMgc2hvdWxk IGJlIGFkZGVkICwgZm9yIGluc3RhbmNlIDI0LDQNCjxvOnA+PC9vOnA+PC9wPg0KPHByZT5MU1Ag aW5zdGFudGlhdGlvbiBlcnJvciwgUmVxdWVzdGVkIGRlbGVnYXRpb24gcmVqZWN0ZWQsIGFub3Ro ZXIgUENFIGhhcyB0aGUgZGVsZWdhdGlvbi4gKGlkZWFsbHkgYWxsb3cgdGhlIG9wdGlvbmFsIGlu Y2x1c2lvbiBvZiB0aGUgb3RoZXIgUENFIFNQRUFLRVItSURFTlRJVFktSUQgZm9yIHRyb3VibGVz aG9vdGluZy4gaXQgc2hvdWxkIGJlIHN1YmplY3QgdG8gc2VjdXJpdHkgcG9saWNpZXMpIDxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izk0MzYzNCI+WWVzLiBJ IGJlbGlldmUgZHJhZnQgZG9lc27igJl0IGFkZHJlc3MgaXQuIEFjY29yZGluZyB0byBkcmFmdCwg UENDIGNhbm5vdCByZXZva2UgdGhlIGRlbGVnYXRpb24gZm9yIFBDRSBpbml0aWF0ZWQgTFNQcyBm b3IgYW4gYWN0aXZlIFBDRVAgc2Vzc2lvbi4gU28sIGlmIHRoZSBvcmlnaW5hbCBQQ0UgaXMgVVAg YW5kIGhhZCB0byB0YWtlIHRoZSBjb250cm9sIGJhY2sNCiBvZiBpdHMgb3duIGluaXRpYXRlZCBM U1BzKGZyb20gYmFja3VwIFBDRSksIGl0IG1pZ2h0IG5vdCBiZSBwb3NzaWJsZSB3aXRob3V0IHNv bWUgY29vcmRpbmF0aW9uIGJldHdlZW4gYm90aCBQQ0VzKGVpdGhlciB0aHJvdWdoIGluLWJhbmQg b3Igb3V0LW9mLWJhbmQgbWVjaGFuaXNtcykuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5NDM2MzQiPkFub3RoZXIgb3B0aW9u IHdvdWxkIGJlLCBQQ0MgY2FuIGlkZW50aWZ5IHRoZSBvcmlnaW5hbCBQQ0UgZnJvbSBQQ0UgU1BF QUtFUi1JREVOVElUWS1JRCBvZiBpbml0aWF0ZWQgTFNQKGF0IGNyZWF0ZSB0aW1lKS4gQW55IHRp bWUgb3JpZ2luYWwgUENFIHRyaWVzIHRvIHRha2UgY29udHJvbCwgUENDIG1heSBjaG9vc2UgdG8g ZWl0aGVyIHJldm9rZSBjb250cm9sIG9mDQogTFNQIGZyb20gYmFja3VwIFBDRSBhbmQgZGVsZWdh dGUgYmFjayB0byBvcmlnaW5hbCBQQ0UgT3IgbWF5IHNlbmQgUENFcnIgd2l0aCDigJxyZXF1ZXN0 ZWQgZGVsZWdhdGlvbiByZWplY3RlZOKAnS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izk0MzYzNCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5 NDM2MzQiPlJlcXVlc3QgYXV0aG9ycyBvcGluaW9uIGFib3V0IGl0LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojOTQzNjM0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDo0LjhwdCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+UmVzcG9uc2Ugd2ls bCBiZSBhcHByZWNpYXRlZC4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21hcmdpbi1sZWZ0OjQuOHB0Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2lu LWxlZnQ6NC44cHQiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoYW5rcyBhIGxvdC48 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6 NC44cHQiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo0LjhwdCI+DQo8c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NC44cHQiPg0KPHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPlZlbnU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bWFyZ2luLWxlZnQ6NC44cHQiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8YnI+DQombmJz cDtDeXJpbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6 MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDowY207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjEyLjBw dDttYXJnaW4tbGVmdDo0LjhwdCI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NClBjZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86 UGNlQGlldGYub3JnIj5QY2VAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wY2UiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BjZTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_10376B02BC561F4185654159EF7900204593EB44szxeml561mbxchi_-- From nobody Mon Jun 22 05:43: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 5C2DA1A1BF3 for ; Mon, 22 Jun 2015 05:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 8RGBTEt3zrV9 for ; Mon, 22 Jun 2015 05:43:53 -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 C49641A1B8D for ; Mon, 22 Jun 2015 05:43:52 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id D92C3324AE1 for ; Mon, 22 Jun 2015 14:43:50 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.31]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 984EF35C06D for ; Mon, 22 Jun 2015 14:43:50 +0200 (CEST) Received: from [10.193.71.204] (10.168.234.1) by OPEXCLILM22.corporate.adroot.infra.ftgroup (10.114.31.31) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 22 Jun 2015 14:43:50 +0200 Message-ID: <21179_1434977030_55880306_21179_853_5_55880305.1030706@orange.com> Date: Mon, 22 Jun 2015 14:43:49 +0200 From: Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "pce@ietf.org" Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.168.234.1] X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.6.2.75418 Archived-At: Subject: [Pce] Building the PCE Agenda for IETF 93 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Julien Meuric , 'JP Vasseur' , Daniel King List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 12:43:54 -0000 Hi all, The PCE WG session is *tentatively* scheduled in Prague meeting on Thursday 23rd at 1 PM. If you need some face to face time to progress your work, please send a request to the chairs and secretary by Friday, July 3, including: - the corresponding I-D(s), - the expected presenter, - a requested duration, - the motivation for requesting a face to face presentation as opposed to using only the mailing list (which you should be using in both cases). Thanks, 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 Jun 23 19:13:35 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 6994E1B33A3; Tue, 23 Jun 2015 19:13:32 -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 lxx1zITY-d3q; Tue, 23 Jun 2015 19:13:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F02211B339B; Tue, 23 Jun 2015 19:13:30 -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.0.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150624021330.25705.18456.idtracker@ietfa.amsl.com> Date: Tue, 23 Jun 2015 19:13:30 -0700 Archived-At: Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-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, 24 Jun 2015 02:13:32 -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 : Conveying path setup type in PCEP messages Authors : Siva Sivabalan Jan Medved Ina Minei Edward Crabbe Robert Varga Jeff Tantsura Jon Hardwick Filename : draft-ietf-pce-lsp-setup-type-03.txt Pages : 8 Date : 2015-06-23 Abstract: A Path Computation Element can compute traffic engineering paths (TE paths) through a network that are subject to various constraints. Currently, TE paths are label switched paths (LSPs) which are set up using the RSVP-TE signaling protocol. However, other TE path setup methods are possible within the PCE architecture. This document proposes an extension to PCEP to allow support for different path setup methods over a given PCEP session. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-setup-type/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-pce-lsp-setup-type-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-lsp-setup-type-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 Jun 23 21:25: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 71C711A01F2 for ; Tue, 23 Jun 2015 21:25:05 -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 1OvGA-UJkL-1 for ; Tue, 23 Jun 2015 21:25: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 1A3241A0016 for ; Tue, 23 Jun 2015 21:25:01 -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 BUG81771; Wed, 24 Jun 2015 04:25:00 +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.158.1; Wed, 24 Jun 2015 05:24:57 +0100 Received: from BLREML509-MBX.china.huawei.com ([169.254.7.39]) by BLREML406-HUB.china.huawei.com ([10.20.4.43]) with mapi id 14.03.0158.001; Wed, 24 Jun 2015 09:54:49 +0530 From: Dhruv Dhody To: pce Thread-Topic: Update to the Stateful PCE Auto-Bw draft Thread-Index: AdCuNbSYNrfNrCoATeqAHIaI1VIyzA== Date: Wed, 24 Jun 2015 04:24:48 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B870EFDC2@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_23CE718903A838468A8B325B80962F9B870EFDC2BLREML509MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Pce] Update to the Stateful PCE Auto-Bw 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: Wed, 24 Jun 2015 04:25:05 -0000 --_000_23CE718903A838468A8B325B80962F9B870EFDC2BLREML509MBXchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, We have updated the draft "draft-dhody-pce-stateful-pce-auto-bandwidth" bas= ed on the comments received during the Dallas meeting. The main changes are - - Rakesh joined the team as co-author and provided valuable inputs and= text - Added clarity in the draft with respect to the two deployment models= with a table summarizing the requirements and differences - Added a scaling consideration section o Added a mechanism to report bandwidth samples together, reducing the nu= mber of PCRpt messages o Described the use threshold to further curb them - Encoding o Added sub-TLVs for the AUTO-BANDWIDTH-ATTRIBUTE TLV =A7 Described each sub-TLV =A7 Part of LSPA object (instead of LSP object) o New BANDWIDTH object type for Bandwidth-Usage reporting =A7 Allow multiple samples - Editorial Changes The diff can be found at - https://www.ietf.org/rfcdiff?url1=3Ddraft-dhody-= pce-stateful-pce-auto-bandwidth-04&url2=3Ddraft-dhody-pce-stateful-pce-auto= -bandwidth-05 I-D: https://tools.ietf.org/html/draft-dhody-pce-stateful-pce-auto-bandwidt= h-05 Please continue to provide feedback... Regards, Dhruv --_000_23CE718903A838468A8B325B80962F9B870EFDC2BLREML509MBXchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi All,

 

We have updated the draft “draft-dhody-pce-st= ateful-pce-auto-bandwidth” based on the comments received during the = Dallas meeting.

 

The main changes are –

-      Rakesh joined the team as co-author and pro= vided valuable inputs and text

-      Added clarity in the draft with respect to = the two deployment models with a table summarizing the requirements and dif= ferences

-      Added a scaling consideration section

o   Added a mechanism to report bandwidth sampl= es together, reducing the number of PCRpt messages

o   Described the use threshold to further curb= them

-      Encoding

o   Added sub-TLVs for the AUTO-BANDWIDTH-ATTRI= BUTE TLV

=A7&= nbsp; Described each sub-TLV

=A7&= nbsp; Part of LSPA object (instead of LSP object)=

o   New BANDWIDTH object type for Bandwidth-Usa= ge reporting

=A7&= nbsp; Allow multiple samples

-      Editorial Changes

 

The diff can be found at - https://www.ietf.org/rfcdiff?url1=3Ddraft-dhody-pce-stateful-pce-auto-bandw= idth-04&url2=3Ddraft-dhody-pce-stateful-pce-auto-bandwidth-05<= /o:p>

I-D: https://tools.ietf.org/html/draft-dhody-pce-st= ateful-pce-auto-bandwidth-05

 

Please continue to provide feedback…

 

Regards,

Dhruv

 

 

--_000_23CE718903A838468A8B325B80962F9B870EFDC2BLREML509MBXchi_-- From nobody Mon Jun 29 05:05:21 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 124B31A9085 for ; Mon, 29 Jun 2015 05:05: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 DfjI0Ehq3cbS for ; Mon, 29 Jun 2015 05:05: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 90D241A9088 for ; Mon, 29 Jun 2015 05:04:27 -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 BYC77255; Mon, 29 Jun 2015 12:04:26 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 29 Jun 2015 13:04:09 +0100 Received: from NKGEML503-MBX.china.huawei.com ([169.254.5.172]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Mon, 29 Jun 2015 20:04:04 +0800 From: "Zhuangyan (Yan)" To: "pce@ietf.org" Thread-Topic: [Pce] I-D Action: draft-zhuang-pce-stateful-pce-lsp-scheduling-00.txt Thread-Index: AdCyY7Cd8olfct/cQ1GSPjPeRt7HZg== Date: Mon, 29 Jun 2015 12:04:03 +0000 Message-ID: <9B4BC45FDEDDD84F813E9E4A5BAF8785865A32B7@nkgeml503-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.135.170.230] Content-Type: multipart/alternative; boundary="_000_9B4BC45FDEDDD84F813E9E4A5BAF8785865A32B7nkgeml503mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Pce] I-D Action: draft-zhuang-pce-stateful-pce-lsp-scheduling-00.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, 29 Jun 2015 12:05:20 -0000 --_000_9B4BC45FDEDDD84F813E9E4A5BAF8785865A32B7nkgeml503mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, As mentioned in rfc7399 on service scheduling in pce, we prepared a new dra= ft to provide LSP scheduling for a centralized pce system as shown in https://tools.ietf.org/html/draft-zhuang-pce-stateful-pce-lsp-scheduling-00 This document is to enable LSP scheduling for path computation and LSP setu= p/deletion based on the actual network resource usage duration of a traffic= service in a centralized network environment. Please feel free to let us know your comments and thoughts on this topic. Regards, Yan --_000_9B4BC45FDEDDD84F813E9E4A5BAF8785865A32B7nkgeml503mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

As mentioned in rfc7399 on serv= ice scheduling in pce, we prepared a new draft to provide LSP scheduling fo= r a centralized pce system as shown in

https://tools.ietf= .org/html/draft-zhuang-pce-stateful-pce-lsp-scheduling-00

 

This document is to enable LSP = scheduling for path computation and LSP setup/deletion based on the actual = network resource usage duration of a traffic service in a centralized netwo= rk environment.

 

Please feel free to let us know= your comments and thoughts on this topic.

 

Regards,

 

Yan

 

--_000_9B4BC45FDEDDD84F813E9E4A5BAF8785865A32B7nkgeml503mbxchi_-- From nobody Mon Jun 29 21:32:08 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 6FBB81B30A4 for ; Mon, 29 Jun 2015 21:32:07 -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 gZOH_WONmXEf for ; Mon, 29 Jun 2015 21:32:05 -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 2A9911B30A2 for ; Mon, 29 Jun 2015 21:32:05 -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 BUN33727; Tue, 30 Jun 2015 04:32:02 +0000 (GMT) Received: from BLREML406-HUB.china.huawei.com (10.20.4.43) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 30 Jun 2015 05:32:01 +0100 Received: from BLREML509-MBX.china.huawei.com ([169.254.7.39]) by BLREML406-HUB.china.huawei.com ([10.20.4.43]) with mapi id 14.03.0158.001; Tue, 30 Jun 2015 10:01:54 +0530 From: Dhruv Dhody To: "pce@ietf.org" Thread-Topic: Stateful PCE for P2MP Thread-Index: AdCy7bEqRlHH4L7rRCKlAh5Kxf4Tlg== Date: Tue, 30 Jun 2015 04:31:54 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B870F5DF0@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_23CE718903A838468A8B325B80962F9B870F5DF0BLREML509MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Pce] Stateful PCE for P2MP 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, 30 Jun 2015 04:32:07 -0000 --_000_23CE718903A838468A8B325B80962F9B870F5DF0BLREML509MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We have updated the Stateful PCE P2MP documents. [1] They were last discussed during the IETF 90 (Toronto) [2]. Since then the technical core of the documents has remain stable [3], while= following modifications are done - - Error handling for missing ENDPOINT / S2LS objects - Fragmentation error handling - Update in error handling for non-supported P2MP - Updated IANA section - Pavan joined the team of co-authors - Editorial changes There are no known open issues; the authors believe that the document is in= good shape for WG adoption. Regards, Dhruv (on behalf of the authors) [1] I-D: https://tools.ietf.org/html/draft-palle-pce-stateful-pce-p2mp-07 & https://tools.ietf.org/html/draft-palle-pce-stateful-pce-initiated-p2mp-l= sp-06 [2] Slides: http://www.ietf.org/proceedings/90/slides/slides-90-pce-2.pdf [3] Diff: http://tools.ietf.org/rfcdiff?url1=3Dhttp://tools.ietf.org/id/dra= ft-palle-pce-stateful-pce-p2mp-04.txt&url2=3Dhttp://tools.ietf.org/id/draft= -palle-pce-stateful-pce-p2mp-07.txt & http://tools.ietf.org/rfcdiff?url1=3Dhttp://tools.ietf.org/id/draft-palle= -pce-stateful-pce-initiated-p2mp-lsp-03.txt&url2=3Dhttp://tools.ietf.org/id= /draft-palle-pce-stateful-pce-initiated-p2mp-lsp-06.txt --_000_23CE718903A838468A8B325B80962F9B870F5DF0BLREML509MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

We have updated the Stateful PCE P2MP documents. [1= ]

They were last discussed during the IETF 90 (Toront= o) [2].

 

Since then the technical core of the documents has = remain stable [3], while following modifications are done -  

 

-      Error handling for missing ENDPOINT / S2LS = objects

-      Fragmentation error handling

-      Update in error handling for non-supported = P2MP

-      Updated IANA section

-      Pavan joined the team of co-authors

-      Editorial changes

 

There are no known open issues; the authors believe= that the document is in good shape for WG adoption.

 

Regards,

Dhruv (on behalf of the authors)<= /p>

 

[1] I-D: https://tools.ietf.org/html/draft-palle-pc= e-stateful-pce-p2mp-07

& https://tools.ietf.org/html/draft-palle-pce-stateful-pce-initiated-p2mp-lsp= -06

 

[2] Slides: h= ttp://www.ietf.org/proceedings/90/slides/slides-90-pce-2.pdf=

 

[3] Diff: http://tools.ietf.org/rfcdiff?url1=3Dhttp://tools.ietf.org/id/draft-palle-p= ce-stateful-pce-p2mp-04.txt&url2=3Dhttp://tools.ietf.org/id/draft-palle= -pce-stateful-pce-p2mp-07.txt

& http://tools.ietf.org/rfcdiff?url1=3Dhttp://tools.ietf.org/id/draft-palle-p= ce-stateful-pce-initiated-p2mp-lsp-03.txt&url2=3Dhttp://tools.ietf.org/= id/draft-palle-pce-stateful-pce-initiated-p2mp-lsp-06.txt

 

--_000_23CE718903A838468A8B325B80962F9B870F5DF0BLREML509MBXchi_-- From nobody Tue Jun 30 23:32:08 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 32BD11AD0B6 for ; Tue, 30 Jun 2015 23:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.422 X-Spam-Level: X-Spam-Status: No, score=-1.422 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, 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 xkMx_-Mew3r9 for ; Tue, 30 Jun 2015 23:32:04 -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 0BC121AD0B3 for ; Tue, 30 Jun 2015 23:32:03 -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 BUO53672; Wed, 01 Jul 2015 06:32:03 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 1 Jul 2015 07:32:02 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.89]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Wed, 1 Jul 2015 14:31:57 +0800 From: Qin Wu To: "pce@ietf.org" Thread-Topic: I-D Action: draft-wu-pce-traffic-steering-sfc-07.txt Thread-Index: AQHQs8ZRXNXpM3cgx069uMhnL6LoP53GJdZg Date: Wed, 1 Jul 2015 06:31:56 +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.138.41.180] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Pce] I-D Action: draft-wu-pce-traffic-steering-sfc-07.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, 01 Jul 2015 06:32:06 -0000 SGksIGFsbDoNClNvbWUgZGlzY3Vzc2lvbiBhcmUgcmFpc2VkIG9uIFNGQyBsaXN0IHJlZ2FyZGlu ZyBQQ0VQIHJlcXVpcmVtZW50cyBmb3IgU0ZDIHN1cHBvcnQuDQpUaGVzZSByZXF1aXJlbWVudHMg aGF2ZSBiZWVuIGRvY3VtZW50ZWQgaW4gdGhlIGNvbnNvbGlkYXRlZCBkcmFmdA0KaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd3ctc2ZjLWNvbnRyb2wtcGxhbmUtMDYudHh0DQoNCkhl cmUgaXMgdGhlIHVwZGF0ZWQgc29sdXRpb24gZHJhZnQgdG8gYWRkcmVzcyB0aGVzZSByZXF1aXJl bWVudHMuDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd3UtcGNlLXRyYWZmaWMt c3RlZXJpbmctc2ZjLTA3DQpNb3N0IG9mIGNoYW5nZXMgYXJlIHRvIGdldCBpbiBsaW5lIHdpdGgg dGhlIGxhdGVzdCB2ZXJzaW9uIG9mIGRyYWZ0LXd3LXNmYy1jb250cm9sLXBsYW5lLTA2Lg0KWW91 ciBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMgYXJlIHdlbGNvbWUhDQoNClJlZ2FyZHMhDQotUWlu DQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogSS1ELUFubm91bmNlIFttYWlsdG86aS1kLWFu bm91bmNlLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQq3 osvNyrG85DogMjAxNcTqN9TCMcjVIDE0OjIyDQrK1bz+yMs6IGktZC1hbm5vdW5jZUBpZXRmLm9y Zw0K1vfM4jogSS1EIEFjdGlvbjogZHJhZnQtd3UtcGNlLXRyYWZmaWMtc3RlZXJpbmctc2ZjLTA3 LnR4dA0KDQoNCkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1s aW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCg0KDQogICAgICAgIFRpdGxlICAgICAg ICAgICA6IFBDRVAgRXh0ZW5zaW9ucyBmb3IgdHJhZmZpYyBzdGVlcmluZyBzdXBwb3J0IGluIFNl cnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcNCiAgICAgICAgQXV0aG9ycyAgICAgICAgIDogUWluIFd1 DQogICAgICAgICAgICAgICAgICAgICAgICAgIERocnV2IERob2R5DQogICAgICAgICAgICAgICAg ICAgICAgICAgIE1vaGFtZWQgQm91Y2FkYWlyDQogICAgICAgICAgICAgICAgICAgICAgICAgIENo cmlzdGlhbiBKYWNxdWVuZXQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgSmVmZiBUYW50c3Vy YQ0KCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LXd1LXBjZS10cmFmZmljLXN0ZWVyaW5nLXNmYy0w Ny50eHQNCglQYWdlcyAgICAgICAgICAgOiAxMQ0KCURhdGUgICAgICAgICAgICA6IDIwMTUtMDYt MzANCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IHByb3ZpZGVzIGFuIG92ZXJ2aWV3IG9m IHRoZSB1c2FnZSBvZiBQYXRoIENvbXB1dGF0aW9uDQogICBFbGVtZW50IChQQ0UpIHdpdGggU2Vy dmljZSBGdW5jdGlvbiBDaGFpbmluZyAoU0ZDKTsgd2hpY2ggaXMNCiAgIGRlc2NyaWJlZCBhcyB0 aGUgZGVmaW5pdGlvbiBhbmQgaW5zdGFudGlhdGlvbiBvZiBhbiBvcmRlcmVkIHNldCBvZg0KICAg c3VjaCBzZXJ2aWNlIGZ1bmN0aW9ucyAoc3VjaCBhcyBmaXJld2FsbHMsIGxvYWQgYmFsYW5jZXJz KSwgYW5kIHRoZQ0KICAgc3Vic2VxdWVudCAic3RlZXJpbmciIG9mIHRyYWZmaWMgZmxvd3MgdGhy b3VnaCB0aG9zZSBzZXJ2aWNlDQogICBmdW5jdGlvbnMuDQoNCiAgIFRoaXMgZG9jdW1lbnQgc3Bl Y2lmaWVzIGV4dGVuc2lvbnMgdG8gdGhlIFBhdGggQ29tcHV0YXRpb24gRWxlbWVudA0KICAgUHJv dG9jb2wgKFBDRVApIHRoYXQgYWxsb3cgYSBzdGF0ZWZ1bCBQQ0UgdG8gY29tcHV0ZSBhbmQgaW5z dGFudGlhdGUNCiAgIFNlcnZpY2UgRnVuY3Rpb24gUGF0aHMgKFNGUCkuDQoNCg0KVGhlIElFVEYg ZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQpodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13dS1wY2UtdHJhZmZpYy1zdGVlcmluZy1zZmMvDQoN ClRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXd1LXBjZS10cmFmZmljLXN0ZWVyaW5nLXNmYy0wNw0K DQpBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQpodHRw czovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtd3UtcGNlLXRyYWZmaWMtc3RlZXJp bmctc2ZjLTA3DQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBt aW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVy c2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpJbnRlcm5l dC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQpmdHA6Ly9m dHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KSS1ELUFubm91bmNlIG1haWxpbmcgbGlzdA0KSS1ELUFu bm91bmNlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2kt ZC1hbm5vdW5jZQ0KSW50ZXJuZXQtRHJhZnQgZGlyZWN0b3JpZXM6IGh0dHA6Ly93d3cuaWV0Zi5v cmcvc2hhZG93Lmh0bWwgb3IgZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50 eHQNCg==