From nobody Thu Oct 2 07:58:24 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3DE61A01F6; Thu, 2 Oct 2014 07:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1uCf5Pgkyao7; Thu, 2 Oct 2014 07:58:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C104F1A03E3; Thu, 2 Oct 2014 07:58:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141002145807.1087.31950.idtracker@ietfa.amsl.com> Date: Thu, 02 Oct 2014 07:58:07 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/a0djKQeklI5TeaK9iAz4GiASs_c Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-pceps-02.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 14:58:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Secure Transport for PCEP Authors : Diego R. Lopez Oscar Gonzalez de Dios Qin Wu Dhruv Dhody Filename : draft-ietf-pce-pceps-02.txt Pages : 15 Date : 2014-10-02 Abstract: The Path Computation Element Communication Protocol (PCEP) defines the mechanisms for the communication between a Path Computation Client (PCC) and a Path Computation Element (PCE), or among PCEs. This document describe the usage of Transport Layer Security (TLS) to enhance PCEP security, hence the PCEPS acronym proposed for it. The additional security mechanisms are provided by the transport protocol supporting PCEP, and therefore they do not affect its flexibility and extensibility. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-pceps/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-pceps-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pceps-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Oct 2 08:04:31 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB38A1A7021 for ; Thu, 2 Oct 2014 08:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6KEE29pJe7Jg for ; Thu, 2 Oct 2014 08:04:25 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42DA91A86ED for ; Thu, 2 Oct 2014 08:04:25 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id at20so2692344iec.40 for ; Thu, 02 Oct 2014 08:04:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3BScIZsdZa9QZTfyxfPYvJFttqO31fPVnQaeHLWqgj8=; b=eLOHElHwOeGrjcTcHWgu9PclABUCUfsYr55veqkfOfKLQQq8PPMykPcpJOPYnBChLw JyVT8ZrzBtG7DCJSz3Xg4oVxpZFcO+HN4uL2rgXF0HC4tWaGU5ViNkO1s3GFeCYkIXK4 6UYKjadPCBrxEiBXdVu329aUTYNyULit9m7e+CrLIyqLxEfbYIv62KH53YlIoRB+A/+/ 8TZKRQ9Rp8BVVTYagwPRV7Wt3UQCYTOz0jd/2K5v8RObqLghdqulUjYOSKiLAedP8AbP 23O0vRRBiglhOuaVzzYhXZCKFlH1mb2lo4+5hdq86jf6c7xZLwCnUT7Z/J6388PidcDZ D7FA== MIME-Version: 1.0 X-Received: by 10.50.72.43 with SMTP id a11mr5418443igv.23.1412262264637; Thu, 02 Oct 2014 08:04:24 -0700 (PDT) Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.90.105 with HTTP; Thu, 2 Oct 2014 08:04:24 -0700 (PDT) Date: Thu, 2 Oct 2014 20:34:24 +0530 X-Google-Sender-Auth: pVGICKxzWjK0e1obgNVhZLd0H-I Message-ID: From: Dhruv Dhody To: DIEGO LOPEZ GARCIA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/pce/uHVwslQdM8tmLYDqteiXLx8cMRI Cc: "pce@ietf.org" Subject: [Pce] I-D Action: draft-ietf-pce-pceps-02.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 15:04:27 -0000 Hi, As mentioned by Diego last month, we have now updated the draft with specification for StartTLS message and its impact on the base protocol. The new revision can be found at - https://datatracker.ietf.org/doc/draft-ietf-pce-pceps/ http://tools.ietf.org/html/draft-ietf-pce-pceps-02 Diff at - http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pce-pceps-02 Regards, Dhruv On Thu, Sep 11, 2014 at 3:16 PM, DIEGO LOPEZ GARCIA wrote: > Hi, > > This new version essentially introduces the idea of a StartTLS message, > which was the agreement for TLS startup after the discussion of the draft > with Transport Area experts. A few aspects remain open for further > experimentation and refinement, though. > > Be goode, > > Begin forwarded message: > > From: > Subject: [Pce] I-D Action: draft-ietf-pce-pceps-01.txt > Date: 11 September 2014 at 11:35:46.000 GMT+2 > To: > Cc: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Path Computation Element Working Group o= f > the IETF. > > Title : Secure Transport for PCEP > Authors : Diego R. Lopez > Oscar Gonzalez de Dios > Qin Wu > Dhruv Dhody > Filename : draft-ietf-pce-pceps-01.txt > Pages : 12 > Date : 2014-09-11 > > Abstract: > The Path Computation Element Communication Protocol (PCEP) defines > the mechanisms for the communication between a Path Computation > Client (PCC) and a Path Computation Element (PCE), or among PCEs. > This document describe the usage of Transport Layer Security (TLS) to > enhance PCEP security, hence the PCEPS acronym proposed for it. The > additional security mechanisms are provided by the transport protocol > supporting PCEP, and therefore they do not affect its flexibility and > extensibility. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-pce-pceps/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-pce-pceps-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pce-pceps-01 > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > > -- > PLEASE NOTE MY NEW EMAIL ADDRESS > "Esta vez no fallaremos, Doctor Infierno" > > Dr Diego R. Lopez > Telefonica I+D > http://people.tid.es/diego.lopez/ > > e-mail: diego.r.lopez@telefonica.com > Tel: +34 913 129 041 > Mobile: +34 682 051 091 > ---------------------------------- > > > ________________________________ > > Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, > puede contener informaci=C3=B3n privilegiada o confidencial y es para uso > exclusivo de la persona o entidad de destino. Si no es usted. el > destinatario indicado, queda notificado de que la lectura, utilizaci=C3= =B3n, > divulgaci=C3=B3n y/o copia sin autorizaci=C3=B3n puede estar prohibida en= virtud de la > legislaci=C3=B3n vigente. Si ha recibido este mensaje por error, le rogam= os que > nos lo comunique inmediatamente por esta misma v=C3=ADa y proceda a su > destrucci=C3=B3n. > > The information contained in this transmission is privileged and > confidential information intended only for the use of the individual or > entity named above. If the reader of this message is not the intended > recipient, you are hereby notified that any dissemination, distribution o= r > copying of this communication is strictly prohibited. If you have receive= d > this transmission in error, do not read it. Please immediately reply to t= he > sender that you have received this communication in error and then delete > it. > > Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=C3= =A1rio, > pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9 pa= ra uso exclusivo > da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vossa senhoria o des= tinat=C3=A1rio > indicado, fica notificado de que a leitura, utiliza=C3=A7=C3=A3o, divulga= =C3=A7=C3=A3o e/ou > c=C3=B3pia sem autoriza=C3=A7=C3=A3o pode estar proibida em virtude da le= gisla=C3=A7=C3=A3o vigente. > Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique > imediatamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > From nobody Sun Oct 5 05:47:45 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA8B81A02E5; Sun, 5 Oct 2014 05:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TN4dGWlx1g14; Sun, 5 Oct 2014 05:47:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 231941A0294; Sun, 5 Oct 2014 05:47:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141005124741.29041.22144.idtracker@ietfa.amsl.com> Date: Sun, 05 Oct 2014 05:47:41 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/4v5Ig_T_myrbpNbPWWC9y7wabpg Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-questions-07.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2014 12:47:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Unanswered Questions in the Path Computation Element Architecture Authors : Adrian Farrel Daniel King Filename : draft-ietf-pce-questions-07.txt Pages : 27 Date : 2014-10-05 Abstract: The Path Computation Element (PCE) architecture is set out in RFC 4655. The architecture is extended for multi-layer networking with the introduction of the Virtual Network Topology Manager (VNTM) in RFC 5623, and generalized to Hierarchical PCE (H-PCE) in RFC 6805. These three architectural views of PCE deliberately leave some key questions unanswered especially with respect to the interactions between architectural components. This document draws out those questions and discusses them in an architectural context with reference to other architectural components, existing protocols, and recent IETF work efforts. This document does not update the architecture documents and does not define how protocols or components must be used. It does, however, suggest how the architectural components might be combined to provide advanced PCE function. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-questions/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-questions-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-questions-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 6 06:57:33 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4CA1A6F8B for ; Mon, 6 Oct 2014 06:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.814 X-Spam-Level: ** X-Spam-Status: No, score=2.814 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_62=0.6, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1PWcSMR2Pln for ; Mon, 6 Oct 2014 06:57:30 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1C4B1A6F8A for ; Mon, 6 Oct 2014 06:57:29 -0700 (PDT) Received: by mail-ig0-f169.google.com with SMTP id uq10so5044907igb.2 for ; Mon, 06 Oct 2014 06:57:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=40tTWgPYDCnNhWoyK7MpsYA3Xfcq5Us6ob/Fc9diCp4=; b=A5DyTo+iY0ccfwTkDxdjlSwBfmouDqGa9N9BXHuuEcml2M292+g0RKjbH+g3F9Wtsp hVHI2Iy2cEQ4pVWMDsaHgeEtbUo3jAlN5Sn1NKSzRV6z7ovKEmctgi/pRUxwceXG/ldG uyte/VK9kG1MD6ZzVU3v/5K6XZV4ra4FzcSBE5t5gZ/7uSZOEZdCCFhXYb1wKJrdcZAL 4ezcdnH4Wfix/ZiqCAp4acKDN11LTlhB/ESGKq2qo8D7JjhP8/eAxvdOH/lPEdo7H0Nh MgQSVZlgkmIFZw8S+W7PeGXkspbH1dNviD1d2c6kbyuB6x8EOEmnkwlidlbN5LdWkTKo 3sgg== MIME-Version: 1.0 X-Received: by 10.42.90.80 with SMTP id j16mr32138275icm.27.1412603849153; Mon, 06 Oct 2014 06:57:29 -0700 (PDT) Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.90.105 with HTTP; Mon, 6 Oct 2014 06:57:29 -0700 (PDT) In-Reply-To: References: Date: Mon, 6 Oct 2014 19:27:29 +0530 X-Google-Sender-Auth: OibjAUROTY9r1AA4dbv-HaBR9xc Message-ID: From: Dhruv Dhody To: "JP Vasseur (jvasseur)" Content-Type: multipart/mixed; boundary=90e6ba3fd081a33d170504c17681 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/gz8teIRAnXoFXNo8fm-jAM2L4M8 Cc: "pce@ietf.org" Subject: Re: [Pce] WG Last Call on draft-ietf-pce-stateful-pce-app-02 and draft-ietf-pce-stateful-pce-09 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 13:57:32 -0000 --90e6ba3fd081a33d170504c17681 Content-Type: text/plain; charset=UTF-8 Hi WG, Support both the documents, and are basically ready for publications. I re-read the documents again, here are some nits/comments which can be handled along the process. -------- For draft-ietf-pce-stateful-pce-app: (listed as a contributor) - In sec 3. Overview of the Stateful PCE Protocol Extensions; the word tunnel is used in below paragraph, for consistency with rest of the document can it be changed to LSP. [I-D.ietf-pce-stateful-pce] specifies a set of extensions to PCEP to enable stateful control of tunnels within and across PCEP sessions in compliance with [RFC4657]. It includes mechanisms to effect tunnel state synchronization between PCCs and PCEs, delegation of control over tunnels to PCEs, and PCE control of timing and sequence of path computations within and across PCEP sessions. Since we are not using RFC2119 keywords in this document, we should not use 'SHOULD'. LSP state synchronization (C-E): after the session between a PCC and a stateful PCE is initialized, the PCE can perform path computation and update attributes in a PCC. However, if the goal of the PCE is to provide accurate path information based on the most up-to-date state of the network, the PCE SHOULD wait until it learns the state of the PCC's LSP states before doing so. - In sec 4.3. PCE Survivability; a reference to draft-ietf-pce-stateful-sync-optimizations can be added for readability. - Expand on first use PCReq, LER, NMS, RRO, RSVP-TE - Suggest if you can add IANA consideration section and explicitly say that there are no request for IANA in this document. - Some unused references like MXMN-TE, MPLS-PC, NET-REC (perhaps because of older version text from draft-ietf-pce-stateful-pce) -------- For draft-ietf-pce-stateful-pce: - RFC2119 keywords requirement language should be added as subsection in introduction. 1.1 Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. - In sec 3.2. Objectives OLD: Allow a PCC to delegate control of its LSPs to an active stateful PCE such that a single LSP is under the control a single PCE at any given time. NEW: Allow a PCC to delegate control of its LSPs to an active stateful PCE such that a LSP is under the control a single PCE at any given time. The current text gives an impression that only one LSP (a single LSP) is under control of a PCE. - In sec 5.4. State Synchronization, for figure 2 and 3 'PCErr=?' is used, I suggest either to put the error type/code or remove '=?'. - Update reference for minei-pce-stateful-sync-optimizations to ietf-pce-stateful-sync-optimizations - I am not sure what is the correct way to put comments inside RBNF, or better yet they should simply be avoided. In section 6.3, 6.4 and 6.5 "<<<<" and "<---" are used. - The alignment for the byte markers is incorrect in figure 10 - In sec 7.3.2. Symbolic Path Name TLV, can the following text be added? The Symbolic Path Name is padded to 4-bytes alignment; padding itself is not included in the Length field. - In sec 7.3.3. LSP Error Code TLV, we should say - "The following LSP Error Codes are *currently* defined:"; so that future documents can easily extend it. - In 9.6. Impact on Network Operation s/PcE/PCE - ietf-pce-gmpls-pcep-extensions can be removed as a normative reference. - there are bunch of idnits that you may wish to handle (see attached) -------- Dhruv On Sun, Sep 14, 2014 at 3:42 PM, JP Vasseur (jvasseur) wrote: > Dear WG, > > Both draft-ietf-pce-stateful-pce-app-02 and draft-ietf-pce-stateful-pce-09 > are now stable ready for WG Last Call. > This starts a 3-week WG Last call, which will end on Oct 6 at noon ET. > > Please send your comments on the mailing list. > > ps: this WG LC will be followed by another WG LC on > draft-ietf-pce-stateful-sync-optimizations-01 > and draft-ietf-pce-pce-initiated-lsp-01. > > > Thanks. > > JP and Julien. > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > --90e6ba3fd081a33d170504c17681 Content-Type: text/plain; charset=US-ASCII; name="draft-ietf-pce-stateful-pce-09-idnits.txt" Content-Disposition: attachment; filename="draft-ietf-pce-stateful-pce-09-idnits.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_i0xvn1md0 CjwhRE9DVFlQRSBIVE1MIFBVQkxJQyAiLS8vVzNDLy9EVEQgWEhUTUwgMS4wIFRyYW5zaXRpb25h bC8vRU4iICJodHRwOi8vd3d3LnczLm9yZy9UUi94aHRtbDEvRFREL3hodG1sMS10cmFuc2l0aW9u YWwuZHRkIj4KPGh0bWwgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGh0bWwiPjwhLS0g SW5zdGFuY2VCZWdpbiB0ZW1wbGF0ZT0iL1RlbXBsYXRlcy9HZW5lcmFsUGFnZS5kd3QiIGNvZGVP dXRzaWRlSFRNTElzTG9ja2VkPSJ0cnVlIiAtLT4KPGhlYWQ+Cgo8bWV0YSBodHRwLWVxdWl2PSJD b250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1VVEYtOCIgLz4KPCEtLSBJ bnN0YW5jZUJlZ2luRWRpdGFibGUgbmFtZT0idGl0bGUiIC0tPgo8dGl0bGU+SUVURiBJRE5JVFMg VG9vbDwvdGl0bGU+CjwhLS0gSW5zdGFuY2VFbmRFZGl0YWJsZSAtLT4KPHNjcmlwdCB0eXBlPSJ0 ZXh0L2phdmFzY3JpcHQiIGxhbmd1YWdlPSJKYXZhU2NyaXB0IiBzcmM9Ii9jc3MvaWV0Zi5qcyI+ PC9zY3JpcHQ+CjxzY3JpcHQgdHlwZT0idGV4dC9qYXZhc2NyaXB0Ij4KZG9jdW1lbnQud3JpdGUo JzxsaW5rIGlkPSJzaGVldDQiIGhyZWY9Ii9jc3MvaWV0ZjQuY3NzIiByZWw9InN0eWxlc2hlZXQi IHR5cGU9InRleHQvY3NzIiAvPicpOwpkb2N1bWVudC53cml0ZSgnPGxpbmsgaWQ9InNoZWV0MyIg aHJlZj0iL2Nzcy9pZXRmMy5jc3MiIHJlbD0ic3R5bGVzaGVldCIgdHlwZT0idGV4dC9jc3MiIC8+ Jyk7CmRvY3VtZW50LndyaXRlKCc8bGluayBpZD0ic2hlZXQyIiBocmVmPSIvY3NzL2lldGYyLmNz cyIgcmVsPSJzdHlsZXNoZWV0IiB0eXBlPSJ0ZXh0L2NzcyIgLz4nKTsKPC9zY3JpcHQ+CjxsaW5r IGlkPSJzaGVldDEiIGhyZWY9Ii9jc3MvaWV0Zi5jc3MiIHJlbD0ic3R5bGVzaGVldCIgdHlwZT0i dGV4dC9jc3MiIC8+CjwvaGVhZD4KPGJvZHkgb25sb2FkPSJzZXRTdHlsZSgwKTsiPgo8ZGl2IGlk PSJjb250YWluZXIiPgogIDx0YWJsZSBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3Bh Y2luZz0iMCI+CiAgICA8dGJvZHk+CiAgICAgIDx0cj4KICAgICAgICA8dGQgaWQ9InNpZGViYXIx Ij48ZGl2IGlkPSJzaWRlYmFyMiI+PGEgaHJlZj0iLyI+PGltZyBzcmM9Ii9pbWFnZXMvaWV0Zmxv Z290cmFucy5naWYiIGFsdD0iTG9nbyIgaGVpZ2h0PSI3NSIgd2lkdGg9IjE0MCIgYm9yZGVyPSIw Ii8+PC9hPgogICAgICAgICAgICA8ZGl2IHN0eWxlPSJtYXJnaW46MDtwYWRkaW5nOjA7d2hpdGUt c3BhY2U6IG5vd3JhcDsiPgogICAgICAgICAgICAgIDxmb3JtIG1ldGhvZD0iZ2V0IiBhY3Rpb249 Imh0dHA6Ly93d3cuZ29vZ2xlLmNvbS91L2lldGYiIHN0eWxlPSJtYXJnaW46MDtwYWRkaW5nOjA7 d2hpdGUtc3BhY2U6IG5vd3JhcDsiPgogICAgICAgICAgICAgICAgPHAgc3R5bGU9Im1hcmdpbjow O3BhZGRpbmc6MDt3aGl0ZS1zcGFjZTogbm93cmFwOyI+CiAgICAgICAgICAgICAgICAgIDxpbnB1 dCBuYW1lPSJxIiBzaXplPSIxNiIgbWF4bGVuZ3RoPSIyNTUiIHZhbHVlPSIiIHR5cGU9InRleHQi IHN0eWxlPSJtYXJnaW46MXB4O3BhZGRpbmc6MDt3aWR0aDoxMDBweDtib3JkZXI6MXB4IHNvbGlk ICM4OWQ7IiAvPgogICAgICAgICAgICAgICAgICA8aW5wdXQgbmFtZT0iU2VhcmNoIiB2YWx1ZT0i U2VhcmNoIiB0eXBlPSJzdWJtaXQiIHN0eWxlPSJtYXJnaW46MDtwYWRkaW5nOjA7Zm9udC1zaXpl Ojg1JTsiIC8+CiAgICAgICAgICAgICAgICA8L3A+CiAgICAgICAgICAgICAgPC9mb3JtPgogICAg ICAgICAgICA8L2Rpdj4KICAgICAgICAgICAgPHVsPgogICAgICAgICAgICAgIDxsaSBjbGFzcz0i c3ViaGRyMDAiPjxhIGNsYXNzPSJzdWJoZHIwMCIgaHJlZj0iLyI+PHN0cm9uZz5Ib21lPC9zdHJv bmc+PC9hPjwvbGk+CiAgICAgICAgICAgICAgPGxpIGNsYXNzPSJzdWJoZHIwMCI+PGEgY2xhc3M9 InN1YmhkcjAwIiBocmVmPSIvYWJvdXQvIj48c3Ryb25nPkFib3V0IHRoZSBJRVRGPC9zdHJvbmc+ PC9hPjwvbGk+CiAgICAgICAgICAgICAgPGxpIGNsYXNzPSJzdWJoZHIwMiI+PGEgY2xhc3M9InN1 YmhkcjAyIiBocmVmPSIvYWJvdXQvbWlzc2lvbi5odG1sIj5NaXNzaW9uPC9hPjwvbGk+CiAgICAg ICAgICAgICAgPGxpIGNsYXNzPSJzdWJoZHIwMiI+PGEgY2xhc3M9InN1YmhkcjAyIiBocmVmPSIv YWJvdXQvc3RhbmRhcmRzLXByb2Nlc3MuaHRtbCI+U3RhbmRhcmRzJm5ic3A7UHJvY2VzczwvYT48 L2xpPgogICAgICAgICAgICAgIDxsaSBjbGFzcz0ic3ViaGRyMDIiPjxhIGNsYXNzPSJzdWJoZHIw MiIgaHJlZj0iL2Fib3V0L25vdGUtd2VsbC5odG1sIj5Ob3RlJm5ic3A7V2VsbDwvYT48L2xpPgog ICAgICAgICAgICAgIDxsaSBjbGFzcz0ic3ViaGRyMDIiPjxhIGNsYXNzPSJzdWJoZHIwMiIgaHJl Zj0iL25vbWNvbS8iPk5vbUNvbTwvYT48L2xpPgogICAgICAgICAgICAgIDxsaSBjbGFzcz0ic3Vi aGRyMDIiPjxhIGNsYXNzPSJzdWJoZHIwMiIgaHJlZj0iL25ld2NvbWVycy5odG1sIj5JbmZvJm5i c3A7Zm9yJm5ic3A7TmV3Y29tZXJzPC9hPjwvbGk+CiAgICAgICAgICAgICAgPGxpIGNsYXNzPSJz dWJoZHIwMCI+PGEgY2xhc3M9InN1YmhkcjAwIiBocmVmPSIvaWQtaW5mby8iPjxzdHJvbmc+SW50 ZXJuZXQtRHJhZnRzPC9zdHJvbmc+PC9hPjwvbGk+CiAgICAgICAgICAgICAgPGxpIGNsYXNzPSJz dWJoZHIwMiI+PGEgY2xhc3M9InN1YmhkcjAyIiBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnLyI+RGF0YXRyYWNrZXI8L2E+PC9saT4KICAgICAgICAgICAgICA8bGkgY2xhc3M9InN1 YmhkcjAyIj48YSBjbGFzcz0ic3ViaGRyMDIiIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZHJhZnRzLyI+U2VhcmNoPC9hPjwvbGk+CiAgICAgICAgICAgICAgPGxpIGNsYXNzPSJz dWJoZHIwMiI+PGEgY2xhc3M9InN1YmhkcjAyIiBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2lkc3QvdXBsb2FkLmNnaSI+U3VibWl0PC9hPjwvbGk+CiAgICAgICAgICAgICAgPGxp IGNsYXNzPSJzdWJoZHIwMCI+PGEgY2xhc3M9InN1YmhkcjAwIiBocmVmPSIvcmZjLmh0bWwiPjxz dHJvbmc+UkZDIFBhZ2VzPC9zdHJvbmc+PC9hPjwvbGk+CiAgICAgICAgICAgICAgPGxpIGNsYXNz PSJzdWJoZHIwMiI+PGEgY2xhc3M9InN1YmhkcjAyIiBocmVmPSJodHRwOi8vcmZjLWVkaXRvci5v cmcvcmZjc2VhcmNoLmh0bWwiPlNlYXJjaCZuYnNwO1JGQyZuYnNwO0VkJm5ic3A7SW5kZXg8L2E+ PC9saT4KICAgICAgICAgICAgICA8bGkgY2xhc3M9InN1YmhkcjAyIj48YSBjbGFzcz0ic3ViaGRy MDIiIGhyZWY9Imh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvcXVldWUyLmh0bWwiPlJGQyZuYnNw O0VkaXRvciZuYnNwO1F1ZXVlPC9hPjwvbGk+CiAgICAgICAgICAgICAgPGxpIGNsYXNzPSJzdWJo ZHIwMCI+PGEgY2xhc3M9InN1YmhkcjAwIiBocmVmPSIvaWFuYS5odG1sIj48c3Ryb25nPklBTkEg UGFnZXM8L3N0cm9uZz48L2E+PC9saT4KICAgICAgICAgICAgICA8bGkgY2xhc3M9InN1YmhkcjAy Ij48YSBjbGFzcz0ic3ViaGRyMDIiIGhyZWY9Ii9hc3NpZ25tZW50cy8iPlByb3RvY29sJm5ic3A7 UGFyYW1ldGVyczwvYT48L2xpPgogICAgICAgICAgICAgIDxsaSBjbGFzcz0ic3ViaGRyMDAiPjxh IGNsYXNzPSJzdWJoZHIwMCIgaHJlZj0iL3dnLyI+PHN0cm9uZz5Xb3JraW5nIEdyb3Vwczwvc3Ry b25nPjwvYT48L2xpPgogICAgICAgICAgICAgIDxsaSBjbGFzcz0ic3ViaGRyMDIiPjxhIGNsYXNz PSJzdWJoZHIwMiIgaHJlZj0iL2R5bi93Zy9jaGFydGVyLmh0bWwiPldHJm5ic3A7Q2hhcnRlcnM8 L2E+PC9saT4KICAgICAgICAgICAgICA8bGkgY2xhc3M9InN1YmhkcjAyIj48YSBjbGFzcz0ic3Vi aGRyMDIiIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9saXN0L3dnLyI+RW1haWwm bmJzcDtMaXN0czwvYT48L2xpPgogICAgICAgICAgICAgIDxsaSBjbGFzcz0ic3ViaGRyMDIiPjxh IGNsYXNzPSJzdWJoZHIwMiIgaHJlZj0iL3dnL2NoYWlycy1wYWdlLmh0bWwiPldHJm5ic3A7Q2hh aXJzJyZuYnNwO1BhZ2U8L2E+PC9saT4KICAgICAgICAgICAgICA8bGkgY2xhc3M9InN1YmhkcjAw Ij48YSBjbGFzcz0ic3ViaGRyMDAiIGhyZWY9Ii90b29scy8iPjxzdHJvbmc+UmVzb3VyY2VzPC9z dHJvbmc+PC9hPjwvbGk+CiAgICAgICAgICAgICAgPGxpIGNsYXNzPSJzdWJoZHIwMiI+PGEgY2xh c3M9InN1YmhkcjAyIiBocmVmPSIvdG9vbHMvdG9vbHMuaHRtbCI+Q29tbXVuaXR5Jm5ic3A7VG9v bHM8L2E+PC9saT4KICAgICAgICAgICAgICA8bGkgY2xhc3M9InN1YmhkcjAyIj48YSBjbGFzcz0i c3ViaGRyMDIiIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy8iPlRvb2xzJm5ic3A7VGVhbSZu YnNwO1BhZ2VzPC9hPjwvbGk+CiAgICAgICAgICAgICAgPGxpIGNsYXNzPSJzdWJoZHIwMiI+PGEg Y2xhc3M9InN1YmhkcjAyIiBocmVmPSJodHRwOi8vd2lraS50b29scy5pZXRmLm9yZy9ncm91cC8i Pldpa2lzPC9hPjwvbGk+CiAgICAgICAgICAgICAgPGxpIGNsYXNzPSJzdWJoZHIwMCI+PGEgY2xh c3M9InN1YmhkcjAwIiBocmVmPSIvbWVldGluZy8iPjxzdHJvbmc+TWVldGluZ3M8L3N0cm9uZz48 L2E+PC9saT4KICAgICAgICAgICAgICA8bGkgY2xhc3M9InN1YmhkcjAyIj48YSBjbGFzcz0ic3Vi aGRyMDIiIGhyZWY9Ii9tZWV0aW5nL3VwY29taW5nLmh0bWwiPlVwY29taW5nJm5ic3A7TWVldGlu Z3M8L2E+PC9saT4KICAgICAgICAgICAgICA8bGkgY2xhc3M9InN1YmhkcjAyIj48YSBjbGFzcz0i c3ViaGRyMDIiIGhyZWY9Ii9tZWV0aW5nL3Bhc3QuaHRtbCI+UGFzdCZuYnNwO01lZXRpbmdzPC9h PjwvbGk+CiAgICAgICAgICAgICAgPGxpIGNsYXNzPSJzdWJoZHIwMiI+PGEgY2xhc3M9InN1Ymhk cjAyIiBocmVmPSIvbWVldGluZy9jdXRvZmYtZGF0ZXMuaHRtbCI+SW1wb3J0YW50Jm5ic3A7RGF0 ZXM8L2E+PC9saT4KICAgICAgICAgICAgICA8bGkgY2xhc3M9InN1YmhkcjAyIj48YSBjbGFzcz0i c3ViaGRyMDIiIGhyZWY9Ii9tZWV0aW5nL3Byb2NlZWRpbmdzLmh0bWwiPlByb2NlZWRpbmdzPC9h PjwvbGk+CiAgICAgICAgICAgICAgPGxpIGNsYXNzPSJzdWJoZHIwMCI+PGEgY2xhc3M9InN1Ymhk cjAwIiBocmVmPSIvbGlzdC8iPjxzdHJvbmc+TWFpbGluZyBMaXN0czwvc3Ryb25nPjwvYT48L2xp PgogICAgICAgICAgICAgIDxsaSBjbGFzcz0ic3ViaGRyMDIiPjxhIGNsYXNzPSJzdWJoZHIwMiIg aHJlZj0iL2xpc3QvYW5ub3VuY2VtZW50Lmh0bWwiPkFubm91bmNlbWVudCZuYnNwO0xpc3RzPC9h PjwvbGk+CiAgICAgICAgICAgICAgPGxpIGNsYXNzPSJzdWJoZHIwMiI+PGEgY2xhc3M9InN1Ymhk cjAyIiBocmVmPSIvbGlzdC9kaXNjdXNzaW9uLmh0bWwiPkRpc2N1c3Npb24mbmJzcDtMaXN0czwv YT48L2xpPgogICAgICAgICAgICAgIDxsaSBjbGFzcz0ic3ViaGRyMDIiPjxhIGNsYXNzPSJzdWJo ZHIwMiIgaHJlZj0iL2xpc3Qvbm9ud2cuaHRtbCI+Tm9uLVdHJm5ic3A7TGlzdHM8L2E+PC9saT4K ICAgICAgICAgICAgICA8bGkgY2xhc3M9InN1YmhkcjAwIj48YSBjbGFzcz0ic3ViaGRyMDAiIGhy ZWY9Ii9pZXNnLyI+PHN0cm9uZz5JRVNHIDwvc3Ryb25nPjwvYT48L2xpPgogICAgICAgICAgICAg IDxsaSBjbGFzcz0ic3ViaGRyMDIiPjxhIGNsYXNzPSJzdWJoZHIwMiIgaHJlZj0iaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9pZXNnL2Fubi9uZXcvIj5Bbm5vdW5jZW1lbnRzPC9hPjwvbGk+ CiAgICAgICAgICAgICAgPGxpIGNsYXNzPSJzdWJoZHIwMiI+PGEgY2xhc3M9InN1YmhkcjAyIiBo cmVmPSIvaWVzZy9zdGF0ZW1lbnQuaHRtbCI+U3RhdGVtZW50czwvYT48L2xpPgogICAgICAgICAg ICAgIDxsaSBjbGFzcz0ic3ViaGRyMDIiPjxhIGNsYXNzPSJzdWJoZHIwMiIgaHJlZj0iL2llc2cv bWVtYmVycy5odG1sIj5NZW1iZXJzPC9hPjwvbGk+CiAgICAgICAgICAgICAgPGxpIGNsYXNzPSJz dWJoZHIwMiI+PGEgY2xhc3M9InN1YmhkcjAyIiBocmVmPSIvaWVzZy9taW51dGVzLmh0bWwiPk1p bnV0ZXM8L2E+PC9saT4KICAgICAgICAgICAgICA8bGkgY2xhc3M9InN1YmhkcjAwIj48YSBjbGFz cz0ic3ViaGRyMDAiIGhyZWY9Ii9pcHIvIj48c3Ryb25nPklQUjwvc3Ryb25nPjwvYT48L2xpPgog ICAgICAgICAgICAgIDxsaSBjbGFzcz0ic3ViaGRyMDIiPjxhIGNsYXNzPSJzdWJoZHIwMiIgaHJl Zj0iL2lwci9wb2xpY3kuaHRtbCI+SVBSJm5ic3A7UG9saWN5PC9hPjwvbGk+CiAgICAgICAgICAg ICAgPGxpIGNsYXNzPSJzdWJoZHIwMiI+PGEgY2xhc3M9InN1YmhkcjAyIiBocmVmPSIvaXByL2Zp bGUtZGlzY2xvc3VyZSI+RmlsZSZuYnNwO2EmbmJzcDtEaXNjbG9zdXJlPC9hPjwvbGk+CiAgICAg ICAgICAgICAgPGxpIGNsYXNzPSJzdWJoZHIwMiI+PGEgY2xhc3M9InN1YmhkcjAyIiBocmVmPSJo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci9zZWFyY2gvIj5EaXNjbG9zdXJlJm5ic3A7 U2VhcmNoPC9hPjwvbGk+CiAgICAgICAgICAgICAgPGxpIGNsYXNzPSJzdWJoZHIwMCI+PGEgY2xh c3M9InN1YmhkcjAwIiBocmVmPSIvbGlhaXNvbi8iPjxzdHJvbmc+TGlhaXNvbnM8L3N0cm9uZz48 L2E+PC9saT4KICAgICAgICAgICAgICA8bGkgY2xhc3M9InN1YmhkcjAyIj48YSBjbGFzcz0ic3Vi aGRyMDIiIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbGlhaXNvbi8iPkxpYWlz b24mbmJzcDtTdGF0ZW1lbnRzPC9hPjwvbGk+CiAgICAgICAgICAgICAgPGxpIGNsYXNzPSJzdWJo ZHIwMiI+PGEgY2xhc3M9InN1YmhkcjAyIiBocmVmPSIvbGlhaXNvbi9tYW5hZ2Vycy5odG1sIj5M aWFpc29uJm5ic3A7TWFuYWdlcnM8L2E+PC9saT4KICAgICAgICAgICAgICA8bGkgY2xhc3M9InN1 YmhkcjAwIj48YSBjbGFzcz0ic3ViaGRyMDAiIGhyZWY9Ii9jb250YWN0LXRoZS1pZXRmLmh0bWwi PjxzdHJvbmc+Q29udGFjdDwvc3Ryb25nPjwvYT48L2xpPgogICAgICAgICAgICAgIDxsaSBjbGFz cz0ic3ViaGRyMDIiPjxhIGNsYXNzPSJzdWJoZHIwMiIgaHJlZj0iL3NlY3JldGFyaWF0Lmh0bWwi PklFVEYmbmJzcDtTZWNyZXRhcmlhdDwvYT48c3VwPiZyZWc7PC9zdXA+PC9saT4KICAgICAgICAg ICAgICA8bGkgY2xhc3M9InN1YmhkcjAyIj48YSBjbGFzcz0ic3ViaGRyMDIiIGhyZWY9Imh0dHA6 Ly9pYW9jLmlldGYub3JnL3N1YnBvZW5hLmh0bWwiPkxlZ2FsJm5ic3A7TWF0dGVyczwvYT48L2xp PgogICAgICAgICAgICAgIDxsaSBjbGFzcz0ic3ViaGRyMDIiPjxhIGNsYXNzPSJzdWJoZHIwMiIg aHJlZj0ibWFpbHRvOndlYm1hc3RlckBpZXRmLm9yZyI+UmVwb3J0Jm5ic3A7V2ViJm5ic3A7U2l0 ZSZuYnNwO0Vycm9yczwvYT48L2xpPgogICAgICAgICAgICAgIDxsaSBjbGFzcz0ic3ViaGRyMDAi PjxzdHJvbmc+Q3VzdG9taXplIFZpZXc8L3N0cm9uZz48YnIgLz4KICAgICAgICAgICAgICA8L2xp PgogICAgICAgICAgICAgIDxsaSBjbGFzcz0ic3ViaGRyMDEiPjxhIGNsYXNzPSJzdWJoZHIwMSIg aHJlZj0iamF2YXNjcmlwdDpzZXRTdHlsZSgnMicpOyIgdGl0bGU9IkJyaWVmIj5CcmllZjwvYT48 L2xpPgogICAgICAgICAgICAgIDxsaSBjbGFzcz0ic3ViaGRyMDEiPjxhIGNsYXNzPSJzdWJoZHIw MSIgaHJlZj0iamF2YXNjcmlwdDpzZXRTdHlsZSgnMScpOyIgdGl0bGU9Ik5vcm1hbCI+Tm9ybWFs PC9hPjwvbGk+CiAgICAgICAgICAgICAgPGxpIGNsYXNzPSJzdWJoZHIwMSI+PGEgY2xhc3M9InN1 YmhkcjAxIiBocmVmPSJqYXZhc2NyaXB0OnNldFN0eWxlKCczJyk7IiB0aXRsZT0iRXh0ZW5kZWQi PkV4dGVuZGVkPC9hPjwvbGk+CiAgICAgICAgICAgICAgPGxpIGNsYXNzPSJzdWJoZHIwMSI+PGEg Y2xhc3M9InN1YmhkcjAxIiBocmVmPSJqYXZhc2NyaXB0OnNldFN0eWxlKCc0Jyk7IiB0aXRsZT0i QWR2YW5jZWQiPkFkdmFuY2VkPC9hPjwvbGk+CiAgICAgICAgICAgICAgPGxpIGNsYXNzPSJzdWJo ZHIwMSI+PHNtYWxsPihSZXF1aXJlcyBKYXZhc2NyaXB0KTwvc21hbGw+PC9saT4KICAgICAgICAg ICAgPC91bD4KICAgICAgICAgPC9kaXY+PC90ZD4KICAgICAgICA8dGQgaWQ9ImNvbnRlbnQxIj48 ZGl2IGlkPSJjb250ZW50MiI+IDwhLS0gSW5zdGFuY2VCZWdpbkVkaXRhYmxlIG5hbWU9ImJvZHki IC0tPgoKCiAgICAgICAgICAgIDxwIGNsYXNzPSJwdGl0bGUiPklETklUUzwvcD4KICAgICAgICAg ICAgPHA+CgoJCTxmb3JtIGFjdGlvbj0iL3Rvb2xzL2lkbml0cyIgbWV0aG9kPSJwb3N0IiBlbmN0 eXBlPSJtdWx0aXBhcnQvZm9ybS1kYXRhIj4KCQlDaGVjayBhIGRyYWZ0IGZvciBuaXRzOjxiciAv PgoJCSZuYnNwOyZuYnNwOzxpbnB1dCB0eXBlPSJjaGVja2JveCIgbmFtZT0idmVyYm9zZSIgLz4g dmVyYm9zZSBvdXRwdXQ8YnIgLz4KCQkmbmJzcDsmbmJzcDs8aW5wdXQgdHlwZT0iY2hlY2tib3gi IG5hbWU9InZ2ZXJib3NlIiAvPiB2ZXJ5IHZlcmJvc2Ugb3V0cHV0PGJyIC8+CgkJJm5ic3A7Jm5i c3A7PGlucHV0IHR5cGU9ImNoZWNrYm94IiBuYW1lPSJzdWJtaXRjaGVjayIgLz4gb25seSBkbyBz dWJtaXNzaW9uIGNoZWNrczxiciAvPgoJCSZuYnNwOyZuYnNwOzxpbnB1dCB0eXBlPSJ0ZXh0IiBz aXplPTQgbmFtZT0ieWVhciIgLz4gY29weXJpZ2h0IHllYXIgKGlmIGRpZmZlcmVudCBmcm9tIGN1 cnJlbnQpPGJyIC8+CgkJPCEtLSA8aW5wdXQgdHlwZT0iZmlsZSIgbmFtZT0iZmlsZTEiIHNpemU9 IjQwIiAvPiAtLT4KCQk8aW5wdXQgdHlwZT0iZmlsZSIgbmFtZT0iZmlsZW5hbWUiIHNpemU9IjQw IiAvPgoJCTxpbnB1dCB0eXBlPSJzdWJtaXQiIG5hbWU9InN1Ym1pdCIgdmFsdWU9IkNoZWNrIGZp bGUiIC8+CgkJPC9mb3JtPgogICAgICAgICAgICA8L3A+CgoKCiAgICAgICAgICAgIDwhLS0gSW5z dGFuY2VFbmRFZGl0YWJsZSAtLT4gPC9kaXY+PC90ZD4KICAgICAgPC90cj4KICAgICAgPHRyPgog ICAgICAgIDx0ZCBpZD0iZm9vdGVyMSIgY29sc3Bhbj0iMiI+PGRpdiBpZD0iZm9vdGVyMiI+CiAg ICAgICAgICAgIDxwPjxhIGhyZWY9Imh0dHA6Ly93d3cuaXNvYy5vcmcvIj48aW1nIHNyYz0iL2lt YWdlcy9pc29jX2xvZ28uZ2lmIiBhbHQ9IkludGVybmV0IFNvY2lldHkiIGFsaWduPSJsZWZ0IiBi b3JkZXI9IjAiIGhzcGFjZT0iNSIgLz48L2E+PGEgaHJlZj0iaHR0cDovL3d3dy5hbXNsLmNvbS8i PjxpbWcgc3JjPSIvaW1hZ2VzL2Ftc19sb2dvLnBuZyIgYWx0PSJBTVMiIGFsaWduPSJyaWdodCIg Ym9yZGVyPSIwIiBoc3BhY2U9IjUiIC8+PC9hPjxhIGhyZWY9Ii8iPkhvbWU8L2E+IC0gPGEgaHJl Zj0iaHR0cDovL3Rvb2xzLmlldGYub3JnLyI+VG9vbHM8L2E+IC0gPGEgaHJlZj0iaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy8iPkRhdGF0cmFja2VyPC9hPiAtIDxhIGhyZWY9Ii91c2FnZWRh dGEvIj5XZWImbmJzcDtTaXRlJm5ic3A7VXNhZ2UmbmJzcDtTdGF0aXN0aWNzPC9hPiAtIDxhIGhy ZWY9Imh0dHA6Ly9pYW9jLmlldGYub3JnLyI+SUFTQTwvYT4gLSA8YSBocmVmPSJodHRwOi8vd3d3 LmlhYi5vcmcvIj5JQUI8L2E+IC0gPGEgaHJlZj0iaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy8i PlJGQyZuYnNwO0VkaXRvcjwvYT4gLSA8YSBocmVmPSJodHRwOi8vd3d3LmlhbmEub3JnLyI+SUFO QTwvYT4gLSA8YSBocmVmPSJodHRwOi8vd3d3LmlydGYub3JnLyI+SVJURjwvYT4gLSA8YSBocmVm PSJodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy8iPklFVEYmbmJzcDtUcnVzdDwvYT4gLSA8YSBocmVm PSJodHRwOi8vd3d3Lmlzb2Mub3JnLyI+SVNPQzwvYT4gLSA8YSBocmVmPSIvc2VjcmV0YXJpYXQu aHRtbCI+Q29udGFjdCZuYnNwO1VzPC9hPjxiciAvPgogICAgICAgICAgICAgIFNlY3JldGFyaWF0 IHNlcnZpY2VzIHByb3ZpZGVkIGJ5IDxhIGhyZWY9Imh0dHA6Ly93d3cuYW1zbC5jb20vIj5Bc3Nv Y2lhdGlvbiBNYW5hZ2VtZW50IFNvbHV0aW9ucywgTExDIChBTVMpPC9hPi48YnIgLz4KICAgICAg ICAgICAgICBQbGVhc2Ugc2VuZCBwcm9ibGVtIHJlcG9ydHMgdG86IDxhIGhyZWY9Im1haWx0bzpp ZXRmLWFjdGlvbkBpZXRmLm9yZyI+aWV0Zi1hY3Rpb25AaWV0Zi5vcmc8L2E+LjxiciAvPgogICAg ICAgICAgICAgICZuYnNwOzwvcD4KICAgICAgICAgIDwvZGl2PjwvdGQ+CiAgICAgIDwvdHI+CiAg ICA8L3Rib2R5PgogIDwvdGFibGU+CjwvZGl2Pgo8L2JvZHk+CjwhLS0gSW5zdGFuY2VFbmQgLS0+ PC9odG1sPgoK --90e6ba3fd081a33d170504c17681-- From nobody Mon Oct 6 09:13:03 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABBD81A6FDD; Mon, 6 Oct 2014 09:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPKus_jwlnl5; Mon, 6 Oct 2014 09:12:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 38C8D1A6FE6; Mon, 6 Oct 2014 09:12:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141006161246.26592.7330.idtracker@ietfa.amsl.com> Date: Mon, 06 Oct 2014 09:12:46 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/LvgH5IsAK_YeniS8pK6DxOQO_z0 Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-questions-08.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 16:12:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Unanswered Questions in the Path Computation Element Architecture Authors : Adrian Farrel Daniel King Filename : draft-ietf-pce-questions-08.txt Pages : 27 Date : 2014-10-06 Abstract: The Path Computation Element (PCE) architecture is set out in RFC 4655. The architecture is extended for multi-layer networking with the introduction of the Virtual Network Topology Manager (VNTM) in RFC 5623, and generalized to Hierarchical PCE (H-PCE) in RFC 6805. These three architectural views of PCE deliberately leave some key questions unanswered especially with respect to the interactions between architectural components. This document draws out those questions and discusses them in an architectural context with reference to other architectural components, existing protocols, and recent IETF work efforts. This document does not update the architecture documents and does not define how protocols or components must be used. It does, however, suggest how the architectural components might be combined to provide advanced PCE function. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-questions/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-questions-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-questions-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 6 10:29:30 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD91B1A8703 for ; Mon, 6 Oct 2014 10:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGbnZlLd3u_z for ; Mon, 6 Oct 2014 10:29:21 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C7C51A005C for ; Mon, 6 Oct 2014 10:29:19 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id em10so5337979wid.10 for ; Mon, 06 Oct 2014 10:29:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qHPPWK3H2qQyD+E9lYXhNc/Z5IrOg/oBwwaxy5q9PU4=; b=TuEKLzQ9KGlDSO670WMZnDF0Dd1yOgyDZvS7jVDhSKIfij1sl54tIt0nwQY/rQtSNO qfxRL4zw0mfzZk5LGtdLA56b/xPkfb4y3u8p0hxHVS9ZvnEFc63/DWXeSP2lZSbLUWCi w6nd5VqLS8cr7gG3LOzsM5WrQE1LY5NYm5ECeb1pU6uixctRXvbW+ZjyAx3z1Ru5qOXx /r8rx81B4Is4zMrxAx3H4+u6akU1ON9tplqPrPX+fjVicar8cIkbjV0ZycTRqctUK4qN 2B8PIPiT0rKFu0vX/C98gPscN/9T0ZkTuzus1SaAn9950ZwYTJ6g5BD5DKKheCSYRRcb 5D5w== MIME-Version: 1.0 X-Received: by 10.194.216.39 with SMTP id on7mr18991037wjc.56.1412616558385; Mon, 06 Oct 2014 10:29:18 -0700 (PDT) Received: by 10.27.78.193 with HTTP; Mon, 6 Oct 2014 10:29:18 -0700 (PDT) In-Reply-To: References: Date: Mon, 6 Oct 2014 13:29:18 -0400 Message-ID: From: Cyril Margaria To: Dhruv Dhody Content-Type: multipart/alternative; boundary=089e013c62b02aa1d30504c46c83 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/bCdkpQFYrGou6KyDdHB6PzHIZJ4 Cc: "pce@ietf.org" Subject: Re: [Pce] WG Last Call on draft-ietf-pce-stateful-pce-app-02 and draft-ietf-pce-stateful-pce-09 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 17:29:26 -0000 --089e013c62b02aa1d30504c46c83 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, (maybe duplicated, I did not see my first email on the list after 1 hour) I support draft-ietf-pce-stateful-pce-app-02 LC. I Have the following comment for draft-ietf-pce-stateful-pce-09: Section 2 The document references the following timers: - State Timeout Interval - Redelegation Timeout Interval RFC5440 defines an Appendix B. PCEP Variables, having a dedicated section for those variables would be better, as they are integral part of the extensions. Section 5.4 After the first paragraph, add: The State synchronization start with a LSP state report having the SYNC Flag in the LSP Object set to 1. Reason: This would allow for the PCC to fully resend its database after the Initialization phase, and clarify the PCE operation. Section 5.6.1 OLD Once an LSP is up, the PCC sends an LSP State Report carried on a PCRpt message to the PCE, indicating that the LSP's status is 'Up'. If the LSP could not be set up, the PCC sends an LSP State Report indicating that the LSP is "Down' and stating the cause of the Failure. NEW Once an LSP is up, the PCC sends an LSP State Report carried on a PCRpt message to the PCE, indicating that the LSP's status is 'Up' or 'Active'. If the LSP could not be set up, the PCC sends an LSP State Report indicating that the LSP is "Down' and stating the cause of the failure. OLD In such cases, the PCC may choose to only send the PCRpt indicating the latest status ('Up' or 'Down=C2=B9). NEW In such cases, the PCC may choose to only send the PCRpt indicating the latest status (=C5=92Active=C2=B9, 'Up' or 'Down'). Reason : Active is also a possible state. Section 5.6.2 OLD If the PCC decides that the LSP parameters proposed in the PCUpd message are unacceptable, it MUST report this error by including the LSP-ERROR-CODE TLV (Section 7.3.3 ) with LSP error-value=3D=C2=B3Unacceptable parameters" in the LSP object in = the PCRpt message to the PCE NEW If the PCC decides that the LSP parameters proposed in the PCUpd message are unacceptable, it MUST report this error by including the LSP-ERROR-CODE TLV (Section 7.3.3 ) with LSP error-value=3D=C2=B3Unacceptable parameters" in the LSP object in = the PCRpt message to the PCE. The PCC MAY/SHOULD include the objects that were not accepted in the PCRpt message. Reason: If the PCC includes the objects (current PCC values) that caused the PCUpd to be rejected, it would help the PCE avoid resending them. A PCErr would allow to include the objects, a new error type would be needed but error handling from PCE side should be rather easy. Another possibility is having the LSP-ERROR-CODE containing a list of Object-Class, OT . OLD Once an LSP is up, the PCC sends an LSP State Report (PCRpt message) to the PCE, indicating that the LSP's status is 'Up'. If the LSP could not be set up, the PCC sends an LSP State Report indicating that the LSP is 'Down' and stating the cause of the failure. NEW Once an LSP is up or active, the PCC sends an LSP State Report (PCRpt message) to the PCE, indicating that the LSP's status is 'Up=C2=B9 (resp. 'Active= '). If the LSP could not be set up, the PCC sends an LSP State Report indicating that the LSP is 'Down' and stating the cause of the failure. Section 6.1 OLD The RRO SHOULD be included by the PCC when the path is up, NEW The RRO SHOULD be included by the PCC when the path is up or active, Section 7 Replace MUST by SHOULD, this is restricting a lot future documents (not allowing to enforce/ignore gracefully some objects) Section 7.3. Nits: Using Synchronize would be better aligned with other bits definition S bit: Add: On PCUpd the R flag SHOULD (MUST?) be set to 0 on transmission and MUST be ignored on receipt. R bit: Add: On PCUpd the R flag SHOULD (MUST?) be set to 0 on transmission and MUST be ignored on receipt (or it is allowed on PCUpd?) O bit: Add: On PCUpd the O Field SHOULD (MUST?) be set to 0 on transmission and MUST be ignored on receipt. Section 7.3.3. The error value =C5=92LSP preempted=C2=B9 could seem a bit redundant with= =C5=92RSVP signaling error=C2=B9 and the corresponding RSVP preempted error code, I believe the error code =C5=92LSP preempted=C2=B9 should be seen when a PCC-= local administrative preemption is made, and the RSVP signaling error should be used otherwise (the error node can be of value for the PCE) BR Cyril On 6 October 2014 09:57, Dhruv Dhody wrote: > Hi WG, > > Support both the documents, and are basically ready for publications. > > I re-read the documents again, here are some nits/comments which can > be handled along the process. > > -------- > > For draft-ietf-pce-stateful-pce-app: (listed as a contributor) > > - In sec 3. Overview of the Stateful PCE Protocol Extensions; the word > tunnel is used in below paragraph, for consistency with rest of the > document can it be changed to LSP. > > [I-D.ietf-pce-stateful-pce] specifies a set of extensions to PCEP to > enable stateful control of tunnels within and across PCEP sessions in > compliance with [RFC4657]. It includes mechanisms to effect tunnel > state synchronization between PCCs and PCEs, delegation of control > over tunnels to PCEs, and PCE control of timing and sequence of path > computations within and across PCEP sessions. > > Since we are not using RFC2119 keywords in this document, we should > not use 'SHOULD'. > > LSP state synchronization (C-E): after the session between a PCC a= nd > a stateful PCE is initialized, the PCE can perform path > computation and update attributes in a PCC. However, if the goal > of the PCE is to provide accurate path information based on the > most up-to-date state of the network, the PCE SHOULD wait until it > learns the state of the PCC's LSP states before doing so. > > - In sec 4.3. PCE Survivability; a reference to > draft-ietf-pce-stateful-sync-optimizations can be added for > readability. > > - Expand on first use PCReq, LER, NMS, RRO, RSVP-TE > > - Suggest if you can add IANA consideration section and explicitly say > that there are no request for IANA in this document. > > - Some unused references like MXMN-TE, MPLS-PC, NET-REC (perhaps > because of older version text from draft-ietf-pce-stateful-pce) > > -------- > > For draft-ietf-pce-stateful-pce: > > - RFC2119 keywords requirement language should be added as subsection > in introduction. > > 1.1 Requirements Language > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [RFC2119]. > > - In sec 3.2. Objectives > OLD: > Allow a PCC to delegate control of its LSPs to an active stateful > PCE such that a single LSP is under the control a single PCE at > any given time. > NEW: > Allow a PCC to delegate control of its LSPs to an active stateful > PCE such that a LSP is under the control a single PCE at > any given time. > The current text gives an impression that only one LSP (a single LSP) > is under control of a PCE. > > - In sec 5.4. State Synchronization, for figure 2 and 3 'PCErr=3D?' is > used, I suggest either to put the error type/code or remove '=3D?'. > > - Update reference for minei-pce-stateful-sync-optimizations to > ietf-pce-stateful-sync-optimizations > > - I am not sure what is the correct way to put comments inside RBNF, > or better yet they should simply be avoided. In section 6.3, 6.4 and > 6.5 "<<<<" and "<---" are used. > > - The alignment for the byte markers is incorrect in figure 10 > > - In sec 7.3.2. Symbolic Path Name TLV, can the following text be added? > > The Symbolic Path Name is padded to 4-bytes alignment; padding > itself is not included in the Length field. > > - In sec 7.3.3. LSP Error Code TLV, we should say - "The following LSP > Error Codes are *currently* defined:"; so that future documents can > easily extend it. > > - In 9.6. Impact on Network Operation s/PcE/PCE > > - ietf-pce-gmpls-pcep-extensions can be removed as a normative reference. > > - there are bunch of idnits that you may wish to handle (see attached) > > -------- > > Dhruv > > > On Sun, Sep 14, 2014 at 3:42 PM, JP Vasseur (jvasseur) > wrote: > > Dear WG, > > > > Both draft-ietf-pce-stateful-pce-app-02 and > draft-ietf-pce-stateful-pce-09 > > are now stable ready for WG Last Call. > > This starts a 3-week WG Last call, which will end on Oct 6 at noon ET. > > > > Please send your comments on the mailing list. > > > > ps: this WG LC will be followed by another WG LC on > > draft-ietf-pce-stateful-sync-optimizations-01 > > and draft-ietf-pce-pce-initiated-lsp-01. > > > > > > Thanks. > > > > JP and Julien. > > > > _______________________________________________ > > 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 > > --089e013c62b02aa1d30504c46c83 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

(maybe duplicated, I did not see my = first email on the list after 1 hour)

I support draft-ietf-pce= -stateful-pce-app-02 LC.
I Have the following comment for draft-ietf-pce= -stateful-pce-09:

Section 2
The document references the following= timers:
=C2=A0=C2=A0 - State Timeout Interval
=C2=A0=C2=A0 - Redeleg= ation Timeout Interval

RFC5440 defines an Appendix B. PCEP Variables= , having a dedicated section
for those variables would be better, as the= y are integral part of the
extensions.


Section 5.4

Aft= er the first paragraph, add:
The State synchronization start with a LSP = state report having the SYNC
Flag in the LSP Object set to 1.

Rea= son: This would allow for the PCC to fully resend its database after
the= Initialization phase, and clarify the PCE operation.

Section 5.6.1<= br>OLD
Once an LSP is up, the PCC sends an LSP State Report carried on a=
=C2=A0=C2=A0 PCRpt message to the PCE, indicating that the LSP's st= atus is 'Up'.
=C2=A0=C2=A0 If the LSP could not be set up, the P= CC sends an LSP State Report
=C2=A0=C2=A0 indicating that the LSP is &qu= ot;Down' and stating the cause of the
=C2=A0=C2=A0 Failure.

N= EW
Once an LSP is up, the PCC sends an LSP State Report carried on a
= =C2=A0=C2=A0 PCRpt message to the PCE, indicating that the LSP's status= is 'Up' or
'Active'.
=C2=A0=C2=A0 If the LSP could n= ot be set up, the PCC sends an LSP State Report
=C2=A0=C2=A0 indicating = that the LSP is "Down' and stating the cause of the
failure.

OLD
In such cases, the PCC may choose to only send the PCRpt=C2=A0=C2=A0 indicating the latest status ('Up' or 'Down=C2=B9= ).

NEW
In such cases, the PCC may choose to only send the PCRpt=C2=A0=C2=A0 indicating the latest status (=C5=92Active=C2=B9, 'Up= 9; or 'Down').


Reason : Active is also a possible state.=


Section 5.6.2
OLD
If the PCC decides that the LSP paramet= ers proposed in the PCUpd message
are unacceptable, it MUST report this = error by including the
LSP-ERROR-CODE TLV (Section 7.3.3
<https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-09#section-7.3.3= >)
with LSP error-value=3D=C2=B3Unacceptable parameters" in = the LSP object in the
PCRpt message to the PCE

NEW
If the PCC = decides that the LSP parameters proposed in the PCUpd message
are unacce= ptable, it MUST report this error by including the
LSP-ERROR-CODE TLV (S= ection 7.3.3
<https://tools.ietf.org/html/draft-ietf-pce-st= ateful-pce-09#section-7.3.3>)
with LSP error-value=3D=C2=B3Unacce= ptable parameters" in the LSP object in the
PCRpt message to the PC= E. The PCC MAY/SHOULD include the objects that were
not accepted in the = PCRpt message.


Reason: If the PCC includes the objects (current = PCC values) that caused
the PCUpd to be rejected, it would help the PCE = avoid resending them. A
PCErr would allow to include the objects, a new = error type would be needed
but error handling from PCE side should be ra= ther easy. Another
possibility is having the LSP-ERROR-CODE containing a= list of
Object-Class, OT .


OLD
=C2=A0=C2=A0 Once an LSP i= s up, the PCC sends an LSP State Report (PCRpt message)
=C2=A0=C2=A0 to = the PCE, indicating that the LSP's status is 'Up'.=C2=A0 If the= LSP
=C2=A0=C2=A0 could not be set up, the PCC sends an LSP State Report= indicating
=C2=A0=C2=A0 that the LSP is 'Down' and stating the = cause of the failure.

NEW
=C2=A0=C2=A0 Once an LSP is up or activ= e, the PCC sends an LSP State Report (PCRpt
message)
=C2=A0=C2=A0 to = the PCE, indicating that the LSP's status is 'Up=C2=B9 (resp. '= Active').
If the LSP
=C2=A0=C2=A0 could not be set up, the PCC se= nds an LSP State Report indicating
=C2=A0=C2=A0 that the LSP is 'Dow= n' and stating the cause of the failure.




Section 6.1=
OLD
The RRO SHOULD be included by the PCC when the path is up,
NEW
The RRO SHOULD be included by the PCC when the path is up or activ= e,

Section 7
Replace MUST by SHOULD, this is restricting a lot fu= ture documents (not
allowing to enforce/ignore gracefully some objects)<= br>
Section 7.3.
Nits: Using Synchronize would be better aligned with= other bits definition

S bit: Add: On PCUpd the R flag SHOULD (MUST?= ) be set to 0 on transmission
and MUST be ignored on receipt.

R b= it: Add: On PCUpd the R flag SHOULD (MUST?) be set to 0 on transmission
= and MUST be ignored on receipt
=C2=A0 (or it is allowed on PCUpd?)
O = bit: Add: On PCUpd the O Field SHOULD (MUST?) be set to 0 on
transmissio= n and MUST be ignored on receipt.

Section 7.3.3.
=C2=A0 The error= value =C5=92LSP preempted=C2=B9 could seem a bit redundant with =C5=92RSVP=
signaling error=C2=B9 and the corresponding RSVP preempted error code, = I
believe the error code =C5=92LSP preempted=C2=B9 should be seen when a= PCC-local
administrative preemption is made, and the RSVP signaling err= or should be
used otherwise (the error node can be of value for the PCE)=



BR
Cyril

<= br>
On 6 October 2014 09:57, Dhruv Dhody <dhr= uv.ietf@gmail.com> wrote:
H= i WG,

Support both the documents, and are basically ready for publications.

I re-read the documents again, here are some nits/comments which can
be handled along the process.

--------

For draft-ietf-pce-stateful-pce-app: (listed as a contributor)

- In sec 3. Overview of the Stateful PCE Protocol Extensions; the word
tunnel is used in below paragraph, for consistency with rest of the
document can it be changed to LSP.

=C2=A0 =C2=A0[I-D.ietf-pce-stateful-pce] specifies a set of extensions to P= CEP to
=C2=A0 =C2=A0enable stateful control of tunnels within and across PCEP sess= ions in
=C2=A0 =C2=A0compliance with [RFC4657].=C2=A0 It includes mechanisms to eff= ect tunnel
=C2=A0 =C2=A0state synchronization between PCCs and PCEs, delegation of con= trol
=C2=A0 =C2=A0over tunnels to PCEs, and PCE control of timing and sequence o= f path
=C2=A0 =C2=A0computations within and across PCEP sessions.

Since we are not using RFC2119 keywords in this document, we should
not use 'SHOULD'.

=C2=A0 =C2=A0 =C2=A0 LSP state synchronization (C-E):=C2=A0 after the sessi= on between a PCC and
=C2=A0 =C2=A0 =C2=A0 a stateful PCE is initialized, the PCE can perform pat= h
=C2=A0 =C2=A0 =C2=A0 computation and update attributes in a PCC.=C2=A0 Howe= ver, if the goal
=C2=A0 =C2=A0 =C2=A0 of the PCE is to provide accurate path information bas= ed on the
=C2=A0 =C2=A0 =C2=A0 most up-to-date state of the network, the PCE SHOULD w= ait until it
=C2=A0 =C2=A0 =C2=A0 learns the state of the PCC's LSP states before do= ing so.

- In sec 4.3. PCE Survivability; a reference to
draft-ietf-pce-stateful-sync-optimizations can be added for
readability.

- Expand on first use PCReq, LER, NMS, RRO, RSVP-TE

- Suggest if you can add IANA consideration section and explicitly say
that there are no request for IANA in this document.

- Some unused references like MXMN-TE, MPLS-PC, NET-REC (perhaps
because of older version text from draft-ietf-pce-stateful-pce)

--------

For draft-ietf-pce-stateful-pce:

- RFC2119 keywords requirement language should be added as subsection
in introduction.

=C2=A0 =C2=A01.1 Requirements Language

=C2=A0 =C2=A0The key words "MUST", "MUST NOT", "RE= QUIRED", "SHALL", "SHALL NOT",
=C2=A0 =C2=A0"SHOULD", "SHOULD NOT", "RECOMMENDED&= quot;, "MAY", and "OPTIONAL" in this
=C2=A0 =C2=A0document are to be interpreted as described in RFC 2119 [RFC21= 19].

- In sec 3.2. Objectives
OLD:
=C2=A0 =C2=A0 =C2=A0 Allow a PCC to delegate control of its LSPs to an acti= ve stateful
=C2=A0 =C2=A0 =C2=A0 PCE such that a single LSP is under the control a sing= le PCE at
=C2=A0 =C2=A0 =C2=A0 any given time.
NEW:
=C2=A0 =C2=A0 =C2=A0 Allow a PCC to delegate control of its LSPs to an acti= ve stateful
=C2=A0 =C2=A0 =C2=A0 PCE such that a LSP is under the control a single PCE = at
=C2=A0 =C2=A0 =C2=A0 any given time.
The current text gives an impression that only one LSP (a single LSP)
is under control of a PCE.

- In sec 5.4. State Synchronization, for figure 2 and 3 'PCErr=3D?'= is
used, I suggest either to put the error type/code or remove '=3D?'.=

- Update reference for minei-pce-stateful-sync-optimizations to
ietf-pce-stateful-sync-optimizations

- I am not sure what is the correct way to put comments inside RBNF,
or better yet they should simply be avoided. In section 6.3, 6.4 and
6.5 "<<<<" and "<---" are used.

- The alignment for the byte markers is incorrect in figure 10

-=C2=A0 In sec 7.3.2. Symbolic Path Name TLV, can the following text be add= ed?

=C2=A0 =C2=A0 The Symbolic Path Name is padded to 4-bytes alignment; paddin= g
=C2=A0 =C2=A0 =C2=A0itself is not included in the Length field.

- In sec 7.3.3. LSP Error Code TLV, we should say - "The following LSP=
Error Codes are *currently* defined:"; so that future documents can easily extend it.

- In 9.6. Impact on Network Operation s/PcE/PCE

- ietf-pce-gmpls-pcep-extensions can be removed as a normative reference.
- there are bunch of idnits that you may wish to handle (see attached)

--------

Dhruv


On Sun, Sep 14, 2014 at 3:42 PM, JP Vasseur (jvasseur)
<jvasseur@cisco.com> wrote:=
> Dear WG,
>
> Both draft-ietf-pce-stateful-pce-app-02 and draft-ietf-pce-stateful-pc= e-09
> are now stable ready for WG Last Call.
> This starts a 3-week WG Last call, which will end on Oct 6 at noon ET.=
>
> Please send your comments on the mailing list.
>
> ps: this WG LC will be followed by another WG LC on
> draft-ietf-pce-stateful-sync-optimizations-01
> and draft-ietf-pce-pce-initiated-lsp-01.
>
>
> Thanks.
>
> JP and Julien.
>
> _______________________________________________
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>

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


--089e013c62b02aa1d30504c46c83-- From nobody Mon Oct 6 11:28:16 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3C081A87AF; Mon, 6 Oct 2014 11:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86rfrgUdFc5p; Mon, 6 Oct 2014 11:28:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4AC1A87C8; Mon, 6 Oct 2014 11:28:10 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141006182810.4731.4691.idtracker@ietfa.amsl.com> Date: Mon, 06 Oct 2014 11:28:10 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/rUqdnDYp6gHrJBQZJVsuA1-VGI0 Cc: pce mailing list , pce chair , RFC Editor Subject: [Pce] Document Action: 'Unanswered Questions in the Path Computation Element Architecture' to Informational RFC (draft-ietf-pce-questions-08.txt) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 18:28:14 -0000 The IESG has approved the following document: - 'Unanswered Questions in the Path Computation Element Architecture' (draft-ietf-pce-questions-08.txt) as Informational RFC This document is the product of the Path Computation Element Working Group. The IESG contact persons are Alia Atlas and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-pce-questions/ Technical Summary The Path Computation Element (PCE) architecture is set out in RFC 4655. The architecture is extended for multi-layer networking with the introduction of the Virtual Network Topology Manager in RFC 5623, and generalized to Hierarchical PCE in RFC 6805. These three architectural views of PCE deliberately leave some key questions unanswered especially with respect to the interactions between architectural components. This document draws out those questions and discusses them in an architectural context with reference to other architectural components, existing protocols, and recent IETF work efforts. This document does not update the architecture documents and does not define how protocols or components must be used. It does, however, suggest how the architectural components might be combined to provide advanced PCE function. Working Group Summary No controversy and strong support Document Quality Well-written informational Personnel Who is the Document Shepherd? :: Dhruv Dhody Who is the Responsible Area Director? :: Alia Atlas From nobody Tue Oct 7 01:15:31 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED2551A9147 for ; Tue, 7 Oct 2014 01:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9DOVc5TQREn4 for ; Tue, 7 Oct 2014 01:15:27 -0700 (PDT) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BCA01A9144 for ; Tue, 7 Oct 2014 01:15:26 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id em10so6981724wid.4 for ; Tue, 07 Oct 2014 01:15:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=9qE57Ftnws+KGILcQXFWUtlujvMTqtj6Dq8x4aQcpwk=; b=RVOwWXnzJWrsY9D54LaAkXX7mfWcWFJ6JTj0Mn/PNWZYioam5o2reKNQhIgHX1Db09 tGRRylxj6L5UrPmfapvvuGa8VDRuho6ZlNWEPLhXX2c0dGwCkVMv8WZ6ySybrEyly7E5 Rg2AYMy0nCZzoweyHxAYuCJGa/O6dhqDEnoaf7CJo9vl+9L8kUBnBV8GYKkaKgQyrs5M R5kbQshpCR0+KNewH/zUp/fJvOXywf9zxab1sb3IujZx+WhFOC0ZiL6hI2f4N+AjHacF rotdpZLwrhCA3/7+4Ms4w3tJPT6V2HKzy+XGkN6+lBSoVdshUxB3NPCcoA1n4c5AlnDg E8EQ== X-Gm-Message-State: ALoCoQnfktsgiET0j0q/JtIUf235ODCsGZNcypuvU7qou8vI6HS2TmsTc4UaMzpYkSEPKloQSLMV X-Received: by 10.180.182.166 with SMTP id ef6mr9211350wic.10.1412669725580; Tue, 07 Oct 2014 01:15:25 -0700 (PDT) Received: from Serenity (176-227-128-84.ip.skylogicnet.com. [176.227.128.84]) by mx.google.com with ESMTPSA id hp2sm19075705wjb.40.2014.10.07.01.15.21 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 07 Oct 2014 01:15:24 -0700 (PDT) Sender: Daniel King X-Google-Original-Sender: "Daniel King" From: "Daniel King" To: Date: Tue, 7 Oct 2014 09:15:11 +0100 Message-ID: <00e201cfe206$d570e2e0$8052a8a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac/iBrfXFUtnttxcQemdFHnV7QwQFA== Content-Language: en-gb Archived-At: http://mailarchive.ietf.org/arch/msg/pce/zukYaHf8uMGk7T0F_oe5WU14QzI Subject: [Pce] Implementation Experience for H-PCE (draft-ietf-pce-hierarchy-extensions) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 08:15:29 -0000 Hi All, The authors of draft-ietf-pce-hierarchy-extensions are updating the document and it would be really useful to include a section on "Implementation Experience" section, as per RFC6982 (RFC6982). Would any early implementers of draft-ietf-pce-hierarchy-extensions please send me any details they wish to share. As per RFC6982, the information we could use, includes: - The organization responsible for the implementation, if any. - The implementation's name and/or a link to a web page describing the implementation. - A brief general description. - The implementation's level of maturity: research, prototype, alpha, beta, production, widely used, etc. - Coverage: which parts of the protocol specification are implemented and which versions of the Internet-Draft were implemented. - Licensing: the terms under which the implementation can be used. For example: proprietary, royalty licensing, freely distributable with acknowledgement (BSD style), freely distributable with requirement to redistribute source (General Public License (GPL) style), and other (specify). - Implementation experience: any useful information the implementers want to share with the community. - Contact information: ideally a person's name and email address, but possibly just a URL or mailing list. Also, any planned section may contain information about interoperability of any or all of the implementations, including references to test-case descriptions and interoperability reports, should they exist. Br, Dan. From nobody Tue Oct 7 01:25:46 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56E2E1A1BB9 for ; Tue, 7 Oct 2014 01:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.385 X-Spam-Level: X-Spam-Status: No, score=-0.385 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_RHS_DOB=1.514] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oi6F-0AeMyzx for ; Tue, 7 Oct 2014 01:25:43 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A58B81A1B53 for ; Tue, 7 Oct 2014 01:25:42 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id B549D2641ED for ; Tue, 7 Oct 2014 10:25:40 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 9DF5335C061 for ; Tue, 7 Oct 2014 10:25:40 +0200 (CEST) Received: from [10.134.113.146] (10.197.38.6) by PEXCVZYH01.corporate.adroot.infra.ftgroup (10.114.1.186) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 7 Oct 2014 10:25:40 +0200 Message-ID: <1448_1412670340_5433A384_1448_9015_1_5433A36E.1060004@orange.com> Date: Tue, 7 Oct 2014 10:25:18 +0200 From: Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "pce@ietf.org" References: <20141006223256.19159.32181.idtracker@ietfa.amsl.com> In-Reply-To: <20141006223256.19159.32181.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20141006223256.19159.32181.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.197.38.6] X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.10.7.53022 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/PEN5NbWKoulgsa-2LaIc42zEAME Subject: [Pce] Fwd: New Non-WG Mailing List: Rtg-yang-coord X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 08:25:44 -0000 FYI -------- Message transféré -------- Date : Mon, 6 Oct 2014 15:32:56 -0700 De : IETF Secretariat Pour : IETF Announcement List Copie à : jhaas@juniper.net, jeff.tantsura@ericsson.com, rtg-yang-coord@ietf.org A new IETF non-working group email list has been created. List address: rtg-yang-coord@ietf.org Archive: http://www.ietf.org/mail-archive/web/rtg-yang-coord/ To subscribe: https://www.ietf.org/mailman/listinfo/rtg-yang-coord Purpose: The rtg-yang-coord mailing list will provide a forum for coordination of the development of YANG models being worked on for Routing, in order to provide a consistent view to the NMS. The intended participants are people active in Routing working groups and interested in the associated YANG models, and YANG experts assisting with Routing YANG models. While this list will help with the synchronization, WGs with responsibility for core routing protocols are expected to also be responsible for the development of YANG models for those protocols. For additional information, please contact the list administrators. _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From nobody Tue Oct 7 01:30:10 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C1B1A1B53 for ; Tue, 7 Oct 2014 01:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tS-__K85ZEn for ; Tue, 7 Oct 2014 01:30:07 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C98BA1A1BB9 for ; Tue, 7 Oct 2014 01:30:00 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id cc10so7033920wib.17 for ; Tue, 07 Oct 2014 01:29:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:to:cc:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=bBf+dwodbzL/q0o/LaDw5uRitjjsI0xjz/bqAA4zLWs=; b=TcF2ioZYnK/ixsHUdoOC03/TIgRXYjVLsW6o32bDX0EWcOPPZ6z1EAxT0wPh7xBLyP DBzEC2vxQZydkgeiEqgalqK2sKoVnQKKqKMIfnq26NUDS9BLL8r279o6ByFKpfqHWokf cVAcNm+hdlGazvpiqGtdSXB7l/tAW7u1/MjgKK8q2QhztIifTEuxZDQy9epw7X1V+iZH JQmV8kQNSOJUmoVh/D1uzukd+oolsK04dFAOFrNLNCsy7RDUd4n5WAuri7RLfkytVFOM DKCsNme/zaP0GC3fslYc8i+NuklAHJczQhkEJLXupZkfNdNeaUfy/JZGXc/FyccJsvLP aEcQ== X-Gm-Message-State: ALoCoQkNm9nn81EPFJLawbLiENiu5j5tOVX7YU5HlJDwxQa8PC1hZZebxFU3Hpe9z1u5OhCs/zUR X-Received: by 10.180.73.210 with SMTP id n18mr19132604wiv.79.1412670599482; Tue, 07 Oct 2014 01:29:59 -0700 (PDT) Received: from Serenity (176-227-128-84.ip.skylogicnet.com. [176.227.128.84]) by mx.google.com with ESMTPSA id i5sm19851637wjz.0.2014.10.07.01.29.52 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 07 Oct 2014 01:29:58 -0700 (PDT) Sender: Daniel King X-Google-Original-Sender: "Daniel King" From: "Daniel King" To: Date: Tue, 7 Oct 2014 09:29:40 +0100 Message-ID: <00e501cfe208$de9a1790$9bce46b0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac/iBxZvfDl7p6l2TL6t2b9i2U1FOw== Content-Language: en-gb Archived-At: http://mailarchive.ietf.org/arch/msg/pce/CuzR_MLiAVOZO5geXuB2ZkSTKxM Cc: diego@tid.es Subject: [Pce] Implementation Experience for draft-wu-pce-dns-pce-discovery X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 08:30:09 -0000 Hi All, Following on from my request for H-PCE implementation experience. I would like to highlight some European Research that utilized the DNS-based PCE Discovery proposal: Path Computation Element (PCE) Discovery using Domain Name System(DNS) https://datatracker.ietf.org/doc/draft-wu-pce-dns-pce-discovery/ The experiment uses virtual instances of VNF-based (Virtualized Network Function) PCE's. Benefits include: - (Virtual) PCEs are instantiated on demand - PCEs Perceived as a single VNF - PCEP Sessions are load-balanced The research ("Transport PCE Network Function Virtualization") is documented in Proceedings of European Conference on Optical Communication (ECOC 2014), 21-25 September, Cannes (France), and available via: http://www.cttc.es/publication/transport-pce-network-function-virtualization / The authors of draft-wu-pce-dns-pce-discovery plan to include the findings in an appendix of the aforementioned I-D. Br, Dan. From nobody Wed Oct 8 01:33:50 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3D7F1A6FD3 for ; Tue, 7 Oct 2014 09:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.014 X-Spam-Level: X-Spam-Status: No, score=0.014 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2jTA1rhxKZ_8 for ; Tue, 7 Oct 2014 09:39:45 -0700 (PDT) Received: from server.isocore.com (server.isocore.com [192.163.204.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2037F1A700A for ; Tue, 7 Oct 2014 09:39:45 -0700 (PDT) Received: from [65.213.193.86] (port=59269 helo=adminPCR) by server.isocore.com with esmtpa (Exim 4.82) (envelope-from ) id 1XbXnY-0006BO-9d for Pce@ietf.org; Tue, 07 Oct 2014 16:39:40 +0000 From: "Shamjhana" To: Date: Tue, 7 Oct 2014 12:39:49 -0400 Organization: Isocore Message-ID: <006001cfe24d$52a507a0$f7ef16e0$@isocore.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0061_01CFE22B.CB951550" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac/iTTwYq6TQXncYR8WE4Oi1O0muFQ== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.isocore.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - isocore.com X-Get-Message-Sender-Via: server.isocore.com: authenticated_id: spokharel@isocore.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/pce/004m1k7htXY-CJ5vxuJ5LpQDfiA X-Mailman-Approved-At: Wed, 08 Oct 2014 01:33:46 -0700 Subject: [Pce] Cloud & Data Center, WAN and Virtualization/NFV - SDN/MPLS 2014 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 16:39:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0061_01CFE22B.CB951550 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, Don't miss the opportunity to find out about the future of networking for service providers and large enterprise entities. Only three weeks is left to SDN/MPLS 2014 Conference. Please make sure to register at your earliest opportunity: http://www.isocore.com/sdn-mpls/attendees.php The SDN/MPLS 2014 Conference program is available at: http://www.isocore.com/sdn-mpls/ Tutorials (Sunday): http://www.isocore.com/sdn-mpls/tutorials.htm Technical sessions (Mon- Wed): http://www.isocore.com/sdn-mpls/technical_sessions.htm Please note that the cutoff date for hotel reservations is almost a week away! After this date, the rooms may not be available for consecutive days reservations. http://www.isocore.com/sdn-mpls/hotel.htm ------=_NextPart_000_0061_01CFE22B.CB951550 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

Don’t miss = the opportunity to find out about the future of networking for service = providers and large enterprise entities.

 

Only three weeks = is left to SDN/MPLS 2014 Conference. Please make sure to register = at your earliest opportunity:

 <= /span>

http://www.isocore= .com/sdn-mpls/attendees.php

 <= /span>

The SDN/MPLS 2014 = Conference program is available at: http://www.isocore.com/sdn-mpls= /
 
Tutorials (Sunday): http://www.isocore= .com/sdn-mpls/tutorials.htm
Technical sessions (Mon- = Wed): http://ww= w.isocore.com/sdn-mpls/technical_sessions.htm =

 

Please note that = the cutoff date for hotel reservations is almost a week away! After this = date, 
the rooms may not be available for consecutive days = reservations. 

http://www.is=
ocore.com/sdn-mpls/hotel.htm

 

------=_NextPart_000_0061_01CFE22B.CB951550-- From nobody Wed Oct 8 06:25:53 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 196461A1A66; Wed, 8 Oct 2014 06:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FeLl2nGMrlt; Wed, 8 Oct 2014 06:25:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4883A1A1A56; Wed, 8 Oct 2014 06:25:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141008132539.16223.77449.idtracker@ietfa.amsl.com> Date: Wed, 08 Oct 2014 06:25:39 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/nlULmVQ3TAajQN_XKKEskQXgBPQ Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-gmpls-pcep-extensions-10.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 13:25:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : PCEP extensions for GMPLS Authors : Cyril Margaria Oscar Gonzalez de Dios Fatai Zhang Filename : draft-ietf-pce-gmpls-pcep-extensions-10.txt Pages : 37 Date : 2014-10-08 Abstract: This memo provides extensions for the Path Computation Element communication Protocol (PCEP) for the support of GMPLS control plane. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-gmpls-pcep-extensions/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-gmpls-pcep-extensions-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-gmpls-pcep-extensions-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Oct 8 06:29:47 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1F8E1A1A55 for ; Wed, 8 Oct 2014 06:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5d52hbQ7FNrg for ; Wed, 8 Oct 2014 06:29:45 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A02351A1A40 for ; Wed, 8 Oct 2014 06:29:44 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id gm9so8253712lab.41 for ; Wed, 08 Oct 2014 06:29:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4p2F3NOMxdqN1SdFSjIWSwhSWpQFhlAgTejPPx7JXUo=; b=whaIkeZi62rT+NOKiH11oLxDbj2fdtEeqQAIVfJlJ+XqU2ezwEuOgjZ/f/uBo6g8o1 De0XZgH3mwi0H6L1n9XP1o5IQ1MWh1cV1SsiN1aGsto+lwiXZREpeks16Z/F0tKQ8HWS 8yjtKHp1/37wFEk6y1O7sKkw1n7LpkNg94ntye8IN9NpT63ccamriKPctPEtjwbqpMhq AAyYxdjnDwbd8hKEkilRXj+6ICQZaEScQIafoa3skEWarbSJ79Bqx8PthHAZukIwYckl d2aZ+3N52UmVitMcGZ3CTgTfgHgBzGgh3bDgyYsCJcGD2w0SLIaFRvadkKSzRLdCOj0l Njbw== MIME-Version: 1.0 X-Received: by 10.152.4.194 with SMTP id m2mr11708737lam.63.1412774982924; Wed, 08 Oct 2014 06:29:42 -0700 (PDT) Received: by 10.112.16.98 with HTTP; Wed, 8 Oct 2014 06:29:42 -0700 (PDT) In-Reply-To: <53CCDF7E.1060506@orange.com> References: <53B6D095.2030004@orange.com> <53CCDF7E.1060506@orange.com> Date: Wed, 8 Oct 2014 09:29:42 -0400 Message-ID: From: Cyril Margaria To: Julien Meuric Content-Type: multipart/alternative; boundary=089e013d1742013dd00504e94f64 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/vPZsnrCy4kh7H8VaMDz6I-XI8uw Cc: "pce@ietf.org" Subject: Re: [Pce] WG Last Call for draft-ietf-pce-gmpls-pcep-extensions-09 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 13:29:46 -0000 --089e013d1742013dd00504e94f64 Content-Type: text/plain; charset=UTF-8 Dear PCErs, The document has been updated to reflect your comments and has been posted. In addition we included the comments on IANA allocation received post LC. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-gmpls-pcep-extensions/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-gmpls-pcep-extensions-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-gmpls-pcep-extensions-10 Best Regards, Cyril On 21 July 2014 05:38, Julien Meuric wrote: > Hi all. > > This WG last call has ended. The authors are expected to address the > received comments (thank you John for the feedback). Chairs' review will > follow. > > Thanks, > > JP & Julien > > > Jul. 04, 2014 - Julien Meuric: > > Dear WG, >> >> Now that you all have some time dedicated to I-Ds, please consider this >> as part of your review list. >> >> This message ignites the WG LC on draft-ietf-pce-gmpls-pcep-extensions-09. >> Comments should be sent to the PCE mailing list by Friday July 18, 11:59 >> PM, HST. >> >> Regards, >> >> JP & Julien >> >> _______________________________________________ >> 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 > --089e013d1742013dd00504e94f64 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear PCErs,

The document has been u= pdated to reflect your comments and has been posted.

In additi= on we included the comments on IANA allocation received post LC.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-g= mpls-pcep-extensions/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-pce-gmpls-pcep-= extensions-10

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf= -pce-gmpls-pcep-extensions-10

Best Regards,
Cyril


O= n 21 July 2014 05:38, Julien Meuric <julien.meuric@orange.com&g= t; wrote:
Hi all.

This WG last call has ended. The authors are expected to address the receiv= ed comments (thank you John for the feedback). Chairs' review will foll= ow.

Thanks,

JP & Julien


Jul. 04, 2014 - Julien Meuric:

Dear WG,

Now that you all have some time dedicated to I-Ds, please consider this as = part of your review list.

This message ignites the WG LC on draft-ietf-pce-gmpls-pcep-extensio= ns-09. Comments should be sent to the PCE mailing list by Friday July 18, 1= 1:59 PM, HST.

Regards,

JP & Julien

_______________________________________________
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

--089e013d1742013dd00504e94f64-- From nobody Wed Oct 8 21:14:27 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5A871A8BBE for ; Wed, 8 Oct 2014 21:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whUrMKfDM4FZ for ; Wed, 8 Oct 2014 21:13:54 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07FE61A8AE3 for ; Wed, 8 Oct 2014 21:13:53 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNL37332; Thu, 09 Oct 2014 04:13:52 +0000 (GMT) Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 9 Oct 2014 05:13:51 +0100 Received: from szxeml556-mbs.china.huawei.com ([169.254.4.112]) by szxeml418-hub.china.huawei.com ([10.82.67.157]) with mapi id 14.03.0158.001; Thu, 9 Oct 2014 12:13:44 +0800 From: Dhruv Dhody To: "pce@ietf.org" Thread-Topic: A query regarding PCUpd - admin down Thread-Index: Ac/jd2lbXNmKIGVuTguw24WBEVUvtw== Date: Thu, 9 Oct 2014 04:13:43 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B866052BC@szxeml556-mbs.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.18.146.248] Content-Type: multipart/related; boundary="_004_23CE718903A838468A8B325B80962F9B866052BCszxeml556mbschi_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/pce/Cy0lQuymvcjK57hl8LMrFQYgNXk Subject: [Pce] A query regarding PCUpd - admin down X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 04:14:11 -0000 --_004_23CE718903A838468A8B325B80962F9B866052BCszxeml556mbschi_ Content-Type: multipart/alternative; boundary="_000_23CE718903A838468A8B325B80962F9B866052BCszxeml556mbschi_" --_000_23CE718903A838468A8B325B80962F9B866052BCszxeml556mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, For a delegated LSP, the stateful PCE may choose to make the LSP down and u= se the A bit in the LSP object in the PCUpd message, as per section 7.3 [ht= tp://tools.ietf.org/html/draft-ietf-pce-stateful-pce-09#page-31] - A(Administrative - 1 bit): On PCRpt messages, the A Flag indicates the PCC's target operational status for this LSP. On PCUpd messages, the A Flag indicates the LSP status that the PCE desires for this LSP. In both cases, a value of '1' means that the desired operational state is active, and a value of '0' means that the desired operational state is inactive. What should be the ERO during this operation in PCUpd message? [http://too= ls.ietf.org/html/draft-ietf-pce-stateful-pce-09#section-6.2] The format of a PCUpd message is as follows: ::=3D Where: ::=3D [] ::=3D Where: ::=3D IMHO it should be an empty ERO (i.e. ERO object with no sub-objects) as thi= s is the state that the PCE desire for this delegated LSP. What do you think? Should the desired behavior be noted in the draft to avo= id misinterpretation and inter-operability issues? Dhruv --_000_23CE718903A838468A8B325B80962F9B866052BCszxeml556mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 <= /p>

For a delegated LSP, the = stateful PCE may choose to make the LSP down and use the A bit in the LSP o= bject in the PCUpd message, as per section 7.3 [http://tools.ietf.org/html/= draft-ietf-pce-stateful-pce-09#page-31] –

 

A(Administrative - 1 bit):  On PCRp= t messages, the A Flag indicates

      the PCC's= target operational status for this LSP.  On PCUpd

      messages,= the A Flag indicates the LSP status that the PCE desires=

      for this = LSP.  In both cases, a value of '1' means that the

      desired o= perational state is active, and a value of '0' means that=

      the desir= ed operational state is inactive.

 

What should be the ERO du= ring this operation in PCUpd message?  [http://tools.ietf.org/html/dra= ft-ietf-pce-stateful-pce-09#section-6.2]

 

   The format of a PCUpd message is as follows:
 
   <PCUpd Message> ::=3D <Common Header>
           =
;            <upd=
ate-request-list>
Where:
 
   <update-request-list> ::=3D <update-request=
>[<update-request-list>]
 
   <update-request> ::=3D <SRP><=
/span>
           =
;             &=
lt;LSP>
           &nbs=
p;            &=
lt;path>
Where:
   <path>::=3D <ERO><attribute-list><=
o:p>
 

IMHO it should be an empt= y ERO (i.e. ERO object with no sub-objects) as this is the state that the P= CE desire for this delegated LSP.

 <= /p>

What do you think? Should= the desired behavior be noted in the draft to avoid misinterpretation and = inter-operability issues?

 <= /p>

Dhruv

--_000_23CE718903A838468A8B325B80962F9B866052BCszxeml556mbschi_-- --_004_23CE718903A838468A8B325B80962F9B866052BCszxeml556mbschi_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=906; creation-date="Thu, 09 Oct 2014 04:13:43 GMT"; modification-date="Thu, 09 Oct 2014 04:13:43 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhJwAmANUAAP///////v///f7+/v7+/f7+/P7++/7++v39/P39+/39+v39+f39+Pz8+fz8 +Pz89/z89vv7+fv7+Pv79/v79vv79fr69/r69vr69fr69Pr68/n59fn59Pn58/n58vj48/j48vj4 8ff38vf38fb27QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAJwAmAAAG/0CQcEgsGo/IYWLJ XCoUTic0MX1GqdWlwZAAeL/gsHhM/k4Uj4LDoTin1220mu2ex990BUVdcVQef35+gA+Cf4F9h4WJ hH4TDgUEBAUDAFsABZSWBpial5mVn54GAZwKCxZxF3oSEmerFK2vrK4KsLIKERMNEg4kv8DBwsPE xcAgHiAUHhwdHCAhy83P0czO0NLX1c0YIcpeXQWYAF0B4uLl5+QA5uPpmArrE/P09fb3+Pn0H94h /v3Q/kEL6G/gP4AHCwqZ8IEChQoMGTqE+EHiw4gNL1bMCLEChYaPLjigMAHCBAwiSZpEObLkyZQu WaoM6YDKgABPCCgIQACnAv+dPH0C7ZlzJ9GfT3AmECDAQc8CCTIlIBA1KlSqUKVitTo1agAECAIk GUs2SYZ5GS48uJDhQVsKGSg8wIDhAVy5dO3GnVv3Lt8HZQILLuOgQYM1hwsnXrwYcWPFiB07GMGB w4gOICx36EAZWgYhGbxp5kztM4jQmS9zfsK6tevXsGO3nnChNgW1tFNecFh7JO7et3nrfpB7AojN FEZQELJZyPLjmJUxj/68uXToH6AaUMCF+/YtVAR8777Fe/jxVMobKMS+vYMH8B1saO8efqH57+Pr 9zawPxGEQvD3n0EBDhECahlwVoFqGngwwoIYiJDggww6CKGECqqWQTxdLACvgIdViQNihx+Sk1WJ S5QIIlQXdNBii3Rx0GIGdGEgYwc12jhjjTfmeOMEDgUp5JBEFmmkQwo0gEEDQD6iJJMkFbZkk1JC 6eSUUTYg0i4YrEEBYl2OBKaXY4opJZlnOvAFJwAQsKYXbnrBZpyWwPlmm14gAIACBZyRwAITLJDA Kn8GOigUgApKaKKHFroAAgdYUNaklBpmS5IMsAFHA5kqsGmnn2rKBqeaNjDYqagGAQA7 --_004_23CE718903A838468A8B325B80962F9B866052BCszxeml556mbschi_-- From nobody Thu Oct 9 06:39:48 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F25E31A90C2 for ; Thu, 9 Oct 2014 06:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.724 X-Spam-Level: X-Spam-Status: No, score=0.724 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJeL0PwzvQ6Y for ; Thu, 9 Oct 2014 06:39:44 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 682F61A9127 for ; Thu, 9 Oct 2014 06:39:43 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 92E4919044E for ; Thu, 9 Oct 2014 15:39:41 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 725F7158086 for ; Thu, 9 Oct 2014 15:39:41 +0200 (CEST) Received: from [10.193.71.69] (10.197.38.2) by PEXCVZYH01.corporate.adroot.infra.ftgroup (10.114.1.186) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 9 Oct 2014 15:39:40 +0200 Message-ID: <24855_1412861981_5436901D_24855_13199_1_5436901B.5020708@orange.com> Date: Thu, 9 Oct 2014 15:39:39 +0200 From: Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: References: In-Reply-To: Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.197.38.2] X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.10.9.45121 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/CkCQaTjfI8F7iakty82Vcc8ddnk Subject: Re: [Pce] WG Last Call on draft-ietf-pce-stateful-pce-app-02 and draft-ietf-pce-stateful-pce-09 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 13:39:46 -0000 Hi all.

These last calls have ended. We have only seen one public review. Authors, please address received comments, including the one received today.

Thanks,

JP & Julien


Sep. 14, 2014 - JP Vasseur (jvasseur):
Dear WG,

Both draft-ietf-pce-stateful-pce-app-02 and draft-ietf-pce-stateful-pce-09 are now stable ready for WG Last Call.
This starts a 3-week WG Last call, which will end on Oct 6 at noon ET.

Please send your comments on the mailing list.

ps: this WG LC will be followed by another WG LC on draft-ietf-pce-stateful-sync-optimizations-01
and draft-ietf-pce-pce-initiated-lsp-01.


Thanks.

JP and Julien.


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


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
From nobody Thu Oct 9 11:33:34 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A15B1A0183 for ; Thu, 9 Oct 2014 11:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvXIQs-wce1k for ; Thu, 9 Oct 2014 11:33:29 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0780.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::780]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E0491A0154 for ; Thu, 9 Oct 2014 11:33:29 -0700 (PDT) Received: from BN1PR05MB358.namprd05.prod.outlook.com (10.141.61.147) by BN1PR05MB359.namprd05.prod.outlook.com (10.141.61.150) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Thu, 9 Oct 2014 18:33:05 +0000 Received: from BN1PR05MB358.namprd05.prod.outlook.com ([169.254.2.230]) by BN1PR05MB358.namprd05.prod.outlook.com ([169.254.2.230]) with mapi id 15.00.1049.012; Thu, 9 Oct 2014 18:33:05 +0000 From: Ramana Yarlagadda To: "pce@ietf.org" Thread-Topic: NULL PCUpdate message Thread-Index: Ac/j73aNrn9wH23VRJKUwPUOGQQ4TQ== Date: Thu, 9 Oct 2014 18:33:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.239.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB359; x-forefront-prvs: 0359162B6D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(53474002)(53754006)(189002)(199003)(120916001)(87936001)(99396003)(2656002)(21056001)(74316001)(64706001)(19580395003)(85852003)(15975445006)(40100002)(122556002)(66066001)(575784001)(76482002)(4396001)(105586002)(2501002)(97736003)(106356001)(108616004)(80022003)(15202345003)(95666004)(20776003)(101416001)(99286002)(86362001)(46102003)(107886001)(92566001)(76576001)(85306004)(50986999)(2351001)(110136001)(77096002)(54356999)(31966008)(33646002)(107046002)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB359; H:BN1PR05MB358.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_dd1f48112a014b0c923912dceebf3d98BN1PR05MB358namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/pce/70TV6VRklfLaNls50oyDXUyc2EQ Subject: [Pce] NULL PCUpdate message X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 18:33:31 -0000 --_000_dd1f48112a014b0c923912dceebf3d98BN1PR05MB358namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, I have a questions on sending the PCUpdate message to delegate an LSP from PCE to PCC. Can somebody please help me here to understand the PCUpdate mes= sage For delegating an LSP back to PCC. Re-delegation section talks about empty message but the PCUpdate request me= ssage definition Says that all LSP parameters muse be sent. 1) PCE requires to send an EMPTY LSP Update message to delegate an LSP= back to PCC. What is an acceptable empty LSP message? Please refer to section 5.5.5 of draft "PCEP extensions for stateful PCE" f= or procedure of returning Delegation 2) Section 6.2 of draft "PCEP extensions for stateful PCE" defines the= PCUpd message. - Three mandatory objects must be included in each PCUpd message. The= error codes Are defined to notify the sender if any of the mandatory objects m= issing in the PCUpdate Message. - Also, The draft says (copied text from section 6.2) - "An LSP Update Request MUST contain all LSP parameters that a PCE wishes to be set for the LSP. A PCC MAY set missing parameters from locally configured defaults. If the LSP specified in the Update Request is already up, it will be re-signaled. A clear definition of NULL message would help us here. -thanks in advance -ramana --_000_dd1f48112a014b0c923912dceebf3d98BN1PR05MB358namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi All,
&nbs= p;
I ha= ve a questions on sending the PCUpdate message to delegate an LSP from
PCE = to PCC. Can somebody please help me here to understand the PCUpdate message=
For = delegating an LSP back to PCC.
&nbs= p;
Re-d= elegation section talks about empty message but the PCUpdate request messag= e definition
Says= that all  LSP parameters muse be sent.
&nbs= p;
  1. PCE requires to send an EMPTY LSP Update message to delegate an LSP&nbs= p; back to PCC.
What is an acceptable empty LSP message?
&nbs= p;
Please refer to section 5.5.5 of draft “PCEP = extensions for stateful PCE” for procedure of returning=
Delegation
&nbs= p;
  1. Section 6.2 of draft “PCEP extensions for stateful PCE” def= ines the PCUpd message.
    2.
  • Three mandatory objects must be included in each PCUpd message. The err= or codes
    •
Are defined to notify the sender if any of the man= datory objects missing in the PCUpdate
Message.
  • Also, The draft says (copied text from section 6.2)
  •  
    • =
“An LSP Update Request MUST contain all LSP parameters that a PC= E wishes to
   be set for the LSP. A PCC MAY set missing parameters from= locally
   configured defaults.  If the LSP specified in the Up= date Request is
   already up, it will be re-signaled.
 
 
A clear definition of NULL message would help u= s here.
 
-thanks in advance
-ramana
&nbs= p;
&nbs= p;
 --_000_dd1f48112a014b0c923912dceebf3d98BN1PR05MB358namprd05pro_-- From nobody Thu Oct 9 12:04:31 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AFDE1A1AAF for ; Thu, 9 Oct 2014 12:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QBfuK5WM5tHA for ; Thu, 9 Oct 2014 12:04:24 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AC3F1A1A8B for ; Thu, 9 Oct 2014 12:04:24 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id cc10so14179871wib.1 for ; Thu, 09 Oct 2014 12:04:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=O9ces/3sBfZUv1kuRlPkvwxWEqpXCH0vArl4sf4xicU=; b=R6OlyLMGDGtqAiUZwr8SCA26HrZ1cHdIp1HHHh55FUuA9IyMcgdM8SNHvb/bhn7bGo O4twOlOeTh/Y+XhKS2/vf0t+xoNo1d1CqXw+pLG2JmZ6FxhBqI/+a6NRJyqVwWQWf5LP RcwJeyNCV84uMmjMsfakaVNesSh6g5jUXe5lTUuEZhQ5gceG0A5/4z/6J7O3a83x/GIO s9l6tq0MCEH1v8hi9hKaOCfzJf902JXwhcL2wmzQSv0zDx+pBi4V+DB1P21zGAVS/v1B qiJSnSvN1Gp/HPTjqse1vJSTzkFidp+kFYbCWRWJpLWwQ6L/TNlbZf8RfX0FC/Xx9iif nqEw== MIME-Version: 1.0 X-Received: by 10.180.210.231 with SMTP id mx7mr95571wic.42.1412881462897; Thu, 09 Oct 2014 12:04:22 -0700 (PDT) Received: by 10.27.78.193 with HTTP; Thu, 9 Oct 2014 12:04:22 -0700 (PDT) In-Reply-To: References: Date: Thu, 9 Oct 2014 15:04:22 -0400 Message-ID: From: Cyril Margaria To: Ramana Yarlagadda Content-Type: multipart/alternative; boundary=001a11c25d32b4b2fe05050219ee Archived-At: http://mailarchive.ietf.org/arch/msg/pce/a5fkzR459vX8_CSMnqv-GCTSVG8 Cc: "pce@ietf.org" Subject: Re: [Pce] NULL PCUpdate message X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 19:04:29 -0000 --001a11c25d32b4b2fe05050219ee Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, >From the definition, an empty PCUpd must contain an ERO, I think the question boils down to having an empty ERO or an ERO that mirrors the last ERO received. This is the only required parameter. I would propose the following text to clarify: Section 5.5.3: Add: Upon reception of a PCUpd with D=3D0 a PCC MUST ignore the LSP object = A bit and the ERO object content. With that the Empty (I would not introduce a NULL message) PCUpd contains SRP, LSP with PLSP-ID, all flags to 0, and an empty ERO. Br Cyril On 9 October 2014 14:33, Ramana Yarlagadda wrote: > Hi All, > > I have a questions on sending the PCUpdate message to delegate an LSP fro= m > PCE to PCC. Can somebody please help me here to understand the PCUpdate > message > For delegating an LSP back to PCC. > > Re-delegation section talks about empty message but the PCUpdate request > message definition > Says that all LSP parameters muse be sent. > > > 1. PCE requires to send an EMPTY LSP Update message to delegate an > LSP back to PCC. > > What is an acceptable empty LSP message? > > Please refer to section 5.5.5 of draft =E2=80=9CPCEP extensions for state= ful PCE=E2=80=9D > for procedure of returning > Delegation > > > 1. Section 6.2 of draft =E2=80=9CPCEP extensions for stateful PCE=E2= =80=9D defines > the PCUpd message. > > > - Three mandatory objects must be included in each PCUpd message. The > error codes > > Are defined to notify the sender if any of the mandatory objects missing > in the PCUpdate > Message. > > - Also, The draft says (copied text from section 6.2) > - > > =E2=80=9CAn LSP Update Request MUST contain all LSP parameters that a PCE= wishes to > be set for the LSP. A PCC MAY set missing parameters from locally > configured defaults. If the LSP specified in the Update Request is > already up, it will be re-signaled. > > > A clear definition of NULL message would help us here. > > -thanks in advance > -ramana > > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > --001a11c25d32b4b2fe05050219ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

From the defini= tion, an empty PCUpd must contain an ERO, I think the question boils down t= o having an empty ERO or an ERO that mirrors the last ERO received. This is= the only required parameter.

I would propose the following t= ext to clarify:

Section 5.5.3:
Add: Upon reception of= a PCUpd with D=3D0 a PCC MUST ignore the LSP object A bit and=C2=A0 the ER= O object content.

With that the Empty (I would not introduce a= NULL message) PCUpd contains SRP, LSP with PLSP-ID, all flags to 0, and an= empty ERO.

Br
Cyril


On 9 October 2014 14:33, Ramana Yarlagadda <ryarlaga@= juniper.net> wrote:
Hi All,
=C2=A0
I have a questio= ns on sending the PCUpdate message to delegate an LSP from
PCE to PCC. Can = somebody please help me here to understand the PCUpdate message
For delegating a= n LSP back to PCC.
=C2=A0
Re-delegation se= ction talks about empty message but the PCUpdate request message definition=
Says that all=C2= =A0 LSP parameters muse be sent.
=C2=A0
  1. PCE requires to send an EMPTY LSP Update message to delegate an LSP=C2= =A0 back to PCC.
What is an acceptable empty LSP message?
=C2=A0
Please refer to section 5.5.5 of draft =E2=80=9CPCEP extensions = for stateful PCE=E2=80=9D for procedure of returning
Delegation
=C2=A0
  1. Section 6.2 of draft =E2=80=9CPCEP extensions for stateful PCE=E2=80=9D= defines the PCUpd message.
    2.
  • Three mandatory objects must be included in each PCUpd message. The err= or codes
    •
Are defined to notify the sender if any of the mandatory object= s missing in the PCUpdate
Message.
  • Also, The draft says (copied text from section 6.2)
  • =C2=A0
    • =
=E2=80=9CAn LSP Update Request MUST contain all LSP parameters that a = PCE wishes to
=C2=A0=C2=A0 be set for the LSP. A PCC MAY set missing parameters from= locally
=C2=A0=C2=A0 configured defaults.=C2=A0 If the LSP specified in the Up= date Request is
=C2=A0=C2=A0 already up, it will be re-signaled.
=C2=A0
=C2=A0
A clear definition of NULL message would help u= s here.
=C2=A0
-thanks in advance
-ramana
=C2=A0
=C2=A0

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


--001a11c25d32b4b2fe05050219ee-- From nobody Thu Oct 9 21:47:12 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 456551A0127 for ; Thu, 9 Oct 2014 21:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vh6nmEFdBY0o for ; Thu, 9 Oct 2014 21:47:07 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEB121A0123 for ; Thu, 9 Oct 2014 21:47:06 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNM40527; Fri, 10 Oct 2014 04:47:05 +0000 (GMT) Received: from SZXEML456-HUB.china.huawei.com (10.82.67.199) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 10 Oct 2014 05:47:03 +0100 Received: from szxeml556-mbs.china.huawei.com ([169.254.4.112]) by szxeml456-hub.china.huawei.com ([10.82.67.199]) with mapi id 14.03.0158.001; Fri, 10 Oct 2014 12:46:57 +0800 From: Dhruv Dhody To: Cyril Margaria , Ramana Yarlagadda Thread-Topic: [Pce] NULL PCUpdate message Thread-Index: Ac/j73aNrn9wH23VRJKUwPUOGQQ4Tf//gqIA//7g7mA= Date: Fri, 10 Oct 2014 04:46:57 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B86605914@szxeml556-mbs.china.huawei.com> References: In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.146.248] Content-Type: multipart/alternative; boundary="_000_23CE718903A838468A8B325B80962F9B86605914szxeml556mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/pce/-Otf_kZ8sr-A1BNmUUPYgQsu7ec Cc: "pce@ietf.org" Subject: Re: [Pce] NULL PCUpdate message X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 04:47:10 -0000 --_000_23CE718903A838468A8B325B80962F9B86605914szxeml556mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQ3lyaWwsIFJhbWFuYSwNCg0KSSBhZ3JlZSB3aXRoIHRoaXMsIGR1cmluZyByZXR1cm5pbmcg ZGVsZWdhdGlvbiDigJMNCk9uIHRoZSByZWNlaXZpbmcgc2lkZSwgd2UgaWdub3JlIHRoZSBjb250 ZW50Lg0KT24gdGhlIHNlbmRpbmcgc2lkZSwgd2UgcHV0IGVtcHR5IEVSTyBvYmplY3Qgd2l0aCBu byBzdWJvYmplY3QuDQoNClRoZSBzYW1lIHByaW5jaXBsZSBpcyBhbHNvIGFwcGxpY2FibGUgdG8g dGhlIGFkbWluIGRvd24gYXMgcGVyIG15IG1haWwgZWFybGllcjogaHR0cDovL3d3dy5pZXRmLm9y Zy9tYWlsLWFyY2hpdmUvd2ViL3BjZS9jdXJyZW50L21zZzA0MDAwLmh0bWwNCg0KSXQgc2hvdWxk IGFsc28gdG8gYmUgbm90ZWQgdGhhdCB0aGlzIGlzIGFwcGxpY2FibGUgdG8gUENScHQgbWVzc2Fn ZSBhcyB3ZWxsIHdoZXJlIGluIHNvbWUgY2FzZSB3ZSB3b3VsZCBub3QgaGF2ZSB0aGUgRVJPIG9i amVjdCAoZm9yIGV4LiBEZWxlZ2F0aW9uIG9mIGp1c3QgY29uZmlndXJlZCwgbm90LXNpZ25hbGVk IExTUCA7IGFkbWluIGRvd24gb2YgTFNQIGV0YykuDQpJbiB0aGVzZSBjYXNlcyBhcyB3ZWxsIC0N Ck9uIHRoZSByZWNlaXZpbmcgc2lkZSwgd2UgaWdub3JlIHRoZSBjb250ZW50Lg0KT24gdGhlIHNl bmRpbmcgc2lkZSwgd2UgcHV0IGVtcHR5IEVSTyBvYmplY3Qgd2l0aCBubyBzdWJvYmplY3QuDQoN ClRodXMsIGFwYXJ0IGZvciBjeXJpbOKAmXMgc3VnZ2VzdGVkIHRleHQsIHdlIGNhbiBhZGQgZ2Vu ZXJpYyB0ZXh0IGluIFBDUnB0L1BjVXBkIG1lc3NhZ2Ugc2VjdGlvbiAoNi4xLCA2LjIpIC0NCg0K SW4gY2FzZSBvZiBhbiBMU1AgdGhhdCBpcyBub3QgeWV0IHNpZ25hbGVkIG9yIGFkbWluaXN0cmF0 aXZlbHkvDQpvcGVyYXRpb25hbGx5IGRvd24gb24gcmVjZWl2aW5nIHN1Y2ggc3RhdHVzIHZpYSBQ Q1JwdCBtZXNzYWdlIHRoZQ0KY29udGVudCBvZiBFUk8gb2JqZWN0IGlzIGlnbm9yZWQgYXQgUENF LCB3aGlsZSB0aGUgUENDIFNIT1VMRA0Kc2VuZCBhbiBlbXB0eSBFUk8gb2JqZWN0IHdpdGggbm8g c3ViLW9iamVjdHMgaW4gUENScHQgbWVzc2FnZS4NCg0KDQpJbiBjYXNlIG9mIGFuIExTUCB0aGF0 IGlzIGFkbWluaXN0cmF0aXZlbHkgZG93biBvciByZXR1cm5pbmcgb2YNCmRlbGVnYXRpb24gdmlh IFBDVXBkIG1lc3NhZ2UgdGhlIGNvbnRlbnQgb2YgRVJPIG9iamVjdCBpcw0KaWdub3JlZCBhdCBQ Q0MsIHdoaWxlIHRoZSBQQ0UgU0hPVUxEIHNlbmQgYW4gZW1wdHkgRVJPIG9iamVjdA0Kd2l0aCBu byBzdWItb2JqZWN0cyBpbiBQQ1VwZCBtZXNzYWdlLg0KDQpXaGF0IGRvZXMgdGhlIFdHIHRoaW5r IGFib3V0IHRoaXM/DQoNClJlZ2FyZHMsDQpEaHJ1dg0KDQpGcm9tOiBQY2UgW21haWx0bzpwY2Ut Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEN5cmlsIE1hcmdhcmlhDQpTZW50OiAxMCBP Y3RvYmVyIDIwMTQgMDA6MzQNClRvOiBSYW1hbmEgWWFybGFnYWRkYQ0KQ2M6IHBjZUBpZXRmLm9y Zw0KU3ViamVjdDogUmU6IFtQY2VdIE5VTEwgUENVcGRhdGUgbWVzc2FnZQ0KDQpIaSwNCkZyb20g dGhlIGRlZmluaXRpb24sIGFuIGVtcHR5IFBDVXBkIG11c3QgY29udGFpbiBhbiBFUk8sIEkgdGhp bmsgdGhlIHF1ZXN0aW9uIGJvaWxzIGRvd24gdG8gaGF2aW5nIGFuIGVtcHR5IEVSTyBvciBhbiBF Uk8gdGhhdCBtaXJyb3JzIHRoZSBsYXN0IEVSTyByZWNlaXZlZC4gVGhpcyBpcyB0aGUgb25seSBy ZXF1aXJlZCBwYXJhbWV0ZXIuDQpJIHdvdWxkIHByb3Bvc2UgdGhlIGZvbGxvd2luZyB0ZXh0IHRv IGNsYXJpZnk6DQoNClNlY3Rpb24gNS41LjM6DQpBZGQ6IFVwb24gcmVjZXB0aW9uIG9mIGEgUENV cGQgd2l0aCBEPTAgYSBQQ0MgTVVTVCBpZ25vcmUgdGhlIExTUCBvYmplY3QgQSBiaXQgYW5kICB0 aGUgRVJPIG9iamVjdCBjb250ZW50Lg0KV2l0aCB0aGF0IHRoZSBFbXB0eSAoSSB3b3VsZCBub3Qg aW50cm9kdWNlIGEgTlVMTCBtZXNzYWdlKSBQQ1VwZCBjb250YWlucyBTUlAsIExTUCB3aXRoIFBM U1AtSUQsIGFsbCBmbGFncyB0byAwLCBhbmQgYW4gZW1wdHkgRVJPLg0KDQpCcg0KQ3lyaWwNCg0K DQpPbiA5IE9jdG9iZXIgMjAxNCAxNDozMywgUmFtYW5hIFlhcmxhZ2FkZGEgPHJ5YXJsYWdhQGp1 bmlwZXIubmV0PG1haWx0bzpyeWFybGFnYUBqdW5pcGVyLm5ldD4+IHdyb3RlOg0KSGkgQWxsLA0K DQpJIGhhdmUgYSBxdWVzdGlvbnMgb24gc2VuZGluZyB0aGUgUENVcGRhdGUgbWVzc2FnZSB0byBk ZWxlZ2F0ZSBhbiBMU1AgZnJvbQ0KUENFIHRvIFBDQy4gQ2FuIHNvbWVib2R5IHBsZWFzZSBoZWxw IG1lIGhlcmUgdG8gdW5kZXJzdGFuZCB0aGUgUENVcGRhdGUgbWVzc2FnZQ0KRm9yIGRlbGVnYXRp bmcgYW4gTFNQIGJhY2sgdG8gUENDLg0KDQpSZS1kZWxlZ2F0aW9uIHNlY3Rpb24gdGFsa3MgYWJv dXQgZW1wdHkgbWVzc2FnZSBidXQgdGhlIFBDVXBkYXRlIHJlcXVlc3QgbWVzc2FnZSBkZWZpbml0 aW9uDQpTYXlzIHRoYXQgYWxsICBMU1AgcGFyYW1ldGVycyBtdXNlIGJlIHNlbnQuDQoNCjEuICAg ICAgIFBDRSByZXF1aXJlcyB0byBzZW5kIGFuIEVNUFRZIExTUCBVcGRhdGUgbWVzc2FnZSB0byBk ZWxlZ2F0ZSBhbiBMU1AgIGJhY2sgdG8gUENDLg0KV2hhdCBpcyBhbiBhY2NlcHRhYmxlIGVtcHR5 IExTUCBtZXNzYWdlPw0KDQpQbGVhc2UgcmVmZXIgdG8gc2VjdGlvbiA1LjUuNSBvZiBkcmFmdCDi gJxQQ0VQIGV4dGVuc2lvbnMgZm9yIHN0YXRlZnVsIFBDReKAnSBmb3IgcHJvY2VkdXJlIG9mIHJl dHVybmluZw0KRGVsZWdhdGlvbg0KDQoyLiAgICAgICBTZWN0aW9uIDYuMiBvZiBkcmFmdCDigJxQ Q0VQIGV4dGVuc2lvbnMgZm9yIHN0YXRlZnVsIFBDReKAnSBkZWZpbmVzIHRoZSBQQ1VwZCBtZXNz YWdlLg0KwrcgICAgICAgICBUaHJlZSBtYW5kYXRvcnkgb2JqZWN0cyBtdXN0IGJlIGluY2x1ZGVk IGluIGVhY2ggUENVcGQgbWVzc2FnZS4gVGhlIGVycm9yIGNvZGVzDQpBcmUgZGVmaW5lZCB0byBu b3RpZnkgdGhlIHNlbmRlciBpZiBhbnkgb2YgdGhlIG1hbmRhdG9yeSBvYmplY3RzIG1pc3Npbmcg aW4gdGhlIFBDVXBkYXRlDQpNZXNzYWdlLg0KwrcgICAgICAgICBBbHNvLCBUaGUgZHJhZnQgc2F5 cyAoY29waWVkIHRleHQgZnJvbSBzZWN0aW9uIDYuMikNCsK3DQrigJxBbiBMU1AgVXBkYXRlIFJl cXVlc3QgTVVTVCBjb250YWluIGFsbCBMU1AgcGFyYW1ldGVycyB0aGF0IGEgUENFIHdpc2hlcyB0 bw0KICAgYmUgc2V0IGZvciB0aGUgTFNQLiBBIFBDQyBNQVkgc2V0IG1pc3NpbmcgcGFyYW1ldGVy cyBmcm9tIGxvY2FsbHkNCiAgIGNvbmZpZ3VyZWQgZGVmYXVsdHMuICBJZiB0aGUgTFNQIHNwZWNp ZmllZCBpbiB0aGUgVXBkYXRlIFJlcXVlc3QgaXMNCiAgIGFscmVhZHkgdXAsIGl0IHdpbGwgYmUg cmUtc2lnbmFsZWQuDQoNCg0KQSBjbGVhciBkZWZpbml0aW9uIG9mIE5VTEwgbWVzc2FnZSB3b3Vs ZCBoZWxwIHVzIGhlcmUuDQoNCi10aGFua3MgaW4gYWR2YW5jZQ0KLXJhbWFuYQ0KDQoNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClBjZSBtYWlsaW5n IGxpc3QNClBjZUBpZXRmLm9yZzxtYWlsdG86UGNlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wY2UNCg0K --_000_23CE718903A838468A8B325B80962F9B86605914szxeml556mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1 IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6Q2FuZGFyYTsNCglwYW5vc2UtMToyIDE0IDUgMiAzIDMgMyAyIDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAz IDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1z b05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlz aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5ob2Vu emINCgl7bXNvLXN0eWxlLW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYW5kYXJhIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4w cHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0 IGwwDQoJe21zby1saXN0LWlkOjE1OTU0MDA5NTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE3 ODkzMjk2ODY7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MTM2MjUwOTM4NjsNCgltc28tbGlz dC10ZW1wbGF0ZS1pZHM6LTcwNDg2NTA1Njt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlkOjE0NDQ5NjI2NjA7DQoJbXNvLWxp c3QtdGVtcGxhdGUtaWRzOi0yMTAyMzkwMzI7fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJe21zby1sZXZl bC1zdGFydC1hdDoyOw0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDMNCgl7 bXNvLWxpc3QtaWQ6MTQ2ODg2Mjk0ODsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6NjE4NjY2NzMy O30NCkBsaXN0IGwzOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0Kb2wNCgl7bWFyZ2lu LWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbmRhcmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBDeXJpbCwgUmFtYW5hLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbmRhcmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YW5kYXJhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBhZ3Jl ZSB3aXRoIHRoaXMsIGR1cmluZyByZXR1cm5pbmcgZGVsZWdhdGlvbiDigJMNCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbmRhcmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5PbiB0aGUgcmVjZWl2aW5nIHNpZGUsIHdlIGlnbm9yZSB0aGUg Y29udGVudC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbmRhcmEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5PbiB0aGUgc2VuZGluZyBz aWRlLCB3ZSBwdXQgZW1wdHkgRVJPIG9iamVjdCB3aXRoIG5vIHN1Ym9iamVjdC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYW5kYXJhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FuZGFyYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlRoZSBzYW1lIHByaW5jaXBsZSBpcyBhbHNvIGFwcGxpY2FibGUgdG8gdGhlIGFkbWluIGRvd24g YXMgcGVyIG15IG1haWwgZWFybGllcjoNCjxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFp bC1hcmNoaXZlL3dlYi9wY2UvY3VycmVudC9tc2cwNDAwMC5odG1sIj5odHRwOi8vd3d3LmlldGYu b3JnL21haWwtYXJjaGl2ZS93ZWIvcGNlL2N1cnJlbnQvbXNnMDQwMDAuaHRtbDwvYT48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYW5kYXJhJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FuZGFyYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkl0IHNob3VsZCBhbHNvIHRvIGJlIG5vdGVkIHRoYXQgdGhpcyBpcyBhcHBsaWNhYmxlIHRv IFBDUnB0IG1lc3NhZ2UgYXMgd2VsbCB3aGVyZSBpbiBzb21lIGNhc2Ugd2Ugd291bGQgbm90IGhh dmUgdGhlIEVSTyBvYmplY3QgKGZvciBleC4gRGVsZWdhdGlvbiBvZiBqdXN0DQogY29uZmlndXJl ZCwgbm90LXNpZ25hbGVkIExTUCA7IGFkbWluIGRvd24gb2YgTFNQIGV0YykuIDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbmRhcmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5JbiB0aGVzZSBjYXNlcyBhcyB3ZWxsIC08bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYW5kYXJhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+T24gdGhlIHJlY2VpdmluZyBzaWRlLCB3ZSBpZ25vcmUgdGhlIGNv bnRlbnQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYW5kYXJhJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T24gdGhlIHNlbmRpbmcgc2lk ZSwgd2UgcHV0IGVtcHR5IEVSTyBvYmplY3Qgd2l0aCBubyBzdWJvYmplY3QuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FuZGFyYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbmRhcmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5U aHVzLCBhcGFydCBmb3IgY3lyaWzigJlzIHN1Z2dlc3RlZCB0ZXh0LCB3ZSBjYW4gYWRkIGdlbmVy aWMgdGV4dCBpbiBQQ1JwdC9QY1VwZCBtZXNzYWdlIHNlY3Rpb24gKDYuMSwgNi4yKSAtDQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYW5kYXJhJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SW4gY2FzZSBvZiBh biBMU1AgdGhhdCBpcyBub3QgeWV0IHNpZ25hbGVkIG9yIGFkbWluaXN0cmF0aXZlbHkvPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFG NDk3RCI+b3BlcmF0aW9uYWxseSBkb3duIG9uIHJlY2VpdmluZyBzdWNoIHN0YXR1cyB2aWEgUENS cHQgbWVzc2FnZSB0aGUNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmNvbnRlbnQgb2YgRVJPIG9iamVjdCBpcyBpZ25v cmVkIGF0IFBDRSwgd2hpbGUgdGhlIFBDQyBTSE9VTEQNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPnNlbmQgYW4gZW1w dHkgRVJPIG9iamVjdCB3aXRoIG5vIHN1Yi1vYmplY3RzIGluIFBDUnB0IG1lc3NhZ2UuDQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5JbiBjYXNlIG9mIGFu IExTUCB0aGF0IGlzIGFkbWluaXN0cmF0aXZlbHkgZG93biBvciByZXR1cm5pbmcgb2Y8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0 OTdEIj5kZWxlZ2F0aW9uIHZpYSBQQ1VwZCBtZXNzYWdlIHRoZSBjb250ZW50IG9mIEVSTyBvYmpl Y3QgaXMNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPmlnbm9yZWQgYXQgUENDLCB3aGlsZSB0aGUgUENFIFNIT1VMRCBz ZW5kIGFuIGVtcHR5IEVSTyBvYmplY3QNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPndpdGggbm8gc3ViLW9iamVjdHMg aW4gUENVcGQgbWVzc2FnZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYW5k YXJhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FuZGFyYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldoYXQgZG9lcyB0aGUgV0cgdGhpbmsgYWJvdXQg dGhpcz8NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbmRhcmEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYW5kYXJhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYW5kYXJhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ RGhydXY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYW5kYXJhJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAx LjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20g MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUGNlIFtt YWlsdG86cGNlLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkN5cmlsIE1h cmdhcmlhPGJyPg0KPGI+U2VudDo8L2I+IDEwIE9jdG9iZXIgMjAxNCAwMDozNDxicj4NCjxiPlRv OjwvYj4gUmFtYW5hIFlhcmxhZ2FkZGE8YnI+DQo8Yj5DYzo8L2I+IHBjZUBpZXRmLm9yZzxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogW1BjZV0gTlVMTCBQQ1VwZGF0ZSBtZXNzYWdlPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5IaSwg PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+RnJvbSB0aGUgZGVmaW5pdGlvbiwgYW4gZW1wdHkgUENVcGQgbXVz dCBjb250YWluIGFuIEVSTywgSSB0aGluayB0aGUgcXVlc3Rpb24gYm9pbHMgZG93biB0byBoYXZp bmcgYW4gZW1wdHkgRVJPIG9yIGFuIEVSTyB0aGF0IG1pcnJvcnMgdGhlIGxhc3QgRVJPIHJlY2Vp dmVkLiBUaGlzIGlzIHRoZSBvbmx5IHJlcXVpcmVkIHBhcmFtZXRlci4NCjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdvdWxkIHByb3Bvc2UgdGhlIGZvbGxv d2luZyB0ZXh0IHRvIGNsYXJpZnk6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxicj4NClNlY3Rpb24gNS41LjM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+QWRkOiBVcG9u IHJlY2VwdGlvbiBvZiBhIFBDVXBkIHdpdGggRD0wIGEgUENDIE1VU1QgaWdub3JlIHRoZSBMU1Ag b2JqZWN0IEEgYml0IGFuZCZuYnNwOyB0aGUgRVJPIG9iamVjdCBjb250ZW50LjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaXRoIHRoYXQgdGhlIEVtcHR5IChJ IHdvdWxkIG5vdCBpbnRyb2R1Y2UgYSBOVUxMIG1lc3NhZ2UpIFBDVXBkIGNvbnRhaW5zIFNSUCwg TFNQIHdpdGggUExTUC1JRCwgYWxsIGZsYWdzIHRvIDAsIGFuZCBhbiBlbXB0eSBFUk8uPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Ccjxicj4NCkN5cmlsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gOSBPY3RvYmVyIDIw MTQgMTQ6MzMsIFJhbWFuYSBZYXJsYWdhZGRhICZsdDs8YSBocmVmPSJtYWlsdG86cnlhcmxhZ2FA anVuaXBlci5uZXQiIHRhcmdldD0iX2JsYW5rIj5yeWFybGFnYUBqdW5pcGVyLm5ldDwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+SGkgQWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7 PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkkgaGF2ZSBh IHF1ZXN0aW9ucyBvbiBzZW5kaW5nIHRoZSBQQ1VwZGF0ZSBtZXNzYWdlIHRvIGRlbGVnYXRlIGFu IExTUCBmcm9tPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PlBDRSB0byBQQ0MuIENhbiBzb21lYm9keSBwbGVhc2UgaGVscCBtZSBoZXJlIHRvIHVuZGVyc3Rh bmQgdGhlIFBDVXBkYXRlIG1lc3NhZ2U8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+Rm9yIGRlbGVnYXRpbmcgYW4gTFNQIGJhY2sgdG8gUENDLjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+UmUtZGVsZWdhdGlvbiBzZWN0 aW9uIHRhbGtzIGFib3V0IGVtcHR5IG1lc3NhZ2UgYnV0IHRoZSBQQ1VwZGF0ZSByZXF1ZXN0IG1l c3NhZ2UgZGVmaW5pdGlvbjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5TYXlzIHRoYXQgYWxsJm5ic3A7IExTUCBwYXJhbWV0ZXJzIG11c2UgYmUgc2VudC48 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDowY207dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDps MCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEuPHNwYW4gc3R5bGU9ImZv bnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPlBDRSByZXF1aXJlcyB0byBzZW5kIGFuIEVNUFRZIExTUCBV cGRhdGUgbWVzc2FnZSB0byBkZWxlZ2F0ZSBhbiBMU1AmbmJzcDsgYmFjayB0byBQQ0MuDQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRl eHQtaW5kZW50OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5XaGF0IGlzIGFu IGFjY2VwdGFibGUgZW1wdHkgTFNQIG1lc3NhZ2U/PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRl eHQtaW5kZW50OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5QbGVhc2UgcmVm ZXIgdG8gc2VjdGlvbiA1LjUuNSBvZiBkcmFmdCDigJxQQ0VQIGV4dGVuc2lvbnMgZm9yIHN0YXRl ZnVsIFBDReKAnSBmb3IgcHJvY2VkdXJlIG9mIHJldHVybmluZzwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9InRleHQtaW5kZW50OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5E ZWxlZ2F0aW9uPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MGNtO3RleHQtaW5kZW50Oi0xOC4wcHQ7 bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzIiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4yLjxzcGFu IHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRp Zl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TZWN0aW9uIDYuMiBvZiBkcmFmdCDigJxQ Q0VQIGV4dGVuc2lvbnMgZm9yIHN0YXRlZnVsIFBDReKAnSBkZWZpbmVzIHRoZSBQQ1VwZCBtZXNz YWdlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4t bGVmdDowY207dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMyBsZXZlbDEgbGZvMyI+DQo8 IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9 ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwh W2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRocmVlIG1hbmRhdG9yeSBvYmpl Y3RzIG11c3QgYmUgaW5jbHVkZWQgaW4gZWFjaCBQQ1VwZCBtZXNzYWdlLiBUaGUgZXJyb3IgY29k ZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5BcmUgZGVmaW5lZCB0byBub3RpZnkgdGhlIHNlbmRl ciBpZiBhbnkgb2YgdGhlIG1hbmRhdG9yeSBvYmplY3RzIG1pc3NpbmcgaW4gdGhlIFBDVXBkYXRl DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+TWVzc2Fn ZS48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjBjbTt0ZXh0LWluZGVudDotMTguMHB0O21zby1s aXN0OmwxIGxldmVsMSBsZm80Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0 Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+QWxzbywgVGhlIGRyYWZ0IHNheXMgKGNvcGllZCB0ZXh0IGZyb20gc2VjdGlvbiA2LjIpPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjBj bTt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwxIGxldmVsMSBsZm80Ij4NCjwhW2lmICFz dXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5 bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3 LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZd PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij7igJxBbiBMU1AgVXBkYXRl IFJlcXVlc3QgTVVTVCBjb250YWluIGFsbCBMU1AgcGFyYW1ldGVycyB0aGF0IGEgUENFIHdpc2hl cyB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgYmUgc2V0IGZvciB0aGUgTFNQLiBBIFBDQyBN QVkgc2V0IG1pc3NpbmcgcGFyYW1ldGVycyBmcm9tIGxvY2FsbHk8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 Jm5ic3A7IGNvbmZpZ3VyZWQgZGVmYXVsdHMuJm5ic3A7IElmIHRoZSBMU1Agc3BlY2lmaWVkIGlu IHRoZSBVcGRhdGUgUmVxdWVzdCBpczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgYWxyZWFkeSB1 cCwgaXQgd2lsbCBiZSByZS1zaWduYWxlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QSBjbGVhciBkZWZpbml0aW9u IG9mIE5VTEwgbWVzc2FnZSB3b3VsZCBoZWxwIHVzIGhlcmUuPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4tdGhhbmtzIGlu IGFkdmFuY2U8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojODg4ODg4Ij4tcmFtYW5hPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM4ODg4ODgiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojODg4ODg4Ij4mbmJzcDs8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6Izg4ODg4OCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiM4ODg4ODgiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojODg4ODg4Ij48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NClBjZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt YWlsdG86UGNlQGlldGYub3JnIj5QY2VAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wY2UiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BjZTwvYT48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_23CE718903A838468A8B325B80962F9B86605914szxeml556mbschi_-- From nobody Fri Oct 10 07:41:50 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94BE01ACE0A for ; Fri, 10 Oct 2014 07:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slSDKWlrm3ld for ; Fri, 10 Oct 2014 07:41:47 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECA381ACD47 for ; Fri, 10 Oct 2014 07:41:46 -0700 (PDT) Received: by mail-ig0-f181.google.com with SMTP id r10so2963829igi.2 for ; Fri, 10 Oct 2014 07:41:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=mQCLAHQcbovPQ5yiy1EUvalwtV1X5b72bnY1YusxmuI=; b=QMo4liLpUrs0g0Z+LeeZsQg++CLgiMp7YAN8bGmGxFi/lqetvXM+tRBzLhxDajY9/4 Blv6yffrA5ZR66L0FCzMy1URTuurYXoOmPjHURrpBQiB8DaSAEFrLiWbua4hz2JO4hL8 +tKynx1yfFXazPLnhTzR96Tisw951a8X63gXRDnfYrYyFdZG1UPwAvqHBihW3fmODfjJ oMYEqyNVeCtFYixc6WxMYi4KRi7l5yyrTdW8CQkRsniIN44mM0MBVMiE8lSSE5c5R4L2 wtRZdZEmBYKIO5ivjSkWlw/SMGbKszBH+Wt5wkJ8bR4VVMg8qX0Vhr63d5ZO705UkZBA KZfw== MIME-Version: 1.0 X-Received: by 10.50.78.70 with SMTP id z6mr7372951igw.23.1412952106278; Fri, 10 Oct 2014 07:41:46 -0700 (PDT) Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.90.105 with HTTP; Fri, 10 Oct 2014 07:41:46 -0700 (PDT) In-Reply-To: <20141010143328.20319.63536.idtracker@ietfa.amsl.com> References: <20141010143328.20319.63536.idtracker@ietfa.amsl.com> Date: Fri, 10 Oct 2014 20:11:46 +0530 X-Google-Sender-Auth: pmxTBjF-GgWd1jsVl27WbhIm_Mw Message-ID: From: Dhruv Dhody To: "pce@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/_5mjRZeLIh3YpOvqOLvz6X_ssSE Subject: [Pce] Fwd: New Version Notification for draft-dhody-pce-iro-survey-00.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 14:41:48 -0000 Hi, Here are the results of the anonymous survey of the IRO implementation, triggered during the discussion of draft-ietf-pce-pcep-domain-sequence-05. The draft includes conclusion and proposed action points in section 5. Please have a look and provide comments on the list. Thanks, Dhruv ---------- Forwarded message ---------- From: Date: Fri, Oct 10, 2014 at 8:03 PM Subject: New Version Notification for draft-dhody-pce-iro-survey-00.txt To: Dhruv Dhody A new version of I-D, draft-dhody-pce-iro-survey-00.txt has been successfully submitted by Dhruv Dhody and posted to the IETF repository. Name: draft-dhody-pce-iro-survey Revision: 00 Title: Informal Survey into Include Route Object (IRO) Implementations in Path Computation Element communication Protocol (PCEP) Document date: 2014-10-10 Group: Individual Submission Pages: 10 URL: http://www.ietf.org/internet-drafts/draft-dhody-pce-iro-survey-00.txt Status: https://datatracker.ietf.org/doc/draft-dhody-pce-iro-survey/ Htmlized: http://tools.ietf.org/html/draft-dhody-pce-iro-survey-00 Abstract: During discussions of a document to provide a standard representation and encoding of Domain-Sequence within the Path Computation Element (PCE) communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. It was determined that there was a need for clarification with respect to the ordered nature of the Include Route Object (IRO). Since there was a proposal to have a new IRO type with ordering, as well as handling of Loose bit, it felt necessary to conduct a survey of the existing and planned implementations. This document summarizes the survey questions and captures the results. Some conclusions are also presented. This survey was informal and conducted via email. Responses were collected and anonymized by the PCE working group chairs. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Fri Oct 10 11:05:07 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1DD1A014C for ; Fri, 10 Oct 2014 11:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POAsoqOzrGOw for ; Fri, 10 Oct 2014 11:05:00 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0736.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::736]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F11661A006B for ; Fri, 10 Oct 2014 11:04:59 -0700 (PDT) Received: from BN1PR05MB358.namprd05.prod.outlook.com (10.141.61.147) by BN1PR05MB360.namprd05.prod.outlook.com (10.141.61.153) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Fri, 10 Oct 2014 18:04:33 +0000 Received: from BN1PR05MB358.namprd05.prod.outlook.com ([169.254.2.230]) by BN1PR05MB358.namprd05.prod.outlook.com ([169.254.2.230]) with mapi id 15.00.1049.012; Fri, 10 Oct 2014 18:04:34 +0000 From: Ramana Yarlagadda To: Dhruv Dhody , "pce@ietf.org" Thread-Topic: [Pce] A query regarding PCUpd - admin down Thread-Index: Ac/jd2lbXNmKIGVuTguw24WBEVUvtwBO8+oA Date: Fri, 10 Oct 2014 18:04:33 +0000 Message-ID: <37f37dea9819451f8d30e9e6833d7439@BN1PR05MB358.namprd05.prod.outlook.com> References: <23CE718903A838468A8B325B80962F9B866052BC@szxeml556-mbs.china.huawei.com> In-Reply-To: <23CE718903A838468A8B325B80962F9B866052BC@szxeml556-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.239.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB360; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 03607C04F0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(53754006)(189002)(199003)(377454003)(120916001)(101416001)(16236675004)(107886001)(86362001)(107046002)(19625215002)(17760045003)(99286002)(95666004)(74316001)(99936001)(76482002)(19580395003)(31966008)(54356999)(19580405001)(19300405004)(106356001)(15975445006)(76176999)(50986999)(92566001)(77096002)(2656002)(4396001)(85852003)(99396003)(87936001)(64706001)(76576001)(33646002)(19627595001)(66066001)(2501002)(19627405001)(105586002)(122556002)(46102003)(18206015026)(97736003)(21056001)(20776003)(85306004)(40100002)(15202345003)(108616004)(80022003)(18717965001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB360; H:BN1PR05MB358.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/related; boundary="_004_37f37dea9819451f8d30e9e6833d7439BN1PR05MB358namprd05pro_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/pce/qp5nqjD_GKd5sxBL3sI2a-sXNKU Subject: Re: [Pce] A query regarding PCUpd - admin down X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 18:05:03 -0000 --_004_37f37dea9819451f8d30e9e6833d7439BN1PR05MB358namprd05pro_ Content-Type: multipart/alternative; boundary="_000_37f37dea9819451f8d30e9e6833d7439BN1PR05MB358namprd05pro_" --_000_37f37dea9819451f8d30e9e6833d7439BN1PR05MB358namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, It helps to implement the draft and inter-operate with others, with a descr= iption of desired behavior in the draft. -regards -ramana From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Dhruv Dhody Sent: Wednesday, October 08, 2014 9:14 PM To: pce@ietf.org Subject: [Pce] A query regarding PCUpd - admin down Hi All, For a delegated LSP, the stateful PCE may choose to make the LSP down and u= se the A bit in the LSP object in the PCUpd message, as per section 7.3 [ht= tp://tools.ietf.org/html/draft-ietf-pce-stateful-pce-09#page-31] - A(Administrative - 1 bit): On PCRpt messages, the A Flag indicates the PCC's target operational status for this LSP. On PCUpd messages, the A Flag indicates the LSP status that the PCE desires for this LSP. In both cases, a value of '1' means that the desired operational state is active, and a value of '0' means that the desired operational state is inactive. What should be the ERO during this operation in PCUpd message? [http://too= ls.ietf.org/html/draft-ietf-pce-stateful-pce-09#section-6.2] The format of a PCUpd message is as follows: ::=3D Where: ::=3D [] ::=3D Where: ::=3D IMHO it should be an empty ERO (i.e. ERO object with no sub-objects) as thi= s is the state that the PCE desire for this delegated LSP. What do you think? Should the desired behavior be noted in the draft to avo= id misinterpretation and inter-operability issues? Dhruv --_000_37f37dea9819451f8d30e9e6833d7439BN1PR05MB358namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

=  

It he= lps to implement the draft and inter-operate with others, with a descriptio= n of  desired

behav= ior  in the draft.

=  

-rega= rds

-rama= na

From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Dhruv Dhody
Sent: Wednesday, October 08, 2014 9:14 PM
To: pce@ietf.org
Subject: [Pce] A query regarding PCUpd - admin down

 

Hi All,

 <= /p>

For a delegated LSP, the = stateful PCE may choose to make the LSP down and use the A bit in the LSP o= bject in the PCUpd message, as per section 7.3 [http://tools.ietf.org/html/= draft-ietf-pce-stateful-pce-09#page-31] –

 

A(Administrative - 1 bit):  On PCRp= t messages, the A Flag indicates

      the PCC's= target operational status for this LSP.  On PCUpd

      messages,= the A Flag indicates the LSP status that the PCE desires=

      for this = LSP.  In both cases, a value of '1' means that the

      desired o= perational state is active, and a value of '0' means that=

      the desir= ed operational state is inactive.

 

What should be the ERO du= ring this operation in PCUpd message?  [http://tools.ietf.org/html/dra= ft-ietf-pce-stateful-pce-09#section-6.2]

 

   The format of a PCUpd message is as follows:
 
   <PCUpd Message> ::=3D <Common Header>
           =
;            <upd=
ate-request-list>
Where:
 
   <update-request-list> ::=3D <update-request=
>[<update-request-list>]
 
   <update-request> ::=3D <SRP><=
/span>
           =
;             &=
lt;LSP>
           &nbs=
p;            &=
lt;path>
Where:
   <path>::=3D <ERO><attribute-list><=
o:p>
 

IMHO it should be an empt= y ERO (i.e. ERO object with no sub-objects) as this is the state that the P= CE desire for this delegated LSP.

 <= /p>

What do you think? Should= the desired behavior be noted in the draft to avoid misinterpretation and = inter-operability issues?

 <= /p>

Dhruv

--_000_37f37dea9819451f8d30e9e6833d7439BN1PR05MB358namprd05pro_-- --_004_37f37dea9819451f8d30e9e6833d7439BN1PR05MB358namprd05pro_ Content-Type: image/gif; name="image002.gif" Content-Description: image002.gif Content-Disposition: inline; filename="image002.gif"; size=906; creation-date="Fri, 10 Oct 2014 18:04:32 GMT"; modification-date="Fri, 10 Oct 2014 18:04:32 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhJwAmANUAAP///////v///f7+/v7+/f7+/P7++/7++v39/P39+/39+v39+f39+Pz8+fz8 +Pz89/z89vv7+fv7+Pv79/v79vv79fr69/r69vr69fr69Pr68/n59fn59Pn58/n58vj48/j48vj4 8ff38vf38fb27QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAJwAmAAAG/0CQcEgsGo/IYWLJ XCoUTic0MX1GqdWlwZAAeL/gsHhM/k4Uj4LDoTin1220mu2ex990BUVdcVQef35+gA+Cf4F9h4WJ hH4TDgUEBAUDAFsABZSWBpial5mVn54GAZwKCxZxF3oSEmerFK2vrK4KsLIKERMNEg4kv8DBwsPE xcAgHiAUHhwdHCAhy83P0czO0NLX1c0YIcpeXQWYAF0B4uLl5+QA5uPpmArrE/P09fb3+Pn0H94h /v3Q/kEL6G/gP4AHCwqZ8IEChQoMGTqE+EHiw4gNL1bMCLEChYaPLjigMAHCBAwiSZpEObLkyZQu WaoM6YDKgABPCCgIQACnAv+dPH0C7ZlzJ9GfT3AmECDAQc8CCTIlIBA1KlSqUKVitTo1agAECAIk GUs2SYZ5GS48uJDhQVsKGSg8wIDhAVy5dO3GnVv3Lt8HZQILLuOgQYM1hwsnXrwYcWPFiB07GMGB w4gOICx36EAZWgYhGbxp5kztM4jQmS9zfsK6tevXsGO3nnChNgW1tFNecFh7JO7et3nrfpB7AojN FEZQELJZyPLjmJUxj/68uXToH6AaUMCF+/YtVAR8777Fe/jxVMobKMS+vYMH8B1saO8efqH57+Pr 9zawPxGEQvD3n0EBDhECahlwVoFqGngwwoIYiJDggww6CKGECqqWQTxdLACvgIdViQNihx+Sk1WJ S5QIIlQXdNBii3Rx0GIGdGEgYwc12jhjjTfmeOMEDgUp5JBEFmmkQwo0gEEDQD6iJJMkFbZkk1JC 6eSUUTYg0i4YrEEBYl2OBKaXY4opJZlnOvAFJwAQsKYXbnrBZpyWwPlmm14gAIACBZyRwAITLJDA Kn8GOigUgApKaKKHFroAAgdYUNaklBpmS5IMsAFHA5kqsGmnn2rKBqeaNjDYqagGAQA7 --_004_37f37dea9819451f8d30e9e6833d7439BN1PR05MB358namprd05pro_-- From nobody Sun Oct 12 02:27:47 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E95F1A89BB for ; Sun, 12 Oct 2014 02:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZxK8EQgFvRdp for ; Sun, 12 Oct 2014 02:27:42 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD7811A89E5 for ; Sun, 12 Oct 2014 02:27:42 -0700 (PDT) Received: by mail-ig0-f179.google.com with SMTP id h18so7486555igc.6 for ; Sun, 12 Oct 2014 02:27:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=m2adKFwtcm6mQnfLAaIBr5y3EbQ7IocwNJpRg2IU9Gg=; b=pBuykY+scDfehnw+Yt2K1wTYjd5NJed8N/cKIxDhPAl6AxTrauRrQQdsRK7+RLrQY5 meRbxNCuWA1SPVSm1DL2iMqtGrGxpbeB7ngiSBrmDhKKw5hEvvoyxxCzhgAVDCpIMWz0 dwJ2aaCf+Zuj0kfNDaWjpaL29bt/UUqyAkvkYmoE4DeN7HBleI2LfGjGs1sTUS8lBvcW QenzWxhvEiQqOsvDJQ30/zyxsxjsmINvEdsyZUhFjf0rzTrlP9ixdpy0cXp8g1Z3T2As fv2thvODnas3xBTRDO8IYKfHMvX/rOuO/AnMqUMHss0vr3oKcjo5fdM3GeP4Cqmw3rfF nRcA== MIME-Version: 1.0 X-Received: by 10.50.112.199 with SMTP id is7mr6554287igb.23.1413106062158; Sun, 12 Oct 2014 02:27:42 -0700 (PDT) Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.90.105 with HTTP; Sun, 12 Oct 2014 02:27:42 -0700 (PDT) Date: Sun, 12 Oct 2014 14:57:42 +0530 X-Google-Sender-Auth: N8oonp8MsuYlH6IdGAE_VQGd7OA Message-ID: From: Dhruv Dhody To: "pce@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/dcecAE6uZw2RpMG9xAh1R0-DGxo Subject: [Pce] Update for P2MP Stateful PCE drafts X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2014 09:27:44 -0000 Hi All, We have updated the stateful P2MP drafts. Changes: - New error values for PCRpt and PCUpd messages. * Mandatory Objects * Fragmentation - Update IANA considerations (no suggested values) and impacted text in other sections. - Editorial Changes - Pavan as co-author We welcome feedback for these drafts. The authors feel that the documents are in good shape to be considered for WG adoption :) Dhruv URL: http://www.ietf.org/internet-drafts/draft-palle-pce-stateful-pce-p2mp-05.txt Status: https://datatracker.ietf.org/doc/draft-palle-pce-stateful-pce-p2mp/ Htmlized: http://tools.ietf.org/html/draft-palle-pce-stateful-pce-p2mp-05 Diff: http://www.ietf.org/rfcdiff?url2=draft-palle-pce-stateful-pce-p2mp-05 URL: http://www.ietf.org/internet-drafts/draft-palle-pce-stateful-pce-initiated-p2mp-lsp-04.txt Status: https://datatracker.ietf.org/doc/draft-palle-pce-stateful-pce-initiated-p2mp-lsp/ Htmlized: http://tools.ietf.org/html/draft-palle-pce-stateful-pce-initiated-p2mp-lsp-04 Diff: http://www.ietf.org/rfcdiff?url2=draft-palle-pce-stateful-pce-initiated-p2mp-lsp-04 From nobody Sun Oct 12 12:18:16 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 577F31A8035 for ; Sun, 12 Oct 2014 12:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.6 X-Spam-Level: X-Spam-Status: No, score=-98.6 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckKFp317Yi7F for ; Sun, 12 Oct 2014 12:18:12 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D672E1A70E2 for ; Sun, 12 Oct 2014 12:18:11 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s9CJI5da020579; Sun, 12 Oct 2014 20:18:05 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s9CJI4bb020571 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 12 Oct 2014 20:18:05 +0100 From: "Adrian Farrel" To: "'Leeyoung'" , References: <0aa101cfc23b$dd4688c0$97d39a40$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C2CA8C@dfweml706-chm> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C2CA8C@dfweml706-chm> Date: Sun, 12 Oct 2014 20:18:03 +0100 Message-ID: <042301cfe651$3efa1530$bcee3f90$@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: AQIXeCbwHdUbvjpcuz1elY1AeDvY/QLEIOxwm4eNdiA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21018.002 X-TM-AS-Result: No--40.019-10.0-31-10 X-imss-scan-details: No--40.019-10.0-31-10 X-TMASE-MatchedRID: IeZYkn8zfFr3fZ+bzIHVnuGonqgs5zxBh8Ytn75ClDNnnK6mXN72m1KH sJxahjDS6VJ24jAAQXFaT7TSaAHhNghU99L10igXQpxiLlDD9FWWesyrtKuK7Xx7vKFGDerJbwD 3tJixqrxNtdLSk6RTzxrVo05uEWY5EnaXhoxT534tMfCdg6KRDeiY+s2L3xQE1gisw2JKo8mCot ZDKveYpViq0hvGzL7x3GOdRCQVa1rLHotnmWgl5hfY306nA3bo+W1UJfANmI6dWeizHxoXa8Lmp 4jPUF8tRFsqph676uC7Ud+6yGPYg0IFCJ5KkAbPma6DzXaohvPoYQLZRCmISQoA43Ygn7fUEWXA mFVxJU5LToqKl4WWQbjPxQEPjqEHJjD3jvPICuBwUSK4/EeOxdRmti/O6j0CRfmFzyKgHb4wd2A EstTKvpXqOy23H22Pjivxf+zd+BLF6K3au82GJVVN8laWo90MYQXxsZnRwoLjsTquy0JRi7al99 To/MN+6f6eicG50XN7nZmSglxg9nNQXkvyemjfLi5PDX0qWHqtO1W2zFTsGC5ogL8T3/3Bv984u oE4bam2K/MJQtOE2FOajJytUgle88D4dD4zprAgYN6vgspk8ClayzmQ9QV0EvoxTu3fj1tQIjnR tfnuJXNhrpqo5RvGYlvEbT8gqkm43QBcEf+g8SArD+K6XhnHgGa+oYp5i6rM8es9bXCnzjkCUq/ CclOAsFVli0DDp5N1wUTUczwzqa1K0iuY09PbbuFuYBIpyuksCc2iFTIxrXjQ0NqHYhIhFMGIr5 XP/IKsg0VAmuAYQYFSTS6b/2fDWXg0GghHbMWeAiCmPx4NwLTrdaH1ZWqCpvI8UZOf47gc4WL5J jd88I2j49Ftap9EkGUtrowrXLg= Archived-At: http://mailarchive.ietf.org/arch/msg/pce/lR6yYvWECF5l3QRCJuHVmTrxPxM Cc: pce@ietf.org Subject: Re: [Pce] FW: AD review of draft-ietf-pce-wson-routing-wavelength X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2014 19:18:15 -0000 Hello, A while back Young sent this response and I didn't see any specific questions to me that were not just rhetorical. So I have been waiting for a new revision. I have to say that I am not convinced by the discussion of which return codes to supply when a path can't be found. Maybe, given the explanation, it would be better to replace "no path found" with "network disconnected" so that "wavelength not found" means there is a path, but not one that meets the WSON request. But it is still not clear to me how "wavelength not found" is used when there is a path and there *are* wavelengths available, but some other WSON constraints cannot be met on that wavelength. Why say "wavelength not found" instead of "unsupported FEC type"? But what if the there are two paths available each with one wavelength, but one cannot support the requested FEC type and the other cannot support the requested modulation type? Similarly, I'm not convinced by some of the discussion about the PCEP request having to include the path computation type. But Young's response, although it starts by disagreeing with my point (the bit I am not convinced by) seems to come round and end up agreeing with me. But bottom line is that this was on the list and no-one leapt in to say that Young's proposed changes are mad, so I was just expecting a new revision so we can move forward. OK? Adrian > -----Original Message----- > From: Leeyoung [mailto:leeyoung@huawei.com] > Sent: 28 August 2014 21:57 > To: adrian@olddog.co.uk; draft-ietf-pce-wson-routing- > wavelength.all@tools.ietf.org > Cc: pce@ietf.org > Subject: RE: [Pce] FW: AD review of draft-ietf-pce-wson-routing-wavelength > > Hi Adrian, > > Thanks for providing your timely review and valuable comments/suggestions of > this draft. > > Please see inline for my comment. > > Regards, > Young > > -----Original Message----- > From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: Wednesday, August 27, 2014 4:14 PM > To: draft-ietf-pce-wson-routing-wavelength.all@tools.ietf.org > Cc: pce@ietf.org > Subject: [Pce] FW: AD review of draft-ietf-pce-wson-routing-wavelength > > Re-send with correct draft alias address. > > Adrian > > > -----Original Message----- > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > Sent: 27 August 2014 22:13 > > To: 'draft-ietf-pce-wson-routing-wavelength.all@ietf.org' > > Cc: 'pce@ietf.org' > > Subject: AD review of draft-ietf-pce-wson-routing-wavelength > > > > Hi authors, > > > > I have done my usual AD review of your document in response to the > > publication request from the working group. The purpose of my review > > is to iron out any issues in the document and make sure I can support > > it through IETF last call and IESG evaluation. > > > > Many of my comments below are editorial, but a lot of them are > > questions of clarification or intended function. I would like to > > discuss these with you and the working group before update the draft. > > > > Thanks for the work, > > Adrian > > > > === > > > > Abstract > > Requirements for optical impairments will be > > addressed in a separate document. > > I guess you mean > > Requirements for PCEP extensions in support of optical impairments > > will be addressed in a separate document. > > > > [Young] Thanks. Yes. Will change per your clarification. > > > --- > > > > A couple of abbreviations are used without expansion... > > WA > > DWA > > > > I think an intro para in section 2 to break out the terminology of R, > > WA, and DWA > > > > [Young] Added in the first paragraph in Section 2 before the figure: > > "R stands for Routing, WA for Wavelength Assignment, and DWA for Distributed > Wavelength Assignment." > > > --- > > > > 3.1 > > A PCEP request MUST include the path computation type. > > > > I don't understand how a PCC knows whether it needs to know the > > wavelength or not. Suppose the PCC is an ingress: how does it know > > whether the network comprises all nodes that cannot perform wavelength > > conversion, all nodes with limited wavelength conversion, all nodes > > with full wavelength conversion abilities, or some mixture. In the > > case of the mixture, the choice of path will determine whether the > > wavelength must be known or not. > > [YOUNG] The PCC does not know which ones have wavelength conversion > capability, etc. That is the reason the PCC to inquire PCE of the wavelength > assignment including some conversion (as the PCE has all these info.). But, I think > you are saying this in the next paragraph. Only thing PCC knows that it needs an > optical path computation from PCE that comprises not only R (routing), but also > WA (wavelength assignment) in most cases. Why then Routing only option? We > assume that PCC has some prior knowledge about its policy/capability (e.g., > distributed WA at each node). > > > > > In fact, isn't it the PCE that knows whether or not to supply the > > wavelength based on its knowledge of the network capabilities and > > possibly based on the path it chose? The PCC, on the other hand, is > > always happy to have the labels supplied in the ERO, or not. > > [Young] Yes. The PCC is passive here. Whatever the PCE sends back, the PCC is > happy. > > > > > Furthermore, depending on the hops in the selected path, the > > wavelength assignment may come from the PCE for some hops (path > > segments) and may be distributed for other hops. It doesn't seem to be > > as black and white in the dimensions you have painted, but I would > > suggest that this does not matter because you can push the whole > > problem to PCE without PCC having to make any choice. > > [Young] Absolutely. > > > > --- > > > > 3.2 > > (i) Explicit Label Control (ELC) [RFC4003] > > > > Is this the right reference? It doesn't look like it to me! > > ELC is section 5 of RFC 3473. > > > [Young] You're correct. Will change. Replaced RFC4003 with RFC 3473 in Section > 8.2 as well. > > > --- > > > > 3.2 > > (ii) A set of recommended labels. The PCC can select the > > label based on local policy. > > > > Are you talking about a set of suggested labels for each hop? > > Or a set of potential e2e labels to use (from which the PCC can select > > just one to use)? > > [Young] Good question. The intention here is the former. As each node/pcc > processes and selects it own label, then the signaling will carry the rest of the > labels available for the next hop (minus the one selected), etc. > > > > --- > > > > 3.2 > > (c) In the case where a valid path is not found, the response MUST > > include why the path is not found (e.g., no path, wavelength not > > found, optical quality check failed, etc.) > > > > There is no explanation of "optical quality check" in this document. > > [Young] It was an illustrative example. I will delete that phrase. > > > > I am concerned that "no path found" and "wavelength not found" are > > artefacts of the implementation of RWA. Certainly, in the case of R+WA > > you might fail to find a path before asking for a wavelength, but even > > in that case, can you be sure that there is no path available because > > the network is disconnected or because all of the bandwidth (i.e. all > > of the labels) on some of the links has been used? In that case, how > > can you choose between "no path" and "no wavelength"? > > [Young] Yah, there is some subtlety here. "No path" available is primarily to > indicate that the network is disconnected for the requested path for a S-D pair. > Of course, this also implies "no wavelength" situation. However, there are cases > where there is path (b/w) but it fails to meet wavelength continuity constraint. > For instance a node has wavelength x available toward the next hop. But the next > hop does not have wavelength x (say it has wavelength y) and it has no > conversion capability. "No Wavelength" indicates this situation. > > > > > In more general cases, the failure to compute a path is simply the > > failure to find a path that meets the constraints. This sort of > > failure is no different to the general PCE computation failures - you > > can't simply state which single constraint caused the computation > > failure even if you know that relaxing one of the constraints would > > have allowed you to find a path because relaxing some other > > constraint(s) might also have resulted in a path being found. > > > > But anyway, how do you anticipate a PCC will react differently to > > these two different return codes? Can a PCC do anything different in > > the two cases? Can it vary the request? Can it trigger something in the > network? > > [Young] In general cases, a PCC may not react differently. On the other hand, I > can envision in advanced cases where the PCC may react differently for the case > of a "No Wavelength" error. Upon receipt of "no wavelength" indicator from the > PCE, the PCC may trigger a "Re-optimization" request (as explained in Section 3.4) > of some existing path in an hope to release the conflicted wavelength. But this > sounds like a bit wacky. :) > > > > --- > > > > 3.3 > > > > For consistency with the terminology in 5440, shouldn't you use > > "synchronized" instead of "simultaneous"? > > [Young] No problem. We can use "synchronized" in place of "simultaneous." > > > > --- > > > > 3.3 > > > > (a) A PCEP request MUST be able to specify an option for bulk RWA > > path request. Bulk path request is an ability to request a number > > of simultaneous RWA path requests. > > > > Are you adding a requirement here, or are you saying that any solution > > must not break existing function? If the latter, why are you singling > > out this specific function as being special to not break? > > [Young] I am adding a new requirement to be able to specify a bulk "RWA" > request indication analogous to section 3.1 for a single "RWA" request. > > > > (b) The PCEP response MUST include the path and the assigned > > wavelength assigned for each RWA path request specified in the > > original bulk request. > > > > > Are you changing SVEC behavior here? Are you making any change to 5440 > > and 6007? > > [Young] I think the encoding for SVEC can potentially include "WA" portion or > some other ways to indicate the path result (which is yet to be determined). But, > I don't think we are changing SVEC behavior. > > > > --- > > > > 3.4 > > 2. The corresponding response to the re-optimized request MUST > > provide the re-optimized path and wavelengths. > > > > I think you should add: > > > > ...even when the request asked for the path or the wavelength to > > remain unchanged. > > [Young] OK. No problem! > > > > --- > > > > 3.4 > > 3. In case that the path is not found, the response MUST include why > > the path is not found (e.g., no path, wavelength not found, both > > path and wavelength not found, etc.) > > > > Interesting. Not only do my comments from 3.2 (c) apply, but I have to > > wonder what it means to be unable to find a path during reoptimization. > > Isn't the current path always a legitimate reply to a reoptimization > > request? > > [Young] Not able to find a path during reoptimization means there is no > alternative path available than the current path. Here perhaps I can add some > phrase to clarify this: > > OLD: In case that the path is not found > NEW: In case that the new path (i.e., other than the current path) is not found > > > > > > --- > > > > 3.5 > > or an > > policy-based restriction > > > > s/an/a/ > > > [Young] Yes. Thanks. > > > --- > > > > Your use of RFC 2119 words is somewhat inconsistent. Sometimes you are > > setting expectations for the protocol solution > > > > Section 3.6 > > A request for two or more paths MUST be able to include an option > > > > and sometimes you are saying what an implementation might do > > > > Section 3.5 > > For any RWA computation type request, the requester (PCC) MAY > > specify a restriction on the wavelengths to be used > > > > While I can derive a protocol requirement from the second type of > > usage of 2119 language, I think I end up with something ambiguous. For > > example, in the quoted text it is possible to interpret: > > > > - The solution MUST allow the requester to specify a restriction > > or > > - The solution MAY allow the requester to specify a restriction > > > > I think you need to be clearer. > > [Young] Good point. I think it "MUST allow" is what is intended. > > How about: > > Section 3.6 > > OLD: A request for two or more paths MUST be able to include an option > NEW: A request for two or more paths MUST allow the requester to include an > option > > Section 3.5 > > OLD: For any RWA computation type request, the requester (PCC) MAY specify a > restriction on the wavelengths to be used > > NEW: For any RWA computation type request, the requester (PCC) MUST be > allowed to specify a restriction on the wavelengths to be used > > > > --- > > > > s/requestor/requester/ > > [Young] OK. Thanks. > > > > --- > > > > 3.6 > > In a network with wavelength conversion capabilities (e.g. sparse 3R > > regenerators), a request SHOULD be able to indicate whether a > > single, continuous wavelength should be allocated or not. In other > > words, the requesting PCC SHOULD be able to specify the precedence > > of wavelength continuity even if wavelength conversion is available. > > > > I don't object to the PCC being able to have input on this issue, but > > it isn't clear to me how the PCC is about to know about the network in > > this way. > > [Young] Do you think how the PCC know about the network is in scope of > discussion in this particular draft? I didn't think so. The PCC can be an NMS or > network planner that knows some networks via policy or some other supporting > systems. Even in the case that the PCC is a node, this knowledge may be inferred > from its local database or some other ways. Is this a reasonable assumption? > > > > > --- > > > > 3.7 > > > > I believe this requirement, but not how it is worded. Isn't the actual > > requirement to allow the PCC to specify the signal type at source, at > > destination, and state whether transit modification is acceptable? > > > > Maybe this section is also lacking a little background information? > > [Young] Yes, it is not clear as is. How about the following for Section 3.7: > > NEW: > > Signal processing compatibility is an important constraint for optical path > computation. The signal type for an end-to-end optical path must match at > source and at destination. > > The PCC MUST be allowed to specify the signal type at the endpoints (i.e., at > source and at destination). The following signal processing capabilities should be > supported at a minimum: > o Modulation Type List > o FEC Type List > > The PCC MUST also be allowed to state whether transit modification is acceptable > for the above signal processing capabilities. > > End of NEW > > > > --- > > > > 4.6 > > > > Mechanisms defined in this document do not imply any new network > > operation requirements in addition to those already listed in > > section 8.6 of [RFC5440]. > > > > Are you sure? Are there no assumptions about the distribution of > > wavelength availability information, and wavelength conversion > > ability, etc.? > > > [Young] Network Operation Impacts in 8.6 of RFC 5440 deal with primarily PCEP > speaker sessions and how to limit it in case of operational impacts or of this > nature. The distribution of optical information you mentioned in a PCEP context is > simple adding more info just like other PCEP extensions, isn't it? > > > -- > > > > I think you have an excess of boilerplate at the end of your draft. > > You can safely delete everything after the Authors' Addresses. (I > > suspect your Word template thing is out of date.) > > [Young] deleted. > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From nobody Mon Oct 13 01:35:23 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 778991A1B53; Mon, 13 Oct 2014 01:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BoxULY_Glg1G; Mon, 13 Oct 2014 01:35:19 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E2751A02A0; Mon, 13 Oct 2014 01:35:16 -0700 (PDT) Received: by mail-ig0-f173.google.com with SMTP id h18so9582329igc.6 for ; Mon, 13 Oct 2014 01:35:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=KaPvzmcmq9//1h6/BCQ/NfRE5nG8LKK5vC6Djzp+D9E=; b=nmxVqlJYCby2AWO8YOXwKdPhI8LIVp1cfHbQVLe8N4MpzWOOObenC+ZljojmJt4qAg 1sVTiotkud52c5UmVU8Og9CQg+/iTQnWA5t2ME2FA5YCyW79E1LKHsfue6j1BwOkXYCW kxIymsXmah2NoziwvXAkrpKf3V9ys/qfH0B38wskkXTUMbHPw1pfNRmhkPTeAIPNSKmd J0POmoR7FAXOWDXEUV46pnH5phegoOLsTGzAOGrGKtWuI+tMFBfar7hIQTjWUAF7E6kD rM26Hb/3qSKsYGhqMlSAzzxaQFvU3CmuGWvumAHAZftXtqvV++AmOEiXtxTuM/tZCpNy J57A== MIME-Version: 1.0 X-Received: by 10.42.90.80 with SMTP id j16mr33236303icm.27.1413189315666; Mon, 13 Oct 2014 01:35:15 -0700 (PDT) Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.90.105 with HTTP; Mon, 13 Oct 2014 01:35:15 -0700 (PDT) In-Reply-To: <20141010045652.15131.78592.idtracker@ietfa.amsl.com> References: <20141010045652.15131.78592.idtracker@ietfa.amsl.com> Date: Mon, 13 Oct 2014 14:05:15 +0530 X-Google-Sender-Auth: rmrRP6Z2Xg57IioS_aTzV3cqf4U Message-ID: From: Dhruv Dhody To: "pce@ietf.org" , Rtg-yang-coord@ietf.org, draft-pkd-pce-pcep-yang@tools.ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/0cJEoQtsx3Qty_wV4jH-JfpFbnM Subject: [Pce] Fwd: New Version Notification for draft-pkd-pce-pcep-yang-00.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 08:35:22 -0000 Hi All, We have submitted a new I.D. that defines a base YANG module for PCEP as per RFC5440. Please provide your feedback on the draft. Regards, Dhruv PS. Once we have initial consensus on the base we would like to work on augmenting the YANG module for PCEP extensions. If you are interested in this work do get in touch. ---------- Forwarded message ---------- From: Date: Fri, Oct 10, 2014 at 10:26 AM Subject: New Version Notification for draft-pkd-pce-pcep-yang-00.txt To: Rohit Pobbathi , Vinod KumarS , Jonathan Hardwick , Dhruv Dhody A new version of I-D, draft-pkd-pce-pcep-yang-00.txt has been successfully submitted by Dhruv Dhody and posted to the IETF repository. Name: draft-pkd-pce-pcep-yang Revision: 00 Title: A YANG Data Model for Path Computation Element Communications Protocol (PCEP) Document date: 2014-10-09 Group: Individual Submission Pages: 44 URL: http://www.ietf.org/internet-drafts/draft-pkd-pce-pcep-yang-00.txt Status: https://datatracker.ietf.org/doc/draft-pkd-pce-pcep-yang/ Htmlized: http://tools.ietf.org/html/draft-pkd-pce-pcep-yang-00 Abstract: This document defines a YANG data model for the management of Path Computation Element communications Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs. The data model includes configuration data and state data (status information and counters for the collection of statistics). Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Mon Oct 13 09:12:54 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B6E71A037D for ; Mon, 13 Oct 2014 09:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.488 X-Spam-Level: X-Spam-Status: No, score=-1.488 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gO9II0Ju_8l for ; Mon, 13 Oct 2014 09:12:46 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C56821A037E for ; Mon, 13 Oct 2014 09:12:44 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNP28256; Mon, 13 Oct 2014 16:12:43 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 13 Oct 2014 17:12:42 +0100 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0158.001; Mon, 13 Oct 2014 09:12:33 -0700 From: Leeyoung To: "adrian@olddog.co.uk" , "draft-ietf-pce-wson-routing-wavelength.all@tools.ietf.org" Thread-Topic: [Pce] FW: AD review of draft-ietf-pce-wson-routing-wavelength Thread-Index: AQIXeCbwHdUbvjpcuz1elY1AeDvY/QLEIOxwm4eNdiCAAVzhgA== Date: Mon, 13 Oct 2014 16:12:33 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C3D8C7@dfweml706-chm> References: <0aa101cfc23b$dd4688c0$97d39a40$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C2CA8C@dfweml706-chm> <042301cfe651$3efa1530$bcee3f90$@olddog.co.uk> In-Reply-To: <042301cfe651$3efa1530$bcee3f90$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.132.244] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/pce/26ziWEkMawAVFsRSnR-PBtb8uF0 Cc: "pce@ietf.org" Subject: Re: [Pce] FW: AD review of draft-ietf-pce-wson-routing-wavelength X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 16:12:50 -0000 Hi Adrian, The update will be available soon. Thanks for your further comment. Please = see in-line for my response.=20 Best regards, Young -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: Sunday, October 12, 2014 2:18 PM To: Leeyoung; draft-ietf-pce-wson-routing-wavelength.all@tools.ietf.org Cc: pce@ietf.org Subject: RE: [Pce] FW: AD review of draft-ietf-pce-wson-routing-wavelength Hello, A while back Young sent this response and I didn't see any specific questio= ns to me that were not just rhetorical. So I have been waiting for a new re= vision. I have to say that I am not convinced by the discussion of which return cod= es to supply when a path can't be found. Maybe, given the explanation, it w= ould be better to replace "no path found" with "network disconnected" so th= at "wavelength not found" means there is a path, but not one that meets the= WSON request.=20 YOUNG>> OK. Agreed. =20 But it is still not clear to me how "wavelength not found" is used when the= re is a path and there *are* wavelengths available, but some other WSON con= straints cannot be met on that wavelength. Why say "wavelength not found" i= nstead of "unsupported FEC type"? But what if the there are two paths avail= able each with one wavelength, but one cannot support the requested FEC typ= e and the other cannot support the requested modulation type? YOUNG>> I will add some text that says wavelength not found means there is = a path, but not one that meets the WSON request (e.g., wavelength continuit= y is not met, unsupported FEC/Modulation type.) =20 Similarly, I'm not convinced by some of the discussion about the PCEP reque= st having to include the path computation type. But Young's response, altho= ugh it starts by disagreeing with my point (the bit I am not convinced by) = seems to come round and end up agreeing with me. But bottom line is that this was on the list and no-one leapt in to say tha= t Young's proposed changes are mad, so I was just expecting a new revision = so we can move forward. OK? Adrian > -----Original Message----- > From: Leeyoung [mailto:leeyoung@huawei.com] > Sent: 28 August 2014 21:57 > To: adrian@olddog.co.uk; draft-ietf-pce-wson-routing-=20 > wavelength.all@tools.ietf.org > Cc: pce@ietf.org > Subject: RE: [Pce] FW: AD review of=20 > draft-ietf-pce-wson-routing-wavelength >=20 > Hi Adrian, >=20 > Thanks for providing your timely review and valuable=20 > comments/suggestions of this draft. >=20 > Please see inline for my comment. >=20 > Regards, > Young >=20 > -----Original Message----- > From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: Wednesday, August 27, 2014 4:14 PM > To: draft-ietf-pce-wson-routing-wavelength.all@tools.ietf.org > Cc: pce@ietf.org > Subject: [Pce] FW: AD review of draft-ietf-pce-wson-routing-wavelength >=20 > Re-send with correct draft alias address. >=20 > Adrian >=20 > > -----Original Message----- > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > Sent: 27 August 2014 22:13 > > To: 'draft-ietf-pce-wson-routing-wavelength.all@ietf.org' > > Cc: 'pce@ietf.org' > > Subject: AD review of draft-ietf-pce-wson-routing-wavelength > > > > Hi authors, > > > > I have done my usual AD review of your document in response to the=20 > > publication request from the working group. The purpose of my review=20 > > is to iron out any issues in the document and make sure I can=20 > > support it through IETF last call and IESG evaluation. > > > > Many of my comments below are editorial, but a lot of them are=20 > > questions of clarification or intended function. I would like to=20 > > discuss these with you and the working group before update the draft. > > > > Thanks for the work, > > Adrian > > > > =3D=3D=3D > > > > Abstract > > Requirements for optical impairments will be > > addressed in a separate document. > > I guess you mean > > Requirements for PCEP extensions in support of optical impairments > > will be addressed in a separate document. > > >=20 > [Young] Thanks. Yes. Will change per your clarification. >=20 > > --- > > > > A couple of abbreviations are used without expansion... > > WA > > DWA > > > > I think an intro para in section 2 to break out the terminology of=20 > > R, WA, and DWA > > >=20 > [Young] Added in the first paragraph in Section 2 before the figure: >=20 > "R stands for Routing, WA for Wavelength Assignment, and DWA for=20 > Distributed Wavelength Assignment." >=20 > > --- > > > > 3.1 > > A PCEP request MUST include the path computation type. > > > > I don't understand how a PCC knows whether it needs to know the=20 > > wavelength or not. Suppose the PCC is an ingress: how does it know=20 > > whether the network comprises all nodes that cannot perform=20 > > wavelength conversion, all nodes with limited wavelength conversion,=20 > > all nodes with full wavelength conversion abilities, or some=20 > > mixture. In the case of the mixture, the choice of path will=20 > > determine whether the wavelength must be known or not. >=20 > [YOUNG] The PCC does not know which ones have wavelength conversion=20 > capability, etc. That is the reason the PCC to inquire PCE of the=20 > wavelength assignment including some conversion (as the PCE has all=20 > these info.). But, I think > you are saying this in the next paragraph. Only thing PCC knows that=20 > it needs an > optical path computation from PCE that comprises not only R (routing),=20 > but also > WA (wavelength assignment) in most cases. Why then Routing only=20 > option? We assume that PCC has some prior knowledge about its=20 > policy/capability (e.g., distributed WA at each node). >=20 > > > > In fact, isn't it the PCE that knows whether or not to supply the=20 > > wavelength based on its knowledge of the network capabilities and=20 > > possibly based on the path it chose? The PCC, on the other hand, is=20 > > always happy to have the labels supplied in the ERO, or not. >=20 > [Young] Yes. The PCC is passive here. Whatever the PCE sends back, the=20 > PCC is happy. >=20 > > > > Furthermore, depending on the hops in the selected path, the=20 > > wavelength assignment may come from the PCE for some hops (path > > segments) and may be distributed for other hops. It doesn't seem to=20 > > be as black and white in the dimensions you have painted, but I=20 > > would suggest that this does not matter because you can push the=20 > > whole problem to PCE without PCC having to make any choice. >=20 > [Young] Absolutely. > > > > --- > > > > 3.2 > > (i) Explicit Label Control (ELC) [RFC4003] > > > > Is this the right reference? It doesn't look like it to me! > > ELC is section 5 of RFC 3473. > > > [Young] You're correct. Will change. Replaced RFC4003 with RFC 3473 in=20 > Section > 8.2 as well. >=20 > > --- > > > > 3.2 > > (ii) A set of recommended labels. The PCC can select the > > label based on local policy. > > > > Are you talking about a set of suggested labels for each hop? > > Or a set of potential e2e labels to use (from which the PCC can=20 > > select just one to use)? >=20 > [Young] Good question. The intention here is the former. As each=20 > node/pcc processes and selects it own label, then the signaling will=20 > carry the rest of the > labels available for the next hop (minus the one selected), etc. > > > > --- > > > > 3.2 > > (c) In the case where a valid path is not found, the response MUST > > include why the path is not found (e.g., no path, wavelength not > > found, optical quality check failed, etc.) > > > > There is no explanation of "optical quality check" in this document. >=20 > [Young] It was an illustrative example. I will delete that phrase. > > > > I am concerned that "no path found" and "wavelength not found" are=20 > > artefacts of the implementation of RWA. Certainly, in the case of=20 > > R+WA you might fail to find a path before asking for a wavelength,=20 > > but even in that case, can you be sure that there is no path=20 > > available because the network is disconnected or because all of the=20 > > bandwidth (i.e. all of the labels) on some of the links has been=20 > > used? In that case, how can you choose between "no path" and "no wavele= ngth"? >=20 > [Young] Yah, there is some subtlety here. "No path" available is=20 > primarily to indicate that the network is disconnected for the=20 > requested path for a S-D pair. > Of course, this also implies "no wavelength" situation. However, there=20 > are cases > where there is path (b/w) but it fails to meet wavelength continuity constraint. > For instance a node has wavelength x available toward the next hop.=20 > But the next > hop does not have wavelength x (say it has wavelength y) and it has no=20 > conversion capability. "No Wavelength" indicates this situation. >=20 > > > > In more general cases, the failure to compute a path is simply the=20 > > failure to find a path that meets the constraints. This sort of=20 > > failure is no different to the general PCE computation failures -=20 > > you can't simply state which single constraint caused the=20 > > computation failure even if you know that relaxing one of the=20 > > constraints would have allowed you to find a path because relaxing=20 > > some other > > constraint(s) might also have resulted in a path being found. > > > > But anyway, how do you anticipate a PCC will react differently to=20 > > these two different return codes? Can a PCC do anything different in=20 > > the two cases? Can it vary the request? Can it trigger something in=20 > > the > network? >=20 > [Young] In general cases, a PCC may not react differently. On the=20 > other hand, I > can envision in advanced cases where the PCC may react differently for=20 > the case > of a "No Wavelength" error. Upon receipt of "no wavelength" indicator=20 > from the PCE, the PCC may trigger a "Re-optimization" request (as=20 > explained in Section 3.4) > of some existing path in an hope to release the conflicted wavelength.=20 > But this > sounds like a bit wacky. :) > > > > --- > > > > 3.3 > > > > For consistency with the terminology in 5440, shouldn't you use=20 > > "synchronized" instead of "simultaneous"? >=20 > [Young] No problem. We can use "synchronized" in place of "simultaneous." > > > > --- > > > > 3.3 > > > > (a) A PCEP request MUST be able to specify an option for bulk RWA > > path request. Bulk path request is an ability to request a number > > of simultaneous RWA path requests. > > > > Are you adding a requirement here, or are you saying that any=20 > > solution must not break existing function? If the latter, why are=20 > > you singling out this specific function as being special to not break? >=20 > [Young] I am adding a new requirement to be able to specify a bulk "RWA" > request indication analogous to section 3.1 for a single "RWA" request. > > > > (b) The PCEP response MUST include the path and the assigned > > wavelength assigned for each RWA path request specified in the > > original bulk request. >=20 > > > > Are you changing SVEC behavior here? Are you making any change to=20 > > 5440 and 6007? >=20 > [Young] I think the encoding for SVEC can potentially include "WA"=20 > portion or some other ways to indicate the path result (which is yet to b= e determined). But, > I don't think we are changing SVEC behavior. > > > > --- > > > > 3.4 > > 2. The corresponding response to the re-optimized request MUST > > provide the re-optimized path and wavelengths. > > > > I think you should add: > > > > ...even when the request asked for the path or the wavelength to > > remain unchanged. >=20 > [Young] OK. No problem! > > > > --- > > > > 3.4 > > 3. In case that the path is not found, the response MUST include why > > the path is not found (e.g., no path, wavelength not found, both > > path and wavelength not found, etc.) > > > > Interesting. Not only do my comments from 3.2 (c) apply, but I have=20 > > to wonder what it means to be unable to find a path during reoptimizati= on. > > Isn't the current path always a legitimate reply to a reoptimization=20 > > request? >=20 > [Young] Not able to find a path during reoptimization means there is=20 > no alternative path available than the current path. Here perhaps I=20 > can add some phrase to clarify this: >=20 > OLD: In case that the path is not found > NEW: In case that the new path (i.e., other than the current path) is=20 > not found >=20 >=20 > > > > --- > > > > 3.5 > > or an > > policy-based restriction > > > > s/an/a/ > > > [Young] Yes. Thanks. >=20 > > --- > > > > Your use of RFC 2119 words is somewhat inconsistent. Sometimes you=20 > > are setting expectations for the protocol solution > > > > Section 3.6 > > A request for two or more paths MUST be able to include an option > > > > and sometimes you are saying what an implementation might do > > > > Section 3.5 > > For any RWA computation type request, the requester (PCC) MAY > > specify a restriction on the wavelengths to be used > > > > While I can derive a protocol requirement from the second type of=20 > > usage of 2119 language, I think I end up with something ambiguous.=20 > > For example, in the quoted text it is possible to interpret: > > > > - The solution MUST allow the requester to specify a restriction > > or > > - The solution MAY allow the requester to specify a restriction > > > > I think you need to be clearer. >=20 > [Young] Good point. I think it "MUST allow" is what is intended. >=20 > How about: >=20 > Section 3.6 >=20 > OLD: A request for two or more paths MUST be able to include an option > NEW: A request for two or more paths MUST allow the requester to=20 > include an option >=20 > Section 3.5 >=20 > OLD: For any RWA computation type request, the requester (PCC) MAY=20 > specify a restriction on the wavelengths to be used >=20 > NEW: For any RWA computation type request, the requester (PCC) MUST be=20 > allowed to specify a restriction on the wavelengths to be used > > > > --- > > > > s/requestor/requester/ >=20 > [Young] OK. Thanks. > > > > --- > > > > 3.6 > > In a network with wavelength conversion capabilities (e.g. sparse 3R > > regenerators), a request SHOULD be able to indicate whether a > > single, continuous wavelength should be allocated or not. In other > > words, the requesting PCC SHOULD be able to specify the precedence > > of wavelength continuity even if wavelength conversion is available. > > > > I don't object to the PCC being able to have input on this issue,=20 > > but it isn't clear to me how the PCC is about to know about the=20 > > network in this way. >=20 > [Young] Do you think how the PCC know about the network is in scope of=20 > discussion in this particular draft? I didn't think so. The PCC can be=20 > an NMS or > network planner that knows some networks via policy or some other=20 > supporting systems. Even in the case that the PCC is a node, this=20 > knowledge may be inferred > from its local database or some other ways. Is this a reasonable assumpti= on? >=20 > > > > --- > > > > 3.7 > > > > I believe this requirement, but not how it is worded. Isn't the=20 > > actual requirement to allow the PCC to specify the signal type at=20 > > source, at destination, and state whether transit modification is accep= table? > > > > Maybe this section is also lacking a little background information? >=20 > [Young] Yes, it is not clear as is. How about the following for Section 3= .7: >=20 > NEW: >=20 > Signal processing compatibility is an important constraint for optical=20 > path computation. The signal type for an end-to-end optical path must=20 > match at source and at destination. >=20 > The PCC MUST be allowed to specify the signal type at the endpoints=20 > (i.e., at source and at destination). The following signal processing=20 > capabilities should be > supported at a minimum: > o Modulation Type List > o FEC Type List >=20 > The PCC MUST also be allowed to state whether transit modification is acceptable > for the above signal processing capabilities. >=20 > End of NEW > > > > --- > > > > 4.6 > > > > Mechanisms defined in this document do not imply any new network > > operation requirements in addition to those already listed in > > section 8.6 of [RFC5440]. > > > > Are you sure? Are there no assumptions about the distribution of=20 > > wavelength availability information, and wavelength conversion=20 > > ability, etc.? > > > [Young] Network Operation Impacts in 8.6 of RFC 5440 deal with=20 > primarily PCEP speaker sessions and how to limit it in case of=20 > operational impacts or of this nature. The distribution of optical=20 > information you mentioned in a PCEP context is > simple adding more info just like other PCEP extensions, isn't it? >=20 > > -- > > > > I think you have an excess of boilerplate at the end of your draft. > > You can safely delete everything after the Authors' Addresses. (I=20 > > suspect your Word template thing is out of date.) >=20 > [Young] deleted. > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From nobody Mon Oct 13 11:43:32 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C206D1A883D; Mon, 13 Oct 2014 11:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuojT3Qvls2m; Mon, 13 Oct 2014 11:43:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 74A4B1A87E9; Mon, 13 Oct 2014 11:43:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141013184328.20457.4027.idtracker@ietfa.amsl.com> Date: Mon, 13 Oct 2014 11:43:28 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/d1uy6prl-0ofSULbuYGiDRBkmJs Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-wson-routing-wavelength-14.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 18:43:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : PCEP Requirements for WSON Routing and Wavelength Assignment Authors : Young Lee Greg Bernstein Jonas Martensson Tomonori Takeda Takehiro Tsuritani Oscar Gonzalez de Dios Filename : draft-ietf-pce-wson-routing-wavelength-14.txt Pages : 13 Date : 2014-10-13 Abstract: This memo provides application-specific requirements for the Path Computation Element communication Protocol (PCEP) for the support of 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. Requirements for PCEP extensions in support of optical impairments will be addressed in a separate document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-wson-routing-wavelength/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-wson-routing-wavelength-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-wson-routing-wavelength-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 13 11:46:23 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D2C1A8831 for ; Mon, 13 Oct 2014 11:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 779ed6__iuf8 for ; Mon, 13 Oct 2014 11:46:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F6BC1A8835 for ; Mon, 13 Oct 2014 11:46:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNP36853; Mon, 13 Oct 2014 18:46:07 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 13 Oct 2014 19:46:07 +0100 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0158.001; Mon, 13 Oct 2014 11:45:59 -0700 From: Leeyoung To: "pce@ietf.org" Thread-Topic: New Version Notification for draft-ietf-pce-wson-routing-wavelength-14.txt Thread-Index: AQHP5xWe+KSs95ZncUuLSrLeotx3eZwuXR+g Date: Mon, 13 Oct 2014 18:45:58 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C3D945@dfweml706-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/pce/p4H3-uc6EK_x18Tl9H9MSpFJ2w4 Cc: "afarrel@juniper.net" Subject: [Pce] FW: New Version Notification for draft-ietf-pce-wson-routing-wavelength-14.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 18:46:14 -0000 SGksIA0KDQpUaGlzIHZlcnNpb24gaXMgdG8gdXBkYXRlIHRoZSBkcmFmdCB0byByZWZsZWN0IGNv bW1lbnRzIGZyb20gQUQgKEEuIEZhcnJlbCkuIA0KDQpSZWdhcmRzLA0KWW91bmcNCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFp bHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBNb25kYXksIE9jdG9iZXIgMTMs IDIwMTQgMTo0MyBQTQ0KVG86IEdyZWcgQmVybnN0ZWluOyBPc2NhciBHb256YWxleiBkZSBEaW9z OyBUb21vbm9yaSBUYWtlZGE7IExlZXlvdW5nOyBUYWtlaGlybyBUc3VyaXRhbmk7IEpvbmFzIE1h cnRlbnNzb247IE9zY2FyIEdvbnphbGV6IGRlIERpb3M7IFRvbW9ub3JpIFRha2VkYTsgTGVleW91 bmc7IEpvbmFzIE1hcnRlbnNzb247IFRha2VoaXJvIFRzdXJpdGFuaTsgR3JlZyBCZXJuc3RlaW4N ClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1wY2Utd3Nv bi1yb3V0aW5nLXdhdmVsZW5ndGgtMTQudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRy YWZ0LWlldGYtcGNlLXdzb24tcm91dGluZy13YXZlbGVuZ3RoLTE0LnR4dA0KaGFzIGJlZW4gc3Vj Y2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBZb3VuZyBMZWUgYW5kIHBvc3RlZCB0byB0aGUgSUVURiBy ZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtaWV0Zi1wY2Utd3Nvbi1yb3V0aW5nLXdhdmVsZW5n dGgNClJldmlzaW9uOgkxNA0KVGl0bGU6CQlQQ0VQIFJlcXVpcmVtZW50cyBmb3IgV1NPTiBSb3V0 aW5nIGFuZCBXYXZlbGVuZ3RoIEFzc2lnbm1lbnQNCkRvY3VtZW50IGRhdGU6CTIwMTQtMTAtMTMN Ckdyb3VwOgkJcGNlDQpQYWdlczoJCTEzDQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1wY2Utd3Nvbi1yb3V0aW5nLXdhdmVsZW5n dGgtMTQudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1wY2Utd3Nvbi1yb3V0aW5nLXdhdmVsZW5ndGgvDQpIdG1saXplZDogICAg ICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1wY2Utd3Nvbi1yb3V0aW5n LXdhdmVsZW5ndGgtMTQNCkRpZmY6ICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2Rp ZmY/dXJsMj1kcmFmdC1pZXRmLXBjZS13c29uLXJvdXRpbmctd2F2ZWxlbmd0aC0xNA0KDQpBYnN0 cmFjdDoNCiAgIFRoaXMgbWVtbyBwcm92aWRlcyBhcHBsaWNhdGlvbi1zcGVjaWZpYyByZXF1aXJl bWVudHMgZm9yIHRoZSBQYXRoDQogICBDb21wdXRhdGlvbiBFbGVtZW50IGNvbW11bmljYXRpb24g UHJvdG9jb2wgKFBDRVApIGZvciB0aGUgc3VwcG9ydCBvZg0KICAgV2F2ZWxlbmd0aCBTd2l0Y2hl ZCBPcHRpY2FsIE5ldHdvcmtzIChXU09OKS4gTGlnaHRwYXRoIHByb3Zpc2lvbmluZw0KICAgaW4g V1NPTnMgcmVxdWlyZXMgYSByb3V0aW5nIGFuZCB3YXZlbGVuZ3RoIGFzc2lnbm1lbnQgKFJXQSkg cHJvY2Vzcy4NCiAgIEZyb20gYSBwYXRoIGNvbXB1dGF0aW9uIHBlcnNwZWN0aXZlLCB3YXZlbGVu Z3RoIGFzc2lnbm1lbnQgaXMgdGhlDQogICBwcm9jZXNzIG9mIGRldGVybWluaW5nIHdoaWNoIHdh dmVsZW5ndGggY2FuIGJlIHVzZWQgb24gZWFjaCBob3Agb2YgYQ0KICAgcGF0aCBhbmQgZm9ybXMg YW4gYWRkaXRpb25hbCByb3V0aW5nIGNvbnN0cmFpbnQgdG8gb3B0aWNhbCBsaWdodA0KICAgcGF0 aCBjb21wdXRhdGlvbi4gUmVxdWlyZW1lbnRzIGZvciBQQ0VQIGV4dGVuc2lvbnMgaW4gc3VwcG9y dCBvZg0KICAgb3B0aWNhbCBpbXBhaXJtZW50cyB3aWxsIGJlIGFkZHJlc3NlZCBpbiBhIHNlcGFy YXRlIGRvY3VtZW50Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5v dGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Yg c3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxh YmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Mon Oct 13 13:24:23 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEBF11A0022; Mon, 13 Oct 2014 13:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igwgFx64g-3M; Mon, 13 Oct 2014 13:24:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 175921A004E; Mon, 13 Oct 2014 13:24:17 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20141013202417.31262.13827.idtracker@ietfa.amsl.com> Date: Mon, 13 Oct 2014 13:24:17 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/Fnenb3IVNP9hAI7iT_N7qLgVIms Cc: pce@ietf.org Subject: [Pce] Last Call: (PCEP Requirements for WSON Routing and Wavelength Assignment) to Informational RFC X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 20:24:19 -0000 The IESG has received a request from the Path Computation Element WG (pce) to consider the following document: - 'PCEP Requirements for WSON Routing and Wavelength Assignment' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-10-27. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo provides application-specific requirements for the Path Computation Element communication Protocol (PCEP) for the support of 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. Requirements for PCEP extensions in support of optical impairments will be addressed in a separate document. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pce-wson-routing-wavelength/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pce-wson-routing-wavelength/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1400/ From nobody Thu Oct 16 11:19:28 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA6D51A1A32; Thu, 16 Oct 2014 11:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LC8OT-ROK8gV; Thu, 16 Oct 2014 11:19:18 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ACA11A0199; Thu, 16 Oct 2014 11:19:17 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s9GIJE7W021852; Thu, 16 Oct 2014 19:19:14 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s9GIJCk8021842 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 16 Oct 2014 19:19:13 +0100 From: "Adrian Farrel" To: "'CCAMP'" , , Date: Thu, 16 Oct 2014 19:19:08 +0100 Message-ID: <028e01cfe96d$ae0b58c0$0a220a40$@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: Ac/pbaw1aHsTHPmgROqdF3p2VsF9QA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21032.002 X-TM-AS-Result: No--4.904-10.0-31-10 X-imss-scan-details: No--4.904-10.0-31-10 X-TMASE-MatchedRID: +zq3ScDhdVz243bLvnYxneLdprnA5EQRz5hzQnUnsHZA9Ad+70NukwaT alM8C773f5Vqqfad4pvUWPjkMGeZuEj+bWNtFbsn2Hdvv/MGE3V9LQinZ4QefL6qvLNjDYTwfyj BJDnutUhQSFbL1bvQASdET58jp62Slph5Erpfp880NeRFKdoAXdDgke9UroWa3BQLMX8eahc1zb 8qMsqVNO6pgZ0FbrwakU7Q86IOG58YSeH4gETaLLp6OACFzbL56Hq9RCTLxvsstHmcXeW1eBVSG W4LjW40FYnPSoXfG8ckhYHVA/r8kw== Archived-At: http://mailarchive.ietf.org/arch/msg/pce/1ISSWxavbvUjyZHzwYB4Ap17-NI Cc: routing-discussion@ietf.org Subject: [Pce] Progress with forming TEAS working group X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 18:19:21 -0000 All, We have been working on a first draft of a charter for TEAS to split out "Traffic Engineering" from the current CCAMP and MPLS working groups. This will also necessitate new charters for CCAMP and MPLS, and a tiny tweak to PCE. Our plan is to get something with some rough agreement from the chairs of the various working groups and then to put it out for discussion. I hope that we will be able to assign some time in Honolulu to discuss any contentious issues that arise. However, note that the current working groups will meet a normal in Hawaii. Adrian and Alia From nobody Fri Oct 17 09:33:51 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2085D1A1B68; Fri, 17 Oct 2014 09:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SsYF27BQuzkw; Fri, 17 Oct 2014 09:33:43 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6BB61A1B94; Fri, 17 Oct 2014 09:33:43 -0700 (PDT) Received: from unnumerable.local ([173.64.248.98]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s9HGXgx6020952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 Oct 2014 11:33:42 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [173.64.248.98] claimed to be unnumerable.local Message-ID: <544144E1.9040405@nostrum.com> Date: Fri, 17 Oct 2014 11:33:37 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: General Area Review Team , pce@ietf.org, "ietf@ietf.org" , draft-ietf-pce-wson-routing-wavelenth.all@tools.ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/pce/WPX3CSk8lwnMYoF2g7rNZjL6b-k Subject: [Pce] Genart LC review: draft-ietf-pce-wson-routing-wavelength X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 16:33:49 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-pce-wson-routing-wavelength-14 Reviewer: Robert Sparks Review Date: 17-Oct-2014 IETF LC End Date: 27-Oct-2014 IESG Telechat date: not currently scheduled for any telechat Summary: Ready for publication as an Informational RFC but with nits that should be considered before publication Nits/editorial comments: There are 6 authors listed - please double-check the guidance in section 4.1.1 of RFC7322. If retaining all the authors still makes sense, please help Adrian by providing an argument that he can pass to the RFC Editor. The shepherd writeup indicates a solution ID is ready. I didn't check to see how the requirements listed here were reflected there. Would it make sense to provide a reference? (While I see no harm in publishing the document, it's not clear how doing so will be helpful if the requirements were uncontentious as the writeup implies. There are few enough of them that adding a short list in the mechanism document might be more effective.) Items 2 and 3 in section 3.4 are confusing as currently written. 2 seems to be talking about the case that the current path is still optimal. Is 3 trying to talk about the case where there is no path, not even the current path, that will work? If so the "(i.e., other than the current path)" in 3 doesn't make sense. Should you have captured a requirement that any mechanism implementing these requirements be extensible to allow for cases like polarization based multiplexing when they eventually come along? Please consider reordering the sentences in section 3.5 - the last sentence seems to be talking about the first paragraph? You say "mechanisms defined in this document" several times in section 4, but this document defines no mechanisms. From nobody Mon Oct 20 05:41:59 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F40D61A8713 for ; Mon, 20 Oct 2014 05:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AnLusLHWwIBi for ; Mon, 20 Oct 2014 05:41:54 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A01781A86E2 for ; Mon, 20 Oct 2014 05:41:53 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id AE80E22C7EA for ; Mon, 20 Oct 2014 14:41:51 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 9721C35C048 for ; Mon, 20 Oct 2014 14:41:51 +0200 (CEST) Received: from [10.193.71.69] (10.197.38.4) by PEXCVZYH01.corporate.adroot.infra.ftgroup (10.114.1.186) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 20 Oct 2014 14:41:51 +0200 Message-ID: <21573_1413808911_5445030F_21573_2393_1_5445030E.6010808@orange.com> Date: Mon, 20 Oct 2014 14:41:50 +0200 From: Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "pce@ietf.org" Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.197.38.4] X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.10.20.104221 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/oYHR_wN0wLLLo4POTyOpdhZwBvE Subject: [Pce] Building PCE Agenda for IETF 91 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Julien Meuric , 'JP Vasseur' , Daniel King List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 12:41:56 -0000 Dear PCE WG, As scheduled on the final IETF agenda (https://datatracker.ietf.org/meeting/91/agenda.html), the PCE WG will meet for a one-hour session on Monday morning in Honolulu. As a result, the agenda will be very tight. If you believe you have a presentation really requiring some face to face time to move forward, please respond to the chairs and secretary by Sunday November 2, including: - the associated I-D, - the presenter's name, - the expected duration, - the reason why you need a face to face slot. More than ever, discussion on the list will allow us to prioritize according to the community's interest. Thanks, JP & Julien _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From nobody Thu Oct 23 00:04:52 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 967931A8904; Thu, 23 Oct 2014 00:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Z3keUMHvdg5; Thu, 23 Oct 2014 00:04:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 11BE81A88D8; Thu, 23 Oct 2014 00:04:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141023070448.4879.77691.idtracker@ietfa.amsl.com> Date: Thu, 23 Oct 2014 00:04:48 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/JcSfCtp_ZixfZ3y8FYrXsmEfC7Q Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-pcep-domain-sequence-06.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 07:04:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Standard Representation Of Domain-Sequence Authors : Dhruv Dhody Udayasree Palle Ramon Casellas Filename : draft-ietf-pce-pcep-domain-sequence-06.txt Pages : 30 Date : 2014-10-22 Abstract: The ability to compute shortest constrained Traffic Engineering Label Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains has been identified as a key requirement. In this context, a domain is a collection of network elements within a common sphere of address management or path computational responsibility such as an Interior Gateway Protocol (IGP) area or an Autonomous Systems (AS). This document specifies a standard representation and encoding of a Domain-Sequence, which is defined as an ordered sequence of domains traversed to reach the destination domain to be used by Path Computation Elements (PCEs) to compute inter-domain shortest constrained paths across a predetermined sequence of domains . This document also defines new subobjects to be used to encode domain identifiers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-domain-sequence/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-pcep-domain-sequence-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-domain-sequence-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Oct 23 05:43:17 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D1241A9060 for ; Thu, 23 Oct 2014 05:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYTP8TOoZ61D for ; Thu, 23 Oct 2014 05:43:00 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D70831A9064 for ; Thu, 23 Oct 2014 05:42:59 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id y20so847112ier.12 for ; Thu, 23 Oct 2014 05:42:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=0I3aFq/3nBvub4YvtCkq6uPF5hMIsCBAMIdpy8dh/a4=; b=LUppLgxEs3By2lhDn3l9qX74iwcxMfFS/oSkV1r/Nv8jz8WAf5gzjMJnScebmapCir 7hNMBxJ8p1zcQNgzaPAN4lj/xP2h+XZBN5lVDqSuXiGjxkSysBQQhQkgLR+sdkL0soMa zXOhjytq6kXUBJBSHQ1rZZ/Qef4L8mtlfzEPPjYv1V/8mxzx9SunXWIXsc0RaPMOUa0/ QNlAbmknpnOi6P4H2inFbT4u5b3OP4yCTyPPY3DZLAakU5j3b+MQj+hST8vEmffEehFm 9eWh5H81kNwazBbIpFYfK9oxIN/N0rgousw/K+aHGtHgX+J8AJljEM2zed/8cAeQymoc ZYhQ== MIME-Version: 1.0 X-Received: by 10.42.5.72 with SMTP id 8mr9897653icv.27.1414068179250; Thu, 23 Oct 2014 05:42:59 -0700 (PDT) Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.252.42 with HTTP; Thu, 23 Oct 2014 05:42:59 -0700 (PDT) Date: Thu, 23 Oct 2014 18:12:59 +0530 X-Google-Sender-Auth: 5Z3h6P8ItP3RNSiEwasDzCFo-Bk Message-ID: From: Dhruv Dhody To: "pce@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/5y_PLFUQQw41Q10jRsiCuwvamGo Subject: [Pce] Regarding IRO Update/Survey & Domain-Sequence X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 12:43:09 -0000 WG, (1) IRO Specification Update: http://tools.ietf.org/html/draft-dhody-pce-iro-update-00 This document updates RFC5440 IRO Specification making IRO as an ordered list as well as support for loose bit (L-bit) based on the IRO Survey conclusion. Abstract: During discussions of a document to provide a standard representation and encoding of Domain-Sequence within the Path Computation Element (PCE) communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. It was determined that there was a need for clarification with respect to the ordered nature of the Include Route Object (IRO). An informal survey was conducted to determine the state of current and planned implementation with respect to IRO ordering and handling of Loose bit. This document updates the IRO specification based on the survey conclusion and recommendation. (2) IRO Survey: http://tools.ietf.org/html/draft-dhody-pce-iro-survey-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-dhody-pce-iro-survey-01 - updated with the reference to above document. (3) Domain Sequence http://tools.ietf.org/html/draft-ietf-pce-pcep-domain-sequence-06 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-domain-sequence-06 - removed IRO options and comparison - uses updated IRO specification Any feedback on the set of documents are most welcome. Hoping we can make progress on these document quickly. Regards, Dhruv From nobody Fri Oct 24 14:49:53 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2861A8AD9 for ; Fri, 24 Oct 2014 14:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKJq771KaMk4 for ; Fri, 24 Oct 2014 14:49:48 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45C811A06FD for ; Fri, 24 Oct 2014 14:49:48 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKX35448; Fri, 24 Oct 2014 21:49:47 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 24 Oct 2014 22:49:46 +0100 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml702-chm ([10.193.5.72]) with mapi id 14.03.0158.001; Fri, 24 Oct 2014 14:49:41 -0700 From: Leeyoung To: "pce@ietf.org" Thread-Topic: New Version Notification for draft-lee-pce-transporting-te-data-01.txt Thread-Index: AQHP79PPS3PvM2az2UGGTF6B+jjW3pw/yDOw Date: Fri, 24 Oct 2014 21:49:41 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C40668@dfweml706-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.135.123] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/pce/PZkowwdOMQGWDRl6n4cQ3ygM0gU Subject: [Pce] FW: New Version Notification for draft-lee-pce-transporting-te-data-01.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 21:49:50 -0000 SGksDQoNClRoaXMgaXMgdG8gdXBkYXRlIHRoZSBmcmFtZXdvcmsgZHJhZnQgdGhhdCBkaXNjdXNz ZWQgUENFIFRyYW5zcG9ydGluZyBvZiBURSBkYXRhLiBUaGlzIGlzIHRoZSBiYXNlIGRyYWZ0IHRv IHdoYXQgRGhydXYgcHVibGlzaGVkIGVhcmx5IG9uLiANCg0KV2UgdXBkYXRlZDoNCi0gYXBwbGlj YWJpbGl0eSBtb3JlIGNsZWFybHkNCi0gYWRkZWQgYSByZWZlcmVuY2UgdGhhdCBtb3RpdmF0ZWQg dGhpcyBkcmFmdC4gDQotIGxpbmtlZCB3aXRoIHRoZSBzb2x1dGlvbiBkcmFmdCwgW2RyYWZ0LWRo b2R5bGVlLXBjZS1wY2VwLXRlLWRhdGEtZXh0bl0uIA0KDQpZb3VyIGNvbW1lbnRzIGFyZSB3ZWxj b21lLiANCg0KQmVzdCByZWdhcmRzLA0KWW91bmcNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZ10gDQpTZW50OiBGcmlkYXksIE9jdG9iZXIgMjQsIDIwMTQgNDo0NSBQTQ0KVG86 IFpoZW5naGFvbWlhbjsgWmhlbmdoYW9taWFuOyBMZWV5b3VuZzsgTGVleW91bmcNClN1YmplY3Q6 IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGVlLXBjZS10cmFuc3BvcnRpbmct dGUtZGF0YS0wMS50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbGVlLXBjZS10 cmFuc3BvcnRpbmctdGUtZGF0YS0wMS50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0 ZWQgYnkgWW91bmcgTGVlIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFt ZToJCWRyYWZ0LWxlZS1wY2UtdHJhbnNwb3J0aW5nLXRlLWRhdGENClJldmlzaW9uOgkwMQ0KVGl0 bGU6CQlQQ0UgaW4gU3VwcG9ydCBvZiBUcmFuc3BvcnRpbmcgVHJhZmZpYyBFbmdpbmVlcmluZyBE YXRhDQpEb2N1bWVudCBkYXRlOgkyMDE0LTEwLTI0DQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlz c2lvbg0KUGFnZXM6CQkyMA0KVVJMOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LWxlZS1wY2UtdHJhbnNwb3J0aW5nLXRlLWRhdGEtMDEudHh0DQpT dGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbGVl LXBjZS10cmFuc3BvcnRpbmctdGUtZGF0YS8NCkh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1sZWUtcGNlLXRyYW5zcG9ydGluZy10ZS1kYXRhLTAxDQpEaWZm OiAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtbGVlLXBj ZS10cmFuc3BvcnRpbmctdGUtZGF0YS0wMQ0KDQpBYnN0cmFjdDoNCiAgIEluIG9yZGVyIHRvIGNv bXB1dGUgYW5kIHByb3ZpZGUgb3B0aW1hbCBwYXRocywgUGF0aCBDb21wdXRhdGlvbg0KICAgRWxl bWVudHMgKFBDRXMpIHJlcXVpcmUgYW4gYWNjdXJhdGUgYW5kIHRpbWVseSBUcmFmZmljIEVuZ2lu ZWVyaW5nDQogICBEYXRhYmFzZSAoVEVEKS4gVHJhZGl0aW9uYWxseSB0aGlzIFRFRCBoYXMgYmVl biBvYnRhaW5lZCBmcm9tIGEgbGluaw0KICAgc3RhdGUgcm91dGluZyBwcm90b2NvbCBzdXBwb3J0 aW5nIHRyYWZmaWMgZW5naW5lZXJpbmcgZXh0ZW5zaW9ucy4NCiAgIFRoaXMgZG9jdW1lbnQgZGlz Y3Vzc2VzIHBvc3NpYmxlIGFsdGVybmF0aXZlcyBhbmQgZW5oYW5jZW1lbnRzIHRvDQogICB0aGUg ZXhpc3RpbmcgYXBwcm9hY2ggdG8gVEVEIGNyZWF0aW9uLiBUaGlzIGRvY3VtZW50IGdpdmVzDQog ICBhcmNoaXRlY3R1cmFsIGFsdGVybmF0aXZlcyBmb3IgdGhlc2UgYWx0ZXJuYXRpdmVzIGFuZCB0 aGVpcg0KICAgcG90ZW50aWFsIGltcGFjdHMgb24gbmV0d29yayBub2Rlcywgcm91dGluZyBwcm90 b2NvbHMsIGFuZCBQQ0VQLg0KDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBs ZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0 aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJl IGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Fri Oct 24 14:58:30 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B15D1A906B; Fri, 24 Oct 2014 14:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63I8ti1dLrC1; Fri, 24 Oct 2014 14:58:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BAF911A06FD; Fri, 24 Oct 2014 14:58:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141024215825.2162.5789.idtracker@ietfa.amsl.com> Date: Fri, 24 Oct 2014 14:58:25 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/n2Ja6HQYCLuB5eXIaUO0g2uBUU8 Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-pcep-mib-11.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 21:58:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Path Computation Element Communications Protocol (PCEP) Management Information Base (MIB) Module Authors : Agrahara Kiran Koushik Emile Stephan Quintin Zhao Daniel King Jonathan Hardwick Filename : draft-ietf-pce-pcep-mib-11.txt Pages : 64 Date : 2014-10-24 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Path Computation Element communications Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-mib/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-pcep-mib-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-mib-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Oct 24 15:02:09 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF241A870D for ; Fri, 24 Oct 2014 15:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxpS60mOTFbu for ; Fri, 24 Oct 2014 15:02:00 -0700 (PDT) Received: from ENFICSETS1.metaswitch.com (enficsets1.metaswitch.com [192.91.191.38]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59EB81A040B for ; Fri, 24 Oct 2014 15:02:00 -0700 (PDT) Received: from ENFIRHMBX1.datcon.co.uk (172.18.74.36) by ENFICSETS1.metaswitch.com (172.18.4.18) with Microsoft SMTP Server (TLS) id 14.3.210.2; Fri, 24 Oct 2014 23:01:54 +0100 Received: from ENFICSMBX1.datcon.co.uk ([fe80::d5d5:c683:a3be:3a19]) by ENFIRHMBX1.datcon.co.uk ([fe80::b06d:4d13:5f63:3715%12]) with mapi id 14.03.0195.001; Fri, 24 Oct 2014 23:01:58 +0100 From: Jonathan Hardwick To: "pce@ietf.org" , "adrian@olddog.co.uk" , "julien.meuric@orange.com" , "JP Vasseur (jvasseur)" Thread-Topic: [Pce] I-D Action: draft-ietf-pce-pcep-mib-11.txt Thread-Index: AQHP79Wp7aXnc6k5a0y5+RAzHITjAZw/y/1w Date: Fri, 24 Oct 2014 22:01:58 +0000 Message-ID: <09CE6C3BE5E1EA40B987BF5F25D8DDBAFDCFEF1F@ENFICSMBX1.datcon.co.uk> References: <20141024215825.2162.5789.idtracker@ietfa.amsl.com> In-Reply-To: <20141024215825.2162.5789.idtracker@ietfa.amsl.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.10.155] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/QF6LsxDCmrX0n7feE0Y_QcYx1Fs Subject: Re: [Pce] I-D Action: draft-ietf-pce-pcep-mib-11.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 22:02:06 -0000 All Here is a new version of the PCEP MIB which addresses comments that we rece= ived from the security area directorate. The change updates the wording in= the security section of the document to use the precise wording from the b= oilerplate at http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security. Regards Jon -----Original Message----- From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.o= rg Sent: 24 October 2014 22:58 To: i-d-announce@ietf.org Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-pcep-mib-11.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Path Computation Element Working Group of= the IETF. Title : Path Computation Element Communications Protocol = (PCEP) Management Information Base (MIB) Module Authors : Agrahara Kiran Koushik Emile Stephan Quintin Zhao Daniel King Jonathan Hardwick Filename : draft-ietf-pce-pcep-mib-11.txt Pages : 64 Date : 2014-10-24 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Path Computation Element communications Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-mib/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-pcep-mib-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pce-pcep-mib-11 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From nobody Fri Oct 24 23:05:15 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED47A1A6FB5 for ; Fri, 24 Oct 2014 23:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uayGC0MPZ4NA for ; Fri, 24 Oct 2014 23:05:02 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 572D51A6F99 for ; Fri, 24 Oct 2014 23:05:02 -0700 (PDT) Received: by mail-ig0-f177.google.com with SMTP id a13so1558114igq.4 for ; Fri, 24 Oct 2014 23:05:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=90bTPOovXZfDXZ1ZQaVqzv9QguFDQ/JAACTFUGFnxt0=; b=OH3n/wfV6a4KJ+fIWI6dwem5O+xKsE+puD8f55rsPC+Y+af67TpHT1ANkUGT//xVbh wjwhszrxF0cNAZMiWHylVZPHUbcZ3q+RLQomwmW4sGfM+whjkdSDsnajKrznWkCD/3ri Qqx8IeKVuHSnaMC85RwdaMCG+v0chuMLD26pa2Q9SWLRvPUj2RnzG8Fcam6NrLdooh5Y N5uzp9uT+ozzopY4QpD1VQwAPMtlEG6v4EQ2BG89vQoWafUiSNlvFLwVQRBs+BrY98ZO Ko1kATWkxb9aiZ+8a/sb6RP+Q2vSnwW+yXo84zpNlX2/wQoJkupgafvkd4J9w+ws/uj5 oJ1Q== MIME-Version: 1.0 X-Received: by 10.42.5.72 with SMTP id 8mr7205678icv.27.1414217101713; Fri, 24 Oct 2014 23:05:01 -0700 (PDT) Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.252.42 with HTTP; Fri, 24 Oct 2014 23:05:01 -0700 (PDT) In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C404E9@dfweml706-chm> References: <20141024172205.9688.5081.idtracker@ietfa.amsl.com> <7AEB3D6833318045B4AE71C2C87E8E1729C404E9@dfweml706-chm> Date: Sat, 25 Oct 2014 11:35:01 +0530 X-Google-Sender-Auth: GfMEvi25vYBlTDKNykPpwWfYL2g Message-ID: From: Dhruv Dhody To: "pce@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/g81jhzx0B64tTJL5loBg9wDvwMI Subject: [Pce] Fwd: New Version Notification for draft-dhodylee-pce-pcep-te-data-extn-00.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Oct 2014 06:05:08 -0000 This mail from Young never made it to the list, thus forwarding! ---------- Forwarded message ---------- From: Leeyoung Date: Sat, Oct 25, 2014 at 12:45 AM Subject: RE: New Version Notification for draft-dhodylee-pce-pcep-te-data-extn-00.txt To: "internet-drafts@ietf.org" , Dhruv Dhody Hi, This draft is written to get the protocol extension details as a follow-up with the informational draft ([I-D.lee-pce-transporting-te-data]) presented and received a considerable interest expressed in the mailing list in Toronto meeting. Your comments will be appreciated. Best Regards, Young and Dhruv -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Friday, October 24, 2014 12:22 PM To: Leeyoung; Dhruv Dhody; Leeyoung; Dhruv Dhody Subject: New Version Notification for draft-dhodylee-pce-pcep-te-data-extn-00.txt A new version of I-D, draft-dhodylee-pce-pcep-te-data-extn-00.txt has been successfully submitted by Dhruv Dhody and posted to the IETF repository. Name: draft-dhodylee-pce-pcep-te-data-extn Revision: 00 Title: PCEP Extension for Transporting TE Data Document date: 2014-10-24 Group: Individual Submission Pages: 23 URL: http://www.ietf.org/internet-drafts/draft-dhodylee-pce-pcep-te-data-extn-00.txt Status: https://datatracker.ietf.org/doc/draft-dhodylee-pce-pcep-te-data-extn/ Htmlized: http://tools.ietf.org/html/draft-dhodylee-pce-pcep-te-data-extn-00 Abstract: In order to compute and provide optimal paths, Path Computation Elements (PCEs) require an accurate and timely Traffic Engineering Database (TED). Traditionally this TED has been obtained from a link state routing protocol supporting traffic engineering extensions. This document extends the Path Computation Element Communication Protocol (PCEP) with TED population capability. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Sat Oct 25 22:14:07 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6AAE1A6F47; Sat, 25 Oct 2014 22:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HG6ycOMpJmj4; Sat, 25 Oct 2014 22:13:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A4DD71A6F28; Sat, 25 Oct 2014 22:13:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141026051357.28355.64059.idtracker@ietfa.amsl.com> Date: Sat, 25 Oct 2014 22:13:57 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/gi9rESTnpGxVaPo6WgM4lraqcvw Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-stateful-pce-app-03.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 05:14:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Applicability of a Stateful Path Computation Element (PCE) Authors : Xian Zhang Ina Minei Filename : draft-ietf-pce-stateful-pce-app-03.txt Pages : 24 Date : 2014-10-25 Abstract: A stateful Path Computation Element (PCE) maintains information about Label Switched Path (LSP) characteristics and resource usage within a network in order to provide traffic engineering calculations for its associated Path Computation Clients (PCCs). This document describes general considerations for a stateful PCE deployment and examines its applicability and benefits, as well as its challenges and limitations through a number of use cases. PCE Communication Protocol (PCEP) extensions required for stateful PCE usage are covered in separate documents. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-app/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-app-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-stateful-pce-app-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Oct 25 23:38:42 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 003E61A6FDB; Sat, 25 Oct 2014 23:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8wtScuG4Evv; Sat, 25 Oct 2014 23:38:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A401A6F62; Sat, 25 Oct 2014 23:38:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141026063835.17974.33365.idtracker@ietfa.amsl.com> Date: Sat, 25 Oct 2014 23:38:35 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/ZFO7eQ_TqZ88pB3rFVMWYHxaywk Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-pce-initiated-lsp-02.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 06:38:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model Authors : Edward Crabbe Ina Minei Siva Sivabalan Robert Varga Filename : draft-ietf-pce-pce-initiated-lsp-02.txt Pages : 16 Date : 2014-10-25 Abstract: The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. The extensions for stateful PCE provide stateful control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSP) via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. This document describes the creation and deletion of PCE-initiated LSPs under the stateful PCE model. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-pce-initiated-lsp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-pce-initiated-lsp-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pce-initiated-lsp-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Oct 25 23:52:21 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C39351A6FD3 for ; Sat, 25 Oct 2014 23:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QDfLcd__wip5 for ; Sat, 25 Oct 2014 23:52:15 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B52091A6FDE for ; Sat, 25 Oct 2014 23:52:15 -0700 (PDT) Received: by mail-ig0-f170.google.com with SMTP id hn18so3552843igb.3 for ; Sat, 25 Oct 2014 23:52:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=1eVKLAouNb6UDtj7FYQcuyMLre7CqbAUVQWVbrG2cUA=; b=IEtAqBFTfZ8OS5nnqd9VVKsBjw/yAIEi3pp9ogK7zoqp1g4xac2lxMy5SMfNigxJii Eamkzg2j39f5kEsbcI/TWLhyg2Kwg40cpiu9BFa43ysFQzu0cVIr5moTHG5fSRIDj/J5 uSO7oLrupRHyj0ohNJsik+A0g8HCxZdn5hsuEpS7tiPwe2ghL7C+pRyZQWAA6abYatsW xky4aw+sjUPQvdz4JcmQzA9Xn/3Spq6n1BFAACdMZBtWs7ItLhMHT3Fol/7TQ2a5Yg7P R6FUOtsGkyRaSGRNs7ca/kkWJ2NbZ6FV9AhAavt7/vFjvK0aNc4y7EemIVi89KFodyKI uuVg== MIME-Version: 1.0 X-Received: by 10.50.119.195 with SMTP id kw3mr14067029igb.5.1414306334895; Sat, 25 Oct 2014 23:52:14 -0700 (PDT) Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.252.42 with HTTP; Sat, 25 Oct 2014 23:52:14 -0700 (PDT) In-Reply-To: <20141026061852.17991.88.idtracker@ietfa.amsl.com> References: <20141026061852.17991.88.idtracker@ietfa.amsl.com> Date: Sun, 26 Oct 2014 12:22:14 +0530 X-Google-Sender-Auth: s6SQA2KJhev0AUlKdKoUuYJjcm0 Message-ID: From: Dhruv Dhody To: "pce@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/h7pKscZdS7Yz_xc53VdN2gi7gJ4 Subject: [Pce] Fwd: New Version Notification for draft-pkd-pce-pcep-yang-01.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 06:52:18 -0000 Hi WG, Here is an update to YANG module with - - Notifications - 'must' conditional statements for leafs Checkout the diff at: http://www.ietf.org/rfcdiff?url2=draft-pkd-pce-pcep-yang-01 We would be further working on augmenting this YANG module with advanced features. Any suggestions/feedback/call-for-collaborations are most welcome. We also have the working copy at Git where you can find the next version as we keep working on it: https://github.com/DhruvDhody/pcep-yang/tree/working Dhruv ---------- Forwarded message ---------- From: Date: Sun, Oct 26, 2014 at 11:48 AM Subject: New Version Notification for draft-pkd-pce-pcep-yang-01.txt To: Rohit Pobbathi , Vinod KumarS , Jonathan Hardwick , Dhruv Dhody A new version of I-D, draft-pkd-pce-pcep-yang-01.txt has been successfully submitted by Dhruv Dhody and posted to the IETF repository. Name: draft-pkd-pce-pcep-yang Revision: 01 Title: A YANG Data Model for Path Computation Element Communications Protocol (PCEP) Document date: 2014-10-25 Group: Individual Submission Pages: 52 URL: http://www.ietf.org/internet-drafts/draft-pkd-pce-pcep-yang-01.txt Status: https://datatracker.ietf.org/doc/draft-pkd-pce-pcep-yang/ Htmlized: http://tools.ietf.org/html/draft-pkd-pce-pcep-yang-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-pkd-pce-pcep-yang-01 Abstract: This document defines a YANG data model for the management of Path Computation Element communications Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs. The data model includes configuration data and state data (status information and counters for the collection of statistics). Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Sun Oct 26 01:26:15 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34F5F1A6FFA for ; Sun, 26 Oct 2014 01:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IzewllCCeoPE for ; Sun, 26 Oct 2014 01:26:10 -0700 (PDT) Received: from torres.puc.rediris.es (torres.puc.rediris.es [IPv6:2001:720:418:ca00::9]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7932C1A6FF8 for ; Sun, 26 Oct 2014 01:26:10 -0700 (PDT) Received: from [2001:40b0:7c22:6020:c88:9c8e:a5:f3a] (helo=leo) by torres.puc.rediris.es with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1XiJ9G-0004bj-5i for pce@ietf.org; Sun, 26 Oct 2014 09:26:07 +0100 Received: from [192.168.1.200] (81.61.170.108.dyn.user.ono.com [81.61.170.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by leo (Postfix) with ESMTPSA id 9D3021FE49 for ; Sun, 26 Oct 2014 09:26:00 +0100 (CET) X-Envelope-From: ramon.casellas@cttc.es Message-ID: <544CB012.4090409@cttc.es> Date: Sun, 26 Oct 2014 09:25:54 +0100 From: Ramon Casellas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "pce@ietf.org" References: <20141026081818.13196.37684.idtracker@ietfa.amsl.com> In-Reply-To: <20141026081818.13196.37684.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20141026081818.13196.37684.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamina-Bogosity: Unsure X-Spamina-Spam-Score: -0.2 (/) X-Spamina-Spam-Report: Content analysis details: (-0.2 points) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: ietf.org] 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4999] Archived-At: http://mailarchive.ietf.org/arch/msg/pce/8jBkFmIY6rUzCnGHBTfCdivzl3I Subject: [Pce] Fwd: New Version Notification for draft-many-pce-pcep-bcp-01.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 08:26:13 -0000 Dear WG, We have just uploaded a new version of draft-many-pce-pcep-bcp-01.txt, focusing on the attributes and path constructs. For the diff between -00 and -01 please check http://www.ietf.org/rfcdiff?url2=draft-many-pce-pcep-bcp Feedback, specially from additional implementations, is more than welcome. Thanks Ramon on behalf of the authors ---------------- A new version of I-D, draft-many-pce-pcep-bcp-01.txt has been successfully submitted by Ramon Casellas and posted to the IETF repository. Name: draft-many-pce-pcep-bcp Revision: 01 Title: PCEP Best Current Practices - Message formats and extensions Document date: 2014-10-23 Group: Individual Submission Pages: 21 URL: http://www.ietf.org/internet-drafts/draft-many-pce-pcep-bcp-01.txt Status: https://datatracker.ietf.org/doc/draft-many-pce-pcep-bcp/ Htmlized: http://tools.ietf.org/html/draft-many-pce-pcep-bcp-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-many-pce-pcep-bcp-01 Abstract: A core standards track RFC defines the main underlying mechanisms, basic object format and message structure of the Path Computation Element (PCE) Communications Protocol (PCEP). PCEP has been later extended in several RFCs, focusing on specific functionalities. The proliferation of such companion RFCs may cause ambiguity when implementing a PCE based solution. This document aims at documenting best current practices and at providing a reference RBNF grammar for PCEP messages, including object ordering and precedence rules. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Sun Oct 26 19:16:35 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23E241A3B9E for ; Sun, 26 Oct 2014 19:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1NFxUuxlvJF for ; Sun, 26 Oct 2014 19:16:31 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C4581A1BFB for ; Sun, 26 Oct 2014 19:16:30 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKY65384; Mon, 27 Oct 2014 02:16:29 +0000 (GMT) Received: from SZXEMA401-HUB.china.huawei.com (10.82.72.33) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 27 Oct 2014 02:16:29 +0000 Received: from SZXEMA504-MBX.china.huawei.com ([169.254.7.19]) by SZXEMA401-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0158.001; Mon, 27 Oct 2014 10:16:23 +0800 From: Zhenghaomian To: "pce@ietf.org" Thread-Topic: New Version Notification for draft-zhang-pce-resource-sharing-02.txt Thread-Index: AQHP8CTPi2PQ+X7uhkm6gfh58sdrbJxDJ+Fg Date: Mon, 27 Oct 2014 02:16:23 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.53.113] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/pce/aTgyfsXPTkUdEbctpYeXTUztVLI Subject: [Pce] =?utf-8?b?6L2s5Y+ROiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y?= =?utf-8?q?_draft-zhang-pce-resource-sharing-02=2Etxt?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 02:16:33 -0000 SGksIA0KDQpUaGlzIGRyYWZ0IGlzIHVwZGF0ZWQgYmFzZWQgb24gYSBmZXcgb2ZmbGluZSBjb21t ZW50cywgYmFzaWNhbGx5IGZvbGxvd2luZyBjaGFuZ2VzIGludm9sdmVkOg0KDQotIERlc2NyaXB0 aW9uIG9mIEZpZ3VyZSAyIGlzIHVwZGF0ZWQgdG8gY29ycmVjdCB0aGUgUENFIG5vdGF0aW9uOw0K LSBTb21lIGVkaXRvcmlhbCBjaGFuZ2VzIGluIGludHJvZHVjdGlvbiBzZXNzaW9uIHRvIGJldHRl ciBjbGFyaWZ5IHRoZSBpbnRlcnJ1cHRpb24gZHVyaW5nIHRoZSByZS1yb3V0aW5nIHByb2NlZHVy ZTsNCi0gUlNPIG9iamVjdCBhc3NvY2lhdGVkICdiYW5kd2lkdGgnIGlzIHJlbW92ZWQsIGR1ZSB0 byB0aGUgUENSZXEgc2hvdWxkIGFscmVhZHkgcmVxdWVzdCBmb3IgdGhlIGJhbmR3aWR0aCBpbmZv cm1hdGlvbiwgbm8gbmVlZCBmb3IgcmVkdW5kYW5jeTsgDQotIFNlY3Rpb24gNS4yIHJlbmFtZWQg YXMgJ1JTTyBmbGFnIGZpZWxkcycgaW5zdGVhZCBvZiAnUlNPIGNvZGVzJywgZGVmaW5pbmcgdGhl IGZsYWdzIGRpc2N1c3NlZCBpbiBwcmV2aW91cyBzZXNzaW9uLg0KDQpQbGVhc2UgbGV0IG1lIGtu b3cgaWYgeW91IGhhdmUgYW55IGZ1cnRoZXIgY29tbWVudHMgb24gdGhlIHVwZGF0ZWQgZHJhZnQs IHRoYW5rcyBhIGxvdC4NCg0KQmVzdCB3aXNoZXMsDQpIYW9taWFuDQoNCi0tLS0t6YKu5Lu25Y6f 5Lu2LS0tLS0NCuWPkeS7tuS6ujogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANCuWPkemAgeaXtumXtDogMjAxNOW5tDEw5pyIMjXml6Ug MTU6MjUNCuaUtuS7tuS6ujogT3NjYXIgR29uemFsZXogZGUgRGlvczsgWmhlbmdoYW9taWFuOyBW aWN0b3IgTG9wZXo7IFpoYW5neGlhbiAoWGlhbik7IFpoYW5neGlhbiAoWGlhbik7IE9zY2FyIEdv bnphbGV6IGRlIERpb3M7IFZpY3RvciBMb3BlejsgWmhlbmdoYW9taWFuDQrkuLvpopg6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtemhhbmctcGNlLXJlc291cmNlLXNoYXJpbmct MDIudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXpoYW5nLXBjZS1yZXNvdXJj ZS1zaGFyaW5nLTAyLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBIYW9t aWFuIFpoZW5nIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRy YWZ0LXpoYW5nLXBjZS1yZXNvdXJjZS1zaGFyaW5nDQpSZXZpc2lvbjoJMDINClRpdGxlOgkJRXh0 ZW5zaW9ucyB0byBQYXRoIENvbXB1dGF0aW9uIEVsZW1lbnQgUHJvdG9jb2wgKFBDRVApIHRvIFN1 cHBvcnQgUmVzb3VyY2UgU2hhcmluZy1iYXNlZCBQYXRoIENvbXB1dGF0aW9uDQpEb2N1bWVudCBk YXRlOgkyMDE0LTEwLTI1DQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkx Mw0KVVJMOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LXpoYW5nLXBjZS1yZXNvdXJjZS1zaGFyaW5nLTAyLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXpoYW5nLXBjZS1yZXNvdXJjZS1z aGFyaW5nLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LXpoYW5nLXBjZS1yZXNvdXJjZS1zaGFyaW5nLTAyDQpEaWZmOiAgICAgICAgICAgaHR0cDovL3d3 dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtemhhbmctcGNlLXJlc291cmNlLXNoYXJpbmct MDINCg0KQWJzdHJhY3Q6DQogICBSZXNvdXJjZSBzaGFyaW5nIGluIGEgbmV0d29yayBtZWFucyB0 d28gb3IgbW9yZSBMYWJlbCBTd2l0Y2hlZCBQYXRocw0KICAgKExTUHMpIHVzZSBjb21tb24gcGll Y2Uocykgb2YgcmVzb3VyY2UgYWxvbmcgdGhlaXIgcGF0aHMuIFRoaXMgY2FuDQogICBoZWxwIHNh dmUgbmV0d29yayByZXNvdXJjZSBhbmQgdXNlZnVsIGluIHNjZW5hcmlvcyBzdWNoIGFzIExTUA0K ICAgcmVjb3Zlcnkgb3Igd2hlbiB0d28gTFNQcyBkbyBub3QgbmVlZCB0byBiZSBhY3RpdmUgYXQg dGhlIHNhbWUgdGltZS4NCiAgIEEgUGF0aCBDb21wdXRhdGlvbiBFbGVtZW50IChQQ0UpIGlzIGEg Y2VudHJhbGl6ZWQgZW50aXR5LA0KICAgcmVzcG9uc2libGUgZm9yIHBhdGggY29tcHV0YXRpb24u IEdpdmVuIHRoaXMgZmVhdHVyZSBhbmQgaXRzIGFjY2Vzcw0KICAgdG8gdGhlIG5ldHdvcmsgcmVz b3VyY2UgaW5mb3JtYXRpb24gYW5kIHBvc3NpYmx5IGFjdGl2ZSBMU1BzDQogICBpbmZvcm1hdGlv biwgaXQgY2FuIGJlIHVzZWQgdG8gc3VwcG9ydCByZXNvdXJjZS1zaGFyaW5nLWJhc2VkIHBhdGgN CiAgIGNvbXB1dGF0aW9uIHdpdGggYmV0dGVyIGVmZmljaWVuY3kuDQoNCiAgIFRoaXMgZG9jdW1l bnQgZXh0ZW5kcyB0aGUgUGF0aCBDb21wdXRhdGlvbiBFbGVtZW50IFByb3RvY29sIChQQ0VQKQ0K ICAgaW4gb3JkZXIgdG8gc3VwcG9ydCByZXNvdXJjZSBzaGFyaW5nLWJhc2VkIHBhdGggY29tcHV0 YXRpb24uDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0 IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNz aW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQg dG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Sun Oct 26 21:36:10 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA4A1A6F41 for ; Sun, 26 Oct 2014 21:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsMcy8DBpcKz for ; Sun, 26 Oct 2014 21:36:07 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFF781A1BBE for ; Sun, 26 Oct 2014 21:36:06 -0700 (PDT) Received: by mail-oi0-f48.google.com with SMTP id x69so1286777oia.35 for ; Sun, 26 Oct 2014 21:36:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=TKdAQIOM6CBTEOtBSUDHzl4lpEaFm+CeetLf+Ab48hY=; b=SpDNvOAzADMORY11qe9R+k6qd8Ok+HSdUzLvhBVot3DSRPP20t66WNnroXy70EhSjg s3LsAdeQvuom7LLSIaPK7J/azx+ouuPJ/8aqQIxlJ2uZBLm592+F4uKbCJb5evbU1yzo 1+4n3lYYueN8saI24KRd3Vs8NZpqjq4XcMPj3/YBKQ9/ngwHMZ9yeRM7Rl6uLd6aE/D9 CzPv8Y055mhVetyusnL782c97t/nP8Eb64UUF4Dar/1I13r5uIHL6zNFSdfvL/IDRGJD vUR4c+HS1N2i65RHQhQP61gHFC3DxuJIEB4fNHohLfu/t+9N6QBvCRguGR86arBaOE0s miBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=TKdAQIOM6CBTEOtBSUDHzl4lpEaFm+CeetLf+Ab48hY=; b=mAKSH2Gk7Bu9jE8nibtA2DL73EQTn+CGigvCAYTg0VRePE6WFJijeWuGs2KPpUh9MM jBcBn5gQh9iL/PPXuK/KQOpZlbPsaL22DsswzZ+B0YEhfhYbSesoc/PKXhzfL/8crzol IQe8LZZ9QO48Xy/+JVloNsh2w4hp+Qcw3KD/2p6f5COOJVGvelmXRQbZEBwAIc5kk7+g DqfvRih0S9aNBsDQ5yXHzos/i59F2irVjZDnTDf2SODfZCLibp5uXIpBjYVJ1xZAdmY1 M9kPrnz65mtA8jlKcseCL+BN8AVpEWnbZCrpXX9iXk1fQ3hcXjj9471vHkG3XrA+uB9e eSLQ== X-Gm-Message-State: ALoCoQmbm58LfQakrQ/ywB1jXuWJm/LGF8exZxNUg7dnfy7XZXLSPNrlXaXac9o5MnDa2cldBBrx MIME-Version: 1.0 X-Received: by 10.182.245.225 with SMTP id xr1mr18522016obc.13.1414384564388; Sun, 26 Oct 2014 21:36:04 -0700 (PDT) Received: by 10.182.23.41 with HTTP; Sun, 26 Oct 2014 21:36:04 -0700 (PDT) In-Reply-To: References: Date: Sun, 26 Oct 2014 21:36:04 -0700 Message-ID: From: Ina Minei To: Dhruv Dhody , pce , JP Vasseur Content-Type: multipart/alternative; boundary=001a11c1c9708965cc05066011fb Archived-At: http://mailarchive.ietf.org/arch/msg/pce/0aTSVba10H9lwjiUzslZSghPLIk Subject: Re: [Pce] WG Last Call on draft-ietf-pce-stateful-pce-app-02 and draft-ietf-pce-stateful-pce-09 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 04:36:08 -0000 --001a11c1c9708965cc05066011fb Content-Type: text/plain; charset=UTF-8 Dhruv, Thank you for the careful review. Please find inline below, ###. > > - RFC2119 keywords requirement language should be added as subsection > in introduction. > > ### This section was already included in the draft, just below the abstract. I moved it to the introduction > 1.1 Requirements Language > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [RFC2119]. > > - In sec 3.2. Objectives > OLD: > Allow a PCC to delegate control of its LSPs to an active stateful > PCE such that a single LSP is under the control a single PCE at > any given time. > NEW: > Allow a PCC to delegate control of its LSPs to an active stateful > PCE such that a LSP is under the control a single PCE at > any given time. > The current text gives an impression that only one LSP (a single LSP) > is under control of a PCE. > ### Yes, I replaced to "a given LSP is under the control of a single PCE at any given time". > > - In sec 5.4. State Synchronization, for figure 2 and 3 'PCErr=?' is > used, I suggest either to put the error type/code or remove '=?'. > ### done > > - Update reference for minei-pce-stateful-sync-optimizations to > ietf-pce-stateful-sync-optimizations > ### done > > - I am not sure what is the correct way to put comments inside RBNF, > or better yet they should simply be avoided. In section 6.3, 6.4 and > 6.5 "<<<<" and "<---" are used. > ### removed > > - The alignment for the byte markers is incorrect in figure 10 > ###fixed > > - In sec 7.3.2. Symbolic Path Name TLV, can the following text be added? > > The Symbolic Path Name is padded to 4-bytes alignment; padding > itself is not included in the Length field. > ### No, I think this is a disruptive change for implementations that already handle the variable length of this TLV. Doing what you propose would break the parsing code. > > - In sec 7.3.3. LSP Error Code TLV, we should say - "The following LSP > Error Codes are *currently* defined:"; so that future documents can > easily extend it. > ### ok > > - In 9.6. Impact on Network Operation s/PcE/PCE > > ###ok > - ietf-pce-gmpls-pcep-extensions can be removed as a normative reference. > > ###ok > - there are bunch of idnits that you may wish to handle (see attached) > > -------- > > Dhruv > > > On Sun, Sep 14, 2014 at 3:42 PM, JP Vasseur (jvasseur) > wrote: > > Dear WG, > > > > Both draft-ietf-pce-stateful-pce-app-02 and > draft-ietf-pce-stateful-pce-09 > > are now stable ready for WG Last Call. > > This starts a 3-week WG Last call, which will end on Oct 6 at noon ET. > > > > Please send your comments on the mailing list. > > > > ps: this WG LC will be followed by another WG LC on > > draft-ietf-pce-stateful-sync-optimizations-01 > > and draft-ietf-pce-pce-initiated-lsp-01. > > > > > > Thanks. > > > > JP and Julien. > > > > _______________________________________________ > > 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 > > --001a11c1c9708965cc05066011fb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dhruv,=C2=A0

Thank you for the careful review.=C2= =A0 Please find inline below, ###.=C2=A0
=C2=A0 =C2=A01.1 Requirements Language

=C2=A0 =C2=A0The key words "MUST", "MUST NOT", "RE= QUIRED", "SHALL", "SHALL NOT",
=C2=A0 =C2=A0"SHOULD", "SHOULD NOT", "RECOMMENDED&= quot;, "MAY", and "OPTIONAL" in this
=C2=A0 =C2=A0document are to be interpreted as described in RFC 2119 [RFC21= 19].

- In sec 3.2. Objectives
OLD:
=C2=A0 =C2=A0 =C2=A0 Allow a PCC to delegate control of its LSPs to an acti= ve stateful
=C2=A0 =C2=A0 =C2=A0 PCE such that a single LSP is under the control a sing= le PCE at
=C2=A0 =C2=A0 =C2=A0 any given time.
NEW:
=C2=A0 =C2=A0 =C2=A0 Allow a PCC to delegate control of its LSPs to an acti= ve stateful
=C2=A0 =C2=A0 =C2=A0 PCE such that a LSP is under the control a single PCE = at
=C2=A0 =C2=A0 =C2=A0 any given time.
The current text gives an impression that only one LSP (a single LSP)
is under control of a PCE.

### Yes, I r= eplaced to "a given LSP is under the control of a single PCE at any gi= ven time".=C2=A0
=C2=A0

- In sec 5.4. State Synchronization, for figure 2 and 3 'PCErr=3D?'= is
used, I suggest either to put the error type/code or remove '=3D?'.=

### done=C2=A0

- Update reference for minei-pce-stateful-sync-optimizations to
ietf-pce-stateful-sync-optimizations
### done=C2=A0

- I am not sure what is the correct way to put comments inside RBNF,
or better yet they should simply be avoided. In section 6.3, 6.4 and
6.5 "<<<<" and "<---" are used.
### removed=C2=A0

- The alignment for the byte markers is incorrect in figure 10
###fixed=C2=A0

-=C2=A0 In sec 7.3.2. Symbolic Path Name TLV, can the following text be add= ed?

=C2=A0 =C2=A0 The Symbolic Path Name is padded to 4-bytes alignment; paddin= g
=C2=A0 =C2=A0 =C2=A0itself is not included in the Length field.
### No, I think this is a disruptive change for implementations t= hat already handle the variable length of this TLV. Doing what you propose = would break the parsing code.=C2=A0

- In sec 7.3.3. LSP Error Code TLV, we should say - "The following LSP=
Error Codes are *currently* defined:"; so that future documents can easily extend it.
### ok=C2=A0

- In 9.6. Impact on Network Operation s/PcE/PCE

###ok=C2=A0
- ietf-pce-gmpls-pcep-extensions can be removed as a normative reference.
###ok=C2=A0
- there are bunch of idnits that you may wish to handle (see attached)

--------

Dhruv


On Sun, Sep 14, 2014 at 3:42 PM, JP Vasseur (jvasseur)
<jvasseur@cisco.com> wrote:=
> Dear WG,
>
> Both draft-ietf-pce-stateful-pce-app-02 and draft-ietf-pce-stateful-pc= e-09
> are now stable ready for WG Last Call.
> This starts a 3-week WG Last call, which will end on Oct 6 at noon ET.=
>
> Please send your comments on the mailing list.
>
> ps: this WG LC will be followed by another WG LC on
> draft-ietf-pce-stateful-sync-optimizations-01
> and draft-ietf-pce-pce-initiated-lsp-01.
>
>
> Thanks.
>
> JP and Julien.
>
> _______________________________________________
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>

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


--001a11c1c9708965cc05066011fb-- From nobody Sun Oct 26 22:44:25 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 272DC1A89A3 for ; Sun, 26 Oct 2014 22:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxZh7oi6hPzj for ; Sun, 26 Oct 2014 22:44:17 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 124001A8997 for ; Sun, 26 Oct 2014 22:44:16 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKY77194; Mon, 27 Oct 2014 05:44:15 +0000 (GMT) Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 27 Oct 2014 05:44:13 +0000 Received: from szxeml556-mbs.china.huawei.com ([169.254.4.112]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.03.0158.001; Mon, 27 Oct 2014 13:44:06 +0800 From: Dhruv Dhody To: Ina Minei , Dhruv Dhody , pce , JP Vasseur Thread-Topic: [Pce] WG Last Call on draft-ietf-pce-stateful-pce-app-02 and draft-ietf-pce-stateful-pce-09 Thread-Index: AQHP0ARVQD5F3VY9REKwNcdOFPjV1JwitMqAgCBkGQCAAJdyQA== Date: Mon, 27 Oct 2014 05:44:06 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B8660DCAC@szxeml556-mbs.china.huawei.com> References: In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.146.248] Content-Type: multipart/alternative; boundary="_000_23CE718903A838468A8B325B80962F9B8660DCACszxeml556mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/pce/Q28HwBfmLKEAEULho1HXltQs9bk Subject: Re: [Pce] WG Last Call on draft-ietf-pce-stateful-pce-app-02 and draft-ietf-pce-stateful-pce-09 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 05:44:19 -0000 --_000_23CE718903A838468A8B325B80962F9B8660DCACszxeml556mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSW5hLA0KDQpTbmlwcGluZyB0byB0aGUgb25seSBvcGVuIGlzc3Vl4oCmDQoNCg0KLSAgSW4g c2VjIDcuMy4yLiBTeW1ib2xpYyBQYXRoIE5hbWUgVExWLCBjYW4gdGhlIGZvbGxvd2luZyB0ZXh0 IGJlIGFkZGVkPw0KDQogICAgVGhlIFN5bWJvbGljIFBhdGggTmFtZSBpcyBwYWRkZWQgdG8gNC1i eXRlcyBhbGlnbm1lbnQ7IHBhZGRpbmcNCiAgICAgaXRzZWxmIGlzIG5vdCBpbmNsdWRlZCBpbiB0 aGUgTGVuZ3RoIGZpZWxkLg0KIyMjIE5vLCBJIHRoaW5rIHRoaXMgaXMgYSBkaXNydXB0aXZlIGNo YW5nZSBmb3IgaW1wbGVtZW50YXRpb25zIHRoYXQgYWxyZWFkeSBoYW5kbGUgdGhlIHZhcmlhYmxl IGxlbmd0aCBvZiB0aGlzIFRMVi4gRG9pbmcgd2hhdCB5b3UgcHJvcG9zZSB3b3VsZCBicmVhayB0 aGUgcGFyc2luZyBjb2RlLg0KDQpCdXQgUkZDNTQ0MCBUTFYgZGVmaW5pdGlvbiByZXF1aXJlIHRo aXMNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU0NDAjc2VjdGlvbi03LjENCjcuMTxo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1NDQwI3NlY3Rpb24tNy4xPi4gIFBDRVAgVExW IEZvcm1hdA0KICAgQSBQQ0VQIG9iamVjdCBtYXkgaW5jbHVkZSBhIHNldCBvZiBvbmUgb3IgbW9y ZSBvcHRpb25hbCBUTFZzLg0KDQogICBBbGwgUENFUCBUTFZzIGhhdmUgdGhlIGZvbGxvd2luZyBm b3JtYXQ6DQoNCiAgIFR5cGU6ICAgMiBieXRlcw0KICAgTGVuZ3RoOiAyIGJ5dGVzDQogICBWYWx1 ZTogIHZhcmlhYmxlDQoNCiAgIEEgUENFUCBvYmplY3QgVExWIGlzIGNvbXByaXNlZCBvZiAyIGJ5 dGVzIGZvciB0aGUgdHlwZSwgMiBieXRlcw0KICAgc3BlY2lmeWluZyB0aGUgVExWIGxlbmd0aCwg YW5kIGEgdmFsdWUgZmllbGQuDQoNCiAgIFRoZSBMZW5ndGggZmllbGQgZGVmaW5lcyB0aGUgbGVu Z3RoIG9mIHRoZSB2YWx1ZSBwb3J0aW9uIGluIGJ5dGVzLg0KICAgVGhlIFRMViBpcyBwYWRkZWQg dG8gNC1ieXRlcyBhbGlnbm1lbnQ7IHBhZGRpbmcgaXMgbm90IGluY2x1ZGVkIGluDQogICB0aGUg TGVuZ3RoIGZpZWxkIChzbyBhIDMtYnl0ZSB2YWx1ZSB3b3VsZCBoYXZlIGEgbGVuZ3RoIG9mIDMs IGJ1dCB0aGUNCiAgIHRvdGFsIHNpemUgb2YgdGhlIFRMViB3b3VsZCBiZSA4IGJ5dGVzKS4NCg0K U28gSSBhbSBob3BpbmcgdGhlIGltcGxlbWVudGF0aW9ucyBvZiBzdGF0ZWZ1bCBQQ0Ugc2hvdWxk IGZvbGxvdyB0aGUgYmFzZSBSRkM1NDQwIFRMViBkZWZpbml0aW9uIC4NCg0KUmVnYXJkcywNCkRo cnV2DQoNCg== --_000_23CE718903A838468A8B325B80962F9B8660DCACszxeml556mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FuZGFyYTsNCglwYW5vc2UtMToyIDE0IDUg MiAzIDMgMyAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KaDMNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk7 DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgMyBDaGFyIjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTMuNXB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQ cmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYW5kYXJhIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkhlYWRp bmczQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSGVhZGluZyAzIENoYXIiOw0KCW1zby1zdHlsZS1w cmlvcml0eTo5Ow0KCW1zby1zdHlsZS1saW5rOiJIZWFkaW5nIDMiOw0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJZm9udC13ZWlnaHQ6Ym9sZDt9DQpzcGFuLkhUTUxQ cmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFy IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9y bWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbmRhcmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBJbmEsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYW5kYXJhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FuZGFyYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNuaXBwaW5nIHRvIHRo ZSBvbmx5IG9wZW4gaXNzdWXigKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YW5kYXJhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQotJm5i c3A7IEluIHNlYyA3LjMuMi4gU3ltYm9saWMgUGF0aCBOYW1lIFRMViwgY2FuIHRoZSBmb2xsb3dp bmcgdGV4dCBiZSBhZGRlZD88YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IFRoZSBTeW1ib2xpYyBQ YXRoIE5hbWUgaXMgcGFkZGVkIHRvIDQtYnl0ZXMgYWxpZ25tZW50OyBwYWRkaW5nPGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDtpdHNlbGYgaXMgbm90IGluY2x1ZGVkIGluIHRoZSBMZW5ndGggZmll bGQuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+IyMjIE5vLCBJIHRoaW5rIHRoaXMgaXMgYSBkaXNydXB0aXZlIGNoYW5nZSBmb3IgaW1w bGVtZW50YXRpb25zIHRoYXQgYWxyZWFkeSBoYW5kbGUgdGhlIHZhcmlhYmxlIGxlbmd0aCBvZiB0 aGlzIFRMVi4gRG9pbmcgd2hhdCB5b3UgcHJvcG9zZSB3b3VsZCBicmVhayB0aGUgcGFyc2luZyBj b2RlLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxNi44cHQiPjxicj4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbmRhcmEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CdXQgUkZDNTQ0MCBUTFYgZGVmaW5pdGlvbiByZXF1 aXJlIHRoaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYW5kYXJhJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PGEgaHJlZj0iaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjNTQ0MCNzZWN0aW9uLTcuMSI+aHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvcmZjNTQ0MCNzZWN0aW9uLTcuMTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpbmUtaGVpZ2h0LWFsdDowcHQ7cGFnZS1icmVhay1i ZWZvcmU6YWx3YXlzIj4NCjxhIG5hbWU9InNlY3Rpb24tNy4xIj48L2E+PGEgaHJlZj0iaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTQ0MCNzZWN0aW9uLTcuMSI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj43LjE8L3Nw YW4+PC9iPjwvYT48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPi4mbmJzcDsgUENFUCBUTFYgRm9ybWF0PG86cD48L286cD48L3Nw YW4+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9y ZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IEEgUENFUCBvYmplY3QgbWF5IGluY2x1ZGUgYSBz ZXQgb2Ygb25lIG9yIG1vcmUgb3B0aW9uYWwgVExWcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IEFsbCBQQ0VQIFRM VnMgaGF2ZSB0aGUgZm9sbG93aW5nIGZvcm1hdDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJw YWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IFR5cGU6Jm5ic3A7Jm5i c3A7IDIgYnl0ZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBMZW5ndGg6 IDIgYnl0ZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBWYWx1ZTombmJz cDsgdmFyaWFibGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTph bHdheXMiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IEEgUENFUCBvYmplY3QgVExWIGlzIGNvbXByaXNlZCBv ZiAyIGJ5dGVzIGZvciB0aGUgdHlwZSwgMiBieXRlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7IHNwZWNpZnlpbmcgdGhlIFRMViBsZW5ndGgsIGFuZCBhIHZhbHVlIGZpZWxk LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdl LWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDsgVGhlIExlbmd0aCBmaWVsZCBkZWZpbmVzIHRoZSBsZW5ndGggb2YgdGhl IHZhbHVlIHBvcnRpb24gaW4gYnl0ZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsNCjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOnllbGxvdzttc28taGlnaGxpZ2h0OnllbGxv dyI+VGhlIFRMViBpcyBwYWRkZWQgdG8gNC1ieXRlcyBhbGlnbm1lbnQ7PC9zcGFuPiBwYWRkaW5n IGlzIG5vdCBpbmNsdWRlZCBpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNw O3RoZSBMZW5ndGggZmllbGQgKHNvIGEgMy1ieXRlIHZhbHVlIHdvdWxkIGhhdmUgYSBsZW5ndGgg b2YgMywgYnV0IHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHRvdGFs IHNpemUgb2YgdGhlIFRMViB3b3VsZCBiZSA4IGJ5dGVzKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDoxNi44cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbmRhcmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5TbyBJIGFtIGhvcGluZyB0aGUgaW1wbGVtZW50YXRpb25zIG9mIHN0YXRlZnVs IFBDRSBzaG91bGQgZm9sbG93IHRoZSBiYXNlIFJGQzU0NDAgVExWIGRlZmluaXRpb24gLg0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjE2LjhwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FuZGFyYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDoxNi44cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbmRhcmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDoxNi44cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbmRhcmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5EaHJ1djxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bmRhcmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_23CE718903A838468A8B325B80962F9B8660DCACszxeml556mbschi_-- From nobody Sun Oct 26 22:57:17 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2250D1A8994 for ; Sun, 26 Oct 2014 22:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYAScuONAqIz for ; Sun, 26 Oct 2014 22:57:12 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 532211A8026 for ; Sun, 26 Oct 2014 22:57:12 -0700 (PDT) Received: by mail-oi0-f54.google.com with SMTP id v63so2832836oia.13 for ; Sun, 26 Oct 2014 22:57:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gXowiZbNziq/BPn/DZpP9O4c/qdxXaV4B3VABu3Rh3A=; b=eH8FRU+WGMagjnQ1ZBbwesBYQawb66jrIYl3VQncYCvyeWNXuVhHZ9F9x6qsObBe1g QyzonwKSi2zp/JONy6mWwrReIZpNyYbXuyyZcmwRITDlZjrjbaVXpLdFfnGutJX4gZJr RvloK5M2f7cNcsy3vZXBtvQCAxpKxEdN19JV2cq92Dsp/z6EGiEM6D96K1+bfgaOcgan +NB8Cjt8M3GS4RZILQp7TpeCO+RCbYjSG69aEbhe4/TXidMql7BGDuKpL2afS+9q47g9 qNJiXlpy793wU40LfOUfbkKL9TdlWlu5q0Ozx0JAxA6W6Pp8+Tp96DsB8xleGAbxX521 XCnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gXowiZbNziq/BPn/DZpP9O4c/qdxXaV4B3VABu3Rh3A=; b=YbJtoOdxIXClRpAN6jOvRGfeWEEBcc2Fm6puotFj6aIu9hY2uxX+K2CaLx1lXMKXJV cGK0PAhF8lmxzAhH35GQEaedGD4iuoCD6wU+QbOsWd7thmJLU671/HADj+KTOHnRA/Ge qyr4ZWbmMy90ox1VEEtUYfBRs/UCqD5XCWCWIe0G4/dxyBV2e5VGJFqA39VftZW4CNUQ Qn1LFXC9xexqN9U6M2L8h7K3ba6rsIfY2UmLUIUam2/wb/Mu6iSFpil83Qh2j0SB2iAJ 8kRd4V24lg+Rd4OR6JK3lJSZM29f3ZL8RrzsIrhduWeR7myXmOb+7PY/OK/FKBRLYjFD 4W2Q== X-Gm-Message-State: ALoCoQlynorDKJ+u7viFB14oKzOgqUOoElpOdhhIGV8gVpSdpkEK8xDEc1Pqcn5U+UgNW8BSuL4p MIME-Version: 1.0 X-Received: by 10.60.123.18 with SMTP id lw18mr18886722oeb.7.1414389431588; Sun, 26 Oct 2014 22:57:11 -0700 (PDT) Received: by 10.182.23.41 with HTTP; Sun, 26 Oct 2014 22:57:11 -0700 (PDT) In-Reply-To: References: Date: Sun, 26 Oct 2014 22:57:11 -0700 Message-ID: From: Ina Minei To: Cyril Margaria Content-Type: multipart/alternative; boundary=047d7b5d4264a4f54f050661337f Archived-At: http://mailarchive.ietf.org/arch/msg/pce/i_2jHGrxzQ_t84A_wIEsVXHQsUw Cc: "pce@ietf.org" Subject: Re: [Pce] WG Last Call on draft-ietf-pce-stateful-pce-app-02 and draft-ietf-pce-stateful-pce-09 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 05:57:16 -0000 --047d7b5d4264a4f54f050661337f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thank you for the careful review, please see inline ###. [snip] > I Have the following comment for draft-ietf-pce-stateful-pce-09: > > Section 2 > The document references the following timers: > - State Timeout Interval > - Redelegation Timeout Interval > > RFC5440 defines an Appendix B. PCEP Variables, having a dedicated section > for those variables would be better, as they are integral part of the > extensions. > ### They are discussed in the main part of the draft, their use etc is introduced as early as page 4 of the doc. The suggested values for these timers are added in the operational section in the appendix, where they logically belong and I don't think we want to move them. > > > Section 5.4 > > After the first paragraph, add: > The State synchronization start with a LSP state report having the SYNC > Flag in the LSP Object set to 1. > > Reason: This would allow for the PCC to fully resend its database after > the Initialization phase, and clarify the PCE operation. > ### This is covered in the current text and also clearly shown in figure 1. . > > Section 5.6.1 > OLD > Once an LSP is up, the PCC sends an LSP State Report carried on a > PCRpt message to the PCE, indicating that the LSP's status is 'Up'. > If the LSP could not be set up, the PCC sends an LSP State Report > indicating that the LSP is "Down' and stating the cause of the > Failure. > > NEW > Once an LSP is up, the PCC sends an LSP State Report carried on a > PCRpt message to the PCE, indicating that the LSP's status is 'Up' or > 'Active'. > If the LSP could not be set up, the PCC sends an LSP State Report > indicating that the LSP is "Down' and stating the cause of the > failure. > > ### Thank you for catching > > OLD > In such cases, the PCC may choose to only send the PCRpt > indicating the latest status ('Up' or 'Down=C2=B9). > > NEW > In such cases, the PCC may choose to only send the PCRpt > indicating the latest status (=C5=92Active=C2=B9, 'Up' or 'Down'). > > > Reason : Active is also a possible state. > ### Added > > > Section 5.6.2 > OLD > If the PCC decides that the LSP parameters proposed in the PCUpd message > are unacceptable, it MUST report this error by including the > LSP-ERROR-CODE TLV (Section 7.3.3 > >) > with LSP error-value=3D=C2=B3Unacceptable parameters" in the LSP object i= n the > PCRpt message to the PCE > > NEW > If the PCC decides that the LSP parameters proposed in the PCUpd message > are unacceptable, it MUST report this error by including the > LSP-ERROR-CODE TLV (Section 7.3.3 > >) > with LSP error-value=3D=C2=B3Unacceptable parameters" in the LSP object i= n the > PCRpt message to the PCE. The PCC MAY/SHOULD include the objects that wer= e > not accepted in the PCRpt message. > > > Reason: If the PCC includes the objects (current PCC values) that caused > the PCUpd to be rejected, it would help the PCE avoid resending them. A > PCErr would allow to include the objects, a new error type would be neede= d > but error handling from PCE side should be rather easy. Another > possibility is having the LSP-ERROR-CODE containing a list of > Object-Class, OT . > > ### While I agree in principle, I think if we go down this road we should also include the reason why the object was rejected to make this useful. Unless others feel strongly, I would not add this. > > OLD > Once an LSP is up, the PCC sends an LSP State Report (PCRpt message) > to the PCE, indicating that the LSP's status is 'Up'. If the LSP > could not be set up, the PCC sends an LSP State Report indicating > that the LSP is 'Down' and stating the cause of the failure. > > NEW > Once an LSP is up or active, the PCC sends an LSP State Report (PCRpt > message) > to the PCE, indicating that the LSP's status is 'Up=C2=B9 (resp. 'Acti= ve'). > If the LSP > could not be set up, the PCC sends an LSP State Report indicating > that the LSP is 'Down' and stating the cause of the failure. > ### Done > > > > > Section 6.1 > OLD > The RRO SHOULD be included by the PCC when the path is up, > > NEW > The RRO SHOULD be included by the PCC when the path is up or active, > ### done > > Section 7 > Replace MUST by SHOULD, this is restricting a lot future documents (not > allowing to enforce/ignore gracefully some objects) > > Section 7.3. > Nits: Using Synchronize would be better aligned with other bits definitio= n > > S bit: Add: On PCUpd the R flag SHOULD (MUST?) be set to 0 on transmissio= n > and MUST be ignored on receipt. > > R bit: Add: On PCUpd the R flag SHOULD (MUST?) be set to 0 on transmissio= n > and MUST be ignored on receipt > (or it is allowed on PCUpd?) > O bit: Add: On PCUpd the O Field SHOULD (MUST?) be set to 0 on > transmission and MUST be ignored on receipt. > ### This would preclude use of these bits in future documents, so I prefer not to add this. > Section 7.3.3. > The error value =C5=92LSP preempted=C2=B9 could seem a bit redundant wi= th =C5=92RSVP > signaling error=C2=B9 and the corresponding RSVP preempted error code, I > believe the error code =C5=92LSP preempted=C2=B9 should be seen when a PC= C-local > administrative preemption is made, and the RSVP signaling error should be > used otherwise (the error node can be of value for the PCE) > ### I think there is value to keep preemption separate from signaling error, and I prefer to leave them distinct. > > > > BR > Cyril > > > On 6 October 2014 09:57, Dhruv Dhody wrote: > >> Hi WG, >> >> Support both the documents, and are basically ready for publications. >> >> I re-read the documents again, here are some nits/comments which can >> be handled along the process. >> >> -------- >> >> For draft-ietf-pce-stateful-pce-app: (listed as a contributor) >> >> - In sec 3. Overview of the Stateful PCE Protocol Extensions; the word >> tunnel is used in below paragraph, for consistency with rest of the >> document can it be changed to LSP. >> >> [I-D.ietf-pce-stateful-pce] specifies a set of extensions to PCEP to >> enable stateful control of tunnels within and across PCEP sessions in >> compliance with [RFC4657]. It includes mechanisms to effect tunnel >> state synchronization between PCCs and PCEs, delegation of control >> over tunnels to PCEs, and PCE control of timing and sequence of path >> computations within and across PCEP sessions. >> >> Since we are not using RFC2119 keywords in this document, we should >> not use 'SHOULD'. >> >> LSP state synchronization (C-E): after the session between a PCC >> and >> a stateful PCE is initialized, the PCE can perform path >> computation and update attributes in a PCC. However, if the goal >> of the PCE is to provide accurate path information based on the >> most up-to-date state of the network, the PCE SHOULD wait until it >> learns the state of the PCC's LSP states before doing so. >> >> - In sec 4.3. PCE Survivability; a reference to >> draft-ietf-pce-stateful-sync-optimizations can be added for >> readability. >> >> - Expand on first use PCReq, LER, NMS, RRO, RSVP-TE >> >> - Suggest if you can add IANA consideration section and explicitly say >> that there are no request for IANA in this document. >> >> - Some unused references like MXMN-TE, MPLS-PC, NET-REC (perhaps >> because of older version text from draft-ietf-pce-stateful-pce) >> >> -------- >> >> For draft-ietf-pce-stateful-pce: >> >> - RFC2119 keywords requirement language should be added as subsection >> in introduction. >> >> 1.1 Requirements Language >> >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this >> document are to be interpreted as described in RFC 2119 [RFC2119]. >> >> - In sec 3.2. Objectives >> OLD: >> Allow a PCC to delegate control of its LSPs to an active stateful >> PCE such that a single LSP is under the control a single PCE at >> any given time. >> NEW: >> Allow a PCC to delegate control of its LSPs to an active stateful >> PCE such that a LSP is under the control a single PCE at >> any given time. >> The current text gives an impression that only one LSP (a single LSP) >> is under control of a PCE. >> >> - In sec 5.4. State Synchronization, for figure 2 and 3 'PCErr=3D?' is >> used, I suggest either to put the error type/code or remove '=3D?'. >> >> - Update reference for minei-pce-stateful-sync-optimizations to >> ietf-pce-stateful-sync-optimizations >> >> - I am not sure what is the correct way to put comments inside RBNF, >> or better yet they should simply be avoided. In section 6.3, 6.4 and >> 6.5 "<<<<" and "<---" are used. >> >> - The alignment for the byte markers is incorrect in figure 10 >> >> - In sec 7.3.2. Symbolic Path Name TLV, can the following text be added= ? >> >> The Symbolic Path Name is padded to 4-bytes alignment; padding >> itself is not included in the Length field. >> >> - In sec 7.3.3. LSP Error Code TLV, we should say - "The following LSP >> Error Codes are *currently* defined:"; so that future documents can >> easily extend it. >> >> - In 9.6. Impact on Network Operation s/PcE/PCE >> >> - ietf-pce-gmpls-pcep-extensions can be removed as a normative reference= . >> >> - there are bunch of idnits that you may wish to handle (see attached) >> >> -------- >> >> Dhruv >> >> >> On Sun, Sep 14, 2014 at 3:42 PM, JP Vasseur (jvasseur) >> wrote: >> > Dear WG, >> > >> > Both draft-ietf-pce-stateful-pce-app-02 and >> draft-ietf-pce-stateful-pce-09 >> > are now stable ready for WG Last Call. >> > This starts a 3-week WG Last call, which will end on Oct 6 at noon ET. >> > >> > Please send your comments on the mailing list. >> > >> > ps: this WG LC will be followed by another WG LC on >> > draft-ietf-pce-stateful-sync-optimizations-01 >> > and draft-ietf-pce-pce-initiated-lsp-01. >> > >> > >> > Thanks. >> > >> > JP and Julien. >> > >> > _______________________________________________ >> > Pce mailing list >> > Pce@ietf.org >> > https://www.ietf.org/mailman/listinfo/pce >> > >> >> _______________________________________________ >> Pce mailing list >> Pce@ietf.org >> https://www.ietf.org/mailman/listinfo/pce >> >> > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > --047d7b5d4264a4f54f050661337f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you for the careful review, please see inline ###.= =C2=A0

[snip]
I Have the following comment for draf= t-ietf-pce-stateful-pce-09:

Section 2
The document references the= following timers:
=C2=A0=C2=A0 - State Timeout Interval
=C2=A0=C2=A0= - Redelegation Timeout Interval

RFC5440 defines an Appendix B. PCEP= Variables, having a dedicated section
for those variables would be bett= er, as they are integral part of the
extensions.

### They are discussed in the main part of the dra= ft, their use etc is introduced as early as page 4 of the doc. The suggeste= d values for these timers are added in the operational section in the appen= dix, where they logically belong and I don't think we want to move them= .=C2=A0


Section 5.4
=
After the first paragraph, add:
The State synchronization start with= a LSP state report having the SYNC
Flag in the LSP Object set to 1.
=
Reason: This would allow for the PCC to fully resend its database after=
the Initialization phase, and clarify the PCE operation.

### This is covered in the current text a= nd also clearly shown in figure 1. .=C2=A0
=C2=A0

Section 5.6.1
OLD
Once an LSP is up,= the PCC sends an LSP State Report carried on a
=C2=A0=C2=A0 PCRpt messa= ge to the PCE, indicating that the LSP's status is 'Up'.
=C2= =A0=C2=A0 If the LSP could not be set up, the PCC sends an LSP State Report=
=C2=A0=C2=A0 indicating that the LSP is "Down' and stating the= cause of the
=C2=A0=C2=A0 Failure.

NEW
Once an LSP is up, the= PCC sends an LSP State Report carried on a
=C2=A0=C2=A0 PCRpt message t= o the PCE, indicating that the LSP's status is 'Up' or
'= Active'.
=C2=A0=C2=A0 If the LSP could not be set up, the PCC sends = an LSP State Report
=C2=A0=C2=A0 indicating that the LSP is "Down&#= 39; and stating the cause of the
failure.

### Thank you for catching=C2=A0

OLD
In such cases, the PCC may choose to only send the PCRp= t
=C2=A0=C2=A0 indicating the latest status ('Up' or 'Down= =C2=B9).

NEW
In such cases, the PCC may choose to only send the P= CRpt
=C2=A0=C2=A0 indicating the latest status (=C5=92Active=C2=B9, '= ;Up' or 'Down').


Reason : Active is also a possible = state.
### Added=C2=A0


Section 5.6.2
OLD
If the PCC decides= that the LSP parameters proposed in the PCUpd message
are unacceptable,= it MUST report this error by including the
LSP-ERROR-CODE TLV (Section = 7.3.3
<https://tools.ietf.org/html/draft-= ietf-pce-stateful-pce-09#section-7.3.3>)
with LSP error-value=3D= =C2=B3Unacceptable parameters" in the LSP object in the
PCRpt messa= ge to the PCE

NEW
If the PCC decides that the LSP parameters prop= osed in the PCUpd message
are unacceptable, it MUST report this error by= including the
LSP-ERROR-CODE TLV (Section 7.3.3
<https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-09#sect= ion-7.3.3>)
with LSP error-value=3D=C2=B3Unacceptable parameters&= quot; in the LSP object in the
PCRpt message to the PCE. The PCC MAY/SHO= ULD include the objects that were
not accepted in the PCRpt message.
=

Reason: If the PCC includes the objects (current PCC values) that c= aused
the PCUpd to be rejected, it would help the PCE avoid resending th= em. A
PCErr would allow to include the objects, a new error type would b= e needed
but error handling from PCE side should be rather easy. Another=
possibility is having the LSP-ERROR-CODE containing a list of
Object= -Class, OT .

### While I agree in prin= ciple, I think if we go down this road we should also include the reason
why the object was rejected to make this useful. Unless others feel= strongly, I would not add this. =C2=A0

OLD
=C2=A0=C2=A0 Once an LSP is up, the PCC sends an LSP St= ate Report (PCRpt message)
=C2=A0=C2=A0 to the PCE, indicating that the = LSP's status is 'Up'.=C2=A0 If the LSP
=C2=A0=C2=A0 could no= t be set up, the PCC sends an LSP State Report indicating
=C2=A0=C2=A0 t= hat the LSP is 'Down' and stating the cause of the failure.

= NEW
=C2=A0=C2=A0 Once an LSP is up or active, the PCC sends an LSP State= Report (PCRpt
message)
=C2=A0=C2=A0 to the PCE, indicating that the = LSP's status is 'Up=C2=B9 (resp. 'Active').
If the LSP=C2=A0=C2=A0 could not be set up, the PCC sends an LSP State Report indic= ating
=C2=A0=C2=A0 that the LSP is 'Down' and stating the cause = of the failure.
### Done=C2=A0




Section 6.1
OLD
The = RRO SHOULD be included by the PCC when the path is up,

NEW
The RR= O SHOULD be included by the PCC when the path is up or active,
### done=C2=A0
=

Section 7
Replace MUST by SHOULD, this is restricting a lot fut= ure documents (not
allowing to enforce/ignore gracefully some objects)

Section 7= .3.
Nits: Using Synchronize would be better aligned with other bits defi= nition

S bit: Add: On PCUpd the R flag SHOULD (MUST?) be set to 0 on= transmission
and MUST be ignored on receipt.=C2=A0
=C2=A0
R bit: Add: On = PCUpd the R flag SHOULD (MUST?) be set to 0 on transmission
and MUST be = ignored on receipt
=C2=A0 (or it is allowed on PCUpd?)
O bit: Add: On PCUpd the O Fi= eld SHOULD (MUST?) be set to 0 on
transmission and MUST be ignored on re= ceipt.

### This would precl= ude use of these bits in future documents, so =C2=A0I prefer not to add thi= s.

=C2=A0
<= div>Section 7.3.3.
=C2=A0 The error value =C5=92LSP preempted=C2=B9 coul= d seem a bit redundant with =C5=92RSVP
signaling error=C2=B9 and the cor= responding RSVP preempted error code, I
believe the error code =C5=92LSP= preempted=C2=B9 should be seen when a PCC-local
administrative preempti= on is made, and the RSVP signaling error should be
used otherwise (the e= rror node can be of value for the PCE)
###= =C2=A0I think there is value to keep preemption separate from signaling er= ror, and I prefer to leave them=C2=A0
distinct. =C2=A0



BR
Cyril


On 6 October 2014 09:57, Dhruv Dhody= <dhruv.ietf@gmail.com> wrote:
Hi WG,=

Support both the documents, and are basically ready for publications.

I re-read the documents again, here are some nits/comments which can
be handled along the process.

--------

For draft-ietf-pce-stateful-pce-app: (listed as a contributor)

- In sec 3. Overview of the Stateful PCE Protocol Extensions; the word
tunnel is used in below paragraph, for consistency with rest of the
document can it be changed to LSP.

=C2=A0 =C2=A0[I-D.ietf-pce-stateful-pce] specifies a set of extensions to P= CEP to
=C2=A0 =C2=A0enable stateful control of tunnels within and across PCEP sess= ions in
=C2=A0 =C2=A0compliance with [RFC4657].=C2=A0 It includes mechanisms to eff= ect tunnel
=C2=A0 =C2=A0state synchronization between PCCs and PCEs, delegation of con= trol
=C2=A0 =C2=A0over tunnels to PCEs, and PCE control of timing and sequence o= f path
=C2=A0 =C2=A0computations within and across PCEP sessions.

Since we are not using RFC2119 keywords in this document, we should
not use 'SHOULD'.

=C2=A0 =C2=A0 =C2=A0 LSP state synchronization (C-E):=C2=A0 after the sessi= on between a PCC and
=C2=A0 =C2=A0 =C2=A0 a stateful PCE is initialized, the PCE can perform pat= h
=C2=A0 =C2=A0 =C2=A0 computation and update attributes in a PCC.=C2=A0 Howe= ver, if the goal
=C2=A0 =C2=A0 =C2=A0 of the PCE is to provide accurate path information bas= ed on the
=C2=A0 =C2=A0 =C2=A0 most up-to-date state of the network, the PCE SHOULD w= ait until it
=C2=A0 =C2=A0 =C2=A0 learns the state of the PCC's LSP states before do= ing so.

- In sec 4.3. PCE Survivability; a reference to
draft-ietf-pce-stateful-sync-optimizations can be added for
readability.

- Expand on first use PCReq, LER, NMS, RRO, RSVP-TE

- Suggest if you can add IANA consideration section and explicitly say
that there are no request for IANA in this document.

- Some unused references like MXMN-TE, MPLS-PC, NET-REC (perhaps
because of older version text from draft-ietf-pce-stateful-pce)

--------

For draft-ietf-pce-stateful-pce:

- RFC2119 keywords requirement language should be added as subsection
in introduction.

=C2=A0 =C2=A01.1 Requirements Language

=C2=A0 =C2=A0The key words "MUST", "MUST NOT", "RE= QUIRED", "SHALL", "SHALL NOT",
=C2=A0 =C2=A0"SHOULD", "SHOULD NOT", "RECOMMENDED&= quot;, "MAY", and "OPTIONAL" in this
=C2=A0 =C2=A0document are to be interpreted as described in RFC 2119 [RFC21= 19].

- In sec 3.2. Objectives
OLD:
=C2=A0 =C2=A0 =C2=A0 Allow a PCC to delegate control of its LSPs to an acti= ve stateful
=C2=A0 =C2=A0 =C2=A0 PCE such that a single LSP is under the control a sing= le PCE at
=C2=A0 =C2=A0 =C2=A0 any given time.
NEW:
=C2=A0 =C2=A0 =C2=A0 Allow a PCC to delegate control of its LSPs to an acti= ve stateful
=C2=A0 =C2=A0 =C2=A0 PCE such that a LSP is under the control a single PCE = at
=C2=A0 =C2=A0 =C2=A0 any given time.
The current text gives an impression that only one LSP (a single LSP)
is under control of a PCE.

- In sec 5.4. State Synchronization, for figure 2 and 3 'PCErr=3D?'= is
used, I suggest either to put the error type/code or remove '=3D?'.=

- Update reference for minei-pce-stateful-sync-optimizations to
ietf-pce-stateful-sync-optimizations

- I am not sure what is the correct way to put comments inside RBNF,
or better yet they should simply be avoided. In section 6.3, 6.4 and
6.5 "<<<<" and "<---" are used.

- The alignment for the byte markers is incorrect in figure 10

-=C2=A0 In sec 7.3.2. Symbolic Path Name TLV, can the following text be add= ed?

=C2=A0 =C2=A0 The Symbolic Path Name is padded to 4-bytes alignment; paddin= g
=C2=A0 =C2=A0 =C2=A0itself is not included in the Length field.

- In sec 7.3.3. LSP Error Code TLV, we should say - "The following LSP=
Error Codes are *currently* defined:"; so that future documents can easily extend it.

- In 9.6. Impact on Network Operation s/PcE/PCE

- ietf-pce-gmpls-pcep-extensions can be removed as a normative reference.
- there are bunch of idnits that you may wish to handle (see attached)

--------

Dhruv


On Sun, Sep 14, 2014 at 3:42 PM, JP Vasseur (jvasseur)
<jvasseur@cisco.= com> wrote:
> Dear WG,
>
> Both draft-ietf-pce-stateful-pce-app-02 and draft-ietf-pce-stateful-pc= e-09
> are now stable ready for WG Last Call.
> This starts a 3-week WG Last call, which will end on Oct 6 at noon ET.=
>
> Please send your comments on the mailing list.
>
> ps: this WG LC will be followed by another WG LC on
> draft-ietf-pce-stateful-sync-optimizations-01
> and draft-ietf-pce-pce-initiated-lsp-01.
>
>
> Thanks.
>
> JP and Julien.
>
> _______________________________________________
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>

_______________________________________________
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


--047d7b5d4264a4f54f050661337f-- From nobody Sun Oct 26 23:00:36 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1E91A89A4; Sun, 26 Oct 2014 23:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxp6EjBBQdZt; Sun, 26 Oct 2014 23:00:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F33B1A00FC; Sun, 26 Oct 2014 23:00:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027060028.1087.65911.idtracker@ietfa.amsl.com> Date: Sun, 26 Oct 2014 23:00:28 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/n7LEb617CFjHbr1yfW2utR0LyDA Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-stateful-pce-10.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 06:00:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : PCEP Extensions for Stateful PCE Authors : Edward Crabbe Ina Minei Jan Medved Robert Varga Filename : draft-ietf-pce-stateful-pce-10.txt Pages : 47 Date : 2014-10-26 Abstract: The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS LSPs via PCEP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-stateful-pce-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Oct 26 23:06:25 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E391A1A8997 for ; Sun, 26 Oct 2014 23:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Gdn6fpI_eF9 for ; Sun, 26 Oct 2014 23:06:19 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6993D1A89A6 for ; Sun, 26 Oct 2014 23:06:19 -0700 (PDT) Received: by mail-oi0-f51.google.com with SMTP id g201so945556oib.38 for ; Sun, 26 Oct 2014 23:06:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=21eRTEx+nja/nFN2wOt7Un2LJ+yfK6JPZqmJn1rxEWk=; b=lr4d3otFLjq4GtVIuyx5yenG99Wok7NBJYBB1YLkltiqr7g22MxPJ42wuAQrcU9erk DYVnSHvqJz69zcml91nrAzsCp71FqvCtBj3zL+yrwg046Y1I/nmp/EIMIPsxSFRd3R+C rkBUirzENE6kGzYr1OYZ+lOXqRpYQkdWXI8m/P2CdZUGolwlD2eErsaIXEnmEmZwvTDm VT2WaliqQPwv9UIpRiGCKPv3CrXOCLi8GAfFw3VdIx4NvqLAceLj272Y41o/2cPb5eUK S/4/pFMz9r+e6/tj86M/9OnwEWR9E+2XXgTzCt0b17ut2JkJaPsyy3e7wtQGQcVxONve ZXww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=21eRTEx+nja/nFN2wOt7Un2LJ+yfK6JPZqmJn1rxEWk=; b=guGn/vgO5zfnG84NU36H3QsyCdIn3E1kDAvnGfIgob7D7iaxXBc8lXEH7Fbndv4KQC X7SfqsyBuuvUoOAvmOUDjdJH3g29viilI75BxWcwSTIO8Ovz7PjiDo3woJ6Nw/ErkyLE iEs5v7WPeMQTaaoS9KbB2kIv3ywqplZgE+DaSQFqYmGwN39fe7mX7498HCwqKw0bJ7Ct /7uNQzsPx+lZ9uo3bS+J3wg6Ug6pqul7ez5MYny3GDpAuNadmJIOyZNn3ej40VoEF59V dSPjW12GzHfVli8KUdpTp5/GiLEXBBs4yxCir3sjJfW5oRs5PsX/r5puS5FIxY6RyWKB VuTg== X-Gm-Message-State: ALoCoQliGIuayGjRO6IKPy+XB5pw7zDGX+x007uTy2CNZU8V3cGZ8tS65bnBXKTlRKLUMbxfzLxK MIME-Version: 1.0 X-Received: by 10.202.169.207 with SMTP id s198mr17663020oie.7.1414389978864; Sun, 26 Oct 2014 23:06:18 -0700 (PDT) Received: by 10.182.23.41 with HTTP; Sun, 26 Oct 2014 23:06:18 -0700 (PDT) In-Reply-To: <23CE718903A838468A8B325B80962F9B8660DCAC@szxeml556-mbs.china.huawei.com> References: <23CE718903A838468A8B325B80962F9B8660DCAC@szxeml556-mbs.china.huawei.com> Date: Sun, 26 Oct 2014 23:06:18 -0700 Message-ID: From: Ina Minei To: Dhruv Dhody Content-Type: multipart/alternative; boundary=001a113cd9ae43c6ef0506615408 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/A9igIR6S9hWD500UeZkJPIMp83E Cc: pce , JP Vasseur Subject: Re: [Pce] WG Last Call on draft-ietf-pce-stateful-pce-app-02 and draft-ietf-pce-stateful-pce-09 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 06:06:21 -0000 --001a113cd9ae43c6ef0506615408 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dhruv, thank you for sending the reference. In that case, should already be compliant since the draft defines new pcep tlvs. On Sun, Oct 26, 2014 at 10:44 PM, Dhruv Dhody wrote: > Hi Ina, > > > > Snipping to the only open issue=E2=80=A6 > > > > > - In sec 7.3.2. Symbolic Path Name TLV, can the following text be added? > > The Symbolic Path Name is padded to 4-bytes alignment; padding > itself is not included in the Length field. > > ### No, I think this is a disruptive change for implementations that > already handle the variable length of this TLV. Doing what you propose > would break the parsing code. > > > But RFC5440 TLV definition require this > > http://tools.ietf.org/html/rfc5440#section-7.1 > > *7.1* *. PCEP TLV Format= * > > A PCEP object may include a set of one or more optional TLVs. > > > > All PCEP TLVs have the following format: > > > > Type: 2 bytes > > Length: 2 bytes > > Value: variable > > > > A PCEP object TLV is comprised of 2 bytes for the type, 2 bytes > > specifying the TLV length, and a value field. > > > > The Length field defines the length of the value portion in bytes. > > The TLV is padded to 4-bytes alignment; padding is not included in > > the Length field (so a 3-byte value would have a length of 3, but the > > total size of the TLV would be 8 bytes). > > > > So I am hoping the implementations of stateful PCE should follow the base > RFC5440 TLV definition . > > > > Regards, > > Dhruv > > > --001a113cd9ae43c6ef0506615408 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dhruv, thank you for sending the reference. In that case, = should already be compliant since the draft defines new pcep tlvs.=C2=A0

On Sun, Oct 26, = 2014 at 10:44 PM, Dhruv Dhody <dhruv.dhody@huawei.com> = wrote:

Hi Ina,

=C2=A0

Snipping to the only open= issue=E2=80=A6

=C2=A0


-=C2=A0 In sec 7.3.2. Symbolic Path Name TLV, can the following text be add= ed?

=C2=A0 =C2=A0 The Symbolic Path Name is padded to 4-bytes alignment; paddin= g
=C2=A0 =C2=A0 =C2=A0itself is not included in the Length field.

### No, I think this is a disruptive change for impl= ementations that already handle the variable length of this TLV. Doing what= you propose would break the parsing code.=C2=A0


But RFC5440 TLV definition require this

http://tools.ietf.org/h= tml/rfc5440#section-7.1

7.1.=C2=A0 PCEP TLV Format=

=C2=A0=C2=A0 A PCEP object may include a set of one or more opt= ional TLVs.

=C2=A0

=C2=A0=C2=A0 All PCEP TLVs have the following format:=

=C2=A0

=C2=A0=C2=A0 Type:=C2=A0=C2=A0 2 bytes

=C2=A0=C2=A0 Length: 2 bytes

=C2=A0=C2=A0 Value:=C2=A0 variable

=C2=A0

=C2=A0=C2=A0 A PCEP object TLV is comprised of 2 bytes for the = type, 2 bytes

=C2=A0=C2=A0 specifying the TLV length, and a value field.

=C2=A0

=C2=A0=C2=A0 The Length field defines the length of the value p= ortion in bytes.

=C2=A0=C2=A0 The TLV is padded to 4-bytes alignment; padding is not included in

=C2=A0 =C2=A0the Length field (so a 3-byte value would have a l= ength of 3, but the

=C2=A0=C2=A0 total size of the TLV would be 8 bytes).=

=C2=A0

So I am hoping the implementations of stateful PCE should follow the ba= se RFC5440 TLV definition .

=C2=A0

Regards,

Dhruv

=C2=A0


--001a113cd9ae43c6ef0506615408-- From nobody Mon Oct 27 00:29:00 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8DF1A8A03 for ; Mon, 27 Oct 2014 00:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d_deitmouv5X for ; Mon, 27 Oct 2014 00:28:55 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 361441A1AF1 for ; Mon, 27 Oct 2014 00:28:55 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKY85921; Mon, 27 Oct 2014 07:28:53 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 27 Oct 2014 07:28:53 +0000 Received: from NKGEML509-MBS.china.huawei.com ([169.254.2.88]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Mon, 27 Oct 2014 15:28:49 +0800 From: Youjianjie To: "pce@ietf.org" Thread-Topic: New Version Notification for draft-xu-pce-sr-sfc-02.txt Thread-Index: AQHP8bamIwRGIiwbuUKY+tAGVNUYSJxDimOg Date: Mon, 27 Oct 2014 07:28:48 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.173] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/pce/Jm4_TwVEKdF2chaWrubzXaDdk9s Subject: [Pce] =?utf-8?b?6L2s5Y+ROiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y?= =?utf-8?q?_draft-xu-pce-sr-sfc-02=2Etxt?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 07:28:57 -0000 SGkgYWxsLA0KDQpBbiB1cGRhdGVkIHJldmlzaW9uIGhhcyBiZWVuIHVwbG9hZGVkLiBUaGUgbWFp biBjaGFuZ2UgaXMgdG8gc3VwcG9ydCBib3RoIHRoZSBzdGF0ZWxlc3MgYW5kIHN0YXRlZnVsIFBD RSBtb2RlbHMuDQpZb3VyIHF1ZXN0aW9ucyBhbmQgY29tbWVudHMgYXJlIGFwcHJlY2lhdGVkLg0K DQpCZXN0IFJlZ2FyZHMsDQpKaWFuamllDQoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7 tuS6ujogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGll dGYub3JnXSANCuWPkemAgeaXtumXtDogMjAxNOW5tDEw5pyIMjfml6UgMTU6MjINCuaUtuS7tuS6 ujogTHVpcyBNLiBDb250cmVyYXM7IFNpdmEgU2l2YWJhbGFuOyBYdXhpYW9odTsgU2l2YSBTaXZh YmFsYW47IFlvdWppYW5qaWU7IFh1eGlhb2h1OyBIaW1hbnNodSBTaGFoOyBIaW1hbnNodSBDLiBT aGFoOyBZb3VqaWFuamllOyBMdWlzIE0uIENvbnRyZXJhcw0K5Li76aKYOiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yIGRyYWZ0LXh1LXBjZS1zci1zZmMtMDIudHh0DQoNCg0KQSBuZXcgdmVy c2lvbiBvZiBJLUQsIGRyYWZ0LXh1LXBjZS1zci1zZmMtMDIudHh0IGhhcyBiZWVuIHN1Y2Nlc3Nm dWxseSBzdWJtaXR0ZWQgYnkgSmlhbmppZSBZb3UgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBv c2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQteHUtcGNlLXNyLXNmYw0KUmV2aXNpb246CTAyDQpUaXRs ZToJCVBDRVAgRXh0ZW5zaW9ucyBmb3IgU0ZDIGluIFNQUklORyBOZXR3b3Jrcw0KRG9jdW1lbnQg ZGF0ZToJMjAxNC0xMC0yNw0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJ MTQNClVSTDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC14dS1wY2Utc3Itc2ZjLTAyLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXh1LXBjZS1zci1zZmMvDQpIdG1saXplZDogICAgICAg aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteHUtcGNlLXNyLXNmYy0wMg0KRGlmZjog ICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXh1LXBjZS1z ci1zZmMtMDINCg0KQWJzdHJhY3Q6DQogICBbSS1ELnh1LXNwcmluZy1wY2UtYmFzZWQtc2ZjLWFy Y2hdIGRlc2NyaWJlcyBhIFBDRS1iYXNlZCBTRkMNCiAgIGFyY2hpdGVjdHVyZSBpbiB3aGljaCB0 aGUgUENFIGlzIHVzZWQgdG8gY29tcHV0ZSBzZXJ2aWNlIGZ1bmN0aW9uDQogICBwYXRocyBpbiBT UFJJTkcgbmV0d29ya3MuICBCYXNlZCBvbiB0aGUgYWJvdmUgYXJjaGl0ZWN0dXJlLCB0aGlzDQog ICBkb2N1bWVudCBkZXNjcmliZXMgZXh0ZW5zaW9ucyB0byB0aGUgUGF0aCBDb21wdXRhdGlvbiBF bGVtZW50DQogICBQcm90b2NvbCAoUENFUCkgdGhhdCBhbGxvdyBhIFBDRSB0byBjb21wdXRlIGFu ZCBpbnN0YW50aWF0ZSBzZXJ2aWNlDQogICBmdW5jdGlvbiBwYXRocyBpbiBTUFJJTkcgbmV0d29y a3MuICBUaGUgZXh0ZW5zaW9ucyBzcGVjaWZpZWQgaW4gdGhpcw0KICAgZG9jdW1lbnQgYXJlIGFw cGxpY2FibGUgdG8gYm90aCB0aGUgc3RhdGVsZXNzIFBDRSBtb2RlbCBhbmQgdGhlDQogICBzdGF0 ZWZ1bCBQQ0UgbW9kZWwuDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFz ZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1l IG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2 YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Mon Oct 27 03:06:32 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 482031A9007; Mon, 27 Oct 2014 03:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id av6cCTswFyqt; Mon, 27 Oct 2014 03:06:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EEA71A8FD4; Mon, 27 Oct 2014 03:06:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027100629.3814.85.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 03:06:29 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/Ng_2IsdR9g05RztX9M3DdccFSHM Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-00.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 10:06:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Conveying path setup type in PCEP messages Authors : Siva Sivabalan Jan Medved Ina Minei Edward Crabbe Robert Varga Filename : draft-ietf-pce-lsp-setup-type-00.txt Pages : 7 Date : 2014-10-26 Abstract: A Path Computation Element can compute traffic engineering paths (TE paths) through a network that are subject to various constraints. Currently, TE paths are label switched paths (LSPs) which are set up using the RSVP-TE signaling protocol. However, other TE path setup methods are possible within the PCE architecture. This document proposes an extension to PCEP to allow support for different path setup methods over a given PCEP session. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-setup-type/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-lsp-setup-type-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 27 06:57:39 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4E421ACC80 for ; Mon, 27 Oct 2014 06:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9DiuGYJhSyu for ; Mon, 27 Oct 2014 06:57:10 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFB901ACCDF for ; Mon, 27 Oct 2014 06:57:03 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id q5so6507003wiv.11 for ; Mon, 27 Oct 2014 06:57:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5M79j4cZWHCnmxnbiB0vldhEFJF2xC8ZhEBcorn4DqA=; b=GMkJsI/Xrgs9m3+1Jei2/HcZ0KpxPHKuMDhLBuEtlIBpX1ENOhhvbevbS3lsmLc9+u 11Is4ed4tgXAR6iTqc7h9Tc2fAdvv9lVkuPh9DjLcE5V72NunCFgrx65iDjlFj8g+EUb bepdQ2CdS2Jzg9RCKJhAD1tNWi7AUroAQBNi2ai9srbh9Qqb/sBiRLP5ClEDn2wj0it1 qJ4WsJ5GH8GXN9todCMtvDNKVYtp0r9PnQgj2s/4FhIV1dKECtG6Zek262gKsSVHuL3S C8pb5tN4LC2PIg4QtkHAOZ5Wki7DtgyHQRDsZNRQPGlg39K4IgVcN8xivCQO37TgIksD QXWg== MIME-Version: 1.0 X-Received: by 10.194.76.70 with SMTP id i6mr23019630wjw.13.1414418222174; Mon, 27 Oct 2014 06:57:02 -0700 (PDT) Received: by 10.217.170.134 with HTTP; Mon, 27 Oct 2014 06:57:02 -0700 (PDT) In-Reply-To: References: Date: Mon, 27 Oct 2014 09:57:02 -0400 Message-ID: From: Cyril Margaria To: Ina Minei Content-Type: multipart/alternative; boundary=047d7bb0401cb25691050667e7a9 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/LIGsft7bSclx-otVZp6yx0TiJJw Cc: "pce@ietf.org" Subject: Re: [Pce] WG Last Call on draft-ietf-pce-stateful-pce-app-02 and draft-ietf-pce-stateful-pce-09 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 13:57:19 -0000 --047d7bb0401cb25691050667e7a9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Ina, Thanks, see inline for the open points. On 27 October 2014 01:57, Ina Minei wrote: > Thank you for the careful review, please see inline ###. > > [snip] >> I Have the following comment for draft-ietf-pce-stateful-pce-09: >> >> Section 2 >> The document references the following timers: >> - State Timeout Interval >> - Redelegation Timeout Interval >> >> RFC5440 defines an Appendix B. PCEP Variables, having a dedicated sectio= n >> for those variables would be better, as they are integral part of the >> extensions. >> > > ### They are discussed in the main part of the draft, their use etc is > introduced as early as page 4 of the doc. The suggested values for these > timers are added in the operational section in the appendix, where they > logically belong and I don't think we want to move them. > I think it will be easier for YANG/MIB module designers to have a small appendix for those, with recommended values repeated there. The rest of the document does not need to be changed in that regards. > >> >> Section 5.4 >> >> After the first paragraph, add: >> The State synchronization start with a LSP state report having the SYNC >> Flag in the LSP Object set to 1. >> >> Reason: This would allow for the PCC to fully resend its database after >> the Initialization phase, and clarify the PCE operation. >> > > ### This is covered in the current text and also clearly shown in figure > 1. . > It is implicit in the text,, I think making it explicit would be better for implementations. > >> >> Section 5.6.2 >> OLD >> If the PCC decides that the LSP parameters proposed in the PCUpd message >> are unacceptable, it MUST report this error by including the >> LSP-ERROR-CODE TLV (Section 7.3.3 >> > >) >> with LSP error-value=3D=C2=B3Unacceptable parameters" in the LSP object = in the >> PCRpt message to the PCE >> >> NEW >> If the PCC decides that the LSP parameters proposed in the PCUpd message >> are unacceptable, it MUST report this error by including the >> LSP-ERROR-CODE TLV (Section 7.3.3 >> > >) >> with LSP error-value=3D=C2=B3Unacceptable parameters" in the LSP object = in the >> PCRpt message to the PCE. The PCC MAY/SHOULD include the objects that we= re >> not accepted in the PCRpt message. >> >> >> Reason: If the PCC includes the objects (current PCC values) that caused >> the PCUpd to be rejected, it would help the PCE avoid resending them. A >> PCErr would allow to include the objects, a new error type would be need= ed >> but error handling from PCE side should be rather easy. Another >> possibility is having the LSP-ERROR-CODE containing a list of >> Object-Class, OT . >> >> ### While I agree in principle, I think if we go down this road we shoul= d > also include the reason > why the object was rejected to make this useful. Unless others feel > strongly, I would not add this. > I think having the mechanism would be aldready usefull with existing error messages. Having WG feedback in also welcomed. > > Section 7.3. >> Nits: Using Synchronize would be better aligned with other bits definiti= on >> >> S bit: Add: On PCUpd the R flag SHOULD (MUST?) be set to 0 on transmissi= on >> and MUST be ignored on receipt. >> > > >> R bit: Add: On PCUpd the R flag SHOULD (MUST?) be set to 0 on transmissi= on >> and MUST be ignored on receipt >> (or it is allowed on PCUpd?) >> > O bit: Add: On PCUpd the O Field SHOULD (MUST?) be set to 0 on >> transmission and MUST be ignored on receipt. >> > > ### This would preclude use of these bits in future documents, so I > prefer not to add this. > Reserved bit are usually defined as follows "Unassigned bits are considered reserved. They MUST be set to zero on transmission and MUST be ignored on receipt." So restricting those values on PCUpd in this document does not preclude another document indicating how to use them when supporting that other document (It will be likely negotiated). Moreover this allows the new defining document to make sure that those bits have a specific value when using the stateful document. > > >> Section 7.3.3. >> The error value =C5=92LSP preempted=C2=B9 could seem a bit redundant w= ith =C5=92RSVP >> signaling error=C2=B9 and the corresponding RSVP preempted error code, I >> believe the error code =C5=92LSP preempted=C2=B9 should be seen when a P= CC-local >> administrative preemption is made, and the RSVP signaling error should b= e >> used otherwise (the error node can be of value for the PCE) >> > ### I think there is value to keep preemption separate from signaling > error, and I prefer to leave them > distinct. > My comment was not much on removing it, but have the text scope them better, as they are mutually exclusive, implementation wise I would like to know when to send the PCEP preempted, and the signaling preempted. --047d7bb0401cb25691050667e7a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Ina,

Thanks, see inline for the open= points.

On 27= October 2014 01:57, Ina Minei <inaminei@google.com> wrote= :
Tha= nk you for the careful review, please see inline ###.=C2=A0

[snip]
I Have th= e following comment for draft-ietf-pce-stateful-pce-09:

Section 2The document references the following timers:
=C2=A0=C2=A0 - State Time= out Interval
=C2=A0=C2=A0 - Redelegation Timeout Interval

RFC5440= defines an Appendix B. PCEP Variables, having a dedicated section
for t= hose variables would be better, as they are integral part of the
extensi= ons.

### They are di= scussed in the main part of the draft, their use etc is introduced as early= as page 4 of the doc. The suggested values for these timers are added in t= he operational section in the appendix, where they logically belong and I d= on't think we want to move them.=C2=A0

I think it will be easier for YANG/MIB module desig= ners to have a small appendix for those, with recommended values repeated t= here. The rest of the document does not need to=C2=A0 be changed in that re= gards.

=C2=A0


Section 5.4

After the first paragraph= , add:
The State synchronization start with a LSP state report having th= e SYNC
Flag in the LSP Object set to 1.

Reason: This would allow = for the PCC to fully resend its database after
the Initialization phase,= and clarify the PCE operation.

=
### This is covered in the current text and also clearly shown = in figure 1. .=C2=A0

It is implicit in the text,, I think m= aking it explicit would be better for implementations.
=C2=A0=


Section 5.6.2
OLD
If the PCC decides that the = LSP parameters proposed in the PCUpd message
are unacceptable, it MUST r= eport this error by including the
LSP-ERROR-CODE TLV (Section 7.3.3
&= lt;https://tools.ietf.org/html/draft-ietf-pce-s= tateful-pce-09#section-7.3.3>)
with LSP error-value=3D=C2=B3Unacc= eptable parameters" in the LSP object in the
PCRpt message to the P= CE

NEW
If the PCC decides that the LSP parameters proposed in the= PCUpd message
are unacceptable, it MUST report this error by including = the
LSP-ERROR-CODE TLV (Section 7.3.3
<https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-09#section-7.3.3>)
with LSP error-value=3D=C2=B3Unacceptable parameters" in th= e LSP object in the
PCRpt message to the PCE. The PCC MAY/SHOULD include= the objects that were
not accepted in the PCRpt message.


Rea= son: If the PCC includes the objects (current PCC values) that caused
th= e PCUpd to be rejected, it would help the PCE avoid resending them. A
PC= Err would allow to include the objects, a new error type would be neededbut error handling from PCE side should be rather easy. Another
possibi= lity is having the LSP-ERROR-CODE containing a list of
Object-Class, OT = .

<= div>why the object was rejected to make this useful. Unless others feel str= ongly, I would not add this. =C2=A0


Section 7.3.Nits: Using Synchronize would be better aligned with other bits definition=

S bit: Add: On PCUpd the R flag SHOULD (MUST?) be set to 0 on trans= mission
and MUST be ignored on receipt.=C2=A0
=C2=A0
R bit: Add: On PCUpd the R flag SHOULD (MUST?) be set to 0 on= transmission
and MUST be ignored on receipt
=C2=A0 (or it is allowed= on PCUpd?)
O bit: Add: On PCUpd the O Field SHOULD (M= UST?) be set to 0 on
transmission and MUST be ignored on receipt.

### This would preclude us= e of these bits in future documents, so =C2=A0I prefer not to add this.


My comment was not much on removing it, but have the text= scope them better, as they are mutually exclusive, implementation wise I w= ould like to know when to send the PCEP preempted, and the signaling preemp= ted.


--047d7bb0401cb25691050667e7a9-- From nobody Mon Oct 27 07:35:53 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14C7C1ACDA9; Mon, 27 Oct 2014 07:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BR3uTjKNl7LR; Mon, 27 Oct 2014 07:35:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B004B1A87BA; Mon, 27 Oct 2014 07:35:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027143506.20449.83966.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 07:35:06 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/fdo5iM-4S8dBNSIB_o8KtFQCPcM Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-stateful-pce-inter-domain-lsp-00.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 14:35:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Cooperative Stateful Path Computation Element (PCE) for Inter-Domain Inter-Vendor PCE-initiated LSP Setup Authors : Xiaoping Zheng Nan Hua Wangyang Liu Bingkun Zhou Guoying Zhang Filename : draft-ietf-pce-stateful-pce-inter-domain-lsp-00.txt Pages : 12 Date : 2014-10-27 Abstract: A stateful Path Computation Element (PCE) maintains the information of Label Switched Path (LSP) and resource availability within a domain, so multiple stateful PCEs are able to provide traffic engineering inter-domain routing through cooperating with each other. This document introduces the applicability of cooperative stateful PCE for establishing inter-domain inter-vendor LSP which is initiated by PCE. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-inter-domain-lsp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-inter-domain-lsp-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 28 04:30:57 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C451A1A1B7A; Tue, 28 Oct 2014 04:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPavZfWww1TP; Tue, 28 Oct 2014 04:30:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0404F1A1BC8; Tue, 28 Oct 2014 04:30:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141028113018.1646.13752.idtracker@ietfa.amsl.com> Date: Tue, 28 Oct 2014 04:30:18 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/OTn1dw6zOJZGkHd2TikfBvU98xI Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-segment-routing-00.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 11:30:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : PCEP Extensions for Segment Routing Authors : Siva Sivabalan Jan Medved Clarence Filsfils Edward Crabbe Robert Raszuk Victor Lopez Jeff Tantsura Filename : draft-ietf-pce-segment-routing-00.txt Pages : 18 Date : 2014-10-26 Abstract: Segment Routing (SR) enables any head-end node to select any path without relying on a hop-by-hop signaling technique (e.g., LDP or RSVP-TE). It depends only on "segments" that are advertised by Link- State Interior Gateway Protocols (IGPs). A Segment Routed Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE). This document specifies extensions to the Path Computation Element Protocol (PCEP) that allow a stateful PCE to compute and initiate Traffic Engineering (TE) paths, as well as a PCC to request a path subject to certain constraint(s) and optimization criteria in SR networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-segment-routing-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 28 08:30:55 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B09701A8AD8 for ; Tue, 28 Oct 2014 08:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYv5gZdRVzxM for ; Tue, 28 Oct 2014 08:30:51 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03D911A8AAB for ; Tue, 28 Oct 2014 08:30:50 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOD37356; Tue, 28 Oct 2014 15:30:49 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 28 Oct 2014 15:30:48 +0000 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml702-chm ([10.193.5.72]) with mapi id 14.03.0158.001; Tue, 28 Oct 2014 08:30:34 -0700 From: Leeyoung To: Julien Meuric , "'JP Vasseur'" , Daniel King , "pce@ietf.org" Thread-Topic: [Pce] Building PCE Agenda for IETF 91 Thread-Index: AQHP7GNECfbpLTh1kEm5zgHPp9Y0eZxFrfwQ Date: Tue, 28 Oct 2014 15:30:33 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C412F5@dfweml706-chm> References: <21573_1413808911_5445030F_21573_2393_1_5445030E.6010808@orange.com> In-Reply-To: <21573_1413808911_5445030F_21573_2393_1_5445030E.6010808@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.227] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/pce/oBzEQ7o4Ijlay8By-nrnkxYvCb4 Subject: Re: [Pce] Building PCE Agenda for IETF 91 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 15:30:53 -0000 Hi Julien, Will you give us a slot for 10 minutes of the following two drafts (togethe= r)? - https://datatracker.ietf.org/doc/draft-lee-pce-transporting-te-data/ - https://datatracker.ietf.org/doc/draft-dhodylee-pce-pcep-te-data-extn/=20 - Presenter (Dhruv/Young) - Duration: 10 min - As follow-up from Toronto meeting (which generated some interest from the= mailing list and the face-to-face meeting), we'd like to get a slot to pre= sent a concrete proposal.=20 Thanks, Young -----Original Message----- From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of julien.meuric@orange.c= om Sent: Monday, October 20, 2014 7:42 AM To: pce@ietf.org Subject: [Pce] Building PCE Agenda for IETF 91 Dear PCE WG, As scheduled on the final IETF agenda (https://datatracker.ietf.org/meeting/91/agenda.html), the PCE WG will meet= for a one-hour session on Monday morning in Honolulu. As a result, the age= nda will be very tight. If you believe you have a presentation really requi= ring some face to face time to move forward, please respond to the chairs a= nd secretary by Sunday November 2, including: - the associated I-D, - the presenter's name, - the expected duration, - the reason why you need a face to face slot. More than ever, discussion on the list will allow us to prioritize accordin= g to the community's interest. Thanks, JP & Julien ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, veuillez= le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From nobody Tue Oct 28 10:23:14 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5FE41A90C1; Tue, 28 Oct 2014 10:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgdTCFAssKv2; Tue, 28 Oct 2014 10:23:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF471A90BC; Tue, 28 Oct 2014 10:23:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141028172308.26988.98309.idtracker@ietfa.amsl.com> Date: Tue, 28 Oct 2014 10:23:08 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/yAUpsiwK_OkK2KL8_OA1KpFgSYg Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-wson-routing-wavelength-15.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 17:23:09 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : PCEP Requirements for WSON Routing and Wavelength Assignment Author(s) : Y. Lee, et al Filename : draft-ietf-pce-wson-routing-wavelength Pages : 13 Date : 2014-10-28 This memo provides application-specific requirements for the Path Computation Element communication Protocol (PCEP) for the support of 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. Requirements for PCEP extensions in support of optical impairments will be addressed in a separate document. A URL for this Internet-Draft is: https://www.ietf.org/internet-drafts/draft-ietf-pce-wson-routing-wavelength-15.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pce-wson-routing-wavelength"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2014-10-28102307.I-D@ietf.org> --NextPart-- From nobody Tue Oct 28 13:05:33 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9731ACE31 for ; Tue, 28 Oct 2014 13:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X16xSRp1fQRz for ; Tue, 28 Oct 2014 13:05:22 -0700 (PDT) Received: from smtpjc.telefonica.com (smtpjc.telefonica.com [81.47.204.76]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28AFF1ACE02 for ; Tue, 28 Oct 2014 13:04:29 -0700 (PDT) Received: from smtpjc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 72A7A2F01A7; Tue, 28 Oct 2014 21:04:26 +0100 (CET) Received: from ESTGVMSP107.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtpjc.telefonica.com (Postfix) with ESMTPS id 5BC692F019B; Tue, 28 Oct 2014 21:04:26 +0100 (CET) Received: from emea01-db3-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.92.6.52) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 28 Oct 2014 21:04:26 +0100 Received: from DB3PR06MB252.eurprd06.prod.outlook.com (10.141.5.153) by DB3PR06MB252.eurprd06.prod.outlook.com (10.141.5.153) with Microsoft SMTP Server (TLS) id 15.1.6.9; Tue, 28 Oct 2014 20:04:24 +0000 Received: from DB3PR06MB252.eurprd06.prod.outlook.com ([10.141.5.153]) by DB3PR06MB252.eurprd06.prod.outlook.com ([10.141.5.153]) with mapi id 15.01.0006.000; Tue, 28 Oct 2014 20:04:24 +0000 From: DIEGO LOPEZ GARCIA To: Julien Meuric , JP Vasseur , Daniel King Thread-Topic: [Pce] Building PCE Agenda for IETF 91 Thread-Index: AQHP7GNDJQ7cT0xlEkeWys+cYgu2bZxF+/QA Date: Tue, 28 Oct 2014 20:04:24 +0000 Message-ID: <6531C0DE-9F2F-4E03-97F5-7A9BD8A7DB41@telefonica.com> References: <21573_1413808911_5445030F_21573_2393_1_5445030E.6010808@orange.com> In-Reply-To: <21573_1413808911_5445030F_21573_2393_1_5445030E.6010808@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [176.84.213.147] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DB3PR06MB252; x-forefront-prvs: 0378F1E47A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(24454002)(252514010)(51704005)(164054003)(50986999)(87936001)(66066001)(107046002)(99396003)(120916001)(106116001)(2656002)(95666004)(106356001)(105586002)(76176999)(15202345003)(54356999)(122556002)(83716003)(85852003)(85306004)(33656002)(64706001)(40100003)(76482002)(36756003)(92566001)(92726001)(101416001)(19580395003)(19580405001)(82746002)(4396001)(31966008)(21056001)(97736003)(15975445006)(20776003)(46102003)(80022003)(86362001)(104396001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR06MB252; H:DB3PR06MB252.eurprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: telefonica.com X-TM-AS-MML: No Archived-At: http://mailarchive.ietf.org/arch/msg/pce/OIFOYY1JOAlQPXaWY--J4vmuywQ Cc: "pce@ietf.org" Subject: Re: [Pce] Building PCE Agenda for IETF 91 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 20:05:27 -0000 Hi, I think the recent changes we made to the PCE on TLS draft are worth some F= 2F discussion. Please find the data you requested below: Draft: draft-ietf-pce-pceps-02 Presenter: Diego Lopez Expected duration: 10 minutes Reason: A new mechanism (the StartTLS message) for starting TLS within a PC= EP connection is proposed, together with a detailed error management for it= . This mechanism addresses the requirements of the transport experts contac= ted by the authors and chairs. Be goode, On 20 Oct 2014, at 14:41 , julien.meuric@orange.com wrote: > Dear PCE WG, > > As scheduled on the final IETF agenda (https://datatracker.ietf.org/meeti= ng/91/agenda.html), the PCE WG will meet for a one-hour session on Monday m= orning in Honolulu. As a result, the agenda will be very tight. If you beli= eve you have a presentation really requiring some face to face time to move= forward, please respond to the chairs and secretary by Sunday November 2, = including: > - the associated I-D, > - the presenter's name, > - the expected duration, > - the reason why you need a face to face slot. > > More than ever, discussion on the list will allow us to prioritize accord= ing to the community's interest. > > Thanks, > > JP & Julien > > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce -- PLEASE NOTE MY NEW EMAIL ADDRESS "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=C3=B3n privilegiada o confidencial y es para uso exc= lusivo de la persona o entidad de destino. Si no es usted. el destinatario = indicado, queda notificado de que la lectura, utilizaci=C3=B3n, divulgaci= =C3=B3n y/o copia sin autorizaci=C3=B3n puede estar prohibida en virtud de = la legislaci=C3=B3n vigente. Si ha recibido este mensaje por error, le roga= mos que nos lo comunique inmediatamente por esta misma v=C3=ADa y proceda a= su destrucci=C3=B3n. The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=C3=A1= rio, pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9= para uso exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vo= ssa senhoria o destinat=C3=A1rio indicado, fica notificado de que a leitura= , utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem autoriza= =C3=A7=C3=A3o pode estar proibida em virtude da legisla=C3=A7=C3=A3o vigent= e. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imedi= atamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o From nobody Wed Oct 29 02:43:43 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6961A7025 for ; Wed, 29 Oct 2014 02:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XsGEZjfGDf66 for ; Wed, 29 Oct 2014 02:43:36 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0361C1A7021 for ; Wed, 29 Oct 2014 02:43:34 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLB20437; Wed, 29 Oct 2014 09:43:33 +0000 (GMT) Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 29 Oct 2014 09:43:32 +0000 Received: from szxeml556-mbs.china.huawei.com ([169.254.4.112]) by szxeml418-hub.china.huawei.com ([10.82.67.157]) with mapi id 14.03.0158.001; Wed, 29 Oct 2014 17:43:24 +0800 From: Dhruv Dhody To: "inaminei@google.com" Thread-Topic: [Pce] NULL PCUpdate message Thread-Index: Ac/j73aNrn9wH23VRJKUwPUOGQQ4Tf//gqIA//7g7mD/35Kq8A== Date: Wed, 29 Oct 2014 09:43:23 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B8660F451@szxeml556-mbs.china.huawei.com> References: <23CE718903A838468A8B325B80962F9B86605914@szxeml556-mbs.china.huawei.com> In-Reply-To: <23CE718903A838468A8B325B80962F9B86605914@szxeml556-mbs.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.146.248] Content-Type: multipart/alternative; boundary="_000_23CE718903A838468A8B325B80962F9B8660F451szxeml556mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/pce/lEkYaqZ6Wgo9LgpGac027ukTMSE Cc: pce , Cyril Margaria Subject: Re: [Pce] NULL PCUpdate message X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 09:43:39 -0000 --_000_23CE718903A838468A8B325B80962F9B8660F451szxeml556mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSW5hLA0KDQpXaGF0IGlzIHRoZSBwb3NpdGlvbiBvZiB0aGUgYXV0aG9y4oCZcyBvbiB0aGlz IGlzc3VlPw0KSSBob3BlIHRoaXMgY2FuIGJlIGNsYXJpZmllZCBpbiB0aGUgbmV4dCByZXZpc2lv biBvZiBkcmFmdC1pZXRmLXBjZS1zdGF0ZWZ1bC1wY2UuDQoNCipUaGlzIGlzIGFuIGludGVyb3Bl cmFiaWxpdHkgaXNzdWUsIHdlIHdvdWxkIHJlYWxseSBiZW5lZml0IGZyb20gYSBjbGFyaWZpY2F0 aW9uIGluIHRoZSBzcGVjaWZpY2F0aW9uKg0KDQpSZWdhcmRzLA0KRGhydXYNCg0KRnJvbTogUGNl IFttYWlsdG86cGNlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEaHJ1diBEaG9keQ0K U2VudDogMTAgT2N0b2JlciAyMDE0IDEwOjE3DQpUbzogQ3lyaWwgTWFyZ2FyaWE7IFJhbWFuYSBZ YXJsYWdhZGRhDQpDYzogcGNlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1BjZV0gTlVMTCBQQ1Vw ZGF0ZSBtZXNzYWdlDQoNCkhpIEN5cmlsLCBSYW1hbmEsDQoNCkkgYWdyZWUgd2l0aCB0aGlzLCBk dXJpbmcgcmV0dXJuaW5nIGRlbGVnYXRpb24g4oCTDQpPbiB0aGUgcmVjZWl2aW5nIHNpZGUsIHdl IGlnbm9yZSB0aGUgY29udGVudC4NCk9uIHRoZSBzZW5kaW5nIHNpZGUsIHdlIHB1dCBlbXB0eSBF Uk8gb2JqZWN0IHdpdGggbm8gc3Vib2JqZWN0Lg0KDQpUaGUgc2FtZSBwcmluY2lwbGUgaXMgYWxz byBhcHBsaWNhYmxlIHRvIHRoZSBhZG1pbiBkb3duIGFzIHBlciBteSBtYWlsIGVhcmxpZXI6IGh0 dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9wY2UvY3VycmVudC9tc2cwNDAwMC5o dG1sDQoNCkl0IHNob3VsZCBhbHNvIHRvIGJlIG5vdGVkIHRoYXQgdGhpcyBpcyBhcHBsaWNhYmxl IHRvIFBDUnB0IG1lc3NhZ2UgYXMgd2VsbCB3aGVyZSBpbiBzb21lIGNhc2Ugd2Ugd291bGQgbm90 IGhhdmUgdGhlIEVSTyBvYmplY3QgKGZvciBleC4gRGVsZWdhdGlvbiBvZiBqdXN0IGNvbmZpZ3Vy ZWQsIG5vdC1zaWduYWxlZCBMU1AgOyBhZG1pbiBkb3duIG9mIExTUCBldGMpLg0KSW4gdGhlc2Ug Y2FzZXMgYXMgd2VsbCAtDQpPbiB0aGUgcmVjZWl2aW5nIHNpZGUsIHdlIGlnbm9yZSB0aGUgY29u dGVudC4NCk9uIHRoZSBzZW5kaW5nIHNpZGUsIHdlIHB1dCBlbXB0eSBFUk8gb2JqZWN0IHdpdGgg bm8gc3Vib2JqZWN0Lg0KDQpUaHVzLCBhcGFydCBmb3IgY3lyaWzigJlzIHN1Z2dlc3RlZCB0ZXh0 LCB3ZSBjYW4gYWRkIGdlbmVyaWMgdGV4dCBpbiBQQ1JwdC9QY1VwZCBtZXNzYWdlIHNlY3Rpb24g KDYuMSwgNi4yKSAtDQoNCkluIGNhc2Ugb2YgYW4gTFNQIHRoYXQgaXMgbm90IHlldCBzaWduYWxl ZCBvciBhZG1pbmlzdHJhdGl2ZWx5Lw0Kb3BlcmF0aW9uYWxseSBkb3duIG9uIHJlY2VpdmluZyBz dWNoIHN0YXR1cyB2aWEgUENScHQgbWVzc2FnZSB0aGUNCmNvbnRlbnQgb2YgRVJPIG9iamVjdCBp cyBpZ25vcmVkIGF0IFBDRSwgd2hpbGUgdGhlIFBDQyBTSE9VTEQNCnNlbmQgYW4gZW1wdHkgRVJP IG9iamVjdCB3aXRoIG5vIHN1Yi1vYmplY3RzIGluIFBDUnB0IG1lc3NhZ2UuDQoNCg0KSW4gY2Fz ZSBvZiBhbiBMU1AgdGhhdCBpcyBhZG1pbmlzdHJhdGl2ZWx5IGRvd24gb3IgcmV0dXJuaW5nIG9m DQpkZWxlZ2F0aW9uIHZpYSBQQ1VwZCBtZXNzYWdlIHRoZSBjb250ZW50IG9mIEVSTyBvYmplY3Qg aXMNCmlnbm9yZWQgYXQgUENDLCB3aGlsZSB0aGUgUENFIFNIT1VMRCBzZW5kIGFuIGVtcHR5IEVS TyBvYmplY3QNCndpdGggbm8gc3ViLW9iamVjdHMgaW4gUENVcGQgbWVzc2FnZS4NCg0KV2hhdCBk b2VzIHRoZSBXRyB0aGluayBhYm91dCB0aGlzPw0KDQpSZWdhcmRzLA0KRGhydXYNCg0KRnJvbTog UGNlIFttYWlsdG86cGNlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBDeXJpbCBNYXJn YXJpYQ0KU2VudDogMTAgT2N0b2JlciAyMDE0IDAwOjM0DQpUbzogUmFtYW5hIFlhcmxhZ2FkZGEN CkNjOiBwY2VAaWV0Zi5vcmc8bWFpbHRvOnBjZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbUGNl XSBOVUxMIFBDVXBkYXRlIG1lc3NhZ2UNCg0KSGksDQpGcm9tIHRoZSBkZWZpbml0aW9uLCBhbiBl bXB0eSBQQ1VwZCBtdXN0IGNvbnRhaW4gYW4gRVJPLCBJIHRoaW5rIHRoZSBxdWVzdGlvbiBib2ls cyBkb3duIHRvIGhhdmluZyBhbiBlbXB0eSBFUk8gb3IgYW4gRVJPIHRoYXQgbWlycm9ycyB0aGUg bGFzdCBFUk8gcmVjZWl2ZWQuIFRoaXMgaXMgdGhlIG9ubHkgcmVxdWlyZWQgcGFyYW1ldGVyLg0K SSB3b3VsZCBwcm9wb3NlIHRoZSBmb2xsb3dpbmcgdGV4dCB0byBjbGFyaWZ5Og0KDQpTZWN0aW9u IDUuNS4zOg0KQWRkOiBVcG9uIHJlY2VwdGlvbiBvZiBhIFBDVXBkIHdpdGggRD0wIGEgUENDIE1V U1QgaWdub3JlIHRoZSBMU1Agb2JqZWN0IEEgYml0IGFuZCAgdGhlIEVSTyBvYmplY3QgY29udGVu dC4NCldpdGggdGhhdCB0aGUgRW1wdHkgKEkgd291bGQgbm90IGludHJvZHVjZSBhIE5VTEwgbWVz c2FnZSkgUENVcGQgY29udGFpbnMgU1JQLCBMU1Agd2l0aCBQTFNQLUlELCBhbGwgZmxhZ3MgdG8g MCwgYW5kIGFuIGVtcHR5IEVSTy4NCg0KQnINCkN5cmlsDQoNCg0KT24gOSBPY3RvYmVyIDIwMTQg MTQ6MzMsIFJhbWFuYSBZYXJsYWdhZGRhIDxyeWFybGFnYUBqdW5pcGVyLm5ldDxtYWlsdG86cnlh cmxhZ2FAanVuaXBlci5uZXQ+PiB3cm90ZToNCkhpIEFsbCwNCg0KSSBoYXZlIGEgcXVlc3Rpb25z IG9uIHNlbmRpbmcgdGhlIFBDVXBkYXRlIG1lc3NhZ2UgdG8gZGVsZWdhdGUgYW4gTFNQIGZyb20N ClBDRSB0byBQQ0MuIENhbiBzb21lYm9keSBwbGVhc2UgaGVscCBtZSBoZXJlIHRvIHVuZGVyc3Rh bmQgdGhlIFBDVXBkYXRlIG1lc3NhZ2UNCkZvciBkZWxlZ2F0aW5nIGFuIExTUCBiYWNrIHRvIFBD Qy4NCg0KUmUtZGVsZWdhdGlvbiBzZWN0aW9uIHRhbGtzIGFib3V0IGVtcHR5IG1lc3NhZ2UgYnV0 IHRoZSBQQ1VwZGF0ZSByZXF1ZXN0IG1lc3NhZ2UgZGVmaW5pdGlvbg0KU2F5cyB0aGF0IGFsbCAg TFNQIHBhcmFtZXRlcnMgbXVzZSBiZSBzZW50Lg0KDQoxLiAgICAgICBQQ0UgcmVxdWlyZXMgdG8g c2VuZCBhbiBFTVBUWSBMU1AgVXBkYXRlIG1lc3NhZ2UgdG8gZGVsZWdhdGUgYW4gTFNQICBiYWNr IHRvIFBDQy4NCldoYXQgaXMgYW4gYWNjZXB0YWJsZSBlbXB0eSBMU1AgbWVzc2FnZT8NCg0KUGxl YXNlIHJlZmVyIHRvIHNlY3Rpb24gNS41LjUgb2YgZHJhZnQg4oCcUENFUCBleHRlbnNpb25zIGZv ciBzdGF0ZWZ1bCBQQ0XigJ0gZm9yIHByb2NlZHVyZSBvZiByZXR1cm5pbmcNCkRlbGVnYXRpb24N Cg0KMi4gICAgICAgU2VjdGlvbiA2LjIgb2YgZHJhZnQg4oCcUENFUCBleHRlbnNpb25zIGZvciBz dGF0ZWZ1bCBQQ0XigJ0gZGVmaW5lcyB0aGUgUENVcGQgbWVzc2FnZS4NCsK3ICAgICAgICAgVGhy ZWUgbWFuZGF0b3J5IG9iamVjdHMgbXVzdCBiZSBpbmNsdWRlZCBpbiBlYWNoIFBDVXBkIG1lc3Nh Z2UuIFRoZSBlcnJvciBjb2Rlcw0KQXJlIGRlZmluZWQgdG8gbm90aWZ5IHRoZSBzZW5kZXIgaWYg YW55IG9mIHRoZSBtYW5kYXRvcnkgb2JqZWN0cyBtaXNzaW5nIGluIHRoZSBQQ1VwZGF0ZQ0KTWVz c2FnZS4NCsK3ICAgICAgICAgQWxzbywgVGhlIGRyYWZ0IHNheXMgKGNvcGllZCB0ZXh0IGZyb20g c2VjdGlvbiA2LjIpDQrCtw0K4oCcQW4gTFNQIFVwZGF0ZSBSZXF1ZXN0IE1VU1QgY29udGFpbiBh bGwgTFNQIHBhcmFtZXRlcnMgdGhhdCBhIFBDRSB3aXNoZXMgdG8NCiAgIGJlIHNldCBmb3IgdGhl IExTUC4gQSBQQ0MgTUFZIHNldCBtaXNzaW5nIHBhcmFtZXRlcnMgZnJvbSBsb2NhbGx5DQogICBj b25maWd1cmVkIGRlZmF1bHRzLiAgSWYgdGhlIExTUCBzcGVjaWZpZWQgaW4gdGhlIFVwZGF0ZSBS ZXF1ZXN0IGlzDQogICBhbHJlYWR5IHVwLCBpdCB3aWxsIGJlIHJlLXNpZ25hbGVkLg0KDQoNCkEg Y2xlYXIgZGVmaW5pdGlvbiBvZiBOVUxMIG1lc3NhZ2Ugd291bGQgaGVscCB1cyBoZXJlLg0KDQot dGhhbmtzIGluIGFkdmFuY2UNCi1yYW1hbmENCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpQY2UgbWFpbGluZyBsaXN0DQpQY2VAaWV0Zi5vcmc8 bWFpbHRvOlBjZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcGNlDQoNCg== --_000_23CE718903A838468A8B325B80962F9B8660F451szxeml556mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OkNhbmRhcmE7DQoJcGFub3NlLTE6MiAxNCA1IDIgMyAzIDMgMiAyIDQ7fQ0K LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5N c29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNl dGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5z LXNlcmlmIjt9DQpzcGFuLmhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh bmRhcmEiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRD aGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FuZGFyYSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiM5OTMzNjY7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5p dGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE1OTU0MDA5NTsNCgltc28tbGlzdC10 ZW1wbGF0ZS1pZHM6LTE3ODkzMjk2ODY7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC10 YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC10YWItc3RvcDo3 Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30N CkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBs MDpsZXZlbDUNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw2 DQoJe21zby1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28t bGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLXRh Yi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC10YWItc3RvcDoz MjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0O30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjEzNjI1MDkzODY7DQoJbXNvLWxpc3Qt dGVtcGxhdGUtaWRzOi03MDQ4NjUwNTY7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLXRhYi1zdG9wOjcyLjBwdDsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9 DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3Qg bDE6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVs NQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNv LWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC10 YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6 Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjMyNC4wcHQ7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6MTQ0NDk2MjY2MDsNCgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6LTIxMDIzOTAzMjt9DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0 OjI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNv LWxldmVsLXRhYi1zdG9wOjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDMNCgl7bXNvLWxldmVsLXRh Yi1zdG9wOjEwOC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDI6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDox NDQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0O30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9 DQpAbGlzdCBsMjpsZXZlbDYNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3Qg bDI6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwyOmxldmVs OA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDkNCgl7bXNv LWxldmVsLXRhYi1zdG9wOjMyNC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDMNCgl7bXNvLWxpc3QtaWQ6MTQ2ODg2 Mjk0ODsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6NjE4NjY2NzMyO30NCkBsaXN0IGwzOmxldmVs MQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWwyDQoJe21zby1sZXZlbC10 YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDM6bGV2ZWwzDQoJe21zby1sZXZlbC10YWItc3RvcDox MDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0O30NCkBsaXN0IGwzOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9 DQpAbGlzdCBsMzpsZXZlbDUNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3Qg bDM6bGV2ZWw2DQoJe21zby1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwzOmxldmVs Nw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMzpsZXZlbDgNCgl7bXNv LWxldmVsLXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDM6bGV2ZWw5DQoJe21zby1sZXZlbC10 YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdp bi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYW5kYXJhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Izk5MzM2NiI+SGkg SW5hLA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FuZGFyYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM5OTMzNjYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbmRhcmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojOTkzMzY2Ij5XaGF0IGlzIHRoZSBwb3NpdGlvbiBvZiB0aGUgYXV0aG9y4oCZcyBv biB0aGlzIGlzc3VlPw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FuZGFy YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM5OTMzNjYiPkkgaG9wZSB0aGlz IGNhbiBiZSBjbGFyaWZpZWQgaW4gdGhlIG5leHQgcmV2aXNpb24gb2YgZHJhZnQtaWV0Zi1wY2Ut c3RhdGVmdWwtcGNlLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FuZGFy YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM5OTMzNjYiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbmRhcmEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojOTkzMzY2Ij4qPGI+VGhpcyBpcyBhbiBpbnRlcm9wZXJhYmlsaXR5 IGlzc3VlLCB3ZSB3b3VsZCByZWFsbHkgYmVuZWZpdCBmcm9tIGEgY2xhcmlmaWNhdGlvbiBpbiB0 aGUgc3BlY2lmaWNhdGlvbjwvYj4qPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FuZGFyYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM5OTMzNjYiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbmRhcmEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojOTkzMzY2Ij5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbmRhcmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojOTkzMzY2Ij5EaHJ1djxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bmRhcmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojOTkzMzY2Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiBQY2UgW21haWx0bzpwY2UtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBP ZiA8L2I+RGhydXYgRGhvZHk8YnI+DQo8Yj5TZW50OjwvYj4gMTAgT2N0b2JlciAyMDE0IDEwOjE3 PGJyPg0KPGI+VG86PC9iPiBDeXJpbCBNYXJnYXJpYTsgUmFtYW5hIFlhcmxhZ2FkZGE8YnI+DQo8 Yj5DYzo8L2I+IHBjZUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1BjZV0gTlVM TCBQQ1VwZGF0ZSBtZXNzYWdlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FuZGFyYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIEN5 cmlsLCBSYW1hbmEsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FuZGFyYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbmRhcmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGFncmVlIHdpdGggdGhpcywgZHVyaW5nIHJldHVybmlu ZyBkZWxlZ2F0aW9uIOKAkw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fu ZGFyYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk9uIHRoZSBy ZWNlaXZpbmcgc2lkZSwgd2UgaWdub3JlIHRoZSBjb250ZW50Lg0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FuZGFyYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPk9uIHRoZSBzZW5kaW5nIHNpZGUsIHdlIHB1dCBlbXB0eSBFUk8gb2JqZWN0 IHdpdGggbm8gc3Vib2JqZWN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bmRhcmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYW5kYXJhJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIHNhbWUgcHJpbmNpcGxlIGlzIGFsc28g YXBwbGljYWJsZSB0byB0aGUgYWRtaW4gZG93biBhcyBwZXIgbXkgbWFpbCBlYXJsaWVyOg0KPGEg aHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3BjZS9jdXJyZW50L21z ZzA0MDAwLmh0bWwiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9wY2UvY3Vy cmVudC9tc2cwNDAwMC5odG1sPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbmRhcmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYW5kYXJhJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SXQgc2hvdWxkIGFsc28gdG8gYmUgbm90 ZWQgdGhhdCB0aGlzIGlzIGFwcGxpY2FibGUgdG8gUENScHQgbWVzc2FnZSBhcyB3ZWxsIHdoZXJl IGluIHNvbWUgY2FzZSB3ZSB3b3VsZCBub3QgaGF2ZSB0aGUgRVJPIG9iamVjdCAoZm9yIGV4LiBE ZWxlZ2F0aW9uIG9mIGp1c3QNCiBjb25maWd1cmVkLCBub3Qtc2lnbmFsZWQgTFNQIDsgYWRtaW4g ZG93biBvZiBMU1AgZXRjKS4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fu ZGFyYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkluIHRoZXNl IGNhc2VzIGFzIHdlbGwgLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbmRh cmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5PbiB0aGUgcmVj ZWl2aW5nIHNpZGUsIHdlIGlnbm9yZSB0aGUgY29udGVudC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbmRhcmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5PbiB0aGUgc2VuZGluZyBzaWRlLCB3ZSBwdXQgZW1wdHkgRVJPIG9iamVjdCB3 aXRoIG5vIHN1Ym9iamVjdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYW5k YXJhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FuZGFyYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRodXMsIGFwYXJ0IGZvciBjeXJpbOKAmXMgc3Vn Z2VzdGVkIHRleHQsIHdlIGNhbiBhZGQgZ2VuZXJpYyB0ZXh0IGluIFBDUnB0L1BjVXBkIG1lc3Nh Z2Ugc2VjdGlvbiAoNi4xLCA2LjIpIC0NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbmRhcmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjojMUY0OTdEIj5JbiBjYXNlIG9mIGFuIExTUCB0aGF0IGlzIG5vdCB5ZXQgc2lnbmFs ZWQgb3IgYWRtaW5pc3RyYXRpdmVseS88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5vcGVyYXRpb25hbGx5IGRvd24gb24g cmVjZWl2aW5nIHN1Y2ggc3RhdHVzIHZpYSBQQ1JwdCBtZXNzYWdlIHRoZQ0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Y29udGVudCBvZiBFUk8gb2JqZWN0IGlzIGlnbm9yZWQgYXQgUENFLCB3aGlsZSB0aGUgUENDIFNI T1VMRA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6IzFGNDk3RCI+c2VuZCBhbiBlbXB0eSBFUk8gb2JqZWN0IHdpdGggbm8gc3ViLW9i amVjdHMgaW4gUENScHQgbWVzc2FnZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkluIGNhc2Ugb2YgYW4gTFNQIHRoYXQgaXMgYWRtaW5pc3RyYXRpdmVs eSBkb3duIG9yIHJldHVybmluZyBvZjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmRlbGVnYXRpb24gdmlhIFBDVXBkIG1l c3NhZ2UgdGhlIGNvbnRlbnQgb2YgRVJPIG9iamVjdCBpcw0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+aWdub3JlZCBh dCBQQ0MsIHdoaWxlIHRoZSBQQ0UgU0hPVUxEIHNlbmQgYW4gZW1wdHkgRVJPIG9iamVjdA0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+d2l0aCBubyBzdWItb2JqZWN0cyBpbiBQQ1VwZCBtZXNzYWdlLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbmRhcmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYW5kYXJhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ V2hhdCBkb2VzIHRoZSBXRyB0aGluayBhYm91dCB0aGlzPw0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FuZGFyYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbmRh cmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbmRhcmEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5EaHJ1djxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbmRhcmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4w cHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1 QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiBQY2UgWzxhIGhyZWY9Im1haWx0bzpwY2UtYm91bmNlc0Bp ZXRmLm9yZyI+bWFpbHRvOnBjZS1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBP ZiA8L2I+Q3lyaWwgTWFyZ2FyaWE8YnI+DQo8Yj5TZW50OjwvYj4gMTAgT2N0b2JlciAyMDE0IDAw OjM0PGJyPg0KPGI+VG86PC9iPiBSYW1hbmEgWWFybGFnYWRkYTxicj4NCjxiPkNjOjwvYj4gPGEg aHJlZj0ibWFpbHRvOnBjZUBpZXRmLm9yZyI+cGNlQGlldGYub3JnPC9hPjxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW1BjZV0gTlVMTCBQQ1VwZGF0ZSBtZXNzYWdlPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5IaSwgPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+RnJvbSB0aGUgZGVmaW5pdGlvbiwgYW4gZW1wdHkgUENVcGQgbXVzdCBjb250YWlu IGFuIEVSTywgSSB0aGluayB0aGUgcXVlc3Rpb24gYm9pbHMgZG93biB0byBoYXZpbmcgYW4gZW1w dHkgRVJPIG9yIGFuIEVSTyB0aGF0IG1pcnJvcnMgdGhlIGxhc3QgRVJPIHJlY2VpdmVkLiBUaGlz IGlzIHRoZSBvbmx5IHJlcXVpcmVkIHBhcmFtZXRlci4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdvdWxkIHByb3Bvc2UgdGhlIGZvbGxvd2luZyB0ZXh0 IHRvIGNsYXJpZnk6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxicj4NClNlY3Rpb24gNS41LjM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+QWRkOiBVcG9uIHJlY2VwdGlv biBvZiBhIFBDVXBkIHdpdGggRD0wIGEgUENDIE1VU1QgaWdub3JlIHRoZSBMU1Agb2JqZWN0IEEg Yml0IGFuZCZuYnNwOyB0aGUgRVJPIG9iamVjdCBjb250ZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaXRoIHRoYXQgdGhlIEVtcHR5IChJIHdvdWxkIG5v dCBpbnRyb2R1Y2UgYSBOVUxMIG1lc3NhZ2UpIFBDVXBkIGNvbnRhaW5zIFNSUCwgTFNQIHdpdGgg UExTUC1JRCwgYWxsIGZsYWdzIHRvIDAsIGFuZCBhbiBlbXB0eSBFUk8uPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ccjxi cj4NCkN5cmlsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gOSBPY3RvYmVyIDIwMTQgMTQ6MzMs IFJhbWFuYSBZYXJsYWdhZGRhICZsdDs8YSBocmVmPSJtYWlsdG86cnlhcmxhZ2FAanVuaXBlci5u ZXQiIHRhcmdldD0iX2JsYW5rIj5yeWFybGFnYUBqdW5pcGVyLm5ldDwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+SGkgQWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkkgaGF2ZSBhIHF1ZXN0aW9u cyBvbiBzZW5kaW5nIHRoZSBQQ1VwZGF0ZSBtZXNzYWdlIHRvIGRlbGVnYXRlIGFuIExTUCBmcm9t PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlBDRSB0byBQ Q0MuIENhbiBzb21lYm9keSBwbGVhc2UgaGVscCBtZSBoZXJlIHRvIHVuZGVyc3RhbmQgdGhlIFBD VXBkYXRlIG1lc3NhZ2U8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+Rm9yIGRlbGVnYXRpbmcgYW4gTFNQIGJhY2sgdG8gUENDLjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+UmUtZGVsZWdhdGlvbiBzZWN0aW9uIHRhbGtz IGFib3V0IGVtcHR5IG1lc3NhZ2UgYnV0IHRoZSBQQ1VwZGF0ZSByZXF1ZXN0IG1lc3NhZ2UgZGVm aW5pdGlvbjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5T YXlzIHRoYXQgYWxsJm5ic3A7IExTUCBwYXJhbWV0ZXJzIG11c2UgYmUgc2VudC48L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttYXJnaW4tbGVmdDowY207dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEg bGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQg JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPlBDRSByZXF1aXJlcyB0byBzZW5kIGFuIEVNUFRZIExTUCBVcGRhdGUgbWVz c2FnZSB0byBkZWxlZ2F0ZSBhbiBMU1AmbmJzcDsgYmFjayB0byBQQ0MuDQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50 OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5XaGF0IGlzIGFuIGFjY2VwdGFi bGUgZW1wdHkgTFNQIG1lc3NhZ2U/PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50 OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5QbGVhc2UgcmVmZXIgdG8gc2Vj dGlvbiA1LjUuNSBvZiBkcmFmdCDigJxQQ0VQIGV4dGVuc2lvbnMgZm9yIHN0YXRlZnVsIFBDReKA nSBmb3IgcHJvY2VkdXJlIG9mIHJldHVybmluZzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRl eHQtaW5kZW50OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5EZWxlZ2F0aW9u PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MGNtO3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6 bDIgbGV2ZWwxIGxmbzQiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4yLjxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TZWN0aW9uIDYuMiBvZiBkcmFmdCDigJxQQ0VQIGV4dGVu c2lvbnMgZm9yIHN0YXRlZnVsIFBDReKAnSBkZWZpbmVzIHRoZSBQQ1VwZCBtZXNzYWdlLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDowY207 dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMyBsZXZlbDEgbGZvNiI+DQo8IVtpZiAhc3Vw cG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1i b2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4w cHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRocmVlIG1hbmRhdG9yeSBvYmplY3RzIG11c3Qg YmUgaW5jbHVkZWQgaW4gZWFjaCBQQ1VwZCBtZXNzYWdlLiBUaGUgZXJyb3IgY29kZXM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5BcmUgZGVmaW5lZCB0byBub3RpZnkgdGhlIHNlbmRlciBpZiBhbnkg b2YgdGhlIG1hbmRhdG9yeSBvYmplY3RzIG1pc3NpbmcgaW4gdGhlIFBDVXBkYXRlDQo8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+TWVzc2FnZS48L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21hcmdpbi1sZWZ0OjBjbTt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwxIGxl dmVsMSBsZm84Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+ wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwv c3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QWxzbywg VGhlIGRyYWZ0IHNheXMgKGNvcGllZCB0ZXh0IGZyb20gc2VjdGlvbiA2LjIpPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjBjbTt0ZXh0LWlu ZGVudDotMTguMHB0O21zby1saXN0OmwxIGxldmVsMSBsZm84Ij4NCjwhW2lmICFzdXBwb3J0TGlz dHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+PHNw YW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij7igJxBbiBMU1AgVXBkYXRlIFJlcXVlc3Qg TVVTVCBjb250YWluIGFsbCBMU1AgcGFyYW1ldGVycyB0aGF0IGEgUENFIHdpc2hlcyB0bzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgYmUgc2V0IGZvciB0aGUgTFNQLiBBIFBDQyBNQVkgc2V0IG1p c3NpbmcgcGFyYW1ldGVycyBmcm9tIGxvY2FsbHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGNv bmZpZ3VyZWQgZGVmYXVsdHMuJm5ic3A7IElmIHRoZSBMU1Agc3BlY2lmaWVkIGluIHRoZSBVcGRh dGUgUmVxdWVzdCBpczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgYWxyZWFkeSB1cCwgaXQgd2ls bCBiZSByZS1zaWduYWxlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QSBjbGVhciBkZWZpbml0aW9uIG9mIE5VTEwg bWVzc2FnZSB3b3VsZCBoZWxwIHVzIGhlcmUuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4tdGhhbmtzIGluIGFkdmFuY2U8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojODg4 ODg4Ij4tcmFtYW5hPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM4ODg4ODgiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojODg4ODg4Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6Izg4ODg4OCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM4ODg4ODgi PiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojODg4ODg4Ij48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NClBjZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86UGNl QGlldGYub3JnIj5QY2VAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wY2UiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BjZTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_23CE718903A838468A8B325B80962F9B8660F451szxeml556mbschi_-- From nobody Fri Oct 31 16:32:37 2014 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAF3F1A873E; Fri, 31 Oct 2014 16:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbOMhIbmKhuP; Fri, 31 Oct 2014 16:32:31 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id E43B81A8747; Fri, 31 Oct 2014 16:32:29 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 88702181C98; Fri, 31 Oct 2014 16:31:37 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20141031233137.88702181C98@rfc-editor.org> Date: Fri, 31 Oct 2014 16:31:37 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/pce/nQmwz__y4cidP2VLmknZ5a0BtBE Cc: drafts-update-ref@iana.org, pce@ietf.org, rfc-editor@rfc-editor.org Subject: [Pce] RFC 7399 on Unanswered Questions in the Path Computation Element Architecture X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 23:32:33 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7399 Title: Unanswered Questions in the Path Computation Element Architecture Author: A. Farrel, D. King Status: Informational Stream: IETF Date: October 2014 Mailbox: adrian@olddog.co.uk, daniel@olddog.co.uk Pages: 29 Characters: 70588 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pce-questions-08.txt URL: https://www.rfc-editor.org/rfc/rfc7399.txt The Path Computation Element (PCE) architecture is set out in RFC 4655. The architecture is extended for multi-layer networking with the introduction of the Virtual Network Topology Manager (VNTM) in RFC 5623 and generalized to Hierarchical PCE (H-PCE) in RFC 6805. These three architectural views of PCE deliberately leave some key questions unanswered, especially with respect to the interactions between architectural components. This document draws out those questions and discusses them in an architectural context with reference to other architectural components, existing protocols, and recent IETF efforts. This document does not update the architecture documents and does not define how protocols or components must be used. It does, however, suggest how the architectural components might be combined to provide advanced PCE function. This document is a product of the Path Computation Element Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC