From dhruv.ietf@gmail.com Mon Apr 1 09:31:33 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31B0C1F0D0B for ; Mon, 1 Apr 2013 09:31:33 -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=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hln2m1cBhcnw for ; Mon, 1 Apr 2013 09:31:31 -0700 (PDT) Received: from mail-ia0-x236.google.com (mail-ia0-x236.google.com [IPv6:2607:f8b0:4001:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id BB8F81F0CF7 for ; Mon, 1 Apr 2013 09:31:31 -0700 (PDT) Received: by mail-ia0-f182.google.com with SMTP id u8so2011730iag.41 for ; Mon, 01 Apr 2013 09:31:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:x-google-sender-delegation :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=YjJvoVH38ZxHqdIQ3yqAIoy4P10ACmmez0FyrWbccl4=; b=jocDWhU+FA40njPwRQEJ8p8MBVK8mStFZzlitseuJuVMwQCQfHZmKJiWI1XX3/OqGp zN8L5c8Vo/5ocrj/W2Tp9w/OwtCm5TgouFI5+JN28Zh0vqi63qOnLf3lmoTFWKxbkyNT GV0QGS8mEONBc0/hoBDgPdFfT/Y0jIhRUr2qDS1ctR82V5Jc2GXnsX4tSiPX8aEXLzhb FVq/QC6ESJx46ZcXAp0S16Tgz0C/ImXkYQmabO9h5oCFNQRPTohtPD7s3aIzXTUXy6Rd kSMSwrEKU+6eDu03TGRjAXFyJHc4qd0AuugvaSE/9imTNxB9HpiY/lhWMeJ5yEd1oiU7 +TRA== MIME-Version: 1.0 X-Received: by 10.50.190.233 with SMTP id gt9mr3718109igc.80.1364833891334; Mon, 01 Apr 2013 09:31:31 -0700 (PDT) Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.25.2 with HTTP; Mon, 1 Apr 2013 09:31:31 -0700 (PDT) In-Reply-To: <70BDAD02381BA54CA31315A2A26A7AD3037352A8@BY2PRD0511MB440.namprd05.prod.outlook.com> References: <70BDAD02381BA54CA31315A2A26A7AD3037352A8@BY2PRD0511MB440.namprd05.prod.outlook.com> Date: Mon, 1 Apr 2013 22:01:31 +0530 X-Google-Sender-Auth: mcKDNOQ2qccU_rouogJjmBJA70M Message-ID: From: Dhruv Dhody To: Ina Minei Content-Type: multipart/alternative; boundary=14dae934117745403a04d94f2783 Cc: "pce@ietf.org" Subject: Re: [Pce] Comments on draft-ietf-pce-stateful-pce-02 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 16:31:33 -0000 --14dae934117745403a04d94f2783 Content-Type: text/plain; charset=ISO-8859-1 Hi Ina, Thanks for your reply, find the response inline, also I have a few comments on -03 version of the draft which is at the end of this mail. Dhruv On Sat, Mar 23, 2013 at 5:40 AM, Ina Minei wrote: > Dhruv, **** > > Thank you for the review. Please see answers inline below ###. > > Ina > > *From:* pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] *On Behalf Of *Dhruv > Dhody > > *Sent:* Monday, March 11, 2013 8:03 AM > *To:* pce@ietf.org > *Subject:* [Pce] Comments on draft-ietf-pce-stateful-pce-02**** > > ** ** > > Hi,**** > > Please find the review comments for this draft (there is some overlap with > comments from Jon, Cyril etc) > ** > > ** > > *Major Comments:* > ** > > ** > > (1) State synchronisation: **** > > a. PCE should determine the synchronisation is over as soon as possible, > as updates, request etc are blocked during synchronisation. Maybe the last > report message can have SYNC=0 (similar to F - fragmentation bit in RP > object) or as Jon suggested an empty report but then the RBNF of PCRpt > should support it. **** > > ### Please see version 03 of the draft.**** > > ** ** > > b. I also dont like the use of word 'purge' with respect to old or stale > entries during PCEP session up/down. A mechanism to mark LSP entries as > stale and waiting for them to be refreshed after session up and deleted (or > 'purged') only after some timer expiry.**** > > ### Please see version 03 of the draft. **** > > ** ** > > ** ** > > (2) The PCRpt Message:**** > > ::= [] Where: ::=[]. > Is this to specify primary and backup? In which case the status of the > paths needs to reported separately in case of standby but we have only one > LSP object here to specify the operational status. Also LSP-ID of primary > and backup would be different. **** > > ** ** > > Also applicable to PCUpd message. **** > > I feel the backup path should be updated and reported separately with each > having there own encoding for LSP object. **** > > ### Clarification on backup paths will be done in the protection doc. I > agree with you the text needs to be cleaned up in the base spec, will do so > in 04. **** > > ** ** > > (3) Node Identifier TLV**** > > PCC may use address that survives the session restart (Loopback, MPLS > LSR-ID etc), i suggest we mention this in the document and provide guidance > to implementers to do this if possible. **** > > ### the node-id (now renamed to predundancy-group-id) will be further > clarified in version 04**** > > ** ** > > (4) LSP Object: **** > > a. What is relationship between the LSP-ID in LSP object and the LSP-ID in > LSP Identifier TLVs?**** > > ### The lsp-id in the lsp object was renamed to plsp-id to avoid such > confusion. > *[DD]: Rename is good, but i hope relationship between the PLSP-ID and the LSP-ID (signalled by RSVP) can be explicitly mentioned. This should especially be clarified in the case of MBB. * > ** > > b. There is no mechanism to report the 'pending' state right now? O-Bit as > zero will mean down, not pending. **** > > ### The O-bit will be revisited in version 04.**** > > ** ** > > (5) Make-Before-Break: **** > > There is a need to clarify how MBB is achieved, what is the LSP-ID in case > of updates and reports? **** > > ### Please see version 03. **** > > > *[DD]: The updated text though in the right direction is still missing key information. I hope the next version clarifies it further. * > **** > > ** ** > > *Minor Comments: ***** > > (1) Abstract/Introduction**** > > There is a consistent use of phrase "between and across PCEP sessions". > Can you clarify? **** > > ### LSPs may move from one PCE to another.**** > > ** ** > > (2) Re-look the terminology section as some terms are no longer in the > document. **** > > ### Could you send the correction?**** > > ** > *[DD]: Just removal of MPLS TE Global Default Restoration & MPLS TE Global Path Protection should do the trick. Both terms are no longer used in this document. * > ** > > (3) LSP Protection **** > > In case of delegated PCE, the desired protection may also be configured at > PCC and the active stateful PCE should support it, the stateful PCE having > full control over the protection / restoration settings can only be > achieved with instantiation capability and should be out of scope from this > document. **** > > ### The whole discussion on protection belongs in a separate document.**** > > ** ** > > (4) Delegation**** > > a. The wording "an LSP may be delegated to one or more PCEs." .. this is > incorrect, from the reading it looks as if this is happening at the same > time. **** > > ### To a single PCE, text is clarified in 03.**** > > ** ** > > b. Active stateful PCE LSP Update (sec 5.6.2)**** > > OLD:**** > > A PCC may choose to compress LSP State Updates to only reflect the most > up to date state, as discussed in the previous section. **** > > NEW:**** > > A PCC may choose to compress LSP State Reports to only reflect the most > up to date state, as discussed in the previous section. **** > > ### Actually, I think we mean updates, not reports (if receiving multiple > updates, may choose to do state compression during processing)**** > > ** > *[DD]: Okay I understand, it mean that PCC is only taking the latest Update into consideration; now i am wondering can PCC choose to compress reports and send the most upto date report? (skip sending pending if not yet send; or in case of multiple up-down only send the latest state) * > ** > > (5) Symbolic Path Name TLV**** > > The length of this TLV must be greater then 0 as well as multiple of four. > **** > > ### I think this is not necessary to specify in words, the figure should > be sufficient. > *[DD]: In most cases yes, but this is a case of variable length we must make sure extra padding is added and the TLV is aligned. You can take your cue from other RFC where variable length TLV exists say RFC4920; RFC6001 etc * > **** > > ** ** > > (6) LSP state DB version TLV (page 40, para 2)**** > > "Since a PCE does not send LSP updates to a PCC, a PCC should never > encounter this TLV". LSP updates here can be easily confused with the PCUpd > messages. Kindly reword this. **** > > ### Will do.**** > > ** ** > > Regards,**** > > Dhruv > * * * * *Few more comments on the -03 version: * * * *(1) Section 5.5.2 (Revocation of delegated LSP)* * * *When a PCC revokes a delegated LSP, PCC immediately clears the LSP state received from this PCE. But we should apply Make-Before-Break here as well, that is while the PCC delegates to another PCE or keep the LSP with itself, the LSP should not be teardown immediately. * * * *(2) Modification of Tunnel configuration at PCC for a delegated LSP. * * * *Incase of manual config change (say bandwidth, priority) at PCC, how the new LSP parameters to be reported to the PCE (maybe a separate delegation request with new PLSP-ID) eventually make-before-break should be applied here as well. When the text for MBB is added in detail, this could also be considered. * * * *(3) Section 6.1 (The PCRpt Message)* * * *Please consider the comments given for **draft-crabbe-pce-stateful-pce-mpls-te-00 regarding the PCRpt message here as well** [** http://www.ietf.org/mail-archive/web/pce/current/msg03007.html**]. * * * *Thanks! * * * *Dhruv* * * --14dae934117745403a04d94f2783 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Ina,

Thanks for your reply, find the= response inline, also I have a few comments on -03 version of the draft wh= ich is at the end of this mail.

Dhruv=A0


On Sat, Mar 23, 2013 at 5:40 AM, Ina Min= ei <ina@juniper.net> wrote:

Dhruv,

Thank you for the review. Please see answers inline below ###.

Ina

From: pce-bounces@ietf.org [mailto:pce-bo= unces@ietf.org] On Behalf Of Dhruv Dhody

=A0

Hi,

Please find the review comments for this draft (there is some overlap wi= th comments from Jon, Cyril etc)

Major Comments:

(1) State synchronisation: =A0

a. PCE should determine the synchronisation is over as soon as possible,= as updates, request etc are blocked during synchronisation. Maybe the last= report message can have SYNC=3D0 (similar to F - fragmentation bit in RP o= bject) or as Jon suggested an empty report but then the RBNF of PCRpt should support it.=A0=

### Please see version 03 of the draft.

=A0

b. I also dont like the use of word 'purge' with respect to old = or stale entries during PCEP session up/down. A mechanism to mark LSP entri= es as stale and waiting for them to be refreshed after session up and delet= ed (or 'purged') only after some timer expiry.

### Please see version 03 of the draft.

=A0

=A0

(2) The PCRpt Message:

<state-report> ::=3D <LSP>[<path-list>]=A0Where:=A0<path-list>::=3D<path>[<path-list>]. Is this to specif= y primary and backup? In which case the status of the paths needs to report= ed=A0separately=A0in case of standby but we have only one LSP object here to specify the operational status. Also LSP-= ID of primary and backup would be different.=A0

=A0

Also applicable to PCUpd message.=A0

I feel the backup path should be updated and reported=A0separately= =A0with each having there own encoding for LSP object.=A0<= /u>

### Clarification on backup paths will be done in the prot= ection doc. I agree with you the text needs to be cleaned up in the base sp= ec, will do so in 04.

=A0

(3) Node Identifier TLV

PCC may use address that survives the session restart (Loopback, M= PLS LSR-ID etc), i suggest we mention this in the document and provide guid= ance to implementers to do this if possible.=A0

### the node-id (now renamed to predundancy-group-id) will= be further clarified in version 04

=A0

(4) LSP Object:=A0

a. What is relationship between the LSP-ID in LSP object and the L= SP-ID in LSP Identifier TLVs?

### The lsp-id in the lsp object was renamed to plsp-id to= avoid such confusion.

[DD]: Rename is good, but i hope relationsh= ip between the PLSP-ID and the LSP-ID (signalled by RSVP) can be explicitly= mentioned. This should especially be clarified in the case of MBB.=A0

=A0=A0

b. There is no=A0mechanism=A0to report the 'pending' state= right now? O-Bit as zero will mean down, not pending.=A0<= /u>

### The O-bit will be revisited in = version 04.

=A0

(5) Make-Before-Break:=A0

There is a need to clarify how MBB is achieved, what is the LSP-ID in ca= se of updates and reports?=A0

### Please see version 03.

=A0

=A0

Minor Comments:=A0

(1) Abstract/Introduction

There is a consistent use of phrase "between and across PCEP sessio= ns". Can you clarify?=A0

### LSPs may move from one PCE to another.

=A0

(2) Re-look the terminology section as some terms are no longer in the d= ocument.=A0

### Could you send the correction?

=A0

(3) LSP Protection=A0

In case of delegated PCE, the desired protection may also be configured = at PCC and the active stateful PCE should support it, the stateful PCE havi= ng full control over the protection / restoration settings can only be achi= eved with instantiation capability and should be out of scope from this document.=A0=

### The whole discussion on protection belongs in a separa= te document.

=A0

(4)=A0Delegation

a. The wording "an LSP may be delegated to one or more PCEs." = .. this is incorrect, from the reading it looks as if this is happening at = the same time.=A0

### To a single PCE, text is clarified in 03.

=A0

b. Active stateful PCE LSP Update (sec 5.6.2)

OLD:

A PCC=A0may choose to compress LSP State Updates to only reflect the mos= t up=A0to date state, as discussed in the previous section.=A0

NEW:

A PCC=A0may choose to compress LSP State Reports to only reflect the mos= t up=A0to date state, as discussed in the previous section.=A0

### Actually, I think we mean updat= es, not reports (if receiving multiple updates, may choose to do state comp= ression during processing)

=A0

=
[DD]: Okay I understand, it mean that PCC i= s only taking the latest Update into consideration; now i am wondering can = PCC choose to compress reports and send the most upto date report? (skip se= nding pending if not yet send; or in case of multiple up-down only send the= latest state) =A0=A0

(5) Symbolic Path Name TLV

The length of this TLV must be greater then 0 as well as multiple of fou= r.=A0

### I think this is not necessary to specify in words, the= figure should be sufficient.

[DD]: In most cases yes,= but this is a case of variable length we must make sure extra padding is a= dded and the TLV is aligned. You can take your cue from other RFC where var= iable length TLV exists say RFC4920; RFC6001 etc =A0

=A0

(6) LSP state DB version TLV (page 40, para 2)

"Since a PCE does not send LSP updates to a PCC, a PCC should never= encounter this TLV".=A0LSP updates here can be easily confused with t= he PCUpd messages. Kindly reword this.=A0

### Will do.

=A0

Regards,

Dhruv



<= /div>
Few more comments on the -03 version:= =A0

(1) Section 5.5.2 (Revocation of delegated LSP)
<= div>
When a PCC revokes a delegated LSP, PCC immediately clears the LSP= state received from this PCE. But we should apply Make-Before-Break here a= s well, that is while the PCC delegates to another PCE or keep the LSP with= itself, the LSP should not be teardown immediately. =A0=A0

(2) Modification of Tunnel configuration at PCC for a deleg= ated LSP.=A0

Incase of manual config change (say b= andwidth, priority) at PCC, how the new LSP parameters to be reported to th= e PCE (maybe a=A0separate=A0delegation request with new PLSP-ID)=A0eventual= ly=A0make-before-break should be=A0applied=A0here as well. When the text fo= r MBB is added in=A0detail, this could also be considered.=A0

(3) Section 6.1 (The PCRpt Message)
<= div style>

Thanks!=A0

Dhr= uv
=A0


--14dae934117745403a04d94f2783-- From adrian@olddog.co.uk Tue Apr 2 05:01:57 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3CE21F97D1 for ; Tue, 2 Apr 2013 05:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJuRFO3p9Vi9 for ; Tue, 2 Apr 2013 05:01:56 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 6D00221F97CD for ; Tue, 2 Apr 2013 05:01:56 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r32C1stZ027832; Tue, 2 Apr 2013 13:01:54 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r32C1sAI027820 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 2 Apr 2013 13:01:54 +0100 From: "Adrian Farrel" To: Date: Tue, 2 Apr 2013 13:01:55 +0100 Message-ID: <036101ce2f99$df19b9f0$9d4d2dd0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4vmdpaOwP2n4Z9Q12FBCbVp+NA2A== Content-Language: en-gb Cc: pce-chairs@tools.ietf.org Subject: [Pce] Recharter text X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 12:01:57 -0000 Hi working group, In Orlando you discussed a paragraph for a charter revision. The work doesn't stop there! In order to officially recharter I need to have the agreed text sent to me as a formal request by the chairs, and I need to see that the WG has consensus behind the text. Thanks, Adrian From ietf-ipr@ietf.org Tue Apr 2 08:54:44 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7A521F8CA0; Tue, 2 Apr 2013 08:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.237 X-Spam-Level: X-Spam-Status: No, score=-102.237 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfzzxzPy3JYA; Tue, 2 Apr 2013 08:54:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A1F4B21F8A68; Tue, 2 Apr 2013 08:54:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: edc@google.com, jmedved@cisco.com, robert.varga@pantheon.sk, ina@juniper.net X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130402155443.10230.4933.idtracker@ietfa.amsl.com> Date: Tue, 02 Apr 2013 08:54:43 -0700 X-Mailman-Approved-At: Tue, 02 Apr 2013 09:00:09 -0700 Cc: jpv@cisco.com, pce@ietf.org, ipr-announce@ietf.org Subject: [Pce] IPR Disclosure: Juniper's Statement of IPR related to draft-ietf-pce-stateful-pce-03 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 15:54:44 -0000 Dear Edward Crabbe, Jan Medved, Robert Varga, Ina Minei: An IPR disclosure that pertains to your Internet-Draft entitled "PCEP Extensions for Stateful PCE" (draft-ietf-pce-stateful-pce) was submitted to= the IETF Secretariat on 2013-04-01 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2046/). The title of the IPR disclosure is "Juniper's Statement of IPR related to draft-ietf-pce-stateful-pce-03.""); The IETF Secretariat From internet-drafts@ietf.org Tue Apr 2 09:34:12 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0F2921F8B9C; Tue, 2 Apr 2013 09:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fu-L4QS4wwFM; Tue, 2 Apr 2013 09:34:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B00021F8AD5; Tue, 2 Apr 2013 09:34:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130402163412.23366.37485.idtracker@ietfa.amsl.com> Date: Tue, 02 Apr 2013 09:34:12 -0700 Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-wson-rwa-ext-00.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 16:34:12 -0000 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 Assignment Author(s) : Young Lee Ramon Casellas Filename : draft-ietf-pce-wson-rwa-ext-00.txt Pages : 22 Date : 2013-03-26 Abstract: This draft 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: http://tools.ietf.org/html/draft-ietf-pce-wson-rwa-ext-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From daniel@olddog.co.uk Tue Apr 2 12:43:25 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF7421F8D45 for ; Tue, 2 Apr 2013 12:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6ESB-1xHPE1 for ; Tue, 2 Apr 2013 12:43:24 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB4621F8D23 for ; Tue, 2 Apr 2013 12:43:24 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r32JhNWo027276 for ; Tue, 2 Apr 2013 20:43:23 +0100 Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r32JhKE0027254 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 2 Apr 2013 20:43:22 +0100 From: "Daniel King" To: Date: Tue, 2 Apr 2013 20:43:16 +0100 Message-ID: <037101ce2fda$53af5aa0$fb0e0fe0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0372_01CE2FE2.B57485F0" X-Mailer: Microsoft Outlook 15.0 Content-Language: en-gb Thread-Index: Ac4v2fZSNET9vjyqTEqdlkXgUncnyw== Subject: [Pce] Inter-domain P2MP PCEP Extensions X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 19:43:25 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0372_01CE2FE2.B57485F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi PCE WG, As mentioned at IETF86 in Orlando, the authors of the inter-domain P2MP extensions for PCEP have slimmed down the document significantly and we would appreciate (especially vendor) feedback on the document as we prepare for Last Call. The draft can be found at the URL below: http://tools.ietf.org/html/draft-ietf-pce-pcep-inter-domain-p2mp-procedures- 03 The key review questions might be: 1. Does the document make sense (scope, requirements and general readability)? 2. Is there adequate detail for implementation? 3. Did we miss any impact on existing PCEP function? 4. Suitable manageability considerations? 5. Missing any obvious or useful references? Br, Dan. ------=_NextPart_000_0372_01CE2FE2.B57485F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi PCE WG,

 

As mentioned = at IETF86 in Orlando, the authors of the inter-domain P2MP extensions = for PCEP have slimmed down the document significantly and we would = appreciate (especially vendor) feedback on the document as we prepare = for Last Call. The draft can be found at the URL below:

 

http://tools.ietf.org/html/draft-ietf-pce-pcep-inter-domai= n-p2mp-procedures-03

 

The key = review questions might be:

 

1. Does the = document make sense (scope, requirements and general = readability)?

 

2. Is there adequate detail for implementation? =  

 

3. Did we miss any impact on existing PCEP = function?

 

4. Suitable manageability = considerations?

 

5. Missing = any obvious or useful references?

 

Br, Dan. =

------=_NextPart_000_0372_01CE2FE2.B57485F0-- From ina@juniper.net Wed Apr 3 09:15:30 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0ECA21F8E72 for ; Wed, 3 Apr 2013 09:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.867 X-Spam-Level: X-Spam-Status: No, score=-2.867 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yx516J6kO4DG for ; Wed, 3 Apr 2013 09:15:30 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5D221F8E6D for ; Wed, 3 Apr 2013 09:15:30 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKUVxVofbdhZ1MsKlgjnq5vt0pN7EM2Xjy@postini.com; Wed, 03 Apr 2013 09:15:30 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 3 Apr 2013 09:09:50 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Wed, 3 Apr 2013 09:09:50 -0700 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.186) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 3 Apr 2013 09:18:54 -0700 Received: from mail154-co1-R.bigfish.com (10.243.78.249) by CO1EHSOBE030.bigfish.com (10.243.66.95) with Microsoft SMTP Server id 14.1.225.23; Wed, 3 Apr 2013 16:09:49 +0000 Received: from mail154-co1 (localhost [127.0.0.1]) by mail154-co1-R.bigfish.com (Postfix) with ESMTP id D4E51C6008D for ; Wed, 3 Apr 2013 16:09:49 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.232.213; KIP:(null); UIP:(null); (null); H:BLUPRD0511HT003.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -22 X-BigFish: PS-22(zz9371I542Izz1f42h1fc6h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1155h) Received: from mail154-co1 (localhost.localdomain [127.0.0.1]) by mail154-co1 (MessageSwitch) id 1365005342297158_11535; Wed, 3 Apr 2013 16:09:02 +0000 (UTC) Received: from CO1EHSMHS021.bigfish.com (unknown [10.243.78.232]) by mail154-co1.bigfish.com (Postfix) with ESMTP id 02DAC2008B; Wed, 3 Apr 2013 16:08:53 +0000 (UTC) Received: from BLUPRD0511HT003.namprd05.prod.outlook.com (157.56.232.213) by CO1EHSMHS021.bigfish.com (10.243.66.31) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 3 Apr 2013 16:08:51 +0000 Received: from BLUPRD0511MB436.namprd05.prod.outlook.com ([169.254.4.213]) by BLUPRD0511HT003.namprd05.prod.outlook.com ([10.255.135.166]) with mapi id 14.16.0287.008; Wed, 3 Apr 2013 16:08:49 +0000 From: Ina Minei To: "Jan Medved (jmedved)" , "pce@ietf.org" Thread-Topic: [Pce] Stateful PCE Capability discovery draft: request for review & adoption as a WG document Thread-Index: AQHOKz1BnZucrDdgSkKBBfjQIKzyOJjEs9Ow Date: Wed, 3 Apr 2013 16:08:45 +0000 Message-ID: <70BDAD02381BA54CA31315A2A26A7AD30374F8FF@BLUPRD0511MB436.namprd05.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: Re: [Pce] Stateful PCE Capability discovery draft: request for review & adoption as a WG document X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 16:15:30 -0000 This is useful and straightforward functionality that is much needed for a = deployment and completes the solution. I support this draft's adoption as a WG document (but I guess we will wait = for the chairs to send the official poll, right?) Ina=20 -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Jan M= edved (jmedved) Sent: Wednesday, March 27, 2013 3:49 PM To: pce@ietf.org Subject: [Pce] Stateful PCE Capability discovery draft: request for review = & adoption as a WG document Dear PCE'rs, can you please review draft-sivabalan-pce-disco-stateful and send your comm= ents to the list? The draft is at: http://datatracker.ietf.org/doc/draft-si= vabalan-pce-disco-stateful/. Also, can you please let us know if you are in favor/opposed to adopting dr= aft-sivabalan-pce-disco-stateful as a PCE WG document?=20 Thanks a lot in advance, Siva and Jan _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From dhruv.ietf@gmail.com Wed Apr 3 09:53:37 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4CC21F8EE3 for ; Wed, 3 Apr 2013 09:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.369 X-Spam-Level: X-Spam-Status: No, score=-1.369 tagged_above=-999 required=5 tests=[AWL=-1.230, BAYES_20=-0.74, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gw9SD8Ua7YZ8 for ; Wed, 3 Apr 2013 09:53:36 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id E8C3721F8F63 for ; Wed, 3 Apr 2013 09:53:35 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id a11so1897470iee.39 for ; Wed, 03 Apr 2013 09:53:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:x-google-sender-delegation :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=sEHd6AxN8QWpugw3XJNi07BY8iIOajBxXGzXjem3UcM=; b=DcrmesRZLfD+ygHfFKdXGlmv78c3gC81fSe9a8MmSlYEHQNEbvLST8vAwoYcFqB2q6 PCkFs1E3ZLtqXnrHcIpk7H4pB6NEn4H+cgPqFVjuemXtpAmlkO0KTvWYtB6F/8tRkkT6 /uMA10b3z4KckHW2aZtX4v+5ogsb6jTgN7U7lW/+jLraFQ+ivEkcfqwhm699Gb+78BmK VK+b2OBJhJ3odjhLBgqouRQ827ke6gA7kFylaq8WYJfqV5a2Na+UIBn0kFP61Wc6trJa /ps8HoGsBtNydCrvjHi1X1Dj1UaGKHaOCBk8V/daVUVHD3AMcmbfT+6RyBzxCgTGHsh0 PgUw== MIME-Version: 1.0 X-Received: by 10.50.208.68 with SMTP id mc4mr1588648igc.35.1365008010522; Wed, 03 Apr 2013 09:53:30 -0700 (PDT) Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.217.162 with HTTP; Wed, 3 Apr 2013 09:53:30 -0700 (PDT) In-Reply-To: <70BDAD02381BA54CA31315A2A26A7AD30374F8FF@BLUPRD0511MB436.namprd05.prod.outlook.com> References: <70BDAD02381BA54CA31315A2A26A7AD30374F8FF@BLUPRD0511MB436.namprd05.prod.outlook.com> Date: Wed, 3 Apr 2013 22:23:30 +0530 X-Google-Sender-Auth: s7I8gFC_ALP3AxWKnEZqCNJjFno Message-ID: From: Dhruv Dhody To: Ina Minei Content-Type: multipart/alternative; boundary=14dae93408e79534ca04d977b15f Cc: "pce@ietf.org" Subject: Re: [Pce] Stateful PCE Capability discovery draft: request for review & adoption as a WG document X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 16:53:37 -0000 --14dae93408e79534ca04d977b15f Content-Type: text/plain; charset=ISO-8859-1 Hi, I agree that, it is a needed functionality. *Question on Process - * Does this belong in a separate ID or better suited in the * ietf-pce-stateful-pce* as before? I am taking cue from other RFC that added new capability like RFC6006. *Few comments - * (1) Bit 9, 10 are already used 9Global Concurrent Optimization (GCO)[RFC5557 ]10P2MP path computation[RFC6006 ](2) Since both PCEP open message and IGP PCE discovery can be used to notify PCE stateful nature, some text should be added to handle it, For ex how should the implementation behave if there is a difference in the capability between what PCC learned via IGP flooding and open message? (3) BGP-LS A PCC could listen to IGP updates, or use other mechanisms that carry IGP information to interested clients, such as BGP-LS ([I-D.ietf-idr-ls-distribution]). Can BGP-LS be used to advertise PCE? As far as i remember it allow the TE information to be carried in BGP and not PCE Discovery TLVs? Jan: Since you are the author of BGP-LS, maybe you can clarify. Dhruv On Wed, Apr 3, 2013 at 9:38 PM, Ina Minei wrote: > This is useful and straightforward functionality that is much needed for a > deployment and completes the solution. > > I support this draft's adoption as a WG document (but I guess we will wait > for the chairs to send the official poll, right?) > > Ina > > -----Original Message----- > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Jan > Medved (jmedved) > Sent: Wednesday, March 27, 2013 3:49 PM > To: pce@ietf.org > Subject: [Pce] Stateful PCE Capability discovery draft: request for review > & adoption as a WG document > > Dear PCE'rs, > > can you please review draft-sivabalan-pce-disco-stateful and send your > comments to the list? The draft is at: > http://datatracker.ietf.org/doc/draft-sivabalan-pce-disco-stateful/. > > Also, can you please let us know if you are in favor/opposed to adopting > draft-sivabalan-pce-disco-stateful as a PCE WG document? > > > > Thanks a lot in advance, > Siva and Jan > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > --14dae93408e79534ca04d977b15f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
I agree that, it is a needed func= tionality.=A0

Question on Process -=A0<= /u>
Does= this belong in a=A0separate=A0ID or better suited in the=A0ietf-pce-sta= teful-pce as before?=A0
I am = taking cue from other RFC that added new capability like RFC6006.=A0=

Few comments -=A0<= br>
(1) Bit 9, 10 are already used =A0
=
9 Global Concurrent Optimizatio= n (GCO)[RFC5557]
10 P2MP path computation<= /td>[RFC6006]
(2) Sinc= e both PCEP open message and IGP PCE discovery can be used to notify PCE st= ateful nature, some text should be added to handle it, For ex how should th= e implementation behave if there is a difference in the capability between = what PCC learned via =A0IGP flooding and open message?=A0

(= 3) BGP-LS=A0
= =A0 =A0A PCC could listen to IGP updates, or use other mechanisms that carr= y
   IGP information=
 to interested clients, such as BGP-LS
   ([I-D.ietf-idr-ls-distribution]).
Can BGP-LS be used to advertise PCE? As far as =
i remember it allow the TE information to be carried in BGP and not PCE Dis=
covery TLVs? 
Jan: Since you are the author of BGP-LS, maybe you can clarify.

Dhruv<=
/font>



On Wed,= Apr 3, 2013 at 9:38 PM, Ina Minei <ina@juniper.net> wrote:
This is useful and straightforward functionality that is much needed for a = deployment and completes the solution.

I support this draft's adoption as a WG document (but I guess we will w= ait for the chairs to send the official poll, right?)

Ina

-----Original Message-----
From: pce-bounces@ietf.org [mai= lto:pce-bounces@ietf.org] On Be= half Of Jan Medved (jmedved)
Sent: Wednesday, March 27, 2013 3:49 PM
To: pce@ietf.org
Subject: [Pce] Stateful PCE Capability discovery draft: request for review = & adoption as a WG document

Dear PCE'rs,

can you please review draft-sivabalan-pce-disco-stateful and send your comm= ents to the list? The draft is at: http://datatracke= r.ietf.org/doc/draft-sivabalan-pce-disco-stateful/.

Also, can you please let us know if you are in favor/opposed to adopting dr= aft-sivabalan-pce-disco-stateful as a PCE WG document?



Thanks a lot in advance,
Siva and Jan
_______________________________________________
Pce mailing list
Pce@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/pce


_______________________________________________
Pce mailing list
Pce@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/pce

--14dae93408e79534ca04d977b15f-- From zali@cisco.com Wed Apr 3 10:30:18 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 714C721F8A85 for ; Wed, 3 Apr 2013 10:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kC4bR5Sq8yFa for ; Wed, 3 Apr 2013 10:30:17 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id AA39821F8A18 for ; Wed, 3 Apr 2013 10:30:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1591; q=dns/txt; s=iport; t=1365010217; x=1366219817; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=jB47jicqOS61CnKzeaeiLJcs73Stuzh4Drkfju5EE8k=; b=CQwenwoE55iANEYE8AN0KJUaTwzFDKRTArsF1y7hAyGGO2/g9SRsnsPT cbcAxZMfzEsFoiEA7twcQ6bAtazN7/TstY7nvT4xhqs1M0rCc7HoAVRvj gqJ9RD6zJVeuqOGkcO5i1j9bhlVpQWn9AfycrIlv343rNM4FokOLpW7QZ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai4FAH1mXFGtJV2a/2dsb2JhbABDgwc2wEWBDBZ0gh8BAQEEAQEBaxcGAQgRAwEBAQsdLgsUCQgCBAESCBOHeQzASo5oOAaCWWEDmAqPbIFVgTaCKA X-IronPort-AV: E=Sophos;i="4.87,402,1363132800"; d="scan'208";a="194690721" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 03 Apr 2013 17:30:17 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r33HUGeb019946 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Apr 2013 17:30:16 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.51]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Wed, 3 Apr 2013 12:30:16 -0500 From: "Zafar Ali (zali)" To: Ina Minei , "Jan Medved (jmedved)" , "pce@ietf.org" Thread-Topic: [Pce] Stateful PCE Capability discovery draft: request for review & adoption as a WG document Thread-Index: AQHOKz1BnZucrDdgSkKBBfjQIKzyOJjEs9OwgAAoQAA= Date: Wed, 3 Apr 2013 17:30:16 +0000 Message-ID: In-Reply-To: <70BDAD02381BA54CA31315A2A26A7AD30374F8FF@BLUPRD0511MB436.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.86.252.193] Content-Type: text/plain; charset="Windows-1252" Content-ID: <3CF4D17AE45D7C418B618C017CFF7908@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Pce] Stateful PCE Capability discovery draft: request for review & adoption as a WG document X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 17:30:18 -0000 Hi-=20 I agree. Indeed a much needed draft. Thanks Regards =8A Zafar -----Original Message----- From: Ina Minei Date: Wednesday, April 3, 2013 12:08 PM To: "Jan Medved (jmedved)" , "pce@ietf.org" Subject: Re: [Pce] Stateful PCE Capability discovery draft: request for review & adoption as a WG document >This is useful and straightforward functionality that is much needed for >a deployment and completes the solution. > >I support this draft's adoption as a WG document (but I guess we will >wait for the chairs to send the official poll, right?) > >Ina=20 > >-----Original Message----- >From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Jan >Medved (jmedved) >Sent: Wednesday, March 27, 2013 3:49 PM >To: pce@ietf.org >Subject: [Pce] Stateful PCE Capability discovery draft: request for >review & adoption as a WG document > >Dear PCE'rs, > >can you please review draft-sivabalan-pce-disco-stateful and send your >comments to the list? The draft is at: >http://datatracker.ietf.org/doc/draft-sivabalan-pce-disco-stateful/. > >Also, can you please let us know if you are in favor/opposed to adopting >draft-sivabalan-pce-disco-stateful as a PCE WG document? > > > >Thanks a lot in advance, >Siva and Jan >_______________________________________________ >Pce mailing list >Pce@ietf.org >https://www.ietf.org/mailman/listinfo/pce > > >_______________________________________________ >Pce mailing list >Pce@ietf.org >https://www.ietf.org/mailman/listinfo/pce From edc@google.com Wed Apr 3 10:36:24 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55DD321F8CD2 for ; Wed, 3 Apr 2013 10:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.177 X-Spam-Level: X-Spam-Status: No, score=-102.177 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aANZPudubLUP for ; Wed, 3 Apr 2013 10:36:23 -0700 (PDT) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id EBF9721F8CCB for ; Wed, 3 Apr 2013 10:36:22 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id l18so1838424wgh.13 for ; Wed, 03 Apr 2013 10:36:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=iB+vApmIdCf+kW51iVEJCdzLrFoldRmHMYWyIS/cqfc=; b=Wc0INAfLKncSIwoQ8ZL8zlRwiE9w6IoLmbIrTH4XQ2KG3+4EwsSvw6aGSUl1K5ulkN Vc8vileLbtopIlD3NGWAudSOV9jMa9NnLI53o+R+MWDBAZm+iH8aTSIdUOIbMJ2u//nk 816IBMG/Dzi+sciRp1zJ6dO8rdSW/PQMgGITXOTZOd7fcI1ybAhSd6h833w3fQ0DodtO mO2WHW0lJuvWsLboNgBGdp2LmwggpIReipiie9UU+bZJ2NRtte7j8G1QbLmGxyhBCekg Y4MJz7MgsstAohpaRDUZe5GZCXyWHZqJxxgurHLM5SHgGcwvmqicTK+Sm77OD2vbGhfv GYNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=iB+vApmIdCf+kW51iVEJCdzLrFoldRmHMYWyIS/cqfc=; b=TNLHeCRT1fPANVuCkGUd+XJlVDSqbGMzPNBsze4VVX1uYXUv8hpzKISoGDe/SxTi9t q0r2WzfLKYAxr1RL6B/BmaZWzZQEltZjlECLrPhQbu/Q1sBvL+VUNnQjlAo8di8NGeYp Vv6JUGjny2RjavFGnUI3ysUSs6foIQf80RCct1VCRG3EgSlUH6GnUnyxLLRvFI8HbFBt IJ8v6oaeW5BizCocheFVzpwA/nNkb6TGSULEtupq9ZDel9cgWzcTCPulV4uj4MLsjgO0 E2IGk6VIbcBbZYBjK4AZ931lcsJp06NksdGmJK9KTv/OAs2pfn/vB5v9iuB3mb2Z5j+Q Ingg== X-Received: by 10.180.91.106 with SMTP id cd10mr4225358wib.6.1365010581850; Wed, 03 Apr 2013 10:36:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.21.8 with HTTP; Wed, 3 Apr 2013 10:35:41 -0700 (PDT) In-Reply-To: <70BDAD02381BA54CA31315A2A26A7AD30374F8FF@BLUPRD0511MB436.namprd05.prod.outlook.com> References: <70BDAD02381BA54CA31315A2A26A7AD30374F8FF@BLUPRD0511MB436.namprd05.prod.outlook.com> From: Edward Crabbe Date: Wed, 3 Apr 2013 10:35:41 -0700 Message-ID: To: Ina Minei Content-Type: multipart/alternative; boundary=f46d043be11ad8adba04d9784abf X-Gm-Message-State: ALoCoQneqf1rcbSt0bXft9hxMU1u1IlNIEQRszCB0uM7GjoKdxJWZGxQEZvAkwirxOFrl1Zq28RZhEj/hL9C0HXsrBLlfSEcXi0QiZwo7MweVM+3CR143YYwNefCYPjnzTkRAIOHY5Oofo5jz7//jeY6KzuiExDQXFFzu4IdObs8Gh7v5k8ioqkgCYdJUCbU3IKZM40hp9+e Cc: "pce@ietf.org" Subject: Re: [Pce] Stateful PCE Capability discovery draft: request for review & adoption as a WG document X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 17:36:24 -0000 --f46d043be11ad8adba04d9784abf Content-Type: text/plain; charset=ISO-8859-1 Ditto: I support this draft's adoption as a WG document. On Wed, Apr 3, 2013 at 9:08 AM, Ina Minei wrote: > This is useful and straightforward functionality that is much needed for a > deployment and completes the solution. > > I support this draft's adoption as a WG document (but I guess we will wait > for the chairs to send the official poll, right?) > > Ina > > -----Original Message----- > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Jan > Medved (jmedved) > Sent: Wednesday, March 27, 2013 3:49 PM > To: pce@ietf.org > Subject: [Pce] Stateful PCE Capability discovery draft: request for review > & adoption as a WG document > > Dear PCE'rs, > > can you please review draft-sivabalan-pce-disco-stateful and send your > comments to the list? The draft is at: > http://datatracker.ietf.org/doc/draft-sivabalan-pce-disco-stateful/. > > Also, can you please let us know if you are in favor/opposed to adopting > draft-sivabalan-pce-disco-stateful as a PCE WG document? > > > > Thanks a lot in advance, > Siva and Jan > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > --f46d043be11ad8adba04d9784abf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Ditto: I support this draft's adoption as a WG documen= t.=A0


On Wed, = Apr 3, 2013 at 9:08 AM, Ina Minei <ina@juniper.net> wrote:
This is useful and straightforward functiona= lity that is much needed for a deployment and completes the solution.

I support this draft's adoption as a WG document (but I guess we will w= ait for the chairs to send the official poll, right?)

Ina

-----Original Message-----
From: pce-bounces= @ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Jan Medved (jmedved)
Sent: Wednesday, March 27, 2013 3:49 PM
To: pce@ietf.org
Subject: [Pce] Stateful PCE Capability discovery draft: request for review = & adoption as a WG document

Dear PCE'rs,

can you please review draft-sivabalan-pce-disco-stateful and send your comm= ents to the list? The draft is at: http://datatracke= r.ietf.org/doc/draft-sivabalan-pce-disco-stateful/.

Also, can you please let us know if you are in favor/opposed to adopting dr= aft-sivabalan-pce-disco-stateful as a PCE WG document?



Thanks a lot in advance,
Siva and Jan
_______________________________________________
Pce mailing list
Pce@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/pce


_______________________________________________
Pce mailing list
Pce@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/pce

--f46d043be11ad8adba04d9784abf-- From ina@juniper.net Wed Apr 3 10:11:02 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A78E21F8F8A; Wed, 3 Apr 2013 10:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.167 X-Spam-Level: X-Spam-Status: No, score=-3.167 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fifqjdmq29Xa; Wed, 3 Apr 2013 10:11:01 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id CB0D821F8F7A; Wed, 3 Apr 2013 10:10:58 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKUVxioh8/LCq2IZoCuvz5uvNYooREZexb@postini.com; Wed, 03 Apr 2013 10:10:58 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 3 Apr 2013 10:04:54 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Wed, 3 Apr 2013 10:04:54 -0700 Received: from va3outboundpool.messaging.microsoft.com (216.32.180.12) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 3 Apr 2013 10:07:39 -0700 Received: from mail129-va3-R.bigfish.com (10.7.14.231) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.23; Wed, 3 Apr 2013 17:04:52 +0000 Received: from mail129-va3 (localhost [127.0.0.1]) by mail129-va3-R.bigfish.com (Postfix) with ESMTP id 4E0671E0141; Wed, 3 Apr 2013 17:04:52 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.232.213; KIP:(null); UIP:(null); (null); H:BLUPRD0511HT005.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -23 X-BigFish: PS-23(zz9371Ic89bh936eI542Izz1f42h1fc6h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL8275dhz2dh2a8h668h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1155h) Received: from mail129-va3 (localhost.localdomain [127.0.0.1]) by mail129-va3 (MessageSwitch) id 1365008690717634_17956; Wed, 3 Apr 2013 17:04:50 +0000 (UTC) Received: from VA3EHSMHS023.bigfish.com (unknown [10.7.14.229]) by mail129-va3.bigfish.com (Postfix) with ESMTP id 9DF214C0078; Wed, 3 Apr 2013 17:04:50 +0000 (UTC) Received: from BLUPRD0511HT005.namprd05.prod.outlook.com (157.56.232.213) by VA3EHSMHS023.bigfish.com (10.7.99.33) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 3 Apr 2013 17:04:48 +0000 Received: from BLUPRD0511MB436.namprd05.prod.outlook.com ([169.254.4.213]) by BLUPRD0511HT005.namprd05.prod.outlook.com ([10.255.135.168]) with mapi id 14.16.0287.008; Wed, 3 Apr 2013 17:04:47 +0000 From: Ina Minei To: IETF Secretariat , "edc@google.com" , "jmedved@cisco.com" , "robert.varga@pantheon.sk" Thread-Topic: IPR Disclosure: Juniper's Statement of IPR related to draft-ietf-pce-stateful-pce-03 Thread-Index: AQHOL7qAWeMC58eSdEmK2SilPgmyrZjEtSxw Date: Wed, 3 Apr 2013 17:04:47 +0000 Message-ID: <70BDAD02381BA54CA31315A2A26A7AD30374F9C8@BLUPRD0511MB436.namprd05.prod.outlook.com> References: <20130402155443.10230.4933.idtracker@ietfa.amsl.com> In-Reply-To: <20130402155443.10230.4933.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.51] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%GOOGLE.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%PANTHEON.SK$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%OLDDOG.CO.UK$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%ORANGE.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-Mailman-Approved-At: Wed, 03 Apr 2013 11:37:00 -0700 Cc: "jpv@cisco.com" , "pce@ietf.org" , "ipr-announce@ietf.org" Subject: Re: [Pce] IPR Disclosure: Juniper's Statement of IPR related to draft-ietf-pce-stateful-pce-03 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 17:11:02 -0000 VGhpcyBlbWFpbMKgIGlzIHJlZ2FyZGluZyB0aGUgc3RhdGVtZW50IG9mIElQUiBzdWJtaXR0ZWQg YnkgSnVuaXBlciByZWdhcmRpbmcgZHJhZnQtaWV0Zi1wY2Utc3RhdGVmdWwtcGNlLTAzIGFuZCBk cmFmdC1jcmFiYmUtcGNlLXN0YXRlZnVsLXBjZS1tcGxzLXRlLTAwLiDCoEFzIG1vc3Qgb2YgeW91 IHdobyBoYXZlIGJlZW4gdHJhY2tpbmcgdGhpcyB3b3JrIGtub3csIMKgdGhlc2UgdHdvIGRyYWZ0 cyB0b2dldGhlciBjb3ZlciB0aGUgZnVuY3Rpb25hbGl0eSBvcmlnaW5hbGx5wqAgcHVibGlzaGVk IGFzIGRyYWZ0LWNyYWJiZS1wY2Utc3RhdGVmdWwtcGNlLTAwLg0KwqANCkR1ZSB0byBhbiBhZG1p bmlzdHJhdGl2ZSBlcnJvciwgdGhlIElQUiBzdGF0ZW1lbnQgd2FzIG5vdCBzdWJtaXR0ZWQgdG8g dGhlIElFVEbCoGluIE9jdG9iZXIgMjAxMSBhdCB0aGUgdGltZSBvZiB0aGUgcHVibGljYXRpb24g b2YgdmVyc2lvbiAwMCBvZiB0aGUgZHJhZnQsIGFuZCB0aGlzIGlzIGJlaW5nIHJlY3RpZmllZCBi eSB0aGUgSVBSIGRpc2Nsb3N1cmUgbm93LiANCsKgDQpUaGUgcHJvYmxlbSBoYXBwZW5lZCBkdWUg dG8gYW4gdW5mb3J0dW5hdGUgY29tYmluYXRpb24gb2YgYW4gYWRtaW5pc3RyYXRpdmUgZXJyb3Ig YW5kIHRoZSDCoGNoYW5nZXMgb2YgYWZmaWxpYXRpb24gb2YgwqB0aGUgdHdvIG9yaWdpbmFsIEp1 bmlwZXIgYXV0aG9ycyBvZiBkcmFmdC1jcmFiYmUtcGNlLXN0YXRlZnVsLXBjZS0wMCBzaG9ydGx5 IGFmdGVyIHRoZSBkcmFmdCBwdWJsaWNhdGlvbi4gDQoNCkJlY2F1c2UgSSB3YXMgbm90IG9uZSBv ZiB0aGUgY28taW52ZW50b3JzIG5vciBhIGNvLWF1dGhvciB1bnRpbCB2ZXJzaW9uIDAyLCBJIGRp ZCBub3QgdHJhY2sgdGhpcy4gSG93ZXZlciwgYXMgYSBjby1hdXRob3Igb24gdGhlIHN0YXRlZnVs IFBDRSB3b3JrLCBJIHdvdWxkIGxpa2UgdG8gYXBvbG9naXplIG9uIGJlaGFsZiBvZiBKdW5pcGVy IGFuZCB3YW50IHRvIGxldCB5b3Uga25vdyB0aGF0IHRoZSBjb21wYW55IGlzIHRha2luZyBzdGVw cyB0byBoZWxwIHByZXZlbnQgc3VjaCBhbiBlcnJvciBmcm9tIHJlLW9jY3VycmluZy4NCg0KSW5h IE1pbmVpDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBJRVRGIFNlY3JldGFy aWF0IFttYWlsdG86aWV0Zi1pcHJAaWV0Zi5vcmddIA0KU2VudDogVHVlc2RheSwgQXByaWwgMDIs IDIwMTMgODo1NSBBTQ0KVG86IGVkY0Bnb29nbGUuY29tOyBqbWVkdmVkQGNpc2NvLmNvbTsgcm9i ZXJ0LnZhcmdhQHBhbnRoZW9uLnNrOyBJbmEgTWluZWkNCkNjOiBzdGJyeWFudEBjaXNjby5jb207 IGFkcmlhbkBvbGRkb2cuY28udWs7IGpwdkBjaXNjby5jb207IGp1bGllbi5tZXVyaWNAb3Jhbmdl LmNvbTsgcGNlQGlldGYub3JnOyBpcHItYW5ub3VuY2VAaWV0Zi5vcmcNClN1YmplY3Q6IElQUiBE aXNjbG9zdXJlOiBKdW5pcGVyJ3MgU3RhdGVtZW50IG9mIElQUiByZWxhdGVkIHRvIGRyYWZ0LWll dGYtcGNlLXN0YXRlZnVsLXBjZS0wMw0KDQoNCkRlYXIgRWR3YXJkIENyYWJiZSwgSmFuIE1lZHZl ZCwgUm9iZXJ0IFZhcmdhLCBJbmEgTWluZWk6DQoNCiBBbiBJUFIgZGlzY2xvc3VyZSB0aGF0IHBl cnRhaW5zIHRvIHlvdXIgSW50ZXJuZXQtRHJhZnQgZW50aXRsZWQgIlBDRVAgRXh0ZW5zaW9ucyBm b3IgU3RhdGVmdWwgUENFIiAoZHJhZnQtaWV0Zi1wY2Utc3RhdGVmdWwtcGNlKSB3YXMgc3VibWl0 dGVkIHRvIHRoZSBJRVRGIFNlY3JldGFyaWF0IG9uIDIwMTMtMDQtMDEgYW5kIGhhcyBiZWVuIHBv c3RlZCBvbiB0aGUgIklFVEYgUGFnZSBvZiBJbnRlbGxlY3R1YWwgUHJvcGVydHkgUmlnaHRzIERp c2Nsb3N1cmVzIg0KKGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByLzIwNDYvKS4gVGhl IHRpdGxlIG9mIHRoZSBJUFIgZGlzY2xvc3VyZSBpcyAiSnVuaXBlcidzIFN0YXRlbWVudCBvZiBJ UFIgcmVsYXRlZCB0byBkcmFmdC1pZXRmLXBjZS1zdGF0ZWZ1bC1wY2UtMDMuIiIpOw0KDQpUaGUg SUVURiBTZWNyZXRhcmlhdA0KDQoNCg== From ina@juniper.net Wed Apr 3 17:07:48 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95F7621F91BF for ; Wed, 3 Apr 2013 17:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.317 X-Spam-Level: X-Spam-Status: No, score=-3.317 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id daC-b+l8NnQ7 for ; Wed, 3 Apr 2013 17:07:44 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 03B0D21F91B8 for ; Wed, 3 Apr 2013 17:07:43 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKUVzET7f/W5QsJuM5/wD5oaVjQ72Qpv55@postini.com; Wed, 03 Apr 2013 17:07:44 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 3 Apr 2013 17:04:10 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Wed, 3 Apr 2013 17:04:09 -0700 Received: from va3outboundpool.messaging.microsoft.com (216.32.180.31) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 3 Apr 2013 17:13:12 -0700 Received: from mail183-va3-R.bigfish.com (10.7.14.238) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.23; Thu, 4 Apr 2013 00:04:08 +0000 Received: from mail183-va3 (localhost [127.0.0.1]) by mail183-va3-R.bigfish.com (Postfix) with ESMTP id B3C13E01E3 for ; Thu, 4 Apr 2013 00:04:08 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.232.213; KIP:(null); UIP:(null); (null); H:BLUPRD0511HT002.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -30 X-BigFish: PS-30(zz98dI9371I1503Mc85fh103dKec9Ndb28izz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz8275ch1033IL17326ah8275dh18c673h8275bh1b8612mz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1155h) Received: from mail183-va3 (localhost.localdomain [127.0.0.1]) by mail183-va3 (MessageSwitch) id 1365033846525660_14959; Thu, 4 Apr 2013 00:04:06 +0000 (UTC) Received: from VA3EHSMHS005.bigfish.com (unknown [10.7.14.246]) by mail183-va3.bigfish.com (Postfix) with ESMTP id 75E5F10007D; Thu, 4 Apr 2013 00:04:06 +0000 (UTC) Received: from BLUPRD0511HT002.namprd05.prod.outlook.com (157.56.232.213) by VA3EHSMHS005.bigfish.com (10.7.99.15) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 4 Apr 2013 00:04:02 +0000 Received: from BLUPRD0511MB436.namprd05.prod.outlook.com ([169.254.4.213]) by BLUPRD0511HT002.namprd05.prod.outlook.com ([10.255.135.165]) with mapi id 14.16.0287.008; Thu, 4 Apr 2013 00:04:02 +0000 From: Ina Minei To: Dhruv Dhody Thread-Topic: [Pce] Comments on draft-ietf-pce-stateful-pce-02 Thread-Index: AQHOHmmisAI383BhpUSpL+pnDbSK9piyXcWAgA9SI4CAA58KUA== Date: Thu, 4 Apr 2013 00:04:01 +0000 Message-ID: <70BDAD02381BA54CA31315A2A26A7AD303751B72@BLUPRD0511MB436.namprd05.prod.outlook.com> References: <70BDAD02381BA54CA31315A2A26A7AD3037352A8@BY2PRD0511MB440.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.51] Content-Type: multipart/alternative; boundary="_000_70BDAD02381BA54CA31315A2A26A7AD303751B72BLUPRD0511MB436_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%GMAIL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "pce@ietf.org" Subject: Re: [Pce] Comments on draft-ietf-pce-stateful-pce-02 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 00:07:48 -0000 --_000_70BDAD02381BA54CA31315A2A26A7AD303751B72BLUPRD0511MB436_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dhruv, Please see inline %%%. From: dhruvdhody@gmail.com [mailto:dhruvdhody@gmail.com] On Behalf Of Dhruv= Dhody Sent: Monday, April 01, 2013 9:32 AM To: Ina Minei Cc: pce@ietf.org Subject: Re: [Pce] Comments on draft-ietf-pce-stateful-pce-02 Hi Ina, Thanks for your reply, find the response inline, also I have a few comments= on -03 version of the draft which is at the end of this mail. Dhruv On Sat, Mar 23, 2013 at 5:40 AM, Ina Minei > wrote: Dhruv, Thank you for the review. Please see answers inline below ###. Ina From: pce-bounces@ietf.org [mailto:pce-bounces= @ietf.org] On Behalf Of Dhruv Dhody Sent: Monday, March 11, 2013 8:03 AM To: pce@ietf.org Subject: [Pce] Comments on draft-ietf-pce-stateful-pce-02 Hi, Please find the review comments for this draft (there is some overlap with = comments from Jon, Cyril etc) Major Comments: (1) State synchronisation: a. PCE should determine the synchronisation is over as soon as possible, as= updates, request etc are blocked during synchronisation. Maybe the last re= port message can have SYNC=3D0 (similar to F - fragmentation bit in RP obje= ct) or as Jon suggested an empty report but then the RBNF of PCRpt should s= upport it. ### Please see version 03 of the draft. b. I also dont like the use of word 'purge' with respect to old or stale en= tries during PCEP session up/down. A mechanism to mark LSP entries as stale= and waiting for them to be refreshed after session up and deleted (or 'pur= ged') only after some timer expiry. ### Please see version 03 of the draft. (2) The PCRpt Message: ::=3D [] Where: ::=3D[]. Is this to specify primary and backup? In which case the status of= the paths needs to reported separately in case of standby but we have only= one LSP object here to specify the operational status. Also LSP-ID of prim= ary and backup would be different. Also applicable to PCUpd message. I feel the backup path should be updated and reported separately with each = having there own encoding for LSP object. ### Clarification on backup paths will be done in the protection doc. I agr= ee with you the text needs to be cleaned up in the base spec, will do so in= 04. (3) Node Identifier TLV PCC may use address that survives the session restart (Loopback, MPLS LSR-I= D etc), i suggest we mention this in the document and provide guidance to i= mplementers to do this if possible. ### the node-id (now renamed to predundancy-group-id) will be further clari= fied in version 04 (4) LSP Object: a. What is relationship between the LSP-ID in LSP object and the LSP-ID in = LSP Identifier TLVs? ### The lsp-id in the lsp object was renamed to plsp-id to avoid such confu= sion. [DD]: Rename is good, but i hope relationship between the PLSP-ID and the L= SP-ID (signalled by RSVP) can be explicitly mentioned. This should especial= ly be clarified in the case of MBB. %%% Could you point to the confusing text in the definition of plsp-id? b. There is no mechanism to report the 'pending' state right now? O-Bit as = zero will mean down, not pending. ### The O-bit will be revisited in version 04. (5) Make-Before-Break: There is a need to clarify how MBB is achieved, what is the LSP-ID in case = of updates and reports? ### Please see version 03. [DD]: The updated text though in the right direction is still missing key i= nformation. I hope the next version clarifies it further. %%% could you please indicate what key information is missing? Minor Comments: (1) Abstract/Introduction There is a consistent use of phrase "between and across PCEP sessions". Can= you clarify? ### LSPs may move from one PCE to another. (2) Re-look the terminology section as some terms are no longer in the docu= ment. ### Could you send the correction? [DD]: Just removal of MPLS TE Global Default Restoration & MPLS TE Global P= ath Protection should do the trick. Both terms are no longer used in this d= ocument. (3) LSP Protection In case of delegated PCE, the desired protection may also be configured at = PCC and the active stateful PCE should support it, the stateful PCE having = full control over the protection / restoration settings can only be achieve= d with instantiation capability and should be out of scope from this docume= nt. ### The whole discussion on protection belongs in a separate document. (4) Delegation a. The wording "an LSP may be delegated to one or more PCEs." .. this is in= correct, from the reading it looks as if this is happening at the same time= . ### To a single PCE, text is clarified in 03. b. Active stateful PCE LSP Update (sec 5.6.2) OLD: A PCC may choose to compress LSP State Updates to only reflect the most up = to date state, as discussed in the previous section. NEW: A PCC may choose to compress LSP State Reports to only reflect the most up = to date state, as discussed in the previous section. ### Actually, I think we mean updates, not reports (if receiving multiple u= pdates, may choose to do state compression during processing) [DD]: Okay I understand, it mean that PCC is only taking the latest Update = into consideration; now i am wondering can PCC choose to compress reports a= nd send the most upto date report? (skip sending pending if not yet send; o= r in case of multiple up-down only send the latest state) %%% There are some issues with this and error reporting, working through th= ese issues now. (5) Symbolic Path Name TLV The length of this TLV must be greater then 0 as well as multiple of four. ### I think this is not necessary to specify in words, the figure should be= sufficient. [DD]: In most cases yes, but this is a case of variable length we must make= sure extra padding is added and the TLV is aligned. You can take your cue = from other RFC where variable length TLV exists say RFC4920; RFC6001 etc (6) LSP state DB version TLV (page 40, para 2) "Since a PCE does not send LSP updates to a PCC, a PCC should never encount= er this TLV". LSP updates here can be easily confused with the PCUpd messag= es. Kindly reword this. ### Will do. Regards, Dhruv Few more comments on the -03 version: (1) Section 5.5.2 (Revocation of delegated LSP) When a PCC revokes a delegated LSP, PCC immediately clears the LSP state re= ceived from this PCE. But we should apply Make-Before-Break here as well, t= hat is while the PCC delegates to another PCE or keep the LSP with itself, = the LSP should not be teardown immediately. %%% Can you please point me to the text that gives this impression? The cur= rent text says: "MAY immediately clear", not "MUST immediately clear". (2) Modification of Tunnel configuration at PCC for a delegated LSP. Incase of manual config change (say bandwidth, priority) at PCC, how the ne= w LSP parameters to be reported to the PCE (maybe a separate delegation req= uest with new PLSP-ID) eventually make-before-break should be applied here = as well. When the text for MBB is added in detail, this could also be consi= dered. %%% Can you explain the scenario? The operator should not change bw/priorit= y or anything else that is PCE-controlled unless he has revoked delegation. (3) Section 6.1 (The PCRpt Message) Please consider the comments given for draft-crabbe-pce-stateful-pce-mpls-t= e-00 regarding the PCRpt message here as well [http://www.ietf.org/mail-arc= hive/web/pce/current/msg03007.html]. Thanks! Dhruv --_000_70BDAD02381BA54CA31315A2A26A7AD303751B72BLUPRD0511MB436_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dhruv,

 <= /p>

Please see inline %%%.

 <= /p>

From: dhruvdho= dy@gmail.com [mailto:dhruvdhody@gmail.com] On Behalf Of Dhruv Dhody
Sent: Monday, April 01, 2013 9:32 AM
To: Ina Minei
Cc: pce@ietf.org
Subject: Re: [Pce] Comments on draft-ietf-pce-stateful-pce-02

 

Hi Ina,

 

Thanks for your reply, find the response inline, als= o I have a few comments on -03 version of the draft which is at the end of = this mail.

 

Dhruv 

 

On Sat, Mar 23, 2013 at 5:40 AM, Ina Minei <ina@juniper.net> wro= te:

Dhruv,

Thank you for the review. Please see answers = inline below ###.

Ina

From: pce-bounces@ietf.= org [mailto:p= ce-bounces@ietf.org] On Behalf Of Dhruv Dhody

 

Hi,

Please find the review comments for this draft (there is some overlap wi= th comments from Jon, Cyril etc)

Major Comments:

(1) State synchronisation:  

a. PCE should determine the synchronisation is over as soon as possible,= as updates, request etc are blocked during synchronisation. Maybe the last= report message can have SYNC=3D0 (similar to F - fragmentation bit in RP o= bject) or as Jon suggested an empty report but then the RBNF of PCRpt should support it. 

### Please see version 03 of the draft.

 

b. I also dont like the use of word 'purge' with respect to old or stale= entries during PCEP session up/down. A mechanism to mark LSP entries as st= ale and waiting for them to be refreshed after session up and deleted (or '= purged') only after some timer expiry.

### Please see version 03 of the draft.

 

 

(2) The PCRpt Message:

<state-report> ::=3D <LSP>[<path-list>] Where:&nb= sp;<path-list>::=3D<path>[<path-list>]. Is this to specif= y primary and backup? In which case the status of the paths needs to report= ed separately in case of standby but we have only one LSP object = here to specify the operational status. Also LSP-ID of primary and backup would be different.&= nbsp;

 

Also applicable to PCUpd message. 

I feel the backup path should be updated and reported separately&nb= sp;with each having there own encoding for LSP object. 

### Clarification on backup paths will be don= e in the protection doc. I agree with you the text needs to be cleaned up i= n the base spec, will do so in 04.

 

(3) Node Identifier TLV

PCC may use address that survives the session restart (Loopback, MPLS LS= R-ID etc), i suggest we mention this in the document and provide guidance t= o implementers to do this if possible. 

### the node-id (now renamed to predundancy-g= roup-id) will be further clarified in version 04

 

(4) LSP Object: 

a. What is relationship between the LSP-ID in LSP object and the LSP-ID = in LSP Identifier TLVs?

### The lsp-id in the lsp object was renamed = to plsp-id to avoid such confusion.

[DD]: Rename is goo= d, but i hope relationship between the PLSP-ID and the LSP-ID (signalled by= RSVP) can be explicitly mentioned. This should especially be clarified in = the case of MBB. 

 <= /p>

%%% Could you point to th= e confusing text in the definition of plsp-id?

  

b. There is no mechanism to report the 'pending' state right n= ow? O-Bit as zero will mean down, not pending. 

### The O-bit will be revisited in version= 04.

 

(5) Make-Before-Break: 

There is a need to clarify how MBB is achieved, what is the LSP-ID in ca= se of updates and reports? 

### Please see version 03.

 

[DD]: The updated t= ext though in the right direction is still missing key information. I hope = the next version clarifies it further. 

%%% could you please indi= cate what key information is missing?

 

Minor Comments: 

(1) Abstract/Introduction

There is a consistent use of phrase "between and across PCEP sessio= ns". Can you clarify? 

### LSPs may move from one PCE to another.

 

(2) Re-look the terminology section as some terms are no longer in the d= ocument. 

### Could you send the correction?

 

[DD]: Just removal = of MPLS TE Global Default Restoration & MPLS TE Global Path P= rotection should do the trick. Both terms are no longer used in this docume= nt. 

(3) LSP Protection 

In case of delegated PCE, the desired protection may also be configured = at PCC and the active stateful PCE should support it, the stateful PCE havi= ng full control over the protection / restoration settings can only be achi= eved with instantiation capability and should be out of scope from this document. 

### The whole discussion on protection belong= s in a separate document.

 

(4) Delegation

a. The wording "an LSP may be delegated to one or more PCEs." = .. this is incorrect, from the reading it looks as if this is happening at = the same time. 

### To a single PCE, text is clarified in 03.=

 

b. Active stateful PCE LSP Update (sec 5.6.2)

OLD:

A PCC may choose to compress LSP State Updates to only reflect the = most up to date state, as discussed in the previous section. 

NEW:

A PCC may choose to compress LSP State Reports to only reflect the = most up to date state, as discussed in the previous section. 

### Actually, I think we mean updates, not= reports (if receiving multiple updates, may choose to do state compression= during processing)

 

[DD]: Okay I unders= tand, it mean that PCC is only taking the latest Update into consideration;= now i am wondering can PCC choose to compress reports and send the most up= to date report? (skip sending pending if not yet send; or in case of multiple up-down only send the latest state= )   

 <= /p>

%%% There are some issues= with this and error reporting, working through these issues now.

(5) Symbolic Path Name TLV

The length of this TLV must be greater then 0 as well as multiple of fou= r. 

### I think this is not necessary to specify = in words, the figure should be sufficient.

[DD]: In most cases= yes, but this is a case of variable length we must make sure extra padding= is added and the TLV is aligned. You can take your cue from other RFC wher= e variable length TLV exists say RFC4920; RFC6001 etc  

 

(6) LSP state DB version TLV (page 40, para 2)

"Since a PCE does not send LSP updates to a PCC, a PCC should never= encounter this TLV". LSP updates here can be easily confused wit= h the PCUpd messages. Kindly reword this. 

### Will do.

 

Regards,

Dhruv

 

 

Few more comments o= n the -03 version: 

 

(1) Section 5.5.2 (= Revocation of delegated LSP)

 

When a PCC revokes = a delegated LSP, PCC immediately clears the LSP state received from this PC= E. But we should apply Make-Before-Break here as well, that is while the PC= C delegates to another PCE or keep the LSP with itself, the LSP should not be teardown immediately.   <= /span>

%%% Can you please point = me to the text that gives this impression? The current text says: “MA= Y immediately clear”, not “MUST immediately clear”.

 

 

(2) Modification of= Tunnel configuration at PCC for a delegated LSP. 

 

Incase of manual co= nfig change (say bandwidth, priority) at PCC, how the new LSP parameters to= be reported to the PCE (maybe a separate delegation request with= new PLSP-ID) eventually make-before-break should be applied here as well. When the text for MBB is added in = detail, this could also be considered. 

 <= /p>

%%% Can you explain the s= cenario? The operator should not change bw/priority or anything else that i= s PCE-controlled unless he has revoked delegation.

 <= /p>

(3) Section 6.1 (Th= e PCRpt Message)

 

 

Thanks! 

 

Dhruv

 

 

 

--_000_70BDAD02381BA54CA31315A2A26A7AD303751B72BLUPRD0511MB436_-- From zhang.xian@huawei.com Wed Apr 3 21:10:50 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81A6611E80A5 for ; Wed, 3 Apr 2013 21:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihCZ7vIKMHIf for ; Wed, 3 Apr 2013 21:10:50 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 40F8D11E80A2 for ; Wed, 3 Apr 2013 21:10:49 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AQB02445; Thu, 04 Apr 2013 04:10:45 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 4 Apr 2013 05:10:28 +0100 Received: from SZXEML454-HUB.china.huawei.com (10.82.67.197) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 4 Apr 2013 05:10:25 +0100 Received: from SZXEML510-MBX.china.huawei.com ([169.254.3.139]) by SZXEML454-HUB.china.huawei.com ([10.82.67.197]) with mapi id 14.01.0323.007; Thu, 4 Apr 2013 12:09:19 +0800 From: "Zhangxian (Xian)" To: Ina Minei , "Jan Medved (jmedved)" , "pce@ietf.org" Thread-Topic: [Pce] Stateful PCE Capability discovery draft: request for review & adoption as a WG document Thread-Index: AQHOKz1BnZucrDdgSkKBBfjQIKzyOJjEs9OwgADEBAA= Date: Thu, 4 Apr 2013 04:09:19 +0000 Message-ID: References: <70BDAD02381BA54CA31315A2A26A7AD30374F8FF@BLUPRD0511MB436.namprd05.prod.outlook.com> In-Reply-To: <70BDAD02381BA54CA31315A2A26A7AD30374F8FF@BLUPRD0511MB436.namprd05.prod.outlook.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.104.209] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Pce] Stateful PCE Capability discovery draft: request for review & adoption as a WG document X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 04:10:50 -0000 SGksIEFsbCwgDQoNCiAgICBBZ3JlZTsgVGhpcyBpcyBwYXJ0IG9mIHRoZSBiYXNpYyBleHRlbnNp b25zIG5lZWRlZCBmb3IgaW1wbGVtZW50aW5nIHN0YXRlZnVsIFBDRSBhbmQgc2hvdWxkIGJlIGNv bnNpZGVyZWQgZm9yIGFkb3B0aW9uIGJ5IFdHLiANCg0KUmVnYXJkcywNCg0KWGlhbiAoc3BlYWtp bmcgYXMgY28tYXV0aG9yKQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogcGNl LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpwY2UtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIEluYSBNaW5laQ0KU2VudDogMjAxM8TqNNTCNMjVIDA6MDkNClRvOiBKYW4gTWVkdmVkIChq bWVkdmVkKTsgcGNlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1BjZV0gU3RhdGVmdWwgUENFIENh cGFiaWxpdHkgZGlzY292ZXJ5IGRyYWZ0OiByZXF1ZXN0IGZvciByZXZpZXcgJiBhZG9wdGlvbiBh cyBhIFdHIGRvY3VtZW50DQoNClRoaXMgaXMgdXNlZnVsIGFuZCBzdHJhaWdodGZvcndhcmQgZnVu Y3Rpb25hbGl0eSB0aGF0IGlzIG11Y2ggbmVlZGVkIGZvciBhIGRlcGxveW1lbnQgYW5kIGNvbXBs ZXRlcyB0aGUgc29sdXRpb24uDQoNCkkgc3VwcG9ydCB0aGlzIGRyYWZ0J3MgYWRvcHRpb24gYXMg YSBXRyBkb2N1bWVudCAoYnV0IEkgZ3Vlc3Mgd2Ugd2lsbCB3YWl0IGZvciB0aGUgY2hhaXJzIHRv IHNlbmQgdGhlIG9mZmljaWFsIHBvbGwsIHJpZ2h0PykNCg0KSW5hIA0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogcGNlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpwY2UtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEphbiBNZWR2ZWQgKGptZWR2ZWQpDQpTZW50OiBX ZWRuZXNkYXksIE1hcmNoIDI3LCAyMDEzIDM6NDkgUE0NClRvOiBwY2VAaWV0Zi5vcmcNClN1Ympl Y3Q6IFtQY2VdIFN0YXRlZnVsIFBDRSBDYXBhYmlsaXR5IGRpc2NvdmVyeSBkcmFmdDogcmVxdWVz dCBmb3IgcmV2aWV3ICYgYWRvcHRpb24gYXMgYSBXRyBkb2N1bWVudA0KDQpEZWFyIFBDRSdycywN Cg0KY2FuIHlvdSBwbGVhc2UgcmV2aWV3IGRyYWZ0LXNpdmFiYWxhbi1wY2UtZGlzY28tc3RhdGVm dWwgYW5kIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUgbGlzdD8gVGhlIGRyYWZ0IGlzIGF0OiBo dHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNpdmFiYWxhbi1wY2UtZGlzY28t c3RhdGVmdWwvLg0KDQpBbHNvLCBjYW4geW91IHBsZWFzZSBsZXQgdXMga25vdyBpZiB5b3UgYXJl IGluIGZhdm9yL29wcG9zZWQgdG8gYWRvcHRpbmcgZHJhZnQtc2l2YWJhbGFuLXBjZS1kaXNjby1z dGF0ZWZ1bCBhcyBhIFBDRSBXRyBkb2N1bWVudD8gDQoNCg0KDQpUaGFua3MgYSBsb3QgaW4gYWR2 YW5jZSwNClNpdmEgYW5kIEphbg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NClBjZSBtYWlsaW5nIGxpc3QNClBjZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wY2UNCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KUGNlIG1haWxpbmcgbGlzdA0KUGNlQGlldGYub3Jn DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BjZQ0K From julien.meuric@orange.com Thu Apr 4 05:32:40 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 136F221F8BA4 for ; Thu, 4 Apr 2013 05:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+2CASgd2sya for ; Thu, 4 Apr 2013 05:32:38 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id EB68221F8B96 for ; Thu, 4 Apr 2013 05:32:36 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 07B7C16C005 for ; Thu, 4 Apr 2013 14:32:36 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id F34FC16C002 for ; Thu, 4 Apr 2013 14:32:35 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 4 Apr 2013 14:32:35 +0200 Received: from [10.193.71.218] ([10.193.71.218]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 4 Apr 2013 14:32:32 +0200 Message-ID: <515D72DE.2090209@orange.com> Date: Thu, 04 Apr 2013 14:32:30 +0200 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: pce@ietf.org References: <70BDAD02381BA54CA31315A2A26A7AD30374F8FF@BLUPRD0511MB436.namprd05.prod.outlook.com> In-Reply-To: <70BDAD02381BA54CA31315A2A26A7AD30374F8FF@BLUPRD0511MB436.namprd05.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Apr 2013 12:32:32.0793 (UTC) FILETIME=[7AC03090:01CE3130] Subject: Re: [Pce] Stateful PCE Capability discovery draft: request for review & adoption as a WG document X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 12:32:46 -0000 Hi Ina. Indeed, there is no poll for WG adoption in progress, which remains in the hands of the chairs. One may interpret Silva and Jan's message as a clever way to get feedback from the WG, but the use of "adopting" is an unfortunate wording. In this context, comments like "support" or "useless" need to be backed up. Thanks, Julien On 04/03/2013 18:08, Ina Minei wrote: > (but I guess we will wait for the chairs to send the official poll, right?) > > Ina > From julien.meuric@orange.com Thu Apr 4 05:43:39 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A549A21F842B for ; Thu, 4 Apr 2013 05:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snReQJ4ki3gE for ; Thu, 4 Apr 2013 05:43:39 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id E9B3421F8411 for ; Thu, 4 Apr 2013 05:43:38 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id AECF0DE4003 for ; Thu, 4 Apr 2013 14:45:20 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id A61F0DE4002 for ; Thu, 4 Apr 2013 14:45:20 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 4 Apr 2013 14:43:38 +0200 Received: from [10.193.71.218] ([10.193.71.218]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 4 Apr 2013 14:43:37 +0200 Message-ID: <515D7578.2040802@orange.com> Date: Thu, 04 Apr 2013 14:43:36 +0200 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: pce@ietf.org References: <036101ce2f99$df19b9f0$9d4d2dd0$@olddog.co.uk> In-Reply-To: <036101ce2f99$df19b9f0$9d4d2dd0$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Apr 2013 12:43:37.0621 (UTC) FILETIME=[0704E450:01CE3132] Subject: Re: [Pce] Recharter text X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 12:43:39 -0000 Hi Adrian. I believe the WG agrees with the process and there is no reason not to abide by it. The next step will be the chairs sharing a new version of the text with the WG for feedback, which will happen soon. Thanks, Julien On 04/02/2013 14:01, Adrian Farrel wrote: > Hi working group, > > In Orlando you discussed a paragraph for a charter revision. > > The work doesn't stop there! > > In order to officially recharter I need to have the agreed text sent to me as a > formal request by the chairs, and I need to see that the WG has consensus behind > the text. > > Thanks, > Adrian > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From wwwrun@rfc-editor.org Fri Apr 5 01:45:43 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71C7A21F9717 for ; Fri, 5 Apr 2013 01:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.353 X-Spam-Level: X-Spam-Status: No, score=-102.353 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ngh5fGB0iekM for ; Fri, 5 Apr 2013 01:45:43 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 03B3921F9649 for ; Fri, 5 Apr 2013 01:45:43 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 2C9EAB1E002; Fri, 5 Apr 2013 01:45:26 -0700 (PDT) To: rbradfor@cisco.com, jpv@cisco.com, adrian@olddog.co.uk, stbryant@cisco.com, adrian@olddog.co.uk, jpv@cisco.com, julien.meuric@orange.com From: RFC Errata System Message-Id: <20130405084526.2C9EAB1E002@rfc-editor.org> Date: Fri, 5 Apr 2013 01:45:26 -0700 (PDT) X-Mailman-Approved-At: Fri, 05 Apr 2013 02:56:19 -0700 Cc: pce@ietf.org, rfc-editor@rfc-editor.org Subject: [Pce] [Editorial Errata Reported] RFC5520 (3582) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 08:45:43 -0000 The following errata report has been submitted for RFC5520, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5520&eid=3582 -------------------------------------- Type: Editorial Reported by: Dhruv Dhody Section: 3.2.3 Original Text ------------- ::= | where: ::= [] [] [] [] [] [] [] ::= Corrected Text -------------- ::= | where: ::= [] [] [] [[]] [] [] ::= Notes ----- This document defines to allow path request message to be used for getting the confidential path segment. The should be as per RFC5440 itself. There is a mistake in the second BANDWIDTH object which should be placed with RRO as per RFC5440. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5520 (draft-ietf-pce-path-key-05) -------------------------------------- Title : Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism Publication Date : April 2009 Author(s) : R. Bradford, Ed., JP. Vasseur, A. Farrel Category : PROPOSED STANDARD Source : Path Computation Element Area : Routing Stream : IETF Verifying Party : IESG From zhangfatai@huawei.com Sun Apr 7 02:00:49 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29B7A21F8712 for ; Sun, 7 Apr 2013 02:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DhaWkX6Pkbf for ; Sun, 7 Apr 2013 02:00:48 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2290921F8700 for ; Sun, 7 Apr 2013 02:00:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AQD30315; Sun, 07 Apr 2013 09:00:46 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sun, 7 Apr 2013 10:00:23 +0100 Received: from SZXEML450-HUB.china.huawei.com (10.82.67.193) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sun, 7 Apr 2013 17:00:44 +0800 Received: from SZXEML552-MBS.china.huawei.com ([169.254.2.42]) by szxeml450-hub.china.huawei.com ([10.82.67.193]) with mapi id 14.01.0323.007; Sun, 7 Apr 2013 17:00:37 +0800 From: Fatai Zhang To: "Jan Medved (jmedved)" , "pce@ietf.org" Thread-Topic: [Pce] Stateful PCE Capability discovery draft: request for review & adoption as a WG document Thread-Index: AQHOKz1BnZucrDdgSkKBBfjQIKzyOJjKhXww Date: Sun, 7 Apr 2013 09:00:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Pce] Stateful PCE Capability discovery draft: request for review & adoption as a WG document X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 09:00:49 -0000 Hi Jan, I would say this draft is useful and I am in favor of this draft, even thou= gh I know this is not an official poll.=20 Best Regards Fatai -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Jan M= edved (jmedved) Sent: Thursday, March 28, 2013 6:49 AM To: pce@ietf.org Subject: [Pce] Stateful PCE Capability discovery draft: request for review = & adoption as a WG document Dear PCE'rs, can you please review draft-sivabalan-pce-disco-stateful and send your comm= ents to the list? The draft is at: http://datatracker.ietf.org/doc/draft-si= vabalan-pce-disco-stateful/. Also, can you please let us know if you are in favor/opposed to adopting dr= aft-sivabalan-pce-disco-stateful as a PCE WG document?=20 Thanks a lot in advance, Siva and Jan _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From adrian@olddog.co.uk Sun Apr 7 06:02:32 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6507E21F8CDD for ; Sun, 7 Apr 2013 06:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.272 X-Spam-Level: X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[AWL=-0.273, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oB1dziqcPFFT for ; Sun, 7 Apr 2013 06:02:31 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 75B0921F8CD8 for ; Sun, 7 Apr 2013 06:02:31 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r37D2PP4020454; Sun, 7 Apr 2013 14:02:25 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r37D2OlD020444 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 7 Apr 2013 14:02:24 +0100 From: "Adrian Farrel" To: References: <20130405084526.2C9EAB1E002@rfc-editor.org> In-Reply-To: <20130405084526.2C9EAB1E002@rfc-editor.org> Date: Sun, 7 Apr 2013 14:02:23 +0100 Message-ID: <04ca01ce3390$262577e0$727067a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLM8DE2/vPmu6kqzyDU2wR6fcXWhJbNPeQQ Content-Language: en-gb Cc: jpv@cisco.com Subject: Re: [Pce] [Editorial Errata Reported] RFC5520 (3582) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 13:02:32 -0000 Hi PCE, Dhurv's Errata Report at http://www.rfc-editor.org/errata_search.php?rfc=5520&eid=3582 seems to make a good point. The RBNF in RFC 5520 appears to offer the presence of two copies of without any explanation, but also to not allow to be present alongside the . I can see how this happened... Revision -08 of draft-ietf-pce-pcep used exactly the formulation that found its way into RFC5520, but by the time PCEP became RFC 5440, this issue had been resolved in the PCEP spec. Obviously the fix did not get applied across to the Path Key document. I propose to accept this Errata Report, but since I am a co-author, I just want to poll the WG to make sure no=one objects. Thanks, Adrian > -----Original Message----- > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > Sent: 05 April 2013 09:45 > To: rbradfor@cisco.com; jpv@cisco.com; adrian@olddog.co.uk; > stbryant@cisco.com; adrian@olddog.co.uk; jpv@cisco.com; > julien.meuric@orange.com > Cc: dhruv.ietf@gmail.com; pce@ietf.org; rfc-editor@rfc-editor.org > Subject: [Editorial Errata Reported] RFC5520 (3582) > > The following errata report has been submitted for RFC5520, > "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a > Path-Key-Based Mechanism". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5520&eid=3582 > > -------------------------------------- > Type: Editorial > Reported by: Dhruv Dhody > > Section: 3.2.3 > > Original Text > ------------- > ::= > | > > where: > ::= > [] > [] > [] > [] > [] > [] > [] > ::= > > > > Corrected Text > -------------- > ::= > | > > where: > ::= > [] > [] > [] > [[]] > [] > [] > ::= > > > > Notes > ----- > This document defines to allow path request message to > be used for getting the confidential path segment. The > should be as per RFC5440 itself. > There is a mistake in the second BANDWIDTH object which should be placed with > RRO as per RFC5440. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5520 (draft-ietf-pce-path-key-05) > -------------------------------------- > Title : Preserving Topology Confidentiality in Inter-Domain Path > Computation Using a Path-Key-Based Mechanism > Publication Date : April 2009 > Author(s) : R. Bradford, Ed., JP. Vasseur, A. Farrel > Category : PROPOSED STANDARD > Source : Path Computation Element > Area : Routing > Stream : IETF > Verifying Party : IESG From abdussalambaryun@gmail.com Sun Apr 7 08:20:27 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C08121F8E6E for ; Sun, 7 Apr 2013 08:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8Hb5Lyoq4JB for ; Sun, 7 Apr 2013 08:20:26 -0700 (PDT) Received: from mail-da0-x231.google.com (mail-da0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 7CBB521F8DFB for ; Sun, 7 Apr 2013 08:20:26 -0700 (PDT) Received: by mail-da0-f49.google.com with SMTP id t11so2237553daj.22 for ; Sun, 07 Apr 2013 08:20:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=yZiWrZLviwcG7uRjjjyF5Jamgecd1zRRufabCc4wrtU=; b=zOY8HGoQuJRzTIHr8LZnYYj5B6tdwO1cbeC0ltaZBOqXOrfzcpbt/pBMYTqn4t5Krx 8oh7qLz/26QnQKQTT7XJ1sxeoliVbaMfwfqA8SmxfGdWrJuZEihEYDTD0jfRhzWx1n4w gtcxoiPmHTUHmgqrU43dcv1rFiKjCof9sqQNgYwfS66GfW77nf37r2gTEo7pIugjicHK QyecSYr5NMdTRvPN31+JL+gbGIqfWgO0uwq70tZ54cffqH6yKDWao8bn2ouk2SODBVrx 8rjBJKYe2wDRu1zMod+JBOcr6UUeVqZscnTBGYjiWiYvaSi0PaytkAY1mt9BYJiKS29f CDpA== MIME-Version: 1.0 X-Received: by 10.66.184.14 with SMTP id eq14mr24278456pac.215.1365348025712; Sun, 07 Apr 2013 08:20:25 -0700 (PDT) Received: by 10.68.33.132 with HTTP; Sun, 7 Apr 2013 08:20:25 -0700 (PDT) In-Reply-To: <04ca01ce3390$262577e0$727067a0$@olddog.co.uk> References: <20130405084526.2C9EAB1E002@rfc-editor.org> <04ca01ce3390$262577e0$727067a0$@olddog.co.uk> Date: Sun, 7 Apr 2013 17:20:25 +0200 Message-ID: From: Abdussalam Baryun To: adrian@olddog.co.uk Content-Type: text/plain; charset=ISO-8859-1 Cc: pce@ietf.org, jpv@cisco.com Subject: Re: [Pce] [Editorial Errata Reported] RFC5520 (3582) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 15:20:27 -0000 My small objection is just that the errata did not add the full PCReq message paragraph in the errata (it contains another editorial issue), as the missing part can add to read the below (similar to RFC5440); ++++++++++++++ The format of a PCReq message is as follows: ::= [] where: ::=[] ::=[] ++++++++++++++ The RFC5520 had mentioned the above as differently from RFC5440 as; +++++++++++++++++ The format of a PCReq message is as follows: ::= [] where: ::=[] ::=[] ++++++++++++++++++ I think there may be difference between and However, I don't object if the authors ignored that, Regards AB *This message was a reply to the below request* ++++++++++++++++++++++++++++++++++++ On 4/7/13, Adrian Farrel wrote: > Hi PCE, > > Dhurv's Errata Report at > http://www.rfc-editor.org/errata_search.php?rfc=5520&eid=3582 seems to make > a > good point. The RBNF in RFC 5520 appears to offer the presence of two copies > of > without any explanation, but also to not allow to > be > present alongside the . > > I can see how this happened... > Revision -08 of draft-ietf-pce-pcep used exactly the formulation that found > its > way into RFC5520, but by the time PCEP became RFC 5440, this issue had been > resolved in the PCEP spec. Obviously the fix did not get applied across to > the > Path Key document. > > I propose to accept this Errata Report, but since I am a co-author, I just > want > to poll the WG to make sure no=one objects. > > Thanks, > Adrian > >> -----Original Message----- >> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >> Sent: 05 April 2013 09:45 >> To: rbradfor@cisco.com; jpv@cisco.com; adrian@olddog.co.uk; >> stbryant@cisco.com; adrian@olddog.co.uk; jpv@cisco.com; >> julien.meuric@orange.com >> Cc: dhruv.ietf@gmail.com; pce@ietf.org; rfc-editor@rfc-editor.org >> Subject: [Editorial Errata Reported] RFC5520 (3582) >> >> The following errata report has been submitted for RFC5520, >> "Preserving Topology Confidentiality in Inter-Domain Path Computation >> Using a >> Path-Key-Based Mechanism". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=5520&eid=3582 >> >> -------------------------------------- >> Type: Editorial >> Reported by: Dhruv Dhody >> >> Section: 3.2.3 >> >> Original Text >> ------------- >> ::= >> | >> >> where: >> ::= >> [] >> [] >> [] >> [] >> [] >> [] >> [] >> ::= >> >> >> >> Corrected Text >> -------------- >> ::= >> | >> >> where: >> ::= >> [] >> [] >> [] >> [[]] >> [] >> [] >> ::= >> >> >> >> Notes >> ----- >> This document defines to allow path request message >> to >> be used for getting the confidential path segment. The >> >> should be as per RFC5440 itself. >> There is a mistake in the second BANDWIDTH object which should be placed >> with >> RRO as per RFC5440. >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC5520 (draft-ietf-pce-path-key-05) >> -------------------------------------- >> Title : Preserving Topology Confidentiality in Inter-Domain >> Path >> Computation Using a Path-Key-Based Mechanism >> Publication Date : April 2009 >> Author(s) : R. Bradford, Ed., JP. Vasseur, A. Farrel >> Category : PROPOSED STANDARD >> Source : Path Computation Element >> Area : Routing >> Stream : IETF >> Verifying Party : IESG > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > From adrian@olddog.co.uk Sun Apr 7 09:06:17 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA39021F8EBF for ; Sun, 7 Apr 2013 09:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iuav29Y4fVZN for ; Sun, 7 Apr 2013 09:06:17 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id EA37D21F8EB7 for ; Sun, 7 Apr 2013 09:06:16 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r37G6BvA019365; Sun, 7 Apr 2013 17:06:11 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r37G6Ase019354 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 7 Apr 2013 17:06:10 +0100 From: "Adrian Farrel" To: "'Abdussalam Baryun'" References: <20130405084526.2C9EAB1E002@rfc-editor.org> <04ca01ce3390$262577e0$727067a0$@olddog.co.uk> In-Reply-To: Date: Sun, 7 Apr 2013 17:06:09 +0100 Message-ID: <050301ce33a9$d236f630$76a4e290$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLM8DE2/vPmu6kqzyDU2wR6fcXWhALYrQVQAYw6GXqWqku3wA== Content-Language: en-gb Cc: pce@ietf.org, jpv@cisco.com Subject: Re: [Pce] [Editorial Errata Reported] RFC5520 (3582) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 16:06:17 -0000 Hi AB, You're right that this is another typo in the same section. It is generally best to raise individual issues in separate reports because that way it is easier to process them. Would you like to raise the Errata Report for this, or shall I handle it? Adrian > -----Original Message----- > From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] > Sent: 07 April 2013 16:20 > To: adrian@olddog.co.uk > Cc: pce@ietf.org; jpv@cisco.com > Subject: Re: [Pce] [Editorial Errata Reported] RFC5520 (3582) > > My small objection is just that the errata did not add the full PCReq > message paragraph in the errata (it contains another editorial issue), > as the missing part can add to read the below (similar to RFC5440); > ++++++++++++++ > The format of a PCReq message is as follows: > > ::= > [] > > > where: > > ::=[] > ::=[] > ++++++++++++++ > > The RFC5520 had mentioned the above as differently from RFC5440 as; > +++++++++++++++++ > The format of a PCReq message is as follows: > > ::= > [] > > > where: > > ::=[] > ::=[] > ++++++++++++++++++ > I think there may be difference between and > However, I don't object if the authors ignored that, > > Regards > AB > > *This message was a reply to the below request* > ++++++++++++++++++++++++++++++++++++ > On 4/7/13, Adrian Farrel wrote: > > Hi PCE, > > > > Dhurv's Errata Report at > > http://www.rfc-editor.org/errata_search.php?rfc=5520&eid=3582 seems to > make > > a > > good point. The RBNF in RFC 5520 appears to offer the presence of two copies > > of > > without any explanation, but also to not allow > to > > be > > present alongside the . > > > > I can see how this happened... > > Revision -08 of draft-ietf-pce-pcep used exactly the formulation that found > > its > > way into RFC5520, but by the time PCEP became RFC 5440, this issue had been > > resolved in the PCEP spec. Obviously the fix did not get applied across to > > the > > Path Key document. > > > > I propose to accept this Errata Report, but since I am a co-author, I just > > want > > to poll the WG to make sure no=one objects. > > > > Thanks, > > Adrian > > > >> -----Original Message----- > >> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > >> Sent: 05 April 2013 09:45 > >> To: rbradfor@cisco.com; jpv@cisco.com; adrian@olddog.co.uk; > >> stbryant@cisco.com; adrian@olddog.co.uk; jpv@cisco.com; > >> julien.meuric@orange.com > >> Cc: dhruv.ietf@gmail.com; pce@ietf.org; rfc-editor@rfc-editor.org > >> Subject: [Editorial Errata Reported] RFC5520 (3582) > >> > >> The following errata report has been submitted for RFC5520, > >> "Preserving Topology Confidentiality in Inter-Domain Path Computation > >> Using a > >> Path-Key-Based Mechanism". > >> > >> -------------------------------------- > >> You may review the report below and at: > >> http://www.rfc-editor.org/errata_search.php?rfc=5520&eid=3582 > >> > >> -------------------------------------- > >> Type: Editorial > >> Reported by: Dhruv Dhody > >> > >> Section: 3.2.3 > >> > >> Original Text > >> ------------- > >> ::= > >> | > >> > >> where: > >> ::= > >> [] > >> [] > >> [] > >> [] > >> [] > >> [] > >> [] > >> ::= > >> > >> > >> > >> Corrected Text > >> -------------- > >> ::= > >> | > >> > >> where: > >> ::= > >> [] > >> [] > >> [] > >> [[]] > >> [] > >> [] > >> ::= > >> > >> > >> > >> Notes > >> ----- > >> This document defines to allow path request message > >> to > >> be used for getting the confidential path segment. The > >> > >> should be as per RFC5440 itself. > >> There is a mistake in the second BANDWIDTH object which should be placed > >> with > >> RRO as per RFC5440. > >> > >> Instructions: > >> ------------- > >> This errata is currently posted as "Reported". If necessary, please > >> use "Reply All" to discuss whether it should be verified or > >> rejected. When a decision is reached, the verifying party (IESG) > >> can log in to change the status and edit the report, if necessary. > >> > >> -------------------------------------- > >> RFC5520 (draft-ietf-pce-path-key-05) > >> -------------------------------------- > >> Title : Preserving Topology Confidentiality in Inter-Domain > >> Path > >> Computation Using a Path-Key-Based Mechanism > >> Publication Date : April 2009 > >> Author(s) : R. Bradford, Ed., JP. Vasseur, A. Farrel > >> Category : PROPOSED STANDARD > >> Source : Path Computation Element > >> Area : Routing > >> Stream : IETF > >> Verifying Party : IESG > > > > _______________________________________________ > > Pce mailing list > > Pce@ietf.org > > https://www.ietf.org/mailman/listinfo/pce > > From rbradfor@cisco.com Sun Apr 7 10:19:38 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1D9121F86E6 for ; Sun, 7 Apr 2013 10:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCvxrs3rLe+s for ; Sun, 7 Apr 2013 10:19:37 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id B4B6921F86C9 for ; Sun, 7 Apr 2013 10:19:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4477; q=dns/txt; s=iport; t=1365355177; x=1366564777; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=VIxsu7HZAXk1X5b5bhq0VsUS7hUG+h85I46Tesmx+S4=; b=AR/BBmOkPwMypt1JxSY40usukp4SsNyp6yJRzYAJkAgu4HG7DVwVJUdp MGJUAdKDxZSI4jJmX7CtP6UFX50zCRykzREGqi93DX+xE36tl8R3dPhLC t7sG9Iu5bnekMmTOSdF2bviFbzt8EaHzhz87vhYsUavdtBtSvMu18JNGY k=; X-IronPort-AV: E=Sophos;i="4.87,424,1363132800"; d="scan'208";a="195932751" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 07 Apr 2013 17:19:37 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r37HJb9d006539 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 7 Apr 2013 17:19:37 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.70]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Sun, 7 Apr 2013 12:19:36 -0500 From: "Rich Bradford (rbradfor)" To: "adrian@olddog.co.uk" , "pce@ietf.org" Thread-Topic: [Editorial Errata Reported] RFC5520 (3582) Thread-Index: AQHOMdn2AQzqAo0/w0KL7Ecf75pFkZjLEGeA///yyHA= Date: Sun, 7 Apr 2013 17:19:35 +0000 Message-ID: <982E8E8D3B916F4CABA9FC1F178874C0150FDC0E@xmb-aln-x10.cisco.com> References: <20130405084526.2C9EAB1E002@rfc-editor.org> <04ca01ce3390$262577e0$727067a0$@olddog.co.uk> In-Reply-To: <04ca01ce3390$262577e0$727067a0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.252.173] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "jpv@cisco.com" Subject: Re: [Pce] [Editorial Errata Reported] RFC5520 (3582) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 17:19:38 -0000 I agree with the changes.=20 --rich -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: Sunday, April 07, 2013 9:02 AM To: pce@ietf.org Cc: dhruv.ietf@gmail.com; Rich Bradford (rbradfor); jpv@cisco.com; Stewart = Bryant (stbryant); jpv@cisco.com; julien.meuric@orange.com Subject: RE: [Editorial Errata Reported] RFC5520 (3582) Importance: High Hi PCE, Dhurv's Errata Report at http://www.rfc-editor.org/errata_search.php?rfc=3D5520&eid=3D3582 seems to = make a good point. The RBNF in RFC 5520 appears to offer the presence of tw= o copies of without any explanation, but also to not allow to be present alongside the . I can see how this happened... Revision -08 of draft-ietf-pce-pcep used exactly the formulation that found= its way into RFC5520, but by the time PCEP became RFC 5440, this issue had= been resolved in the PCEP spec. Obviously the fix did not get applied acro= ss to the Path Key document. I propose to accept this Errata Report, but since I am a co-author, I just = want to poll the WG to make sure no=3Done objects. Thanks, Adrian > -----Original Message----- > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > Sent: 05 April 2013 09:45 > To: rbradfor@cisco.com; jpv@cisco.com; adrian@olddog.co.uk;=20 > stbryant@cisco.com; adrian@olddog.co.uk; jpv@cisco.com;=20 > julien.meuric@orange.com > Cc: dhruv.ietf@gmail.com; pce@ietf.org; rfc-editor@rfc-editor.org > Subject: [Editorial Errata Reported] RFC5520 (3582) >=20 > The following errata report has been submitted for RFC5520,=20 > "Preserving Topology Confidentiality in Inter-Domain Path Computation=20 > Using a Path-Key-Based Mechanism". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5520&eid=3D3582 >=20 > -------------------------------------- > Type: Editorial > Reported by: Dhruv Dhody >=20 > Section: 3.2.3 >=20 > Original Text > ------------- > ::=3D > | >=20 > where: > ::=3D > [] > [] > [] > [] > [] > [] > [] > ::=3D >=20 >=20 >=20 > Corrected Text > -------------- > ::=3D > | >=20 > where: > ::=3D > [] > [] > [] > [[]] > [] > [] > ::=3D >=20 >=20 >=20 > Notes > ----- > This document defines to allow path request=20 > message to be used for getting the confidential path segment. The=20 > should be as per RFC5440 itself. > There is a mistake in the second BANDWIDTH object which should be=20 > placed with RRO as per RFC5440. >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please=20 > use "Reply All" to discuss whether it should be verified or rejected.=20 > When a decision is reached, the verifying party (IESG) can log in to=20 > change the status and edit the report, if necessary. >=20 > -------------------------------------- > RFC5520 (draft-ietf-pce-path-key-05) > -------------------------------------- > Title : Preserving Topology Confidentiality in Inter-Domain= Path > Computation Using a Path-Key-Based Mechanism > Publication Date : April 2009 > Author(s) : R. Bradford, Ed., JP. Vasseur, A. Farrel > Category : PROPOSED STANDARD > Source : Path Computation Element > Area : Routing > Stream : IETF > Verifying Party : IESG From wwwrun@rfc-editor.org Sun Apr 7 13:22:21 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 720FD21F8E5A for ; Sun, 7 Apr 2013 13:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.373 X-Spam-Level: X-Spam-Status: No, score=-102.373 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sw97twXtrD8W for ; Sun, 7 Apr 2013 13:22:21 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 07F9B21F8ACE for ; Sun, 7 Apr 2013 13:22:21 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 2CA8BB1E002; Sun, 7 Apr 2013 13:21:55 -0700 (PDT) To: rbradfor@cisco.com, jpv@cisco.com, adrian@olddog.co.uk, stbryant@cisco.com, adrian@olddog.co.uk, jpv@cisco.com, julien.meuric@orange.com From: RFC Errata System Message-Id: <20130407202155.2CA8BB1E002@rfc-editor.org> Date: Sun, 7 Apr 2013 13:21:55 -0700 (PDT) X-Mailman-Approved-At: Mon, 08 Apr 2013 02:15:39 -0700 Cc: rfc-editor@rfc-editor.org, pce@ietf.org Subject: [Pce] [Editorial Errata Reported] RFC5520 (3583) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 20:22:21 -0000 The following errata report has been submitted for RFC5520, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5520&eid=3583 -------------------------------------- Type: Editorial Reported by: Abdussalam Baryun Section: 3.2.3 Original Text ------------- The format of a PCReq message is as follows: ::= [] where: ::=[] ::=[] Corrected Text -------------- The format of a PCReq message is as follows: ::= [] where: ::=[] ::=[] Notes ----- The corrected text is as RFC5440 section 6.4, the editorial difference is in RFC5520 and in RFC5440 is . Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5520 (draft-ietf-pce-path-key-05) -------------------------------------- Title : Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism Publication Date : April 2009 Author(s) : R. Bradford, Ed., JP. Vasseur, A. Farrel Category : PROPOSED STANDARD Source : Path Computation Element Area : Routing Stream : IETF Verifying Party : IESG From ina@juniper.net Wed Apr 10 12:36:58 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3422A21F8F25 for ; Wed, 10 Apr 2013 12:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lyzlt6dHpxUX for ; Wed, 10 Apr 2013 12:36:57 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2F421F8F1E for ; Wed, 10 Apr 2013 12:36:57 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKUWW/WXyorH9fIVxALWUHyfSLogXyit8C@postini.com; Wed, 10 Apr 2013 12:36:57 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 10 Apr 2013 12:23:54 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Wed, 10 Apr 2013 12:23:54 -0700 Received: from db9outboundpool.messaging.microsoft.com (213.199.154.245) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 10 Apr 2013 12:33:52 -0700 Received: from mail14-db9-R.bigfish.com (10.174.16.240) by DB9EHSOBE003.bigfish.com (10.174.14.66) with Microsoft SMTP Server id 14.1.225.23; Wed, 10 Apr 2013 19:23:52 +0000 Received: from mail14-db9 (localhost [127.0.0.1]) by mail14-db9-R.bigfish.com (Postfix) with ESMTP id 871E8A005E for ; Wed, 10 Apr 2013 19:23:52 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.232.213; KIP:(null); UIP:(null); (null); H:BLUPRD0511HT003.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -23 X-BigFish: PS-23(zz9371I936eI542Izz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz1033IL17326ah8275dhz2dh2a8h668h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1155h) Received: from mail14-db9 (localhost.localdomain [127.0.0.1]) by mail14-db9 (MessageSwitch) id 1365621830967704_6037; Wed, 10 Apr 2013 19:23:50 +0000 (UTC) Received: from DB9EHSMHS009.bigfish.com (unknown [10.174.16.234]) by mail14-db9.bigfish.com (Postfix) with ESMTP id DFCE63A0047 for ; Wed, 10 Apr 2013 19:23:50 +0000 (UTC) Received: from BLUPRD0511HT003.namprd05.prod.outlook.com (157.56.232.213) by DB9EHSMHS009.bigfish.com (10.174.14.19) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 10 Apr 2013 19:23:50 +0000 Received: from BLUPRD0511MB436.namprd05.prod.outlook.com ([169.254.4.213]) by BLUPRD0511HT003.namprd05.prod.outlook.com ([10.255.135.166]) with mapi id 14.16.0293.003; Wed, 10 Apr 2013 19:23:44 +0000 From: Ina Minei To: "pce@ietf.org" Thread-Topic: New Version Notification for draft-crabbe-pce-pce-initiated-lsp-01.txt Thread-Index: AQHONiCYPs0Z5Aia0UGyD5/VYAaKepjP1QGA Date: Wed, 10 Apr 2013 19:23:43 +0000 Message-ID: <70BDAD02381BA54CA31315A2A26A7AD303753859@BLUPRD0511MB436.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.50] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: [Pce] FW: New Version Notification for draft-crabbe-pce-pce-initiated-lsp-01.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 19:36:58 -0000 VGhpcyBpcyBqdXN0IGEgbWlub3IgcmVmcmVzaCwgc2luY2UgdGhlIGRyYWZ0IHdhcyBwZW5kaW5n IGV4cGlyYXRpb24uIFRoZXJlIGFyZSBzdGlsbCBvcGVuIGlzc3VlcyB0aGF0IHdlcmUgcmFpc2Vk IG9uIHRoZSBsaXN0IGFuZCB3aWxsIGJlIGFkZHJlc3NlZCBpbiB0aGUgbmVhciBmdXR1cmUuDQoN CkluYSANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBXZWRu ZXNkYXksIEFwcmlsIDEwLCAyMDEzIDEyOjIxIFBNDQpUbzogSW5hIE1pbmVpDQpDYzogZWRjQGdv b2dsZS5jb207IG1zaXZhQGNpc2NvLmNvbTsgcm9iZXJ0LnZhcmdhQHBhbnRoZW9uLnNrDQpTdWJq ZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWNyYWJiZS1wY2UtcGNlLWlu aXRpYXRlZC1sc3AtMDEudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWNyYWJi ZS1wY2UtcGNlLWluaXRpYXRlZC1sc3AtMDEudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3Vi bWl0dGVkIGJ5IEluYSBNaW5laSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoN CkZpbGVuYW1lOgkgZHJhZnQtY3JhYmJlLXBjZS1wY2UtaW5pdGlhdGVkLWxzcA0KUmV2aXNpb246 CSAwMQ0KVGl0bGU6CQkgUENFUCBFeHRlbnNpb25zIGZvciBQQ0UtaW5pdGlhdGVkIExTUCBTZXR1 cCBpbiBhIFN0YXRlZnVsIFBDRSBNb2RlbA0KQ3JlYXRpb24gZGF0ZToJIDIwMTMtMDQtMTANCkdy b3VwOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAxNA0KVVJMOiAg ICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1jcmFi YmUtcGNlLXBjZS1pbml0aWF0ZWQtbHNwLTAxLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWNyYWJiZS1wY2UtcGNlLWluaXRpYXRlZC1s c3ANCkh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY3Jh YmJlLXBjZS1wY2UtaW5pdGlhdGVkLWxzcC0wMQ0KRGlmZjogICAgICAgICAgICBodHRwOi8vd3d3 LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1jcmFiYmUtcGNlLXBjZS1pbml0aWF0ZWQtbHNw LTAxDQoNCkFic3RyYWN0Og0KICAgVGhlIFBhdGggQ29tcHV0YXRpb24gRWxlbWVudCBDb21tdW5p Y2F0aW9uIFByb3RvY29sIChQQ0VQKSBwcm92aWRlcw0KICAgbWVjaGFuaXNtcyBmb3IgUGF0aCBD b21wdXRhdGlvbiBFbGVtZW50cyAoUENFcykgdG8gcGVyZm9ybSBwYXRoDQogICBjb21wdXRhdGlv bnMgaW4gcmVzcG9uc2UgdG8gUGF0aCBDb21wdXRhdGlvbiBDbGllbnRzIChQQ0NzKSByZXF1ZXN0 cy4NCg0KICAgVGhlIGV4dGVuc2lvbnMgZGVzY3JpYmVkIGluIFtJLUQuaWV0Zi1wY2Utc3RhdGVm dWwtcGNlXSBwcm92aWRlDQogICBzdGF0ZWZ1bCBjb250cm9sIG9mIE11bHRpcHJvdG9jb2wgTGFi ZWwgU3dpdGNoaW5nIChNUExTKSBUcmFmZmljDQogICBFbmdpbmVlcmluZyBMYWJlbCBTd2l0Y2hl ZCBQYXRocyAoVEUgTFNQKSB2aWEgUENFUCwgZm9yIGEgbW9kZWwgd2hlcmUNCiAgIHRoZSBQQ0Mg ZGVsZWdhdGVzIGNvbnRyb2wgb3ZlciBvbmUgb3IgbW9yZSBsb2NhbGx5IGNvbmZpZ3VyZWQgTFNQ cyB0bw0KICAgdGhlIFBDRS4gIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSBjcmVhdGlvbiBh bmQgZGVsZXRpb24gb2YgUENFLQ0KICAgaW5pdGlhdGVkIExTUHMgdW5kZXIgdGhlIHN0YXRlZnVs IFBDRSBtb2RlbC4NCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KVGhlIElFVEYg U2VjcmV0YXJpYXQNCg0KDQo= From jvasseur@cisco.com Tue Apr 16 03:51:56 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1AD421F9685 for ; Tue, 16 Apr 2013 03:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4gb5e+0WP9H for ; Tue, 16 Apr 2013 03:51:55 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id E247C21F9677 for ; Tue, 16 Apr 2013 03:51:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=71039; q=dns/txt; s=iport; t=1366109511; x=1367319111; h=from:to:cc:subject:date:message-id:mime-version; bh=1CGzzVvdUm6eMZdbDdIPypgZryCpcK/Z3q9RKYpootA=; b=DBF7XIxVcnq4K9jaE8nURosYUHQiMRAfNRp55/b4CT/pUfhVGRsBaIZr l/2QAVItb9o38/sVZa+9/+J6zXnoYxPlBjBeVI7XLGCSu9t0Lx0OvSL98 +7rI4CDGQr+r5bKcYoLK/4/kOck0m2PwV/IDrNuMFDyYXj/NjGtoX2Phc 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFANYrbVGtJXHB/2dsb2JhbABQgkJEg2e9VQ17FnSCIQEEIwpMEgEGFBAWAQkCBDAXEAQODYgMjwKbBIJAkDmNV4EHMYI2MmEDqBmDC4FqPg X-IronPort-AV: E=Sophos;i="4.87,485,1363132800"; d="scan'208,217";a="199055385" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 16 Apr 2013 10:51:50 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r3GApoB2023102 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Apr 2013 10:51:50 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.165]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Tue, 16 Apr 2013 05:51:50 -0500 From: "JP Vasseur (jvasseur)" To: "pce@ietf.org" Thread-Topic: Proposed updated Charter Thread-Index: AQHOOpBlJA65sxsSq0Kb8Jp++fZ8wA== Date: Tue, 16 Apr 2013 10:51:48 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772341EB38@xmb-rcd-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.228] Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A772341EB38xmbrcdx02ciscoc_" MIME-Version: 1.0 Subject: [Pce] Proposed updated Charter X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 10:51:56 -0000 --_000_03B78081B371D44390ED6E7BADBB4A772341EB38xmbrcdx02ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCkFzIGRpc2N1c3NlZCBpbiBPcmxhbmRvIGFuZCBhY2NvcmRpbmcgdG8gdGhl IGNvbnNlbnN1cyBpbiB0aGUgV0cgdG8gbW9kaWZ5IG91ciBjaGFydGVyLCBwbGVhc2UgZmluZCBh IHByb3Bvc2VkIHRleHQuDQoNClBsZWFzZSBjb21tZW50IGJ5IEFwcmlsIDMwdGguDQoNCkpQIGFu ZCBKdWxpZW4uDQoNCkRlc2NyaXB0aW9uIG9mIFdvcmtpbmcgR3JvdXANClRoZSBQQ0UgV29ya2lu ZyBHcm91cCBpcyBjaGFydGVyZWQgdG8gc3BlY2lmeSB0aGUgcmVxdWlyZWQgcHJvdG9jb2xzIHNv IOKAqGFzIHRvIGVuYWJsZSBhIFBhdGggQ29tcHV0YXRpb24gRWxlbWVudCAoUENFKS1iYXNlZCBh cmNoaXRlY3R1cmUgZm9yIHRoZSDigKhjb21wdXRhdGlvbiBvZiBwYXRocyBmb3IgTVBMUyBhbmQg R01QTFMgUG9pbnQgdG8gUG9pbnQgYW5kIFBvaW50IHRvIOKAqE11bHRpLXBvaW50IFRyYWZmaWMg RW5naW5lZXJlZCBMU1BzLiDigKjigKgNCkluIHRoaXMgYXJjaGl0ZWN0dXJlIHBhdGggY29tcHV0 YXRpb24gZG9lcyBub3QgbmVjZXNzYXJpbHkgb2NjdXIgb24gdGhlIOKAqGhlYWQtZW5kIChpbmdy ZXNzKSBMU1IsIGJ1dCBvbiBzb21lIG90aGVyIHBhdGggY29tcHV0YXRpb24gZW50aXR5IHRoYXQg 4oCobWF5IHBoeXNpY2FsbHkgbm90IGJlIGxvY2F0ZWQgb24gZWFjaCBoZWFkLWVuZCBMU1IuIOKA qOKAqA0KVGhlIFBDRSBXRyB3b3JrcyBvbiBhcHBsaWNhdGlvbiBvZiB0aGlzIG1vZGVsIHdpdGhp biBhIHNpbmdsZSBkb21haW4g4oCob3Igd2l0aGluIGEgZ3JvdXAgb2YgZG9tYWlucyAod2hlcmUg YSBkb21haW4gaXMgYSBsYXllciwgSUdQIGFyZWEgb3Ig4oCoQXV0b25vbW91cyBTeXN0ZW0gd2l0 aCBsaW1pdGVkIHZpc2liaWxpdHkgZnJvbSB0aGUgaGVhZC1lbmQgTFNSKS4gQXQg4oCodGhpcyB0 aW1lLCBhcHBseWluZyB0aGlzIG1vZGVsIHRvIGxhcmdlIGdyb3VwcyBvZiBkb21haW5zIHN1Y2gg YXMgdGhlIOKAqEludGVybmV0IGlzIG5vdCB0aG91Z2h0IHRvIGJlIHBvc3NpYmxlLCBhbmQgdGhl IFBDRSBXRyB3aWxsIG5vdCBzcGVuZCDigKhlbmVyZ3kgb24gdGhhdCB0b3BpYy4g4oCo4oCoVGhl IFdHIHNwZWNpZmllcyB0aGUgUENFIGNvbW11bmljYXRpb24gUHJvdG9jb2wgKFBDRVApIGFuZCBu ZWVkZWQg4oCoZXh0ZW5zaW9ucyBmb3IgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIExTUnMgKHRlcm1l ZCBQYXRoIENvbXB1dGF0aW9uIOKAqENsaWVudHMgLSBQQ0NzKSBhbmQgUENFcywgYW5kIGJldHdl ZW4gY29vcGVyYXRpbmcgUENFcy4gU2VjdXJpdHkg4oCobWVjaGFuaXNtcyBzdWNoIGFzIGF1dGhl bnRpY2F0aW9uIGFuZCBjb25maWRlbnRpYWxpdHkgYXJlIGluY2x1ZGVkLiDigKjigKhUaGUgV0cg ZGV0ZXJtaW5lcyByZXF1aXJlbWVudHMgZm9yIGV4dGVuc2lvbnMgdG8gZXhpc3Rpbmcgcm91dGlu ZyBhbmQg4oCoc2lnbmFsaW5nIHByb3RvY29scyBpbiBzdXBwb3J0IG9mIHRoZSBQQ0UgYXJjaGl0 ZWN0dXJlIGFuZCB0aGUgc2lnbmFsaW5nIOKAqG9mIGludGVyLWRvbWFpbiBwYXRocyAoZS5nLiBS U1ZQLVRFIGFuZCBpdHMgR01QTFMgdmFyaWF0aW9ucykuIEFueSDigKhuZWNlc3NhcnkgZXh0ZW5z aW9ucyB3aWxsIGJlIHByb2R1Y2VkIGluIGNvbGxhYm9yYXRpb24gd2l0aCB0aGUgV29ya2luZyDi gKhHcm91cHMgcmVzcG9uc2libGUgZm9yIHRoZSBwcm90b2NvbHMuIOKAqOKAqFRoZSBXRyBhbHNv IHdvcmtzIG9uIHRoZSBtZWNoYW5pc21zIHRvIGZvciBtdWx0aS1sYXllciBwYXRoIGNvbXB1dGF0 aW9uIOKAqGFuZCBQQ0VQIGV4dGVuc2lvbnMgZm9yIGNvbW11bmljYXRpb24gYmV0d2VlbiBzZXZl cmFsIG5ldHdvcmsgbGF5ZXJzLiDigKjigKhUaGUgV0cgZGVmaW5lcyB0aGUgcmVxdWlyZWQgUENF UCBleHRlbnNpb25zIGZvciBXYXZlbGVuZ3RoIFN3aXRjaGVkIOKAqE9wdGljYWwgTmV0d29ya3Mg KFdTT04pIHdoaWxlIGtlZXBpbmcgY29uc2lzdGVuY3kgd2l0aCB0aGUgR01QTFMg4oCoYXJjaGl0 ZWN0dXJlIHNwZWNpZmllZCBpbiB0aGUgQ0NBTVAgV0cuIOKAqOKAqA0KV29yayBJdGVtczog4oCo 4oCoDQotIFBDRVAgZXh0ZW5zaW9ucyBmb3IgTVBMUyBhbmQgR01QTFMgVHJhZmZpYyBFbmdpbmVl cmVkIExTUCBwYXRoIOKAqGNvbXB1dGF0aW9uIG1vZGVscyBpbnZvbHZpbmcgUENFKHMpLiBUaGlz IGluY2x1ZGVzIHRoZSBjYXNlIG9mIOKAqGNvbXB1dGluZyB0aGUgcGF0aHMgb2YgaW50cmEgYW5k IGludGVyLWRvbWFpbiBURSBMU1BzLiBTdWNoIHBhdGgg4oCoY29tcHV0YXRpb24gaW5jbHVkZXMg dGhlIGdlbmVyYXRpb24gb2YgcHJpbWFyeSwgcHJvdGVjdGlvbiBhbmQg4oCocmVjb3ZlcnkgcGF0 aHMsIGFzIHdlbGwgYXMgY29tcHV0YXRpb25zIGZvciAobG9jYWwvZ2xvYmFsKSDigKhyZW9wdGlt aXphdGlvbiBhbmQgbG9hZCBiYWxhbmNpbmcuIEJvdGggaW50cmEtIGFuZCBpbnRlci1kb21haW4g 4oCoYXBwbGljYXRpb25zIGFyZSBjb3ZlcmVkLiDigKgNCi0gSW4gY29vcGVyYXRpb24gd2l0aCBw cm90b2NvbCBzcGVjaWZpYyBXb3JraW5nIEdyb3VwIChlLmcuLCBNUExTLCDigKhDQ0FNUCksIGRl dmVsb3BtZW50IG9mIExTUCBzaWduYWxpbmcgKFJTVlAtVEUpIGV4dGVuc2lvbnMgcmVxdWlyZWQg 4oCodG8gc3VwcG9ydCBQQ0UtYmFzZWQgcGF0aCBjb21wdXRhdGlvbiBtb2RlbHMuIOKAqA0KLSBT cGVjaWZpY2F0aW9uIG9mIFBDRVAgZXh0ZW5zaW9ucyBmb3IgY29tbXVuaWNhdGlvbiBpbiB0aGUg dmFyaW91cyDigKhHTVBMUy1jb250cm9sbGVkIG5ldHdvcmtzLCBpbmNsdWRpbmcgV1NPTi4g4oCo DQotIERlZmluaXRpb24gb2YgUENFUCBleHRlbnNpb25zIGZvciBwYXRoIGNvbXB1dGF0aW9uIGlu IG11bHRpLWxheWVyIG5ldHdvcmtzLg0KLSBEZWZpbml0aW9uIG9mIHRoZSBQQ0VQIGV4dGVuc2lv bnMgdXNlZCBieSBhIHN0YXRlZnVsIFBDRSBmb3IgcmVjb21tZW5kaW5nIGEgbmV3IHBhdGggZm9y IGFuIGV4aXN0aW5nIG9yIG5ldyBMU1AgdG8gdGhlIFBDQy9QQ0UuIEZ1cnRoZXIgcHJvdG9jb2wg ZXh0ZW5zaW9ucyBtdXN0IGNvdmVyIHRoZSBjYXNlIHdoZXJlIHRoZSByZWNvbW1lbmRhdGlvbiBp cyBub3QgZm9sbG93ZWQgYnkgdGhlIFBDQy9QQ0UuDQpHb2FscyBhbmQgTWlsZXN0b25lcw0KQXBy aWwgMjAxMyAgU3VibWl0IHRoZSBHTVBMUyByZXF1aXJlbWVudHMgdG8gdGhlIElFU0cgdG8gYmUg Y29uc2lkZXJlZCBhcyBhbiBJbmZvcm1hdGlvbmFsIFJGQw0KU2VwdCAyMDEzICBTdWJtaXQgUENF UCBleHRlbnNpb25zIGZvciBHTVBMUyB0byB0aGUgSUVTRyB0byBiZSBjb25zaWRlcmVkIGFzIGEg UHJvcG9zZWQgU3RhbmRhcmQNClNlcHQgMjAxMyAgU3VibWl0IGludGVyLWFyZWEvQVMgYXBwbGlj YWJpbGl0eSBzdGF0ZW1lbnQgdG8gdGhlIElFU0cgYXMgYW4gSW5mb3JtYXRpb25hbCBSRkMNCk5v diAyMDEzICAgQWRvcHQgUENFUCBleHRlbnNpb25zIGZvciBoaWVyYXJjaGljYWwgUENFIHBhdGgg Y29tcHV0YXRpb24gbW9kZWwgYXMgV0cgZG9jdW1lbnQNCkphbiAyMDE0ICBTdWJtaXQgdGhlIFBD RVAgTUlCIHRvIHRoZSBJRVNHIHRvIGJlIGNvbnNpZGVyZWQgYXMgYSBQcm9wb3NlZCBTdGFuZGFy ZA0KRmViIDIwMTQgU3VibWl0IGludGVyLWxheWVyIFBDRVAgZXh0ZW5zaW9ucyB0byB0aGUgSUVT RyB0byBiZSBjb25zaWRlcmVkIGFzIGEgUHJvcG9zZWQgU3RhbmRhcmQNCkFwcmlsIDIwMTQgIEFk b3B0IFBDRVAgUDJNUCBNSUIgYXMgYSBXRyBkb2N1bWVudA0KQXByaWwgMjAxNCBTdWJtaXQgdGhl IFBDRSBEaXNjb3ZlcnkgTUlCIHRvIHRoZSBJRVNHIHRvIGJlIGNvbnNpZGVyZWQgYXMgYSBQcm9w b3NlZCBTdGFuZGFyZA0KQXByaWwgMjAxNCAgU3VibWl0IFBDRVAgUDJNUCBNSUIgdG8gdGhlIElF U0cgdG8gYmUgY29uc2lkZXJlZCBhcyBhIFByb3Bvc2VkIFN0YW5kYXJkDQpUQkQ6IEFERCBORVcg TUlMRVNUT05FUyBBQ0NPUkRJTkcgVE8gVEhFIE5FVyBDSEFSVEVSLg0KRmViIDIwMTUgICBFdmFs dWF0ZSBXRyBwcm9ncmVzcywgcmVjaGFydGVyIG9yIGNsb3NlDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQo= --_000_03B78081B371D44390ED6E7BADBB4A772341EB38xmbrcdx02ciscoc_ Content-Type: text/html; charset="utf-8" Content-ID: <2CF1A77B70089B4F924909FCB0A5A587@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgIj4NCkRlYXIgYWxsLA0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+QXMgZGlzY3Vzc2VkIGluIE9ybGFuZG8gYW5kIGFjY29yZGluZyB0byB0aGUgY29uc2Vu c3VzIGluIHRoZSBXRyB0byBtb2RpZnkgb3VyIGNoYXJ0ZXIsIHBsZWFzZSBmaW5kIGEgcHJvcG9z ZWQgdGV4dC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlBsZWFzZSBjb21tZW50IGJ5 IEFwcmlsIDMwdGguPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5KUCBhbmQgSnVsaWVu LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQogPG86T2ZmaWNlRG9jdW1lbnRTZXR0aW5ncz4NCiAgPG86QWxsb3dQTkcvPg0KIDwvbzpPZmZp Y2VEb2N1bWVudFNldHRpbmdzPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQogPHc6V29yZERvY3VtZW50Pg0KICA8dzpWaWV3Pk5vcm1hbDwvdzpWaWV3Pg0KICA8 dzpab29tPjA8L3c6Wm9vbT4NCiAgPHc6VHJhY2tNb3Zlcy8+DQogIDx3OlRyYWNrRm9ybWF0dGlu Zy8+DQogIDx3OlB1bmN0dWF0aW9uS2VybmluZy8+DQogIDx3OlZhbGlkYXRlQWdhaW5zdFNjaGVt YXMvPg0KICA8dzpTYXZlSWZYTUxJbnZhbGlkPmZhbHNlPC93OlNhdmVJZlhNTEludmFsaWQ+DQog IDx3Oklnbm9yZU1peGVkQ29udGVudD5mYWxzZTwvdzpJZ25vcmVNaXhlZENvbnRlbnQ+DQogIDx3 OkFsd2F5c1Nob3dQbGFjZWhvbGRlclRleHQ+ZmFsc2U8L3c6QWx3YXlzU2hvd1BsYWNlaG9sZGVy VGV4dD4NCiAgPHc6RG9Ob3RQcm9tb3RlUUYvPg0KICA8dzpMaWRUaGVtZU90aGVyPkVOLVVTPC93 OkxpZFRoZW1lT3RoZXI+DQogIDx3OkxpZFRoZW1lQXNpYW4+SkE8L3c6TGlkVGhlbWVBc2lhbj4N CiAgPHc6TGlkVGhlbWVDb21wbGV4U2NyaXB0PlgtTk9ORTwvdzpMaWRUaGVtZUNvbXBsZXhTY3Jp cHQ+DQogIDx3OkNvbXBhdGliaWxpdHk+DQogICA8dzpCcmVha1dyYXBwZWRUYWJsZXMvPg0KICAg PHc6U25hcFRvR3JpZEluQ2VsbC8+DQogICA8dzpXcmFwVGV4dFdpdGhQdW5jdC8+DQogICA8dzpV c2VBc2lhbkJyZWFrUnVsZXMvPg0KICAgPHc6RG9udEdyb3dBdXRvZml0Lz4NCiAgIDx3OlNwbGl0 UGdCcmVha0FuZFBhcmFNYXJrLz4NCiAgIDx3OkVuYWJsZU9wZW5UeXBlS2VybmluZy8+DQogICA8 dzpEb250RmxpcE1pcnJvckluZGVudHMvPg0KICAgPHc6T3ZlcnJpZGVUYWJsZVN0eWxlSHBzLz4N CiAgIDx3OlVzZUZFTGF5b3V0Lz4NCiAgPC93OkNvbXBhdGliaWxpdHk+DQogIDxtOm1hdGhQcj4N CiAgIDxtOm1hdGhGb250IG06dmFsPSJDYW1icmlhIE1hdGgiLz4NCiAgIDxtOmJya0JpbiBtOnZh bD0iYmVmb3JlIi8+DQogICA8bTpicmtCaW5TdWIgbTp2YWw9IiYjNDU7LSIvPg0KICAgPG06c21h bGxGcmFjIG06dmFsPSJvZmYiLz4NCiAgIDxtOmRpc3BEZWYvPg0KICAgPG06bE1hcmdpbiBtOnZh bD0iMCIvPg0KICAgPG06ck1hcmdpbiBtOnZhbD0iMCIvPg0KICAgPG06ZGVmSmMgbTp2YWw9ImNl bnRlckdyb3VwIi8+DQogICA8bTp3cmFwSW5kZW50IG06dmFsPSIxNDQwIi8+DQogICA8bTppbnRM aW0gbTp2YWw9InN1YlN1cCIvPg0KICAgPG06bmFyeUxpbSBtOnZhbD0idW5kT3ZyIi8+DQogIDwv bTptYXRoUHI+PC93OldvcmREb2N1bWVudD4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KIDx3OkxhdGVudFN0eWxlcyBEZWZMb2NrZWRTdGF0ZT0iZmFsc2UiIERl ZlVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICBEZWZTZW1pSGlkZGVuPSJ0cnVlIiBEZWZRRm9ybWF0 PSJmYWxzZSIgRGVmUHJpb3JpdHk9Ijk5Ig0KICBMYXRlbnRTdHlsZUNvdW50PSIyNzYiPg0KICA8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjAiIFNlbWlIaWRkZW49ImZh bHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJOb3Jt YWwiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBTZW1p SGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIg TmFtZT0iaGVhZGluZyAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyAyIi8+DQogIDx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVh ZGluZyAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIg UUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA1Ii8+ DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0i dHJ1ZSIgTmFtZT0iaGVhZGluZyA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA3Ii8+DQogIDx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFt ZT0iaGVhZGluZyA4Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA5Ii8+DQogIDx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyAxIi8+DQogIDx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyAyIi8+DQogIDx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyAzIi8+ DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRv YyA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5h bWU9InRvYyA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i MzkiIE5hbWU9InRvYyA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iMzkiIE5hbWU9InRvYyA3Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyA4Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyA5Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzUiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImNhcHRpb24i Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxMCIgU2VtaUhp ZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5h bWU9IlRpdGxlIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i MSIgTmFtZT0iRGVmYXVsdCBQYXJhZ3JhcGggRm9udCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjExIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iU3VidGl0bGUiLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIyMiIgU2VtaUhpZGRlbj0iZmFsc2Ui DQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlN0cm9uZyIv Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjIwIiBTZW1pSGlk ZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFt ZT0iRW1waGFzaXMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI1OSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 IlRhYmxlIEdyaWQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iUGxhY2Vob2xkZXIgVGV4dCIvPg0KICA8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjEiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJObyBTcGFjaW5nIi8+DQog IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIFNlbWlIaWRkZW49 ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBTaGFkaW5nIi8+ DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIFNlbWlIaWRk ZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBMaXN0Ii8+ DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIFNlbWlIaWRk ZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBHcmlkIi8+ DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIFNlbWlIaWRk ZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGlu ZyAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIFNl bWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0g U2hhZGluZyAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjUiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJN ZWRpdW0gTGlzdCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNjYiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1l PSJNZWRpdW0gTGlzdCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjciIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJNZWRpdW0gR3JpZCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjgiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBOYW1lPSJNZWRpdW0gR3JpZCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNjkiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNzAiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJEYXJrIExpc3QiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI3MSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmciLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIExpc3QiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIEdyaWQiLz4NCiAgPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDEiLz4NCiAgPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgU2VtaUhpZGRlbj0iZmFs c2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDEi Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgU2VtaUhp ZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IEdyaWQg QWNjZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 MyIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1l ZGl1bSBTaGFkaW5nIDEgQWNjZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDEiLz4NCiAg PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iUmV2aXNpb24iLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSIzNCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3Jt YXQ9InRydWUiIE5hbWU9Ikxpc3QgUGFyYWdyYXBoIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjkiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJRdW90ZSIvPg0KICA8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjMwIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAg IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iSW50ZW5zZSBRdW90 ZSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBTZW1p SGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExp c3QgMiBBY2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjY3IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjY4IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgMSIvPg0KICA8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJm YWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCAx Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIFNlbWlI aWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBT aGFkaW5nIEFjY2VudCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNzIiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNzMiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCAxIi8+DQogIDx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCAyIi8+DQog IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIFNlbWlIaWRkZW49 ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBMaXN0IEFjY2Vu dCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIFNl bWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBH cmlkIEFjY2VudCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNjMiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1l PSJNZWRpdW0gU2hhZGluZyAxIEFjY2VudCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjQiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCAyIi8+DQogIDx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIFNlbWlIaWRkZW49ImZhbHNlIg0K ICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCAyIi8+ DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIFNlbWlIaWRk ZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAy IEFjY2VudCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjciIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJN ZWRpdW0gR3JpZCAxIEFjY2VudCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNjgiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCAyIi8+DQogIDx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIFNlbWlIaWRkZW49ImZhbHNl Ig0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDIiLz4N CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgU2VtaUhpZGRl bj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIFNoYWRp bmcgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI3MiIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 IkNvbG9yZnVsIExpc3QgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI3MyIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDMiLz4NCiAgPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgU2VtaUhpZGRlbj0iZmFs c2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDMi Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgU2VtaUhp ZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IEdyaWQg QWNjZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 MyIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1l ZGl1bSBTaGFkaW5nIDEgQWNjZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDMiLz4NCiAg PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2VtaUhpZGRlbj0i ZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNj ZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIg U2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1 bSBHcmlkIDEgQWNjZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDMiLz4NCiAgPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgU2VtaUhpZGRlbj0iZmFsc2UiDQog ICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgMyIvPg0KICA8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlkZGVuPSJm YWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBB Y2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9Ijcy IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29s b3JmdWwgTGlzdCBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgNCIvPg0KICA8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlkZGVuPSJmYWxzZSIN CiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgNCIvPg0K ICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1pSGlkZGVu PSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgR3JpZCBBY2Nl bnQgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBT ZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVt IFNoYWRpbmcgMSBBY2NlbnQgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjY0IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgNCIvPg0KICA8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBTZW1pSGlkZGVuPSJmYWxz ZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQg NCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBTZW1p SGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdy aWQgMSBBY2NlbnQgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjY4IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjY5IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgNCIvPg0KICA8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCA0Ii8+DQogIDx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIFNlbWlIaWRkZW49ImZhbHNl Ig0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2Vu dCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIFNl bWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1 bCBMaXN0IEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNzMiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjAiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCA1Ii8+DQogIDx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIFNlbWlIaWRkZW49ImZh bHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCA1 Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIFNlbWlI aWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hh ZGluZyAxIEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjQiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIFNlbWlIaWRkZW49ImZhbHNlIg0K ICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCA1Ii8+ DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIFNlbWlIaWRk ZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAx IEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjgiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJN ZWRpdW0gR3JpZCAyIEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNjkiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgU2VtaUhpZGRlbj0iZmFsc2UiDQog ICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDUi Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgU2VtaUhp ZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIExp c3QgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI3MyIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 IkNvbG9yZnVsIEdyaWQgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDYiLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgU2VtaUhpZGRlbj0iZmFsc2Ui DQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDYiLz4N CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgU2VtaUhpZGRl bj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5n IDEgQWNjZW50IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNl ZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDYiLz4NCiAgPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDYiLz4NCiAg PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgU2VtaUhpZGRlbj0i ZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNj ZW50IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIg U2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1 bSBHcmlkIDIgQWNjZW50IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2OSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgNiIvPg0K ICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBTZW1pSGlkZGVu PSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgTGlzdCBB Y2NlbnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9Ijcz IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29s b3JmdWwgR3JpZCBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjE5IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iU3VidGxlIEVtcGhhc2lzIi8+DQogIDx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjEiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJJbnRlbnNlIEVtcGhh c2lzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzEiIFNl bWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVl IiBOYW1lPSJTdWJ0bGUgUmVmZXJlbmNlIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iMzIiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJJbnRlbnNlIFJlZmVyZW5jZSIvPg0KICA8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjMzIiBTZW1pSGlkZGVuPSJmYWxz ZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iQm9vayBU aXRsZSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM3IiBO YW1lPSJCaWJsaW9ncmFwaHkiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSIzOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iVE9DIEhlYWRpbmciLz4NCiA8L3c6TGF0 ZW50U3R5bGVzPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDEwXT4NCjxzdHls ZT4NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KdGFibGUuTXNvTm9ybWFsVGFibGUNCgl7bXNv LXN0eWxlLW5hbWU6IlRhYmxlIE5vcm1hbCI7DQoJbXNvLXRzdHlsZS1yb3diYW5kLXNpemU6MDsN Cgltc28tdHN0eWxlLWNvbGJhbmQtc2l6ZTowOw0KCW1zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtcGFyZW50OiIiOw0KCW1zby1wYWRkaW5n LWFsdDowaW4gNS40cHQgMGluIDUuNHB0Ow0KCW1zby1wYXJhLW1hcmdpbi10b3A6MGluOw0KCW1z by1wYXJhLW1hcmdpbi1yaWdodDowaW47DQoJbXNvLXBhcmEtbWFyZ2luLWJvdHRvbToxMC4wcHQ7 DQoJbXNvLXBhcmEtbWFyZ2luLWxlZnQ6MGluOw0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhh bjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OkNhbWJyaWE7DQoJbXNvLWFzY2lp LWZvbnQtZmFtaWx5OkNhbWJyaWE7DQoJbXNvLWFzY2lpLXRoZW1lLWZvbnQ6bWlub3ItbGF0aW47 DQoJbXNvLWhhbnNpLWZvbnQtZmFtaWx5OkNhbWJyaWE7DQoJbXNvLWhhbnNpLXRoZW1lLWZvbnQ6 bWlub3ItbGF0aW47DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6SkE7fQ0KPC9zdHlsZT4NCjwhW2Vu ZGlmXS0tPjwhLS1TdGFydEZyYWdtZW50LS0+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxNi4wcHQ7bXNvLXBhZ2luYXRpb246bm9uZTttc28tbGF5b3V0LWdyaWQt YWxpZ246DQpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToyMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWwiPkRlc2NyaXB0aW9uIG9mIFdvcmtpbmcgR3Jv dXA8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTMuMHB0O21zby1wYWdpbmF0aW9uOm5vbmU7bXNvLWxheW91dC1ncmlk LWFsaWduOg0Kbm9uZTt0ZXh0LWF1dG9zcGFjZTpub25lIj4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsIj5UaGUgUENFIFdvcmtpbmcgR3JvdXAgaXMgY2hh cnRlcmVkIHRvIHNwZWNpZnkgdGhlIHJlcXVpcmVkIHByb3RvY29scyBzbyDigKhhcyB0byBlbmFi bGUgYSBQYXRoIENvbXB1dGF0aW9uIEVsZW1lbnQgKFBDRSktYmFzZWQgYXJjaGl0ZWN0dXJlIGZv ciB0aGUg4oCoY29tcHV0YXRpb24gb2YgcGF0aHMgZm9yIE1QTFMgYW5kIEdNUExTIFBvaW50IHRv IFBvaW50IGFuZCBQb2ludA0KIHRvIOKAqE11bHRpLXBvaW50IFRyYWZmaWMgRW5naW5lZXJlZCBM U1BzLiDigKjigKg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMy4wcHQ7bXNvLXBhZ2luYXRpb246bm9uZTttc28tbGF5b3V0 LWdyaWQtYWxpZ246DQpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6QXJpYWwiPkluIHRoaXMgYXJjaGl0ZWN0dXJlIHBh dGggY29tcHV0YXRpb24gZG9lcyBub3QgbmVjZXNzYXJpbHkgb2NjdXIgb24gdGhlIOKAqGhlYWQt ZW5kIChpbmdyZXNzKSBMU1IsIGJ1dCBvbiBzb21lIG90aGVyIHBhdGggY29tcHV0YXRpb24gZW50 aXR5IHRoYXQg4oCobWF5IHBoeXNpY2FsbHkgbm90IGJlIGxvY2F0ZWQgb24gZWFjaCBoZWFkLWVu ZCBMU1IuIOKAqOKAqDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEzLjBwdDttc28tcGFnaW5hdGlvbjpub25lO21zby1sYXlv dXQtZ3JpZC1hbGlnbjoNCm5vbmU7dGV4dC1hdXRvc3BhY2U6bm9uZSI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpBcmlhbCI+VGhlIFBDRSBXRyB3b3JrcyBvbiBh cHBsaWNhdGlvbiBvZiB0aGlzIG1vZGVsIHdpdGhpbiBhIHNpbmdsZSBkb21haW4g4oCob3Igd2l0 aGluIGEgZ3JvdXAgb2YgZG9tYWlucyAod2hlcmUgYSBkb21haW4gaXMgYSBsYXllciwgSUdQIGFy ZWEgb3Ig4oCoQXV0b25vbW91cyBTeXN0ZW0gd2l0aCBsaW1pdGVkIHZpc2liaWxpdHkgZnJvbSB0 aGUgaGVhZC1lbmQgTFNSKS4gQXQNCiDigKh0aGlzIHRpbWUsIGFwcGx5aW5nIHRoaXMgbW9kZWwg dG8gbGFyZ2UgZ3JvdXBzIG9mIGRvbWFpbnMgc3VjaCBhcyB0aGUg4oCoSW50ZXJuZXQgaXMgbm90 IHRob3VnaHQgdG8gYmUgcG9zc2libGUsIGFuZCB0aGUgUENFIFdHIHdpbGwgbm90IHNwZW5kIOKA qGVuZXJneSBvbiB0aGF0IHRvcGljLiDigKjigKhUaGUgV0cgc3BlY2lmaWVzIHRoZSBQQ0UgY29t bXVuaWNhdGlvbiBQcm90b2NvbCAoUENFUCkgYW5kIG5lZWRlZCDigKhleHRlbnNpb25zIGZvciBj b21tdW5pY2F0aW9uDQogYmV0d2VlbiBMU1JzICh0ZXJtZWQgUGF0aCBDb21wdXRhdGlvbiDigKhD bGllbnRzIC0gUENDcykgYW5kIFBDRXMsIGFuZCBiZXR3ZWVuIGNvb3BlcmF0aW5nIFBDRXMuIFNl Y3VyaXR5IOKAqG1lY2hhbmlzbXMgc3VjaCBhcyBhdXRoZW50aWNhdGlvbiBhbmQgY29uZmlkZW50 aWFsaXR5IGFyZSBpbmNsdWRlZC4g4oCo4oCoVGhlIFdHIGRldGVybWluZXMgcmVxdWlyZW1lbnRz IGZvciBleHRlbnNpb25zIHRvIGV4aXN0aW5nIHJvdXRpbmcgYW5kIOKAqHNpZ25hbGluZw0KIHBy b3RvY29scyBpbiBzdXBwb3J0IG9mIHRoZSBQQ0UgYXJjaGl0ZWN0dXJlIGFuZCB0aGUgc2lnbmFs aW5nIOKAqG9mIGludGVyLWRvbWFpbiBwYXRocyAoZS5nLiBSU1ZQLVRFIGFuZCBpdHMgR01QTFMg dmFyaWF0aW9ucykuIEFueSDigKhuZWNlc3NhcnkgZXh0ZW5zaW9ucyB3aWxsIGJlIHByb2R1Y2Vk IGluIGNvbGxhYm9yYXRpb24gd2l0aCB0aGUgV29ya2luZyDigKhHcm91cHMgcmVzcG9uc2libGUg Zm9yIHRoZSBwcm90b2NvbHMuIOKAqOKAqFRoZSBXRyBhbHNvDQogd29ya3Mgb24gdGhlIG1lY2hh bmlzbXMgdG8gZm9yIG11bHRpLWxheWVyIHBhdGggY29tcHV0YXRpb24g4oCoYW5kIFBDRVAgZXh0 ZW5zaW9ucyBmb3IgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIHNldmVyYWwgbmV0d29yayBsYXllcnMu IOKAqOKAqFRoZSBXRyBkZWZpbmVzIHRoZSByZXF1aXJlZCBQQ0VQIGV4dGVuc2lvbnMgZm9yIFdh dmVsZW5ndGggU3dpdGNoZWQg4oCoT3B0aWNhbCBOZXR3b3JrcyAoV1NPTikgd2hpbGUga2VlcGlu ZyBjb25zaXN0ZW5jeSB3aXRoDQogdGhlIEdNUExTIOKAqGFyY2hpdGVjdHVyZSBzcGVjaWZpZWQg aW4gdGhlIENDQU1QIFdHLiDigKjigKg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMy4wcHQ7bXNvLXBhZ2luYXRpb246bm9u ZTttc28tbGF5b3V0LWdyaWQtYWxpZ246DQpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6QXJpYWwiPldvcmsgSXRlbXM6 IOKAqOKAqDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEzLjBwdDttc28tcGFnaW5hdGlvbjpub25lO21zby1sYXlvdXQtZ3Jp ZC1hbGlnbjoNCm5vbmU7dGV4dC1hdXRvc3BhY2U6bm9uZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpBcmlhbCI+LSBQQ0VQIGV4dGVuc2lvbnMgZm9yIE1QTFMg YW5kIEdNUExTIFRyYWZmaWMgRW5naW5lZXJlZCBMU1AgcGF0aCDigKhjb21wdXRhdGlvbiBtb2Rl bHMgaW52b2x2aW5nIFBDRShzKS4gVGhpcyBpbmNsdWRlcyB0aGUgY2FzZSBvZiDigKhjb21wdXRp bmcgdGhlIHBhdGhzIG9mIGludHJhIGFuZCBpbnRlci1kb21haW4gVEUgTFNQcy4gU3VjaCBwYXRo IOKAqGNvbXB1dGF0aW9uDQogaW5jbHVkZXMgdGhlIGdlbmVyYXRpb24gb2YgcHJpbWFyeSwgcHJv dGVjdGlvbiBhbmQg4oCocmVjb3ZlcnkgcGF0aHMsIGFzIHdlbGwgYXMgY29tcHV0YXRpb25zIGZv ciAobG9jYWwvZ2xvYmFsKSDigKhyZW9wdGltaXphdGlvbiBhbmQgbG9hZCBiYWxhbmNpbmcuIEJv dGggaW50cmEtIGFuZCBpbnRlci1kb21haW4g4oCoYXBwbGljYXRpb25zIGFyZSBjb3ZlcmVkLiDi gKg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMy4wcHQ7bXNvLXBhZ2luYXRpb246bm9uZTttc28tbGF5b3V0LWdyaWQtYWxp Z246DQpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6QXJpYWwiPi0gSW4gY29vcGVyYXRpb24gd2l0aCBwcm90b2NvbCBz cGVjaWZpYyBXb3JraW5nIEdyb3VwIChlLmcuLCBNUExTLCDigKhDQ0FNUCksIGRldmVsb3BtZW50 IG9mIExTUCBzaWduYWxpbmcgKFJTVlAtVEUpIGV4dGVuc2lvbnMgcmVxdWlyZWQg4oCodG8gc3Vw cG9ydCBQQ0UtYmFzZWQgcGF0aCBjb21wdXRhdGlvbiBtb2RlbHMuIOKAqDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEzLjBw dDttc28tcGFnaW5hdGlvbjpub25lO21zby1sYXlvdXQtZ3JpZC1hbGlnbjoNCm5vbmU7dGV4dC1h dXRvc3BhY2U6bm9uZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpBcmlhbCI+LSBTcGVjaWZpY2F0aW9uIG9mIFBDRVAgZXh0ZW5zaW9ucyBmb3IgY29tbXVuaWNh dGlvbiBpbiB0aGUgdmFyaW91cyDigKhHTVBMUy1jb250cm9sbGVkIG5ldHdvcmtzLCBpbmNsdWRp bmcgV1NPTi4g4oCoPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTMuMHB0O21zby1wYWdpbmF0aW9uOm5vbmU7bXNvLWxheW91 dC1ncmlkLWFsaWduOg0Kbm9uZTt0ZXh0LWF1dG9zcGFjZTpub25lIj4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsIj4tIERlZmluaXRpb24gb2YgUENFUCBl eHRlbnNpb25zIGZvciBwYXRoIGNvbXB1dGF0aW9uIGluIG11bHRpLWxheWVyIG5ldHdvcmtzLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEzLjBwdDttc28tcGFnaW5hdGlvbjpub25lO21zby1sYXlvdXQtZ3JpZC1hbGlnbjoN Cm5vbmU7dGV4dC1hdXRvc3BhY2U6bm9uZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpBcmlhbCI+LSBEZWZpbml0aW9uIG9mIHRoZSBQQ0VQIGV4dGVuc2lvbnMg dXNlZCBieSBhIHN0YXRlZnVsIFBDRSBmb3IgcmVjb21tZW5kaW5nIGEgbmV3IHBhdGggZm9yIGFu IGV4aXN0aW5nIG9yIG5ldyBMU1AgdG8gdGhlIFBDQy9QQ0UuIEZ1cnRoZXIgcHJvdG9jb2wgZXh0 ZW5zaW9ucyBtdXN0IGNvdmVyIHRoZSBjYXNlIHdoZXJlIHRoZSByZWNvbW1lbmRhdGlvbiBpcyBu b3QNCiBmb2xsb3dlZCBieSB0aGUgUENDL1BDRS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMy4wcHQ7bXNvLXBhZ2luYXRp b246bm9uZTttc28tbGF5b3V0LWdyaWQtYWxpZ246DQpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUi Pg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToyMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWwiPkdv YWxzIGFuZCBNaWxlc3RvbmVzPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpBcmlhbCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTMuMHB0O21zby1wYWdpbmF0aW9uOm5vbmU7 bXNvLWxheW91dC1ncmlkLWFsaWduOg0Kbm9uZTt0ZXh0LWF1dG9zcGFjZTpub25lIj4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsIj5BcHJpbCAyMDEzPHNw YW4gc3R5bGU9Im1zby1zcGFjZXJ1bjp5ZXMiPiZuYnNwOw0KPC9zcGFuPlN1Ym1pdCB0aGUgR01Q TFMgcmVxdWlyZW1lbnRzIHRvIHRoZSBJRVNHIHRvIGJlIGNvbnNpZGVyZWQgYXMgYW4gSW5mb3Jt YXRpb25hbCBSRkM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMy4wcHQ7bXNvLXBhZ2luYXRpb246bm9uZTttc28tbGF5b3V0 LWdyaWQtYWxpZ246DQpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6QXJpYWwiPlNlcHQgMjAxMzxzcGFuIHN0eWxlPSJt c28tc3BhY2VydW46eWVzIj4mbmJzcDsNCjwvc3Bhbj5TdWJtaXQgUENFUCBleHRlbnNpb25zIGZv ciBHTVBMUyB0byB0aGUgSUVTRyB0byBiZSBjb25zaWRlcmVkIGFzIGEgUHJvcG9zZWQgU3RhbmRh cmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMy4wcHQ7bXNvLXBhZ2luYXRpb246bm9uZTttc28tbGF5b3V0LWdyaWQtYWxp Z246DQpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6QXJpYWwiPlNlcHQgMjAxMzxzcGFuIHN0eWxlPSJtc28tc3BhY2Vy dW46eWVzIj4mbmJzcDsNCjwvc3Bhbj5TdWJtaXQgaW50ZXItYXJlYS9BUyBhcHBsaWNhYmlsaXR5 IHN0YXRlbWVudCB0byB0aGUgSUVTRyBhcyBhbiBJbmZvcm1hdGlvbmFsIFJGQzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEz LjBwdDttc28tcGFnaW5hdGlvbjpub25lO21zby1sYXlvdXQtZ3JpZC1hbGlnbjoNCm5vbmU7dGV4 dC1hdXRvc3BhY2U6bm9uZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpBcmlhbCI+Tm92IDIwMTMgPHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjp5ZXMiPg0KJm5i c3A7Jm5ic3A7PC9zcGFuPkFkb3B0IFBDRVAgZXh0ZW5zaW9ucyBmb3IgaGllcmFyY2hpY2FsIFBD RSBwYXRoIGNvbXB1dGF0aW9uIG1vZGVsIGFzIFdHIGRvY3VtZW50PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTMuMHB0O21z by1wYWdpbmF0aW9uOm5vbmU7bXNvLWxheW91dC1ncmlkLWFsaWduOg0Kbm9uZTt0ZXh0LWF1dG9z cGFjZTpub25lIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkFy aWFsIj5KYW4gMjAxNDxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46eWVzIj4mbmJzcDsNCjwvc3Bh bj5TdWJtaXQgdGhlIFBDRVAgTUlCIHRvIHRoZSBJRVNHIHRvIGJlIGNvbnNpZGVyZWQgYXMgYSBQ cm9wb3NlZCBTdGFuZGFyZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEzLjBwdDttc28tcGFnaW5hdGlvbjpub25lO21zby1s YXlvdXQtZ3JpZC1hbGlnbjoNCm5vbmU7dGV4dC1hdXRvc3BhY2U6bm9uZSI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpBcmlhbCI+RmViIDIwMTQgU3VibWl0IGlu dGVyLWxheWVyIFBDRVAgZXh0ZW5zaW9ucyB0byB0aGUgSUVTRyB0byBiZSBjb25zaWRlcmVkIGFz IGEgUHJvcG9zZWQgU3RhbmRhcmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMy4wcHQ7bXNvLXBhZ2luYXRpb246bm9uZTtt c28tbGF5b3V0LWdyaWQtYWxpZ246DQpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6QXJpYWwiPkFwcmlsIDIwMTQgPHNw YW4gc3R5bGU9Im1zby1zcGFjZXJ1bjp5ZXMiPg0KJm5ic3A7PC9zcGFuPkFkb3B0IFBDRVAgUDJN UCBNSUIgYXMgYSBXRyBkb2N1bWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEzLjBwdDttc28tcGFnaW5hdGlvbjpub25l O21zby1sYXlvdXQtZ3JpZC1hbGlnbjoNCm5vbmU7dGV4dC1hdXRvc3BhY2U6bm9uZSI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpBcmlhbCI+QXByaWwgMjAxNCBT dWJtaXQgdGhlIFBDRSBEaXNjb3ZlcnkgTUlCIHRvIHRoZSBJRVNHIHRvIGJlIGNvbnNpZGVyZWQg YXMgYSBQcm9wb3NlZCBTdGFuZGFyZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEzLjBwdDttc28tcGFnaW5hdGlvbjpub25l O21zby1sYXlvdXQtZ3JpZC1hbGlnbjoNCm5vbmU7dGV4dC1hdXRvc3BhY2U6bm9uZSI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpBcmlhbCI+QXByaWwgMjAxNDxz cGFuIHN0eWxlPSJtc28tc3BhY2VydW46eWVzIj4mbmJzcDsNCjwvc3Bhbj5TdWJtaXQgUENFUCBQ Mk1QIE1JQiB0byB0aGUgSUVTRyB0byBiZSBjb25zaWRlcmVkIGFzIGEgUHJvcG9zZWQgU3RhbmRh cmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMy4wcHQ7bXNvLXBhZ2luYXRpb246bm9uZTttc28tbGF5b3V0LWdyaWQtYWxp Z246DQpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6QXJpYWwiPlRCRDogQUREIE5FVyBNSUxFU1RPTkVTIEFDQ09SRElO RyBUTyBUSEUgTkVXIENIQVJURVIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTMuMHB0O21zby1wYWdpbmF0aW9uOm5vbmU7 bXNvLWxheW91dC1ncmlkLWFsaWduOg0Kbm9uZTt0ZXh0LWF1dG9zcGFjZTpub25lIj4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsIj5GZWIgMjAxNSA8c3Bh biBzdHlsZT0ibXNvLXNwYWNlcnVuOnllcyI+DQombmJzcDsmbmJzcDs8L3NwYW4+RXZhbHVhdGUg V0cgcHJvZ3Jlc3MsIHJlY2hhcnRlciBvciBjbG9zZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEzLjBwdDttc28tcGFnaW5h dGlvbjpub25lO21zby1sYXlvdXQtZ3JpZC1hbGlnbjoNCm5vbmU7dGV4dC1hdXRvc3BhY2U6bm9u ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpBcmlhbCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTMuMHB0O21zby1wYWdpbmF0aW9uOm5vbmU7bXNvLWxheW91dC1ncmlkLWFs aWduOg0Kbm9uZTt0ZXh0LWF1dG9zcGFjZTpub25lIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMy4wcHQ7bXNvLXBhZ2lu YXRpb246bm9uZTttc28tbGF5b3V0LWdyaWQtYWxpZ246DQpub25lO3RleHQtYXV0b3NwYWNlOm5v bmUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy4wcHQ7Zm9udC1mYW1pbHk6QXJpYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUi IGJvcmRlcj0iMSIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iNzMwIiBz dHlsZT0iYm9yZGVyLWNvbGxhcHNlOmNvbGxhcHNlO21zby10YWJsZS1sYXlvdXQtYWx0OmZpeGVk O2JvcmRlcjpub25lOw0KIG1zby1wYWRkaW5nLWFsdDowaW4gNS40cHQgMGluIDUuNHB0Ij4NCjx0 Ym9keT4NCjx0ciBzdHlsZT0ibXNvLXlmdGktaXJvdzowO21zby15ZnRpLWZpcnN0cm93OnllcyI+ DQo8dGQgd2lkdGg9IjgwIiBzdHlsZT0id2lkdGg6ODAuMHB0O2JvcmRlcjpub25lO3BhZGRpbmc6 MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbTowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O21zby1wYWdpbmF0aW9uOg0KICBub25l O21zby1sYXlvdXQtZ3JpZC1hbGlnbjpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToNCiAgMTMuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI2NTAiIHN0eWxlPSJ3aWR0aDo2 NTAuMHB0O2JvcmRlcjpub25lO3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWJvdHRvbTouMDAw MXB0O21zby1wYWdpbmF0aW9uOg0KICBub25lO21zby1sYXlvdXQtZ3JpZC1hbGlnbjpub25lO3Rl eHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToNCiAgMTMuMHB0O2Zv bnQtZmFtaWx5OkFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90 cj4NCjx0ciBzdHlsZT0ibXNvLXlmdGktaXJvdzoxIj4NCjx0ZCB3aWR0aD0iODAiIHN0eWxlPSJ3 aWR0aDo4MC4wcHQ7Ym9yZGVyOm5vbmU7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tYm90dG9t Oi4wMDAxcHQ7bXNvLXBhZ2luYXRpb246DQogIG5vbmU7bXNvLWxheW91dC1ncmlkLWFsaWduOm5v bmU7dGV4dC1hdXRvc3BhY2U6bm9uZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOg0KICAxMy4w cHQ7Zm9udC1mYW1pbHk6QXJpYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+ DQo8dGQgd2lkdGg9IjY1MCIgc3R5bGU9IndpZHRoOjY1MC4wcHQ7Ym9yZGVyOm5vbmU7cGFkZGlu ZzowaW4gNS40cHQgMGluIDUuNHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQ7bXNvLXBhZ2luYXRpb246DQogIG5v bmU7bXNvLWxheW91dC1ncmlkLWFsaWduOm5vbmU7dGV4dC1hdXRvc3BhY2U6bm9uZSI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOg0KICAxMy4wcHQ7Zm9udC1mYW1pbHk6QXJpYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyIHN0eWxlPSJtc28teWZ0aS1p cm93OjIiPg0KPHRkIHdpZHRoPSI4MCIgc3R5bGU9IndpZHRoOjgwLjBwdDtib3JkZXI6bm9uZTtw YWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MGluO21hcmdpbi1ib3R0b206LjAwMDFwdDttc28tcGFnaW5hdGlvbjoN CiAgbm9uZTttc28tbGF5b3V0LWdyaWQtYWxpZ246bm9uZTt0ZXh0LWF1dG9zcGFjZTpub25lIj4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6DQogIDEzLjBwdDtmb250LWZhbWlseTpBcmlhbCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNjUwIiBzdHlsZT0i d2lkdGg6NjUwLjBwdDtib3JkZXI6bm9uZTtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MGluO21hcmdpbi1ib3R0 b206LjAwMDFwdDttc28tcGFnaW5hdGlvbjoNCiAgbm9uZTttc28tbGF5b3V0LWdyaWQtYWxpZ246 bm9uZTt0ZXh0LWF1dG9zcGFjZTpub25lIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6DQogIDEz LjBwdDtmb250LWZhbWlseTpBcmlhbCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC90 ZD4NCjwvdHI+DQo8dHIgc3R5bGU9Im1zby15ZnRpLWlyb3c6MyI+DQo8dGQgd2lkdGg9IjgwIiBz dHlsZT0id2lkdGg6ODAuMHB0O2JvcmRlcjpub25lO3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTowaW47bWFyZ2lu LWJvdHRvbTouMDAwMXB0O21zby1wYWdpbmF0aW9uOg0KICBub25lO21zby1sYXlvdXQtZ3JpZC1h bGlnbjpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToN CiAgMTMuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L3RkPg0KPHRkIHdpZHRoPSI2NTAiIHN0eWxlPSJ3aWR0aDo2NTAuMHB0O2JvcmRlcjpub25l O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O21zby1wYWdpbmF0aW9u Og0KICBub25lO21zby1sYXlvdXQtZ3JpZC1hbGlnbjpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToNCiAgMTMuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0ibXNv LXlmdGktaXJvdzo0Ij4NCjx0ZCB3aWR0aD0iODAiIHN0eWxlPSJ3aWR0aDo4MC4wcHQ7Ym9yZGVy Om5vbmU7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQ7bXNvLXBhZ2lu YXRpb246DQogIG5vbmU7bXNvLWxheW91dC1ncmlkLWFsaWduOm5vbmU7dGV4dC1hdXRvc3BhY2U6 bm9uZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOg0KICAxMy4wcHQ7Zm9udC1mYW1pbHk6QXJp YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjY1MCIg c3R5bGU9IndpZHRoOjY1MC4wcHQ7Ym9yZGVyOm5vbmU7cGFkZGluZzowaW4gNS40cHQgMGluIDUu NHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjBpbjttYXJn aW4tYm90dG9tOi4wMDAxcHQ7bXNvLXBhZ2luYXRpb246DQogIG5vbmU7bXNvLWxheW91dC1ncmlk LWFsaWduOm5vbmU7dGV4dC1hdXRvc3BhY2U6bm9uZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl Og0KICAxMy4wcHQ7Zm9udC1mYW1pbHk6QXJpYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvdGQ+DQo8L3RyPg0KPHRyIHN0eWxlPSJtc28teWZ0aS1pcm93OjUiPg0KPHRkIHdpZHRo PSI4MCIgc3R5bGU9IndpZHRoOjgwLjBwdDtib3JkZXI6bm9uZTtwYWRkaW5nOjBpbiA1LjRwdCAw aW4gNS40cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MGlu O21hcmdpbi1ib3R0b206LjAwMDFwdDttc28tcGFnaW5hdGlvbjoNCiAgbm9uZTttc28tbGF5b3V0 LWdyaWQtYWxpZ246bm9uZTt0ZXh0LWF1dG9zcGFjZTpub25lIj4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6DQogIDEzLjBwdDtmb250LWZhbWlseTpBcmlhbCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNjUwIiBzdHlsZT0id2lkdGg6NjUwLjBwdDtib3Jk ZXI6bm9uZTtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MGluO21hcmdpbi1ib3R0b206LjAwMDFwdDttc28tcGFn aW5hdGlvbjoNCiAgbm9uZTttc28tbGF5b3V0LWdyaWQtYWxpZ246bm9uZTt0ZXh0LWF1dG9zcGFj ZTpub25lIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6DQogIDEzLjBwdDtmb250LWZhbWlseTpB cmlhbCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5 bGU9Im1zby15ZnRpLWlyb3c6NiI+DQo8dGQgd2lkdGg9IjgwIiBzdHlsZT0id2lkdGg6ODAuMHB0 O2JvcmRlcjpub25lO3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O21z by1wYWdpbmF0aW9uOg0KICBub25lO21zby1sYXlvdXQtZ3JpZC1hbGlnbjpub25lO3RleHQtYXV0 b3NwYWNlOm5vbmUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToNCiAgMTMuMHB0O2ZvbnQtZmFt aWx5OkFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHdpZHRo PSI2NTAiIHN0eWxlPSJ3aWR0aDo2NTAuMHB0O2JvcmRlcjpub25lO3BhZGRpbmc6MGluIDUuNHB0 IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTow aW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O21zby1wYWdpbmF0aW9uOg0KICBub25lO21zby1sYXlv dXQtZ3JpZC1hbGlnbjpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToNCiAgMTMuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0ibXNvLXlmdGktaXJvdzo3Ij4NCjx0 ZCB3aWR0aD0iODAiIHN0eWxlPSJ3aWR0aDo4MC4wcHQ7Ym9yZGVyOm5vbmU7cGFkZGluZzowaW4g NS40cHQgMGluIDUuNHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQ7bXNvLXBhZ2luYXRpb246DQogIG5vbmU7bXNv LWxheW91dC1ncmlkLWFsaWduOm5vbmU7dGV4dC1hdXRvc3BhY2U6bm9uZSI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOg0KICAxMy4wcHQ7Zm9udC1mYW1pbHk6QXJpYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjY1MCIgc3R5bGU9IndpZHRoOjY1MC4w cHQ7Ym9yZGVyOm5vbmU7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQ7 bXNvLXBhZ2luYXRpb246DQogIG5vbmU7bXNvLWxheW91dC1ncmlkLWFsaWduOm5vbmU7dGV4dC1h dXRvc3BhY2U6bm9uZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOg0KICAxMy4wcHQ7Zm9udC1m YW1pbHk6QXJpYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0K PHRyIHN0eWxlPSJtc28teWZ0aS1pcm93OjgiPg0KPHRkIHdpZHRoPSI4MCIgc3R5bGU9IndpZHRo OjgwLjBwdDtib3JkZXI6bm9uZTtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MGluO21hcmdpbi1ib3R0b206LjAw MDFwdDttc28tcGFnaW5hdGlvbjoNCiAgbm9uZTttc28tbGF5b3V0LWdyaWQtYWxpZ246bm9uZTt0 ZXh0LWF1dG9zcGFjZTpub25lIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6DQogIDEzLjBwdDtm b250LWZhbWlseTpBcmlhbCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjx0 ZCB3aWR0aD0iNjUwIiBzdHlsZT0id2lkdGg6NjUwLjBwdDtib3JkZXI6bm9uZTtwYWRkaW5nOjBp biA1LjRwdCAwaW4gNS40cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MGluO21hcmdpbi1ib3R0b206LjAwMDFwdDttc28tcGFnaW5hdGlvbjoNCiAgbm9uZTtt c28tbGF5b3V0LWdyaWQtYWxpZ246bm9uZTt0ZXh0LWF1dG9zcGFjZTpub25lIj4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6DQogIDEzLjBwdDtmb250LWZhbWlseTpBcmlhbCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9Im1zby15ZnRpLWlyb3c6 OSI+DQo8dGQgd2lkdGg9IjgwIiBzdHlsZT0id2lkdGg6ODAuMHB0O2JvcmRlcjpub25lO3BhZGRp bmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbTowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O21zby1wYWdpbmF0aW9uOg0KICBu b25lO21zby1sYXlvdXQtZ3JpZC1hbGlnbjpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToNCiAgMTMuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI2NTAiIHN0eWxlPSJ3aWR0 aDo2NTAuMHB0O2JvcmRlcjpub25lO3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWJvdHRvbTou MDAwMXB0O21zby1wYWdpbmF0aW9uOg0KICBub25lO21zby1sYXlvdXQtZ3JpZC1hbGlnbjpub25l O3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToNCiAgMTMuMHB0 O2ZvbnQtZmFtaWx5OkFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0K PC90cj4NCjx0ciBzdHlsZT0ibXNvLXlmdGktaXJvdzoxMCI+DQo8dGQgd2lkdGg9IjgwIiBzdHls ZT0id2lkdGg6ODAuMHB0O2JvcmRlcjpub25lO3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWJv dHRvbTouMDAwMXB0O21zby1wYWdpbmF0aW9uOg0KICBub25lO21zby1sYXlvdXQtZ3JpZC1hbGln bjpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToNCiAg MTMuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L3RkPg0KPHRkIHdpZHRoPSI2NTAiIHN0eWxlPSJ3aWR0aDo2NTAuMHB0O2JvcmRlcjpub25lO3Bh ZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O21zby1wYWdpbmF0aW9uOg0K ICBub25lO21zby1sYXlvdXQtZ3JpZC1hbGlnbjpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToNCiAgMTMuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0ibXNvLXlm dGktaXJvdzoxMSI+DQo8dGQgd2lkdGg9IjgwIiBzdHlsZT0id2lkdGg6ODAuMHB0O2JvcmRlcjpu b25lO3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O21zby1wYWdpbmF0 aW9uOg0KICBub25lO21zby1sYXlvdXQtZ3JpZC1hbGlnbjpub25lO3RleHQtYXV0b3NwYWNlOm5v bmUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToNCiAgMTMuMHB0O2ZvbnQtZmFtaWx5OkFyaWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI2NTAiIHN0 eWxlPSJ3aWR0aDo2NTAuMHB0O2JvcmRlcjpub25lO3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTowaW47bWFyZ2lu LWJvdHRvbTouMDAwMXB0O21zby1wYWdpbmF0aW9uOg0KICBub25lO21zby1sYXlvdXQtZ3JpZC1h bGlnbjpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToN CiAgMTMuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0ibXNvLXlmdGktaXJvdzoxMiI+DQo8dGQgd2lkdGg9 IjgwIiBzdHlsZT0id2lkdGg6ODAuMHB0O2JvcmRlcjpub25lO3BhZGRpbmc6MGluIDUuNHB0IDBp biA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTowaW47 bWFyZ2luLWJvdHRvbTouMDAwMXB0O21zby1wYWdpbmF0aW9uOg0KICBub25lO21zby1sYXlvdXQt Z3JpZC1hbGlnbjpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToNCiAgMTMuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI2NTAiIHN0eWxlPSJ3aWR0aDo2NTAuMHB0O2JvcmRl cjpub25lO3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O21zby1wYWdp bmF0aW9uOg0KICBub25lO21zby1sYXlvdXQtZ3JpZC1hbGlnbjpub25lO3RleHQtYXV0b3NwYWNl Om5vbmUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToNCiAgMTMuMHB0O2ZvbnQtZmFtaWx5OkFy aWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBzdHls ZT0ibXNvLXlmdGktaXJvdzoxMyI+DQo8dGQgd2lkdGg9IjgwIiBzdHlsZT0id2lkdGg6ODAuMHB0 O2JvcmRlcjpub25lO3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O21z by1wYWdpbmF0aW9uOg0KICBub25lO21zby1sYXlvdXQtZ3JpZC1hbGlnbjpub25lO3RleHQtYXV0 b3NwYWNlOm5vbmUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToNCiAgMTMuMHB0O2ZvbnQtZmFt aWx5OkFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHdpZHRo PSI2NTAiIHN0eWxlPSJ3aWR0aDo2NTAuMHB0O2JvcmRlcjpub25lO3BhZGRpbmc6MGluIDUuNHB0 IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTow aW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O21zby1wYWdpbmF0aW9uOg0KICBub25lO21zby1sYXlv dXQtZ3JpZC1hbGlnbjpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToNCiAgMTMuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0ibXNvLXlmdGktaXJvdzoxNCI+DQo8 dGQgd2lkdGg9IjgwIiBzdHlsZT0id2lkdGg6ODAuMHB0O2JvcmRlcjpub25lO3BhZGRpbmc6MGlu IDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbTowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O21zby1wYWdpbmF0aW9uOg0KICBub25lO21z by1sYXlvdXQtZ3JpZC1hbGlnbjpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToNCiAgMTMuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI2NTAiIHN0eWxlPSJ3aWR0aDo2NTAu MHB0O2JvcmRlcjpub25lO3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0 O21zby1wYWdpbmF0aW9uOg0KICBub25lO21zby1sYXlvdXQtZ3JpZC1hbGlnbjpub25lO3RleHQt YXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToNCiAgMTMuMHB0O2ZvbnQt ZmFtaWx5OkFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4N Cjx0ciBzdHlsZT0ibXNvLXlmdGktaXJvdzoxNSI+DQo8dGQgd2lkdGg9IjgwIiBzdHlsZT0id2lk dGg6ODAuMHB0O2JvcmRlcjpub25lO3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWJvdHRvbTou MDAwMXB0O21zby1wYWdpbmF0aW9uOg0KICBub25lO21zby1sYXlvdXQtZ3JpZC1hbGlnbjpub25l O3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToNCiAgMTMuMHB0 O2ZvbnQtZmFtaWx5OkFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0K PHRkIHdpZHRoPSI2NTAiIHN0eWxlPSJ3aWR0aDo2NTAuMHB0O2JvcmRlcjpub25lO3BhZGRpbmc6 MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbTowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O21zby1wYWdpbmF0aW9uOg0KICBub25l O21zby1sYXlvdXQtZ3JpZC1hbGlnbjpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToNCiAgMTMuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0ibXNvLXlmdGktaXJv dzoxNiI+DQo8dGQgd2lkdGg9IjgwIiBzdHlsZT0id2lkdGg6ODAuMHB0O2JvcmRlcjpub25lO3Bh ZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O21zby1wYWdpbmF0aW9uOg0K ICBub25lO21zby1sYXlvdXQtZ3JpZC1hbGlnbjpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToNCiAgMTMuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI2NTAiIHN0eWxlPSJ3 aWR0aDo2NTAuMHB0O2JvcmRlcjpub25lO3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWJvdHRv bTouMDAwMXB0O21zby1wYWdpbmF0aW9uOg0KICBub25lO21zby1sYXlvdXQtZ3JpZC1hbGlnbjpu b25lO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToNCiAgMTMu MHB0O2ZvbnQtZmFtaWx5OkFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L3Rk Pg0KPC90cj4NCjx0ciBzdHlsZT0ibXNvLXlmdGktaXJvdzoxNyI+DQo8dGQgd2lkdGg9IjgwIiBz dHlsZT0id2lkdGg6ODAuMHB0O2JvcmRlcjpub25lO3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTowaW47bWFyZ2lu LWJvdHRvbTouMDAwMXB0O21zby1wYWdpbmF0aW9uOg0KICBub25lO21zby1sYXlvdXQtZ3JpZC1h bGlnbjpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToN CiAgMTMuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L3RkPg0KPHRkIHdpZHRoPSI2NTAiIHN0eWxlPSJ3aWR0aDo2NTAuMHB0O2JvcmRlcjpub25l O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O21zby1wYWdpbmF0aW9u Og0KICBub25lO21zby1sYXlvdXQtZ3JpZC1hbGlnbjpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToNCiAgMTMuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0ibXNv LXlmdGktaXJvdzoxOCI+DQo8dGQgd2lkdGg9IjgwIiBzdHlsZT0id2lkdGg6ODAuMHB0O2JvcmRl cjpub25lO3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O21zby1wYWdp bmF0aW9uOg0KICBub25lO21zby1sYXlvdXQtZ3JpZC1hbGlnbjpub25lO3RleHQtYXV0b3NwYWNl Om5vbmUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToNCiAgMTMuMHB0O2ZvbnQtZmFtaWx5OkFy aWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI2NTAi IHN0eWxlPSJ3aWR0aDo2NTAuMHB0O2JvcmRlcjpub25lO3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1 LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTowaW47bWFy Z2luLWJvdHRvbTouMDAwMXB0O21zby1wYWdpbmF0aW9uOg0KICBub25lO21zby1sYXlvdXQtZ3Jp ZC1hbGlnbjpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToNCiAgMTMuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0ibXNvLXlmdGktaXJvdzoxOSI+DQo8dGQgd2lk dGg9IjgwIiBzdHlsZT0id2lkdGg6ODAuMHB0O2JvcmRlcjpub25lO3BhZGRpbmc6MGluIDUuNHB0 IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTow aW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O21zby1wYWdpbmF0aW9uOg0KICBub25lO21zby1sYXlv dXQtZ3JpZC1hbGlnbjpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToNCiAgMTMuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI2NTAiIHN0eWxlPSJ3aWR0aDo2NTAuMHB0O2Jv cmRlcjpub25lO3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O21zby1w YWdpbmF0aW9uOg0KICBub25lO21zby1sYXlvdXQtZ3JpZC1hbGlnbjpub25lO3RleHQtYXV0b3Nw YWNlOm5vbmUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToNCiAgMTMuMHB0O2ZvbnQtZmFtaWx5 OkFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBz dHlsZT0ibXNvLXlmdGktaXJvdzoyMCI+DQo8dGQgd2lkdGg9IjgwIiBzdHlsZT0id2lkdGg6ODAu MHB0O2JvcmRlcjpub25lO3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0 O21zby1wYWdpbmF0aW9uOg0KICBub25lO21zby1sYXlvdXQtZ3JpZC1hbGlnbjpub25lO3RleHQt YXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToNCiAgMTMuMHB0O2ZvbnQt ZmFtaWx5OkFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHdp ZHRoPSI2NTAiIHN0eWxlPSJ3aWR0aDo2NTAuMHB0O2JvcmRlcjpub25lO3BhZGRpbmc6MGluIDUu NHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bTowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O21zby1wYWdpbmF0aW9uOg0KICBub25lO21zby1s YXlvdXQtZ3JpZC1hbGlnbjpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToNCiAgMTMuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0ibXNvLXlmdGktaXJvdzoyMSI+ DQo8dGQgd2lkdGg9IjgwIiBzdHlsZT0id2lkdGg6ODAuMHB0O2JvcmRlcjpub25lO3BhZGRpbmc6 MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbTowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O21zby1wYWdpbmF0aW9uOg0KICBub25l O21zby1sYXlvdXQtZ3JpZC1hbGlnbjpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToNCiAgMTMuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI2NTAiIHN0eWxlPSJ3aWR0aDo2 NTAuMHB0O2JvcmRlcjpub25lO3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWJvdHRvbTouMDAw MXB0O21zby1wYWdpbmF0aW9uOg0KICBub25lO21zby1sYXlvdXQtZ3JpZC1hbGlnbjpub25lO3Rl eHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToNCiAgMTMuMHB0O2Zv bnQtZmFtaWx5OkFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90 cj4NCjx0ciBzdHlsZT0ibXNvLXlmdGktaXJvdzoyMiI+DQo8dGQgd2lkdGg9IjgwIiBzdHlsZT0i d2lkdGg6ODAuMHB0O2JvcmRlcjpub25lO3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWJvdHRv bTouMDAwMXB0O21zby1wYWdpbmF0aW9uOg0KICBub25lO21zby1sYXlvdXQtZ3JpZC1hbGlnbjpu b25lO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToNCiAgMTMu MHB0O2ZvbnQtZmFtaWx5OkFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L3Rk Pg0KPHRkIHdpZHRoPSI2NTAiIHN0eWxlPSJ3aWR0aDo2NTAuMHB0O2JvcmRlcjpub25lO3BhZGRp bmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbTowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O21zby1wYWdpbmF0aW9uOg0KICBu b25lO21zby1sYXlvdXQtZ3JpZC1hbGlnbjpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToNCiAgMTMuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0ibXNvLXlmdGkt aXJvdzoyMyI+DQo8dGQgd2lkdGg9IjgwIiBzdHlsZT0id2lkdGg6ODAuMHB0O2JvcmRlcjpub25l O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O21zby1wYWdpbmF0aW9u Og0KICBub25lO21zby1sYXlvdXQtZ3JpZC1hbGlnbjpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToNCiAgMTMuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI2NTAiIHN0eWxl PSJ3aWR0aDo2NTAuMHB0O2JvcmRlcjpub25lO3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWJv dHRvbTouMDAwMXB0O21zby1wYWdpbmF0aW9uOg0KICBub25lO21zby1sYXlvdXQtZ3JpZC1hbGln bjpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToNCiAg MTMuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0ibXNvLXlmdGktaXJvdzoyNCI+DQo8dGQgd2lkdGg9Ijgw IiBzdHlsZT0id2lkdGg6ODAuMHB0O2JvcmRlcjpub25lO3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1 LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTowaW47bWFy Z2luLWJvdHRvbTouMDAwMXB0O21zby1wYWdpbmF0aW9uOg0KICBub25lO21zby1sYXlvdXQtZ3Jp ZC1hbGlnbjpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToNCiAgMTMuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI2NTAiIHN0eWxlPSJ3aWR0aDo2NTAuMHB0O2JvcmRlcjpu b25lO3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O21zby1wYWdpbmF0 aW9uOg0KICBub25lO21zby1sYXlvdXQtZ3JpZC1hbGlnbjpub25lO3RleHQtYXV0b3NwYWNlOm5v bmUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToNCiAgMTMuMHB0O2ZvbnQtZmFtaWx5OkFyaWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0i bXNvLXlmdGktaXJvdzoyNSI+DQo8dGQgd2lkdGg9IjgwIiBzdHlsZT0id2lkdGg6ODAuMHB0O2Jv cmRlcjpub25lO3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O21zby1w YWdpbmF0aW9uOg0KICBub25lO21zby1sYXlvdXQtZ3JpZC1hbGlnbjpub25lO3RleHQtYXV0b3Nw YWNlOm5vbmUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToNCiAgMTMuMHB0O2ZvbnQtZmFtaWx5 OkFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI2 NTAiIHN0eWxlPSJ3aWR0aDo2NTAuMHB0O2JvcmRlcjpub25lO3BhZGRpbmc6MGluIDUuNHB0IDBp biA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTowaW47 bWFyZ2luLWJvdHRvbTouMDAwMXB0O21zby1wYWdpbmF0aW9uOg0KICBub25lO21zby1sYXlvdXQt Z3JpZC1hbGlnbjpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToNCiAgMTMuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0ibXNvLXlmdGktaXJvdzoyNiI+DQo8dGQg d2lkdGg9IjgwIiBzdHlsZT0id2lkdGg6ODAuMHB0O2JvcmRlcjpub25lO3BhZGRpbmc6MGluIDUu NHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bTowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O21zby1wYWdpbmF0aW9uOg0KICBub25lO21zby1s YXlvdXQtZ3JpZC1hbGlnbjpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToNCiAgMTMuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI2NTAiIHN0eWxlPSJ3aWR0aDo2NTAuMHB0 O2JvcmRlcjpub25lO3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O21z by1wYWdpbmF0aW9uOg0KICBub25lO21zby1sYXlvdXQtZ3JpZC1hbGlnbjpub25lO3RleHQtYXV0 b3NwYWNlOm5vbmUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToNCiAgMTMuMHB0O2ZvbnQtZmFt aWx5OkFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjx0 ciBzdHlsZT0ibXNvLXlmdGktaXJvdzoyNyI+DQo8dGQgd2lkdGg9IjgwIiBzdHlsZT0id2lkdGg6 ODAuMHB0O2JvcmRlcjpub25lO3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWJvdHRvbTouMDAw MXB0O21zby1wYWdpbmF0aW9uOg0KICBub25lO21zby1sYXlvdXQtZ3JpZC1hbGlnbjpub25lO3Rl eHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToNCiAgMTMuMHB0O2Zv bnQtZmFtaWx5OkFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRk IHdpZHRoPSI2NTAiIHN0eWxlPSJ3aWR0aDo2NTAuMHB0O2JvcmRlcjpub25lO3BhZGRpbmc6MGlu IDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbTowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O21zby1wYWdpbmF0aW9uOg0KICBub25lO21z by1sYXlvdXQtZ3JpZC1hbGlnbjpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToNCiAgMTMuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0ibXNvLXlmdGktaXJvdzoy ODttc28teWZ0aS1sYXN0cm93OnllcyI+DQo8dGQgd2lkdGg9IjgwIiBzdHlsZT0id2lkdGg6ODAu MHB0O2JvcmRlcjpub25lO3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0 O21zby1wYWdpbmF0aW9uOg0KICBub25lO21zby1sYXlvdXQtZ3JpZC1hbGlnbjpub25lO3RleHQt YXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToNCiAgMTMuMHB0O2ZvbnQt ZmFtaWx5OkFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHdp ZHRoPSI2NTAiIHN0eWxlPSJ3aWR0aDo2NTAuMHB0O2JvcmRlcjpub25lO3BhZGRpbmc6MGluIDUu NHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bTowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O21zby1wYWdpbmF0aW9uOg0KICBub25lO21zby1s YXlvdXQtZ3JpZC1hbGlnbjpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToNCiAgMTMuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8IS0tRW5kRnJhZ21lbnQtLT48L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_03B78081B371D44390ED6E7BADBB4A772341EB38xmbrcdx02ciscoc_-- From dhruv.ietf@gmail.com Tue Apr 16 05:40:30 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B80C21F96DF for ; Tue, 16 Apr 2013 05:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.882 X-Spam-Level: X-Spam-Status: No, score=-0.882 tagged_above=-999 required=5 tests=[AWL=-0.883, BAYES_50=0.001, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hz++ABAsBnUW for ; Tue, 16 Apr 2013 05:40:28 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id DA6DA21F96C9 for ; Tue, 16 Apr 2013 05:40:27 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id e11so415039iej.16 for ; Tue, 16 Apr 2013 05:40:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:x-google-sender-delegation :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=YVOBmVklmrvqcvNxEZNKEbeK5WiAdMUORzugeW5UrPI=; b=Wtl4ZrzC8D9vqHfthsq27uEd8FFBGWkNcsGZSW7RKoK/ZrSZgaZ903YapDbvFgK24D my5qB9sHxoI31PcK56fp165Rrup1k4P8hYNbVm/jvZRBB8caTXN1f4LBYh0a6FtiQZgW 7Rm9IG9wQYmFvOR0XXtrbZjZ1Aws0VAgAD0VYQhun7RnflSCd4ehrSMToMYihMnn3leH O7L4+qAGUoSj5Ju5jse2T5uHgLN1iAlXTeibpcOSB0wY00m1FTFsiL2gWmGwUGjqGQ1+ d01BKRaUFlWkLGBDE/DflLloIRFPkHTwBQ2kAgJiE/1Tslc/kOT3OHIUhMeyAVg1NIYh yN3g== MIME-Version: 1.0 X-Received: by 10.50.173.9 with SMTP id bg9mr7854842igc.82.1366116027246; Tue, 16 Apr 2013 05:40:27 -0700 (PDT) Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.217.162 with HTTP; Tue, 16 Apr 2013 05:40:27 -0700 (PDT) In-Reply-To: <70BDAD02381BA54CA31315A2A26A7AD303751B72@BLUPRD0511MB436.namprd05.prod.outlook.com> References: <70BDAD02381BA54CA31315A2A26A7AD3037352A8@BY2PRD0511MB440.namprd05.prod.outlook.com> <70BDAD02381BA54CA31315A2A26A7AD303751B72@BLUPRD0511MB436.namprd05.prod.outlook.com> Date: Tue, 16 Apr 2013 18:10:27 +0530 X-Google-Sender-Auth: Lksz7PqalLSXfKKTRbuGrFCqvMc Message-ID: From: Dhruv Dhody To: Ina Minei Content-Type: multipart/alternative; boundary=e89a8f838b7b87005704da79ac8d Cc: "pce@ietf.org" Subject: Re: [Pce] Comments on draft-ietf-pce-stateful-pce-02 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 12:40:30 -0000 --e89a8f838b7b87005704da79ac8d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Ina, I just realized that this mail has been sitting in my draft folder, as I forgot to send it.... :D Please find reply as [DD2] On Thu, Apr 4, 2013 at 5:34 AM, Ina Minei wrote: > Dhruv, **** > > ** ** > > Please see inline %%%.**** > > ** ** > > *From:* dhruvdhody@gmail.com [mailto:dhruvdhody@gmail.com] *On Behalf Of = *Dhruv > Dhody > *Sent:* Monday, April 01, 2013 9:32 AM > *To:* Ina Minei > *Cc:* pce@ietf.org > *Subject:* Re: [Pce] Comments on draft-ietf-pce-stateful-pce-02**** > > ** ** > > Hi Ina,**** > > ** ** > > Thanks for your reply, find the response inline, also I have a few > comments on -03 version of the draft which is at the end of this mail.***= * > > ** ** > > Dhruv **** > > ** ** > > On Sat, Mar 23, 2013 at 5:40 AM, Ina Minei wrote:**** > > Dhruv, **** > > Thank you for the review. Please see answers inline below ###.**** > > Ina**** > > *From:* pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] *On Behalf Of = *Dhruv > Dhody**** > > *Sent:* Monday, March 11, 2013 8:03 AM > *To:* pce@ietf.org > *Subject:* [Pce] Comments on draft-ietf-pce-stateful-pce-02**** > > **** > > Hi,**** > > Please find the review comments for this draft (there is some overlap wit= h > comments from Jon, Cyril etc)**** > > *Major Comments:***** > > (1) State synchronisation: **** > > a. PCE should determine the synchronisation is over as soon as possible, > as updates, request etc are blocked during synchronisation. Maybe the las= t > report message can have SYNC=3D0 (similar to F - fragmentation bit in RP > object) or as Jon suggested an empty report but then the RBNF of PCRpt > should support it. **** > > ### Please see version 03 of the draft.**** > > **** > > b. I also dont like the use of word 'purge' with respect to old or stale > entries during PCEP session up/down. A mechanism to mark LSP entries as > stale and waiting for them to be refreshed after session up and deleted (= or > 'purged') only after some timer expiry.**** > > ### Please see version 03 of the draft. **** > > **** > > **** > > (2) The PCRpt Message:**** > > ::=3D > [] Where: ::=3D[]. Is this to > specify primary and backup? In which case the status of the paths needs t= o > reported separately in case of standby but we have only one LSP object he= re > to specify the operational status. Also LSP-ID of primary and backup woul= d > be different. **** > > **** > > Also applicable to PCUpd message. **** > > I feel the backup path should be updated and reported separately with eac= h > having there own encoding for LSP object. **** > > ### Clarification on backup paths will be done in the protection doc. I > agree with you the text needs to be cleaned up in the base spec, will do = so > in 04. **** > > **** > > (3) Node Identifier TLV**** > > PCC may use address that survives the session restart (Loopback, MPLS > LSR-ID etc), i suggest we mention this in the document and provide guidan= ce > to implementers to do this if possible. **** > > ### the node-id (now renamed to predundancy-group-id) will be further > clarified in version 04**** > > **** > > (4) LSP Object: **** > > a. What is relationship between the LSP-ID in LSP object and the LSP-ID i= n > LSP Identifier TLVs?**** > > ### The lsp-id in the lsp object was renamed to plsp-id to avoid such > confusion.**** > > *[DD]: Rename is good, but i hope relationship between the PLSP-ID and > the LSP-ID (signalled by RSVP) can be explicitly mentioned. This should > especially be clarified in the case of MBB. * > > ** ** > > %%% Could you point to the confusing text in the definition of plsp-id? > *[DD2]: The description of PLSID-ID on its own is fine, but draft-crabbe-pce-stateful-pce-mpls-te also has LSP-ID as a part of **LSP Identifiers TLVs which interns point to RFC3209. So considering PLSP-ID is the ID generated by PCC, and LSP_ID in LSP Identifier TLV is the one used in RSVP signalling, the implementers need clarity on how to handle these ID during MBB (something inline with Tanaka's MBB doc) * *considering* *- both existing and modified LSP are being signalled and co-exist for brief time, * *- the result of MBB can be success or failure (i.e. the new path given by active stateful PCE cannot be signaled successfully and the old path is retained, we need to report to stateful PCE both cases clearly. * > **** > > b. There is no mechanism to report the 'pending' state right now? O-Bit a= s > zero will mean down, not pending. **** > > ### The O-bit will be revisited in version 04.**** > > **** > > (5) Make-Before-Break: **** > > There is a need to clarify how MBB is achieved, what is the LSP-ID in cas= e > of updates and reports? **** > > ### Please see version 03. **** > > **** > > *[DD]: The updated text though in the right direction is still missing > key information. I hope the next version clarifies it further. * > > %%% could you please indicate what key information is missing? > *[DD2]: as per previous comment.* > **** > > **** > > *Minor Comments: ***** > > (1) Abstract/Introduction**** > > There is a consistent use of phrase "between and across PCEP sessions". > Can you clarify? **** > > ### LSPs may move from one PCE to another.**** > > **** > > (2) Re-look the terminology section as some terms are no longer in the > document. **** > > ### Could you send the correction?**** > > **** > > *[DD]: Just removal of MPLS TE Global Default Restoration & MPLS TE > Global Path Protection should do the trick. Both terms are no longer used > in this document. ***** > > (3) LSP Protection **** > > In case of delegated PCE, the desired protection may also be configured a= t > PCC and the active stateful PCE should support it, the stateful PCE havin= g > full control over the protection / restoration settings can only be > achieved with instantiation capability and should be out of scope from th= is > document. **** > > ### The whole discussion on protection belongs in a separate document.***= * > > **** > > (4) Delegation**** > > a. The wording "an LSP may be delegated to one or more PCEs." .. this is > incorrect, from the reading it looks as if this is happening at the same > time. **** > > ### To a single PCE, text is clarified in 03.**** > > **** > > b. Active stateful PCE LSP Update (sec 5.6.2)**** > > OLD:**** > > A PCC may choose to compress LSP State Updates to only reflect the most > up to date state, as discussed in the previous section. **** > > NEW:**** > > A PCC may choose to compress LSP State Reports to only reflect the most > up to date state, as discussed in the previous section. **** > > ### Actually, I think we mean updates, not reports (if receiving multiple > updates, may choose to do state compression during processing)**** > > **** > > *[DD]: Okay I understand, it mean that PCC is only taking the latest > Update into consideration; now i am wondering can PCC choose to compress > reports and send the most upto date report? (skip sending pending if not > yet send; or in case of multiple up-down only send the latest state) * *= * > ** > > ** ** > > %%% There are some issues with this and error reporting, working through > these issues now. **** > > (5) Symbolic Path Name TLV**** > > The length of this TLV must be greater then 0 as well as multiple of four= . > **** > > ### I think this is not necessary to specify in words, the figure should > be sufficient.**** > > *[DD]: In most cases yes, but this is a case of variable length we must > make sure extra padding is added and the TLV is aligned. You can take you= r > cue from other RFC where variable length TLV exists say RFC4920; RFC6001 > etc ***** > > **** > > (6) LSP state DB version TLV (page 40, para 2)**** > > "Since a PCE does not send LSP updates to a PCC, a PCC should never > encounter this TLV". LSP updates here can be easily confused with the PCU= pd > messages. Kindly reword this. **** > > ### Will do.**** > > **** > > Regards,**** > > Dhruv**** > > ** ** > > ** ** > > *Few more comments on the -03 version: ***** > > ** ** > > *(1) Section 5.5.2 (Revocation of delegated LSP)***** > > ** ** > > *When a PCC revokes a delegated LSP, PCC immediately clears the LSP state > received from this PCE. But we should apply Make-Before-Break here as wel= l, > that is while the PCC delegates to another PCE or keep the LSP with itsel= f, > the LSP should not be teardown immediately. * > > %%% Can you please point me to the text that gives this impression? The > current text says: =93MAY immediately clear=94, not =93MUST immediately c= lear=94. > *[DD2]: I agree, but say a stateful PCE revokes, PCC may look for another active stateful PCE to delegate, if not found, it may ask another stateless/passive PCE or ingress CSPF to recompute and if the paths are different, it should again apply make-before-break. IMHO Data disruption should be avoided at all times. * *So use of MAY without a mention of MBB doesnt look correct... ** * > **** > > * * > > ** ** > > *(2) Modification of Tunnel configuration at PCC for a delegated LSP. ***= * > * > > ** ** > > *Incase of manual config change (say bandwidth, priority) at PCC, how the > new LSP parameters to be reported to the PCE (maybe a separate delegation > request with new PLSP-ID) eventually make-before-break should > be applied here as well. When the text for MBB is added in detail, this > could also be considered. * > > ** ** > > %%% Can you explain the scenario? The operator should not change > bw/priority or anything else that is PCE-controlled unless he has revoked > delegation. > *[DD2]: The requirements change, an existing service after paying a premium amount could be moved to higher class and thus higher LSP priority and more bandwidth would be reserved. This should be achieved without any traffic loss. * *In existing network (local CSPF computation) this is achieved at ingress by keeping the existing LSP intact, a modified path is computed based on the new constraints, a modified LSP is signaled (at this time both old and modified LSP exist), traffic is switched to the new (modified) LSP and then the old (existing) LSP is tear down. * *Note the behavior would be the same when stateless or passive PCE is used.= * * * *We are looking for a similar behaviour in active PCE with delegated LSP, incase when operator changes the constraints at Ingress via configuration the new path should consider that and make sure no data disruption happens. * * * *One way would be, as you mentioned - first revoke the delegation and resend the delegation with new parameters but also follow make-before-break? * *or* *PCC sends a delegation request for modified LSP with modified parameters (also linking it to the existing LSP); PCC apply make-before-break as befor= e **. * > **** > > ** ** > > *(3) Section 6.1 (The PCRpt Message)***** > > ** ** > > *Please consider the comments given > for draft-crabbe-pce-stateful-pce-mpls-te-00 regarding the PCRpt message > here as well [ > http://www.ietf.org/mail-archive/web/pce/current/msg03007.html]. ***** > > ** ** > > *Thanks! ***** > > ** ** > > *Dhruv***** > > * ***** > > ** ** > > ** ** > --e89a8f838b7b87005704da79ac8d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Ina,

I just realized that this mail has been sitting in= my draft folder, as I forgot to send it.... :D

Please find reply as [DD2]


On Thu, Apr 4, 2013 at 5:34 AM, Ina Minei <in= a@juniper.net> wrote:

Dhruv,

=A0

Please see inline %%%.

=A0

From: dhruvdhody@= gmail.com [mailto:dhruvdhody@gmail.com] On Behalf Of Dhruv Dhody
Sent: Monday, April 01, 2013 9:32 AM
To: Ina Minei
Cc: pce@ietf.org
Subject: Re: [Pce] Comments on draft-ietf-pce-stateful-pce-02=

=A0

Hi Ina,

=A0

Thanks for your reply, find the response inline, also I have = a few comments on -03 version of the draft which is at the end of this mail= .

=A0

Dhruv=A0

=A0

On Sat, Mar 23, 2013 at 5:40 AM, Ina Minei <ina@juniper.net> wrote:

Dhruv,

Thank you for the review. Please see answers inline below ###.

Ina

From: pce-bounces@ietf.= org [mailto:p= ce-bounces@ietf.org] On Behalf Of Dhruv Dhody

=A0

Hi,

Please find the review comments for this draft (there is some overlap wi= th comments from Jon, Cyril etc)

Major Comments:

(1) State synchronisation: =A0

a. PCE should determine the synchronisation is over as soon as possible,= as updates, request etc are blocked during synchronisation. Maybe the last= report message can have SYNC=3D0 (similar to F - fragmentation bit in RP o= bject) or as Jon suggested an empty report but then the RBNF of PCRpt should support it.=A0

### Please see version 03 of the draft.

=A0

b. I also dont like the use of word 'purge' with respect to old = or stale entries during PCEP session up/down. A mechanism to mark LSP entri= es as stale and waiting for them to be refreshed after session up and delet= ed (or 'purged') only after some timer expiry.

### Please see version 03 of the draft.

=A0

=A0

(2) The PCRpt Message:

<state-report> ::=3D <LSP>[<path-list>]=A0Where:=A0<= ;path-list>::=3D<path>[<path-list>]. Is this to specify prim= ary and backup? In which case the status of the paths needs to reported=A0s= eparately=A0in case of standby but we have only one LSP object here to spec= ify the operational status. Also LSP-ID of primary and backup would be different.= =A0

=A0

Also applicable to PCUpd message.=A0

I feel the backup path should be updated and reported=A0separately=A0wit= h each having there own encoding for LSP object.=A0

### Clarification on backup paths will be done in the protection= doc. I agree with you the text needs to be cleaned up in the base spec, wi= ll do so in 04.

=A0

(3) Node Identifier TLV

PCC may use address that survives the session restart (Loopback, MPLS LS= R-ID etc), i suggest we mention this in the document and provide guidance t= o implementers to do this if possible.=A0

### the node-id (now renamed to predundancy-group-id) will be fu= rther clarified in version 04

=A0

(4) LSP Object:=A0

a. What is relationship between the LSP-ID in LSP object and the LSP-ID = in LSP Identifier TLVs?

### The lsp-id in the lsp object was renamed to plsp-id to avoid= such confusion.

considering
- both existing and modified LSP are bein= g signalled and co-exist for brief time,=A0
= - the result of MBB can be success or = failure (i.e. the new path given by active stateful PCE cannot be signaled= =A0successfully=A0and the old path is retained, we need to repo= rt to stateful PCE both cases clearly. =A0

=A0=A0

b. There is no=A0mechanism=A0to report the 'pending' state right= now? O-Bit as zero will mean down, not pending.=A0

### The O-bit will be revisited in = version 04.

=A0

(5) Make-Before-Break:=A0

There is a need to clarify how MBB is achieved, what is the LSP-ID in ca= se of updates and reports?=A0

### Please see version 03.

=A0

[DD]: The updated tex= t though in the right direction is still missing key information. I hope th= e next version clarifies it further.=A0

%%% could you please indicate what key informat= ion is missing?

[DD2]: as per previous comment.=A0

=A0

Minor Comments:=A0

(1) Abstract/Introduction

There is a consistent use of phrase "between and across PCEP sessio= ns". Can you clarify?=A0

### LSPs may move from one PCE to another.<= /p>

=A0

(2) Re-look the terminology section as some terms are no longer in the d= ocument.=A0

### Could you send the correction?

=A0

[DD]: Just removal of= MPLS TE Global=A0Default=A0Restoration & MPLS TE Global Path Protectio= n should do the trick. Both terms are no longer used in this document.=A0

(3) LSP Protection=A0

In case of delegated PCE, the desired protection may also be configured = at PCC and the active stateful PCE should support it, the stateful PCE havi= ng full control over the protection / restoration settings can only be achi= eved with instantiation capability and should be out of scope from this document.=A0

### The whole discussion on protection belongs in a separate doc= ument.

=A0

(4)=A0Delegation

a. The wording "an LSP may be delegated to one or more PCEs." = .. this is incorrect, from the reading it looks as if this is happening at = the same time.=A0

### To a single PCE, text is clarified in 03.

=A0

b. Active stateful PCE LSP Update (sec 5.6.2)

OLD:

A PCC=A0may choose to compress LSP State Updates to only reflect the mos= t up=A0to date state, as discussed in the previous section.=A0

NEW:

A PCC=A0may choose to compress LSP State Reports to only reflect the mos= t up=A0to date state, as discussed in the previous section.=A0

### Actually, I think we mean updat= es, not reports (if receiving multiple updates, may choose to do state comp= ression during processing)

=A0

[DD]: Okay I understa= nd, it mean that PCC is only taking the latest Update into consideration; n= ow i am wondering can PCC choose to compress reports and send the most upto= date report? (skip sending pending if not yet send; or in case of multiple up-down only send the latest state= ) =A0=A0

=A0

%%% There are some issues with this and error r= eporting, working through these issues now.

(5) Symbolic Path Name TLV

The length of this TLV must be greater then 0 as well as multiple of fou= r.=A0

### I think this is not necessary to specify in words, the figur= e should be sufficient.

[DD]: In most cases y= es, but this is a case of variable length we must make sure extra padding i= s added and the TLV is aligned. You can take your cue from other RFC where = variable length TLV exists say RFC4920; RFC6001 etc =A0

=A0

(6) LSP state DB version TLV (page 40, para 2)

"Since a PCE does not send LSP updates to a PCC, a PCC should never= encounter this TLV".=A0LSP updates here can be easily confused with t= he PCUpd messages. Kindly reword this.=A0

### Will do.

=A0

Regards,

Dhruv

=A0

=A0

Few more comments on = the -03 version:=A0

=A0

(1) Section 5.5.2 (Re= vocation of delegated LSP)

=A0

When a PCC revokes a = delegated LSP, PCC immediately clears the LSP state received from this PCE.= But we should apply Make-Before-Break here as well, that is while the PCC = delegates to another PCE or keep the LSP with itself, the LSP should not be teardown immediately. =A0=A0=

%%% Can you please point me to the text that gi= ves this impression? The current text says: =93MAY immediately clear=94, no= t =93MUST immediately clear=94.

So use of MAY without a mention of MBB doesnt look correct= ...=A0=A0=A0

=A0

=A0

(2) Modification of T= unnel configuration at PCC for a delegated LSP.=A0=

=A0

Incase of manual conf= ig change (say bandwidth, priority) at PCC, how the new LSP parameters to b= e reported to the PCE (maybe a=A0separate=A0delegation request with new PLS= P-ID)=A0eventually=A0make-before-break should be=A0applied=A0here as well. When the text for MBB is added in=A0detail, t= his could also be considered.=A0

=A0

%%% Can you explain the scenario? The operator should= not change bw/priority or anything else that is PCE-controlled unless he h= as revoked delegation.

[DD2]: The requ= irements change, an existing service after paying a premium amount could be= moved to higher class and thus higher LSP priority and more bandwidth woul= d be reserved. This should be achieved without any traffic loss.=A0
In existing network (local CSPF computation) this is achieved at ingress= by keeping the existing LSP intact, a modified path is computed based on t= he new=A0constraints, a modified LSP is signaled (at this time both old and= modified LSP exist), traffic is switched to the new (modified) LSP and the= n the old (existing) LSP is tear down.=A0
= Note the behavior would be the same when stateless or passive PCE is use= d.

We are looking for a similar behaviour in active PCE wi= th delegated LSP, incase when operator changes the constraints at Ingress v= ia configuration the new path should consider that and make sure no data di= sruption happens.=A0

One way would be, as you mentioned - first revok= e the delegation and resend the delegation with new parameters but also fol= low make-before-break?=A0
or
PCC sends a delegation request for modified LSP wi= th modified parameters (also linking it to the existing LSP); PCC apply mak= e-before-break as before. =A0

--e89a8f838b7b87005704da79ac8d-- From dhruv.ietf@gmail.com Tue Apr 16 05:46:34 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2234E21F96BC for ; Tue, 16 Apr 2013 05:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[AWL=0.711, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0T6b8sAdY-Ic for ; Tue, 16 Apr 2013 05:46:33 -0700 (PDT) Received: from mail-ia0-x22a.google.com (mail-ia0-x22a.google.com [IPv6:2607:f8b0:4001:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 22C3921F96B7 for ; Tue, 16 Apr 2013 05:46:33 -0700 (PDT) Received: by mail-ia0-f170.google.com with SMTP id 21so164136iay.29 for ; Tue, 16 Apr 2013 05:46:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:x-google-sender-delegation :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=QZrD3s1ik4Mjah363wXxiHDfDFCIZ1ewERMH8jRepXQ=; b=hAuhWp7DUIn1lMcUuqixJN9zxrDUSQZK9Nbw9qinDradTT0GJxsvDU2kUt5YwmKkMs j7fclTErdkq1rO7acCVIzEH+Qf/TCi0gUneXIKvE5MSryKg1JoBpOFv049wtibkow1UM A2Ktfgcpb4KitY2VWd9c3hQoqNxzu7oLAZi3anWT6+CsY3Z+azg7jmXUomkj5ZBK7G2X yZr9LZZfN9hq0eM8h8Vc+mDXfNnDQYqjkRyyHUiSn0dEtlzP1u8Z+0NZq9AEg/beGSH4 kuHGKYGE+CDABtNuoRsTPv0Mc0oryJDYdBmaN/yfFL5lmnzUmEUaGPjeEslwqBo60RHF UPQQ== MIME-Version: 1.0 X-Received: by 10.50.208.68 with SMTP id mc4mr1171982igc.35.1366116392671; Tue, 16 Apr 2013 05:46:32 -0700 (PDT) Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.217.162 with HTTP; Tue, 16 Apr 2013 05:46:32 -0700 (PDT) In-Reply-To: <20130416060032.18997.28094.idtracker@ietfa.amsl.com> References: <20130416060032.18997.28094.idtracker@ietfa.amsl.com> Date: Tue, 16 Apr 2013 18:16:32 +0530 X-Google-Sender-Auth: fu4BGCEPPH2EmxZWWQTPUTXLuyQ Message-ID: From: Dhruv Dhody To: "pce@ietf.org" Content-Type: multipart/alternative; boundary=14dae93408e74e9f6d04da79c2ac Subject: [Pce] Fwd: New Version Notification for draft-dhody-pce-pcep-p2mp-per-destination-04.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 12:46:34 -0000 --14dae93408e74e9f6d04da79c2ac Content-Type: text/plain; charset=ISO-8859-1 *Hi,* * * *We presented the ID for inclusion/exclusion of abstract nodes for a subset of P2MP destinations in PCEP in Atlanta [ http://www.ietf.org/proceedings/85/slides/slides-85-pce-1.pdf]. * * * *Here is revision....* * * *Comments and feedback, always welcome. * * * *Dhruv * ---------- Forwarded message ---------- From: Date: Tue, Apr 16, 2013 at 11:30 AM Subject: New Version Notification for draft-dhody-pce-pcep-p2mp-per-destination-04.txt To: dhruv.ietf@gmail.com Cc: dhruv.dhody@huawei.com, venugopalreddyk@huawei.com, udayasree.palle@huawei.com A new version of I-D, draft-dhody-pce-pcep-p2mp-per-destination-04.txt has been successfully submitted by Dhruv Dhody and posted to the IETF repository. Filename: draft-dhody-pce-pcep-p2mp-per-destination Revision: 04 Title: Supporting explicit inclusion or exclusion of abstract nodes for a subset of P2MP destinations in Path Computation Element Communication Protocol (PCEP). Creation date: 2013-04-16 Group: Individual Submission Number of pages: 12 URL: http://www.ietf.org/internet-drafts/draft-dhody-pce-pcep-p2mp-per-destination-04.txt Status: http://datatracker.ietf.org/doc/draft-dhody-pce-pcep-p2mp-per-destination Htmlized: http://tools.ietf.org/html/draft-dhody-pce-pcep-p2mp-per-destination-04 Diff: http://www.ietf.org/rfcdiff?url2=draft-dhody-pce-pcep-p2mp-per-destination-04 Abstract: The ability to determine paths of point-to-multipoint (P2MP) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) is one the key requirements for Path Computation Element (PCE). [RFC6006] and [PCE-P2MP-PROCEDURES] describes these mechanisms for intra and inter domain path computation via PCE. This document describes the motivation and PCE communication Protocol (PCEP) extension for explicitly specifying abstract nodes for inclusion or exclusion for a subset of destinations during the Point to Multipoint (P2MP) path computation via PCE. The IETF Secretariat --14dae93408e74e9f6d04da79c2ac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable --14dae93408e74e9f6d04da79c2ac-- From internet-drafts@ietf.org Tue Apr 16 06:14:55 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E820C21F96E5; Tue, 16 Apr 2013 06:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kuvBRt2RRmJ; Tue, 16 Apr 2013 06:14:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5957A21F96D9; Tue, 16 Apr 2013 06:14:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130416131453.31092.10378.idtracker@ietfa.amsl.com> Date: Tue, 16 Apr 2013 06:14:53 -0700 Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-vendor-constraints-09.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 13:14:56 -0000 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 : Conveying Vendor-Specific Constraints in the Path Comput= ation Element Protocol Author(s) : Fatai Zhang Adrian Farrel Filename : draft-ietf-pce-vendor-constraints-09.txt Pages : 12 Date : 2013-04-16 Abstract: The Path Computation Element Protocol (PCEP) is used to convey path computation requests and responses between Path Computation Clients (PCCs) and Path Computation Elements (PCEs), and also between cooperating PCEs. In PCEP the path computation requests carry details of the constraints and objective functions that the PCC wishes the PCE to apply in its computation. The mechanisms defined for indicating objective functions include the capability to convey vendor-specific objective functions. This document defines a facility to carry vendor-specific constraints in PCEP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-vendor-constraints There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-vendor-constraints-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pce-vendor-constraints-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From adrian@olddog.co.uk Tue Apr 16 06:21:19 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5111B21F938E for ; Tue, 16 Apr 2013 06:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.394 X-Spam-Level: X-Spam-Status: No, score=-1.394 tagged_above=-999 required=5 tests=[AWL=1.205, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fe12wVQHPAAI for ; Tue, 16 Apr 2013 06:21:18 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id E0E9D21F96FE for ; Tue, 16 Apr 2013 06:21:17 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r3GDLGZD023360 for ; Tue, 16 Apr 2013 14:21:16 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r3GDLG5N023334 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 16 Apr 2013 14:21:16 +0100 From: "Adrian Farrel" To: References: <20130416131455.31092.45508.idtracker@ietfa.amsl.com> In-Reply-To: <20130416131455.31092.45508.idtracker@ietfa.amsl.com> Date: Tue, 16 Apr 2013 14:21:11 +0100 Message-ID: <00f301ce3aa5$43a4ed20$caeec760$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKh54k9kJ2DMDOWuqR7nNfF/DXOkJcxediA Content-Language: en-gb Subject: [Pce] FW: New Version Notification for draft-ietf-pce-vendor-constraints-09.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 13:21:20 -0000 Hi, This is just a refresh of the I-D with a few layout changes to keep = idnits happy. Fatai and I are discussing a few additional changes with Ina. The intent = is to make the work slightly more widely applicable (specifically to = PCEP extensions for stateful PCE) without causing any changes to the use = cases already defined. I'll propose some text modifications to the list = shortly. Our hope (well, Fatai and I have this hope) is that after those changes = the document will be ready for WG last call. So now is a good time to = review and comment. Cheers, Adrian > A new version of I-D, draft-ietf-pce-vendor-constraints-09.txt > has been successfully submitted by Adrian Farrel and posted to the > IETF repository. >=20 > Filename: draft-ietf-pce-vendor-constraints > Revision: 09 > Title: Conveying Vendor-Specific Constraints in the Path Computation > Element Protocol > Creation date: 2013-04-16 > Group: pce > Number of pages: 12 > URL: = http://www.ietf.org/internet-drafts/draft-ietf-pce-vendor- > constraints-09.txt > Status: = http://datatracker.ietf.org/doc/draft-ietf-pce-vendor-constraints > Htmlized: = http://tools.ietf.org/html/draft-ietf-pce-vendor-constraints-09 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pce-vendor-constraints-09 >=20 > Abstract: > The Path Computation Element Protocol (PCEP) is used to convey path > computation requests and responses between Path Computation Clients > (PCCs) and Path Computation Elements (PCEs), and also between > cooperating PCEs. In PCEP the path computation requests carry > details of the constraints and objective functions that the PCC > wishes the PCE to apply in its computation. >=20 > The mechanisms defined for indicating objective functions include > the capability to convey vendor-specific objective functions. This > document defines a facility to carry vendor-specific constraints in > PCEP. From adrian@olddog.co.uk Sat Apr 20 12:26:38 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A88121F8F4A for ; Sat, 20 Apr 2013 12:26:38 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkDUqFpP8kgk for ; Sat, 20 Apr 2013 12:26:37 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id C242E21F8917 for ; Sat, 20 Apr 2013 12:26:35 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r3KJQX6l025136; Sat, 20 Apr 2013 20:26:34 +0100 Received: from 950129200 (50-76-52-235-ip-static.hfc.comcastbusiness.net [50.76.52.235]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r3KJQO0t025109 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 20 Apr 2013 20:26:29 +0100 From: "Adrian Farrel" To: Date: Sat, 20 Apr 2013 20:26:23 +0100 Message-ID: <04b501ce3dfc$f7151510$e53f3f30$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac49/OXDd5Svs6XwTduiMX3ia5GhJQ== Content-Language: en-gb Subject: [Pce] What are your unanswered questions about PCE? X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 19:26:38 -0000 Hi, Dan and I have updated our draft as below. We added the table of comparison of stateful/active/etc. as recently = discussed on the list. Also a section about the relationship with SDN. And a paragraph about the potential for using PCEP as an = information-gathering protocol. That covers, I think, everything that has been discussed on the list. We would be really happy to hear from you if you have questions about = PCE that you feel are unanswered in the community. Thanks, Adrian > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: 20 April 2013 20:18 > To: Adrian Farrel; Daniel King > Subject: New Version Notification for = draft-farrkingel-pce-questions-02.txt >=20 >=20 > A new version of I-D, draft-farrkingel-pce-questions-02.txt > has been successfully submitted by Adrian Farrel and posted to the > IETF repository. >=20 > Filename: draft-farrkingel-pce-questions > Revision: 02 > Title: Unanswered Questions in the Path Computation Element > Architecture > Creation date: 2013-04-20 > Group: Individual Submission > Number of pages: 24 > URL: = http://www.ietf.org/internet-drafts/draft-farrkingel-pce-questions- > 02.txt > Status: = http://datatracker.ietf.org/doc/draft-farrkingel-pce-questions > Htmlized: = http://tools.ietf.org/html/draft-farrkingel-pce-questions-02 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-farrkingel-pce-questions-02 From adrian@olddog.co.uk Mon Apr 22 22:01:25 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35A9C21F958A for ; Mon, 22 Apr 2013 22:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrybtzNKwWfT for ; Mon, 22 Apr 2013 22:01:24 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 5805821F955A for ; Mon, 22 Apr 2013 22:01:23 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r3N51C2v026626 for ; Tue, 23 Apr 2013 06:01:12 +0100 Received: from 950129200 (50-76-52-228-ip-static.hfc.comcastbusiness.net [50.76.52.228]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r3N51AEp026608 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 23 Apr 2013 06:01:12 +0100 From: "Adrian Farrel" To: Date: Tue, 23 Apr 2013 06:01:07 +0100 Message-ID: <019301ce3fdf$91defcd0$b59cf670$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4/33lZH+oC/e19TmCf1gdneZfOmA== Content-Language: en-gb Subject: [Pce] Revising PCEP Vendor Constraints X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 05:01:25 -0000 Hi, I spent some time discussing changes to draft-ietf-pce-vendor-constraints with Ina and Fatai. It turns out that the main change is to rename the object and TLV from "vendor constraints" to "vendor information". The scope of *this* draft still remains vendor constraints, but largely through this renaming, we make the mechanism available for other vendor-specific uses documented in future specifications. Otherwise, it seems to me that the changes are not actually substantive, so I will post a new revision and let you comment. If you have any issues, let's discuss them and see what additional changes we need to make. Cheers, Adrian From internet-drafts@ietf.org Mon Apr 22 22:05:20 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A7F21F9604; Mon, 22 Apr 2013 22:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGXE8DoeLBqC; Mon, 22 Apr 2013 22:05:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A19DE21F8494; Mon, 22 Apr 2013 22:05:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130423050519.19411.17420.idtracker@ietfa.amsl.com> Date: Mon, 22 Apr 2013 22:05:19 -0700 Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-vendor-constraints-10.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 05:05:20 -0000 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 : Conveying Vendor-Specific Constraints in the Path Comput= ation Element Protocol Author(s) : Fatai Zhang Adrian Farrel Filename : draft-ietf-pce-vendor-constraints-10.txt Pages : 11 Date : 2013-04-22 Abstract: The Path Computation Element Protocol (PCEP) is used to convey path computation requests and responses between Path Computation Clients (PCCs) and Path Computation Elements (PCEs), and also between cooperating PCEs. In PCEP the path computation requests carry details of the constraints and objective functions that the PCC wishes the PCE to apply in its computation. This document defines a facility to carry vendor-specific information in PCEP using a dedicated object and a new Type-Length-Variable that can be carried in any existing PCEP object. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-vendor-constraints There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-vendor-constraints-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pce-vendor-constraints-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From johnsonhammond1@hushmail.com Sat Apr 27 15:47:31 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 998E821F991C for ; Sat, 27 Apr 2013 15:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ds2pOQb5W4mA for ; Sat, 27 Apr 2013 15:47:31 -0700 (PDT) Received: from smtp10.hushmail.com (smtp10a.hushmail.com [65.39.178.239]) by ietfa.amsl.com (Postfix) with ESMTP id C631021F9921 for ; Sat, 27 Apr 2013 15:47:29 -0700 (PDT) Received: from smtp10.hushmail.com (smtp10a.hushmail.com [65.39.178.239]) by smtp10.hushmail.com (Postfix) with SMTP id AD26F1B5320 for ; Sat, 27 Apr 2013 17:30:16 +0000 (UTC) X-hush-relay-time: 213 X-hush-relay-id: b1bd903faba185ee07e5a0ed3a1fde37 Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp10.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 17:30:16 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 32323E6736; Sat, 27 Apr 2013 17:30:14 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 13:30:14 -0400 To: pce@ietf.org From: johnsonhammond1@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427173015.32323E6736@smtp.hushmail.com> Subject: [Pce] Biggest Fake Conference in Computer Science X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 22:47:32 -0000 Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. From julien.meuric@orange.com Tue Apr 30 02:13:05 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB18021F9B6A for ; Tue, 30 Apr 2013 02:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNEy1zAZ43Wt for ; Tue, 30 Apr 2013 02:13:00 -0700 (PDT) Received: from r-mail1.rd.orange.com (r-mail1.rd.orange.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id C64B621F9AA3 for ; Tue, 30 Apr 2013 02:13:00 -0700 (PDT) Received: from r-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9CF31DE4003; Tue, 30 Apr 2013 11:14:41 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.orange.com (Postfix) with ESMTP id 91105A44291; Tue, 30 Apr 2013 11:14:41 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 30 Apr 2013 11:12:58 +0200 Received: from [10.193.71.218] ([10.193.71.218]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 30 Apr 2013 11:12:58 +0200 Message-ID: <517F8B19.3080809@orange.com> Date: Tue, 30 Apr 2013 11:12:57 +0200 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: draft-ietf-pce-gmpls-aps-req@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Apr 2013 09:12:58.0222 (UTC) FILETIME=[E81728E0:01CE4582] Cc: "pce@ietf.org" Subject: [Pce] Last IPR Check on draft-ietf-pce-gmpls-aps-req-07 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 09:13:06 -0000 Dear authors of the aforementioned I-D, Are you aware of any other IPR that applies to draft-ietf-pce-gmpls-aps-req? If so, has all this IPR been disclosed in compliance with IETF IPR rules? (see RFCs 3979, 4879, 3669 and 5378 for more details) Note that an IPR was disclosed on this I-D last summer. A response from each of you is expected. Regards, JP & Julien
Hi,

Here is revision....

Comments and feedback, always welcome.=A0

Dhruv

---------- Forwarded message ----------=
From: <internet-drafts@ietf.org>
Date: Tue, Apr 16, 2013 at 11:30 AM
Subject: New Version Notification fo= r draft-dhody-pce-pcep-p2mp-per-destination-04.txt
To: dhruv.ietf@gmail.com
Cc: dhruv.dhody@huawei.com, venugopalreddyk@huawei.com, udayasree.palle@huawei.com



A new version of I-D, draft-dhody-pce-pcep-p2mp-per-destination-04.txt
has been successfully submitted by Dhruv Dhody and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-dhody-pce-pcep-p2mp-per-destination
Revision: =A0 =A0 =A0 =A004
Title: =A0 =A0 =A0 =A0 =A0 Supporting explicit inclusion or exclusion of ab= stract nodes for a subset of P2MP destinations in Path Computation Element = Communication Protocol (PCEP).
Creation date: =A0 2013-04-16
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 12
URL: =A0 =A0 =A0 =A0 =A0 =A0 http:/= /www.ietf.org/internet-drafts/draft-dhody-pce-pcep-p2mp-per-destination-04.= txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.= ietf.org/doc/draft-dhody-pce-pcep-p2mp-per-destination
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/h= tml/draft-dhody-pce-pcep-p2mp-per-destination-04
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.= ietf.org/rfcdiff?url2=3Ddraft-dhody-pce-pcep-p2mp-per-destination-04
Abstract:
=A0 =A0The ability to determine paths of point-to-multipoint (P2MP)
=A0 =A0Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) =A0 =A0Traffic Engineering Label Switched Paths (TE LSPs) is one the key =A0 =A0requirements for Path Computation Element (PCE). =A0[RFC6006] and =A0 =A0[PCE-P2MP-PROCEDURES] describes these mechanisms for intra and inter=
=A0 =A0domain path computation via PCE.

=A0 =A0This document describes the motivation and PCE communication Protoco= l
=A0 =A0(PCEP) extension for explicitly specifying abstract nodes for
=A0 =A0inclusion or exclusion for a subset of destinations during the Point=
=A0 =A0to Multipoint (P2MP) path computation via PCE.




The IETF Secretariat