From nobody Thu Jul 2 17:21:10 2020 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D25ED3A095D; Thu, 2 Jul 2020 17:20:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: pce@ietf.org, db3546@att.com X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159373562983.30173.1610366258972983042@ietfa.amsl.com> Date: Thu, 02 Jul 2020 17:20:29 -0700 Archived-At: Subject: [Pce] pce - Requested session has been scheduled for IETF 108 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2020 00:20:32 -0000 Dear Dhruv Dhody, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. pce Session 1 (1:40 requested) Tuesday, 28 July 2020, Session III 1410-1550 Room Name: Room 4 size: 4 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/108/sessions/pce.ics Request Information: --------------------------------------------------------- Working Group Name: Path Computation Element Area Name: Routing Area Session Requester: Dhruv Dhody Number of Sessions: 1 Length of Session(s): 100 Minutes Number of Attendees: 75 Conflicts to Avoid: Chair Conflict: spring teas ccamp Technology Overlap: panrg Key Participant Conflict: mpls rift rtgwg detnet idr lsr sfc pals opsawg bess netconf netmod 6man bier rtgarea raw nmrg lsvr ippm People who must be present: Deborah Brungard Julien Meuric Dhruv Dhody Hariharan Ananthakrishnan Resources Requested: Special Requests: Do not schedule against RTG area BOF (if any) --------------------------------------------------------- From nobody Thu Jul 2 19:43:01 2020 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DD79C3A0B6A; Thu, 2 Jul 2020 19:42:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: pce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: pce@ietf.org Message-ID: <159374416983.13542.15845288051341273327@ietfa.amsl.com> Date: Thu, 02 Jul 2020 19:42:49 -0700 Archived-At: Subject: [Pce] I-D Action: draft-ietf-pce-segment-routing-ipv6-06.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2020 02:42: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 WG of the IETF. Title : PCEP Extensions for Segment Routing leveraging the IPv6 data plane Authors : Cheng Li(Editor) Mahendra Singh Negi Mike Koldychev Prejeeth Kaladharan Yongqing Zhu Filename : draft-ietf-pce-segment-routing-ipv6-06.txt Pages : 22 Date : 2020-07-02 Abstract: The Source Packet Routing in Networking (SPRING) architecture describes how Segment Routing (SR) can be used to steer packets through an IPv6 or MPLS network using the source routing paradigm. 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 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). Since SR can be applied to both MPLS and IPv6 forwarding plane, a PCE should be able to compute SR-Path for both MPLS and IPv6 forwarding plane. This document describes the extensions required for SR support for IPv6 data plane in Path Computation Element communication Protocol (PCEP). The PCEP extension and mechanism to support SR-MPLS is described in RFC 8664. This document extends it to support SRv6 (SR over IPv6). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-ipv6/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-segment-routing-ipv6-06 https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-ipv6-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-segment-routing-ipv6-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 Fri Jul 3 00:07:43 2020 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BF7053A0DA6; Fri, 3 Jul 2020 00:07:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Roni Even via Datatracker To: Cc: pce@ietf.org, last-call@ietf.org, draft-ietf-pce-pcep-flowspec.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159376005772.18637.5184937794879939300@ietfa.amsl.com> Reply-To: Roni Even Date: Fri, 03 Jul 2020 00:07:37 -0700 Archived-At: Subject: [Pce] Genart last call review of draft-ietf-pce-pcep-flowspec-09 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2020 07:07:38 -0000 Reviewer: Roni Even Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-pce-pcep-flowspec-?? Reviewer: Roni Even Review Date: 2020-07-03 IETF LC End Date: 2020-07-06 IESG Telechat date: Not scheduled for a telechat Summary: The document is ready for publication as standard track RFC Major issues: Minor issues: Nits/editorial comments: From nobody Fri Jul 3 05:57:33 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5CB43A09CE; Fri, 3 Jul 2020 05:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.548 X-Spam-Level: X-Spam-Status: No, score=-0.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 doiyT3mFVv6u; Fri, 3 Jul 2020 05:57:21 -0700 (PDT) Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (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 8C2853A09C1; Fri, 3 Jul 2020 05:57:17 -0700 (PDT) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id 063CvDFu004271; Fri, 3 Jul 2020 13:57:13 +0100 Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 756A62203C; Fri, 3 Jul 2020 13:57:13 +0100 (BST) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs1.iomartmail.com (Postfix) with ESMTPS id 5FC9E2203A; Fri, 3 Jul 2020 13:57:13 +0100 (BST) Received: from LAPTOPK7AS653V ([87.113.100.254]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id 063CvB7Z029339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 3 Jul 2020 13:57:12 +0100 Reply-To: From: "Adrian Farrel" To: "'Roni Even'" , Cc: , , References: <159376005772.18637.5184937794879939300@ietfa.amsl.com> In-Reply-To: <159376005772.18637.5184937794879939300@ietfa.amsl.com> Date: Fri, 3 Jul 2020 13:57:11 +0100 Organization: Old Dog Consulting Message-ID: <04c601d65139$78320ca0$689625e0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGpqVRGGobZvo86s3CZShoptaCXsqlPIBhg Content-Language: en-gb X-Originating-IP: 87.113.100.254 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25518.007 X-TM-AS-Result: No--8.739-10.0-31-10 X-imss-scan-details: No--8.739-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25518.007 X-TMASE-Result: 10--8.738900-10.000000 X-TMASE-MatchedRID: VfovoVrt/oaWfDtBOz4q23FPUrVDm6jtekMgTOQbVFvkaanwmLVtc18g kdmvvg/2Lt6Th6XF55wfUYgX+mnChwvpaofpaZfelVHM/F6YkvQUg4oIuVTlOJD9SXSj20wQQQ/ s9vEJJnenpp75HenHOwKZK6bT2O14qwZ1EgVNi/MNEGOVZ0MgDXdKxNZo5eYYDO+DX+rUwfaLCO HoFtyz5HfJp0r2LKg+vtWJkSab+buWURsDUI+g39WvZ0LprH5qyWxPa/RwSU/uLrWPHZAw8jq1p NeY4KBJOREa3LFkLiC4fMIiODWrIr9ZdlL8eonaU6baA36eiazEQdG7H66TyMdRT5TQAJnAMvVm +31exrt4hXmuWRutZ6SAwt3240+/MBnUo1AihSaeqD9WtJkSIw== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Pce] Genart last call review of draft-ietf-pce-pcep-flowspec-09 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2020 12:57:23 -0000 Thanks for taking time to so the review, Roni. Best, Adrian -----Original Message----- From: Roni Even via Datatracker =20 Sent: 03 July 2020 08:08 To: gen-art@ietf.org Cc: pce@ietf.org; last-call@ietf.org; = draft-ietf-pce-pcep-flowspec.all@ietf.org Subject: Genart last call review of draft-ietf-pce-pcep-flowspec-09 Reviewer: Roni Even Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-pce-pcep-flowspec-?? Reviewer: Roni Even Review Date: 2020-07-03 IETF LC End Date: 2020-07-06 IESG Telechat date: Not scheduled for a telechat Summary: The document is ready for publication as standard track RFC Major issues: Minor issues: Nits/editorial comments: From nobody Fri Jul 3 19:20:59 2020 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F6E3A0A2A; Fri, 3 Jul 2020 19:20:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joseph Touch via Datatracker To: Cc: draft-ietf-pce-pcep-flowspec.all@ietf.org, last-call@ietf.org, pce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159382925133.13370.16692501581037089439@ietfa.amsl.com> Reply-To: Joseph Touch Date: Fri, 03 Jul 2020 19:20:51 -0700 Archived-At: Subject: [Pce] Tsvart last call review of draft-ietf-pce-pcep-flowspec-09 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2020 02:20:52 -0000 Reviewer: Joseph Touch Review result: Ready with Nits This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review. Overall, the document has no direct transport issues. There are potential issues in coupled documents, notably in draft-ietf-idr-rfc5575bis. Section 4.2.2.4 of that other document indicates three issues of concern: 1) inability to handle transport protocols other than TCP and UDP (e.g., SCTP or DCCP), 2) inability to handle any but initial fragments, and 3) the omission of addressing MTU issues in the associated tunnels. Presumably those will be addressed when that document is reviewed more thoroughly. Nits: I would encourage a revision of the abstract to focus on this document and its contributions, particularly as a single paragraph. The abstract of this document buries the lede; the final sentence would be usefully moved to the front and supporting material explaining context can be moved into the intro or a background section. The abstract could more usefully provide a summary of the actual contents of this document instead, e.g., from paragraph 7 of the introduction. The introduction has similar issues; the document itself is not discussed until the 6th paragraph. Again, it would be useful to focus on this document and address the relation of its contents to other documents and the overall PCE architecture in a background section separately. It also seems odd that this paragraph (#6 of the intro) undermines the terminology of the document that this supplements (as cited in the abstract). These documents as a pair should have consistent use of terminology, coining new terms as needed rather than redefining a key term as different in the two. From nobody Fri Jul 3 19:21:10 2020 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CFF33A0A2B; Fri, 3 Jul 2020 19:20:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joseph Touch via Datatracker To: Cc: draft-ietf-pce-pcep-flowspec.all@ietf.org, last-call@ietf.org, pce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159382925133.28743.14792720064657903878@ietfa.amsl.com> Reply-To: Joseph Touch Date: Fri, 03 Jul 2020 19:20:51 -0700 Archived-At: Subject: [Pce] Tsvart last call review of draft-ietf-pce-pcep-flowspec-09 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2020 02:20:52 -0000 Reviewer: Joseph Touch Review result: Ready with Nits This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review. Overall, the document has no direct transport issues. There are potential issues in coupled documents, notably in draft-ietf-idr-rfc5575bis. Section 4.2.2.4 of that other document indicates three issues of concern: 1) inability to handle transport protocols other than TCP and UDP (e.g., SCTP or DCCP), 2) inability to handle any but initial fragments, and 3) the omission of addressing MTU issues in the associated tunnels. Presumably those will be addressed when that document is reviewed more thoroughly. Nits: I would encourage a revision of the abstract to focus on this document and its contributions, particularly as a single paragraph. The abstract of this document buries the lede; the final sentence would be usefully moved to the front and supporting material explaining context can be moved into the intro or a background section. The abstract could more usefully provide a summary of the actual contents of this document instead, e.g., from paragraph 7 of the introduction. The introduction has similar issues; the document itself is not discussed until the 6th paragraph. Again, it would be useful to focus on this document and address the relation of its contents to other documents and the overall PCE architecture in a background section separately. It also seems odd that this paragraph (#6 of the intro) undermines the terminology of the document that this supplements (as cited in the abstract). These documents as a pair should have consistent use of terminology, coining new terms as needed rather than redefining a key term as different in the two. From nobody Sun Jul 5 23:45:54 2020 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB9CF3A1134; Sun, 5 Jul 2020 23:45:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Erik Kline via Datatracker To: "The IESG" Cc: draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org, pce-chairs@ietf.org, pce@ietf.org, Adrian Farrel , adrian@olddog.co.uk X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Erik Kline Message-ID: <159401794220.31718.17372315222906941609@ietfa.amsl.com> Date: Sun, 05 Jul 2020 23:45:42 -0700 Archived-At: Subject: [Pce] Erik Kline's No Objection on draft-ietf-pce-stateful-pce-lsp-scheduling-18: (with COMMENT) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 06:45:43 -0000 Erik Kline has entered the following ballot position for draft-ietf-pce-stateful-pce-lsp-scheduling-18: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-lsp-scheduling/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [ section 1 ] * "the service really being used" -> "the service is really being used"? [ section 4.1 ] * "SHALL check ... and computes" -> "... and compute" * "on the scheduling usage expires" -> "on scheduled usage expiration"? [ section 4.2.2 ] * If there is no possible path do you want some text, maybe even just a lowercase should, about "should report to an administrator" or something? [ section 4.3 ] * In the first of the 4 bullet points at the end of this section, should the "required" and "shall" be capitalized? [ section 4.5 ] * "In other case," -> "In all other cases," or just "Otherwise,"? [ section 5.1 ] * Perhaps there's a way to strengthen the "PD requires B" text by saying what an endpoint should do if it sees PD without B? [ section 5.2.1 & 5.2.2 ] * R bit. WRT to R=0 and the wraparound, it would seem to me that in this case the receiver really needs to check if start-time is less than the current time, and if so treat that as wrap-around (2106) + start-time number of seconds. Otherwise, I think you'll need to be more precise about what it means to be "near" the wrap-around. Even still, if times are not sync'd carefully and the start-time is not a moderate amount of time in the future there remains a chance that an endpoint could receive a start-time it perceives as "in the past". What should an endpoint in this circumstance? Yet another alternative is to take a flag bit to indicate that start-time is after the wrap-around, and say that by 2242 CE some other solution should be found. :-) * Duration: Is a value of 1 just as nonsensical as 0? What about a value of 0 if grace-before and grace-after are non-zero? I may not understand the grace and elastic uses properly, but it seems to me that the thing to forbid is an "effective duration" of 0 (i.e. factoring in grace or elastic values). * Grace and Elastic fields: If it cannot provide both simultaneously why have both fields? What just have a "lower" and "upper" pair of fields and choose a new flag value to indicate whether the fields are grace values or elastic values? From nobody Mon Jul 6 06:42:12 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 384F03A14CB for ; Mon, 6 Jul 2020 06:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dhruvdhody-com.20150623.gappssmtp.com 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 VZJFoUvnVItv for ; Mon, 6 Jul 2020 06:42:11 -0700 (PDT) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 090783A14CC for ; Mon, 6 Jul 2020 06:42:11 -0700 (PDT) Received: by mail-pg1-x532.google.com with SMTP id p3so18400924pgh.3 for ; Mon, 06 Jul 2020 06:42:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dhruvdhody-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wpwdOUdd0L+jfzfb4H8nQwuVpXNXf0m+GJFNP+a73lI=; b=LO71qMlyYeNHHjnZOACrzCu+pc3xlzEWzEi9T65XNN4uXW5IJ52Z0+ZTx3EfFQAPL+ t/dvQZ1Fv9CNNNoya7YBWPbHxAPcrBSWOckWGRhN68KgJBklcYhVOCudZXZXdF98YfrE arR0QPq1rS5049OZinnbI9JyCa41fA89tbA2mTMCnELL9Ubr7H4Ma3dJWmxEwZGM/zQd lIJIAd5X9SGKWWzJ7qls3rQSEylMG5GZamwTu4+OnoObk2NGSymwMKFHUHQ1XFzp5aoT LbVl6LYVVNYR9uYddyZywQTp1Sod3ZUqOZLHYkgRKn2JFSp5zgeZWMDphRtJ1EyFlxJq emCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wpwdOUdd0L+jfzfb4H8nQwuVpXNXf0m+GJFNP+a73lI=; b=A9oJ5FNxkcUzaDZEs197MD+NldklEGXj9/2xGV2Ayc3MOoghtDN+R+o0kUd4wMI4Dz pqK7a/KseUSobGLfpdeTrFHTgVpg6bwW4E2BqQeJR/EeW8TrL5S4+gmE4J1nux9SXHj6 inCqpr9dlGkhiuqQETAgRV/k39Qwsg2eDIE9Q/wz51Vkm4IckgoJ6lTHkNM9+EDMCGSY 7QpkVSp95jWesaKYBcKFvtxyC31HA/Mm1O4iKc7sF+d0qTY2mkTrJ0Z3mMLiqsP2Z1xR 9QOD1ceLIzamRRnQCP/HGyqKjR2wGRrfbt+BgLqKjrOgYsihGCCwceDaAE3xu/SVqrnh vfyg== X-Gm-Message-State: AOAM530561ygkEWijK89qi8l1rwLRjH/l23MEK6GfscIhi5X6W0BNgmm hn1/Jte+YfbxSBazJr7eC6mExjDfbfTa/qQCffxDQnoOi8HnLg== X-Google-Smtp-Source: ABdhPJxmH//0R/0dQ3teJ3iZ/aD/zIfwUJZPKygoW8s3Lb53kq5IsIc6W+ggDuf70XEGJqDPj+CjWvzw+8FfXORpH8Q= X-Received: by 2002:a63:4f05:: with SMTP id d5mr24667857pgb.298.1594042930179; Mon, 06 Jul 2020 06:42:10 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dhruv Dhody Date: Mon, 6 Jul 2020 19:11:58 +0530 Message-ID: To: pce@ietf.org Cc: pce-chairs@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Pce] PCE WG agenda request for 108 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 13:42:12 -0000 Hi WG, The PCE WG is scheduled for Tuesday, July 28, 2020 (UTC) 14:10-15:50 Session III [1]. The last date to request slots is in 2 days (on Wednesday 8th July) by sending an email to the chairs/secretary . You could make a request for a slot even if you have not uploaded your new or revised draft yet. The last date for that is Monday, July 13th [2]. Find useful information about attending IETF 108 at [3]. Thanks! PCE Chairs & Secretary. [1] https://datatracker.ietf.org/meeting/108/agenda/#2020-07-28-110000 [2] https://datatracker.ietf.org/meeting/108/important-dates/ [3] https://ietf.org/how/meetings/108/session-participant-guide/ > On Tue, Jun 23, 2020 at 10:33 PM Hariharan Ananthakrishnan > wrote: > > > > Hi WG, > > > > The PCE WG would be meeting during the IETF 108 [1] week. If you need > > some agenda time to progress some work, please send a slot request > > directly to the chairs/secretary by Wednesday > > 8th July including: > > > > - the draft(s) you want to discuss, > > - the expected presenter name, > > - the requested duration, including question time as part of the slot, > > - the reason why you want to be on the agenda; What do you want to > > achieve? Why is a presentation necessary to achieve it? > > > > Please note - Asking for a slot does not mean you will get one. We > > will be prioritizing moving WG work first as well as drafts that were > > discussed on the mailing list. Please make sure to introduce your new > > draft or summarize an update on the mailing list. The last date to > > submit drafts is Monday, July 13th [2]. > > > > Thanks! > > PCE Chairs & Secretary > > > > [1] https://www.ietf.org/how/meetings/108/ > > [2] https://datatracker.ietf.org/meeting/108/important-dates/ From nobody Mon Jul 6 08:02:16 2020 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3640E3A15E8; Mon, 6 Jul 2020 08:02:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org, pce-chairs@ietf.org, pce@ietf.org, Adrian Farrel , adrian@olddog.co.uk X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <159404773419.726.16088712990695893519@ietfa.amsl.com> Date: Mon, 06 Jul 2020 08:02:14 -0700 Archived-At: Subject: [Pce] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf-?= =?utf-8?q?pce-stateful-pce-lsp-scheduling-18=3A_=28with_COMMENT=29?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 15:02:14 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-pce-stateful-pce-lsp-scheduling-18: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-lsp-scheduling/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. Please find below one non-blocking COMMENTs. I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Section 4.2.2.1 -- May be am I failing to understand this part of the sentence "|X| is the minimum value from 0 to max(P, Q)" as it is not the same as "where -P <= X <= Q" or does the "|X|" not represent the absolute value of X ? == NITS == -- Section 4.2.2.1 -- Please use "are" rather than "is" in "Note that both Ta and Tb is shifted by the same 'X'" From nobody Mon Jul 6 11:52:57 2020 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8AC3A0907; Mon, 6 Jul 2020 11:52:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: pce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: pce@ietf.org Message-ID: <159406157591.24636.3005248838933406205@ietfa.amsl.com> Date: Mon, 06 Jul 2020 11:52:56 -0700 Archived-At: Subject: [Pce] I-D Action: draft-ietf-pce-stateful-pce-lsp-scheduling-19.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 18:52:56 -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 WG of the IETF. Title : PCEP Extensions for LSP scheduling with stateful PCE Authors : Huaimo Chen Yan Zhuang Qin Wu Daniele Ceccarelli Filename : draft-ietf-pce-stateful-pce-lsp-scheduling-19.txt Pages : 26 Date : 2020-07-06 Abstract: This document defines a set of extensions needed to the stateful Path Computation Element (PCE) communication Protocol (PCEP), so as to enable Labeled Switched Path (LSP) scheduling for path computation and LSP setup/deletion based on the actual network resource usage and the duration of a traffic service in a centralized network environment as stated in RFC 8413. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-lsp-scheduling/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-lsp-scheduling-19 https://datatracker.ietf.org/doc/html/draft-ietf-pce-stateful-pce-lsp-scheduling-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-stateful-pce-lsp-scheduling-19 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 Jul 6 12:05:39 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BFAC3A09C3; Mon, 6 Jul 2020 12:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com 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 0gjwS3bjoStU; Mon, 6 Jul 2020 12:05:35 -0700 (PDT) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2096.outbound.protection.outlook.com [40.107.93.96]) (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 07D423A0994; Mon, 6 Jul 2020 12:05:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Och0NpNFLdR/fu5TmCp4RV3EHQmbsQQGX4anJfPLY7yqPwnX9hiOOEJBHRKSkjM0ZwTcfBxUrVIoNBOboXKfX6KpDjOt+39KKxePxzvYW0tsPZNLVW8DgoEsoREBFsAk87wyvOTCPRc+w2CE0E61DhB4AMHdpPLxFoekJFXGuQEVDrvn1qOHYkn8+TWjX+0/4taGzLwCA8/fMIJMehdKNX03B3cyYlahDjljCcCL/CljTaqCP2RDMd+tXM3Bzc7bUcL5nh4A5m4VGKQiOPdpNOBLNv4Nx8KOTviX35FTxAlh7LAomj7Jng/v+T7iTsl1GbyH1rtGzxEVcPu4ESUuzA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/0rLiIGALhxOGqIZOnKnixrTToHFX6p3no0RjHfeprU=; b=KVmgJXo1H922jR0jq+qEEOYA1+BThV++etWcyP/P04hP802xveCvzgFcC9iiej2UQbOriAvqVoN/e1wm+lMQgTHZa5RJ9HeAwbUWWhIxK592sq6IL9kHKKbE/09egspvmalrZp3+jpscbiUh8Hi2rCFMgze0pf5VZfDWn8cLCdRU+oIRjo4OSiRoiWZo89cH6Wb5IlL6XgW/S7Ipynog0Jk6lYoR49ZOGQy9Gyd2QCXifjRsk6SgmOFQFcAj2BylYbh3BxM7l0Shu4hPI/+reDjYPriS8PK7cEnBh3bRV58hOd5ydLh/A5yFVlqqgH3W9lA2oWU3zvyw1jaNcbAqIw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/0rLiIGALhxOGqIZOnKnixrTToHFX6p3no0RjHfeprU=; b=K6RFC4/NAVyc/ttyEjR0GJNHSj7sNnU9YSYA7c3kJHDPTio+Jsmkti0K1QF8D96g7rVHylhKPe4Np/KN+OfJy2dxOBfOfCEicLGRcLxsMZ93tSCBNQrqD0v/NQAksSaoabfQBxf6PKouvd2I1Hy0NOg5ZzmOXo+6MbC1nEs58VU= Received: from MN2PR13MB3117.namprd13.prod.outlook.com (2603:10b6:208:13a::20) by MN2PR13MB2975.namprd13.prod.outlook.com (2603:10b6:208:13f::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.8; Mon, 6 Jul 2020 19:05:30 +0000 Received: from MN2PR13MB3117.namprd13.prod.outlook.com ([fe80::d5b6:8550:9c40:eec2]) by MN2PR13MB3117.namprd13.prod.outlook.com ([fe80::d5b6:8550:9c40:eec2%7]) with mapi id 15.20.3174.019; Mon, 6 Jul 2020 19:05:30 +0000 From: Huaimo Chen To: The IESG , =?iso-8859-1?Q?=C9ric_Vyncke?= CC: "draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org" , "pce-chairs@ietf.org" , "pce@ietf.org" , Adrian Farrel , Adrian Farrel Thread-Topic: =?iso-8859-1?Q?=C9ric_Vyncke's_No_Objection_on_draft-ietf-pce-stateful-pc?= =?iso-8859-1?Q?e-lsp-scheduling-18:_(with_COMMENT)?= Thread-Index: AQHWU6Zxwdqp0EqERk6bTki4I0SVi6j65rXp Date: Mon, 6 Jul 2020 19:05:30 +0000 Message-ID: References: <159404773419.726.16088712990695893519@ietfa.amsl.com> In-Reply-To: <159404773419.726.16088712990695893519@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=futurewei.com; x-originating-ip: [2601:199:4300:8e5a:614a:385c:1647:35e3] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 18a4fceb-a64b-4470-9e46-08d821df8d59 x-ms-traffictypediagnostic: MN2PR13MB2975: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: nOVy5bz3WjcxG7rFYL6PSEhruCnsV0cIHL+PiSkOjETuAmzh2xanqblh41pljjfT7DaDzn0q7gJrEL4t3dq7hdQMrzXeazIWL9Il2K9GljXFaSYnVX/HiDKNm4R9RcT6X0CqxsxETC4/bshje8hcc2x5YY3LRVbrFxiJsPRceh8zBErVLb7xg/ELY7uQsDvjpIbaNhCyVQ1Tg09t8gUUwEV47wG2XRc7j6qkYBw3Mg4z4pUfyAiDHhMMOP2boXl/IqmRNlKJwgSPm8HPEhTkHIMbhg10wgUERjqzScj0JDOoAEMp0DUnXWXrF+BEYXu2Vsi1qA0yCCGNfJuZR3xGWi2mlMfjCfk3LO01mvyvRdofC85IAl8qqEtDzh0RkeRsMr06O7exAltIrB944CxGOw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR13MB3117.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(396003)(39840400004)(376002)(366004)(346002)(2906002)(478600001)(966005)(45080400002)(8936002)(4326008)(166002)(6506007)(33656002)(53546011)(186003)(7696005)(54906003)(110136005)(44832011)(9686003)(83380400001)(316002)(86362001)(55016002)(52536014)(76116006)(5660300002)(19627405001)(66946007)(71200400001)(224303003)(66476007)(66556008)(66446008)(64756008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 0yKRlFKW7HKaB6poaL1IQd83e49NWH+urTtvKS4ZkAbEthRqNOOyL5h+6M3fNwJmKWP4gTQlCbvf3nszR3wuoJjNpf4prnN5Fx0pmJ82I0GMnEuPAWg01SrcUccV5ju1JCAZfo4Z3TNsN3r2uWxtfkSIH90seGesKJiQ7iYLVW7g05luxKs/8eNkuaRQM7458aaHUd6IZtphKRo71BWyPB4e/UlNZ4n17gmMqzEEwaUu0s6sm8XsepcUx4nhfEN926sAzYmIWibipegYMj3XoY0IFolpWDQxTr6YVgWgSSGbfykW6D7nJQ1jM6+zYkp7dCYypSy4msEWf4TaDYSdTWUjygFv0A3RKt5MPE++nTaVej1DmRgvWVvs9CQCydRysQb3Z7LYjSfkfutL/pMOhY4SpvXRgHJ/YWEoMbuDheNjVBhQ74+h3Rs2GFp35uITwD48tP46uNnptmaO2zE74EfG7uYB9ODquMUemn4IVzUjgFL3G8P/6ELYlwIfEwm02Bhy9EDkJI26gAt4syTZJDYLDh0TCf5g049Mg+z8IVUErVevVEtXy77kl6D73140 x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR13MB3117336EA88C4654A1DB3021F2690MN2PR13MB3117namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR13MB3117.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 18a4fceb-a64b-4470-9e46-08d821df8d59 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jul 2020 19:05:30.5169 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: eN1zbx8eKrncPou1zUshxoFiiaWiLEB6m5fdKIih0ZRqB286wuBqd7HUh4BYQlYNdhnQkuqagY/YJ5ssmQ4qBQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR13MB2975 Archived-At: Subject: Re: [Pce] =?iso-8859-1?q?=C9ric_Vyncke=27s_No_Objection_on_draft-iet?= =?iso-8859-1?q?f-pce-stateful-pce-lsp-scheduling-18=3A_=28with_COMMENT=29?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 19:05:38 -0000 --_000_MN2PR13MB3117336EA88C4654A1DB3021F2690MN2PR13MB3117namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Eric, Thank you very much for your valuable comments, which improve the quali= ty of the document. My explanations/answers are inline below with prefix [HC]. Best Regards, Huaimo ________________________________ From: =C9ric Vyncke via Datatracker Sent: Monday, July 6, 2020 11:02 AM To: The IESG Cc: draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org ; pce-chairs@ietf.org ; pce@ietf.org ; Adrian Farrel ; adria= n@olddog.co.uk Subject: =C9ric Vyncke's No Objection on draft-ietf-pce-stateful-pce-lsp-sc= heduling-18: (with COMMENT) =C9ric Vyncke has entered the following ballot position for draft-ietf-pce-stateful-pce-lsp-scheduling-18: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://nam11.safelinks.protection.outlook.com/?url=3Dhttps= %3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html&data= =3D02%7C01%7Chuaimo.chen%40futurewei.com%7Ce52618a253284bdcf29608d821bd921a= %7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637296445383410363&sdata= =3Davjm%2BwJ4A%2FKpyAnTbGY0hN6nut2w5uDwjOxu%2BV2j%2B%2FI%3D&reserved=3D= 0 for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatra= cker.ietf.org%2Fdoc%2Fdraft-ietf-pce-stateful-pce-lsp-scheduling%2F&dat= a=3D02%7C01%7Chuaimo.chen%40futurewei.com%7Ce52618a253284bdcf29608d821bd921= a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637296445383420360&sdata= =3Dq4C8iND0oAGJgcy6HfpVt1zvlC6ck%2BKrfQxVBpN8jG0%3D&reserved=3D0 ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. Please find below one non-blocking COMMENTs. I hope that this helps to improve the document, Regards, -=E9ric =3D=3D COMMENTS =3D=3D -- Section 4.2.2.1 -- May be am I failing to understand this part of the sentence "|X| is the min= imum value from 0 to max(P, Q)" as it is not the same as "where -P <=3D X <=3D Q= " or does the "|X|" not represent the absolute value of X ? [HC]: "|X|" represents the absolute value of X. There are two sentences: 1) "[Ta, Tb] within -P and Q" means a time period from (Ta+X) to (Tb+X), where -P <=3D X <=3D Q. 2) When an LSP is configured with elastic time interval "[Ta, Tb] within -P and Q", a path is computed such that the path satisfies the constraints for the LSP in the time period from (Ta+X) to (Tb+X) and |X| is the minimum value from 0 to max(P, Q). In the first sentence, an acceptable range of X is given by -P <=3D X <=3D = Q. In the second sentence, a value of X is found within the acceptable range to satisfies the constraints. If we change X to Xv in the second sentence, it may be clear. 2)' When an LSP is configured with elastic time interval "[Ta, Tb] within -P and Q", a path is computed such that the path satisfies the constraints for the LSP in the time period from (Ta+Xv) to (Tb+Xv) and |Xv| is the minimum value for Vx from -P to Q. We have rephrased the related text in the updated document. =3D=3D NITS =3D=3D -- Section 4.2.2.1 -- Please use "are" rather than "is" in "Note that both Ta and Tb is shifted b= y the same 'X'" [HC]: We have changed "is" to "are". --_000_MN2PR13MB3117336EA88C4654A1DB3021F2690MN2PR13MB3117namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Eric,

    Thank you very much for your valuable comments, which improve= the quality of the document.  
    My explanations/answers are inline below with prefix [HC].

Best Regards,
Huaimo
From: =C9ric Vyncke via Dat= atracker <noreply@ietf.org>
Sent: Monday, July 6, 2020 11:02 AM
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org <draft-ie= tf-pce-stateful-pce-lsp-scheduling@ietf.org>; pce-chairs@ietf.org <pc= e-chairs@ietf.org>; pce@ietf.org <pce@ietf.org>; Adrian Farrel <= ;adrian@olddog.co.uk>; adrian@olddog.co.uk <adrian@olddog.co.uk> Subject: =C9ric Vyncke's No Objection on draft-ietf-pce-stateful-pce= -lsp-scheduling-18: (with COMMENT)
 
=C9ric Vyncke has entered the following ballot pos= ition for
draft-ietf-pce-stateful-pce-lsp-scheduling-18: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html&amp;data=3D02%7C01%7Ch= uaimo.chen%40futurewei.com%7Ce52618a253284bdcf29608d821bd921a%7C0fee8ff2a3b= 240189c753a1d5591fedc%7C1%7C0%7C637296445383410363&amp;sdata=3Davjm%2Bw= J4A%2FKpyAnTbGY0hN6nut2w5uDwjOxu%2BV2j%2B%2FI%3D&amp;reserved=3D0 for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://nam11.safelinks.protection.outlook.com/?url=3Dhtt= ps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-pce-stateful-pce-lsp-sch= eduling%2F&amp;data=3D02%7C01%7Chuaimo.chen%40futurewei.com%7Ce52618a25= 3284bdcf29608d821bd921a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637296= 445383420360&amp;sdata=3Dq4C8iND0oAGJgcy6HfpVt1zvlC6ck%2BKrfQxVBpN8jG0%= 3D&amp;reserved=3D0



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work put into this document.

Please find below one non-blocking COMMENTs.

I hope that this helps to improve the document,

Regards,

-=E9ric

=3D=3D COMMENTS =3D=3D

-- Section 4.2.2.1 --
May be am I failing to understand this part of the sentence "|X| is th= e minimum
value from 0 to max(P, Q)" as it is not the same as "where -P <= ;=3D X <=3D Q" or
does the "|X|" not represent the absolute value of X ?

[HC]: "|X|" represents the absolute value of X.
There are two sentences:
1) "[Ta, Tb] within -P and Q" means a time period from (Ta&#= 43;X) to (Tb+X),
   where -P <=3D X <=3D Q.
2) When an LSP is configured with elastic time interval "[Ta, Tb]= within
   -P and Q", a path is computed such that the path sat= isfies the
   constraints for the LSP in the time period from (Ta+X= ) to (Tb+X)
   and |X| is the minimum value from 0 to max(P, Q).
In the first sentence, an acceptable range of X is given by -P <=3D= X <=3D Q.
In the second sentence, a value of X is found within the acceptable ra= nge
to satisfies the constraints.
If we change X to Xv in the second sentence, it may be clear.
2)' When an LSP is configured with elastic time interval "[Ta, Tb= ] within
   -P and Q", a path is computed such that the path sat= isfies the
   constraints for the LSP in the time period from (Ta+X= v) to (Tb+Xv)
   and |Xv| is the minimum value for Vx from -P to Q.
We have rephrased the related text in the updated document.

=3D=3D NITS =3D=3D

-- Section 4.2.2.1 --
Please use "are" rather than "is" in "Note that bo= th Ta and Tb is shifted by
the same 'X'"

[HC]: We have changed "is" to "= ;are".



--_000_MN2PR13MB3117336EA88C4654A1DB3021F2690MN2PR13MB3117namp_-- From nobody Mon Jul 6 23:07:19 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD0643A0930; Mon, 6 Jul 2020 23:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.597 X-Spam-Level: X-Spam-Status: No, score=-14.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=GiLeVQ1N; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=n6wNACt6 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 GsrYipvyBjzp; Mon, 6 Jul 2020 23:07:11 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CCFB3A092E; Mon, 6 Jul 2020 23:07:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21905; q=dns/txt; s=iport; t=1594102031; x=1595311631; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=BuZlIDev48lRVp+m7Cn0fPcJqEjr7rvt6iRAQqk3oPQ=; b=GiLeVQ1NwhYXxf7JSOJFMftBcNQjR76KBa5YI2y1uyO+b6yCqKiM0ymu OI8g+ckuleiBjmy35Bzv33/FSj50dWhizwrVnLcRY1To2RkK/L72tzQqK Iu5RA7at/P2Mpq4MIPJpLHsX/MUNXvCmyO1w+mR80vvbI66KYEVbodvGg o=; IronPort-PHdr: =?us-ascii?q?9a23=3AYrqldBGeBudRcLC5xf3w451GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e401gWbU5jH9uhJlOfX9avnXD9I7ZWAtSUEd5pBH1?= =?us-ascii?q?8AhN4NlgMtSMiCFQXgLfHsYiB7eaYKVFJs83yhd0QAHsH4ag7cv2Gv9zMNFx?= =?us-ascii?q?S5Pg1wdaz5H4fIhJGx0Oa/s5TYfwRPgm+7ZrV/ZBW7pAncrI8Ym4xnf60w0R?= =?us-ascii?q?DO5HBPfrdb?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DZAQDJDwRf/5JdJa1gGwEBAQEBAQE?= =?us-ascii?q?BBQEBARIBAQEDAwEBAYIKgSMvUQdvWC8shDKDRgONSpNvhGuBQoEQA1ULAQE?= =?us-ascii?q?BDAEBIgsCBAEBgWqCXQIXgg8CJDgTAgMBAQsBAQUBAQECAQYEbYVbDIVuAQE?= =?us-ascii?q?BBBIRChMBATcBDwIBCBEDAQEBKwICAjAaAwgCBAENBSKCfwQBAYF+TQMuAQ6?= =?us-ascii?q?dXwKBOYhhdoEygwEBAQWBRkGDCwMVgg4DBoE4gmmFYhuEBBqBQT+BESccgk0?= =?us-ascii?q?+glwCAgEBFYERARIBOAkNgmkzgi2PKA+DBIZDnBEKglyIS4wUhGsDHYJziTC?= =?us-ascii?q?SeoQii2WBU4oclEUCBAIEBQIOAQEFgWoiDFpYEQdwFWUBgj4TPRcCDY4eN4M?= =?us-ascii?q?6hRSFQnQCAQEBMgIGAQcBAQMJAXuPZQEB?= X-IronPort-AV: E=Sophos;i="5.75,321,1589241600"; d="scan'208,217";a="798104838" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Jul 2020 06:07:09 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 06767AWb016964 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 7 Jul 2020 06:07:10 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 7 Jul 2020 01:07:09 -0500 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 7 Jul 2020 02:07:08 -0400 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 7 Jul 2020 01:07:08 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=icnvRo1l2wyRrGVsQQMz9s/1aPHY4zzpNKpwtqyd8rHkVVlGI3KOFlXV3sQ4dOHyNcYo30vpG1D+bLvqYM8f7vtUEUcHNcBy2NA+r4daV+ut77DcA7eukw4qOqHD6OdhHiVdJOByIi6GJhLXb6ixUULxgndCNtV262c/KGvijSDIyb5yFuHWeP/xOEd4Y/d69yg/VM2CRnMad2bPJlgcGCQ1N+PwqU3PoQarabpjBIFqW+5BaDjQWMKq15qE3emGuVKsQWLT37I3sxExzHddJaSY+q9iouZnUyeESlRMT5Ev9xz5Luu+eR4cn0/7a9pCRGaK2eZcGfJErfDQ85giNg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BuZlIDev48lRVp+m7Cn0fPcJqEjr7rvt6iRAQqk3oPQ=; b=jZkQ71DKFiDeVxExo/u0YWirV5u2FLdNjzIKuHf7IsEGdbqF+iiGQV1ExYtU7Kl89B7dovfU3/Rp+rMiMB8dmsPXQzFMKIBCv70AmX1L1KsOGN563uY8xvS4hjn6vsyqf7F55HbkICU+sjWs6laI5QVPW/uGrvo0bl0ErP8jpvIQ0CdocMrQMjY8YuxfQi0MQDG4ljreWw5srZKx7ezYNJikmAXhLQ//CieEBuMWj+XuNat/9d8TfAOs034oiP5Un1S5VWdZBITuMWXmWCUDQTfpcoyCYRoIoDZZSYOesl+OxdGU5XVJPmnAxHedh6Y1eYKqpIAhRt5kCep309YP1w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BuZlIDev48lRVp+m7Cn0fPcJqEjr7rvt6iRAQqk3oPQ=; b=n6wNACt61d4+FnI7x7kd2CXTVni5iOvvPu3KJfNG9slbTlANEyPjZUkDdMynqtQ3E7inpxWST9aUHW6rPCg6g3hXQUI920JJwYeab5A1pzN6dYDj+4bW5qM/5Mgq9kEb99PmSq5CeXjDAt4cLNmD42bUUp0PbYy991FzQvlXx0c= Received: from DM5PR11MB1753.namprd11.prod.outlook.com (2603:10b6:3:10d::13) by DM6PR11MB3769.namprd11.prod.outlook.com (2603:10b6:5:142::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.27; Tue, 7 Jul 2020 06:07:06 +0000 Received: from DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::a14c:59b6:47b0:f630]) by DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::a14c:59b6:47b0:f630%7]) with mapi id 15.20.3153.029; Tue, 7 Jul 2020 06:07:06 +0000 From: "Eric Vyncke (evyncke)" To: Huaimo Chen , The IESG CC: "draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org" , "pce-chairs@ietf.org" , "pce@ietf.org" , Adrian Farrel Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtcGNl?= =?utf-8?Q?-stateful-pce-lsp-scheduling-18:_(with_COMMENT)?= Thread-Index: AQHWU6Zxwdqp0EqERk6bTki4I0SVi6j65rXpgADdMoA= Date: Tue, 7 Jul 2020 06:07:06 +0000 Message-ID: <007EB8BD-ECEE-42D8-B379-BE700E089618@cisco.com> References: <159404773419.726.16088712990695893519@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.38.20061401 authentication-results: futurewei.com; dkim=none (message not signed) header.d=none;futurewei.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2001:420:c0c1:36:91f1:7724:5187:ba1a] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 38a36b5c-67d3-402a-16bd-08d8223bfa14 x-ms-traffictypediagnostic: DM6PR11MB3769: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0457F11EAF x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: qasQtO+hBFmRBpzU3KytbwwmEWLxu1g7hyuJKKJ4kthTraefa4T5aM0fPcb96032r6l6XS92hhJ8kAHmjFuhLBKgiIhHPDltZw32bujiS58VjVDCaWgQXszu5RnThotWyPIMmnfDDl411XWvzHCsGiO6r6GWtqZLafbe2xfzq4S7auT7hoo2vJgTuk+5WxEly1bl8rzxwHw/ffVpeR9qvrOI1Zg1scZ7ERIPAMRE/cFMgZrOdZL157wwniympnmnxRAPNf3P/EyYQ+8PNJ2VIBuh0obYI+AyL2vGz+Gg94J/n+wzI7JKATq72Tfzriobs1gdn1XM6jtsZDZyiWsdftIwA8keww0nKgPFRTbG9f6XsLtN9avsyUmOWKpoycVxHIp/VQVu2uHQNQEqFshJLw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR11MB1753.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(136003)(376002)(366004)(396003)(346002)(166002)(71200400001)(8936002)(2616005)(186003)(2906002)(6512007)(6506007)(53546011)(45080400002)(66476007)(66946007)(66446008)(64756008)(66556008)(86362001)(83380400001)(76116006)(478600001)(110136005)(224303003)(54906003)(33656002)(5660300002)(91956017)(966005)(316002)(4326008)(6486002)(36756003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: XkItc45DK1/lsKNwmHEKUV0J/ynr9V9PQVPwixd88N7LSQ7aCzfmv/IfgrhxoBHm/W2+S7LgjRAeWZagDDfx6cZZkiyvVNxm82xpLCltY5/Xzcxicgaz/3QpDOVo+CfNsWa9DGuwXo4FkhNJvhSfHuAbyjNvzQC2p975h9HLMc9/Onzb393667JFSgg9FWYAfZs4GoVaPhfBZZu37exV0h74DD0wEr/q9qnWwy/NsQ3lVXd7KIQh2SRBtfDUPtzQOoEEKT4VIOt/aTqMyk8a8o/r7SUTzurqq04KgXR3mnSgoVkA8JExoiIJYexWWfSjCLRfQ+DnzqjwH74w9pl3BVF4UjIqJLvpKqxpNHEitJ46FoA8LTfFMhWXLQ//8+LTYl+ErKOXTbzNYaujoC/ivDBvd0OwNCFj2wBEz57WL/mx2Lv1XO8sXX2KiaZkVnBrooX+6ud8s7XfpQsatbK90W1lvT9nua8zjTCv1SM1bmGNzmX1AiqttMmfQG9aHSUzHR4BZe39YnNxvrWpsx7eUOf1+MK3u0npXhWMrXOlZag= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_007EB8BDECEE42D8B379BE700E089618ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM5PR11MB1753.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 38a36b5c-67d3-402a-16bd-08d8223bfa14 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2020 06:07:06.5271 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: xYtnmgQiMAFciA5tfBlYNUUh9wY93ZQ0d8OD5vV5Wabhz/1kTbP5EQsKuLD1fBh3DDr799hv6ZJNqo2dYxQc1A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3769 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: Subject: Re: [Pce] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf-?= =?utf-8?q?pce-stateful-pce-lsp-scheduling-18=3A_=28with_COMMENT=29?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 06:07:14 -0000 --_000_007EB8BDECEE42D8B379BE700E089618ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmsgeW91IEh1YWltbyBmb3IgeW91ciByZXBseS4NCg0KUGxlYXNlIG5vdGUgdGhhdCB5b3Ug dXNlZCDigJhWeOKAmSByYXRoZXIgdGhhbiDigJhYduKAmSBpbiB5b3VyIHByb3Bvc2VkIHRleHQu DQoNClJlZ2FyZHMNCg0KLcOpcmljDQoNCkZyb206IEh1YWltbyBDaGVuIDxodWFpbW8uY2hlbkBm dXR1cmV3ZWkuY29tPg0KRGF0ZTogTW9uZGF5LCA2IEp1bHkgMjAyMCBhdCAyMTowNQ0KVG86IFRo ZSBJRVNHIDxpZXNnQGlldGYub3JnPiwgRXJpYyBWeW5ja2UgPGV2eW5ja2VAY2lzY28uY29tPg0K Q2M6ICJkcmFmdC1pZXRmLXBjZS1zdGF0ZWZ1bC1wY2UtbHNwLXNjaGVkdWxpbmdAaWV0Zi5vcmci IDxkcmFmdC1pZXRmLXBjZS1zdGF0ZWZ1bC1wY2UtbHNwLXNjaGVkdWxpbmdAaWV0Zi5vcmc+LCAi cGNlLWNoYWlyc0BpZXRmLm9yZyIgPHBjZS1jaGFpcnNAaWV0Zi5vcmc+LCAicGNlQGlldGYub3Jn IiA8cGNlQGlldGYub3JnPiwgQWRyaWFuIEZhcnJlbCA8YWRyaWFuQG9sZGRvZy5jby51az4sIEFk cmlhbiBGYXJyZWwgPGFkcmlhbkBvbGRkb2cuY28udWs+DQpTdWJqZWN0OiBSZTogw4lyaWMgVnlu Y2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtcGNlLXN0YXRlZnVsLXBjZS1sc3Atc2No ZWR1bGluZy0xODogKHdpdGggQ09NTUVOVCkNCg0KSGkgRXJpYywNCg0KICAgIFRoYW5rIHlvdSB2 ZXJ5IG11Y2ggZm9yIHlvdXIgdmFsdWFibGUgY29tbWVudHMsIHdoaWNoIGltcHJvdmUgdGhlIHF1 YWxpdHkgb2YgdGhlIGRvY3VtZW50Lg0KICAgIE15IGV4cGxhbmF0aW9ucy9hbnN3ZXJzIGFyZSBp bmxpbmUgYmVsb3cgd2l0aCBwcmVmaXggW0hDXS4NCg0KQmVzdCBSZWdhcmRzLA0KSHVhaW1vDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogw4lyaWMgVnluY2tlIHZpYSBE YXRhdHJhY2tlciA8bm9yZXBseUBpZXRmLm9yZz4NClNlbnQ6IE1vbmRheSwgSnVseSA2LCAyMDIw IDExOjAyIEFNDQpUbzogVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+DQpDYzogZHJhZnQtaWV0Zi1w Y2Utc3RhdGVmdWwtcGNlLWxzcC1zY2hlZHVsaW5nQGlldGYub3JnIDxkcmFmdC1pZXRmLXBjZS1z dGF0ZWZ1bC1wY2UtbHNwLXNjaGVkdWxpbmdAaWV0Zi5vcmc+OyBwY2UtY2hhaXJzQGlldGYub3Jn IDxwY2UtY2hhaXJzQGlldGYub3JnPjsgcGNlQGlldGYub3JnIDxwY2VAaWV0Zi5vcmc+OyBBZHJp YW4gRmFycmVsIDxhZHJpYW5Ab2xkZG9nLmNvLnVrPjsgYWRyaWFuQG9sZGRvZy5jby51ayA8YWRy aWFuQG9sZGRvZy5jby51az4NClN1YmplY3Q6IMOJcmljIFZ5bmNrZSdzIE5vIE9iamVjdGlvbiBv biBkcmFmdC1pZXRmLXBjZS1zdGF0ZWZ1bC1wY2UtbHNwLXNjaGVkdWxpbmctMTg6ICh3aXRoIENP TU1FTlQpDQoNCsOJcmljIFZ5bmNrZSBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBw b3NpdGlvbiBmb3INCmRyYWZ0LWlldGYtcGNlLXN0YXRlZnVsLXBjZS1sc3Atc2NoZWR1bGluZy0x ODogTm8gT2JqZWN0aW9uDQoNCldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1Ympl Y3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0KZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVk IGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMNCmludHJvZHVj dG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KDQoNClBsZWFzZSByZWZlciB0byBodHRwczovL25h bTExLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3 d3cuaWV0Zi5vcmclMkZpZXNnJTJGc3RhdGVtZW50JTJGZGlzY3Vzcy1jcml0ZXJpYS5odG1sJmFt cDtkYXRhPTAyJTdDMDElN0NodWFpbW8uY2hlbiU0MGZ1dHVyZXdlaS5jb20lN0NlNTI2MThhMjUz Mjg0YmRjZjI5NjA4ZDgyMWJkOTIxYSU3QzBmZWU4ZmYyYTNiMjQwMTg5Yzc1M2ExZDU1OTFmZWRj JTdDMSU3QzAlN0M2MzcyOTY0NDUzODM0MTAzNjMmYW1wO3NkYXRhPWF2am0lMkJ3SjRBJTJGS3B5 QW5UYkdZMGhONm51dDJ3NXVEd2pPeHUlMkJWMmolMkIlMkZJJTNEJmFtcDtyZXNlcnZlZD0wDQpm b3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRp b25zLg0KDQoNClRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25z LCBjYW4gYmUgZm91bmQgaGVyZToNCmh0dHBzOi8vbmFtMTEuc2FmZWxpbmtzLnByb3RlY3Rpb24u b3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmRhdGF0cmFja2VyLmlldGYub3JnJTJGZG9j JTJGZHJhZnQtaWV0Zi1wY2Utc3RhdGVmdWwtcGNlLWxzcC1zY2hlZHVsaW5nJTJGJmFtcDtkYXRh PTAyJTdDMDElN0NodWFpbW8uY2hlbiU0MGZ1dHVyZXdlaS5jb20lN0NlNTI2MThhMjUzMjg0YmRj ZjI5NjA4ZDgyMWJkOTIxYSU3QzBmZWU4ZmYyYTNiMjQwMTg5Yzc1M2ExZDU1OTFmZWRjJTdDMSU3 QzAlN0M2MzcyOTY0NDUzODM0MjAzNjAmYW1wO3NkYXRhPXE0QzhpTkQwb0FHSmdjeTZIZnBWdDF6 dmxDNmNrJTJCS3JmUXhWQnBOOGpHMCUzRCZhbXA7cmVzZXJ2ZWQ9MA0KDQoNCg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KQ09NTUVOVDoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KVGhhbmsgeW91IGZvciB0aGUgd29yayBw dXQgaW50byB0aGlzIGRvY3VtZW50Lg0KDQpQbGVhc2UgZmluZCBiZWxvdyBvbmUgbm9uLWJsb2Nr aW5nIENPTU1FTlRzLg0KDQpJIGhvcGUgdGhhdCB0aGlzIGhlbHBzIHRvIGltcHJvdmUgdGhlIGRv Y3VtZW50LA0KDQpSZWdhcmRzLA0KDQotw6lyaWMNCg0KPT0gQ09NTUVOVFMgPT0NCg0KLS0gU2Vj dGlvbiA0LjIuMi4xIC0tDQpNYXkgYmUgYW0gSSBmYWlsaW5nIHRvIHVuZGVyc3RhbmQgdGhpcyBw YXJ0IG9mIHRoZSBzZW50ZW5jZSAifFh8IGlzIHRoZSBtaW5pbXVtDQp2YWx1ZSBmcm9tIDAgdG8g bWF4KFAsIFEpIiBhcyBpdCBpcyBub3QgdGhlIHNhbWUgYXMgIndoZXJlIC1QIDw9IFggPD0gUSIg b3INCmRvZXMgdGhlICJ8WHwiIG5vdCByZXByZXNlbnQgdGhlIGFic29sdXRlIHZhbHVlIG9mIFgg Pw0KDQpbSENdOiAifFh8IiByZXByZXNlbnRzIHRoZSBhYnNvbHV0ZSB2YWx1ZSBvZiBYLg0KVGhl cmUgYXJlIHR3byBzZW50ZW5jZXM6DQoxKSAiW1RhLCBUYl0gd2l0aGluIC1QIGFuZCBRIiBtZWFu cyBhIHRpbWUgcGVyaW9kIGZyb20gKFRhK1gpIHRvIChUYitYKSwNCiAgIHdoZXJlIC1QIDw9IFgg PD0gUS4NCjIpIFdoZW4gYW4gTFNQIGlzIGNvbmZpZ3VyZWQgd2l0aCBlbGFzdGljIHRpbWUgaW50 ZXJ2YWwgIltUYSwgVGJdIHdpdGhpbg0KICAgLVAgYW5kIFEiLCBhIHBhdGggaXMgY29tcHV0ZWQg c3VjaCB0aGF0IHRoZSBwYXRoIHNhdGlzZmllcyB0aGUNCiAgIGNvbnN0cmFpbnRzIGZvciB0aGUg TFNQIGluIHRoZSB0aW1lIHBlcmlvZCBmcm9tIChUYStYKSB0byAoVGIrWCkNCiAgIGFuZCB8WHwg aXMgdGhlIG1pbmltdW0gdmFsdWUgZnJvbSAwIHRvIG1heChQLCBRKS4NCkluIHRoZSBmaXJzdCBz ZW50ZW5jZSwgYW4gYWNjZXB0YWJsZSByYW5nZSBvZiBYIGlzIGdpdmVuIGJ5IC1QIDw9IFggPD0g US4NCkluIHRoZSBzZWNvbmQgc2VudGVuY2UsIGEgdmFsdWUgb2YgWCBpcyBmb3VuZCB3aXRoaW4g dGhlIGFjY2VwdGFibGUgcmFuZ2UNCnRvIHNhdGlzZmllcyB0aGUgY29uc3RyYWludHMuDQpJZiB3 ZSBjaGFuZ2UgWCB0byBYdiBpbiB0aGUgc2Vjb25kIHNlbnRlbmNlLCBpdCBtYXkgYmUgY2xlYXIu DQoyKScgV2hlbiBhbiBMU1AgaXMgY29uZmlndXJlZCB3aXRoIGVsYXN0aWMgdGltZSBpbnRlcnZh bCAiW1RhLCBUYl0gd2l0aGluDQogICAtUCBhbmQgUSIsIGEgcGF0aCBpcyBjb21wdXRlZCBzdWNo IHRoYXQgdGhlIHBhdGggc2F0aXNmaWVzIHRoZQ0KICAgY29uc3RyYWludHMgZm9yIHRoZSBMU1Ag aW4gdGhlIHRpbWUgcGVyaW9kIGZyb20gKFRhK1h2KSB0byAoVGIrWHYpDQogICBhbmQgfFh2fCBp cyB0aGUgbWluaW11bSB2YWx1ZSBmb3IgVnggZnJvbSAtUCB0byBRLg0KV2UgaGF2ZSByZXBocmFz ZWQgdGhlIHJlbGF0ZWQgdGV4dCBpbiB0aGUgdXBkYXRlZCBkb2N1bWVudC4NCg0KPT0gTklUUyA9 PQ0KDQotLSBTZWN0aW9uIDQuMi4yLjEgLS0NClBsZWFzZSB1c2UgImFyZSIgcmF0aGVyIHRoYW4g ImlzIiBpbiAiTm90ZSB0aGF0IGJvdGggVGEgYW5kIFRiIGlzIHNoaWZ0ZWQgYnkNCnRoZSBzYW1l ICdYJyINCg0KW0hDXTogV2UgaGF2ZSBjaGFuZ2VkICJpcyIgdG8gImFyZSIuDQoNCg0K --_000_007EB8BDECEE42D8B379BE700E089618ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6LXdlYmtpdC1z dGFuZGFyZDsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJlbi1CRSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoYW5r IHlvdSBIdWFpbW8gZm9yIHlvdXIgcmVwbHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5QbGVhc2Ugbm90 ZSB0aGF0IHlvdSB1c2VkIOKAmDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 LXdlYmtpdC1zdGFuZGFyZCZxdW90OyxzZXJpZjtjb2xvcjpibGFjayI+Vng8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPuKAmSByYXRoZXIgdGhhbiDigJhYduKAmSBpbiB5b3VyIHByb3Bvc2VkIHRl eHQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5SZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4tw6lyaWM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtjb2xvcjpibGFjayI+SHVhaW1vIENoZW4gJmx0O2h1YWltby5jaGVuQGZ1dHVyZXdl aS5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPk1vbmRheSwgNiBKdWx5IDIwMjAgYXQgMjE6MDU8 YnI+DQo8Yj5UbzogPC9iPlRoZSBJRVNHICZsdDtpZXNnQGlldGYub3JnJmd0OywgRXJpYyBWeW5j a2UgJmx0O2V2eW5ja2VAY2lzY28uY29tJmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7ZHJhZnQt aWV0Zi1wY2Utc3RhdGVmdWwtcGNlLWxzcC1zY2hlZHVsaW5nQGlldGYub3JnJnF1b3Q7ICZsdDtk cmFmdC1pZXRmLXBjZS1zdGF0ZWZ1bC1wY2UtbHNwLXNjaGVkdWxpbmdAaWV0Zi5vcmcmZ3Q7LCAm cXVvdDtwY2UtY2hhaXJzQGlldGYub3JnJnF1b3Q7ICZsdDtwY2UtY2hhaXJzQGlldGYub3JnJmd0 OywgJnF1b3Q7cGNlQGlldGYub3JnJnF1b3Q7ICZsdDtwY2VAaWV0Zi5vcmcmZ3Q7LCBBZHJpYW4g RmFycmVsICZsdDthZHJpYW5Ab2xkZG9nLmNvLnVrJmd0OywgQWRyaWFuIEZhcnJlbCAmbHQ7YWRy aWFuQG9sZGRvZy5jby51ayZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IMOJcmljIFZ5bmNr ZSdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLXBjZS1zdGF0ZWZ1bC1wY2UtbHNwLXNjaGVk dWxpbmctMTg6ICh3aXRoIENPTU1FTlQpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtj b2xvcjpibGFjayI+SGkgRXJpYyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2si PiZuYnNwOyAmbmJzcDsgVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgeW91ciB2YWx1YWJsZSBjb21t ZW50cywgd2hpY2ggaW1wcm92ZSB0aGUgcXVhbGl0eSBvZiB0aGUgZG9jdW1lbnQuJm5ic3A7Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDsgTXkgZXhwbGFuYXRpb25zL2Fuc3dlcnMg YXJlIGlubGluZSBiZWxvdyB3aXRoIHByZWZpeCBbSENdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkJlc3QgUmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+SHVhaW1v PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFs aWduPSJjZW50ZXIiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7dGV4dC1hbGlnbjpjZW50ZXIi Pg0KPGhyIHNpemU9IjAiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj4NCjwvZGl2Pg0KPGRp diBpZD0iZGl2UnBseUZ3ZE1zZyI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiDDiXJpYyBWeW5ja2UgdmlhIERhdGF0cmFja2Vy ICZsdDtub3JlcGx5QGlldGYub3JnJmd0Ozxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEp1bHkg NiwgMjAyMCAxMTowMiBBTTxicj4NCjxiPlRvOjwvYj4gVGhlIElFU0cgJmx0O2llc2dAaWV0Zi5v cmcmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBkcmFmdC1pZXRmLXBjZS1zdGF0ZWZ1bC1wY2UtbHNwLXNj aGVkdWxpbmdAaWV0Zi5vcmcgJmx0O2RyYWZ0LWlldGYtcGNlLXN0YXRlZnVsLXBjZS1sc3Atc2No ZWR1bGluZ0BpZXRmLm9yZyZndDs7IHBjZS1jaGFpcnNAaWV0Zi5vcmcgJmx0O3BjZS1jaGFpcnNA aWV0Zi5vcmcmZ3Q7OyBwY2VAaWV0Zi5vcmcgJmx0O3BjZUBpZXRmLm9yZyZndDs7IEFkcmlhbiBG YXJyZWwgJmx0O2FkcmlhbkBvbGRkb2cuY28udWsmZ3Q7OyBhZHJpYW5Ab2xkZG9nLmNvLnVrICZs dDthZHJpYW5Ab2xkZG9nLmNvLnVrJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiDDiXJpYyBWeW5j a2UncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1wY2Utc3RhdGVmdWwtcGNlLWxzcC1zY2hl ZHVsaW5nLTE4OiAod2l0aCBDT01NRU5UKTwvc3Bhbj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+w4lyaWMgVnluY2tlIGhhcyBlbnRl cmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcjxicj4NCmRyYWZ0LWlldGYtcGNl LXN0YXRlZnVsLXBjZS1sc3Atc2NoZWR1bGluZy0xODogTm8gT2JqZWN0aW9uPGJyPg0KPGJyPg0K V2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQg cmVwbHkgdG8gYWxsPGJyPg0KZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQg Q0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXM8YnI+DQppbnRyb2R1Y3RvcnkgcGFyYWdy YXBoLCBob3dldmVyLik8YnI+DQo8YnI+DQo8YnI+DQpQbGVhc2UgcmVmZXIgdG8gPGEgaHJlZj0i aHR0cHM6Ly9uYW0xMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBz JTNBJTJGJTJGd3d3LmlldGYub3JnJTJGaWVzZyUyRnN0YXRlbWVudCUyRmRpc2N1c3MtY3JpdGVy aWEuaHRtbCZhbXA7YW1wO2RhdGE9MDIlN0MwMSU3Q2h1YWltby5jaGVuJTQwZnV0dXJld2VpLmNv bSU3Q2U1MjYxOGEyNTMyODRiZGNmMjk2MDhkODIxYmQ5MjFhJTdDMGZlZThmZjJhM2IyNDAxODlj NzUzYTFkNTU5MWZlZGMlN0MxJTdDMCU3QzYzNzI5NjQ0NTM4MzQxMDM2MyZhbXA7YW1wO3NkYXRh PWF2am0lMkJ3SjRBJTJGS3B5QW5UYkdZMGhONm51dDJ3NXVEd2pPeHUlMkJWMmolMkIlMkZJJTNE JmFtcDthbXA7cmVzZXJ2ZWQ9MCI+DQpodHRwczovL25hbTExLnNhZmVsaW5rcy5wcm90ZWN0aW9u Lm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZpZXNnJTJGc3Rh dGVtZW50JTJGZGlzY3Vzcy1jcml0ZXJpYS5odG1sJmFtcDthbXA7ZGF0YT0wMiU3QzAxJTdDaHVh aW1vLmNoZW4lNDBmdXR1cmV3ZWkuY29tJTdDZTUyNjE4YTI1MzI4NGJkY2YyOTYwOGQ4MjFiZDky MWElN0MwZmVlOGZmMmEzYjI0MDE4OWM3NTNhMWQ1NTkxZmVkYyU3QzElN0MwJTdDNjM3Mjk2NDQ1 MzgzNDEwMzYzJmFtcDthbXA7c2RhdGE9YXZqbSUyQndKNEElMkZLcHlBblRiR1kwaE42bnV0Mnc1 dUR3ak94dSUyQlYyaiUyQiUyRkklM0QmYW1wO2FtcDtyZXNlcnZlZD0wPC9hPjxicj4NCmZvciBt b3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMu PGJyPg0KPGJyPg0KPGJyPg0KVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBw b3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vbmFtMTEu c2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmRhdGF0 cmFja2VyLmlldGYub3JnJTJGZG9jJTJGZHJhZnQtaWV0Zi1wY2Utc3RhdGVmdWwtcGNlLWxzcC1z Y2hlZHVsaW5nJTJGJmFtcDthbXA7ZGF0YT0wMiU3QzAxJTdDaHVhaW1vLmNoZW4lNDBmdXR1cmV3 ZWkuY29tJTdDZTUyNjE4YTI1MzI4NGJkY2YyOTYwOGQ4MjFiZDkyMWElN0MwZmVlOGZmMmEzYjI0 MDE4OWM3NTNhMWQ1NTkxZmVkYyU3QzElN0MwJTdDNjM3Mjk2NDQ1MzgzNDIwMzYwJmFtcDthbXA7 c2RhdGE9cTRDOGlORDBvQUdKZ2N5NkhmcFZ0MXp2bEM2Y2slMkJLcmZReFZCcE44akcwJTNEJmFt cDthbXA7cmVzZXJ2ZWQ9MCI+aHR0cHM6Ly9uYW0xMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRs b29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZk cmFmdC1pZXRmLXBjZS1zdGF0ZWZ1bC1wY2UtbHNwLXNjaGVkdWxpbmclMkYmYW1wO2FtcDtkYXRh PTAyJTdDMDElN0NodWFpbW8uY2hlbiU0MGZ1dHVyZXdlaS5jb20lN0NlNTI2MThhMjUzMjg0YmRj ZjI5NjA4ZDgyMWJkOTIxYSU3QzBmZWU4ZmYyYTNiMjQwMTg5Yzc1M2ExZDU1OTFmZWRjJTdDMSU3 QzAlN0M2MzcyOTY0NDUzODM0MjAzNjAmYW1wO2FtcDtzZGF0YT1xNEM4aU5EMG9BR0pnY3k2SGZw VnQxenZsQzZjayUyQktyZlF4VkJwTjhqRzAlM0QmYW1wO2FtcDtyZXNlcnZlZD0wPC9hPjxicj4N Cjxicj4NCjxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpDT01NRU5UOjxicj4NCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS08YnI+DQo8YnI+DQpUaGFuayB5b3UgZm9yIHRoZSB3b3JrIHB1dCBpbnRvIHRoaXMg ZG9jdW1lbnQuPGJyPg0KPGJyPg0KUGxlYXNlIGZpbmQgYmVsb3cgb25lIG5vbi1ibG9ja2luZyBD T01NRU5Ucy48YnI+DQo8YnI+DQpJIGhvcGUgdGhhdCB0aGlzIGhlbHBzIHRvIGltcHJvdmUgdGhl IGRvY3VtZW50LDxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KPGJyPg0KLcOpcmljPGJyPg0KPGJy Pg0KPT0gQ09NTUVOVFMgPT08YnI+DQo8YnI+DQotLSBTZWN0aW9uIDQuMi4yLjEgLS08YnI+DQpN YXkgYmUgYW0gSSBmYWlsaW5nIHRvIHVuZGVyc3RhbmQgdGhpcyBwYXJ0IG9mIHRoZSBzZW50ZW5j ZSAmcXVvdDt8WHwgaXMgdGhlIG1pbmltdW08YnI+DQp2YWx1ZSBmcm9tIDAgdG8gbWF4KFAsIFEp JnF1b3Q7IGFzIGl0IGlzIG5vdCB0aGUgc2FtZSBhcyAmcXVvdDt3aGVyZSAtUCAmbHQ7PSBYICZs dDs9IFEmcXVvdDsgb3I8YnI+DQpkb2VzIHRoZSAmcXVvdDt8WHwmcXVvdDsgbm90IHJlcHJlc2Vu dCB0aGUgYWJzb2x1dGUgdmFsdWUgb2YgWCA/PGJyPg0KPGJyPg0KW0hDXTombmJzcDsmcXVvdDt8 WHwmcXVvdDsgcmVwcmVzZW50cyB0aGUgYWJzb2x1dGUgdmFsdWUgb2YgWC4gPG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+VGhlcmUgYXJlIHR3byBzZW50ZW5jZXM6IDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+MSkgJnF1 b3Q7W1RhLCBUYl0gd2l0aGluIC1QIGFuZCBRJnF1b3Q7IG1lYW5zIGEgdGltZSBwZXJpb2QgZnJv bSAoVGEmIzQzO1gpIHRvIChUYiYjNDM7WCksDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNw OyAmbmJzcDt3aGVyZSAtUCAmbHQ7PSBYICZsdDs9IFEuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4y KSBXaGVuIGFuIExTUCBpcyBjb25maWd1cmVkIHdpdGggZWxhc3RpYyB0aW1lIGludGVydmFsICZx dW90O1tUYSwgVGJdIHdpdGhpbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7ICZuYnNwOy1Q IGFuZCBRJnF1b3Q7LCBhIHBhdGggaXMgY29tcHV0ZWQgc3VjaCB0aGF0IHRoZSBwYXRoIHNhdGlz ZmllcyB0aGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOyAmbmJzcDtjb25zdHJhaW50cyBm b3IgdGhlIExTUCBpbiB0aGUgdGltZSBwZXJpb2QgZnJvbSAoVGEmIzQzO1gpIHRvIChUYiYjNDM7 WCk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOyAmbmJzcDthbmQgfFh8IGlzIHRoZSBtaW5p bXVtIHZhbHVlIGZyb20gMCB0byBtYXgoUCwgUSkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5JbiB0 aGUgZmlyc3Qgc2VudGVuY2UsIGFuIGFjY2VwdGFibGUgcmFuZ2Ugb2YgWCBpcyBnaXZlbiBieSAt UCAmbHQ7PSBYICZsdDs9IFEuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5JbiB0aGUgc2Vjb25kIHNl bnRlbmNlLCBhIHZhbHVlIG9mIFggaXMgZm91bmQgd2l0aGluIHRoZSBhY2NlcHRhYmxlIHJhbmdl PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij50byBzYXRpc2ZpZXMgdGhlIGNvbnN0cmFpbnRzLiA8bzpw Pg0KPC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SWYgd2UgY2hhbmdlIFggdG8gWHYgaW4gdGhlIHNlY29uZCBz ZW50ZW5jZSwgaXQgbWF5IGJlIGNsZWFyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+MiknIFdoZW4g YW4gTFNQIGlzIGNvbmZpZ3VyZWQgd2l0aCBlbGFzdGljIHRpbWUgaW50ZXJ2YWwgJnF1b3Q7W1Rh LCBUYl0gd2l0aGluPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDsgJm5ic3A7LVAgYW5kIFEm cXVvdDssIGEgcGF0aCBpcyBjb21wdXRlZCBzdWNoIHRoYXQgdGhlIHBhdGggc2F0aXNmaWVzIHRo ZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7ICZuYnNwO2NvbnN0cmFpbnRzIGZvciB0aGUg TFNQIGluIHRoZSB0aW1lIHBlcmlvZCBmcm9tIChUYSYjNDM7WHYpIHRvIChUYiYjNDM7WHYpPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDsgJm5ic3A7YW5kIHxYdnwgaXMgdGhlIG1pbmltdW0g dmFsdWUgZm9yIFZ4IGZyb20gLVAgdG8gUS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+V2UgaGF2ZSByZXBocmFz ZWQgdGhlIHJlbGF0ZWQgdGV4dCBpbiB0aGUgdXBkYXRlZCBkb2N1bWVudC48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxicj4NCj09IE5JVFMgPT08YnI+DQo8YnI+DQotLSBTZWN0aW9uIDQuMi4yLjEg LS08YnI+DQpQbGVhc2UgdXNlICZxdW90O2FyZSZxdW90OyByYXRoZXIgdGhhbiAmcXVvdDtpcyZx dW90OyBpbiAmcXVvdDtOb3RlIHRoYXQgYm90aCBUYSBhbmQgVGIgaXMgc2hpZnRlZCBieTxicj4N CnRoZSBzYW1lICdYJyZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OjBjbTttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206MTIuMHB0O21h cmdpbi1sZWZ0OjM2LjBwdCI+DQpbSENdOiZuYnNwO1dlIGhhdmUgY2hhbmdlZCAmcXVvdDtpcyZx dW90OyB0byAmcXVvdDthcmUmcXVvdDsuPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_007EB8BDECEE42D8B379BE700E089618ciscocom_-- From nobody Mon Jul 6 23:11:12 2020 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 47ABA3A0948; Mon, 6 Jul 2020 23:11:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Murray Kucherawy via Datatracker To: "The IESG" Cc: draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org, pce-chairs@ietf.org, pce@ietf.org, Adrian Farrel X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Murray Kucherawy Message-ID: <159410226606.30562.499771898082555566@ietfa.amsl.com> Date: Mon, 06 Jul 2020 23:11:06 -0700 Archived-At: Subject: [Pce] Murray Kucherawy's No Objection on draft-ietf-pce-stateful-pce-lsp-scheduling-19: (with COMMENT) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 06:11:06 -0000 Murray Kucherawy has entered the following ballot position for draft-ietf-pce-stateful-pce-lsp-scheduling-19: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-lsp-scheduling/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 2.1: * "Passive Stateful PCE" is listed in the imported terminology, but not used elsewhere in the document. Sections 5.2.1 & 5.2.2: * I had the same questions Erik did about the R-bit. Section 7: The text here is unchanged since version -09 of this document, which recorded no known implementations, and was posted almost a year ago. Is that still the case now? Section 10.1.1: This section defines a new registry but doesn't explicitly describe the fields of that registry like Section 10.1.2 does. It's nice to be explicit about these things, in my opinion. From nobody Tue Jul 7 09:40:51 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A152B3A08D4; Tue, 7 Jul 2020 09:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com 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 TYA2tdp4hAra; Tue, 7 Jul 2020 09:40:40 -0700 (PDT) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2098.outbound.protection.outlook.com [40.107.92.98]) (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 746583A08C6; Tue, 7 Jul 2020 09:40:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=T+wsMYlw0yzsLvPL+ko/z85FBfuadeBtzkwe1urHH6mdHxm+Rcjcis1qkr8IxFxBBkweq5e3/xBTgutycG2DU/tL8YWKH/euBy3w0MxXn/lzyrTiHeGmhhma3p+ixsP284o23vAArosc7gYRIKFENWFow8oEzh/LIZ/4dJI5WReXO3dpcg2T+/AqIoVER7Eq7g4zj2g1HQ6O93SstoRX2FxWWl6a+v5G3qP2ZSuSbW9V59FFn5kjr4KV7Wd2P1IokoGsJ06SUWPVBICfbS7Z8T8ReJm2HPlcCdPfzPkqXh3s1gvxXfRDC/PedYujlXy27uPiZJOL2Ln+LfrMg5K1Eg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zJE+IMTQkygquxrTKC3nZxxAH/GdEhv+7wLvM6wmoDI=; b=btfiSIZDEiJb/aOvdMQLhNGPoGmVGayQCuHEJEXAKgOPwduFqw7X/N11gT5daO5gImjukr5vNGN9jAFPzgWN0ESWpEh1xP3YGvQwVoXN0Pa2rCM0OTAiDcIYAixHXbl5fuS8VWcc3yqZAoNYBZxCvOmcdB22ROOXSUQUvtvqAxTggfomqvgZCLx01fwLi5emAue7ZSLAM8s8YDXzhCjYbNBIAXe3ifxJtNQKDePSHG10grF9NjmzaIZfJAZ/HiKPXdL0CjhvL/YVOM1Cu3USWrZGWTx0XcyIAeYWPZDKBYlqOJjoMwKysIiLBUYlSVadKaooXvJTYW/6VJdmnw+PZg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zJE+IMTQkygquxrTKC3nZxxAH/GdEhv+7wLvM6wmoDI=; b=Ho99bJ0P6BjHF6pDLpRxk31r3rnMqZb+45CpJ5JgCC4BeB+RGWZqCVbzbEZ0CP2crLYCNBkef48xflHgbs+KfngaCVUOJu1Swdm/VGDG7DJ0e9v5ylMYDrAJeMa7mH33QilWRtCDN8mIdqFdfv0fDWOFoAbO78rT5m4QG4elqTA= Received: from MN2PR13MB3117.namprd13.prod.outlook.com (2603:10b6:208:13a::20) by MN2PR13MB3471.namprd13.prod.outlook.com (2603:10b6:208:168::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.8; Tue, 7 Jul 2020 16:40:37 +0000 Received: from MN2PR13MB3117.namprd13.prod.outlook.com ([fe80::d5b6:8550:9c40:eec2]) by MN2PR13MB3117.namprd13.prod.outlook.com ([fe80::d5b6:8550:9c40:eec2%7]) with mapi id 15.20.3174.019; Tue, 7 Jul 2020 16:40:37 +0000 From: Huaimo Chen To: "Eric Vyncke (evyncke)" , The IESG CC: "draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org" , "pce-chairs@ietf.org" , "pce@ietf.org" , Adrian Farrel Thread-Topic: =?Windows-1252?Q?=C9ric_Vyncke's_No_Objection_on_draft-ietf-pce-stateful-?= =?Windows-1252?Q?pce-lsp-scheduling-18:_(with_COMMENT)?= Thread-Index: AQHWU6Zxwdqp0EqERk6bTki4I0SVi6j65rXpgADdMoCAAI7LNg== Date: Tue, 7 Jul 2020 16:40:37 +0000 Message-ID: References: <159404773419.726.16088712990695893519@ietfa.amsl.com> , <007EB8BD-ECEE-42D8-B379-BE700E089618@cisco.com> In-Reply-To: <007EB8BD-ECEE-42D8-B379-BE700E089618@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=futurewei.com; x-originating-ip: [2601:199:4300:8e5a:614a:385c:1647:35e3] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a4f3fe4b-eda1-461e-9c06-08d822947a1a x-ms-traffictypediagnostic: MN2PR13MB3471: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: hARVjgQB1oNrTGYdbizF5wxpZgdiGEhGSjDJl+yMp41FuJFVVsXXmZfujTI5hf66G7Y+pigStL8FNXDgXGUq1kmtW8aSaG7r4a3CUQgG5++2iY938yYm0gDUp0eYujtTzOdE6WKuqaqEGLFAW6YTLQUfo6A6OAFEIU/l8yxWqUvRGPAsa1nsXbgFjqGl+y9QKsZeqYm4762fQdwQGahl8BE3GxluwFKmKUQeBrSUXOPnKkWZdzD+Kgt8W89BADrnLPGBYq9lM1KCZOsD9E921lOmBnLMkbH+HRCQatPWnHP9dtkkXdj30TeuxDM+83vfSI215FKPfqNarf/GS0SNcVMtdXQdHDS2b0fp8tym2IljRjMV80TAWaNVQpMvX1SaDKMgGqTduhT650jyQlfHzg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR13MB3117.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(346002)(39830400003)(136003)(376002)(366004)(76116006)(71200400001)(5660300002)(8936002)(55016002)(9686003)(186003)(66556008)(66476007)(66446008)(64756008)(52536014)(54906003)(66946007)(44832011)(33656002)(53546011)(4326008)(166002)(478600001)(45080400002)(110136005)(316002)(966005)(2906002)(224303003)(6506007)(7696005)(19627405001)(83380400001)(86362001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: al9b9QGVPdpaNClSIMqu6D6fxG34BFTx3V9PPKTE+m81eCnvPOyFjNY1I58WcCbtoyT+y5K7D+vmw7w/N1y1hAffbHa1VapZvMwkY9hAwd7SGWOGX+rGvg6IheeGFt7MiYvawnKhHSPuSrzWK3hc/I8ro39L5yTJvYCt5/fR1eZ35pIat7oA/GY1DD4fmNRtK/32nsB1i7vtHCpaHMpwiwOCxKXHu7YKDbtbTC997rbunbtM47uITnxSRoMaw79OLwapBJkCJZQZCjWC5bWUYrsilZ9i/DtOGEiD/qw7UZHRVvx1Iklge2KtVtjG8PI7CUy1CLM9qifqcbgSSvzAW7BeTYJyj9G40GzZV9vmzDSnYChNnWAQSnH8RLV6uaU1dD1eeHXExfQeaNweNG8hJoFCkRFiC1qoov7ZKKCy+/tC/8XVRrUoJ8qnUYx0Fk/QKqXVYYlYY7iyDRB398O5MYbQxb17CB3uiuQRE3AMjJOhbCl7Qy5IkhJg2/O73iz+dZnhzWye1hSNCudjPP66tY/bjcbMlMzBzwKxtLFLKLQQwDKOmU/USh1pu3lWe193 x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR13MB3117D8FA11EEB007C322AC8CF2660MN2PR13MB3117namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR13MB3117.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a4f3fe4b-eda1-461e-9c06-08d822947a1a X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2020 16:40:37.0224 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: hJeo4mEk0D8M9fA59masJp8XKNhsIxHU3g/qEXe+U4bvslTHbiKjA5y1iBXylfe+WnuJKQ64Tr/ZEP4+xrIHsg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR13MB3471 Archived-At: Subject: Re: [Pce] =?windows-1252?q?=C9ric_Vyncke=27s_No_Objection_on_draft-i?= =?windows-1252?q?etf-pce-stateful-pce-lsp-scheduling-18=3A_=28with_COMMEN?= =?windows-1252?q?T=29?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 16:40:43 -0000 --_000_MN2PR13MB3117D8FA11EEB007C322AC8CF2660MN2PR13MB3117namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Eric, Thank you very much. We will correct it (change Vx to Xv) accordingly. Best Regards, Huaimo ________________________________ From: Eric Vyncke (evyncke) Sent: Tuesday, July 7, 2020 2:07 AM To: Huaimo Chen ; The IESG Cc: draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org ; pce-chairs@ietf.org ; pce@ietf.org ; Adrian Farrel Subject: Re: =C9ric Vyncke's No Objection on draft-ietf-pce-stateful-pce-ls= p-scheduling-18: (with COMMENT) Thank you Huaimo for your reply. Please note that you used =91Vx=92 rather than =91Xv=92 in your proposed te= xt. Regards -=E9ric From: Huaimo Chen Date: Monday, 6 July 2020 at 21:05 To: The IESG , Eric Vyncke Cc: "draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org" , "pce-chairs@ietf.org" , "pce@ietf.org" , Adrian Farrel ,= Adrian Farrel Subject: Re: =C9ric Vyncke's No Objection on draft-ietf-pce-stateful-pce-ls= p-scheduling-18: (with COMMENT) Hi Eric, Thank you very much for your valuable comments, which improve the quali= ty of the document. My explanations/answers are inline below with prefix [HC]. Best Regards, Huaimo ________________________________ From: =C9ric Vyncke via Datatracker Sent: Monday, July 6, 2020 11:02 AM To: The IESG Cc: draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org ; pce-chairs@ietf.org ; pce@ietf.org ; Adrian Farrel ; adria= n@olddog.co.uk Subject: =C9ric Vyncke's No Objection on draft-ietf-pce-stateful-pce-lsp-sc= heduling-18: (with COMMENT) =C9ric Vyncke has entered the following ballot position for draft-ietf-pce-stateful-pce-lsp-scheduling-18: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://nam11.safelinks.protection.outlook.com/?url=3Dhttps= %3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html&data= =3D02%7C01%7Chuaimo.chen%40futurewei.com%7Ce52618a253284bdcf29608d821bd921a= %7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637296445383410363&sdata= =3Davjm%2BwJ4A%2FKpyAnTbGY0hN6nut2w5uDwjOxu%2BV2j%2B%2FI%3D&reserved=3D= 0 for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatra= cker.ietf.org%2Fdoc%2Fdraft-ietf-pce-stateful-pce-lsp-scheduling%2F&dat= a=3D02%7C01%7Chuaimo.chen%40futurewei.com%7Ce52618a253284bdcf29608d821bd921= a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637296445383420360&sdata= =3Dq4C8iND0oAGJgcy6HfpVt1zvlC6ck%2BKrfQxVBpN8jG0%3D&reserved=3D0 ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. Please find below one non-blocking COMMENTs. I hope that this helps to improve the document, Regards, -=E9ric =3D=3D COMMENTS =3D=3D -- Section 4.2.2.1 -- May be am I failing to understand this part of the sentence "|X| is the min= imum value from 0 to max(P, Q)" as it is not the same as "where -P <=3D X <=3D Q= " or does the "|X|" not represent the absolute value of X ? [HC]: "|X|" represents the absolute value of X. There are two sentences: 1) "[Ta, Tb] within -P and Q" means a time period from (Ta+X) to (Tb+X), where -P <=3D X <=3D Q. 2) When an LSP is configured with elastic time interval "[Ta, Tb] within -P and Q", a path is computed such that the path satisfies the constraints for the LSP in the time period from (Ta+X) to (Tb+X) and |X| is the minimum value from 0 to max(P, Q). In the first sentence, an acceptable range of X is given by -P <=3D X <=3D = Q. In the second sentence, a value of X is found within the acceptable range to satisfies the constraints. If we change X to Xv in the second sentence, it may be clear. 2)' When an LSP is configured with elastic time interval "[Ta, Tb] within -P and Q", a path is computed such that the path satisfies the constraints for the LSP in the time period from (Ta+Xv) to (Tb+Xv) and |Xv| is the minimum value for Vx from -P to Q. We have rephrased the related text in the updated document. =3D=3D NITS =3D=3D -- Section 4.2.2.1 -- Please use "are" rather than "is" in "Note that both Ta and Tb is shifted b= y the same 'X'" [HC]: We have changed "is" to "are". --_000_MN2PR13MB3117D8FA11EEB007C322AC8CF2660MN2PR13MB3117namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Eric,

    Thank you very much.
    We will correct it (change Vx to Xv) accordingly.

Best Regards,
Huaimo
From: Eric Vyncke (evyncke)= <evyncke@cisco.com>
Sent: Tuesday, July 7, 2020 2:07 AM
To: Huaimo Chen <huaimo.chen@futurewei.com>; The IESG <iesg= @ietf.org>
Cc: draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org <draft-ie= tf-pce-stateful-pce-lsp-scheduling@ietf.org>; pce-chairs@ietf.org <pc= e-chairs@ietf.org>; pce@ietf.org <pce@ietf.org>; Adrian Farrel <= ;adrian@olddog.co.uk>
Subject: Re: =C9ric Vyncke's No Objection on draft-ietf-pce-stateful= -pce-lsp-scheduling-18: (with COMMENT)
 

Thank you Huaimo for your reply.

 

Please note that you used =91Vx=92 rather than =91Xv=92 in your proposed text.

 

Regards

 

-=E9ric

 

From: Huaimo Chen <huaimo.chen@futurewei.= com>
Date: Monday, 6 July 2020 at 21:05
To: The IESG <iesg@ietf.org>, Eric Vyncke <evyncke@cisco.co= m>
Cc: "draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org" = <draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org>, "pce-chai= rs@ietf.org" <pce-chairs@ietf.org>, "pce@ietf.org" <= ;pce@ietf.org>, Adrian Farrel <adrian@olddog.co.uk>, Adrian Farrel= <adrian@olddog.co.uk>
Subject: Re: =C9ric Vyncke's No Objection on draft-ietf-pce-stateful= -pce-lsp-scheduling-18: (with COMMENT)

 

Hi Eric,

 

    Thank you very = much for your valuable comments, which improve the quality of the document.=   

    My explanations= /answers are inline below with prefix [HC].

 

Best Regards,

Huaimo

From:= =C9ric Vyncke via Datatracker <noreply@ietf.org>
Sent: Monday, July 6, 2020 11:02 AM
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org <draft-ie= tf-pce-stateful-pce-lsp-scheduling@ietf.org>; pce-chairs@ietf.org <pc= e-chairs@ietf.org>; pce@ietf.org <pce@ietf.org>; Adrian Farrel <= ;adrian@olddog.co.uk>; adrian@olddog.co.uk <adrian@olddog.co.uk> Subject: =C9ric Vyncke's No Objection on draft-ietf-pce-stateful-pce= -lsp-scheduling-18: (with COMMENT)

 

=C9ric Vyncke has entered the following ballot position for
draft-ietf-pce-stateful-pce-lsp-scheduling-18: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html&amp;data=3D02%7C01%7Ch= uaimo.chen%40futurewei.com%7Ce52618a253284bdcf29608d821bd921a%7C0fee8ff2a3b= 240189c753a1d5591fedc%7C1%7C0%7C637296445383410363&amp;sdata=3Davjm%2Bw= J4A%2FKpyAnTbGY0hN6nut2w5uDwjOxu%2BV2j%2B%2FI%3D&amp;reserved=3D0 for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http= s://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatracker= .ietf.org%2Fdoc%2Fdraft-ietf-pce-stateful-pce-lsp-scheduling%2F&amp;dat= a=3D02%7C01%7Chuaimo.chen%40futurewei.com%7Ce52618a253284bdcf29608d821bd921= a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637296445383420360&amp;s= data=3Dq4C8iND0oAGJgcy6HfpVt1zvlC6ck%2BKrfQxVBpN8jG0%3D&amp;reserved=3D= 0



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work put into this document.

Please find below one non-blocking COMMENTs.

I hope that this helps to improve the document,

Regards,

-=E9ric

=3D=3D COMMENTS =3D=3D

-- Section 4.2.2.1 --
May be am I failing to understand this part of the sentence "|X| is th= e minimum
value from 0 to max(P, Q)" as it is not the same as "where -P <= ;=3D X <=3D Q" or
does the "|X|" not represent the absolute value of X ?

[HC]: "|X|" represents the absolute value of X.

There are two sentences:

1) "[Ta, Tb] within -P and Q" means a time period from (Ta+X)= to (Tb+X),

   where -P <=3D X <=3D Q.

2) When an LSP is configured with elastic time interval "[Ta, Tb] with= in

   -P and Q", a path is computed such that the path satisfie= s the

   constraints for the LSP in the time period from (Ta+X) to = (Tb+X)

   and |X| is the minimum value from 0 to max(P, Q).

In the first sentence, an acceptable range of X is given by -P <=3D X &l= t;=3D Q.

In the second sentence, a value of X is found within the acceptable range

to satisfies the constraints.

If we change X to Xv in the second sentence, it may be clear.

2)' When an LSP is configured with elastic time interval "[Ta, Tb] wit= hin

   -P and Q", a path is computed such that the path satisfie= s the

   constraints for the LSP in the time period from (Ta+Xv) to= (Tb+Xv)

   and |Xv| is the minimum value for Vx from -P to Q.

We have rephrased the related text in the updated document.


=3D=3D NITS =3D=3D

-- Section 4.2.2.1 --
Please use "are" rather than "is" in "Note that bo= th Ta and Tb is shifted by
the same 'X'"

 

[HC]: We have changed "is" to "are".


--_000_MN2PR13MB3117D8FA11EEB007C322AC8CF2660MN2PR13MB3117namp_-- From nobody Tue Jul 7 11:38:14 2020 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 08DCC3A13C7; Tue, 7 Jul 2020 11:38:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Alvaro Retana via Datatracker To: "The IESG" Cc: draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org, pce-chairs@ietf.org, pce@ietf.org, Adrian Farrel X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alvaro Retana Message-ID: <159414709200.5178.3398442601733460072@ietfa.amsl.com> Date: Tue, 07 Jul 2020 11:38:12 -0700 Archived-At: Subject: [Pce] Alvaro Retana's No Objection on draft-ietf-pce-stateful-pce-lsp-scheduling-19: (with COMMENT) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 18:38:12 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-pce-stateful-pce-lsp-scheduling-19: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-lsp-scheduling/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I think that this document still needs work before publication. I consider the first 3 points below to be close to DISCUSS-worthy. (1) In general, it feels like an editorial pass is needed to tighten up the language used as specification in this document. There are several places where the language feels loose -- as an example (from §4.4): In PCC-Initiated case, the PCC can send a PCRpt message for the scheduled LSP with updated parameters as well as scheduled information included in the SCHED-LSP-ATTRIBUTE TLV (see Section 5.2.1) or SCHED-PD-LSP-ATTRIBUTE TLV (see Section 5.2.2) carried in the LSP Object. The PCE would take the updated resources and schedule into considerations and update the new path for the scheduled LSP to the PCC as well as synchronize to other PCEs in the network. In case path cannot be set based on new requirements, the previous LSP will not be impacted and the same should be conveyed by the use of empty ERO in the PCEP messages. "the PCC can send" Does it have to? If the information is not sent, then the PCE will not be able to calculate the path, so something stronger than "can" seems to be needed. "PCE would take" Does this mean that it is optional? I can imagine how the PCE may have local policies affecting the action...but I shouldn't have to imagine anything. "should be conveyed" Again, do you have to? Are there cases when it is ok not to do it? Not everything needs rfc2119 key words, but in some cases they would help. In this case, I can see a couple of variations possible. rfc2119> ...the PCC MUST send...the PCE SHOULD take...MUST be conveyed... non-rfc2119> ...the PCC sends...the PCE takes...is conveyed... (2) §4.1: "a PCE MUST synchronize to other PCEs within the network...Which way is used to achieve this is out of scope for this document." If the synchronization mechanism is out of scope, how can an implementation be compliant with this specification? IOW, if there's nothing to normatively refer to, then normative language shouldn't be used, or a mechanism should be mandated. In either case, because synchronization between the PCEs seems important for this specification, I would like to also see a discussion about the specific effects on LSP scheduling instead of the generic pointer to rfc7399. §4.3 says that the "stateful PCE...shall send a PCRpt message with the scheduled LSP to other PCEs...to achieve...synchronization." Even though normative language is not used, the intent seems to specifically point at using PCRpt messages for synchronization... Besides the confusing use of language, rfc8231 defines PCRpt as a "message sent by a PCC to a PCE to report the current state of an LSP", but I didn't see where the use if defined between PCEs -- maybe I missed it. §6.1 does reinforce that the "Path Computation State Report (PCRpt) is a PCEP message sent by a PCC to a PCE to report the status of one or more LSPs as per [RFC8231]....This message is also used to synchronize the scheduled LSPs to other PCE as described in [RFC8231]". But this last point is what I can't find in rfc8231. (3) This whole document is about scheduling LSPs, which would seem to require time synchronization. However, I found only one mention: "It is necessary to synchronize the clocks of the PCEs and PCCs when relative time is used." Should this sentence use normative language? Is there a recommended way to achieve time synchronization? This seems to be an important manageability consideration that impacts network operations. (4) rfc8413 should be a Normative reference because it "provides a framework that describes and discusses the problem, and defines an appropriate architecture for the scheduled reservation of TE resources", which is the basis for the extensions defined in this document. (5) §2.1: Some of the terminology terms have 2 references -- that caught my attention. For example, the definition of TED points at both rfc5440 and rfc8231. rfc5440 has a definition, but rfc8231 points at rfc4655. Luckily, the definitions in rfc5440 and rfc4655 are the same...but the added indirection through rfc8231 is unnecessary. Please revalidate the references and include only one. (6) §2.1: "Duration: This value indicates the time duration..." Please don't use "duration" to define "duration". Maybe s/time duration/length of time (7) §4.1: "A PCC MUST delegate a scheduled LSP with information of its scheduling parameters, including the starting time and the duration using PCRpt message." This sentence seems to refer to the use of the new TLVs defined later in the test. Please include a forward reference to make it easier for the reader to figure out how this action would be done. (8) §4.3: "The PCE SHOULD add the scheduled LSP into its scheduled LSP-DB and update its scheduled TED." When is it ok for the PCE not to add this information? IOW, why is MUST not used? If the information is not added, what is the effect on the required synchronization? Later in this section: "The stateful PCE is required to update its local scheduled LSP-DB and scheduled TED with the scheduled LSP." Even though normative language is not used here, the intent of requiring an update to the databases seems different than above and results in confusion. (9) §4.3: "the PCC knows that it is a scheduled path" How? I'm sure that it is through the contents of the messages. Please be specific. (10) §5.1: "After a PCEP session has been established, a PCC and a PCE indicates its ability to support LSP scheduling during the PCEP session establishment phase." Is it after or during? (11) §5.1: "...the STATEFUL-PCE-CAPABILITY TLV defined in [RFC8231]. Note that the STATEFUL-PCE-CAPABILITY TLV is defined in [RFC8231]..." Redundant. (12) §5.1: "we define a new flag bit B (SCHED-LSP-CAPABLITY) flag...B (LSP-SCHEDULING-CAPABILITY..." The names don't match. (13) §5.1: "Setting PD bit requires setting B bit as specified in 5.2.2." That is not specified in §5.2.2. However, it brings up the question about the interpretation of only receiving the PD bit set -- I'm assuming that it should be ignored unless the B but is also set, right? If so, please specify it! (14) §5.2: "this LSP is requesting scheduled parameters" The request is by the PCC, not the LSP... (15) §5.2: "scheduled LSP attribute TLV" Even though it may be obvious, the SCHED-LSP-ATTRIBUTE TLV is not called "scheduled LSP attribute TLV" anywhere in the document. (16) §5.2: "For periodical LSPs, the SCHED-PD-LSP-ATTRIBUTE TLV can be used in LSP Object for each periodic scheduled LSP carried in the PCEP messages." Don't you *have* to use it? Otherwise, how would the periodic nature be known? (17) §5.2: "Only one of these TLV SHOULD be present in the LSP object. In case more than one scheduling TLV is found, the first instance is processed and others ignored." This section talks about both the SCHED-LSP-ATTRIBUTE and the SCHED-PD-LSP-ATTRIBUTE TLVs -- the sentence sounds as if only one of them (either one) should be present. Please rephrase -- it may be better to define this behavior for each TLV independently (in §5.2.*). (18) §5.2.1: "This TLV MUST NOT be included unless both PCEP peers have set the B..." What should the receiver do if the TLV is received when both peers didn't set the B bit? (19) §5.2.1: "Just before the wraparound, if the time at which the LSP is to be activated is after the wraparound..." I don't know how that is possible. (20) §5.2.1: "...non-zero grace period or elastic range, but it MUST NOT provide both for an LSP." What should a receiver do if both sets are non-zero? (21) §5.2.2: "This TLV MUST NOT be included unless both PCEP peers have set the B...and PD..." What should the receiver do if the TLV is received but both bits were not set? (22) §5.2.2: "A new registry "Opt" under SCHED-PD-LSP-ATTRIBUTE is created." The registry is not part of the definition of the field...this sentence is not needed here. (23) §5.2.2: "Opt value not defined" I think you may mean an unknown value (or maybe unsupported). (24) Nits: s/following terminologies are re-used/following terminology is re-used s/computes a path/compute a path/g s/by PCE itself/by a|the PCE itself s/setup of LSP/setup of an LSP s/ask PCC/ask the PCC s/In PCC-Initiated case/In the PCC-Initiated case/g s/In PCE-Initiated case/In the PCE-Initiated case/g s/establish PCEP session/establish a PCEP session s/Setting PD bit requires setting B bit/Setting the PD bit requires setting the B bit s/presence of SCHED-LSP-ATTRIBUTE/presence of the SCHED-LSP-ATTRIBUTE s/in LSP Object/in the LSP Object/g s/one of these TLV/one of these TLVs s/B (LSP-SCHEDULING-CAPABILITY bit)/B (LSP-SCHEDULING-CAPABILITY) bit/g s/Following flags/The following flags s/remains same as/remain the same as in the s/Options =/Opt = s/In each of repeats, /During each repetition §6.1: s/described in [RFC8231]/described in [RFC8231]. From nobody Tue Jul 7 15:26:48 2020 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CC9453A0B39; Tue, 7 Jul 2020 15:26:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org, pce-chairs@ietf.org, pce@ietf.org, Adrian Farrel , adrian@olddog.co.uk X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <159416079981.20914.17756604864923287337@ietfa.amsl.com> Date: Tue, 07 Jul 2020 15:26:39 -0700 Archived-At: Subject: [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-stateful-pce-lsp-scheduling-19: (with DISCUSS and COMMENT) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 22:26:40 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-pce-stateful-pce-lsp-scheduling-19: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-lsp-scheduling/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This being a discuss ballot notwithstanding, the protocol mechanisms here seem pretty well thought-out; I'm just wanting changes to how they are described. There seems to be an internal inconsistency in Section 4.3, between "[t]he PCE SHOULD add the scheduled LSP into its scheduled LSP-DB and update its scheduled TED" and "[t]he stateful PCE is required to update its local scheduled LSP-DB and scheduled TED". (I think the "SHOULD" one is wrong, personally.) Let's also take a closer look at the precise interdependency between the B bit and PD bit -- Section 5.1 implies that the PD bit itself cannot be set in the absence of the B bit, referring forward to Section 5.2.2, but Section 5.2.2 seems to only say that you need both the B and PD bits set in order to send SCHED-PD-LSP-ATTRIBUTE. Bits being set as a prerequisite for sending the TLV is a subtly different condition than having the one bit itself depend on the other, with correspondingly different error handling. Section 6.6 refers to the "LSP-ERROR-CODE TLV (Section 7.3.3) which is not defined in this document, rather, the reference should be to § 3.3 of RFC 8231. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm pretty sympathetic to Alvaro's not-quite-Discuss, but also am not quite prepared to elevate it to Discuss level (and incur the responsibility to determine what changes are necessary to resolve it). I note several editorial comments and nits below, but those remarks are not comprehensive. Abstract so as to enable Labeled Switched Path (LSP) scheduling for path computation and LSP setup/deletion based on the actual network resource usage and the duration of a traffic service in a centralized network environment as stated in RFC 8413. Just looking at this text in isolation, it's not entirely clear if the event that is scheduled is the LSP activation, creation, calculation, or something else, and whether it is just the computed path that depends on the resource usage/traffic duration, or if other things like the frequency of scheduling or the existence of an LSP at all would be dependent on those. Presumably the rest of the document will clarify, but perhaps there is some wordsmithing possible here. Section 1 letting other services use it when this service is not using it. The requirement of scheduled LSP provision is mentioned in [RFC8231] and nit(?): I think s/provision/provisioning/ [RFC7399]. A solution for providing more efficient network resource usage for traffic engineering is desired. Also, for deterministic nit: I don't really follow the connection between these two sentences -- "a solution for [...] is desired" seems to be a general re-statement of the problem, whereas the previous discussion has been discussing, essentially, the benefits of the proposed solution. Section 2.1 Hmm, RFC 8231 says that it itself takes the definitions for "Active Stateful PCE", "Passive Stateful PCE", and several other terms from RFC 8051; we should probably short-circuit the reference chain(s). Scheduled TED: Traffic engineering database with the awareness of scheduled resources for TE. This database is generated by the PCE from the information in TED and scheduled LSP-DB and allows knowing, at any time, the amount of available resources (does not include failures in the future). I'd consider "the expected amount of available resources (discounting the possibility of failures in the future)". Section 4.1 The LSP scheduling allows PCEs and PCCs to provide scheduled LSP for customers' traffic services at its actual usage time, so as to improve the network resource efficient utilization. nit: s/resource efficient utilization/resource utilization efficiency/ In case of implementing PCC-initiated scheduled LSPs, before a PCC delegates a scheduled LSP, it MAY use the PCReq/PCRep messages to Just to check: there is some risk that the computed path might change between this query and when the LSP actually becomes active? learn the path for the scheduled LSP. A PCC MUST delegate a scheduled LSP with information of its scheduling parameters, including the starting time and the duration using PCRpt message. I suggest "When delegating a scheduled LSP, a PCC MUST include its scheduling parameters, including [...]", to be clear about what cases the "MUST" applies to. (It might also be worth saying what a PCE should do if it receives a delegation request for a scheduled LSP that does not include the requisite parameters.) For a multiple PCE environment, a PCE MUST synchronize to other PCEs within the network, so as to keep their scheduling information synchronized. There are many ways that this could be achieved: one such mechanism is described in [I-D.litkowski-pce-state-sync]. Which way is used to achieve this is out of scope for this document. [...] I'd suggest restructuring how this paragraph is laid out (akin to Alvaro's comment). Specifically, it's an intrinsic fact that if you're in a multi-PCE environment, you have to have inter-PCE synchronization or the stat skew causes problems. That's not new with this document; what we are most interested in saying is that, in addition to the existing need to synchrnoize the TED and LSP-DB, when scheduled LSPs are in use you also have to synchronize the SLSP-DB and have each PCE reconstruct the Scheduled TED (or synchronize the Scheduled TED as well). The ways to perform such synchronization are hardly worth mentioning, except to the extent that existing mechanisms cannot handle sending the extra information. The scheduled LSP can also be initiated by PCE itself. In case of nit: missing article (perhaps "by a PCE itself"). scheduled LSP based on the local policy. For the former SCHED-LSP- ATTRIBUTE TLV (see Section 5.2.1) MUST be included in the message I suggest s/For the former/In the former case, the/ where as for the latter SCHED-LSP-ATTRIBUTE TLV SHOULD NOT be nits: s/where as/whereas/, s/SCHED-LSP-ATTRIBUTE/the SCHED-LSP-ATTRIBUTE/ included. Either way the synchronization to other PCEs should be done when the scheduled LSP is created. I recognize that the BCP 14 keywords are not being used, but earlier we said "shall synchronize" but here it's just "synchronization should be done"; it's probably worth making these consistent. In both modes, for activation of scheduled LSPs, the PCC could initiate the setup of scheduled LSP at the start time by itself or wait for the PCE to update the PCC to initiate the setup of LSP. I'm worried about the "could initiate [...] or wait". While it's true that either party could take the initiative, doesn't there need to be an agreement between them about which one it will be, to avoid the risk of the LSP not actually geting instantiated at the start time? Similarly on the scheduling usage expires, the PCC could initiate the nit: s/expires/expiry/ or s/expires/expiration/ (Same comment about "could" as above.) Section 4.2.2 When an LSP is configured with a scheduling interval such as "[Ta, Tb] repeats 10 times with a repeat cycle a week" (representing 11 scheduling intervals), a path satisfying the constraints for the LSP in every interval represented by the periodical scheduling interval is computed once. And then the LSP along the path is set up to carry traffic in each of the scheduling intervals. If there is no path satisfying the constraints for some of the intervals, the LSP will not be set up at all. This seems to say that the same path must be used for each recurrence of the scheduled event, precluding some optimizations that might be desired in the face of other (unscheduled or differently scheduled) load. Is that intended? Section 4.2.2.1 When an LSP is configured with elastic time interval "[Ta, Tb] within -P and Q", a path is computed such that the path satisfies the constraints for the LSP in the time period from (Ta+Xv) to (Tb+Xv) and |Xv| is the minimum value for Xv from -P to Q. That is, [Ta+Xv, To check my understanding, this mention of |Xv| is indicating that the PCE attempts to limit the deviation from the requested interval, using an absolute value metric to indicate distance from the requested value? It might be worth putting in a few more words to indicate that this optimization is being performed; just "is the minimum value" could be confusing. Section 4.2.2.2 During grace periods from (Ta-GB) to Ta and from Tb to (Tb+GA), the LSP is up to carry traffic (maybe in best effort). This point seems pretty key to having grace periods at all. In particular, if there is no difference between the traffic-handling properties for the grace period and the "main interval", then the grace period is more simply handled by the entity requesting the interval (i.e., "just ask for a larger interval"). The fact that we propose to give different traffic-handling behavior during the grace period should be emphasized, in order to justify the existence of the protocol element. In the absence of such justifying text, I would propose to remove the grace-period feature as needless complexity. Section 4.3 For PCE-Initiated Scheduled LSP, the stateful PCE can compute a path for the scheduled LSP per requests from network management systems automatically based on the network resource availability in the scheduled TED, send a PCInitiate message with the path information nit: s/, send/ and send/ back to the PCC. Based on the local policy, the PCInitiate message could be sent immediately to ask PCC to create a scheduled LSP (as nit: s/ask PCC/ask the PCC/ o Based on the configuration (and the C flag in scheduled TLVs), when it is time (i.e., at the start time) for the LSP to be set up, either the PCC triggers the LSP to be signaled or the delegated PCE sends a PCUpd message to the head end LSR providing the updated path to be signaled (with A flag set to indicate LSP activation). We haven't discussed the C flag yet, so a reader is left wondering "how do I know whether the PCC or PCE is going to take initiative?". We could reword, perhaps like "When it is time for the LSP to be set up (i.e., at the start time), based on the value of the C flag for the scheduled TLV, either the PCC [...]". Similar changes would be applicable in later sections as well. Section 4.4 Are there any special considerations for modifying a periodic scheduled LSP after some recurrences have already happened? What about for modifying any scheduled LSP that is currently active (whether before the chage, after the change, or both)? Section 5.1 After a PCEP session has been established, a PCC and a PCE indicates its ability to support LSP scheduling during the PCEP session establishment phase. For a multiple-PCE environment, the PCEs should also establish PCEP session and indicate its ability to support LSP scheduling among PCEP peers. The Open Object in the Open message Does a PCE need to refrain from advertising scheduling support to PCCs if its PCE peers do not all support scheduling? scheduling among PCEP peers. The Open Object in the Open message contains the STATEFUL-PCE-CAPABILITY TLV defined in [RFC8231]. Note that the STATEFUL-PCE-CAPABILITY TLV is defined in [RFC8231] and updated in [RFC8281] and [RFC8232]". In this document, we define a new flag bit B (SCHED-LSP-CAPABLITY) flag for the STATEFUL-PCE- CAPABILITY TLV to indicate the support of LSP scheduling and another flag bit PD (PD-LSP-CAPABLITY) to indicate the support of LSP periodical scheduling. I note that (e.g.) RFC 8623 does not seem to give mnemonic names for the individual bits, so our "bit B" and "bit PD" seem a bit out of place. Section 5.2 Only one of these TLV SHOULD be present in the LSP object. In case more than one scheduling TLV is found, the first instance is processed and others ignored. It seems that this wording "more than one scheduling TLV" might apply to some hypothetical future TLV type for a different variation of scheduled LSPs. If that would be undesirable, we could reword to mention the two TLV types by name. Section 5.2.1 Please note that this formulation (number of seconds since a fixed time) is invariant to leap seconds, but that conversions from current UTC time to it might need to account for leap seconds. (Or if you want to ignore leap seconds, say that.) C (1 bit): Set to 1 to indicate the PCC is responsible to setup and remove the scheduled LSP based on the Start-Time and duration. I suggest noting that the PCE holds these responsibilities when the bit is set to zero. Start-Time (32 bits): This value in seconds, indicates when the scheduled LSP is used to carry traffic and the corresponding LSP must be setup and activated. Value of 0 MUST NOT be used in Start-Time. Note that the transmission delay SHOULD be considered when R=1 and the value of Start-Time is small. I don't understand why start-time of 0 is disallowed (for at least the R=0 case) -- that would disallow requesting a start time that happens to land on the time when the time counter wraps around, for no reason. The Start-Time indicates a time at or before which the scheduled LSP must be set up. The value of the Start-Time represents the number of seconds since the epoch when R bit is set to 0. When R bit is set to 1, it represents the number of seconds from the current time. In addition, it contains an non zero grace-before and grace-after if I suggest s/it/the SCHED-LSP-ATTRIBUTE TLV/; it's easy to misread the "it" as referring to the "Start-Time" from the previous paragraph. grace periods are configured. It includes an non zero elastic range Are the Grace-Before/Grace-After fields set to zero when grace periods are not configured? lower bound and upper bound if there is an elastic range configured. (Likewise for elastic-range.) Section 5.2.2 Opt: (4 bits) Indicates options to repeat. A new registry "Opt" under SCHED-PD-LSP-ATTRIBUTE is created. When a PCE receives a TLV with a Opt value not defined, it does not compute any path for the LSP. It generates a PCEP Error (PCErr) with a PCEP-ERROR object having Error-type = 4 (Not supported object) and Error- value = 4 (Unsupported parameter). Have we thought about what kind of negotiation might be needed in the case where a new Opt value is defined? Though the possibility currently seems unlikely, this error message does not seem sufficient to indicate which Opt value is problematic. NR: (12 bits) The number of repeats. In each of repeats, LSP carries traffic. Maybe say that NR==0 is equivalent to using SCHED-LSP-ATTRIBUTE (to avoid questions of 0- vs. 1-indexing)? Section 6.x We mention in several places "the scheduled TLVs" for the LSP object, but this seems misleading, since at most one scheduled TLV should be present in a given object. Perhaps "a scheduled TLV" would be better? Section 6.2 Perhaps it's worth noting that in the PCE-initiated case there is the option to avoid using the scheduled LSP TLVs (and, to some extent, PCUpd at all), since the PCE can just not tell the PCC about the scheduled path until its start-time occurs. Section 6.4 request the path computation based on scheduled TED and LSP-DB. A PCC MAY use PCReq message to obtain the scheduled path before delegating the LSP. [if my previous comment about "subject to change" results in text changes, similar changes would apply here] Section 6.5 Just to check: the scheduled TLV should still be included in the response even for a negative response? (Also, same comment about "obtain the scheduled path before delegating".) Section 8 Since we deal with scheduled events, we should remind implementations to do something reasonable when their current time jumps. Jumps can be forward or backward, and might cross boundaries for when LSPs should be (in)active. The presence of a significant time correction may be indicative of other (configuration) issues, and falling back to a conservative stance (keep LSPs active?) might be appropriate. Similarly, some discussion of how things break when there is clock skew between PCC and PCE might be useful (we already have a requirement for clock synchronization in discussion of the R flag). on the network. Thus, such deployment should employ suitable PCEP security mechanisms like TCP Authentication Option (TCP-AO) [RFC5925] or [RFC8253]. The procedure based on Transport Layer Security (TLS) in [RFC8253] is considered a security enhancement and thus is much better suited for the sensitive information. PCCs may also need to nit: TCP-AO would be considered a "security enhancement" as well (compared to a baseline of unprotected TCP). Perhaps the intent is to say that the TLS procedure from RFC 8253 additionally provides confidentiality protection to the conveyed data? nit: "such deployments" plural. Section 9.1 When configuring the parameters about time, a user SHOULD consider leap-years and leap-seconds. I know I mentioned leap seconds earlier as well, but this feels like a cop-out. We can tell the reader in much more detail how leap years and seconds will affect their calculations, which in aggregate will be much more efficient than making each reader think it through for themself. Section 9.2 nit(?) "view the capability" (singular) sounds like it's just seeing whether the scheduled LSP functionality is enabled or not, a boolean value. If the intent is to say that the specific (e.g., per-tunnel) state should be visible, then this should be reworded accordingly. Section 9.4 Is there something to say about checking that LSPs are activated/disabled at the appropriate times for scheduled and periodic events? Section 9.5 Are there any requirements on PCE-to-PCE synchronization protocols that now need to carry the SLSP-DB? Section 10.1.1 Is there anything to say about why the two reserved values are reserved? From nobody Tue Jul 7 20:59:09 2020 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE5C83A0766; Tue, 7 Jul 2020 20:58:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: pce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: pce@ietf.org Message-ID: <159418073673.14731.12554441530156713031@ietfa.amsl.com> Date: Tue, 07 Jul 2020 20:58:56 -0700 Archived-At: Subject: [Pce] I-D Action: draft-ietf-pce-pcep-yang-14.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2020 03:58:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element WG of the IETF. Title : A YANG Data Model for Path Computation Element Communications Protocol (PCEP) Authors : Dhruv Dhody Jonathan Hardwick Vishnu Pavan Beeram Jeff Tantsura Filename : draft-ietf-pce-pcep-yang-14.txt Pages : 113 Date : 2020-07-07 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 and state data. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-pcep-yang-14 https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-yang-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-yang-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 Wed Jul 8 07:26:11 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D07A93A0C39; Wed, 8 Jul 2020 07:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=iu12JkY6; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=AoDAWzc+ 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 8-Fbu5JYgZ_X; Wed, 8 Jul 2020 07:25:58 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0324A3A0C5A; Wed, 8 Jul 2020 07:25:57 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 5029F5C0103; Wed, 8 Jul 2020 10:25:57 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 08 Jul 2020 10:25:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= from:message-id:content-type:mime-version:subject:date :in-reply-to:cc:to:references; s=fm3; bh=Ljy63sVW+wNt3Gp4zJ8Ai3N BvaMQMlwwp3V3o8NXiE0=; b=iu12JkY6tXmcXcyuO9rG1T1YSk6MV6FqkEfmZSw yVOrnPxa0VYlnA2iTG+2yDffxzlaSvyDEdK62h1Z/hudkTxDu/8CpQKdsnm/zYQy dv5+uZb2DNI2kR9AThbgtxhvRuMZmjQamuOVKHA3MWEV9VoXxrd6ODh9rsHPnGYP 9I4QKSHjZrx3HIdjOzeRwhynYpoufQ8byqsqiH6kfYUWxQWxhfBZEOKiJxpXJ9fw Irlet9f2F/m2hUnRNdxJmlQw99Nknd6S6kW0AyYQJnSPQys0PYdEXwDRDL6F4o1q Fg8GowNbwHKlWbECowIepsATpc4FJI6OePJDDTbRcxSKARA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=Ljy63s VW+wNt3Gp4zJ8Ai3NBvaMQMlwwp3V3o8NXiE0=; b=AoDAWzc+7/zesgOECJj4y1 Jpr48RQdR4pD/HAQQ9m7aP3i+ebhLORLEorhKdQ/z3D2Q6Aiqly2yCNuEzcBvCI+ vCMX7bpqSmze8X2NJWfgfha1HWAfpiNIQfgCLwzC3uOZirQBdEGnR+fDd3gBvp5o r4i5jzXxWT+qPR9+7+GbzNwWYOdJDnwiCecZ9R0pNaWFOgU46iNEA8YZY1vXn0+N CqZVom/sTfws8lefRqCg/zsB7eWVr7lm+C8gObl8FvNt2UZcl4KgAH+gt6+tSORq rSQ/F14g/OO8vuI8QeDo1RAxCOXq1hxY7Rw0LocMJEZkyAMZ65oAfAhEavgpFQYw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudejgdejkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhkfgtggfuffgjvfhfofesrgdtmherhhdtjeenucfhrhhomheptehlihhsshgr ucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucggtffrrghtth gvrhhnpedtjedtgedtveefuddthfeugfduffduiedvgeeljeetffeghfegteejjeegveej teenucffohhmrghinhepihgvthhfrdhorhhgpdhouhhtlhhoohhkrdgtohhmnecukfhppe dutdekrdehuddruddtuddrleeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghm pehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinh X-ME-Proxy: Received: from alcoop-m-c46z.fios-router.home (pool-108-51-101-98.washdc.fios.verizon.net [108.51.101.98]) by mail.messagingengine.com (Postfix) with ESMTPA id BC2E2306005F; Wed, 8 Jul 2020 10:25:56 -0400 (EDT) From: Alissa Cooper Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_F163AEB7-60D4-427E-A718-86ED69C6BB6F" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\)) Date: Wed, 8 Jul 2020 10:25:55 -0400 In-Reply-To: Cc: "gen-art@ietf.org" , "last-call@ietf.org" , "draft-ietf-pce-stateful-pce-lsp-scheduling.all@ietf.org" , "pce@ietf.org" To: Huaimo Chen , Robert Sparks References: <159173888777.20611.18058918121871985684@ietfa.amsl.com> <33e569da-059e-b250-78ca-ba2bd639ddeb@nostrum.com> <32ec172d-3112-08bf-333c-851cd73df290@nostrum.com> X-Mailer: Apple Mail (2.3445.9.5) Archived-At: Subject: Re: [Pce] [Gen-art] Genart last call review of draft-ietf-pce-stateful-pce-lsp-scheduling-13 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2020 14:26:01 -0000 --Apple-Mail=_F163AEB7-60D4-427E-A718-86ED69C6BB6F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Robert, thanks for your review. Huaimo, thanks for addressing Robert=E2=80= =99s comments. I entered a No Objection ballot. Alissa > On Jun 12, 2020, at 11:49 AM, Huaimo Chen = wrote: >=20 > Hi Robert, >=20 > Thank you very much for your suggestion. > We have updated the document (version 16 uploaded) according to = your suggestion. >=20 > Best Regards, > Huaimo > From: Robert Sparks > > Sent: Friday, June 12, 2020 11:32 AM > To: Huaimo Chen >; gen-art@ietf.org = > > Cc: last-call@ietf.org >; = draft-ietf-pce-stateful-pce-lsp-scheduling.all@ietf.org = = >; = pce@ietf.org > > Subject: Re: [Gen-art] Genart last call review of = draft-ietf-pce-stateful-pce-lsp-scheduling-13 > =20 >=20 > On 6/11/20 9:12 AM, Robert Sparks wrote: >> Thanks! Some initial replies inline (I haven't looked at the updated = draft yet, but will do so soon): > I've looked at the diffs between -13 and -15 and my comments have been = addressed except for one point. >=20 > Only one of them (i.e., elastic range and grace periods) is = used for an LSP. >=20 > Isn't strong enough. I think you need normative language here. >=20 > I suggest > A TLV can configure a non-zero grace period or elastic bound, but = it MUST NOT provide both. >> On 6/10/20 7:35 PM, Huaimo Chen wrote: >>> Hi Robert, >>>=20 >>> Thank you very much for your time and valuable comments. >>>=20 >>> My answers/explanations are inline below with prefix [HC]. >>>=20 >>> Your comments have been addressed in the updated document=20 >>> = https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-lsp-schedulin= g/ = >>>=20 >>> Best Regards, >>> Huaimo >>> From: Robert Sparks via Datatracker = >>> Sent: Tuesday, June 9, 2020 5:41 PM >>> To: gen-art@ietf.org = >>> Cc: last-call@ietf.org = ; pce@ietf.org = ; = draft-ietf-pce-stateful-pce-lsp-scheduling.all@ietf.org = = = >>> Subject: Genart last call review of = draft-ietf-pce-stateful-pce-lsp-scheduling-13 >>> =20 >>> Reviewer: Robert Sparks >>> Review result: Ready with Issues >>>=20 >>> I am the assigned Gen-ART reviewer for this draft. The General Area >>> Review Team (Gen-ART) reviews all IETF documents being processed >>> by the IESG for the IETF Chair. Please treat these comments just >>> like any other last call comments. >>>=20 >>> For more information, please see the FAQ at >>>=20 >>> = >. >>>=20 >>> Document: draft-ietf-pce-stateful-pce-lsp-scheduling-13 >>> Reviewer: Robert Sparks >>> Review Date: 2020-06-09 >>> IETF LC End Date: 2020-06-12 >>> IESG Telechat date: Not scheduled for a telechat >>>=20 >>> Summary: Essentially ready for publication as a Proposed Standard = RFC, but with >>> issues to consider before progressing >>>=20 >>> Minor Issues: >>>=20 >>> Section 4.2.2: It's not clear when the computation for a path = satisfying the >>> constraint happens. Is this done once when the periodical LSP = arrives, or at >>> each scheduled interval? If the former, what happens if there is no = path >>> solution for only one of the multiple intervals? >>>=20 >>> [HC]: We have made it clear in the document through revising the = texts.=20 >>> When a periodical LSP is configured, the paths for all the scheduled=20= >>> intervals of the LSP is computed once.=20 >>> If there is no path for some (e.g., one) of the intervals,=20 >>> the constraints for the periodical LSP is not satisfied and >>> the LSP will not be set up at all.=20 >>>=20 >>> Section 4.4, second paragraph, last sentence: If the path cannot be = set, is the >>> previous LSP left in effect? Or does the failure result in no there = being no >>> scheduled LSPs in effect? >>>=20 >>> [HC]: We have added the texts explicitly stating that=20 >>> the previous LSP will not be impacted if the path for new=20 >>> requirements cannot be set. >>>=20 >>> Section 5.1 first paragraph: Why is TCP called out here? >>>=20 >>> [HC]: We have removed TCP.=20 >>>=20 >>> You should be explicit about whether it's ok to have both grace = periods and >>> elastic bounds at the same time. The TLV allows that to happen. I'm = not sure >>> what it would mean, and I suspect it's unlikely that you would have = two >>> implementers compute the consequences the same way. >>>=20 >>> [HC]: We have added some texts to say that only one of them is used. >>>=20 >>> Section 5.2.1, definition of the R bit: You should call out that = relative time >>> is in seconds (I think?) when the R bit is 1, and you need a = discussion >>> somewhere about the necessity of synchronized clocks and potential = problems >>> with transmission delay when the R bit is 1. >>>=20 >>> [HC]: You are right. The relative time is in seconds.=20 >>> We have explicitly stated this and had some discussions about=20 >>> synchronizing clocks and potential problems with transmission delay. >>>=20 >>> Section 5.2.1, definition of Start-Time: Why must a value of 0 not = be used? Is >>> this true for both R=3D1 and R=3D0? For R=3D1, a start time value of = 1 vs a start >>> time value of 0 may, in practice, be indistinguishable (because of = transmission >>> or processing delay). >>>=20 >>> [HC]: When R=3D1, Start-Time=3D0 means right now.=20 >>> Because of transmission and processing delay, this cannot be = achieved. >> And you don't have the same problem (or at least a race condition) = for R=3D1, Start-Time=3D1? >> (And perhaps other small values of Start-Time?). This isn't a big = deal, but it looks like a rough >> edge, and I want to make sure it's been thought through. >>> For R=3D0, Start-Time=3D0 means the epoch (i.e., 1 January 1970 at = 00:00 UTC). >>> So for both R=3D1 and R=3D0, a value of 0 must not be used in = Start-Time. >>>=20 >>> In section 5.2.2 at the definition of Repeat-time-length: Please be = explicit >>> about whether this is the interval between the start time of two = repetitions or >>> the interval between the end-time of one repetition and the start of = the next >>> repetition. I think you mean the former. >>>=20 >>> [HC]: It is the interval between the end-time of one repetition and >>> the start of the next repetition. We had added some texts to=20 >>> state this explicitly. >> That surprises me. All the other values are start-start and not = end-start. >> With REPEAT-EVERY-DAY, you're aiming for the same time every day. >> Suppose you didn't have REPEAT-EVERY-DAY and had to express that with = REPEAT-EVERY-TIME-LENGTH. >> If it were start-start, you could set the interval to 86400 (as you = compute in 9.1) and be done. >> With it being end-start you have to calculate the value by = subtracting the Duration field value from >> 86400.=20 >> I think that's likely to surprise implementors trying to achieve = something like "every other day". >>=20 >>>=20 >>> At section 5.2.1 you say this TLV SHOULD NOT be included unless both = PCEP peers >>> have set the B bit. But in section 6.6, you say MUST NOT. Please = choose one.. I >>> think you want both places to say MUST NOT. >>>=20 >>> [HC]: We have changed SHOULD NOT to MUST NOT. >>>=20 >>> Nits: >>>=20 >>> Introduction, paragraph 3, second sentence: This is hard to read. I = suggest >>> trying to break it into more than one sentence. >>>=20 >>> [HC]: We have split and rephrased it. >>>=20 >>> Introduction, paragraph 4, third sentence: This is hard to read. = Please >>> simplify. >>>=20 >>> [HC]: We have rephrased it. >>>=20 >>> The document uses both "database" and "data base". Please pick one. >>>=20 >>> [HC]: We have changed "data base" to database. >>>=20 >>> Top of page 7: "In case of former" does not parse. Please clarify.. >>>=20 >>> [HC]: We have rephrased it. >>>=20 >>> Section 4.2.2, second paragraph, first sentence: Does not parse. I = think it is >>> missing more than articles. >>>=20 >>> [HC]: We have revised it. >>>=20 >>> Section 4.3 at "In both modes": It's not clear what "modes" means = here. >>>=20 >>> [HC]: We have added some details. >>>=20 >>> It would be worth calling out in section 5.1 that setting PD = requires setting B >>> as specified in 5.2.2. >>>=20 >>> [HC]: We have added some texts to state this. >>>=20 >>> It would be helpful in 5.2.2 at the definition of Opt: to point = forward to the >>> registry you are creating for its values. It would also be good to = be explicit >>> about what to do if an element receives a TLV with a value here it = does not >>> understand yet. >>>=20 >>> [HC]: We have added some descriptions about these. >>>=20 >>> Section 9.1 ignores leap-years and leap-seconds. It's worth = explicitly noting >>> that. >>>=20 >>> [HC]: We have added some texts about this. >>>=20 >>=20 >>=20 >> _______________________________________________ >> Gen-art mailing list >> Gen-art@ietf.org >> https://www.ietf.org/mailman/listinfo/gen-art = > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art = --Apple-Mail=_F163AEB7-60D4-427E-A718-86ED69C6BB6F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Robert, thanks for your review. Huaimo, thanks for addressing = Robert=E2=80=99s comments. I entered a No Objection ballot.

Alissa


On Jun 12, 2020, at 11:49 AM, Huaimo Chen = <huaimo.chen@futurewei.com> wrote:

Hi Robert,

    Thank you very = much for your suggestion.
 =   We have updated the document (version 16 uploaded) according to = your suggestion.

Best Regards,
Huaimo
From: Robert Sparks <rjsparks@nostrum.com>
Sent: Friday, June 12, 2020 11:32 = AM
To: Huaimo Chen <huaimo.chen@futurewei.com>; gen-art@ietf.org <gen-art@ietf.org>
Cc: last-call@ietf.org <last-call@ietf.org>; draft-ietf-pce-stateful-pce-lsp-scheduling.all@ietf.org <draft-ietf-pce-stateful-pce-lsp-scheduling.all@ietf.org>= ; pce@ietf.org <pce@ietf.org>
Subject: Re: [Gen-art] Genart last = call review of draft-ietf-pce-stateful-pce-lsp-scheduling-13
 

On 6/11/20 9:12 AM, Robert Sparks wrote:
Thanks! Some = initial replies inline (I haven't looked at the updated draft yet, but = will do so soon):
I've looked at = the diffs between -13 and -15 and my comments have been addressed except = for one point.

        = Only one of them (i.e., elastic range and grace periods) is used for an = LSP.

Isn't strong enough. I think you need = normative language here.

I = suggest
    A TLV can configure a non-zero grace = period or elastic bound, but it MUST NOT provide both.
On 6/10/20 7:35 PM, Huaimo Chen wrote:
Hi Robert,

    Thank you very = much for your time and valuable comments.

    My answers/explanations are inline below with prefix = [HC].

    Your comments have been addressed in the = updated document 
 https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-ls= p-scheduling/

Best = Regards,
Huaimo
From: Robert Sparks via = Datatracker <noreply@ietf.org>
Sent: Tuesday, June 9, 2020 5:41 = PM
To: gen-art@ietf.org <gen-art@ietf.org>
Cc: last-call@ietf.org <last-call@ietf.org>; pce@ietf.org <pce@ietf.org>; dr= aft-ietf-pce-stateful-pce-lsp-scheduling.all@ietf.org &l= t;draft-ietf-pce-stateful-pce-lsp-scheduling.all@ietf.org>
Subject: Genart last call review of = draft-ietf-pce-stateful-pce-lsp-scheduling-13
 
Reviewer: Robert Sparks
Review = result: Ready with Issues

I am the assigned = Gen-ART reviewer for this draft. The General Area
Review = Team (Gen-ART) reviews all IETF documents being processed
by= the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%= 2F%2Ftrac.ietf.org%2Ftrac%2Fgen%2Fwiki%2FGenArtfaq&amp;data=3D02%7C01%= 7Chuaimo.chen%40futurewei.com%7C009e6885956a4c1957c908d80cbde38d%7C0fee8ff= 2a3b240189c753a1d5591fedc%7C1%7C0%7C637273356999321440&amp;sdata=3Dx1%= 2BeFVCwSKtx16TqY5ycJgjrXK%2Bb%2Be4ttO0SuBrPStY%3D&amp;reserved=3D0= >.

Document: = draft-ietf-pce-stateful-pce-lsp-scheduling-13
Reviewer: = Robert Sparks
Review Date: 2020-06-09
IETF = LC End Date: 2020-06-12
IESG Telechat date: Not scheduled = for a telechat

Summary: Essentially ready = for publication as a Proposed Standard RFC, but with
issues = to consider before progressing

Minor = Issues:

Section 4.2.2: It's not clear when = the computation for a path satisfying the
constraint = happens. Is this done once when the periodical LSP arrives, or at
each scheduled interval? If the former, what happens if there = is no path
solution for only one of the multiple = intervals?

[HC]: We have made it clear in = the document through revising the texts. 
When a periodical LSP is configured, the paths for all the = scheduled 
intervals of the LSP is computed = once. 
If there is no path for some (e.g., = one) of the intervals, 
the constraints for the periodical LSP is not satisfied = and
the LSP will not be set up at = all. 

Section 4.4, second paragraph, last = sentence: If the path cannot be set, is the
previous LSP = left in effect? Or does the failure result in no there being no
scheduled LSPs in effect?

[HC]: We = have added the texts explicitly stating that 
the previous LSP will not be impacted if the path for = new 
requirements cannot be set.

Section 5.1 first paragraph: Why is TCP called = out here?

[HC]: We have removed TCP. 

You should be explicit about whether it's ok to have both = grace periods and
elastic bounds at the same time. The TLV = allows that to happen. I'm not sure
what it would mean, = and I suspect it's unlikely that you would have two
implementers compute the consequences the same way.

[HC]: We have added some texts to say that only = one of them is used.

Section 5.2.1, = definition of the R bit: You should call out that relative time
is in seconds (I think?) when the R bit is 1, and you need a = discussion
somewhere about the necessity of synchronized = clocks and potential problems
with transmission delay when = the R bit is 1.

[HC]: You are right. The relative = time is in seconds. 
We have explicitly stated this and had = some discussions about 
synchronizing clocks and potential problems with transmission = delay.

Section 5.2.1, definition of = Start-Time: Why must a value of 0 not be used? Is
this = true for both R=3D1 and R=3D0? For R=3D1, a start time value of 1 vs a = start
time value of 0 may, in practice, be = indistinguishable (because of transmission
or processing = delay).

[HC]: When R=3D1, = Start-Time=3D0 means right now. 
Because of transmission and processing delay, this cannot be = achieved.
And you don't have the same problem (or at least a race = condition) for R=3D1, Start-Time=3D1?
(And perhaps other small values of Start-Time?). This isn't = a big deal, but it looks like a rough
edge, and I want to make sure it's been thought through.
For R=3D0, Start-Time=3D0 means the = epoch (i.e., 1 January 1970 at 00:00 UTC).
So for both R=3D1 and R=3D0, a value of 0 must not be used in = Start-Time.

In section 5.2.2 at the = definition of Repeat-time-length: Please be explicit
about = whether this is the interval between the start time of two repetitions = or
the interval between the end-time of one repetition and = the start of the next
repetition. I think you mean the = former.

[HC]: It is the interval between = the end-time of one repetition and
the start of the next repetition. We had added some texts = to 
state this explicitly.
That surprises me. All the other values are start-start and = not end-start.
With REPEAT-EVERY-DAY, = you're aiming for the same time every day.
Suppose you didn't have REPEAT-EVERY-DAY and had to express = that with REPEAT-EVERY-TIME-LENGTH.
If it were start-start, you could set the interval to 86400 = (as you compute in 9.1) and be done.
With = it being end-start you have to calculate the value by subtracting the = Duration field value from
86400. 
I think that's likely to = surprise implementors trying to achieve something like "every other = day".


At section 5.2.1 you say this TLV SHOULD NOT be included = unless both PCEP peers
have set the B bit. But in section = 6.6, you say MUST NOT. Please choose one.. I
think you = want both places to say MUST NOT.

[HC]: We have changed SHOULD NOT to MUST NOT.

Nits:

Introduction, paragraph 3, second sentence: = This is hard to read. I suggest
trying to break it into = more than one sentence.

[HC]: We have split and rephrased it.

Introduction, paragraph 4, third sentence: This is hard to = read. Please
simplify.

[HC]: = We have rephrased it.

The = document uses both "database" and "data base". Please pick = one.

[HC]: We have changed "data base" to database.

Top of page 7: "In case of former" does not = parse. Please clarify..

[HC]: We have rephrased = it.

Section 4.2.2, second paragraph, first = sentence: Does not parse. I think it is
missing more than = articles.

[HC]: We have revised it.

Section 4.3 at "In both modes": It's not clear = what "modes" means here.

[HC]: We have added some = details.

It would be worth calling out in = section 5.1 that setting PD requires setting B
as = specified in 5.2.2.

[HC]: We have added some = texts to state this.

It would be helpful in = 5.2.2 at the definition of Opt: to point forward to the
registry you are creating for its values. It would also be = good to be explicit
about what to do if an element = receives a TLV with a value here it does not
understand = yet.

[HC]: We have added some descriptions = about these.

Section 9.1 ignores leap-years = and leap-seconds. It's worth explicitly noting
that.

[HC]: = We have added some texts about this.


_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo=
/gen-art
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

= --Apple-Mail=_F163AEB7-60D4-427E-A718-86ED69C6BB6F-- From nobody Wed Jul 8 10:11:06 2020 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7423A1094; Wed, 8 Jul 2020 10:10:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Wilton via Datatracker To: "The IESG" Cc: draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org, pce-chairs@ietf.org, pce@ietf.org, Adrian Farrel , adrian@olddog.co.uk X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Wilton Message-ID: <159422825461.24161.2698084555123962875@ietfa.amsl.com> Date: Wed, 08 Jul 2020 10:10:54 -0700 Archived-At: Subject: [Pce] Robert Wilton's No Objection on draft-ietf-pce-stateful-pce-lsp-scheduling-19: (with COMMENT) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2020 17:11:01 -0000 Robert Wilton has entered the following ballot position for draft-ietf-pce-stateful-pce-lsp-scheduling-19: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-lsp-scheduling/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I found that document somewhat hard to read and support Alvaro's comment that this document would benefit from an editorial pass. However, it is worth noting that I don't have much knowledge/experience of PCE. A few comments: Top level comment - should this draft be marked as "Experimental" if it unclear whether it will be implemented? 4.2.2.1. Elastic Time LSP Scheduling It wasn't quite clear to me how an end client would make use of elastic time scheduling. Is there some signalling mechanism to inform the client at the point in time that the tunnel has actually been set up, or otherwise how do they know when to make use of it? This might be worth clarifying in this section unless it is covered elsewhere. 4.2.2.2. Grace Periods I'm not really convinced that grace periods are worth it. I.e. the PCC client could trivially do the calculation and request the exact duration that they wanted which would slightly simplify the protocol messages. Is there any further justification as to why grace periods are requried? 5.2. LSP Object I'm not entirely convinced that it is that useful/necessary to have both messages. I would have probably just defined SCHED-PD-LSP-ATTRIBUTE TLV and treated the non repeating case as degenerate case (i.e. opt = "no-repeats", repeat-time-length = 0). 5.2.2. SCHED-PD-LSP-ATTRIBUTE TLV It isn't clear to me whether a client can make a request for it to repeat forever (until cancelled), and if so, how that would be indicated. Did you consider other encodings of the "Opt" and "Repeat-time-length" fields: - I would have added "seconds", "minute", "hours" to the "Opt" field and removed "Options = 5: repeat every Repeat-time-length". - I would then always combine the "Opt" field with the "Repeat-time-length" field, e.g. so that you could express repeat every 12 hours as: (opt="hours", repeat-time-length=12), or every 30 minutes as (opt="minutes", repeat-time-length=30), etc. Hopefully these comment help to improve this document. Regards, Rob From nobody Wed Jul 8 18:53:04 2020 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D8A403A0C08; Wed, 8 Jul 2020 18:53:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org, pce-chairs@ietf.org, pce@ietf.org, Adrian Farrel , adrian@olddog.co.uk X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <159425958286.30155.15214639006444253746@ietfa.amsl.com> Date: Wed, 08 Jul 2020 18:53:02 -0700 Archived-At: Subject: [Pce] Roman Danyliw's No Objection on draft-ietf-pce-stateful-pce-lsp-scheduling-19: (with COMMENT) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2020 01:53:03 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-pce-stateful-pce-lsp-scheduling-19: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-lsp-scheduling/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I concur with Alvaro Retana’s point (2) and (3), that since time synchronization is key to functionality clarified normative guidance is needed. I support Ben Kaduk's DISCUSS position. ** Section 2.1. Thank you for providing a mapping of terms to references. ** Consider using normative language in the following places: -- Section 5.2.1. Per “The Start-Time indicates a time at or before which the schedule LSP must be set up”, should this be a normative MUST? -- Section 8. Per “Thus, such deployment should employ suitable PCEP security mechanisms …”, why not a normative SHOULD? ** Editorial Nits: -- Section 1. Typo. s/can not/cannot/ -- Section 5.2.1. Typo. s/an non zero/a non zero/g From nobody Fri Jul 10 07:41:46 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D603A0E1E; Fri, 10 Jul 2020 07:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 9nDFNZYaOldD; Fri, 10 Jul 2020 07:41:37 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 217493A0E21; Fri, 10 Jul 2020 07:41:37 -0700 (PDT) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id 06AEWJck045639; Fri, 10 Jul 2020 10:41:36 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049297.ppops.net-00191d01. with ESMTP id 325k81c15b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 10 Jul 2020 10:41:36 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 06AEfYVN028543; Fri, 10 Jul 2020 10:41:35 -0400 Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [135.47.91.179]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 06AEfWqJ028471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 10 Jul 2020 10:41:32 -0400 Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [127.0.0.1]) by zlp30484.vci.att.com (Service) with ESMTP id 8AA994009E66; Fri, 10 Jul 2020 14:41:32 +0000 (GMT) Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (unknown [130.8.218.155]) by zlp30484.vci.att.com (Service) with ESMTPS id 75EFF4009E65; Fri, 10 Jul 2020 14:41:32 +0000 (GMT) Received: from GAALPA1MSGEX1DD.ITServices.sbc.com (135.50.89.117) by GAALPA1MSGHUBAF.ITServices.sbc.com (130.8.218.155) with Microsoft SMTP Server (TLS) id 14.3.487.0; Fri, 10 Jul 2020 10:41:31 -0400 Received: from GAALPA1MSGEX1DE.ITServices.sbc.com (135.50.89.118) by GAALPA1MSGEX1DD.ITServices.sbc.com (135.50.89.117) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4; Fri, 10 Jul 2020 10:41:31 -0400 Received: from GAALPA1MSGEX1DE.ITServices.sbc.com ([135.50.89.118]) by GAALPA1MSGEX1DE.ITServices.sbc.com ([135.50.89.118]) with mapi id 15.01.2044.004; Fri, 10 Jul 2020 10:41:31 -0400 From: "BRUNGARD, DEBORAH A" To: "teas@ietf.org" , "pce@ietf.org" , "'CCAMP'" , "detnet@ietf.org" , "raw@ietf.org" , mpls Thread-Topic: ANRW TE talk at IETF108 Thread-Index: AdZWx5XPPsDxIL4aQXKOC6z2t5qPMQ== Date: Fri, 10 Jul 2020 14:41:31 +0000 Message-ID: <8c7120cc392e47f480fbabc0095cb166@att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.154.249] Content-Type: multipart/alternative; boundary="_000_8c7120cc392e47f480fbabc0095cb166attcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-10_10:2020-07-10, 2020-07-10 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 bulkscore=0 mlxscore=0 suspectscore=0 malwarescore=0 clxscore=1011 adultscore=0 priorityscore=1501 spamscore=0 lowpriorityscore=0 mlxlogscore=432 impostorscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007100102 Archived-At: Subject: [Pce] ANRW TE talk at IETF108 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2020 14:41:40 -0000 --_000_8c7120cc392e47f480fbabc0095cb166attcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi TE fans, Take note, there will be an ANRW "Transport Protocols and Traffic Engineeri= ng" talk on July 30 (Thursday) at 14:10 UTC: https://irtf.org/anrw/2020/program.html Good weekends- Deborah --_000_8c7120cc392e47f480fbabc0095cb166attcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi TE fans,

 

Take note, there will be an ANRW “Transport Pr= otocols and Traffic Engineering” talk on July 30 (Thursday) at 14:10 = UTC:

= https://irtf.org/anrw/2020/program.html

 

Good weekends-

Deborah

 

--_000_8c7120cc392e47f480fbabc0095cb166attcom_-- From nobody Fri Jul 10 07:51:31 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4CD3A0DAD; Fri, 10 Jul 2020 07:51:30 -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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 WUMf0csaUQe2; Fri, 10 Jul 2020 07:51:28 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 EF4F13A0D6A; Fri, 10 Jul 2020 07:51:26 -0700 (PDT) Received: from lhreml708-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 705E264E04ED45658D42; Fri, 10 Jul 2020 15:51:25 +0100 (IST) Received: from fraeml712-chm.china.huawei.com (10.206.15.61) by lhreml708-chm.china.huawei.com (10.201.108.57) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Fri, 10 Jul 2020 15:51:24 +0100 Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml712-chm.china.huawei.com (10.206.15.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 10 Jul 2020 16:51:24 +0200 Received: from fraeml714-chm.china.huawei.com ([10.206.15.33]) by fraeml714-chm.china.huawei.com ([10.206.15.33]) with mapi id 15.01.1913.007; Fri, 10 Jul 2020 16:51:24 +0200 From: Giuseppe Fioccola To: "pce@ietf.org" CC: "draft-chen-pce-sr-policy-ifit@ietf.org" Thread-Topic: New Version Notification for draft-chen-pce-sr-policy-ifit-02.txt Thread-Index: AQHWVrWTo11OSzKFj0aAKKzFdsHG3akAw5cg Date: Fri, 10 Jul 2020 14:51:24 +0000 Message-ID: <0b290b63152b4448a950b291b5960fb3@huawei.com> References: <159438406431.12133.11734833260610050043@ietfa.amsl.com> In-Reply-To: <159438406431.12133.11734833260610050043@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.48.210.232] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Pce] FW: New Version Notification for draft-chen-pce-sr-policy-ifit-02.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2020 14:51:30 -0000 Dear All, We have recently updated draft-chen-pce-sr-policy-ifit. It aims to define t= he Extensions to PCEP to enable automatically IOAM and Alternate Marking wh= en the SR policy is applied. In particular we have clarified better the PCE= P usage in this scenario. Feedbacks and suggestions are always welcome. Best Regards, Giuseppe -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Friday, July 10, 2020 2:28 PM To: Giuseppe Fioccola ; Hang Yuan ; Huanan Chen ; wangyali ; Liweidong (Poly) ; Tianran Zhou Subject: New Version Notification for draft-chen-pce-sr-policy-ifit-02.txt A new version of I-D, draft-chen-pce-sr-policy-ifit-02.txt has been successfully submitted by Giuseppe Fioccola and posted to the IETF= repository. Name: draft-chen-pce-sr-policy-ifit Revision: 02 Title: PCEP SR Policy Extensions to Enable IFIT Document date: 2020-07-10 Group: Individual Submission Pages: 12 URL: https://www.ietf.org/internet-drafts/draft-chen-pce-sr-poli= cy-ifit-02.txt Status: https://datatracker.ietf.org/doc/draft-chen-pce-sr-policy-i= fit/ Htmlized: https://tools.ietf.org/html/draft-chen-pce-sr-policy-ifit-0= 2 Htmlized: https://datatracker.ietf.org/doc/html/draft-chen-pce-sr-pol= icy-ifit Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-chen-pce-sr-polic= y-ifit-02 Abstract: Segment Routing (SR) policy is a set of candidate SR paths consisting of one or more segment lists and necessary path attributes. It enables instantiation of an ordered list of segments with a specific intent for traffic steering. In-situ Flow Information Telemetry (IFIT) refers to network OAM applications that apply dataplane on- path telemetry techniques. This document defines extensions to PCEP to distribute SR policies carrying IFIT information. So that IFIT behavior can be enabled automatically when the SR policy is applied. = =20 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. The IETF Secretariat From nobody Fri Jul 10 10:50:25 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE0B03A07BD for ; Fri, 10 Jul 2020 10:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com 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 igMM_KzQInWW for ; Fri, 10 Jul 2020 10:50:17 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC8DC3A0789 for ; Fri, 10 Jul 2020 10:50:16 -0700 (PDT) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by opfednr23.francetelecom.fr (ESMTP service) with ESMTPS id 4B3LD71nytz5w6F for ; Fri, 10 Jul 2020 19:50:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1594403415; bh=vb8V78OHdHAfHoPK9feN+kpNw7VV/c6fwUQ0WJceoLw=; h=Subject:To:From:Message-ID:Date:MIME-Version:Content-Type; b=KdYZ3oYa8kOxP+HB6oTl+pUKFNaXaEJNFJBBLjVZndxoDcHrSuGr0bOhY2FW25rlY Ri/VwnPOKrqHMviGT/M9D4dW4/hE55mkjS4g5oVnhaHjWxRFSFJH7k5i8eX2Sb1OCS JLlobtny+ahJAP0zHkkQwq3odPhzjFBEfN7fhT2Z2FqtdNUuuVEY0li9x26YgrFSQ7 bauAyMK0pygyasKCOOWCtHszM1ckJLr9svy53HJPAcLy09dXcy8uYtSpfeM9yDLWMC seukgJKGmQsBmyW484DUxbPZuF1GoJohk22pEvQdzig/WIwGe7aL2vlb3hHpOwW2kR oRlABLq25pnBQ== Received: from Exchangemail-eme3.itn.ftgroup (unknown [xx.xx.50.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by opfednr00.francetelecom.fr (ESMTP service) with ESMTPS id 4B3LD717w0zDq7T for ; Fri, 10 Jul 2020 19:50:15 +0200 (CEST) Received: from [10.192.151.194] (10.114.50.248) by exchange-eme3.itn.ftgroup (10.114.50.64) with Microsoft SMTP Server (TLS) id 14.3.487.0; Fri, 10 Jul 2020 19:50:14 +0200 References: <159440324509.25627.12930115633247946214@ietfa.amsl.com> To: "pce@ietf.org" From: Organization: Orange Labs X-Forwarded-Message-Id: <159440324509.25627.12930115633247946214@ietfa.amsl.com> Message-ID: <6b9637e3-cec3-cd9a-3bb8-ecfd9cef0d89@orange.com> Date: Fri, 10 Jul 2020 19:50:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <159440324509.25627.12930115633247946214@ietfa.amsl.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000008060601070802040806" X-Originating-IP: [10.114.50.248] Archived-At: Subject: [Pce] Fwd: New Version Notification for draft-dugeon-pce-stateful-interdomain-04.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2020 17:50:19 -0000 --------------ms000008060601070802040806 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: fr Dear all, FYI. We just post a new version of our draft. Regards Olivier & co-authors -------- Message transf=C3=A9r=C3=A9 -------- Sujet=C2=A0: New Version Notification for draft-dugeon-pce-stateful-inte= rdomain-04.txt Date=C2=A0: Fri, 10 Jul 2020 10:47:25 -0700 De=C2=A0: internet-drafts@ietf.org Pour=C2=A0: Daniele Ceccarelli , Olivie= r Dugeon , Julien Meuric , Young Lee A new version of I-D, draft-dugeon-pce-stateful-interdomain-04.txt has been successfully submitted by Olivier Dugeon and posted to the IETF repository. Name: draft-dugeon-pce-stateful-interdomain Revision: 04 Title: PCEP Extension for Stateful Inter-Domain Tunnels Document date: 2020-07-10 Group: Individual Submission Pages: 34 URL: https://www.ietf.org/internet-drafts/draft-dugeon-pce-stateful-inter= domain-04.txt Status: https://datatracker.ietf.org/doc/draft-dugeon-pce-stateful-interd= omain/ Htmlized: https://tools.ietf.org/html/draft-dugeon-pce-stateful-interdoma= in-04 Htmlized: https://datatracker.ietf.org/doc/html/draft-dugeon-pce-stateful= -interdomain Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-dugeon-pce-stateful-inter= domain-04 Abstract: This document specifies how to combine a Backward Recursive or Hierarchical method with inter-domain paths in the context of stateful Path Computation Element (PCE). It relies on the PCInitiate message to set up independent paths per domain. Combining these different paths together enables to operate them as end-to-end inter- domain paths without the need for a signaling session between inter- domain border routers. A new Stitching Label is defined, new Path Setup Types, a new Association Type and a new PCEP communication Protocol (PCEP) Capability are considered for that purpose. 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. The IETF Secretariat --------------ms000008060601070802040806 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: Signature cryptographique S/MIME MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC EnAwggTeMIIDxqADAgECAgEBMA0GCSqGSIb3DQEBBQUAMGoxCzAJBgNVBAYTAkZSMRowGAYD VQQKDBFGcmFuY2UgVGVsZWNvbSBTQTEXMBUGA1UECwwOMDAwMiAzODAxMjk4NjYxJjAkBgNV BAMMHUdyb3VwZSBGcmFuY2UgVGVsZWNvbSBSb290IENBMB4XDTA1MTExNzExMDkzOVoXDTI1 MTExNzExMDkzOVowgZYxCzAJBgNVBAYTAkZSMRowGAYDVQQKDBFGcmFuY2UgVGVsZWNvbSBT QTEkMCIGA1UECwwbV2VzdGVybkVVIE1pZGRsZUVhc3QgQWZyaWNhMRcwFQYDVQQLDA4wMDAy IDM4MDEyOTg2NjEsMCoGA1UEAwwjR3JvdXBlIEZyYW5jZSBUZWxlY29tIEludGVybmFsIENB IDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCw8ytv/3/3nS8Xkfrfv3lWqny4 Gd1V8eVOT7B0WxfJMqfWPbu0aoc4WScRhqIhAH61Gmfa6f3AVq+o3PptjJ459kMp/ACaeRp8 DFzW7iNFm/Qfdk81V9dVLXHsbYwWU373j/ksx1Smmk3vsq4fWapeAOLfds70KO4RWP/YVSmO rAFVMiqV4l9f6a+G8Lr2tOZkWaX+3vb3HE6mDG3la3Y6VDpVpioSrz61KPb8pLyOg7TuhhIx OKTNNefEcDwFKx9zfVJax+PHj6zGbFzdGEMWexwGSi3SXkgAV6/CJNtCHHXE2OprWc30JiCY 18GkvPrRgO1XBSqx0xDIam+WpEh/AgMBAAGjggFgMIIBXDAPBgNVHRMBAf8EBTADAQH/MA4G A1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUNhwzZ9MTXPpbn+qLukRmdEbxd3gwdAYDVR0jBG0w a4AUGpJTyM8zG7bypWB94q8kEkGwmmChUIFOQ049R3JvdXBlIEZyYW5jZSBUZWxlY29tIFJv b3QgQ0EsIE9VPTAwMDIgMzgwMTI5ODY2LCBPPUZyYW5jZSBUZWxlY29tIFNBLCBDPUZSggEA MIGOBgNVHR8EgYYwgYMwQ6BBoD+GPWh0dHA6Ly9pZ2NnZnQtcmNhLWh0dHAuc2kuZnJhbmNl dGVsZWNvbS5mci9jcmwvaWdjZ2Z0X3JjYS5jcmwwPKA6oDiGNmh0dHA6Ly9pZ2NnZnQtcmNh LmZyYW5jZXRlbGVjb20uY29tL2NybC9pZ2NnZnRfcmNhLmNybDATBgNVHSAEDDAKMAgGBiqB egEQDDANBgkqhkiG9w0BAQUFAAOCAQEAlt994iqOFDZH/wQfDU6EQ1W1B/xs/k3xwBuBZgi3 NRWvvb8KhfoOVOyeuoO1r4072jo/AFDphvixN8EZiRp+luqZXQEXEaHrZjwRydCuUDwjPQkw A/DU5NzWn0FrKWRIstQa/MBcN9xniazs41Br3oNzlkUbAyuP2s3GRi5uFp7VV5Y5dU8lqdoL nE/TuBV0LFdre0WOdM7CoWVqNlreb7/zmuK2/zfLIaq2QIcWIOulqiIW1xxFWxc0JZi8p7qV zvysS0+8wevgoefks3PHoUMEaIHCpoSOC14JSkKCVuUMPBvu+ftPasJ+NQz1jUbb0kjUkpGn q33GgLPLSvsK5TCCBsMwggWroAMCAQICEhEhALb/Yna0F+7w+91Hjc99TTANBgkqhkiG9w0B AQUFADCBljELMAkGA1UEBhMCRlIxGjAYBgNVBAoMEUZyYW5jZSBUZWxlY29tIFNBMSQwIgYD VQQLDBtXZXN0ZXJuRVUgTWlkZGxlRWFzdCBBZnJpY2ExFzAVBgNVBAsMDjAwMDIgMzgwMTI5 ODY2MSwwKgYDVQQDDCNHcm91cGUgRnJhbmNlIFRlbGVjb20gSW50ZXJuYWwgQ0EgMTAeFw0x NjExMjUwOTQwMjBaFw0yMDExMjUwOTQwMjBaMGwxCzAJBgNVBAYTAkZSMRowGAYDVQQKExFG cmFuY2UgVGVsZWNvbSBTQTEXMBUGA1UEAwwORHVnZW9uIE9saXZpZXIxKDAmBgkqhkiG9w0B CQEMGW9saXZpZXIuZHVnZW9uQG9yYW5nZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQCo6z0xg3LuYDs4VyVltd9KrkQbChbMxmqyO/x+TMNiJekiFrwgPOcIQL2Kb/4Q 3oacMtUUpxWKTDpsRjQF8SM8MU5yAeYJjz+vVrnfKOHbfEOKOGOazlW4/KZFRcH+7aauwU6P DJzR2/A7p6QOioMrq1LIi5laQa4RpGqRexev/zCPFdLj1sM8akao4vc4+0HhrO6iFIda40a1 biyeqkZSznxHvENX8qbwLe1rXktUNp64oGGQ399TrGXPPYMZCv6c4Oujnm8zBvwfZPQIkHLU icKHzHw6Mp91Rr7tkkAQz5nkiGaO1ZQuO10pNHKo89OjX/2WiER5yP1fl6IYeNXVAgMBAAGj ggMyMIIDLjAOBgNVHQ8BAf8EBAMCBsAwEwYDVR0lBAwwCgYIKwYBBQUHAwQwJAYDVR0RBB0w G4EZb2xpdmllci5kdWdlb25Ab3JhbmdlLmNvbTCCAiEGA1UdHwSCAhgwggIUMIHooIHloIHi hoHfbGRhcDovLy9jbj1Hcm91cGUlMjBGcmFuY2UlMjBUZWxlY29tJTIwSW50ZXJuYWwlMjBD QSUyMDEsY249aWdjZ2Z0aSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049 U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1hZCxEQz1mcmFuY2V0ZWxlY29tLERDPWZy P2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RjbGFzcz1jUkxEaXN0cmli dXRpb25Qb2ludDCBqaCBpqCBo4aBoGxkYXA6Ly9pZ2NnZnRpLWNhMS1sZGFwLnNpLmZyYW5j ZXRlbGVjb20uZnIvb3U9aWdjZ2Z0aV9jYTEsb3U9Q0Esb3U9Q1JMRFAsb3U9QUNfT04sb3U9 SUdDR3JvdXBlLG89RnJhbmNlVGVsZWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jh c2U/b2JqZWN0Y2xhc3M9cGtpQ2EwNKAyoDCGLmh0dHA6Ly9wa2ktY3JsLml0bi5mdGdyb3Vw L2NybC9pZ2NnZnRpX2NhMS5jcmwwRaBDoEGGP2h0dHA6Ly9pZ2NnZnRpLWNhMS1odHRwLnNp LmZyYW5jZXRlbGVjb20uZnIvY3JsL2lnY2dmdGlfY2ExLmNybDA+BgNVHSAENzA1MDMGCCqB egEQDAIDMCcwJQYIKwYBBQUHAgEWGWh0dHA6Ly9wa2ktb3JhbmdlLmNvbS9jcHMwPAYIKwYB BQUHAQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8vcGtpLW9jc3AuaXRuLmZ0Z3JvdXAvb2Nz cDAdBgNVHQ4EFgQUjYeHRIZIpGCGrvSKwjwi5RFlwIgwHwYDVR0jBBgwFoAUNhwzZ9MTXPpb n+qLukRmdEbxd3gwDQYJKoZIhvcNAQEFBQADggEBAGf1f3G0N8jRxapp2+BTbcOLcMInm45E Cjk+IxPtQrJmRy0nPjI31rQWqINa62V+KN7qMU55fnWJoaU4mm0kdfGrYoYK4Q7CHcKrJoya G+fHXTk1Sw207vbyW/0PLbq28FTDXkO8ANoB/sJHFY/vqGv92IldLRqttU7w6RmrovmAl3Fb KJktiQFzIKdQCWkoY7yQbdRURAoXWCKnNGmyfSz45oldNt5j1AwiNKW9EvAlbVqKkvK42ttu uWg12zFIL1S9qsNZ5kWzCgUc0Pe80nwasR7kfgIWzcO07JJMLsrtCVAijrB2t+gM1WOkpor+ k33uBbYnJIyg6idWK2ulhFQwggbDMIIFq6ADAgECAhIRIXXhbjTOsSMww6TYpJXHjbcwDQYJ KoZIhvcNAQEFBQAwgZYxCzAJBgNVBAYTAkZSMRowGAYDVQQKDBFGcmFuY2UgVGVsZWNvbSBT QTEkMCIGA1UECwwbV2VzdGVybkVVIE1pZGRsZUVhc3QgQWZyaWNhMRcwFQYDVQQLDA4wMDAy IDM4MDEyOTg2NjEsMCoGA1UEAwwjR3JvdXBlIEZyYW5jZSBUZWxlY29tIEludGVybmFsIENB IDEwHhcNMTYxMTI1MDk0MDMyWhcNMjAxMTI1MDk0MDMyWjBsMQswCQYDVQQGEwJGUjEaMBgG A1UEChMRRnJhbmNlIFRlbGVjb20gU0ExFzAVBgNVBAMMDkR1Z2VvbiBPbGl2aWVyMSgwJgYJ KoZIhvcNAQkBDBlvbGl2aWVyLmR1Z2VvbkBvcmFuZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAvuQFmvjh9eFHxMjlkTUIQZGUSCgW+SxoXiyNwyQ1FqwP3UZMekA2 Al78WyTSLjL2bQZd9mKDKPJYBnp6W/zF90sc6eLuoY9HMelU70qJqmEBNliEOrEQcI9g8PsO /AEWa1iYnRAL2CKipJldr4ncmmLhvlKba14da0czONYxGkDvwiNeNkbTvMP8ucOFeV6QvD8b zHCKHlnwdLW1Cv5IkhWTVMAK+65GmPtWGOCqejbxLUbNDwj0SJN8AQ84XpbGLVyPVc4HxlhM rnyYmYDSEeMy8E/ejG576hjp7rEDAeUR2WvSPsUYGLARWNsQm948KUEIwvq201Zll+uzYzy4 twIDAQABo4IDMjCCAy4wDgYDVR0PAQH/BAQDAgUgMBMGA1UdJQQMMAoGCCsGAQUFBwMEMCQG A1UdEQQdMBuBGW9saXZpZXIuZHVnZW9uQG9yYW5nZS5jb20wggIhBgNVHR8EggIYMIICFDCB 6KCB5aCB4oaB32xkYXA6Ly8vY249R3JvdXBlJTIwRnJhbmNlJTIwVGVsZWNvbSUyMEludGVy bmFsJTIwQ0ElMjAxLGNuPWlnY2dmdGksQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZp Y2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9YWQsREM9ZnJhbmNldGVsZWNv bSxEQz1mcj9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Y2xhc3M9Y1JM RGlzdHJpYnV0aW9uUG9pbnQwgamggaaggaOGgaBsZGFwOi8vaWdjZ2Z0aS1jYTEtbGRhcC5z aS5mcmFuY2V0ZWxlY29tLmZyL291PWlnY2dmdGlfY2ExLG91PUNBLG91PUNSTERQLG91PUFD X09OLG91PUlHQ0dyb3VwZSxvPUZyYW5jZVRlbGVjb20/Y2VydGlmaWNhdGVSZXZvY2F0aW9u TGlzdD9iYXNlP29iamVjdGNsYXNzPXBraUNhMDSgMqAwhi5odHRwOi8vcGtpLWNybC5pdG4u ZnRncm91cC9jcmwvaWdjZ2Z0aV9jYTEuY3JsMEWgQ6BBhj9odHRwOi8vaWdjZ2Z0aS1jYTEt aHR0cC5zaS5mcmFuY2V0ZWxlY29tLmZyL2NybC9pZ2NnZnRpX2NhMS5jcmwwPgYDVR0gBDcw NTAzBggqgXoBEAwCAjAnMCUGCCsGAQUFBwIBFhlodHRwOi8vcGtpLW9yYW5nZS5jb20vY3Bz MDwGCCsGAQUFBwEBBDAwLjAsBggrBgEFBQcwAYYgaHR0cDovL3BraS1vY3NwLml0bi5mdGdy b3VwL29jc3AwHQYDVR0OBBYEFFGiQ9ZfvjUvdKKWJjIoc3BO27R+MB8GA1UdIwQYMBaAFDYc M2fTE1z6W5/qi7pEZnRG8Xd4MA0GCSqGSIb3DQEBBQUAA4IBAQBoh10SuRJLWk81NrXRrMvV ItpfGEhP4kdytjI3YaGKDKJvtAFdSIEsb9a4hz6cXeYXpWdHJUj9k3C/+CyIHlnleryJRBrO Nbo0d+gMhKZ8T42DCsbdyKmvCOYEaVrULNx3WFTL1L+otA2JjMU35puHKOt22Y4PFkllFcJ5 QgpzZ7TmW6jwuyohyfUoSTH562BdR14kvxxeoO7UM9UkBVqP2HhkJZq29gZ7tlJHg2rVWbIA ZVHgEHHa3N5cWjCGdp5f/+DPEeqt1DEQKm9Oj/c6oITm6/Tjms5oimdsITNO7epd3gsEHYxu 7wcLpgSxinWLqFWFsK6xlI0rac1/QkG7MYIEODCCBDQCAQEwga0wgZYxCzAJBgNVBAYTAkZS MRowGAYDVQQKDBFGcmFuY2UgVGVsZWNvbSBTQTEkMCIGA1UECwwbV2VzdGVybkVVIE1pZGRs ZUVhc3QgQWZyaWNhMRcwFQYDVQQLDA4wMDAyIDM4MDEyOTg2NjEsMCoGA1UEAwwjR3JvdXBl IEZyYW5jZSBUZWxlY29tIEludGVybmFsIENBIDECEhEhALb/Yna0F+7w+91Hjc99TTANBglg hkgBZQMEAgEFAKCCAlswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMjAwNzEwMTc1MDEzWjAvBgkqhkiG9w0BCQQxIgQg3/yI15INV6g3McZAeY0oidh7fnc4 QLwoKSv/DdS8oGkwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAEC MAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzAN BggqhkiG9w0DAgIBKDCBvgYJKwYBBAGCNxAEMYGwMIGtMIGWMQswCQYDVQQGEwJGUjEaMBgG A1UECgwRRnJhbmNlIFRlbGVjb20gU0ExJDAiBgNVBAsMG1dlc3Rlcm5FVSBNaWRkbGVFYXN0 IEFmcmljYTEXMBUGA1UECwwOMDAwMiAzODAxMjk4NjYxLDAqBgNVBAMMI0dyb3VwZSBGcmFu Y2UgVGVsZWNvbSBJbnRlcm5hbCBDQSAxAhIRIXXhbjTOsSMww6TYpJXHjbcwgcAGCyqGSIb3 DQEJEAILMYGwoIGtMIGWMQswCQYDVQQGEwJGUjEaMBgGA1UECgwRRnJhbmNlIFRlbGVjb20g U0ExJDAiBgNVBAsMG1dlc3Rlcm5FVSBNaWRkbGVFYXN0IEFmcmljYTEXMBUGA1UECwwOMDAw MiAzODAxMjk4NjYxLDAqBgNVBAMMI0dyb3VwZSBGcmFuY2UgVGVsZWNvbSBJbnRlcm5hbCBD QSAxAhIRIXXhbjTOsSMww6TYpJXHjbcwDQYJKoZIhvcNAQEBBQAEggEAndmJLasN2UuVXX+9 lXJI2dgRwv1dt63V7CIErpKPN/D0RSfb2zsQ5+f/ANIxlwxTgqgkFDCPOSNoG36tlY0UjwxG TBt8FpwwsKTmw9Rz310oVN2hU7yQ+gNrQ2AlkraiCzhFC+kVLe2NElj9/3HijqbHjpl8Cj7W V3HzI5mZ8cJunx9xSkaAdWYtn3HtHDBxWXX7/R3jxQmi28rEKVXwmo61EcNlDhjycG8cVecj 7x9obgCe/h3iM9xGOb9BAu+jdJShzEZgsrl0VL+y4pd1jEz0e4x4lFGwNuUH9Pk2jl4ZD+qL yXjFRp+31cgcY/2kmDZtlKwPlQdLHXzhXnCpPAAAAAAAAA== --------------ms000008060601070802040806-- From nobody Sun Jul 12 11:36:19 2020 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D1BC23A07E7; Sun, 12 Jul 2020 11:36:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: pce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: pce@ietf.org Message-ID: <159457897781.23781.15692456699739288591@ietfa.amsl.com> Date: Sun, 12 Jul 2020 11:36:17 -0700 Archived-At: Subject: [Pce] I-D Action: draft-ietf-pce-stateful-pce-lsp-scheduling-20.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2020 18:36:18 -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 WG of the IETF. Title : PCEP Extensions for LSP scheduling with stateful PCE Authors : Huaimo Chen Yan Zhuang Qin Wu Daniele Ceccarelli Filename : draft-ietf-pce-stateful-pce-lsp-scheduling-20.txt Pages : 26 Date : 2020-07-12 Abstract: This document defines a set of extensions needed to the stateful Path Computation Element (PCE) communication Protocol (PCEP), so as to enable Labeled Switched Path (LSP) scheduling for path computation and LSP setup/deletion based on the actual network resource usage and the duration of a traffic service in a centralized network environment as stated in RFC 8413. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-lsp-scheduling/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-lsp-scheduling-20 https://datatracker.ietf.org/doc/html/draft-ietf-pce-stateful-pce-lsp-scheduling-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-stateful-pce-lsp-scheduling-20 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jul 12 11:44:24 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5203A07E8; Sun, 12 Jul 2020 11:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com 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 7sa227PtfsZ5; Sun, 12 Jul 2020 11:44:20 -0700 (PDT) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2137.outbound.protection.outlook.com [40.107.237.137]) (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 65BD63A07F3; Sun, 12 Jul 2020 11:44:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VrLzwz64NO1L8PkMTXVfveVD7T1358cTgEg2udjtlNuhcDqbVSeXLArh0e4JsTNnlO9UoWjz8+jUogY4I7oUIjJoUicX6SlxEIU/OTJqELflhCoa2KUSlxC6bj31lbmhsgzrGQCTgYtygsE+NDouHlLd0tFVCA6uN3s8pXQRi2Z2gshyUImh5wBbhlSvCci/o7OLZ92L6p01ymSy8evjZHTQ1nI2vTzb8dk/+waPLm3aD/dKz2lGbGkuDGhTsSk+bC7zXcKk/MQzgpT4QtlNB1WbrUe4Lz5kYWeW7IrysDHfKGIskN344c8DKO2gMDEnOPBuxOWI4BT/8ibAnKAruw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0A0EmrmXK3DUWl8wckLIx+ZqYbbWArliUqT+yO4NOBc=; b=CeogcPEs+xafspIdvnXTkoKGhvGqjL2XTs9+VntqvkUdmr+SwXXroZfetsMAnyUsIuGcNZj3v2NsonGY9bUCQDWc8UXzq9s8lj/u5G/v5zelUdvjPkC67Y6W2w/QeIWb+oM5jUcsjnvlU4eg4qeiud8oPeN5sjRtMWB6fAZvq1SgTE2orwKwWHBJPENSM46H9JNTQIhJEjZDcvC4jZJVH64MK6/4JXFYP4YyfVAIUkQ9pRV+7TbzRlVYAdPcnF5+wQFPtj94vC6M26y3OAH7IYEeDZ/Cf24MO65QSHWDeyHNtlo6c4e04RrqBeOrWBQkrvKj2h/1aQwFD+7Hu5PYSw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0A0EmrmXK3DUWl8wckLIx+ZqYbbWArliUqT+yO4NOBc=; b=m+bMBmM/5FTWS9sDO3xqxxUXLsNFOKdNZtf6I5VVLIjA9j4XKQqWW6kYyv9qjs2dDvvbkmAdo03pt9DZbKS5Oc+aKCXpu3lYt7hbCHpi8t/pKwfRk4GmW0kjAI25VCuRK2Fpan2rjofk/InQoSDVS94Cpfk1C8DjMwZAbmCwlfI= Received: from MN2PR13MB3117.namprd13.prod.outlook.com (2603:10b6:208:13a::20) by MN2PR13MB3103.namprd13.prod.outlook.com (2603:10b6:208:135::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.9; Sun, 12 Jul 2020 18:44:17 +0000 Received: from MN2PR13MB3117.namprd13.prod.outlook.com ([fe80::bd0d:e70d:94e5:81e7]) by MN2PR13MB3117.namprd13.prod.outlook.com ([fe80::bd0d:e70d:94e5:81e7%7]) with mapi id 15.20.3195.009; Sun, 12 Jul 2020 18:44:17 +0000 From: Huaimo Chen To: The IESG , Erik Kline CC: "draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org" , "pce-chairs@ietf.org" , "pce@ietf.org" , Adrian Farrel , Adrian Farrel Thread-Topic: Erik Kline's No Objection on draft-ietf-pce-stateful-pce-lsp-scheduling-18: (with COMMENT) Thread-Index: AQHWU2EUMzftWK6p9kylEqmpbAmRNqkEUKui Date: Sun, 12 Jul 2020 18:44:17 +0000 Message-ID: References: <159401794220.31718.17372315222906941609@ietfa.amsl.com> In-Reply-To: <159401794220.31718.17372315222906941609@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=futurewei.com; x-originating-ip: [73.114.233.24] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8ef1713d-6f28-44f2-5511-08d8269394f9 x-ms-traffictypediagnostic: MN2PR13MB3103: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: DhU8KmMiQiwgDwyTP5vdLYQGRXpufoQ/6Z1enL6mZPNPfLjSqb9xjSvRHS+ZF3tSMoOWoeN0oo0T2Ve1C7PTIIJtdl9t50qdOG4MQNNyX+2DRd1mQ0VoPpMcEyLy7mOnV5VoprKuI9y3erjSHHZKEdridR1qVOS71zP/9eQLkWl9Jr+XEFWi7cHF6RKeKZpRYD2CAgpTKlbtFJjeLgSM7s/dR08bR32p0xAl/tB1pY1kEyZB2CH0C2hAxezBc71f+fPPhWZ+qgC8VrMOePzcQBNt3oHYNB5GKxFxDmHADRI2poO/rt5ipjNSw/9GFwnWkyF2bjIlhBa/TZe90joLbtPTHGXZ9PVW83PxHvmCYBW39KGo28ClEJpY50xKM3C6QBPhhOzVen83i/NSyjG/Yg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR13MB3117.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(39830400003)(366004)(136003)(396003)(376002)(44832011)(55016002)(166002)(8676002)(186003)(316002)(19627405001)(9686003)(2906002)(33656002)(26005)(110136005)(54906003)(5660300002)(4326008)(966005)(478600001)(52536014)(6506007)(53546011)(86362001)(45080400002)(7696005)(8936002)(76116006)(83380400001)(66556008)(64756008)(66446008)(66476007)(71200400001)(66946007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: LkcMCnxdSyF75h3rPg1Yu1xuoQjJv/Puhb+4MNgKojnQTWE6b1zVIcWdOOR5VPbI4Y63Nt6RNSIWC/utN+v11GHB3FSAQ7ayU59Dm276hKoVtwxtEIQPzaPhPWfGZ3ywzJM11EqLJykHld5jpLEU3uef+JNSWDaiAYj6AtoJnK7TZVktqRqRPv68shtEmbk8OWlHbtnmBYpoZbtot9ilePXwN5I951sGQKDUHHJWBzTXZ97/L61KiZmSeQz5C4zFMK5ZQ89kLvYA6Y9HJekyLQGi6IDWtpuBad2sGCeDOqQPMXYHJ3vcu7xWJwTPITzRf93r0+gxp/4e7g3yDH6oJdZOX5pQESe1QlxtYgZeHmlxhqSR2IPQvWRWnsNAZK6JPoWw3FIv5hpnrLV+L3P1ygh69OCJ6niAQddAYs//Mq3nvqzZiOZcrj0AsferQdBINZ+RuKPMv7gHxdLsKKycAL4IkgSMzIQkVDMROrlXIQ/Zb6x7gdny0GreptiRkrah x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR13MB3117628BD9E3EA528F2F5465F2630MN2PR13MB3117namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR13MB3117.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8ef1713d-6f28-44f2-5511-08d8269394f9 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2020 18:44:17.2812 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: qBlvNC+Av3Tb8eyn6O2bBR/nJlt4neYDy7y89PNX/D2wF7+xmfl8pAS3FQnVwtdkLQlKHTVXcH+3msRJE5NjNg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR13MB3103 Archived-At: Subject: Re: [Pce] Erik Kline's No Objection on draft-ietf-pce-stateful-pce-lsp-scheduling-18: (with COMMENT) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2020 18:44:22 -0000 --_000_MN2PR13MB3117628BD9E3EA528F2F5465F2630MN2PR13MB3117namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Erik, Thank you very much for your valuable comments, which improve the quali= ty of the document. My explanations/answers are inline below with prefix [HC]. The comments have been addressed in version 20 of the document uploaded= . Best Regards, Huaimo ________________________________ From: Erik Kline via Datatracker Sent: Monday, July 6, 2020 2:45 AM To: The IESG Cc: draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org ; pce-chairs@ietf.org ; pce@ietf.org ; Adrian Farrel ; adria= n@olddog.co.uk Subject: Erik Kline's No Objection on draft-ietf-pce-stateful-pce-lsp-sched= uling-18: (with COMMENT) Erik Kline has entered the following ballot position for draft-ietf-pce-stateful-pce-lsp-scheduling-18: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://nam11.safelinks.protection.outlook.com/?url=3Dhttps= %3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html&data= =3D02%7C01%7Chuaimo.chen%40futurewei.com%7C2dab594ee3e44c0e8a7008d82178352b= %7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637296147471756053&sdata= =3D1PioVZz%2FQB%2FDpaOFqyDjFZbFg8DQNxTNHPD0%2B7NRd8w%3D&reserved=3D0 for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatra= cker.ietf.org%2Fdoc%2Fdraft-ietf-pce-stateful-pce-lsp-scheduling%2F&dat= a=3D02%7C01%7Chuaimo.chen%40futurewei.com%7C2dab594ee3e44c0e8a7008d82178352= b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637296147471756053&sdata= =3DTt1CWH9WxW%2BmOO1Yi8t%2FyVw6vfJkyc1kRj4hPDH7fZQ%3D&reserved=3D0 ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [ section 1 ] * "the service really being used" -> "the service is really being used"? [HC]: We have changed it as you suggested. [ section 4.1 ] * "SHALL check ... and computes" -> "... and compute" [HC]: We have changed it as you suggested. * "on the scheduling usage expires" -> "on scheduled usage expiration"? [HC]: We have changed it as you suggested. [ section 4.2.2 ] * If there is no possible path do you want some text, maybe even just a lowercase should, about "should report to an administrator" or something? [HC]: Yes. We have added some text to report "Constraints could not be met for some intervals". [ section 4.3 ] * In the first of the 4 bullet points at the end of this section, should th= e "required" and "shall" be capitalized? [HC]: We have capitalized them. [ section 4.5 ] * "In other case," -> "In all other cases," or just "Otherwise,"? [HC]: We have changed it to "Otherwise," as you suggested. [ section 5.1 ] * Perhaps there's a way to strengthen the "PD requires B" text by saying wh= at an endpoint should do if it sees PD without B? [HC]: We have added some text accordingly. [ section 5.2.1 & 5.2.2 ] * R bit. WRT to R=3D0 and the wraparound, it would seem to me that in this case the receiver really needs to check if start-time is less than the current time, and if so treat that as wrap-around (2106) + start-time num= ber of seconds. Otherwise, I think you'll need to be more precise about what it means to = be "near" the wrap-around. Even still, if times are not sync'd carefully an= d the start-time is not a moderate amount of time in the future there remai= ns a chance that an endpoint could receive a start-time it perceives as "in the past". What should an endpoint in this circumstance? Yet another alternative is to take a flag bit to indicate that start-time= is after the wrap-around, and say that by 2242 CE some other solution should= be found. :-) [HC]: We have added some more details. * Duration: Is a value of 1 just as nonsensical as 0? What about a value o= f 0 if grace-before and grace-after are non-zero? I may not understand the grace and elastic uses properly, but it seems to me that the thing to forbid is an "effective duration" of 0 (i.e. factori= ng in grace or elastic values). [HC]: We have added some text to state that the value of Duration SHOULD be greater than a constant MINIMUM-DURATION seconds, where MINIMUM-DURATION is 5. Even though the grace-before and grace-after are non-zero, the value of Duration SHOULD be greater than a constant MINIMUM-DURATION seconds. Elastic will not change the duration of an LSP, it just gives some relaxation for computing a path for the LSP with a time interval (say [Ta, Tb], which means from time Ta to time Tb). The duration, which is Tb - Ta, is fixed. With elastic, the interval [Ta, Tb] may be shifted to left or right to satisfy the constraints of the path for the LSP if a path could not be found in the interval [Ta, Tb]. Grace extends the lifetime of the LSP to include the grace period. For an LSP with interval [Ta, Tb], and grace-before GB and grace-after GA, the lifetime of the LSP is from (Ta-GB) to (Tb+GA). During grace periods from (Ta-GB) to Ta and from Tb to (Tb+GA), the LSP is up to carry traffic (maybe in best effort). In the time period from Ta to Tb, QoS is guaranteed since a path is computed such that the path satisfies the constraints for the LSP in the time period from Ta to Tb. * Grace and Elastic fields: If it cannot provide both simultaneously why h= ave both fields? What just have a "lower" and "upper" pair of fields and cho= ose a new flag value to indicate whether the fields are grace values or elast= ic values? [HC]: We have updated the document according to your suggestion. --_000_MN2PR13MB3117628BD9E3EA528F2F5465F2630MN2PR13MB3117namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Erik,

    Thank you very much for your valuable comments, wh= ich improve the quality of the document.  
    My explanations/answers are inline below with prefix [HC= ]. 
    The comments have been addressed in version 20 of the do= cument uploaded.

Best Regards,
Huaimo

From: Erik Kline via Datatr= acker <noreply@ietf.org>
Sent: Monday, July 6, 2020 2:45 AM
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org <draft-ie= tf-pce-stateful-pce-lsp-scheduling@ietf.org>; pce-chairs@ietf.org <pc= e-chairs@ietf.org>; pce@ietf.org <pce@ietf.org>; Adrian Farrel <= ;adrian@olddog.co.uk>; adrian@olddog.co.uk <adrian@olddog.co.uk> Subject: Erik Kline's No Objection on draft-ietf-pce-stateful-pce-ls= p-scheduling-18: (with COMMENT)
 
Erik Kline has entered the following ballot positi= on for
draft-ietf-pce-stateful-pce-lsp-scheduling-18: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html&amp;data=3D02%7C01%7Ch= uaimo.chen%40futurewei.com%7C2dab594ee3e44c0e8a7008d82178352b%7C0fee8ff2a3b= 240189c753a1d5591fedc%7C1%7C0%7C637296147471756053&amp;sdata=3D1PioVZz%= 2FQB%2FDpaOFqyDjFZbFg8DQNxTNHPD0%2B7NRd8w%3D&amp;reserved=3D0
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://nam11.safelinks.protection.outlook.com/?url=3Dh= ttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-pce-stateful-pce-lsp-s= cheduling%2F&amp;data=3D02%7C01%7Chuaimo.chen%40futurewei.com%7C2dab594= ee3e44c0e8a7008d82178352b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6372= 96147471756053&amp;sdata=3DTt1CWH9WxW%2BmOO1Yi8t%2FyVw6vfJkyc1kRj4hPDH7= fZQ%3D&amp;reserved=3D0



---------------------------------------------------------------------= -
COMMENT:
----------------------------------------------------------------------=

[ section 1 ]

* "the service really being used" -> "the service is= really being used"?

[HC]: We have changed it as you suggested.

[ section 4.1 ]

* "SHALL check ... and computes" -> "... and compute= "

[HC]: We have changed it as you suggested.

* "on the scheduling usage expires" -> "on scheduled= usage expiration"?

[HC]: We have changed it as you suggested.

[ section 4.2.2 ]

* If there is no possible path do you want some text, maybe even just = a
  lowercase should, about "should report to an administrator= " or something?

[HC]: Yes. We have added some text to report
"Constraints could not be met for some intervals".


[ section 4.3 ]

* In the first of the 4 bullet points at the end of this section, shou= ld the
  "required" and "shall" be capitalized?

[HC]: We have capitalized them.

[ section 4.5 ]

* "In other case," -> "In all other cases," or = just "Otherwise,"?

[HC]: We have changed it to "Otherwise," as you suggested.

[ section 5.1 ]

* Perhaps there's a way to strengthen the "PD requires B" te= xt by saying what
  an endpoint should do if it sees PD without B?

[HC]: We have added some text accordingly.

[ section 5.2.1 & 5.2.2 ]

* R bit.  WRT to R=3D0 and the wraparound, it would seem to me th= at in this
  case the receiver really needs to check if start-time is less t= han the
  current time, and if so treat that as wrap-around (2106) + = start-time number
  of seconds.

  Otherwise, I think you'll need to be more precise about what it= means to be
  "near" the wrap-around.  Even still, if times ar= e not sync'd carefully and
  the start-time is not a moderate amount of time in the future t= here remains
  a chance that an endpoint could receive a start-time it perceiv= es as
  "in the past". What should an endpoint in this circum= stance?

  Yet another alternative is to take a flag bit to indicate that = start-time is
  after the wrap-around, and say that by 2242 CE some other solut= ion should be
  found.  :-)

[HC]: We have added some more details.


* Duration: Is a value of 1 just as nonsensical as 0?  What about= a value of
  0 if grace-before and grace-after are non-zero?

  I may not understand the grace and elastic uses properly, but i= t seems to
  me that the thing to forbid is an "effective duration"= ; of 0 (i.e. factoring
  in grace or elastic values).

[HC]: We have added some text to state that the value of Duration SHOU= LD
be greater than a constant MINIMUM-DURATION seconds, where MINIMUM-DUR= ATION
is 5.
Even though the grace-before and grace-after are non-zero, the value o= f
Duration SHOULD be greater than a constant MINIMUM-DURATION seconds.
Elastic will not change the duration of an LSP, it just gives some
relaxation for computing a path for the LSP with a time interval
(say [Ta, Tb], which means from time Ta to time Tb). The duration,
which is Tb - Ta, is fixed. With elastic, the interval [Ta, Tb] may
be shifted to left or right to satisfy the constraints of the path
for the LSP if a path could not be found in the interval [Ta, Tb].
Grace extends the lifetime of the LSP to include the grace period.
For an LSP with interval [Ta, Tb], and grace-before GB and grace-after= GA,
the lifetime of the LSP is from (Ta-GB) to (Tb+GA).
During grace periods from (Ta-GB) to Ta and from Tb to (Tb+GA), th= e
LSP is up to carry traffic (maybe in best effort).
In the time period from Ta to Tb, QoS is guaranteed since
a path is computed such that the path satisfies the constraints for th= e
LSP in the time period from Ta to Tb.
 

* Grace and Elastic fields:  If it cannot provide both simultaneo= usly why have
  both fields?  What just have a "lower" and "= ;upper" pair of fields and choose
  a new flag value to indicate whether the fields are grace value= s or elastic
  values?

[HC]: We have updated the document according to your suggestion.

--_000_MN2PR13MB3117628BD9E3EA528F2F5465F2630MN2PR13MB3117namp_-- From nobody Sun Jul 12 12:08:17 2020 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 69D733A0818; Sun, 12 Jul 2020 12:08:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: pce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: pce@ietf.org Message-ID: <159458089139.22828.10148116763630808410@ietfa.amsl.com> Date: Sun, 12 Jul 2020 12:08:11 -0700 Archived-At: Subject: [Pce] I-D Action: draft-ietf-pce-stateful-pce-lsp-scheduling-21.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2020 19:08:12 -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 WG of the IETF. Title : PCEP Extensions for LSP scheduling with stateful PCE Authors : Huaimo Chen Yan Zhuang Qin Wu Daniele Ceccarelli Filename : draft-ietf-pce-stateful-pce-lsp-scheduling-21.txt Pages : 26 Date : 2020-07-12 Abstract: This document defines a set of extensions needed to the stateful Path Computation Element (PCE) communication Protocol (PCEP), so as to enable Labeled Switched Path (LSP) scheduling for path computation and LSP setup/deletion based on the actual network resource usage and the duration of a traffic service in a centralized network environment as stated in RFC 8413. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-lsp-scheduling/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-lsp-scheduling-21 https://datatracker.ietf.org/doc/html/draft-ietf-pce-stateful-pce-lsp-scheduling-21 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-stateful-pce-lsp-scheduling-21 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 Jul 12 12:10:11 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37A573A0812; Sun, 12 Jul 2020 12:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com 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 4aLG0wo2UWVK; Sun, 12 Jul 2020 12:10:03 -0700 (PDT) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2130.outbound.protection.outlook.com [40.107.244.130]) (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 491943A07FF; Sun, 12 Jul 2020 12:10:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TsWmdLDIYDL1Dp30rJPOo3WlYcGiYtrytsNpZzKZmFzHxX43KhDMH0OZYWV51frEp3y35xs5Z/nuFBSLuzF6s5lx4o1V8LVIu3pkn/9a6hPjP6TKZHa6Y7LsyrdBsPFp9xWkIXDSmKewc16UQ4YjYs0abX2iyiqf31gu+w/6c5h+3ahbx5qZriZulaou2rlyd1ZYoGJFhoo0HuuBpY6HMCCB9FfHsOkab3IOiuLF27oYvx8FRkQDfnNg5egWgsxN3uRQ9tNBcouGq9igmI7CZIcATUhI0RLAePFa3X8O+a3LeOB6lg6Lv++i7aGidspHlWuDviB1yVUO1h+agoat/A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EmQoIaZvmS5ORWQicZnoXv2jbQ4SwVTOgpN5rO5whd0=; b=PV2AN4mUf5rHw9OhRkIEWPAaW7DhV706P4KdYU/Lrf+2JCZ+bcjCpv0AnWQbsgnkX283k0b54BIlBtZrCbh4g3AtAyEdr29SGrQbrBykiSWN/GrLGZzhNG6spQKcl8qMgtsyECZmhIQ3S8/qUL5UWzFK1drqPZyVBYR4Zo88E0YOjJnIxxQWesGdshFSxxJSgzR/ehh6fW0vGT+Az/vAoTKn++tLPvqXeKjXXwIKIzjnVthKM22/erycxNXKKtIK9fsQwp2zyPFS+EUI0BlXvFZfaoIViYy7UfqeinaF1ExRvdxBpY93+KDYNNBeG5AKbfDs1dSPCgPAsTHFtr/4SA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EmQoIaZvmS5ORWQicZnoXv2jbQ4SwVTOgpN5rO5whd0=; b=A72H8QaEOfzO7SPQ9h4ZVZkOOAWUlKigugHXFkkRnZSj3rGFG+TlrhiEmgiAb8EV0DM8ek7ncnCzNfNipkIJhSTrNaGh1uUJjAKFeuLSwzfc/RHegvIQY0uRJOnQ9n9aeQ552m9cZHu/GMiHegnLwDM749D8hT39vG8t+Quw5LM= Received: from MN2PR13MB3117.namprd13.prod.outlook.com (2603:10b6:208:13a::20) by MN2PR13MB2640.namprd13.prod.outlook.com (2603:10b6:208:ed::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.13; Sun, 12 Jul 2020 19:10:00 +0000 Received: from MN2PR13MB3117.namprd13.prod.outlook.com ([fe80::bd0d:e70d:94e5:81e7]) by MN2PR13MB3117.namprd13.prod.outlook.com ([fe80::bd0d:e70d:94e5:81e7%7]) with mapi id 15.20.3195.009; Sun, 12 Jul 2020 19:10:00 +0000 From: Huaimo Chen To: The IESG , Murray Kucherawy CC: "draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org" , "pce-chairs@ietf.org" , "pce@ietf.org" , Adrian Farrel Thread-Topic: Murray Kucherawy's No Objection on draft-ietf-pce-stateful-pce-lsp-scheduling-19: (with COMMENT) Thread-Index: AQHWVCVp9JE/UrH1BES4XxDKBDgqE6kEUcI+ Date: Sun, 12 Jul 2020 19:10:00 +0000 Message-ID: References: <159410226606.30562.499771898082555566@ietfa.amsl.com> In-Reply-To: <159410226606.30562.499771898082555566@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=futurewei.com; x-originating-ip: [73.114.233.24] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 49ec77ba-cceb-4905-654f-08d826972caa x-ms-traffictypediagnostic: MN2PR13MB2640: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 0jjBOcqn3FJt/17tcm9p5n/EZRbYacPZbQLc+uPnBRRaw7mUnq5sT6FtIB8mvyBa0c5VjobvqRy2BFqWZSYbt/SPrDbb/nR0b5ucNhl4MdpnD/9U8JphCOO2irZyuVUJPrRPa2KaFGpudw5OJ6VBJ1yq5wid52MB16qKM5viKuuDEst1rkYMOqZJQqT1MtM10SFDxVDUEk4OxntdNDxRMGA/X73+tRw2rn14rv8JR+tdLR6ucPvbmseXfmyzmfRZP6ARf2Msq3imQ80vugYPqEZ1O45AZWCm+3d7w2ZflKK0TEEuWh/3qZDDZTx+DOYZXjxsOeNWOHksR6PZJ7MbPSoEAbQLI+D1CwUk6ZvYgyZDMgtQP86tzSPl9I56x7pyIkMdjd7GXkEEx71YhdaSqw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR13MB3117.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39830400003)(346002)(136003)(396003)(376002)(366004)(45080400002)(478600001)(52536014)(19627405001)(5660300002)(316002)(54906003)(110136005)(53546011)(8676002)(4326008)(71200400001)(6506007)(8936002)(26005)(76116006)(44832011)(966005)(186003)(2906002)(66446008)(64756008)(66556008)(66476007)(33656002)(55016002)(66946007)(86362001)(9686003)(7696005)(166002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: SBr1MbqZ1x+30FTHiV7xCqaS4lG7vdXXwRfESTQ1OOInAMRK5YWfRgfk+LMR4Q+fiwDoKzVyx4M3RKe/9hGzx8Qjt45deu+D5QBloKcWa5KsTR9EesN/88S2/OoIr6n2cAZ+JLwe2Nj0xBfq9dHP/mSYAWtpuGz0+2YFQ0dx+VuHsXoU0r3IfVf2gX/ezyv4/HvGqfp874G2lUuUe5z4sT4UwB4s2MlfRTEHj2W/B9va3CK4VcSkG0bggjd8y4UkU4fiqhkRLT2h51mhNWXxYYsxbZ6V81Sgs18eNQT7qinGWmpPdskByHC2hDdceNMTBZIdIVOBg8lWrG9MaF7L5pzlAPzbG2+AeDLKRnlalCnfH/Vw/RGN2NJ//VmIrTQd0LIp2ZAJTmasFz8WY5AnAuR2Imo21LsnQs2cS6nGa498TikOFkW2G34uvjd9wY6Gf42BMiaSAjcW8UDfTSw3jz/oLt+U7zAisYqCnv4JD7cmAqhKBRMhXa+4FRGVy/Kq x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR13MB311715CD3D78EC50FB7A3961F2630MN2PR13MB3117namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR13MB3117.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 49ec77ba-cceb-4905-654f-08d826972caa X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2020 19:10:00.3347 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 9u+x9yX6PHMKcmp2c6Jg6L6/jUCZaVNtfWsgRwCikoMEEVXvcphTUGtJIBZ5IyuDUYRReE1DaCIjuVDiiBL+yw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR13MB2640 Archived-At: Subject: Re: [Pce] Murray Kucherawy's No Objection on draft-ietf-pce-stateful-pce-lsp-scheduling-19: (with COMMENT) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2020 19:10:05 -0000 --_000_MN2PR13MB311715CD3D78EC50FB7A3961F2630MN2PR13MB3117namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Murray , Thank you very much for your comments. My explanations/answers are inline below with prefix [HC]. The comments have been addressed in version 21 of the document uploaded= . Best Regards, Huaimo ________________________________ From: Murray Kucherawy via Datatracker Sent: Tuesday, July 7, 2020 2:11 AM To: The IESG Cc: draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org ; pce-chairs@ietf.org ; pce@ietf.org ; Adrian Farrel Subject: Murray Kucherawy's No Objection on draft-ietf-pce-stateful-pce-lsp= -scheduling-19: (with COMMENT) Murray Kucherawy has entered the following ballot position for draft-ietf-pce-stateful-pce-lsp-scheduling-19: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://nam11.safelinks.protection.outlook.com/?url=3Dhttps= %3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html&data= =3D02%7C01%7Chuaimo.chen%40futurewei.com%7Ccc7fa71c5bbd435cec2d08d8223c89c1= %7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637296990716411702&sdata= =3Dcong4fV26Uh90MTTrnkk8yzl2mdn7R5Y%2BiLMX7mSjoQ%3D&reserved=3D0 for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatra= cker.ietf.org%2Fdoc%2Fdraft-ietf-pce-stateful-pce-lsp-scheduling%2F&dat= a=3D02%7C01%7Chuaimo.chen%40futurewei.com%7Ccc7fa71c5bbd435cec2d08d8223c89c= 1%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637296990716411702&sdata= =3DaxjllnikE02TCDbuYOMt7KJqgE%2FMIxt5n2SQVAEJx%2Bg%3D&reserved=3D0 ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 2.1: * "Passive Stateful PCE" is listed in the imported terminology, but not use= d elsewhere in the document. [HC]: We have removed it. Sections 5.2.1 & 5.2.2: * I had the same questions Erik did about the R-bit. [HC]: Addressed in version 20. We have added some more details. Section 7: The text here is unchanged since version -09 of this document, which record= ed no known implementations, and was posted almost a year ago. Is that still = the case now? [HC]: Yes. Section 10.1.1: This section defines a new registry but doesn't explicitly describe the fie= lds of that registry like Section 10.1.2 does. It's nice to be explicit about these things, in my opinion. [HC]: We have described the fields explicitly. --_000_MN2PR13MB311715CD3D78EC50FB7A3961F2630MN2PR13MB3117namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Murray ,

    Thank you very much for your comments.
    My explanations/answers are inline below with pref= ix [HC].
    The comments have been addressed in version 21 o= f the document uploaded.

Best Regards,
Huaimo
From: Murray Kucherawy via = Datatracker <noreply@ietf.org>
Sent: Tuesday, July 7, 2020 2:11 AM
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org <draft-ie= tf-pce-stateful-pce-lsp-scheduling@ietf.org>; pce-chairs@ietf.org <pc= e-chairs@ietf.org>; pce@ietf.org <pce@ietf.org>; Adrian Farrel <= ;adrian@olddog.co.uk>
Subject: Murray Kucherawy's No Objection on draft-ietf-pce-stateful-= pce-lsp-scheduling-19: (with COMMENT)
 
Murray Kucherawy has entered the following ballot = position for
draft-ietf-pce-stateful-pce-lsp-scheduling-19: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html&amp;data=3D02%7C01%7Ch= uaimo.chen%40futurewei.com%7Ccc7fa71c5bbd435cec2d08d8223c89c1%7C0fee8ff2a3b= 240189c753a1d5591fedc%7C1%7C0%7C637296990716411702&amp;sdata=3Dcong4fV2= 6Uh90MTTrnkk8yzl2mdn7R5Y%2BiLMX7mSjoQ%3D&amp;reserved=3D0
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://nam11.safelinks.protection.outlook.com/?url=3Dh= ttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-pce-stateful-pce-lsp-s= cheduling%2F&amp;data=3D02%7C01%7Chuaimo.chen%40futurewei.com%7Ccc7fa71= c5bbd435cec2d08d8223c89c1%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6372= 96990716411702&amp;sdata=3DaxjllnikE02TCDbuYOMt7KJqgE%2FMIxt5n2SQVAEJx%= 2Bg%3D&amp;reserved=3D0



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 2.1:

* "Passive Stateful PCE" is listed in the imported terminology, b= ut not used
elsewhere in the document.

[HC]: We have removed it.

Sections 5.2.1 & 5.2.2:

* I had the same questions Erik did about the R-bit.

[HC]: Addressed in version 20. We have added = some more details.

Section 7:

The text here is unchanged since version -09 of this document, which record= ed
no known implementations, and was posted almost a year ago.  Is that s= till the
case now?

[HC]: Yes.

Section 10.1.1:

This section defines a new registry but doesn't explicitly describe the fie= lds
of that registry like Section 10.1.2 does.  It's nice to be explicit a= bout
these things, in my opinion.

[HC]: We have described the fields explicitly.


--_000_MN2PR13MB311715CD3D78EC50FB7A3961F2630MN2PR13MB3117namp_-- From nobody Mon Jul 13 03:34:04 2020 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E0E603A0D65; Mon, 13 Jul 2020 03:33:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: pce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.8.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: pce@ietf.org Message-ID: <159463643887.26066.15463022841748124909@ietfa.amsl.com> Date: Mon, 13 Jul 2020 03:33:58 -0700 Archived-At: Subject: [Pce] I-D Action: draft-ietf-pce-pcep-extension-for-pce-controller-06.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2020 10:33:59 -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 WG of the IETF. Title : PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) of LSPs Authors : Zhenbin Li Shuping Peng Mahendra Singh Negi Quintin Zhao Chao Zhou Filename : draft-ietf-pce-pcep-extension-for-pce-controller-06.txt Pages : 35 Date : 2020-07-13 Abstract: The Path Computation Element (PCE) is a core component of Software- Defined Networking (SDN) systems. It can compute optimal paths for traffic across a network and can also update the paths to reflect changes in the network or traffic demands. PCE was developed to derive paths for MPLS Label Switched Paths (LSPs), which are supplied to the head end of the LSP using the Path Computation Element Communication Protocol (PCEP). But SDN has a broader applicability than signaled (G)MPLS traffic-engineered (TE) networks, and the PCE may be used to determine paths in a range of use cases. PCEP has been proposed as a control protocol for use in these environments to allow the PCE to be fully enabled as a central controller. A PCE-based central controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it. Thus, the LSP can be calculated/setup/initiated and the label forwarding entries can also be downloaded through a centralized PCE server to each network devices along the path while leveraging the existing PCE technologies as much as possible. This document specifies the procedures and PCEP protocol extensions for using the PCE as the central controller. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-for-pce-controller/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-pcep-extension-for-pce-controller-06 https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-for-pce-controller-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-extension-for-pce-controller-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 Mon Jul 13 12:15:11 2020 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 159EB3A17F3; Mon, 13 Jul 2020 12:15:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: pce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.8.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: pce@ietf.org Message-ID: <159466770605.22902.14153007147460398490@ietfa.amsl.com> Date: Mon, 13 Jul 2020 12:15:06 -0700 Archived-At: Subject: [Pce] I-D Action: draft-ietf-pce-stateful-pce-lsp-scheduling-22.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2020 19:15:06 -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 WG of the IETF. Title : PCEP Extensions for LSP scheduling with stateful PCE Authors : Huaimo Chen Yan Zhuang Qin Wu Daniele Ceccarelli Filename : draft-ietf-pce-stateful-pce-lsp-scheduling-22.txt Pages : 26 Date : 2020-07-13 Abstract: This document defines a set of extensions needed to the stateful Path Computation Element (PCE) communication Protocol (PCEP), so as to enable Labeled Switched Path (LSP) scheduling for path computation and LSP setup/deletion based on the actual network resource usage and the duration of a traffic service in a centralized network environment as stated in RFC 8413. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-lsp-scheduling/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-lsp-scheduling-22 https://datatracker.ietf.org/doc/html/draft-ietf-pce-stateful-pce-lsp-scheduling-22 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-stateful-pce-lsp-scheduling-22 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 Jul 13 12:29:23 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A89963A003E; Mon, 13 Jul 2020 12:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com 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 hlBxNGl1BwA3; Mon, 13 Jul 2020 12:29:14 -0700 (PDT) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2130.outbound.protection.outlook.com [40.107.244.130]) (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 1207E3A005B; Mon, 13 Jul 2020 12:29:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=beFo1YxV2mJvJ0DhtUQEOzbvhUXsI1WZbw1DtSKwfpLncDO3LdK1Mfa8c1vxv4EDG5CNRkls6aqg2PxjLG6/m6LW/eVfjL/ESfhN2qUGBCSU/A90ZuZ1uQuZoO1NO/TwWSuxLxp1Y3W+918Qr4Uo1H+qSEUgEbrvXb49ljD8fAFvijEcHPS5/79XtSdIo0cPMZa3av6swH+ORfaoR0NhJFq2xcHNm81rNI71D+fUFFRN5OkN0IlQXqwn/2iEakE55iLgMFQYy2oYjm2jR5iw2D1geRtYFlTJ+XeeeeWoSbKuVRaY8kCY2pCBQhgCyS0c6a7MJC4fdBkBtYU9x4fbqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DZIzeXmWeUw+b/d9hwQjIYYWU+ZHhZhldMeWboEoyPc=; b=PTcC//oOhSzC73CrDOvWh3avn66Y/aM+HqaHUq1c3euVcY7mclZ5wskXeJ8BU3Gcsr7vanA445x+cEoFhi9hIURfgVZcY0oVnE8GDMNVXCQfFPvzRMBcQo4xvPRQpQkcJN6Fy92IdfGmvWEqSR/3lDzmihQwW1opfnHXsNgP1i1GF0gAeDwqc7807uB37vO/aWec3ZVt/wKTexZU2zSXbouZQU4BsKpleBHwukQIdIuwu1boU+0+2EPv+8a+1Kjv5jpYMEvQQi5UBElhUKvO8Rzrp3HJPkIV1zvngHguGngzIRLc3EwSeu7bOxYd7SGPwPVeZhCP9daNAXADsrFI6w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DZIzeXmWeUw+b/d9hwQjIYYWU+ZHhZhldMeWboEoyPc=; b=eMWIEpMegKNUyhVB+1JC3Up5orG/1aHXk9n3AzI+2VxP2FJb9LpC6dsclM2i+tDwl3ogrL1vkV+mB8VsFhW9zZi8E2W8lsXIoZGAsZTpPfjoTXaoGX/lSMrkZ/DghDxB75Gye4UrxCiMjXJ0k2jf968T45L4DYZQkmkS/CYYhpk= Received: from MN2PR13MB3117.namprd13.prod.outlook.com (2603:10b6:208:13a::20) by MN2PR13MB3007.namprd13.prod.outlook.com (2603:10b6:208:153::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.10; Mon, 13 Jul 2020 19:29:09 +0000 Received: from MN2PR13MB3117.namprd13.prod.outlook.com ([fe80::bd0d:e70d:94e5:81e7]) by MN2PR13MB3117.namprd13.prod.outlook.com ([fe80::bd0d:e70d:94e5:81e7%7]) with mapi id 15.20.3195.009; Mon, 13 Jul 2020 19:29:09 +0000 From: Huaimo Chen To: The IESG , Alvaro Retana CC: "draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org" , "pce-chairs@ietf.org" , "pce@ietf.org" , Adrian Farrel Thread-Topic: Alvaro Retana's No Objection on draft-ietf-pce-stateful-pce-lsp-scheduling-19: (with COMMENT) Thread-Index: AQHWVI3Xkb0zxFK8G0euXGvvDcHNd6kF67ZD Date: Mon, 13 Jul 2020 19:29:09 +0000 Message-ID: References: <159414709200.5178.3398442601733460072@ietfa.amsl.com> In-Reply-To: <159414709200.5178.3398442601733460072@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=futurewei.com; x-originating-ip: [2601:199:4300:8e5a:9cf8:2542:22db:1b63] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9d5caf97-d0f6-4663-23e3-08d8276303e4 x-ms-traffictypediagnostic: MN2PR13MB3007: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: DCtuvSaJxoy0JcqOaRyPUYUT2teyW43vwfUT3mLjIyTYad5KH4BCSkgzKEUwnt5gfyPMXs+PptiwnkUdL/6UFcvC1oc1iCstBWCJr881peDUcPD9rnIc2KdTDwg4tEsP7Qvr5S4D+E3nVb62tvzNGk6gOs6inX02AGu5Fq4cgPA2gUWmiGNlivta3A1GCpl3FUeS2Cznd/BSCkeHmm7YOEAwrKBmBCAxGVD9wRXSYlrp9T3f8lOn15PrHnzGMIK1esURLUHnuDlarpM3+Y4IS/aBStdoBViSojzv0gh5Z31FjVC3Df1K7x7BY2yFI902qhJaRxF1Q6WSbtPWu8fI9XQX2E1JuAaPXD+QSeX9Rt2M59yxj55/8bSlAHe0K1xV62dA3TseanhMxPMDjLKtTA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR13MB3117.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(39840400004)(396003)(376002)(136003)(366004)(71200400001)(166002)(6506007)(186003)(53546011)(7696005)(4326008)(19627405001)(9686003)(64756008)(66446008)(86362001)(55016002)(66476007)(66556008)(2906002)(66946007)(83380400001)(54906003)(5660300002)(33656002)(110136005)(52536014)(76116006)(316002)(8936002)(30864003)(44832011)(966005)(478600001)(45080400002)(8676002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: JnY07Vck9I+1CZVMV6n0Jx8KO38+ILvhWd/rAIwbqMrdxQvq2Xq4FH7p5MtbUcky/vxTeN0qzYOvEIX+3tZYXOD/Nl+kPckKlAexrQAbDgrhQ9kTKnau8Ds9r+v7u554JbVJ2G0myhE0ANf1e22GAb/AtMfpEjwt4RPOz5JtZ2AagsIxVOPRU6Py2+GhsOwGZ+TEtUVSeGMGa7zmEBGsisAWkVwkW5k/2jJ/W1foc4Km4NFVi2Y7cCIhuNA7hnphYuJW9e1DfeANTibxyYEbx+bkDCAwEjdc4QsA0jXhktQqOT9Xr8GrkmLxFAC2DA7MUV8PB8FRG4dZMBomAyHZXZ5X65oGvmAjJn2WUpiSwQvTr0Pz0pySZGDXXPWHBwSGQOQoD7t8zm+ooKZOX0sTTOHkBHH527+VsUd5OCXL6SEyFsmhZY5crf9C+PfnwBxN8QfEaQujiLXIjAFh5ySmCdmorngyQyReB3CDCnSVqz8i85kl9fl5cDdmiaMIT4+lYt1tTfrxKpTkmT2963vqRV5nPlmTParterD4Jn7H2oopA8/9zp7hi8+RlEQPlKD7 x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR13MB311703B5D3940596CC01FBE1F2600MN2PR13MB3117namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR13MB3117.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9d5caf97-d0f6-4663-23e3-08d8276303e4 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2020 19:29:09.3034 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: KfyJ+aPMxF9mIDJK96K/F8dlIQgdmQJtq7UbXkV3siWOnyXF/aD+kiTNIYwy+j3QCe24SZihKWiRLdlCx9yvKA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR13MB3007 Archived-At: Subject: Re: [Pce] Alvaro Retana's No Objection on draft-ietf-pce-stateful-pce-lsp-scheduling-19: (with COMMENT) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2020 19:29:18 -0000 --_000_MN2PR13MB311703B5D3940596CC01FBE1F2600MN2PR13MB3117namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Alvaro, Thank you very much for your valuable comments, which improve the quali= ty of the document. My explanations/answers are inline below with prefix [HC]. The comments have been addressed in version 22 of the document uploaded Best Regards, Huaimo ________________________________ From: Alvaro Retana via Datatracker Sent: Tuesday, July 7, 2020 2:38 PM To: The IESG Cc: draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org ; pce-chairs@ietf.org ; pce@ietf.org ; Adrian Farrel Subject: Alvaro Retana's No Objection on draft-ietf-pce-stateful-pce-lsp-sc= heduling-19: (with COMMENT) Alvaro Retana has entered the following ballot position for draft-ietf-pce-stateful-pce-lsp-scheduling-19: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://nam11.safelinks.protection.outlook.com/?url=3Dhttps= %3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html&data= =3D02%7C01%7Chuaimo.chen%40futurewei.com%7C434b7ffeba034a05e78408d822a4f7d2= %7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637297439231224552&sdata= =3DmCwVobys5l1PWRY5kMWJpEpJkiMERoWN3gEgdh0eNg8%3D&reserved=3D0 for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatra= cker.ietf.org%2Fdoc%2Fdraft-ietf-pce-stateful-pce-lsp-scheduling%2F&dat= a=3D02%7C01%7Chuaimo.chen%40futurewei.com%7C434b7ffeba034a05e78408d822a4f7d= 2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637297439231224552&sdata= =3DSmHFx7UDDZGg15NdjPtjkGsRQuweyNiH1Xr9X93yvgo%3D&reserved=3D0 ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I think that this document still needs work before publication. I consider= the first 3 points below to be close to DISCUSS-worthy. (1) In general, it feels like an editorial pass is needed to tighten up the language used as specification in this document. There are several places where the language feels loose -- as an example (from =A74.4): In PCC-Initiated case, the PCC can send a PCRpt message for the scheduled LSP with updated parameters as well as scheduled information included in the SCHED-LSP-ATTRIBUTE TLV (see Section 5.2.1) or SCHED-PD-LSP-ATTRIBUTE TLV (see Section 5.2.2) carried in the LSP Object. The PCE would take the updated resources and schedule into considerations and update the new path for the scheduled LSP to the PCC as well as synchronize to other PCEs in the network. In case path cannot be set based on new requirements, the previous LSP will not be impacted and the same should be conveyed by the use of empty ERO in the PCEP messages. "the PCC can send" Does it have to? If the information is not sent, then = the PCE will not be able to calculate the path, so something stronger than "can= " seems to be needed. "PCE would take" Does this mean that it is optional? I can imagine how th= e PCE may have local policies affecting the action...but I shouldn't have to imagine anything. "should be conveyed" Again, do you have to? Are there cases when it is ok= not to do it? Not everything needs rfc2119 key words, but in some cases they would help. = In this case, I can see a couple of variations possible. rfc2119> ...the PCC MUST send...the PCE SHOULD take...MUST be conveyed... non-rfc2119> ...the PCC sends...the PCE takes...is conveyed... [HC]: We have updated the document according to rfc2119 as you suggested. (2) =A74.1: "a PCE MUST synchronize to other PCEs within the network...Whic= h way is used to achieve this is out of scope for this document." If the synchronization mechanism is out of scope, how can an implementation be compliant with this specification? IOW, if there's nothing to normatively refer to, then normative language shouldn't be used, or a mechanism should = be mandated. In either case, because synchronization between the PCEs seems important for this specification, I would like to also see a discussion abo= ut the specific effects on LSP scheduling instead of the generic pointer to rfc7399. [HC]: The description related seems too broad. We have rephrased the related text to focus on the state of a scheduled LSP crossing multiple domains from an ingress domain to an egress domain. There is a PCE responsible for each of these domains. The PCE for the ingress domain is called ingress PCE. The PCE for the egress domain is called egress PCE. The state of the LSP MUST be synchronized among these PCEs. After a path for the LSP is computed, a PCRpt message with the scheduled LSP inforamtion MUST be sent to every PCE along the path from the ingress PCE to the egress PCE. After receiving the PCRpt message, the PCE MUST update its SLSP-DB according to the scheduled LSP inforamtion. The ingress PCE acting as a PCC sends its next hop PCE the PCRpt message. After receiving the PCRpt message, the next hop PCE acting as a PCC sends its next hop PCE the PCRpt message. This continues until the egress PCE receives the PCRpt message. =A74.3 says that the "stateful PCE...shall send a PCRpt message with the scheduled LSP to other PCEs...to achieve...synchronization." Even though normative language is not used, the intent seems to specifically point at u= sing PCRpt messages for synchronization... Besides the confusing use of language, rfc8231 defines PCRpt as a "message = sent by a PCC to a PCE to report the current state of an LSP", but I didn't see where the use if defined between PCEs -- maybe I missed it. =A76.1 does reinforce that the "Path Computation State Report (PCRpt) is a PCEP message sent by a PCC to a PCE to report the status of one or more LSPs as per [RFC8231]....This message is also used to synchronize the scheduled LSPs to other PCE as described in [RFC8231]". But this last point is what I can't = find in rfc8231. [HC]: We have updated/cleaned the text related. The Path Computation State Report (PCRpt) is a PCEP message sent by a PCC to a PCE as per [RFC8231]. A PCE can act as a PCC to send a PCRpt message to another PCE. (3) This whole document is about scheduling LSPs, which would seem to requi= re time synchronization. However, I found only one mention: "It is necessary = to synchronize the clocks of the PCEs and PCCs when relative time is used." Should this sentence use normative language? Is there a recommended way to achieve time synchronization? This seems to be an important manageability consideration that impacts network operations. [HC]: Yes. We have changed it to use normative language, and recommended Network Time Protocol [RFC5905] for time synchronization. (4) rfc8413 should be a Normative reference because it "provides a framewor= k that describes and discusses the problem, and defines an appropriate architecture for the scheduled reservation of TE resources", which is the b= asis for the extensions defined in this document. [HC]: We have moved it to Normative reference section. (5) =A72.1: Some of the terminology terms have 2 references -- that caught = my attention. For example, the definition of TED points at both rfc5440 and rfc8231. rfc5440 has a definition, but rfc8231 points at rfc4655. Luckily= , the definitions in rfc5440 and rfc4655 are the same...but the added indirec= tion through rfc8231 is unnecessary. Please revalidate the references and inclu= de only one. [HC]: We have revalidated them and removed the unnecessary ones. (6) =A72.1: "Duration: This value indicates the time duration..." Please= don't use "duration" to define "duration". Maybe s/time duration/length of time [HC]: We have changed it as you suggested. (7) =A74.1: "A PCC MUST delegate a scheduled LSP with information of its scheduling parameters, including the starting time and the duration using P= CRpt message." This sentence seems to refer to the use of the new TLVs defined later in the test. Please include a forward reference to make it easier fo= r the reader to figure out how this action would be done. [HC]: We have added a forward reference to the TLV. (8) =A74.3: "The PCE SHOULD add the scheduled LSP into its scheduled LSP-DB= and update its scheduled TED." When is it ok for the PCE not to add this information? IOW, why is MUST not used? If the information is not added, = what is the effect on the required synchronization? [HC]: We have changed SHOULD to MUST. Later in this section: "The stateful PCE is required to update its local scheduled LSP-DB and scheduled TED with the scheduled LSP." Even though normative language is not used here, the intent of requiring an update to t= he databases seems different than above and results in confusion. [HC]: We have changed "is required to" to MUST (9) =A74.3: "the PCC knows that it is a scheduled path" How? I'm sure tha= t it is through the contents of the messages. Please be specific. [HC]: We have indicated the specific TLV in the message. (10) =A75.1: "After a PCEP session has been established, a PCC and a PCE indicates its ability to support LSP scheduling during the PCEP session establishment phase." Is it after or during? [HC]: During. We have changed it to During. (11) =A75.1: "...the STATEFUL-PCE-CAPABILITY TLV defined in [RFC8231]. Not= e that the STATEFUL-PCE-CAPABILITY TLV is defined in [RFC8231]..." Redundant. [HC]: We have removed the first "defined in [RFC8231]". (12) =A75.1: "we define a new flag bit B (SCHED-LSP-CAPABLITY) flag...B (LSP-SCHEDULING-CAPABILITY..." The names don't match. [HC]: We have updated the text. (13) =A75.1: "Setting PD bit requires setting B bit as specified in 5.2.2."= That is not specified in =A75.2.2. However, it brings up the question about the interpretation of only receiving the PD bit set -- I'm assuming that it sho= uld be ignored unless the B but is also set, right? If so, please specify it! [HC]: You are right. We have added the text to state that it MUST be ignore= d. (14) =A75.2: "this LSP is requesting scheduled parameters" The request is = by the PCC, not the LSP... [HC]: It SHOULD be "this LSP has scheduled parameters". We have changed it accordingly. (15) =A75.2: "scheduled LSP attribute TLV" Even though it may be obvious, = the SCHED-LSP-ATTRIBUTE TLV is not called "scheduled LSP attribute TLV" anywher= e in the document. [HC]: We have changed it to "SCHED-LSP-ATTRIBUTE TLV". (16) =A75.2: "For periodical LSPs, the SCHED-PD-LSP-ATTRIBUTE TLV can be us= ed in LSP Object for each periodic scheduled LSP carried in the PCEP messages." Don't you *have* to use it? Otherwise, how would the periodic nature be kn= own? [HC]: We have changed can to MUST. (17) =A75.2: "Only one of these TLV SHOULD be present in the LSP object. I= n case more than one scheduling TLV is found, the first instance is processed and others ignored." This section talks about both the SCHED-LSP-ATTRIBUTE and= the SCHED-PD-LSP-ATTRIBUTE TLVs -- the sentence sounds as if only one of them (either one) should be present. Please rephrase -- it may be better to def= ine this behavior for each TLV independently (in =A75.2.*). [HC]: We have rephrased it as you suggested. (18) =A75.2.1: "This TLV MUST NOT be included unless both PCEP peers have s= et the B..." What should the receiver do if the TLV is received when both peers didn't set the B bit? [HC]: The receiver ignores the TLV. We have added the text about this. (19) =A75.2.1: "Just before the wraparound, if the time at which the LSP is= to be activated is after the wraparound..." I don't know how that is possible. [HC]: We have added details in version 20. (20) =A75.2.1: "...non-zero grace period or elastic range, but it MUST NOT provide both for an LSP." What should a receiver do if both sets are non-z= ero? [HC]: We have addressed this in version 20. The same space (32 bits) is used for grace period or elastic range. A flag G-bit is defined to indicate which one is stored in the space. G=3D1: the space stores the Grace period. G=3D0: the space stores elastic range. (21) =A75.2.2: "This TLV MUST NOT be included unless both PCEP peers have s= et the B...and PD..." What should the receiver do if the TLV is received but both bits were not set? [HC]: The receiver ignores the TLV. We have added the text about this. (22) =A75.2.2: "A new registry "Opt" under SCHED-PD-LSP-ATTRIBUTE is create= d." The registry is not part of the definition of the field...this sentence is = not needed here. [HC]: We have removed it. (23) =A75.2.2: "Opt value not defined" I think you may mean an unknown va= lue (or maybe unsupported). [HC]: We have changed it to "unknown Opt value". (24) Nits: s/following terminologies are re-used/following terminology is re-used s/computes a path/compute a path/g s/by PCE itself/by a|the PCE itself s/setup of LSP/setup of an LSP s/ask PCC/ask the PCC s/In PCC-Initiated case/In the PCC-Initiated case/g s/In PCE-Initiated case/In the PCE-Initiated case/g s/establish PCEP session/establish a PCEP session s/Setting PD bit requires setting B bit/Setting the PD bit requires setting= the B bit s/presence of SCHED-LSP-ATTRIBUTE/presence of the SCHED-LSP-ATTRIBUTE s/in LSP Object/in the LSP Object/g s/one of these TLV/one of these TLVs s/B (LSP-SCHEDULING-CAPABILITY bit)/B (LSP-SCHEDULING-CAPABILITY) bit/g s/Following flags/The following flags s/remains same as/remain the same as in the s/Options =3D/Opt =3D s/In each of repeats, /During each repetition =A76.1: s/described in [RFC8231]/described in [RFC8231]. [HC]: We have changed all the related text accordingly. --_000_MN2PR13MB311703B5D3940596CC01FBE1F2600MN2PR13MB3117namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Alvaro,

    Thank you very much for your valuable comments, which i= mprove the quality of the document.
    My explanations/answers are inline below with prefix [HC= ].
    The comments have been addressed in version 22 of the d= ocument uploaded

Best Regards,
Huaimo

From: Alvaro Retana via Dat= atracker <noreply@ietf.org>
Sent: Tuesday, July 7, 2020 2:38 PM
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org <draft-ie= tf-pce-stateful-pce-lsp-scheduling@ietf.org>; pce-chairs@ietf.org <pc= e-chairs@ietf.org>; pce@ietf.org <pce@ietf.org>; Adrian Farrel <= ;adrian@olddog.co.uk>
Subject: Alvaro Retana's No Objection on draft-ietf-pce-stateful-pce= -lsp-scheduling-19: (with COMMENT)
 
Alvaro Retana has entered the following ballot pos= ition for
draft-ietf-pce-stateful-pce-lsp-scheduling-19: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html&amp;data=3D02%7C01%7Ch= uaimo.chen%40futurewei.com%7C434b7ffeba034a05e78408d822a4f7d2%7C0fee8ff2a3b= 240189c753a1d5591fedc%7C1%7C0%7C637297439231224552&amp;sdata=3DmCwVobys= 5l1PWRY5kMWJpEpJkiMERoWN3gEgdh0eNg8%3D&amp;reserved=3D0
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://nam11.safelinks.protection.outlook.com/?url=3Dhttps= %3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-pce-stateful-pce-lsp-sched= uling%2F&amp;data=3D02%7C01%7Chuaimo.chen%40futurewei.com%7C434b7ffeba0= 34a05e78408d822a4f7d2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63729743= 9231224552&amp;sdata=3DSmHFx7UDDZGg15NdjPtjkGsRQuweyNiH1Xr9X93yvgo%3D&a= mp;amp;reserved=3D0



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
I think that this document still needs work before publication.  = ;I consider the
first 3 points below to be close to DISCUSS-worthy.

(1) In general, it feels like an editorial pass is needed to tighten u= p the
language used as specification in this document.  There are sever= al places
where the language feels loose -- as an example (from =A74.4):

   In PCC-Initiated case, the PCC can send a PCRpt message f= or the
   scheduled LSP with updated parameters as well as schedule= d
   information included in the SCHED-LSP-ATTRIBUTE TLV (see<= br>
   Section 5.2.1) or SCHED-PD-LSP-ATTRIBUTE TLV (see Section= 5.2.2)
   carried in the LSP Object.  The PCE would take the u= pdated resources
   and schedule into considerations and update the new path = for the
   scheduled LSP to the PCC as well as synchronize to other = PCEs in the
   network.  In case path cannot be set based on new re= quirements, the
   previous LSP will not be impacted and the same should be = conveyed by
   the use of empty ERO in the PCEP messages.

"the PCC can send"  Does it have to?  If the infor= mation is not sent, then the
PCE will not be able to calculate the path, so something stronger than= "can"
seems to be needed.

"PCE would take"  Does this mean that it is optional? &= nbsp;I can imagine how the
PCE may have local policies affecting the action...but I shouldn't hav= e to
imagine anything.

"should be conveyed"  Again, do you have to?  Are = there cases when it is ok not
to do it?

Not everything needs rfc2119 key words, but in some cases they would h= elp.  In
this case, I can see a couple of variations possible.

rfc2119>
   ...the PCC MUST send...the PCE SHOULD take...MUST be conv= eyed...

non-rfc2119>
   ...the PCC sends...the PCE takes...is conveyed...

[HC]: We have updated the document according to rfc2119 as you suggest= ed.


(2) =A74.1: "a PCE MUST synchronize to other PCEs within the netw= ork...Which way
is used to achieve this is out of scope for this document."  = ; If the
synchronization mechanism is out of scope, how can an implementation b= e
compliant with this specification?  IOW, if there's nothing to no= rmatively
refer to, then normative language shouldn't be used, or a mechanism sh= ould be
mandated.  In either case, because synchronization between the PC= Es seems
important for this specification, I would like to also see a discussio= n about
the specific effects on LSP scheduling instead of the generic pointer = to
rfc7399.

[HC]: The description related seems too broad. We have rephrased
the related text to focus on the state of a scheduled LSP
crossing multiple domains from an ingress domain to an egress domain. =
There is a PCE responsible for each of these domains.
The PCE for the ingress domain is called ingress PCE.
The PCE for the egress domain is called egress PCE.
The state of the LSP MUST be synchronized among these PCEs.

After a path for the LSP is computed, a PCRpt message with the
scheduled LSP inforamtion MUST be sent to every PCE along the path
from the ingress PCE to the egress PCE.  
After receiving the PCRpt message,
the PCE MUST update its SLSP-DB according to the scheduled LSP inforam= tion.
 
The ingress PCE acting as a PCC sends its next hop PCE the PCRpt messa= ge.
After receiving the PCRpt message, the next hop PCE acting as a PCC se= nds
its next hop PCE the PCRpt message. This continues until the egress
PCE receives the PCRpt message.


=A74.3 says that the "stateful PCE...shall send a PCRpt message w= ith the
scheduled LSP to other PCEs...to achieve...synchronization." &nbs= p;Even though
normative language is not used, the intent seems to specifically point= at using
PCRpt messages for synchronization...

Besides the confusing use of language, rfc8231 defines PCRpt as a &quo= t;message sent
by a PCC to a PCE to report the current state of an LSP", but I d= idn't see
where the use if defined between PCEs -- maybe I missed it.  =A76= .1 does
reinforce that the "Path Computation State Report (PCRpt) is a PC= EP message
sent by a PCC to a PCE to report the status of one or more LSPs as per=
[RFC8231]....This message is also used to synchronize the scheduled LS= Ps to
other PCE as described in [RFC8231]".  But this last point i= s what I can't find
in rfc8231.

[HC]: We have updated/cleaned the text related.
The Path Computation State Report (PCRpt) is a PCEP message sent by
a PCC to a PCE as per [RFC8231]. A PCE can act as a PCC to send a PCRp= t
message to another PCE.


(3) This whole document is about scheduling LSPs, which would seem to = require
time synchronization.  However, I found only one mention: "I= t is necessary to
synchronize the clocks of the PCEs and PCCs when relative time is used= ."
Should this sentence use normative language?  Is there a recommen= ded way to
achieve time synchronization?  This seems to be an important mana= geability
consideration that impacts network operations.

[HC]: Yes. We have changed it to use normative language, and
recommended Network Time Protocol [RFC5905] for time synchronization.<= br>


(4) rfc8413 should be a Normative reference because it "provides = a framework
that describes and discusses the problem, and defines an appropriate
architecture for the scheduled reservation of TE resources", whic= h is the basis
for the extensions defined in this document.

[HC]: We have moved it to Normative reference section.


(5) =A72.1: Some of the terminology terms have 2 references -- that ca= ught my
attention.  For example, the definition of TED points at both rfc= 5440 and
rfc8231.  rfc5440 has a definition, but rfc8231 points at rfc4655= .  Luckily,
the definitions in rfc5440 and rfc4655 are the same...but the added in= direction
through rfc8231 is unnecessary.  Please revalidate the references= and include
only one.
 
[HC]: We have revalidated them and removed the unnecessary ones.
 

(6) =A72.1: "Duration:  This value indicates the time durati= on..."   Please don't
use "duration" to define "duration".  Maybe s= /time duration/length of time
 
[HC]: We have changed it as you suggested.
 

(7) =A74.1: "A PCC MUST delegate a scheduled LSP with information= of its
scheduling parameters, including the starting time and the duration us= ing PCRpt
message."  This sentence seems to refer to the use of the ne= w TLVs defined
later in the test.  Please include a forward reference to make it= easier for
the reader to figure out how this action would be done.
 
[HC]: We have added a forward reference to the TLV.
 

(8) =A74.3: "The PCE SHOULD add the scheduled LSP into its schedu= led LSP-DB and
update its scheduled TED."  When is it ok for the PCE not to= add this
information?  IOW, why is MUST not used?  If the information= is not added, what
is the effect on the required synchronization?
 
[HC]: We have changed SHOULD to MUST.
 

Later in this section: "The stateful PCE is required to update it= s local
scheduled LSP-DB and scheduled TED with the scheduled LSP."  = ;Even though
normative language is not used here, the intent of requiring an update= to the
databases seems different than above and results in confusion.
 
[HC]: We have changed "is required to" to MUST
 

(9) =A74.3: "the PCC knows that it is a scheduled path" &nbs= p;How?  I'm sure that it
is through the contents of the messages.  Please be specific.
 
[HC]: We have indicated the specific TLV in the message.
 

(10) =A75.1: "After a PCEP session has been established, a PCC an= d a PCE
indicates its ability to support LSP scheduling during the PCEP sessio= n
establishment phase."  Is it after or during?
 
[HC]: During. We have changed it to During.
 

(11) =A75.1: "...the STATEFUL-PCE-CAPABILITY TLV defined in [RFC8= 231].  Note that
the STATEFUL-PCE-CAPABILITY TLV is defined in [RFC8231]..."  = ;Redundant.
 
[HC]: We have removed the first "defined in [RFC8231]".
 

(12) =A75.1: "we define a new flag bit B (SCHED-LSP-CAPABLITY) fl= ag...B
(LSP-SCHEDULING-CAPABILITY..."  The names don't match.
 
[HC]: We have updated the text.
 

(13) =A75.1: "Setting PD bit requires setting B bit as specified = in 5.2.2."  That
is not specified in =A75.2.2.  However, it brings up the question= about the
interpretation of only receiving the PD bit set -- I'm assuming that i= t should
be ignored unless the B but is also set, right?  If so, please sp= ecify it!
 
[HC]: You are right. We have added the text to state that it MUST be i= gnored.
 

(14) =A75.2: "this LSP is requesting scheduled parameters" &= nbsp;The request is by the
PCC, not the LSP...
 
[HC]: It SHOULD be "this LSP has scheduled parameters".
We have changed it accordingly.
 

(15) =A75.2: "scheduled LSP attribute TLV"  Even though= it may be obvious, the
SCHED-LSP-ATTRIBUTE TLV is not called "scheduled LSP attribute TL= V" anywhere in
the document.
 
[HC]: We have changed it to "SCHED-LSP-ATTRIBUTE TLV".
 

(16) =A75.2: "For periodical LSPs, the SCHED-PD-LSP-ATTRIBUTE TLV= can be used in
LSP Object for each periodic scheduled LSP carried in the PCEP message= s."
Don't you *have* to use it?  Otherwise, how would the periodic na= ture be known?
 
[HC]: We have changed can to MUST.
 

(17) =A75.2: "Only one of these TLV SHOULD be present in the LSP = object.  In case
more than one scheduling TLV is found, the first instance is processed= and
others ignored."  This section talks about both the SCHED-LS= P-ATTRIBUTE and the
SCHED-PD-LSP-ATTRIBUTE TLVs -- the sentence sounds as if only one of t= hem
(either one) should be present.  Please rephrase -- it may be bet= ter to define
this behavior for each TLV independently (in =A75.2.*).
 
[HC]: We have rephrased it as you suggested.
 

(18) =A75.2.1: "This TLV MUST NOT be included unless both PCEP pe= ers have set the
B..."  What should the receiver do if the TLV is received wh= en both peers
didn't set the B bit?
 
[HC]: The receiver ignores the TLV. We have added the text about this.=

 

(19) =A75.2.1: "Just before the wraparound, if the time at which = the LSP is to be
activated is after the wraparound..."   I don't know how tha= t is possible.
 
[HC]: We have added details in version 20.
 

(20) =A75.2.1: "...non-zero grace period or elastic range, but it= MUST NOT
provide both for an LSP."  What should a receiver do if both= sets are non-zero?
 
[HC]: We have addressed this in version 20.
The same space (32 bits) is used for grace period or elastic range.
A flag G-bit is defined to indicate which one is stored in the space.<= br>
G=3D1: the space stores the Grace period.
G=3D0: the space stores elastic range.
 

(21) =A75.2.2: "This TLV MUST NOT be included unless both PCEP pe= ers have set the
B...and PD..."  What should the receiver do if the TLV is re= ceived but both
bits were not set?
 
[HC]: The receiver ignores the TLV. We have added the text about this.=
 

(22) =A75.2.2: "A new registry "Opt" under SCHED-PD-LSP= -ATTRIBUTE is created."
The registry is not part of the definition of the field...this sentenc= e is not
needed here.
 
[HC]: We have removed it.
 

(23) =A75.2.2: "Opt value not defined"   I think you ma= y mean an unknown value
(or maybe unsupported).
 
[HC]: We have changed it to "unknown Opt value".
 

(24) Nits:

s/following terminologies are re-used/following terminology is re-used=

s/computes a path/compute a path/g

s/by PCE itself/by a|the PCE itself

s/setup of LSP/setup of an LSP

s/ask PCC/ask the PCC

s/In PCC-Initiated case/In the PCC-Initiated case/g

s/In PCE-Initiated case/In the PCE-Initiated case/g

s/establish PCEP session/establish a PCEP session

s/Setting PD bit requires setting B bit/Setting the PD bit requires se= tting the
B bit

s/presence of SCHED-LSP-ATTRIBUTE/presence of the SCHED-LSP-ATTRIBUTE<= br>

s/in LSP Object/in the LSP Object/g

s/one of these TLV/one of these TLVs

s/B (LSP-SCHEDULING-CAPABILITY bit)/B (LSP-SCHEDULING-CAPABILITY) bit/= g

s/Following flags/The following flags

s/remains same as/remain the same as in the

s/Options =3D/Opt =3D

s/In each of repeats, /During each repetition

=A76.1: s/described in [RFC8231]/described in [RFC8231].

[HC]: We have changed all the related text accordingly.




--_000_MN2PR13MB311703B5D3940596CC01FBE1F2600MN2PR13MB3117namp_-- From nobody Mon Jul 13 13:34:06 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 919583A090B; Mon, 13 Jul 2020 13:34:04 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 IWg4WvVZI3Ss; Mon, 13 Jul 2020 13:34:03 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56D0F3A08C7; Mon, 13 Jul 2020 13:34:03 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 28B5EF4074E; Mon, 13 Jul 2020 13:34:02 -0700 (PDT) To: chillol@juniper.net, edward.crabbe@oracle.com, inaminei@google.com, jmedved@cisco.com, robert.varga@pantheon.tech X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: db3546@att.com, iesg@ietf.org, pce@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200713203402.28B5EF4074E@rfc-editor.org> Date: Mon, 13 Jul 2020 13:34:02 -0700 (PDT) Archived-At: Subject: [Pce] [Errata Held for Document Update] RFC8231 (5796) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2020 20:34:05 -0000 The following errata report has been held for document update for RFC8231, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5796 -------------------------------------- Status: Held for Document Update Type: Technical Reported by: Hillol Date Reported: 2019-07-29 Held by: Deborah Brungard (IESG) Section: 7.3.3 Original Text ------------- Value Description ----- ------------------------------------- 1 Unknown reason 2 Limit reached for PCE-controlled LSPs 3 Too many pending LSP Update Requests 4 Unacceptable parameters 5 Internal error 6 LSP administratively brought down 7 LSP preempted 8 RSVP signaling error Corrected Text -------------- Remove Value 2 2 Limit reached for PCE-controlled LSPs Notes ----- Value 2 "Limit reached for PCE-controlled LSPs" can occur when an PC update message comes for either PCInitiated or PCDelegated LSP. But since the lsp is already created or delegated, it means the resource is available and allocated. Also RFC 8281 (section 5.3) states that if LSP provisioned exceeds the limit, an LSP error message should be sent with Error-type=19 (Invalid Operation) and Error-value=6 (PCE-initiated LSP limit reached). So, I believe there is no scenario where LSP Error code TLV "Limit reached for PCE-controlled LSPs" would be used. Please let me know if there is some scenario which can trigger the same. -------------------------------------- RFC8231 (draft-ietf-pce-stateful-pce-21) -------------------------------------- Title : Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE Publication Date : September 2017 Author(s) : E. Crabbe, I. Minei, J. Medved, R. Varga Category : PROPOSED STANDARD Source : Path Computation Element Area : Routing Stream : IETF Verifying Party : IESG From nobody Mon Jul 13 13:36:12 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 123903A0DC7; Mon, 13 Jul 2020 13:36:02 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 n9Ir7iEqG0MR; Mon, 13 Jul 2020 13:36:00 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19E7E3A0C17; Mon, 13 Jul 2020 13:35:30 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id E0314F4074E; Mon, 13 Jul 2020 13:35:28 -0700 (PDT) To: dhruv.ietf@gmail.com, edward.crabbe@oracle.com, inaminei@google.com, jmedved@cisco.com, robert.varga@pantheon.tech X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: db3546@att.com, iesg@ietf.org, pce@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200713203528.E0314F4074E@rfc-editor.org> Date: Mon, 13 Jul 2020 13:35:28 -0700 (PDT) Archived-At: Subject: [Pce] [Errata Verified] RFC8231 (6012) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2020 20:36:07 -0000 The following errata report has been verified for RFC8231, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6012 -------------------------------------- Status: Verified Type: Editorial Reported by: Dhruv Dhody Date Reported: 2020-03-10 Verified by: Deborah Brungard (IESG) Section: 5.8.3 Original Text ------------- If the PCC receives a PCUpd message for an LSP object identified with a PLSP-ID that does not exist on the PCC, it MUST generate a PCErr with Error-type=19 (Invalid Operation), error-value 3, (Attempted LSP Update Request for an LSP identified by an unknown PSP-ID) (see Section 8.5). Corrected Text -------------- If the PCC receives a PCUpd message for an LSP object identified with a PLSP-ID that does not exist on the PCC, it MUST generate a PCErr with Error-type=19 (Invalid Operation), error-value 3, (Attempted LSP Update Request for an LSP identified by an unknown PLSP-ID) (see Section 8.5). Notes ----- s/PSP-ID/PLSP-ID/ Thanks to Rebecca Vanrheenen from RFC Editor team for spotting this while editing another I-D. -------------------------------------- RFC8231 (draft-ietf-pce-stateful-pce-21) -------------------------------------- Title : Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE Publication Date : September 2017 Author(s) : E. Crabbe, I. Minei, J. Medved, R. Varga Category : PROPOSED STANDARD Source : Path Computation Element Area : Routing Stream : IETF Verifying Party : IESG From nobody Mon Jul 13 14:00:43 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08FDF3A081F; Mon, 13 Jul 2020 14:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 hIO51X0zddbw; Mon, 13 Jul 2020 14:00:36 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1003B3A098C; Mon, 13 Jul 2020 14:00:36 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id CF7D5F40751; Mon, 13 Jul 2020 14:00:34 -0700 (PDT) To: sburnwal@juniper.net, edward.crabbe@oracle.com, inaminei@google.com, jmedved@cisco.com, robert.varga@pantheon.tech X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: db3546@att.com, iesg@ietf.org, pce@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200713210034.CF7D5F40751@rfc-editor.org> Date: Mon, 13 Jul 2020 14:00:34 -0700 (PDT) Archived-At: Subject: [Pce] [Errata Verified] RFC8231 (5970) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2020 21:00:38 -0000 The following errata report has been verified for RFC8231, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5970 -------------------------------------- Status: Verified Type: Technical Reported by: Subham Burnwal Date Reported: 2020-01-31 Verified by: Deborah Brungard (IESG) Section: 8.5 Original Text ------------- 19 Invalid Operation Error-value 1: Attempted LSP Update Request for a non-delegated LSP. The PCEP-ERROR object is followed by the LSP object that identifies the LSP. Corrected Text -------------- 19 Invalid Operation Error-value 1: Attempted LSP Update Request for a non-delegated LSP. Notes ----- RFC 8231 Section 6.3 - LSP Object is not part of PCErr message. -------------------------------------- RFC8231 (draft-ietf-pce-stateful-pce-21) -------------------------------------- Title : Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE Publication Date : September 2017 Author(s) : E. Crabbe, I. Minei, J. Medved, R. Varga Category : PROPOSED STANDARD Source : Path Computation Element Area : Routing Stream : IETF Verifying Party : IESG From nobody Mon Jul 13 14:20:12 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BABC3A0B6B for ; Mon, 13 Jul 2020 14:18:39 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 dlDPpFI3q7pv for ; Mon, 13 Jul 2020 14:18:38 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2715F3A0858 for ; Mon, 13 Jul 2020 14:18:09 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id D95B6F4074C; Mon, 13 Jul 2020 14:18:07 -0700 (PDT) To: edward.crabbe@oracle.com, inaminei@google.com, jmedved@cisco.com, robert.varga@pantheon.tech, db3546@att.com, aretana.ietf@gmail.com, martin.vigoureux@nokia.com, dd@dhruvdhody.com, julien.meuric@orange.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: dd@dhruvdhody.com, pce@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200713211807.D95B6F4074C@rfc-editor.org> Date: Mon, 13 Jul 2020 14:18:07 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Mon, 13 Jul 2020 14:20:11 -0700 Subject: [Pce] [Technical Errata Reported] RFC8231 (6231) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2020 21:18:39 -0000 The following errata report has been submitted for RFC8231, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6231 -------------------------------------- Type: Technical Reported by: Dhruv Dhody Section: 8.5 Original Text ------------- 20 LSP State Synchronization Error Error-value 1: A PCE indicates to a PCC that it cannot process (an otherwise valid) LSP State Report. The PCEP-ERROR object is followed by the LSP object that identifies the LSP. Corrected Text -------------- 20 LSP State Synchronization Error Error-value 1: A PCE indicates to a PCC that it cannot process (an otherwise valid) LSP State Report. Notes ----- This is a companion errata to https://www.rfc-editor.org/errata/eid5970 which identified the issue in Error-type 19 Error-value 1. The same issue exists for Error-type 20 Error-value 1 i.e. LSP Object is not part of the PCErr message. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8231 (draft-ietf-pce-stateful-pce-21) -------------------------------------- Title : Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE Publication Date : September 2017 Author(s) : E. Crabbe, I. Minei, J. Medved, R. Varga Category : PROPOSED STANDARD Source : Path Computation Element Area : Routing Stream : IETF Verifying Party : IESG From nobody Thu Jul 16 06:35:09 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69EF83A0528 for ; Thu, 16 Jul 2020 06:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dhruvdhody-com.20150623.gappssmtp.com 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 O6bvgIe3CCZM for ; Thu, 16 Jul 2020 06:35:06 -0700 (PDT) Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 535A83A0746 for ; Thu, 16 Jul 2020 06:35:06 -0700 (PDT) Received: by mail-pf1-x42e.google.com with SMTP id x72so3703758pfc.6 for ; Thu, 16 Jul 2020 06:35:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dhruvdhody-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=9oCNBorq/xd72R1WdiRwfjEquWumsqFrrL1CYl3Wx/A=; b=YQHr6aqqfgEI3YTi/07Bd1Z/MIivA0O98GIR71tvVzKCKKwJnCSKxxrt+nk8C2hAwr iDBg6fGAp9Q5IY287ZFRJxKXJdL4qZP2e1FzCOtkkTBJq5uRvKd+GZrQhz14IQx3zC80 JYZVBlXgOJd368obQFhD/vxNyPleRBSp6LqUlue6qHPKgxZVdvZO2gkm+SNvzuoYkTwz YW6+5/lVMdK3SQYpnKVoF2azuudh8tnKar5y8MU8/eYa0bQseRRpsjFNMXUecn54vxWb lGrXpdwNmiXg5MAuNxFHMhMaJolDDXqGhEiZhWHR+jJLKbfQlz/RpWTParFO8ACBxuim XheQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=9oCNBorq/xd72R1WdiRwfjEquWumsqFrrL1CYl3Wx/A=; b=qSpMSaSHzcstlgUcIXf/u5PXu79au6urf9pjYOqUf2DPCreXFtcklPmFcnS8hkkbS0 fpEq/2fIZBZpfdbRMHhutC8Q+CEiixFXTpkcs6F1otYw45Yn3iVH8HaGP6xfNxbk3IHJ utyWiRaHCQ6UeMKN77CpaGF/+QjDOUgKd+DOaq+sJjYBEeP/BjGCCDulGQj8yN9/kQlD J6Mj0exipHL719i+gA1qoWyk8TKFsg6pA00Lc9v4VwiLEonpCRnGJ6yv4thyZqHtOPuq nHg5B8gGC+J865cai4++GmT0W6UlR33aweN0rWyeA2U3HSiOtu1Lw4AsqLCNOClTB5yE KaXA== X-Gm-Message-State: AOAM531aswWE7qb0ynyaEcrfJHoqKH2OgtevkGGpJD7ewYbHG8gF2YCp +yvyJflsK40Xukpt/sblDAvCdiNAlwFuO7PsC0K1X6byOrH3eQ== X-Google-Smtp-Source: ABdhPJwz1EASZ6QXIb5y4QQa6N4PcskpE9K8L5+MTiGJULQR0BA2MnWcayj7zbSlTJV8uwzFUjNE9MOtqSKfuJrEYi4= X-Received: by 2002:aa7:9d81:: with SMTP id f1mr3584780pfq.225.1594906505347; Thu, 16 Jul 2020 06:35:05 -0700 (PDT) MIME-Version: 1.0 From: Dhruv Dhody Date: Thu, 16 Jul 2020 19:04:54 +0530 Message-ID: To: pce@ietf.org Cc: pce-chairs Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Pce] PCE WG Agenda for IETF 108 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 13:35:07 -0000 Hi WG, The agenda for the PCE WG session during IETF 108 is posted -https://datatracker.ietf.org/meeting/108/materials/agenda-108-pce.html Please familiarize yourself with the meetecho tool with prep session scheduled for tomorrow; find useful information at - https://www.ietf.org/how/meetings/108/session-participant-guide/ Presenters, please send your slides to pce-chairs@ietf.org by Sunday 26th July 12:00 UTC, earlier is much better! Stay Safe! Thanks! Dhruv, Julien & Hari. From nobody Tue Jul 21 06:19:00 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE6763A0825 for ; Tue, 21 Jul 2020 06:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 E4lX5WJbMewz for ; Tue, 21 Jul 2020 06:18:56 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 978083A0805 for ; Tue, 21 Jul 2020 06:18:56 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id y2so21343315ioy.3 for ; Tue, 21 Jul 2020 06:18:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=cSpLTuIgq26M5xBv9Nf13nw/scLwbW1Hq/8gVzkGVPo=; b=iPlD3+CM1iZ0oQmejTTIym+eG4RTOvYpu79xtI4wlE4kaS7a8b3mgKtO472Y0R1fRL 0ZcE8VsxlBJSx/bG80dH369rf+NH8rEIFg2sV6j9gQpnZ40XZpcAqDjk8fY3QnLlPC0D VwZTEaOtPcZOxBgT4/R/x1m5g79R6ChCw7rsXBmJsWz/XmAQDQYfbjO0AIUnjGG0sDBT n0BAGUQUiYYc1zY0xTrXrp909EchI+Qz8OI7Ip8oyFY/+xRDg8b3L/jbJ/7WA3PeqyJk iVYIMBpD/v3dpuXdkbV/ctfHTSkg7HaVDDVOxAy87nJTQ76w2aTCJTZ/zNm5/rEOPbUA Yt2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=cSpLTuIgq26M5xBv9Nf13nw/scLwbW1Hq/8gVzkGVPo=; b=imssRj/3G4aK17I4+lmLzZHY1xvEVdDq/iCC+jzBnq3fDxmd8tHXwpTrhNeaNtKsoU e5wcZ/RRDIJbuorbH44hBTM095kTvYSCHlDOXy2q9/mxVVaNM0LUMlaQEpIDbueOXriM OakrqBru+pOoySrQ6C8i1F52FlrlqJNd8wFKme5UYZUjxevOeDTdxHxj1+jvv5NWudpM XKhxS3oEW57BAuHZ+Q30NFBbf4fUv5Eyc+mQY+XUB0UESLylQUa4DrLzLm8ugaxUxDB2 GiSWYSdjt32CSQBCWfCGIvjawrCAS3pf6WmkgKRdOJtTnJaIjNDpz2WqHmrt2M5Icuy6 pf0A== X-Gm-Message-State: AOAM532QmuqvFmN6Jg1nfOV0U22z08WYlRYoylgWEpr4uB3/cYiLoHCL cdokpSqxE+nPRbeZt447YSnd5CL9b99xQCgcizThICb0PdY= X-Google-Smtp-Source: ABdhPJwaz6S4GIBecO7FxRrjEMI9ttInLRjBiM3r3nBHH4PM/rZmZzcQZv23pN5eC1GbLrtRUAOlrrL9i8+VuNy/TQQ= X-Received: by 2002:a05:6638:3aa:: with SMTP id z10mr32082836jap.54.1595337535390; Tue, 21 Jul 2020 06:18:55 -0700 (PDT) MIME-Version: 1.0 From: Dhruv Dhody Date: Tue, 21 Jul 2020 18:48:18 +0530 Message-ID: To: pce@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Pce] L2 flow specifications in draft-ietf-pce-pcep-flowspec X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2020 13:18:58 -0000 Hi WG, While reviewing the L2 Flowspec document [1] in IDR, I noticed that a change was made in the IANA consideration [2] where they are asking for a new L2 Flow Specification Component Type registry, whereas earlier they were requesting the codepoints from the existing registry. There is a need to align the PCEP Flowspec to handle L2 flow specifications. We propose a new container TLV called L2 Flow Filter TLV to carry the L2 Flow Specifications and maintain another registry for this. The rest of the mechanism would remain the same. The authors discussed this with chairs/AD and have a proposed update at [4] with the diff at [5]. Please take a look and let us know if you have any objections to this change or have any questions/suggestions. Note that the document is out of the WG, and Julien will work with Deborah on the next step to handle this change. Thanks! Dhruv, Adrian & Robin [1] https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-l2vpn/ [2] https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-l2vpn-15#section-6 [3] https://tools.ietf.org/html/draft-ietf-pce-pcep-flowspec-08#section-7 [4] https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-pcep-flowspec-10.txt [5] https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=draft-ietf-pce-pcep-flowspec-09&url2=https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-pcep-flowspec-10.txt From nobody Tue Jul 21 08:36:05 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC2CA3A0B27; Tue, 21 Jul 2020 08:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Wz1JMn5unZs6; Tue, 21 Jul 2020 08:35:57 -0700 (PDT) Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 747673A0B63; Tue, 21 Jul 2020 08:35:55 -0700 (PDT) Received: by mail-wr1-x443.google.com with SMTP id z15so21619236wrl.8; Tue, 21 Jul 2020 08:35:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=T57q13wpGKTbSe+pJQPHirUG1wycWOCX9wOJptMOdVM=; b=olxr+M4P3iD4hLLcWAZ1lcuejwtDvTdaGF7i1lJjfP66KEC65XM0toO2IbCtwsuAPq K87deKUhLHQEIPhpulF8YSNTJ2bTJcHsfwD++ZZIVI/c+523bs0MMvwHTxiQLdcGJUre zxQN/Mc9A+kMsCBIOYojNScmnuR2+VtQMpV5pM45cxLPWzlkrzSwTRESflD7oaX47KXj mtuKEz4MchR5SJ5fxQ7vuKi+fgdMrj+BfDQv1pyKsLY21x8q29rYhfQvP0N2EG0M2azw l78t9c1OG/uHp3hFSQ7gXrNGpa0A1TeNrYHNeqfiI+yBaS3kv29lsmfLU8B/7fwYfMHM 3n6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=T57q13wpGKTbSe+pJQPHirUG1wycWOCX9wOJptMOdVM=; b=ODvuoLJ/F0v4LwrQGd0UGzvzjLnqVkZ12SQycypIpWVK30MhrRN2gQC9+94HDaTPTW hwFg2+qxPG+kmCmp5NMxNLGAVhllPVna9IB1kQ85je9Y5KbCuuSXehtTUGH2Wn1FKjpX lL3uyuhMZPQuid9fnYmPgSNA8k7GdtdFYXC52j3wSsVudi9dtU64vbMPdnEeTTyJZ7ou 75B/52uPaWJ1ba0KJ56Vv9sX/0T9XUJsufj/ncjY4rzdoZlq5Pyi1Dmt2jFnDkVG4nkJ hxKMNjPKO5a6VB5cdCPin+hypeAmllOAp+gEhCPsUoMR3Ku4FYTOAgyLG7IWhY1hofa/ qbyw== X-Gm-Message-State: AOAM533oOj2bAO9AN8kgzIP1Q0Lfe9LluhQ+VPbnNaSi8XbUaOLUjckF rkj8fPywwDG/rcvC0YzUikPZthUuEp7XfY2KxjUzF7Xx X-Google-Smtp-Source: ABdhPJyvbbjcBC76NpD0ZD0Vyx+M9P4NZSu6ztZS6HyeyVTp08xww8tO3t0+3zaQeitWxCnf6Z2K2MQXPKxvPmvxWF0= X-Received: by 2002:a5d:5651:: with SMTP id j17mr25835954wrw.145.1595345753432; Tue, 21 Jul 2020 08:35:53 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 21 Jul 2020 11:35:52 -0400 From: Alvaro Retana In-Reply-To: <159414709200.5178.3398442601733460072@ietfa.amsl.com> References: <159414709200.5178.3398442601733460072@ietfa.amsl.com> MIME-Version: 1.0 Date: Tue, 21 Jul 2020 11:35:52 -0400 Message-ID: To: Alvaro Retana via Datatracker , The IESG Cc: pce-chairs@ietf.org, draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org, pce@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Pce] Alvaro Retana's No Objection on draft-ietf-pce-stateful-pce-lsp-scheduling-19: (with COMMENT) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2020 15:35:59 -0000 On July 13, 2020 at 3:29:13 PM, Huaimo Chen wrote: Huaimo: Hi! ... > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > I think that this document still needs work before publication. I conside= r > the first 3 points below to be close to DISCUSS-worthy. > > (1) In general, it feels like an editorial pass is needed to tighten up t= he > language used as specification in this document. There are several places > where the language feels loose -- as an example (from =C2=A74.4): ... > [HC]: We have updated the document according to rfc2119 as you suggested. Thanks for addressing this one instance. =C2=A0As I mentioned, there are other similar instances that would benefit from similar tightening up -- please reread through the document with an eye for "loose language". =C2=A0I trust that you will do the right thing. > (2) =C2=A74.1: "a PCE MUST synchronize to other PCEs within the network..= .Which > way is used to achieve this is out of scope for this document." If the > synchronization mechanism is out of scope, how can an implementation be > compliant with this specification? IOW, if there's nothing to normatively > refer to, then normative language shouldn't be used, or a mechanism shoul= d > be mandated. In either case, because synchronization between the PCEs see= ms > important for this specification, I would like to also see a discussion > about the specific effects on LSP scheduling instead of the generic point= er > to rfc7399. > > [HC]: The description related seems too broad. We have rephrased > the related text to focus on the state of a scheduled LSP > crossing multiple domains from an ingress domain to an egress domain. ... As mentioned separately...I think that changing the scenario is not a good idea at this point. =C2=A0It also leaves the single domain case unaddressed. > =C2=A74.3 says that the "stateful PCE...shall send a PCRpt message with t= he > scheduled LSP to other PCEs...to achieve...synchronization." Even though > normative language is not used, the intent seems to specifically point at > using PCRpt messages for synchronization... > > Besides the confusing use of language, rfc8231 defines PCRpt as a "messag= e > sent by a PCC to a PCE to report the current state of an LSP", but I didn= 't > see where the use if defined between PCEs -- maybe I missed it. =C2=A76.1= does > reinforce that the "Path Computation State Report (PCRpt) is a PCEP messa= ge > sent by a PCC to a PCE to report the status of one or more LSPs as per > [RFC8231]....This message is also used to synchronize the scheduled LSPs = to > other PCE as described in [RFC8231]". But this last point is what I can't > find in rfc8231. > > [HC]: We have updated/cleaned the text related. > The Path Computation State Report (PCRpt) is a PCEP message sent by > a PCC to a PCE as per [RFC8231]. A PCE can act as a PCC to send a PCRpt > message to another PCE. The "as described in [RFC8231]" text is still not accurate -- that document doesn't talk about using the PCRpt message between PCEs. I don't think that the "PCE can act as a PCC" part is well defined. Is it specified somewhere else? > (3) This whole document is about scheduling LSPs, which would seem to req= uire > time synchronization. However, I found only one mention: "It is necessary= to > synchronize the clocks of the PCEs and PCCs when relative time is used." > Should this sentence use normative language? Is there a recommended way t= o > achieve time synchronization? This seems to be an important manageability > consideration that impacts network operations. > > [HC]: Yes. We have changed it to use normative language, and > recommended Network Time Protocol [RFC5905] for time synchronization. The reference should be Normative. Thanks! Alvaro. From nobody Tue Jul 21 16:51:55 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0901A3A084D; Tue, 21 Jul 2020 16:51:50 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 1abR2Wnzh2kX; Tue, 21 Jul 2020 16:51:48 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C52B63A0840; Tue, 21 Jul 2020 16:51:48 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 6F3C4F40758; Tue, 21 Jul 2020 16:51:34 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, pce@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20200721235134.6F3C4F40758@rfc-editor.org> Date: Tue, 21 Jul 2020 16:51:34 -0700 (PDT) Archived-At: Subject: [Pce] =?utf-8?q?RFC_8779_on_Path_Computation_Element_Communicati?= =?utf-8?q?on_Protocol_=28PCEP=29_Extensions_for_GMPLS?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2020 23:51:50 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8779 Title: Path Computation Element Communication Protocol (PCEP) Extensions for GMPLS Author: C. Margaria, Ed., O. Gonzalez de Dios, Ed., F. Zhang, Ed. Status: Standards Track Stream: IETF Date: July 2020 Mailbox: cmargaria@juniper.net, oscar.gonzalezdedios@telefonica.com, zhangfatai@huawei.com Pages: 38 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pce-gmpls-pcep-extensions-16.txt URL: https://www.rfc-editor.org/info/rfc8779 DOI: 10.17487/RFC8779 A Path Computation Element (PCE) provides path computation functions for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Additional requirements for GMPLS are identified in RFC 7025. This memo provides extensions to the Path Computation Element Communication Protocol (PCEP) for the support of the GMPLS control plane to address those requirements. This document is a product of the Path Computation Element Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. 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/retrieve/bulk 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 From nobody Tue Jul 21 16:52:19 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B15513A08CC; Tue, 21 Jul 2020 16:52:11 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 DbirTduwVc6g; Tue, 21 Jul 2020 16:52:10 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6F393A08E1; Tue, 21 Jul 2020 16:52:08 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 9579FF40761; Tue, 21 Jul 2020 16:51:54 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, pce@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20200721235154.9579FF40761@rfc-editor.org> Date: Tue, 21 Jul 2020 16:51:54 -0700 (PDT) Archived-At: Subject: [Pce] =?utf-8?q?RFC_8780_on_The_Path_Computation_Element_Communi?= =?utf-8?q?cation_Protocol_=28PCEP=29_Extension_for_Wavelength_Switched_Op?= =?utf-8?q?tical_Network_=28WSON=29_Routing_and_Wavelength_Assignment_=28R?= =?utf-8?b?V0Ep?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2020 23:52:18 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8780 Title: The Path Computation Element Communication Protocol (PCEP) Extension for Wavelength Switched Optical Network (WSON) Routing and Wavelength Assignment (RWA) Author: Y. Lee, Ed., R. Casellas, Ed. Status: Standards Track Stream: IETF Date: July 2020 Mailbox: younglee.tx@gmail.com, ramon.casellas@cttc.es Pages: 26 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pce-wson-rwa-ext-17.txt URL: https://www.rfc-editor.org/info/rfc8780 DOI: 10.17487/RFC8780 This document provides Path Computation Element Communication Protocol (PCEP) extensions for the support of Routing and Wavelength Assignment (RWA) in Wavelength Switched Optical Networks (WSONs). Path provisioning in WSONs requires an 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 path computation. This document is a product of the Path Computation Element Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. 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/retrieve/bulk 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 From nobody Tue Jul 21 21:25:03 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D4D3A0D79 for ; Tue, 21 Jul 2020 21:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dhruvdhody-com.20150623.gappssmtp.com 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 gQ7O0-b3zDKi for ; Tue, 21 Jul 2020 21:25:00 -0700 (PDT) Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E2713A0D7D for ; Tue, 21 Jul 2020 21:25:00 -0700 (PDT) Received: by mail-pj1-x102f.google.com with SMTP id t15so495836pjq.5 for ; Tue, 21 Jul 2020 21:25:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dhruvdhody-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=X6/kqsyeF+vzt5tz8p8/hJ1PNXLmbvEYanP5nIN99Lw=; b=OR+e+qNFZ16fgybxyffw0tSc+OHKeROzgk9ITOLvxt8potZExD9++cJaKTcqf5cMfl uZndNG1UftghDXQbW5+/x4X2QieCpgXBj3y4epdwHe0MR9R2tAHrnlttLsyeKcwBmbrC tSGe6RsU39scC/U62bKYm+UYgv8qp3aNjWnPUEiInvbQtIzygR1iiBlvs/aNH3Abo2Ko MOy6iY9EPDtOkx3J9WFLeKdOjn7C43yL7HTZUwUaoxSikkDGOA4B2odtveQoT56T9TxF BVoEYVjO8dfiYMcyWHicceQFPZmGkEF8489Cg/HHlFyr/W7GGlfLKnjtH+PzqG+EYA4R NycA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=X6/kqsyeF+vzt5tz8p8/hJ1PNXLmbvEYanP5nIN99Lw=; b=JGp1guD9t2uuQ8La1xMkER5K3pCItZKpI9xflZkyIR3xZKGXyGLtWMNMoVqYsfL0UD ZvQK3JMZD1JZbO3m3kjGCrlcUa20liugs0LzmIHQHo+JO8KktrsKX/+jTC/uQNoXqV2R RXJOICOV3k7UvoKzIL52NBS7D6X3AjD4foMauQRa1zHMQ74bZlS1sQQ5lTqux+6wxxwN fEyfaQ8z2W9Q9OYmoh4I2eTdS5j28Ie/ybA2C6RB1p8bbDmdXlac3Qx+CZTeY6dsFQDc LBh5PLJFXZc8u2EF0nKYtCwXZnZ/pU/c8/XbjfpXXRM/Q035K9q0jIMulFSTrnWVJ/Ij U4gQ== X-Gm-Message-State: AOAM531DbEH3EFKpNbifKoOnly+bFd/EI2ljPN4dK9N8H62R1ho/J45o NABJVXhD3Frw5eM5dyd2cqlIWzWLmsUEIYD1rLfj6g== X-Google-Smtp-Source: ABdhPJywsqIrQtxJFF+i7pD0XGYcfrcFdrryjCw5TgZyDRiliU6sEFfvYbmVTUeE9F5Yn4ZkpBX0QC75Vt+mdl9/ThU= X-Received: by 2002:a17:90a:338a:: with SMTP id n10mr8665882pjb.50.1595391899494; Tue, 21 Jul 2020 21:24:59 -0700 (PDT) MIME-Version: 1.0 References: <159414709200.5178.3398442601733460072@ietfa.amsl.com> In-Reply-To: From: Dhruv Dhody Date: Wed, 22 Jul 2020 09:54:48 +0530 Message-ID: To: Alvaro Retana Cc: Alvaro Retana via Datatracker , The IESG , pce-chairs , draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org, pce@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Pce] Alvaro Retana's No Objection on draft-ietf-pce-stateful-pce-lsp-scheduling-19: (with COMMENT) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2020 04:25:02 -0000 Hi Huaimo, Alvaro, > > > (2) =C2=A74.1: "a PCE MUST synchronize to other PCEs within the network= ...Which > > way is used to achieve this is out of scope for this document." If the > > synchronization mechanism is out of scope, how can an implementation be > > compliant with this specification? IOW, if there's nothing to normative= ly > > refer to, then normative language shouldn't be used, or a mechanism sho= uld > > be mandated. In either case, because synchronization between the PCEs s= eems > > important for this specification, I would like to also see a discussion > > about the specific effects on LSP scheduling instead of the generic poi= nter > > to rfc7399. > > > > [HC]: The description related seems too broad. We have rephrased > > the related text to focus on the state of a scheduled LSP > > crossing multiple domains from an ingress domain to an egress domain. > ... > > > As mentioned separately...I think that changing the scenario is not a > good idea at this point. It also leaves the single domain case > unaddressed. > > I suggested making these changes in section 4.1 - In case of multiple PCEs within a single domain, the PCE would need to synchronize their scheduling information with other PCEs within the domain. This could be achieved by proprietary database synchronization techniques or via a possible PCEP extension [I-D.litkowski-pce-state-sync]. The technique used to synchronize SLSP-DB is out of scope for this document. Also, update section 4.3 with - o The stateful PCE MUST update its local scheduled LSP-DB and scheduled TED with the scheduled LSP and synchronize the scheduling information with other PCEs in the domain. > > > =C2=A74.3 says that the "stateful PCE...shall send a PCRpt message with= the > > scheduled LSP to other PCEs...to achieve...synchronization." Even thoug= h > > normative language is not used, the intent seems to specifically point = at > > using PCRpt messages for synchronization... > > > > Besides the confusing use of language, rfc8231 defines PCRpt as a "mess= age > > sent by a PCC to a PCE to report the current state of an LSP", but I di= dn't > > see where the use if defined between PCEs -- maybe I missed it. =C2=A76= .1 does > > reinforce that the "Path Computation State Report (PCRpt) is a PCEP mes= sage > > sent by a PCC to a PCE to report the status of one or more LSPs as per > > [RFC8231]....This message is also used to synchronize the scheduled LSP= s to > > other PCE as described in [RFC8231]". But this last point is what I can= 't > > find in rfc8231. > > > > [HC]: We have updated/cleaned the text related. > > The Path Computation State Report (PCRpt) is a PCEP message sent by > > a PCC to a PCE as per [RFC8231]. A PCE can act as a PCC to send a PCRpt > > message to another PCE. > > The "as described in [RFC8231]" text is still not accurate -- that > document doesn't talk about using the PCRpt message between PCEs. > > I don't think that the "PCE can act as a PCC" part is well defined. > Is it specified somewhere else? > In this case, the right reference is draft-litkowski-pce-state-sync to synchronize between PCEs using PCRpt/PCUpd. My suggestion would be to change the text in Section 6.1 (version -19) OLD: This message is also used to synchronize the scheduled LSPs to other PCE as described in [RFC8231] NEW: This message could also be used to synchronize the scheduled LSPs to other PCE as described in [I-D.litkowski-pce-state-sync]. END I can even live with removing the text completely. BTW, just for information - PCE acting as PCC and using PCReq message towards other PCEs goes back to RFC 5441. RFC 8751 has a child PCE acting as PCC and sending PCRpt messages to parent PCE. But that has no bearing on the fate of the above text. Thanks, Dhruv From nobody Wed Jul 22 04:00:42 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB743A078C; Wed, 22 Jul 2020 04:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 v5KU5k6KLrG7; Wed, 22 Jul 2020 04:00:32 -0700 (PDT) Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 848693A0780; Wed, 22 Jul 2020 04:00:32 -0700 (PDT) Received: by mail-wm1-x343.google.com with SMTP id 9so1521074wmj.5; Wed, 22 Jul 2020 04:00:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=qCyPqzS+f13jp8r5mdYJ2/hTMxuEcRe67bWcyzg2Dfw=; b=quZbmXlLMn71y/m3QURgYFGIFQHflcpQfrpVQAwstCBmZVAiAE6hkI09IF3FrrYMeA zdux7UuxEzB8GKh8b7X4a86mx5LEtbZoed+kaSA+qgn5cCdL7j/OlcOu/zpkGO3K1Noh I9xsqWtZtRbcrl9nHxaZmqATjES7DYAiMG29S7ABtB+eE3CNTLUIfdoIyQsNw0J2XFdx 5bQwmHwwGSiA1jBuAhbgLqAbTExHwhvDT10w8mTkrq2N90tUZs0GS858lfebuBxCvkou Tqh4FAebCzPvOLGnVZnlIGsMGXcZzb+SKAzcwYAf9B+0b8XY+Y0ag7ZZWSDtVf9IYgkB 6DDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=qCyPqzS+f13jp8r5mdYJ2/hTMxuEcRe67bWcyzg2Dfw=; b=PpIDUv7/vPxKepUjQ21X3EVTkGAozgKz58Cbc1f76dTIW1MrbtvQYSWcgNVowLiAc8 t3qTy+nQBjnNeM0mrsqnMtqia/wHl6dGQ9+hq3sFgstzBiPM/gWsF6q/JWDZ9IdCMOCA zDKB1LqHRpd5N1IaMi1xXpRFf7bbZQLAcLZmSUWIBF4M60vNs141difAT4/yiBZSeclN SeOefAxvVD6IKTsQjB8otJa0s/8KehtP07vQhCUq4g6FX1knpi4W10NdGfhU4idPhoIc ZgqqUJl4FMQDa5H63nCXQ+fgj5EuV6x4GHwzIf4byWMdJFLO4a5NLwbNe2sH8+ja7pJw tacQ== X-Gm-Message-State: AOAM531lVZnQqfBF3TUR8fZ2Wbq7ByrfvIKSqrPuq9lZ1mlmXfhRaSe4 L8IKJciwxfgvCEEGPjqY9tA5OVDWt05m9PHqycE= X-Google-Smtp-Source: ABdhPJzrmfZXfggFqtU9Vy5gMhh5SPBi5m/YhQpZ/UsyI1LIzGLeKcVnWSUqSO/SoKTAM6C56AlXksWnLQsA/ovNdcM= X-Received: by 2002:a7b:c2f7:: with SMTP id e23mr8027447wmk.175.1595415630029; Wed, 22 Jul 2020 04:00:30 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 22 Jul 2020 04:00:29 -0700 From: Alvaro Retana In-Reply-To: References: <159414709200.5178.3398442601733460072@ietfa.amsl.com> MIME-Version: 1.0 Date: Wed, 22 Jul 2020 04:00:29 -0700 Message-ID: To: Dhruv Dhody Cc: Alvaro Retana via Datatracker , pce-chairs , pce@ietf.org, The IESG , draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Pce] Alvaro Retana's No Objection on draft-ietf-pce-stateful-pce-lsp-scheduling-19: (with COMMENT) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2020 11:00:34 -0000 On July 22, 2020 at 12:25:00 AM, Dhruv Dhody wrote: Dhruv: Hi! ... > > > (2) =C2=A74.1: "a PCE MUST synchronize to other PCEs within the > > > network...Which way is used to achieve this is out of scope for this > > > document." If the synchronization mechanism is out of scope, how can > > > an implementation be compliant with this specification? IOW, if > > > there's nothing to normatively refer to, then normative language > > > shouldn't be used, or a mechanism should be mandated. In either case, > > > because synchronization between the PCEs seems important for this > > > specification, I would like to also see a discussion about the specif= ic > > > effects on LSP scheduling instead of the generic pointer to rfc7399. > > > > > > [HC]: The description related seems too broad. We have rephrased > > > the related text to focus on the state of a scheduled LSP > > > crossing multiple domains from an ingress domain to an egress domain. > > ... > > > > > > As mentioned separately...I think that changing the scenario is not a > > good idea at this point. It also leaves the single domain case > > unaddressed. > > > > > > I suggested making these changes in section 4.1 - > > In case of multiple PCEs within a single domain, the PCE would need > to synchronize their scheduling information with other PCEs > within the domain. This could be achieved by proprietary database > synchronization techniques or via a possible PCEP extension > [I-D.litkowski-pce-state-sync]. The technique used to synchronize > SLSP-DB is out of scope for this document. > > Also, update section 4.3 with - > > o The stateful PCE MUST update its local scheduled LSP-DB and > scheduled TED with the scheduled LSP and synchronize the > scheduling information with other PCEs in the domain. Those changes are ok. If no normative reference will be included, then I would still like to see a discussion about the effects of not synchronizing, in this specific case. =C2=A0The text in rfc7399 is general. > > > =C2=A74.3 says that the "stateful PCE...shall send a PCRpt message wi= th the > > > scheduled LSP to other PCEs...to achieve...synchronization." Even > > > though normative language is not used, the intent seems to > > > specifically point at using PCRpt messages for synchronization... > > > > > > Besides the confusing use of language, rfc8231 defines PCRpt as a > > > "message sent by a PCC to a PCE to report the current state of an LSP= ", > > > but I didn't see where the use if defined between PCEs -- maybe I > > > missed it. =C2=A76.1 does reinforce that the "Path Computation State = Report > > > (PCRpt) is a PCEP message sent by a PCC to a PCE to report the status > > > of one or more LSPs as per [RFC8231]....This message is also used to > > > synchronize the scheduled LSPs to other PCE as described in [RFC8231]= ". > > > But this last point is what I can't find in rfc8231. > > > > > > [HC]: We have updated/cleaned the text related. > > > The Path Computation State Report (PCRpt) is a PCEP message sent by > > > a PCC to a PCE as per [RFC8231]. A PCE can act as a PCC to send a PCR= pt > > > message to another PCE. > > > > The "as described in [RFC8231]" text is still not accurate -- that > > document doesn't talk about using the PCRpt message between PCEs. > > > > I don't think that the "PCE can act as a PCC" part is well defined. > > Is it specified somewhere else? > > > > In this case, the right reference is draft-litkowski-pce-state-sync to > synchronize between PCEs using PCRpt/PCUpd. This goes back to the initial point: should draft-litkowski-pce-state-sync be the normative reference? =C2=A0If not, then I think it is best to leave the details out. > My suggestion would be to change the text in Section 6.1 (version -19) > OLD: > This message is also used > to synchronize the scheduled LSPs to other PCE as described in > [RFC8231] > NEW: > This message could also be used > to synchronize the scheduled LSPs to other PCE as described in > [I-D.litkowski-pce-state-sync]. > END > > I can even live with removing the text completely. If removing it, since the suggestion above is not leave sync completely out of scope, then remove all other talk about PCRpt... > BTW, just for information - PCE acting as PCC and using PCReq message > towards other PCEs goes back to RFC 5441. RFC 8751 has a child PCE > acting as PCC and sending PCRpt messages to parent PCE. But that has > no bearing on the fate of the above text. No it doesn't. =C2=A0But if there is a reference to include... In the end, my interest here is for the specification to be complete. If sync is out of scope then leave it out -- and better discuss the effects of not properly sync'ing. =C2=A0If it can be specified here (or normatively pointed at), then please do it. =C2=A0:-) Thanks! Alvaro. From nobody Wed Jul 22 11:18:49 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 195B73A091F; Wed, 22 Jul 2020 11:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com 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 oZLY4x8a2FnI; Wed, 22 Jul 2020 11:18:44 -0700 (PDT) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2105.outbound.protection.outlook.com [40.107.223.105]) (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 3E4233A091E; Wed, 22 Jul 2020 11:18:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RL63i0XM+FEldSr05tzikl8QHeEfDIHuD8JMHwlSTHoo8b880SemqV8MFMbZ4ANPsuhw4TX/oz/GOO9BEUJ+Tkds7rhC5Cvcj1PseEmW0Wj4mfqo2/9oR9JVcNh0/kCSqdHezE6oEdzomDHPCt7k1MnSLf54UwJkT1xUjkud/82Sc7TlfWUCT860RAsQ4ULV6v2y6aJDUwIMarT8U98eCwK9CC1zdNYcJ3ZzO1uixD6dW475NOg0VUgl0vccPxZXa6VGl0S0k2kIGeafB2LP0aCjNsAE/MRwQAyHaam+HvH0yCMgPL7Qs6O41NG6+GYv8Ve2cAPVoPOHLb5v2u2bbw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=71gAbQaVZXW4jD2kXtZEuE4fqs9R54UI71Zzncu7HfU=; b=DN7yInbvwdmLZVcQTVhqP0IFOP9qA/o0Dbn8RPaIPB7GTZGtro/xHEGNlBKP09f7/GwEJsqsJzheNMT24+mJaArToKU/4hCGHh9N7v2MWN+NGIaoHk3zRGkqExwZ6ZBBpcjf+fKiNmVNM9eqeQqqHCWYB4jha5gtye8HUufY4208+dBaGmRuBq6Tu0Rz4i0ugkUQTjyu2DQsfMDh+pDTWch+lTjmrc+czeHS4AbpmlyPyLcL3mtzSi60Sk/heAAkJk0l2CMOSvgsURaNl93F37WRTrmcWpNZrWHN3nVKPq08P6sKNfklwXlA+pzu0v28NPWbc/CCMz8MsZbwdUlSPQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=71gAbQaVZXW4jD2kXtZEuE4fqs9R54UI71Zzncu7HfU=; b=mnFVVIX7+fEJyafHjvGld7w1K4nnNf7/hfucD4BT3WLigK0tasq/iDbDzHxY6KGbtVkkTkI2ukXGE4COqsKKpeH/aYfcmZFvL9ZLAqse7K2d10Gao2mudgqdIQrLSwIu2sLMcLirN0xgkZr5n+6KkXkvWyNaOgGoC1gnR8jol+k= Received: from MN2PR13MB3117.namprd13.prod.outlook.com (2603:10b6:208:13a::20) by MN2PR13MB3711.namprd13.prod.outlook.com (2603:10b6:208:1e3::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.18; Wed, 22 Jul 2020 18:18:42 +0000 Received: from MN2PR13MB3117.namprd13.prod.outlook.com ([fe80::bd0d:e70d:94e5:81e7]) by MN2PR13MB3117.namprd13.prod.outlook.com ([fe80::bd0d:e70d:94e5:81e7%7]) with mapi id 15.20.3216.020; Wed, 22 Jul 2020 18:18:42 +0000 From: Huaimo Chen To: Alvaro Retana , Alvaro Retana via Datatracker , The IESG CC: "pce-chairs@ietf.org" , "draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org" , "pce@ietf.org" Thread-Topic: [Pce] Alvaro Retana's No Objection on draft-ietf-pce-stateful-pce-lsp-scheduling-19: (with COMMENT) Thread-Index: AQHWVI3Xkb0zxFK8G0euXGvvDcHNd6kSQB8AgAG3j/8= Date: Wed, 22 Jul 2020 18:18:42 +0000 Message-ID: References: <159414709200.5178.3398442601733460072@ietfa.amsl.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=futurewei.com; x-originating-ip: [2601:199:4300:8e5a:f4d4:7dde:c8f6:9ec1] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ce70d76c-5969-47c2-1445-08d82e6baa4a x-ms-traffictypediagnostic: MN2PR13MB3711: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: B+37BrtvU1CS1z2M00o0KwMSY+fkmpyXIR2gumbpph2Iku4xZb0vZ8y4UY/1YZZUQojgEG2CVdGL+Ps5mkdOLpUbrbvh3bUOYZGZUUURuWqadtc5b+0mzX8ggWoHvKxnHV7CTkZAKbXHjjqqe8AedjWWGUEO/Vz4mjnY6wMQjWIMtlC7LZdb85h+63jZN9sTagypTwLHzdN+tCJYa+Kp0tiK3m57f3/dlqeVPQcgkVnfggQcbeESt9utT47VKZRnn/3jZPCoGCRKUPfhEIAg+QfKiuOf+wqIoejKuydL6L/Q9Z9WrpwIU85ZlP1Q/gTElK/cKWMn3L17VGG0UTA8fA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR13MB3117.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(366004)(39850400004)(396003)(136003)(376002)(9686003)(186003)(71200400001)(6506007)(4326008)(19627405001)(2906002)(7696005)(110136005)(53546011)(54906003)(52536014)(55016002)(316002)(478600001)(8676002)(8936002)(33656002)(66946007)(76116006)(83380400001)(86362001)(66476007)(64756008)(66446008)(66556008)(44832011)(5660300002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: qm/ocWcol1wtdd40YPtn0O3eV34s93JCRiI7DaGJtY4bsoxHbu1kbLYxm4Y/g3vjGqx8bUw8PrA+tVxHJ2WQTRGPRXT8RS/r2Bih8QdL1ZVKJq2ijDLtnCb/vNm2TCWhiLsc0G899AHGub2gbXCfJa1t+0te/UUJ2nHAuWj5BqqGOwsr0U8rWuoMCtQ3EelhswsGn1mpraiZf+b0EPG16HFmct+LPdan8cgYBgBZMKEKLQ+aFBbCqfB2gIhTkvSKUg9ZXcHYIZuunJm5QL6uZ/EXuC/cFV4zTscdp5Eb2RtqlbQuDxjCIjJpAMCaTJJJ4dMHTPJNW0pwKiluuS7r816D6CYA7itWaJy6cWRU1eH6rWmBS7pv1kw1MGGEHdtN/dzBbsuCJLEs724OPp8D9BdX97ZkbTPyyo7GdJBvcosHSsvQ5IXM8YgB76yExtqFmB+28vGGOc1OGW0PhdSj2oYIUSi+oZ447j1p6u7q8xSOc/2BRm4q+cIKz88rz3cxvwGHaEOXIVtfVEEgErpWaKRzt6mp4Z+OczBBSva8eGNdx9GcwbNl4tAEeq/CwHCm x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR13MB3117333366F91AEDF0B74FC1F2790MN2PR13MB3117namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR13MB3117.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ce70d76c-5969-47c2-1445-08d82e6baa4a X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2020 18:18:42.5045 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Lw8vPPK/M/8qSbFqkTkzGwZjtKc+w+33ytQU9hvjZ1f6n9zGZBcsDXDrs6jypPy/bG5GDXTLytbMTUDfYfY6zg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR13MB3711 Archived-At: Subject: Re: [Pce] Alvaro Retana's No Objection on draft-ietf-pce-stateful-pce-lsp-scheduling-19: (with COMMENT) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2020 18:18:46 -0000 --_000_MN2PR13MB3117333366F91AEDF0B74FC1F2790MN2PR13MB3117namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Alvaro, Thank you very much for your valuable comments. My answers/explanations are inline below with prefix [HC2]. Best Regards, Huaimo ________________________________ From: Alvaro Retana Sent: Tuesday, July 21, 2020 11:35 AM To: Alvaro Retana via Datatracker ; The IESG Cc: pce-chairs@ietf.org ; draft-ietf-pce-stateful-pce-= lsp-scheduling@ietf.org ; pce@ietf.org Subject: Re: [Pce] Alvaro Retana's No Objection on draft-ietf-pce-stateful-= pce-lsp-scheduling-19: (with COMMENT) On July 13, 2020 at 3:29:13 PM, Huaimo Chen wrote: Huaimo: Hi! ... > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > I think that this document still needs work before publication. I conside= r > the first 3 points below to be close to DISCUSS-worthy. > > (1) In general, it feels like an editorial pass is needed to tighten up t= he > language used as specification in this document. There are several places > where the language feels loose -- as an example (from =A74.4): ... > [HC]: We have updated the document according to rfc2119 as you suggested. Thanks for addressing this one instance. As I mentioned, there are other similar instances that would benefit from similar tightening up -- please reread through the document with an eye for "loose language". I trust that you will do the right thing. [HC2]: We will reread through the document carefully for "loose language" a= nd update it accordingly. > (2) =A74.1: "a PCE MUST synchronize to other PCEs within the network...Wh= ich > way is used to achieve this is out of scope for this document." If the > synchronization mechanism is out of scope, how can an implementation be > compliant with this specification? IOW, if there's nothing to normatively > refer to, then normative language shouldn't be used, or a mechanism shoul= d > be mandated. In either case, because synchronization between the PCEs see= ms > important for this specification, I would like to also see a discussion > about the specific effects on LSP scheduling instead of the generic point= er > to rfc7399. > > [HC]: The description related seems too broad. We have rephrased > the related text to focus on the state of a scheduled LSP > crossing multiple domains from an ingress domain to an egress domain. ... As mentioned separately...I think that changing the scenario is not a good idea at this point. It also leaves the single domain case unaddressed. [HC2]: We will update the text according to Dhruv's suggestion. > =A74.3 says that the "stateful PCE...shall send a PCRpt message with the > scheduled LSP to other PCEs...to achieve...synchronization." Even though > normative language is not used, the intent seems to specifically point at > using PCRpt messages for synchronization... > > Besides the confusing use of language, rfc8231 defines PCRpt as a "messag= e > sent by a PCC to a PCE to report the current state of an LSP", but I didn= 't > see where the use if defined between PCEs -- maybe I missed it. =A76.1 do= es > reinforce that the "Path Computation State Report (PCRpt) is a PCEP messa= ge > sent by a PCC to a PCE to report the status of one or more LSPs as per > [RFC8231]....This message is also used to synchronize the scheduled LSPs = to > other PCE as described in [RFC8231]". But this last point is what I can't > find in rfc8231. > > [HC]: We have updated/cleaned the text related. > The Path Computation State Report (PCRpt) is a PCEP message sent by > a PCC to a PCE as per [RFC8231]. A PCE can act as a PCC to send a PCRpt > message to another PCE. The "as described in [RFC8231]" text is still not accurate -- that document doesn't talk about using the PCRpt message between PCEs. I don't think that the "PCE can act as a PCC" part is well defined. Is it specified somewhere else? [HC2]: RFC 8751 has a child PCE acting as PCC and sending PCRpt messages to its parent PCE. > (3) This whole document is about scheduling LSPs, which would seem to req= uire > time synchronization. However, I found only one mention: "It is necessary= to > synchronize the clocks of the PCEs and PCCs when relative time is used." > Should this sentence use normative language? Is there a recommended way t= o > achieve time synchronization? This seems to be an important manageability > consideration that impacts network operations. > > [HC]: Yes. We have changed it to use normative language, and > recommended Network Time Protocol [RFC5905] for time synchronization. The reference should be Normative. [HC2]: We will move it to Normative References Thanks! Alvaro. --_000_MN2PR13MB3117333366F91AEDF0B74FC1F2790MN2PR13MB3117namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Alvaro,

    Thank you very much for your valuable comments.
    My answers/explanations are inline below with prefix [HC2].

Best Regards,
Huaimo
From: Alvaro Retana <are= tana.ietf@gmail.com>
Sent: Tuesday, July 21, 2020 11:35 AM
To: Alvaro Retana via Datatracker <noreply@ietf.org>; The IESG= <iesg@ietf.org>
Cc: pce-chairs@ietf.org <pce-chairs@ietf.org>; draft-ietf-pce-= stateful-pce-lsp-scheduling@ietf.org <draft-ietf-pce-stateful-pce-lsp-sc= heduling@ietf.org>; pce@ietf.org <pce@ietf.org>
Subject: Re: [Pce] Alvaro Retana's No Objection on draft-ietf-pce-st= ateful-pce-lsp-scheduling-19: (with COMMENT)
 
On July 13, 2020 at 3:29:13 PM, Huaimo Chen wrote:=


Huaimo:

Hi!



...
> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
> I think that this document still needs work before publication. I cons= ider
> the first 3 points below to be close to DISCUSS-worthy.
>
> (1) In general, it feels like an editorial pass is needed to tighten u= p the
> language used as specification in this document. There are several pla= ces
> where the language feels loose -- as an example (from =A74.4):
...
> [HC]: We have updated the document according to rfc2119 as you suggest= ed.

Thanks for addressing this one instance.  As I mentioned, there are other similar instances that would benefit from similar tightening up
-- please reread through the document with an eye for "loose
language".  I trust that you will do the right thing.

[HC2]: We will reread through the document carefully for "loose l= anguage" and 
update it accordingly.

> (2) =A74.1: "a PCE MUST synchronize to other PCEs within the netw= ork...Which
> way is used to achieve this is out of scope for this document." I= f the
> synchronization mechanism is out of scope, how can an implementation b= e
> compliant with this specification? IOW, if there's nothing to normativ= ely
> refer to, then normative language shouldn't be used, or a mechanism sh= ould
> be mandated. In either case, because synchronization between the PCEs = seems
> important for this specification, I would like to also see a discussio= n
> about the specific effects on LSP scheduling instead of the generic po= inter
> to rfc7399.
>
> [HC]: The description related seems too broad. We have rephrased
> the related text to focus on the state of a scheduled LSP
> crossing multiple domains from an ingress domain to an egress domain.<= br> ...


As mentioned separately...I think that changing the scenario is not a
good idea at this point.  It also leaves the single domain case
unaddressed.

[HC2]: We will update the text according to Dhruv's suggestion.

> =A74.3 says that the "stateful PCE...shall send a PCRpt message w= ith the
> scheduled LSP to other PCEs...to achieve...synchronization." Even= though
> normative language is not used, the intent seems to specifically point= at
> using PCRpt messages for synchronization...
>
> Besides the confusing use of language, rfc8231 defines PCRpt as a &quo= t;message
> sent by a PCC to a PCE to report the current state of an LSP", bu= t I didn't
> see where the use if defined between PCEs -- maybe I missed it. =A76.1= does
> reinforce that the "Path Computation State Report (PCRpt) is a PC= EP message
> sent by a PCC to a PCE to report the status of one or more LSPs as per=
> [RFC8231]....This message is also used to synchronize the scheduled LS= Ps to
> other PCE as described in [RFC8231]". But this last point is what= I can't
> find in rfc8231.
>
> [HC]: We have updated/cleaned the text related.
> The Path Computation State Report (PCRpt) is a PCEP message sent by > a PCC to a PCE as per [RFC8231]. A PCE can act as a PCC to send a PCRp= t
> message to another PCE.

The "as described in [RFC8231]" text is still not accurate -- tha= t
document doesn't talk about using the PCRpt message between PCEs.

I don't think that the "PCE can act as a PCC" part is well define= d.
Is it specified somewhere else?

[HC2]:  RFC 8751 has a child PCE acting as PCC and 
sending PCRpt messages to its parent PCE.

> (3) This whole document is about scheduling LSPs, which would seem to = require
> time synchronization. However, I found only one mention: "It is n= ecessary to
> synchronize the clocks of the PCEs and PCCs when relative time is used= ."
> Should this sentence use normative language? Is there a recommended wa= y to
> achieve time synchronization? This seems to be an important manageabil= ity
> consideration that impacts network operations.
>
> [HC]: Yes. We have changed it to use normative language, and
> recommended Network Time Protocol [RFC5905] for time synchronization.<= br>
The reference should be Normative.

[HC2]: We will move it to Normative References

Thanks!

Alvaro.
--_000_MN2PR13MB3117333366F91AEDF0B74FC1F2790MN2PR13MB3117namp_-- From nobody Wed Jul 22 11:27:18 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37D463A077A; Wed, 22 Jul 2020 11:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com 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 hkiuzljzSgCU; Wed, 22 Jul 2020 11:27:09 -0700 (PDT) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2116.outbound.protection.outlook.com [40.107.223.116]) (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 55C383A05AC; Wed, 22 Jul 2020 11:27:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EwwyzpFufGw7uGrV6hlrZ5w6+j14CHL0Xt7S3eMKVgMv6+feRAf6dgbfjDjY/4lEPJyfazCrn6QLNSzXFlKLIUDtvN6NSj5Z/iKgPgSfXQlqnXWVSaW0BS6VgbXCZkCtLw6tOcsnZN3r666tEXQwGuS5P7wuiPOH0syRRUL85MfLHfdgNcu5Ygj1zNRkyZIEz09RdYTGFf/h3KRnXWhDSXmj4uvjLoiCyp/GkxFjqAvp/2UTW2aVFOgA3IVmpJA8/0/X+2Rj4N8PEEB1GMnf2Kiut5OR6YD/01/qILzMrjoJdY4kVjKrX6jYVZo1MO9koQZRJpoHPeE01hd7jLFm4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fnbBJOQ3gO04NHVSOZ9abq3fF4xgJWcssYih2qtEvA4=; b=EQQxm/Zt33EKmSXzK2eyNBSA6IP7HuCYoE4dENhyw2msw+CnaZUAooGRnN5+SH5uUEz2JjVPUUiXpclyA9vMeWE970dnmDc2hVlhoY0lO90f2E5ACmmDQOl4PNOsOSOiNvK+wZxDjzoxBYsJe5sKGFZPAYyd6eYUGXklKtzntfraTvsRYznJi8mFHleEunCl0NIbIO1IyHooHADLV3PRO3nOvFjr+c2h5PMJ1Bom0Vox0hNlW+rLbSL7zCWxhyQ33nH6JOfy76nfCWdfSWQQZNjp5sHRbHiRidrOTcPjtlHCh7hE95IAjJfMqOpMGiKRxnsDu1jFEv4BJrfm7o5Udg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fnbBJOQ3gO04NHVSOZ9abq3fF4xgJWcssYih2qtEvA4=; b=uLoeC9w4PbdoBYyVGjdHQA8/l7psrG5u1TLjFdAmBqeIujhrPfhz5t1tJf//NALtTzaff2Pbu4XxVf+74udKHJ/ce9VvL1STrsOeYOb3+iHS9c6rXziEpCOdnBVleqAhqkPSTS9Ohw8eJh3o8rvG5VMALcGo9oROvsQlUy/bYws= Received: from MN2PR13MB3117.namprd13.prod.outlook.com (2603:10b6:208:13a::20) by MN2PR13MB3216.namprd13.prod.outlook.com (2603:10b6:208:13b::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.14; Wed, 22 Jul 2020 18:27:06 +0000 Received: from MN2PR13MB3117.namprd13.prod.outlook.com ([fe80::bd0d:e70d:94e5:81e7]) by MN2PR13MB3117.namprd13.prod.outlook.com ([fe80::bd0d:e70d:94e5:81e7%7]) with mapi id 15.20.3216.020; Wed, 22 Jul 2020 18:27:06 +0000 From: Huaimo Chen To: Dhruv Dhody , Alvaro Retana CC: Alvaro Retana via Datatracker , The IESG , pce-chairs , "draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org" , "pce@ietf.org" Thread-Topic: [Pce] Alvaro Retana's No Objection on draft-ietf-pce-stateful-pce-lsp-scheduling-19: (with COMMENT) Thread-Index: AQHWVI3Xkb0zxFK8G0euXGvvDcHNd6kSQB8AgADW1wCAAOmtsQ== Date: Wed, 22 Jul 2020 18:27:05 +0000 Message-ID: References: <159414709200.5178.3398442601733460072@ietfa.amsl.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dhruvdhody.com; dkim=none (message not signed) header.d=none;dhruvdhody.com; dmarc=none action=none header.from=futurewei.com; x-originating-ip: [2601:199:4300:8e5a:f4d4:7dde:c8f6:9ec1] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5d348ad4-4a8c-4578-84c5-08d82e6cd656 x-ms-traffictypediagnostic: MN2PR13MB3216: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 9ul9Nv8EaFLFoz1/BW0Frq6+npvnxo2zP6b3qlWdvqGejM2YDUR5yAqiqk05uWh9klGLiRoyO35lgEIzSjaw3DQle7BOMokdw3biNkkALhhB3VW3y424mx6uKx42+d4r0eIv1D3rhMyvMztnaZ0N5vXrurM+O7ALL5VeeJlFES+7N1gX9HTrSg4msTONuU+TCnnHCDcEABrZUB9MuCRhdJp01FtZOI4R4kN/tSFe1pu+/JldjW4e5ygVfF3C1JxDbi0KZnN9sViCcsIIlTFpanWBp5dcNBTmqtvxVa6u9K20guto64iXcZOqvKnhk9ZwCFKnGIy1rTuGD+qL9+mQ+Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR13MB3117.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(366004)(346002)(396003)(39850400004)(376002)(8936002)(316002)(9686003)(5660300002)(86362001)(7696005)(2906002)(186003)(71200400001)(8676002)(478600001)(83380400001)(4326008)(110136005)(66556008)(66476007)(33656002)(66946007)(64756008)(66446008)(76116006)(55016002)(54906003)(44832011)(53546011)(6506007)(19627405001)(52536014); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: YFjjYNBLeDuttQzx+0GEQI4uYxHZaO9oWbCCJmMtmNWgDQs01b2wwOju6KNtIgOtUe3GPqY3uI2wHi6p78XutO62+lv3I/dx5GYpuGrYvVErNSF2nwkyAiKjHLkAaEC17ouqmOFmWiQ5LKiI3e0MWTu9+ELq/G3ZiyYex13IxuJsidk/1l93fJmuYF15jWHwWOyTXzVgeaOpK+Q5igcHyiZ/JDBZ29VYaP0KCK4CzdklAm/K41U1kdAQB6Gif8Xp/+YXzynKMHtJmQWNDYwWKzsJ7VUUKg6IC5h9MrvDAOM3wG0vOgaXOhzm1z+BQOlJZ5mSw00s5APCsd50cNbe8Ue0QqpaCdhWuewOTeq7QY9nAbCynVpjBff9zKxVIkaDbm4eRUZXIh39z6n2Ct8a+ADRFUaX8pPEW1AVzP5ptzxR8RNlrq703IIjRllyVgQVvg4NP3VWyzBoR/ttLhdt0NkrElKA9os2Zr7u7mKwRt1PeZsLWMbNHvvlBlbjy/9XXBfzaYTw4YAettEqiRvBBnlEirqrFlkEQRrfQEYfXjWB5LPfFJZKGYb15t41cGHL x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR13MB3117AE60D6774BC1ABB65DF0F2790MN2PR13MB3117namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR13MB3117.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5d348ad4-4a8c-4578-84c5-08d82e6cd656 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2020 18:27:05.8576 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: T4wSmVrLwp0irqLw4Bg9XlWYpV9e4nW6/yObwB/4OFG3XxLgGGkXV7kMyXf4fu1VM0oPC1ehh+aqxdtWPegQMA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR13MB3216 Archived-At: Subject: Re: [Pce] Alvaro Retana's No Objection on draft-ietf-pce-stateful-pce-lsp-scheduling-19: (with COMMENT) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2020 18:27:11 -0000 --_000_MN2PR13MB3117AE60D6774BC1ABB65DF0F2790MN2PR13MB3117namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Dhruv, Thank you very much for your valuable suggestions. We will update the document accordingly. Details are inline below with = prefix [HC2]. Best Regards, Huaimo ________________________________ From: Dhruv Dhody Sent: Wednesday, July 22, 2020 12:24 AM To: Alvaro Retana Cc: Alvaro Retana via Datatracker ; The IESG ; pce-chairs ; draft-ietf-pce-stateful-pce-lsp-sche= duling@ietf.org ; pce@= ietf.org Subject: Re: [Pce] Alvaro Retana's No Objection on draft-ietf-pce-stateful-= pce-lsp-scheduling-19: (with COMMENT) Hi Huaimo, Alvaro, > > > (2) =A74.1: "a PCE MUST synchronize to other PCEs within the network...= Which > > way is used to achieve this is out of scope for this document." If the > > synchronization mechanism is out of scope, how can an implementation be > > compliant with this specification? IOW, if there's nothing to normative= ly > > refer to, then normative language shouldn't be used, or a mechanism sho= uld > > be mandated. In either case, because synchronization between the PCEs s= eems > > important for this specification, I would like to also see a discussion > > about the specific effects on LSP scheduling instead of the generic poi= nter > > to rfc7399. > > > > [HC]: The description related seems too broad. We have rephrased > > the related text to focus on the state of a scheduled LSP > > crossing multiple domains from an ingress domain to an egress domain. > ... > > > As mentioned separately...I think that changing the scenario is not a > good idea at this point. It also leaves the single domain case > unaddressed. > > I suggested making these changes in section 4.1 - In case of multiple PCEs within a single domain, the PCE would need to synchronize their scheduling information with other PCEs within the domain. This could be achieved by proprietary database synchronization techniques or via a possible PCEP extension [I-D.litkowski-pce-state-sync]. The technique used to synchronize SLSP-DB is out of scope for this document. Also, update section 4.3 with - o The stateful PCE MUST update its local scheduled LSP-DB and scheduled TED with the scheduled LSP and synchronize the scheduling information with other PCEs in the domain. [HC2]: We will update the related text as you suggested. > > > =A74.3 says that the "stateful PCE...shall send a PCRpt message with th= e > > scheduled LSP to other PCEs...to achieve...synchronization." Even thoug= h > > normative language is not used, the intent seems to specifically point = at > > using PCRpt messages for synchronization... > > > > Besides the confusing use of language, rfc8231 defines PCRpt as a "mess= age > > sent by a PCC to a PCE to report the current state of an LSP", but I di= dn't > > see where the use if defined between PCEs -- maybe I missed it. =A76.1 = does > > reinforce that the "Path Computation State Report (PCRpt) is a PCEP mes= sage > > sent by a PCC to a PCE to report the status of one or more LSPs as per > > [RFC8231]....This message is also used to synchronize the scheduled LSP= s to > > other PCE as described in [RFC8231]". But this last point is what I can= 't > > find in rfc8231. > > > > [HC]: We have updated/cleaned the text related. > > The Path Computation State Report (PCRpt) is a PCEP message sent by > > a PCC to a PCE as per [RFC8231]. A PCE can act as a PCC to send a PCRpt > > message to another PCE. > > The "as described in [RFC8231]" text is still not accurate -- that > document doesn't talk about using the PCRpt message between PCEs. > > I don't think that the "PCE can act as a PCC" part is well defined. > Is it specified somewhere else? > In this case, the right reference is draft-litkowski-pce-state-sync to synchronize between PCEs using PCRpt/PCUpd. My suggestion would be to change the text in Section 6.1 (version -19) OLD: This message is also used to synchronize the scheduled LSPs to other PCE as described in [RFC8231] NEW: This message could also be used to synchronize the scheduled LSPs to other PCE as described in [I-D.litkowski-pce-state-sync]. END I can even live with removing the text completely. [HC2]: We will remove the text completely. BTW, just for information - PCE acting as PCC and using PCReq message towards other PCEs goes back to RFC 5441. RFC 8751 has a child PCE acting as PCC and sending PCRpt messages to parent PCE. But that has no bearing on the fate of the above text. [HC2]: Thanks much for the information. Thanks, Dhruv --_000_MN2PR13MB3117AE60D6774BC1ABB65DF0F2790MN2PR13MB3117namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Dhruv,

    Thank you very much for your valuable suggesti= ons.
    We will update the document accordingly. Details are inline b= elow with prefix [HC2].

Best Regards,
Huaimo
From: Dhruv Dhody <dd@dh= ruvdhody.com>
Sent: Wednesday, July 22, 2020 12:24 AM
To: Alvaro Retana <aretana.ietf@gmail.com>
Cc: Alvaro Retana via Datatracker <noreply@ietf.org>; The IESG= <iesg@ietf.org>; pce-chairs <pce-chairs@ietf.org>; draft-ietf-= pce-stateful-pce-lsp-scheduling@ietf.org <draft-ietf-pce-stateful-pce-ls= p-scheduling@ietf.org>; pce@ietf.org <pce@ietf.org>
Subject: Re: [Pce] Alvaro Retana's No Objection on draft-ietf-pce-st= ateful-pce-lsp-scheduling-19: (with COMMENT)
 
Hi Huaimo, Alvaro,

<snip>
>
> > (2) =A74.1: "a PCE MUST synchronize to other PCEs within the= network...Which
> > way is used to achieve this is out of scope for this document.&qu= ot; If the
> > synchronization mechanism is out of scope, how can an implementat= ion be
> > compliant with this specification? IOW, if there's nothing to nor= matively
> > refer to, then normative language shouldn't be used, or a mechani= sm should
> > be mandated. In either case, because synchronization between the = PCEs seems
> > important for this specification, I would like to also see a disc= ussion
> > about the specific effects on LSP scheduling instead of the gener= ic pointer
> > to rfc7399.
> >
> > [HC]: The description related seems too broad. We have rephrased<= br> > > the related text to focus on the state of a scheduled LSP
> > crossing multiple domains from an ingress domain to an egress dom= ain.
> ...
>
>
> As mentioned separately...I think that changing the scenario is not a<= br> > good idea at this point.  It also leaves the single domain case > unaddressed.
>
>

I suggested making these changes in section 4.1 -

   In case of multiple PCEs within a single domain, the PCE would= need
   to synchronize their scheduling information with other PCEs    within the domain. This could be achieved by proprietary datab= ase
   synchronization techniques or via a possible PCEP extension    [I-D.litkowski-pce-state-sync]. The technique used to synchron= ize
   SLSP-DB is out of scope for this document.

Also, update section 4.3 with -

   o  The stateful PCE MUST update its local scheduled LSP-D= B and
      scheduled TED with the scheduled LSP and syn= chronize the
      scheduling information with other PCEs in th= e domain.

[HC2]: We will update the related text as you suggested.

>
> > =A74.3 says that the "stateful PCE...shall send a PCRpt mess= age with the
> > scheduled LSP to other PCEs...to achieve...synchronization."= Even though
> > normative language is not used, the intent seems to specifically = point at
> > using PCRpt messages for synchronization...
> >
> > Besides the confusing use of language, rfc8231 defines PCRpt as a= "message
> > sent by a PCC to a PCE to report the current state of an LSP"= ;, but I didn't
> > see where the use if defined between PCEs -- maybe I missed it. = =A76.1 does
> > reinforce that the "Path Computation State Report (PCRpt) is= a PCEP message
> > sent by a PCC to a PCE to report the status of one or more LSPs a= s per
> > [RFC8231]....This message is also used to synchronize the schedul= ed LSPs to
> > other PCE as described in [RFC8231]". But this last point is= what I can't
> > find in rfc8231.
> >
> > [HC]: We have updated/cleaned the text related.
> > The Path Computation State Report (PCRpt) is a PCEP message sent = by
> > a PCC to a PCE as per [RFC8231]. A PCE can act as a PCC to send a= PCRpt
> > message to another PCE.
>
> The "as described in [RFC8231]" text is still not accurate -= - that
> document doesn't talk about using the PCRpt message between PCEs.
>
> I don't think that the "PCE can act as a PCC" part is well d= efined.
> Is it specified somewhere else?
>

In this case, the right reference is draft-litkowski-pce-state-sync to
synchronize between PCEs using PCRpt/PCUpd.

My suggestion would be to change the text in Section 6.1 (version -19)
OLD:
   This message is also used
   to synchronize the scheduled LSPs to other PCE as described in=
   [RFC8231]
NEW:
   This message could also be used
   to synchronize the scheduled LSPs to other PCE as described in=
   [I-D.litkowski-pce-state-sync].
END

I can even live with removing the text completely.

[HC2]: We will remove the text completely.

BTW, just for information - PCE acting as PCC and using PCReq message
towards other PCEs goes back to RFC 5441. RFC 8751 has a child PCE
acting as PCC and sending PCRpt messages to parent PCE. But that has
no bearing on the fate of the above text.

[HC2]: Thanks much for the information.

Thanks,
Dhruv
--_000_MN2PR13MB3117AE60D6774BC1ABB65DF0F2790MN2PR13MB3117namp_-- From nobody Sun Jul 26 04:53:55 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00C403A0DD3; Sun, 26 Jul 2020 04:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 pA6gcTF0NtaK; Sun, 26 Jul 2020 04:53:49 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57FEF3A0DD2; Sun, 26 Jul 2020 04:53:46 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id e64so14136364iof.12; Sun, 26 Jul 2020 04:53:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=p3neefiOagbSosMMAxfEznJzDeARSFF2Jzr9EMGllxY=; b=s7Snq838YcEAEQEf/FSde6HbGhItBSlDt9tt8GUA5eabJ/OCzWHAxzhXnqF7n6myDf 26HiLrXuYEionHugHMI2Kq/eDqNJOKrWD6ZKml8gKs42vII3V6banRw1JEtFEMIRY8N9 i/kgRDJlUaKdm6bhB+D6BPyGb7FRROKJ8qISQJ7FNcGugB7iOpUwQcm64jklHt0oHvnm xeYpGjznhqOf/81ZwgPvjqbOReMihUzXSYEU3tGi5lckr3OZF5xyqhT3r3QZ+KJDO0Kx rpS9D6Djb5C+CTwMKXVtW9G/hXts2Yg/IQVhHf6H6/s8JYEsu+3/oAQNtvFs3UXhqnHk RhjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=p3neefiOagbSosMMAxfEznJzDeARSFF2Jzr9EMGllxY=; b=J/QmhH3likTX4AGP4niW8v8lVGkC+TWOf1q1Ls9lW0hI46zySDN2dOJBscvvTkJY7C 3foxgUewsQrNn19115GhUkmtmhHyz6Yvx3SvRpAgwGi18N7YyoB7JEaE/TBgFIcPllzs DugCDppjb9LX82CetjQCA5moXzte/nDIX7jajb/c6jruX5L3reNZjq4RYVBIawTK8SzY 2qHV1vqv8TPaOu+OAkbCnKK28FmgVe/EYl8SAzz1ed+3GwrOoOfgQ3/UZGwz6XdeHMjt sSeByLslro5kKR55+avS/fPElcnsKKLROhlx2JN/QgthvxvcnwvlHE2hbOrwpLZUk0nP cAAQ== X-Gm-Message-State: AOAM531ac0jGkRC03875hdBV9Z0TFJv3REowP2jtjH0VP9EwvA5vFYyK 59YiSvNOREJxjtPr8xps3E9P4cWNjcF3fNjYUf4= X-Google-Smtp-Source: ABdhPJxev3ar80l3HkFbPG+G9P08oSTB5rajU/Jk2GJ9K0FiUJtQUV7iph7SIxdXCDb2WLtP2OQfdnCScPwIRcbPPCc= X-Received: by 2002:a05:6602:1610:: with SMTP id x16mr12494455iow.68.1595764425298; Sun, 26 Jul 2020 04:53:45 -0700 (PDT) MIME-Version: 1.0 References: <159438406431.12133.11734833260610050043@ietfa.amsl.com> <0b290b63152b4448a950b291b5960fb3@huawei.com> In-Reply-To: <0b290b63152b4448a950b291b5960fb3@huawei.com> From: Dhruv Dhody Date: Sun, 26 Jul 2020 17:23:08 +0530 Message-ID: To: Giuseppe Fioccola Cc: "pce@ietf.org" , "draft-chen-pce-sr-policy-ifit@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Pce] FW: New Version Notification for draft-chen-pce-sr-policy-ifit-02.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2020 11:53:53 -0000 Hi Giuseppe, Thanks for letting the WG know about your I-D. I have some suggestions to improve this I-D - (0) Can these TLVs be carried inside the LSPA object, and allow the IFIT to be used for all paths (including SR, SRv6, RSVP-TE, PCECC, etc). I understand that your key case is with SR-Policy but it is better to put the TLVs in a generic object rather than in an SR specific one. I am guessing you might be influenced by BGP SR Policy (where it makes sense to limit it to SR-Policy as BGP is used only for SR-Policy) but in the case of PCEP, making it generic is a better idea IMHO. (1) Add capability exchange between PCEP speakers by adding a flag in SR-PCE-CAPABILITY Sub-TLV. PCE WG has a long history of explicit capability exchange in open before using new features. (2) You need to re-write section 5.1, it does not come across as an example - it describes some new procedure to handle SR Policy that is not aligned with the rest of PCE documents. I suggest adding an example figure with a PCInitiate message from PCE to PCC carrying the SR Policy/Candidate Path/IFIT attributes to explain the flow with an example. (3) The document is light on motivation, you say "So that IFIT behavior can be enabled automatically when the SR policy is applied". I wish you can expand on this a little more. Something on lines of - When a PCE is used to initiate paths using PCEP, it is important that the head end of the path also understands the IFIT behavior that is intended for the path. When PCEP is in use for path initiation it makes sense for that same protocol to be used to also carry the IFIT attributes that describe the IOAM header/procedure that needs to be applied to the data that flow those paths. (4) Only one of these TLVs can be enabled right? This needs to be described. Also, add text to describe disabling of IFIT or making changes. Some tightening of the procedure is needed here. (5) PCE would need to maintain the uniqueness of Flow ID, FlowMonID etc. This can be highlighted with a reference to other I-Ds that describe the procedure. (6) It would be good to also point to the registries created by other documents that we would be re-using. I hope you find this useful. I would encourage the WG to provide their thoughts as well. Thanks! Dhruv On Fri, Jul 10, 2020 at 8:21 PM Giuseppe Fioccola wrote: > > Dear All, > We have recently updated draft-chen-pce-sr-policy-ifit. It aims to define the Extensions to PCEP to enable automatically IOAM and Alternate Marking when the SR policy is applied. In particular we have clarified better the PCEP usage in this scenario. > > Feedbacks and suggestions are always welcome. > > Best Regards, > > Giuseppe > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Friday, July 10, 2020 2:28 PM > To: Giuseppe Fioccola ; Hang Yuan ; Huanan Chen ; wangyali ; Liweidong (Poly) ; Tianran Zhou > Subject: New Version Notification for draft-chen-pce-sr-policy-ifit-02.txt > > > A new version of I-D, draft-chen-pce-sr-policy-ifit-02.txt > has been successfully submitted by Giuseppe Fioccola and posted to the IETF repository. > > Name: draft-chen-pce-sr-policy-ifit > Revision: 02 > Title: PCEP SR Policy Extensions to Enable IFIT > Document date: 2020-07-10 > Group: Individual Submission > Pages: 12 > URL: https://www.ietf.org/internet-drafts/draft-chen-pce-sr-policy-ifit-02.txt > Status: https://datatracker.ietf.org/doc/draft-chen-pce-sr-policy-ifit/ > Htmlized: https://tools.ietf.org/html/draft-chen-pce-sr-policy-ifit-02 > Htmlized: https://datatracker.ietf.org/doc/html/draft-chen-pce-sr-policy-ifit > Diff: https://www.ietf.org/rfcdiff?url2=draft-chen-pce-sr-policy-ifit-02 > > Abstract: > Segment Routing (SR) policy is a set of candidate SR paths consisting > of one or more segment lists and necessary path attributes. It > enables instantiation of an ordered list of segments with a specific > intent for traffic steering. In-situ Flow Information Telemetry > (IFIT) refers to network OAM applications that apply dataplane on- > path telemetry techniques. This document defines extensions to PCEP > to distribute SR policies carrying IFIT information. So that IFIT > behavior can be enabled automatically when the SR policy is applied. > > > > > > 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 > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From nobody Sun Jul 26 04:55:55 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA7F83A0DD7; Sun, 26 Jul 2020 04:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 MKFo65czqqRY; Sun, 26 Jul 2020 04:55:47 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 387BC3A0DD5; Sun, 26 Jul 2020 04:55:46 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id z6so14188827iow.6; Sun, 26 Jul 2020 04:55:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=fso11mlfZmxlC45fdWgJKFTyE/+e2mJxdYs0i7ULcdQ=; b=Ap4QoxfIVCJTwyCv1b7beXs6cfVOr7c2LmQ4MEpqdtQN9mwVDIrrZWzoXVXFTWl1nL VVy1gJCrOQYut2gtxormJd5GgUZ6Nr7gbx9oyt60mOvtgPXtSMjFHtL28ow8Aa8F5FQ6 Z+xM18u5N+c0+00QpFYlIG3dwGzC0N4Cfegy8yXfc9WP/OegK5Umodv4S4i+6kHHe6am MVf+/nPM6khgD5be0NzzQHaf1aHkoIDkBtgUaHDQk/+WEZmS9TJlgVord2jlYjLyAPNh q1qdSUdCs8jNoTaXZEuQZ8pwAwpL3BCyLgZPDrSlbjXjdJ0f/+sSlvqCOqI6tOQxrHFw chFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=fso11mlfZmxlC45fdWgJKFTyE/+e2mJxdYs0i7ULcdQ=; b=sgvYHUEKWlmaP02rdNAXOM68+F4guy0C59EvqmvA/nuH+p0/EA/xdxvlcRIPw+vQm1 nQl825wbv0Zwb3jInJTrlndeChEjy+m9H38t1l+S1Ta6Hd25MLR0Pqh/BHyJBMDQG341 PZUHSrpUgCUK19h6mq1Keim315pHjYQtR8CCsJ/nnZDzvnNC09ayhPOPZS2r6uz5QZgP hDPk770LgljFl2Qs9qlpajnTmVBFEUxXYG8SnSbLtPHTtFOQUgNMwupa5KpjFM1pRZSu A+vyxFDLft3oQwzV9EseAxirbJhruGzQbc+Beot76iab0oQIOLaI3Gm7siOikeeah7iy eJnQ== X-Gm-Message-State: AOAM530bdagUA228e3gbLK4qJXoX/0Cb5Jj6B9Sk0YkFHFVcTHkuKghf e7Mu7/9tgG1flVxFTIarx3MyBP2ubdMJbBzmRy/51BMX6vI= X-Google-Smtp-Source: ABdhPJyOygkdkV4m9Lok/AiJgDCBN+pVhGGAguEuJ6fQdzs733dQUeQcPXkVshZtOYxn7G2xGc6/1ZazsQQ9MB583hk= X-Received: by 2002:a6b:6c09:: with SMTP id a9mr19029493ioh.178.1595764545541; Sun, 26 Jul 2020 04:55:45 -0700 (PDT) MIME-Version: 1.0 From: Dhruv Dhody Date: Sun, 26 Jul 2020 17:25:09 +0530 Message-ID: To: draft-peng-pce-entropy-label-position@ietf.org, slitkows.ietf@gmail.com Cc: pce@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Pce] A pending item for draft-peng-pce-entropy-label-position X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2020 11:55:53 -0000 Hi Authors, Stephane, In the last meeting [1], Stephane mentioned that the PCE is unaware of the PCC's capability to push ELI/EL pairs and thus questioned the usability of your I-D. He mentioned that existing information in IGP/BGP-LS i.e. MSD, ELC, ERLD does not tell the PCC's capability to push ELI/EL pairs. The current draft has a single bit ELP - A PCC sets this flag to 1 to indicate that it supports the capability of inserting multiple ELI/EL pairs and and supports the results of SR path with ELP from PCE. I want to confirm if this bit and BMI-MSD enough? If not, what else? It would be good if this can be discussed here or during the meeting. Thanks! Dhruv [1] https://datatracker.ietf.org/doc/minutes-106-pce/ From nobody Sun Jul 26 05:06:55 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4863A0DE5 for ; Sun, 26 Jul 2020 05:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 k-KYYzOaD2iT for ; Sun, 26 Jul 2020 05:06:52 -0700 (PDT) Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E7CF3A0DE4 for ; Sun, 26 Jul 2020 05:06:52 -0700 (PDT) Received: by mail-il1-x12e.google.com with SMTP id i138so4892575ild.9 for ; Sun, 26 Jul 2020 05:06:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=yrRvciQWUuG+GmENQwqTOtyy9EWT4vsycTxseg+N0Hk=; b=hx2sF8xybVbcZ5Z1iAB1ayS1jTgnUqQfYAMlFhcGCIc1YxGwdEiuIAC+WP626trugf Gqmpkz2AKgR4ch6KKVRiTHR8+4YeHMtt6+68+whOpQgX7EnnCHvRgd3pSlpSvm/Zzo/Y 4bCwAAEG8pJ3wHwhYgF9nY+Nwu3MuROzOd1j3tDB7hBTSmX0zu1/zUBSllLVKqbJT5rO D+K/GeOfXFA90ErR4lAvWvhdEwkVcFuzUXXvKFw8NDA9mJ008gs9b6Da4W1w8JPJK2UX o8tLnO4Jah3UtxIniC6O2uMKXM1LaRJAbvfO3MBI8y1OZKcmjXtSzYHfykTgAoetOZRN iRWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=yrRvciQWUuG+GmENQwqTOtyy9EWT4vsycTxseg+N0Hk=; b=l+h2mX+40fxkenhZNfhLFp9oS0I18E65Ppv3a4ti44NutHWHyFVWQgEcHFP2HRGLpe X1Ry3A2/r9iqtSWjspqyOHkGuehKywJDbFLojCA8n/GZ9N7T9b/E/h0PIpCERkmY5/gy hA9zvbmeoDgOzI3OBzEhDGH4+MP/Oc8ksg381n82S1Gva/s3LmxzeM8QErYNXBr0fplz AeedDFK+MHTqc+c6/j4jykhY7zkZu6xe3iuIpm6NGUQpECkyLtIxLODa1sZWGCT422d0 8DkucZvvlshn1GSsdr8mQ0sDejoJkNEByBp20V8AzfRgEyUDs9JwSc4/itUkPZvPwE/w 5gNw== X-Gm-Message-State: AOAM533+RIMG33MlptTVSudBEFOWnAipedoXqVjf1UCpM1801yNN39gM V+MaluKmE/wcIyLZZxeQ2x1i/rtgNbVP7ocQFyM= X-Google-Smtp-Source: ABdhPJwNh4WwrECQjyI6i+d29zmIZPBf4FKpJ69F2RKnklufkeyEjFiR5i4e2fJuRYE2ldXUBFAlRxm9ufoCIezGznc= X-Received: by 2002:a92:c087:: with SMTP id h7mr18016282ile.279.1595765211165; Sun, 26 Jul 2020 05:06:51 -0700 (PDT) MIME-Version: 1.0 References: <158316673618.27361.7017725094379697473@ietfa.amsl.com> In-Reply-To: From: Dhruv Dhody Date: Sun, 26 Jul 2020 17:36:14 +0530 Message-ID: To: "Stone, Andrew (Nokia - CA/Ottawa)" Cc: "pce@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Pce] FW: New Version Notification for draft-stone-pce-local-protection-enforcement-00.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2020 12:06:54 -0000 Hi Andrew, Do you think an update to RFC 5440 is required (with meta-data set in the document header)? Based on the description of the flag field it feels like an update would be needed - o L flag: As defined in [RFC5440] and further updated by this document. When set, protection is desired. When not set, protection is not desired. The enforcement of the protection is identified via the E-Flag. BTW, thanks for section 4 it helps! Maybe add an explicit backward compatibility section. Consider a PCC that supports your extension, and sets the E flag to 1 and a PCE that does not support your extension will ignore it and behave as before and thus not enforce local protection, and there would be no way for the PCC to know about it! Not sure if we need some sort of capability exchange here? Thanks! Dhruv On Fri, Mar 6, 2020 at 10:45 PM Stone, Andrew (Nokia - CA/Ottawa) wrote: > > Hi PCE WG, > > This draft was updated to include the following: > > - Draft renamed to reflect this is for "local" protection enforcement (us= ed to be called path-protection) > - new co author > - Added more text regarding the various use cases / why a user may want t= hese options > - Added text discussing situations of no preference / "no not care" > > Thanks > Andrew > > > > =EF=BB=BFOn 2020-03-02, 11:32 AM, "internet-drafts@ietf.org" wrote: > > > A new version of I-D, draft-stone-pce-local-protection-enforcement-00= .txt > has been successfully submitted by Andrew Stone and posted to the > IETF repository. > > Name: draft-stone-pce-local-protection-enforcement > Revision: 00 > Title: Local Protection Enforcement in PCEP > Document date: 2020-03-02 > Group: Individual Submission > Pages: 8 > URL: https://www.ietf.org/internet-drafts/draft-stone-pce-= local-protection-enforcement-00.txt > Status: https://datatracker.ietf.org/doc/draft-stone-pce-loca= l-protection-enforcement/ > Htmlized: https://tools.ietf.org/html/draft-stone-pce-local-pro= tection-enforcement-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-stone-pce= -local-protection-enforcement > > > Abstract: > This document aims to clarify existing usage of the local protecti= on > desired bit signalled in Path Computation Element Protocol (PCEP). > This document also introduces a new flag for signalling protection > strictness in PCEP. > > > > > Please note that it may take a couple of minutes from the time of sub= mission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From nobody Sun Jul 26 23:22:29 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 501973A16FF; Sun, 26 Jul 2020 23:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 TIX4bHJa5_RH; Sun, 26 Jul 2020 23:22:26 -0700 (PDT) Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (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 2780C3A15FC; Sun, 26 Jul 2020 23:22:26 -0700 (PDT) Received: from mse-fl1.zte.com.cn (unknown [10.30.14.238]) by Forcepoint Email with ESMTPS id 8DD90A0D1F3B6FC6A976; Mon, 27 Jul 2020 14:22:24 +0800 (CST) Received: from njxapp03.zte.com.cn ([10.41.132.202]) by mse-fl1.zte.com.cn with SMTP id 06R6MDZp017940; Mon, 27 Jul 2020 14:22:13 +0800 (GMT-8) (envelope-from xiong.quan@zte.com.cn) Received: from mapi (njxapp03[null]) by mapi (Zmail) with MAPI id mid201; Mon, 27 Jul 2020 14:22:13 +0800 (CST) Date: Mon, 27 Jul 2020 14:22:13 +0800 (CST) X-Zmail-TransId: 2afb5f1e72957cac3a31 X-Mailer: Zmail v1.0 Message-ID: <202007271422134170143@zte.com.cn> In-Reply-To: References: CAB75xn4V0W7Nya+1PrcEGsdbpn+YGnysdBYWsZqn_Xi=b8sd2w@mail.gmail.com Mime-Version: 1.0 From: To: Cc: , , Content-Type: multipart/mixed; boundary="=====_001_next=====" X-MAIL: mse-fl1.zte.com.cn 06R6MDZp017940 Archived-At: Subject: [Pce] =?utf-8?b?562U5aSNOiBBIHBlbmRpbmcgaXRlbSBmb3IgZHJhZnQtcGVu?= =?utf-8?q?g-pce-entropy-label-position?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 06:22:28 -0000 --=====_001_next===== Content-Type: multipart/related; boundary="=====_002_next=====" --=====_002_next===== Content-Type: multipart/alternative; boundary="=====_003_next=====" --=====_003_next===== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgRGhydXYgYW5kIFN0ZXBoYW5lLA0KDQoNCg0KDQoNCg0KVGhhbmtzIGZvciB5b3VyIHJldmll dyBhbmQgY29tbWVudHMhIA0KDQoNCkkgYXBwcmVjaWF0ZWQgdGhlIGNvbW1lbnRzIGZyb20geW91 IGxhc3QgbWVldGluZyBhbmQgdXBkYXRlZCB0aGUgZHJhZnQgdGhpcyBtZWV0aW5nLg0KDQoNCg0K DQoNCg0KTXVsdGlwbGUgPEVMSSwgRUw+IHBhaXJzIE1BWSBiZSBpbnNlcnRlZCBpbiB0aGUgU1It TVBMUyBsYWJlbCBzdGFjayBhcyBkZWZpbmVkIGluIFJGQzg2NjIgc2Vjc3Npb24gNy4xLg0KDQoN ClNvIGZyb20gaW1wbGVtZW50YXRpb24gdmlldywgdGhlIGluZ3Jlc3MgTVVTVCBzdXBwb3J0IHRo ZSBjYXBhYmlsaXR5IG9mICBpbnNlcnRpbmcgbXVsdGlwbGUgRUxJL0VMcy4NCg0KQW5kIGluIGNh c2Ugb2YgaW50ZXItZG9tYWluIHNjZW5hcmlvLCBQQ0Ugd291bGQgYmUgdXNlZnVsIGZvciBjb21w dXRpbmcgYm90aCBTUiBwYXRoIGFuZCB0aGUgcGxhY2VtZW50IG9mIGVudHJvcHkgbGFiZWxzLg0K DQoNCg0KDQoNCg0KU28gSSBhZ3JlZSB3aXRoIHlvdS4gIFdlIG5lZWQgdG8gZXh0ZW5kIHRoZSBj YXBhYmlsaXR5IGF0IGluZ3Jlc3Mgbm9kZSBpbiBjb250cm9sIHBsYW5lLiAgQnV0IEkgdGhpbmsg dGhlIGNhcGFiaWxpdHkgaXMgbm8gbmVlZCB0byBiZSBhZHZlcnRpc2VkICBieSBJR1AgcHJvdG9j b2wuDQoNCg0KUENFIG1pZ2h0IG5vdCBiZSBhd2FyZSBvZiB0aGUgY2FwYWJpbGl0eSBvZiBpbmdy ZXNzIHRvIHB1c2ggRUxJL0VMIHBhaXJzLiBXZSBzaG91bGQgYWRkIHRoZSBjYXBhYmlsaXR5IGlu IE9QRU4gbWVzc2FnZSBmcm9tIFBDQyB0byBQQ0UuICANCg0KDQpUaGVyZSBhcmUgdHdvIG9wdGlv bnMgZm9yIHVzLg0KDQoNCg0KQSwgYWRkIGEgbmV3IGJpdCB0byBpbmRpY2F0ZSB0aGUgY2FwYWJp bGl0eSBvZiBpbmdyZXNzIHRvIHB1c2ggRUxJL0VMIHBhaXJzLg0KDQoNCkIsIHJldXNlIHRoZSBF IChFTFApICBiaXQgdG8gaW5kaWNhdGUgdGhlIGNhcGFiaWxpdHkgb2YgaW5zZXJ0aW5nIG11bHRp cGxlIEVMSS9FTCBwYWlycyBhdCBQQ0MgYW5kIHN1cHBvcnQgdGhlIFNSIHBhdGggd2l0aCBFTFAg ZnJvbSBQQ0Ugd2hlbiBQQ0Mgc2VuZCBPUEVOIG1lc3NhZ2UgdG8gUENFLg0KDQoNCg0KDQoNCg0K SSB1cGRhdGVkIHRoZSBkcmFmdCBhcyB0aGUgb3B0aW9uIDIuICBDb3VsZCB5b3UgcGxlYXNlIHRl bGwgbWUgd2hhdCBpcyB5b3VyIHN1Z2dlc3Rpb24/DQoNCg0KQW5kIGFueSBjb21tZW50cyBhcmUg d2VsY29tZSENCg0KDQoNCg0KDQoNClRoYW5rcywNCg0KDQpRdWFuDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCuWOn+Wni+mCruS7tg0KDQoNCg0K5Y+R5Lu25Lq677yaRGhydXZEaG9k eSA8ZGhydXYuaWV0ZkBnbWFpbC5jb20+DQrmlLbku7bkurrvvJpkcmFmdC1wZW5nLXBjZS1lbnRy b3B5LWxhYmVsLXBvc2l0aW9uQGlldGYub3JnIDxkcmFmdC1wZW5nLXBjZS1lbnRyb3B5LWxhYmVs LXBvc2l0aW9uQGlldGYub3JnPjtzbGl0a293cy5pZXRmQGdtYWlsLmNvbSA8c2xpdGtvd3MuaWV0 ZkBnbWFpbC5jb20+Ow0K5oqE6YCB5Lq677yacGNlQGlldGYub3JnIDxwY2VAaWV0Zi5vcmc+Ow0K 5pelIOacnyDvvJoyMDIw5bm0MDfmnIgyNuaXpSAxOTo1Ng0K5Li7IOmimCDvvJpBIHBlbmRpbmcg aXRlbSBmb3IgZHJhZnQtcGVuZy1wY2UtZW50cm9weS1sYWJlbC1wb3NpdGlvbg0KDQoNCkhpIEF1 dGhvcnMsIFN0ZXBoYW5lLA0KDQpJbiB0aGUgbGFzdCBtZWV0aW5nIFsxXSwgU3RlcGhhbmUgbWVu dGlvbmVkIHRoYXQgdGhlIFBDRSBpcyB1bmF3YXJlIG9mDQp0aGUgUENDJ3MgY2FwYWJpbGl0eSB0 byBwdXNoIEVMSS9FTCBwYWlycyBhbmQgdGh1cyBxdWVzdGlvbmVkIHRoZQ0KdXNhYmlsaXR5IG9m IHlvdXIgSS1ELiBIZSBtZW50aW9uZWQgdGhhdCBleGlzdGluZyBpbmZvcm1hdGlvbiBpbg0KSUdQ L0JHUC1MUyBpLmUuIE1TRCwgRUxDLCBFUkxEIGRvZXMgbm90IHRlbGwgdGhlIFBDQydzIGNhcGFi aWxpdHkgdG8NCnB1c2ggRUxJL0VMIHBhaXJzLg0KDQpUaGUgY3VycmVudCBkcmFmdCBoYXMgYSBz aW5nbGUgYml0IEVMUCAtDQoNCiAgICBBIFBDQyBzZXRzIHRoaXMgZmxhZyB0byAxIHRvDQogICAg aW5kaWNhdGUgdGhhdCBpdCBzdXBwb3J0cyB0aGUgY2FwYWJpbGl0eSBvZiBpbnNlcnRpbmcgbXVs dGlwbGUgRUxJL0VMDQogICAgcGFpcnMgYW5kIGFuZCBzdXBwb3J0cyB0aGUgcmVzdWx0cyBvZiBT UiBwYXRoIHdpdGggRUxQIGZyb20gUENFLg0KDQpJIHdhbnQgdG8gY29uZmlybSBpZiB0aGlzIGJp dCBhbmQgQk1JLU1TRCBlbm91Z2g/IElmIG5vdCwgd2hhdCBlbHNlPw0KSXQgd291bGQgYmUgZ29v ZCBpZiB0aGlzIGNhbiBiZSBkaXNjdXNzZWQgaGVyZSBvciBkdXJpbmcgdGhlIG1lZXRpbmcuDQoN ClRoYW5rcyENCkRocnV2DQoNClsxXSBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9t aW51dGVzLTEwNi1wY2Uv --=====_003_next===== Content-Type: text/html ; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBjbGFzcz0iemNvbnRlbnRSb3ciPjxwIHN0eWxlPSJmb250LXNpemU6MjBweDtmb250LWZh bWlseTphcmlhbDsiPkhpIERocnV2IGFuZCBTdGVwaGFuZSw8L3A+PHAgc3R5bGU9ImZvbnQtc2l6 ZToyMHB4O2ZvbnQtZmFtaWx5OmFyaWFsOyI+PGJyPjwvcD48cCBzdHlsZT0iZm9udC1zaXplOjIw cHg7Zm9udC1mYW1pbHk6YXJpYWw7Ij5UaGFua3MgZm9yIHlvdXIgcmV2aWV3IGFuZCBjb21tZW50 cyEmbmJzcDs8L3A+PHAgc3R5bGU9ImZvbnQtc2l6ZToyMHB4O2ZvbnQtZmFtaWx5OmFyaWFsOyI+ SSBhcHByZWNpYXRlZCB0aGUgY29tbWVudHMgZnJvbSB5b3UgbGFzdCBtZWV0aW5nIGFuZCB1cGRh dGVkIHRoZSBkcmFmdCB0aGlzIG1lZXRpbmcuPC9wPjxwIHN0eWxlPSJmb250LXNpemU6MjBweDtm b250LWZhbWlseTphcmlhbDsiPjxicj48L3A+PHAgc3R5bGU9ImZvbnQtc2l6ZTogMjBweDsiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCI+TTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6IHNhbnMtc2VyaWY7Ij51bHRpcGxlICZsdDtFTEksIEVMJmd0OyBwYWlycyBNQVkgYmUg aW5zZXJ0ZWQgaW4gdGhlIFNSLU1QTFMgbGFiZWwgc3RhY2sgYXMgZGVmaW5lZCBpbiBSRkM4NjYy IHNlY3NzaW9uIDcuMS48L3NwYW4+PC9wPjxwIHN0eWxlPSJmb250LXNpemU6MjBweDtmb250LWZh bWlseTphcmlhbDsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogc2Fucy1zZXJpZjsiPlNvIGZy b20gaW1wbGVtZW50YXRpb24gdmlldywgdGhlJm5ic3A7aW5ncmVzcyBNVVNUIHN1cHBvcnQgdGhl IGNhcGFiaWxpdHkgb2YgJm5ic3A7aW5zZXJ0aW5nIG11bHRpcGxlJm5ic3A7RUxJL0VMcy48L3Nw YW4+PC9wPjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDIwcHg7Ij5BbmQgaW4gY2FzZSBvZiBp bnRlci1kb21haW4gc2NlbmFyaW8sIFBDRSB3b3VsZCBiZSB1c2VmdWwgZm9yIGNvbXB1dGluZyBi b3RoIFNSIHBhdGggYW5kIHRoZSBwbGFjZW1lbnQgb2YgZW50cm9weSBsYWJlbHMuPC9zcGFuPjwv cD48cCBzdHlsZT0iZm9udC1zaXplOjIwcHg7Zm9udC1mYW1pbHk6YXJpYWw7Ij48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6IHNhbnMtc2VyaWY7Ij48L3NwYW4+PGJyPjwvcD48cCBzdHlsZT0iZm9u dC1zaXplOjIwcHg7Zm9udC1mYW1pbHk6YXJpYWw7Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 IHNhbnMtc2VyaWY7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAyMHB4OyBsaW5lLWhlaWdodDog MzBweDsiPlNvIEkgYWdyZWUgd2l0aCB5b3UuICZuYnNwO1dlIG5lZWQgdG8gZXh0ZW5kIHRoZSZu YnNwOzxzcGFuIHN0eWxlPSJmb250LXNpemU6IDIwcHg7IGxpbmUtaGVpZ2h0OiAzMHB4OyI+Y2Fw YWJpbGl0eSBhdCZuYnNwOzxzcGFuIHN0eWxlPSJmb250LXNpemU6IDIwcHg7IGxpbmUtaGVpZ2h0 OiAzMHB4OyI+aW5ncmVzcyBub2RlIGluIGNvbnRyb2wgcGxhbmUuICZuYnNwO0J1dCBJIHRoaW5r IHRoZSA8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAyMHB4OyBsaW5lLWhlaWdodDogMzBweDsiPmNh cGFiaWxpdHk8L3NwYW4+Jm5ic3A7aXMmbmJzcDs8L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+ PHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiAzMHB4OyBmb250LWZhbWlseTogc2Fucy1zZXJpZjsi Pm5vIG5lZWQgdG8gYmUgYWR2ZXJ0aXNlZCAmbmJzcDtieSBJR1AgcHJvdG9jb2wuPC9zcGFuPjwv cD48cCBzdHlsZT0iZm9udC1zaXplOjIwcHg7Zm9udC1mYW1pbHk6YXJpYWw7Ij48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6IHNhbnMtc2VyaWY7Ij5QQ0UgbWlnaHQgbm90IGJlIGF3YXJlIG9mIHRo ZSZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IHNhbnMtc2VyaWY7Ij5jYXBh YmlsaXR5IG9mIGluZ3Jlc3MgdG8gcHVzaCBFTEkvRUwgcGFpcnMuJm5ic3A7PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTogc2Fucy1zZXJpZjsiPldlIHNob3VsZCBhZGQgdGhlIDwvc3Bh bj48c3BhbiBzdHlsZT0ibGluZS1oZWlnaHQ6IDMwcHg7IGZvbnQtZmFtaWx5OiBzYW5zLXNlcmlm OyI+Y2FwYWJpbGl0eSBpbjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IHNhbnMtc2Vy aWY7Ij4mbmJzcDtPUEVOIG1lc3NhZ2UgZnJvbSBQQ0MgdG8gUENFLiAmbmJzcDs8L3NwYW4+PC9w PjxwIHN0eWxlPSJmb250LXNpemU6MjBweDtmb250LWZhbWlseTphcmlhbDsiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTogc2Fucy1zZXJpZjsiPlRoZXJlIGFyZSB0d28gb3B0aW9ucyBmb3IgdXMu PC9zcGFuPjxicj48L3A+PHAgc3R5bGU9ImZvbnQtc2l6ZToyMHB4O2ZvbnQtZmFtaWx5OmFyaWFs OyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBzYW5zLXNlcmlmOyI+QSwgYWRkIGEgbmV3IGJp dCB0byBpbmRpY2F0ZSB0aGUmbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAyMHB4OyBsaW5l LWhlaWdodDogMzBweDsiPmNhcGFiaWxpdHkgb2YgaW5ncmVzcyB0byBwdXNoIEVMSS9FTCBwYWly cy48L3NwYW4+PC9zcGFuPjwvcD48cCBzdHlsZT0iZm9udC1zaXplOjIwcHg7Zm9udC1mYW1pbHk6 YXJpYWw7Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IHNhbnMtc2VyaWY7Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOiAyMHB4OyBsaW5lLWhlaWdodDogMzBweDsiPkIsIHJldXNlIHRoZSBFIChF TFApICZuYnNwO2JpdCB0byBpbmRpY2F0ZTxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDogMjFweDsi PiZuYnNwO3RoZSZuYnNwO2NhcGFiaWxpdHkmbmJzcDtvZiZuYnNwO2luc2VydGluZyZuYnNwO211 bHRpcGxlJm5ic3A7RUxJL0VMJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDog MjFweDsiPnBhaXJzIGF0IFBDQyBhbmQmbmJzcDtzdXBwb3J0IHRoZSBTUiZuYnNwO3BhdGgmbmJz cDt3aXRoJm5ic3A7RUxQJm5ic3A7ZnJvbSZuYnNwO1BDRSB3aGVuIFBDQyBzZW5kIE9QRU4gbWVz c2FnZSB0byBQQ0UuPC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9wPjxwIHN0eWxlPSJmb250LXNpemU6 MjBweDtmb250LWZhbWlseTphcmlhbDsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogc2Fucy1z ZXJpZjsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDIwcHg7IGxpbmUtaGVpZ2h0OiAzMHB4OyI+ PHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMXB4OyI+PGJyPjwvc3Bhbj48L3NwYW4+PC9zcGFu PjwvcD48cCBzdHlsZT0iZm9udC1zaXplOiAyMHB4OyI+PHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0 OiAyMXB4OyI+SSB1cGRhdGVkIHRoZSBkcmFmdCBhcyB0aGUgb3B0aW9uIDIuICZuYnNwO0NvdWxk IHlvdSBwbGVhc2UgdGVsbCBtZSB3aGF0IGlzIHlvdXIgc3VnZ2VzdGlvbj88L3NwYW4+PC9wPjxw IHN0eWxlPSJmb250LXNpemU6IDIwcHg7Ij48c3BhbiBzdHlsZT0ibGluZS1oZWlnaHQ6IDIxcHg7 Ij5BbmQgYW55IGNvbW1lbnRzIGFyZSB3ZWxjb21lITwvc3Bhbj48L3A+PHAgc3R5bGU9ImZvbnQt c2l6ZTogMjBweDsiPjxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDogMjFweDsiPjxicj48L3NwYW4+ PC9wPjxwIHN0eWxlPSJmb250LXNpemU6IDIwcHg7Ij48c3BhbiBzdHlsZT0ibGluZS1oZWlnaHQ6 IDIxcHg7Ij5UaGFua3MsPC9zcGFuPjwvcD48cCBzdHlsZT0iZm9udC1zaXplOiAyMHB4OyI+PHNw YW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMXB4OyI+UXVhbjwvc3Bhbj48L3A+PHAgc3R5bGU9ImZv bnQtc2l6ZToyMHB4O2ZvbnQtZmFtaWx5OmFyaWFsOyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiBzYW5zLXNlcmlmOyI+PGJyPjwvc3Bhbj48L3A+PHAgc3R5bGU9ImZvbnQtc2l6ZToyMHB4O2Zv bnQtZmFtaWx5OmFyaWFsOyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBzYW5zLXNlcmlmOyBm b250LXNpemU6IDIwcHg7IGxpbmUtaGVpZ2h0OiAzMHB4OyI+PGJyPjwvc3Bhbj48YnI+PC9wPjxw IHN0eWxlPSJmb250LXNpemU6MjBweDtmb250LWZhbWlseTphcmlhbDsiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTogc2Fucy1zZXJpZjsiPjxicj48L3NwYW4+PC9wPjxkaXY+PGRpdiBjbGFzcz0i emhpc3RvcnlSb3ciIHN0eWxlPSJkaXNwbGF5OmJsb2NrIj48ZGl2IGNsYXNzPSJ6aGlzdG9yeURl cyIgc3R5bGU9IndpZHRoOiAxMDAlOyBoZWlnaHQ6IDI4cHg7IGxpbmUtaGVpZ2h0OiAyOHB4OyBi YWNrZ3JvdW5kLWNvbG9yOiAjRTBFNUU5OyBjb2xvcjogIzEzODhGRjsgdGV4dC1hbGlnbjogY2Vu dGVyOyIgbGFuZ3VhZ2UtZGF0YT0iSGlzdG9yeU9yZ1R4dCI+5Y6f5aeL6YKu5Lu2PC9kaXY+PGRp diBpZD0iendyaXRlSGlzdG9yeUNvbnRhaW5lciI+PGRpdiBjbGFzcz0iY29udHJvbC1ncm91cCB6 aGlzdG9yeVBhbmVsIj48ZGl2IGNsYXNzPSJ6aGlzdG9yeUhlYWRlciIgc3R5bGU9InBhZGRpbmc6 IDhweDsgYmFja2dyb3VuZC1jb2xvcjogI0Y1RjZGODsiPjxkaXY+PHN0cm9uZyBsYW5ndWFnZS1k YXRhPSJIaXN0b3J5U2VuZGVyVHh0Ij7lj5Hku7bkurrvvJo8L3N0cm9uZz48c3BhbiBjbGFzcz0i enJlYWRVc2VyTmFtZSI+RGhydXZEaG9keSAmbHQ7ZGhydXYuaWV0ZkBnbWFpbC5jb20mZ3Q7PC9z cGFuPjwvZGl2PjxkaXY+PHN0cm9uZyBsYW5ndWFnZS1kYXRhPSJIaXN0b3J5VE9UeHQiPuaUtuS7 tuS6uu+8mjwvc3Ryb25nPjxzcGFuIGNsYXNzPSJ6cmVhZFVzZXJOYW1lIiBzdHlsZT0iZGlzcGxh eTogaW5saW5lOyI+ZHJhZnQtcGVuZy1wY2UtZW50cm9weS1sYWJlbC1wb3NpdGlvbkBpZXRmLm9y ZyAmbHQ7ZHJhZnQtcGVuZy1wY2UtZW50cm9weS1sYWJlbC1wb3NpdGlvbkBpZXRmLm9yZyZndDs7 c2xpdGtvd3MuaWV0ZkBnbWFpbC5jb20gJmx0O3NsaXRrb3dzLmlldGZAZ21haWwuY29tJmd0Ozs8 L3NwYW4+PC9kaXY+PGRpdj48c3Ryb25nIGxhbmd1YWdlLWRhdGE9Ikhpc3RvcnlDQ1R4dCI+5oqE 6YCB5Lq677yaPC9zdHJvbmc+PHNwYW4gY2xhc3M9InpyZWFkVXNlck5hbWUiIHN0eWxlPSJkaXNw bGF5OiBpbmxpbmU7Ij5wY2VAaWV0Zi5vcmcgJmx0O3BjZUBpZXRmLm9yZyZndDs7PC9zcGFuPjwv ZGl2PjxkaXY+PHN0cm9uZyBsYW5ndWFnZS1kYXRhPSJIaXN0b3J5RGF0ZVR4dCI+5pelIOacnyDv vJo8L3N0cm9uZz48c3BhbiBjbGFzcz0iIj4yMDIw5bm0MDfmnIgyNuaXpSAxOTo1Njwvc3Bhbj48 L2Rpdj48ZGl2PjxzdHJvbmcgbGFuZ3VhZ2UtZGF0YT0iSGlzdG9yeVN1YmplY3RUeHQiPuS4uyDp opgg77yaPC9zdHJvbmc+PHNwYW4gY2xhc3M9InpyZWFkVGl0bGUiPjxzdHJvbmc+QSBwZW5kaW5n IGl0ZW0gZm9yIGRyYWZ0LXBlbmctcGNlLWVudHJvcHktbGFiZWwtcG9zaXRpb248L3N0cm9uZz48 L3NwYW4+PC9kaXY+PC9kaXY+PGRpdiBjbGFzcz0iemhpc3RvcnlDb250ZW50Ij48ZGl2PkhpJm5i c3A7QXV0aG9ycywmbmJzcDtTdGVwaGFuZSw8YnI+PGJyPkluJm5ic3A7dGhlJm5ic3A7bGFzdCZu YnNwO21lZXRpbmcmbmJzcDtbMV0sJm5ic3A7U3RlcGhhbmUmbmJzcDttZW50aW9uZWQmbmJzcDt0 aGF0Jm5ic3A7dGhlJm5ic3A7UENFJm5ic3A7aXMmbmJzcDt1bmF3YXJlJm5ic3A7b2Y8YnI+dGhl Jm5ic3A7UENDJ3MmbmJzcDtjYXBhYmlsaXR5Jm5ic3A7dG8mbmJzcDtwdXNoJm5ic3A7RUxJL0VM Jm5ic3A7cGFpcnMmbmJzcDthbmQmbmJzcDt0aHVzJm5ic3A7cXVlc3Rpb25lZCZuYnNwO3RoZTxi cj51c2FiaWxpdHkmbmJzcDtvZiZuYnNwO3lvdXImbmJzcDtJLUQuJm5ic3A7SGUmbmJzcDttZW50 aW9uZWQmbmJzcDt0aGF0Jm5ic3A7ZXhpc3RpbmcmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2luPGJy PklHUC9CR1AtTFMmbmJzcDtpLmUuJm5ic3A7TVNELCZuYnNwO0VMQywmbmJzcDtFUkxEJm5ic3A7 ZG9lcyZuYnNwO25vdCZuYnNwO3RlbGwmbmJzcDt0aGUmbmJzcDtQQ0MncyZuYnNwO2NhcGFiaWxp dHkmbmJzcDt0bzxicj5wdXNoJm5ic3A7RUxJL0VMJm5ic3A7cGFpcnMuPGJyPjxicj5UaGUmbmJz cDtjdXJyZW50Jm5ic3A7ZHJhZnQmbmJzcDtoYXMmbmJzcDthJm5ic3A7c2luZ2xlJm5ic3A7Yml0 Jm5ic3A7RUxQJm5ic3A7LTxicj48YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7QSZuYnNwO1BD QyZuYnNwO3NldHMmbmJzcDt0aGlzJm5ic3A7ZmxhZyZuYnNwO3RvJm5ic3A7MSZuYnNwO3RvPGJy PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2luZGljYXRlJm5ic3A7dGhhdCZuYnNwO2l0Jm5ic3A7 c3VwcG9ydHMmbmJzcDt0aGUmbmJzcDtjYXBhYmlsaXR5Jm5ic3A7b2YmbmJzcDtpbnNlcnRpbmcm bmJzcDttdWx0aXBsZSZuYnNwO0VMSS9FTDxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtwYWly cyZuYnNwO2FuZCZuYnNwO2FuZCZuYnNwO3N1cHBvcnRzJm5ic3A7dGhlJm5ic3A7cmVzdWx0cyZu YnNwO29mJm5ic3A7U1ImbmJzcDtwYXRoJm5ic3A7d2l0aCZuYnNwO0VMUCZuYnNwO2Zyb20mbmJz cDtQQ0UuPGJyPjxicj5JJm5ic3A7d2FudCZuYnNwO3RvJm5ic3A7Y29uZmlybSZuYnNwO2lmJm5i c3A7dGhpcyZuYnNwO2JpdCZuYnNwO2FuZCZuYnNwO0JNSS1NU0QmbmJzcDtlbm91Z2g/Jm5ic3A7 SWYmbmJzcDtub3QsJm5ic3A7d2hhdCZuYnNwO2Vsc2U/PGJyPkl0Jm5ic3A7d291bGQmbmJzcDti ZSZuYnNwO2dvb2QmbmJzcDtpZiZuYnNwO3RoaXMmbmJzcDtjYW4mbmJzcDtiZSZuYnNwO2Rpc2N1 c3NlZCZuYnNwO2hlcmUmbmJzcDtvciZuYnNwO2R1cmluZyZuYnNwO3RoZSZuYnNwO21lZXRpbmcu PGJyPjxicj5UaGFua3MhPGJyPkRocnV2PGJyPjxicj5bMV0mbmJzcDtodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9taW51dGVzLTEwNi1wY2UvPC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+ PC9kaXY+PC9kaXY+PHA+PGJyPjwvcD48L2Rpdj4= --=====_003_next=====-- --=====_002_next=====-- --=====_001_next=====-- From nobody Mon Jul 27 05:47:08 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF02D3A18D9 for ; Mon, 27 Jul 2020 05:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com 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 DBkoiN3jX29J for ; Mon, 27 Jul 2020 05:47:04 -0700 (PDT) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2133.outbound.protection.outlook.com [40.107.244.133]) (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 13C193A194B for ; Mon, 27 Jul 2020 05:47:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QmwKXslZRqYDFrL67yDfiJBY69oyTbEnr5LGu51JeU1EpEMJdUMvCQUL3NhobaToLqPFC8nlVAAlASb+zUw7PkonJcUtS+dz8RVroUB4tV5ULCPiPbF7sbt9hn/0UdPkVB8d9QtYSwZOdMkmfzbDdb1mWIYJgL/H4HSM/x+jeMBeTIk3ja3BAKBk227a+ie4xHzVWMNyMli8L0mHnG85veRSZDpLaT0wi6/lRKvrden3ueFQjf0kKjhFzzIjPZ3d99t+g8K8m2iKfd4uBCZQC6tO3qTJj40OiVT2iWzT5SIvff3LQ3Bjq5RvlUDhJurO04vLCs2hmXCZnuQVqwjLUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RfcA61UsNFYkOOpAK3ulIQNAijpOLPjfY5rIOEugGmw=; b=PT/fgXC+UYJm3HslPVS43EcngP9fMU0zOkEQPs8q2E22yaOwCx+tOH32IXGBv9DZq7m0BIOJYpWTArdRkBctUocFuc1JuHLXkW/M41smdg1wztHOzlz9YBBmNkc2LtkZ3ZY7i2IX9tzDqABvl64zD6SMdN4XPFwKkFzd3CKptZg29MU/IO+8b2+iKzaDRu3wOrLVFcIC7WOojEoLfWyyE79TMjiJi1ohnjmQzoqfms48pi+GS9TlFcEG6G8B0T1/sEMnz7q8px53KuAAedM//VT7sktIucOttQCOwBwdOWQJY+/Iw8zMJR94pdNAllpCZQkrMnD0N20SzTaGs8DFZQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RfcA61UsNFYkOOpAK3ulIQNAijpOLPjfY5rIOEugGmw=; b=nCJL6oKx12TNbrXNNfSkky69N49lD3BRB7dNaIwaCGz1epp7XB2NlNL0r44mGTs1jlid6BmtgNesD1N90xV1McwxyCfxzITs5sDbOUyiyILlE9rvrxHMTcjPPGWdBrMDm7M6dk3KVk3hHIKhCf1CdkgavxHfsLdAcAkPCWBr3s8= Received: from DM6PR08MB4393.namprd08.prod.outlook.com (2603:10b6:5:a2::21) by DM6PR08MB5433.namprd08.prod.outlook.com (2603:10b6:5:f9::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.27; Mon, 27 Jul 2020 12:47:00 +0000 Received: from DM6PR08MB4393.namprd08.prod.outlook.com ([fe80::5079:e07:ea06:58d7]) by DM6PR08MB4393.namprd08.prod.outlook.com ([fe80::5079:e07:ea06:58d7%7]) with mapi id 15.20.3216.033; Mon, 27 Jul 2020 12:47:00 +0000 From: "Stone, Andrew (Nokia - CA/Ottawa)" To: Dhruv Dhody CC: "pce@ietf.org" Thread-Topic: [Pce] FW: New Version Notification for draft-stone-pce-local-protection-enforcement-00.txt Thread-Index: AQHV8LAlX25e8CaRakeOwDgMwEGUgag7gFWAgN8onACAAVqqAA== Date: Mon, 27 Jul 2020 12:47:00 +0000 Message-ID: References: <158316673618.27361.7017725094379697473@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.39.20071300 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=nokia.com; x-originating-ip: [135.245.20.8] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 844d670c-ae67-4e0a-833e-08d8322b27d3 x-ms-traffictypediagnostic: DM6PR08MB5433: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: aL2CEc8JjfiHVDqHH5biTYg0N9aGVjmJyVm0Ck30Vg9AG/e7kM/iPKiUz2PDfcJjsaudrFTQrwjDeWGof7rpKNTdrc2D2CSm+xdMT0d7nN2DdEk30QZE3rJJeKZM52sOjv42k40KC2JgDz9JtS1xaN9QaqkB+PyfD1K1peNiBvWx2SN7xvR6eVCQu+9O6gx29QhDWRFi9nvZVHWNMk8OdyBhqR24CNUmlGPB70Jb0FzYPPn72j+5frK9xaG6bthPwh97iR8w0DU9iqwEzTiCoIFZmvnD/KllJ8ETeFa2+honYWn1ERmKAba2HBVYfnFdx9hRXon8r68HKziX0oIpVtJCvA9J9FDSid9rxubhkFvP4/9yeiLv+OL61d3TC2klFKFbexGPjL2t0kNp9jQ0RA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR08MB4393.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(39850400004)(136003)(346002)(366004)(396003)(8936002)(71200400001)(8676002)(316002)(15650500001)(33656002)(91956017)(76116006)(6512007)(66446008)(64756008)(66946007)(66476007)(66556008)(478600001)(6916009)(966005)(6506007)(53546011)(4326008)(2906002)(36756003)(66574015)(26005)(2616005)(83380400001)(5660300002)(86362001)(186003)(6486002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: p+Btp3iyV45pTpI8xoKQigHKx3M9gQZrL9dqt+BuWVh0fBLuz8M0xduXDRmt56pZxeNBefpg7c4pKBTkMlNHuLGsglmr0z7qG9HgLYROZDJzTLCV2MC33DWvAl8tUUa51ejt5MS12/FJK8orzklflRR5KqHKMIQRs43kbjtuTU0AHwCX8LzdcxYwGRmwtvCcFqTZwEU81Y86PBTGr4P8O1KVjcS7jm+k54cYLzWkeBJbzvRfzZgHfl3KRmvH0mjZynPGWu212zyvv9wTEfx4JC3lzE9jvolXrNO1Jc1FhPs72rfJwRdm2uIndfDSqDxeosjNd0lzZ34fpCSnZ7VuirUtczK8vuXCx1ltsCob0AMxRTZFQGw1wiUWflXhC1fY2iqSSvo1t4Eg3wxKUkdTitUdXVHj7Ri1miF2Q+gePtwTH2FSSvR6ZTCjWr5Jj0cu/LpFadxCVSugQ1aTjCXpx/Cq78DqJgSbUmknbg9SU7U= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <063AC245F6517C4B9C3A109D34D7EA01@namprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR08MB4393.namprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 844d670c-ae67-4e0a-833e-08d8322b27d3 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2020 12:47:00.5521 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 4my3gLYA3luUPuYElXP6/ijA03niexziOlk4hqxYv0OEirOruj4yS2LPKvba08hbHSu0lOPI4uAvKsdvW0AU2Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR08MB5433 Archived-At: Subject: Re: [Pce] FW: New Version Notification for draft-stone-pce-local-protection-enforcement-00.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 12:47:06 -0000 SGkgRGhydXYsDQoNClRoYW5rcyBmb3IgdGhlIGZlZWRiYWNrLg0KDQpUaGUgZG9jdW1lbnRzIGFp bSBpcyBleHRlbmRpbmcgbmV3IGZ1bmN0aW9uYWxpdHksIHdpdGggYWxzbyBhZGRpbmcgYWRkaXRp b25hbCBsYW5ndWFnZSB0byBpbXBsZW1lbnRhdGlvbiBiZWhhdmlvdXIgb2YgdGhlIGV4aXN0aW5n IGZsYWcgc28gSSBzdXBwb3NlIGl0IHdvdWxkIGJlIGFuIHVwZGF0ZSB0byBSRkM1NDQwLiBBcmUg dGhlcmUgb3RoZXIgZGlmZmVyZW5jZXMgdG8gbWFrZSwgb3RoZXIgdGhhbiB4bWwgbWV0YSBkYXRh IGluIHRoZSBkb2N1bWVudCB0byBpbmRpY2F0ZSBpdCB1cGRhdGVzIFJGQzU0NDA/ICAoaWYgdGhl cmUncyBhIGxpbmsgdGhhdCBkZXNjcmliZXMgdGhhdCBpcyByZXF1aXJlZCB0aGF0IHlvdSBjYW4g cG9pbnQgbWUgdG8gdGhhdCB3b3VsZCBiZSBhcHByZWNpYXRlZCkuDQoNClJlZ2FyZGluZyBiYWNr d2FyZHMgY29tcGF0aWJpbGl0eSwgZ29vZCBwb2ludDogdGhlIGRvYyBpbmNsdWRlcyBQQ0MgYmFj a3dhcmRzIGNvbXBhdGliaWxpdHkgY29tbWVudHMgaW4gc2VjdGlvbiA1IGJ1dCBkb2VzIGluZGVl ZCBub3QgZGlzY3VzcyBQQ0UgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkuIEZyb20gbXkgcG9pbnQg b2YgdmlldywgSSBkb24ndCBzZWUgYSBjYXBhYmlsaXR5IGV4Y2hhbmdlIGJlaW5nIHJlcXVpcmVk LiBJIHNlZSBzdXBwb3J0IG9mICdMJyBmbGFnIGJlaW5nIGFuIGluZGVwZW5kZW50IGludGVyb3Ag Y2xhcmlmaWNhdGlvbiBhbmQgJ0UnIGZsYWcgYmVpbmcgc2ltaWxhciB0byBhZGRpbmcgYW5vdGhl ciBraW5kIG9mICdjb25zdHJhaW50JyB0byBhIHBhdGguICBJIGRvbid0IHRoaW5rIHdvdWxkIHJl cXVpcmUgYSBjYXBhYmlsaXR5IGV4Y2hhbmdlIHRvIGluZm9ybSB0aGUgUENDIHdoZXRoZXIgb3Ig bm90IHBjZSBzdXBwb3J0cyBhIGdpdmVuIGNvbnN0cmFpbnQgdHlwZS4gSSB0aGluayB0aGUgaW1w b3J0YW50IHRoaW5nIGlzIGFuIGV4aXN0aW5nIHBjZSB3b3VsZCBub3QgZXJyb3Igb3V0IGlmIGl0 IGRpZCByZWNlaXZlICdFJyBmbGFnIHNldCwgYW5kIGZvcnR1bmF0ZWx5IFJGQzU0NDAgaGFzIHRo YXQgY292ZXJlZCB3aXRoICdVbmFzc2lnbmVkIGZsYWdzIE1VU1QgYmUgc2V0IHRvIHplcm8gb24g dHJhbnNtaXNzaW9uIGFuZCBNVVNUIGJlIGlnbm9yZWQgb24gcmVjZWlwdC4nICBJJ2xsIGFkZCBh IHJlbWFyayBpbiB0aGUgZG9jdW1lbnQgdGhhdCBjb21tZW50cyBvbiB0aGlzLiANCg0KVGhhbmtz IGFnYWluLA0KQW5kcmV3DQoNCu+7v09uIDIwMjAtMDctMjYsIDg6MDYgQU0sICJEaHJ1diBEaG9k eSIgPGRocnV2LmlldGZAZ21haWwuY29tPiB3cm90ZToNCg0KICAgIEhpIEFuZHJldywNCg0KICAg IERvIHlvdSB0aGluayBhbiB1cGRhdGUgdG8gUkZDIDU0NDAgaXMgcmVxdWlyZWQgKHdpdGggbWV0 YS1kYXRhIHNldCBpbg0KICAgIHRoZSBkb2N1bWVudCBoZWFkZXIpPw0KICAgIEJhc2VkIG9uIHRo ZSBkZXNjcmlwdGlvbiBvZiB0aGUgZmxhZyBmaWVsZCBpdCBmZWVscyBsaWtlIGFuIHVwZGF0ZQ0K ICAgIHdvdWxkIGJlIG5lZWRlZCAtDQoNCiAgICAgIG8gIEwgZmxhZzogQXMgZGVmaW5lZCBpbiBb UkZDNTQ0MF0gYW5kIGZ1cnRoZXIgdXBkYXRlZCBieSB0aGlzDQogICAgICAgICAgZG9jdW1lbnQu ICBXaGVuIHNldCwgcHJvdGVjdGlvbiBpcyBkZXNpcmVkLiAgV2hlbiBub3Qgc2V0LA0KICAgICAg ICAgIHByb3RlY3Rpb24gaXMgbm90IGRlc2lyZWQuICBUaGUgZW5mb3JjZW1lbnQgb2YgdGhlIHBy b3RlY3Rpb24gaXMNCiAgICAgICAgICBpZGVudGlmaWVkIHZpYSB0aGUgRS1GbGFnLg0KDQoNCiAg ICBCVFcsIHRoYW5rcyBmb3Igc2VjdGlvbiA0IGl0IGhlbHBzIQ0KDQogICAgTWF5YmUgYWRkIGFu IGV4cGxpY2l0IGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgc2VjdGlvbi4gQ29uc2lkZXIgYSBQQ0MN CiAgICB0aGF0IHN1cHBvcnRzIHlvdXIgZXh0ZW5zaW9uLCBhbmQgc2V0cyB0aGUgRSBmbGFnIHRv IDEgYW5kIGEgUENFIHRoYXQNCiAgICBkb2VzIG5vdCBzdXBwb3J0IHlvdXIgZXh0ZW5zaW9uIHdp bGwgaWdub3JlIGl0IGFuZCBiZWhhdmUgYXMgYmVmb3JlDQogICAgYW5kIHRodXMgbm90IGVuZm9y Y2UgbG9jYWwgcHJvdGVjdGlvbiwgYW5kIHRoZXJlIHdvdWxkIGJlIG5vIHdheSBmb3INCiAgICB0 aGUgUENDIHRvIGtub3cgYWJvdXQgaXQhIE5vdCBzdXJlIGlmIHdlIG5lZWQgc29tZSBzb3J0IG9m IGNhcGFiaWxpdHkNCiAgICBleGNoYW5nZSBoZXJlPw0KDQogICAgVGhhbmtzIQ0KICAgIERocnV2 DQoNCiAgICBPbiBGcmksIE1hciA2LCAyMDIwIGF0IDEwOjQ1IFBNIFN0b25lLCBBbmRyZXcgKE5v a2lhIC0gQ0EvT3R0YXdhKQ0KICAgIDxhbmRyZXcuc3RvbmVAbm9raWEuY29tPiB3cm90ZToNCiAg ICA+DQogICAgPiBIaSBQQ0UgV0csDQogICAgPg0KICAgID4gVGhpcyBkcmFmdCB3YXMgdXBkYXRl ZCB0byBpbmNsdWRlIHRoZSBmb2xsb3dpbmc6DQogICAgPg0KICAgID4gLSBEcmFmdCByZW5hbWVk IHRvIHJlZmxlY3QgdGhpcyBpcyBmb3IgImxvY2FsIiBwcm90ZWN0aW9uIGVuZm9yY2VtZW50ICh1 c2VkIHRvIGJlIGNhbGxlZCBwYXRoLXByb3RlY3Rpb24pDQogICAgPiAtIG5ldyBjbyBhdXRob3IN CiAgICA+IC0gQWRkZWQgbW9yZSB0ZXh0IHJlZ2FyZGluZyB0aGUgdmFyaW91cyB1c2UgY2FzZXMg LyB3aHkgYSB1c2VyIG1heSB3YW50IHRoZXNlIG9wdGlvbnMNCiAgICA+IC0gQWRkZWQgdGV4dCBk aXNjdXNzaW5nIHNpdHVhdGlvbnMgb2Ygbm8gcHJlZmVyZW5jZSAvICJubyBub3QgY2FyZSINCiAg ICA+DQogICAgPiBUaGFua3MNCiAgICA+IEFuZHJldw0KICAgID4NCiAgICA+DQogICAgPg0KICAg ID4gT24gMjAyMC0wMy0wMiwgMTE6MzIgQU0sICJpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIDxp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IHdyb3RlOg0KICAgID4NCiAgICA+DQogICAgPiAgICAg QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXN0b25lLXBjZS1sb2NhbC1wcm90ZWN0aW9uLWVu Zm9yY2VtZW50LTAwLnR4dA0KICAgID4gICAgIGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0 ZWQgYnkgQW5kcmV3IFN0b25lIGFuZCBwb3N0ZWQgdG8gdGhlDQogICAgPiAgICAgSUVURiByZXBv c2l0b3J5Lg0KICAgID4NCiAgICA+ICAgICBOYW1lOiAgICAgICAgICAgICAgIGRyYWZ0LXN0b25l LXBjZS1sb2NhbC1wcm90ZWN0aW9uLWVuZm9yY2VtZW50DQogICAgPiAgICAgUmV2aXNpb246ICAg MDANCiAgICA+ICAgICBUaXRsZTogICAgICAgICAgICAgIExvY2FsIFByb3RlY3Rpb24gRW5mb3Jj ZW1lbnQgaW4gUENFUA0KICAgID4gICAgIERvY3VtZW50IGRhdGU6ICAgICAgMjAyMC0wMy0wMg0K ICAgID4gICAgIEdyb3VwOiAgICAgICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQogICAg PiAgICAgUGFnZXM6ICAgICAgICAgICAgICA4DQogICAgPiAgICAgVVJMOiAgICAgICAgICAgIGh0 dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1zdG9uZS1wY2UtbG9jYWwt cHJvdGVjdGlvbi1lbmZvcmNlbWVudC0wMC50eHQNCiAgICA+ICAgICBTdGF0dXM6ICAgICAgICAg aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc3RvbmUtcGNlLWxvY2FsLXBy b3RlY3Rpb24tZW5mb3JjZW1lbnQvDQogICAgPiAgICAgSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zdG9uZS1wY2UtbG9jYWwtcHJvdGVjdGlvbi1lbmZv cmNlbWVudC0wMA0KICAgID4gICAgIEh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXN0b25lLXBjZS1sb2NhbC1wcm90ZWN0aW9uLWVuZm9y Y2VtZW50DQogICAgPg0KICAgID4NCiAgICA+ICAgICBBYnN0cmFjdDoNCiAgICA+ICAgICAgICBU aGlzIGRvY3VtZW50IGFpbXMgdG8gY2xhcmlmeSBleGlzdGluZyB1c2FnZSBvZiB0aGUgbG9jYWwg cHJvdGVjdGlvbg0KICAgID4gICAgICAgIGRlc2lyZWQgYml0IHNpZ25hbGxlZCBpbiBQYXRoIENv bXB1dGF0aW9uIEVsZW1lbnQgUHJvdG9jb2wgKFBDRVApLg0KICAgID4gICAgICAgIFRoaXMgZG9j dW1lbnQgYWxzbyBpbnRyb2R1Y2VzIGEgbmV3IGZsYWcgZm9yIHNpZ25hbGxpbmcgcHJvdGVjdGlv bg0KICAgID4gICAgICAgIHN0cmljdG5lc3MgaW4gUENFUC4NCiAgICA+DQogICAgPg0KICAgID4N CiAgICA+DQogICAgPiAgICAgUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBv ZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KICAgID4gICAgIHVudGlsIHRo ZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5v cmcuDQogICAgPg0KICAgID4gICAgIFRoZSBJRVRGIFNlY3JldGFyaWF0DQogICAgPg0KICAgID4N CiAgICA+DQogICAgPg0KICAgID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCiAgICA+IFBjZSBtYWlsaW5nIGxpc3QNCiAgICA+IFBjZUBpZXRmLm9yZw0K ICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wY2UNCg0K From nobody Mon Jul 27 06:33:20 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5903A1990 for ; Mon, 27 Jul 2020 06:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 pVb_V1eYcLAX for ; Mon, 27 Jul 2020 06:33:14 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBFEA3A1994 for ; Mon, 27 Jul 2020 06:33:13 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id q75so8775235iod.1 for ; Mon, 27 Jul 2020 06:33:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=u6dl2hCeih9eM2NCT3zLcpi83Zpw9NxczxYE95uzkO0=; b=DTcDRBh92MeVkXcXvlinR+/KILflNX/iey03fvaJXfZs5pOS6WQaZfrIrxpo3oKE/i Y8JfDOhH1JnUy2dUcLcWY92RPPTYgiz1ff1rEe/RODGcOMZUgdl8MJW3dGd8FlGaWyVB mdlLWSsw1IvL+9EbfGdf5Mo7jjDK+U43Sn3Yd7vPTH+HkVwbdhORllReeLLnJIH7YV3u NgkLah8g+BfIJ7cTeL2HjQ62ubcjYlLR+4u8LpZmAnZ0AfOaKlQgjqEPAgkZF9vmU063 yTghP1en58M95MaEFc9jqbDvbGqnnP3UBP1udJTWDm5XHJcElyWJOPZxffkdl9cuwnup Bpnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=u6dl2hCeih9eM2NCT3zLcpi83Zpw9NxczxYE95uzkO0=; b=CR4WWMzWOTxulL0jINdposXOz0v+zoBQEkl0IOVhc4hVSgyyRT/BwWOlUrkrH0m7+v iardZpQ3+zWoAKmoNNn9xCyc7EqVxQ2A9wxp5JJP6g/dK9pOr634YwBbJSZR5F+g4zwe aoI2Al/gbCiyi2eYLNGtiKDHPNd2zB8vEamVgozy65UGAtBdGt/g5OHTIvdxQHwpZo4I hGCUaDE9ER0vPy+8wPYN88B6d398qq8iwKCPC39Va5u29XaZUOHGRhezj6X4LnHHGXLm G377c5ZAN6raTeHME+yTh2ZbXbmwUX83VEDW2Huv58+q0aIwGn5EfpNBkv3dqVfCklcg DNmQ== X-Gm-Message-State: AOAM530GtZ9tMyV4TmZ745kT43iOru0TAbAJR95d5VbnvN33qdmkc6v7 O+ki9YxMGq6AYkF/9NsFVXbykHbC5K/+qX259uJT70q2G1I= X-Google-Smtp-Source: ABdhPJyTuJy6y2Xy3FFYEO7rWFQydkh0L+uN1J6g7RvVmYan/3R/3y9ZsH2kD/TIw5DK5xQrDCG4rMglT+97lljDXlE= X-Received: by 2002:a05:6602:1610:: with SMTP id x16mr17307813iow.68.1595856792907; Mon, 27 Jul 2020 06:33:12 -0700 (PDT) MIME-Version: 1.0 References: <158316673618.27361.7017725094379697473@ietfa.amsl.com> In-Reply-To: From: Dhruv Dhody Date: Mon, 27 Jul 2020 19:02:36 +0530 Message-ID: To: "Stone, Andrew (Nokia - CA/Ottawa)" Cc: "pce@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Pce] FW: New Version Notification for draft-stone-pce-local-protection-enforcement-00.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 13:33:17 -0000 Hi Andrew, >From my point of view, to mark "updates RFC", you need to - - Update the metadata (https://tools.ietf.org/html/rfc7322#section-4.1.4) - Mention that you are updating the RFC 5440 in your abstract/introduction - Clarify what text is being updated in RFC 5440 and provide the updated te= xt - Backward compatibility One easy reference would be to look at the recent RFC 8786 that updates RFC 8231. Not sure about a process document that describes these. I remember there was another individual draft to clarify on what it means to update an RFC and have more descriptive tags - update/amend/extend an RFC but we could ignore that for now :) Dhruv On Mon, Jul 27, 2020 at 6:17 PM Stone, Andrew (Nokia - CA/Ottawa) wrote: > > Hi Dhruv, > > Thanks for the feedback. > > The documents aim is extending new functionality, with also adding additi= onal language to implementation behaviour of the existing flag so I suppose= it would be an update to RFC5440. Are there other differences to make, oth= er than xml meta data in the document to indicate it updates RFC5440? (if = there's a link that describes that is required that you can point me to tha= t would be appreciated). > > Regarding backwards compatibility, good point: the doc includes PCC backw= ards compatibility comments in section 5 but does indeed not discuss PCE ba= ckwards compatibility. From my point of view, I don't see a capability exch= ange being required. I see support of 'L' flag being an independent interop= clarification and 'E' flag being similar to adding another kind of 'constr= aint' to a path. I don't think would require a capability exchange to info= rm the PCC whether or not pce supports a given constraint type. I think the= important thing is an existing pce would not error out if it did receive '= E' flag set, and fortunately RFC5440 has that covered with 'Unassigned flag= s MUST be set to zero on transmission and MUST be ignored on receipt.' I'l= l add a remark in the document that comments on this. > > Thanks again, > Andrew > > =EF=BB=BFOn 2020-07-26, 8:06 AM, "Dhruv Dhody" wro= te: > > Hi Andrew, > > Do you think an update to RFC 5440 is required (with meta-data set in > the document header)? > Based on the description of the flag field it feels like an update > would be needed - > > o L flag: As defined in [RFC5440] and further updated by this > document. When set, protection is desired. When not set, > protection is not desired. The enforcement of the protection i= s > identified via the E-Flag. > > > BTW, thanks for section 4 it helps! > > Maybe add an explicit backward compatibility section. Consider a PCC > that supports your extension, and sets the E flag to 1 and a PCE that > does not support your extension will ignore it and behave as before > and thus not enforce local protection, and there would be no way for > the PCC to know about it! Not sure if we need some sort of capability > exchange here? > > Thanks! > Dhruv > > On Fri, Mar 6, 2020 at 10:45 PM Stone, Andrew (Nokia - CA/Ottawa) > wrote: > > > > Hi PCE WG, > > > > This draft was updated to include the following: > > > > - Draft renamed to reflect this is for "local" protection enforceme= nt (used to be called path-protection) > > - new co author > > - Added more text regarding the various use cases / why a user may = want these options > > - Added text discussing situations of no preference / "no not care" > > > > Thanks > > Andrew > > > > > > > > On 2020-03-02, 11:32 AM, "internet-drafts@ietf.org" wrote: > > > > > > A new version of I-D, draft-stone-pce-local-protection-enforcem= ent-00.txt > > has been successfully submitted by Andrew Stone and posted to t= he > > IETF repository. > > > > Name: draft-stone-pce-local-protection-enforcemen= t > > Revision: 00 > > Title: Local Protection Enforcement in PCEP > > Document date: 2020-03-02 > > Group: Individual Submission > > Pages: 8 > > URL: https://www.ietf.org/internet-drafts/draft-ston= e-pce-local-protection-enforcement-00.txt > > Status: https://datatracker.ietf.org/doc/draft-stone-pc= e-local-protection-enforcement/ > > Htmlized: https://tools.ietf.org/html/draft-stone-pce-loc= al-protection-enforcement-00 > > Htmlized: https://datatracker.ietf.org/doc/html/draft-sto= ne-pce-local-protection-enforcement > > > > > > Abstract: > > This document aims to clarify existing usage of the local pr= otection > > desired bit signalled in Path Computation Element Protocol (= PCEP). > > This document also introduces a new flag for signalling prot= ection > > strictness in PCEP. > > > > > > > > > > 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 > > > > > > > > > > _______________________________________________ > > Pce mailing list > > Pce@ietf.org > > https://www.ietf.org/mailman/listinfo/pce > From nobody Mon Jul 27 07:52:17 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 572453A1EBD; Mon, 27 Jul 2020 07:52:09 -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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 X2S5_ltXwQ_W; Mon, 27 Jul 2020 07:52:06 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 5C3F03A2260; Mon, 27 Jul 2020 07:49:11 -0700 (PDT) Received: from lhreml733-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 9570ACDDFB35CA0B9F2F; Mon, 27 Jul 2020 15:49:09 +0100 (IST) Received: from fraeml713-chm.china.huawei.com (10.206.15.32) by lhreml733-chm.china.huawei.com (10.201.108.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 27 Jul 2020 15:49:09 +0100 Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml713-chm.china.huawei.com (10.206.15.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 27 Jul 2020 16:49:08 +0200 Received: from fraeml714-chm.china.huawei.com ([10.206.15.33]) by fraeml714-chm.china.huawei.com ([10.206.15.33]) with mapi id 15.01.1913.007; Mon, 27 Jul 2020 16:49:08 +0200 From: Giuseppe Fioccola To: Dhruv Dhody CC: "pce@ietf.org" , "draft-chen-pce-sr-policy-ifit@ietf.org" Thread-Topic: [Pce] FW: New Version Notification for draft-chen-pce-sr-policy-ifit-02.txt Thread-Index: AQHWVrWTo11OSzKFj0aAKKzFdsHG3akAw5cggBj0HwCAAbKhwA== Date: Mon, 27 Jul 2020 14:49:08 +0000 Message-ID: <817642cbc828413983c4260f5e4ac8ab@huawei.com> References: <159438406431.12133.11734833260610050043@ietfa.amsl.com> <0b290b63152b4448a950b291b5960fb3@huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.48.223.178] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Pce] FW: New Version Notification for draft-chen-pce-sr-policy-ifit-02.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 14:52:16 -0000 SGkgRGhydXYsDQpUaGFua3MgYSBsb3QgZm9yIHRoZSByZXZpZXcgYW5kIGZvciB0aGUgc3VnZ2Vz dGlvbnMuDQpQbGVhc2UgZmluZCBteSBhbnN3ZXJzIGlubGluZSB0YWdnZWQgYXMgW0dGXS4NCg0K UmVnYXJkcywNCg0KR2l1c2VwcGUNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IERocnV2IERob2R5IFttYWlsdG86ZGhydXYuaWV0ZkBnbWFpbC5jb21dIA0KU2VudDogU3VuZGF5 LCBKdWx5IDI2LCAyMDIwIDE6NTMgUE0NClRvOiBHaXVzZXBwZSBGaW9jY29sYSA8Z2l1c2VwcGUu ZmlvY2NvbGFAaHVhd2VpLmNvbT4NCkNjOiBwY2VAaWV0Zi5vcmc7IGRyYWZ0LWNoZW4tcGNlLXNy LXBvbGljeS1pZml0QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1BjZV0gRlc6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtY2hlbi1wY2Utc3ItcG9saWN5LWlmaXQtMDIudHh0DQoN CkhpIEdpdXNlcHBlLA0KDQpUaGFua3MgZm9yIGxldHRpbmcgdGhlIFdHIGtub3cgYWJvdXQgeW91 ciBJLUQuDQoNCjx3Zy1jb250cmlidXRvcj4NCkkgaGF2ZSBzb21lIHN1Z2dlc3Rpb25zIHRvIGlt cHJvdmUgdGhpcyBJLUQgLQ0KDQooMCkgQ2FuIHRoZXNlIFRMVnMgYmUgY2FycmllZCBpbnNpZGUg dGhlIExTUEEgb2JqZWN0LCBhbmQgYWxsb3cgdGhlIElGSVQgdG8gYmUgdXNlZCBmb3IgYWxsIHBh dGhzIChpbmNsdWRpbmcgU1IsIFNSdjYsIFJTVlAtVEUsIFBDRUNDLCBldGMpLiBJIHVuZGVyc3Rh bmQgdGhhdCB5b3VyIGtleSBjYXNlIGlzIHdpdGggU1ItUG9saWN5IGJ1dCBpdCBpcyBiZXR0ZXIg dG8gcHV0IHRoZSBUTFZzIGluIGEgZ2VuZXJpYyBvYmplY3QgcmF0aGVyIHRoYW4gaW4gYW4gU1Ig c3BlY2lmaWMgb25lLiBJIGFtIGd1ZXNzaW5nIHlvdSBtaWdodCBiZSBpbmZsdWVuY2VkIGJ5IEJH UCBTUiBQb2xpY3kgKHdoZXJlIGl0IG1ha2VzIHNlbnNlIHRvIGxpbWl0IGl0IHRvIFNSLVBvbGlj eSBhcyBCR1AgaXMgdXNlZCBvbmx5IGZvcg0KU1ItUG9saWN5KSBidXQgaW4gdGhlIGNhc2Ugb2Yg UENFUCwgbWFraW5nIGl0IGdlbmVyaWMgaXMgYSBiZXR0ZXIgaWRlYSBJTUhPLg0KDQpbR0ZdOiBX ZSBjYW4gc3VyZWx5IG1ha2UgaXQgZ2VuZXJpYyBhbmQgZGVmaW5lIHRoZSBzYW1lIFRMVnMgY2Fy cmllZCBpbnNpZGUgdGhlIExTUEEgb2JqZWN0IGluIG9yZGVyIHRvIGJlIGFwcGxpZWQgZm9yIGFs bCBwYXRoIHR5cGVzLCBhcyBsb25nIGFzIHRoZXkgc3VwcG9ydCB0aGUgcmVsZXZhbnQgZGF0YSBw bGFuZSB0ZWxlbWV0cnkgbWV0aG9kLiBUaGUgY3VycmVudCB2ZXJzaW9uIG9mIHRoZSBkcmFmdCBh bHJlYWR5IG1lbnRpb25zIHRoZSBwb3NzaWJpbGl0eSB0byBnZW5lcmFsaXplIHRoZSBwcm9wb3Nh bCBidXQgdGhyb3VnaCBSRkM4Njk3OiAiTm90ZSB0aGF0IHRoZSBJRklUIGF0dHJpYnV0ZXMgaGVy ZSBkZXNjcmliZWQgY2FuIGFsc28gYmUgZ2VuZXJhbGl6ZWQgYW5kIGluY2x1ZGVkIGFzIFRMVnMg Zm9yIG90aGVyIEFzc29jaWF0aW9uIEdyb3VwcyIuIFdlIG9ubHkgY29uc2lkZXJlZCB0aGUgY2Fz ZSBvZiBTUiBQb2xpY3kgc2luY2UgSU9BTSBhbmQgQWx0ZXJuYXRlIE1hcmtpbmcgYXJlIGJlY29t aW5nIG1hdHVyZSBlc3BlY2lhbGx5IGZvciBTUiwgbG9va2luZyBhdCB0aGUgcmVsZXZhbnQgYWRv cHRlZCB3b3JrIGZvciBkYXRhIHBsYW5lIHRlbGVtZXRyeSAoZS5nLiBmb3IgU1J2NjogZHJhZnQt aWV0Zi02bWFuLWlwdjYtYWx0LW1hcmssIGRyYWZ0LWlldGYtaXBwbS1pb2FtLWlwdjYtb3B0aW9u cykuIEFueXdheSB0aGUgcG9zc2liaWxpdHkgdG8gZ2VuZXJhbGl6ZSB0aGUgcHJvcG9zYWwgY2Fu IGJlIGRpc2N1c3NlZC4gSSBndWVzcyB5b3UgYXJlIGFsc28gc3VnZ2VzdGluZyB0byByZXBsYWNl IHRoaXMgSS1EIHdpdGggYSBuZXcgSS1EIHRoYXQgaGFzIGEgZ2VuZXJhbCBzY29wZSAobm90IGxp bWl0ZWQgdG8gU1IgcG9saWN5LCBhcyBpdCBpcyBub3cpLCBjb3JyZWN0Pw0KDQooMSkgQWRkIGNh cGFiaWxpdHkgZXhjaGFuZ2UgYmV0d2VlbiBQQ0VQIHNwZWFrZXJzIGJ5IGFkZGluZyBhIGZsYWcg aW4gU1ItUENFLUNBUEFCSUxJVFkgU3ViLVRMVi4gUENFIFdHIGhhcyBhIGxvbmcgaGlzdG9yeSBv ZiBleHBsaWNpdCBjYXBhYmlsaXR5IGV4Y2hhbmdlIGluIG9wZW4gYmVmb3JlIHVzaW5nIG5ldyBm ZWF0dXJlcy4NCg0KW0dGXTogR29vZCBzdWdnZXN0aW9uLiBXZSB3aWxsIGFkZCBhIG5ldyBTZWN0 aW9uIGluIHRoZSBuZXh0IHJldmlzaW9uIGFuZCBkZXNjcmliZSBhIG5ldyBTUi1QQ0UtQ0FQQUJJ TElUWSBzdWItVExWIGluc2lkZSB0aGUgUEFUSC1TRVRVUC1UWVBFLUNBUEFCSUxJVFkgVExWIGlu IG9yZGVyIHRvIGFsbG93IGV4cGxpY2l0IGNhcGFiaWxpdHkgZXhjaGFuZ2UuDQoNCigyKSBZb3Ug bmVlZCB0byByZS13cml0ZSBzZWN0aW9uIDUuMSwgaXQgZG9lcyBub3QgY29tZSBhY3Jvc3MgYXMg YW4gZXhhbXBsZSAtIGl0IGRlc2NyaWJlcyBzb21lIG5ldyBwcm9jZWR1cmUgdG8gaGFuZGxlIFNS IFBvbGljeSB0aGF0IGlzIG5vdCBhbGlnbmVkIHdpdGggdGhlIHJlc3Qgb2YgUENFIGRvY3VtZW50 cy4gSSBzdWdnZXN0IGFkZGluZyBhbiBleGFtcGxlIGZpZ3VyZSB3aXRoIGEgUENJbml0aWF0ZSBt ZXNzYWdlIGZyb20gUENFIHRvIFBDQyBjYXJyeWluZyB0aGUgU1IgUG9saWN5L0NhbmRpZGF0ZSBQ YXRoL0lGSVQgYXR0cmlidXRlcyB0byBleHBsYWluIHRoZSBmbG93IHdpdGggYW4gZXhhbXBsZS4N Cg0KW0dGXTogQWdyZWUuIFNlY3Rpb24gNS4xIHdpbGwgYmUgcmV2aXNlZCBpbiB0aGUgbmV4dCB2 ZXJzaW9uIGFuZCwgYXMgeW91IHN1Z2dlc3RlZCwgYSBmaWd1cmUgY2FuIGhlbHAgaW4gdGhpcyBj YXNlIHRvIGRlc2NyaWJlIHRoZSBmbG93Lg0KDQooMykgVGhlIGRvY3VtZW50IGlzIGxpZ2h0IG9u IG1vdGl2YXRpb24sIHlvdSBzYXkgIlNvIHRoYXQgSUZJVCBiZWhhdmlvciBjYW4gYmUgZW5hYmxl ZCBhdXRvbWF0aWNhbGx5IHdoZW4gdGhlIFNSIHBvbGljeSBpcyBhcHBsaWVkIi4NCkkgd2lzaCB5 b3UgY2FuIGV4cGFuZCBvbiB0aGlzIGEgbGl0dGxlIG1vcmUuICBTb21ldGhpbmcgb24gbGluZXMg b2YgLQ0KDQogICBXaGVuIGEgUENFIGlzIHVzZWQgdG8gaW5pdGlhdGUgcGF0aHMgdXNpbmcgUENF UCwgaXQgaXMgaW1wb3J0YW50DQogICB0aGF0IHRoZSBoZWFkIGVuZCBvZiB0aGUgcGF0aCBhbHNv IHVuZGVyc3RhbmRzIHRoZSBJRklUIGJlaGF2aW9yDQogICB0aGF0IGlzIGludGVuZGVkIGZvciB0 aGUgcGF0aC4gV2hlbiBQQ0VQIGlzIGluIHVzZSBmb3IgcGF0aCBpbml0aWF0aW9uDQogICBpdCBt YWtlcyBzZW5zZSBmb3IgdGhhdCBzYW1lIHByb3RvY29sIHRvIGJlIHVzZWQgdG8gYWxzbyBjYXJy eSB0aGUNCiAgIElGSVQgYXR0cmlidXRlcyB0aGF0IGRlc2NyaWJlIHRoZSBJT0FNIGhlYWRlci9w cm9jZWR1cmUgdGhhdCBuZWVkcw0KICAgdG8gYmUgYXBwbGllZCB0byB0aGUgZGF0YSB0aGF0IGZs b3cgdGhvc2UgcGF0aHMuDQoNCltHRl06IFllcywgdGhlIG1vdGl2YXRpb24gcGFydCBhbHNvIG5l ZWRzIHRvIGJlIGV4dGVuZGVkIGFuZCB0aGFua3MgZm9yIHRoZSBpbnB1dCBvbiB0aGlzLg0KDQoo NCkgT25seSBvbmUgb2YgdGhlc2UgVExWcyBjYW4gYmUgZW5hYmxlZCByaWdodD8gVGhpcyBuZWVk cyB0byBiZSBkZXNjcmliZWQuIEFsc28sIGFkZCB0ZXh0IHRvIGRlc2NyaWJlIGRpc2FibGluZyBv ZiBJRklUIG9yIG1ha2luZyBjaGFuZ2VzLiBTb21lIHRpZ2h0ZW5pbmcgb2YgdGhlIHByb2NlZHVy ZSBpcyBuZWVkZWQgaGVyZS4NCg0KW0dGXTogV2UgY2FuIGNlcnRhaW5seSBhZGQgYSBuZXcgc2Vj dGlvbiBhYm91dCB0aGUgcHJvY2VkdXJlIG9mIGVuYWJsaW5nL2Rpc2FibGluZyBvZiBJRklUIGFu ZCBhbHNvIGRlc2NyaWJlIHRoZSBjb2V4aXN0ZW5jZSBvZiBJT0FNIGFuZCBBbHRlcm5hdGUgTWFy a2luZy4NCg0KKDUpIFBDRSB3b3VsZCBuZWVkIHRvIG1haW50YWluIHRoZSB1bmlxdWVuZXNzIG9m IEZsb3cgSUQsIEZsb3dNb25JRCBldGMuIFRoaXMgY2FuIGJlIGhpZ2hsaWdodGVkIHdpdGggYSBy ZWZlcmVuY2UgdG8gb3RoZXIgSS1EcyB0aGF0IGRlc2NyaWJlIHRoZSBwcm9jZWR1cmUuDQoNCltH Rl06IFllcywgSSB3aWxsIHNwZWNpZnkgYmV0dGVyIHRoZSBwcm9jZWR1cmUgaW4gdGhlIG5leHQg dmVyc2lvbi4gDQoNCig2KSBJdCB3b3VsZCBiZSBnb29kIHRvIGFsc28gcG9pbnQgdG8gdGhlIHJl Z2lzdHJpZXMgY3JlYXRlZCBieSBvdGhlciBkb2N1bWVudHMgdGhhdCB3ZSB3b3VsZCBiZSByZS11 c2luZy4NCg0KW0dGXTogT2suDQoNCkkgaG9wZSB5b3UgZmluZCB0aGlzIHVzZWZ1bC4gSSB3b3Vs ZCBlbmNvdXJhZ2UgdGhlIFdHIHRvIHByb3ZpZGUgdGhlaXIgdGhvdWdodHMgYXMgd2VsbC4NCjwv d2ctY29udHJpYnV0b3I+DQoNClRoYW5rcyENCkRocnV2DQoNCk9uIEZyaSwgSnVsIDEwLCAyMDIw IGF0IDg6MjEgUE0gR2l1c2VwcGUgRmlvY2NvbGEgPGdpdXNlcHBlLmZpb2Njb2xhQGh1YXdlaS5j b20+IHdyb3RlOg0KPg0KPiBEZWFyIEFsbCwNCj4gV2UgaGF2ZSByZWNlbnRseSB1cGRhdGVkIGRy YWZ0LWNoZW4tcGNlLXNyLXBvbGljeS1pZml0LiBJdCBhaW1zIHRvIGRlZmluZSB0aGUgRXh0ZW5z aW9ucyB0byBQQ0VQIHRvIGVuYWJsZSBhdXRvbWF0aWNhbGx5IElPQU0gYW5kIEFsdGVybmF0ZSBN YXJraW5nIHdoZW4gdGhlIFNSIHBvbGljeSBpcyBhcHBsaWVkLiBJbiBwYXJ0aWN1bGFyIHdlIGhh dmUgY2xhcmlmaWVkIGJldHRlciB0aGUgUENFUCB1c2FnZSBpbiB0aGlzIHNjZW5hcmlvLg0KPg0K PiBGZWVkYmFja3MgYW5kIHN1Z2dlc3Rpb25zIGFyZSBhbHdheXMgd2VsY29tZS4NCj4NCj4gQmVz dCBSZWdhcmRzLA0KPg0KPiBHaXVzZXBwZQ0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmddDQo+IFNlbnQ6IEZyaWRheSwgSnVseSAxMCwgMjAyMCAyOjI4IFBNDQo+IFRv OiBHaXVzZXBwZSBGaW9jY29sYSA8Z2l1c2VwcGUuZmlvY2NvbGFAaHVhd2VpLmNvbT47IEhhbmcg WXVhbiANCj4gPHl1YW5oYW5nQHVuaW9ucGF5LmNvbT47IEh1YW5hbiBDaGVuIDxjaGVuaHVhbjZA Y2hpbmF0ZWxlY29tLmNuPjsgDQo+IHdhbmd5YWxpIDx3YW5neWFsaTExQGh1YXdlaS5jb20+OyBM aXdlaWRvbmcgKFBvbHkpIA0KPiA8cG9seS5saUBodWF3ZWkuY29tPjsgVGlhbnJhbiBaaG91IDx6 aG91dGlhbnJhbkBodWF3ZWkuY29tPg0KPiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIA0KPiBkcmFmdC1jaGVuLXBjZS1zci1wb2xpY3ktaWZpdC0wMi50eHQNCj4NCj4NCj4g QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWNoZW4tcGNlLXNyLXBvbGljeS1pZml0LTAyLnR4 dA0KPiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEdpdXNlcHBlIEZpb2Njb2xh IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCj4NCj4gTmFtZTogICAgICAgICAg IGRyYWZ0LWNoZW4tcGNlLXNyLXBvbGljeS1pZml0DQo+IFJldmlzaW9uOiAgICAgICAwMg0KPiBU aXRsZTogICAgICAgICAgUENFUCBTUiBQb2xpY3kgRXh0ZW5zaW9ucyB0byBFbmFibGUgSUZJVA0K PiBEb2N1bWVudCBkYXRlOiAgMjAyMC0wNy0xMA0KPiBHcm91cDogICAgICAgICAgSW5kaXZpZHVh bCBTdWJtaXNzaW9uDQo+IFBhZ2VzOiAgICAgICAgICAxMg0KPiBVUkw6ICAgICAgICAgICAgaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWNoZW4tcGNlLXNyLXBvbGlj eS1pZml0LTAyLnR4dA0KPiBTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtY2hlbi1wY2Utc3ItcG9saWN5LWlmaXQvDQo+IEh0bWxpemVkOiAgICAg ICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2hlbi1wY2Utc3ItcG9saWN5LWlm aXQtMDINCj4gSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2h0bWwvZHJhZnQtY2hlbi1wY2Utc3ItcG9saWN5LWlmaXQNCj4gRGlmZjogICAgICAgICAgIGh0 dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1jaGVuLXBjZS1zci1wb2xpY3kt aWZpdC0wMg0KPg0KPiBBYnN0cmFjdDoNCj4gICAgU2VnbWVudCBSb3V0aW5nIChTUikgcG9saWN5 IGlzIGEgc2V0IG9mIGNhbmRpZGF0ZSBTUiBwYXRocyBjb25zaXN0aW5nDQo+ICAgIG9mIG9uZSBv ciBtb3JlIHNlZ21lbnQgbGlzdHMgYW5kIG5lY2Vzc2FyeSBwYXRoIGF0dHJpYnV0ZXMuICBJdA0K PiAgICBlbmFibGVzIGluc3RhbnRpYXRpb24gb2YgYW4gb3JkZXJlZCBsaXN0IG9mIHNlZ21lbnRz IHdpdGggYSBzcGVjaWZpYw0KPiAgICBpbnRlbnQgZm9yIHRyYWZmaWMgc3RlZXJpbmcuICBJbi1z aXR1IEZsb3cgSW5mb3JtYXRpb24gVGVsZW1ldHJ5DQo+ICAgIChJRklUKSByZWZlcnMgdG8gbmV0 d29yayBPQU0gYXBwbGljYXRpb25zIHRoYXQgYXBwbHkgZGF0YXBsYW5lIG9uLQ0KPiAgICBwYXRo IHRlbGVtZXRyeSB0ZWNobmlxdWVzLiAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGV4dGVuc2lvbnMg dG8gUENFUA0KPiAgICB0byBkaXN0cmlidXRlIFNSIHBvbGljaWVzIGNhcnJ5aW5nIElGSVQgaW5m b3JtYXRpb24uICBTbyB0aGF0IElGSVQNCj4gICAgYmVoYXZpb3IgY2FuIGJlIGVuYWJsZWQgYXV0 b21hdGljYWxseSB3aGVuIHRoZSBTUiBwb2xpY3kgaXMgYXBwbGllZC4NCj4NCj4NCj4NCj4NCj4N Cj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20g dGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlm ZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPg0KPiBUaGUgSUVURiBTZWNyZXRh cmlhdA0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiBQY2UgbWFpbGluZyBsaXN0DQo+IFBjZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BjZQ0K From nobody Mon Jul 27 10:16:42 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F2B3A1AF2; Mon, 27 Jul 2020 10:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 11ux08-heiWs; Mon, 27 Jul 2020 10:16:38 -0700 (PDT) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 250AB3A1ADB; Mon, 27 Jul 2020 10:16:38 -0700 (PDT) Received: by mail-il1-x130.google.com with SMTP id b18so8550689ilo.12; Mon, 27 Jul 2020 10:16:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=3SqhW+6FwOK7rptSPSvAx+4OZeOlpOG9R9LrcssKmlA=; b=ZOtbT+hZwhMpqVjXfgl4U86LSXJyuExXmN3yH/MbPRMztjIeXca26Pl/Z+iMfQezpM jr8/0Iy4ajFfCPaMY+Lk0a5cC1iE9hNsH9PmWDZPh7zTbDDCU4Ma/lhlByYlBv2OgEMu XWHwIUHvBKirB91g71SEB94mQ+8XaJCfMzy6yFp063To06lOhN03Z4TS5NJVLxyoIxGb yxtJpcdt6fa2QVOJQVY+RQXxmfJ8YkwqxUJ5x775nsdzXvV7XmOLE4PJXekamXL/DNUE EWSh+M7G/XIBU5MYWGC0BicS76R4R+uPlA5qYWhN1JgODBL24pGod/PXFpeX4zgqHis+ hkSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=3SqhW+6FwOK7rptSPSvAx+4OZeOlpOG9R9LrcssKmlA=; b=WTcBXdxXnDXyN90SYPzv/nTLhd/QslGxZDd8XlMUtM8v87sNZMRu4ovMpA+PM3P4iF OXbbBans/9ioFMRFRQtKNDPgxOrKlg1eUlk6nr/4+98O9BXpx1S+OkalIZBCk8HpevFw udocHbY7RgbnI8N0WBcYHjlime4Xp0L5N7TcStmofvOoG2mZ9hdqJhajIdkBRgzSeW9n BN62uzvbZxiWuT1plTmIs1rQKupCL7fbNbR31EUSvYDtEDVxyhC8Xc+EX8Z7sZCg6tAl WBz2nIzOSoLZHKvWdfzjD3kEu8im5vqPAUKfNH1CAbA+Mpek3TxP4/4Tt11IznIvnKRG WnAQ== X-Gm-Message-State: AOAM531eSbuw+J3Zx8GwlxmQfU6TzTFuZKBGTKNWxkeups1ZLRhM5Itt pDhlnzpy7QXIyxaMFKFng2gwg+mQ6vVFzZnnj2Y= X-Google-Smtp-Source: ABdhPJy8V36WI6u+zqTC70XTXmkbu1xyTwY7BN/DyvJfNUIGBajv4MBgq1xaNQzVmIgk7Gu1Py4yklz/XG/eLsLmjrk= X-Received: by 2002:a92:9a84:: with SMTP id c4mr15583770ill.1.1595870197112; Mon, 27 Jul 2020 10:16:37 -0700 (PDT) MIME-Version: 1.0 References: <159438406431.12133.11734833260610050043@ietfa.amsl.com> <0b290b63152b4448a950b291b5960fb3@huawei.com> <817642cbc828413983c4260f5e4ac8ab@huawei.com> In-Reply-To: <817642cbc828413983c4260f5e4ac8ab@huawei.com> From: Dhruv Dhody Date: Mon, 27 Jul 2020 22:46:00 +0530 Message-ID: To: Giuseppe Fioccola Cc: "pce@ietf.org" , "draft-chen-pce-sr-policy-ifit@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Pce] FW: New Version Notification for draft-chen-pce-sr-policy-ifit-02.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 17:16:40 -0000 Hi Giuseppe, Snipping to... > (0) Can these TLVs be carried inside the LSPA object, and allow the IFIT = to be used for all paths (including SR, SRv6, RSVP-TE, PCECC, etc). I under= stand that your key case is with SR-Policy but it is better to put the TLVs= in a generic object rather than in an SR specific one. I am guessing you m= ight be influenced by BGP SR Policy (where it makes sense to limit it to SR= -Policy as BGP is used only for > SR-Policy) but in the case of PCEP, making it generic is a better idea IM= HO. > > [GF]: We can surely make it generic and define the same TLVs carried insi= de the LSPA object in order to be applied for all path types, as long as th= ey support the relevant data plane telemetry method. The current version of= the draft already mentions the possibility to generalize the proposal but = through RFC8697: "Note that the IFIT attributes here described can also be = generalized and included as TLVs for other Association Groups". [Dhruv]: Encoding these TLVs in an ASSOCIATION object of any type would not be the best encoding option in my opinion. The association types already defined are Protection, Diversity, Policy, and the next set coming up are Bi-direction (multiple types), VN association, SR policy etc. It would be out of place to put IFIT attribute TLV in all these associations. LSPA object seems to be a better place to encode and would be applicable to all path-setup-types by default. Check out RFC 8733 on how to use LSPA to encode new attributes. > We only considered the case of SR Policy since IOAM and Alternate Marking= are becoming mature especially for SR, looking at the relevant adopted wor= k for data plane telemetry (e.g. for SRv6: draft-ietf-6man-ipv6-alt-mark, d= raft-ietf-ippm-ioam-ipv6-options). Anyway the possibility to generalize the= proposal can be discussed. I guess you are also suggesting to replace this= I-D with a new I-D that has a general scope (not limited to SR policy, as = it is now), correct? [Dhruv] Let's continue to discuss during the meeting tomorrow. Thanks! Dhruv From nobody Mon Jul 27 12:29:24 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2CE23A0B32; Mon, 27 Jul 2020 12:29:22 -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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 QDWUzVNLKeyt; Mon, 27 Jul 2020 12:29:20 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 A3E4F3A0B27; Mon, 27 Jul 2020 12:29:20 -0700 (PDT) Received: from lhreml708-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id B2E76A5FF44D47D24890; Mon, 27 Jul 2020 20:29:16 +0100 (IST) Received: from fraeml709-chm.china.huawei.com (10.206.15.37) by lhreml708-chm.china.huawei.com (10.201.108.57) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Mon, 27 Jul 2020 20:29:16 +0100 Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml709-chm.china.huawei.com (10.206.15.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 27 Jul 2020 21:29:16 +0200 Received: from fraeml714-chm.china.huawei.com ([10.206.15.33]) by fraeml714-chm.china.huawei.com ([10.206.15.33]) with mapi id 15.01.1913.007; Mon, 27 Jul 2020 21:29:15 +0200 From: Giuseppe Fioccola To: Dhruv Dhody CC: "pce@ietf.org" , "draft-chen-pce-sr-policy-ifit@ietf.org" Thread-Topic: [Pce] FW: New Version Notification for draft-chen-pce-sr-policy-ifit-02.txt Thread-Index: AQHWVrWTo11OSzKFj0aAKKzFdsHG3akAw5cggBj0HwCAAbKhwIAAOekAgABByvA= Date: Mon, 27 Jul 2020 19:29:15 +0000 Message-ID: References: <159438406431.12133.11734833260610050043@ietfa.amsl.com> <0b290b63152b4448a950b291b5960fb3@huawei.com> <817642cbc828413983c4260f5e4ac8ab@huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.48.216.224] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Pce] FW: New Version Notification for draft-chen-pce-sr-policy-ifit-02.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 19:29:23 -0000 SGkgRGhydXYsDQpQbGVhc2Ugc2VlIGlubGluZSBhcyBbR0ZdDQpSZWdhcmRzLA0KDQpHaXVzZXBw ZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRGhydXYgRGhvZHkgW21haWx0 bzpkaHJ1di5pZXRmQGdtYWlsLmNvbV0gDQpTZW50OiBNb25kYXksIEp1bHkgMjcsIDIwMjAgNzox NiBQTQ0KVG86IEdpdXNlcHBlIEZpb2Njb2xhIDxnaXVzZXBwZS5maW9jY29sYUBodWF3ZWkuY29t Pg0KQ2M6IHBjZUBpZXRmLm9yZzsgZHJhZnQtY2hlbi1wY2Utc3ItcG9saWN5LWlmaXRAaWV0Zi5v cmcNClN1YmplY3Q6IFJlOiBbUGNlXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC1jaGVuLXBjZS1zci1wb2xpY3ktaWZpdC0wMi50eHQNCg0KSGkgR2l1c2VwcGUsDQoNClNu aXBwaW5nIHRvLi4uDQoNCj4gKDApIENhbiB0aGVzZSBUTFZzIGJlIGNhcnJpZWQgaW5zaWRlIHRo ZSBMU1BBIG9iamVjdCwgYW5kIGFsbG93IHRoZSANCj4gSUZJVCB0byBiZSB1c2VkIGZvciBhbGwg cGF0aHMgKGluY2x1ZGluZyBTUiwgU1J2NiwgUlNWUC1URSwgUENFQ0MsIA0KPiBldGMpLiBJIHVu ZGVyc3RhbmQgdGhhdCB5b3VyIGtleSBjYXNlIGlzIHdpdGggU1ItUG9saWN5IGJ1dCBpdCBpcyAN Cj4gYmV0dGVyIHRvIHB1dCB0aGUgVExWcyBpbiBhIGdlbmVyaWMgb2JqZWN0IHJhdGhlciB0aGFu IGluIGFuIFNSIA0KPiBzcGVjaWZpYyBvbmUuIEkgYW0gZ3Vlc3NpbmcgeW91IG1pZ2h0IGJlIGlu Zmx1ZW5jZWQgYnkgQkdQIFNSIFBvbGljeSANCj4gKHdoZXJlIGl0IG1ha2VzIHNlbnNlIHRvIGxp bWl0IGl0IHRvIFNSLVBvbGljeSBhcyBCR1AgaXMgdXNlZCBvbmx5IGZvcg0KPiBTUi1Qb2xpY3kp IGJ1dCBpbiB0aGUgY2FzZSBvZiBQQ0VQLCBtYWtpbmcgaXQgZ2VuZXJpYyBpcyBhIGJldHRlciBp ZGVhIElNSE8uDQo+DQo+IFtHRl06IFdlIGNhbiBzdXJlbHkgbWFrZSBpdCBnZW5lcmljIGFuZCBk ZWZpbmUgdGhlIHNhbWUgVExWcyBjYXJyaWVkIGluc2lkZSB0aGUgTFNQQSBvYmplY3QgaW4gb3Jk ZXIgdG8gYmUgYXBwbGllZCBmb3IgYWxsIHBhdGggdHlwZXMsIGFzIGxvbmcgYXMgdGhleSBzdXBw b3J0IHRoZSByZWxldmFudCBkYXRhIHBsYW5lIHRlbGVtZXRyeSBtZXRob2QuIFRoZSBjdXJyZW50 IHZlcnNpb24gb2YgdGhlIGRyYWZ0IGFscmVhZHkgbWVudGlvbnMgdGhlIHBvc3NpYmlsaXR5IHRv IGdlbmVyYWxpemUgdGhlIHByb3Bvc2FsIGJ1dCB0aHJvdWdoIFJGQzg2OTc6ICJOb3RlIHRoYXQg dGhlIElGSVQgYXR0cmlidXRlcyBoZXJlIGRlc2NyaWJlZCBjYW4gYWxzbyBiZSBnZW5lcmFsaXpl ZCBhbmQgaW5jbHVkZWQgYXMgVExWcyBmb3Igb3RoZXIgQXNzb2NpYXRpb24gR3JvdXBzIi4NCg0K W0RocnV2XTogRW5jb2RpbmcgdGhlc2UgVExWcyBpbiBhbiBBU1NPQ0lBVElPTiBvYmplY3Qgb2Yg YW55IHR5cGUgd291bGQgbm90IGJlIHRoZSBiZXN0IGVuY29kaW5nIG9wdGlvbiBpbiBteSBvcGlu aW9uLiBUaGUgYXNzb2NpYXRpb24gdHlwZXMgYWxyZWFkeSBkZWZpbmVkIGFyZSBQcm90ZWN0aW9u LCBEaXZlcnNpdHksIFBvbGljeSwgYW5kIHRoZSBuZXh0IHNldCBjb21pbmcgdXAgYXJlIEJpLWRp cmVjdGlvbiAobXVsdGlwbGUgdHlwZXMpLCBWTiBhc3NvY2lhdGlvbiwgU1IgcG9saWN5IGV0Yy4g SXQgd291bGQgYmUgb3V0IG9mIHBsYWNlIHRvIHB1dCAgSUZJVCBhdHRyaWJ1dGUgVExWIGluIGFs bCB0aGVzZSBhc3NvY2lhdGlvbnMuDQoNCltHRl06IEkgc2VlIHlvdXIgcG9pbnQuIFNpbmNlIHdl IHN0YXJ0ZWQgdG8gZm9jdXMgb24gU1IsIGluIHRoZSBjb250ZXh0IG9mIGRyYWZ0LWlldGYtcGNl LXNlZ21lbnQtcm91dGluZy1wb2xpY3ktY3AsIGl0IG1ha2VzIHNlbnNlIHRvIGFkZCBJRklUIGF0 dHJpYnV0ZSBUTFYgdG8gdGhlIFNSUEFHLiBCdXQsIGxvb2tpbmcgYXQgdGhlIGFzc29jaWF0aW9u IHR5cGVzIGFscmVhZHkgZGVmaW5lZCwgSSBhZ3JlZSwgdGhlIElGSVQgYXR0cmlidXRlIFRMVnMg Y2Fubm90IGJlIGdlbmVyYWxpemVkIGluIHRoaXMgd2F5Lg0KDQpMU1BBIG9iamVjdCBzZWVtcyB0 byBiZSBhIGJldHRlciBwbGFjZSB0byBlbmNvZGUgYW5kIHdvdWxkIGJlIGFwcGxpY2FibGUgdG8g YWxsIHBhdGgtc2V0dXAtdHlwZXMgYnkgZGVmYXVsdC4gQ2hlY2sgb3V0IFJGQyA4NzMzIG9uIGhv dyB0byB1c2UgTFNQQSB0byBlbmNvZGUgbmV3IGF0dHJpYnV0ZXMuDQoNCltHRl06IFRoYW5rcyBm b3IgdGhlIHJlZmVyZW5jZS4gSSB3aWxsIGhhdmUgYSBsb29rIGF0IFJGQzg3MzMuDQoNCj4gV2Ug b25seSBjb25zaWRlcmVkIHRoZSBjYXNlIG9mIFNSIFBvbGljeSBzaW5jZSBJT0FNIGFuZCBBbHRl cm5hdGUgTWFya2luZyBhcmUgYmVjb21pbmcgbWF0dXJlIGVzcGVjaWFsbHkgZm9yIFNSLCBsb29r aW5nIGF0IHRoZSByZWxldmFudCBhZG9wdGVkIHdvcmsgZm9yIGRhdGEgcGxhbmUgdGVsZW1ldHJ5 IChlLmcuIGZvciBTUnY2OiBkcmFmdC1pZXRmLTZtYW4taXB2Ni1hbHQtbWFyaywgZHJhZnQtaWV0 Zi1pcHBtLWlvYW0taXB2Ni1vcHRpb25zKS4gQW55d2F5IHRoZSBwb3NzaWJpbGl0eSB0byBnZW5l cmFsaXplIHRoZSBwcm9wb3NhbCBjYW4gYmUgZGlzY3Vzc2VkLiBJIGd1ZXNzIHlvdSBhcmUgYWxz byBzdWdnZXN0aW5nIHRvIHJlcGxhY2UgdGhpcyBJLUQgd2l0aCBhIG5ldyBJLUQgdGhhdCBoYXMg YSBnZW5lcmFsIHNjb3BlIChub3QgbGltaXRlZCB0byBTUiBwb2xpY3ksIGFzIGl0IGlzIG5vdyks IGNvcnJlY3Q/DQoNCltEaHJ1dl0gTGV0J3MgY29udGludWUgdG8gZGlzY3VzcyBkdXJpbmcgdGhl IG1lZXRpbmcgdG9tb3Jyb3cuDQoNCltHRl06IFN1cmUuDQoNClRoYW5rcyENCkRocnV2DQo= From nobody Tue Jul 28 15:53:08 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B00613A0A34; Tue, 28 Jul 2020 15:53:06 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 Sgrx8EBIBOld; Tue, 28 Jul 2020 15:53:04 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B16A3A0A00; Tue, 28 Jul 2020 15:53:04 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 7A48DF4073A; Tue, 28 Jul 2020 15:52:38 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, pce@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20200728225238.7A48DF4073A@rfc-editor.org> Date: Tue, 28 Jul 2020 15:52:38 -0700 (PDT) Archived-At: Subject: [Pce] =?utf-8?q?RFC_8800_on_Path_Computation_Element_Communicati?= =?utf-8?q?on_Protocol_=28PCEP=29_Extension_for_Label_Switched_Path_=28LSP?= =?utf-8?q?=29_Diversity_Constraint_Signaling?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 22:53:07 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8800 Title: Path Computation Element Communication Protocol (PCEP) Extension for Label Switched Path (LSP) Diversity Constraint Signaling Author: S. Litkowski, S. Sivabalan, C. Barth, M. Negi Status: Standards Track Stream: IETF Date: July 2020 Mailbox: slitkows.ietf@gmail.com, msiva282@gmail.com, cbarth@juniper.net, mahend.ietf@gmail.com Pages: 21 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pce-association-diversity-15.txt URL: https://www.rfc-editor.org/info/rfc8800 DOI: 10.17487/RFC8800 This document introduces a simple mechanism to associate a group of Label Switched Paths (LSPs) via an extension to the Path Computation Element Communication Protocol (PCEP) with the purpose of computing diverse (disjointed) paths for those LSPs. The proposed extension allows a Path Computation Client (PCC) to advertise to a Path Computation Element (PCE) that a particular LSP belongs to a particular Disjoint Association Group; thus, the PCE knows that the LSPs in the same group need to be disjoint from each other. This document is a product of the Path Computation Element Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. 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/retrieve/bulk 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 From nobody Wed Jul 29 01:07:26 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B6E3A10A3; Wed, 29 Jul 2020 01:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 ruYOBeyX7j_S; Wed, 29 Jul 2020 01:07:19 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 014B33A10D1; Wed, 29 Jul 2020 01:07:14 -0700 (PDT) Received: from [192.168.1.19] (unknown [122.2.101.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id A9B3C326A46; Wed, 29 Jul 2020 10:07:11 +0200 (CEST) To: draft-xiong-pce-lsp-flag@ietf.org, "pce-chairs@ietf.org" From: Loa Andersson Cc: "pce@ietf.org" Message-ID: <138eecce-8db7-90da-d6e8-b006ee4ddc8e@pi.nu> Date: Wed, 29 Jul 2020 16:07:07 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Pce] cursory review of draft-xiong-pce-lsp-flag X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 08:07:25 -0000 Quan, I have not done a comprehensive review of the document, but from what I see it is a well written and much needed document. I would advice to run the working group adoption poll as soon as possible. I have one comment and one question. Comment: 5.2. PCEP-Error Object IANA is requested to register the following error types and error values within the "PCEP-ERROR Object Error Types and Values" subregistry of the "Path Computation Element Protocol (PCEP) Numbers" registry: +--------------+-------------------------------------+ | Error-Type | Meaning | +--------------+-------------------------------------+ | 6 | Mandatory Object missing | | | Error-value | | | TBD2: LSP-EXTENDED-FLAG TLV missing | +--------------+-------------------------------------+ Table 2 Both the RTG DIR rules and IANA rules strongly advice against putting fixed numeric values into allocation from existing registries. The reason is obvious, in the time from you put the value in your document until iet is ready for IESG review (which includes IANA review) someone else might have been assigned tht value. This has happened and have caused serious problems. 6 in table 2 hould be replaced with TBA (to be assigned). Note: If you really want the value 6, we should go for an early allocation as soon as we have the wg document. Question: In section 4 you say: The LSP-EXTENDED-FLAG TLV MUST be defined as mandatory when a router supporting the LSP Object and needs to use the extended flag field. I don't really parse; are you saying that if it is present it should be treated as mandatory? If that is what you are saying, what does it change? /Loa -- Loa Andersson email: loa@pi.nu Senior MPLS Expert loa.pi.nu@gmail.com Bronze Dragon Consulting phone: +46 739 81 21 64 From nobody Wed Jul 29 02:01:34 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 865203A0A02 for ; Wed, 29 Jul 2020 02:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dhruvdhody-com.20150623.gappssmtp.com 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 tWGSUJU6qFEE for ; Wed, 29 Jul 2020 02:01:29 -0700 (PDT) Received: from mail-pg1-x542.google.com (mail-pg1-x542.google.com [IPv6:2607:f8b0:4864:20::542]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6EB33A0AB0 for ; Wed, 29 Jul 2020 02:01:29 -0700 (PDT) Received: by mail-pg1-x542.google.com with SMTP id h12so2551946pgf.7 for ; Wed, 29 Jul 2020 02:01:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dhruvdhody-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8GPWaM7ZK8FBNonlBhpyyxhHHn7F65adwSkjRD5rkBU=; b=lN9y+I+G8t17f7tjb27HxYVb/T7qcs/ll7uzm59TmLSRsdPLeSOjowgER9Mbh3sky9 bIl0cjIQetW+SJt6gx6w/kSvMt29dWR00pJEVoXWyEoVhsV7SAzffjdiIZBocoN2q1lq p6RUrswE/du3mr+rpjwo3H6mr7O4asHlUSU7/zs2I8uUI6SPOHIc1BWMWzcenGApZJ26 OMcTeB2WGTJwrTqiBkCTWcpMZ9AK51DtqYR0sABSAj6o508xBqG/vpsyS+JhayGhPIZI J/49gvE8kXyn28xm73KEfh406M39n1YmAlGqC37dMY9mopRHQbj2aFXDXRcgTT/u+PCQ STbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8GPWaM7ZK8FBNonlBhpyyxhHHn7F65adwSkjRD5rkBU=; b=aFHjA8PIa4Q22ztFYKinOWi2PmFAQb0mgQOTKb7WBkmg20hM8RnQQLg1SA+GBNPb6p 1LdinhsEAB006dVJ0T3sA40koHcxfsH0oYYt3emG7KRsUHCQ2m5H6s76R5u+CscRaFug +KF71PSpX3/UsgmCC5u+vAIZU24vSuoTkH5jwPBKlbNv7S4XTcsXX/z5cRDJiHfMRJAQ mBRbgqwjjo5AnhpcKcYJxT8p6SnQvBn7xBb0BAzktn5fBzaSGO8WSFfKweSYSp6+2Jon RSqdIQ5niXbdRokFrnPvaLB8oWUOipAF2a5FhuLXKsTy5xLpXo0jrvlNlcWOhmFqczhm L1Tw== X-Gm-Message-State: AOAM531LDIcObQnxuqefZraJJnuJAvvEuJRBvT2t3it9W/mz355uNslb lgNymU1gh7CQ/l4MagI4tHQgo5PmXhyHuP8c96mqBEYXR4PlBQ== X-Google-Smtp-Source: ABdhPJyXGOYfzsubKMKBPMHPwfy4Cbvf2MVf5sfocKEYIlU/cfy017Ok4s6M5tpclXbXBi2vspE4UNtZCKgT1+TIijQ= X-Received: by 2002:a63:920b:: with SMTP id o11mr29378187pgd.447.1596013288889; Wed, 29 Jul 2020 02:01:28 -0700 (PDT) MIME-Version: 1.0 References: <138eecce-8db7-90da-d6e8-b006ee4ddc8e@pi.nu> In-Reply-To: <138eecce-8db7-90da-d6e8-b006ee4ddc8e@pi.nu> From: Dhruv Dhody Date: Wed, 29 Jul 2020 14:31:17 +0530 Message-ID: To: Loa Andersson Cc: draft-xiong-pce-lsp-flag@ietf.org, "pce-chairs@ietf.org" , "pce@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Pce] cursory review of draft-xiong-pce-lsp-flag X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 09:01:32 -0000 Hi Loa, > Comment: > > 5.2. PCEP-Error Object > > IANA is requested to register the following error types and error > values within the "PCEP-ERROR Object Error Types and Values" > subregistry of the "Path Computation Element Protocol (PCEP) Numbers" > registry: > > +--------------+-------------------------------------+ > | Error-Type | Meaning | > +--------------+-------------------------------------+ > | 6 | Mandatory Object missing | > | | Error-value | > | | TBD2: LSP-EXTENDED-FLAG TLV missing | > +--------------+-------------------------------------+ > > Table 2 > > Both the RTG DIR rules and IANA rules strongly advice against putting > fixed numeric values into allocation from existing registries. The > reason is obvious, in the time from you put the value in your document > until iet is ready for IESG review (which includes IANA review) someone > else might have been assigned tht value. This has happened and have > caused serious problems. > > 6 in table 2 hould be replaced with TBA (to be assigned). > > Note: If you really want the value 6, we should go for an early > allocation as soon as we have the wg document. > [Dhruv] The value 6 is for Error-Type already allocated by RFC 5440. This I-D is asking for a new Error-Value which is TBD2. A reference column in the IANA table would have helped here. > Question: > > In section 4 you say: > > The LSP-EXTENDED-FLAG TLV MUST be defined as mandatory when a router > supporting the LSP Object and needs to use the extended flag field. > > I don't really parse; are you saying that if it is present it should be > treated as mandatory? > > If that is what you are saying, what does it change? > [Dhruv]: I read it as a requirement for a future extension that would define a flag in the LSP-EXTENDED-FLAG TLV. If that is true, I would suggest not using normative MUST. How about - A future extension that defines a flag in the LSP-EXTENDED-FLAG TLV could mark this TLV as mandatory to be carried the LSP Object. Thanks! Dhruv > /Loa > > > -- > > Loa Andersson email: loa@pi.nu > Senior MPLS Expert loa.pi.nu@gmail.com > Bronze Dragon Consulting phone: +46 739 81 21 64 From nobody Wed Jul 29 03:43:57 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 027FC3A0919; Wed, 29 Jul 2020 03:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 F0G0hE8jau0P; Wed, 29 Jul 2020 03:43:49 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B3A43A0901; Wed, 29 Jul 2020 03:43:47 -0700 (PDT) Received: from [192.168.1.19] (unknown [122.2.101.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 499D0326A68; Wed, 29 Jul 2020 12:43:42 +0200 (CEST) To: Dhruv Dhody Cc: draft-xiong-pce-lsp-flag@ietf.org, "pce-chairs@ietf.org" , "pce@ietf.org" References: <138eecce-8db7-90da-d6e8-b006ee4ddc8e@pi.nu> From: Loa Andersson Message-ID: <123c58ae-390b-28a0-01bb-4cc467272877@pi.nu> Date: Wed, 29 Jul 2020 18:43:25 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Pce] cursory review of draft-xiong-pce-lsp-flag X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 10:43:56 -0000 Dhruv, Inline please. On 29/07/2020 17:01, Dhruv Dhody wrote: > Hi Loa, > >> Comment: >> >> 5.2. PCEP-Error Object >> >> IANA is requested to register the following error types and error >> values within the "PCEP-ERROR Object Error Types and Values" >> subregistry of the "Path Computation Element Protocol (PCEP) Numbers" >> registry: >> >> +--------------+-------------------------------------+ >> | Error-Type | Meaning | >> +--------------+-------------------------------------+ >> | 6 | Mandatory Object missing | >> | | Error-value | >> | | TBD2: LSP-EXTENDED-FLAG TLV missing | >> +--------------+-------------------------------------+ >> >> Table 2 >> >> Both the RTG DIR rules and IANA rules strongly advice against putting >> fixed numeric values into allocation from existing registries. The >> reason is obvious, in the time from you put the value in your document >> until iet is ready for IESG review (which includes IANA review) someone >> else might have been assigned tht value. This has happened and have >> caused serious problems. >> >> 6 in table 2 hould be replaced with TBA (to be assigned). >> >> Note: If you really want the value 6, we should go for an early >> allocation as soon as we have the wg document. >> > > [Dhruv] The value 6 is for Error-Type already allocated by RFC 5440. > This I-D is asking for a new Error-Value which is TBD2. A reference > column in the IANA table would have helped here. hmmmm - okey, but no, we are asking IANA to register a new error-value, but not a new error type. The text says: "IANA is requested to register the following error types and error values ..." But then the table is very unclear, at a minimum it should look something like this: +-------------+----------------------------+-------------------------+ | Error-Type | Meaning | Error-value | +-------------+----------------------------+-------------------------+ | 6 | Mandatory Object missing | 0: Unassigned | | | | 1-15 Assigned | | | | TBD2: LSP-EXTENDED-FLAG | | | | TLV missing | +-------------+----------------------------+-------------------------+ Table 2 > >> Question: >> >> In section 4 you say: >> >> The LSP-EXTENDED-FLAG TLV MUST be defined as mandatory when a router >> supporting the LSP Object and needs to use the extended flag field. >> >> I don't really parse; are you saying that if it is present it should be >> treated as mandatory? >> >> If that is what you are saying, what does it change? >> > > [Dhruv]: I read it as a requirement for a future extension that would > define a flag in the LSP-EXTENDED-FLAG TLV. > > If that is true, I would suggest not using normative MUST. How about - > > A future extension that defines a flag in the LSP-EXTENDED-FLAG TLV > could mark this TLV as mandatory to be carried the LSP Object. I have been reading a bit more, but this is still unclear to me, if I understand it will still be valid to send without the extended TLV (if you don't need the flags). How are you deciding if the extended TLV missing? /Loa > > Thanks! > Dhruv > >> /Loa >> >> >> -- >> >> Loa Andersson email: loa@pi.nu >> Senior MPLS Expert loa.pi.nu@gmail.com >> Bronze Dragon Consulting phone: +46 739 81 21 64 -- Loa Andersson email: loa@pi.nu Senior MPLS Expert loa.pi.nu@gmail.com Bronze Dragon Consulting phone: +46 739 81 21 64 From nobody Wed Jul 29 04:15:18 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 549D23A0920 for ; Wed, 29 Jul 2020 04:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dhruvdhody-com.20150623.gappssmtp.com 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 5yMdCNTOeRzf for ; Wed, 29 Jul 2020 04:15:16 -0700 (PDT) Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E990E3A091B for ; Wed, 29 Jul 2020 04:15:15 -0700 (PDT) Received: by mail-pj1-x102d.google.com with SMTP id k1so1718580pjt.5 for ; Wed, 29 Jul 2020 04:15:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dhruvdhody-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=adu54y1HVCpwN0BPA6XMF1bt8bdVraIqVYLQ5lbeYZs=; b=GWvzPr94yUafoHCNOVP3XT1f7z/9sjbj8ZHNgt74jiLTcZmpdi5eyXQKrMGbFUR1fz twa/xPvaXtb5eWR07yOfySYRYl7zHpuGB6K4XehKd3PoQPBvvOrrGV5YPzGB4//eHxtg ziaBMhrzN3SjJoh+ompyjOxqdzO4PijRb+2Jxkdy4UBPeawxDtH1+7/g4UhR/98+KXRZ PNdGBxnsbHxtTCDW6JI9mNTHGojmi/TBnSTBNW5SnZgrlWdoxY6v+1rtBmLwMx6lrvLu 7uQXUeqhIvwIqPlxycmhsAzkmyDPFnBIkXG07z7LVSqNoc1xumLw/nZBtcjmzp8pGpSW sHUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=adu54y1HVCpwN0BPA6XMF1bt8bdVraIqVYLQ5lbeYZs=; b=DBjAoGKl0JVS53O8tGEXzd53T554VAUfn70oOQ3W88hAqBiZ7BJWTiOSPEQ4+W4r/Z iy0J8fFAgQIDEJK6MLv2q1AsrSfk5Z2j09YYjEO2CUbVbAhWpsnAaVvropoHPRFsPHFJ hHrVzZMBq4eqDVP1m6GDyjV3lqb/cFwq+2WLDtn844FHE6uDfFjtHkMNopNL95YlERg8 n2q6Nc2X4LDbyqWcLCv8wji6jxDZs+Am+B63DHH1THzCo3NijDSmUduXEfFAn3myAPpt XyDs5uITlNHfdbw5UI9qVE2wfgaB5YvBAMMyQIgT70KEU+NZk68fV/Ms5kwPBLu9CEMC J7rg== X-Gm-Message-State: AOAM531a3B6X8fDBZS3EZEVqFIrmu5v/DJbmuccn8LXkuzHnVHa3W3ky w3uNiQhX2crE6T/yGnzD2SCwDTUM8eLf6B0MfTlCNw== X-Google-Smtp-Source: ABdhPJz6Vb9PcHLQz+mBc7LvTMrk8Fw/S1g+ojX3I+9oV4Qkz5BWlWs1bfQd+paoy+IQ4+Z0wIJzcKoegMvMFCxDYVU= X-Received: by 2002:a17:90a:338a:: with SMTP id n10mr9657400pjb.50.1596021314964; Wed, 29 Jul 2020 04:15:14 -0700 (PDT) MIME-Version: 1.0 References: <138eecce-8db7-90da-d6e8-b006ee4ddc8e@pi.nu> <123c58ae-390b-28a0-01bb-4cc467272877@pi.nu> In-Reply-To: <123c58ae-390b-28a0-01bb-4cc467272877@pi.nu> From: Dhruv Dhody Date: Wed, 29 Jul 2020 16:45:03 +0530 Message-ID: To: Loa Andersson Cc: draft-xiong-pce-lsp-flag@ietf.org, "pce-chairs@ietf.org" , "pce@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Pce] cursory review of draft-xiong-pce-lsp-flag X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 11:15:17 -0000 Hi Loa, On Wed, Jul 29, 2020 at 4:13 PM Loa Andersson wrote: > > Dhruv, > > Inline please. > > On 29/07/2020 17:01, Dhruv Dhody wrote: > > Hi Loa, > > > >> Comment: > >> > >> 5.2. PCEP-Error Object > >> > >> IANA is requested to register the following error types and error > >> values within the "PCEP-ERROR Object Error Types and Values" > >> subregistry of the "Path Computation Element Protocol (PCEP) Numbers" > >> registry: > >> > >> +--------------+-------------------------------------+ > >> | Error-Type | Meaning | > >> +--------------+-------------------------------------+ > >> | 6 | Mandatory Object missing | > >> | | Error-value | > >> | | TBD2: LSP-EXTENDED-FLAG TLV missing | > >> +--------------+-------------------------------------+ > >> > >> Table 2 > >> > >> Both the RTG DIR rules and IANA rules strongly advice against putting > >> fixed numeric values into allocation from existing registries. The > >> reason is obvious, in the time from you put the value in your document > >> until iet is ready for IESG review (which includes IANA review) someone > >> else might have been assigned tht value. This has happened and have > >> caused serious problems. > >> > >> 6 in table 2 hould be replaced with TBA (to be assigned). > >> > >> Note: If you really want the value 6, we should go for an early > >> allocation as soon as we have the wg document. > >> > > > > [Dhruv] The value 6 is for Error-Type already allocated by RFC 5440. > > This I-D is asking for a new Error-Value which is TBD2. A reference > > column in the IANA table would have helped here. > > hmmmm - okey, but no, we are asking IANA to register a new error-value, > but not a new error type. The text says: > > "IANA is requested to register the following error types and error > values ..." > This text is incorrect then and should be fixed. > But then the table is very unclear, at a minimum it should look > something like this: > > +-------------+----------------------------+-------------------------+ > | Error-Type | Meaning | Error-value | > +-------------+----------------------------+-------------------------+ > | 6 | Mandatory Object missing | 0: Unassigned | > | | | 1-15 Assigned | > | | | TBD2: LSP-EXTENDED-FLAG | > | | | TLV missing | > +-------------+----------------------------+-------------------------+ > > Table 2 > Yes. I suggest Quan to look at - https://www.rfc-editor.org/rfc/rfc8800.html#section-7.5 as a good reference from a recent published RFC. > > > > >> Question: > >> > >> In section 4 you say: > >> > >> The LSP-EXTENDED-FLAG TLV MUST be defined as mandatory when a router > >> supporting the LSP Object and needs to use the extended flag field. > >> > >> I don't really parse; are you saying that if it is present it should be > >> treated as mandatory? > >> > >> If that is what you are saying, what does it change? > >> > > > > [Dhruv]: I read it as a requirement for a future extension that would > > define a flag in the LSP-EXTENDED-FLAG TLV. > > > > If that is true, I would suggest not using normative MUST. How about - > > > > A future extension that defines a flag in the LSP-EXTENDED-FLAG TLV > > could mark this TLV as mandatory to be carried the LSP Object. > > I have been reading a bit more, but this is still unclear to me, if I > understand it will still be valid to send without the extended TLV > (if you don't need the flags). Yes! Maybe we should not use the word "mandatory" then! As it is "mandatory" in the context of using a new feature defined in a future extension -- so to use the new feature, an implementation MUST include the LSP-EXTENDED-FLAG TLV and MUST set a particular flag. The so-called "mandatory" would be only in the scope of the protocol extension and not required when the feature is not used. > How are you deciding if the extended TLV > missing? > This could be because of the presence of some other object/TLVs needed by the same extension but without the LSP-EXTENDED-FLAG TLV in the LSP object. Perhaps the right thing to do would be to move the error handling to the first document that uses the LSP-EXTENDED-FLAG TLV instead of this document. Thanks! Dhruv > > /Loa > > > > Thanks! > > Dhruv > > > >> /Loa > >> > >> > >> -- > >> > >> Loa Andersson email: loa@pi.nu > >> Senior MPLS Expert loa.pi.nu@gmail.com > >> Bronze Dragon Consulting phone: +46 739 81 21 64 > > -- > > Loa Andersson email: loa@pi.nu > Senior MPLS Expert loa.pi.nu@gmail.com > Bronze Dragon Consulting phone: +46 739 81 21 64 From nobody Wed Jul 29 19:30:52 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC9D3A0B84; Wed, 29 Jul 2020 19:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 rB06YUHQuGEM; Wed, 29 Jul 2020 19:30:46 -0700 (PDT) Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (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 46E903A0B89; Wed, 29 Jul 2020 19:30:46 -0700 (PDT) Received: from mse-fl2.zte.com.cn (unknown [10.30.14.239]) by Forcepoint Email with ESMTPS id B02459D4A500291ABB5C; Thu, 30 Jul 2020 10:30:44 +0800 (CST) Received: from njxapp03.zte.com.cn ([10.41.132.202]) by mse-fl2.zte.com.cn with SMTP id 06U2UgTA064103; Thu, 30 Jul 2020 10:30:42 +0800 (GMT-8) (envelope-from xiong.quan@zte.com.cn) Received: from mapi (njxapp03[null]) by mapi (Zmail) with MAPI id mid201; Thu, 30 Jul 2020 10:30:42 +0800 (CST) Date: Thu, 30 Jul 2020 10:30:42 +0800 (CST) X-Zmail-TransId: 2afb5f2230d23c4065f8 X-Mailer: Zmail v1.0 Message-ID: <202007301030421412655@zte.com.cn> In-Reply-To: References: 138eecce-8db7-90da-d6e8-b006ee4ddc8e@pi.nu, CAP7zK5bw9_1+DY0WH0Y+MpqVuE34rj9YXMJ6-A7864PtUpX-0A@mail.gmail.com Mime-Version: 1.0 From: To: Cc: , , , Content-Type: multipart/mixed; boundary="=====_001_next=====" X-MAIL: mse-fl2.zte.com.cn 06U2UgTA064103 Archived-At: Subject: [Pce] =?utf-8?b?562U5aSNOiBjdXJzb3J5IHJldmlldyBvZiBkcmFmdC14aW9u?= =?utf-8?q?g-pce-lsp-flag?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 02:30:50 -0000 --=====_001_next===== Content-Type: multipart/related; boundary="=====_002_next=====" --=====_002_next===== Content-Type: multipart/alternative; boundary="=====_003_next=====" --=====_003_next===== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgRGhydXYgYW5kIExvYSwNCg0KDQoNCg0KDQoNClRoYW5rcyBmb3IgeW91ciByZXZpZXcgYW5k IGRldGFpbGVkIGRpc2N1c3Npb24hDQoNCg0KRm9yIHRoZSBJQU5BIHRleHQsIEkgd2lsbCB1cGRh dGUgdGhhdCBhcyB5b3Ugc3VnZ2VzdC4NCg0KDQoNCg0KDQoNCkluIG15IHZpZXcsIHdlIG5lZWQg dG8gY2xhcmlmeSB0aGUgTFNQLUVYVEVOREVELUZMQUcgVExWIGlzIG1hbmRhdG9yeSBvciBub3Qg Zmlyc3RseS4gVGhlbiBjb25zaWRlciB0aGUgZXJyb3IgaGFuZGxpbmcuDQoNCg0KVGhlcmUgYXJl IHR3byBjYXNlcy4NCg0KDQpGaXJzdCBjYXNlLCBmb3IgdGhlIGltcGxlbWVudGF0aW9ucyB3aGlj aCBqdXN0IHVzZSB0aGUgRmxhZyBmaWVsZCBvZiAgTFNQIE9iamVjdCBmcm9tICBiaXQgMSB0byBi aXQgMTEsIGl0IGhhcyBubyBuZWVkIHRvIGNhcnJ5IExTUC1FWFRFTkRFRC1GTEFHIFRMViBhbmQg bm90IG1hbmRhdG9yeS4NCg0KDQpTZWNvbmQgY2FzZSwgZm9yIHRoZSBpbXBsZW1lbnRhdGlvbnMg d2hpY2ggd2lsbCB1c2UgdGhlIGZsYWcgb2YgTFNQLUVYVEVOREVELUZMQUcgVExWLCBJdCBpcyBt YW5kYXRvcnkuICBXaGVuIExTUC1FWFRFTkRFRC1GTEFHIFRMViBpcyBtaXNzaW5nLCB0aGUgZXJy b3IgaGFuZGxpbmcgc2hvdWxkIGJlIHRha2VuIGludG8gY29uc2lkZXJhdGlvbi4NCg0KDQoNCg0K DQoNCkkgc3VnZ2VzdCB0byBtYWtlIGNsYXJpZmljYXRpb24gaW4gdGhlIGRyYWZ0IGFib3V0IHRo ZSBpbXBsZW1lbnRhdGlvbnMgDQoNCg0Kb3IgdXNlIHRoZSBiaXQgMCBvZiBGbGFnIGZpZWxkIGlu IExTUCBPYmplY3QgdG8gaW5kaWNhdGUgdGhlIGV4aXN0aW5nIG9mIHRoZSBMU1AtRVhURU5ERUQt RkxBRyBUTFY/DQoNCg0KQ291bGQgeW91IHRlbGwgbWUgd2hhdCBpcyB5b3VyIHN1Z2dlc3Rpb24/ DQoNCg0KDQoNCg0KDQpUaGFua3MsDQoNCg0KUXVhbg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0K5Y6f5aeL6YKu5Lu2DQoNCg0KDQrlj5Hku7bkurrvvJpEaHJ1dkRob2R5IDxkZEBkaHJ1 dmRob2R5LmNvbT4NCuaUtuS7tuS6uu+8mkxvYSBBbmRlcnNzb24gPGxvYUBwaS5udT47DQrmioTp gIHkurrvvJpkcmFmdC14aW9uZy1wY2UtbHNwLWZsYWdAaWV0Zi5vcmcgPGRyYWZ0LXhpb25nLXBj ZS1sc3AtZmxhZ0BpZXRmLm9yZz47cGNlLWNoYWlyc0BpZXRmLm9yZyA8cGNlLWNoYWlyc0BpZXRm Lm9yZz47cGNlQGlldGYub3JnIDxwY2VAaWV0Zi5vcmc+Ow0K5pelIOacnyDvvJoyMDIw5bm0MDfm nIgyOeaXpSAxOToxNQ0K5Li7IOmimCDvvJpSZTogY3Vyc29yeSByZXZpZXcgb2YgZHJhZnQteGlv bmctcGNlLWxzcC1mbGFnDQoNCg0KSGkgTG9hLA0KDQpPbiBXZWQsIEp1bCAyOSwgMjAyMCBhdCA0 OjEzIFBNIExvYSBBbmRlcnNzb24gPGxvYUBwaS5udT4gd3JvdGU6DQo+DQo+IERocnV2LA0KPg0K PiBJbmxpbmUgcGxlYXNlLg0KPg0KPiBPbiAyOS8wNy8yMDIwIDE3OjAxLCBEaHJ1diBEaG9keSB3 cm90ZToNCj4gPiBIaSBMb2EsDQo+ID4NCj4gPj4gQ29tbWVudDoNCj4gPj4NCj4gPj4gNS4yLiAg UENFUC1FcnJvciBPYmplY3QNCj4gPj4NCj4gPj4gICAgICBJQU5BIGlzIHJlcXVlc3RlZCB0byBy ZWdpc3RlciB0aGUgZm9sbG93aW5nIGVycm9yIHR5cGVzIGFuZCBlcnJvcg0KPiA+PiAgICAgIHZh bHVlcyB3aXRoaW4gdGhlICJQQ0VQLUVSUk9SIE9iamVjdCBFcnJvciBUeXBlcyBhbmQgVmFsdWVz Ig0KPiA+PiAgICAgIHN1YnJlZ2lzdHJ5IG9mIHRoZSAiUGF0aCBDb21wdXRhdGlvbiBFbGVtZW50 IFByb3RvY29sIChQQ0VQKSBOdW1iZXJzIg0KPiA+PiAgICAgIHJlZ2lzdHJ5Og0KPiA+Pg0KPiA+ PiAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSsNCj4gPj4gICAgICAgICAgICAgfCAgRXJyb3ItVHlwZSAgfCAgTWVhbmluZyAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ID4+ICAgICAgICAgICAgICstLS0tLS0tLS0t LS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPiA+PiAgICAgICAg ICAgICB8ICA2ICAgICAgICAgICB8ICBNYW5kYXRvcnkgT2JqZWN0IG1pc3NpbmcgICAgICAgICAg IHwNCj4gPj4gICAgICAgICAgICAgfCAgICAgICAgICAgICAgfCAgRXJyb3ItdmFsdWUgICAgICAg ICAgICAgICAgICAgICAgICB8DQo+ID4+ICAgICAgICAgICAgIHwgICAgICAgICAgICAgIHwgVEJE MjogTFNQLUVYVEVOREVELUZMQUcgVExWIG1pc3NpbmcgfA0KPiA+PiAgICAgICAgICAgICArLS0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4gPj4N Cj4gPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVGFibGUgMg0KPiA+Pg0K PiA+PiBCb3RoIHRoZSBSVEcgRElSIHJ1bGVzIGFuZCBJQU5BIHJ1bGVzIHN0cm9uZ2x5IGFkdmlj ZSBhZ2FpbnN0IHB1dHRpbmcNCj4gPj4gZml4ZWQgbnVtZXJpYyAgdmFsdWVzIGludG8gYWxsb2Nh dGlvbiBmcm9tIGV4aXN0aW5nIHJlZ2lzdHJpZXMuIFRoZQ0KPiA+PiByZWFzb24gaXMgb2J2aW91 cywgaW4gdGhlIHRpbWUgZnJvbSB5b3UgcHV0IHRoZSB2YWx1ZSBpbiB5b3VyIGRvY3VtZW50DQo+ ID4+IHVudGlsIGlldCBpcyByZWFkeSBmb3IgSUVTRyByZXZpZXcgKHdoaWNoIGluY2x1ZGVzIElB TkEgcmV2aWV3KSBzb21lb25lDQo+ID4+IGVsc2UgbWlnaHQgaGF2ZSBiZWVuIGFzc2lnbmVkIHRo dCB2YWx1ZS4gVGhpcyBoYXMgaGFwcGVuZWQgYW5kIGhhdmUNCj4gPj4gY2F1c2VkIHNlcmlvdXMg cHJvYmxlbXMuDQo+ID4+DQo+ID4+IDYgaW4gdGFibGUgMiBob3VsZCBiZSByZXBsYWNlZCB3aXRo IFRCQSAodG8gYmUgYXNzaWduZWQpLg0KPiA+Pg0KPiA+PiBOb3RlOiBJZiB5b3UgcmVhbGx5IHdh bnQgdGhlIHZhbHVlIDYsIHdlIHNob3VsZCBnbyBmb3IgYW4gZWFybHkNCj4gPj4gYWxsb2NhdGlv biBhcyBzb29uIGFzIHdlIGhhdmUgdGhlIHdnIGRvY3VtZW50Lg0KPiA+Pg0KPiA+DQo+ID4gW0Ro cnV2XSBUaGUgdmFsdWUgNiBpcyBmb3IgRXJyb3ItVHlwZSBhbHJlYWR5IGFsbG9jYXRlZCBieSBS RkMgNTQ0MC4NCj4gPiBUaGlzIEktRCBpcyBhc2tpbmcgZm9yIGEgbmV3IEVycm9yLVZhbHVlIHdo aWNoIGlzICBUQkQyLiBBIHJlZmVyZW5jZQ0KPiA+IGNvbHVtbiBpbiB0aGUgSUFOQSB0YWJsZSB3 b3VsZCBoYXZlIGhlbHBlZCBoZXJlLg0KPg0KPiBobW1tbSAtIG9rZXksIGJ1dCBubywgd2UgYXJl IGFza2luZyBJQU5BIHRvIHJlZ2lzdGVyIGEgbmV3IGVycm9yLXZhbHVlLA0KPiBidXQgbm90IGEg bmV3IGVycm9yIHR5cGUuIFRoZSB0ZXh0IHNheXM6DQo+DQo+ICAgICJJQU5BIGlzIHJlcXVlc3Rl ZCB0byByZWdpc3RlciB0aGUgZm9sbG93aW5nIGVycm9yIHR5cGVzIGFuZCBlcnJvcg0KPiAgICAg IHZhbHVlcyAuLi4iDQo+DQoNClRoaXMgdGV4dCBpcyBpbmNvcnJlY3QgdGhlbiBhbmQgc2hvdWxk IGJlIGZpeGVkLg0KDQo+IEJ1dCB0aGVuIHRoZSB0YWJsZSBpcyB2ZXJ5IHVuY2xlYXIsIGF0IGEg bWluaW11bSBpdCBzaG91bGQgbG9vaw0KPiBzb21ldGhpbmcgbGlrZSB0aGlzOg0KPg0KPiAgICAr LS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rDQo+ICAgIHwgIEVycm9yLVR5cGUgfCBNZWFuaW5nICAgICAgICAgICAgICAg ICAgICB8IEVycm9yLXZhbHVlICAgICAgICAgICAgIHwNCj4gICAgKy0tLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPiAg ICB8ICA2ICAgICAgICAgIHwgTWFuZGF0b3J5IE9iamVjdCBtaXNzaW5nICAgfCAwOiBVbmFzc2ln bmVkICAgICAgICAgICB8DQo+ICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8IDEtMTUgQXNzaWduZWQgICAgICAgICAgIHwNCj4gICAgfCAgICAgICAgICAgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgVEJEMjogTFNQLUVYVEVOREVELUZMQUcgfA0K PiAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICBU TFYgbWlzc2luZyAgICAgICB8DQo+ICAgICstLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4NCj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBUYWJsZSAyDQo+DQpZZXMuIEkgc3VnZ2VzdCBRdWFu IHRvIGxvb2sgYXQgLQ0KaHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvcmZjL3JmYzg4MDAuaHRt bCNzZWN0aW9uLTcuNSBhcyBhIGdvb2QNCnJlZmVyZW5jZSBmcm9tIGEgcmVjZW50IHB1Ymxpc2hl ZCBSRkMuDQoNCj4NCj4gPg0KPiA+PiBRdWVzdGlvbjoNCj4gPj4NCj4gPj4gSW4gc2VjdGlvbiA0 IHlvdSBzYXk6DQo+ID4+DQo+ID4+ICAgICAgVGhlIExTUC1FWFRFTkRFRC1GTEFHIFRMViBNVVNU IGJlIGRlZmluZWQgYXMgbWFuZGF0b3J5IHdoZW4gYSByb3V0ZXINCj4gPj4gICAgICBzdXBwb3J0 aW5nIHRoZSBMU1AgT2JqZWN0IGFuZCBuZWVkcyB0byB1c2UgdGhlIGV4dGVuZGVkIGZsYWcgZmll bGQuDQo+ID4+DQo+ID4+IEkgZG9uJ3QgcmVhbGx5IHBhcnNlOyBhcmUgeW91IHNheWluZyB0aGF0 IGlmIGl0IGlzIHByZXNlbnQgaXQgc2hvdWxkIGJlDQo+ID4+IHRyZWF0ZWQgYXMgbWFuZGF0b3J5 Pw0KPiA+Pg0KPiA+PiBJZiB0aGF0IGlzIHdoYXQgeW91IGFyZSBzYXlpbmcsIHdoYXQgZG9lcyBp dCBjaGFuZ2U/DQo+ID4+DQo+ID4NCj4gPiBbRGhydXZdOiBJIHJlYWQgaXQgYXMgYSByZXF1aXJl bWVudCBmb3IgYSBmdXR1cmUgZXh0ZW5zaW9uIHRoYXQgd291bGQNCj4gPiBkZWZpbmUgYSBmbGFn IGluIHRoZSBMU1AtRVhURU5ERUQtRkxBRyBUTFYuDQo+ID4NCj4gPiBJZiB0aGF0IGlzIHRydWUs IEkgd291bGQgc3VnZ2VzdCBub3QgdXNpbmcgbm9ybWF0aXZlIE1VU1QuIEhvdyBhYm91dCAtDQo+ ID4NCj4gPiBBIGZ1dHVyZSBleHRlbnNpb24gdGhhdCBkZWZpbmVzIGEgZmxhZyBpbiB0aGUgTFNQ LUVYVEVOREVELUZMQUcgVExWDQo+ID4gY291bGQgbWFyayB0aGlzIFRMViBhcyBtYW5kYXRvcnkg dG8gYmUgY2FycmllZCB0aGUgTFNQIE9iamVjdC4NCj4NCj4gSSBoYXZlIGJlZW4gcmVhZGluZyBh IGJpdCBtb3JlLCBidXQgdGhpcyBpcyBzdGlsbCB1bmNsZWFyIHRvIG1lLCBpZiBJDQo+IHVuZGVy c3RhbmQgaXQgd2lsbCBzdGlsbCBiZSB2YWxpZCB0byBzZW5kIHdpdGhvdXQgdGhlIGV4dGVuZGVk IFRMVg0KPiAoaWYgeW91IGRvbid0IG5lZWQgdGhlIGZsYWdzKS4NCg0KWWVzISBNYXliZSB3ZSBz aG91bGQgbm90IHVzZSB0aGUgd29yZCAibWFuZGF0b3J5IiB0aGVuIQ0KDQpBcyBpdCBpcyAibWFu ZGF0b3J5IiBpbiB0aGUgY29udGV4dCBvZiB1c2luZyBhIG5ldyBmZWF0dXJlIGRlZmluZWQgaW4N CmEgZnV0dXJlIGV4dGVuc2lvbiAtLSBzbyB0byB1c2UgdGhlIG5ldyBmZWF0dXJlLCBhbiBpbXBs ZW1lbnRhdGlvbg0KTVVTVCBpbmNsdWRlIHRoZSBMU1AtRVhURU5ERUQtRkxBRyBUTFYgYW5kIE1V U1Qgc2V0IGEgcGFydGljdWxhciBmbGFnLg0KVGhlIHNvLWNhbGxlZCAibWFuZGF0b3J5IiB3b3Vs ZCBiZSBvbmx5IGluIHRoZSBzY29wZSBvZiB0aGUgcHJvdG9jb2wNCmV4dGVuc2lvbiBhbmQgbm90 IHJlcXVpcmVkIHdoZW4gdGhlIGZlYXR1cmUgaXMgbm90IHVzZWQuDQoNCj4gSG93IGFyZSB5b3Ug ZGVjaWRpbmcgaWYgdGhlIGV4dGVuZGVkIFRMVg0KPiBtaXNzaW5nPw0KPg0KDQpUaGlzIGNvdWxk IGJlIGJlY2F1c2Ugb2YgdGhlIHByZXNlbmNlIG9mIHNvbWUgb3RoZXIgb2JqZWN0L1RMVnMgbmVl ZGVkDQpieSB0aGUgc2FtZSBleHRlbnNpb24gYnV0IHdpdGhvdXQgdGhlIExTUC1FWFRFTkRFRC1G TEFHIFRMViBpbiB0aGUgTFNQDQpvYmplY3QuDQpQZXJoYXBzIHRoZSByaWdodCB0aGluZyB0byBk byB3b3VsZCBiZSB0byBtb3ZlIHRoZSBlcnJvciBoYW5kbGluZyB0bw0KdGhlIGZpcnN0IGRvY3Vt ZW50IHRoYXQgdXNlcyB0aGUgTFNQLUVYVEVOREVELUZMQUcgVExWIGluc3RlYWQgb2YgdGhpcw0K ZG9jdW1lbnQuDQoNClRoYW5rcyENCkRocnV2DQoNCj4NCj4gL0xvYQ0KPiA+DQo+ID4gVGhhbmtz IQ0KPiA+IERocnV2DQo+ID4NCj4gPj4gL0xvYQ0KPiA+Pg0KPiA+Pg0KPiA+PiAtLQ0KPiA+Pg0K PiA+PiBMb2EgQW5kZXJzc29uICAgICAgICAgICAgICAgICAgICAgICAgZW1haWw6IGxvYUBwaS5u dQ0KPiA+PiBTZW5pb3IgTVBMUyBFeHBlcnQgICAgICAgICAgICAgICAgICAgICAgICAgIGxvYS5w aS5udUBnbWFpbC5jb20NCj4gPj4gQnJvbnplIERyYWdvbiBDb25zdWx0aW5nICAgICAgICAgICAg IHBob25lOiArNDYgNzM5IDgxIDIxIDY0DQo+DQo+IC0tDQo+DQo+IExvYSBBbmRlcnNzb24gICAg ICAgICAgICAgICAgICAgICAgICBlbWFpbDogbG9hQHBpLm51DQo+IFNlbmlvciBNUExTIEV4cGVy dCAgICAgICAgICAgICAgICAgICAgICAgICAgbG9hLnBpLm51QGdtYWlsLmNvbQ0KPiBCcm9uemUg RHJhZ29uIENvbnN1bHRpbmcgICAgICAgICAgICAgcGhvbmU6ICs0NiA3MzkgODEgMjEgNjQ= --=====_003_next===== Content-Type: text/html ; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBjbGFzcz0iemNvbnRlbnRSb3ciPjxwIHN0eWxlPSJmb250LXNpemU6MjBweDtmb250LWZh bWlseTphcmlhbDsiPjxicj48L3A+PHAgc3R5bGU9ImZvbnQtc2l6ZToyMHB4O2ZvbnQtZmFtaWx5 OmFyaWFsOyI+SGkgRGhydXYgYW5kIExvYSw8L3A+PHAgc3R5bGU9ImZvbnQtc2l6ZToyMHB4O2Zv bnQtZmFtaWx5OmFyaWFsOyI+PGJyPjwvcD48cCBzdHlsZT0iZm9udC1zaXplOjIwcHg7Zm9udC1m YW1pbHk6YXJpYWw7Ij5UaGFua3MgZm9yIHlvdXIgcmV2aWV3IGFuZCBkZXRhaWxlZCBkaXNjdXNz aW9uITwvcD48cCBzdHlsZT0iZm9udC1zaXplOjIwcHg7Zm9udC1mYW1pbHk6YXJpYWw7Ij5Gb3Ig dGhlIElBTkEgdGV4dCwgSSB3aWxsIHVwZGF0ZSB0aGF0IGFzIHlvdSBzdWdnZXN0LjwvcD48cCBz dHlsZT0iZm9udC1zaXplOjIwcHg7Zm9udC1mYW1pbHk6YXJpYWw7Ij48YnI+PC9wPjxwIHN0eWxl PSJmb250LXNpemU6MjBweDtmb250LWZhbWlseTphcmlhbDsiPkluIG15IHZpZXcsIHdlIG5lZWQg dG8gY2xhcmlmeSB0aGUmbmJzcDs8c3BhbiBzdHlsZT0ibGluZS1oZWlnaHQ6IDIxcHg7Ij5MU1At RVhURU5ERUQtRkxBRyZuYnNwO1RMViBpcyZuYnNwOzxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDog MjFweDsiPm1hbmRhdG9yeSBvciBub3QgZmlyc3RseS4gVGhlbiBjb25zaWRlciB0aGUgZXJyb3Ig aGFuZGxpbmcuPC9zcGFuPjwvc3Bhbj48L3A+PHAgc3R5bGU9ImZvbnQtc2l6ZToyMHB4O2ZvbnQt ZmFtaWx5OmFyaWFsOyI+PHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMXB4OyI+PHNwYW4gc3R5 bGU9ImxpbmUtaGVpZ2h0OiAyMXB4OyI+VGhlcmUgYXJlIHR3byBjYXNlcy48L3NwYW4+PC9zcGFu PjwvcD48cCBzdHlsZT0iZm9udC1zaXplOjIwcHg7Zm9udC1mYW1pbHk6YXJpYWw7Ij48c3BhbiBz dHlsZT0ibGluZS1oZWlnaHQ6IDIxcHg7Ij48c3BhbiBzdHlsZT0ibGluZS1oZWlnaHQ6IDIxcHg7 Ij5GaXJzdCBjYXNlLCBmb3IgdGhlJm5ic3A7PHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMXB4 OyI+aW1wbGVtZW50YXRpb25zIHdoaWNoIGp1c3QgdXNlIHRoZSBGbGFnIGZpZWxkIG9mICZuYnNw O0xTUCBPYmplY3QgZnJvbSAmbmJzcDtiaXQgMSB0byBiaXQgMTEsIGl0IGhhcyBubyBuZWVkIHRv IGNhcnJ5Jm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBhcmlhbDsgZm9udC1zaXplOiAy MHB4OyBsaW5lLWhlaWdodDogMjFweDsiPkxTUC1FWFRFTkRFRC1GTEFHJm5ic3A7VExWIGFuZCBu b3QmbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IGFyaWFsOyBmb250LXNpemU6IDIwcHg7 IGxpbmUtaGVpZ2h0OiAyMXB4OyI+bWFuZGF0b3J5Ljwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bh bj48L3NwYW4+PC9wPjxwIHN0eWxlPSJmb250LXNpemU6MjBweDtmb250LWZhbWlseTphcmlhbDsi PjxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDogMjFweDsiPjxzcGFuIHN0eWxlPSJsaW5lLWhlaWdo dDogMjFweDsiPjxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDogMjFweDsiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTogYXJpYWw7IGZvbnQtc2l6ZTogMjBweDsgbGluZS1oZWlnaHQ6IDIxcHg7Ij48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IGFyaWFsOyBmb250LXNpemU6IDIwcHg7IGxpbmUtaGVp Z2h0OiAyMXB4OyI+U2Vjb25kIGNhc2UsIGZvciZuYnNwOzxzcGFuIHN0eWxlPSJmb250LWZhbWls eTogYXJpYWw7IGZvbnQtc2l6ZTogMjBweDsgbGluZS1oZWlnaHQ6IDIxcHg7Ij50aGUmbmJzcDs8 L3NwYW4+PHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMXB4OyBmb250LWZhbWlseTogYXJpYWw7 IGZvbnQtc2l6ZTogMjBweDsiPmltcGxlbWVudGF0aW9ucyB3aGljaCB3aWxsIHVzZSB0aGUgZmxh ZyBvZiZuYnNwOzxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogYXJpYWw7IGZvbnQtc2l6ZTogMjBw eDsgbGluZS1oZWlnaHQ6IDIxcHg7Ij5MU1AtRVhURU5ERUQtRkxBRyZuYnNwO1RMViwgSXQgaXMm bmJzcDs8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IGFyaWFsOyBmb250LXNpemU6IDIwcHg7IGxp bmUtaGVpZ2h0OiAyMXB4OyI+bWFuZGF0b3J5LiAmbmJzcDtXaGVuJm5ic3A7PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiBhcmlhbDsgZm9udC1zaXplOiAyMHB4OyBsaW5lLWhlaWdodDogMjFweDsi PkxTUC1FWFRFTkRFRC1GTEFHJm5ic3A7VExWIGlzIG1pc3NpbmcsIHRoZSZuYnNwOzxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTogYXJpYWw7IGZvbnQtc2l6ZTogMjBweDsgbGluZS1oZWlnaHQ6IDIx cHg7Ij5lcnJvciBoYW5kbGluZyBzaG91bGQgYmUgdGFrZW4gaW50byBjb25zaWRlcmF0aW9uLjwv c3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9z cGFuPjwvc3Bhbj48L3A+PHAgc3R5bGU9ImZvbnQtc2l6ZToyMHB4O2ZvbnQtZmFtaWx5OmFyaWFs OyI+PHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMXB4OyI+PHNwYW4gc3R5bGU9ImxpbmUtaGVp Z2h0OiAyMXB4OyI+PHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMXB4OyI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiBhcmlhbDsgZm9udC1zaXplOiAyMHB4OyBsaW5lLWhlaWdodDogMjFweDsi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogYXJpYWw7IGZvbnQtc2l6ZTogMjBweDsgbGluZS1o ZWlnaHQ6IDIxcHg7Ij48c3BhbiBzdHlsZT0ibGluZS1oZWlnaHQ6IDIxcHg7IGZvbnQtZmFtaWx5 OiBhcmlhbDsgZm9udC1zaXplOiAyMHB4OyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBhcmlh bDsgZm9udC1zaXplOiAyMHB4OyBsaW5lLWhlaWdodDogMjFweDsiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTogYXJpYWw7IGZvbnQtc2l6ZTogMjBweDsgbGluZS1oZWlnaHQ6IDIxcHg7Ij48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6IGFyaWFsOyBmb250LXNpemU6IDIwcHg7IGxpbmUtaGVpZ2h0 OiAyMXB4OyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBhcmlhbDsgZm9udC1zaXplOiAyMHB4 OyBsaW5lLWhlaWdodDogMjFweDsiPjxicj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9z cGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9wPjxwIHN0eWxlPSJmb250 LXNpemU6MjBweDtmb250LWZhbWlseTphcmlhbDsiPjxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDog MjFweDsiPjxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDogMjFweDsiPjxzcGFuIHN0eWxlPSJsaW5l LWhlaWdodDogMjFweDsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogYXJpYWw7IGZvbnQtc2l6 ZTogMjBweDsgbGluZS1oZWlnaHQ6IDIxcHg7Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IGFy aWFsOyBmb250LXNpemU6IDIwcHg7IGxpbmUtaGVpZ2h0OiAyMXB4OyI+PHNwYW4gc3R5bGU9Imxp bmUtaGVpZ2h0OiAyMXB4OyBmb250LWZhbWlseTogYXJpYWw7IGZvbnQtc2l6ZTogMjBweDsiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTogYXJpYWw7IGZvbnQtc2l6ZTogMjBweDsgbGluZS1oZWln aHQ6IDIxcHg7Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IGFyaWFsOyBmb250LXNpemU6IDIw cHg7IGxpbmUtaGVpZ2h0OiAyMXB4OyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBhcmlhbDsg Zm9udC1zaXplOiAyMHB4OyBsaW5lLWhlaWdodDogMjFweDsiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTogYXJpYWw7IGZvbnQtc2l6ZTogMjBweDsgbGluZS1oZWlnaHQ6IDIxcHg7Ij5JIHN1Z2dl c3QgdG8gbWFrZSBjbGFyaWZpY2F0aW9uIGluIHRoZSBkcmFmdCBhYm91dCB0aGUgPHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiBhcmlhbDsgZm9udC1zaXplOiAyMHB4OyBsaW5lLWhlaWdodDogMjFw eDsiPmltcGxlbWVudGF0aW9ucyZuYnNwOzwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3Nw YW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9wPjxwIHN0eWxl PSJmb250LXNpemU6MjBweDtmb250LWZhbWlseTphcmlhbDsiPjxzcGFuIHN0eWxlPSJsaW5lLWhl aWdodDogMjFweDsiPjxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDogMjFweDsiPjxzcGFuIHN0eWxl PSJsaW5lLWhlaWdodDogMjFweDsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogYXJpYWw7IGZv bnQtc2l6ZTogMjBweDsgbGluZS1oZWlnaHQ6IDIxcHg7Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6IGFyaWFsOyBmb250LXNpemU6IDIwcHg7IGxpbmUtaGVpZ2h0OiAyMXB4OyI+PHNwYW4gc3R5 bGU9ImxpbmUtaGVpZ2h0OiAyMXB4OyBmb250LWZhbWlseTogYXJpYWw7IGZvbnQtc2l6ZTogMjBw eDsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogYXJpYWw7IGZvbnQtc2l6ZTogMjBweDsgbGlu ZS1oZWlnaHQ6IDIxcHg7Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IGFyaWFsOyBmb250LXNp emU6IDIwcHg7IGxpbmUtaGVpZ2h0OiAyMXB4OyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBh cmlhbDsgZm9udC1zaXplOiAyMHB4OyBsaW5lLWhlaWdodDogMjFweDsiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTogYXJpYWw7IGZvbnQtc2l6ZTogMjBweDsgbGluZS1oZWlnaHQ6IDIxcHg7Ij5v ciB1c2UgdGhlIGJpdCAwIG9mIEZsYWcgZmllbGQgaW4gTFNQIE9iamVjdCB0byBpbmRpY2F0ZSB0 aGUgZXhpc3Rpbmcgb2YgdGhlJm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBhcmlhbDsg Zm9udC1zaXplOiAyMHB4OyBsaW5lLWhlaWdodDogMjFweDsiPkxTUC1FWFRFTkRFRC1GTEFHJm5i c3A7VExWPzwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48 L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9wPjxwIHN0eWxlPSJmb250LXNpemU6MjBweDtm b250LWZhbWlseTphcmlhbDsiPjxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDogMjFweDsiPjxzcGFu IHN0eWxlPSJsaW5lLWhlaWdodDogMjFweDsiPjxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDogMjFw eDsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogYXJpYWw7IGZvbnQtc2l6ZTogMjBweDsgbGlu ZS1oZWlnaHQ6IDIxcHg7Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IGFyaWFsOyBmb250LXNp emU6IDIwcHg7IGxpbmUtaGVpZ2h0OiAyMXB4OyI+PHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiAy MXB4OyBmb250LWZhbWlseTogYXJpYWw7IGZvbnQtc2l6ZTogMjBweDsiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTogYXJpYWw7IGZvbnQtc2l6ZTogMjBweDsgbGluZS1oZWlnaHQ6IDIxcHg7Ij48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IGFyaWFsOyBmb250LXNpemU6IDIwcHg7IGxpbmUtaGVp Z2h0OiAyMXB4OyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBhcmlhbDsgZm9udC1zaXplOiAy MHB4OyBsaW5lLWhlaWdodDogMjFweDsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogYXJpYWw7 IGZvbnQtc2l6ZTogMjBweDsgbGluZS1oZWlnaHQ6IDIxcHg7Ij48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6IGFyaWFsOyBmb250LXNpemU6IDIwcHg7IGxpbmUtaGVpZ2h0OiAyMXB4OyI+Q291bGQg eW91IHRlbGwgbWUgd2hhdCBpcyB5b3VyIHN1Z2dlc3Rpb24/PC9zcGFuPjwvc3Bhbj48L3NwYW4+ PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48 L3A+PHAgc3R5bGU9ImZvbnQtc2l6ZToyMHB4O2ZvbnQtZmFtaWx5OmFyaWFsOyI+PHNwYW4gc3R5 bGU9ImxpbmUtaGVpZ2h0OiAyMXB4OyI+PHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMXB4OyI+ PHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMXB4OyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiBhcmlhbDsgZm9udC1zaXplOiAyMHB4OyBsaW5lLWhlaWdodDogMjFweDsiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTogYXJpYWw7IGZvbnQtc2l6ZTogMjBweDsgbGluZS1oZWlnaHQ6IDIxcHg7 Ij48c3BhbiBzdHlsZT0ibGluZS1oZWlnaHQ6IDIxcHg7IGZvbnQtZmFtaWx5OiBhcmlhbDsgZm9u dC1zaXplOiAyMHB4OyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBhcmlhbDsgZm9udC1zaXpl OiAyMHB4OyBsaW5lLWhlaWdodDogMjFweDsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogYXJp YWw7IGZvbnQtc2l6ZTogMjBweDsgbGluZS1oZWlnaHQ6IDIxcHg7Ij48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6IGFyaWFsOyBmb250LXNpemU6IDIwcHg7IGxpbmUtaGVpZ2h0OiAyMXB4OyI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBhcmlhbDsgZm9udC1zaXplOiAyMHB4OyBsaW5lLWhlaWdo dDogMjFweDsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogYXJpYWw7IGZvbnQtc2l6ZTogMjBw eDsgbGluZS1oZWlnaHQ6IDIxcHg7Ij48YnI+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwv c3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3A+PHAgc3R5 bGU9ImZvbnQtc2l6ZToyMHB4O2ZvbnQtZmFtaWx5OmFyaWFsOyI+PHNwYW4gc3R5bGU9ImxpbmUt aGVpZ2h0OiAyMXB4OyI+PHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMXB4OyI+PHNwYW4gc3R5 bGU9ImxpbmUtaGVpZ2h0OiAyMXB4OyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBhcmlhbDsg Zm9udC1zaXplOiAyMHB4OyBsaW5lLWhlaWdodDogMjFweDsiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTogYXJpYWw7IGZvbnQtc2l6ZTogMjBweDsgbGluZS1oZWlnaHQ6IDIxcHg7Ij48c3BhbiBz dHlsZT0ibGluZS1oZWlnaHQ6IDIxcHg7IGZvbnQtZmFtaWx5OiBhcmlhbDsgZm9udC1zaXplOiAy MHB4OyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBhcmlhbDsgZm9udC1zaXplOiAyMHB4OyBs aW5lLWhlaWdodDogMjFweDsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogYXJpYWw7IGZvbnQt c2l6ZTogMjBweDsgbGluZS1oZWlnaHQ6IDIxcHg7Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 IGFyaWFsOyBmb250LXNpemU6IDIwcHg7IGxpbmUtaGVpZ2h0OiAyMXB4OyI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiBhcmlhbDsgZm9udC1zaXplOiAyMHB4OyBsaW5lLWhlaWdodDogMjFweDsi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogYXJpYWw7IGZvbnQtc2l6ZTogMjBweDsgbGluZS1o ZWlnaHQ6IDIxcHg7Ij5UaGFua3MsPC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48 L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3A+PHAgc3R5bGU9ImZv bnQtc2l6ZToyMHB4O2ZvbnQtZmFtaWx5OmFyaWFsOyI+PHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0 OiAyMXB4OyI+PHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMXB4OyI+PHNwYW4gc3R5bGU9Imxp bmUtaGVpZ2h0OiAyMXB4OyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBhcmlhbDsgZm9udC1z aXplOiAyMHB4OyBsaW5lLWhlaWdodDogMjFweDsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTog YXJpYWw7IGZvbnQtc2l6ZTogMjBweDsgbGluZS1oZWlnaHQ6IDIxcHg7Ij48c3BhbiBzdHlsZT0i bGluZS1oZWlnaHQ6IDIxcHg7IGZvbnQtZmFtaWx5OiBhcmlhbDsgZm9udC1zaXplOiAyMHB4OyI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBhcmlhbDsgZm9udC1zaXplOiAyMHB4OyBsaW5lLWhl aWdodDogMjFweDsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogYXJpYWw7IGZvbnQtc2l6ZTog MjBweDsgbGluZS1oZWlnaHQ6IDIxcHg7Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IGFyaWFs OyBmb250LXNpemU6IDIwcHg7IGxpbmUtaGVpZ2h0OiAyMXB4OyI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiBhcmlhbDsgZm9udC1zaXplOiAyMHB4OyBsaW5lLWhlaWdodDogMjFweDsiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTogYXJpYWw7IGZvbnQtc2l6ZTogMjBweDsgbGluZS1oZWlnaHQ6 IDIxcHg7Ij5RdWFuPC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9z cGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3A+PHAgc3R5bGU9ImZvbnQtc2l6ZToy MHB4O2ZvbnQtZmFtaWx5OmFyaWFsOyI+PHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMXB4OyI+ PHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMXB4OyI+PHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0 OiAyMXB4OyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBhcmlhbDsgZm9udC1zaXplOiAyMHB4 OyBsaW5lLWhlaWdodDogMjFweDsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogYXJpYWw7IGZv bnQtc2l6ZTogMjBweDsgbGluZS1oZWlnaHQ6IDIxcHg7Ij48c3BhbiBzdHlsZT0ibGluZS1oZWln aHQ6IDIxcHg7IGZvbnQtZmFtaWx5OiBhcmlhbDsgZm9udC1zaXplOiAyMHB4OyI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiBhcmlhbDsgZm9udC1zaXplOiAyMHB4OyBsaW5lLWhlaWdodDogMjFw eDsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogYXJpYWw7IGZvbnQtc2l6ZTogMjBweDsgbGlu ZS1oZWlnaHQ6IDIxcHg7Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IGFyaWFsOyBmb250LXNp emU6IDIwcHg7IGxpbmUtaGVpZ2h0OiAyMXB4OyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBh cmlhbDsgZm9udC1zaXplOiAyMHB4OyBsaW5lLWhlaWdodDogMjFweDsiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTogYXJpYWw7IGZvbnQtc2l6ZTogMjBweDsgbGluZS1oZWlnaHQ6IDIxcHg7Ij48 YnI+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bh bj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3A+PHAgc3R5bGU9ImZvbnQtc2l6ZToyMHB4O2ZvbnQt ZmFtaWx5OmFyaWFsOyI+PHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMXB4OyI+PHNwYW4gc3R5 bGU9ImxpbmUtaGVpZ2h0OiAyMXB4OyI+PGJyPjwvc3Bhbj48L3NwYW4+PC9wPjxwIHN0eWxlPSJm b250LXNpemU6MjBweDtmb250LWZhbWlseTphcmlhbDsiPjxicj48L3A+PGRpdj48ZGl2IGNsYXNz PSJ6aGlzdG9yeVJvdyIgc3R5bGU9ImRpc3BsYXk6YmxvY2siPjxkaXYgY2xhc3M9InpoaXN0b3J5 RGVzIiBzdHlsZT0id2lkdGg6IDEwMCU7IGhlaWdodDogMjhweDsgbGluZS1oZWlnaHQ6IDI4cHg7 IGJhY2tncm91bmQtY29sb3I6ICNFMEU1RTk7IGNvbG9yOiAjMTM4OEZGOyB0ZXh0LWFsaWduOiBj ZW50ZXI7IiBsYW5ndWFnZS1kYXRhPSJIaXN0b3J5T3JnVHh0Ij7ljp/lp4vpgq7ku7Y8L2Rpdj48 ZGl2IGlkPSJ6d3JpdGVIaXN0b3J5Q29udGFpbmVyIj48ZGl2IGNsYXNzPSJjb250cm9sLWdyb3Vw IHpoaXN0b3J5UGFuZWwiPjxkaXYgY2xhc3M9InpoaXN0b3J5SGVhZGVyIiBzdHlsZT0icGFkZGlu ZzogOHB4OyBiYWNrZ3JvdW5kLWNvbG9yOiAjRjVGNkY4OyI+PGRpdj48c3Ryb25nIGxhbmd1YWdl LWRhdGE9Ikhpc3RvcnlTZW5kZXJUeHQiPuWPkeS7tuS6uu+8mjwvc3Ryb25nPjxzcGFuIGNsYXNz PSJ6cmVhZFVzZXJOYW1lIj5EaHJ1dkRob2R5ICZsdDtkZEBkaHJ1dmRob2R5LmNvbSZndDs8L3Nw YW4+PC9kaXY+PGRpdj48c3Ryb25nIGxhbmd1YWdlLWRhdGE9Ikhpc3RvcnlUT1R4dCI+5pS25Lu2 5Lq677yaPC9zdHJvbmc+PHNwYW4gY2xhc3M9InpyZWFkVXNlck5hbWUiIHN0eWxlPSJkaXNwbGF5 OiBpbmxpbmU7Ij5Mb2EgQW5kZXJzc29uICZsdDtsb2FAcGkubnUmZ3Q7Ozwvc3Bhbj48L2Rpdj48 ZGl2PjxzdHJvbmcgbGFuZ3VhZ2UtZGF0YT0iSGlzdG9yeUNDVHh0Ij7mioTpgIHkurrvvJo8L3N0 cm9uZz48c3BhbiBjbGFzcz0ienJlYWRVc2VyTmFtZSIgc3R5bGU9ImRpc3BsYXk6IGlubGluZTsi PmRyYWZ0LXhpb25nLXBjZS1sc3AtZmxhZ0BpZXRmLm9yZyAmbHQ7ZHJhZnQteGlvbmctcGNlLWxz cC1mbGFnQGlldGYub3JnJmd0Ozs8L3NwYW4+PHNwYW4gY2xhc3M9InpyZWFkVXNlck5hbWUiIHN0 eWxlPSJkaXNwbGF5OiBpbmxpbmU7Ij5wY2UtY2hhaXJzQGlldGYub3JnICZsdDtwY2UtY2hhaXJz QGlldGYub3JnJmd0Ozs8L3NwYW4+PHNwYW4gY2xhc3M9InpyZWFkVXNlck5hbWUiIHN0eWxlPSJk aXNwbGF5OiBpbmxpbmU7Ij5wY2VAaWV0Zi5vcmcgJmx0O3BjZUBpZXRmLm9yZyZndDs7PC9zcGFu PjwvZGl2PjxkaXY+PHN0cm9uZyBsYW5ndWFnZS1kYXRhPSJIaXN0b3J5RGF0ZVR4dCI+5pelIOac nyDvvJo8L3N0cm9uZz48c3BhbiBjbGFzcz0iIj4yMDIw5bm0MDfmnIgyOeaXpSAxOToxNTwvc3Bh bj48L2Rpdj48ZGl2PjxzdHJvbmcgbGFuZ3VhZ2UtZGF0YT0iSGlzdG9yeVN1YmplY3RUeHQiPuS4 uyDpopgg77yaPC9zdHJvbmc+PHNwYW4gY2xhc3M9InpyZWFkVGl0bGUiPjxzdHJvbmc+UmU6IGN1 cnNvcnkgcmV2aWV3IG9mIGRyYWZ0LXhpb25nLXBjZS1sc3AtZmxhZzwvc3Ryb25nPjwvc3Bhbj48 L2Rpdj48L2Rpdj48ZGl2IGNsYXNzPSJ6aGlzdG9yeUNvbnRlbnQiPjxkaXY+SGkmbmJzcDtMb2Es PGJyPjxicj5PbiZuYnNwO1dlZCwmbmJzcDtKdWwmbmJzcDsyOSwmbmJzcDsyMDIwJm5ic3A7YXQm bmJzcDs0OjEzJm5ic3A7UE0mbmJzcDtMb2EmbmJzcDtBbmRlcnNzb24mbmJzcDsmbHQ7bG9hQHBp Lm51Jmd0OyZuYnNwO3dyb3RlOjxicj4mZ3Q7PGJyPiZndDsmbmJzcDtEaHJ1diw8YnI+Jmd0Ozxi cj4mZ3Q7Jm5ic3A7SW5saW5lJm5ic3A7cGxlYXNlLjxicj4mZ3Q7PGJyPiZndDsmbmJzcDtPbiZu YnNwOzI5LzA3LzIwMjAmbmJzcDsxNzowMSwmbmJzcDtEaHJ1diZuYnNwO0Rob2R5Jm5ic3A7d3Jv dGU6PGJyPiZndDsmbmJzcDsmZ3Q7Jm5ic3A7SGkmbmJzcDtMb2EsPGJyPiZndDsmbmJzcDsmZ3Q7 PGJyPiZndDsmbmJzcDsmZ3Q7Jmd0OyZuYnNwO0NvbW1lbnQ6PGJyPiZndDsmbmJzcDsmZ3Q7Jmd0 Ozxicj4mZ3Q7Jm5ic3A7Jmd0OyZndDsmbmJzcDs1LjIuJm5ic3A7Jm5ic3A7UENFUC1FcnJvciZu YnNwO09iamVjdDxicj4mZ3Q7Jm5ic3A7Jmd0OyZndDs8YnI+Jmd0OyZuYnNwOyZndDsmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7SUFOQSZuYnNwO2lzJm5ic3A7cmVxdWVz dGVkJm5ic3A7dG8mbmJzcDtyZWdpc3RlciZuYnNwO3RoZSZuYnNwO2ZvbGxvd2luZyZuYnNwO2Vy cm9yJm5ic3A7dHlwZXMmbmJzcDthbmQmbmJzcDtlcnJvcjxicj4mZ3Q7Jm5ic3A7Jmd0OyZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt2YWx1ZXMmbmJzcDt3aXRoaW4mbmJz cDt0aGUmbmJzcDsiUENFUC1FUlJPUiZuYnNwO09iamVjdCZuYnNwO0Vycm9yJm5ic3A7VHlwZXMm bmJzcDthbmQmbmJzcDtWYWx1ZXMiPGJyPiZndDsmbmJzcDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO3N1YnJlZ2lzdHJ5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDsi UGF0aCZuYnNwO0NvbXB1dGF0aW9uJm5ic3A7RWxlbWVudCZuYnNwO1Byb3RvY29sJm5ic3A7KFBD RVApJm5ic3A7TnVtYmVycyI8YnI+Jmd0OyZuYnNwOyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7cmVnaXN0cnk6PGJyPiZndDsmbmJzcDsmZ3Q7Jmd0Ozxicj4mZ3Q7 Jm5ic3A7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsrLS0tLS0tLS0tLS0tLS0rLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSs8YnI+Jmd0OyZuYnNwOyZndDsmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNwO0Vycm9yLVR5cGUmbmJzcDsmbmJzcDt8Jm5i c3A7Jm5ic3A7TWVhbmluZyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwO3w8YnI+Jmd0OyZuYnNwOyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Ky0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rPGJy PiZndDsmbmJzcDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wmbmJzcDsmbmJzcDs2Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7fCZuYnNwOyZuYnNwO01hbmRhdG9yeSZuYnNwO09iamVjdCZuYnNwO21pc3NpbmcmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDt8PGJyPiZndDsmbmJzcDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDt8Jm5ic3A7Jm5ic3A7RXJyb3ItdmFsdWUmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDt8PGJyPiZndDsmbmJzcDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwO3wmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8Jm5ic3A7VEJEMjombmJzcDtMU1AtRVhU RU5ERUQtRkxBRyZuYnNwO1RMViZuYnNwO21pc3NpbmcmbmJzcDt8PGJyPiZndDsmbmJzcDsmZ3Q7 Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOystLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tKzxicj4mZ3Q7Jm5ic3A7Jmd0OyZndDs8YnI+Jmd0OyZuYnNw OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7VGFibGUmbmJzcDsyPGJyPiZndDsmbmJzcDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7Jmd0OyZn dDsmbmJzcDtCb3RoJm5ic3A7dGhlJm5ic3A7UlRHJm5ic3A7RElSJm5ic3A7cnVsZXMmbmJzcDth bmQmbmJzcDtJQU5BJm5ic3A7cnVsZXMmbmJzcDtzdHJvbmdseSZuYnNwO2FkdmljZSZuYnNwO2Fn YWluc3QmbmJzcDtwdXR0aW5nPGJyPiZndDsmbmJzcDsmZ3Q7Jmd0OyZuYnNwO2ZpeGVkJm5ic3A7 bnVtZXJpYyZuYnNwOyZuYnNwO3ZhbHVlcyZuYnNwO2ludG8mbmJzcDthbGxvY2F0aW9uJm5ic3A7 ZnJvbSZuYnNwO2V4aXN0aW5nJm5ic3A7cmVnaXN0cmllcy4mbmJzcDtUaGU8YnI+Jmd0OyZuYnNw OyZndDsmZ3Q7Jm5ic3A7cmVhc29uJm5ic3A7aXMmbmJzcDtvYnZpb3VzLCZuYnNwO2luJm5ic3A7 dGhlJm5ic3A7dGltZSZuYnNwO2Zyb20mbmJzcDt5b3UmbmJzcDtwdXQmbmJzcDt0aGUmbmJzcDt2 YWx1ZSZuYnNwO2luJm5ic3A7eW91ciZuYnNwO2RvY3VtZW50PGJyPiZndDsmbmJzcDsmZ3Q7Jmd0 OyZuYnNwO3VudGlsJm5ic3A7aWV0Jm5ic3A7aXMmbmJzcDtyZWFkeSZuYnNwO2ZvciZuYnNwO0lF U0cmbmJzcDtyZXZpZXcmbmJzcDsod2hpY2gmbmJzcDtpbmNsdWRlcyZuYnNwO0lBTkEmbmJzcDty ZXZpZXcpJm5ic3A7c29tZW9uZTxicj4mZ3Q7Jm5ic3A7Jmd0OyZndDsmbmJzcDtlbHNlJm5ic3A7 bWlnaHQmbmJzcDtoYXZlJm5ic3A7YmVlbiZuYnNwO2Fzc2lnbmVkJm5ic3A7dGh0Jm5ic3A7dmFs dWUuJm5ic3A7VGhpcyZuYnNwO2hhcyZuYnNwO2hhcHBlbmVkJm5ic3A7YW5kJm5ic3A7aGF2ZTxi cj4mZ3Q7Jm5ic3A7Jmd0OyZndDsmbmJzcDtjYXVzZWQmbmJzcDtzZXJpb3VzJm5ic3A7cHJvYmxl bXMuPGJyPiZndDsmbmJzcDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7Jmd0OyZndDsmbmJzcDs2Jm5i c3A7aW4mbmJzcDt0YWJsZSZuYnNwOzImbmJzcDtob3VsZCZuYnNwO2JlJm5ic3A7cmVwbGFjZWQm bmJzcDt3aXRoJm5ic3A7VEJBJm5ic3A7KHRvJm5ic3A7YmUmbmJzcDthc3NpZ25lZCkuPGJyPiZn dDsmbmJzcDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7Jmd0OyZndDsmbmJzcDtOb3RlOiZuYnNwO0lm Jm5ic3A7eW91Jm5ic3A7cmVhbGx5Jm5ic3A7d2FudCZuYnNwO3RoZSZuYnNwO3ZhbHVlJm5ic3A7 NiwmbmJzcDt3ZSZuYnNwO3Nob3VsZCZuYnNwO2dvJm5ic3A7Zm9yJm5ic3A7YW4mbmJzcDtlYXJs eTxicj4mZ3Q7Jm5ic3A7Jmd0OyZndDsmbmJzcDthbGxvY2F0aW9uJm5ic3A7YXMmbmJzcDtzb29u Jm5ic3A7YXMmbmJzcDt3ZSZuYnNwO2hhdmUmbmJzcDt0aGUmbmJzcDt3ZyZuYnNwO2RvY3VtZW50 Ljxicj4mZ3Q7Jm5ic3A7Jmd0OyZndDs8YnI+Jmd0OyZuYnNwOyZndDs8YnI+Jmd0OyZuYnNwOyZn dDsmbmJzcDtbRGhydXZdJm5ic3A7VGhlJm5ic3A7dmFsdWUmbmJzcDs2Jm5ic3A7aXMmbmJzcDtm b3ImbmJzcDtFcnJvci1UeXBlJm5ic3A7YWxyZWFkeSZuYnNwO2FsbG9jYXRlZCZuYnNwO2J5Jm5i c3A7UkZDJm5ic3A7NTQ0MC48YnI+Jmd0OyZuYnNwOyZndDsmbmJzcDtUaGlzJm5ic3A7SS1EJm5i c3A7aXMmbmJzcDthc2tpbmcmbmJzcDtmb3ImbmJzcDthJm5ic3A7bmV3Jm5ic3A7RXJyb3ItVmFs dWUmbmJzcDt3aGljaCZuYnNwO2lzJm5ic3A7Jm5ic3A7VEJEMi4mbmJzcDtBJm5ic3A7cmVmZXJl bmNlPGJyPiZndDsmbmJzcDsmZ3Q7Jm5ic3A7Y29sdW1uJm5ic3A7aW4mbmJzcDt0aGUmbmJzcDtJ QU5BJm5ic3A7dGFibGUmbmJzcDt3b3VsZCZuYnNwO2hhdmUmbmJzcDtoZWxwZWQmbmJzcDtoZXJl Ljxicj4mZ3Q7PGJyPiZndDsmbmJzcDtobW1tbSZuYnNwOy0mbmJzcDtva2V5LCZuYnNwO2J1dCZu YnNwO25vLCZuYnNwO3dlJm5ic3A7YXJlJm5ic3A7YXNraW5nJm5ic3A7SUFOQSZuYnNwO3RvJm5i c3A7cmVnaXN0ZXImbmJzcDthJm5ic3A7bmV3Jm5ic3A7ZXJyb3ItdmFsdWUsPGJyPiZndDsmbmJz cDtidXQmbmJzcDtub3QmbmJzcDthJm5ic3A7bmV3Jm5ic3A7ZXJyb3ImbmJzcDt0eXBlLiZuYnNw O1RoZSZuYnNwO3RleHQmbmJzcDtzYXlzOjxicj4mZ3Q7PGJyPiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsiSUFOQSZuYnNwO2lzJm5ic3A7cmVxdWVzdGVkJm5ic3A7dG8mbmJzcDtyZWdpc3Rl ciZuYnNwO3RoZSZuYnNwO2ZvbGxvd2luZyZuYnNwO2Vycm9yJm5ic3A7dHlwZXMmbmJzcDthbmQm bmJzcDtlcnJvcjxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7dmFs dWVzJm5ic3A7Li4uIjxicj4mZ3Q7PGJyPjxicj5UaGlzJm5ic3A7dGV4dCZuYnNwO2lzJm5ic3A7 aW5jb3JyZWN0Jm5ic3A7dGhlbiZuYnNwO2FuZCZuYnNwO3Nob3VsZCZuYnNwO2JlJm5ic3A7Zml4 ZWQuPGJyPjxicj4mZ3Q7Jm5ic3A7QnV0Jm5ic3A7dGhlbiZuYnNwO3RoZSZuYnNwO3RhYmxlJm5i c3A7aXMmbmJzcDt2ZXJ5Jm5ic3A7dW5jbGVhciwmbmJzcDthdCZuYnNwO2EmbmJzcDttaW5pbXVt Jm5ic3A7aXQmbmJzcDtzaG91bGQmbmJzcDtsb29rPGJyPiZndDsmbmJzcDtzb21ldGhpbmcmbmJz cDtsaWtlJm5ic3A7dGhpczo8YnI+Jmd0Ozxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Ky0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tKzxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNw O0Vycm9yLVR5cGUmbmJzcDt8Jm5ic3A7TWVhbmluZyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wmbmJzcDtFcnJvci12YWx1ZSZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwO3w8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOystLS0t LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSs8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wmbmJzcDsmbmJzcDs2Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 fCZuYnNwO01hbmRhdG9yeSZuYnNwO09iamVjdCZuYnNwO21pc3NpbmcmbmJzcDsmbmJzcDsmbmJz cDt8Jm5ic3A7MDombmJzcDtVbmFzc2lnbmVkJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fDxicj4mZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8Jm5ic3A7MS0xNSZuYnNwO0Fzc2lnbmVk Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7fDxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwO3wmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDt8Jm5ic3A7VEJEMjombmJzcDtMU1AtRVhURU5ERUQtRkxBRyZuYnNwO3w8YnI+Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1RMViZuYnNwO21pc3NpbmcmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8PGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsrLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0rPGJyPiZndDs8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1RhYmxlJm5ic3A7Mjxicj4m Z3Q7PGJyPlllcy4mbmJzcDtJJm5ic3A7c3VnZ2VzdCZuYnNwO1F1YW4mbmJzcDt0byZuYnNwO2xv b2smbmJzcDthdCZuYnNwOy08YnI+aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvcmZjL3JmYzg4 MDAuaHRtbCNzZWN0aW9uLTcuNSZuYnNwO2FzJm5ic3A7YSZuYnNwO2dvb2Q8YnI+cmVmZXJlbmNl Jm5ic3A7ZnJvbSZuYnNwO2EmbmJzcDtyZWNlbnQmbmJzcDtwdWJsaXNoZWQmbmJzcDtSRkMuPGJy Pjxicj4mZ3Q7PGJyPiZndDsmbmJzcDsmZ3Q7PGJyPiZndDsmbmJzcDsmZ3Q7Jmd0OyZuYnNwO1F1 ZXN0aW9uOjxicj4mZ3Q7Jm5ic3A7Jmd0OyZndDs8YnI+Jmd0OyZuYnNwOyZndDsmZ3Q7Jm5ic3A7 SW4mbmJzcDtzZWN0aW9uJm5ic3A7NCZuYnNwO3lvdSZuYnNwO3NheTo8YnI+Jmd0OyZuYnNwOyZn dDsmZ3Q7PGJyPiZndDsmbmJzcDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwO1RoZSZuYnNwO0xTUC1FWFRFTkRFRC1GTEFHJm5ic3A7VExWJm5ic3A7TVVTVCZuYnNw O2JlJm5ic3A7ZGVmaW5lZCZuYnNwO2FzJm5ic3A7bWFuZGF0b3J5Jm5ic3A7d2hlbiZuYnNwO2Em bmJzcDtyb3V0ZXI8YnI+Jmd0OyZuYnNwOyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7c3VwcG9ydGluZyZuYnNwO3RoZSZuYnNwO0xTUCZuYnNwO09iamVjdCZuYnNw O2FuZCZuYnNwO25lZWRzJm5ic3A7dG8mbmJzcDt1c2UmbmJzcDt0aGUmbmJzcDtleHRlbmRlZCZu YnNwO2ZsYWcmbmJzcDtmaWVsZC48YnI+Jmd0OyZuYnNwOyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsm Z3Q7Jmd0OyZuYnNwO0kmbmJzcDtkb24ndCZuYnNwO3JlYWxseSZuYnNwO3BhcnNlOyZuYnNwO2Fy ZSZuYnNwO3lvdSZuYnNwO3NheWluZyZuYnNwO3RoYXQmbmJzcDtpZiZuYnNwO2l0Jm5ic3A7aXMm bmJzcDtwcmVzZW50Jm5ic3A7aXQmbmJzcDtzaG91bGQmbmJzcDtiZTxicj4mZ3Q7Jm5ic3A7Jmd0 OyZndDsmbmJzcDt0cmVhdGVkJm5ic3A7YXMmbmJzcDttYW5kYXRvcnk/PGJyPiZndDsmbmJzcDsm Z3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7Jmd0OyZndDsmbmJzcDtJZiZuYnNwO3RoYXQmbmJzcDtpcyZu YnNwO3doYXQmbmJzcDt5b3UmbmJzcDthcmUmbmJzcDtzYXlpbmcsJm5ic3A7d2hhdCZuYnNwO2Rv ZXMmbmJzcDtpdCZuYnNwO2NoYW5nZT88YnI+Jmd0OyZuYnNwOyZndDsmZ3Q7PGJyPiZndDsmbmJz cDsmZ3Q7PGJyPiZndDsmbmJzcDsmZ3Q7Jm5ic3A7W0RocnV2XTombmJzcDtJJm5ic3A7cmVhZCZu YnNwO2l0Jm5ic3A7YXMmbmJzcDthJm5ic3A7cmVxdWlyZW1lbnQmbmJzcDtmb3ImbmJzcDthJm5i c3A7ZnV0dXJlJm5ic3A7ZXh0ZW5zaW9uJm5ic3A7dGhhdCZuYnNwO3dvdWxkPGJyPiZndDsmbmJz cDsmZ3Q7Jm5ic3A7ZGVmaW5lJm5ic3A7YSZuYnNwO2ZsYWcmbmJzcDtpbiZuYnNwO3RoZSZuYnNw O0xTUC1FWFRFTkRFRC1GTEFHJm5ic3A7VExWLjxicj4mZ3Q7Jm5ic3A7Jmd0Ozxicj4mZ3Q7Jm5i c3A7Jmd0OyZuYnNwO0lmJm5ic3A7dGhhdCZuYnNwO2lzJm5ic3A7dHJ1ZSwmbmJzcDtJJm5ic3A7 d291bGQmbmJzcDtzdWdnZXN0Jm5ic3A7bm90Jm5ic3A7dXNpbmcmbmJzcDtub3JtYXRpdmUmbmJz cDtNVVNULiZuYnNwO0hvdyZuYnNwO2Fib3V0Jm5ic3A7LTxicj4mZ3Q7Jm5ic3A7Jmd0Ozxicj4m Z3Q7Jm5ic3A7Jmd0OyZuYnNwO0EmbmJzcDtmdXR1cmUmbmJzcDtleHRlbnNpb24mbmJzcDt0aGF0 Jm5ic3A7ZGVmaW5lcyZuYnNwO2EmbmJzcDtmbGFnJm5ic3A7aW4mbmJzcDt0aGUmbmJzcDtMU1At RVhURU5ERUQtRkxBRyZuYnNwO1RMVjxicj4mZ3Q7Jm5ic3A7Jmd0OyZuYnNwO2NvdWxkJm5ic3A7 bWFyayZuYnNwO3RoaXMmbmJzcDtUTFYmbmJzcDthcyZuYnNwO21hbmRhdG9yeSZuYnNwO3RvJm5i c3A7YmUmbmJzcDtjYXJyaWVkJm5ic3A7dGhlJm5ic3A7TFNQJm5ic3A7T2JqZWN0Ljxicj4mZ3Q7 PGJyPiZndDsmbmJzcDtJJm5ic3A7aGF2ZSZuYnNwO2JlZW4mbmJzcDtyZWFkaW5nJm5ic3A7YSZu YnNwO2JpdCZuYnNwO21vcmUsJm5ic3A7YnV0Jm5ic3A7dGhpcyZuYnNwO2lzJm5ic3A7c3RpbGwm bmJzcDt1bmNsZWFyJm5ic3A7dG8mbmJzcDttZSwmbmJzcDtpZiZuYnNwO0k8YnI+Jmd0OyZuYnNw O3VuZGVyc3RhbmQmbmJzcDtpdCZuYnNwO3dpbGwmbmJzcDtzdGlsbCZuYnNwO2JlJm5ic3A7dmFs aWQmbmJzcDt0byZuYnNwO3NlbmQmbmJzcDt3aXRob3V0Jm5ic3A7dGhlJm5ic3A7ZXh0ZW5kZWQm bmJzcDtUTFY8YnI+Jmd0OyZuYnNwOyhpZiZuYnNwO3lvdSZuYnNwO2Rvbid0Jm5ic3A7bmVlZCZu YnNwO3RoZSZuYnNwO2ZsYWdzKS48YnI+PGJyPlllcyEmbmJzcDtNYXliZSZuYnNwO3dlJm5ic3A7 c2hvdWxkJm5ic3A7bm90Jm5ic3A7dXNlJm5ic3A7dGhlJm5ic3A7d29yZCZuYnNwOyJtYW5kYXRv cnkiJm5ic3A7dGhlbiE8YnI+PGJyPkFzJm5ic3A7aXQmbmJzcDtpcyZuYnNwOyJtYW5kYXRvcnki Jm5ic3A7aW4mbmJzcDt0aGUmbmJzcDtjb250ZXh0Jm5ic3A7b2YmbmJzcDt1c2luZyZuYnNwO2Em bmJzcDtuZXcmbmJzcDtmZWF0dXJlJm5ic3A7ZGVmaW5lZCZuYnNwO2luPGJyPmEmbmJzcDtmdXR1 cmUmbmJzcDtleHRlbnNpb24mbmJzcDstLSZuYnNwO3NvJm5ic3A7dG8mbmJzcDt1c2UmbmJzcDt0 aGUmbmJzcDtuZXcmbmJzcDtmZWF0dXJlLCZuYnNwO2FuJm5ic3A7aW1wbGVtZW50YXRpb248YnI+ TVVTVCZuYnNwO2luY2x1ZGUmbmJzcDt0aGUmbmJzcDtMU1AtRVhURU5ERUQtRkxBRyZuYnNwO1RM ViZuYnNwO2FuZCZuYnNwO01VU1QmbmJzcDtzZXQmbmJzcDthJm5ic3A7cGFydGljdWxhciZuYnNw O2ZsYWcuPGJyPlRoZSZuYnNwO3NvLWNhbGxlZCZuYnNwOyJtYW5kYXRvcnkiJm5ic3A7d291bGQm bmJzcDtiZSZuYnNwO29ubHkmbmJzcDtpbiZuYnNwO3RoZSZuYnNwO3Njb3BlJm5ic3A7b2YmbmJz cDt0aGUmbmJzcDtwcm90b2NvbDxicj5leHRlbnNpb24mbmJzcDthbmQmbmJzcDtub3QmbmJzcDty ZXF1aXJlZCZuYnNwO3doZW4mbmJzcDt0aGUmbmJzcDtmZWF0dXJlJm5ic3A7aXMmbmJzcDtub3Qm bmJzcDt1c2VkLjxicj48YnI+Jmd0OyZuYnNwO0hvdyZuYnNwO2FyZSZuYnNwO3lvdSZuYnNwO2Rl Y2lkaW5nJm5ic3A7aWYmbmJzcDt0aGUmbmJzcDtleHRlbmRlZCZuYnNwO1RMVjxicj4mZ3Q7Jm5i c3A7bWlzc2luZz88YnI+Jmd0Ozxicj48YnI+VGhpcyZuYnNwO2NvdWxkJm5ic3A7YmUmbmJzcDti ZWNhdXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtwcmVzZW5jZSZuYnNwO29mJm5ic3A7c29tZSZu YnNwO290aGVyJm5ic3A7b2JqZWN0L1RMVnMmbmJzcDtuZWVkZWQ8YnI+YnkmbmJzcDt0aGUmbmJz cDtzYW1lJm5ic3A7ZXh0ZW5zaW9uJm5ic3A7YnV0Jm5ic3A7d2l0aG91dCZuYnNwO3RoZSZuYnNw O0xTUC1FWFRFTkRFRC1GTEFHJm5ic3A7VExWJm5ic3A7aW4mbmJzcDt0aGUmbmJzcDtMU1A8YnI+ b2JqZWN0Ljxicj5QZXJoYXBzJm5ic3A7dGhlJm5ic3A7cmlnaHQmbmJzcDt0aGluZyZuYnNwO3Rv Jm5ic3A7ZG8mbmJzcDt3b3VsZCZuYnNwO2JlJm5ic3A7dG8mbmJzcDttb3ZlJm5ic3A7dGhlJm5i c3A7ZXJyb3ImbmJzcDtoYW5kbGluZyZuYnNwO3RvPGJyPnRoZSZuYnNwO2ZpcnN0Jm5ic3A7ZG9j dW1lbnQmbmJzcDt0aGF0Jm5ic3A7dXNlcyZuYnNwO3RoZSZuYnNwO0xTUC1FWFRFTkRFRC1GTEFH Jm5ic3A7VExWJm5ic3A7aW5zdGVhZCZuYnNwO29mJm5ic3A7dGhpczxicj5kb2N1bWVudC48YnI+ PGJyPlRoYW5rcyE8YnI+RGhydXY8YnI+PGJyPiZndDs8YnI+Jmd0OyZuYnNwOy9Mb2E8YnI+Jmd0 OyZuYnNwOyZndDs8YnI+Jmd0OyZuYnNwOyZndDsmbmJzcDtUaGFua3MhPGJyPiZndDsmbmJzcDsm Z3Q7Jm5ic3A7RGhydXY8YnI+Jmd0OyZuYnNwOyZndDs8YnI+Jmd0OyZuYnNwOyZndDsmZ3Q7Jm5i c3A7L0xvYTxicj4mZ3Q7Jm5ic3A7Jmd0OyZndDs8YnI+Jmd0OyZuYnNwOyZndDsmZ3Q7PGJyPiZn dDsmbmJzcDsmZ3Q7Jmd0OyZuYnNwOy0tPGJyPiZndDsmbmJzcDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5i c3A7Jmd0OyZndDsmbmJzcDtMb2EmbmJzcDtBbmRlcnNzb24mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDtlbWFpbDombmJzcDtsb2FAcGkubnU8YnI+Jmd0OyZuYnNwOyZndDsmZ3Q7Jm5ic3A7 U2VuaW9yJm5ic3A7TVBMUyZuYnNwO0V4cGVydCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwO2xvYS5waS5udUBnbWFpbC5jb208YnI+Jmd0OyZuYnNwOyZndDsmZ3Q7Jm5i c3A7QnJvbnplJm5ic3A7RHJhZ29uJm5ic3A7Q29uc3VsdGluZyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O3Bob25lOiZuYnNwOys0NiZuYnNwOzczOSZuYnNwOzgxJm5ic3A7MjEmbmJzcDs2NDxicj4mZ3Q7 PGJyPiZndDsmbmJzcDstLTxicj4mZ3Q7PGJyPiZndDsmbmJzcDtMb2EmbmJzcDtBbmRlcnNzb24m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtlbWFpbDombmJzcDtsb2FAcGkubnU8YnI+Jmd0 OyZuYnNwO1NlbmlvciZuYnNwO01QTFMmbmJzcDtFeHBlcnQmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDtsb2EucGkubnVAZ21haWwuY29tPGJyPiZndDsmbmJzcDtCcm9u emUmbmJzcDtEcmFnb24mbmJzcDtDb25zdWx0aW5nJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cGhvbmU6 Jm5ic3A7KzQ2Jm5ic3A7NzM5Jm5ic3A7ODEmbmJzcDsyMSZuYnNwOzY0PC9kaXY+PC9kaXY+PC9k aXY+PC9kaXY+PC9kaXY+PC9kaXY+PHA+PGJyPjwvcD48L2Rpdj4= --=====_003_next=====-- --=====_002_next=====-- --=====_001_next=====-- From nobody Wed Jul 29 22:46:52 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A143D3A0E25 for ; Wed, 29 Jul 2020 22:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dhruvdhody-com.20150623.gappssmtp.com 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 hELH1k42m3fu for ; Wed, 29 Jul 2020 22:46:48 -0700 (PDT) Received: from mail-pf1-x442.google.com (mail-pf1-x442.google.com [IPv6:2607:f8b0:4864:20::442]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 981253A0E23 for ; Wed, 29 Jul 2020 22:46:48 -0700 (PDT) Received: by mail-pf1-x442.google.com with SMTP id y206so4104383pfb.10 for ; Wed, 29 Jul 2020 22:46:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dhruvdhody-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=B3vU0SB0WWq7pHACm2OiGAkb5vk/Pq9cd5ZszVLNi28=; b=Y0leM4zkO/LONJMrAD+0SWoBPlf1o/W9AXp896eBcuC1z9ojs4KjgWoBPzAUPXQTC/ G+kYNEuIGysYg6QECis9A1ZIJrtpbDK8Z/GqM0L45cDKFpp8/wfE3GoqKbV8zoqtFx6F baq6XxYcCRb240r722cUeTtfF/SMr6g5rmZ/ZgvpC1JEtBPVreDV8wUaRw7Z6aLZyKm8 JEZVOz8a2p5VB7ad4f4P15moC0rSk81kuxccvMNmLY/igBFq8OsLDqnQw/X6vJZvxPS2 HY8vrTE6NgSh0EXxbXPoxTtWMQLBLON35nyqdGOH2xsEm+CJbesivXrwEgnJJQGwL9Ht CN+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=B3vU0SB0WWq7pHACm2OiGAkb5vk/Pq9cd5ZszVLNi28=; b=iEoPjcPv09ZRR/Ce821IqYTkqOJMKRBJanDFwJC7Dz862Que+ze+uAkfyh7QmwoR8X LD0/uVneO1FjRl6MvE8q6Lc14n5gjlvf+Ut2Xo6aSQ2BSNNSk3p7UdalRaWENyexH0oD 0C5xUbyZBpuvERjKOLdfSY5AmP7nW3jmoR6QvFYCL5/xBRRVkK1/r8VANru4nAwb1/wC rpPC9ItDRU8i4tzkMpfXchiHOMQfyUqzX+U+RmIx8lrahgtVnClDakX9NZIG2OyAn9OD TuZc376yP+fpeSTgOgfx3O/P+mSIdR97abmwZIs2HkXT37UhCVZ+cbAo0lC+1zOrm938 M8TA== X-Gm-Message-State: AOAM531Q5QX7VkfYK3KL/QbQ+kTzfM9jFkHlL038BDTnw17hDCgvJtjU t4OVBmvNxpNValGXH+di4C2A/2RgVllNVW3QURvZ8Pt7c1bBIg== X-Google-Smtp-Source: ABdhPJyxAM+HoTAW+lQ9Zd8sIEuq9//zrdqgqz2UOwF3PIj85pxAcwRXr0+pbiya2J3lIy9LDxxLYdi0krBj2nfk/vg= X-Received: by 2002:a62:a20d:: with SMTP id m13mr1652391pff.201.1596088007420; Wed, 29 Jul 2020 22:46:47 -0700 (PDT) MIME-Version: 1.0 References: <202007301030421412655@zte.com.cn> In-Reply-To: <202007301030421412655@zte.com.cn> From: Dhruv Dhody Date: Thu, 30 Jul 2020 11:16:36 +0530 Message-ID: To: xiong.quan@zte.com.cn Cc: Loa Andersson , draft-xiong-pce-lsp-flag@ietf.org, pce-chairs , pce@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Pce] cursory review of draft-xiong-pce-lsp-flag X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 05:46:51 -0000 Hi Quan, On Thu, Jul 30, 2020 at 8:00 AM wrote: > > > Hi Dhruv and Loa, > > > Thanks for your review and detailed discussion! > > For the IANA text, I will update that as you suggest. > > > In my view, we need to clarify the LSP-EXTENDED-FLAG TLV is mandatory or = not firstly. Then consider the error handling. > > There are two cases. > > First case, for the implementations which just use the Flag field of LSP= Object from bit 1 to bit 11, it has no need to carry LSP-EXTENDED-FLAG TL= V and not mandatory. > > Second case, for the implementations which will use the flag of LSP-EXTEN= DED-FLAG TLV, It is mandatory. When LSP-EXTENDED-FLAG TLV is missing, the = error handling should be taken into consideration. > >From the point of view of this I-D there are no flags defined in the LSP-EXTENDED-FLAG TLV yet. Also, Loa rightly pointed out that any text would be incomplete as an implementation that just receives an LSP object without the LSP-EXTENDED-FLAG TLV would not know if it is the first "valid" or the second "error" case in your text above just by the fact that the TLV is missing. The error would be noticed in conjunction with some other encoding required by the extension. So my suggestion would be to move the error handling to the first document that defines the flag in LSP-EXTENDED-FLAG TLV. We have documents that need to use it right away so this should not be a problem, just some coordination. Thanks! Dhruv > > I suggest to make clarification in the draft about the implementations > > or use the bit 0 of Flag field in LSP Object to indicate the existing of = the LSP-EXTENDED-FLAG TLV? > > Could you tell me what is your suggestion? > > > Thanks, > > Quan > > > > > =E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6 > =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9ADhruvDhody > =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9ALoa Andersson ; > =E6=8A=84=E9=80=81=E4=BA=BA=EF=BC=9Adraft-xiong-pce-lsp-flag@ietf.org ;pce-chairs@ietf.org ;= pce@ietf.org ; > =E6=97=A5 =E6=9C=9F =EF=BC=9A2020=E5=B9=B407=E6=9C=8829=E6=97=A5 19:15 > =E4=B8=BB =E9=A2=98 =EF=BC=9ARe: cursory review of draft-xiong-pce-lsp-fl= ag > Hi Loa, > > On Wed, Jul 29, 2020 at 4:13 PM Loa Andersson wrote: > > > > Dhruv, > > > > Inline please. > > > > On 29/07/2020 17:01, Dhruv Dhody wrote: > > > Hi Loa, > > > > > >> Comment: > > >> > > >> 5.2. PCEP-Error Object > > >> > > >> IANA is requested to register the following error types and err= or > > >> values within the "PCEP-ERROR Object Error Types and Values" > > >> subregistry of the "Path Computation Element Protocol (PCEP) Nu= mbers" > > >> registry: > > >> > > >> +--------------+-------------------------------------+ > > >> | Error-Type | Meaning | > > >> +--------------+-------------------------------------+ > > >> | 6 | Mandatory Object missing | > > >> | | Error-value | > > >> | | TBD2: LSP-EXTENDED-FLAG TLV missing | > > >> +--------------+-------------------------------------+ > > >> > > >> Table 2 > > >> > > >> Both the RTG DIR rules and IANA rules strongly advice against puttin= g > > >> fixed numeric values into allocation from existing registries. The > > >> reason is obvious, in the time from you put the value in your docume= nt > > >> until iet is ready for IESG review (which includes IANA review) some= one > > >> else might have been assigned tht value. This has happened and have > > >> caused serious problems. > > >> > > >> 6 in table 2 hould be replaced with TBA (to be assigned). > > >> > > >> Note: If you really want the value 6, we should go for an early > > >> allocation as soon as we have the wg document. > > >> > > > > > > [Dhruv] The value 6 is for Error-Type already allocated by RFC 5440. > > > This I-D is asking for a new Error-Value which is TBD2. A reference > > > column in the IANA table would have helped here. > > > > hmmmm - okey, but no, we are asking IANA to register a new error-value, > > but not a new error type. The text says: > > > > "IANA is requested to register the following error types and error > > values ..." > > > > This text is incorrect then and should be fixed. > > > But then the table is very unclear, at a minimum it should look > > something like this: > > > > +-------------+----------------------------+------------------------= -+ > > | Error-Type | Meaning | Error-value = | > > +-------------+----------------------------+------------------------= -+ > > | 6 | Mandatory Object missing | 0: Unassigned = | > > | | | 1-15 Assigned = | > > | | | TBD2: LSP-EXTENDED-FLAG= | > > | | | TLV missing = | > > +-------------+----------------------------+------------------------= -+ > > > > Table 2 > > > Yes. I suggest Quan to look at - > https://www.rfc-editor.org/rfc/rfc8800.html#section-7.5 as a good > reference from a recent published RFC. > > > > > > > > >> Question: > > >> > > >> In section 4 you say: > > >> > > >> The LSP-EXTENDED-FLAG TLV MUST be defined as mandatory when a r= outer > > >> supporting the LSP Object and needs to use the extended flag fi= eld. > > >> > > >> I don't really parse; are you saying that if it is present it should= be > > >> treated as mandatory? > > >> > > >> If that is what you are saying, what does it change? > > >> > > > > > > [Dhruv]: I read it as a requirement for a future extension that would > > > define a flag in the LSP-EXTENDED-FLAG TLV. > > > > > > If that is true, I would suggest not using normative MUST. How about = - > > > > > > A future extension that defines a flag in the LSP-EXTENDED-FLAG TLV > > > could mark this TLV as mandatory to be carried the LSP Object. > > > > I have been reading a bit more, but this is still unclear to me, if I > > understand it will still be valid to send without the extended TLV > > (if you don't need the flags). > > Yes! Maybe we should not use the word "mandatory" then! > > As it is "mandatory" in the context of using a new feature defined in > a future extension -- so to use the new feature, an implementation > MUST include the LSP-EXTENDED-FLAG TLV and MUST set a particular flag. > The so-called "mandatory" would be only in the scope of the protocol > extension and not required when the feature is not used. > > > How are you deciding if the extended TLV > > missing? > > > > This could be because of the presence of some other object/TLVs needed > by the same extension but without the LSP-EXTENDED-FLAG TLV in the LSP > object. > Perhaps the right thing to do would be to move the error handling to > the first document that uses the LSP-EXTENDED-FLAG TLV instead of this > document. > > Thanks! > Dhruv > > > > > /Loa > > > > > > Thanks! > > > Dhruv > > > > > >> /Loa > > >> > > >> > > >> -- > > >> > > >> Loa Andersson email: loa@pi.nu > > >> Senior MPLS Expert loa.pi.nu@gmail.com > > >> Bronze Dragon Consulting phone: +46 739 81 21 64 > > > > -- > > > > Loa Andersson email: loa@pi.nu > > Senior MPLS Expert loa.pi.nu@gmail.com > > Bronze Dragon Consulting phone: +46 739 81 21 64 > > From nobody Wed Jul 29 23:02:32 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 676B43A0E48; Wed, 29 Jul 2020 23:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 kulTU1s1ntsg; Wed, 29 Jul 2020 23:00:43 -0700 (PDT) Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (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 9A02E3A077E; Wed, 29 Jul 2020 23:00:42 -0700 (PDT) Received: from mse-fl2.zte.com.cn (unknown [10.30.14.239]) by Forcepoint Email with ESMTPS id EA3AA8D1B9984F5366AB; Thu, 30 Jul 2020 14:00:39 +0800 (CST) Received: from njxapp02.zte.com.cn ([10.41.132.201]) by mse-fl2.zte.com.cn with SMTP id 06U60cSd045735; Thu, 30 Jul 2020 14:00:38 +0800 (GMT-8) (envelope-from xiong.quan@zte.com.cn) Received: from mapi (njxapp03[null]) by mapi (Zmail) with MAPI id mid201; Thu, 30 Jul 2020 14:00:37 +0800 (CST) Date: Thu, 30 Jul 2020 14:00:37 +0800 (CST) X-Zmail-TransId: 2afb5f2262056c85e7a5 X-Mailer: Zmail v1.0 Message-ID: <202007301400379208395@zte.com.cn> In-Reply-To: References: CAP7zK5bw9_1+DY0WH0Y+MpqVuE34rj9YXMJ6-A7864PtUpX-0A@mail.gmail.com, CAP7zK5Zk=0GANmdiAz4KvQzo1K2E+frSoVWmvCFLsoAh5kMZzg@mail.gmail.com Mime-Version: 1.0 From: To: Cc: , , , Content-Type: multipart/mixed; boundary="=====_001_next=====" X-MAIL: mse-fl2.zte.com.cn 06U60cSd045735 Archived-At: Subject: [Pce] =?utf-8?b?562U5aSNOiBjdXJzb3J5IHJldmlldyBvZiBkcmFmdC14aW9u?= =?utf-8?q?g-pce-lsp-flag?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 06:00:59 -0000 --=====_001_next===== Content-Type: multipart/related; boundary="=====_002_next=====" --=====_002_next===== Content-Type: multipart/alternative; boundary="=====_003_next=====" --=====_003_next===== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgRGhydXYsDQoNCg0KDQoNCg0KDQoNClRoYW5rcyBmb3IgeW91ciBxdWljayByZXBseSBhbmQg c3VnZ2VzdGlvbiENCg0KDQpUaGUgIExTUC1FWFRFTkRFRC1GTEFHIFRMViBpcyBub3QgbWFuZGF0 b3J5IGFuZCBJIHdpbGwgbW9kaWZ5IGFuZCBtb3ZlIHRoZSBlcnJvciBoYW5kaW5nIHRvIHRoZSBk cmFmdC1wZW5nLXBjZS1lbnRyb3B5LWxhYmVsIHdoaWNoIG5lZWRzIHRvIHVzZSB0aGUgZmxhZy4g IEkgd2lsbCB1cGRhdGUgdGhlIGRyYWZ0cyBhcyB5b3Ugc3VnZ2VzdCBhcyBzb29uIGFzIHBvc3Np YmxlIQ0KDQoNCg0KDQoNCg0KVGhhbmtzLA0KDQoNClF1YW4NCg0KDQoNCg0KDQoNCg0K5Y6f5aeL 6YKu5Lu2DQoNCg0KDQrlj5Hku7bkurrvvJpEaHJ1dkRob2R5IDxkZEBkaHJ1dmRob2R5LmNvbT4N CuaUtuS7tuS6uu+8mueGiuaziTAwMDkxMDY1Ow0K5oqE6YCB5Lq677yaTG9hIEFuZGVyc3NvbiA8 bG9hQHBpLm51PjtkcmFmdC14aW9uZy1wY2UtbHNwLWZsYWdAaWV0Zi5vcmcgPGRyYWZ0LXhpb25n LXBjZS1sc3AtZmxhZ0BpZXRmLm9yZz47cGNlLWNoYWlycyA8cGNlLWNoYWlyc0BpZXRmLm9yZz47 cGNlQGlldGYub3JnIDxwY2VAaWV0Zi5vcmc+Ow0K5pelIOacnyDvvJoyMDIw5bm0MDfmnIgzMOaX pSAxMzo0Nw0K5Li7IOmimCDvvJpSZTogY3Vyc29yeSByZXZpZXcgb2YgZHJhZnQteGlvbmctcGNl LWxzcC1mbGFnDQoNCg0KSGkgUXVhbiwNCg0KT24gVGh1LCBKdWwgMzAsIDIwMjAgYXQgODowMCBB TSA8eGlvbmcucXVhbkB6dGUuY29tLmNuPiB3cm90ZToNCj4NCj4NCj4gSGkgRGhydXYgYW5kIExv YSwNCj4NCj4NCj4gVGhhbmtzIGZvciB5b3VyIHJldmlldyBhbmQgZGV0YWlsZWQgZGlzY3Vzc2lv biENCj4NCj4gRm9yIHRoZSBJQU5BIHRleHQsIEkgd2lsbCB1cGRhdGUgdGhhdCBhcyB5b3Ugc3Vn Z2VzdC4NCj4NCj4NCj4gSW4gbXkgdmlldywgd2UgbmVlZCB0byBjbGFyaWZ5IHRoZSBMU1AtRVhU RU5ERUQtRkxBRyBUTFYgaXMgbWFuZGF0b3J5IG9yIG5vdCBmaXJzdGx5LiBUaGVuIGNvbnNpZGVy IHRoZSBlcnJvciBoYW5kbGluZy4NCj4NCj4gVGhlcmUgYXJlIHR3byBjYXNlcy4NCj4NCj4gRmly c3QgY2FzZSwgZm9yIHRoZSBpbXBsZW1lbnRhdGlvbnMgd2hpY2gganVzdCB1c2UgdGhlIEZsYWcg ZmllbGQgb2YgIExTUCBPYmplY3QgZnJvbSAgYml0IDEgdG8gYml0IDExLCBpdCBoYXMgbm8gbmVl ZCB0byBjYXJyeSBMU1AtRVhURU5ERUQtRkxBRyBUTFYgYW5kIG5vdCBtYW5kYXRvcnkuDQo+DQo+ IFNlY29uZCBjYXNlLCBmb3IgdGhlIGltcGxlbWVudGF0aW9ucyB3aGljaCB3aWxsIHVzZSB0aGUg ZmxhZyBvZiBMU1AtRVhURU5ERUQtRkxBRyBUTFYsIEl0IGlzIG1hbmRhdG9yeS4gIFdoZW4gTFNQ LUVYVEVOREVELUZMQUcgVExWIGlzIG1pc3NpbmcsIHRoZSBlcnJvciBoYW5kbGluZyBzaG91bGQg YmUgdGFrZW4gaW50byBjb25zaWRlcmF0aW9uLg0KPg0KDQo+RnJvbSB0aGUgcG9pbnQgb2Ygdmll dyBvZiB0aGlzIEktRCB0aGVyZSBhcmUgbm8gZmxhZ3MgZGVmaW5lZCBpbiB0aGUNCkxTUC1FWFRF TkRFRC1GTEFHIFRMViB5ZXQuDQoNCkFsc28sIExvYSByaWdodGx5IHBvaW50ZWQgb3V0IHRoYXQg YW55IHRleHQgd291bGQgYmUgaW5jb21wbGV0ZSBhcyBhbg0KaW1wbGVtZW50YXRpb24gdGhhdCBq dXN0IHJlY2VpdmVzIGFuIExTUCBvYmplY3Qgd2l0aG91dCB0aGUNCkxTUC1FWFRFTkRFRC1GTEFH IFRMViB3b3VsZCBub3Qga25vdyBpZiBpdCBpcyB0aGUgZmlyc3QgInZhbGlkIiBvciB0aGUNCnNl Y29uZCAiZXJyb3IiIGNhc2UgaW4geW91ciB0ZXh0IGFib3ZlIGp1c3QgYnkgdGhlIGZhY3QgdGhh dCB0aGUgVExWDQppcyBtaXNzaW5nLiBUaGUgZXJyb3Igd291bGQgYmUgbm90aWNlZCBpbiBjb25q dW5jdGlvbiB3aXRoIHNvbWUgb3RoZXINCmVuY29kaW5nIHJlcXVpcmVkIGJ5IHRoZSBleHRlbnNp b24uDQoNClNvIG15IHN1Z2dlc3Rpb24gd291bGQgYmUgdG8gbW92ZSB0aGUgZXJyb3IgaGFuZGxp bmcgdG8gdGhlIGZpcnN0DQpkb2N1bWVudCB0aGF0IGRlZmluZXMgdGhlIGZsYWcgaW4gTFNQLUVY VEVOREVELUZMQUcgVExWLiBXZSBoYXZlDQpkb2N1bWVudHMgdGhhdCBuZWVkIHRvIHVzZSBpdCBy aWdodCBhd2F5IHNvIHRoaXMgc2hvdWxkIG5vdCBiZSBhDQpwcm9ibGVtLCBqdXN0IHNvbWUgY29v cmRpbmF0aW9uLg0KDQpUaGFua3MhDQpEaHJ1dg0KDQo+DQo+IEkgc3VnZ2VzdCB0byBtYWtlIGNs YXJpZmljYXRpb24gaW4gdGhlIGRyYWZ0IGFib3V0IHRoZSBpbXBsZW1lbnRhdGlvbnMNCj4NCj4g b3IgdXNlIHRoZSBiaXQgMCBvZiBGbGFnIGZpZWxkIGluIExTUCBPYmplY3QgdG8gaW5kaWNhdGUg dGhlIGV4aXN0aW5nIG9mIHRoZSBMU1AtRVhURU5ERUQtRkxBRyBUTFY/DQo+DQo+IENvdWxkIHlv dSB0ZWxsIG1lIHdoYXQgaXMgeW91ciBzdWdnZXN0aW9uPw0KPg0KPg0KPiBUaGFua3MsDQo+DQo+ IFF1YW4NCj4NCj4NCj4NCj4NCj4g5Y6f5aeL6YKu5Lu2DQo+IOWPkeS7tuS6uu+8mkRocnV2RGhv ZHkgPGRkQGRocnV2ZGhvZHkuY29tPg0KPiDmlLbku7bkurrvvJpMb2EgQW5kZXJzc29uIDxsb2FA cGkubnU+Ow0KPiDmioTpgIHkurrvvJpkcmFmdC14aW9uZy1wY2UtbHNwLWZsYWdAaWV0Zi5vcmcg PGRyYWZ0LXhpb25nLXBjZS1sc3AtZmxhZ0BpZXRmLm9yZz47cGNlLWNoYWlyc0BpZXRmLm9yZyA8 cGNlLWNoYWlyc0BpZXRmLm9yZz47cGNlQGlldGYub3JnIDxwY2VAaWV0Zi5vcmc+Ow0KPiDml6Ug 5pyfIO+8mjIwMjDlubQwN+aciDI55pelIDE5OjE1DQo+IOS4uyDpopgg77yaUmU6IGN1cnNvcnkg cmV2aWV3IG9mIGRyYWZ0LXhpb25nLXBjZS1sc3AtZmxhZw0KPiBIaSBMb2EsDQo+DQo+IE9uIFdl ZCwgSnVsIDI5LCAyMDIwIGF0IDQ6MTMgUE0gTG9hIEFuZGVyc3NvbiA8bG9hQHBpLm51PiB3cm90 ZToNCj4gPg0KPiA+IERocnV2LA0KPiA+DQo+ID4gSW5saW5lIHBsZWFzZS4NCj4gPg0KPiA+IE9u IDI5LzA3LzIwMjAgMTc6MDEsIERocnV2IERob2R5IHdyb3RlOg0KPiA+ID4gSGkgTG9hLA0KPiA+ ID4NCj4gPiA+PiBDb21tZW50Og0KPiA+ID4+DQo+ID4gPj4gNS4yLiAgUENFUC1FcnJvciBPYmpl Y3QNCj4gPiA+Pg0KPiA+ID4+ICAgICAgSUFOQSBpcyByZXF1ZXN0ZWQgdG8gcmVnaXN0ZXIgdGhl IGZvbGxvd2luZyBlcnJvciB0eXBlcyBhbmQgZXJyb3INCj4gPiA+PiAgICAgIHZhbHVlcyB3aXRo aW4gdGhlICJQQ0VQLUVSUk9SIE9iamVjdCBFcnJvciBUeXBlcyBhbmQgVmFsdWVzIg0KPiA+ID4+ ICAgICAgc3VicmVnaXN0cnkgb2YgdGhlICJQYXRoIENvbXB1dGF0aW9uIEVsZW1lbnQgUHJvdG9j b2wgKFBDRVApIE51bWJlcnMiDQo+ID4gPj4gICAgICByZWdpc3RyeToNCj4gPiA+Pg0KPiA+ID4+ ICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tKw0KPiA+ID4+ICAgICAgICAgICAgIHwgIEVycm9yLVR5cGUgIHwgIE1lYW5pbmcg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPiA+ID4+ICAgICAgICAgICAgICstLS0tLS0t LS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPiA+ID4+ICAg ICAgICAgICAgIHwgIDYgICAgICAgICAgIHwgIE1hbmRhdG9yeSBPYmplY3QgbWlzc2luZyAgICAg ICAgICAgfA0KPiA+ID4+ICAgICAgICAgICAgIHwgICAgICAgICAgICAgIHwgIEVycm9yLXZhbHVl ICAgICAgICAgICAgICAgICAgICAgICAgfA0KPiA+ID4+ICAgICAgICAgICAgIHwgICAgICAgICAg ICAgIHwgVEJEMjogTFNQLUVYVEVOREVELUZMQUcgVExWIG1pc3NpbmcgfA0KPiA+ID4+ICAgICAg ICAgICAgICstLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tKw0KPiA+ID4+DQo+ID4gPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg VGFibGUgMg0KPiA+ID4+DQo+ID4gPj4gQm90aCB0aGUgUlRHIERJUiBydWxlcyBhbmQgSUFOQSBy dWxlcyBzdHJvbmdseSBhZHZpY2UgYWdhaW5zdCBwdXR0aW5nDQo+ID4gPj4gZml4ZWQgbnVtZXJp YyAgdmFsdWVzIGludG8gYWxsb2NhdGlvbiBmcm9tIGV4aXN0aW5nIHJlZ2lzdHJpZXMuIFRoZQ0K PiA+ID4+IHJlYXNvbiBpcyBvYnZpb3VzLCBpbiB0aGUgdGltZSBmcm9tIHlvdSBwdXQgdGhlIHZh bHVlIGluIHlvdXIgZG9jdW1lbnQNCj4gPiA+PiB1bnRpbCBpZXQgaXMgcmVhZHkgZm9yIElFU0cg cmV2aWV3ICh3aGljaCBpbmNsdWRlcyBJQU5BIHJldmlldykgc29tZW9uZQ0KPiA+ID4+IGVsc2Ug bWlnaHQgaGF2ZSBiZWVuIGFzc2lnbmVkIHRodCB2YWx1ZS4gVGhpcyBoYXMgaGFwcGVuZWQgYW5k IGhhdmUNCj4gPiA+PiBjYXVzZWQgc2VyaW91cyBwcm9ibGVtcy4NCj4gPiA+Pg0KPiA+ID4+IDYg aW4gdGFibGUgMiBob3VsZCBiZSByZXBsYWNlZCB3aXRoIFRCQSAodG8gYmUgYXNzaWduZWQpLg0K PiA+ID4+DQo+ID4gPj4gTm90ZTogSWYgeW91IHJlYWxseSB3YW50IHRoZSB2YWx1ZSA2LCB3ZSBz aG91bGQgZ28gZm9yIGFuIGVhcmx5DQo+ID4gPj4gYWxsb2NhdGlvbiBhcyBzb29uIGFzIHdlIGhh dmUgdGhlIHdnIGRvY3VtZW50Lg0KPiA+ID4+DQo+ID4gPg0KPiA+ID4gW0RocnV2XSBUaGUgdmFs dWUgNiBpcyBmb3IgRXJyb3ItVHlwZSBhbHJlYWR5IGFsbG9jYXRlZCBieSBSRkMgNTQ0MC4NCj4g PiA+IFRoaXMgSS1EIGlzIGFza2luZyBmb3IgYSBuZXcgRXJyb3ItVmFsdWUgd2hpY2ggaXMgIFRC RDIuIEEgcmVmZXJlbmNlDQo+ID4gPiBjb2x1bW4gaW4gdGhlIElBTkEgdGFibGUgd291bGQgaGF2 ZSBoZWxwZWQgaGVyZS4NCj4gPg0KPiA+IGhtbW1tIC0gb2tleSwgYnV0IG5vLCB3ZSBhcmUgYXNr aW5nIElBTkEgdG8gcmVnaXN0ZXIgYSBuZXcgZXJyb3ItdmFsdWUsDQo+ID4gYnV0IG5vdCBhIG5l dyBlcnJvciB0eXBlLiBUaGUgdGV4dCBzYXlzOg0KPiA+DQo+ID4gICAgIklBTkEgaXMgcmVxdWVz dGVkIHRvIHJlZ2lzdGVyIHRoZSBmb2xsb3dpbmcgZXJyb3IgdHlwZXMgYW5kIGVycm9yDQo+ID4g ICAgICB2YWx1ZXMgLi4uIg0KPiA+DQo+DQo+IFRoaXMgdGV4dCBpcyBpbmNvcnJlY3QgdGhlbiBh bmQgc2hvdWxkIGJlIGZpeGVkLg0KPg0KPiA+IEJ1dCB0aGVuIHRoZSB0YWJsZSBpcyB2ZXJ5IHVu Y2xlYXIsIGF0IGEgbWluaW11bSBpdCBzaG91bGQgbG9vaw0KPiA+IHNvbWV0aGluZyBsaWtlIHRo aXM6DQo+ID4NCj4gPiAgICArLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+ID4gICAgfCAgRXJyb3ItVHlwZSB8IE1l YW5pbmcgICAgICAgICAgICAgICAgICAgIHwgRXJyb3ItdmFsdWUgICAgICAgICAgICAgfA0KPiA+ ICAgICstLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSsNCj4gPiAgICB8ICA2ICAgICAgICAgIHwgTWFuZGF0b3J5IE9iamVj dCBtaXNzaW5nICAgfCAwOiBVbmFzc2lnbmVkICAgICAgICAgICB8DQo+ID4gICAgfCAgICAgICAg ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgMS0xNSBBc3NpZ25lZCAgICAgICAg ICAgfA0KPiA+ICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 IFRCRDI6IExTUC1FWFRFTkRFRC1GTEFHIHwNCj4gPiAgICB8ICAgICAgICAgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICBUTFYgbWlzc2luZyAgICAgICB8DQo+ID4gICAg Ky0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tKw0KPiA+DQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBUYWJsZSAyDQo+ID4NCj4gWWVzLiBJIHN1Z2dlc3QgUXVhbiB0byBsb29rIGF0IC0NCj4g aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvcmZjL3JmYzg4MDAuaHRtbCNzZWN0aW9uLTcuNSBh cyBhIGdvb2QNCj4gcmVmZXJlbmNlIGZyb20gYSByZWNlbnQgcHVibGlzaGVkIFJGQy4NCj4NCj4g Pg0KPiA+ID4NCj4gPiA+PiBRdWVzdGlvbjoNCj4gPiA+Pg0KPiA+ID4+IEluIHNlY3Rpb24gNCB5 b3Ugc2F5Og0KPiA+ID4+DQo+ID4gPj4gICAgICBUaGUgTFNQLUVYVEVOREVELUZMQUcgVExWIE1V U1QgYmUgZGVmaW5lZCBhcyBtYW5kYXRvcnkgd2hlbiBhIHJvdXRlcg0KPiA+ID4+ICAgICAgc3Vw cG9ydGluZyB0aGUgTFNQIE9iamVjdCBhbmQgbmVlZHMgdG8gdXNlIHRoZSBleHRlbmRlZCBmbGFn IGZpZWxkLg0KPiA+ID4+DQo+ID4gPj4gSSBkb24ndCByZWFsbHkgcGFyc2U7IGFyZSB5b3Ugc2F5 aW5nIHRoYXQgaWYgaXQgaXMgcHJlc2VudCBpdCBzaG91bGQgYmUNCj4gPiA+PiB0cmVhdGVkIGFz IG1hbmRhdG9yeT8NCj4gPiA+Pg0KPiA+ID4+IElmIHRoYXQgaXMgd2hhdCB5b3UgYXJlIHNheWlu Zywgd2hhdCBkb2VzIGl0IGNoYW5nZT8NCj4gPiA+Pg0KPiA+ID4NCj4gPiA+IFtEaHJ1dl06IEkg cmVhZCBpdCBhcyBhIHJlcXVpcmVtZW50IGZvciBhIGZ1dHVyZSBleHRlbnNpb24gdGhhdCB3b3Vs ZA0KPiA+ID4gZGVmaW5lIGEgZmxhZyBpbiB0aGUgTFNQLUVYVEVOREVELUZMQUcgVExWLg0KPiA+ ID4NCj4gPiA+IElmIHRoYXQgaXMgdHJ1ZSwgSSB3b3VsZCBzdWdnZXN0IG5vdCB1c2luZyBub3Jt YXRpdmUgTVVTVC4gSG93IGFib3V0IC0NCj4gPiA+DQo+ID4gPiBBIGZ1dHVyZSBleHRlbnNpb24g dGhhdCBkZWZpbmVzIGEgZmxhZyBpbiB0aGUgTFNQLUVYVEVOREVELUZMQUcgVExWDQo+ID4gPiBj b3VsZCBtYXJrIHRoaXMgVExWIGFzIG1hbmRhdG9yeSB0byBiZSBjYXJyaWVkIHRoZSBMU1AgT2Jq ZWN0Lg0KPiA+DQo+ID4gSSBoYXZlIGJlZW4gcmVhZGluZyBhIGJpdCBtb3JlLCBidXQgdGhpcyBp cyBzdGlsbCB1bmNsZWFyIHRvIG1lLCBpZiBJDQo+ID4gdW5kZXJzdGFuZCBpdCB3aWxsIHN0aWxs IGJlIHZhbGlkIHRvIHNlbmQgd2l0aG91dCB0aGUgZXh0ZW5kZWQgVExWDQo+ID4gKGlmIHlvdSBk b24ndCBuZWVkIHRoZSBmbGFncykuDQo+DQo+IFllcyEgTWF5YmUgd2Ugc2hvdWxkIG5vdCB1c2Ug dGhlIHdvcmQgIm1hbmRhdG9yeSIgdGhlbiENCj4NCj4gQXMgaXQgaXMgIm1hbmRhdG9yeSIgaW4g dGhlIGNvbnRleHQgb2YgdXNpbmcgYSBuZXcgZmVhdHVyZSBkZWZpbmVkIGluDQo+IGEgZnV0dXJl IGV4dGVuc2lvbiAtLSBzbyB0byB1c2UgdGhlIG5ldyBmZWF0dXJlLCBhbiBpbXBsZW1lbnRhdGlv bg0KPiBNVVNUIGluY2x1ZGUgdGhlIExTUC1FWFRFTkRFRC1GTEFHIFRMViBhbmQgTVVTVCBzZXQg YSBwYXJ0aWN1bGFyIGZsYWcuDQo+IFRoZSBzby1jYWxsZWQgIm1hbmRhdG9yeSIgd291bGQgYmUg b25seSBpbiB0aGUgc2NvcGUgb2YgdGhlIHByb3RvY29sDQo+IGV4dGVuc2lvbiBhbmQgbm90IHJl cXVpcmVkIHdoZW4gdGhlIGZlYXR1cmUgaXMgbm90IHVzZWQuDQo+DQo+ID4gSG93IGFyZSB5b3Ug ZGVjaWRpbmcgaWYgdGhlIGV4dGVuZGVkIFRMVg0KPiA+IG1pc3Npbmc/DQo+ID4NCj4NCj4gVGhp cyBjb3VsZCBiZSBiZWNhdXNlIG9mIHRoZSBwcmVzZW5jZSBvZiBzb21lIG90aGVyIG9iamVjdC9U TFZzIG5lZWRlZA0KPiBieSB0aGUgc2FtZSBleHRlbnNpb24gYnV0IHdpdGhvdXQgdGhlIExTUC1F WFRFTkRFRC1GTEFHIFRMViBpbiB0aGUgTFNQDQo+IG9iamVjdC4NCj4gUGVyaGFwcyB0aGUgcmln aHQgdGhpbmcgdG8gZG8gd291bGQgYmUgdG8gbW92ZSB0aGUgZXJyb3IgaGFuZGxpbmcgdG8NCj4g dGhlIGZpcnN0IGRvY3VtZW50IHRoYXQgdXNlcyB0aGUgTFNQLUVYVEVOREVELUZMQUcgVExWIGlu c3RlYWQgb2YgdGhpcw0KPiBkb2N1bWVudC4NCj4NCj4gVGhhbmtzIQ0KPiBEaHJ1dg0KPg0KPiA+ DQo+ID4gL0xvYQ0KPiA+ID4NCj4gPiA+IFRoYW5rcyENCj4gPiA+IERocnV2DQo+ID4gPg0KPiA+ ID4+IC9Mb2ENCj4gPiA+Pg0KPiA+ID4+DQo+ID4gPj4gLS0NCj4gPiA+Pg0KPiA+ID4+IExvYSBB bmRlcnNzb24gICAgICAgICAgICAgICAgICAgICAgICBlbWFpbDogbG9hQHBpLm51DQo+ID4gPj4g U2VuaW9yIE1QTFMgRXhwZXJ0ICAgICAgICAgICAgICAgICAgICAgICAgICBsb2EucGkubnVAZ21h aWwuY29tDQo+ID4gPj4gQnJvbnplIERyYWdvbiBDb25zdWx0aW5nICAgICAgICAgICAgIHBob25l OiArNDYgNzM5IDgxIDIxIDY0DQo+ID4NCj4gPiAtLQ0KPiA+DQo+ID4gTG9hIEFuZGVyc3NvbiAg ICAgICAgICAgICAgICAgICAgICAgIGVtYWlsOiBsb2FAcGkubnUNCj4gPiBTZW5pb3IgTVBMUyBF eHBlcnQgICAgICAgICAgICAgICAgICAgICAgICAgIGxvYS5waS5udUBnbWFpbC5jb20NCj4gPiBC cm9uemUgRHJhZ29uIENvbnN1bHRpbmcgICAgICAgICAgICAgcGhvbmU6ICs0NiA3MzkgODEgMjEg NjQNCj4NCj4= --=====_003_next===== Content-Type: text/html ; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBjbGFzcz0iemNvbnRlbnRSb3ciPjxwIHN0eWxlPSJmb250LXNpemU6MjBweDtmb250LWZh bWlseTphcmlhbDsiPjxicj48L3A+PHAgc3R5bGU9ImZvbnQtc2l6ZToyMHB4O2ZvbnQtZmFtaWx5 OmFyaWFsOyI+SGkgRGhydXYsPGJyPjwvcD48cCBzdHlsZT0iZm9udC1zaXplOjIwcHg7Zm9udC1m YW1pbHk6YXJpYWw7Ij48YnI+PC9wPjxwIHN0eWxlPSJmb250LXNpemU6MjBweDtmb250LWZhbWls eTphcmlhbDsiPlRoYW5rcyBmb3IgeW91ciBxdWljayByZXBseSBhbmQgc3VnZ2VzdGlvbiE8L3A+ PHAgc3R5bGU9ImZvbnQtc2l6ZToyMHB4O2ZvbnQtZmFtaWx5OmFyaWFsOyI+VGhlIDxzcGFuIHN0 eWxlPSJsaW5lLWhlaWdodDogMjFweDsiPiZuYnNwO0xTUC1FWFRFTkRFRC1GTEFHJm5ic3A7VExW PC9zcGFuPiBpcyBub3QmbmJzcDs8c3BhbiBzdHlsZT0ibGluZS1oZWlnaHQ6IDIxcHg7Ij5tYW5k YXRvcnkgYW5kJm5ic3A7PC9zcGFuPkkgd2lsbCBtb2RpZnkgYW5kIG1vdmUgdGhlIGVycm9yIGhh bmRpbmcgdG8gdGhlIGRyYWZ0LXBlbmctcGNlLWVudHJvcHktbGFiZWwgd2hpY2ggbmVlZHMgdG8g dXNlIHRoZSBmbGFnLiAmbmJzcDtJIHdpbGwgdXBkYXRlIHRoZSBkcmFmdHMgYXMgeW91IHN1Z2dl c3QgYXMgc29vbiBhcyBwb3NzaWJsZSE8L3A+PHAgc3R5bGU9ImZvbnQtc2l6ZToyMHB4O2ZvbnQt ZmFtaWx5OmFyaWFsOyI+PGJyPjwvcD48cCBzdHlsZT0iZm9udC1zaXplOjIwcHg7Zm9udC1mYW1p bHk6YXJpYWw7Ij5UaGFua3MsPC9wPjxwIHN0eWxlPSJmb250LXNpemU6MjBweDtmb250LWZhbWls eTphcmlhbDsiPlF1YW48L3A+PHAgc3R5bGU9ImZvbnQtc2l6ZToyMHB4O2ZvbnQtZmFtaWx5OmFy aWFsOyI+PGJyPjwvcD48ZGl2PjxkaXYgY2xhc3M9InpoaXN0b3J5Um93IiBzdHlsZT0iZGlzcGxh eTpibG9jayI+PGRpdiBjbGFzcz0iemhpc3RvcnlEZXMiIHN0eWxlPSJ3aWR0aDogMTAwJTsgaGVp Z2h0OiAyOHB4OyBsaW5lLWhlaWdodDogMjhweDsgYmFja2dyb3VuZC1jb2xvcjogI0UwRTVFOTsg Y29sb3I6ICMxMzg4RkY7IHRleHQtYWxpZ246IGNlbnRlcjsiIGxhbmd1YWdlLWRhdGE9Ikhpc3Rv cnlPcmdUeHQiPuWOn+Wni+mCruS7tjwvZGl2PjxkaXYgaWQ9Inp3cml0ZUhpc3RvcnlDb250YWlu ZXIiPjxkaXYgY2xhc3M9ImNvbnRyb2wtZ3JvdXAgemhpc3RvcnlQYW5lbCI+PGRpdiBjbGFzcz0i emhpc3RvcnlIZWFkZXIiIHN0eWxlPSJwYWRkaW5nOiA4cHg7IGJhY2tncm91bmQtY29sb3I6ICNG NUY2Rjg7Ij48ZGl2PjxzdHJvbmcgbGFuZ3VhZ2UtZGF0YT0iSGlzdG9yeVNlbmRlclR4dCI+5Y+R 5Lu25Lq677yaPC9zdHJvbmc+PHNwYW4gY2xhc3M9InpyZWFkVXNlck5hbWUiPkRocnV2RGhvZHkg Jmx0O2RkQGRocnV2ZGhvZHkuY29tJmd0Ozwvc3Bhbj48L2Rpdj48ZGl2PjxzdHJvbmcgbGFuZ3Vh Z2UtZGF0YT0iSGlzdG9yeVRPVHh0Ij7mlLbku7bkurrvvJo8L3N0cm9uZz48c3BhbiBjbGFzcz0i enJlYWRVc2VyTmFtZSIgc3R5bGU9ImRpc3BsYXk6IGlubGluZTsiPueGiuaziTAwMDkxMDY1Ozwv c3Bhbj48L2Rpdj48ZGl2PjxzdHJvbmcgbGFuZ3VhZ2UtZGF0YT0iSGlzdG9yeUNDVHh0Ij7mioTp gIHkurrvvJo8L3N0cm9uZz48c3BhbiBjbGFzcz0ienJlYWRVc2VyTmFtZSIgc3R5bGU9ImRpc3Bs YXk6IGlubGluZTsiPkxvYSBBbmRlcnNzb24gJmx0O2xvYUBwaS5udSZndDs7PC9zcGFuPjxzcGFu IGNsYXNzPSJ6cmVhZFVzZXJOYW1lIiBzdHlsZT0iZGlzcGxheTogaW5saW5lOyI+ZHJhZnQteGlv bmctcGNlLWxzcC1mbGFnQGlldGYub3JnICZsdDtkcmFmdC14aW9uZy1wY2UtbHNwLWZsYWdAaWV0 Zi5vcmcmZ3Q7Ozwvc3Bhbj48c3BhbiBjbGFzcz0ienJlYWRVc2VyTmFtZSIgc3R5bGU9ImRpc3Bs YXk6IGlubGluZTsiPnBjZS1jaGFpcnMgJmx0O3BjZS1jaGFpcnNAaWV0Zi5vcmcmZ3Q7Ozwvc3Bh bj48c3BhbiBjbGFzcz0ienJlYWRVc2VyTmFtZSIgc3R5bGU9ImRpc3BsYXk6IGlubGluZTsiPnBj ZUBpZXRmLm9yZyAmbHQ7cGNlQGlldGYub3JnJmd0Ozs8L3NwYW4+PC9kaXY+PGRpdj48c3Ryb25n IGxhbmd1YWdlLWRhdGE9Ikhpc3RvcnlEYXRlVHh0Ij7ml6Ug5pyfIO+8mjwvc3Ryb25nPjxzcGFu IGNsYXNzPSIiPjIwMjDlubQwN+aciDMw5pelIDEzOjQ3PC9zcGFuPjwvZGl2PjxkaXY+PHN0cm9u ZyBsYW5ndWFnZS1kYXRhPSJIaXN0b3J5U3ViamVjdFR4dCI+5Li7IOmimCDvvJo8L3N0cm9uZz48 c3BhbiBjbGFzcz0ienJlYWRUaXRsZSI+PHN0cm9uZz5SZTogY3Vyc29yeSByZXZpZXcgb2YgZHJh ZnQteGlvbmctcGNlLWxzcC1mbGFnPC9zdHJvbmc+PC9zcGFuPjwvZGl2PjwvZGl2PjxkaXYgY2xh c3M9InpoaXN0b3J5Q29udGVudCI+PGRpdj5IaSZuYnNwO1F1YW4sPGJyPjxicj5PbiZuYnNwO1Ro dSwmbmJzcDtKdWwmbmJzcDszMCwmbmJzcDsyMDIwJm5ic3A7YXQmbmJzcDs4OjAwJm5ic3A7QU0m bmJzcDsmbHQ7eGlvbmcucXVhbkB6dGUuY29tLmNuJmd0OyZuYnNwO3dyb3RlOjxicj4mZ3Q7PGJy PiZndDs8YnI+Jmd0OyZuYnNwO0hpJm5ic3A7RGhydXYmbmJzcDthbmQmbmJzcDtMb2EsPGJyPiZn dDs8YnI+Jmd0Ozxicj4mZ3Q7Jm5ic3A7VGhhbmtzJm5ic3A7Zm9yJm5ic3A7eW91ciZuYnNwO3Jl dmlldyZuYnNwO2FuZCZuYnNwO2RldGFpbGVkJm5ic3A7ZGlzY3Vzc2lvbiE8YnI+Jmd0Ozxicj4m Z3Q7Jm5ic3A7Rm9yJm5ic3A7dGhlJm5ic3A7SUFOQSZuYnNwO3RleHQsJm5ic3A7SSZuYnNwO3dp bGwmbmJzcDt1cGRhdGUmbmJzcDt0aGF0Jm5ic3A7YXMmbmJzcDt5b3UmbmJzcDtzdWdnZXN0Ljxi cj4mZ3Q7PGJyPiZndDs8YnI+Jmd0OyZuYnNwO0luJm5ic3A7bXkmbmJzcDt2aWV3LCZuYnNwO3dl Jm5ic3A7bmVlZCZuYnNwO3RvJm5ic3A7Y2xhcmlmeSZuYnNwO3RoZSZuYnNwO0xTUC1FWFRFTkRF RC1GTEFHJm5ic3A7VExWJm5ic3A7aXMmbmJzcDttYW5kYXRvcnkmbmJzcDtvciZuYnNwO25vdCZu YnNwO2ZpcnN0bHkuJm5ic3A7VGhlbiZuYnNwO2NvbnNpZGVyJm5ic3A7dGhlJm5ic3A7ZXJyb3Im bmJzcDtoYW5kbGluZy48YnI+Jmd0Ozxicj4mZ3Q7Jm5ic3A7VGhlcmUmbmJzcDthcmUmbmJzcDt0 d28mbmJzcDtjYXNlcy48YnI+Jmd0Ozxicj4mZ3Q7Jm5ic3A7Rmlyc3QmbmJzcDtjYXNlLCZuYnNw O2ZvciZuYnNwO3RoZSZuYnNwO2ltcGxlbWVudGF0aW9ucyZuYnNwO3doaWNoJm5ic3A7anVzdCZu YnNwO3VzZSZuYnNwO3RoZSZuYnNwO0ZsYWcmbmJzcDtmaWVsZCZuYnNwO29mJm5ic3A7Jm5ic3A7 TFNQJm5ic3A7T2JqZWN0Jm5ic3A7ZnJvbSZuYnNwOyZuYnNwO2JpdCZuYnNwOzEmbmJzcDt0byZu YnNwO2JpdCZuYnNwOzExLCZuYnNwO2l0Jm5ic3A7aGFzJm5ic3A7bm8mbmJzcDtuZWVkJm5ic3A7 dG8mbmJzcDtjYXJyeSZuYnNwO0xTUC1FWFRFTkRFRC1GTEFHJm5ic3A7VExWJm5ic3A7YW5kJm5i c3A7bm90Jm5ic3A7bWFuZGF0b3J5Ljxicj4mZ3Q7PGJyPiZndDsmbmJzcDtTZWNvbmQmbmJzcDtj YXNlLCZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO2ltcGxlbWVudGF0aW9ucyZuYnNwO3doaWNoJm5i c3A7d2lsbCZuYnNwO3VzZSZuYnNwO3RoZSZuYnNwO2ZsYWcmbmJzcDtvZiZuYnNwO0xTUC1FWFRF TkRFRC1GTEFHJm5ic3A7VExWLCZuYnNwO0l0Jm5ic3A7aXMmbmJzcDttYW5kYXRvcnkuJm5ic3A7 Jm5ic3A7V2hlbiZuYnNwO0xTUC1FWFRFTkRFRC1GTEFHJm5ic3A7VExWJm5ic3A7aXMmbmJzcDtt aXNzaW5nLCZuYnNwO3RoZSZuYnNwO2Vycm9yJm5ic3A7aGFuZGxpbmcmbmJzcDtzaG91bGQmbmJz cDtiZSZuYnNwO3Rha2VuJm5ic3A7aW50byZuYnNwO2NvbnNpZGVyYXRpb24uPGJyPiZndDs8YnI+ PGJyPiZndDtGcm9tJm5ic3A7dGhlJm5ic3A7cG9pbnQmbmJzcDtvZiZuYnNwO3ZpZXcmbmJzcDtv ZiZuYnNwO3RoaXMmbmJzcDtJLUQmbmJzcDt0aGVyZSZuYnNwO2FyZSZuYnNwO25vJm5ic3A7Zmxh Z3MmbmJzcDtkZWZpbmVkJm5ic3A7aW4mbmJzcDt0aGU8YnI+TFNQLUVYVEVOREVELUZMQUcmbmJz cDtUTFYmbmJzcDt5ZXQuPGJyPjxicj5BbHNvLCZuYnNwO0xvYSZuYnNwO3JpZ2h0bHkmbmJzcDtw b2ludGVkJm5ic3A7b3V0Jm5ic3A7dGhhdCZuYnNwO2FueSZuYnNwO3RleHQmbmJzcDt3b3VsZCZu YnNwO2JlJm5ic3A7aW5jb21wbGV0ZSZuYnNwO2FzJm5ic3A7YW48YnI+aW1wbGVtZW50YXRpb24m bmJzcDt0aGF0Jm5ic3A7anVzdCZuYnNwO3JlY2VpdmVzJm5ic3A7YW4mbmJzcDtMU1AmbmJzcDtv YmplY3QmbmJzcDt3aXRob3V0Jm5ic3A7dGhlPGJyPkxTUC1FWFRFTkRFRC1GTEFHJm5ic3A7VExW Jm5ic3A7d291bGQmbmJzcDtub3QmbmJzcDtrbm93Jm5ic3A7aWYmbmJzcDtpdCZuYnNwO2lzJm5i c3A7dGhlJm5ic3A7Zmlyc3QmbmJzcDsidmFsaWQiJm5ic3A7b3ImbmJzcDt0aGU8YnI+c2Vjb25k Jm5ic3A7ImVycm9yIiZuYnNwO2Nhc2UmbmJzcDtpbiZuYnNwO3lvdXImbmJzcDt0ZXh0Jm5ic3A7 YWJvdmUmbmJzcDtqdXN0Jm5ic3A7YnkmbmJzcDt0aGUmbmJzcDtmYWN0Jm5ic3A7dGhhdCZuYnNw O3RoZSZuYnNwO1RMVjxicj5pcyZuYnNwO21pc3NpbmcuJm5ic3A7VGhlJm5ic3A7ZXJyb3ImbmJz cDt3b3VsZCZuYnNwO2JlJm5ic3A7bm90aWNlZCZuYnNwO2luJm5ic3A7Y29uanVuY3Rpb24mbmJz cDt3aXRoJm5ic3A7c29tZSZuYnNwO290aGVyPGJyPmVuY29kaW5nJm5ic3A7cmVxdWlyZWQmbmJz cDtieSZuYnNwO3RoZSZuYnNwO2V4dGVuc2lvbi48YnI+PGJyPlNvJm5ic3A7bXkmbmJzcDtzdWdn ZXN0aW9uJm5ic3A7d291bGQmbmJzcDtiZSZuYnNwO3RvJm5ic3A7bW92ZSZuYnNwO3RoZSZuYnNw O2Vycm9yJm5ic3A7aGFuZGxpbmcmbmJzcDt0byZuYnNwO3RoZSZuYnNwO2ZpcnN0PGJyPmRvY3Vt ZW50Jm5ic3A7dGhhdCZuYnNwO2RlZmluZXMmbmJzcDt0aGUmbmJzcDtmbGFnJm5ic3A7aW4mbmJz cDtMU1AtRVhURU5ERUQtRkxBRyZuYnNwO1RMVi4mbmJzcDtXZSZuYnNwO2hhdmU8YnI+ZG9jdW1l bnRzJm5ic3A7dGhhdCZuYnNwO25lZWQmbmJzcDt0byZuYnNwO3VzZSZuYnNwO2l0Jm5ic3A7cmln aHQmbmJzcDthd2F5Jm5ic3A7c28mbmJzcDt0aGlzJm5ic3A7c2hvdWxkJm5ic3A7bm90Jm5ic3A7 YmUmbmJzcDthPGJyPnByb2JsZW0sJm5ic3A7anVzdCZuYnNwO3NvbWUmbmJzcDtjb29yZGluYXRp b24uPGJyPjxicj5UaGFua3MhPGJyPkRocnV2PGJyPjxicj4mZ3Q7PGJyPiZndDsmbmJzcDtJJm5i c3A7c3VnZ2VzdCZuYnNwO3RvJm5ic3A7bWFrZSZuYnNwO2NsYXJpZmljYXRpb24mbmJzcDtpbiZu YnNwO3RoZSZuYnNwO2RyYWZ0Jm5ic3A7YWJvdXQmbmJzcDt0aGUmbmJzcDtpbXBsZW1lbnRhdGlv bnM8YnI+Jmd0Ozxicj4mZ3Q7Jm5ic3A7b3ImbmJzcDt1c2UmbmJzcDt0aGUmbmJzcDtiaXQmbmJz cDswJm5ic3A7b2YmbmJzcDtGbGFnJm5ic3A7ZmllbGQmbmJzcDtpbiZuYnNwO0xTUCZuYnNwO09i amVjdCZuYnNwO3RvJm5ic3A7aW5kaWNhdGUmbmJzcDt0aGUmbmJzcDtleGlzdGluZyZuYnNwO29m Jm5ic3A7dGhlJm5ic3A7TFNQLUVYVEVOREVELUZMQUcmbmJzcDtUTFY/PGJyPiZndDs8YnI+Jmd0 OyZuYnNwO0NvdWxkJm5ic3A7eW91Jm5ic3A7dGVsbCZuYnNwO21lJm5ic3A7d2hhdCZuYnNwO2lz Jm5ic3A7eW91ciZuYnNwO3N1Z2dlc3Rpb24/PGJyPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7Jm5ic3A7 VGhhbmtzLDxicj4mZ3Q7PGJyPiZndDsmbmJzcDtRdWFuPGJyPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7 PGJyPiZndDs8YnI+Jmd0OyZuYnNwO+WOn+Wni+mCruS7tjxicj4mZ3Q7Jm5ic3A75Y+R5Lu25Lq6 77yaRGhydXZEaG9keSZuYnNwOyZsdDtkZEBkaHJ1dmRob2R5LmNvbSZndDs8YnI+Jmd0OyZuYnNw O+aUtuS7tuS6uu+8mkxvYSZuYnNwO0FuZGVyc3NvbiZuYnNwOyZsdDtsb2FAcGkubnUmZ3Q7Ozxi cj4mZ3Q7Jm5ic3A75oqE6YCB5Lq677yaZHJhZnQteGlvbmctcGNlLWxzcC1mbGFnQGlldGYub3Jn Jm5ic3A7Jmx0O2RyYWZ0LXhpb25nLXBjZS1sc3AtZmxhZ0BpZXRmLm9yZyZndDs7cGNlLWNoYWly c0BpZXRmLm9yZyZuYnNwOyZsdDtwY2UtY2hhaXJzQGlldGYub3JnJmd0OztwY2VAaWV0Zi5vcmcm bmJzcDsmbHQ7cGNlQGlldGYub3JnJmd0Ozs8YnI+Jmd0OyZuYnNwO+aXpSZuYnNwO+acnyZuYnNw O++8mjIwMjDlubQwN+aciDI55pelJm5ic3A7MTk6MTU8YnI+Jmd0OyZuYnNwO+S4uyZuYnNwO+mi mCZuYnNwO++8mlJlOiZuYnNwO2N1cnNvcnkmbmJzcDtyZXZpZXcmbmJzcDtvZiZuYnNwO2RyYWZ0 LXhpb25nLXBjZS1sc3AtZmxhZzxicj4mZ3Q7Jm5ic3A7SGkmbmJzcDtMb2EsPGJyPiZndDs8YnI+ Jmd0OyZuYnNwO09uJm5ic3A7V2VkLCZuYnNwO0p1bCZuYnNwOzI5LCZuYnNwOzIwMjAmbmJzcDth dCZuYnNwOzQ6MTMmbmJzcDtQTSZuYnNwO0xvYSZuYnNwO0FuZGVyc3NvbiZuYnNwOyZsdDtsb2FA cGkubnUmZ3Q7Jm5ic3A7d3JvdGU6PGJyPiZndDsmbmJzcDsmZ3Q7PGJyPiZndDsmbmJzcDsmZ3Q7 Jm5ic3A7RGhydXYsPGJyPiZndDsmbmJzcDsmZ3Q7PGJyPiZndDsmbmJzcDsmZ3Q7Jm5ic3A7SW5s aW5lJm5ic3A7cGxlYXNlLjxicj4mZ3Q7Jm5ic3A7Jmd0Ozxicj4mZ3Q7Jm5ic3A7Jmd0OyZuYnNw O09uJm5ic3A7MjkvMDcvMjAyMCZuYnNwOzE3OjAxLCZuYnNwO0RocnV2Jm5ic3A7RGhvZHkmbmJz cDt3cm90ZTo8YnI+Jmd0OyZuYnNwOyZndDsmbmJzcDsmZ3Q7Jm5ic3A7SGkmbmJzcDtMb2EsPGJy PiZndDsmbmJzcDsmZ3Q7Jm5ic3A7Jmd0Ozxicj4mZ3Q7Jm5ic3A7Jmd0OyZuYnNwOyZndDsmZ3Q7 Jm5ic3A7Q29tbWVudDo8YnI+Jmd0OyZuYnNwOyZndDsmbmJzcDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5i c3A7Jmd0OyZuYnNwOyZndDsmZ3Q7Jm5ic3A7NS4yLiZuYnNwOyZuYnNwO1BDRVAtRXJyb3ImbmJz cDtPYmplY3Q8YnI+Jmd0OyZuYnNwOyZndDsmbmJzcDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7Jmd0 OyZuYnNwOyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7SUFOQSZu YnNwO2lzJm5ic3A7cmVxdWVzdGVkJm5ic3A7dG8mbmJzcDtyZWdpc3RlciZuYnNwO3RoZSZuYnNw O2ZvbGxvd2luZyZuYnNwO2Vycm9yJm5ic3A7dHlwZXMmbmJzcDthbmQmbmJzcDtlcnJvcjxicj4m Z3Q7Jm5ic3A7Jmd0OyZuYnNwOyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7dmFsdWVzJm5ic3A7d2l0aGluJm5ic3A7dGhlJm5ic3A7IlBDRVAtRVJST1ImbmJzcDtP YmplY3QmbmJzcDtFcnJvciZuYnNwO1R5cGVzJm5ic3A7YW5kJm5ic3A7VmFsdWVzIjxicj4mZ3Q7 Jm5ic3A7Jmd0OyZuYnNwOyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7c3VicmVnaXN0cnkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwOyJQYXRoJm5ic3A7Q29tcHV0YXRp b24mbmJzcDtFbGVtZW50Jm5ic3A7UHJvdG9jb2wmbmJzcDsoUENFUCkmbmJzcDtOdW1iZXJzIjxi cj4mZ3Q7Jm5ic3A7Jmd0OyZuYnNwOyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7cmVnaXN0cnk6PGJyPiZndDsmbmJzcDsmZ3Q7Jm5ic3A7Jmd0OyZndDs8YnI+Jmd0 OyZuYnNwOyZndDsmbmJzcDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOystLS0tLS0tLS0t LS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKzxicj4mZ3Q7Jm5ic3A7 Jmd0OyZuYnNwOyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNwO0Vycm9y LVR5cGUmbmJzcDsmbmJzcDt8Jm5ic3A7Jm5ic3A7TWVhbmluZyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3w8YnI+Jmd0OyZuYnNwOyZndDsmbmJz cDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOystLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKzxicj4mZ3Q7Jm5ic3A7Jmd0OyZuYnNwOyZndDsm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNwOzYmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8Jm5ic3A7Jm5i c3A7TWFuZGF0b3J5Jm5ic3A7T2JqZWN0Jm5ic3A7bWlzc2luZyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3w8YnI+Jmd0OyZu YnNwOyZndDsmbmJzcDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDt8Jm5ic3A7Jm5ic3A7RXJyb3ItdmFsdWUmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDt8PGJyPiZndDsmbmJzcDsmZ3Q7Jm5ic3A7Jmd0OyZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDt8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCZuYnNwO1RCRDI6Jm5ic3A7TFNQ LUVYVEVOREVELUZMQUcmbmJzcDtUTFYmbmJzcDttaXNzaW5nJm5ic3A7fDxicj4mZ3Q7Jm5ic3A7 Jmd0OyZuYnNwOyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Ky0tLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rPGJyPiZndDsmbmJzcDsmZ3Q7Jm5i c3A7Jmd0OyZndDs8YnI+Jmd0OyZuYnNwOyZndDsmbmJzcDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1RhYmxlJm5ic3A7Mjxicj4mZ3Q7 Jm5ic3A7Jmd0OyZuYnNwOyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsmZ3Q7Jm5ic3A7Jmd0OyZndDsm bmJzcDtCb3RoJm5ic3A7dGhlJm5ic3A7UlRHJm5ic3A7RElSJm5ic3A7cnVsZXMmbmJzcDthbmQm bmJzcDtJQU5BJm5ic3A7cnVsZXMmbmJzcDtzdHJvbmdseSZuYnNwO2FkdmljZSZuYnNwO2FnYWlu c3QmbmJzcDtwdXR0aW5nPGJyPiZndDsmbmJzcDsmZ3Q7Jm5ic3A7Jmd0OyZndDsmbmJzcDtmaXhl ZCZuYnNwO251bWVyaWMmbmJzcDsmbmJzcDt2YWx1ZXMmbmJzcDtpbnRvJm5ic3A7YWxsb2NhdGlv biZuYnNwO2Zyb20mbmJzcDtleGlzdGluZyZuYnNwO3JlZ2lzdHJpZXMuJm5ic3A7VGhlPGJyPiZn dDsmbmJzcDsmZ3Q7Jm5ic3A7Jmd0OyZndDsmbmJzcDtyZWFzb24mbmJzcDtpcyZuYnNwO29idmlv dXMsJm5ic3A7aW4mbmJzcDt0aGUmbmJzcDt0aW1lJm5ic3A7ZnJvbSZuYnNwO3lvdSZuYnNwO3B1 dCZuYnNwO3RoZSZuYnNwO3ZhbHVlJm5ic3A7aW4mbmJzcDt5b3VyJm5ic3A7ZG9jdW1lbnQ8YnI+ Jmd0OyZuYnNwOyZndDsmbmJzcDsmZ3Q7Jmd0OyZuYnNwO3VudGlsJm5ic3A7aWV0Jm5ic3A7aXMm bmJzcDtyZWFkeSZuYnNwO2ZvciZuYnNwO0lFU0cmbmJzcDtyZXZpZXcmbmJzcDsod2hpY2gmbmJz cDtpbmNsdWRlcyZuYnNwO0lBTkEmbmJzcDtyZXZpZXcpJm5ic3A7c29tZW9uZTxicj4mZ3Q7Jm5i c3A7Jmd0OyZuYnNwOyZndDsmZ3Q7Jm5ic3A7ZWxzZSZuYnNwO21pZ2h0Jm5ic3A7aGF2ZSZuYnNw O2JlZW4mbmJzcDthc3NpZ25lZCZuYnNwO3RodCZuYnNwO3ZhbHVlLiZuYnNwO1RoaXMmbmJzcDto YXMmbmJzcDtoYXBwZW5lZCZuYnNwO2FuZCZuYnNwO2hhdmU8YnI+Jmd0OyZuYnNwOyZndDsmbmJz cDsmZ3Q7Jmd0OyZuYnNwO2NhdXNlZCZuYnNwO3NlcmlvdXMmbmJzcDtwcm9ibGVtcy48YnI+Jmd0 OyZuYnNwOyZndDsmbmJzcDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7Jmd0OyZuYnNwOyZndDsmZ3Q7 Jm5ic3A7NiZuYnNwO2luJm5ic3A7dGFibGUmbmJzcDsyJm5ic3A7aG91bGQmbmJzcDtiZSZuYnNw O3JlcGxhY2VkJm5ic3A7d2l0aCZuYnNwO1RCQSZuYnNwOyh0byZuYnNwO2JlJm5ic3A7YXNzaWdu ZWQpLjxicj4mZ3Q7Jm5ic3A7Jmd0OyZuYnNwOyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsmZ3Q7Jm5i c3A7Jmd0OyZndDsmbmJzcDtOb3RlOiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7cmVhbGx5Jm5ic3A7 d2FudCZuYnNwO3RoZSZuYnNwO3ZhbHVlJm5ic3A7NiwmbmJzcDt3ZSZuYnNwO3Nob3VsZCZuYnNw O2dvJm5ic3A7Zm9yJm5ic3A7YW4mbmJzcDtlYXJseTxicj4mZ3Q7Jm5ic3A7Jmd0OyZuYnNwOyZn dDsmZ3Q7Jm5ic3A7YWxsb2NhdGlvbiZuYnNwO2FzJm5ic3A7c29vbiZuYnNwO2FzJm5ic3A7d2Um bmJzcDtoYXZlJm5ic3A7dGhlJm5ic3A7d2cmbmJzcDtkb2N1bWVudC48YnI+Jmd0OyZuYnNwOyZn dDsmbmJzcDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7Jmd0OyZuYnNwOyZndDs8YnI+Jmd0OyZuYnNw OyZndDsmbmJzcDsmZ3Q7Jm5ic3A7W0RocnV2XSZuYnNwO1RoZSZuYnNwO3ZhbHVlJm5ic3A7NiZu YnNwO2lzJm5ic3A7Zm9yJm5ic3A7RXJyb3ItVHlwZSZuYnNwO2FscmVhZHkmbmJzcDthbGxvY2F0 ZWQmbmJzcDtieSZuYnNwO1JGQyZuYnNwOzU0NDAuPGJyPiZndDsmbmJzcDsmZ3Q7Jm5ic3A7Jmd0 OyZuYnNwO1RoaXMmbmJzcDtJLUQmbmJzcDtpcyZuYnNwO2Fza2luZyZuYnNwO2ZvciZuYnNwO2Em bmJzcDtuZXcmbmJzcDtFcnJvci1WYWx1ZSZuYnNwO3doaWNoJm5ic3A7aXMmbmJzcDsmbmJzcDtU QkQyLiZuYnNwO0EmbmJzcDtyZWZlcmVuY2U8YnI+Jmd0OyZuYnNwOyZndDsmbmJzcDsmZ3Q7Jm5i c3A7Y29sdW1uJm5ic3A7aW4mbmJzcDt0aGUmbmJzcDtJQU5BJm5ic3A7dGFibGUmbmJzcDt3b3Vs ZCZuYnNwO2hhdmUmbmJzcDtoZWxwZWQmbmJzcDtoZXJlLjxicj4mZ3Q7Jm5ic3A7Jmd0Ozxicj4m Z3Q7Jm5ic3A7Jmd0OyZuYnNwO2htbW1tJm5ic3A7LSZuYnNwO29rZXksJm5ic3A7YnV0Jm5ic3A7 bm8sJm5ic3A7d2UmbmJzcDthcmUmbmJzcDthc2tpbmcmbmJzcDtJQU5BJm5ic3A7dG8mbmJzcDty ZWdpc3RlciZuYnNwO2EmbmJzcDtuZXcmbmJzcDtlcnJvci12YWx1ZSw8YnI+Jmd0OyZuYnNwOyZn dDsmbmJzcDtidXQmbmJzcDtub3QmbmJzcDthJm5ic3A7bmV3Jm5ic3A7ZXJyb3ImbmJzcDt0eXBl LiZuYnNwO1RoZSZuYnNwO3RleHQmbmJzcDtzYXlzOjxicj4mZ3Q7Jm5ic3A7Jmd0Ozxicj4mZ3Q7 Jm5ic3A7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyJJQU5BJm5ic3A7aXMmbmJzcDtyZXF1 ZXN0ZWQmbmJzcDt0byZuYnNwO3JlZ2lzdGVyJm5ic3A7dGhlJm5ic3A7Zm9sbG93aW5nJm5ic3A7 ZXJyb3ImbmJzcDt0eXBlcyZuYnNwO2FuZCZuYnNwO2Vycm9yPGJyPiZndDsmbmJzcDsmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7dmFsdWVzJm5ic3A7Li4uIjxicj4mZ3Q7 Jm5ic3A7Jmd0Ozxicj4mZ3Q7PGJyPiZndDsmbmJzcDtUaGlzJm5ic3A7dGV4dCZuYnNwO2lzJm5i c3A7aW5jb3JyZWN0Jm5ic3A7dGhlbiZuYnNwO2FuZCZuYnNwO3Nob3VsZCZuYnNwO2JlJm5ic3A7 Zml4ZWQuPGJyPiZndDs8YnI+Jmd0OyZuYnNwOyZndDsmbmJzcDtCdXQmbmJzcDt0aGVuJm5ic3A7 dGhlJm5ic3A7dGFibGUmbmJzcDtpcyZuYnNwO3ZlcnkmbmJzcDt1bmNsZWFyLCZuYnNwO2F0Jm5i c3A7YSZuYnNwO21pbmltdW0mbmJzcDtpdCZuYnNwO3Nob3VsZCZuYnNwO2xvb2s8YnI+Jmd0OyZu YnNwOyZndDsmbmJzcDtzb21ldGhpbmcmbmJzcDtsaWtlJm5ic3A7dGhpczo8YnI+Jmd0OyZuYnNw OyZndDs8YnI+Jmd0OyZuYnNwOyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsrLS0tLS0tLS0t LS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0rPGJyPiZndDsmbmJzcDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNw O0Vycm9yLVR5cGUmbmJzcDt8Jm5ic3A7TWVhbmluZyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wmbmJzcDtFcnJvci12YWx1ZSZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwO3w8YnI+Jmd0OyZuYnNwOyZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsrLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0rPGJyPiZndDsmbmJzcDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7fCZuYnNwOyZuYnNwOzYmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDt8Jm5ic3A7TWFuZGF0b3J5Jm5ic3A7T2JqZWN0Jm5ic3A7bWlz c2luZyZuYnNwOyZuYnNwOyZuYnNwO3wmbmJzcDswOiZuYnNwO1VuYXNzaWduZWQmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8 PGJyPiZndDsmbmJzcDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwO3wmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDt8Jm5ic3A7MS0xNSZuYnNwO0Fzc2lnbmVkJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fDxicj4mZ3Q7Jm5ic3A7Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCZuYnNwO1RCRDI6 Jm5ic3A7TFNQLUVYVEVOREVELUZMQUcmbmJzcDt8PGJyPiZndDsmbmJzcDsmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7VExWJm5ic3A7bWlzc2luZyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO3w8YnI+Jmd0OyZuYnNwOyZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsrLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rPGJyPiZndDsmbmJzcDsmZ3Q7PGJyPiZndDsmbmJzcDsmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7VGFibGUmbmJzcDsyPGJyPiZndDsmbmJzcDsmZ3Q7PGJyPiZndDsmbmJzcDtZZXMuJm5i c3A7SSZuYnNwO3N1Z2dlc3QmbmJzcDtRdWFuJm5ic3A7dG8mbmJzcDtsb29rJm5ic3A7YXQmbmJz cDstPGJyPiZndDsmbmJzcDtodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9yZmMvcmZjODgwMC5o dG1sI3NlY3Rpb24tNy41Jm5ic3A7YXMmbmJzcDthJm5ic3A7Z29vZDxicj4mZ3Q7Jm5ic3A7cmVm ZXJlbmNlJm5ic3A7ZnJvbSZuYnNwO2EmbmJzcDtyZWNlbnQmbmJzcDtwdWJsaXNoZWQmbmJzcDtS RkMuPGJyPiZndDs8YnI+Jmd0OyZuYnNwOyZndDs8YnI+Jmd0OyZuYnNwOyZndDsmbmJzcDsmZ3Q7 PGJyPiZndDsmbmJzcDsmZ3Q7Jm5ic3A7Jmd0OyZndDsmbmJzcDtRdWVzdGlvbjo8YnI+Jmd0OyZu YnNwOyZndDsmbmJzcDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7Jmd0OyZuYnNwOyZndDsmZ3Q7Jm5i c3A7SW4mbmJzcDtzZWN0aW9uJm5ic3A7NCZuYnNwO3lvdSZuYnNwO3NheTo8YnI+Jmd0OyZuYnNw OyZndDsmbmJzcDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7Jmd0OyZuYnNwOyZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhlJm5ic3A7TFNQLUVYVEVOREVELUZMQUcm bmJzcDtUTFYmbmJzcDtNVVNUJm5ic3A7YmUmbmJzcDtkZWZpbmVkJm5ic3A7YXMmbmJzcDttYW5k YXRvcnkmbmJzcDt3aGVuJm5ic3A7YSZuYnNwO3JvdXRlcjxicj4mZ3Q7Jm5ic3A7Jmd0OyZuYnNw OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7c3VwcG9ydGluZyZu YnNwO3RoZSZuYnNwO0xTUCZuYnNwO09iamVjdCZuYnNwO2FuZCZuYnNwO25lZWRzJm5ic3A7dG8m bmJzcDt1c2UmbmJzcDt0aGUmbmJzcDtleHRlbmRlZCZuYnNwO2ZsYWcmbmJzcDtmaWVsZC48YnI+ Jmd0OyZuYnNwOyZndDsmbmJzcDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7Jmd0OyZuYnNwOyZndDsm Z3Q7Jm5ic3A7SSZuYnNwO2Rvbid0Jm5ic3A7cmVhbGx5Jm5ic3A7cGFyc2U7Jm5ic3A7YXJlJm5i c3A7eW91Jm5ic3A7c2F5aW5nJm5ic3A7dGhhdCZuYnNwO2lmJm5ic3A7aXQmbmJzcDtpcyZuYnNw O3ByZXNlbnQmbmJzcDtpdCZuYnNwO3Nob3VsZCZuYnNwO2JlPGJyPiZndDsmbmJzcDsmZ3Q7Jm5i c3A7Jmd0OyZndDsmbmJzcDt0cmVhdGVkJm5ic3A7YXMmbmJzcDttYW5kYXRvcnk/PGJyPiZndDsm bmJzcDsmZ3Q7Jm5ic3A7Jmd0OyZndDs8YnI+Jmd0OyZuYnNwOyZndDsmbmJzcDsmZ3Q7Jmd0OyZu YnNwO0lmJm5ic3A7dGhhdCZuYnNwO2lzJm5ic3A7d2hhdCZuYnNwO3lvdSZuYnNwO2FyZSZuYnNw O3NheWluZywmbmJzcDt3aGF0Jm5ic3A7ZG9lcyZuYnNwO2l0Jm5ic3A7Y2hhbmdlPzxicj4mZ3Q7 Jm5ic3A7Jmd0OyZuYnNwOyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsmZ3Q7Jm5ic3A7Jmd0Ozxicj4m Z3Q7Jm5ic3A7Jmd0OyZuYnNwOyZndDsmbmJzcDtbRGhydXZdOiZuYnNwO0kmbmJzcDtyZWFkJm5i c3A7aXQmbmJzcDthcyZuYnNwO2EmbmJzcDtyZXF1aXJlbWVudCZuYnNwO2ZvciZuYnNwO2EmbmJz cDtmdXR1cmUmbmJzcDtleHRlbnNpb24mbmJzcDt0aGF0Jm5ic3A7d291bGQ8YnI+Jmd0OyZuYnNw OyZndDsmbmJzcDsmZ3Q7Jm5ic3A7ZGVmaW5lJm5ic3A7YSZuYnNwO2ZsYWcmbmJzcDtpbiZuYnNw O3RoZSZuYnNwO0xTUC1FWFRFTkRFRC1GTEFHJm5ic3A7VExWLjxicj4mZ3Q7Jm5ic3A7Jmd0OyZu YnNwOyZndDs8YnI+Jmd0OyZuYnNwOyZndDsmbmJzcDsmZ3Q7Jm5ic3A7SWYmbmJzcDt0aGF0Jm5i c3A7aXMmbmJzcDt0cnVlLCZuYnNwO0kmbmJzcDt3b3VsZCZuYnNwO3N1Z2dlc3QmbmJzcDtub3Qm bmJzcDt1c2luZyZuYnNwO25vcm1hdGl2ZSZuYnNwO01VU1QuJm5ic3A7SG93Jm5ic3A7YWJvdXQm bmJzcDstPGJyPiZndDsmbmJzcDsmZ3Q7Jm5ic3A7Jmd0Ozxicj4mZ3Q7Jm5ic3A7Jmd0OyZuYnNw OyZndDsmbmJzcDtBJm5ic3A7ZnV0dXJlJm5ic3A7ZXh0ZW5zaW9uJm5ic3A7dGhhdCZuYnNwO2Rl ZmluZXMmbmJzcDthJm5ic3A7ZmxhZyZuYnNwO2luJm5ic3A7dGhlJm5ic3A7TFNQLUVYVEVOREVE LUZMQUcmbmJzcDtUTFY8YnI+Jmd0OyZuYnNwOyZndDsmbmJzcDsmZ3Q7Jm5ic3A7Y291bGQmbmJz cDttYXJrJm5ic3A7dGhpcyZuYnNwO1RMViZuYnNwO2FzJm5ic3A7bWFuZGF0b3J5Jm5ic3A7dG8m bmJzcDtiZSZuYnNwO2NhcnJpZWQmbmJzcDt0aGUmbmJzcDtMU1AmbmJzcDtPYmplY3QuPGJyPiZn dDsmbmJzcDsmZ3Q7PGJyPiZndDsmbmJzcDsmZ3Q7Jm5ic3A7SSZuYnNwO2hhdmUmbmJzcDtiZWVu Jm5ic3A7cmVhZGluZyZuYnNwO2EmbmJzcDtiaXQmbmJzcDttb3JlLCZuYnNwO2J1dCZuYnNwO3Ro aXMmbmJzcDtpcyZuYnNwO3N0aWxsJm5ic3A7dW5jbGVhciZuYnNwO3RvJm5ic3A7bWUsJm5ic3A7 aWYmbmJzcDtJPGJyPiZndDsmbmJzcDsmZ3Q7Jm5ic3A7dW5kZXJzdGFuZCZuYnNwO2l0Jm5ic3A7 d2lsbCZuYnNwO3N0aWxsJm5ic3A7YmUmbmJzcDt2YWxpZCZuYnNwO3RvJm5ic3A7c2VuZCZuYnNw O3dpdGhvdXQmbmJzcDt0aGUmbmJzcDtleHRlbmRlZCZuYnNwO1RMVjxicj4mZ3Q7Jm5ic3A7Jmd0 OyZuYnNwOyhpZiZuYnNwO3lvdSZuYnNwO2Rvbid0Jm5ic3A7bmVlZCZuYnNwO3RoZSZuYnNwO2Zs YWdzKS48YnI+Jmd0Ozxicj4mZ3Q7Jm5ic3A7WWVzISZuYnNwO01heWJlJm5ic3A7d2UmbmJzcDtz aG91bGQmbmJzcDtub3QmbmJzcDt1c2UmbmJzcDt0aGUmbmJzcDt3b3JkJm5ic3A7Im1hbmRhdG9y eSImbmJzcDt0aGVuITxicj4mZ3Q7PGJyPiZndDsmbmJzcDtBcyZuYnNwO2l0Jm5ic3A7aXMmbmJz cDsibWFuZGF0b3J5IiZuYnNwO2luJm5ic3A7dGhlJm5ic3A7Y29udGV4dCZuYnNwO29mJm5ic3A7 dXNpbmcmbmJzcDthJm5ic3A7bmV3Jm5ic3A7ZmVhdHVyZSZuYnNwO2RlZmluZWQmbmJzcDtpbjxi cj4mZ3Q7Jm5ic3A7YSZuYnNwO2Z1dHVyZSZuYnNwO2V4dGVuc2lvbiZuYnNwOy0tJm5ic3A7c28m bmJzcDt0byZuYnNwO3VzZSZuYnNwO3RoZSZuYnNwO25ldyZuYnNwO2ZlYXR1cmUsJm5ic3A7YW4m bmJzcDtpbXBsZW1lbnRhdGlvbjxicj4mZ3Q7Jm5ic3A7TVVTVCZuYnNwO2luY2x1ZGUmbmJzcDt0 aGUmbmJzcDtMU1AtRVhURU5ERUQtRkxBRyZuYnNwO1RMViZuYnNwO2FuZCZuYnNwO01VU1QmbmJz cDtzZXQmbmJzcDthJm5ic3A7cGFydGljdWxhciZuYnNwO2ZsYWcuPGJyPiZndDsmbmJzcDtUaGUm bmJzcDtzby1jYWxsZWQmbmJzcDsibWFuZGF0b3J5IiZuYnNwO3dvdWxkJm5ic3A7YmUmbmJzcDtv bmx5Jm5ic3A7aW4mbmJzcDt0aGUmbmJzcDtzY29wZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7cHJv dG9jb2w8YnI+Jmd0OyZuYnNwO2V4dGVuc2lvbiZuYnNwO2FuZCZuYnNwO25vdCZuYnNwO3JlcXVp cmVkJm5ic3A7d2hlbiZuYnNwO3RoZSZuYnNwO2ZlYXR1cmUmbmJzcDtpcyZuYnNwO25vdCZuYnNw O3VzZWQuPGJyPiZndDs8YnI+Jmd0OyZuYnNwOyZndDsmbmJzcDtIb3cmbmJzcDthcmUmbmJzcDt5 b3UmbmJzcDtkZWNpZGluZyZuYnNwO2lmJm5ic3A7dGhlJm5ic3A7ZXh0ZW5kZWQmbmJzcDtUTFY8 YnI+Jmd0OyZuYnNwOyZndDsmbmJzcDttaXNzaW5nPzxicj4mZ3Q7Jm5ic3A7Jmd0Ozxicj4mZ3Q7 PGJyPiZndDsmbmJzcDtUaGlzJm5ic3A7Y291bGQmbmJzcDtiZSZuYnNwO2JlY2F1c2UmbmJzcDtv ZiZuYnNwO3RoZSZuYnNwO3ByZXNlbmNlJm5ic3A7b2YmbmJzcDtzb21lJm5ic3A7b3RoZXImbmJz cDtvYmplY3QvVExWcyZuYnNwO25lZWRlZDxicj4mZ3Q7Jm5ic3A7YnkmbmJzcDt0aGUmbmJzcDtz YW1lJm5ic3A7ZXh0ZW5zaW9uJm5ic3A7YnV0Jm5ic3A7d2l0aG91dCZuYnNwO3RoZSZuYnNwO0xT UC1FWFRFTkRFRC1GTEFHJm5ic3A7VExWJm5ic3A7aW4mbmJzcDt0aGUmbmJzcDtMU1A8YnI+Jmd0 OyZuYnNwO29iamVjdC48YnI+Jmd0OyZuYnNwO1BlcmhhcHMmbmJzcDt0aGUmbmJzcDtyaWdodCZu YnNwO3RoaW5nJm5ic3A7dG8mbmJzcDtkbyZuYnNwO3dvdWxkJm5ic3A7YmUmbmJzcDt0byZuYnNw O21vdmUmbmJzcDt0aGUmbmJzcDtlcnJvciZuYnNwO2hhbmRsaW5nJm5ic3A7dG88YnI+Jmd0OyZu YnNwO3RoZSZuYnNwO2ZpcnN0Jm5ic3A7ZG9jdW1lbnQmbmJzcDt0aGF0Jm5ic3A7dXNlcyZuYnNw O3RoZSZuYnNwO0xTUC1FWFRFTkRFRC1GTEFHJm5ic3A7VExWJm5ic3A7aW5zdGVhZCZuYnNwO29m Jm5ic3A7dGhpczxicj4mZ3Q7Jm5ic3A7ZG9jdW1lbnQuPGJyPiZndDs8YnI+Jmd0OyZuYnNwO1Ro YW5rcyE8YnI+Jmd0OyZuYnNwO0RocnV2PGJyPiZndDs8YnI+Jmd0OyZuYnNwOyZndDs8YnI+Jmd0 OyZuYnNwOyZndDsmbmJzcDsvTG9hPGJyPiZndDsmbmJzcDsmZ3Q7Jm5ic3A7Jmd0Ozxicj4mZ3Q7 Jm5ic3A7Jmd0OyZuYnNwOyZndDsmbmJzcDtUaGFua3MhPGJyPiZndDsmbmJzcDsmZ3Q7Jm5ic3A7 Jmd0OyZuYnNwO0RocnV2PGJyPiZndDsmbmJzcDsmZ3Q7Jm5ic3A7Jmd0Ozxicj4mZ3Q7Jm5ic3A7 Jmd0OyZuYnNwOyZndDsmZ3Q7Jm5ic3A7L0xvYTxicj4mZ3Q7Jm5ic3A7Jmd0OyZuYnNwOyZndDsm Z3Q7PGJyPiZndDsmbmJzcDsmZ3Q7Jm5ic3A7Jmd0OyZndDs8YnI+Jmd0OyZuYnNwOyZndDsmbmJz cDsmZ3Q7Jmd0OyZuYnNwOy0tPGJyPiZndDsmbmJzcDsmZ3Q7Jm5ic3A7Jmd0OyZndDs8YnI+Jmd0 OyZuYnNwOyZndDsmbmJzcDsmZ3Q7Jmd0OyZuYnNwO0xvYSZuYnNwO0FuZGVyc3NvbiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO2VtYWlsOiZuYnNwO2xvYUBwaS5udTxicj4mZ3Q7Jm5ic3A7 Jmd0OyZuYnNwOyZndDsmZ3Q7Jm5ic3A7U2VuaW9yJm5ic3A7TVBMUyZuYnNwO0V4cGVydCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2xvYS5waS5udUBnbWFpbC5jb208 YnI+Jmd0OyZuYnNwOyZndDsmbmJzcDsmZ3Q7Jmd0OyZuYnNwO0Jyb256ZSZuYnNwO0RyYWdvbiZu YnNwO0NvbnN1bHRpbmcmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtwaG9uZTombmJzcDsrNDYmbmJzcDs3 MzkmbmJzcDs4MSZuYnNwOzIxJm5ic3A7NjQ8YnI+Jmd0OyZuYnNwOyZndDs8YnI+Jmd0OyZuYnNw OyZndDsmbmJzcDstLTxicj4mZ3Q7Jm5ic3A7Jmd0Ozxicj4mZ3Q7Jm5ic3A7Jmd0OyZuYnNwO0xv YSZuYnNwO0FuZGVyc3NvbiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2VtYWlsOiZuYnNw O2xvYUBwaS5udTxicj4mZ3Q7Jm5ic3A7Jmd0OyZuYnNwO1NlbmlvciZuYnNwO01QTFMmbmJzcDtF eHBlcnQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtsb2EucGkubnVA Z21haWwuY29tPGJyPiZndDsmbmJzcDsmZ3Q7Jm5ic3A7QnJvbnplJm5ic3A7RHJhZ29uJm5ic3A7 Q29uc3VsdGluZyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3Bob25lOiZuYnNwOys0NiZuYnNwOzczOSZu YnNwOzgxJm5ic3A7MjEmbmJzcDs2NDxicj4mZ3Q7PGJyPiZndDs8L2Rpdj48L2Rpdj48L2Rpdj48 L2Rpdj48L2Rpdj48L2Rpdj48cD48YnI+PC9wPjwvZGl2Pg== --=====_003_next=====-- --=====_002_next=====-- --=====_001_next=====--