From pce-bounces@ietf.org Sun Jan 4 12:15:04 2009 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3677B3A6A94; Sun, 4 Jan 2009 12:15:04 -0800 (PST) X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id BF03D3A6972; Sun, 4 Jan 2009 12:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090104201501.BF03D3A6972@core3.amsl.com> Date: Sun, 4 Jan 2009 12:15:01 -0800 (PST) Cc: pce@ietf.org Subject: [Pce] I-D Action:draft-ietf-pce-manageability-requirements-06.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Inclusion of Manageability Sections in PCE Working Group Drafts Author(s) : A. Farrel Filename : draft-ietf-pce-manageability-requirements-06.txt Pages : 13 Date : 2009-01-04 It has often been the case that manageability considerations have been retrofitted to protocols after they have been specified, standardized, implemented, or deployed. This is sub-optimal. Similarly, new protocols or protocol extensions are frequently designed without due consideration of manageability requirements. This document specifies the recommendation for all new Internet-Drafts in the PCE Working Group to include a "Manageability Considerations" section, and gives guidance on what that section should contain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-manageability-requirements-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pce-manageability-requirements-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-01-04120738.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@ietf.org Sun Jan 4 12:45:31 2009 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0B723A68B4; Sun, 4 Jan 2009 12:45:31 -0800 (PST) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1275D3A68B4 for ; Sun, 4 Jan 2009 12:45:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[AWL=-0.663, BAYES_50=0.001, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtbIsvMdyadF for ; Sun, 4 Jan 2009 12:45:29 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id EC5D33A6813 for ; Sun, 4 Jan 2009 12:45:28 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id n04KjEWU003893 for ; Sun, 4 Jan 2009 20:45:14 GMT Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id n04KjDDD003886 for ; Sun, 4 Jan 2009 20:45:14 GMT Message-ID: <79495DB526C94F0A8A602817C00DD452@your029b8cecfe> From: "Adrian Farrel" To: References: <3D1E7B57-07FE-41F0-AAAB-3E07162200E4@cisco.com> Date: Sun, 4 Jan 2009 20:36:35 -0000 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: [Pce] Working Group Last Call Complete:draft-ietf-pce-global-concurrent-optimization-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Hi, We allowed a little extra time over Christmas in case someone was sitting on comments, but it looks like we are done with no comments. If the authors would care to resubmit the I-D with updated IPR boilerplate, the chairs will pass it on to the AD. Thanks, Adrian ----- Original Message ----- From: "JP Vasseur" To: Sent: Tuesday, November 25, 2008 8:57 AM Subject: [Pce] Working Group Last Call:draft-ietf-pce-global-concurrent-optimization-05.txt > Dear WG, > > This starts a 2-week Working Group Last Call on draft-ietf-pce-global- > concurrent-optimization-05.txt, which will end on December 9 at noon ET. > > Please send your comment on the Mailing list and to the authors. > > Thanks. > > JP. -------------------------------------------------------------------------------- > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Mon Jan 5 10:30:03 2009 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2233028C0F8; Mon, 5 Jan 2009 10:30:03 -0800 (PST) X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1D9E83A680C; Mon, 5 Jan 2009 10:30:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090105183002.1D9E83A680C@core3.amsl.com> Date: Mon, 5 Jan 2009 10:30:02 -0800 (PST) Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-inter-layer-req-09.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering Author(s) : E. Oki, J. Le Roux, K. Kumaki, A. Farrel, T. Takeda Filename : draft-ietf-pce-inter-layer-req-09.txt Pages : 13 Date : 2009-1-5 The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. MPLS and GMPLS networks may be constructed from layered client/server networks. It is advantageous for overall network efficiency to provide end-to-end traffic engineering across multiple network layers. PCE is a candidate solution for such requirements. Generic requirements for a communication protocol between Path Computation Clients (PCCs) and PCEs are presented in "PCE Communication Protocol Generic Requirements". Generic requirements for PCE discovery protocol are presented in "Requirements for Path Computation Element (PCE) Discovery". This document complements the generic requirements and presents detailed sets of PCC-PCE communication protocol requirements and PCE discovery protocol requirements for inter-layer traffic engineering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-inter-layer-req-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pce-inter-layer-req-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-1-5102950.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@ietf.org Mon Jan 5 10:45:08 2009 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2966428C0EB; Mon, 5 Jan 2009 10:45:08 -0800 (PST) X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 072803A67F9; Mon, 5 Jan 2009 10:45:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090105184503.072803A67F9@core3.amsl.com> Date: Mon, 5 Jan 2009 10:45:02 -0800 (PST) Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-inter-layer-ext-02.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Extensions to the Path Computation Element communication Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering Author(s) : E. Oki, J. Le Roux, A. Farrel Filename : draft-ietf-pce-inter-layer-ext-02.txt Pages : 16 Date : 2009-1-5 The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. MPLS and GMPLS networks may be constructed from layered service networks. It is advantageous for overall network efficiency to provide end-to-end traffic engineering across multiple network layers through a process called inter-layer traffic engineering. PCE is a candidate solution for such requirements. The PCE communication Protocol (PCEP) is designed as a communication protocol between Path Computation Clients (PCCs) and PCEs. This document presents PCEP extensions for inter-layer traffic engineering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-inter-layer-ext-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pce-inter-layer-ext-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-1-5103732.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@ietf.org Tue Jan 6 03:30:05 2009 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FE9728C119; Tue, 6 Jan 2009 03:30:05 -0800 (PST) X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 115B03A6867; Tue, 6 Jan 2009 03:30:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090106113002.115B03A6867@core3.amsl.com> Date: Tue, 6 Jan 2009 03:30:02 -0800 (PST) Cc: pce@ietf.org Subject: [Pce] I-D Action:draft-ietf-pce-inter-layer-frwk-08.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering Author(s) : E. Oki, et al. Filename : draft-ietf-pce-inter-layer-frwk-08.txt Pages : 30 Date : 2009-01-06 A network may comprise multiple layers. It is important to globally optimize network resource utilization, taking into account all layers, rather than optimizing resource utilization at each layer independently. This allows better network efficiency to be achieved through a process that we call inter-layer traffic engineering. The Path Computation Element (PCE) can be a powerful tool to achieve inter-layer traffic engineering. This document describes a framework for applying the PCE-based architecture to inter-layer Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) traffic engineering. It provides suggestions for the deployment of PCE in support of multi-layer networks. This document also describes network models where PCE performs inter-layer traffic engineering, and the relationship between PCE and a functional component called the Virtual Network Topology Manager (VNTM). Oki et al. Expires July 2009 [page 1] draft-ietf-pce-inter-layer-frwk-08.txt Janaury 2009 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-inter-layer-frwk-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pce-inter-layer-frwk-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-01-06032724.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@ietf.org Tue Jan 6 03:43:56 2009 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC8663A6867; Tue, 6 Jan 2009 03:43:56 -0800 (PST) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2A5C3A67FC for ; Tue, 6 Jan 2009 03:43:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.64 X-Spam-Level: X-Spam-Status: No, score=-0.64 tagged_above=-999 required=5 tests=[AWL=-0.455, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19teaDSZZnRD for ; Tue, 6 Jan 2009 03:43:55 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id 113A83A6867 for ; Tue, 6 Jan 2009 03:43:54 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id n06Bhbmi028040 for ; Tue, 6 Jan 2009 11:43:40 GMT Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id n06BhaS5028016 for ; Tue, 6 Jan 2009 11:43:37 GMT Message-ID: <1249F3F84F3B455C87C231051794A656@your029b8cecfe> From: "Adrian Farrel" To: References: <34CD72EB03F6410D9C8BBB1C40758C86@your029b8cecfe> Date: Tue, 6 Jan 2009 11:43:29 -0000 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: [Pce] Working group last call complete : draft-ietf-pce-monitoring-03.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Hi, Working group last call completed. The authors have a bunch of comment to address. Thanks, Adrian ----- Original Message ----- From: "Adrian Farrel" To: Sent: Monday, December 15, 2008 12:30 PM Subject: [Pce] Working group last call draft-ietf-pce-monitoring-02.txt > This email begins a working group last call on > draft-ietf-pce-monitoring-02.txt > > The last call will run for three weeks to give people a little extra time > over the Christmas period. > Thus, the call will end on 5th January 2009 at noon GMT > > Please send your comments to the mailing list. > > Thanks, > Adrian > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Tue Jan 6 03:45:05 2009 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00A0428C113; Tue, 6 Jan 2009 03:45:05 -0800 (PST) X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 125013A67FC; Tue, 6 Jan 2009 03:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090106114502.125013A67FC@core3.amsl.com> Date: Tue, 6 Jan 2009 03:45:02 -0800 (PST) Cc: pce@ietf.org Subject: [Pce] I-D Action:draft-ietf-pce-inter-layer-frwk-09.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering Author(s) : E. Oki, et al. Filename : draft-ietf-pce-inter-layer-frwk-09.txt Pages : 30 Date : 2009-01-06 A network may comprise multiple layers. It is important to globally optimize network resource utilization, taking into account all layers, rather than optimizing resource utilization at each layer independently. This allows better network efficiency to be achieved through a process that we call inter-layer traffic engineering. The Path Computation Element (PCE) can be a powerful tool to achieve inter-layer traffic engineering. This document describes a framework for applying the PCE-based architecture to inter-layer Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) traffic engineering. It provides suggestions for the deployment of PCE in support of multi-layer networks. This document also describes network models where PCE performs inter-layer traffic engineering, and the relationship between PCE and a functional component called the Virtual Network Topology Manager (VNTM). Oki, et al. [page 1] draft-ietf-pce-inter-layer-frwk-09.txt Janaury 2009 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-inter-layer-frwk-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pce-inter-layer-frwk-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-01-06034034.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@ietf.org Tue Jan 6 03:58:56 2009 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F32B3A68BA; Tue, 6 Jan 2009 03:58:56 -0800 (PST) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1731928C118 for ; Tue, 6 Jan 2009 03:58:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.839 X-Spam-Level: X-Spam-Status: No, score=-1.839 tagged_above=-999 required=5 tests=[AWL=0.759, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5x0EYzPMKvgI for ; Tue, 6 Jan 2009 03:58:54 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id F2B6F3A6768 for ; Tue, 6 Jan 2009 03:58:53 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id n06Bwbtx013043 for ; Tue, 6 Jan 2009 11:58:39 GMT Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id n06BwZZO013012 for ; Tue, 6 Jan 2009 11:58:36 GMT Message-ID: <0A8AA43A2E544F9B990EE94B0BF3146E@your029b8cecfe> From: "Adrian Farrel" To: References: <20090106114502.125013A67FC@core3.amsl.com> Date: Tue, 6 Jan 2009 11:58:28 -0000 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [Pce] I-D Action:draft-ietf-pce-inter-layer-frwk-09.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Hi, Fixed some formatting Put in the new IPR boilerplate Added a null IANA section Fixed several of the sequences to renumber the action steps. The authors believe this I-D is now ready for last call. Thanks, Adrian ----- Original Message ----- From: To: Cc: Sent: Tuesday, January 06, 2009 11:45 AM Subject: I-D Action:draft-ietf-pce-inter-layer-frwk-09.txt >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Path Computation Element Working Group of > the IETF. > > > Title : Framework for PCE-Based Inter-Layer MPLS and GMPLS > Traffic Engineering > Author(s) : E. Oki, et al. > Filename : draft-ietf-pce-inter-layer-frwk-09.txt > Pages : 30 > Date : 2009-01-06 > > A network may comprise multiple layers. It is important to globally > optimize network resource utilization, taking into account all > layers, rather than optimizing resource utilization at each layer > independently. This allows better network efficiency to be achieved > through a process that we call inter-layer traffic engineering. The > Path Computation Element (PCE) can be a powerful tool to achieve > inter-layer traffic engineering. > > This document describes a framework for applying the PCE-based > architecture to inter-layer Multiprotocol Label Switching (MPLS) and > Generalized MPLS (GMPLS) traffic engineering. It provides > suggestions for the deployment of PCE in support of multi-layer > networks. This document also describes network models where PCE > performs inter-layer traffic engineering, and the relationship > between PCE and a functional component called the Virtual Network > Topology Manager (VNTM). > > Oki, et al. > > > > > > > > > > > > > > > > > [page 1] > > draft-ietf-pce-inter-layer-frwk-09.txt > > > > > > > Janaury 2009 > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pce-inter-layer-frwk-09.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------------------- > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Tue Jan 6 07:45:02 2009 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB4473A689D; Tue, 6 Jan 2009 07:45:02 -0800 (PST) X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id EA1673A689D; Tue, 6 Jan 2009 07:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090106154501.EA1673A689D@core3.amsl.com> Date: Tue, 6 Jan 2009 07:45:01 -0800 (PST) Cc: pce@ietf.org Subject: [Pce] I-D Action:draft-ietf-pce-global-concurrent-optimization-06.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Path Computation Element Communication Protocol (PCECP) Requirements and Protocol Extensions In Support of Global Concurrent Optimization Author(s) : Y. Lee, et al. Filename : draft-ietf-pce-global-concurrent-optimization-06.txt Pages : 31 Date : 2009-01-05 The Path Computation Element (PCE) is a network component, application, or node that is capable of performing path computations at the request of Path Computation Clients (PCCs). The PCE is applied in Multiprotocol Label Switching Traffic Engineering (MPLS-TE) networks and in Generalized MPLS (GMPLS) networks to determine the routes of Label Switched Paths (LSPs) through the network. In this context a PCC may be a Label Switching Router (LSR), a Network Management System (NMS), or another PCE. The Path Computation Element Communication Protocol (PCEP) is specified for communications between PCCs and PCEs, and between cooperating PCEs. When computing or re-optimizing the routes of a set of TE LSPs through a network it may be advantageous to perform bulk path computations in order to avoid blocking problems and to achieve more optimal network-wide solutions. Such bulk optimization is termed Global Concurrent Optimization (GCO). A GCO is able to simultaneously consider the entire topology of the network and the complete set of existing TE LSPs, and their respective constraints, and look to optimize or re-optimize the entire network to satisfy all constraints for all TE LSPs. A GCO may also be applied to some subset of the TE LSPs in a network. The GCO application is primarily a Network Management System (NMS) solution. While GCO is applicable to any simultaneous request for multiple TE LSPs (for example, a request for end-to-end protection), it is not envisaged that global concurrent reoptimization would be applied in a network (such as an MPLS-TE network) that contains a very large number of very low bandwidth or zero bandwidth TE LSPs since the large scope of the problem and the small benefit of concurrent reoptimization relative to single TE LSP reoptimization is unlikely to make the process worthwhile. Further, applying global concurrent reoptimization in a network with a high rate of change of TE LSPs (churn) is not advised because of the likelihood that TE LSPs would change before they could be globally reoptimized. Global reoptimization is more applicable to stable networks such as transport networks or those with long-term TE LSP tunnels. This document provides application-specific requirements and the PCEP extensions in support of GCO applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-global-concurrent-optimization-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pce-global-concurrent-optimization-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-01-06074419.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@ietf.org Tue Jan 6 07:52:22 2009 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E12B3A67B2; Tue, 6 Jan 2009 07:52:22 -0800 (PST) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B88BF3A67B2 for ; Tue, 6 Jan 2009 07:52:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=1.052, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SmBwfHqQrtja for ; Tue, 6 Jan 2009 07:52:19 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id D58E33A6774 for ; Tue, 6 Jan 2009 07:52:19 -0800 (PST) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KD20001F42UBG@usaga04-in.huawei.com> for pce@ietf.org; Tue, 06 Jan 2009 09:52:06 -0600 (CST) Received: from L73682 ([10.124.12.74]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KD200A1042MFG@usaga04-in.huawei.com> for pce@ietf.org; Tue, 06 Jan 2009 09:52:06 -0600 (CST) Date: Tue, 06 Jan 2009 09:51:57 -0600 From: Young Lee To: pce@ietf.org Message-id: <000601c97016$b6b0eed0$4a0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Thread-index: AclwFZ7x/AdwLNMFTXaHKcfayakvIwAAMisw Cc: jpv@cisco.com Subject: [Pce] FW: New Version Notification for draft-ietf-pce-global-concurrent-optimization-06 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Hi PCE WG chairs, Per your request, a newer version of PCE-GCO draft in compliance to the new boiler template has been issued for the AD's review. Thanks. Regards, Young -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Tuesday, January 06, 2009 9:44 AM To: ylee@huawei.com Cc: jeanlouis.leroux@orange-ftgroup.com; daniel@olddog.co.uk; oki@ice.uec.ac.jp Subject: New Version Notification for draft-ietf-pce-global-concurrent-optimization-06 A new version of I-D, draft-ietf-pce-global-concurrent-optimization-06.txt has been successfuly submitted by Young Lee and posted to the IETF repository. Filename: draft-ietf-pce-global-concurrent-optimization Revision: 06 Title: Path Computation Element Communication Protocol (PCECP) Requirements and Protocol Extensions In Support of Global Concurrent Optimization Creation_date: 2009-01-05 WG ID: pce Number_of_pages: 31 Abstract: The Path Computation Element (PCE) is a network component, application, or node that is capable of performing path computations at the request of Path Computation Clients (PCCs). The PCE is applied in Multiprotocol Label Switching Traffic Engineering (MPLS-TE) networks and in Generalized MPLS (GMPLS) networks to determine the routes of Label Switched Paths (LSPs) through the network. In this context a PCC may be a Label Switching Router (LSR), a Network Management System (NMS), or another PCE. The Path Computation Element Communication Protocol (PCEP) is specified for communications between PCCs and PCEs, and between cooperating PCEs. When computing or re-optimizing the routes of a set of TE LSPs through a network it may be advantageous to perform bulk path computations in order to avoid blocking problems and to achieve more optimal network-wide solutions. Such bulk optimization is termed Global Concurrent Optimization (GCO). A GCO is able to simultaneously consider the entire topology of the network and the complete set of existing TE LSPs, and their respective constraints, and look to optimize or re-optimize the entire network to satisfy all constraints for all TE LSPs. A GCO may also be applied to some subset of the TE LSPs in a network. The GCO application is primarily a Network Management System (NMS) solution. While GCO is applicable to any simultaneous request for multiple TE LSPs (for example, a request for end-to-end protection), it is not envisaged that global concurrent reoptimization would be applied in a network (such as an MPLS-TE network) that contains a very large number of very low bandwidth or zero bandwidth TE LSPs since the large scope of the problem and the small benefit of concurrent reoptimization relative to single TE LSP reoptimization is unlikely to make the process worthwhile. Further, applying global concurrent reoptimization in a network with a high rate of change of TE LSPs (churn) is not advised because of the likelihood that TE LSPs would change before they could be globally reoptimized. Global reoptimization is more applicable to stable networks such as transport networks or those with long-term TE LSP tunnels. This document provides application-specific requirements and the PCEP extensions in support of GCO applications. The IETF Secretariat. _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Tue Jan 6 07:52:51 2009 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 708253A6A32; Tue, 6 Jan 2009 07:52:51 -0800 (PST) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74CA03A6A32 for ; Tue, 6 Jan 2009 07:52:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.542 X-Spam-Level: X-Spam-Status: No, score=-10.542 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVrYotPt289x for ; Tue, 6 Jan 2009 07:52:49 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 5721F3A6774 for ; Tue, 6 Jan 2009 07:52:49 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,339,1228089600"; d="scan'208,217";a="30177492" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 06 Jan 2009 15:52:35 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n06FqZn3018025 for ; Tue, 6 Jan 2009 16:52:35 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n06FqZj9005213 for ; Tue, 6 Jan 2009 15:52:35 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Jan 2009 16:52:34 +0100 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Jan 2009 16:52:34 +0100 Message-Id: <3FBAA33B-D92D-4A9D-862A-BA2F936208F1@cisco.com> From: JP Vasseur To: pce@ietf.org Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 6 Jan 2009 16:52:33 +0100 X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 06 Jan 2009 15:52:34.0589 (UTC) FILETIME=[CA822CD0:01C97016] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2602; t=1231257155; x=1232121155; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Working=20Group=20Last=20Call=3A=20draft-ietf-p ce-inter-layer-frwk-09.txt |Sender:=20; bh=tDetmQWUSyu7xjpY2CfPFF7EIDdCPd5ABpkoMs2luzU=; b=Uw1R5AYvP/sUGajuhVHXbPxDWzEc0McOwStvi7CEVtb8NXaL9gFYg6tgDt rktsY2EzbhWN/0FE8IyN/ZYYaek14yE/JtUL6O9xsLAx2yomDllpioUGK1ch F2m/Nvg+ud; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: [Pce] Working Group Last Call: draft-ietf-pce-inter-layer-frwk-09.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0086659478==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org --===============0086659478== Content-Type: multipart/alternative; boundary=Apple-Mail-39--453116469 --Apple-Mail-39--453116469 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Dear WG, First of all, happy new year to all of you. This email starts a 2-week Working Group Last Call on draft-ietf-pce- inter-layer-frwk-09.txt, which will end on January 20 at noon ET. Please send your comment on the Mailing list and to the authors. Thanks. JP. --Apple-Mail-39--453116469 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Dear WG,

First of all, happy new year to all of = you.

This email starts a 2-week Working Group Last Call = on draft-ietf-pce-inter-layer-frwk-09.txt
Please send your comment on = the Mailing list and to the authors.

Thanks.

X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 627623A6A62; Tue, 6 Jan 2009 11:08:49 -0800 (PST) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E10FA28C108; Tue, 6 Jan 2009 11:08:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.412 X-Spam-Level: X-Spam-Status: No, score=-6.412 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TG1JDA-nLA1s; Tue, 6 Jan 2009 11:08:47 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 8C2F03A6A98; Tue, 6 Jan 2009 11:08:47 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKSWOsMtOTgoJ3zs7flPjce/tIyWPfMog5@postini.com; Tue, 06 Jan 2009 11:08:35 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.336.0; Tue, 6 Jan 2009 11:04:22 -0800 Received: from p-emsmtp03.jnpr.net ([66.129.254.54]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Jan 2009 11:04:22 -0800 Received: from emailwf1.jnpr.net ([10.10.2.33]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Jan 2009 11:04:21 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 6 Jan 2009 14:04:18 -0500 Message-ID: <3525C9833C09ED418C6FD6CD9514668C05660B4F@emailwf1.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: draft-farrel-rtg-common-bnf (Reduced Backus-Naur Form (RBNF) A Syntax Used in Various Protocol Specifications) to Proposed Standard Thread-Index: AclwMIRsBs6pUzOtTVCjiAYG5vI6zwAABnxA From: Ross Callon To: , , , , X-OriginalArrivalTime: 06 Jan 2009 19:04:21.0767 (UTC) FILETIME=[95523170:01C97031] Cc: Ross Callon , Magnus Westerlund , David Ward , Lars Eggert Subject: [Pce] FW: Last Call: draft-farrel-rtg-common-bnf (Reduced Backus-Naur Form (RBNF) A Syntax Used in Various Protocol Specifications) to Proposed Standard X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org FYI. This may be of interest to the CCAMP, MPLS, PCE and TSVWG WGs. thanks, Ross -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG Sent: 06 January 2009 13:56 To: IETF-Announce Subject: Last Call: draft-farrel-rtg-common-bnf (Reduced Backus-Naur Form (RBNF) A Syntax Used in Various Protocol Specifications) to Proposed Standard The IESG has received a request from an individual submitter to consider the following document: - 'Reduced Backus-Naur Form (RBNF) A Syntax Used in Various Protocol Specifications ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-02-03. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-farrel-rtg-common-bnf-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag= 17681&rfc_flag=0 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Tue Jan 6 12:45:04 2009 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FA4528C0F3; Tue, 6 Jan 2009 12:45:04 -0800 (PST) X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id CA1583A6A5C; Tue, 6 Jan 2009 12:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090106204501.CA1583A6A5C@core3.amsl.com> Date: Tue, 6 Jan 2009 12:45:01 -0800 (PST) Cc: pce@ietf.org Subject: [Pce] I-D Action:draft-ietf-pce-global-concurrent-optimization-07.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Path Computation Element Communication Protocol (PCECP) Requirements and Protocol Extensions In Support of Global Concurrent Optimization Author(s) : Y. Lee, et al. Filename : draft-ietf-pce-global-concurrent-optimization-07.txt Pages : 31 Date : 2009-01-06 The Path Computation Element (PCE) is a network component, application, or node that is capable of performing path computations at the request of Path Computation Clients (PCCs). The PCE is applied in Multiprotocol Label Switching Traffic Engineering (MPLS-TE) networks and in Generalized MPLS (GMPLS) networks to determine the routes of Label Switched Paths (LSPs) through the network. In this context a PCC may be a Label Switching Router (LSR), a Network Management System (NMS), or another PCE. The Path Computation Element Communication Protocol (PCEP) is specified for communications between PCCs and PCEs, and between cooperating PCEs. When computing or re-optimizing the routes of a set of TE LSPs through a network it may be advantageous to perform bulk path computations in order to avoid blocking problems and to achieve more optimal network-wide solutions. Such bulk optimization is termed Global Concurrent Optimization (GCO). A GCO is able to simultaneously consider the entire topology of the network and the complete set of existing TE LSPs, and their respective constraints, and look to optimize or re-optimize the entire network to satisfy all constraints for all TE LSPs. A GCO may also be applied to some subset of the TE LSPs in a network. The GCO application is primarily a Network Management System (NMS) solution. While GCO is applicable to any simultaneous request for multiple TE LSPs (for example, a request for end-to-end protection), it is not envisaged that global concurrent reoptimization would be applied in a network (such as an MPLS-TE network) that contains a very large number of very low bandwidth or zero bandwidth TE LSPs since the large scope of the problem and the small benefit of concurrent reoptimization relative to single TE LSP reoptimization is unlikely to make the process worthwhile. Further, applying global concurrent reoptimization in a network with a high rate of change of TE LSPs (churn) is not advised because of the likelihood that TE LSPs would change before they could be globally reoptimized. Global reoptimization is more applicable to stable networks such as transport networks or those with long-term TE LSP tunnels. This document provides application-specific requirements and the PCEP extensions in support of GCO applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-global-concurrent-optimization-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pce-global-concurrent-optimization-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-01-06123616.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@ietf.org Tue Jan 6 13:36:04 2009 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FE8E3A6893; Tue, 6 Jan 2009 13:36:04 -0800 (PST) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 416093A6893 for ; Tue, 6 Jan 2009 13:36:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.921 X-Spam-Level: X-Spam-Status: No, score=-0.921 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_20=-0.74, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id og4MHc+H76GA for ; Tue, 6 Jan 2009 13:36:02 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id 52EAE3A6817 for ; Tue, 6 Jan 2009 13:36:02 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id n06LZfpQ008289; Tue, 6 Jan 2009 21:35:41 GMT Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id n06LZcaK008263; Tue, 6 Jan 2009 21:35:39 GMT Message-ID: From: "Adrian Farrel" To: Date: Tue, 6 Jan 2009 21:32:04 -0000 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: [Pce] IPR disclosure on draft-ietf-pce-global-concurrent-optimization X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Hi, We recently completed last call on this draft, and the authors are busy tidying it up ready to go to the AD. In the mean time, we have https://datatracker.ietf.org/ipr/1061/ which is titled... HUAWEI TECHNOLOGIES CO.,LTD's Statement about IPR related to draft-bernstein-ccamp-wson-signaling-03, draft-ietf-pce-global-concurrent-optimization-05, and draft-tsou-pcn-racf-applic-01 Please consider this IPR disclosure and decide whether you would like the working group to continue with the draft as it is, or revisit the work to develop a different solution. Thanks, Adrian _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Tue Jan 6 14:30:02 2009 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 291AE3A69D2; Tue, 6 Jan 2009 14:30:02 -0800 (PST) X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 40BCC3A69CA; Tue, 6 Jan 2009 14:30:00 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090106223001.40BCC3A69CA@core3.amsl.com> Date: Tue, 6 Jan 2009 14:30:01 -0800 (PST) Cc: pce@ietf.org Subject: [Pce] I-D Action:draft-ietf-pce-global-concurrent-optimization-08.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions In Support of Global Concurrent Optimization Author(s) : Y. Lee, et al. Filename : draft-ietf-pce-global-concurrent-optimization-08.txt Pages : 27 Date : 2009-01-06 The Path Computation Element (PCE) is a network component, application, or node that is capable of performing path computations at the request of Path Computation Clients (PCCs). The PCE is applied in Multiprotocol Label Switching Traffic Engineering (MPLS-TE) networks and in Generalized MPLS (GMPLS) networks to determine the routes of Label Switched Paths (LSPs) through the network. In this context a PCC may be a Label Switching Router (LSR), a Network Management System (NMS), or another PCE. The Path Computation Element Communication Protocol (PCEP) is specified for communications between PCCs and PCEs, and between cooperating PCEs. When computing or re-optimizing the routes of a set of TE LSPs through a network it may be advantageous to perform bulk path computations in order to avoid blocking problems and to achieve more optimal network-wide solutions. Such bulk optimization is termed Global Concurrent Optimization (GCO). A GCO is able to simultaneously consider the entire topology of the network and the complete set of existing TE LSPs, and their respective constraints, and look to optimize or re-optimize the entire network to satisfy all constraints for all TE LSPs. A GCO may also be applied to some subset of the TE LSPs in a network. The GCO application is primarily a Network Management System (NMS) solution. While GCO is applicable to any simultaneous request for multiple TE LSPs (for example, a request for end-to-end protection), it is not envisaged that global concurrent reoptimization would be applied in a network (such as an MPLS-TE network) that contains a very large number of very low bandwidth or zero bandwidth TE LSPs since the large scope of the problem and the small benefit of concurrent reoptimization relative to single TE LSP reoptimization is unlikely to make the process worthwhile. Further, applying global concurrent reoptimization in a network with a high rate of change of TE LSPs (churn) is not advised because of the likelihood that TE LSPs would change before they could be globally reoptimized. Global reoptimization is more applicable to stable networks such as transport networks or those with long-term TE LSP tunnels. This document provides application-specific requirements and the PCEP extensions in support of GCO applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-global-concurrent-optimization-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pce-global-concurrent-optimization-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-01-06141922.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@ietf.org Thu Jan 8 11:23:31 2009 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4986D3A680C; Thu, 8 Jan 2009 11:23:31 -0800 (PST) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCEE23A680C for ; Thu, 8 Jan 2009 11:23:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.643 X-Spam-Level: X-Spam-Status: No, score=-0.643 tagged_above=-999 required=5 tests=[AWL=-0.458, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MjiXGsxwlN2r for ; Thu, 8 Jan 2009 11:23:29 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id C78B73A67B6 for ; Thu, 8 Jan 2009 11:23:28 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id n08JN72V017330; Thu, 8 Jan 2009 19:23:07 GMT Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id n08JN7Zi017316; Thu, 8 Jan 2009 19:23:07 GMT Message-ID: <7395E316AC0E4286A147A731A21D7805@your029b8cecfe> From: "Adrian Farrel" To: Date: Thu, 8 Jan 2009 19:23:01 -0000 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: Ross Callon Subject: [Pce] Nit in draft-ietf-pce-path-key-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Hi, Post last call we found a nit in this draft. I don't think that fixing it does more than change a nonsense typo into meaningful text. Please shout if you have any issues with the change. Thanks, Adrian The change is... 6.1. Control of Function Through Configuration and Policy The treatment of a path segment as a CPS, and its substitution in a PCReq ERO with a PKS, is a function that MUST be under operator s/PCReq/PCRep/ and policy control where a PCE supports the function. The operator MUST be given the ability to specify which path segments are to be replaced and under what circumstances. For example, an operator might set a policy that states that every path segment for the operator's domain will be replaced by a PKS when the PCReq has been issued from outside the domain. _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pcdphq@brain.net.pk Thu Jan 8 11:35:30 2009 Return-Path: X-Original-To: ietfarch-pce-archive@core3.amsl.com Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D29AD3A69BD for ; Thu, 8 Jan 2009 11:35:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -36.937 X-Spam-Level: X-Spam-Status: No, score=-36.937 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_H_CANADIAN=0.5, GB_H_PHARMACY=1, GB_PHARMACY=1, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MANGLED_SEX=2.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_IMG_ONLY=1.666, URIBL_BLACK=20, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dlt9OyKb0D47 for ; Thu, 8 Jan 2009 11:35:24 -0800 (PST) Received: from mta.email.webmd.com (unknown [99.8.246.13]) by core3.amsl.com (Postfix) with SMTP id D2D9E3A6940 for ; Thu, 8 Jan 2009 11:35:21 -0800 (PST) Content-Return: allowed X-Mailer: CME-V6.5.4.3; MSN Message-Id: <20090108-53512.5688.qmail@mta.email.webmd.com> From: "Doctor Eugenio" To: pce-archive@ietf.org Subject: RE: (Canadian Pharmacy Message) We can give you second s(e\'x)ual life! MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Date: Thu, 8 Jan 2009 11:35:21 -0800 (PST)
From pce-bounces@ietf.org Thu Jan 8 22:14:38 2009 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 010C03A67D9; Thu, 8 Jan 2009 22:14:38 -0800 (PST) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 451EE3A67FD for ; Thu, 8 Jan 2009 22:14:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.52 X-Spam-Level: X-Spam-Status: No, score=-10.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHJCHxe8-REG for ; Thu, 8 Jan 2009 22:14:29 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 601AC3A67B3 for ; Thu, 8 Jan 2009 22:14:28 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,238,1231113600"; d="scan'208";a="30423590" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 09 Jan 2009 06:14:13 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n096EDHY025460; Fri, 9 Jan 2009 07:14:13 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n096EDUR018108; Fri, 9 Jan 2009 06:14:13 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Jan 2009 07:14:13 +0100 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Jan 2009 07:14:12 +0100 Message-Id: <1BDE1A4A-EBBD-4D80-A2FD-357520001943@cisco.com> From: JP Vasseur To: pce@ietf.org Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 9 Jan 2009 07:14:12 +0100 X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 09 Jan 2009 06:14:12.0869 (UTC) FILETIME=[7DE92B50:01C97221] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=379; t=1231481653; x=1232345653; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20draft-kkoushik-pce-pcep-mib-02.txt=20adopted=20 as=20WG=20document |Sender:=20; bh=nULkraqfP7WUnTwvY56l+N/UgF60157HNXmSlK+XWC0=; b=j/lNpjtjmLVPlhMVzLo6xnXMGpM4GkXI2CgDCQVbCWYuo5/JU9Z2GaHUgl nasxkK1FRisQ/niwQp3FFF4XWDcLF4zPYxne4Uq/AF9miNycW2QTQMPNqbzb 1/UmIgXZnB; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [Pce] draft-kkoushik-pce-pcep-mib-02.txt adopted as WG document X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Dear WG, As discussed during our last WG meeting, draft-kkoushik-pce-pcep- mib-02.txt is clearly related to one of our WG item and should be adopted as a WG document (we had the promise from their authors to continue the work since the ID has been in a "silent" mode for a few month). Let us know if you have any objection by Jan 16, noon ET. Thanks. JP. _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Thu Jan 8 22:36:07 2009 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A8AA3A67C0; Thu, 8 Jan 2009 22:36:07 -0800 (PST) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9BFD3A67C0 for ; Thu, 8 Jan 2009 22:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.522 X-Spam-Level: X-Spam-Status: No, score=-10.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdoZ1I4FjHTQ for ; Thu, 8 Jan 2009 22:36:05 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 52E7C3A65A5 for ; Thu, 8 Jan 2009 22:36:05 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,238,1231113600"; d="scan'208";a="30424139" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 09 Jan 2009 06:35:50 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n096Zob7017549; Fri, 9 Jan 2009 07:35:50 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n096Zo7p020236; Fri, 9 Jan 2009 06:35:50 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Jan 2009 07:35:50 +0100 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Jan 2009 07:35:49 +0100 Message-Id: <4BCCC444-C7D3-4F34-91E5-2B1A66DA2BB1@cisco.com> From: JP Vasseur To: pce@ietf.org Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 9 Jan 2009 07:35:49 +0100 X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 09 Jan 2009 06:35:49.0661 (UTC) FILETIME=[82DBECD0:01C97224] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=379; t=1231482950; x=1232346950; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20draft-kkoushik-pce-pcep-mib-02.txt=20adopted=20 as=20WG=20document |Sender:=20; bh=nULkraqfP7WUnTwvY56l+N/UgF60157HNXmSlK+XWC0=; b=I/CQdTDIPf3eLNgI+id58VSlZwH7SIMonHAjVbDIRku167SkNDToyE21zQ U3ImFmgVsbbsdWnYKDQW0FXL+rqYRftvPukzVAatkQnXMi4XCsdbt2T61K5a PDjO3aPn4a; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: [Pce] draft-kkoushik-pce-pcep-mib-02.txt adopted as WG document X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Dear WG, As discussed during our last WG meeting, draft-kkoushik-pce-pcep- mib-02.txt is clearly related to one of our WG item and should be adopted as a WG document (we had the promise from their authors to continue the work since the ID has been in a "silent" mode for a few month). Let us know if you have any objection by Jan 16, noon ET. Thanks. JP. _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Mon Jan 12 01:41:39 2009 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FB1C3A6853; Mon, 12 Jan 2009 01:41:39 -0800 (PST) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EA0C3A68A2 for ; Mon, 12 Jan 2009 01:41:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.527 X-Spam-Level: X-Spam-Status: No, score=-10.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nALHKypMYGtU for ; Mon, 12 Jan 2009 01:41:32 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 3CC873A67D8 for ; Mon, 12 Jan 2009 01:41:30 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,252,1231113600"; d="scan'208";a="30590191" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 12 Jan 2009 09:41:13 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n0C9fCDT020821 for ; Mon, 12 Jan 2009 10:41:12 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0C9fCjO006137 for ; Mon, 12 Jan 2009 09:41:12 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Jan 2009 10:41:12 +0100 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Jan 2009 10:41:12 +0100 Message-Id: From: JP Vasseur To: pce@ietf.org Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 12 Jan 2009 10:41:11 +0100 X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 12 Jan 2009 09:41:12.0376 (UTC) FILETIME=[E7C0CB80:01C97499] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=56; t=1231753272; x=1232617272; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Inportant=20Meeting=20Dates=20IETF-74 |Sender:=20; bh=jhmddcjs8S5GCDdIc5WGYNzHboAZ2bqET+9BiIwlL04=; b=hdHSNKvWxnfJEfTnHq4swBIuKpFeZAPzEY0m8J7BTrpBZ79OcHB0IEhO4D poxeNI2HNOAsyNRgghqN+AuTNyuw26GqkP1brVbEtOOHePZV/NeebNRoHDWk OkEzuvZ+3W; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: [Pce] Inportant Meeting Dates IETF-74 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org FYI: http://www.ietf.org/meetings/74/cutoff-dates.html _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Tue Jan 13 05:34:49 2009 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08E8D3A6899; Tue, 13 Jan 2009 05:34:49 -0800 (PST) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA6233A6899 for ; Tue, 13 Jan 2009 05:34:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.837 X-Spam-Level: X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[AWL=0.762, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkadN+2+Athh for ; Tue, 13 Jan 2009 05:34:47 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id B83CB3A6856 for ; Tue, 13 Jan 2009 05:34:46 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id n0DDYQDe017168 for ; Tue, 13 Jan 2009 13:34:26 GMT Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id n0DDYPvs017149 for ; Tue, 13 Jan 2009 13:34:25 GMT Message-ID: <6CDD67E7B28D4FAA83466FA119751754@your029b8cecfe> From: "Adrian Farrel" To: References: Date: Tue, 13 Jan 2009 13:34:22 -0000 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [Pce] IPR disclosure on draft-ietf-pce-global-concurrent-optimization X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Hi, No-one has sent any comments on this issue, so we will proceed with the draft. There is still scope to discuss the point during IETF last call and IESG review. I'll ask the AD for publication. Cheers, Adrian ----- Original Message ----- From: "Adrian Farrel" To: Sent: Tuesday, January 06, 2009 9:32 PM Subject: [Pce] IPR disclosure ondraft-ietf-pce-global-concurrent-optimization > Hi, > > We recently completed last call on this draft, and the authors are busy > tidying it up ready to go to the AD. > > In the mean time, we have https://datatracker.ietf.org/ipr/1061/ which is > titled... > HUAWEI TECHNOLOGIES CO.,LTD's Statement about IPR related to > draft-bernstein-ccamp-wson-signaling-03, > draft-ietf-pce-global-concurrent-optimization-05, and > draft-tsou-pcn-racf-applic-01 > > Please consider this IPR disclosure and decide whether you would like the > working group to continue with the draft as it is, or revisit the work to > develop a different solution. > > Thanks, > Adrian > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Tue Jan 13 05:41:03 2009 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 848FD3A6915; Tue, 13 Jan 2009 05:41:03 -0800 (PST) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5E763A6915 for ; Tue, 13 Jan 2009 05:41:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.794 X-Spam-Level: X-Spam-Status: No, score=-0.794 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wNan+s0SfG9R for ; Tue, 13 Jan 2009 05:41:02 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id 42B473A67ED for ; Tue, 13 Jan 2009 05:41:02 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id n0DDdtpS005100; Tue, 13 Jan 2009 13:39:55 GMT Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id n0DDds7p005088; Tue, 13 Jan 2009 13:39:54 GMT Message-ID: From: "Adrian Farrel" To: "Ross Callon" Date: Tue, 13 Jan 2009 13:39:42 -0000 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: iesg-secretary@iesg.org, pce@ietf.org Subject: [Pce] Please publish draft-ietf-pce-global-concurrent-optimization-08.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Proto-write-up for draft-ietf-pce-global-concurrent-optimization-08.txt Intended status : Standards Track > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of the > document and, in particular, does he or she believe this > version is ready for forwarding to the IESG for publication? Adrian Farrel is the document shepherd. He has personally reviewed the I-D and believes it is ready for forwarding to the IESG for publication. > (1.b) Has the document had adequate review both from key WG members > and from key non-WG members? Does the Document Shepherd have > any concerns about the depth or breadth of the reviews that > have been performed? The I-D has had a good level of discussions and review in the PCE working group. It has not had review in any wider forums, but none was deemed necessary or appropriate. > (1.c) Does the Document Shepherd have concerns that the document > needs more review from a particular or broader perspective, > e.g., security, operational complexity, someone familiar with > AAA, internationalization or XML? No concerns. > (1.d) Does the Document Shepherd have any specific concerns or > issues with this document that the Responsible Area Director > and/or the IESG should be aware of? For example, perhaps he > or she is uncomfortable with certain parts of the document, or > has concerns whether there really is a need for it. In any > event, if the WG has discussed those issues and has indicated > that it still wishes to advance the document, detail those > concerns here. Has an IPR disclosure related to this document > been filed? If so, please include a reference to the > disclosure and summarize the WG discussion and conclusion on > this issue. The document is sound. An IPR disclosure was made just as the proto write-up was being done. It can be found at https://datatracker.ietf.org/ipr/1061. This disclosure appears to be somewhat peripheral to the content of the I-D although each person will need to make their own assessment. The working group was immediately polled for its opinion, but there were no comments requesting that we halt progress. The WG has been informed that it should continue to consider the issue during IETF last call and IESG review. > (1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole understand and > agree with it? Consensus is good and relatively broad. There was previously some significant concern expressed by one of the chairs with respect to the applicability of this draft and its effect on network stability. However, the authors worked closely with the chairs to derive text that addressed the issues and both chairs now support the work. > (1.f) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in > separate email messages to the Responsible Area Director. (It > should be in a separate email because this questionnaire is > entered into the ID Tracker.) No threats. No discontent. > (1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See > http://www.ietf.org/ID-Checklist.html and > http://tools.ietf.org/tools/idnits/). Boilerplate checks are > not enough; this check needs to be thorough. Has the document > met all formal review criteria it needs to, such as the MIB > Doctor, media type and URI type reviews? All checks made. > (1.h) Has the document split its references into normative and > informative? Are there normative references to documents that > are not ready for advancement or are otherwise in an unclear > state? If such normative references exist, what is the > strategy for their completion? Are there normative references > that are downward references, as described in [RFC3967]? If > so, list these downward references to support the Area > Director in the Last Call procedure for them [RFC3967]. References split. No downrefs. > (1.i) Has the Document Shepherd verified that the document IANA > consideration section exists and is consistent with the body > of the document? If the document specifies protocol > extensions, are reservations requested in appropriate IANA > registries? Are the IANA registries clearly identified? If > the document creates a new registry, does it define the > proposed initial contents of the registry and an allocation > procedure for future registrations? Does it suggest a > reasonable name for the new registry? See [RFC2434]. If the > document describes an Expert Review process has Shepherd > conferred with the Responsible Area Director so that the IESG > can appoint the needed Expert during the IESG Evaluation? The document defines small protocol enhancements to PCEP. The PCEP specification is progressing through the RFC Editor process and no formal IANA registry has yet been created. Nevertheless, this I-D requests further allocations from the PCEP registry that IANA will create and manage. The IANA section of this I-D uses the same language as the PCEP specification and, in particular, uses the same sub-registry names. > (1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as XML > code, BNF rules, MIB definitions, etc., validate correctly in > an automated checker? The message formats are described in relatively simple BNF as per the PCEP specification. This is defined in a referenced document. No automated checker has been used. The document shepherd has reviewed the BNF by hand. > (1.k) The IESG approval announcement includes a Document > Announcement Write-Up. Please provide such a Document > Announcement Write-Up. Recent examples can be found in the > "Action" announcements for approved documents. The approval > announcement contains the following sections: > > Technical Summary > Relevant content can frequently be found in the abstract > and/or introduction of the document. If not, this may be > an indication that there are deficiencies in the abstract > or introduction. The Path Computation Element (PCE) is a network component, application, or node that is capable of performing path computations at the request of Path Computation Clients (PCCs). The PCE is applied in Multiprotocol Label Switching Traffic Engineering (MPLS-TE) networks and in Generalized MPLS (GMPLS) networks to determine the routes of Label Switched Paths (LSPs) through the network. In this context a PCC may be a Label Switching Router (LSR), a Network Management System (NMS), or another PCE. The Path Computation Element Communication Protocol (PCEP) is specified for communications between PCCs and PCEs, and between cooperating PCEs. When computing or re-optimizing the routes of a set of TE LSPs through a network it may be advantageous to perform bulk path computations in order to avoid blocking problems and to achieve more optimal network-wide solutions. Such bulk optimization is termed Global Concurrent Optimization (GCO). A GCO is able to simultaneously consider the entire topology of the network and the complete set of existing TE LSPs, and their respective constraints, and look to optimize or re-optimize the entire network to satisfy all constraints for all TE LSPs. A GCO may also be applied to some subset of the TE LSPs in a network. The GCO application is primarily a Network Management System (NMS) solution. While GCO is applicable to any simultaneous request for multiple TE LSPs (for example, a request for end-to-end protection), it is not envisaged that global concurrent reoptimization would be applied in a network (such as an MPLS-TE network) that contains a very large number of very low bandwidth or zero bandwidth TE LSPs since the large scope of the problem and the small benefit of concurrent reoptimization relative to single TE LSP reoptimization is unlikely to make the process worthwhile. Further, applying global concurrent reoptimization in a network with a high rate of change of TE LSPs (churn) is not advised because of the likelihood that TE LSPs would change before they could be globally reoptimized. Global reoptimization is more applicable to stable networks such as transport networks or those with long-term TE LSP tunnels. This document provides application-specific requirements and the PCEP extensions in support of GCO applications. > Working Group Summary > Was there anything in WG process that is worth noting? For > example, was there controversy about particular points or > were there decisions where the consensus was particularly > rough? WG has good consensus with no disputes or disagreements. Concerns over the impact of this work on network stability (as a result of "churn") have been addressed with suitable text to describe the concerns and advise the operator about the risk. > Document Quality > Are there existing implementations of the protocol? Have a > significant number of vendors indicated their plan to > implement the specification? Are there any reviewers that > merit special mention as having done a thorough review, > e.g., one that resulted in important changes or a > conclusion that the document had no substantive issues? If > there was a MIB Doctor, Media Type or other expert review, > what was its course (briefly)? In the case of a Media Type > review, on what date was the request posted? There are two known implementations of the protocol extensions described in this document. _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From jenac@advancenotice.com Thu Jan 15 07:21:22 2009 Return-Path: X-Original-To: ietfarch-pce-archive@core3.amsl.com Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC4A928C256 for ; Thu, 15 Jan 2009 07:21:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.328 X-Spam-Level: X-Spam-Status: No, score=-11.328 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbbPCLV9XdHF for ; Thu, 15 Jan 2009 07:21:16 -0800 (PST) Received: from line143-240.actel.hu (line143-240.actel.hu [88.209.143.240]) by core3.amsl.com (Postfix) with SMTP id 5989E28C24D for ; Thu, 15 Jan 2009 07:21:14 -0800 (PST) To: Subject: from admin From: MIME-Version: 1.0 Importance: High Content-Type: text/html X-Antivirus: avast! (VPS 090114-0, 2009.01.14), Outbound message X-Antivirus-Status: Clean Message-Id: <20090115152115.5989E28C24D@core3.amsl.com> Date: Thu, 15 Jan 2009 07:21:14 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 13994
From pce-bounces@ietf.org Fri Jan 16 08:48:52 2009 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD79828C166; Fri, 16 Jan 2009 08:48:52 -0800 (PST) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF20928C166 for ; Fri, 16 Jan 2009 08:48:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.533 X-Spam-Level: X-Spam-Status: No, score=-10.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dPFVgLvkdEA for ; Fri, 16 Jan 2009 08:48:51 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 924E828C0F1 for ; Fri, 16 Jan 2009 08:48:50 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,277,1231113600"; d="scan'208";a="31122860" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 16 Jan 2009 16:48:34 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n0GGmYTI009687; Fri, 16 Jan 2009 17:48:34 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0GGmYnw023867; Fri, 16 Jan 2009 16:48:34 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Jan 2009 17:48:33 +0100 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Jan 2009 17:48:33 +0100 Message-Id: <5E7AF40A-13E9-452F-86AF-64B628D7D596@cisco.com> From: JP Vasseur To: pce@ietf.org, kkoushik@cisco.com, emile.stephan@orange-ftgroup.com In-Reply-To: <4BCCC444-C7D3-4F34-91E5-2B1A66DA2BB1@cisco.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 16 Jan 2009 17:48:33 +0100 References: <4BCCC444-C7D3-4F34-91E5-2B1A66DA2BB1@cisco.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 16 Jan 2009 16:48:33.0709 (UTC) FILETIME=[44D4B5D0:01C977FA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=817; t=1232124514; x=1232988514; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Pce]=20draft-kkoushik-pce-pcep-mib-02. txt=20adopted=20as=20WG=20document |Sender:=20; bh=GB8OGTVFQOd1IqwKcaezPvxjiDM9XrcQnXhsEVKWSok=; b=lWFBDcb5aIcQ851/dHa6SSl15rxlwkDVwNGEp3y0IRgd+95jocBSk93eYy nB4aR/Upvr0GOvEOuwZoeZsW/UW/aX1GMpS/img/S4q7gN7/Pz3vOac5V1CP idVYslC0mB; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: Re: [Pce] draft-kkoushik-pce-pcep-mib-02.txt adopted as WG document X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Dear WG, Since there was no discontent, the document is approved as a PCE WG. Authors, please resubmit as draft-ietf-pce-pcep-mib-00.txt (with no change others than name, dates, new boiler template, ...). Thanks. JP. On Jan 9, 2009, at 7:35 AM, JP Vasseur wrote: > Dear WG, > > As discussed during our last WG meeting, draft-kkoushik-pce-pcep- > mib-02.txt is clearly related to one of our WG item and should be > adopted as a WG document (we had the promise from their authors to > continue the work since the ID has been in a "silent" mode for a few > month). > > Let us know if you have any objection by Jan 16, noon ET. > > Thanks. > > JP. > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Mon Jan 19 01:20:54 2009 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35CA728C19C; Mon, 19 Jan 2009 01:20:54 -0800 (PST) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5916828C19C for ; Mon, 19 Jan 2009 01:20:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEOnzUXjUBjK for ; Mon, 19 Jan 2009 01:20:52 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 1B3493A6930 for ; Mon, 19 Jan 2009 01:20:45 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,288,1231113600"; d="txt'?scan'208,217";a="31230955" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 19 Jan 2009 09:20:28 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n0J9KSmY028682; Mon, 19 Jan 2009 10:20:28 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0J9KS6k024817; Mon, 19 Jan 2009 09:20:28 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jan 2009 10:20:28 +0100 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jan 2009 10:20:22 +0100 Message-Id: From: JP Vasseur To: Adrian Farrel In-Reply-To: Mime-Version: 1.0 (Apple Message framework v930.3) X-Priority: 3 Date: Mon, 19 Jan 2009 10:20:21 +0100 References: <34CD72EB03F6410D9C8BBB1C40758C86@your029b8cecfe> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 19 Jan 2009 09:20:23.0463 (UTC) FILETIME=[283C0B70:01C97A17] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=431824; t=1232356828; x=1233220828; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Pce]=20Last=20call=20comments=20on=20d raft-ietf-pce-monitoring-02.txt |Sender:=20; bh=VIn1njOcA+M18PEBAjpVGwv/XXlNiN658nl3XqkhGYo=; b=M1/dRNXYc2v6LIQP4yZqjdf85Y/vilp32vwkMcEa3nn5oYORwapuHL73mH h7mbqFxvKFGpNvWFCgWYfwRgGWsODRImXBiKusRhvAcg8nMTzXSD7Bxva+Ql mlOUYykOEX; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: pce@ietf.org Subject: Re: [Pce] Last call comments on draft-ietf-pce-monitoring-02.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0518266793==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org --===============0518266793== Content-Type: multipart/alternative; boundary=Apple-Mail-87-646551409 --Apple-Mail-87-646551409 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Adrian, Many Thanks for the review. See below. On Dec 19, 2008, at 12:01 AM, Adrian Farrel wrote: > Hi, > > A few nitty comments on this draft. > > Adrian > > === > > Abstract. Second sentence. > > "In PCE-based environments, it is thus critical..." > I don't think this follows as a conclusion from the previous > sentence. In > particular, there is no definition of a "path computation chain" and > no > explanation of the process involved in PCE that leads to the > conclusion that > certain things need to be monitored or troubleshooted. > > I suggest inserting a new second sentence to give some background. > Something > like... > > Path Computation Clients (PCCs) send computation requests to PCEs, > and these may forward the requests to and cooperate with other PCEs > forming a "path computation chain". > > You can then put in a paragraph break and continue with your text. > Added. > === > > Section 1 > > You need to expand "PCC" and "TE LSP" on first usage as the > Terminology section comes later. > Done. > === > > Section 3 > > Please include a reference to draft-farrel-rtg-common-bnf-07.txt. > At this stage you should (and can safely) make this a normative > reference. The RBNF draft will go to IETF last call in early January > and will be ahead of this draft in the processing queue. > Added. > === > > Section 3 > > s/Computation Monitoring request/Computation Monitoring Request/ > Fixed. > === > > Section 3.1 > > is shown to optionally contain the RRO. > > The text that follows refers to the ERO. > > I think the text is wrong. > Fixed. > === > > Section 3.1 > > s/metric(s)/metrics/ > Fixed > === > > Section 3.1 > > Examples 1 and 3 should also include a note that the requested > information is returned in a PCMonRep. > Indeed, the text has been expanded and clarified: "In all of the examples above, a PCRep (in-band request) or PCMonReq (out of band request) message is sent in response to the request that reports the computed metrics." > === > > Section 3.2 > > Are you sure that you want to send an Error message in response to a > bad PCMonRep? > > Sending an Error in response to a PCMonReq is useful because it > cancels the request and means the sender does not continue to wait > or a PCMonRep. But sending an Error in response to a PCMonRep does > not seem to have any use except to load the network. For example, > what is the state of the outstanding PCMonReq in this situation? > What is the sender of the PCMonRep supposed to do when it receives > the Error message? > > More appropriate would be for the receiver of the bad PCMonRep to > raise an alert to the operator and to put the sender of the bad > message on a blacklist so that it never send it another PCMonReq. > Well yes but ... error message are not only useful for the PCC to clean states but for troubleshooting on both sides, especially on the PCC side where the absence of reply can either be interpreted as a lost request, overloaded PCE, malformed request, .... Furthermore, it is inline with the general approach taken by PCEP when a message is received that does not carry a mandatory object. Fair enough ? > === > > Section 3.2 > > It would be useful to include references for the objects listed in > the BNF as you do in Section 3.1. > Text added. > === > > Section 3.2 > > I'm slightly confused by the BNF. > > ::=[] > [] > [] > > This means that can be completely empty. > Surely is mandatory within ? oops ! [] removed, thanks. It should read ::=. It would not help not knowing which PCE the metrics apply to ;-) > > > === > > Section 4 > > You state that the P and I flags in the new objects are cleared. > > I think you mean "SHOULD be set to zero and MUST be ignored" Yes, fixed. > > > === > > Section 4 > Second paragraph. > > The case of "in band" monitoring seems to be described twice. > Fixed. > === > > Section 4.2 > > The object has previously been referred to as the PCE-ID object. > That seems like a better name. Can you check the whole I-D to make > sure this is consistent. > Fixed: PCE-ID used everywhere. > === > > Section 4.3 > > If allowed by policy, the PCE includes a PROC-TIME object within a > PCMonRep or a PCRep message if the P bit of the MONITORING object > > This conflicts with Section 4.1 > > P (Processing Time) - 1 bit: the P bit of the MONITORING object > carried in a PCMonReq or a PCReq message is set to indicate that the > processing times is a metric of interest, in which case a PROC-TIME > object MUST be inserted in the corresponding PCMonRep or PCRep > message. > > I prefer the "if allowed by policy" which means you need to change > the text Section 4.1. > Right new text: P (Processing Time) - 1 bit: the P bit of the MONITORING object carried in a PCMonReq or a PCReq message is set to indicate that the processing times is a metric of interest. If allowed by policy, a PROC- TIME object MUST be inserted in the corresponding PCMonRep or PCRep message. The P bit MUST always be ignored in a PCMonRep or PCRep message. > === > > Section 4.3 > s/algorithm(s)/algorithms/ (twice) > Fixed. > === > > Section 4.3 > > Flags: 18 bits - No Flags are currently defined: > > Looks like 16 bits, and one flag is defined! > fixed, thanks. > === > > Section 4.3 > s/computation(s)/computations/ > Fixed > === > > Section 4.3 > > Unassigned bits are considered as reserved and MUST be set to zero on > transmission. > > Move this text to immediately after the definition of the E bit > Done. > === > > Section 4.3 > > More granularity may be introduced in further revision of this > document to get a monitoring metric for a general request of a > particular class (e.g. all PCReq of priority X). > > I guess you decided not to do this. Delete the text. Deleted. > > > === > > Section 4.4 > > - Rather than one bit and a reserved field, shouldn't you have a > flags field (with one bit assigned) and a reserved field. Yes, Flag field is now 8 bits (one allocated) + Reserved (8bits) + Congestion duration field (16 bits) > > - You need to explain that setting the C bit and a congestion > duration of zero has meaning. If it has no meaning, you don't > need the C bit. It is stated in the text: "When cleared this indicates that the PCE is not congested and the "Congestion Duration" field MUST be set to 0x0000". C=0 means "no congestion on the PCE". > > - Although it verges on telling the implementer how to write code > I think some advice is needed on what to do when a > CONGESTION object is received with the C bit set. There > are two aspects... > - How long has the CONGESTION object taken to propagate > from the reporting PCE to the PCC (might not be one hop)? > - What should the receiver do with the Congestion Duration > value? You already know what I think about this ;-))) It is in my opinion very much implementation dependent, don't you think ? First of all, specifying what the PCC should be in this document is a bit awkward. Indeed, it could be for pure management purposes (out of band) or in the context of a particular path computation request (e.g. after a PCreq local timeout). Even in that latter case, the PCC may decide to back-off and retry or select another PCE, depending on the urgency of the request which is usually context dependent (the PCC may decide to select another PCE for an already retransmitted request if the priority is > X, ....). Furthermore the PCC may also be a function of the reported congestion value, ... I would argue that documenting this behavior is out of scope (not a monitoring issue) and very much implementation/application specific. > > - It may also be worth noting whether a PCE in the middle of a > chain is allowed to look at the CONGESTION information > that it receives from a downstream PCE and plans to pass on > to an upstream PCE or PCC. Interesting observation. Text added: "It is worth noting that a PCE along a PCE chain involved in the monitoring request may decide to learn from the congestion information received by one of downstream PCE in the chain." > > > === > > Section 6 > > Reception of a PCMonReq message: upon receiving a PCMonReq message: > > Can you sort out the over-use of colons? Fixed: "Upon receiving a PCMonReq message:" > > > === > > Section 6, case 1) > > I think you should refer explicitly to Section 6.9 of [PCEP] because > that includes not only the error message, but some important back- > off and shutdown procedures. > 100% agree, very good catch, thanks. OLD: 1) As specified in [I-D.ietf-pce-pcep], if the PCE does not support the PCMonReq message, the PCE peer must send a PCErr message with Error-value=2 (capability not supported). NEW: 1) As specified in [I-D.ietf-pce-pcep], if the PCE does not support the PCMonReq message, the PCE peer MUST send a PCErr message with Error-value=2 (capability not supported). According to the procedure defined in section 6.9 of [I-D.ietf-pce-pcep], if a PCC/PCE receives unrecognized messages at a rate equal of greater than specified rate, the PCC/ PCE must send a PCEP CLOSE message with close value="Reception of an unacceptable number of unknown PCEP message. In this case, the PCC/PCE must also close the TCP session and must not send any further PCEP messages on the PCEP session. Note that we may want to also use this procedure to handle DoS attacks. More below. > === > > Section 6, case 2) > > You should refer back to Section 5. Yes. > > But note also that you have an explicit case (section 4.3) where > policy causes the message to be processed but an object to be left > out of the reply. > Not sure to see which case you're referring to ? > === > > Section 6 > > You need a similar set of text for the in band case. > Right, text added: Upon receiving a PCReq message that carries a MONITORING and potentially other monitoring objects (e.g. PCE-ID object): 1) As specified in [I-D.ietf-pce-pcep], if the PCE does not support (in band) monitoring, the PCE peer MUST send a PCErr message with Error-value=2 (capability not supported). According to the procedure defined in section 6.9 of [I-D.ietf-pce-pcep], if a PCC/PCE receives unrecognized messages at a rate equal of greater than specified rate, the PCC/PCE must send a PCEP CLOSE message with close value="Reception of an unacceptable number of unknown PCEP message. In this case, the PCC/PCE must also close the TCP session and must not send any further PCEP messages on the PCEP session. 2) If the PCE supports the monitoring request but the monitoring request is prohibited by policy, the PCE must follow the procedure specified in section 5. 3) If the PCE supports the monitoring request and that request is not prohibited by policy, the receiving PCE MUST first determine whether it is the last PCE of the path computation chain. If the PCE is not the last element of the path computation chain, the PCReq message (with the MONITORING object and potentially other monitoring objects such as the PCE-ID) is relayed to the next hop PCE: such next-hop may either be specified by means of a PCE-ID object present in the PCReq message or dynamically determined by means of a procedure outside of the scope of this document. Conversely, if the PCE is the last PCE of the path computation chain, the PCE originates a PCRep message that contains the requested objects according to the set of requested PCE states metrics listed in the MONITORING and potentially other monitoring objects carried in the corresponding PCReq message. + Upon receiving a PCRep message that carrries monitoring data, the message is processed, additional monitoring data is added according to this specification and the message is forwarded upstream to the requesting PCE or PCC. > === > > Section 7.2 > s/MAY/may/ > fixed > === > > Section 7.6 > > An implementation SHOULD allow handling PCReq messages with > a higher priority than PCMonReq messages. > > And when the monitoring is in band? > Yes, text added "An implementation SHOULD allow the configuration of a second limit for the PCReq message requesting monitoring data. " > === > > Section 8 > > It would be helpful to IANA if you split this into subsections for > each registry/subregistry. > Also nice if you could try to cut and paste from the registry naming > used in [PCEP]. > Done. > === > > Section 8 > > The IANA section doesn't seem to be complete. > > For example: > - The flags field in the Monitoring Object > (be careful to get the bit numbering correct :-) > - The flags field in the PROC-TIME object > - The flags field in the CONGESTION object > Yes ! Text Added. > === > > Section 9 > > Does the information gathered by monitoring represent any additional > vulnerability? Could an attacker gain interesting information by > snooping this? > > I think the Congestion object is a good and lightweight way to > attack a PCE deployment. Yes indeed but similarly to regular PCReq messages for which we have suggested security mechanism. > You should note this and suggest that this makes the use of security > mechanisms important. You may also need to node that there is a > chain of trust model here such that even if one PCE ensures that it > uses security, the information it supplies can be changed on a hop > further upstream. Therefore, a consistent security model across all > cooperating PCEs is desirable. Right but again this is true for regular PCRep message. Text Added (let me know if you think that this is sufficient): 9. Security Considerations The use of monitoring data can be used for various attacks such as denail of service attacks (for example by setting the C bit and congestion during field of the CONGESTION object to stop PCCs from using a PCE). Thus it is recommended to make use of the security mechanisms discussed in [I-D.ietf-pce-pcep] to secure a PCEP session (authenticity, integrity, privacy, DoS protection, etc) to secure the PCMonReq, PCMonRep messages and PCE state metric objects defined in this document. An implementation SHOULD allow limiting the rate at which PCMonReq or PCReq messages carrying monitoring requests received from a specific peer are processed (input shapping), or from another domain (see also section 7.6). > > > === > > Section 11.2 > > [I-D.ietf-pce-disco-proto-isis] is not referenced (did you run I-D > nits?) Reference deleted. > > > [I-D.ietf-pce-of] and [I-D.ietf-pce-pcep-xro] are normative since > they define objects that you cite explicitly. > > Diffs Attached. New Boiler template not yet included. Many Thanks. JP. > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce --Apple-Mail-87-646551409 Content-Type: multipart/mixed; boundary=Apple-Mail-88-646551410 --Apple-Mail-88-646551410 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi = Adrian,

Many Thanks for the review. See = below.

On Dec 19, 2008, at 12:01 AM, Adrian = Farrel wrote:

Hi,

A few nitty comments on this = draft.

Adrian

=3D=3D=3D

Abstract. Second = sentence.

"In PCE-based environments, it is thus = critical..."
I don't think this follows as a conclusion from the = previous sentence. In
particular, there is no definition of a "path = computation chain" and no
explanation of the process involved in PCE = that leads to the conclusion that
certain things need to be monitored = or troubleshooted.

I suggest inserting a new second sentence to = give some background. Something
like...

 Path = Computation Clients (PCCs) send computation requests to PCEs,
=  and these may forward the requests to and cooperate with other = PCEs
 forming a "path computation chain".

You can then = put in a paragraph break and continue with your = text.


Added.

=3D=3D=3D

Section 1

You need to = expand "PCC" and "TE LSP" on first usage as the Terminology section = comes = later.


Done.

=3D=3D=3D

Section 3

Please = include a reference to draft-farrel-rtg-common-bnf-07.txt.
At this = stage you should (and can safely) make this a normative reference. The = RBNF draft will go to IETF last call in early January and will be ahead = of this draft in the processing = queue.


Added.

=3D=3D=3D

Section = 3

s/Computation Monitoring request/Computation Monitoring = Request/


Fixed.

=3D=3D=3D

Section = 3.1

<request> is shown to optionally contain the = RRO.

The text that follows refers to the ERO.

I think the = text is = wrong.


Fixed.

=3D=3D=3D

Section = 3.1

s/metric(s)/metrics/


<= div>Fixed

=3D=3D=3D

Section= 3.1

Examples 1 and 3 should also include a note that the = requested information is returned in a = PCMonRep.


Indeed, the text = has been expanded and clarified: "In all of the examples above, a PCRep = (in-band request) or PCMonReq (out of band request) message is sent in = response to the request that reports the computed = metrics."

=3D=3D=3D

Section 3.2

Are you sure that = you want to send an Error message in response to a bad = PCMonRep?

Sending an Error in response to a PCMonReq is useful = because it cancels the request and means the sender does not continue to = wait or a PCMonRep. But sending an Error in response to a PCMonRep does = not seem to have any use except to load the network. For example, what = is the state of the outstanding PCMonReq in this situation? What is the = sender of the PCMonRep supposed to do when it receives the Error = message?

More appropriate would be for the receiver of the bad = PCMonRep to raise an alert to the operator and to put the sender of the = bad message on a blacklist so that it never send it another = PCMonReq.


Well yes but ... = error message are not only useful for the PCC to clean states but for = troubleshooting on both sides, especially on the PCC side where the = absence of reply can either be interpreted as a lost request, overloaded = PCE, malformed request, .... Furthermore, it is inline with the general = approach taken by PCEP when a message is received that does not carry a = mandatory object.

Fair enough = ?

=3D=3D=3D

Sect= ion 3.2

It would be useful to include references for the objects = listed in the BNF as you do in Section = 3.1.


Text = added.

=3D=3D=3D

Section = 3.2

I'm slightly confused by the BNF.

=  <metric-pce>::=3D[<PCE-ID>]
=             &n= bsp;   [<PROC-TIME>]
=             &n= bsp;   [<CONGESTION>]

This means that = <metric-pce> can be completely empty.
Surely <PCE-ID> is = mandatory within <metric-pce> = ?

oops ! [] removed, thanks. It = should = read

<metric-pce>::=3D<PCE-ID>.
<= br>
It would not help not knowing which PCE the metrics apply = to ;-)



=3D=3D=3D

Se= ction 4

You state that the P and I flags in the new objects are = cleared.

I think you mean "SHOULD be set to zero and MUST be = ignored"

Yes, = fixed.



=3D=3D=3D

Se= ction 4
Second paragraph.

The case of "in band" monitoring = seems to be described = twice.


Fixed.

=3D=3D=3D

Section 4.2

The object = has previously been referred to as the PCE-ID object. That seems like a = better name. Can you check the whole I-D to make sure this is = consistent.


Fixed: PCE-ID = used everywhere.

=3D=3D=3D

Section 4.3

 If allowed = by policy, the PCE includes a PROC-TIME object within a
=  PCMonRep or a PCRep message if the P bit of the MONITORING = object

This conflicts with Section 4.1

 P = (Processing Time) - 1 bit: the P bit of the MONITORING object
=  carried in a PCMonReq or a PCReq message is set to indicate that = the
 processing times is a metric of interest, in which case a = PROC-TIME
 object MUST be inserted in the corresponding = PCMonRep or PCRep
 message.

I prefer the "if allowed by = policy" which means you need to change the text Section = 4.1.


Right new = text:

P (Processing Time) - 1 bit: the P bit of = the MONITORING object carried in a PCMonReq or a PCReq message is set to = indicate that the processing times is a metric of interest. If allowed = by policy, a PROC-TIME object MUST be inserted in the corresponding = PCMonRep or PCRep message. The P bit MUST always be ignored in a = PCMonRep or PCRep message.

=3D=3D=3D

Section = 4.3
s/algorithm(s)/algorithms/ =  (twice)


Fixed.
=3D=3D=3D

Section 4.3

=  Flags: 18 bits - No Flags are currently defined:

Looks like = 16 bits, and one flag is = defined!


fixed, = thanks.

=3D=3D=3D

Section = 4.3
s/computation(s)/computations/


<= /div>
Fixed

=3D=3D=3D

S= ection 4.3

 Unassigned bits are considered as reserved and = MUST be set to zero on
 transmission.

Move this text to = immediately after the definition of the E = bit


Done.

=3D=3D=3D

Section 4.3

 More = granularity may be introduced in further revision of this
=  document to get a monitoring metric for a general request of a
=  particular class (e.g. all PCReq of priority X).

I guess = you decided not to do this. Delete the = text.

Deleted.



=3D=3D=3D

Section 4.4

- Rather = than one bit and a reserved field, shouldn't you have a
flags field = (with one bit assigned) and a reserved = field.

Yes, Flag field is now 8 = bits (one allocated) + Reserved (8bits) + Congestion duration field (16 = bits)


- You need to explain = that setting the C bit and a congestion
 duration of zero has = meaning. If it has no meaning, you don't
 need the C = bit.

It is stated in the text: = "When cleared this indicates that the PCE is not congested and the = "Congestion Duration" field MUST be set to 0x0000".
C=3D0 = means "no congestion on the PCE".


- Although it verges on telling the implementer = how to write code
I think some advice is needed on what to do when = a
CONGESTION object is received with the C bit set. There
are = two aspects...
- How long has the CONGESTION object taken to = propagate
   from the reporting PCE to the PCC (might = not be one hop)?
- What should the receiver do with the Congestion = Duration
=    value?

You = already know what I think about this ;-))) It is in my opinion very much = implementation dependent, don't you think ?
First of all, = specifying what the PCC should be in this document is a bit awkward. = Indeed, it could be for pure management
purposes (out of band) = or in the context of a particular path computation request (e.g. after a = PCreq local timeout). Even
in that latter case, the PCC may = decide to back-off and retry or select another PCE, depending on the = urgency of the request
which is usually context dependent (the = PCC may decide to select another PCE for an already retransmitted = request if the
priority is > X, ....). Furthermore the PCC may = also be a function of the reported congestion value, = ...

I would argue that documenting this = behavior is out of scope (not a monitoring issue) and very much = implementation/application specific.


- It may also be worth noting whether a PCE in = the middle of a
 chain is allowed to look at the CONGESTION = information
 that it receives from a downstream PCE and plans = to pass on
 to an upstream PCE or = PCC.

Interesting observation. Text = added:

"It is worth noting that a PCE along a = PCE chain involved in the monitoring request may decide to learn from = the congestion information received by one of downstream PCE in the = chain."



=3D=3D=3D

S= ection 6

 Reception of a PCMonReq message: upon receiving a = PCMonReq message:

Can you sort out the over-use of = colons?

Fixed: "Upon receiving a = PCMonReq message:"



=3D=3D=3D

Section 6, case 1)

I = think you should refer explicitly to Section 6.9 of [PCEP] because that = includes not only the error message, but some important back-off and = shutdown procedures.


100% = agree, very good catch, = thanks.

OLD:

1) As specified in = [I-D.ietf-pce-pcep], if the PCE does not support the PCMonReq message, the PCE peer must send a PCErr message with Error-value=3D2 (capability not supported).
NEW:
1) As specified in =
[I-D.ietf-pce-pcep], if the PCE does not support
   the PCMonReq message, the PCE peer MUST send a PCErr message with
   Error-value=3D2 (capability not supported). According to the =
procedure 
   defined in section 6.9 of =
[I-D.ietf-pce-pcep], if a PCC/PCE receives =
unrecognized 
   messages at a rate equal of greater than =
specified rate, the PCC/PCE must send a 
   PCEP CLOSE =
message with close value=3D"Reception of an unacceptable number =
of 
   unknown PCEP message. In this case, the =
PCC/PCE must also close the TCP session 
   and must not =
send any further PCEP messages on the PCEP =
session.

= Note that we may want to also use this procedure to handle DoS attacks. = More below.

=3D=3D=3D

Secti= on 6, case 2)

You should refer back to Section = 5.

Yes.


But note also that you have an explicit case = (section 4.3) where policy causes the message to be processed but an = object to be left out of the = reply.


Not sure to see = which case you're referring to ?

=3D=3D=3D

Section 6

You need a similar = set of text for the in band = case.


Right, text = added:

 Upon receiving a PCReq message that carries =
a MONITORING and
   potentially other monitoring objects (e.g.  PCE-ID object):

   1) As specified in [I-D.ietf-pce-pcep], if the PCE does not support
   (in band) monitoring, the PCE peer MUST send a PCErr message with
   Error-value=3D2 (capability not supported).  According to the =
procedure
   defined in section 6.9 of [I-D.ietf-pce-pcep], if a PCC/PCE receives
   unrecognized messages at a rate equal of greater than specified rate,
   the PCC/PCE must send a PCEP CLOSE message with close
   value=3D"Reception of an unacceptable number of unknown PCEP message.
   In this case, the PCC/PCE must also close the TCP session and must
   not send any further PCEP messages on the PCEP session.

   2) If the PCE supports the monitoring request but the monitoring
   request is prohibited by policy, the PCE must follow the procedure
   specified in section 5.

   3) If the PCE supports the monitoring request and that request is not
   prohibited by policy, the receiving PCE MUST first determine whether
   it is the last PCE of the path computation chain.  If the PCE is not
   the last element of the path computation chain, the PCReq message
   (with the MONITORING object and potentially other monitoring objects
   such as the PCE-ID) is relayed to the next hop PCE: such next-hop may
   either be specified by means of a PCE-ID object present in the PCReq
   message or dynamically determined by means of a procedure outside of
   the scope of this document.  Conversely, if the PCE is the last PCE
   of the path computation chain, the PCE originates a PCRep message
   that contains the requested objects according to the set of requested
   PCE states metrics listed in the MONITORING and potentially other
   monitoring objects carried in the corresponding PCReq message.

+

Upon receiving a PCRep message that carrries =
monitoring data, the
   message is processed, additional monitoring data is added according
   to this specification and the message is forwarded upstream to the
   requesting PCE or =
PCC.

=3D=3D=3D

Section = 7.2
s/MAY/may/


fixed
=3D=3D=3D

Section 7.6

=  An implementation SHOULD allow handling PCReq messages with
=  a higher priority than PCMonReq messages.

And when the = monitoring is in = band?


Yes, text added "An = implementation SHOULD allow the configuration of a second limit for the = PCReq message requesting monitoring data. = "

=3D=3D=3D

Sect= ion 8

It would be helpful to IANA if you split this into = subsections for each registry/subregistry.
Also nice if you could try = to cut and paste from the registry naming used in = [PCEP].


Done.

=3D=3D=3D

Section 8

The IANA = section doesn't seem to be complete.

For example:
- The flags = field in the Monitoring Object
 (be careful to get the bit = numbering correct :-)
- The flags field in the PROC-TIME object
- = The flags field in the CONGESTION = object


Yes ! Text = Added.

=3D=3D=3D

Section = 9

Does the information gathered by monitoring represent any = additional vulnerability? Could an attacker gain interesting information = by snooping this?

I think the Congestion object is a good and = lightweight way to attack a PCE deployment. =

Yes indeed but similarly to = regular PCReq messages for which we have suggested security = mechanism.

You should note this = and suggest that this makes the use of security mechanisms important. = You may also need to node that there is a chain of trust model here such = that even if one PCE ensures that it uses security, the information it = supplies can be changed on a hop further upstream. Therefore, a = consistent security model across all cooperating PCEs is = desirable.

Right but again this is = true for regular PCRep message.

Text Added (let = me know if you think that this is = sufficient):

9.  Security Considerations

   The use of monitoring data can be used for various attacks such as
   denail of service attacks (for example by setting the C bit and
   congestion during field of the CONGESTION object to stop PCCs from
   using a PCE).  Thus it is recommended to make use of the security
   mechanisms discussed in [I-D.ietf-pce-pcep] to secure a PCEP session
   (authenticity, integrity, privacy, DoS protection, etc) to secure the
   PCMonReq, PCMonRep messages and PCE state metric objects defined in
   this document.  An implementation SHOULD allow limiting the rate at
   which PCMonReq or PCReq messages carrying monitoring requests
   received from a specific peer are processed (input shapping), or from
   another domain (see also section =
7.6).



=3D=3D=3D

Section = 11.2

[I-D.ietf-pce-disco-proto-isis] is not referenced (did you = run I-D nits?)

Reference = deleted.



[I-D.ietf-pce-of]= and [I-D.ietf-pce-pcep-xro] are normative since they define objects = that you cite = explicitly.




Diffs Attached. New Boiler template not yet = included. 
= --Apple-Mail-88-646551410 Content-Disposition: attachment; filename=draft-ietf-pce-monitoring-04.txt Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-pce-monitoring-04.txt" Content-Transfer-Encoding: quoted-printable Networking Working Group JP. Vasseur, Ed. Internet-Draft Cisco Systems, Inc Intended status: Standards Track JL. Le Roux Expires: July 12, 2009 France Telecom Y. Ikejiri NTT Communications Corporation January 8, 2009 A set of monitoring tools for Path Computation Element based Architecture draft-ietf-pce-monitoring-04.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 12, 2009. Abstract A Path Computation Element (PCE) based architecture has been specified for the computation of Traffic Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks in the context of single or multiple domains (where a domain refers to a collection of network elements within a common sphere of address management or path computational responsibility such as IGP areas and Autonomous Systems). Path Computation Clients (PCCs) send computation requests Vasseur, et al. Expires July 12, 2009 [Page 1] =0C Internet-Draft draft-ietf-pce-monitoring-04.txt January 2009 to PCEs, and these may forward the requests to and cooperate with other PCEs forming a "path computation chain". In PCE-based environments, it is thus critical to monitor the state of the path computation chain for troubleshooting and performance monitoring purposes: liveness of each element (PCE) involved in the PCE chain, detection of potential resource contention states and statistics in term of path computation times are examples of such metrics of interest. This document specifies procedures and extensions to the Path Computation Element Protocol (PCEP) in order to gather such information. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Vasseur, et al. Expires July 12, 2009 [Page 2] =0C Internet-Draft draft-ietf-pce-monitoring-04.txt January 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Path Computation Monitoring messages . . . . . . . . . . . . . 5 3.1. Path Computation Monitoring Request message (PCMonReq) . . 6 3.2. Path Monitoring Reply message (PCMonRep) . . . . . . . . . 9 4. Path Computation Monitoring Objects . . . . . . . . . . . . . 12 4.1. MONITORING Object . . . . . . . . . . . . . . . . . . . . 12 4.2. PCE-ID Object . . . . . . . . . . . . . . . . . . . . . . 14 4.3. PROC-TIME Object . . . . . . . . . . . . . . . . . . . . . 15 4.4. CONGESTION Object . . . . . . . . . . . . . . . . . . . . 17 5. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 18 7. Manageability Considerations . . . . . . . . . . . . . . . . . 20 7.1. Control of Function and Policy . . . . . . . . . . . . . . 20 7.2. Information and Data Models . . . . . . . . . . . . . . . 20 7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 20 7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 20 7.5. Requirements On Other Protocols . . . . . . . . . . . . . 20 7.6. Impact On Network Operations . . . . . . . . . . . . . . . 20 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 8.1. New PCEP Message . . . . . . . . . . . . . . . . . . . . . 21 8.2. New PCEP Objects . . . . . . . . . . . . . . . . . . . . . 21 8.3. New Error-Type and Error-Values . . . . . . . . . . . . . 21 8.4. MONITORING Object Flag Field . . . . . . . . . . . . . . . 22 8.5. PROC-TIME Object Flag Field . . . . . . . . . . . . . . . 22 8.6. CONGESTION Object Flag field . . . . . . . . . . . . . . . 23 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 11.1. Normative References . . . . . . . . . . . . . . . . . . . 24 11.2. Informative References . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . . . . 26 Vasseur, et al. Expires July 12, 2009 [Page 3] =0C Internet-Draft draft-ietf-pce-monitoring-04.txt January 2009 1. Introduction The Path Computation Element (PCE) based architecture has been specified in [RFC4655] for the computation of Traffic Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks in the context of single or multiple domains where a domain refers to a collection of network elements within a common sphere of address management or path computational responsibility such as IGP areas and Autonomous Systems. Path Computation Clients (PCCs) send computation requests to PCEs, and these may forward the requests to and cooperate with other PCEs forming a "path computation chain". In PCE-based environments, it is critical to monitor the state of the path computation chain for troubeshooting and performance monitoring purposes: liveness of each element (PCE) involved in the PCE chain, detection of potential resource contention states and statistics in term of path computation times are examples of such metrics of interest. This document specifies procedures and extensions to the Path Computation Element Protocol (PCEP) ([I-D.ietf-pce-pcep]) in order to monitor the path computation chain and gather various performance metrics. As defined in [RFC4655], there are circumstances where more than one PCE is involved in the computation of a TE LSP. A typical example is when the PCC requires the computation of a TE LSP where the head-end and the tail-end of the TE LSP do not reside in adjacent domains and there is no single PCE with the visibility of both the head-end and tail-end domain. We call the set of PCEs involved in the computation of a TE LSP a "path computation chain". As further discussed in Section 3.1, the PCE chain may either be static (pre-configured) or dynamically determined during the path computation process. As discussed in [RFC4655], a TE LSP may be computed by one PCE (referred to as single PCE path computation) or several PCEs (referred to as multiple PCE path computation). In the former case, the PCC may be able to use IGP extensions to check the liveness of the PCE (see [RFC5088] and [RFC5089]) or PCEP using Keepalive messages. In contrast, when multiple PCEs are involved in the path computation chain an example of which is the BRPC procedure defined in [I-D.ietf-pce-brpc], the PCC's visibility may be limited to the first PCE involved in the path computation chain. Thus, it is critical to define mechanisms in order to monitor the state of the path computation chain. This document specifies PCEP extensions in order to gather various state metrics along the path computation chain. In this document we call a "state metric" a metric that characterizes a PCE state. For Vasseur, et al. Expires July 12, 2009 [Page 4] =0C Internet-Draft draft-ietf-pce-monitoring-04.txt January 2009 example, such metric can have a form of a bolean (PCE is alive or not, PCE is congested or not) or a performance metric (path computation time at each PCE). PCE state metrics can be gathered in two different contexts: in band or out of band. By "In band" we refer to the situation whereby a PCC requests to gather metrics in the context of a path computation request. For example, a PCC may send a path computation request to a PCE and may want to know the processing time of that request in addition to the computed path. Conversely, if the request is "out of band", PCE state metric collection is performed as a standalone request (e.g. check the liveness of a specific PCE chain, collect the average processing time computed over the last 5mn period on one or more PCEs"). In this document we define two monitoring request types: general and specific. A general monitoring request relates to the collection of a PCE state metrics that is not coupled to a particular path computation request (e.g. average CPU load on a PCE). Conversely, a specific monitoring request relates to a particular path computation request (processing time to complete the path computation for a TE LSP). The message formats in this document are specified using Backus Naur Format (BNF) encoding as specified in [I-D.farrel-rtg-common-bnf]. 2. Terminology PCC (Path Computation Client): any client application requesting a path computation to be performed by a Path Computation Element. PCE (Path Computation Element): an entity (component, application or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints. TE LSP: Traffic Engineering Label Switched Path. 3. Path Computation Monitoring messages As defined in [I-D.ietf-pce-pcep], a PCEP message consists of a common header followed by a variable length body made of a set of objects that can either be mandatory or optional. As a reminder, an object is said to be mandatory in a PCEP message when the object must be included for the message to be considered as valid. The P flag (defined in [I-D.ietf-pce-pcep]) is located in the common header of each PCEP object and can be set by a PCEP peer to require a PCE to Vasseur, et al. Expires July 12, 2009 [Page 5] =0C Internet-Draft draft-ietf-pce-monitoring-04.txt January 2009 take into account the related information during the path computation. Because the P flag exclusively relates to a path computation request, it MUST be cleared in the two PCEP messages (PCEMonReq and PCMonRep message) defined in this document. For each PCEP message type a set of rules is defined that specify the set of objects that the message can carry. An implementation MUST form the PCEP messages using the object ordering specified in this document. In this document we define two PCEP messages referred to as the Path Computation Monitoring Request (PCMonReq) and Path Computation Monitoring Reply (PCMonRep) messages so as to handle "out of band" monitoring request. The aim of the PCMonReq message sent by a PCC to a PCE is to gather one or more PCE state metrics on a set of PCEs involved in a path computation chain. The PCMonRep message sent by a PCE to a PCC is used to provide such data. 3.1. Path Computation Monitoring Request message (PCMonReq) The Message-Type field of the PCEP common header for the PCMonReq message is set to 8 (To be confirmed by IANA). There is one mandatory object that MUST be included within a PCMonReq message: the MONITORING object (see section Section 4.1). If the MONITORING object is missing, the receiving PCE MUST send a PCErr message with Error-type=3D6 (Mandatory Object missing) and Error- value=3D4 (MONITORING Object missing). Other objects are optional. Vasseur, et al. Expires July 12, 2009 [Page 6] =0C Internet-Draft draft-ietf-pce-monitoring-04.txt January 2009 Format of a PCMonReq message (out of band request): ::=3D [] [] [] where: ::=3D [] [] ::=3D[] ::=3D [] [] [] [] [] [] [] ::=3D[] ::=3D[] Vasseur, et al. Expires July 12, 2009 [Page 7] =0C Internet-Draft draft-ietf-pce-monitoring-04.txt January 2009 Format of a PCReq message with monitoring data requested (in band request): ::=3D [] [] where: ::=3D[] ::=3D[] ::=3D [] [] [] [[]] [] [] where: ::=3D[] ::=3D[] The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, METRIC, RRO, IRO and LOAD- BALANCING objects are defined in [I-D.ietf-pce-pcep]. The XRO object is defined in [I-D.ietf-pce-pcep-xro] and the OF object is defined in [I-D.ietf-pce-of]. The PCMonReq message is used to gather various PCE state metrics along a path computation chain. The path computation chain may be determined by the PCC (in the form of a series of a series of PCE-ID objects defined in Section 4.2.) or may alternatively be determined by the path computation procedure. For example, if the BRPC procedure ([I-D.ietf-pce-brpc]) is used to compute an inter-domain TE LSP, the PCE chain may be determined dynamically. In that case, the PCC sends a PCMonReq message that contains the PCEP objects that charaterize the TE LSP attributes along with the MONITORING object (see Section 4.1) that lists the set of metrics of interest. Several PCE state metrics may be requested that are specified by a set of objects defined in Section 4. Note that this set of objects may be extended in the future. For the sake of illustration, consider the three following examples: Vasseur, et al. Expires July 12, 2009 [Page 8] =0C Internet-Draft draft-ietf-pce-monitoring-04.txt January 2009 Example 1 (out of band request): PCC1 requests to check the path computation chain that would be used should it request a path computation for a specific TE LSP named T1. A PCMonReq message is sent that contains a MONITORING object specifying a path computation check, along with the appropriate set of objects (e.g. RP, END- POINTS, ...) that would be included in a PCReq message for T1. Example 2 (in band request): PCC1 requests a path computation for a TE LSP and also request to gather the processing time along the path computation chain selected for the computation of T1. A PCReq message is sent that also contains a MONITORING object that specifies the performance metrics of interest. Example 3 (out of band request): PCC2 requests to gather performance metrics along the specific path computation chain . A PCMonreq message is sent to PCE1 that contains a MONITORING object and a sequence of PCE-ID objects that identify PCE1, PCE2, PCE3 and PCE7 respectively. In all of the examples above, a PCRep message (in-band request) or PCMonReq message (out of band request) is sent in response to the request that reports the computed metrics. 3.2. Path Monitoring Reply message (PCMonRep) The PCMonRep message is used to provide PCE state metrics back to the requester for "out of band" monitoring requests. The Message-Type field of the PCEP common header for the PCMonRep message is set to 9 (To be confirmed by IANA). There is one mandatory object that MUST be included within a PCMonRep message: the MONITORING object (see Section 4.1). If the MONITORING object is missing, the receiving PCE MUST send a PCErr message with Error-type=3D6 (Mandatory Object missing) and Error-value=3D4 = (MONITORING Object missing). Other objects are optional. Vasseur, et al. Expires July 12, 2009 [Page 9] =0C Internet-Draft draft-ietf-pce-monitoring-04.txt January 2009 Format of a PCMonReq (out of band request): ::=3D [] [] where: ::=3D[] ::=3D [] [] Vasseur, et al. Expires July 12, 2009 [Page 10] =0C Internet-Draft draft-ietf-pce-monitoring-04.txt January 2009 Format of a PCRep message with monitoring data (in band): ::=3D where: ::=3D[] ::=3D [] [] [] [] ::=3D[] ::=3D where: ::=3D[] [] [] [] ::=3D[] ::=3D[] ::=3D [] [] The RP object is defined in [I-D.ietf-pce-pcep]. As pointed out in [I-D.ietf-pce-pcep] several situation can arise: o Bundle of a set of independent and non-synchronized path computation requests o Bundle of a set of independent and synchronized path computation requests (SVEC object defined below required), o Bundle of a set of dependent and synchronized path computation requests (SVEC object defined below required) Vasseur, et al. Expires July 12, 2009 [Page 11] =0C Internet-Draft draft-ietf-pce-monitoring-04.txt January 2009 In the case of a bundle of a set of request, the MONITORING object SHOULD only be present in the first PCReq or PCMonReq message and the monitoring request applies to all the request of the bundle, even in the case of dependent and/or synchronized requests sent using more than one PCReq or PCMonReq message. 4. Path Computation Monitoring Objects The PCEP objects defined in the document are compliant with the PCEP object format defined in [I-D.ietf-pce-pcep]. The P flag and the I flag of the PCEP objects defined in this document SHOULD always be set to 0 on transmission and MUST be ignored on receipt since these flags are exclusively related to path computation requests. Several objects are defined in this section that can be carried within the PCEP PCReq or PCRep messages defined in [I-D.ietf-pce-pcep] in case of "in band" monitoring requests (the PCC requests the computation of the TE LSP in addition to gathering PCE state metrics). In case of "out of band" monitoring requests, the objects defined in this section are carried within PCMonReq and PCMonRep messages. 4.1. MONITORING Object The MONITORING object MUST be present within PCMonReq and PCMonRep messages ("out of band" monitoring requests) and MAY be carried within PCRep and PCReq messages ("in band" monitoring requests). There SHOULD NOT be more than one instance of the MONITORING object: if more than one instance of the MONITORING object is present, the recipient MUST process the first instance and MUST ignore other instances. The MONITORING object is used to specify the set of requested PCE state metrics. The MONITORING Object-Class is to be assigned by IANA (recommended value=3D19) The MONITORING Object-Type is to be assigned by IANA (recommended value=3D1) Vasseur, et al. Expires July 12, 2009 [Page 12] =0C Internet-Draft draft-ietf-pce-monitoring-04.txt January 2009 The format of the MONITORING object body is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Flags |I|C|P|G|L| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Monitoring-id-number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Optional TLV(s) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flags: 24 bits The following flags are currently defined: L (Liveness) - 1 bit: when set, this indicates that the state metric of interest is the PCE's liveness and thus the PCE MUST include a PCE-ID object in the corresponding reply. The L bit MUST always be ignored in a PCMonRep or PCRep message. G (General) - 1 bit: when set, this indicates that the monitoring request is a general monitoring request. When the requested performance metric is specific, the G bit MUST be cleared. The G bit MUST always be ignored in a PCMonRep or PCRep message. P (Processing Time) - 1 bit: the P bit of the MONITORING object carried in a PCMonReq or a PCReq message is set to indicate that the processing times is a metric of interest. If allowed by policy, a PROC-TIME object MUST be inserted in the corresponding PCMonRep or PCRep message. The P bit MUST always be ignored in a PCMonRep or PCRep message. C (Congestion) - 1 bit: The C bit of the MONITORING object carried in a PCMonReq or a PCReq message is set to indicate that the congestion status is a metric of interest, in which case a CONGESTION object MUST be inserted in the corresponding PCMonRep or PCRep message. The C bit MUST always be ignored in a PCMonRep or PCRep message. I (Incomplete) - 1 bit: If a PCE supports a received PCMonReq message and that message does not trigger any policy violation, but the PCE cannot provide any of the set of requested performance metrics for unspecified reasons, the PCE MUST set the I bit. The I bit has no meaning in a request and SHOULD be ignored on receipt. Monitoring-id-number (32 bits): The monitoring-id-number value Vasseur, et al. Expires July 12, 2009 [Page 13] =0C Internet-Draft draft-ietf-pce-monitoring-04.txt January 2009 combined with the PCEP-ID of the PCC identifies the monitoring request context. The monitoring-id-number MUST start at a non-zero value and MUST be incremented each time a new monitoring request is sent to a PCE. Each increment SHOULD have a value of 1 and may cause a wrap back to one. If no reply to a monitoring request is received from the PCE, and the PCC wishes to resend its path computation monitoring request, the same monitoring-id-number MUST be used. Conversely, a different monitoring-id-number MUST be used for different requests sent to a PCE. The path computation monitoring reply is unambiguously identified by the monitoring-id-number and the PCEP-ID of the replying PCE. A PCEP implementation SHOULD checkpoint the Monitoring-id-number of pending monitoring requests in case of restart thus avoiding the re-use of a Monitoring-id-number of an in- process monitoring request. Unassigned bits are considered as reserved and MUST be set to zero on transmission and ignored on reception. No optional TLVs are currently defined. 4.2. PCE-ID Object The PCE-ID Object is used to specify a PCE's IP address. A set of PCE-ID objects may be inserted within a PCReq or a PCMonReq message to specify the PCE for which PCE state metrics are requested and in a PCMonRep or a PCRep message to record the IP address of the PCE reporting PCE state metrics or that was involved in the path computation chain. Two PCE-ID objects (for IPv4 and IPv6) are defined. PCE-ID Object- Class is to be assigned by IANA (recommended value=3D20) PCE-ID = Object- Type is to be assigned by IANA (recommended value=3D1 for IPv4 and 2 for IPv6) The format of the PCE-ID Object is as follows: Vasseur, et al. Expires July 12, 2009 [Page 14] =0C Internet-Draft draft-ietf-pce-monitoring-04.txt January 2009 The format of the PCE-ID object body for IPv4 and IPv6 are as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6 Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The PCE-ID object body has a fixed length of 4 octets for IPv4 and 16 octets for IPv6. When a dynamic discovery mechanism is used for PCE discovery, a PCE advertises its PCE address in the PCE-ADDRESS sub-TLV defined in [RFC5088] and [RFC5089]. A PCC MUST use this address in PCReq and PCMonReq messages and a PCE MUST also use this address in PCRep and PCMonRep messages. 4.3. PROC-TIME Object If allowed by policy, the PCE includes a PROC-TIME object within a PCMonRep or a PCRep message if the P bit of the MONITORING object carried within the corresponding PCMonReq or PCReq message is set. The PROC-TIME object is used to report various processing time related metrics. 1) Case of general monitoring requests A PCC may request processing time metrics for general monitoring requests (e.g. the PCC may want to know the minimum, maximum and average processing times on a particular PCE). In this case, general requests can only be made by using PCMonReq/PCMonRep messages. The Current-processing-time field (as explained below) is exclusively used for specific monitoring requests and MUST be cleared for general monitoring requests. The algorithms used by a PCE to compute the Min, Average, Max and Variance of the processing times are out of the scope of this document (A PCE may decide to compute the minimum processing time over a period of times, for the last N path computation requests, ...). Vasseur, et al. Expires July 12, 2009 [Page 15] =0C Internet-Draft draft-ietf-pce-monitoring-04.txt January 2009 2) Case of specific monitoring requests In the case of a specific request, the algorithms used by a PCE to compute the Procesing-time metrics are out of the scope of this document but a flag is specified that is used to indicate to the requester whether the processing time value was estimated or computed. The PCE may either (1) estimate the processing time without performing an actual path computation or (2) effectively perform the computation to report the processing time. In the former case, the E bit of the PROC-TIME object MUST be set. The G bit MUST be cleared and the Min-processing-time, Max-processing-time, Average- processing-time and Variance-processing-time MUST be set to 0x00000000. When the processing time is requested in addition to a path computation (case where the MONITORING object is carried within a PCReq message), the PROC-TIME object always reports the actual processing time for that request and thus the E bit MUST be cleared. The PROC-TIME Object-Class is to be assigned by IANA (recommended value=3D21) The PROC-TIME Object-Type is to be assigned by IANA (recommended value=3D1) The format of the PROC-TIME object body is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Flags |E| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Current-processing-time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Min-processing-time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max-processing-time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Average-processing time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variance-processing-time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flags: 16 bits - one flag is currently defined: E (Estimated) - 1 bit: when set, this indicates that the reported metric value is based on estimated processing time as opposed to actual computations. Vasseur, et al. Expires July 12, 2009 [Page 16] =0C Internet-Draft draft-ietf-pce-monitoring-04.txt January 2009 Unassigned bits are considered as reserved and MUST be set to zero on transmission. Current-processing-time: This field indicates in milliseconds the processing time for the path computation of interest characterized in the corresponding PCMonReq message. Min-processing-time: This field indicates in milliseconds the minimum processing time. Max-processing-time: This field indicates in milliseconds the maximum processing time. Average-processing-time: This field indicates in milliseconds the average processing time. Variance-processing-time: This field indicates in milliseconds the variance of the processing times. 4.4. CONGESTION Object The CONGESTION object MUST be present within a PCMonRep or a PCRep message if the C bit of the MONITORING object carried within the corresponding PCMonReq or PCReq message is set. The CONGESTION object is used to report a PCE processing congestion state. The CONGESTION Object-Class is to be assigned by IANA (recommended value=3D22) The CONGESTION Object-Type is to be assigned by IANA (recommended value=3D1) The format of the CONGESTION object body is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags |C| Reserved | Congestion Duration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flags: 8 bits - one flag is currently defined: C (Congestion) - 1 bit: when set, this indicates that PCE is congested, in which case the congestion duration may be non nul. When cleared this indicates that the PCE is not congested and the "Congestion Duration" field MUST be set to 0x0000. Congestion duration - 16 bits: This field indicates in seconds the estimated congestion duration. It is worth noting that a PCE along a PCE chain involved in the Vasseur, et al. Expires July 12, 2009 [Page 17] =0C Internet-Draft draft-ietf-pce-monitoring-04.txt January 2009 monitoring request may decide to learn from the congestion information received by one of downstream PCE in the chain. 5. Policy The receipt of a PCMonReq message may trigger a policy violation on some PCE in which case the PCE MUST send a PCErr message with Error- Type=3D5 and Error-value=3D3 (To be Confirmed by IANA). 6. Elements of Procedure I bit processing: as indicated in section Section 4.1, if a PCE supports a received PCMonReq message and that message does not trigger any policy violation, but the PCE cannot provide any of the set of requested performance metrics for unspecified reasons, the PCE MUST set the I bit. Once set, the I bit MUST NOT be changed by a receiving PCE. Upon receiving a PCMonReq message: 1) As specified in [I-D.ietf-pce-pcep], if the PCE does not support the PCMonReq message, the PCE peer MUST send a PCErr message with Error-value=3D2 (capability not supported). According to the = procedure defined in section 6.9 of [I-D.ietf-pce-pcep], if a PCC/PCE receives unrecognized messages at a rate equal of greater than specified rate, the PCC/PCE must send a PCEP CLOSE message with close value=3D"Reception of an unacceptable number of unknown PCEP message. In this case, the PCC/PCE must also close the TCP session and must not send any further PCEP messages on the PCEP session. 2) If the PCE supports the PCMonReq message but the monitoring request is prohibited by policy, the PCE must follow the procedure specified in section 5. 3) If the PCE supports the PCMonReq and the monitoring request is not prohibited by policy, the receiving PCE MUST first determine whether it is the last PCE of the path computation chain. If the PCE is not the last element of the path computation chain, the PCMonReq message is relayed to the next hop PCE: such next-hop may either be specified by means of a PCE-ID object present in the PCMonReq message or dynamically determined by means of a procedure outside of the scope of this document. Conversely, if the PCE is the last PCE of the path computation chain, the PCE originates a PCMonRep message that contains the requested objects according to the set of requested PCE states metrics listed in the MONITORING object carried in the corresponding PCMonReq message. Vasseur, et al. Expires July 12, 2009 [Page 18] =0C Internet-Draft draft-ietf-pce-monitoring-04.txt January 2009 Upon receiving a PCReq message that carries a MONITORING and potentially other monitoring objects (e.g. PCE-ID object): 1) As specified in [I-D.ietf-pce-pcep], if the PCE does not support (in band) monitoring, the PCE peer MUST send a PCErr message with Error-value=3D2 (capability not supported). According to the = procedure defined in section 6.9 of [I-D.ietf-pce-pcep], if a PCC/PCE receives unrecognized messages at a rate equal of greater than specified rate, the PCC/PCE must send a PCEP CLOSE message with close value=3D"Reception of an unacceptable number of unknown PCEP message. In this case, the PCC/PCE must also close the TCP session and must not send any further PCEP messages on the PCEP session. 2) If the PCE supports the monitoring request but the monitoring request is prohibited by policy, the PCE must follow the procedure specified in section 5. 3) If the PCE supports the monitoring request and that request is not prohibited by policy, the receiving PCE MUST first determine whether it is the last PCE of the path computation chain. If the PCE is not the last element of the path computation chain, the PCReq message (with the MONITORING object and potentially other monitoring objects such as the PCE-ID) is relayed to the next hop PCE: such next-hop may either be specified by means of a PCE-ID object present in the PCReq message or dynamically determined by means of a procedure outside of the scope of this document. Conversely, if the PCE is the last PCE of the path computation chain, the PCE originates a PCRep message that contains the requested objects according to the set of requested PCE states metrics listed in the MONITORING and potentially other monitoring objects carried in the corresponding PCReq message. Upon receiving a PCMonRep message: upon receiving a PCMonRep message, the PCE processes the request, adds the relevant objects to the PCMonRep message and forwards the PCMonRep message to the upstream requesting PCE or PCC. Upon receiving a PCRep message that carrries monitoring data, the message is processed, additional monitoring data is added according to this specification and the message is forwarded upstream to the requesting PCE or PCC. Special case of Multi-destination monitoring: monitoring request related to more than one destinations may involve a set of path computation chains. In that case, a PCE sends each copy of the PCMonReq message to each downstream PCE of each path computation chain. Vasseur, et al. Expires July 12, 2009 [Page 19] =0C Internet-Draft draft-ietf-pce-monitoring-04.txt January 2009 7. Manageability Considerations 7.1. Control of Function and Policy It MUST be possible to configure the activation/deactivation of PCEP monitoring on a PCEP speaker. In addition to the parameters already listed in section 8.1 of [I-D.ietf-pce-pcep], a PCEP implementation SHOULD allow configuring on a PCE whether specific, generic, in band and out of band monitoring requests are allowed or not. Also a PCEP implementation SHOULD allow configuring on a PCE a list of authorized state metrics (aliveness, congestion, processing time, etc). This may apply to any session the PCEP speaker participates in, to a specific session with a given PCEP peer or to a specific group of sessions with a specific group of PCEP peers, for instance the PCEP peers of a neighbor AS. 7.2. Information and Data Models A new MIB Module may be defined that provides local PCE state metrics, as well as state metrics of other PCEs gathered using mechanisms defined in this document. 7.3. Liveness Detection and Monitoring This document provides mechanisms to monitor the liveliness and performances of a given PCE chain. 7.4. Verify Correct Operations Mechanisms defined in this document do not imply any new operation verification requirements in addition to those already listed in [I-D.ietf-pce-pcep]. 7.5. Requirements On Other Protocols Mechanisms defined in this document do not imply any requirements on other protocols in addition to those already listed in [I-D.ietf-pce-pcep]. 7.6. Impact On Network Operations The frequency of PCMonReq messages may impact the operations of PCEs. An implementation SHOULD allow a limit to be placed on the rate of PCMonReq messages sent by a PCEP speaker and processed from a peer. It SHOULD also allow sending a notification when a rate threshold is reached. An implementation SHOULD allow handling PCReq messages with a higher priority than PCMonReq messages. An implementation SHOULD allow the configuration of a second limit for the PCReq message Vasseur, et al. Expires July 12, 2009 [Page 20] =0C Internet-Draft draft-ietf-pce-monitoring-04.txt January 2009 requesting monitoring data. 8. IANA Considerations 8.1. New PCEP Message Each PCEP message has a message type value. Two new PCEP (specified in [I-D.ietf-pce-pcep]) messages are defined in this document: Value Description Reference 8 Path Computation Monitoring Request (PCMonReq) This document 9 Path Computation Monitoring Reply (PCMonRep) This document 8.2. New PCEP Objects Each PCEP object has an Object-Class and an Object-Type. The following new PCEP objects are defined in this document. Object-Class Value Name Object-Type Reference 19 MONITORING 1 This document 20 PCE-ID 1: IPv4 addresses This document 2: IPv6 addresses This document 21 PROC-TIME 1 This document 22 CONGESTION 1 This document 8.3. New Error-Type and Error-Values A registry has been created for the Error-type and Error-value of the PCEP Error Object. A new Error-value for the PCErr message Error-types=3D5 (Policy Violation) (see [I-D.ietf-pce-pcep]) is defined in this document (Error-value to be assigned by IANA). Vasseur, et al. Expires July 12, 2009 [Page 21] =0C Internet-Draft draft-ietf-pce-monitoring-04.txt January 2009 Error-Type Meaning Error-value Reference 5 Policy violation 3 This = document Monitoring message supported but rejected due to policy violation A new Error-value for the PCErr message Error-types=3D6 (Mandatory Object missing) (see [I-D.ietf-pce-pcep]) is defined in this document (Error-Type and Error-value to be assigned by IANA). Error-type Meaning Error-value Reference 6 Mandatory Object missing 4 This = document MONITORING Object missing 8.4. MONITORING Object Flag Field IANA is requested to create a registry to manage the Flag field of the MONITORING object. New bit numbers may be allocated only by an IETF Consensus action. Each bit should be tracked with the following qualities: o Bit number (counting from bit 0 as the most significant bit) o Capability Description o Defining RFC Several bits are defined for the MONITORING Object flag field in this document: Codespace of the Flag field (MONITORING Object) Bit Description Reference 0-18 Unassigned 19 Incomplete This document 20 Congestion This document 21 Processing Time This document 22 General This document 23 Liveness This document 8.5. PROC-TIME Object Flag Field IANA is requested to create a registry to manage the Flag field of the PROC-TIME object. New bit numbers may be allocated only by an IETF Consensus action. Each bit should be tracked with the following qualities: Vasseur, et al. Expires July 12, 2009 [Page 22] =0C Internet-Draft draft-ietf-pce-monitoring-04.txt January 2009 o Bit number (counting from bit 0 as the most significant bit) o Capability Description o Defining RFC One bit is defined for the PROC-TIME Object flag field in this document: Codespace of the Flag field (PROC-TIME Object) Bit Description Reference 0-14 Unassigned 15 Estimated This document 8.6. CONGESTION Object Flag field IANA is requested to create a registry to manage the Flag field of the CONGESTION object. New bit numbers may be allocated only by an IETF Consensus action. Each bit should be tracked with the following qualities: o Bit number (counting from bit 0 as the most significant bit) o Capability Description o Defining RFC One bit is defined for the CONGESTION Object flag field in this document: Codespace of the Flag field (CONGESTION Object) Bit Description Reference 0-6 Unassigned 7 Congestion This document 9. Security Considerations The use of monitoring data can be used for various attacks such as denail of service attacks (for example by setting the C bit and congestion during field of the CONGESTION object to stop PCCs from using a PCE). Thus it is recommended to make use of the security mechanisms discussed in [I-D.ietf-pce-pcep] to secure a PCEP session (authenticity, integrity, privacy, DoS protection, etc) to secure the PCMonReq, PCMonRep messages and PCE state metric objects defined in Vasseur, et al. Expires July 12, 2009 [Page 23] =0C Internet-Draft draft-ietf-pce-monitoring-04.txt January 2009 this document. An implementation SHOULD allow limiting the rate at which PCMonReq or PCReq messages carrying monitoring requests received from a specific peer are processed (input shapping), or from another domain (see also section 7.6). 10. Acknowledgements The authors would like to thank Eiji Oki, Mach Chen, Fabien Verhaeghe and Dimitri Papadimitriou for their useful comments. Special thank to Adrian Farrel for his detailed review. 11. References 11.1. Normative References [I-D.farrel-rtg-common-bnf] Farrel, A., "Reduced Backus-Naur Form (RBNF) A Syntax Used in Various Protocol Specifications", draft-farrel-rtg-common-bnf-07 (work in progress), November 2008. [I-D.ietf-pce-of] Roux, J., Vasseur, J., and Y. Lee, "Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)", draft-ietf-pce-of-06 (work in progress), December 2008. [I-D.ietf-pce-pcep] Ayyangar, A., Farrel, A., Oki, E., Atlas, A., Dolganow, A., Ikejiri, Y., Kumaki, K., Vasseur, J., and J. Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", draft-ietf-pce-pcep-19 (work in progress), November 2008. [I-D.ietf-pce-pcep-xro] Takeda, T., Oki, E., and A. Farrel, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions", draft-ietf-pce-pcep-xro-06 (work in progress), July 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. Vasseur, et al. Expires July 12, 2009 [Page 24] =0C Internet-Draft draft-ietf-pce-monitoring-04.txt January 2009 11.2. Informative References [I-D.ietf-pce-brpc] Vasseur, J., Zhang, R., Bitar, N., and J. Roux, "A Backward Recursive PCE-based Computation (BRPC) Procedure To Compute Shortest Constrained Inter-domain Traffic Engineering Label Switched Paths", draft-ietf-pce-brpc-09 (work in progress), April 2008. [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, January 2008. [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5089, January 2008. Authors' Addresses JP Vasseur (editor) Cisco Systems, Inc 1414 Massachusetts Avenue Boxborough, MA 01719 USA Email: jpv@cisco.com JL Le Roux France Telecom 2, Avenue Pierre-Marzin Lannion, 22307 FRANCE Email: jeanlouis.leroux@orange-ftgroup.com Yuichi Ikejiri NTT Communications Corporation 1-1-6, Uchisaiwai-cho, Chiyoda-ku Tokyo, 100-8019 Japan Email: : y.ikejiri@ntt.com Vasseur, et al. Expires July 12, 2009 [Page 25] =0C Internet-Draft draft-ietf-pce-monitoring-04.txt January 2009 Full Copyright Statement Copyright (C) The IETF Trust (2009). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Vasseur, et al. Expires July 12, 2009 [Page 26] =0C --Apple-Mail-88-646551410 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
--Apple-Mail-88-646551410 Content-Disposition: attachment; filename*0="Diff: draft-ietf-pce-monitoring-03.txt - draft-ietf-pce-monitori"; filename*1=ng-04.webarchive Content-Type: application/octet-stream; x-mac-hide-extension=yes; x-unix-mode=0644; name="Diff: draft-ietf-pce-monitoring-03.txt - draft-ietf-pce-monitoring-04.webarchive" Content-Transfer-Encoding: quoted-printable bplist00=D1=01=02_=10=0FWebMainResource=D5=03=04=05=06=07=08=09=0A=0B=0C= ^WebResourceURL_=10=1BWebResourceTextEncodingName_=10=13WebResourceMIMETyp= e_=10=0FWebResourceData_=10=14WebResourceFrameName_=10=1Dhttp://tools.ietf= .org/rfcdiffUUTF-8Ytext/htmlO=12=00=03=AAA=20=0A=20=20= =20=0A=20=20=20=0A=20=20= Diff:=20draft-ietf-pce-monitoring-03.txt=20-=20= draft-ietf-pce-monitoring-04.txt=20=0A=20=20=20=0A=20=20=20=20body=20=20=20=20{=20margin:=200.4ex;=20= margin-right:=20auto;=20}=20=0A=20=20=20=20tr=20=20=20=20=20=20{=20}=20=0A= =20=20=20=20td=20=20=20=20=20=20{=20white-space:=20pre;=20font-family:=20= monospace;=20vertical-align:=20top;=20font-size:=200.86em;}=20=0A=20=20=20= =20th=20=20=20=20=20=20{=20font-size:=200.86em;=20}=20=0A=20=20=20=20= .small=20=20{=20font-size:=200.6em;=20font-style:=20italic;=20= font-family:=20Verdana,=20Helvetica,=20sans-serif;=20}=20=0A=20=20=20=20= .left=20=20=20{=20background-color:=20#EEE;=20}=20=0A=20=20=20=20.right=20= =20{=20background-color:=20#FFF;=20}=20=0A=20=20=20=20.diff=20=20=20{=20= background-color:=20#CCF;=20}=20=0A=20=20=20=20.lblock=20{=20= background-color:=20#BFB;=20}=20=0A=20=20=20=20.rblock=20{=20= background-color:=20#FF8;=20}=20=0A=20=20=20=20.insert=20{=20= background-color:=20#8FF;=20}=20=0A=20=20=20=20.delete=20{=20= background-color:=20#ACF;=20}=20=0A=20=20=20=20.void=20=20=20{=20= background-color:=20#FFB;=20}=20=0A=20=20=20=20.cont=20=20=20{=20= background-color:=20#EEE;=20}=20=0A=20=20=20=20.linebr=20{=20= background-color:=20#AAA;=20}=20=0A=20=20=20=20.lineno=20{=20color:=20= red;=20background-color:=20#FFF;=20font-size:=200.7em;=20text-align:=20= right;=20padding:=200=202px;=20}=20=0A=20=20=20=20.elipsis{=20= background-color:=20#AAA;=20}=20=0A=20=20=20=20.left=20.cont=20{=20= background-color:=20#DDD;=20}=20=0A=20=20=20=20.right=20.cont=20{=20= background-color:=20#EEE;=20}=20=0A=20=20=20=20.lblock=20.cont=20{=20= background-color:=20#9D9;=20}=20=0A=20=20=20=20.rblock=20.cont=20{=20= background-color:=20#DD6;=20}=20=0A=20=20=20=20.insert=20.cont=20{=20= background-color:=20#0DD;=20}=20=0A=20=20=20=20.delete=20.cont=20{=20= background-color:=20#8AD;=20}=20=0A=20=20=20=20.stats,=20.stats=20td,=20= .stats=20th=20{=20background-color:=20#EEE;=20padding:=202px=200;=20}=20=0A= =20=20=20=0A=20=0A=20=20=20=0A=20=20=C2=A0draft-ietf-pce-monitoring-03.txt=C2=A0= =20= =C2=A0draft-ietf-pce-monitoring-04.txt=C2=A0=20= =0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20Networking=20= Working=20Group=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20JP.=20Vasseur,=20Ed.=20= Networking=20Working=20Group=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20JP.=20Vasseur,=20Ed.=0A=20=20=20=20=20=20Internet-Draft=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20Cisco=20Systems,=20Inc=20Internet-Draft=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Cisco=20Systems,=20Inc=0A=20=20=20=20=20=20Intended=20status:=20Standards=20= Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20JL.=20Le=20Roux=20Intended=20status:=20Standards=20Track=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20JL.=20= Le=20Roux=0A=20=20= =20=20=20=20=0A=20=20=20=20=20= =20Expires:=20May=206,=202009=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20France=20Telecom=20= Expires:=20July=20= 12,=202009=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20France=20= Telecom=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Y.=20Ikejiri=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Y.=20= Ikejiri=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20NTT=20= Communications=20Corporation=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20NTT=20Communications=20= Corporation=0A=20=20= =20=20=20=20=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20November=20= 2,=202008=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20January=208,=202009=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=20=20A=20set=20of=20= monitoring=20tools=20for=20Path=20Computation=20Element=20based=20= =20=20=20=20=20=20A=20set=20of=20monitoring=20= tools=20for=20Path=20Computation=20Element=20based=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Architecture=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Architecture=0A=20= =20=20=20=20=20=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20draft-ietf-pce-monitoring-03.txt=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= draft-ietf-pce-monitoring-04.txt=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20Status=20of=20this=20= Memo=20Status=20of=20this=20= Memo=0A=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20=20=20=20By=20= submitting=20this=20Internet-Draft,=20each=20author=20represents=20that=20= any=20=20=20=20By=20submitting=20= this=20Internet-Draft,=20each=20author=20represents=20that=20any=0A=20=20=20=20=20=20=20=20=20= applicable=20patent=20or=20other=20IPR=20claims=20of=20which=20he=20or=20= she=20is=20aware=20=20=20=20= applicable=20patent=20or=20other=20IPR=20claims=20of=20which=20he=20or=20= she=20is=20aware=0A= =20=20=20=20=20=20=20=20=20have=20been=20or=20will=20be=20disclosed,=20and=20= any=20of=20which=20he=20or=20she=20becomes=20=20=20=20have=20been=20or=20will=20be=20disclosed,=20and=20= any=20of=20which=20he=20or=20she=20becomes=0A=20=20=20=20=20=20=20=20=20aware=20will=20be=20= disclosed,=20in=20accordance=20with=20Section=206=20of=20BCP=20= 79.=20=20=20=20aware=20will=20be=20= disclosed,=20in=20accordance=20with=20Section=206=20of=20BCP=20= 79.=0A=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20=20=20=20= Internet-Drafts=20are=20working=20documents=20of=20the=20Internet=20= Engineering=20=20=20=20= Internet-Drafts=20are=20working=20documents=20of=20the=20Internet=20= Engineering=0A=20=20= =20=20=20=20=20=20=20Task=20Force=20(IETF),=20its=20areas,=20and=20= its=20working=20groups.=20=20Note=20that=20=20=20=20Task=20Force=20(IETF),=20its=20areas,=20and=20= its=20working=20groups.=20=20Note=20that=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20= skipping=20= to=20change=20at=20page=201,=20line=2038=20= skipping=20to=20change=20= at=20page=201,=20line=2038=0A=20=20= =20=20=20=20=20=20=20and=20may=20be=20updated,=20replaced,=20or=20= obsoleted=20by=20other=20documents=20at=20any=20=20=20=20and=20may=20be=20updated,=20replaced,=20or=20= obsoleted=20by=20other=20documents=20at=20any=0A=20=20=20=20=20=20=20=20=20time.=20=20It=20is=20= inappropriate=20to=20use=20Internet-Drafts=20as=20reference=20= =20=20=20time.=20=20It=20is=20inappropriate=20= to=20use=20Internet-Drafts=20as=20reference=0A=20=20=20=20=20=20=20=20=20material=20or=20to=20= cite=20them=20other=20than=20as=20"work=20in=20progress."=20= =20=20=20material=20or=20to=20cite=20them=20= other=20than=20as=20"work=20in=20progress."=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20The=20list=20of=20current=20Internet-Drafts=20= can=20be=20accessed=20at=20=20=20=20= The=20list=20of=20current=20Internet-Drafts=20can=20be=20accessed=20= at=0A=20=20=20=20=20= =20=20= =20=20http://www.ietf.org/ietf/1id-abstracts.txt.=20=20=20=20= http://www.ietf.org/ietf/1id-abstracts.txt.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20The=20list=20of=20Internet-Draft=20Shadow=20= Directories=20can=20be=20accessed=20at=20=20=20=20The=20list=20of=20Internet-Draft=20Shadow=20= Directories=20can=20be=20accessed=20at=0A=20=20=20=20=20=20=20=20=20= http://www.ietf.org/shadow.html.=20=20= =20=20http://www.ietf.org/shadow.html.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20This=20Internet-Draft=20will=20expire=20on=20= May=206,=202009.=20=20=20=20This=20Internet-Draft=20will=20expire=20on=20= July=2012,=202009.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20Abstract=20Abstract=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20A=20Path=20Computation=20Element=20(PCE)=20based=20= architecture=20has=20been=20=20=20=20= A=20Path=20Computation=20Element=20(PCE)=20based=20architecture=20has=20= been=0A=20=20=20=20= =20=20=20=20=20specified=20for=20the=20computation=20of=20= Traffic=20Engineering=20(TE)=20Label=20=20=20=20specified=20for=20the=20computation=20of=20= Traffic=20Engineering=20(TE)=20Label=0A=20=20=20=20=20=20=20=20=20Switched=20Paths=20= (LSPs)=20in=20Multiprotocol=20Label=20Switching=20(MPLS)=20and=20= =20=20=20Switched=20Paths=20(LSPs)=20in=20= Multiprotocol=20Label=20Switching=20(MPLS)=20and=0A=20=20=20=20=20=20=20=20=20= Generalized=20MPLS=20(GMPLS)=20networks=20in=20the=20context=20of=20= single=20or=20=20=20=20Generalized=20= MPLS=20(GMPLS)=20networks=20in=20the=20context=20of=20single=20= or=0A=20=20=20=20=20= =20=20= =20=20multiple=20domains=20(where=20a=20domain=20refers=20to=20a=20= collection=20of=20network=20=20=20=20= multiple=20domains=20(where=20a=20domain=20refers=20to=20a=20collection=20= of=20network=0A=20= =20=20=20=20=20=20=20=20elements=20within=20a=20common=20sphere=20of=20= address=20management=20or=20path=20=20= =20=20elements=20within=20a=20common=20sphere=20of=20address=20= management=20or=20path=0A=20=20=20=20=20=20=20=20=20computational=20= responsibility=20such=20as=20IGP=20areas=20and=20Autonomous=20= =20=20=20computational=20responsibility=20= such=20as=20IGP=20areas=20and=20Autonomous=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= Systems).=20=20In=20PCE-based=20environments,=20it=20is=20thus=20= critical=20to=20monitor=20=20=20=20= Systems).=20=20Path=20Computation=20Clients=20= (PCCs)=20send=20computation=20requests=0A=20=20=20=20=20=20=20=20=20the=20state=20of=20= the=20path=20computation=20chain=20for=20troubleshooting=20and=20= =20=20=20to=20PCEs,=20= and=20these=20may=20forward=20the=20requests=20to=20and=20cooperate=20= with=0A=20=20= =20=20=20=20=20=20=20performance=20monitoring=20purposes:=20= liveness=20of=20each=20element=20(PCE)=20=20=20=20other=20PCEs=20= forming=20a=20"path=20computation=20chain".=20=20In=20= PCE-based=0A=20=20= =20=20=20=20=20=20=20involved=20in=20the=20PCE=20chain,=20detection=20= of=20potential=20resource=20contention=20=20=20=20environments,=20it=20is=20thus=20critical=20to=20= monitor=20the=20state=20of=20the=20path=0A=20=20=20=20=20=20=20=20=20states=20and=20= statistics=20in=20term=20of=20path=20computation=20times=20are=20= examples=20=20=20=20computation=20= chain=20for=20troubleshooting=20and=20performance=20monitoring=0A=20=20=20=20=20=20=20=20=20= of=20such=20metrics=20of=20interest.=20=20This=20document=20specifies=20= procedures=20and=20=20=20=20= purposes:=20liveness=20of=20each=20element=20(PCE)=20involved=20in=20the=20= PCE=20chain,=0A=20= =20=20=20=20=20=20=20=20extensions=20to=20the=20Path=20Computation=20= Element=20Protocol=20(PCEP)=20in=20order=20=20=20=20detection=20of=20potential=20resource=20= contention=20states=20and=20statistics=20in=0A=20=20=20=20=20=20=20=20=20to=20gather=20such=20= information.=20=20=20=20term=20of=20= path=20computation=20times=20are=20examples=20of=20such=20metrics=20= of=0A=20=20=20=20=20= =20=20=20=20=20= interest.=20=20This=20document=20specifies=20procedures=20and=20= extensions=20to=20the=0A=20=20=20=20=20=20=20=20=20=20Path=20Computation=20Element=20Protocol=20= (PCEP)=20in=20order=20to=20gather=20such=0A=20=20=20=20=20=20=20=20=20=20information.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20Requirements=20Language=20Requirements=20Language=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20The=20key=20words=20"MUST",=20"MUST=20NOT",=20= "REQUIRED",=20"SHALL",=20"SHALL=20NOT",=20=20=20=20The=20key=20words=20"MUST",=20"MUST=20NOT",=20= "REQUIRED",=20"SHALL",=20"SHALL=20NOT",=0A=20=20=20=20=20=20=20=20=20"SHOULD",=20"SHOULD=20= NOT",=20"RECOMMENDED",=20"MAY",=20and=20"OPTIONAL"=20in=20this=20= =20=20=20"SHOULD",=20"SHOULD=20NOT",=20= "RECOMMENDED",=20"MAY",=20and=20"OPTIONAL"=20in=20this=0A=20=20=20=20=20=20=20=20=20= document=20are=20to=20be=20interpreted=20as=20described=20in=20RFC=20= 2119=20[RFC2119].=20=20=20=20= document=20are=20to=20be=20interpreted=20as=20described=20in=20RFC=20= 2119=20[RFC2119].=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20Table=20of=20= Contents=20Table=20of=20= Contents=0A=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= =20= =20=201.=20=20Introduction=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20=203=20=20=20=20= 1.=20=20Introduction=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20=204=0A=20=20=20=20=20=20=20=20=202.=20=20Terminology=20= =20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20=204=20= =20=20=202.=20=20Terminology=20=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20=205=0A=20=20=20=20=20=20=20=20=20= 3.=20=20Path=20Computation=20Monitoring=20messages=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20=204=20=20=20=20= 3.=20=20Path=20Computation=20Monitoring=20messages=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20=205=0A=20=20=20=20=20=20=20=20=20=20=203.1.=20=20Path=20= Computation=20Monitoring=20Request=20message=20(PCMonReq)=20.=20.=20=20= 5=20=20= =20=20=20=203.1.=20=20Path=20Computation=20Monitoring=20Request=20= message=20(PCMonReq)=20.=20.=20=206=0A=20=20=20=20=20=20=20=20=20=20=203.2.=20=20Path=20= Monitoring=20Reply=20message=20(PCMonRep)=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20=207=20=20=20=20=20=203.2.=20=20Path=20Monitoring=20Reply=20= message=20(PCMonRep)=20.=20.=20.=20.=20.=20.=20.=20.=20.=20=209=0A=20=20=20=20=20=20=20=20=204.=20=20Path=20= Computation=20Monitoring=20Objects=20=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20=208=20= =20=20=204.=20=20Path=20Computation=20= Monitoring=20Objects=20=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=2012=0A=20=20=20=20=20=20=20=20=20=20=204.1.=20=20= MONITORING=20Object=20=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20=208=20=20=20=20= =20=204.1.=20=20MONITORING=20Object=20=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=2012=0A=20=20=20=20=20=20=20=20=20=20=204.2.=20=20= PCEP-ID=20Object=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=2010=20=20=20=20= =20=204.2.=20=20PCE-ID=20Object=20=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=2014=0A=20=20=20=20=20=20=20=20=20=20=204.3.=20=20= PROC-TIME=20Object=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=2011=20=20=20=20= =20=204.3.=20=20PROC-TIME=20Object=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=2015=0A=20=20=20=20=20=20=20=20=20=20=204.4.=20=20= CONGESTION=20Object=20=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=2013=20=20=20=20= =20=204.4.=20=20CONGESTION=20Object=20=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=2017=0A=20=20=20=20=20=20=20=20=205.=20=20Policy=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=2014=20=20=20=20= 5.=20=20Policy=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=2018=0A=20=20=20=20=20=20=20=20=206.=20=20Elements=20= of=20Procedure=20=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=2014=20= =20=20=206.=20=20Elements=20of=20Procedure=20= =20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=2018=0A=20=20=20=20=20=20=20=20=207.=20=20= Manageability=20Considerations=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=2015=20= =20=20=207.=20=20Manageability=20= Considerations=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=2020=0A=20=20=20=20=20=20=20=20=20=20=207.1.=20=20= Control=20of=20Function=20and=20Policy=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=2015=20= =20=20=20=20=207.1.=20=20Control=20of=20= Function=20and=20Policy=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=2020=0A=20=20=20=20=20=20=20=20=20=20=207.2.=20=20= Information=20and=20Data=20Models=20=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=2015=20= =20=20=20=20=207.2.=20=20Information=20and=20= Data=20Models=20=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=2020=0A=20=20=20=20=20=20=20=20=20=20=207.3.=20=20= Liveness=20Detection=20and=20Monitoring=20=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=2015=20= =20=20=20=20=207.3.=20=20Liveness=20= Detection=20and=20Monitoring=20=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=2020=0A=20=20=20=20=20=20=20=20=20=20=207.4.=20=20= Verify=20Correct=20Operations=20=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=2015=20= =20=20=20=20=207.4.=20=20Verify=20Correct=20= Operations=20=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=2020=0A=20=20=20=20=20=20=20=20=20=20=207.5.=20=20= Requirements=20On=20Other=20Protocols=20=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=2015=20= =20=20=20=20=207.5.=20=20Requirements=20On=20= Other=20Protocols=20=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= 20=0A=20=20=20=20=20=20=20=20=20=20=207.6.=20=20= Impact=20On=20Network=20Operations=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=2015=20= =20=20=20=20=207.6.=20=20Impact=20On=20= Network=20Operations=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=2020=0A=20=20=20=20=20=20=20=20=208.=20=20IANA=20= Considerations=20=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=2016=20=20=20=20= 8.=20=20IANA=20Considerations=20=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=2021=0A=20=20=20=20=20=20=20=20=209.=20=20Security=20= Considerations=20=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=2017=20= =20=20=20=20=208.1.=20= =20New=20PCEP=20Message=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=2021=0A=20=20=20=20=20=20=20=20=2010.=20= Acknowledgements=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=2017=20=20=20=20=20=208.2.=20=20New=20PCEP=20Objects=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=2021=0A=20= =20=20=20=20=20=20=20=2011.=20References=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=2017=20=20=20=20=20=208.3.=20=20New=20= Error-Type=20and=20Error-Values=20=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=2021=0A=20=20=20=20=20=20=20=20=20=20=2011.1.=20= Normative=20References=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=2017=20= =20=20=20=20=208.4.=20= =20MONITORING=20Object=20Flag=20Field=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=2022=0A=20=20=20=20=20=20=20=20=20=20=2011.2.=20= Informative=20References=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=2018=20= =20=20=20=20=208.5.=20= =20PROC-TIME=20Object=20Flag=20Field=20=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=2022=0A=20=20=20=20=20=20=20=20=20Authors'=20Addresses=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=2018=20= =20=20=20=20=208.6.=20= =20CONGESTION=20Object=20Flag=20field=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=2023=0A=20=20=20=20=20=20=20=20=20Intellectual=20= Property=20and=20Copyright=20Statements=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=2020=20=20=20=209.=20=20Security=20Considerations=20=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= 23=0A=20=20=20=20=20=20=20=20=20=2010.=20Acknowledgements=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= 24=0A=20=20=20=20=20=20=20=20=20=2011.=20References=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=2024=0A=20=20=20=20=20=20=20=20=20=20=20=2011.1.=20Normative=20References=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= 24=0A=20=20=20=20=20=20=20=20=20=20=20=2011.2.=20Informative=20References=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=2025=0A=20=20=20=20=20=20=20=20=20=20Authors'=20Addresses=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= 25=0A=20=20=20=20=20=20=20=20=20=20Intellectual=20Property=20and=20Copyright=20= Statements=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=2026=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=201.=20=20Introduction=201.=20=20Introduction=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20The=20Path=20Computation=20Element=20(PCE)=20= based=20architecture=20has=20been=20=20= =20=20The=20Path=20Computation=20Element=20(PCE)=20based=20architecture=20= has=20been=0A=20=20= =20=20=20=20=20=20=20specified=20in=20[RFC4655]=20for=20the=20= computation=20of=20Traffic=20Engineering=20=20=20=20specified=20in=20[RFC4655]=20for=20the=20= computation=20of=20Traffic=20Engineering=0A=20=20=20=20=20=20=20=20=20(TE)=20Label=20= Switched=20Paths=20(LSPs)=20in=20Multiprotocol=20Label=20= Switching=20=20=20=20(TE)=20Label=20= Switched=20Paths=20(LSPs)=20in=20Multiprotocol=20Label=20= Switching=0A=20=20= =20=20=20=20=20=20=20(MPLS)=20and=20Generalized=20MPLS=20(GMPLS)=20= networks=20in=20the=20context=20of=20single=20=20=20=20(MPLS)=20and=20Generalized=20MPLS=20(GMPLS)=20= networks=20in=20the=20context=20of=20single=0A=20=20=20=20=20=20=20=20=20or=20multiple=20= domains=20where=20a=20domain=20refers=20to=20a=20collection=20of=20= network=20=20=20=20or=20multiple=20= domains=20where=20a=20domain=20refers=20to=20a=20collection=20of=20= network=0A=20=20=20= =20=20=20=20=20=20elements=20within=20a=20common=20sphere=20of=20= address=20management=20or=20path=20=20= =20=20elements=20within=20a=20common=20sphere=20of=20address=20= management=20or=20path=0A=20=20=20=20=20=20=20=20=20computational=20= responsibility=20such=20as=20IGP=20areas=20and=20Autonomous=20= =20=20=20computational=20responsibility=20= such=20as=20IGP=20areas=20and=20Autonomous=0A=20=20=20=20=20=20=20=20=20Systems.=20= =20=20=20Systems.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20=20Path=20Computation=20Clients=20(PCCs)=20send=20= computation=20requests=20to=20PCEs,=0A=20=20=20=20=20=20=20=20=20=20and=20these=20may=20= forward=20the=20requests=20to=20and=20cooperate=20with=20other=20= PCEs=0A=20=20= =20=20=20=20=20=20=20=20forming=20a=20"path=20computation=20chain".=20=20= In=20PCE-based=20environments,=20it=20is=0A=20=20=20=20=20=20=20= =20=20=20critical=20= to=20monitor=20the=20state=20of=20the=20path=20computation=20chain=20= for=0A=20=20= =20=20=20=20=20=20=20=20troubeshooting=20and=20performance=20= monitoring=20purposes:=20liveness=20of=20each=0A=20=20=20=20=20=20=20= =20=20=20element=20= (PCE)=20involved=20in=20the=20PCE=20chain,=20detection=20of=20= potential=0A= =20=20=20=20=20=20=20=20=20=20resource=20contention=20states=20and=20= statistics=20in=20term=20of=20path=20computation=0A=20=20=20=20=20=20=20= =20=20=20times=20= are=20examples=20of=20such=20metrics=20of=20interest.=20=20This=20= document=0A= =20=20=20=20=20=20=20=20=20=20specifies=20procedures=20and=20extensions=20to=20= the=20Path=20Computation=20Element=0A=20=20=20=20=20=20=20=20=20=20Protocol=20(PCEP)=20= ([I-D.ietf-pce-pcep])=20in=20order=20to=20monitor=20the=20= path=0A=20=20= =20=20=20=20=20=20=20=20computation=20chain=20and=20gather=20various=20= performance=20metrics.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=0A=20= =20=20=20=20=20=20=20=20As=20defined=20in=20[RFC4655],=20there=20are=20= circumstances=20where=20more=20than=20one=20=20=20=20As=20defined=20in=20[RFC4655],=20there=20are=20= circumstances=20where=20more=20than=20one=0A=20=20=20=20=20=20=20=20=20PCE=20is=20involved=20= in=20the=20computation=20of=20a=20TE=20LSP.=20=20A=20typical=20example=20= is=20=20=20=20PCE=20is=20involved=20= in=20the=20computation=20of=20a=20TE=20LSP.=20=20A=20typical=20example=20= is=0A=20=20=20=20=20= =20=20= =20=20when=20the=20PCC=20requires=20the=20computation=20of=20a=20TE=20= LSP=20where=20the=20head-end=20=20=20= =20when=20the=20PCC=20requires=20the=20computation=20of=20a=20TE=20LSP=20= where=20the=20head-end=0A=20=20=20=20=20=20=20=20=20and=20the=20tail-end=20= of=20the=20TE=20LSP=20do=20not=20reside=20in=20adjacent=20domains=20= and=20=20=20=20and=20the=20tail-end=20= of=20the=20TE=20LSP=20do=20not=20reside=20in=20adjacent=20domains=20= and=0A=20=20=20=20= =20=20=20=20=20there=20is=20no=20single=20PCE=20with=20the=20= visibility=20of=20both=20the=20head-end=20and=20=20=20=20there=20is=20no=20single=20PCE=20with=20the=20= visibility=20of=20both=20the=20head-end=20and=0A=20=20=20=20=20=20=20=20=20tail-end=20domain.=20=20= We=20call=20the=20set=20of=20PCEs=20involved=20in=20the=20= computation=20=20=20=20tail-end=20= domain.=20=20We=20call=20the=20set=20of=20PCEs=20involved=20in=20the=20= computation=0A=20=20= =20=20=20=20=20=20=20of=20a=20TE=20LSP=20a=20"path=20computation=20= chain".=20=20As=20further=20discussed=20in=20=20=20=20of=20a=20TE=20LSP=20a=20"path=20computation=20= chain".=20=20As=20further=20discussed=20in=0A=20=20=20=20=20=20=20=20=20Section=203.1,=20the=20= PCE=20chain=20may=20either=20be=20static=20(pre-configured)=20= or=20=20=20=20Section=203.1,=20the=20= PCE=20chain=20may=20either=20be=20static=20(pre-configured)=20or=0A=20=20=20=20=20=20=20=20=20= dynamically=20determined=20during=20the=20path=20computation=20= process.=20=20=20=20dynamically=20= determined=20during=20the=20path=20computation=20process.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= In=20PCE-based=20environments,=20it=20is=20= critical=20to=20monitor=20the=20state=20of=20the=20= =0A=20=20=20=20=20=20=20=20= =20path=20computation=20chain=20for=20troubeshooting=20and=20performance=20= monitoring=20=0A=20=20=20=20=20=20=20=20=20purposes:=20liveness=20of=20each=20element=20= (PCE)=20involved=20in=20the=20PCE=20chain,=20=0A= =20=20=20=20=20=20=20=20=20detection=20of=20= potential=20resource=20contention=20states=20and=20statistics=20= in=20=0A=20=20=20=20=20=20=20=20=20term=20of=20path=20computation=20times=20are=20= examples=20of=20such=20metrics=20of=20=0A= =20=20=20=20=20=20=20=20=20interest.=20=20This=20= document=20specifies=20procedures=20and=20extensions=20to=20= the=20=0A=20=20=20=20=20=20=20=20=20Path=20Computation=20Element=20Protocol=20= (PCEP)=20([I-D.ietf-pce-pcep])=20in=20=0A= =20=20=20=20=20=20=20=20=20order=20to=20monitor=20= the=20path=20computation=20chain=20and=20gather=20= various=20=0A=20=20=20=20=20=20=20=20=20performance=20metrics.=20= =0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20As=20discussed=20in=20[RFC4655],=20a=20TE=20LSP=20= may=20be=20computed=20by=20one=20PCE=20=20=20=20As=20discussed=20in=20[RFC4655],=20a=20TE=20LSP=20= may=20be=20computed=20by=20one=20PCE=0A=20=20=20=20=20=20=20=20=20(referred=20to=20as=20= single=20PCE=20path=20computation)=20or=20several=20PCEs=20= =20=20=20(referred=20to=20as=20single=20PCE=20= path=20computation)=20or=20several=20PCEs=0A=20=20=20=20=20=20=20=20=20(referred=20to=20as=20= multiple=20PCE=20path=20computation).=20=20In=20the=20former=20= case,=20=20=20=20(referred=20to=20as=20= multiple=20PCE=20path=20computation).=20=20In=20the=20former=20= case,=0A=20=20=20=20= =20=20=20=20=20the=20PCC=20may=20be=20able=20to=20use=20IGP=20= extensions=20to=20check=20the=20liveness=20of=20=20=20=20the=20PCC=20may=20be=20able=20to=20use=20IGP=20= extensions=20to=20check=20the=20liveness=20of=0A=20=20=20=20=20=20=20=20=20the=20PCE=20(see=20= [RFC5088]=20and=20[RFC5089])=20or=20PCEP=20using=20Keepalive=20= =20=20=20the=20PCE=20(see=20[RFC5088]=20and=20= [RFC5089])=20or=20PCEP=20using=20Keepalive=0A=20=20=20=20=20=20=20=20=20messages.=20=20In=20= contrast,=20when=20multiple=20PCEs=20are=20involved=20in=20the=20= path=20=20=20=20messages.=20=20In=20= contrast,=20when=20multiple=20PCEs=20are=20involved=20in=20the=20= path=0A=20=20=20=20= =20=20=20=20=20computation=20chain=20an=20example=20of=20which=20= is=20the=20BRPC=20procedure=20defined=20=20=20=20computation=20chain=20an=20example=20of=20which=20= is=20the=20BRPC=20procedure=20defined=0A=20=20=20=20=20=20=20=20=20in=20= [I-D.ietf-pce-brpc],=20the=20PCC's=20visibility=20may=20be=20limited=20= to=20the=20=20=20=20in=20= [I-D.ietf-pce-brpc],=20the=20PCC's=20visibility=20may=20be=20limited=20= to=20the=0A=20=20=20= =20=20=20=20=20=20first=20PCE=20involved=20in=20the=20path=20= computation=20chain.=20=20Thus,=20it=20is=20=20=20=20first=20PCE=20involved=20in=20the=20path=20= computation=20chain.=20=20Thus,=20it=20is=0A=20=20=20=20=20=20=20=20=20critical=20to=20define=20= mechanisms=20in=20order=20to=20monitor=20the=20state=20of=20the=20= =20=20=20critical=20to=20define=20mechanisms=20= in=20order=20to=20monitor=20the=20state=20of=20the=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20= skipping=20= to=20change=20at=20page=204,=20line=2025=20= skipping=20to=20change=20= at=20page=205,=20line=2027=0A=20=20= =20=20=20=20=20=20=20more=20PCEs").=20=20=20=20more=20PCEs").=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20In=20this=20document=20we=20define=20two=20= monitoring=20request=20types:=20general=20and=20=20=20=20In=20this=20document=20we=20define=20two=20= monitoring=20request=20types:=20general=20and=0A=20=20=20=20=20=20=20=20=20specific.=20=20A=20= general=20monitoring=20request=20relates=20to=20the=20collection=20= of=20=20=20=20specific.=20=20A=20= general=20monitoring=20request=20relates=20to=20the=20collection=20= of=0A=20=20=20=20=20= =20=20= =20=20a=20PCE=20state=20metrics=20that=20is=20not=20coupled=20to=20a=20= particular=20path=20=20=20=20a=20PCE=20= state=20metrics=20that=20is=20not=20coupled=20to=20a=20particular=20= path=0A=20=20=20=20= =20=20=20=20=20computation=20request=20(e.g.=20average=20CPU=20= load=20on=20a=20PCE).=20=20Conversely,=20a=20=20=20=20computation=20request=20(e.g.=20average=20CPU=20= load=20on=20a=20PCE).=20=20Conversely,=20a=0A=20=20=20=20=20=20=20=20=20specific=20monitoring=20= request=20relates=20to=20a=20particular=20path=20computation=20= =20=20=20specific=20monitoring=20request=20= relates=20to=20a=20particular=20path=20computation=0A=20=20=20=20=20=20=20=20=20= request=20(processing=20time=20to=20complete=20the=20path=20computation=20= for=20a=20TE=20=20=20=20request=20= (processing=20time=20to=20complete=20the=20path=20computation=20for=20a=20= TE=0A=20=20=20=20=20= =20=20= =20=20LSP).=20=20=20=20LSP).=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20The=20= message=20formats=20in=20this=20document=20are=20specified=20using=20= Backus=20Naur=0A=20=20=20=20=20=20=20=20=20=20Format=20(BNF)=20= encoding=20as=20specified=20in=20= [I-D.farrel-rtg-common-bnf].=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=0A=20= =20=20=20=20=202.=20=20Terminology=202.=20=20Terminology=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20PCC=20(Path=20Computation=20Client):=20any=20= client=20application=20requesting=20a=20=20=20=20PCC=20(Path=20Computation=20Client):=20any=20= client=20application=20requesting=20a=0A=20=20=20=20=20=20=20=20=20path=20computation=20= to=20be=20performed=20by=20a=20Path=20Computation=20Element.=20= =20=20=20path=20computation=20to=20be=20= performed=20by=20a=20Path=20Computation=20Element.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20PCE=20(Path=20= Computation=20Element):=20an=20entity=20(component,=20application=20= or=20=20=20=20PCE=20(Path=20= Computation=20Element):=20an=20entity=20(component,=20application=20= or=0A=20=20=20=20=20= =20=20= =20=20network=20node)=20that=20is=20capable=20of=20computing=20a=20= network=20path=20or=20route=20=20=20=20= network=20node)=20that=20is=20capable=20of=20computing=20a=20network=20= path=20or=20route=0A= =20=20=20=20=20=20=20=20=20based=20on=20a=20network=20graph=20and=20= applying=20computational=20constraints.=20=20=20=20based=20on=20a=20network=20graph=20and=20= applying=20computational=20constraints.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20TE=20LSP:=20Traffic=20Engineering=20Label=20= Switched=20Path.=20=20=20=20TE=20= LSP:=20Traffic=20Engineering=20Label=20Switched=20Path.=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20= skipping=20= to=20change=20at=20page=205,=20line=206=20= skipping=20to=20change=20= at=20page=206,=20line=2010=0A=20=20= =20=20=20=20=20=20=20object=20is=20said=20to=20be=20mandatory=20in=20= a=20PCEP=20message=20when=20the=20object=20must=20=20=20=20object=20is=20said=20to=20be=20mandatory=20in=20= a=20PCEP=20message=20when=20the=20object=20must=0A=20=20=20=20=20=20=20=20=20be=20= included=20for=20the=20message=20to=20be=20considered=20as=20valid.=20=20= The=20P=20flag=20=20=20=20be=20= included=20for=20the=20message=20to=20be=20considered=20as=20valid.=20=20= The=20P=20flag=0A=20= =20=20=20=20=20=20=20=20(defined=20in=20[I-D.ietf-pce-pcep])=20is=20= located=20in=20the=20common=20header=20of=20=20=20=20(defined=20in=20[I-D.ietf-pce-pcep])=20is=20= located=20in=20the=20common=20header=20of=0A=20=20=20=20=20=20=20=20=20each=20PCEP=20object=20= and=20can=20be=20set=20by=20a=20PCEP=20peer=20to=20require=20a=20PCE=20= to=20=20=20=20each=20PCEP=20object=20= and=20can=20be=20set=20by=20a=20PCEP=20peer=20to=20require=20a=20PCE=20= to=0A=20=20=20=20=20= =20=20= =20=20take=20into=20account=20the=20related=20information=20during=20the=20= path=20=20=20=20take=20into=20= account=20the=20related=20information=20during=20the=20path=0A=20=20=20=20=20=20=20=20=20= computation.=20=20Because=20the=20P=20flag=20exclusively=20relates=20to=20= a=20path=20=20=20=20computation.=20=20= Because=20the=20P=20flag=20exclusively=20relates=20to=20a=20path=0A=20=20=20=20=20=20=20=20=20= computation=20request,=20it=20MUST=20be=20cleared=20in=20the=20two=20= PCEP=20messages=20=20=20=20= computation=20request,=20it=20MUST=20be=20cleared=20in=20the=20two=20= PCEP=20messages=0A= =20=20=20=20=20=20=20=20=20(PCEMonReq=20and=20PCMonRep=20message)=20defined=20= in=20this=20document.=20=20=20=20= (PCEMonReq=20and=20PCMonRep=20message)=20defined=20in=20this=20= document.=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20For=20= each=20PCEP=20message=20type=20a=20set=20of=20rules=20is=20defined=20= that=20specify=20the=20=20=20=20For=20= each=20PCEP=20message=20type=20a=20set=20of=20rules=20is=20defined=20= that=20specify=20the=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= set=20of=20objects=20that=20the=20message=20can=20carry.=20=20We=20use=20the=20Backus-Naur=20=20=20=20set=20of=20objects=20that=20the=20message=20= can=20carry.=20=20An=20implementation=20MUST=0A=20=20=20=20=20=20=20=20= =20Form=20(BNF)=20to=20specify=20such=20rules.=20=20Square=20brackets=20= refer=20to=20optional=20=20=20= =20form=20the=20PCEP=20messages=20using=20the=20object=20ordering=20= specified=20in=20this=0A=20=20=20=20=20=20=20=20= =20sub-sequences.=20=20An=20implementation=20MUST=20form=20the=20= PCEP=20messages=20using=20=20=20=20= document.=0A=20=20= =20=20=20=20=20=20=20the=20object=20ordering=20specified=20in=20= this=20document.=20=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20In=20this=20document=20= we=20define=20two=20PCEP=20messages=20referred=20to=20as=20the=20= Path=20=20=20=20In=20this=20document=20= we=20define=20two=20PCEP=20messages=20referred=20to=20as=20the=20= Path=0A=20=20=20=20= =20=20=0A=20=20=20=20=20=20= =20= =20=20Computation=20Monitoring=20request=20= (PCMonReq)=20and=20Path=20Computation=20=20=20=20Computation=20Monitoring=20Request=20(PCMonReq)=20and=20Path=20= Computation=0A=20=20= =20=20=20=20=20=20=20Monitoring=20Reply=20(PCMonRep)=20messages=20so=20= as=20to=20handle=20"out=20of=20band"=20=20=20=20Monitoring=20Reply=20(PCMonRep)=20messages=20so=20= as=20to=20handle=20"out=20of=20band"=0A=20=20=20=20=20=20=20=20=20monitoring=20request.=20= =20The=20aim=20of=20the=20PCMonReq=20message=20sent=20by=20a=20PCC=20= to=20=20=20=20monitoring=20request.=20= =20The=20aim=20of=20the=20PCMonReq=20message=20sent=20by=20a=20PCC=20= to=0A=20=20=20=20=20= =20=20= =20=20a=20PCE=20is=20to=20gather=20one=20or=20more=20PCE=20state=20= metrics=20on=20a=20set=20of=20PCEs=20=20= =20=20a=20PCE=20is=20to=20gather=20one=20or=20more=20PCE=20state=20= metrics=20on=20a=20set=20of=20PCEs=0A=20=20=20=20=20=20=20=20=20involved=20in=20a=20= path=20computation=20chain.=20=20The=20PCMonRep=20message=20sent=20by=20= a=20=20=20=20involved=20in=20a=20= path=20computation=20chain.=20=20The=20PCMonRep=20message=20sent=20by=20= a=0A=20=20=20=20=20= =20=20= =20=20PCE=20to=20a=20PCC=20is=20used=20to=20provide=20such=20= data.=20=20=20=20PCE=20to=20a=20PCC=20= is=20used=20to=20provide=20such=20data.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=203.1.=20=20Path=20Computation=20Monitoring=20Request=20= message=20(PCMonReq)=203.1.=20=20= Path=20Computation=20Monitoring=20Request=20message=20(PCMonReq)=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20The=20Message-Type=20= field=20of=20the=20PCEP=20common=20header=20for=20the=20= PCMonReq=20=20=20=20The=20= Message-Type=20field=20of=20the=20PCEP=20common=20header=20for=20the=20= PCMonReq=0A=20=20=20= =20=20=20=20=20=20message=20is=20set=20to=208=20(To=20be=20= confirmed=20by=20IANA).=20=20=20=20= message=20is=20set=20to=208=20(To=20be=20confirmed=20by=20IANA).=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20There=20is=20one=20= mandatory=20object=20that=20MUST=20be=20included=20within=20a=20= PCMonReq=20=20=20=20There=20is=20one=20= mandatory=20object=20that=20MUST=20be=20included=20within=20a=20= PCMonReq=0A=20=20=20= =20=20=20=0A=20=20=20=20=20=20= =20= =20=20message:=20the=20Monitoring=20= object=20(see=20section=20Section=204.1).=20=20If=20the=20= =20=20=20message:=20the=20MONITORING=20object=20(see=20section=20Section=20= 4.1).=20=20If=20the= =0A=20=20=20=20=20=20=20=20=20Monitoring=20= object=20is=20missing,=20the=20receiving=20PCE=20MUST=20send=20a=20= PCErr=20=20=20=20MONITORING=20object=20is=20missing,=20the=20= receiving=20PCE=20MUST=20send=20a=20PCErr=0A=20=20=20=20=20=20=20=20=20message=20with=20= Error-type=3D6=20(Mandatory=20Object=20missing)=20and=20Error-=20= =20=20=20message=20with=20Error-type=3D6=20= (Mandatory=20Object=20missing)=20and=20Error-=0A=20=20=20=20=20=20=20=20=20value=3D4=20= (MONITORING=20Object=20missing).=20=20Other=20objects=20are=20= optional.=20=20=20=20value=3D4=20= (MONITORING=20Object=20missing).=20=20Other=20objects=20are=20= optional.=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= =20= =20=20The=20format=20of=20a=20PCMonReq=20= message=20is=20as=20follows:=20=20=20=20Format=20of=20a=20= PCMonReq=20message=20(out=20of=20band=20request):=0A=20=20=20=20=20=20=20=20=20= <PCMonReq=20Message>::=3D=20<Common=20Header>=20=20=20=20<PCMonReq=20Message>::=3D=20<Common=20= Header>=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20<MONITORING>=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= <MONITORING>=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20[<pce-list>]=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= [<pce-list>]=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20[<svec-list>]=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= [<svec-list>]=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20[<request-list>]=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= [<request-list>]= =0A=20=20=20=20=20=20=20=20=20where:=20=20=20= =20where:=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= <svec-list>::=3D<SVEC>=20=20=20= =20<svec-list>::=3D<SVEC>=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20[<OF>]=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20[<OF>]=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20[<svec-list>]=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= [<svec-list>]=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20skipping=20to=20= change=20at=20page=206,=20line=2032=20= skipping=20to=20change=20= at=20page=208,=20line=204=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= [<BANDWIDTH>]=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20[<BANDWIDTH>]=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20[<metric-list>]=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[<metric-list>]=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20[<RRO>]=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= [<RRO>]=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= [<IRO>]=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20[<IRO>]=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20[<LOAD-BALANCING>]=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= [<LOAD-BALANCING>]=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20[<XRO>]=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20[<XRO>]=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20= <metric-list>::=3D<METRIC>[<metric-list>]=20=20=20=20= <metric-list>::=3D<METRIC>[<metric-list>]=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20= <pce-list>::=3D<PCE-ID>[<pce-list>]=20=20=20=20= <pce-list>::=3D<PCE-ID>[<pce-list>]=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20Format=20= of=20a=20PCReq=20message=20with=20monitoring=20data=20requested=20(in=20= band=0A=20=20= =20=20=20=20=20=20=20=20request):=0A=20=20=20=20=20=20=20=20=20=20<PCReq=20= Message>::=3D=20<Common=20Header>=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20<MONITORING>=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= [<pce-list>]=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20[<svec-list>]=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= <request-list>=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20The=20SVEC,=20RP,=20END-POINTS,=20LSPA,=20= BANDWIDTH,=20METRIC,=20ERO,=20IRO=20and=20= LOAD-=20=20=20=20where:=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= <svec-list>::=3D<SVEC>[<svec-list>]=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20= <request-list>::=3D<request>[<request-list>]=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20= =20=20=20=20=20=20= <request>::=3D=20<RP>=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20<END-POINTS>=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20[<LSPA>]=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20[<BANDWIDTH>]=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20[<metric-list>]=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20= [<RRO>[<BANDWIDTH>]]=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20[<IRO>]=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20[<LOAD-BALANCING>]=0A=20=20=20=20=20=20=20= =20=20=20= where:=0A=20= =20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20= <metric-list>::=3D<METRIC>[<metric-list>]=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20= =20=20=20= <pce-list>::=3D<PCE-ID>[<pce-list>]=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20The=20SVEC,=20RP,=20END-POINTS,=20LSPA,=20= BANDWIDTH,=20METRIC,=20RRO,=20IRO=20and=20= LOAD-=0A=20=20=20=20= =20=20=20=20=20BALANCING=20objects=20are=20defined=20in=20= [I-D.ietf-pce-pcep].=20=20The=20XRO=20object=20=20=20=20BALANCING=20objects=20are=20defined=20in=20= [I-D.ietf-pce-pcep].=20=20The=20XRO=20object=0A=20=20=20=20=20=20=20=20=20is=20defined=20in=20= [I-D.ietf-pce-pcep-xro]=20and=20the=20OF=20object=20is=20defined=20= in=20=20=20=20is=20defined=20in=20= [I-D.ietf-pce-pcep-xro]=20and=20the=20OF=20object=20is=20defined=20= in=0A=20=20=20=20=20= =20=20= =20=20[I-D.ietf-pce-of].=20=20=20=20= [I-D.ietf-pce-of].=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20The=20= PCMonReq=20message=20is=20used=20to=20gather=20various=20PCE=20state=20= metrics=20=20=20=20The=20PCMonReq=20= message=20is=20used=20to=20gather=20various=20PCE=20state=20= metrics=0A=20=20=20= =20=20=20=20=20=20along=20a=20path=20computation=20chain.=20=20The=20= path=20computation=20chain=20may=20be=20=20=20=20along=20a=20path=20computation=20chain.=20=20= The=20path=20computation=20chain=20may=20be=0A=20=20=20=20=20=20=20=20=20determined=20by=20the=20= PCC=20(in=20the=20form=20of=20a=20series=20of=20a=20series=20of=20= PCE-ID=20=20=20=20determined=20by=20= the=20PCC=20(in=20the=20form=20of=20a=20series=20of=20a=20series=20of=20= PCE-ID=0A=20=20=20= =20=20=20=20=20=20objects=20defined=20in=20Section=204.2.)=20or=20= may=20alternatively=20be=20determined=20=20=20=20objects=20defined=20in=20Section=204.2.)=20or=20= may=20alternatively=20be=20determined=0A=20=20=20=20=20=20=20=20=20by=20the=20path=20= computation=20procedure.=20=20For=20example,=20if=20the=20BRPC=20= =20=20=20by=20the=20path=20computation=20= procedure.=20=20For=20example,=20if=20the=20BRPC=0A=20=20=20=20=20=20=20=20=20= procedure=20([I-D.ietf-pce-brpc])=20is=20used=20to=20compute=20an=20= inter-domain=20TE=20=20=20=20= procedure=20([I-D.ietf-pce-brpc])=20is=20used=20to=20compute=20an=20= inter-domain=20TE=0A= =20=20=20=20=20=20=20=20=20LSP,=20the=20PCE=20chain=20may=20be=20determined=20= dynamically.=20=20In=20that=20case,=20the=20=20=20=20LSP,=20the=20PCE=20chain=20may=20be=20= determined=20dynamically.=20=20In=20that=20case,=20the=0A=20=20=20=20=20=20=20=20=20PCC=20= sends=20a=20PCMonReq=20message=20that=20contains=20the=20PCEP=20objects=20= that=20=20=20=20PCC=20sends=20a=20= PCMonReq=20message=20that=20contains=20the=20PCEP=20objects=20= that=0A=20=20=20=20= =20=20=0A=20=20=20=20=20=20= =20= =20=20charaterize=20the=20TE=20LSP=20attributes=20along=20with=20the=20= monitoring=20objects=20=20=20=20charaterize=20the=20TE=20LSP=20attributes=20= along=20with=20the=20MONITORING=20= object=0A=20= =20=20=20=20=20=20=20=20(see=20Section=204.1)=20that=20list=20the=20set=20of=20metric(s)=20of=20interest.=20=20=20=20(see=20Section=204.1)=20that=20lists=20the=20set=20of=20metrics=20of=20interest.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20Several=20PCE=20state=20= metrics=20may=20be=20requested=20that=20are=20specified=20by=20= a=20=20=20=20Several=20PCE=20state=20= metrics=20may=20be=20requested=20that=20are=20specified=20by=20a=0A=20=20=20=20=20=20=20=20=20set=20= of=20objects=20defined=20in=20Section=204.=20=20Note=20that=20this=20set=20= of=20objects=20=20=20=20set=20of=20= objects=20defined=20in=20Section=204.=20=20Note=20that=20this=20set=20of=20= objects=0A=20=20=20= =20=20=20=20=20=20may=20be=20extended=20in=20the=20= future.=20=20=20=20may=20be=20= extended=20in=20the=20future.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20For=20the=20sake=20of=20illustraion,=20= consider=20the=20three=20following=20examples:=20=20=20=20For=20the=20sake=20of=20illustration,=20consider=20the=20three=20following=20= examples:=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= =20= =20=20Example=201:=20PCC1=20requests=20= to=20check=20the=20path=20computation=20chain=20that=20=20=20=20Example=201=20(out=20= of=20band=20request):=20PCC1=20requests=20to=20check=20the=20= path=0A=20=20=20=20= =20=20=20=20=20would=20be=20used=20should=20it=20request=20a=20= path=20computation=20for=20a=20specific=20TE=20=20=20=20computation=20chain=20that=20would=20be=20used=20= should=20it=20request=20a=20path=0A=20=20=20=20=20=20=20=20=20LSP=20named=20T1.=20=20= A=20PCMonReq=20message=20is=20sent=20that=20contains=20a=20= MONITORING=20=20=20=20computation=20= for=20a=20specific=20TE=20LSP=20named=20T1.=20=20A=20PCMonReq=20message=20= is=0A=20=20=20=20=20= =20=20=20=20object=20specifying=20a=20path=20computation=20= check,=20along=20with=20the=20=20=20= =20sent=20that=20contains=20a=20MONITORING=20object=20specifying=20a=20= path=20computation=0A= =20=20=20=20=20=20=20=20=20appropriate=20set=20of=20objects=20(e.g.=20=20= RP,=20END-POINTS,=20...)=20that=20would=20= be=20=20=20=20check,=20along=20with=20= the=20appropriate=20set=20of=20objects=20(e.g.=20=20RP,=20END-=0A=20=20=20=20=20=20=20=20=20included=20in=20a=20= PCReq=20message=20for=20T1.=20=20=20=20POINTS,=20...)=20that=20would=20be=20= included=20in=20a=20PCReq=20message=20for=20T1.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= Example=202:=20PCC1=20requests=20a=20= path=20computation=20for=20a=20TE=20LSP=20and=20also=20=20=20=20Example=202=20(in=20= band=20request):=20PCC1=20requests=20a=20path=20computation=20for=20= a=0A=20=20=20=20=20= =20=20=20=20request=20to=20gather=20the=20processing=20= time=20along=20the=20path=20computation=20=20=20=20TE=20LSP=20and=20also=20request=20to=20gather=20= the=20processing=20time=20along=20the=20path=0A=20=20=20=20=20=20=20=20=20chain=20selected=20= for=20the=20computation=20of=20T1.=20=20A=20PCReq=20message=20is=20= sent=20=20=20=20computation=20chain=20= selected=20for=20the=20computation=20of=20T1.=20=20A=20PCReq=0A=20=20=20=20=20=20=20=20=20= that=20also=20contains=20a=20MONITORING=20object=20that=20specifies=20= the=20performance=20=20=20=20= message=20is=20sent=20that=20also=20contains=20a=20MONITORING=20object=20= that=20specifies=0A= =20=20=20=20=20=20=20=20=20metric=20of=20= interest.=20=20The=20PCRep=20message=20also=20= carries=20a=20PROC-TIME=20=20= =20=20the=20performance=20metrics=20of=20= interest.=0A=20=20= =20=20=20=20=20=20=20object=20defined=20in=20= section=20Section=204.1=20that=20reports=20the=20= computed=20=0A=20=20=20=20=20=20=20=20=20metrics.=20=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= =20= =20=20Example=203:=20PCC2=20requests=20= to=20gather=20performance=20metrics=20along=20the=20=20=20=20Example=203=20(out=20= of=20band=20request):=20PCC2=20requests=20to=20gather=20= performance=0A=20=20= =20=20=20=20=20=20=20specific=20path=20computation=20chain=20= <pce1,=20pce2,=20pce3,=20pce7>.=20=20A=20PCMonreq=20=20=20=20metrics=20along=20the=20specific=20path=20= computation=20chain=20<pce1,=20pce2,=20pce3,=0A=20=20=20=20=20=20=20=20=20= message=20is=20sent=20to=20PCE1=20that=20contains=20a=20sequence=20of=20= PCE-ID=20objects=20=20=20=20pce7>.=20= =20A=20PCMonreq=20message=20is=20sent=20to=20PCE1=20that=20contains=20a=20= MONITORING=0A=20=20=20=20=20=20=20=20=20that=20identify=20= PCE1,=20PCE2,=20PCE3=20and=20PCE7=20respectively.=20=20=20=20object=20and=20= a=20sequence=20of=20PCE-ID=20objects=20that=20identify=20PCE1,=20= PCE2,=0A=20=20=20=20= =20=20=20=20=20=20PCE3=20= and=20PCE7=20respectively.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=0A=20= =20=20=20=20=20=20=20=20=20In=20all=20of=20the=20examples=20above,=20a=20PCRep=20= message=20(in-band=20request)=20or=0A=20=20=20=20=20=20=20=20=20=20PCMonReq=20message=20= (out=20of=20band=20request)=20is=20sent=20in=20response=20to=20= the=0A=20=20= =20=20=20=20=20=20=20=20request=20that=20reports=20the=20computed=20= metrics.=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=203.2.=20=20= Path=20Monitoring=20Reply=20message=20(PCMonRep)=203.2.=20=20Path=20Monitoring=20Reply=20message=20= (PCMonRep)=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20The=20= PCMonRep=20message=20is=20used=20to=20provide=20PCE=20state=20metrics=20= back=20to=20the=20=20=20=20The=20= PCMonRep=20message=20is=20used=20to=20provide=20PCE=20state=20metrics=20= back=20to=20the=0A= =20=20=20=20=20=20=20=20=20requester=20for=20"out=20of=20band"=20monitoring=20= requests.=20=20The=20Message-Type=20=20= =20=20requester=20for=20"out=20of=20band"=20monitoring=20requests.=20=20= The=20Message-Type=0A= =20=20=20=20=20=20=20=20=20field=20of=20the=20PCEP=20common=20header=20for=20= the=20PCMonRep=20message=20is=20set=20to=209=20=20=20=20field=20of=20the=20PCEP=20common=20header=20for=20= the=20PCMonRep=20message=20is=20set=20to=209=0A=20=20=20=20=20=20=20=20=20(To=20be=20confirmed=20= by=20IANA).=20=20=20=20(To=20be=20= confirmed=20by=20IANA).=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20There=20is=20one=20mandatory=20object=20that=20= MUST=20be=20included=20within=20a=20PCMonRep=20=20=20=20There=20is=20one=20mandatory=20object=20that=20= MUST=20be=20included=20within=20a=20PCMonRep=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= message:=20the=20Monitoring=20object=20(see=20= Section=204.1).=20=20If=20the=20Monitoring=20=20=20=20message:=20the=20MONITORING=20object=20(see=20Section=204.1).=20=20If=20= the=20MONITORING=0A=20=20=20=20=20=20=20=20=20object=20is=20missing,=20= the=20receiving=20PCE=20MUST=20send=20a=20PCErr=20message=20= with=20=20=20=20object=20is=20= missing,=20the=20receiving=20PCE=20MUST=20send=20a=20PCErr=20message=20= with=0A=20=20=20=20= =20=20=20=20=20Error-type=3D6=20(Mandatory=20Object=20missing)=20= and=20Error-value=3D4=20(MONITORING=20= =20=20=20Error-type=3D6=20(Mandatory=20Object=20missing)=20and=20= Error-value=3D4=20(MONITORING=0A=20=20=20=20=20=20=20=20=20Object=20= missing).=20=20=20=20Object=20= missing).=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= Other=20objects=20are=20optional.=20=20= =20=20Other=20objects=20are=20optional.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20The=20format=20of=20a=20= PCReq=20message=20is=20as=20follows:=20=20=20=20Format=20of=20a=20= PCMonReq=20(out=20of=20band=20request):=0A=20=20=20=20=20=20=20=20=20<PCMonRep=20= Message>::=3D=20<Common=20Header>=20=20=20=20<PCMonRep=20Message>::=3D=20<Common=20= Header>=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20<MONITORING>=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= <MONITORING>=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20[<RP>]=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= [<RP>]=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20[<metric-pce-list>]=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20[<metric-pce-list>]=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20where:=20=20=20= =20where:=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= <metric-pce-list>::=3D<metric-pce>[<metric-pce-list>]=20= =20=20=20= <metric-pce-list>::=3D<metric-pce>[<metric-pce-list>]=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= <metric-pce>::=3D[<PCE-ID>]= =20=20=20=20<metric-pce>::=3D<PCE-ID>=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20[<PROC-TIME>]=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= [<PROC-TIME>]=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= [<CONGESTION>]=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20[<CONGESTION>]=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= =20=20=20=20Format=20of=20a=20PCRep=20message=20with=20monitoring=20= data=20(in=20band):=0A=20=20=20=20=20=20=20=20=20=20<PCRep=20Message>=20= ::=3D=20<Common=20Header>=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20<response-list>=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20= =20=20=20= where:=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20= <response-list>::=3D<response>[<response-list>]=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20= =20=20=20=20=20=20= <response>::=3D<RP>=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20<MONITORING>=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20[<NO-PATH>]=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20[<attribute-list>]=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20[<path-list>]=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20[<metric-pce-list>]=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20= =20=20=20=20=20=20= <path-list>::=3D<path>[<path-list>]=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20= =20=20=20=20=20=20= <path>::=3D=20<ERO><attribute-list>=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20= =20=20=20= where:=0A=20= =20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20= <attribute-list>::=3D[<LSPA>]=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20[<BANDWIDTH>]=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= [<metric-list>]=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20[<IRO>]=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20= =20=20=20=20= <metric-list>::=3D<METRIC>[<metric-list>]=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20= =20=20=20=20= <metric-pce-list>::=3D<metric-pce>[<metric-pce-list>]= =0A=20=20=20=20=20=20= =20=0A=20=20=20=20=20=20=20=20=20=20=20= <metric-pce>::=3D<PCE-ID>=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20[<PROC-TIME>]=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20[<CONGESTION>]=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20The=20RP=20= object=20is=20defined=20in=20[I-D.ietf-pce-pcep].=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20= =20=20=20As=20= pointed=20out=20in=20[I-D.ietf-pce-pcep]=20several=20situation=20can=20= arise:=0A=20= =20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20o=20=20Bundle=20of=20= a=20set=20of=20independent=20and=20non-synchronized=20= path=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20computation=20requests=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20= =20=20=20o=20=20= Bundle=20of=20a=20set=20of=20independent=20and=20synchronized=20path=20= computation=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20requests=20(SVEC=20object=20defined=20= below=20required),=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20o=20=20= Bundle=20of=20a=20set=20of=20dependent=20and=20synchronized=20path=20= computation=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20requests=20(SVEC=20object=20defined=20= below=20required)=0A=20=20=20=20=20=20=20=20=20=20In=20the=20case=20of=20= a=20bundle=20of=20a=20set=20of=20request,=20the=20MONITORING=20= object=0A=20= =20=20=20=20=20=20=20=20=20SHOULD=20only=20be=20present=20in=20the=20= first=20PCReq=20or=20PCMonReq=20message=20and=20the=0A=20=20=20=20=20=20=20= =20=20=20monitoring=20= request=20applies=20to=20all=20the=20request=20of=20the=20bundle,=20even=20= in=0A=20=20= =20=20=20=20=20=20=20=20the=20case=20of=20dependent=20and/or=20= synchronized=20requests=20sent=20using=20more=0A=20=20=20=20=20=20=20= =20=20=20than=20one=20= PCReq=20or=20PCMonReq=20message.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=204.=20=20Path=20Computation=20Monitoring=20= Objects=204.=20=20Path=20Computation=20= Monitoring=20Objects=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20The=20PCEP=20objects=20defined=20in=20the=20= document=20are=20compliant=20with=20the=20PCEP=20=20=20=20The=20PCEP=20objects=20defined=20in=20the=20= document=20are=20compliant=20with=20the=20PCEP=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= object=20format=20defined=20in=20[I-D.ietf-pce-pcep],=20with=20the=20P=20flag=20= and=20the=20=20=20=20object=20= format=20defined=20in=20[I-D.ietf-pce-pcep].=20=20= The=20P=20flag=20and=20the=20I=0A=20=20=20=20=20=20=20=20=20I=20flag=20cleared=20since=20these=20flags=20are=20= exclusively=20related=20to=20path=20=20= =20=20flag=20of=20the=20PCEP=20objects=20= defined=20in=20this=20document=20SHOULD=20always=20be=0A=20=20=20=20=20=20=20=20=20= computation=20requests.=20=20=20=20set=20to=200=20on=20transmission=20and=20MUST=20= be=20ignored=20on=20receipt=20since=20these=0A=20=20=20=20=20=20=20= =20=20=20flags=20are=20exclusively=20related=20= to=20path=20computation=20requests.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20Several=20objects=20are=20defined=20in=20this=20= section=20that=20can=20be=20carried=20= =20=20=20Several=20objects=20are=20defined=20in=20this=20section=20that=20= can=20be=20carried=0A= =20=20=20=20=20=20=20=20=20within=20the=20PCEP=20PCReq=20or=20PCRep=20= messages=20defined=20in=20=20=20=20= within=20the=20PCEP=20PCReq=20or=20PCRep=20messages=20defined=20= in=0A=20=20=20=20=20= =20=0A=20=20=20=20=20=20= =20= =20=20[I-D.ietf-pce-pcep]=20in=20case=20of=20"in=20band"=20monitoring=20= requests.=20=20In=20=20=20=20[I-D.ietf-pce-pcep]=20in=20case=20of=20"in=20= band"=20monitoring=20requests=20(the=20= PCC=0A=20=20=20=20= =20=20=20=20=20case=20of=20"out=20of=20= band"=20monitoring=20requests,=20the=20objects=20defined=20= in=20=20=20=20requests=20the=20= computation=20of=20the=20TE=20LSP=20in=20addition=20to=20gathering=20= PCE=0A=20=20=20=20= =20=20=20=20=20this=20section=20are=20= carried=20within=20PCMonReq=20and=20PCMonRep=20messages.=20= =20=20=20state=20metrics).=20=20In=20case=20of=20"out=20of=20= band"=20monitoring=20requests,=20= the=0A=20=20= =20=20=20=20=20=20=20Conversely,=20if=20= the=20PCC=20requests=20the=20computation=20of=20the=20TE=20LSP=20= in=20=20=20=20objects=20defined=20in=20this=20section=20are=20carried=20= within=20PCMonReq=20and=0A=20=20=20=20=20=20=20=20=20= addition=20to=20gathering=20PCE=20state=20metrics= =20(i.e.=20=20"In=20band"=20requests),=20= =20=20=20PCMonRep=20messages.=0A=20=20=20=20=20=20=20=20=20these=20objects=20are=20carried=20= within=20PCReq=20and=20PCRep=20messages.=20=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=204.1.=20=20= MONITORING=20Object=204.1.=20=20= MONITORING=20Object= =0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20The=20= MONITORING=20object=20MUST=20be=20present=20within=20PCMonReq=20and=20= PCMonRep=20=20=20=20The=20MONITORING=20= object=20MUST=20be=20present=20within=20PCMonReq=20and=20= PCMonRep=0A=20=20=20= =20=20=20=20=20=20messages=20("out=20of=20band"=20monitoring=20= requests)=20and=20MAY=20be=20carried=20=20=20=20messages=20("out=20of=20band"=20monitoring=20= requests)=20and=20MAY=20be=20carried=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= within=20PCERep=20and=20PCReq=20messages=20= ("in=20band"=20monitoring=20requests).=20=20=20=20within=20PCRep=20and=20PCReq=20messages=20("in=20= band"=20monitoring=20requests).=0A=20=20=20=20=20=20=20=20=20There=20SHOULD=20NOT=20= be=20more=20than=20one=20instance=20of=20the=20MONITORING=20= object:=20=20=20=20There=20SHOULD=20= NOT=20be=20more=20than=20one=20instance=20of=20the=20MONITORING=20= object:=0A=20=20=20= =20=20=20=20=20=20if=20more=20than=20one=20instance=20of=20the=20= MONITORING=20object=20is=20present,=20the=20=20=20=20if=20more=20than=20one=20instance=20of=20the=20= MONITORING=20object=20is=20present,=20the=0A=20=20=20=20=20=20=20=20=20recipient=20MUST=20= process=20the=20first=20instance=20and=20MUST=20ignore=20other=20= =20=20=20recipient=20MUST=20process=20the=20= first=20instance=20and=20MUST=20ignore=20other=0A=20=20=20=20=20=20=20=20=20instances.=20= =20=20=20instances.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20The=20MONITORING=20object=20is=20used=20to=20= specify=20the=20set=20of=20requested=20PCE=20=20=20=20The=20MONITORING=20object=20is=20used=20to=20= specify=20the=20set=20of=20requested=20PCE=0A=20=20=20=20=20=20=20=20=20state=20= metrics.=20=20=20=20state=20= metrics.=0A=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20=20=20=20The=20= MONITORING=20Object-Class=20is=20to=20be=20assigned=20by=20IANA=20= (recommended=20=20=20=20The=20= MONITORING=20Object-Class=20is=20to=20be=20assigned=20by=20IANA=20= (recommended=0A=20= =20=20=20=20=20=20=20=20value=3D19)=20= =20=20=20value=3D19)=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20= skipping=20= to=20change=20at=20page=209,=20line=2035=20= skipping=20to=20change=20= at=20page=2013,=20line=2033=0A=20= =20=20=20=20=20=20=20=20PCE-ID=20object=20in=20the=20corresponding=20= reply.=20=20The=20L=20bit=20MUST=20always=20be=20=20=20=20PCE-ID=20object=20in=20the=20corresponding=20= reply.=20=20The=20L=20bit=20MUST=20always=20be=0A=20=20=20=20=20=20=20=20=20ignored=20in=20a=20= PCMonRep=20or=20PCRep=20message.=20=20= =20=20ignored=20in=20a=20PCMonRep=20or=20PCRep=20message.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20G=20(General)=20-=201=20= bit:=20when=20set,=20this=20indicates=20that=20the=20monitoring=20= =20=20=20G=20(General)=20-=201=20bit:=20when=20= set,=20this=20indicates=20that=20the=20monitoring=0A=20=20=20=20=20=20=20=20=20= request=20is=20a=20general=20monitoring=20request.=20=20When=20the=20= requested=20=20=20=20request=20is=20= a=20general=20monitoring=20request.=20=20When=20the=20requested=0A=20=20=20=20=20=20=20=20=20= performance=20metric=20is=20specific,=20the=20G=20bit=20MUST=20be=20= cleared.=20=20The=20G=20bit=20=20=20=20= performance=20metric=20is=20specific,=20the=20G=20bit=20MUST=20be=20= cleared.=20=20The=20G=20bit=0A=20=20=20=20=20=20=20=20=20MUST=20always=20be=20= ignored=20in=20a=20PCMonRep=20or=20PCRep=20message.=20=20=20=20MUST=20always=20be=20ignored=20in=20a=20= PCMonRep=20or=20PCRep=20message.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20P=20(Processing=20Time)=20-=201=20bit:=20the=20P=20= bit=20of=20the=20MONITORING=20object=20=20=20=20P=20(Processing=20Time)=20-=201=20bit:=20the=20= P=20bit=20of=20the=20MONITORING=20object=0A=20=20=20=20=20=20=20=20=20carried=20in=20a=20= PCMonReq=20or=20a=20PCReq=20message=20is=20set=20to=20indicate=20that=20= the=20=20=20=20carried=20in=20a=20= PCMonReq=20or=20a=20PCReq=20message=20is=20set=20to=20indicate=20that=20= the=0A=20=20=20=20= =20=20=0A=20=20=20=20=20=20= =20= =20=20processing=20times=20is=20a=20metric=20of=20interest,=20in=20which=20case=20a=20= PROC-TIME=20=20=20=20processing=20= times=20is=20a=20metric=20of=20interest.=20=20= If=20allowed=20by=20policy,=20a=0A=20=20=20=20=20=20=20=20=20object=20MUST=20be=20= inserted=20in=20the=20corresponding=20PCMonRep=20or=20PCRep=20= =20=20=20PROC-TIME=20object=20MUST=20be=20= inserted=20in=20the=20corresponding=20PCMonRep=20or=0A=20=20=20=20=20=20=20=20=20= message.=20=20The=20P=20bit=20MUST=20always=20be=20ignored=20in=20a=20= PCMonRep=20or=20PCRep=20=20=20=20= PCRep=20message.=20=20The=20P=20bit=20MUST=20always=20be=20ignored=20in=20= a=20PCMonRep=20or=0A= =20=20=20=20=20=20=20=20=20message.=20= =20=20=20PCRep=20message.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20C=20(Congestion)=20-=201=20bit:=20The=20C=20bit=20= of=20the=20MONITORING=20object=20carried=20in=20=20=20=20C=20(Congestion)=20-=201=20bit:=20The=20C=20bit=20= of=20the=20MONITORING=20object=20carried=20in=0A=20=20=20=20=20=20=20=20=20a=20PCMonReq=20or=20a=20= PCReq=20message=20is=20set=20to=20indicate=20that=20the=20= congestion=20=20=20=20a=20PCMonReq=20= or=20a=20PCReq=20message=20is=20set=20to=20indicate=20that=20the=20= congestion=0A=20=20= =20=20=20=20=20=20=20status=20is=20a=20metric=20of=20interest,=20in=20= which=20case=20a=20CONGESTION=20object=20=20=20=20status=20is=20a=20metric=20of=20interest,=20in=20= which=20case=20a=20CONGESTION=20object=0A=20=20=20=20=20=20=20=20=20MUST=20be=20inserted=20= in=20the=20corresponding=20PCMonRep=20or=20PCRep=20message.=20=20= The=20=20=20=20MUST=20be=20inserted=20= in=20the=20corresponding=20PCMonRep=20or=20PCRep=20message.=20=20= The=0A=20=20=20=20= =20=20=20=20=20C=20bit=20MUST=20always=20be=20ignored=20in=20a=20= PCMonRep=20or=20PCRep=20message.=20=20= =20=20C=20bit=20MUST=20always=20be=20ignored=20in=20a=20PCMonRep=20or=20= PCRep=20message.=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20I=20= (Incomplete)=20-=201=20bit:=20If=20a=20PCE=20supports=20a=20received=20= PCMonReq=20message=20=20=20=20I=20= (Incomplete)=20-=201=20bit:=20If=20a=20PCE=20supports=20a=20received=20= PCMonReq=20message=0A= =20=20=20=20=20=20=20=20=20and=20that=20message=20does=20not=20trigger=20= any=20policy=20violation,=20but=20the=20PCE=20=20=20=20and=20that=20message=20does=20not=20trigger=20= any=20policy=20violation,=20but=20the=20PCE=0A=20=20=20=20=20=20=20=20=20cannot=20provide=20any=20= of=20the=20set=20of=20requested=20performance=20metrics=20for=20= =20=20=20cannot=20provide=20any=20of=20the=20= set=20of=20requested=20performance=20metrics=20for=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20= skipping=20= to=20change=20at=20page=2010,=20line=2026=20= skipping=20to=20change=20= at=20page=2014,=20line=2024=0A=20= =20=20=20=20=20=20=20=20PCEP-ID=20of=20the=20replying=20PCE.=20=20A=20= PCEP=20implementation=20SHOULD=20checkpoint=20=20=20=20PCEP-ID=20of=20the=20replying=20PCE.=20=20A=20= PCEP=20implementation=20SHOULD=20checkpoint=0A=20=20=20=20=20=20=20=20=20the=20= Monitoring-id-number=20of=20pending=20monitoring=20requests=20in=20case=20= of=20=20=20=20the=20= Monitoring-id-number=20of=20pending=20monitoring=20requests=20in=20case=20= of=0A=20=20=20=20=20= =20=20= =20=20restart=20thus=20avoiding=20the=20re-use=20of=20a=20= Monitoring-id-number=20of=20an=20in-=20=20=20=20restart=20thus=20avoiding=20the=20re-use=20of=20= a=20Monitoring-id-number=20of=20an=20in-=0A=20=20=20=20=20=20=20=20=20process=20monitoring=20= request.=20=20=20=20process=20= monitoring=20request.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20Unassigned=20bits=20are=20considered=20as=20= reserved=20and=20MUST=20be=20set=20to=20zero=20on=20=20=20=20Unassigned=20bits=20are=20considered=20as=20= reserved=20and=20MUST=20be=20set=20to=20zero=20on=0A=20=20=20=20=20=20=20=20=20= transmission=20and=20ignored=20on=20reception.=20=20=20=20transmission=20and=20ignored=20on=20= reception.=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20No=20= optional=20TLVs=20are=20currently=20defined.=20=20=20=20No=20optional=20TLVs=20are=20currently=20= defined.=0A=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= 4.2.=20=20PCEP-ID=20= Object=204.2.=20=20PCE-ID=20= Object=0A=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= =20= =20=20The=20PCEP-ID=20Object=20is=20used=20= to=20specify=20a=20PCE's=20IP=20address.=20=20=20=20The=20PCE-ID=20Object=20is=20used=20to=20= specify=20a=20PCE's=20IP=20address.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20A=20set=20of=20PCEP-ID=20objects=20may=20be=20inserted=20within=20= a=20PCReq=20or=20a=20PCMonReq=20=20=20= =20A=20set=20of=20PCE-ID=20objects=20may=20be=20inserted=20within=20a=20= PCReq=20or=20a=20PCMonReq=0A=20=20=20=20=20=20=20=20=20message=20to=20specify=20= the=20PCE=20for=20which=20PCE=20state=20metrics=20are=20= requested=20=20=20=20message=20to=20= specify=20the=20PCE=20for=20which=20PCE=20state=20metrics=20are=20= requested=0A=20=20= =20=20=20=20=20=20=20and=20in=20a=20PCMonRep=20or=20a=20PCRep=20= message=20to=20record=20the=20IP=20address=20of=20the=20= =20=20=20and=20in=20a=20PCMonRep=20or=20a=20= PCRep=20message=20to=20record=20the=20IP=20address=20of=20the=0A=20=20=20=20=20=20=20=20=20PCE=20= reporting=20PCE=20state=20metrics=20or=20that=20was=20involved=20in=20= the=20path=20=20=20=20PCE=20= reporting=20PCE=20state=20metrics=20or=20that=20was=20involved=20in=20= the=20path=0A=20=20= =20=20=20=20=20=20=20computation=20chain.=20=20=20=20computation=20chain.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20Two=20PCEP-ID=20= objects=20(for=20IPv4=20and=20IPv6)=20are=20defined.=20=20PCEP-ID=20Object-=20=20=20=20Two=20PCE-ID=20= objects=20(for=20IPv4=20and=20IPv6)=20are=20defined.=20=20PCE-ID=20Object-=0A=20=20=20=20=20=20=20=20=20Class=20is=20to=20be=20= assigned=20by=20IANA=20(recommended=20value=3D20)=20PCEP-ID=20=20= =20=20Class=20is=20to=20be=20assigned=20by=20IANA=20(recommended=20= value=3D20)=20PCE-ID=20Object-=0A=20=20=20=20=20=20=20=20=20Object-Type=20is=20to=20be=20assigned=20= by=20IANA=20(recommended=20value=3D1=20for=20IPv4=20=20=20=20Type=20is=20to=20= be=20assigned=20by=20IANA=20(recommended=20value=3D1=20for=20IPv4=20and=20= 2=0A=20=20=20=20=20= =20=20=20=20and=202=20for=20IPv6)=20=20=20=20for=20IPv6)=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20The=20format=20of=20the=20PCEP-ID=20Object=20is=20as=20follows:=20= =20=20=20The=20format=20of=20the=20PCE-ID=20= Object=20is=20as=20follows:=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20The=20format=20of=20the=20PCEP-ID=20object=20body=20for=20IPv4=20and=20IPv6=20= are=20as=20=20=20=20The=20format=20= of=20the=20PCE-ID=20object=20body=20for=20IPv4=20and=20IPv6=20are=20= as=0A=20=20=20=20=20= =20=20= =20=20follows:=20=20=20=20= follows:=0A=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20= 0=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=201=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=202=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=203=20=20=20= =20=200=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=201=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=202=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=203=0A=20=20=20=20=20=20=20=20=20=200=201=202=203=204=20= 5=206=207=208=209=200=201=202=203=204=205=206=207=208=209=200=201=202=20= 3=204=205=206=207=208=209=200=201=20=20= =20=20=200=201=202=203=204=205=206=207=208=209=200=201=202=203=204=205=20= 6=207=208=209=200=201=202=203=204=205=206=207=208=209=200=201=0A=20=20=20=20=20=20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= =20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=20=20=20=20=20=20=20=20=20|=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20IPv4=20Address=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20|=20=20=20=20|=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= IPv4=20Address=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20|=0A=20= =20=20=20=20=20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= =20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=200=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=201=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=202=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=203=20=20=20=20=200=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=201=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=202=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=203=0A=20= =20=20=20=20=20=20=20=20=200=201=202=203=204=205=206=207=208=209=200=201=20= 2=203=204=205=206=207=208=209=200=201=202=203=204=205=206=207=208=209=20= 0=201=20=20=20=20=200=201=202=203=20= 4=205=206=207=208=209=200=201=202=203=204=205=206=207=208=209=200=201=20= 2=203=204=205=206=207=208=209=200=201=0A=20=20=20=20=20=20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= =20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=20=20=20=20=20=20=20=20=20|=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20|=20=20=20=20|=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= |=0A=20=20=20=20=20= =20=20= =20=20|=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20IPv6=20Address=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20|=20=20=20= =20|=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20IPv6=20Address=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20|=0A=20=20=20=20=20=20=20=20=20|=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20|=20=20=20=20|=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20|=0A=20=20=20=20=20=20=20=20=20|=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20|=20=20=20=20|=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20|=0A=20=20=20=20=20=20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= =20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= =20= =20=20The=20PCEP-ID=20object=20body=20= has=20a=20fixed=20length=20of=204=20octets=20for=20IPv4=20and=20= =20=20=20The=20PCE-ID=20object=20body=20has=20a=20fixed=20= length=20of=204=20octets=20for=20IPv4=20and=2016=0A=20=20=20=20=20=20=20=20=20= 16=20octets=20for=20IPv6.=20=20=20=20= octets=20for=20IPv6.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20When=20a=20dynamic=20discovery=20mechanism=20is=20= used=20for=20PCE=20discovery,=20a=20PCE=20=20=20=20When=20a=20dynamic=20discovery=20mechanism=20is=20= used=20for=20PCE=20discovery,=20a=20PCE=0A=20=20=20=20=20=20=20=20=20advertises=20its=20PCE=20= address=20in=20the=20PCE-ADDRESS=20sub-TLV=20defined=20in=20= =20=20=20advertises=20its=20PCE=20address=20= in=20the=20PCE-ADDRESS=20sub-TLV=20defined=20in=0A=20=20=20=20=20=20=20=20=20= [RFC5088]=20and=20[RFC5089].=20=20A=20PCC=20MUST=20use=20this=20address=20= in=20PCReq=20and=20=20=20=20= [RFC5088]=20and=20[RFC5089].=20=20A=20PCC=20MUST=20use=20this=20address=20= in=20PCReq=20and=0A= =20=20=20=20=20=20=20=20=20PCMonReq=20messages=20and=20a=20PCE=20MUST=20= also=20use=20this=20address=20in=20PCRep=20and=20=20=20=20PCMonReq=20messages=20and=20a=20PCE=20MUST=20= also=20use=20this=20address=20in=20PCRep=20and=0A=20=20=20=20=20=20=20=20=20PCMonRep=20= messages.=20=20=20=20PCMonRep=20= messages.=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=204.3.=20=20= PROC-TIME=20Object=204.3.=20=20= PROC-TIME=20Object=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20If=20= allowed=20by=20policy,=20the=20PCE=20includes=20a=20PROC-TIME=20object=20= within=20a=20=20=20=20If=20allowed=20= by=20policy,=20the=20PCE=20includes=20a=20PROC-TIME=20object=20within=20= a=0A=20=20=20=20=20= =20=20= =0A=20=20= =20=20=20=20skipping=20to=20change=20at=20page=20= 11,=20line=2047=20skipping=20to=20change=20at=20page=20= 15,=20line=2047=0A=20=20=20=20=20=20=20=20=20= related=20metrics.=20=20=20=20= related=20metrics.=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=201)=20= Case=20of=20general=20monitoring=20requests=20=20=20=201)=20Case=20of=20general=20monitoring=20= requests=0A=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20=20=20=20A=20= PCC=20may=20request=20processing=20time=20metrics=20for=20general=20= monitoring=20=20=20=20A=20PCC=20may=20= request=20processing=20time=20metrics=20for=20general=20= monitoring=0A=20=20= =20=20=20=20=20=20=20requests=20(e.g.=20the=20PCC=20may=20want=20to=20= know=20the=20minimum,=20maximum=20and=20=20=20=20requests=20(e.g.=20the=20PCC=20may=20want=20to=20= know=20the=20minimum,=20maximum=20and=0A=20=20=20=20=20=20=20=20=20average=20processing=20= times=20on=20a=20particular=20PCE).=20=20In=20this=20case,=20= general=20=20=20=20average=20= processing=20times=20on=20a=20particular=20PCE).=20=20In=20this=20case,=20= general=0A=20=20=20= =20=20=20=20=20=20requests=20can=20only=20be=20made=20by=20using=20= PCMonReq/PCMonRep=20messages.=20=20The=20=20=20=20requests=20can=20only=20be=20made=20by=20using=20= PCMonReq/PCMonRep=20messages.=20=20The=0A=20=20=20=20=20=20=20=20=20= Current-processing-time=20field=20(as=20explained=20below)=20is=20= exclusively=20=20=20=20= Current-processing-time=20field=20(as=20explained=20below)=20is=20= exclusively=0A=20=20= =20=20=20=20=20=20=20used=20for=20specific=20monitoring=20requests=20= and=20MUST=20be=20cleared=20for=20general=20=20=20=20used=20for=20specific=20monitoring=20requests=20= and=20MUST=20be=20cleared=20for=20general=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= monitoring=20requests.=20=20The=20algorithm(s)=20used=20by=20a=20PCE=20to=20compute=20= the=20=20=20=20monitoring=20= requests.=20=20The=20algorithms=20used=20= by=20a=20PCE=20to=20compute=20the=0A=20=20=20=20=20=20=20=20=20Min,=20Average,=20Max=20= and=20Variance=20of=20the=20processing=20times=20are=20out=20of=20= the=20=20=20=20Min,=20Average,=20Max=20= and=20Variance=20of=20the=20processing=20times=20are=20out=20of=20= the=0A=20=20=20=20= =20=20=20=20=20scope=20of=20this=20document=20(A=20PCE=20may=20= decide=20to=20compute=20the=20minimum=20=20=20=20scope=20of=20this=20document=20(A=20PCE=20may=20= decide=20to=20compute=20the=20minimum=0A=20=20=20=20=20=20=20=20=20processing=20time=20= over=20a=20period=20of=20times,=20for=20the=20last=20N=20path=20= =20=20=20processing=20time=20over=20a=20= period=20of=20times,=20for=20the=20last=20N=20path=0A=20=20=20=20=20=20=20=20=20= computation=20requests,=20...).=20=20= =20=20computation=20requests,=20...).=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=202)=20Case=20of=20specific=20monitoring=20= requests=20=20=20=202)=20Case=20of=20= specific=20monitoring=20requests=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20In=20the=20case=20of=20a=20specific=20request,=20= the=20algorithm(s)=20used=20by=20a=20PCE=20= to=20=20=20=20In=20the=20case=20of=20= a=20specific=20request,=20the=20algorithms= =20used=20by=20a=20PCE=20to=0A=20=20=20=20=20=20=20=20=20compute=20the=20= Procesing-time=20metrics=20are=20out=20of=20the=20scope=20of=20= this=20=20=20=20compute=20the=20= Procesing-time=20metrics=20are=20out=20of=20the=20scope=20of=20= this=0A=20=20=20=20= =20=20=20=20=20document=20but=20a=20flag=20is=20specified=20= that=20is=20used=20to=20indicate=20to=20the=20=20=20=20document=20but=20a=20flag=20is=20specified=20= that=20is=20used=20to=20indicate=20to=20the=0A=20=20=20=20=20=20=20=20=20requester=20whether=20= the=20processing=20time=20value=20was=20estimated=20or=20= =20=20=20requester=20whether=20the=20= processing=20time=20value=20was=20estimated=20or=0A=20=20=20=20=20=20=20=20=20= computed.=20=20The=20PCE=20may=20either=20(1)=20estimate=20the=20= processing=20time=20=20=20=20= computed.=20=20The=20PCE=20may=20either=20(1)=20estimate=20the=20= processing=20time=0A= =20=20=20=20=20=20=20=20=20without=20performing=20an=20actual=20path=20= computation=20or=20(2)=20effectively=20=20=20=20without=20performing=20an=20actual=20path=20= computation=20or=20(2)=20effectively=0A=20=20=20=20=20=20=20=20=20perform=20the=20= computation=20to=20report=20the=20processing=20time.=20=20In=20the=20= former=20=20=20=20perform=20the=20= computation=20to=20report=20the=20processing=20time.=20=20In=20the=20= former=0A=20=20=20= =20=20=20=20=20=20case,=20the=20E=20bit=20of=20the=20PROC-TIME=20= object=20MUST=20be=20set.=20=20The=20G=20bit=20MUST=20=20=20=20case,=20the=20E=20bit=20of=20the=20PROC-TIME=20= object=20MUST=20be=20set.=20=20The=20G=20bit=20MUST=0A=20=20=20=20=20=20=20=20=20be=20= cleared=20and=20the=20Min-processing-time,=20Max-processing-time,=20= Average-=20=20=20=20be=20cleared=20= and=20the=20Min-processing-time,=20Max-processing-time,=20= Average-=0A=20=20=20= =20=20=20=20=20=20processing-time=20and=20Variance-processing-time=20= MUST=20be=20set=20to=20=20=20=20= processing-time=20and=20Variance-processing-time=20MUST=20be=20set=20= to=0A=20=20=20=20=20= =20=20= =20=200x00000000.=20=20=20=20= 0x00000000.=0A=20=20= =20=20=20=20= =20=0A=20= =20=20=20=20=20skipping=20to=20change=20at=20page=20= 12,=20line=2047=20skipping=20to=20change=20at=20page=20= 16,=20line=2047=0A=20=20=20=20=20=20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= =20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=20=20=20=20=20=20=20=20=20|=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Min-processing-time=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20|=20=20=20=20|=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Min-processing-time=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20|=0A=20=20=20= =20=20=20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= =20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=20=20=20=20=20=20=20=20=20|=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Max-processing-time=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20|=20=20=20=20|=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Max-processing-time=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20|=0A=20=20=20= =20=20=20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= =20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=20=20=20=20=20=20=20=20=20|=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Average-processing=20time=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20|=20=20=20=20|=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Average-processing=20= time=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=0A=20=20=20=20=20=20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= =20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=20=20=20=20=20=20=20=20=20|=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Variance-processing-time=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= |=20=20=20=20|=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Variance-processing-time=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20|=0A=20=20=20=20=20=20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= =20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= Flags:=2018=20bits=20-=20No=20Flags=20= are=20currently=20defined:=20=20= =20=20Flags:=2016=20bits=20-=20one=20flag=20= is=20currently=20defined:=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20E=20(Estimated)=20-=201=20bit:=20when=20set,=20= this=20indicates=20that=20the=20reported=20=20=20=20E=20(Estimated)=20-=201=20bit:=20when=20set,=20= this=20indicates=20that=20the=20reported=0A=20=20=20=20=20=20=20=20=20metric=20value=20is=20= based=20on=20estimated=20processing=20time=20as=20opposed=20to=20= =20=20=20metric=20value=20is=20based=20on=20= estimated=20processing=20time=20as=20opposed=20to=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= =20= =20=20actual=20computation(s).=20= =20=20=20actual=20computations.=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20Unassigned=20= bits=20are=20considered=20as=20reserved=20and=20MUST=20be=20set=20to=20= zero=20on=0A= =20=20=20=20=20=20=20=20=20=20transmission.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20Current-processing-time:=20This=20field=20= indicates=20in=20milliseconds=20the=20= =20=20=20Current-processing-time:=20This=20field=20indicates=20in=20= milliseconds=20the=0A= =20=20=20=20=20=20=20=20=20processing=20time=20for=20the=20path=20= computation=20of=20interest=20characterized=20in=20=20=20=20processing=20time=20for=20the=20path=20= computation=20of=20interest=20characterized=20in=0A=20=20=20=20=20=20=20=20=20the=20= corresponding=20PCMonReq=20message.=20= =20=20=20the=20corresponding=20PCMonReq=20message.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20Min-processing-time:=20= This=20field=20indicates=20in=20milliseconds=20the=20minimum=20= =20=20=20Min-processing-time:=20This=20field=20= indicates=20in=20milliseconds=20the=20minimum=0A=20=20=20=20=20=20=20=20=20processing=20= time.=20=20=20=20processing=20= time.=0A=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20=20=20=20= Max-processing-time:=20This=20field=20indicates=20in=20milliseconds=20= the=20maximum=20=20=20=20= Max-processing-time:=20This=20field=20indicates=20in=20milliseconds=20= the=20maximum=0A=20= =20=20=20=20=20=20=20=20processing=20time.=20=20=20=20processing=20time.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20Average-processing-time:=20This=20field=20= indicates=20in=20milliseconds=20the=20= =20=20=20Average-processing-time:=20This=20field=20indicates=20in=20= milliseconds=20the=0A= =20=20=20=20=20=20=20=20=20average=20processing=20time.=20=20=20=20average=20processing=20time.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20= Variance-processing-time:=20This=20field=20indicates=20in=20milliseconds=20= the=20=20=20=20= Variance-processing-time:=20This=20field=20indicates=20in=20milliseconds=20= the=0A=20=20=20=20= =20=20=20=20=20variance=20of=20the=20processing=20= times.=20=20=20=20variance=20of=20= the=20processing=20times.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20Unassigned=20bits=20= are=20considered=20as=20reserved=20and=20MUST=20be=20set=20to=20zero=20= on=20=0A=20=20=20=20=20=20=20=20=20transmission.=20=0A= =20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20More=20granularity=20= may=20be=20introduced=20in=20further=20revision=20of=20= this=20=0A=20=20=20=20=20=20=20=20=20document=20to=20get=20a=20monitoring=20metric=20= for=20a=20general=20request=20of=20a=20=0A= =20=20=20=20=20=20=20=20=20particular=20class=20= (e.g.=20all=20PCReq=20of=20priority=20X).=20=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=0A=20=20=20=20=20=204.4.=20=20= CONGESTION=20Object=204.4.=20=20= CONGESTION=20Object= =0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20The=20= CONGESTION=20object=20MUST=20be=20present=20within=20a=20PCMonRep=20or=20= a=20PCRep=20=20=20=20The=20= CONGESTION=20object=20MUST=20be=20present=20within=20a=20PCMonRep=20or=20= a=20PCRep=0A=20=20= =20=20=20=20=20=20=20message=20if=20the=20C=20bit=20of=20the=20= MONITORING=20object=20carried=20within=20the=20=20=20=20message=20if=20the=20C=20bit=20of=20the=20= MONITORING=20object=20carried=20within=20the=0A=20=20=20=20=20=20=20=20=20corresponding=20= PCMonReq=20or=20PCReq=20message=20is=20set.=20=20The=20= CONGESTION=20=20=20=20corresponding=20= PCMonReq=20or=20PCReq=20message=20is=20set.=20=20The=20= CONGESTION=0A=20=20= =20=20=20=20=20=20=20object=20is=20used=20to=20report=20a=20PCE=20= processing=20congestion=20state.=20=20The=20=20=20=20object=20is=20used=20to=20report=20a=20PCE=20= processing=20congestion=20state.=20=20The=0A=20=20=20=20=20=20=20=20=20CONGESTION=20= Object-Class=20is=20to=20be=20assigned=20by=20IANA=20= (recommended=20=20=20=20CONGESTION=20= Object-Class=20is=20to=20be=20assigned=20by=20IANA=20= (recommended=0A=20= =20=20=20=20=20=20=20=20value=3D22)=20The=20CONGESTION=20Object-Type=20= is=20to=20be=20assigned=20by=20IANA=20= =20=20=20value=3D22)=20The=20CONGESTION=20Object-Type=20is=20to=20be=20= assigned=20by=20IANA=0A=20=20=20=20=20=20=20=20=20(recommended=20= value=3D1)=20=20=20=20(recommended=20= value=3D1)=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20The=20= format=20of=20the=20CONGESTION=20object=20body=20is=20as=20= follows:=20=20=20=20The=20format=20= of=20the=20CONGESTION=20object=20body=20is=20as=20follows:=0A=20=20=20=20=20=20=20=20=200=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=201=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=202=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=203=20=20=20=20= 0=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=201=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=202=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=203=0A=20=20=20=20=20=20=20=20=200=201=202=203=204=205=20= 6=207=208=209=200=201=202=203=204=205=206=207=208=209=200=201=202=203=20= 4=205=206=207=208=209=200=201=20=20=20= =200=201=202=203=204=205=206=207=208=209=200=201=202=203=204=205=206=207=20= 8=209=200=201=202=203=204=205=206=207=208=209=200=201=0A=20=20=20=20=20=20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= =20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= =20= =20=20|C|=20=20=20=20=20=20=20=20Reserved=20=20=20= =20=20=20=20=20=20=20=20=20=20|=20=20=20=20Congestion=20Duration=20=20= =20=20=20=20=20=20|=20=20=20=20= |=20=20=20Flags=20=20=20=20=20|C|=20=20=20= Reserved=20=20=20=20|=20=20=20=20=20=20Congestion=20Duration=20=20= =20=20=20=20|=0A=20= =20=20=20=20=20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= =20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20Flags:=208=20= bits=20-=20one=20flag=20is=20currently=20defined:=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20C=20(Congestion)=20-=20= 1=20bit:=20when=20set,=20this=20indicates=20that=20PCE=20is=20= =20=20=20C=20(Congestion)=20-=201=20bit:=20= when=20set,=20this=20indicates=20that=20PCE=20is=0A=20=20=20=20=20=20=20=20=20= congested,=20in=20which=20case=20the=20congestion=20duration=20may=20be=20= non=20nul.=20=20=20=20congested,=20= in=20which=20case=20the=20congestion=20duration=20may=20be=20non=20= nul.=0A=20=20=20=20= =20=20=20=20=20When=20cleared=20this=20indicates=20that=20the=20= PCE=20is=20not=20congested=20and=20the=20=20=20=20When=20cleared=20this=20indicates=20that=20the=20= PCE=20is=20not=20congested=20and=20the=0A=20=20=20=20=20=20=20=20=20"Congestion=20= Duration"=20field=20MUST=20be=20set=20to=200x0000.=20=20=20=20"Congestion=20Duration"=20field=20MUST=20be=20= set=20to=200x0000.=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= Congestion=20duration=20-=2016=20bits:=20This=20field=20indicates=20in=20= seconds=20the=20=20=20=20Congestion=20= duration=20-=2016=20bits:=20This=20field=20indicates=20in=20seconds=20= the=0A=20=20=20=20= =20=20=20=20=20estimated=20congestion=20duration.=20= =20=20=20estimated=20congestion=20= duration.=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= =20=20=20=20It=20is=20worth=20noting=20that=20a=20PCE=20along=20a=20= PCE=20chain=20involved=20in=20the=0A=20=20=20=20=20=20=20=20=20=20monitoring=20request=20= may=20decide=20to=20learn=20from=20the=20congestion=0A=20=20=20=20=20=20=20= =20=20=20= information=20received=20by=20one=20of=20downstream=20PCE=20in=20the=20= chain.=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=205.=20=20= Policy=205.=20=20Policy=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20The=20receipt=20of=20a=20= PCMonReq=20message=20may=20trigger=20a=20policy=20violation=20= on=20=20=20=20The=20receipt=20of=20a=20= PCMonReq=20message=20may=20trigger=20a=20policy=20violation=20on=0A=20=20=20=20=20=20=20=20=20= some=20PCE=20in=20which=20case=20the=20PCE=20MUST=20send=20a=20PCErr=20= message=20with=20Error-=20=20=20=20= some=20PCE=20in=20which=20case=20the=20PCE=20MUST=20send=20a=20PCErr=20= message=20with=20Error-=0A=20=20=20=20=20=20=20=20=20Type=3D5=20and=20= Error-value=3D3=20(To=20be=20Confirmed=20by=20IANA).=20=20=20=20Type=3D5=20and=20Error-value=3D3=20(To=20be=20= Confirmed=20by=20IANA).=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=206.=20=20Elements=20of=20Procedure=206.=20=20Elements=20of=20Procedure=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20I=20bit=20processing:=20= as=20indicated=20in=20section=20Section=204.1,=20if=20a=20PCE=20= =20=20=20I=20bit=20processing:=20as=20= indicated=20in=20section=20Section=204.1,=20if=20a=20PCE=0A=20=20=20=20=20=20=20=20=20= supports=20a=20received=20PCMonReq=20message=20and=20that=20message=20= does=20not=20=20=20=20supports=20a=20= received=20PCMonReq=20message=20and=20that=20message=20does=20= not=0A=20=20=20=20= =20=20=20=20=20trigger=20any=20policy=20violation,=20but=20the=20= PCE=20cannot=20provide=20any=20of=20the=20=20=20=20trigger=20any=20policy=20violation,=20but=20the=20= PCE=20cannot=20provide=20any=20of=20the=0A=20=20=20=20=20=20=20=20=20set=20of=20requested=20= performance=20metrics=20for=20unspecified=20reasons,=20the=20= PCE=20=20=20=20set=20of=20requested=20= performance=20metrics=20for=20unspecified=20reasons,=20the=20PCE=0A=20=20=20=20=20=20=20=20=20= MUST=20set=20the=20I=20bit.=20=20Once=20set,=20the=20I=20bit=20MUST=20= NOT=20be=20changed=20by=20a=20=20=20=20= MUST=20set=20the=20I=20bit.=20=20Once=20set,=20the=20I=20bit=20MUST=20= NOT=20be=20changed=20by=20a=0A=20=20=20=20=20=20=20=20=20receiving=20= PCE.=20=20=20=20receiving=20= PCE.=0A=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= =20= =20=20Reception=20of=20a=20PCMonReq=20message:=20= upon=20receiving=20a=20PCMonReq=20message:=20=20=20=20Upon=20= receiving=20a=20PCMonReq=20message:=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=201)=20As=20specified=20in=20[I-D.ietf-pce-pcep],=20= if=20the=20PCE=20does=20not=20support=20=20=20=201)=20As=20specified=20in=20[I-D.ietf-pce-pcep],=20= if=20the=20PCE=20does=20not=20support=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= the=20PCMonReq=20message,=20the=20PCE=20peer=20must=20send=20a=20PCErr=20message=20= with=20=20=20=20the=20PCMonReq=20= message,=20the=20PCE=20peer=20MUST=20= send=20a=20PCErr=20message=20with=0A=20=20=20=20=20=20=20=20=20Error-value=3D2=20= (capability=20not=20supported).=20=20= =20=20Error-value=3D2=20(capability=20not=20supported).=20=20According=20to=20the=20procedure=0A=20=20=20=20=20=20=20= =20=20=20defined=20= in=20section=206.9=20of=20[I-D.ietf-pce-pcep],=20if=20a=20PCC/PCE=20= receives=0A= =20=20=20=20=20=20=20=20=20=20unrecognized=20messages=20at=20a=20rate=20= equal=20of=20greater=20than=20specified=20rate,=0A=20=20=20=20=20=20=20= =20=20=20the=20= PCC/PCE=20must=20send=20a=20PCEP=20CLOSE=20message=20with=20= close=0A=20= =20=20=20=20=20=20=20=20=20value=3D"Reception=20of=20an=20unacceptable=20= number=20of=20unknown=20PCEP=20message.=0A=20=20=20=20=20=20=20=20=20=20In=20this=20case,=20= the=20PCC/PCE=20must=20also=20close=20the=20TCP=20session=20and=20= must=0A=20=20= =20=20=20=20=20=20=20=20not=20send=20any=20further=20PCEP=20messages=20= on=20the=20PCEP=20session.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=202)=20If=20the=20PCE=20supports=20the=20= PCMonReq=20message=20but=20the=20request=20is=20=20=20=202)=20If=20the=20PCE=20supports=20the=20= PCMonReq=20message=20but=20the=20monitoring=0A=20=20=20=20=20=20=20=20=20prohibited=20by=20= policy,=20the=20PCE=20MUST=20send=20a=20PCErr=20= message=20with=20Error-=20=20= =20=20request=20is=20prohibited=20by=20policy,=20the=20PCE=20must=20follow=20the=20procedure=0A=20=20=20=20=20=20=20=20=20Type=3D5=20and=20= Error-value=3D3.=20=20=20=20specified=20in=20section=205.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=203)=20If=20the=20PCE=20= supports=20the=20PCMonReq=20and=20the=20monitoring=20request=20is=20= not=20=20=20=203)=20If=20the=20PCE=20= supports=20the=20PCMonReq=20and=20the=20monitoring=20request=20is=20= not=0A=20=20=20=20= =20=20=20=20=20prohibited=20by=20policy,=20the=20receiving=20= PCE=20MUST=20first=20determine=20whether=20=20=20=20prohibited=20by=20policy,=20the=20receiving=20= PCE=20MUST=20first=20determine=20whether=0A=20=20=20=20=20=20=20=20=20it=20is=20the=20last=20= PCE=20of=20the=20path=20computation=20chain.=20=20If=20the=20PCE=20is=20= not=20=20=20=20it=20is=20the=20last=20= PCE=20of=20the=20path=20computation=20chain.=20=20If=20the=20PCE=20is=20= not=0A=20=20=20=20= =20=20=20=20=20the=20last=20element=20of=20the=20path=20= computation=20chain,=20the=20PCMonReq=20message=20=20=20=20the=20last=20element=20of=20the=20path=20= computation=20chain,=20the=20PCMonReq=20message=0A=20=20=20=20=20=20=20=20=20is=20= relayed=20to=20the=20next=20hop=20PCE:=20such=20next-hop=20may=20either=20= be=20specified=20=20=20=20is=20= relayed=20to=20the=20next=20hop=20PCE:=20such=20next-hop=20may=20either=20= be=20specified=0A=20= =20=20=20=20=20=0A=20=20=20=20= =20=20=20=20=20by=20means=20of=20a=20PCEP-ID=20object=20present=20in=20the=20PCMonReq=20= message=20or=20=20=20=20by=20means=20= of=20a=20PCE-ID=20object=20present=20in=20the=20PCMonReq=20message=20= or=0A=20=20=20=20=20= =20=20= =20=20dynamically=20determined=20by=20means=20of=20a=20procedure=20= outside=20of=20the=20scope=20=20=20=20= dynamically=20determined=20by=20means=20of=20a=20procedure=20outside=20= of=20the=20scope=0A= =20=20=20=20=20=20=20=20=20of=20this=20document.=20=20Conversely,=20if=20= the=20PCE=20is=20the=20last=20PCE=20of=20the=20path=20=20=20=20of=20this=20document.=20=20Conversely,=20if=20= the=20PCE=20is=20the=20last=20PCE=20of=20the=20path=0A=20=20=20=20=20=20=20=20=20= computation=20chain,=20the=20PCE=20originates=20a=20PCMonRep=20message=20= that=20=20=20=20computation=20chain,=20= the=20PCE=20originates=20a=20PCMonRep=20message=20that=0A=20=20=20=20=20=20=20=20=20= contains=20the=20requested=20objects=20according=20to=20the=20set=20of=20= requested=20PCE=20=20=20=20contains=20= the=20requested=20objects=20according=20to=20the=20set=20of=20requested=20= PCE=0A=20=20=20=20= =20=20=20=20=20states=20metrics=20listed=20in=20the=20= MONITORING=20object=20carried=20in=20the=20=20=20=20states=20metrics=20listed=20in=20the=20= MONITORING=20object=20carried=20in=20the=0A=20=20=20=20=20=20=20=20=20corresponding=20= PCMonReq=20message.=20=20=20=20= corresponding=20PCMonReq=20message.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20=20Upon=20receiving=20a=20PCReq=20message=20that=20carries=20= a=20MONITORING=20and=0A=20=20=20=20=20=20=20=20=20=20potentially=20other=20= monitoring=20objects=20(e.g.=20=20PCE-ID=20object):=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20= =20=20=201)=20As=20= specified=20in=20[I-D.ietf-pce-pcep],=20if=20the=20PCE=20does=20not=20= support=0A=20= =20=20=20=20=20=20=20=20=20(in=20band)=20monitoring,=20the=20PCE=20peer=20= MUST=20send=20a=20PCErr=20message=20with=0A=20=20=20=20=20=20=20= =20=20=20= Error-value=3D2=20(capability=20not=20supported).=20=20According=20to=20= the=20procedure=0A=20=20=20=20=20=20=20=20=20=20defined=20in=20= section=206.9=20of=20[I-D.ietf-pce-pcep],=20if=20a=20PCC/PCE=20= receives=0A= =20=20=20=20=20=20=20=20=20=20unrecognized=20messages=20at=20a=20rate=20= equal=20of=20greater=20than=20specified=20rate,=0A=20=20=20=20=20=20=20= =20=20=20the=20= PCC/PCE=20must=20send=20a=20PCEP=20CLOSE=20message=20with=20= close=0A=20= =20=20=20=20=20=20=20=20=20value=3D"Reception=20of=20an=20unacceptable=20= number=20of=20unknown=20PCEP=20message.=0A=20=20=20=20=20=20=20=20=20=20In=20this=20case,=20= the=20PCC/PCE=20must=20also=20close=20the=20TCP=20session=20and=20= must=0A=20=20= =20=20=20=20=20=20=20=20not=20send=20any=20further=20PCEP=20messages=20= on=20the=20PCEP=20session.=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=202)=20If=20= the=20PCE=20supports=20the=20monitoring=20request=20but=20the=20= monitoring=0A= =20=20=20=20=20=20=20=20=20=20request=20is=20prohibited=20by=20policy,=20the=20= PCE=20must=20follow=20the=20procedure=0A=20=20=20=20=20=20=20=20=20=20specified=20in=20= section=205.= =0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=203)=20If=20the=20PCE=20= supports=20the=20monitoring=20request=20and=20that=20request=20is=20= not=0A=20=20= =20=20=20=20=20=20=20=20prohibited=20by=20policy,=20the=20receiving=20= PCE=20MUST=20first=20determine=20whether=0A=20=20=20=20=20=20=20= =20=20=20it=20is=20= the=20last=20PCE=20of=20the=20path=20computation=20chain.=20=20If=20the=20= PCE=20is=20not=0A=20=20=20=20=20=20=20=20=20=20the=20last=20element=20= of=20the=20path=20computation=20chain,=20the=20PCReq=20= message=0A=20= =20=20=20=20=20=20=20=20=20(with=20the=20MONITORING=20object=20and=20= potentially=20other=20monitoring=20objects=0A=20=20=20=20=20=20=20= =20=20=20such=20as=20= the=20PCE-ID)=20is=20relayed=20to=20the=20next=20hop=20PCE:=20such=20= next-hop=20may=0A=20=20=20=20=20=20=20=20=20=20either=20be=20= specified=20by=20means=20of=20a=20PCE-ID=20object=20present=20in=20the=20= PCReq=0A=20= =20=20=20=20=20=20=20=20=20message=20or=20dynamically=20determined=20by=20= means=20of=20a=20procedure=20outside=20of=0A=20=20=20=20=20=20=20= =20=20=20the=20= scope=20of=20this=20document.=20=20Conversely,=20if=20the=20PCE=20is=20= the=20last=20PCE=0A=20=20=20=20=20=20=20=20=20=20of=20the=20path=20= computation=20chain,=20the=20PCE=20originates=20a=20PCRep=20= message=0A=20= =20=20=20=20=20=20=20=20=20that=20contains=20the=20requested=20objects=20= according=20to=20the=20set=20of=20requested=0A=20=20=20=20=20=20=20= =20=20=20PCE=20= states=20metrics=20listed=20in=20the=20MONITORING=20and=20potentially=20= other=0A=20= =20=20=20=20=20=20=20=20=20monitoring=20objects=20carried=20in=20the=20= corresponding=20PCReq=20message.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=0A=20= =20=20=20=20=20=20=20=20Upon=20receiving=20a=20PCMonRep=20message:=20= upon=20receiving=20a=20PCMonRep=20message,=20=20=20=20Upon=20receiving=20a=20PCMonRep=20message:=20= upon=20receiving=20a=20PCMonRep=20message,=0A=20=20=20=20=20=20=20=20=20the=20PCE=20processes=20= the=20request,=20adds=20the=20relevant=20objects=20to=20the=20= =20=20=20the=20PCE=20processes=20the=20= request,=20adds=20the=20relevant=20objects=20to=20the=0A=20=20=20=20=20=20=20=20=20= PCMonRep=20message=20and=20forwards=20the=20PCMonRep=20message=20to=20= the=20upstream=20=20=20=20PCMonRep=20= message=20and=20forwards=20the=20PCMonRep=20message=20to=20the=20= upstream=0A=20=20=20= =20=20=20=20=20=20requesting=20PCE=20or=20PCC.=20=20=20=20requesting=20PCE=20or=20PCC.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20Upon=20= receiving=20a=20PCRep=20message=20that=20carrries=20monitoring=20data,=20= the=0A=20=20= =20=20=20=20=20=20=20=20message=20is=20processed,=20additional=20= monitoring=20data=20is=20added=20according=0A=20=20=20=20=20=20=20= =20=20=20to=20this=20= specification=20and=20the=20message=20is=20forwarded=20upstream=20to=20= the=0A=20=20= =20=20=20=20=20=20=20=20requesting=20PCE=20or=20PCC.=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20Special=20case=20of=20= Multi-destination=20monitoring:=20monitoring=20request=20= =20=20=20Special=20case=20of=20= Multi-destination=20monitoring:=20monitoring=20request=0A=20=20=20=20=20=20=20=20=20= related=20to=20more=20than=20one=20destinations=20may=20involve=20a=20= set=20of=20path=20=20=20=20related=20= to=20more=20than=20one=20destinations=20may=20involve=20a=20set=20of=20= path=0A=20=20=20=20= =20=20=20=20=20computation=20chains.=20=20In=20that=20case,=20a=20= PCE=20sends=20each=20copy=20of=20the=20=20=20=20computation=20chains.=20=20In=20that=20case,=20= a=20PCE=20sends=20each=20copy=20of=20the=0A=20=20=20=20=20=20=20=20=20PCMonReq=20message=20= to=20each=20downstream=20PCE=20of=20each=20path=20computation=20= =20=20=20PCMonReq=20message=20to=20each=20= downstream=20PCE=20of=20each=20path=20computation=0A=20=20=20=20=20=20=20=20=20= chain.=20=20=20=20chain.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=207.=20=20Manageability=20= Considerations=207.=20=20= Manageability=20Considerations=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=207.1.=20=20Control=20of=20Function=20and=20Policy=20= 7.1.=20=20Control=20of=20Function=20and=20= Policy=0A=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20=20=20=20It=20= MUST=20be=20possible=20to=20configure=20the=20activation/deactivation=20= of=20PCEP=20=20=20=20It=20MUST=20be=20= possible=20to=20configure=20the=20activation/deactivation=20of=20= PCEP=0A=20=20=20=20= =20=20=20=20=20monitoring=20on=20a=20PCEP=20speaker.=20=20In=20= addition=20to=20the=20parameters=20already=20=20=20=20monitoring=20on=20a=20PCEP=20speaker.=20=20In=20= addition=20to=20the=20parameters=20already=0A=20=20=20=20=20=20=20=20=20listed=20in=20section=20= 8.1=20of=20[I-D.ietf-pce-pcep],=20a=20PCEP=20implementation=20= =20=20=20listed=20in=20section=208.1=20of=20= [I-D.ietf-pce-pcep],=20a=20PCEP=20implementation=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= =20= =20=20SHOULD=20allow=20configuring=20on=20a=20PCE=20whether=20specific,=20= generic,=20in-band=20=20=20=20SHOULD=20allow=20configuring=20on=20a=20PCE=20= whether=20specific,=20generic,=20in=20= band=0A=20=20= =20=20=20=20=20=20=20and=20out-of-band=20monitoring=20requests=20are=20= allowed=20or=20not.=20=20Also=20a=20PCEP=20=20=20=20and=20out=20of=20= band=20monitoring=20requests=20are=20allowed=20or=20not.=20=20= Also=20a=20PCEP=0A= =20=20=20=20=20=20=20=20=20implementation=20SHOULD=20allow=20configuring=20= on=20a=20PCE=20a=20list=20of=20authorized=20=20=20=20implementation=20SHOULD=20allow=20configuring=20= on=20a=20PCE=20a=20list=20of=20authorized=0A=20=20=20=20=20=20=20=20=20state=20metrics=20= (aliveness,=20congestion,=20processing=20time,=20etc).=20=20= This=20=20=20=20state=20metrics=20= (aliveness,=20congestion,=20processing=20time,=20etc).=20=20This=0A=20=20=20=20=20=20=20=20=20may=20= apply=20to=20any=20session=20the=20PCEP=20speaker=20participates=20in,=20= to=20a=20=20=20=20may=20apply=20to=20= any=20session=20the=20PCEP=20speaker=20participates=20in,=20to=20= a=0A=20=20=20=20=20= =20=20= =20=20specific=20session=20with=20a=20given=20PCEP=20peer=20or=20to=20a=20= specific=20group=20of=20=20=20=20= specific=20session=20with=20a=20given=20PCEP=20peer=20or=20to=20a=20= specific=20group=20of=0A=20=20=20=20=20=20=20=20=20sessions=20with=20a=20= specific=20group=20of=20PCEP=20peers,=20for=20instance=20the=20= PCEP=20=20=20=20sessions=20with=20a=20= specific=20group=20of=20PCEP=20peers,=20for=20instance=20the=20= PCEP=0A=20=20=20=20= =20=20=20=20=20peers=20of=20a=20neighbor=20AS.=20= =20=20=20peers=20of=20a=20neighbor=20= AS.=0A=20=20=20=20= =20=20=20=0A=20=20=20=20=20=207.2.=20=20= Information=20and=20Data=20Models=207.2.=20=20Information=20and=20Data=20Models=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20A=20= new=20MIB=20Module=20MAY=20be=20defined=20= that=20provides=20local=20PCE=20state=20=20=20=20A=20new=20MIB=20Module=20may=20be=20defined=20that=20provides=20local=20= PCE=20state=0A=20=20= =20=20=20=20=20=20=20metrics,=20as=20well=20as=20state=20metrics=20of=20= other=20PCEs=20gathered=20using=20=20= =20=20metrics,=20as=20well=20as=20state=20metrics=20of=20other=20PCEs=20= gathered=20using=0A= =20=20=20=20=20=20=20=20=20mechanisms=20defined=20in=20this=20= document.=20=20=20=20mechanisms=20= defined=20in=20this=20document.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=207.3.=20=20Liveness=20Detection=20and=20= Monitoring=207.3.=20=20Liveness=20= Detection=20and=20Monitoring=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20This=20document=20provides=20mechanisms=20to=20= monitor=20the=20liveliness=20and=20=20= =20=20This=20document=20provides=20mechanisms=20to=20monitor=20the=20= liveliness=20and=0A= =20=20=20=20=20=20=20=20=20performances=20of=20a=20given=20PCE=20= chain.=20=20=20=20performances=20of=20= a=20given=20PCE=20chain.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=207.4.=20=20Verify=20Correct=20Operations=20= 7.4.=20=20Verify=20Correct=20= Operations=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20= skipping= =20to=20change=20at=20page=2016,=20line=20= 5=20skipping=20= to=20change=20at=20page=2020,=20line=20= 51=0A=20=20=20=20=20=20=20=20=20= other=20protocols=20in=20addition=20to=20those=20already=20listed=20= in=20=20=20=20other=20protocols=20in=20= addition=20to=20those=20already=20listed=20in=0A=20=20=20=20=20=20=20=20=20= [I-D.ietf-pce-pcep].=20=20=20=20= [I-D.ietf-pce-pcep].=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=207.6.=20=20Impact=20On=20Network=20Operations=20= 7.6.=20=20Impact=20On=20Network=20= Operations=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20The=20= frequency=20of=20PCMonReq=20messages=20may=20impact=20the=20operations=20= of=20PCEs.=20=20=20=20The=20= frequency=20of=20PCMonReq=20messages=20may=20impact=20the=20operations=20= of=20PCEs.=0A=20=20= =20=20=20=20=20=20=20An=20implementation=20SHOULD=20allow=20a=20limit=20= to=20be=20placed=20on=20the=20rate=20of=20=20=20=20An=20implementation=20SHOULD=20allow=20a=20= limit=20to=20be=20placed=20on=20the=20rate=20of=0A=20=20=20=20=20=20=20=20=20= PCMonReq=20messages=20sent=20by=20a=20PCEP=20speaker=20and=20processed=20= from=20a=20peer.=20=20=20=20PCMonReq=20= messages=20sent=20by=20a=20PCEP=20speaker=20and=20processed=20from=20a=20= peer.=0A=20=20=20=20= =20=20=20=20=20It=20SHOULD=20also=20allow=20sending=20a=20= notification=20when=20a=20rate=20threshold=20is=20=20=20=20It=20SHOULD=20also=20allow=20sending=20a=20= notification=20when=20a=20rate=20threshold=20is=0A=20=20=20=20=20=20=20=20=20= reached.=20=20An=20implementation=20SHOULD=20allow=20handling=20PCReq=20= messages=20with=20=20=20=20reached.=20= =20An=20implementation=20SHOULD=20allow=20handling=20PCReq=20messages=20= with=0A=20=20=20=20= =20=20=0A=20=20=20=20=20=20= =20= =20=20a=20higher=20priority=20than=20PCMonReq=20messages.=20= =20=20=20a=20higher=20priority=20than=20= PCMonReq=20messages.=20=20An=20implementation=20= SHOULD=0A=20= =20=20=20=20=20=20=20=20=20allow=20the=20configuration=20of=20a=20second=20= limit=20for=20the=20PCReq=20message=0A=20=20=20=20=20=20=20=20=20=20requesting=20= monitoring=20data.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=208.=20=20IANA=20Considerations=208.=20=20IANA=20Considerations=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=208.1.=20=20New=20PCEP=20Message=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20Each=20PCEP=20message=20= has=20a=20message=20type=20value.=20=20= =20=20Each=20PCEP=20message=20has=20a=20message=20type=20value.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20Two=20new=20PCEP=20= (specified=20in=20[I-D.ietf-pce-pcep])=20messages=20are=20= defined=20=20=20=20Two=20new=20PCEP=20= (specified=20in=20[I-D.ietf-pce-pcep])=20messages=20are=20= defined=0A=20=20=20= =20=20=20=20=20=20in=20this=20document:=20=20=20=20in=20this=20document:=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20Value=20=20=20=20Meaning=20=20= Value=20=20=20=20Description=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20Reference=0A=20=20=20=20=20=20=20=20=20=20=208=20=20=20=20=20= =20Path=20Computation=20Monitoring=20Request=20(PCMonReq)=20= =20=20=208=20=20=20=20=20=20Path=20= Computation=20Monitoring=20Request=20(PCMonReq)=20=20=20This=20document=0A=20=20=20=20=20=20=20=20=20=20=209=20=20=20=20=20= =20Path=20Computation=20Monitoring=20Reply=20(PCMonRep)=20= =20=20=209=20=20=20=20=20=20Path=20= Computation=20Monitoring=20Reply=20(PCMonRep)=20=20=20=20=20This=20document=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= 8.2.=20=20New=20= PCEP=20Objects=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20Each=20PCEP=20object=20has=20an=20Object-Class=20= and=20an=20Object-Type.=20=20The=20=20= =20=20Each=20PCEP=20object=20has=20an=20Object-Class=20and=20an=20= Object-Type.=20=20The=0A=20=20=20=20=20=20=20=20=20following=20new=20PCEP=20= objects=20are=20defined=20in=20this=20document.=20=20=20=20following=20new=20PCEP=20objects=20are=20= defined=20in=20this=20document.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20Object-Class=20=20=20=20= =20=20Name=20=20=20=20= Object-Class=20Value=20Name=20=20=20=20=20=20=20= =20Object-Type=20=20=20=20=20=20=20=20=20=20=20=20=20= Reference=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= =20= =20=20=20=20=20=20=20=20=2019=20=20=20=20=20=20=20=20=20= MONITORING=20=20=20=20=20=20=20=20=20= =20=2019=20=20=20=20=20=20=20=20=20=20MONITORING=20=201=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20This=20document=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20Object-Type=20=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=201=20=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=2020=20=20=20=20=20=20=20=20=20PCEP-ID=20=20= =20=20=20=20=20=20=20=20=2020=20=20=20=20=20=20=20=20=20=20PCE-ID=20=20=20=20=20=201:=20IPv4=20addresses=20=20= =20=20=20=20=20This=20document=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20Object-Type=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=202:=20IPv6=20addresses=20=20=20=20=20=20=20This=20document=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=201:=20IPv4=20addresses=20= =0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=202:=20IPv6=20addresses=20= =0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=2021=20=20=20=20=20=20=20=20= =20PROC-TIME=20=20=20=20=20=20=20=20= =20=20=2021=20=20=20=20=20=20=20=20=20PROC-TIME=20=20=20=201=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20This=20document=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20Object-Type=20=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=201=20=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=2022=20=20=20=20=20=20=20=20=20CONGESTION=20= =20=20=20=20=20=20=20=20=20=2022=20=20=20=20=20= =20=20=20=20CONGESTION=20=20=201=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20This=20= document=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20Object-Type=20=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=201=20= 8.3.=20=20New=20= Error-Type=20and=20Error-Values=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20A=20registry=20has=20been=20created=20for=20the=20= Error-type=20and=20Error-value=20of=20the=20=20=20=20A=20registry=20has=20been=20created=20for=20the=20= Error-type=20and=20Error-value=20of=20the=0A=20=20=20=20=20=20=20=20=20PCEP=20Error=20= Object.=20=20=20=20PCEP=20Error=20= Object.=0A=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20=20=20=20A=20= new=20Error-value=20for=20the=20PCErr=20message=20Error-types=3D5=20= (Policy=20=20=20=20A=20new=20= Error-value=20for=20the=20PCErr=20message=20Error-types=3D5=20= (Policy=0A=20=20=20= =20=20=20=20=20=20Violation)=20(see=20[I-D.ietf-pce-pcep])=20is=20= defined=20in=20this=20document=20=20=20= =20Violation)=20(see=20[I-D.ietf-pce-pcep])=20is=20defined=20in=20this=20= document=0A=20=20=20= =20=20=20=0A=20=20=20=20=20=20= =20= =20=20(Error-Type=20and=20Error-value=20= to=20be=20assigned=20by=20IANA).=20=20= =20=20(Error-value=20to=20be=20assigned=20by=20IANA).=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20= =20Error-type=20=20=20=20=20=20=20=20= Meaning=20=20=20Error-Type=20=20=20Meaning=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Error-value=20=20=20=20Reference=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=205=20=20=20=20=20=20=20=20=20=20=20=20=20=20Policy=20= violation=20=20=20=20=20=205=20=20=20= =20=20=20=20=20=20Policy=20violation=20=20=20=20=20=20=20=20=20=20=20=20=20= =203=20=20=20=20=20=20=20=20=20=20=20=20=20=20= This=20document=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Error-value=3D3=20=20=20=20=20=20=20=20=20=20=20=20=20=20= [This=20document]=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20Monitoring=20message=20= supported=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20Monitoring=20message=20supported=20but=20= rejected=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20but=20rejected=20due=20to=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20due=20to=20= policy=20violation=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20policy=20violation=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20A=20new=20Error-value=20= for=20the=20PCErr=20message=20Error-types=3D6=20(Mandatory=20= =20=20=20A=20new=20Error-value=20for=20the=20= PCErr=20message=20Error-types=3D6=20(Mandatory=0A=20=20=20=20=20=20=20=20=20Object=20missing)=20= (see=20[I-D.ietf-pce-pcep])=20is=20defined=20in=20this=20= document=20=20=20=20Object=20= missing)=20(see=20[I-D.ietf-pce-pcep])=20is=20defined=20in=20this=20= document=0A=20=20=20= =20=20=20=20=20=20(Error-Type=20and=20Error-value=20to=20be=20= assigned=20by=20IANA).=20=20=20=20= (Error-Type=20and=20Error-value=20to=20be=20assigned=20by=20= IANA).=0A=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= =20= =20=20=20=20Error-type=20=20=20=20=20=20=20=20Meaning=20= =20=20Error-type=20=20=20Meaning=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Error-value=20=20=20=20Reference=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=206=20=20=20=20=20=20=20=20=20=20=20=20=20=20Mandatory=20= Object=20missing=20=20=20=20=20=206=20= =20=20=20=20=20=20=20=20Mandatory=20Object=20missing=20=20=20=20=20=20= 4=20=20=20=20=20=20=20=20=20=20=20=20=20=20This=20= document=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20Error-value=3D4=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20[This=20document]=20= =0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20MONITORING=20Object=20= missing=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20MONITORING=20= Object=20missing=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= =208.4.=20=20MONITORING=20Object=20Flag=20= Field=0A=20= =20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20IANA=20is=20requested=20= to=20create=20a=20registry=20to=20manage=20the=20Flag=20field=20= of=0A=20=20= =20=20=20=20=20=20=20=20the=20MONITORING=20object.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20= =20=20=20New=20bit=20= numbers=20may=20be=20allocated=20only=20by=20an=20IETF=20Consensus=20= action.=0A=20= =20=20=20=20=20=20=20=20=20Each=20bit=20should=20be=20tracked=20with=20= the=20following=20qualities:=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20o=20=20Bit=20= number=20(counting=20from=20bit=200=20as=20the=20most=20significant=20= bit)=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20o=20=20Capability=20= Description=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20o=20=20Defining=20= RFC=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20Several=20bits=20are=20= defined=20for=20the=20MONITORING=20Object=20flag=20field=20in=20= this=0A=20=20= =20=20=20=20=20=20=20=20document:=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20Codespace=20= of=20the=20Flag=20field=20(MONITORING=20Object)=0A=20=20=20=20=20=20=20= =20=20=20=20=20Bit=20= =20=20=20=20=20Description=20=20=20=20=20=20=20=20=20= Reference=0A= =20=20=20=20=20=20=20=20=20=20=20=200-18=20=20=20=20=20= Unassigned=0A= =20=20=20=20=20=20=20=20=20=20=20=20=2019=20=20=20=20=20=20Incomplete=20=20=20= =20=20=20=20=20=20=20This=20document=0A=20=20=20=20=20=20=20=20=20=20=20=20=2020=20=20=20=20= =20=20Congestion=20=20=20=20=20=20=20=20=20=20This=20= document=0A= =20=20=20=20=20=20=20=20=20=20=20=20=2021=20=20=20=20=20=20Processing=20Time=20= =20=20=20=20This=20document=0A=20=20=20=20=20=20=20=20=20=20=20=20=2022=20=20=20=20= =20=20General=20=20=20=20=20=20=20=20=20=20=20=20=20This=20= document=0A= =20=20=20=20=20=20=20=20=20=20=20=20=2023=20=20=20=20=20=20Liveness=20=20=20=20= =20=20=20=20=20=20=20=20This=20document=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= 8.5.=20=20PROC-TIME=20= Object=20Flag=20Field=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20IANA=20is=20= requested=20to=20create=20a=20registry=20to=20manage=20the=20Flag=20= field=20of=0A= =20=20=20=20=20=20=20=20=20=20the=20PROC-TIME=20object.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20= =20=20=20New=20bit=20= numbers=20may=20be=20allocated=20only=20by=20an=20IETF=20Consensus=20= action.=0A=20= =20=20=20=20=20=20=20=20=20Each=20bit=20should=20be=20tracked=20with=20= the=20following=20qualities:=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20o=20=20Bit=20= number=20(counting=20from=20bit=200=20as=20the=20most=20significant=20= bit)=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20o=20=20Capability=20= Description=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20o=20=20Defining=20= RFC=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20One=20bit=20is=20= defined=20for=20the=20PROC-TIME=20Object=20flag=20field=20in=20= this=0A=20=20= =20=20=20=20=20=20=20=20document:=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20Codespace=20= of=20the=20Flag=20field=20(PROC-TIME=20Object)=0A=20=20=20=20=20=20=20= =20=20=20=20=20Bit=20= =20=20=20=20=20Description=20=20=20=20=20=20=20=20=20=20=20=20=20= Reference=0A= =20=20=20=20=20=20=20=20=20=20=20=200-14=20=20=20=20=20= Unassigned=0A= =20=20=20=20=20=20=20=20=20=20=20=20=2015=20=20=20=20=20=20Estimated=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20This=20document=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20= 8.6.=20=20= CONGESTION=20Object=20Flag=20field=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20IANA=20is=20= requested=20to=20create=20a=20registry=20to=20manage=20the=20Flag=20= field=20of=0A= =20=20=20=20=20=20=20=20=20=20the=20CONGESTION=20object.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20= =20=20=20New=20bit=20= numbers=20may=20be=20allocated=20only=20by=20an=20IETF=20Consensus=20= action.=0A=20= =20=20=20=20=20=20=20=20=20Each=20bit=20should=20be=20tracked=20with=20= the=20following=20qualities:=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20o=20=20Bit=20= number=20(counting=20from=20bit=200=20as=20the=20most=20significant=20= bit)=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20o=20=20Capability=20= Description=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20o=20=20Defining=20= RFC=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20One=20bit=20is=20= defined=20for=20the=20CONGESTION=20Object=20flag=20field=20in=20= this=0A=20=20= =20=20=20=20=20=20=20=20document:=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20Codespace=20= of=20the=20Flag=20field=20(CONGESTION=20Object)=0A=20=20=20=20=20=20=20= =20=20=20=20=20Bit=20= =20=20=20=20=20Description=20=20=20=20=20=20=20=20=20=20=20=20=20= Reference=0A= =20=20=20=20=20=20=20=20=20=20=20=200-6=20=20=20=20=20=20= Unassigned=0A= =20=20=20=20=20=20=20=20=20=20=20=20=207=20=20=20=20=20=20=20Congestion=20=20= =20=20=20=20=20=20=20=20=20=20=20=20This=20document=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=0A=20=20=20=20=20=209.=20=20Security=20= Considerations=209.=20=20Security=20= Considerations=0A=20= =20=20=20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= =20= =20=20Mechanisms=20discussed=20in=20= [I-D.ietf-pce-pcep]=20to=20secure=20a=20PCEP=20session=20= =20=20=20The=20use=20= of=20monitoring=20data=20can=20be=20used=20for=20various=20attacks=20= such=20as=0A= =20=20=20=20=20=20=20=20=20(authenticity,=20integrity,=20privacy,=20DoS=20= protection,=20etc)=20can=20be=20= used=20=20=20=20denail=20of=20service=20attacks=20(for=20= example=20by=20setting=20the=20C=20bit=20and=0A=20=20=20=20=20=20=20=20=20= to=20secure=20the=20PCMonReq,=20PCMonRep=20messages=20and=20PCE=20state=20= metric=20=20= =20=20congestion=20during=20field=20of=20the=20CONGESTION=20object=20to=20= stop=20PCCs=20from=0A=20=20=20=20=20=20=20=20=20objects=20defined=20= in=20this=20document=20as=20well.=20=20A=20PCE=20= may=20face=20a=20denial=20of=20=20=20=20using=20a=20PCE).=20=20= Thus=20it=20is=20recommended=20to=20make=20use=20of=20the=20= security=0A= =20=20=20=20=20=20=20=20=20service=20attack=20= with=20PCMonReq=20messages.=20=20An=20implementation=20= SHOULD=20=20= =20=20mechanisms=20discussed=20in=20[I-D.ietf-pce-pcep]=20to=20= secure=20a=20PCEP=20session=0A=20=20=20=20=20=20=20=20=20allow=20limiting=20= the=20rate=20at=20which=20PCMonReq=20messages=20received=20from=20= a=20=20=20=20(authenticity,=20= integrity,=20privacy,=20DoS=20protection,=20etc)=20to=20secure=20= the=0A=20=20=20=20= =20=20=20=20=20specific=20peer=20are=20processed=20(input=20= shapping),=20or=20from=20another=20domain=20=20=20=20PCMonReq,=20PCMonRep=20messages=20and=20PCE=20= state=20metric=20objects=20defined=20in=0A=20=20=20=20=20=20=20=20=20(see=20also=20= section=207.6).=20=20=20=20this=20= document.=20=20An=20implementation=20= SHOULD=20allow=20limiting=20the=20rate=20at=0A=20=20=20=20=20=20=20=20=20=20which=20PCMonReq=20or=20= PCReq=20messages=20carrying=20monitoring=20= requests=0A= =20=20=20=20=20=20=20=20=20=20= received=20from=20a=20specific=20peer=20are=20processed=20(input=20= shapping),=20or=20from=0A=20=20=20=20=20=20=20=20=20=20another=20domain=20(see=20also=20section=20= 7.6).=0A=20=20=20=20= =20=20=20=0A=20=20=20=20=20=2010.=20=20= Acknowledgements=2010.=20=20= Acknowledgements=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= =20= =20=20The=20authors=20would=20like=20to=20thank=20Eiji=20Oki,=20Mach=20= Chen=20and=20Dimitri=20=20=20=20The=20authors=20would=20like=20to=20thank=20= Eiji=20Oki,=20Mach=20Chen,=20Fabien=20= Verhaeghe=0A= =20=20=20=20=20=20=20=20=20Papadimitriou=20for=20their=20useful=20= comments.=20=20Special=20thank=20to=20Adrian=20=20=20=20and=20Dimitri=20Papadimitriou=20for=20their=20= useful=20comments.=20=20Special=20thank=0A=20=20=20=20=20=20=20=20=20Farrel=20for=20his=20= detailed=20review.=20=20=20=20to=20= Adrian=20Farrel=20for=20his=20detailed=20review.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=2011.=20=20References=20= 11.=20=20References=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=2011.1.=20=20Normative=20References=2011.1.=20=20Normative=20References=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20[I-D.farrel-rtg-common-bnf]=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20= =20=20=20=20=20=20=20Farrel,=20A.,=20"Reduced=20Backus-Naur=20Form=20= (RBNF)=20A=20Syntax=20Used=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20in=20Various=20Protocol=20=20Specifications",=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20= =20=20=20=20=20=20=20draft-farrel-rtg-common-bnf-07=20(work=20in=20= progress),=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20November=20= 2008.=0A=20= =20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20= [I-D.ietf-pce-of]=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20Roux,=20J.,=20Vasseur,=20J.,=20and=20Y.=20Lee,=20"Encoding=20of=20= Objective=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Functions=20= in=20the=20Path=20Computation=20Element=20=20= Communication=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20Protocol=20(PCEP)",=20draft-ietf-pce-of-06=20(work=20in=20= progress),=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20December=20= 2008.=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= [I-D.ietf-pce-pcep]=20=20=20=20= [I-D.ietf-pce-pcep]= =0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Ayyangar,=20A.,=20= Farrel,=20A.,=20Oki,=20E.,=20Atlas,=20A.,=20Dolganow,=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20= Ayyangar,=20A.,=20Farrel,=20A.,=20Oki,=20E.,=20Atlas,=20A.,=20= Dolganow,=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20A.,=20Ikejiri,=20= Y.,=20Kumaki,=20K.,=20Vasseur,=20J.,=20and=20J.=20Roux,=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20A.,=20= Ikejiri,=20Y.,=20Kumaki,=20K.,=20Vasseur,=20J.,=20and=20J.=20= Roux,=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20"Path=20= Computation=20Element=20(PCE)=20Communication=20Protocol=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20= "Path=20Computation=20Element=20(PCE)=20Communication=20Protocol=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= =20= =20=20=20=20=20=20=20=20=20=20=20=20=20(PCEP)",=20= draft-ietf-pce-pcep-18=20(work=20in=20= progress),=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20(PCEP)",=20draft-ietf-pce-pcep-19=20(work=20in=20progress),=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20November=202008.=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20November=20= 2008.=0A=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= =20=20=20=20[I-D.ietf-pce-pcep-xro]=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20= =20=20=20=20=20=20=20Takeda,=20T.,=20Oki,=20E.,=20and=20A.=20Farrel,=20= "Extensions=20to=20the=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20Path=20Computation=20Element=20Communication=20Protocol=20= (PCEP)=20for= =0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Route=20= Exclusions",=20draft-ietf-pce-pcep-xro-06=20(work=20in=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20= =20=20=20=20=20=20=20progress),=20July=202008.=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20[RFC2119]=20=20= Bradner,=20S.,=20"Key=20words=20for=20use=20in=20RFCs=20to=20= Indicate=20=20=20=20[RFC2119]=20=20= Bradner,=20S.,=20"Key=20words=20for=20use=20in=20RFCs=20to=20= Indicate=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Requirement=20= Levels",=20BCP=2014,=20RFC=202119,=20March=201997.=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Requirement=20= Levels",=20BCP=2014,=20RFC=202119,=20March=201997.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20[RFC4655]=20=20Farrel,=20= A.,=20Vasseur,=20J.,=20and=20J.=20Ash,=20"A=20Path=20= Computation=20=20=20=20[RFC4655]=20=20= Farrel,=20A.,=20Vasseur,=20J.,=20and=20J.=20Ash,=20"A=20Path=20= Computation=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Element=20= (PCE)-Based=20Architecture",=20RFC=204655,=20August=202006.=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20= Element=20(PCE)-Based=20Architecture",=20RFC=204655,=20August=20= 2006.=0A=20=20=20=20= =20=20=20=0A=20=20=20=20=20=2011.2.=20=20= Informative=20References=2011.2.=20=20= Informative=20References=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20[I-D.ietf-pce-brpc]=20=20=20=20[I-D.ietf-pce-brpc]=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20Vasseur,=20J.,=20Zhang,=20R.,=20Bitar,=20N.,=20and=20J.=20Roux,=20= "A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20Vasseur,=20J.,=20Zhang,=20R.,=20Bitar,=20N.,=20and=20J.=20Roux,=20= "A=0A=20=20=20=20=20= =20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20Backward=20Recursive=20PCE-based=20= Computation=20(BRPC)=20Procedure=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20Backward=20Recursive=20PCE-based=20= Computation=20(BRPC)=20Procedure=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20To=20Compute=20=20Shortest=20Constrained=20Inter-domain=20= Traffic=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20To=20Compute=20=20Shortest=20Constrained=20Inter-domain=20= Traffic=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Engineering=20= Label=20Switched=20Paths",=20draft-ietf-pce-brpc-09=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Engineering=20= Label=20Switched=20Paths",=20draft-ietf-pce-brpc-09=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20(work=20in=20progress),=20April=20= 2008.=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20(work=20in=20progress),=20April=202008.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= [I-D.ietf-pce-disco-proto-isis]=20= =0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20Roux,=20J.,=20"IS-IS=20Protocol=20= Extensions=20for=20Path=20Computation=20=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20Element=20(PCE)=20Discovery",=20=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20draft-ietf-pce-disco-proto-isis-08=20(work=20in=20= progress),=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20September=20= 2007.=20=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20[I-D.ietf-pce-of]=20=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20Roux,=20J.,=20Vasseur,=20J.,=20and=20Y.=20Lee,=20"Encoding=20of=20= Objective=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Functions=20= in=20the=20Path=20Computation=20Element=20=20= Communication=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Protocol=20= (PCEP)",=20draft-ietf-pce-of-05=20(work=20in=20= progress),=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20September=20= 2008.=20=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20[I-D.ietf-pce-pcep-xro]=20= =0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20Takeda,=20T.,=20Oki,=20E.,=20and=20= A.=20Farrel,=20"Extensions=20to=20the=20=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20Path=20Computation=20Element=20Communication=20Protocol=20= (PCEP)=20for=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Route=20= Exclusions",=20draft-ietf-pce-pcep-xro-06=20(work=20in=20= =0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20progress),=20July=20= 2008.=20=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20[RFC5088]=20=20Le=20= Roux,=20JL.,=20Vasseur,=20JP.,=20Ikejiri,=20Y.,=20and=20R.=20= Zhang,=20=20=20=20[RFC5088]=20=20Le=20= Roux,=20JL.,=20Vasseur,=20JP.,=20Ikejiri,=20Y.,=20and=20R.=20= Zhang,=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20"OSPF=20= Protocol=20Extensions=20for=20Path=20Computation=20Element=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20= "OSPF=20Protocol=20Extensions=20for=20Path=20Computation=20= Element=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(PCE)=20= Discovery",=20RFC=205088,=20January=202008.=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(PCE)=20= Discovery",=20RFC=205088,=20January=202008.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20[RFC5089]=20=20Le=20Roux,=20JL.,=20Vasseur,=20= JP.,=20Ikejiri,=20Y.,=20and=20R.=20Zhang,=20=20=20=20[RFC5089]=20=20Le=20Roux,=20JL.,=20Vasseur,=20= JP.,=20Ikejiri,=20Y.,=20and=20R.=20Zhang,=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20"IS-IS=20Protocol=20Extensions=20for=20Path=20Computation=20= Element=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20"IS-IS=20Protocol=20Extensions=20for=20Path=20Computation=20= Element=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(PCE)=20= Discovery",=20RFC=205089,=20January=202008.=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(PCE)=20= Discovery",=20RFC=205089,=20January=202008.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20Authors'=20Addresses=20Authors'=20Addresses=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20skipping=20= to=20change=20at=20page=2020,=20line=207=20= skipping=20to=20change=20= at=20page=2026,=20line=207=0A=20=20= =20=20=20=20=20=20=20Yuichi=20Ikejiri=20=20=20=20Yuichi=20Ikejiri=0A=20=20=20=20=20=20=20=20=20NTT=20Communications=20= Corporation=20=20=20=20NTT=20= Communications=20Corporation=0A=20=20=20=20=20=20=20=20=201-1-6,=20= Uchisaiwai-cho,=20Chiyoda-ku=20=20=20= =201-1-6,=20Uchisaiwai-cho,=20Chiyoda-ku=0A=20=20=20=20=20=20=20=20=20Tokyo,=20=20=20= 100-8019=20=20=20=20Tokyo,=20=20=20= 100-8019=0A=20=20=20= =20=20=20=20=20=20Japan=20=20=20= =20Japan=0A=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20=20=20=20= Email:=20:=20y.ikejiri@ntt.com=20=20=20= =20Email:=20:=20y.ikejiri@ntt.com=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20Full=20Copyright=20Statement=20Full=20Copyright=20Statement=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20Copyright=20(C)=20The=20IETF=20Trust=20= (2008).=20=20=20=20Copyright=20(C)=20The=20IETF=20Trust=20= (2009).=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20This=20document=20is=20subject=20to=20the=20= rights,=20licenses=20and=20restrictions=20=20=20=20This=20document=20is=20subject=20to=20the=20= rights,=20licenses=20and=20restrictions=0A=20=20=20=20=20=20=20=20=20contained=20in=20BCP=20= 78,=20and=20except=20as=20set=20forth=20therein,=20the=20= authors=20=20=20=20contained=20in=20= BCP=2078,=20and=20except=20as=20set=20forth=20therein,=20the=20= authors=0A=20=20=20= =20=20=20=20=20=20retain=20all=20their=20rights.=20= =20=20=20retain=20all=20their=20= rights.=0A=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20=20=20=20= This=20document=20and=20the=20information=20contained=20herein=20are=20= provided=20on=20an=20=20=20=20This=20= document=20and=20the=20information=20contained=20herein=20are=20provided=20= on=20an=0A=20=20=20= =20=20=20=20=20=20"AS=20IS"=20basis=20and=20THE=20CONTRIBUTOR,=20= THE=20ORGANIZATION=20HE/SHE=20REPRESENTS=20=20=20=20"AS=20IS"=20basis=20and=20THE=20CONTRIBUTOR,=20= THE=20ORGANIZATION=20HE/SHE=20REPRESENTS=0A=20=20=20=20=20=20=20=20=20OR=20IS=20SPONSORED=20= BY=20(IF=20ANY),=20THE=20INTERNET=20SOCIETY,=20THE=20IETF=20TRUST=20= AND=20=20=20=20OR=20IS=20SPONSORED=20= BY=20(IF=20ANY),=20THE=20INTERNET=20SOCIETY,=20THE=20IETF=20TRUST=20= AND=0A=20=20=20=20= =20=20=20=20=20THE=20INTERNET=20ENGINEERING=20TASK=20FORCE=20= DISCLAIM=20ALL=20WARRANTIES,=20EXPRESS=20=20=20=20THE=20INTERNET=20ENGINEERING=20TASK=20FORCE=20= DISCLAIM=20ALL=20WARRANTIES,=20EXPRESS=0A=20=20=20=20=20=20=20=20=20OR=20IMPLIED,=20= INCLUDING=20BUT=20NOT=20LIMITED=20TO=20ANY=20WARRANTY=20THAT=20THE=20USE=20= OF=20=20=20=20OR=20IMPLIED,=20= INCLUDING=20BUT=20NOT=20LIMITED=20TO=20ANY=20WARRANTY=20THAT=20THE=20USE=20= OF=0A=0A=20=20=20=20= =20=20=0A=20=20=20=20=20=C2=A0End=20of=20changes.=2070=20change=20= blocks.=C2=A0=0A=20=20=20=20=20186=20lines=20changed=20or=20= deleted=20393=20lines=20changed=20or=20= added=0A=20=20=20=20=20
This=20html=20diff=20was=20= produced=20by=20rfcdiff=201.35.=20The=20latest=20version=20is=20= available=20from=20http://tools.ietf.org/to= ols/rfcdiff/=20=0A=20=20=20=0A=20=20=20=0A=20= =20=20=0AP=00=00=08=00=00=0B= =00=00=1D=00=00(=00=007=00=00U=00=00k=00=00}=00=00=94=00=00=B4=00=00=BA=00= =00=C4=03=AB=0B=00=00=00=00=00=00=03=01=00=00=00=00=00=00=00=0D= =00=00=00=00=00=00=00=00=00=00=00=00=00=03=AB=0C= --Apple-Mail-88-646551410 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit

Many Thanks.

JP.

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

--Apple-Mail-88-646551410-- --Apple-Mail-87-646551409-- --===============0518266793== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --===============0518266793==-- From pce-bounces@ietf.org Mon Jan 19 01:21:00 2009 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ADC728C1A7; Mon, 19 Jan 2009 01:21:00 -0800 (PST) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54E5D28C1A7 for ; Mon, 19 Jan 2009 01:20:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.533 X-Spam-Level: X-Spam-Status: No, score=-10.533 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHHy9dhOY2Ii for ; Mon, 19 Jan 2009 01:20:58 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 00D9128C19E for ; Mon, 19 Jan 2009 01:20:54 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,288,1231113600"; d="scan'208,217";a="31230979" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 19 Jan 2009 09:20:39 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n0J9Kdxg028736; Mon, 19 Jan 2009 10:20:39 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0J9KcHa024881; Mon, 19 Jan 2009 09:20:39 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jan 2009 10:20:38 +0100 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jan 2009 10:20:36 +0100 Message-Id: <98DA3F97-CEC4-4699-BB5C-79979A5B66A7@cisco.com> From: JP Vasseur To: Fabien Verhaeghe , Adrian Farrel In-Reply-To: Mime-Version: 1.0 (Apple Message framework v930.3) X-Priority: 3 Date: Mon, 19 Jan 2009 10:20:31 +0100 References: <000301c969d5$cafe8c40$1214a8c0@marbenproducts.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 19 Jan 2009 09:20:37.0463 (UTC) FILETIME=[30944670:01C97A17] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10766; t=1232356839; x=1233220839; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Pce]=20PCE=20Monitoring=20=3A=20wrong= 20version=20last=20called |Sender:=20; bh=DWkCSzTuwaEbbcUanxpf58Cn3Qy+8tPt8RHxi3zhMAs=; b=AE0bW5VtAKQ5VCVc8o9Gz6oQzmj69vjl34MYv42JMgtBiIojOJHBzSQuMa BlpdiFK6r2KXrBjtdIdbgbAstD5ZErtPOJy9CwrDkTwvDOwg1pNldIYbe9QT waPw2zIaDn; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: pce@ietf.org Subject: Re: [Pce] PCE Monitoring : wrong version last called X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2059454373==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org --===============2059454373== Content-Type: multipart/alternative; boundary=Apple-Mail-89-646561441 --Apple-Mail-89-646561441 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, On Dec 31, 2008, at 8:07 PM, Adrian Farrel wrote: > That is my fault :-( > > The I-D is at revision -03 > > http://www.ietf.org/internet-drafts/draft-ietf-pce-monitoring-03.txt > > You still have until Monday next week if you want to make comments. > > As my punishment, I have gone through Fabien's email to check which > of his coments still apply... > >> Below my comments on monitoring draft: >> >> Section 3.1: >> >> Example 3: The request must also contain a MONITORING object. > > Issue stands. > That was "in addition to" but the text had been clarified, thanks. >> Section 3.2: >> >> The format of a PCReq message is as follows: >> >> Must be >> >> The format of a PCMonRep message is as follows: > > Issue stands Fixed. > > >> Section 4.1: >> >> Seems the first sentence is repeated twice. > > Fixed in revision -03 > >> Besides it is said that the Monitoring object MAY be included in >> PCReq and PCRep so I think it would be good to add the enhanced >> PCReq and PCRep BNF description. > > Issue stands > Added. > Also in 4.1 > s/PCEReq/PCReq/ > Fixed. >> General comment: >> >> The in-band monitoring request is not fully clear to me. >> You are right that this is not clearly explained in the current text. >> If there are several path computation requests in the PCReq >> which one is targeting? >> i.e. Must the PCE return the processing time for each request >> seperatly >> or a single processing time for all requests? We could decide to have one MONITORING object per request in the bundle case but this does introduce some complexity and is not likely to be that useful. I'd rather propose to keep the current mode with one MONITORING object per PCMonReq or PCReq message. When present the monitoring request applies to all requests of the bundle. Text added in section 3.2. " As pointed out in [PCEP] we can have several situations: o Bundle of a set of independent and non-synchronized path computation requests, o Bundle of a set of independent and synchronized path computation requests (SVEC object defined below required), o Bundle of a set of dependent and synchronized path computation requests (SVEC object defined below required). In the case of a bundle of a set of request, the MONITORING object SHOULD only be present in the first PCReq or PCMonReq message and the monitoring request applies to all the request of the bundle, even in the case of dependent and/or synchronized requests sent using more than one PCReq or PCMonReq message. >> >> >> In first case what happens if there is an SVEC object and Path >> Requests >> are spread in multiple PCRep messages. Must the Monitoring object be >> repeated? >> See above. >> If a PCRep contains a Monitoring object, is it possible that >> this PCRep contains Path replies not related to the Monitoring >> request? Yes because in the BNF, the is per in the Thanks for the comments. Cheers, JP. >> > > Issue stands. > > Happy New Year > > Adrian > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce --Apple-Mail-89-646561441 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi,

On Dec = 31, 2008, at 8:07 PM, Adrian Farrel wrote:



Section 3.2:

The format of a = PCReq message is as follows:

Must = be

The format of a PCMonRep message is as = follows:

Issue = stands

Fixed.



Section = 4.1:

Seems the first = sentence is repeated twice.

Fixed in revision = -03

Besides it is said that the = Monitoring object MAY be included in
PCReq and PCRep so I think it would be good to add the = enhanced
PCReq and PCRep BNF = description.

Issue = stands


Added.

Also in = 4.1
s/PCEReq/PCReq/


Fixed= .

General comment:

The in-band = monitoring request is not fully clear to me.


You = are right that this is not clearly explained in the current = text.

If= there are several path computation requests in the = PCReq
which one is = targeting?
i.e. Must the PCE = return the processing time for each request = seperatly
or a single = processing time for all = requests?

We could = decide to have one MONITORING object per request in the bundle case but = this does
introduce some complexity and is not likely to be = that useful. I'd rather propose to keep the current
mode with = one MONITORING object per PCMonReq or PCReq message. When present = the 
monitoring request applies to all requests of the = bundle. Text added in section = 3.2.

"
As pointed out in [PCEP] = we can have several situations:
 o   Bundle of a set of independent and =
non-synchronized path
      computation requests,

   o  Bundle of a set of independent and synchronized path computation
       requests (SVEC object defined below required),

   o  Bundle of a set of dependent and synchronized path computation
       requests (SVEC object defined below =
required).

In the case of a bundle of a set of request, =
the MONITORING object SHOULD only be present in =
the
first PCReq or PCMonReq message and the monitoring request =
applies to all the request of the bundle,
even in the case =
of dependent and/or synchronized requests sent using more than one PCReq =
or 
PCMonReq =
message.




In first case = what happens if there is an SVEC object and Path = Requests
are spread in = multiple PCRep messages. Must the Monitoring object = be
repeated?


See = above.

If a PCRep contains a Monitoring object, is it possible = that
this PCRep contains Path = replies not related to the Monitoring
request?

= Yes because in the BNF, the <metric-pce-list> is per in the = <response>

Thanks for the = comments.

Cheers,


= --Apple-Mail-89-646561441-- --===============2059454373== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --===============2059454373==-- From pce-bounces@ietf.org Mon Jan 19 01:24:10 2009 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ACF828C198; Mon, 19 Jan 2009 01:24:10 -0800 (PST) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 440C03A683E for ; Mon, 19 Jan 2009 01:24:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.535 X-Spam-Level: X-Spam-Status: No, score=-10.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjEOvBmLxkzw for ; Mon, 19 Jan 2009 01:24:08 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 1E3673A6B84 for ; Mon, 19 Jan 2009 01:24:07 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,288,1231113600"; d="scan'208";a="31231548" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 19 Jan 2009 09:23:51 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n0J9Npqc016371 for ; Mon, 19 Jan 2009 10:23:51 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0J9Npcd026266 for ; Mon, 19 Jan 2009 09:23:51 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jan 2009 10:23:51 +0100 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jan 2009 10:23:50 +0100 Message-Id: <2DC6A2F8-2DFE-470C-A6FB-103BB0968194@cisco.com> From: JP Vasseur To: pce@ietf.org Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 19 Jan 2009 10:23:50 +0100 X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 19 Jan 2009 09:23:50.0894 (UTC) FILETIME=[A3DF80E0:01C97A17] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=359; t=1232357031; x=1233221031; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20PCE=20WG=20on=20draft-ietf-pce-p2mp-app-00.txt |Sender:=20; bh=XgBaniUH6vvuuk3THxvbytVGHI29EPfzF9TkTqn7lKA=; b=Rkf9C9IGL8vqpSYuSfeLWjQm5D4QApnk/PsPv2yvhvaeRqTSqfNRuqBi1r njfxe1epuic5bRQ7QOMc4XxINh15WflzCmcK1YhLo4vy3FWP9bycLcf3Zkk3 rtEtIJt8mK; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: [Pce] PCE WG on draft-ietf-pce-p2mp-app-00.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Dear Wg, According to the authors, draft-ietf-pce-p2mp-app-00.txt is now stable. This starts a 3 week WG Last Call that will end on February 9, noon ET. Although that I-D has been discussed several times, we would like to see a few reviews during WG Last Call. Thanks to send your comments on the list and to the authors. Thanks. JP. _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Mon Jan 19 03:40:06 2009 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 966EA28C1AD; Mon, 19 Jan 2009 03:40:06 -0800 (PST) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C51128C1AD for ; Mon, 19 Jan 2009 03:40:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.834 X-Spam-Level: X-Spam-Status: No, score=-1.834 tagged_above=-999 required=5 tests=[AWL=0.764, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQmxIEOjL0Hd for ; Mon, 19 Jan 2009 03:40:03 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id C2DEB28C19E for ; Mon, 19 Jan 2009 03:40:01 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id n0JBdaZa024887; Mon, 19 Jan 2009 11:39:36 GMT Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id n0JBdZIc024855; Mon, 19 Jan 2009 11:39:35 GMT Message-ID: <80C8540CF2924B0B9C71FA7666ACA3F6@your029b8cecfe> From: "Adrian Farrel" To: "JP Vasseur" References: <34CD72EB03F6410D9C8BBB1C40758C86@your029b8cecfe> Date: Mon, 19 Jan 2009 11:37:37 -0000 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: pce@ietf.org Subject: Re: [Pce] Last call comments on draft-ietf-pce-monitoring-02.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Hi, Thanks for the work. Very nearly converged on everything. >> Section 3.2 >> >> Are you sure that you want to send an Error message in response to a >> bad PCMonRep? >> >> Sending an Error in response to a PCMonReq is useful because it >> cancels the request and means the sender does not continue to wait >> or a PCMonRep. But sending an Error in response to a PCMonRep does >> not seem to have any use except to load the network. For example, >> what is the state of the outstanding PCMonReq in this situation? >> What is the sender of the PCMonRep supposed to do when it receives >> the Error message? >> >> More appropriate would be for the receiver of the bad PCMonRep to >> raise an alert to the operator and to put the sender of the bad >> message on a blacklist so that it never send it another PCMonReq. > > Well yes but ... error message are not only useful for the PCC to > clean states but for troubleshooting on both sides, especially on the > PCC side where the absence of reply can either be interpreted as a > lost request, overloaded PCE, malformed request, .... Furthermore, it > is inline with the general approach taken by PCEP when a message is > received that does not carry a mandatory object. Well, in fact there is no state to be cleaned by this error message. The error is sent in response to a PCMonRep. The PCMonRep has already cleaned the state. I agree the error message can be used for trouble shooting, but not in the way you say. You say: > the absence of reply can either be interpreted as a > lost request, overloaded PCE, malformed request but there is no absent reply in this case. There is not normally a positive response to a PCEMonRep, so there is nothing expected. Furthermore, you say: "Furthermore..." But what does PCEP do with a malformed PCErr? Section 6.7 of PCEP says: The PCErr message is sent by a PCC or a PCE in response to a request or in an unsolicited manner. So, here it says implicitly that it is not sent in response to a response. But I believe we had this same "discussion" about Error-Type 8. :-) My biggest concerns are: 1. Broken system such that bad PCMonRep is sent in every case or sporadically (or even as part of an attack). This will always trigger an error response. This is not so important, so perhaps the text in this I-D can stand. [Which means I am not demanding you change this I-D.] 2. A tight loop where a PCC and PCE object to each other's PCErr messages and respond with a new PCErr message which is objected to with a PCErr message, etc. But perhaps this should have been in the PCEP spec. >> Section 4.4 >> >> - You need to explain that setting the C bit and a congestion >> duration of zero has meaning. If it has no meaning, you don't >> need the C bit. > > It is stated in the text: "When cleared this indicates that the PCE is > not congested and the "Congestion Duration" field MUST be set to > 0x0000". > C=0 means "no congestion on the PCE". Hmm, yes. I saw that in the I-D. This says: C=0 means CD MUST be 0x0000 What is meant by: C=1, CD=0x0000 ? If this has meaning, what is it? If it has no meaning, then we do not need the C bit since: CD=0x0000 is equivalent to C=0 and CD!=0x0000 is equivalent to C=1 And anyway, why is the Congestion object present with the C bit clear? Surely the object should simply be absent? That removes the duplication between the C bit in the Congestion object and the C bit in the Monitoring object. >> - Although it verges on telling the implementer how to write code >> I think some advice is needed on what to do when a >> CONGESTION object is received with the C bit set. There >> are two aspects... >> - How long has the CONGESTION object taken to propagate >> from the reporting PCE to the PCC (might not be one hop)? >> - What should the receiver do with the Congestion Duration >> value? > > You already know what I think about this ;-))) It is in my opinion > very much implementation dependent, don't you think ? > First of all, specifying what the PCC should be in this document is a > bit awkward. Indeed, it could be for pure management > purposes (out of band) or in the context of a particular path > computation request (e.g. after a PCreq local timeout). Even > in that latter case, the PCC may decide to back-off and retry or > select another PCE, depending on the urgency of the request > which is usually context dependent (the PCC may decide to select > another PCE for an already retransmitted request if the > priority is > X, ....). Furthermore the PCC may also be a function of > the reported congestion value, ... > > I would argue that documenting this behavior is out of scope (not a > monitoring issue) and very much implementation/application specific. Well... There is very little in the draft about the meaning of the Congestion Duration field. In fact, *all* we have is: Congestion duration - 16 bits: This field indicates in seconds the estimated congestion duration. Maybe we can address my concerns by beefing this text up a bit. For example... Congestion duration - 16 bits: This field indicates in the amount of time in seconds that the responding PCE expects that it may continue to be congested from the time that the response message was generated. The receiver MAY use this value to decide whether or not so send further requests to the same PCE. >> Section 6, case 2) >> >> You should refer back to Section 5. > > Yes. > >> But note also that you have an explicit case (section 4.3) where >> policy causes the message to be processed but an object to be left >> out of the reply. > > Not sure to see which case you're referring to ? Section 4.3 says... If allowed by policy, the PCE includes a PROC-TIME object within a PCMonRep or a PCRep message That means that you can set a policy that causes the object to be left out even if requested by setting the P bit of the MONITORING object. So, part of the request is prohibited by policy, but a response (not an error) is still generated. Perhaps add a note: Compare this case with that in Section 4.3 where part of the request is prohibited by policy, but the request is still processed. >> Section 9 >> >> Does the information gathered by monitoring represent any additional >> vulnerability? Could an attacker gain interesting information by >> snooping this? >> >> I think the Congestion object is a good and lightweight way to >> attack a PCE deployment. > > Yes indeed but similarly to regular PCReq messages for which we have > suggested security mechanism. > >> You should note this and suggest that this makes the use of security >> mechanisms important. You may also need to node that there is a >> chain of trust model here such that even if one PCE ensures that it >> uses security, the information it supplies can be changed on a hop >> further upstream. Therefore, a consistent security model across all >> cooperating PCEs is desirable. > > Right but again this is true for regular PCRep message. > > Text Added (let me know if you think that this is sufficient): Yes this is good. The point is not to provide additional security techniques, but to explain to the deployer the additional vulnerabilities that might make them want to turn on the existing security techniques. You now have this covered. Just a couple of points to reach agreement on then: - spell-check - IPR boilerplate - idnits - post Cheers, Adrian _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Mon Jan 19 04:55:58 2009 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6195B3A6900; Mon, 19 Jan 2009 04:55:58 -0800 (PST) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E44B3A67FD for ; Mon, 19 Jan 2009 04:55:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRO+C4rwW39m for ; Mon, 19 Jan 2009 04:55:56 -0800 (PST) Received: from bizpsie3.9services.com (bizpsie3.9services.com [84.96.93.161]) by core3.amsl.com (Postfix) with ESMTP id AB9433A67E5 for ; Mon, 19 Jan 2009 04:55:55 -0800 (PST) Received: from pooky.marben-products.com ([86.65.15.130]) by bizpsie3.9services.com with 9services id 5Qvy1b0012oN1dS03Qvykl; Mon, 19 Jan 2009 13:55:59 +0100 X-Biz3: ?? X-VRSPAM-SCORE: -80.00 Received: from AOFR11476 (aofr11476.marben-products.com [192.168.7.180]) by pooky.marben-products.com (8.14.0/8.14.0) with ESMTP id n0JCtZ5e018473; Mon, 19 Jan 2009 13:55:36 +0100 From: "Fabien Verhaeghe" To: "'JP Vasseur'" , "'Adrian Farrel'" Date: Mon, 19 Jan 2009 13:55:30 +0100 Message-ID: <003f01c97a35$391bd330$b407a8c0@marbenproducts.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <003e01c97a33$3af279e0$b407a8c0@marbenproducts.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acl6Mzd0cKhJ1NgMRUGln+arH0kyDgAAArUQ Cc: pce@ietf.org Subject: Re: [Pce] PCE Monitoring : wrong version last called X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Hi JP, Thanks for the update. Everything seems fine to me except 2 minor comments. See inline >> That is my fault :-( >> >> The I-D is at revision -03 >> >> http://www.ietf.org/internet-drafts/draft-ietf-pce-monitoring-03.txt >> >> You still have until Monday next week if you want to make comments. >> >> As my punishment, I have gone through Fabien's email to check which of >> his coments still apply... >> >> >> Below my comments on monitoring draft: >> >> Section 3.1: >> >> Example 3: The request must also contain a MONITORING object. >> >> Issue stands. >> > That was "in addition to" but the text had been clarified, thanks. > > Ok >> Section 3.2: >> >> The format of a PCReq message is as follows: >> >> Must be >> >> The format of a PCMonRep message is as follows: >> >> Issue stands > > Fixed. > Format of a PCMonReq (out of band request): Must be replaced by Format of a PCMonRep (out of band request): >> >> Section 4.1: >> >> Seems the first sentence is repeated twice. >> >> Fixed in revision -03 >> >> >> Besides it is said that the Monitoring object MAY be included in >> PCReq and PCRep so I think it would be good to add the enhanced >> PCReq and PCRep BNF description. >> >> Issue stands >> > Added. > Ok >> >> Also in 4.1 >> s/PCEReq/PCReq/ >> > Fixed. > Ok >> >>General comment: >> >> The in-band monitoring request is not fully clear to me. >> > > You are right that this is not clearly explained in the current text. > >> >> If there are several path computation requests in the PCReq >> which one is targeting? >> i.e. Must the PCE return the processing time for each request seperatly >> or a single processing time for all requests? > > We could decide to have one MONITORING object per request in the bundle > case > but this does > introduce some complexity and is not likely to be that useful. I'd rather > propose to keep the current > mode with one MONITORING object per PCMonReq or PCReq message. When > present > the > monitoring request applies to all requests of the bundle. Text added in > section 3.2. > Seems good to me except maybe I would rather put the text in section 3.1 that deals with PCReq. > " > As pointed out in [PCEP] we can have several situations: > o Bundle of a set of independent and non-synchronized path > computation requests, > > o Bundle of a set of independent and synchronized path computation > requests (SVEC object defined below required), > > o Bundle of a set of dependent and synchronized path computation > requests (SVEC object defined below required). > > In the case of a bundle of a set of request, the MONITORING object SHOULD > only be present in the > first PCReq or PCMonReq message and the monitoring request applies to all > the request of the bundle, > even in the case of dependent and/or synchronized requests sent using more > than one PCReq or > PCMonReq message. > > > > > >> In first case what happens if there is an SVEC object and Path Requests >> are spread in multiple PCRep messages. Must the Monitoring object be >> repeated? > > > See above. > Ok > >> If a PCRep contains a Monitoring object, is it possible that >> this PCRep contains Path replies not related to the Monitoring >> request? > > Yes because in the BNF, the is per in the > Ok > Thanks for the comments. > > Cheers, > > JP. > > > > > Issue stands. > > Happy New Year > > Adrian > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Mon Jan 19 23:14:06 2009 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 495703A6820; Mon, 19 Jan 2009 23:14:06 -0800 (PST) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DBC83A6820 for ; Mon, 19 Jan 2009 23:14:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nd0SxaKXrnQp for ; Mon, 19 Jan 2009 23:14:05 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id EE3773A67FB for ; Mon, 19 Jan 2009 23:13:56 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,294,1231113600"; d="scan'208,217";a="31337281" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 20 Jan 2009 07:13:35 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n0K7DZvf030950; Tue, 20 Jan 2009 08:13:35 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0K7DZZC002329; Tue, 20 Jan 2009 07:13:35 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jan 2009 08:13:35 +0100 Received: from ams-jvasseur-8711.cisco.com ([10.55.201.130]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jan 2009 08:13:30 +0100 Message-Id: <5F174B33-3B10-4157-B1E6-B2E94B63646B@cisco.com> From: JP Vasseur To: "Adrian Farrel" In-Reply-To: <80C8540CF2924B0B9C71FA7666ACA3F6@your029b8cecfe> Content-Type: multipart/mixed; boundary=Apple-Mail-5-725339526 Mime-Version: 1.0 (Apple Message framework v930.3) X-Priority: 3 Date: Tue, 20 Jan 2009 08:13:29 +0100 References: <34CD72EB03F6410D9C8BBB1C40758C86@your029b8cecfe> <80C8540CF2924B0B9C71FA7666ACA3F6@your029b8cecfe> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 20 Jan 2009 07:13:30.0856 (UTC) FILETIME=[992E2680:01C97ACE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=352686; t=1232435615; x=1233299615; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Pce]=20Last=20call=20comments=20on=20d raft-ietf-pce-monitoring-02.txt |Sender:=20; bh=nE/ZLkVQ0wWw9fn6cP+IFNadT9Rmh39y0dv0R/aoITI=; b=lvlPa2ZY7G4/CoQcUqwDzyg6A8tx5xgoLamZeJK3pXXj+2jz5ouDiSTnL1 grXtgUcJCSGrgjvSR76P7HG8lVWFTy+LZ0GnTeFKoKOIq1yp52k27reklR1X 1Z2fHzme//; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: pce@ietf.org Subject: Re: [Pce] Last call comments on draft-ietf-pce-monitoring-02.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org --Apple-Mail-5-725339526 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Adrian, On Jan 19, 2009, at 12:37 PM, Adrian Farrel wrote: > Hi, > > Thanks for the work. Very nearly converged on everything. > >>> Section 3.2 >>> >>> Are you sure that you want to send an Error message in response to a >>> bad PCMonRep? >>> >>> Sending an Error in response to a PCMonReq is useful because it >>> cancels the request and means the sender does not continue to wait >>> or a PCMonRep. But sending an Error in response to a PCMonRep does >>> not seem to have any use except to load the network. For example, >>> what is the state of the outstanding PCMonReq in this situation? >>> What is the sender of the PCMonRep supposed to do when it receives >>> the Error message? >>> >>> More appropriate would be for the receiver of the bad PCMonRep to >>> raise an alert to the operator and to put the sender of the bad >>> message on a blacklist so that it never send it another PCMonReq. >> >> Well yes but ... error message are not only useful for the PCC to >> clean states but for troubleshooting on both sides, especially on the >> PCC side where the absence of reply can either be interpreted as a >> lost request, overloaded PCE, malformed request, .... Furthermore, it >> is inline with the general approach taken by PCEP when a message is >> received that does not carry a mandatory object. > > Well, in fact there is no state to be cleaned by this error message. > The error is sent in response to a PCMonRep. The PCMonRep has > already cleaned the state. > Yes, I was to fast I was thinking of a Re*q* not a Re*p*, still useful for troubleshooting though. > I agree the error message can be used for trouble shooting, but not > in the way you say. You say: >> the absence of reply can either be interpreted as a >> lost request, overloaded PCE, malformed request > but there is no absent reply in this case. Yes I was thinking of a Re*q* > There is not normally a positive response to a PCEMonRep, so there > is nothing expected. > > Furthermore, you say: "Furthermore..." > But what does PCEP do with a malformed PCErr? > > Section 6.7 of PCEP says: > The PCErr message is sent by a PCC or a PCE in response to a request > or in an unsolicited manner. > So, here it says implicitly that it is not sent in response to a > response. > > But I believe we had this same "discussion" about Error-Type 8. :-) > Indeed ;-) > My biggest concerns are: > 1. Broken system such that bad PCMonRep is sent in every case > or sporadically (or even as part of an attack). Although we have protection mechanism against such attacks. > This will always > trigger an error response. > This is not so important, so perhaps the text in this I-D can stand. > [Which means I am not demanding you change this I-D.] > 2. A tight loop where a PCC and PCE object to each other's PCErr > messages and respond with a new PCErr message which is objected > to with a PCErr message, etc. > But perhaps this should have been in the PCEP spec. > Yes, the loop would be very tight. >>> Section 4.4 >>> >>> - You need to explain that setting the C bit and a congestion >>> duration of zero has meaning. If it has no meaning, you don't >>> need the C bit. >> >> It is stated in the text: "When cleared this indicates that the PCE >> is >> not congested and the "Congestion Duration" field MUST be set to >> 0x0000". >> C=0 means "no congestion on the PCE". > > Hmm, yes. I saw that in the I-D. > > This says: > C=0 means CD MUST be 0x0000 > > What is meant by: > C=1, CD=0x0000 ? > > If this has meaning, what is it? > > If it has no meaning, then we do not need the C bit since: > CD=0x0000 is equivalent to C=0 > and > CD!=0x0000 is equivalent to C=1 > > And anyway, why is the Congestion object present with the C bit > clear? Surely the object should simply be absent? > That removes the duplication between the C bit in the Congestion > object and the C bit in the Monitoring object. > I see your point, yes I do agree. Next text: >>> - Although it verges on telling the implementer how to write code >>> I think some advice is needed on what to do when a >>> CONGESTION object is received with the C bit set. There >>> are two aspects... >>> - How long has the CONGESTION object taken to propagate >>> from the reporting PCE to the PCC (might not be one hop)? >>> - What should the receiver do with the Congestion Duration >>> value? >> >> You already know what I think about this ;-))) It is in my opinion >> very much implementation dependent, don't you think ? >> First of all, specifying what the PCC should be in this document is a >> bit awkward. Indeed, it could be for pure management >> purposes (out of band) or in the context of a particular path >> computation request (e.g. after a PCreq local timeout). Even >> in that latter case, the PCC may decide to back-off and retry or >> select another PCE, depending on the urgency of the request >> which is usually context dependent (the PCC may decide to select >> another PCE for an already retransmitted request if the >> priority is > X, ....). Furthermore the PCC may also be a function of >> the reported congestion value, ... >> >> I would argue that documenting this behavior is out of scope (not a >> monitoring issue) and very much implementation/application specific. > > Well... > There is very little in the draft about the meaning of the > Congestion Duration field. In fact, *all* we have is: > > Congestion duration - 16 bits: This field indicates in seconds the > estimated congestion duration. > > Maybe we can address my concerns by beefing this text up a bit. For > example... > > Congestion duration - 16 bits: This field indicates in the amount > of time > in seconds that the responding PCE expects that it may continue to be > congested from the time that the response message was generated. The > receiver MAY use this value to decide whether or not so send further > requests to the same PCE. Perfectly fine, text modified. 4.4. CONGESTION Object The CONGESTION object is used to report a PCE processing congestion state. The CONGESTION object MUST be present within a PCMonRep or a PCRep message if the C bit of the MONITORING object carried within the corresponding PCMonReq or PCReq message is set and the PCE is experiencing a congested state. The CONGESTION Object-Class is to be assigned by IANA (recommended value=22) The CONGESTION Object-Type is to be assigned by IANA (recommended value=1) The format of the CONGESTION object body is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | Congestion Duration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flags: 8 bits - No flag is currently defined: Congestion duration - 16 bits: This field indicates in the amount of time in seconds that the responding PCE expects that it may continue to be congested from the time that the response message was generated. The receiver MAY use this value to decide whether or not so send further requests to the same PCE. It is worth noting that a PCE along a PCE chain involved in the monitoring request may decide to learn from the congestion information received by one of downstream PCE in the chain. > > >>> Section 6, case 2) >>> >>> You should refer back to Section 5. >> >> Yes. >> >>> But note also that you have an explicit case (section 4.3) where >>> policy causes the message to be processed but an object to be left >>> out of the reply. >> >> Not sure to see which case you're referring to ? > > Section 4.3 says... > If allowed by policy, the PCE includes a PROC-TIME object within a > PCMonRep or a PCRep message > That means that you can set a policy that causes the object to be > left out even if requested by setting the P bit of the MONITORING > object. > > So, part of the request is prohibited by policy, but a response (not > an error) is still generated. > > Perhaps add a note: > > Compare this case with that in Section 4.3 where part of the request > is prohibited by policy, but the request is still processed. Note added in section 6: "As pointed out in section 4.3, a PCE may still partially satisfy a request, leaving out some of the required data if not allowed by policy." > > >>> Section 9 >>> >>> Does the information gathered by monitoring represent any additional >>> vulnerability? Could an attacker gain interesting information by >>> snooping this? >>> >>> I think the Congestion object is a good and lightweight way to >>> attack a PCE deployment. >> >> Yes indeed but similarly to regular PCReq messages for which we have >> suggested security mechanism. >> >>> You should note this and suggest that this makes the use of security >>> mechanisms important. You may also need to node that there is a >>> chain of trust model here such that even if one PCE ensures that it >>> uses security, the information it supplies can be changed on a hop >>> further upstream. Therefore, a consistent security model across all >>> cooperating PCEs is desirable. >> >> Right but again this is true for regular PCRep message. >> >> Text Added (let me know if you think that this is sufficient): > > Yes this is good. > > The point is not to provide additional security techniques, but to > explain to the deployer the additional vulnerabilities that might > make them want to turn on the existing security techniques. You now > have this covered. > > > > Just a couple of points to reach agreement on then: > - spell-check > - IPR boilerplate > - idnits > - post > Thanks again for the thorough review. Diffs: --Apple-Mail-5-725339526 Content-Disposition: attachment; filename*0="Diff: draft-ietf-pce-monitoring-03.txt - draft-ietf-pce-monitori"; filename*1=ng-04.webarchive Content-Type: application/octet-stream; x-mac-hide-extension=yes; x-unix-mode=0644; name="Diff: draft-ietf-pce-monitoring-03.txt - draft-ietf-pce-monitoring-04.webarchive" Content-Transfer-Encoding: quoted-printable bplist00=D1=01=02_=10=0FWebMainResource=D5=03=04=05=06=07=08=09=0A=0B=0C= ^WebResourceURL_=10=1BWebResourceTextEncodingName_=10=13WebResourceMIMETyp= e_=10=0FWebResourceData_=10=14WebResourceFrameName_=10=1Dhttp://tools.ietf= .org/rfcdiffUUTF-8Ytext/htmlO=12=00=03=B8=1C=20=0A=20=20= =20=0A=20=20=20=0A=20=20= Diff:=20draft-ietf-pce-monitoring-03.txt=20-=20= draft-ietf-pce-monitoring-04.txt=20=0A=20=20=20=0A=20=20=20=20body=20=20=20=20{=20margin:=200.4ex;=20= margin-right:=20auto;=20}=20=0A=20=20=20=20tr=20=20=20=20=20=20{=20}=20=0A= =20=20=20=20td=20=20=20=20=20=20{=20white-space:=20pre;=20font-family:=20= monospace;=20vertical-align:=20top;=20font-size:=200.86em;}=20=0A=20=20=20= =20th=20=20=20=20=20=20{=20font-size:=200.86em;=20}=20=0A=20=20=20=20= .small=20=20{=20font-size:=200.6em;=20font-style:=20italic;=20= font-family:=20Verdana,=20Helvetica,=20sans-serif;=20}=20=0A=20=20=20=20= .left=20=20=20{=20background-color:=20#EEE;=20}=20=0A=20=20=20=20.right=20= =20{=20background-color:=20#FFF;=20}=20=0A=20=20=20=20.diff=20=20=20{=20= background-color:=20#CCF;=20}=20=0A=20=20=20=20.lblock=20{=20= background-color:=20#BFB;=20}=20=0A=20=20=20=20.rblock=20{=20= background-color:=20#FF8;=20}=20=0A=20=20=20=20.insert=20{=20= background-color:=20#8FF;=20}=20=0A=20=20=20=20.delete=20{=20= background-color:=20#ACF;=20}=20=0A=20=20=20=20.void=20=20=20{=20= background-color:=20#FFB;=20}=20=0A=20=20=20=20.cont=20=20=20{=20= background-color:=20#EEE;=20}=20=0A=20=20=20=20.linebr=20{=20= background-color:=20#AAA;=20}=20=0A=20=20=20=20.lineno=20{=20color:=20= red;=20background-color:=20#FFF;=20font-size:=200.7em;=20text-align:=20= right;=20padding:=200=202px;=20}=20=0A=20=20=20=20.elipsis{=20= background-color:=20#AAA;=20}=20=0A=20=20=20=20.left=20.cont=20{=20= background-color:=20#DDD;=20}=20=0A=20=20=20=20.right=20.cont=20{=20= background-color:=20#EEE;=20}=20=0A=20=20=20=20.lblock=20.cont=20{=20= background-color:=20#9D9;=20}=20=0A=20=20=20=20.rblock=20.cont=20{=20= background-color:=20#DD6;=20}=20=0A=20=20=20=20.insert=20.cont=20{=20= background-color:=20#0DD;=20}=20=0A=20=20=20=20.delete=20.cont=20{=20= background-color:=20#8AD;=20}=20=0A=20=20=20=20.stats,=20.stats=20td,=20= .stats=20th=20{=20background-color:=20#EEE;=20padding:=202px=200;=20}=20=0A= =20=20=20=0A=20=0A=20=20=20=0A=20=20=C2=A0draft-ietf-pce-monitoring-03.txt=C2=A0= =20= =C2=A0draft-ietf-pce-monitoring-04.txt=C2=A0=20= =0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20Networking=20= Working=20Group=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20JP.=20Vasseur,=20Ed.=20= Networking=20Working=20Group=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20JP.=20Vasseur,=20Ed.=0A=20=20=20=20=20=20Internet-Draft=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20Cisco=20Systems,=20Inc=20Internet-Draft=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Cisco=20Systems,=20Inc=0A=20=20=20=20=20=20Intended=20status:=20Standards=20= Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20JL.=20Le=20Roux=20Intended=20status:=20Standards=20Track=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20JL.=20= Le=20Roux=0A=20=20= =20=20=20=20=0A=20=20=20=20=20= =20Expires:=20May=206,=202009=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20France=20Telecom=20= Expires:=20July=20= 12,=202009=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20France=20= Telecom=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Y.=20Ikejiri=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Y.=20= Ikejiri=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20NTT=20= Communications=20Corporation=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20NTT=20Communications=20= Corporation=0A=20=20= =20=20=20=20=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20November=20= 2,=202008=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20January=208,=202009=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=20=20A=20set=20of=20= monitoring=20tools=20for=20Path=20Computation=20Element=20based=20= =20=20=20=20=20=20A=20set=20of=20monitoring=20= tools=20for=20Path=20Computation=20Element=20based=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Architecture=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Architecture=0A=20= =20=20=20=20=20=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20draft-ietf-pce-monitoring-03.txt=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= draft-ietf-pce-monitoring-04.txt=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20Status=20of=20this=20= Memo=20Status=20of=20this=20= Memo=0A=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20=20=20=20By=20= submitting=20this=20Internet-Draft,=20each=20author=20represents=20that=20= any=20=20=20=20By=20submitting=20= this=20Internet-Draft,=20each=20author=20represents=20that=20any=0A=20=20=20=20=20=20=20=20=20= applicable=20patent=20or=20other=20IPR=20claims=20of=20which=20he=20or=20= she=20is=20aware=20=20=20=20= applicable=20patent=20or=20other=20IPR=20claims=20of=20which=20he=20or=20= she=20is=20aware=0A= =20=20=20=20=20=20=20=20=20have=20been=20or=20will=20be=20disclosed,=20and=20= any=20of=20which=20he=20or=20she=20becomes=20=20=20=20have=20been=20or=20will=20be=20disclosed,=20and=20= any=20of=20which=20he=20or=20she=20becomes=0A=20=20=20=20=20=20=20=20=20aware=20will=20be=20= disclosed,=20in=20accordance=20with=20Section=206=20of=20BCP=20= 79.=20=20=20=20aware=20will=20be=20= disclosed,=20in=20accordance=20with=20Section=206=20of=20BCP=20= 79.=0A=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20=20=20=20= Internet-Drafts=20are=20working=20documents=20of=20the=20Internet=20= Engineering=20=20=20=20= Internet-Drafts=20are=20working=20documents=20of=20the=20Internet=20= Engineering=0A=20=20= =20=20=20=20=20=20=20Task=20Force=20(IETF),=20its=20areas,=20and=20= its=20working=20groups.=20=20Note=20that=20=20=20=20Task=20Force=20(IETF),=20its=20areas,=20and=20= its=20working=20groups.=20=20Note=20that=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20= skipping=20= to=20change=20at=20page=201,=20line=2038=20= skipping=20to=20change=20= at=20page=201,=20line=2038=0A=20=20= =20=20=20=20=20=20=20and=20may=20be=20updated,=20replaced,=20or=20= obsoleted=20by=20other=20documents=20at=20any=20=20=20=20and=20may=20be=20updated,=20replaced,=20or=20= obsoleted=20by=20other=20documents=20at=20any=0A=20=20=20=20=20=20=20=20=20time.=20=20It=20is=20= inappropriate=20to=20use=20Internet-Drafts=20as=20reference=20= =20=20=20time.=20=20It=20is=20inappropriate=20= to=20use=20Internet-Drafts=20as=20reference=0A=20=20=20=20=20=20=20=20=20material=20or=20to=20= cite=20them=20other=20than=20as=20"work=20in=20progress."=20= =20=20=20material=20or=20to=20cite=20them=20= other=20than=20as=20"work=20in=20progress."=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20The=20list=20of=20current=20Internet-Drafts=20= can=20be=20accessed=20at=20=20=20=20= The=20list=20of=20current=20Internet-Drafts=20can=20be=20accessed=20= at=0A=20=20=20=20=20= =20=20= =20=20http://www.ietf.org/ietf/1id-abstracts.txt.=20=20=20=20= http://www.ietf.org/ietf/1id-abstracts.txt.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20The=20list=20of=20Internet-Draft=20Shadow=20= Directories=20can=20be=20accessed=20at=20=20=20=20The=20list=20of=20Internet-Draft=20Shadow=20= Directories=20can=20be=20accessed=20at=0A=20=20=20=20=20=20=20=20=20= http://www.ietf.org/shadow.html.=20=20= =20=20http://www.ietf.org/shadow.html.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20This=20Internet-Draft=20will=20expire=20on=20= May=206,=202009.=20=20=20=20This=20Internet-Draft=20will=20expire=20on=20= July=2012,=202009.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20Abstract=20Abstract=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20A=20Path=20Computation=20Element=20(PCE)=20based=20= architecture=20has=20been=20=20=20=20= A=20Path=20Computation=20Element=20(PCE)=20based=20architecture=20has=20= been=0A=20=20=20=20= =20=20=20=20=20specified=20for=20the=20computation=20of=20= Traffic=20Engineering=20(TE)=20Label=20=20=20=20specified=20for=20the=20computation=20of=20= Traffic=20Engineering=20(TE)=20Label=0A=20=20=20=20=20=20=20=20=20Switched=20Paths=20= (LSPs)=20in=20Multiprotocol=20Label=20Switching=20(MPLS)=20and=20= =20=20=20Switched=20Paths=20(LSPs)=20in=20= Multiprotocol=20Label=20Switching=20(MPLS)=20and=0A=20=20=20=20=20=20=20=20=20= Generalized=20MPLS=20(GMPLS)=20networks=20in=20the=20context=20of=20= single=20or=20=20=20=20Generalized=20= MPLS=20(GMPLS)=20networks=20in=20the=20context=20of=20single=20= or=0A=20=20=20=20=20= =20=20= =20=20multiple=20domains=20(where=20a=20domain=20refers=20to=20a=20= collection=20of=20network=20=20=20=20= multiple=20domains=20(where=20a=20domain=20refers=20to=20a=20collection=20= of=20network=0A=20= =20=20=20=20=20=20=20=20elements=20within=20a=20common=20sphere=20of=20= address=20management=20or=20path=20=20= =20=20elements=20within=20a=20common=20sphere=20of=20address=20= management=20or=20path=0A=20=20=20=20=20=20=20=20=20computational=20= responsibility=20such=20as=20IGP=20areas=20and=20Autonomous=20= =20=20=20computational=20responsibility=20= such=20as=20IGP=20areas=20and=20Autonomous=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= Systems).=20=20In=20PCE-based=20environments,=20it=20is=20thus=20= critical=20to=20monitor=20=20=20=20= Systems).=20=20Path=20Computation=20Clients=20= (PCCs)=20send=20computation=20requests=0A=20=20=20=20=20=20=20=20=20the=20state=20of=20= the=20path=20computation=20chain=20for=20troubleshooting=20and=20= =20=20=20to=20PCEs,=20= and=20these=20may=20forward=20the=20requests=20to=20and=20cooperate=20= with=0A=20=20= =20=20=20=20=20=20=20performance=20monitoring=20purposes:=20= liveness=20of=20each=20element=20(PCE)=20=20=20=20other=20PCEs=20= forming=20a=20"path=20computation=20chain".=20=20In=20= PCE-based=0A=20=20= =20=20=20=20=20=20=20involved=20in=20the=20PCE=20chain,=20detection=20= of=20potential=20resource=20contention=20=20=20=20environments,=20it=20is=20thus=20critical=20to=20= monitor=20the=20state=20of=20the=20path=0A=20=20=20=20=20=20=20=20=20states=20and=20= statistics=20in=20term=20of=20path=20computation=20times=20are=20= examples=20=20=20=20computation=20= chain=20for=20troubleshooting=20and=20performance=20monitoring=0A=20=20=20=20=20=20=20=20=20= of=20such=20metrics=20of=20interest.=20=20This=20document=20specifies=20= procedures=20and=20=20=20=20= purposes:=20liveness=20of=20each=20element=20(PCE)=20involved=20in=20the=20= PCE=20chain,=0A=20= =20=20=20=20=20=20=20=20extensions=20to=20the=20Path=20Computation=20= Element=20Protocol=20(PCEP)=20in=20order=20=20=20=20detection=20of=20potential=20resource=20= contention=20states=20and=20statistics=20in=0A=20=20=20=20=20=20=20=20=20to=20gather=20such=20= information.=20=20=20=20term=20of=20= path=20computation=20times=20are=20examples=20of=20such=20metrics=20= of=0A=20=20=20=20=20= =20=20=20=20=20= interest.=20=20This=20document=20specifies=20procedures=20and=20= extensions=20to=20the=0A=20=20=20=20=20=20=20=20=20=20Path=20Computation=20Element=20Protocol=20= (PCEP)=20in=20order=20to=20gather=20such=0A=20=20=20=20=20=20=20=20=20=20information.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20Requirements=20Language=20Requirements=20Language=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20The=20key=20words=20"MUST",=20"MUST=20NOT",=20= "REQUIRED",=20"SHALL",=20"SHALL=20NOT",=20=20=20=20The=20key=20words=20"MUST",=20"MUST=20NOT",=20= "REQUIRED",=20"SHALL",=20"SHALL=20NOT",=0A=20=20=20=20=20=20=20=20=20"SHOULD",=20"SHOULD=20= NOT",=20"RECOMMENDED",=20"MAY",=20and=20"OPTIONAL"=20in=20this=20= =20=20=20"SHOULD",=20"SHOULD=20NOT",=20= "RECOMMENDED",=20"MAY",=20and=20"OPTIONAL"=20in=20this=0A=20=20=20=20=20=20=20=20=20= document=20are=20to=20be=20interpreted=20as=20described=20in=20RFC=20= 2119=20[RFC2119].=20=20=20=20= document=20are=20to=20be=20interpreted=20as=20described=20in=20RFC=20= 2119=20[RFC2119].=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20Table=20of=20= Contents=20Table=20of=20= Contents=0A=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= =20= =20=201.=20=20Introduction=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20=203=20=20=20=20= 1.=20=20Introduction=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20=204=0A=20=20=20=20=20=20=20=20=202.=20=20Terminology=20= =20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20=204=20= =20=20=202.=20=20Terminology=20=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20=205=0A=20=20=20=20=20=20=20=20=20= 3.=20=20Path=20Computation=20Monitoring=20messages=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20=204=20=20=20=20= 3.=20=20Path=20Computation=20Monitoring=20messages=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20=205=0A=20=20=20=20=20=20=20=20=20=20=203.1.=20=20Path=20= Computation=20Monitoring=20Request=20message=20(PCMonReq)=20.=20.=20=20= 5=20=20= =20=20=20=203.1.=20=20Path=20Computation=20Monitoring=20Request=20= message=20(PCMonReq)=20.=20.=20=206=0A=20=20=20=20=20=20=20=20=20=20=203.2.=20=20Path=20= Monitoring=20Reply=20message=20(PCMonRep)=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20=207=20=20=20=20=20=203.2.=20=20Path=20Monitoring=20Reply=20= message=20(PCMonRep)=20.=20.=20.=20.=20.=20.=20.=20.=20.=20=209=0A=20=20=20=20=20=20=20=20=204.=20=20Path=20= Computation=20Monitoring=20Objects=20=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20=208=20= =20=20=204.=20=20Path=20Computation=20= Monitoring=20Objects=20=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=2011=0A=20=20=20=20=20=20=20=20=20=20=204.1.=20=20= MONITORING=20Object=20=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20=208=20=20=20=20= =20=204.1.=20=20MONITORING=20Object=20=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=2012=0A=20=20=20=20=20=20=20=20=20=20=204.2.=20=20= PCEP-ID=20Object=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=2010=20=20=20=20= =20=204.2.=20=20PCE-ID=20Object=20=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=2014=0A=20=20=20=20=20=20=20=20=20=20=204.3.=20=20= PROC-TIME=20Object=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=2011=20=20=20=20= =20=204.3.=20=20PROC-TIME=20Object=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=2014=0A=20=20=20=20=20=20=20=20=20=20=204.4.=20=20= CONGESTION=20Object=20=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=2013=20=20=20=20= =20=204.4.=20=20CONGESTION=20Object=20=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=2016=0A=20=20=20=20=20=20=20=20=205.=20=20Policy=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=2014=20=20=20=20= 5.=20=20Policy=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=2017=0A=20=20=20=20=20=20=20=20=206.=20=20Elements=20= of=20Procedure=20=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=2014=20= =20=20=206.=20=20Elements=20of=20Procedure=20= =20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=2017=0A=20=20=20=20=20=20=20=20=207.=20=20= Manageability=20Considerations=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=2015=20= =20=20=207.=20=20Manageability=20= Considerations=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=2019=0A=20=20=20=20=20=20=20=20=20=20=207.1.=20=20= Control=20of=20Function=20and=20Policy=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=2015=20= =20=20=20=20=207.1.=20=20Control=20of=20= Function=20and=20Policy=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=2019=0A=20=20=20=20=20=20=20=20=20=20=207.2.=20=20= Information=20and=20Data=20Models=20=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=2015=20= =20=20=20=20=207.2.=20=20Information=20and=20= Data=20Models=20=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=2019=0A=20=20=20=20=20=20=20=20=20=20=207.3.=20=20= Liveness=20Detection=20and=20Monitoring=20=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=2015=20= =20=20=20=20=207.3.=20=20Liveness=20= Detection=20and=20Monitoring=20=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=2020=0A=20=20=20=20=20=20=20=20=20=20=207.4.=20=20= Verify=20Correct=20Operations=20=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=2015=20= =20=20=20=20=207.4.=20=20Verify=20Correct=20= Operations=20=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=2020=0A=20=20=20=20=20=20=20=20=20=20=207.5.=20=20= Requirements=20On=20Other=20Protocols=20=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=2015=20= =20=20=20=20=207.5.=20=20Requirements=20On=20= Other=20Protocols=20=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= 20=0A=20=20=20=20=20=20=20=20=20=20=207.6.=20=20= Impact=20On=20Network=20Operations=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=2015=20= =20=20=20=20=207.6.=20=20Impact=20On=20= Network=20Operations=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=2020=0A=20=20=20=20=20=20=20=20=208.=20=20IANA=20= Considerations=20=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=2016=20=20=20=20= 8.=20=20IANA=20Considerations=20=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=2020=0A=20=20=20=20=20=20=20=20=209.=20=20Security=20= Considerations=20=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=2017=20= =20=20=20=20=208.1.=20= =20New=20PCEP=20Message=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=2020=0A=20=20=20=20=20=20=20=20=2010.=20= Acknowledgements=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=2017=20=20=20=20=20=208.2.=20=20New=20PCEP=20Objects=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=2020=0A=20= =20=20=20=20=20=20=20=2011.=20References=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=2017=20=20=20=20=20=208.3.=20=20New=20= Error-Type=20and=20Error-Values=20=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=2021=0A=20=20=20=20=20=20=20=20=20=20=2011.1.=20= Normative=20References=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=2017=20= =20=20=20=20=208.4.=20= =20MONITORING=20Object=20Flag=20Field=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=2021=0A=20=20=20=20=20=20=20=20=20=20=2011.2.=20= Informative=20References=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=2018=20= =20=20=20=20=208.5.=20= =20PROC-TIME=20Object=20Flag=20Field=20=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=2022=0A=20=20=20=20=20=20=20=20=20Authors'=20Addresses=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=2018=20= =20=20=20=20=208.6.=20= =20CONGESTION=20Object=20Flag=20field=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=2022=0A=20=20=20=20=20=20=20=20=20Intellectual=20= Property=20and=20Copyright=20Statements=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=2020=20=20=20=209.=20=20Security=20Considerations=20=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= 23=0A=20=20=20=20=20=20=20=20=20=2010.=20Acknowledgements=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= 23=0A=20=20=20=20=20=20=20=20=20=2011.=20References=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=2023=0A=20=20=20=20=20=20=20=20=20=20=20=2011.1.=20Normative=20References=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= 23=0A=20=20=20=20=20=20=20=20=20=20=20=2011.2.=20Informative=20References=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=2024=0A=20=20=20=20=20=20=20=20=20=20Authors'=20Addresses=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= 24=0A=20=20=20=20=20=20=20=20=20=20Intellectual=20Property=20and=20Copyright=20= Statements=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=2026=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=201.=20=20Introduction=201.=20=20Introduction=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20The=20Path=20Computation=20Element=20(PCE)=20= based=20architecture=20has=20been=20=20= =20=20The=20Path=20Computation=20Element=20(PCE)=20based=20architecture=20= has=20been=0A=20=20= =20=20=20=20=20=20=20specified=20in=20[RFC4655]=20for=20the=20= computation=20of=20Traffic=20Engineering=20=20=20=20specified=20in=20[RFC4655]=20for=20the=20= computation=20of=20Traffic=20Engineering=0A=20=20=20=20=20=20=20=20=20(TE)=20Label=20= Switched=20Paths=20(LSPs)=20in=20Multiprotocol=20Label=20= Switching=20=20=20=20(TE)=20Label=20= Switched=20Paths=20(LSPs)=20in=20Multiprotocol=20Label=20= Switching=0A=20=20= =20=20=20=20=20=20=20(MPLS)=20and=20Generalized=20MPLS=20(GMPLS)=20= networks=20in=20the=20context=20of=20single=20=20=20=20(MPLS)=20and=20Generalized=20MPLS=20(GMPLS)=20= networks=20in=20the=20context=20of=20single=0A=20=20=20=20=20=20=20=20=20or=20multiple=20= domains=20where=20a=20domain=20refers=20to=20a=20collection=20of=20= network=20=20=20=20or=20multiple=20= domains=20where=20a=20domain=20refers=20to=20a=20collection=20of=20= network=0A=20=20=20= =20=20=20=20=20=20elements=20within=20a=20common=20sphere=20of=20= address=20management=20or=20path=20=20= =20=20elements=20within=20a=20common=20sphere=20of=20address=20= management=20or=20path=0A=20=20=20=20=20=20=20=20=20computational=20= responsibility=20such=20as=20IGP=20areas=20and=20Autonomous=20= =20=20=20computational=20responsibility=20= such=20as=20IGP=20areas=20and=20Autonomous=0A=20=20=20=20=20=20=20=20=20Systems.=20= =20=20=20Systems.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20=20Path=20Computation=20Clients=20(PCCs)=20send=20= computation=20requests=20to=20PCEs,=0A=20=20=20=20=20=20=20=20=20=20and=20these=20may=20= forward=20the=20requests=20to=20and=20cooperate=20with=20other=20= PCEs=0A=20=20= =20=20=20=20=20=20=20=20forming=20a=20"path=20computation=20chain".=20=20= In=20PCE-based=20environments,=20it=20is=0A=20=20=20=20=20=20=20= =20=20=20critical=20= to=20monitor=20the=20state=20of=20the=20path=20computation=20chain=20= for=0A=20=20= =20=20=20=20=20=20=20=20troubeshooting=20and=20performance=20= monitoring=20purposes:=20liveness=20of=20each=0A=20=20=20=20=20=20=20= =20=20=20element=20= (PCE)=20involved=20in=20the=20PCE=20chain,=20detection=20of=20= potential=0A= =20=20=20=20=20=20=20=20=20=20resource=20contention=20states=20and=20= statistics=20in=20term=20of=20path=20computation=0A=20=20=20=20=20=20=20= =20=20=20times=20= are=20examples=20of=20such=20metrics=20of=20interest.=20=20This=20= document=0A= =20=20=20=20=20=20=20=20=20=20specifies=20procedures=20and=20extensions=20to=20= the=20Path=20Computation=20Element=0A=20=20=20=20=20=20=20=20=20=20Protocol=20(PCEP)=20= ([I-D.ietf-pce-pcep])=20in=20order=20to=20monitor=20the=20= path=0A=20=20= =20=20=20=20=20=20=20=20computation=20chain=20and=20gather=20various=20= performance=20metrics.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=0A=20= =20=20=20=20=20=20=20=20As=20defined=20in=20[RFC4655],=20there=20are=20= circumstances=20where=20more=20than=20one=20=20=20=20As=20defined=20in=20[RFC4655],=20there=20are=20= circumstances=20where=20more=20than=20one=0A=20=20=20=20=20=20=20=20=20PCE=20is=20involved=20= in=20the=20computation=20of=20a=20TE=20LSP.=20=20A=20typical=20example=20= is=20=20=20=20PCE=20is=20involved=20= in=20the=20computation=20of=20a=20TE=20LSP.=20=20A=20typical=20example=20= is=0A=20=20=20=20=20= =20=20= =20=20when=20the=20PCC=20requires=20the=20computation=20of=20a=20TE=20= LSP=20where=20the=20head-end=20=20=20= =20when=20the=20PCC=20requires=20the=20computation=20of=20a=20TE=20LSP=20= where=20the=20head-end=0A=20=20=20=20=20=20=20=20=20and=20the=20tail-end=20= of=20the=20TE=20LSP=20do=20not=20reside=20in=20adjacent=20domains=20= and=20=20=20=20and=20the=20tail-end=20= of=20the=20TE=20LSP=20do=20not=20reside=20in=20adjacent=20domains=20= and=0A=20=20=20=20= =20=20=20=20=20there=20is=20no=20single=20PCE=20with=20the=20= visibility=20of=20both=20the=20head-end=20and=20=20=20=20there=20is=20no=20single=20PCE=20with=20the=20= visibility=20of=20both=20the=20head-end=20and=0A=20=20=20=20=20=20=20=20=20tail-end=20domain.=20=20= We=20call=20the=20set=20of=20PCEs=20involved=20in=20the=20= computation=20=20=20=20tail-end=20= domain.=20=20We=20call=20the=20set=20of=20PCEs=20involved=20in=20the=20= computation=0A=20=20= =20=20=20=20=20=20=20of=20a=20TE=20LSP=20a=20"path=20computation=20= chain".=20=20As=20further=20discussed=20in=20=20=20=20of=20a=20TE=20LSP=20a=20"path=20computation=20= chain".=20=20As=20further=20discussed=20in=0A=20=20=20=20=20=20=20=20=20Section=203.1,=20the=20= PCE=20chain=20may=20either=20be=20static=20(pre-configured)=20= or=20=20=20=20Section=203.1,=20the=20= PCE=20chain=20may=20either=20be=20static=20(pre-configured)=20or=0A=20=20=20=20=20=20=20=20=20= dynamically=20determined=20during=20the=20path=20computation=20= process.=20=20=20=20dynamically=20= determined=20during=20the=20path=20computation=20process.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= In=20PCE-based=20environments,=20it=20is=20= critical=20to=20monitor=20the=20state=20of=20the=20= =0A=20=20=20=20=20=20=20=20= =20path=20computation=20chain=20for=20troubeshooting=20and=20performance=20= monitoring=20=0A=20=20=20=20=20=20=20=20=20purposes:=20liveness=20of=20each=20element=20= (PCE)=20involved=20in=20the=20PCE=20chain,=20=0A= =20=20=20=20=20=20=20=20=20detection=20of=20= potential=20resource=20contention=20states=20and=20statistics=20= in=20=0A=20=20=20=20=20=20=20=20=20term=20of=20path=20computation=20times=20are=20= examples=20of=20such=20metrics=20of=20=0A= =20=20=20=20=20=20=20=20=20interest.=20=20This=20= document=20specifies=20procedures=20and=20extensions=20to=20= the=20=0A=20=20=20=20=20=20=20=20=20Path=20Computation=20Element=20Protocol=20= (PCEP)=20([I-D.ietf-pce-pcep])=20in=20=0A= =20=20=20=20=20=20=20=20=20order=20to=20monitor=20= the=20path=20computation=20chain=20and=20gather=20= various=20=0A=20=20=20=20=20=20=20=20=20performance=20metrics.=20= =0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20As=20discussed=20in=20[RFC4655],=20a=20TE=20LSP=20= may=20be=20computed=20by=20one=20PCE=20=20=20=20As=20discussed=20in=20[RFC4655],=20a=20TE=20LSP=20= may=20be=20computed=20by=20one=20PCE=0A=20=20=20=20=20=20=20=20=20(referred=20to=20as=20= single=20PCE=20path=20computation)=20or=20several=20PCEs=20= =20=20=20(referred=20to=20as=20single=20PCE=20= path=20computation)=20or=20several=20PCEs=0A=20=20=20=20=20=20=20=20=20(referred=20to=20as=20= multiple=20PCE=20path=20computation).=20=20In=20the=20former=20= case,=20=20=20=20(referred=20to=20as=20= multiple=20PCE=20path=20computation).=20=20In=20the=20former=20= case,=0A=20=20=20=20= =20=20=20=20=20the=20PCC=20may=20be=20able=20to=20use=20IGP=20= extensions=20to=20check=20the=20liveness=20of=20=20=20=20the=20PCC=20may=20be=20able=20to=20use=20IGP=20= extensions=20to=20check=20the=20liveness=20of=0A=20=20=20=20=20=20=20=20=20the=20PCE=20(see=20= [RFC5088]=20and=20[RFC5089])=20or=20PCEP=20using=20Keepalive=20= =20=20=20the=20PCE=20(see=20[RFC5088]=20and=20= [RFC5089])=20or=20PCEP=20using=20Keepalive=0A=20=20=20=20=20=20=20=20=20messages.=20=20In=20= contrast,=20when=20multiple=20PCEs=20are=20involved=20in=20the=20= path=20=20=20=20messages.=20=20In=20= contrast,=20when=20multiple=20PCEs=20are=20involved=20in=20the=20= path=0A=20=20=20=20= =20=20=20=20=20computation=20chain=20an=20example=20of=20which=20= is=20the=20BRPC=20procedure=20defined=20=20=20=20computation=20chain=20an=20example=20of=20which=20= is=20the=20BRPC=20procedure=20defined=0A=20=20=20=20=20=20=20=20=20in=20= [I-D.ietf-pce-brpc],=20the=20PCC's=20visibility=20may=20be=20limited=20= to=20the=20=20=20=20in=20= [I-D.ietf-pce-brpc],=20the=20PCC's=20visibility=20may=20be=20limited=20= to=20the=0A=20=20=20= =20=20=20=20=20=20first=20PCE=20involved=20in=20the=20path=20= computation=20chain.=20=20Thus,=20it=20is=20=20=20=20first=20PCE=20involved=20in=20the=20path=20= computation=20chain.=20=20Thus,=20it=20is=0A=20=20=20=20=20=20=20=20=20critical=20to=20define=20= mechanisms=20in=20order=20to=20monitor=20the=20state=20of=20the=20= =20=20=20critical=20to=20define=20mechanisms=20= in=20order=20to=20monitor=20the=20state=20of=20the=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20= skipping=20= to=20change=20at=20page=204,=20line=2025=20= skipping=20to=20change=20= at=20page=205,=20line=2027=0A=20=20= =20=20=20=20=20=20=20more=20PCEs").=20=20=20=20more=20PCEs").=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20In=20this=20document=20we=20define=20two=20= monitoring=20request=20types:=20general=20and=20=20=20=20In=20this=20document=20we=20define=20two=20= monitoring=20request=20types:=20general=20and=0A=20=20=20=20=20=20=20=20=20specific.=20=20A=20= general=20monitoring=20request=20relates=20to=20the=20collection=20= of=20=20=20=20specific.=20=20A=20= general=20monitoring=20request=20relates=20to=20the=20collection=20= of=0A=20=20=20=20=20= =20=20= =20=20a=20PCE=20state=20metrics=20that=20is=20not=20coupled=20to=20a=20= particular=20path=20=20=20=20a=20PCE=20= state=20metrics=20that=20is=20not=20coupled=20to=20a=20particular=20= path=0A=20=20=20=20= =20=20=20=20=20computation=20request=20(e.g.=20average=20CPU=20= load=20on=20a=20PCE).=20=20Conversely,=20a=20=20=20=20computation=20request=20(e.g.=20average=20CPU=20= load=20on=20a=20PCE).=20=20Conversely,=20a=0A=20=20=20=20=20=20=20=20=20specific=20monitoring=20= request=20relates=20to=20a=20particular=20path=20computation=20= =20=20=20specific=20monitoring=20request=20= relates=20to=20a=20particular=20path=20computation=0A=20=20=20=20=20=20=20=20=20= request=20(processing=20time=20to=20complete=20the=20path=20computation=20= for=20a=20TE=20=20=20=20request=20= (processing=20time=20to=20complete=20the=20path=20computation=20for=20a=20= TE=0A=20=20=20=20=20= =20=20= =20=20LSP).=20=20=20=20LSP).=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20The=20= message=20formats=20in=20this=20document=20are=20specified=20using=20= Backus=20Naur=0A=20=20=20=20=20=20=20=20=20=20Format=20(BNF)=20= encoding=20as=20specified=20in=20= [I-D.farrel-rtg-common-bnf].=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=0A=20= =20=20=20=20=202.=20=20Terminology=202.=20=20Terminology=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20PCC=20(Path=20Computation=20Client):=20any=20= client=20application=20requesting=20a=20=20=20=20PCC=20(Path=20Computation=20Client):=20any=20= client=20application=20requesting=20a=0A=20=20=20=20=20=20=20=20=20path=20computation=20= to=20be=20performed=20by=20a=20Path=20Computation=20Element.=20= =20=20=20path=20computation=20to=20be=20= performed=20by=20a=20Path=20Computation=20Element.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20PCE=20(Path=20= Computation=20Element):=20an=20entity=20(component,=20application=20= or=20=20=20=20PCE=20(Path=20= Computation=20Element):=20an=20entity=20(component,=20application=20= or=0A=20=20=20=20=20= =20=20= =20=20network=20node)=20that=20is=20capable=20of=20computing=20a=20= network=20path=20or=20route=20=20=20=20= network=20node)=20that=20is=20capable=20of=20computing=20a=20network=20= path=20or=20route=0A= =20=20=20=20=20=20=20=20=20based=20on=20a=20network=20graph=20and=20= applying=20computational=20constraints.=20=20=20=20based=20on=20a=20network=20graph=20and=20= applying=20computational=20constraints.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20TE=20LSP:=20Traffic=20Engineering=20Label=20= Switched=20Path.=20=20=20=20TE=20= LSP:=20Traffic=20Engineering=20Label=20Switched=20Path.=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20= skipping=20= to=20change=20at=20page=205,=20line=206=20= skipping=20to=20change=20= at=20page=206,=20line=2010=0A=20=20= =20=20=20=20=20=20=20object=20is=20said=20to=20be=20mandatory=20in=20= a=20PCEP=20message=20when=20the=20object=20must=20=20=20=20object=20is=20said=20to=20be=20mandatory=20in=20= a=20PCEP=20message=20when=20the=20object=20must=0A=20=20=20=20=20=20=20=20=20be=20= included=20for=20the=20message=20to=20be=20considered=20as=20valid.=20=20= The=20P=20flag=20=20=20=20be=20= included=20for=20the=20message=20to=20be=20considered=20as=20valid.=20=20= The=20P=20flag=0A=20= =20=20=20=20=20=20=20=20(defined=20in=20[I-D.ietf-pce-pcep])=20is=20= located=20in=20the=20common=20header=20of=20=20=20=20(defined=20in=20[I-D.ietf-pce-pcep])=20is=20= located=20in=20the=20common=20header=20of=0A=20=20=20=20=20=20=20=20=20each=20PCEP=20object=20= and=20can=20be=20set=20by=20a=20PCEP=20peer=20to=20require=20a=20PCE=20= to=20=20=20=20each=20PCEP=20object=20= and=20can=20be=20set=20by=20a=20PCEP=20peer=20to=20require=20a=20PCE=20= to=0A=20=20=20=20=20= =20=20= =20=20take=20into=20account=20the=20related=20information=20during=20the=20= path=20=20=20=20take=20into=20= account=20the=20related=20information=20during=20the=20path=0A=20=20=20=20=20=20=20=20=20= computation.=20=20Because=20the=20P=20flag=20exclusively=20relates=20to=20= a=20path=20=20=20=20computation.=20=20= Because=20the=20P=20flag=20exclusively=20relates=20to=20a=20path=0A=20=20=20=20=20=20=20=20=20= computation=20request,=20it=20MUST=20be=20cleared=20in=20the=20two=20= PCEP=20messages=20=20=20=20= computation=20request,=20it=20MUST=20be=20cleared=20in=20the=20two=20= PCEP=20messages=0A= =20=20=20=20=20=20=20=20=20(PCEMonReq=20and=20PCMonRep=20message)=20defined=20= in=20this=20document.=20=20=20=20= (PCEMonReq=20and=20PCMonRep=20message)=20defined=20in=20this=20= document.=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20For=20= each=20PCEP=20message=20type=20a=20set=20of=20rules=20is=20defined=20= that=20specify=20the=20=20=20=20For=20= each=20PCEP=20message=20type=20a=20set=20of=20rules=20is=20defined=20= that=20specify=20the=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= set=20of=20objects=20that=20the=20message=20can=20carry.=20=20We=20use=20the=20Backus-Naur=20=20=20=20set=20of=20objects=20that=20the=20message=20= can=20carry.=20=20An=20implementation=20MUST=0A=20=20=20=20=20=20=20=20= =20Form=20(BNF)=20to=20specify=20such=20rules.=20=20Square=20brackets=20= refer=20to=20optional=20=20=20= =20form=20the=20PCEP=20messages=20using=20the=20object=20ordering=20= specified=20in=20this=0A=20=20=20=20=20=20=20=20= =20sub-sequences.=20=20An=20implementation=20MUST=20form=20the=20= PCEP=20messages=20using=20=20=20=20= document.=0A=20=20= =20=20=20=20=20=20=20the=20object=20ordering=20specified=20in=20= this=20document.=20=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20In=20this=20document=20= we=20define=20two=20PCEP=20messages=20referred=20to=20as=20the=20= Path=20=20=20=20In=20this=20document=20= we=20define=20two=20PCEP=20messages=20referred=20to=20as=20the=20= Path=0A=20=20=20=20= =20=20=0A=20=20=20=20=20=20= =20= =20=20Computation=20Monitoring=20request=20= (PCMonReq)=20and=20Path=20Computation=20=20=20=20Computation=20Monitoring=20Request=20(PCMonReq)=20and=20Path=20= Computation=0A=20=20= =20=20=20=20=20=20=20Monitoring=20Reply=20(PCMonRep)=20messages=20so=20= as=20to=20handle=20"out=20of=20band"=20=20=20=20Monitoring=20Reply=20(PCMonRep)=20messages=20so=20= as=20to=20handle=20"out=20of=20band"=0A=20=20=20=20=20=20=20=20=20monitoring=20request.=20= =20The=20aim=20of=20the=20PCMonReq=20message=20sent=20by=20a=20PCC=20= to=20=20=20=20monitoring=20request.=20= =20The=20aim=20of=20the=20PCMonReq=20message=20sent=20by=20a=20PCC=20= to=0A=20=20=20=20=20= =20=20= =20=20a=20PCE=20is=20to=20gather=20one=20or=20more=20PCE=20state=20= metrics=20on=20a=20set=20of=20PCEs=20=20= =20=20a=20PCE=20is=20to=20gather=20one=20or=20more=20PCE=20state=20= metrics=20on=20a=20set=20of=20PCEs=0A=20=20=20=20=20=20=20=20=20involved=20in=20a=20= path=20computation=20chain.=20=20The=20PCMonRep=20message=20sent=20by=20= a=20=20=20=20involved=20in=20a=20= path=20computation=20chain.=20=20The=20PCMonRep=20message=20sent=20by=20= a=0A=20=20=20=20=20= =20=20= =20=20PCE=20to=20a=20PCC=20is=20used=20to=20provide=20such=20= data.=20=20=20=20PCE=20to=20a=20PCC=20= is=20used=20to=20provide=20such=20data.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=203.1.=20=20Path=20Computation=20Monitoring=20Request=20= message=20(PCMonReq)=203.1.=20=20= Path=20Computation=20Monitoring=20Request=20message=20(PCMonReq)=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20The=20Message-Type=20= field=20of=20the=20PCEP=20common=20header=20for=20the=20= PCMonReq=20=20=20=20The=20= Message-Type=20field=20of=20the=20PCEP=20common=20header=20for=20the=20= PCMonReq=0A=20=20=20= =20=20=20=20=20=20message=20is=20set=20to=208=20(To=20be=20= confirmed=20by=20IANA).=20=20=20=20= message=20is=20set=20to=208=20(To=20be=20confirmed=20by=20IANA).=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20There=20is=20one=20= mandatory=20object=20that=20MUST=20be=20included=20within=20a=20= PCMonReq=20=20=20=20There=20is=20one=20= mandatory=20object=20that=20MUST=20be=20included=20within=20a=20= PCMonReq=0A=20=20=20= =20=20=20=0A=20=20=20=20=20=20= =20= =20=20message:=20the=20Monitoring=20= object=20(see=20section=20Section=204.1).=20=20If=20the=20= =20=20=20message:=20the=20MONITORING=20object=20(see=20section=20Section=20= 4.1).=20=20If=20the= =0A=20=20=20=20=20=20=20=20=20Monitoring=20= object=20is=20missing,=20the=20receiving=20PCE=20MUST=20send=20a=20= PCErr=20=20=20=20MONITORING=20object=20is=20missing,=20the=20= receiving=20PCE=20MUST=20send=20a=20PCErr=0A=20=20=20=20=20=20=20=20=20message=20with=20= Error-type=3D6=20(Mandatory=20Object=20missing)=20and=20Error-=20= =20=20=20message=20with=20Error-type=3D6=20= (Mandatory=20Object=20missing)=20and=20Error-=0A=20=20=20=20=20=20=20=20=20value=3D4=20= (MONITORING=20Object=20missing).=20=20Other=20objects=20are=20= optional.=20=20=20=20value=3D4=20= (MONITORING=20Object=20missing).=20=20Other=20objects=20are=20= optional.=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= =20= =20=20The=20format=20of=20a=20PCMonReq=20= message=20is=20as=20follows:=20=20=20=20Format=20of=20a=20= PCMonReq=20message=20(out=20of=20band=20request):=0A=20=20=20=20=20=20=20=20=20= <PCMonReq=20Message>::=3D=20<Common=20Header>=20=20=20=20<PCMonReq=20Message>::=3D=20<Common=20= Header>=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20<MONITORING>=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= <MONITORING>=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20[<pce-list>]=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= [<pce-list>]=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20[<svec-list>]=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= [<svec-list>]=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20[<request-list>]=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= [<request-list>]= =0A=20=20=20=20=20=20=20=20=20where:=20=20=20= =20where:=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= <svec-list>::=3D<SVEC>=20=20=20= =20<svec-list>::=3D<SVEC>=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20[<OF>]=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20[<OF>]=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20[<svec-list>]=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= [<svec-list>]=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20skipping=20to=20= change=20at=20page=206,=20line=2032=20= skipping=20to=20change=20= at=20page=208,=20line=204=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= [<BANDWIDTH>]=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20[<BANDWIDTH>]=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20[<metric-list>]=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[<metric-list>]=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20[<RRO>]=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= [<RRO>]=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= [<IRO>]=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20[<IRO>]=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20[<LOAD-BALANCING>]=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= [<LOAD-BALANCING>]=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20[<XRO>]=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20[<XRO>]=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20= <metric-list>::=3D<METRIC>[<metric-list>]=20=20=20=20= <metric-list>::=3D<METRIC>[<metric-list>]=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20= <pce-list>::=3D<PCE-ID>[<pce-list>]=20=20=20=20= <pce-list>::=3D<PCE-ID>[<pce-list>]=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20Format=20= of=20a=20PCReq=20message=20with=20monitoring=20data=20requested=20(in=20= band=0A=20=20= =20=20=20=20=20=20=20=20request):=0A=20=20=20=20=20=20=20=20=20=20<PCReq=20= Message>::=3D=20<Common=20Header>=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20<MONITORING>=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= [<pce-list>]=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20[<svec-list>]=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= <request-list>=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20= where:=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20= <svec-list>::=3D<SVEC>[<svec-list>]=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20= <request-list>::=3D<request>[<request-list>]=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20= =20=20=20=20=20=20= <request>::=3D=20<RP>=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20<END-POINTS>=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20[<LSPA>]=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20[<BANDWIDTH>]=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20[<metric-list>]=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20= [<RRO>[<BANDWIDTH>]]=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20[<IRO>]=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20[<LOAD-BALANCING>]=0A=20=20=20=20=20=20=20= =20=20=20= where:=0A=20= =20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20= <metric-list>::=3D<METRIC>[<metric-list>]=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20= =20=20=20= <pce-list>::=3D<PCE-ID>[<pce-list>]=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= The=20SVEC,=20RP,=20END-POINTS,=20LSPA,=20BANDWIDTH,=20METRIC,=20ERO,=20IRO=20and=20LOAD-=20=20=20=20The=20SVEC,=20RP,=20END-POINTS,=20LSPA,=20= BANDWIDTH,=20METRIC,=20RRO,=20IRO=20and=20= LOAD-=0A=20=20=20=20= =20=20=20=20=20BALANCING=20objects=20are=20defined=20in=20= [I-D.ietf-pce-pcep].=20=20The=20XRO=20object=20=20=20=20BALANCING=20objects=20are=20defined=20in=20= [I-D.ietf-pce-pcep].=20=20The=20XRO=20object=0A=20=20=20=20=20=20=20=20=20is=20defined=20in=20= [I-D.ietf-pce-pcep-xro]=20and=20the=20OF=20object=20is=20defined=20= in=20=20=20=20is=20defined=20in=20= [I-D.ietf-pce-pcep-xro]=20and=20the=20OF=20object=20is=20defined=20= in=0A=20=20=20=20=20= =20=20= =20=20[I-D.ietf-pce-of].=20=20=20=20= [I-D.ietf-pce-of].=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20The=20= PCMonReq=20message=20is=20used=20to=20gather=20various=20PCE=20state=20= metrics=20=20=20=20The=20PCMonReq=20= message=20is=20used=20to=20gather=20various=20PCE=20state=20= metrics=0A=20=20=20= =20=20=20=20=20=20along=20a=20path=20computation=20chain.=20=20The=20= path=20computation=20chain=20may=20be=20=20=20=20along=20a=20path=20computation=20chain.=20=20= The=20path=20computation=20chain=20may=20be=0A=20=20=20=20=20=20=20=20=20determined=20by=20the=20= PCC=20(in=20the=20form=20of=20a=20series=20of=20a=20series=20of=20= PCE-ID=20=20=20=20determined=20by=20= the=20PCC=20(in=20the=20form=20of=20a=20series=20of=20a=20series=20of=20= PCE-ID=0A=20=20=20= =20=20=20=20=20=20objects=20defined=20in=20Section=204.2.)=20or=20= may=20alternatively=20be=20determined=20=20=20=20objects=20defined=20in=20Section=204.2.)=20or=20= may=20alternatively=20be=20determined=0A=20=20=20=20=20=20=20=20=20by=20the=20path=20= computation=20procedure.=20=20For=20example,=20if=20the=20BRPC=20= =20=20=20by=20the=20path=20computation=20= procedure.=20=20For=20example,=20if=20the=20BRPC=0A=20=20=20=20=20=20=20=20=20= procedure=20([I-D.ietf-pce-brpc])=20is=20used=20to=20compute=20an=20= inter-domain=20TE=20=20=20=20= procedure=20([I-D.ietf-pce-brpc])=20is=20used=20to=20compute=20an=20= inter-domain=20TE=0A= =20=20=20=20=20=20=20=20=20LSP,=20the=20PCE=20chain=20may=20be=20determined=20= dynamically.=20=20In=20that=20case,=20the=20=20=20=20LSP,=20the=20PCE=20chain=20may=20be=20= determined=20dynamically.=20=20In=20that=20case,=20the=0A=20=20=20=20=20=20=20=20=20PCC=20= sends=20a=20PCMonReq=20message=20that=20contains=20the=20PCEP=20objects=20= that=20=20=20=20PCC=20sends=20a=20= PCMonReq=20message=20that=20contains=20the=20PCEP=20objects=20= that=0A=20=20=20=20= =20=20=0A=20=20=20=20=20=20= =20= =20=20charaterize=20the=20TE=20LSP=20attributes=20along=20with=20the=20= monitoring=20objects=20=20=20=20charaterize=20the=20TE=20LSP=20attributes=20= along=20with=20the=20MONITORING=20= object=0A=20= =20=20=20=20=20=20=20=20(see=20Section=204.1)=20that=20list=20the=20set=20of=20metric(s)=20of=20interest.=20=20=20=20(see=20Section=204.1)=20that=20lists=20the=20set=20of=20metrics=20of=20interest.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20Several=20PCE=20state=20= metrics=20may=20be=20requested=20that=20are=20specified=20by=20= a=20=20=20=20Several=20PCE=20state=20= metrics=20may=20be=20requested=20that=20are=20specified=20by=20a=0A=20=20=20=20=20=20=20=20=20set=20= of=20objects=20defined=20in=20Section=204.=20=20Note=20that=20this=20set=20= of=20objects=20=20=20=20set=20of=20= objects=20defined=20in=20Section=204.=20=20Note=20that=20this=20set=20of=20= objects=0A=20=20=20= =20=20=20=20=20=20may=20be=20extended=20in=20the=20= future.=20=20=20=20may=20be=20= extended=20in=20the=20future.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20For=20the=20sake=20of=20= illustraion,=20consider=20the=20three=20following=20= examples:=20=20=20=20As=20pointed=20out=20in=20[I-D.ietf-pce-pcep]=20several=20= situations=20can=20arise:=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20Example=201:=20PCC1=20= requests=20to=20check=20the=20path=20computation=20chain=20= that=20=20=20=20o=20=20Bundle=20of=20a=20set=20of=20independent=20and=20non-synchronized=20= path=0A=20=20= =20=20=20=20=20=20=20would=20be=20used=20= should=20it=20request=20a=20path=20computation=20for=20a=20specific=20= TE=20= =20=20=20=20=20=20computation=20requests,=0A=20=20=20=20=20=20=20=20=20LSP=20named=20T1.=20=20A=20PCMonReq=20message=20= is=20sent=20that=20contains=20a=20MONITORING=20=0A= =20=20=20=20=20=20=20=20=20object=20= specifying=20a=20path=20computation=20= check,=20along=20with=20the=20=0A= =20=20=20=20=20=20=20=20=20appropriate=20= set=20of=20objects=20(e.g.=20=20RP,=20= END-POINTS,=20...)=20that=20would=20be=20=0A= =20=20=20=20=20=20=20=20=20included=20in=20a=20= PCReq=20message=20for=20T1.=20=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= =20= =20=20Example=202:=20PCC1=20requests=20a=20path=20= computation=20for=20a=20TE=20LSP=20= and=20also=20=20=20=20o=20=20Bundle=20= of=20a=20set=20of=20independent=20= and=20synchronized=20path=20= computation=0A=20=20= =20=20=20=20=20=20=20request=20to=20gather=20= the=20processing=20time=20along=20the=20path=20= computation=20=20=20=20=20=20=20= requests=20(SVEC=20object=20defined=20= below=20required),=0A=20=20=20=20=20=20=20=20=20= chain=20selected=20for=20the=20computation=20of=20= T1.=20=20A=20PCReq=20message=20is=20sent=20=0A= =20=20=20=20=20=20=20=20=20that=20also=20= contains=20a=20MONITORING=20object=20that=20specifies=20the=20= performance=20=0A=20=20=20=20=20=20=20=20=20metric=20of=20interest.=20=20The=20PCRep=20= message=20also=20carries=20a=20PROC-TIME=20=0A= =20=20=20=20=20=20=20=20=20object=20defined=20in=20= section=20Section=204.1=20that=20reports=20the=20= computed=20=0A=20=20=20=20=20=20=20=20=20metrics.=20=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= =20= =20=20Example=203:=20PCC2=20requests=20= to=20gather=20performance=20metrics=20along=20the=20=20=20=20o=20=20Bundle=20of=20= a=20set=20of=20dependent=20and=20synchronized=20path=20= computation=0A= =20=20=20=20=20=20=20=20=20specific=20path=20computation=20chain=20= <pce1,=20pce2,=20pce3,=20pce7>.=20=20A=20PCMonreq=20=20=20=20=20=20=20requests=20= (SVEC=20object=20defined=20below=20required).=0A=20=20=20=20=20=20=20=20=20= message=20is=20sent=20to=20PCE1=20that=20contains=20a=20sequence=20of=20= PCE-ID=20objects=20=0A=20=20=20=20=20=20=20=20=20that=20identify=20= PCE1,=20PCE2,=20PCE3=20and=20PCE7=20respectively.=20=20=20=20In=20the=20case=20of=20= a=20bundle=20of=20a=20set=20of=20request,=20the=20MONITORING=20= object=0A=20= =20=20=20=20=20=20=20=20=20SHOULD=20only=20be=20present=20in=20the=20= first=20PCReq=20or=20PCMonReq=20message=20and=20the=0A=20=20=20=20=20=20=20= =20=20=20monitoring=20= request=20applies=20to=20all=20the=20requests=20of=20the=20bundle,=20= even=20in=0A= =20=20=20=20=20=20=20=20=20=20the=20case=20of=20dependent=20and/or=20= synchronized=20requests=20sent=20using=20more=0A=20=20=20=20=20=20=20= =20=20=20than=20one=20= PCReq=20or=20PCMonReq=20message.=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20Examples=20= of=20requests.=20=20For=20the=20sake=20of=20illustration,=20consider=20= the=0A=20=20= =20=20=20=20=20=20=20=20three=20following=20examples:=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20Example=201=20(out=20= of=20band=20request):=20PCC1=20requests=20to=20check=20the=20= path=0A=20=20= =20=20=20=20=20=20=20=20computation=20chain=20that=20would=20be=20used=20= should=20it=20request=20a=20path=0A=20=20=20=20=20=20=20=20=20=20computation=20for=20a=20= specific=20TE=20LSP=20named=20T1.=20=20A=20PCMonReq=20message=20= is=0A=20=20= =20=20=20=20=20=20=20=20sent=20that=20contains=20a=20MONITORING=20= object=20specifying=20a=20path=20computation=0A=20=20=20=20=20=20=20= =20=20=20check,=20= along=20with=20the=20appropriate=20set=20of=20objects=20(e.g.=20=20RP,=20= END-=0A=20=20= =20=20=20=20=20=20=20=20POINTS,=20...)=20that=20would=20be=20included=20= in=20a=20PCReq=20message=20for=20T1.=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20Example=20= 2=20(in=20band=20request):=20PCC1=20requests=20a=20path=20computation=20= for=20a=0A=20= =20=20=20=20=20=20=20=20=20TE=20LSP=20and=20also=20request=20to=20gather=20= the=20processing=20time=20along=20the=20path=0A=20=20=20=20=20=20=20= =20=20=20= computation=20chain=20selected=20for=20the=20computation=20of=20T1.=20=20= A=20PCReq=0A= =20=20=20=20=20=20=20=20=20=20message=20is=20sent=20that=20also=20contains=20= a=20MONITORING=20object=20that=20specifies=0A=20=20=20=20=20=20=20= =20=20=20the=20= performance=20metrics=20of=20interest.=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20Example=20= 3=20(out=20of=20band=20request):=20PCC2=20requests=20to=20gather=20= performance=0A=20=20= =20=20=20=20=20=20=20=20= metrics=20along=20the=20specific=20path=20computation=20chain=20= <pce1,=20pce2,=20pce3,=0A=20=20=20=20=20=20=20=20=20=20pce7>.=20=20A=20PCMonreq=20message=20is=20sent=20= to=20PCE1=20that=20contains=20a=20MONITORING=0A=20=20=20=20=20=20=20=20=20=20object=20and=20= a=20sequence=20of=20PCE-ID=20objects=20that=20identify=20PCE1,=20= PCE2,=0A=20=20=20=20= =20=20=20=20=20=20PCE3=20= and=20PCE7=20respectively.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=0A=20= =20=20=20=20=20=20=20=20=20In=20all=20of=20the=20examples=20above,=20a=20PCRep=20= message=20(in-band=20request)=20or=0A=20=20=20=20=20=20=20=20=20=20PCMonReq=20message=20= (out=20of=20band=20request)=20is=20sent=20in=20response=20to=20= the=0A=20=20= =20=20=20=20=20=20=20=20request=20that=20reports=20the=20computed=20= metrics.=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=203.2.=20=20= Path=20Monitoring=20Reply=20message=20(PCMonRep)=203.2.=20=20Path=20Monitoring=20Reply=20message=20= (PCMonRep)=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20The=20= PCMonRep=20message=20is=20used=20to=20provide=20PCE=20state=20metrics=20= back=20to=20the=20=20=20=20The=20= PCMonRep=20message=20is=20used=20to=20provide=20PCE=20state=20metrics=20= back=20to=20the=0A= =20=20=20=20=20=20=20=20=20requester=20for=20"out=20of=20band"=20monitoring=20= requests.=20=20The=20Message-Type=20=20= =20=20requester=20for=20"out=20of=20band"=20monitoring=20requests.=20=20= The=20Message-Type=0A= =20=20=20=20=20=20=20=20=20field=20of=20the=20PCEP=20common=20header=20for=20= the=20PCMonRep=20message=20is=20set=20to=209=20=20=20=20field=20of=20the=20PCEP=20common=20header=20for=20= the=20PCMonRep=20message=20is=20set=20to=209=0A=20=20=20=20=20=20=20=20=20(To=20be=20confirmed=20= by=20IANA).=20=20=20=20(To=20be=20= confirmed=20by=20IANA).=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20There=20is=20one=20mandatory=20object=20that=20= MUST=20be=20included=20within=20a=20PCMonRep=20=20=20=20There=20is=20one=20mandatory=20object=20that=20= MUST=20be=20included=20within=20a=20PCMonRep=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= message:=20the=20Monitoring=20object=20(see=20= Section=204.1).=20=20If=20the=20Monitoring=20=20=20=20message:=20the=20MONITORING=20object=20(see=20Section=204.1).=20=20If=20= the=20MONITORING=0A=20=20=20=20=20=20=20=20=20object=20is=20missing,=20= the=20receiving=20PCE=20MUST=20send=20a=20PCErr=20message=20= with=20=20=20=20object=20is=20= missing,=20the=20receiving=20PCE=20MUST=20send=20a=20PCErr=20message=20= with=0A=20=20=20=20= =20=20=20=20=20Error-type=3D6=20(Mandatory=20Object=20missing)=20= and=20Error-value=3D4=20(MONITORING=20= =20=20=20Error-type=3D6=20(Mandatory=20Object=20missing)=20and=20= Error-value=3D4=20(MONITORING=0A=20=20=20=20=20=20=20=20=20Object=20= missing).=20=20=20=20Object=20= missing).=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= Other=20objects=20are=20optional.=20=20= =20=20Other=20objects=20are=20optional.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20The=20format=20of=20a=20= PCReq=20message=20is=20as=20follows:=20=20=20=20Format=20of=20a=20= PCMonRep=20(out=20of=20band=20request):=0A=20=20=20=20=20=20=20=20=20<PCMonRep=20= Message>::=3D=20<Common=20Header>=20=20=20=20<PCMonRep=20Message>::=3D=20<Common=20= Header>=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20<MONITORING>=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= <MONITORING>=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20[<RP>]=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= [<RP>]=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20[<metric-pce-list>]=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20[<metric-pce-list>]=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20where:=20=20=20= =20where:=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= <metric-pce-list>::=3D<metric-pce>[<metric-pce-list>]=20= =20=20=20= <metric-pce-list>::=3D<metric-pce>[<metric-pce-list>]=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= <metric-pce>::=3D[<PCE-ID>]= =20=20=20=20<metric-pce>::=3D<PCE-ID>=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20[<PROC-TIME>]=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20[<CONGESTION>]=0A=20=20=20=20=20=20=20= =20=20=20Format=20= of=20a=20PCRep=20message=20with=20monitoring=20data=20(in=20= band):=0A=20= =20=20=20=20=20=20=20=20=20<PCRep=20Message>=20::=3D=20<Common=20= Header>=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20<response-list>=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20= where:=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20= <response-list>::=3D<response>[<response-list>]=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20= =20=20=20=20=20=20= <response>::=3D<RP>=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20<MONITORING>=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20[<NO-PATH>]=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20[<attribute-list>]=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20[<path-list>]=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20[<metric-pce-list>]=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20= =20=20=20=20=20=20= <path-list>::=3D<path>[<path-list>]=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20= =20=20=20=20=20=20= <path>::=3D=20<ERO><attribute-list>=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20= =20=20=20= where:=0A=20= =20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20= <attribute-list>::=3D[<LSPA>]=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20[<BANDWIDTH>]=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= [<metric-list>]=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20[<IRO>]=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20= =20=20=20=20= <metric-list>::=3D<METRIC>[<metric-list>]=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20= =20=20=20=20= <metric-pce-list>::=3D<metric-pce>[<metric-pce-list>]= =0A=20=20=20=20=20=20= =20=0A=20=20=20=20=20=20=20=20=20=20=20= <metric-pce>::=3D<PCE-ID>=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20[<PROC-TIME>]=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= [<PROC-TIME>]=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= [<CONGESTION>]=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20[<CONGESTION>]=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20The=20RP=20= object=20is=20defined=20in=20[I-D.ietf-pce-pcep].=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=0A=20=20=20=20=20=204.=20=20Path=20Computation=20= Monitoring=20Objects=204.=20=20Path=20= Computation=20Monitoring=20Objects=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20The=20PCEP=20objects=20defined=20in=20the=20= document=20are=20compliant=20with=20the=20PCEP=20=20=20=20The=20PCEP=20objects=20defined=20in=20the=20= document=20are=20compliant=20with=20the=20PCEP=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= object=20format=20defined=20in=20[I-D.ietf-pce-pcep],=20with=20the=20P=20flag=20= and=20the=20=20=20=20object=20= format=20defined=20in=20[I-D.ietf-pce-pcep].=20=20= The=20P=20flag=20and=20the=20I=0A=20=20=20=20=20=20=20=20=20I=20flag=20cleared=20since=20these=20flags=20are=20= exclusively=20related=20to=20path=20=20= =20=20flag=20of=20the=20PCEP=20objects=20= defined=20in=20this=20document=20SHOULD=20always=20be=0A=20=20=20=20=20=20=20=20=20= computation=20requests.=20=20=20=20set=20to=200=20on=20transmission=20and=20MUST=20= be=20ignored=20on=20receipt=20since=20these=0A=20=20=20=20=20=20=20= =20=20=20flags=20are=20exclusively=20related=20= to=20path=20computation=20requests.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20Several=20objects=20are=20defined=20in=20this=20= section=20that=20can=20be=20carried=20= =20=20=20Several=20objects=20are=20defined=20in=20this=20section=20that=20= can=20be=20carried=0A= =20=20=20=20=20=20=20=20=20within=20the=20PCEP=20PCReq=20or=20PCRep=20= messages=20defined=20in=20=20=20=20= within=20the=20PCEP=20PCReq=20or=20PCRep=20messages=20defined=20= in=0A=20=20=20=20=20= =20=0A=20=20=20=20=20=20= =20= =20=20[I-D.ietf-pce-pcep]=20in=20case=20of=20"in=20band"=20monitoring=20= requests.=20=20In=20=20=20=20[I-D.ietf-pce-pcep]=20in=20case=20of=20"in=20= band"=20monitoring=20requests=20(the=20= PCC=0A=20=20=20=20= =20=20=20=20=20case=20of=20"out=20of=20= band"=20monitoring=20requests,=20the=20objects=20defined=20= in=20=20=20=20requests=20the=20= computation=20of=20the=20TE=20LSP=20in=20addition=20to=20gathering=20= PCE=0A=20=20=20=20= =20=20=20=20=20this=20section=20are=20= carried=20within=20PCMonReq=20and=20PCMonRep=20messages.=20= =20=20=20state=20metrics).=20=20In=20case=20of=20"out=20of=20= band"=20monitoring=20requests,=20= the=0A=20=20= =20=20=20=20=20=20=20Conversely,=20if=20= the=20PCC=20requests=20the=20computation=20of=20the=20TE=20LSP=20= in=20=20=20=20objects=20defined=20in=20this=20section=20are=20carried=20= within=20PCMonReq=20and=0A=20=20=20=20=20=20=20=20=20= addition=20to=20gathering=20PCE=20state=20metrics= =20(i.e.=20=20"In=20band"=20requests),=20= =20=20=20PCMonRep=20messages.=0A=20=20=20=20=20=20=20=20=20these=20objects=20are=20carried=20= within=20PCReq=20and=20PCRep=20messages.=20=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=204.1.=20=20= MONITORING=20Object=204.1.=20=20= MONITORING=20Object= =0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20The=20= MONITORING=20object=20MUST=20be=20present=20within=20PCMonReq=20and=20= PCMonRep=20=20=20=20The=20MONITORING=20= object=20MUST=20be=20present=20within=20PCMonReq=20and=20= PCMonRep=0A=20=20=20= =20=20=20=20=20=20messages=20("out=20of=20band"=20monitoring=20= requests)=20and=20MAY=20be=20carried=20=20=20=20messages=20("out=20of=20band"=20monitoring=20= requests)=20and=20MAY=20be=20carried=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= within=20PCERep=20and=20PCReq=20messages=20= ("in=20band"=20monitoring=20requests).=20=20=20=20within=20PCRep=20and=20PCReq=20messages=20("in=20= band"=20monitoring=20requests).=0A=20=20=20=20=20=20=20=20=20There=20SHOULD=20NOT=20= be=20more=20than=20one=20instance=20of=20the=20MONITORING=20= object:=20=20=20=20There=20SHOULD=20= NOT=20be=20more=20than=20one=20instance=20of=20the=20MONITORING=20= object:=0A=20=20=20= =20=20=20=20=20=20if=20more=20than=20one=20instance=20of=20the=20= MONITORING=20object=20is=20present,=20the=20=20=20=20if=20more=20than=20one=20instance=20of=20the=20= MONITORING=20object=20is=20present,=20the=0A=20=20=20=20=20=20=20=20=20recipient=20MUST=20= process=20the=20first=20instance=20and=20MUST=20ignore=20other=20= =20=20=20recipient=20MUST=20process=20the=20= first=20instance=20and=20MUST=20ignore=20other=0A=20=20=20=20=20=20=20=20=20instances.=20= =20=20=20instances.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20The=20MONITORING=20object=20is=20used=20to=20= specify=20the=20set=20of=20requested=20PCE=20=20=20=20The=20MONITORING=20object=20is=20used=20to=20= specify=20the=20set=20of=20requested=20PCE=0A=20=20=20=20=20=20=20=20=20state=20= metrics.=20=20=20=20state=20= metrics.=0A=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20=20=20=20The=20= MONITORING=20Object-Class=20is=20to=20be=20assigned=20by=20IANA=20= (recommended=20=20=20=20The=20= MONITORING=20Object-Class=20is=20to=20be=20assigned=20by=20IANA=20= (recommended=0A=20= =20=20=20=20=20=20=20=20value=3D19)=20= =20=20=20value=3D19)=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20= skipping=20= to=20change=20at=20page=209,=20line=2035=20= skipping=20to=20change=20= at=20page=2013,=20line=2012=0A=20= =20=20=20=20=20=20=20=20PCE-ID=20object=20in=20the=20corresponding=20= reply.=20=20The=20L=20bit=20MUST=20always=20be=20=20=20=20PCE-ID=20object=20in=20the=20corresponding=20= reply.=20=20The=20L=20bit=20MUST=20always=20be=0A=20=20=20=20=20=20=20=20=20ignored=20in=20a=20= PCMonRep=20or=20PCRep=20message.=20=20= =20=20ignored=20in=20a=20PCMonRep=20or=20PCRep=20message.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20G=20(General)=20-=201=20= bit:=20when=20set,=20this=20indicates=20that=20the=20monitoring=20= =20=20=20G=20(General)=20-=201=20bit:=20when=20= set,=20this=20indicates=20that=20the=20monitoring=0A=20=20=20=20=20=20=20=20=20= request=20is=20a=20general=20monitoring=20request.=20=20When=20the=20= requested=20=20=20=20request=20is=20= a=20general=20monitoring=20request.=20=20When=20the=20requested=0A=20=20=20=20=20=20=20=20=20= performance=20metric=20is=20specific,=20the=20G=20bit=20MUST=20be=20= cleared.=20=20The=20G=20bit=20=20=20=20= performance=20metric=20is=20specific,=20the=20G=20bit=20MUST=20be=20= cleared.=20=20The=20G=20bit=0A=20=20=20=20=20=20=20=20=20MUST=20always=20be=20= ignored=20in=20a=20PCMonRep=20or=20PCRep=20message.=20=20=20=20MUST=20always=20be=20ignored=20in=20a=20= PCMonRep=20or=20PCRep=20message.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20P=20(Processing=20Time)=20-=201=20bit:=20the=20P=20= bit=20of=20the=20MONITORING=20object=20=20=20=20P=20(Processing=20Time)=20-=201=20bit:=20the=20= P=20bit=20of=20the=20MONITORING=20object=0A=20=20=20=20=20=20=20=20=20carried=20in=20a=20= PCMonReq=20or=20a=20PCReq=20message=20is=20set=20to=20indicate=20that=20= the=20=20=20=20carried=20in=20a=20= PCMonReq=20or=20a=20PCReq=20message=20is=20set=20to=20indicate=20that=20= the=0A=20=20=20=20= =20=20=0A=20=20=20=20=20=20= =20= =20=20processing=20times=20is=20a=20metric=20of=20interest,=20in=20which=20case=20a=20= PROC-TIME=20=20=20=20processing=20= times=20is=20a=20metric=20of=20interest.=20=20= If=20allowed=20by=20policy,=20a=0A=20=20=20=20=20=20=20=20=20object=20MUST=20be=20= inserted=20in=20the=20corresponding=20PCMonRep=20or=20PCRep=20= =20=20=20PROC-TIME=20object=20MUST=20be=20= inserted=20in=20the=20corresponding=20PCMonRep=20or=0A=20=20=20=20=20=20=20=20=20= message.=20=20The=20P=20bit=20MUST=20always=20be=20ignored=20in=20a=20= PCMonRep=20or=20PCRep=20=20=20=20= PCRep=20message.=20=20The=20P=20bit=20MUST=20always=20be=20ignored=20in=20= a=20PCMonRep=20or=0A= =20=20=20=20=20=20=20=20=20message.=20= =20=20=20PCRep=20message.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20C=20(Congestion)=20-=201=20bit:=20The=20C=20bit=20= of=20the=20MONITORING=20object=20carried=20in=20=20=20=20C=20(Congestion)=20-=201=20bit:=20The=20C=20bit=20= of=20the=20MONITORING=20object=20carried=20in=0A=20=20=20=20=20=20=20=20=20a=20PCMonReq=20or=20a=20= PCReq=20message=20is=20set=20to=20indicate=20that=20the=20= congestion=20=20=20=20a=20PCMonReq=20= or=20a=20PCReq=20message=20is=20set=20to=20indicate=20that=20the=20= congestion=0A=20=20= =20=20=20=20=20=20=20status=20is=20a=20metric=20of=20interest,=20in=20= which=20case=20a=20CONGESTION=20object=20=20=20=20status=20is=20a=20metric=20of=20interest,=20in=20= which=20case=20a=20CONGESTION=20object=0A=20=20=20=20=20=20=20=20=20MUST=20be=20inserted=20= in=20the=20corresponding=20PCMonRep=20or=20PCRep=20message.=20=20= The=20=20=20=20MUST=20be=20inserted=20= in=20the=20corresponding=20PCMonRep=20or=20PCRep=20message.=20=20= The=0A=20=20=20=20= =20=20=20=20=20C=20bit=20MUST=20always=20be=20ignored=20in=20a=20= PCMonRep=20or=20PCRep=20message.=20=20= =20=20C=20bit=20MUST=20always=20be=20ignored=20in=20a=20PCMonRep=20or=20= PCRep=20message.=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20I=20= (Incomplete)=20-=201=20bit:=20If=20a=20PCE=20supports=20a=20received=20= PCMonReq=20message=20=20=20=20I=20= (Incomplete)=20-=201=20bit:=20If=20a=20PCE=20supports=20a=20received=20= PCMonReq=20message=0A= =20=20=20=20=20=20=20=20=20and=20that=20message=20does=20not=20trigger=20= any=20policy=20violation,=20but=20the=20PCE=20=20=20=20and=20that=20message=20does=20not=20trigger=20= any=20policy=20violation,=20but=20the=20PCE=0A=20=20=20=20=20=20=20=20=20cannot=20provide=20any=20= of=20the=20set=20of=20requested=20performance=20metrics=20for=20= =20=20=20cannot=20provide=20any=20of=20the=20= set=20of=20requested=20performance=20metrics=20for=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20= skipping=20= to=20change=20at=20page=2010,=20line=2026=20= skipping=20to=20change=20= at=20page=2014,=20line=205=0A=20=20= =20=20=20=20=20=20=20PCEP-ID=20of=20the=20replying=20PCE.=20=20A=20= PCEP=20implementation=20SHOULD=20checkpoint=20=20=20=20PCEP-ID=20of=20the=20replying=20PCE.=20=20A=20= PCEP=20implementation=20SHOULD=20checkpoint=0A=20=20=20=20=20=20=20=20=20the=20= Monitoring-id-number=20of=20pending=20monitoring=20requests=20in=20case=20= of=20=20=20=20the=20= Monitoring-id-number=20of=20pending=20monitoring=20requests=20in=20case=20= of=0A=20=20=20=20=20= =20=20= =20=20restart=20thus=20avoiding=20the=20re-use=20of=20a=20= Monitoring-id-number=20of=20an=20in-=20=20=20=20restart=20thus=20avoiding=20the=20re-use=20of=20= a=20Monitoring-id-number=20of=20an=20in-=0A=20=20=20=20=20=20=20=20=20process=20monitoring=20= request.=20=20=20=20process=20= monitoring=20request.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20Unassigned=20bits=20are=20considered=20as=20= reserved=20and=20MUST=20be=20set=20to=20zero=20on=20=20=20=20Unassigned=20bits=20are=20considered=20as=20= reserved=20and=20MUST=20be=20set=20to=20zero=20on=0A=20=20=20=20=20=20=20=20=20= transmission=20and=20ignored=20on=20reception.=20=20=20=20transmission=20and=20ignored=20on=20= reception.=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20No=20= optional=20TLVs=20are=20currently=20defined.=20=20=20=20No=20optional=20TLVs=20are=20currently=20= defined.=0A=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= 4.2.=20=20PCEP-ID=20= Object=204.2.=20=20PCE-ID=20= Object=0A=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= =20= =20=20The=20PCEP-ID=20Object=20is=20used=20= to=20specify=20a=20PCE's=20IP=20address.=20=20=20=20The=20PCE-ID=20Object=20is=20used=20to=20= specify=20a=20PCE's=20IP=20address.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20A=20set=20of=20PCEP-ID=20objects=20may=20be=20inserted=20within=20= a=20PCReq=20or=20a=20PCMonReq=20=20=20= =20A=20set=20of=20PCE-ID=20objects=20may=20be=20inserted=20within=20a=20= PCReq=20or=20a=20PCMonReq=0A=20=20=20=20=20=20=20=20=20message=20to=20specify=20= the=20PCE=20for=20which=20PCE=20state=20metrics=20are=20= requested=20=20=20=20message=20to=20= specify=20the=20PCE=20for=20which=20PCE=20state=20metrics=20are=20= requested=0A=20=20= =20=20=20=20=20=20=20and=20in=20a=20PCMonRep=20or=20a=20PCRep=20= message=20to=20record=20the=20IP=20address=20of=20the=20= =20=20=20and=20in=20a=20PCMonRep=20or=20a=20= PCRep=20message=20to=20record=20the=20IP=20address=20of=20the=0A=20=20=20=20=20=20=20=20=20PCE=20= reporting=20PCE=20state=20metrics=20or=20that=20was=20involved=20in=20= the=20path=20=20=20=20PCE=20= reporting=20PCE=20state=20metrics=20or=20that=20was=20involved=20in=20= the=20path=0A=20=20= =20=20=20=20=20=20=20computation=20chain.=20=20=20=20computation=20chain.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20Two=20PCEP-ID=20= objects=20(for=20IPv4=20and=20IPv6)=20are=20defined.=20=20PCEP-ID=20Object-=20=20=20=20Two=20PCE-ID=20= objects=20(for=20IPv4=20and=20IPv6)=20are=20defined.=20=20PCE-ID=20Object-=0A=20=20=20=20=20=20=20=20=20Class=20is=20to=20be=20= assigned=20by=20IANA=20(recommended=20value=3D20)=20PCEP-ID=20=20= =20=20Class=20is=20to=20be=20assigned=20by=20IANA=20(recommended=20= value=3D20)=20PCE-ID=20Object-=0A=20=20=20=20=20=20=20=20=20Object-Type=20is=20to=20be=20assigned=20= by=20IANA=20(recommended=20value=3D1=20for=20IPv4=20=20=20=20Type=20is=20to=20= be=20assigned=20by=20IANA=20(recommended=20value=3D1=20for=20IPv4=20and=20= 2=0A=20=20=20=20=20= =20=20=20=20and=202=20for=20IPv6)=20=20=20=20for=20IPv6)=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20The=20format=20of=20the=20PCEP-ID=20Object=20is=20as=20follows:=20= =20=20=20The=20format=20of=20the=20PCE-ID=20= Object=20is=20as=20follows:=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20The=20format=20of=20the=20PCEP-ID=20object=20body=20for=20IPv4=20and=20IPv6=20= are=20as=20=20=20=20The=20format=20= of=20the=20PCE-ID=20object=20body=20for=20IPv4=20and=20IPv6=20are=20= as=0A=20=20=20=20=20= =20=20= =20=20follows:=20=20=20=20= follows:=0A=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20= 0=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=201=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=202=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=203=20=20=20= =20=200=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=201=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=202=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=203=0A=20=20=20=20=20=20=20=20=20=200=201=202=203=204=20= 5=206=207=208=209=200=201=202=203=204=205=206=207=208=209=200=201=202=20= 3=204=205=206=207=208=209=200=201=20=20= =20=20=200=201=202=203=204=205=206=207=208=209=200=201=202=203=204=205=20= 6=207=208=209=200=201=202=203=204=205=206=207=208=209=200=201=0A=20=20=20=20=20=20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= =20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=20=20=20=20=20=20=20=20=20|=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20IPv4=20Address=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20|=20=20=20=20|=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= IPv4=20Address=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20|=0A=20= =20=20=20=20=20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= =20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=200=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=201=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=202=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=203=20=20=20=20=200=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=201=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=202=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=203=0A=20= =20=20=20=20=20=20=20=20=200=201=202=203=204=205=206=207=208=209=200=201=20= 2=203=204=205=206=207=208=209=200=201=202=203=204=205=206=207=208=209=20= 0=201=20=20=20=20=200=201=202=203=20= 4=205=206=207=208=209=200=201=202=203=204=205=206=207=208=209=200=201=20= 2=203=204=205=206=207=208=209=200=201=0A=20=20=20=20=20=20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= =20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=20=20=20=20=20=20=20=20=20|=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20|=20=20=20=20|=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= |=0A=20=20=20=20=20= =20=20= =20=20|=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20IPv6=20Address=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20|=20=20=20= =20|=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20IPv6=20Address=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20|=0A=20=20=20=20=20=20=20=20=20|=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20|=20=20=20=20|=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20|=0A=20=20=20=20=20=20=20=20=20|=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20|=20=20=20=20|=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20|=0A=20=20=20=20=20=20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= =20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= =20= =20=20The=20PCEP-ID=20object=20body=20= has=20a=20fixed=20length=20of=204=20octets=20for=20IPv4=20and=20= =20=20=20The=20PCE-ID=20object=20body=20has=20a=20fixed=20= length=20of=204=20octets=20for=20IPv4=20and=2016=0A=20=20=20=20=20=20=20=20=20= 16=20octets=20for=20IPv6.=20=20=20=20= octets=20for=20IPv6.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20When=20a=20dynamic=20discovery=20mechanism=20is=20= used=20for=20PCE=20discovery,=20a=20PCE=20=20=20=20When=20a=20dynamic=20discovery=20mechanism=20is=20= used=20for=20PCE=20discovery,=20a=20PCE=0A=20=20=20=20=20=20=20=20=20advertises=20its=20PCE=20= address=20in=20the=20PCE-ADDRESS=20sub-TLV=20defined=20in=20= =20=20=20advertises=20its=20PCE=20address=20= in=20the=20PCE-ADDRESS=20sub-TLV=20defined=20in=0A=20=20=20=20=20=20=20=20=20= [RFC5088]=20and=20[RFC5089].=20=20A=20PCC=20MUST=20use=20this=20address=20= in=20PCReq=20and=20=20=20=20= [RFC5088]=20and=20[RFC5089].=20=20A=20PCC=20MUST=20use=20this=20address=20= in=20PCReq=20and=0A= =20=20=20=20=20=20=20=20=20PCMonReq=20messages=20and=20a=20PCE=20MUST=20= also=20use=20this=20address=20in=20PCRep=20and=20=20=20=20PCMonReq=20messages=20and=20a=20PCE=20MUST=20= also=20use=20this=20address=20in=20PCRep=20and=0A=20=20=20=20=20=20=20=20=20PCMonRep=20= messages.=20=20=20=20PCMonRep=20= messages.=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=204.3.=20=20= PROC-TIME=20Object=204.3.=20=20= PROC-TIME=20Object=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20If=20= allowed=20by=20policy,=20the=20PCE=20includes=20a=20PROC-TIME=20object=20= within=20a=20=20=20=20If=20allowed=20= by=20policy,=20the=20PCE=20includes=20a=20PROC-TIME=20object=20within=20= a=0A=20=20=20=20=20= =20=20= =0A=20=20= =20=20=20=20skipping=20to=20change=20at=20page=20= 11,=20line=2047=20skipping=20to=20change=20at=20page=20= 15,=20line=2016=0A=20=20=20=20=20=20=20=20=20= related=20metrics.=20=20=20=20= related=20metrics.=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=201)=20= Case=20of=20general=20monitoring=20requests=20=20=20=201)=20Case=20of=20general=20monitoring=20= requests=0A=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20=20=20=20A=20= PCC=20may=20request=20processing=20time=20metrics=20for=20general=20= monitoring=20=20=20=20A=20PCC=20may=20= request=20processing=20time=20metrics=20for=20general=20= monitoring=0A=20=20= =20=20=20=20=20=20=20requests=20(e.g.=20the=20PCC=20may=20want=20to=20= know=20the=20minimum,=20maximum=20and=20=20=20=20requests=20(e.g.=20the=20PCC=20may=20want=20to=20= know=20the=20minimum,=20maximum=20and=0A=20=20=20=20=20=20=20=20=20average=20processing=20= times=20on=20a=20particular=20PCE).=20=20In=20this=20case,=20= general=20=20=20=20average=20= processing=20times=20on=20a=20particular=20PCE).=20=20In=20this=20case,=20= general=0A=20=20=20= =20=20=20=20=20=20requests=20can=20only=20be=20made=20by=20using=20= PCMonReq/PCMonRep=20messages.=20=20The=20=20=20=20requests=20can=20only=20be=20made=20by=20using=20= PCMonReq/PCMonRep=20messages.=20=20The=0A=20=20=20=20=20=20=20=20=20= Current-processing-time=20field=20(as=20explained=20below)=20is=20= exclusively=20=20=20=20= Current-processing-time=20field=20(as=20explained=20below)=20is=20= exclusively=0A=20=20= =20=20=20=20=20=20=20used=20for=20specific=20monitoring=20requests=20= and=20MUST=20be=20cleared=20for=20general=20=20=20=20used=20for=20specific=20monitoring=20requests=20= and=20MUST=20be=20cleared=20for=20general=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= monitoring=20requests.=20=20The=20algorithm(s)=20used=20by=20a=20PCE=20to=20compute=20= the=20=20=20=20monitoring=20= requests.=20=20The=20algorithms=20used=20= by=20a=20PCE=20to=20compute=20the=0A=20=20=20=20=20=20=20=20=20Min,=20Average,=20Max=20= and=20Variance=20of=20the=20processing=20times=20are=20out=20of=20= the=20=20=20=20Min,=20Average,=20Max=20= and=20Variance=20of=20the=20processing=20times=20are=20out=20of=20= the=0A=20=20=20=20= =20=20=20=20=20scope=20of=20this=20document=20(A=20PCE=20may=20= decide=20to=20compute=20the=20minimum=20=20=20=20scope=20of=20this=20document=20(A=20PCE=20may=20= decide=20to=20compute=20the=20minimum=0A=20=20=20=20=20=20=20=20=20processing=20time=20= over=20a=20period=20of=20times,=20for=20the=20last=20N=20path=20= =20=20=20processing=20time=20over=20a=20= period=20of=20times,=20for=20the=20last=20N=20path=0A=20=20=20=20=20=20=20=20=20= computation=20requests,=20...).=20=20= =20=20computation=20requests,=20...).=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=202)=20Case=20of=20specific=20monitoring=20= requests=20=20=20=202)=20Case=20of=20= specific=20monitoring=20requests=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20In=20the=20case=20of=20a=20specific=20request,=20= the=20algorithm(s)=20used=20by=20a=20PCE=20= to=20=20=20=20In=20the=20case=20of=20= a=20specific=20request,=20the=20algorithms= =20used=20by=20a=20PCE=20to=0A=20=20=20=20=20=20=20=20=20compute=20the=20= Procesing-time=20metrics=20are=20out=20of=20the=20scope=20of=20= this=20=20=20=20compute=20the=20= Procesing-time=20metrics=20are=20out=20of=20the=20scope=20of=20= this=0A=20=20=20=20= =20=20=20=20=20document=20but=20a=20flag=20is=20specified=20= that=20is=20used=20to=20indicate=20to=20the=20=20=20=20document=20but=20a=20flag=20is=20specified=20= that=20is=20used=20to=20indicate=20to=20the=0A=20=20=20=20=20=20=20=20=20requester=20whether=20= the=20processing=20time=20value=20was=20estimated=20or=20= =20=20=20requester=20whether=20the=20= processing=20time=20value=20was=20estimated=20or=0A=20=20=20=20=20=20=20=20=20= computed.=20=20The=20PCE=20may=20either=20(1)=20estimate=20the=20= processing=20time=20=20=20=20= computed.=20=20The=20PCE=20may=20either=20(1)=20estimate=20the=20= processing=20time=0A= =20=20=20=20=20=20=20=20=20without=20performing=20an=20actual=20path=20= computation=20or=20(2)=20effectively=20=20=20=20without=20performing=20an=20actual=20path=20= computation=20or=20(2)=20effectively=0A=20=20=20=20=20=20=20=20=20perform=20the=20= computation=20to=20report=20the=20processing=20time.=20=20In=20the=20= former=20=20=20=20perform=20the=20= computation=20to=20report=20the=20processing=20time.=20=20In=20the=20= former=0A=20=20=20= =20=20=20=20=20=20case,=20the=20E=20bit=20of=20the=20PROC-TIME=20= object=20MUST=20be=20set.=20=20The=20G=20bit=20MUST=20=20=20=20case,=20the=20E=20bit=20of=20the=20PROC-TIME=20= object=20MUST=20be=20set.=20=20The=20G=20bit=20MUST=0A=20=20=20=20=20=20=20=20=20be=20= cleared=20and=20the=20Min-processing-time,=20Max-processing-time,=20= Average-=20=20=20=20be=20cleared=20= and=20the=20Min-processing-time,=20Max-processing-time,=20= Average-=0A=20=20=20= =20=20=20=20=20=20processing-time=20and=20Variance-processing-time=20= MUST=20be=20set=20to=20=20=20=20= processing-time=20and=20Variance-processing-time=20MUST=20be=20set=20= to=0A=20=20=20=20=20= =20=20= =20=200x00000000.=20=20=20=20= 0x00000000.=0A=20=20= =20=20=20=20= =20=0A=20= =20=20=20=20=20skipping=20to=20change=20at=20page=20= 12,=20line=2047=20skipping=20to=20change=20at=20page=20= 16,=20line=2021=0A=20=20=20=20=20=20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= =20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=20=20=20=20=20=20=20=20=20|=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Min-processing-time=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20|=20=20=20=20|=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Min-processing-time=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20|=0A=20=20=20= =20=20=20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= =20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=20=20=20=20=20=20=20=20=20|=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Max-processing-time=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20|=20=20=20=20|=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Max-processing-time=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20|=0A=20=20=20= =20=20=20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= =20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=20=20=20=20=20=20=20=20=20|=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Average-processing=20time=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20|=20=20=20=20|=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Average-processing=20= time=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=0A=20=20=20=20=20=20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= =20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=20=20=20=20=20=20=20=20=20|=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Variance-processing-time=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= |=20=20=20=20|=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Variance-processing-time=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20|=0A=20=20=20=20=20=20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= =20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= Flags:=2018=20bits=20-=20No=20Flags=20= are=20currently=20defined:=20=20= =20=20Flags:=2016=20bits=20-=20one=20flag=20= is=20currently=20defined:=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20E=20(Estimated)=20-=201=20bit:=20when=20set,=20= this=20indicates=20that=20the=20reported=20=20=20=20E=20(Estimated)=20-=201=20bit:=20when=20set,=20= this=20indicates=20that=20the=20reported=0A=20=20=20=20=20=20=20=20=20metric=20value=20is=20= based=20on=20estimated=20processing=20time=20as=20opposed=20to=20= =20=20=20metric=20value=20is=20based=20on=20= estimated=20processing=20time=20as=20opposed=20to=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= =20= =20=20actual=20computation(s).=20= =20=20=20actual=20computations.=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20Unassigned=20= bits=20are=20considered=20as=20reserved=20and=20MUST=20be=20set=20to=20= zero=20on=0A= =20=20=20=20=20=20=20=20=20=20transmission.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20Current-processing-time:=20This=20field=20= indicates=20in=20milliseconds=20the=20= =20=20=20Current-processing-time:=20This=20field=20indicates=20in=20= milliseconds=20the=0A= =20=20=20=20=20=20=20=20=20processing=20time=20for=20the=20path=20= computation=20of=20interest=20characterized=20in=20=20=20=20processing=20time=20for=20the=20path=20= computation=20of=20interest=20characterized=20in=0A=20=20=20=20=20=20=20=20=20the=20= corresponding=20PCMonReq=20message.=20= =20=20=20the=20corresponding=20PCMonReq=20message.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20Min-processing-time:=20= This=20field=20indicates=20in=20milliseconds=20the=20minimum=20= =20=20=20Min-processing-time:=20This=20field=20= indicates=20in=20milliseconds=20the=20minimum=0A=20=20=20=20=20=20=20=20=20processing=20= time.=20=20=20=20processing=20= time.=0A=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20=20=20=20= Max-processing-time:=20This=20field=20indicates=20in=20milliseconds=20= the=20maximum=20=20=20=20= Max-processing-time:=20This=20field=20indicates=20in=20milliseconds=20= the=20maximum=0A=20= =20=20=20=20=20=20=20=20processing=20time.=20=20=20=20processing=20time.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20Average-processing-time:=20This=20field=20= indicates=20in=20milliseconds=20the=20= =20=20=20Average-processing-time:=20This=20field=20indicates=20in=20= milliseconds=20the=0A= =20=20=20=20=20=20=20=20=20average=20processing=20time.=20=20=20=20average=20processing=20time.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20= Variance-processing-time:=20This=20field=20indicates=20in=20milliseconds=20= the=20=20=20=20= Variance-processing-time:=20This=20field=20indicates=20in=20milliseconds=20= the=0A=20=20=20=20= =20=20=20=20=20variance=20of=20the=20processing=20= times.=20=20=20=20variance=20of=20= the=20processing=20times.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20Unassigned=20bits=20= are=20considered=20as=20reserved=20and=20MUST=20be=20set=20to=20zero=20= on=20=0A=20=20=20=20=20=20=20=20=20transmission.=20=0A= =20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20More=20granularity=20= may=20be=20introduced=20in=20further=20revision=20of=20= this=20=0A=20=20=20=20=20=20=20=20=20document=20to=20get=20a=20monitoring=20metric=20= for=20a=20general=20request=20of=20a=20=0A= =20=20=20=20=20=20=20=20=20particular=20class=20= (e.g.=20all=20PCReq=20of=20priority=20X).=20=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=0A=20=20=20=20=20=204.4.=20=20= CONGESTION=20Object=204.4.=20=20= CONGESTION=20Object= =0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= =20= =20=20The=20CONGESTION=20object=20MUST=20be=20present=20within=20a=20= PCMonRep=20or=20a=20PCRep=20=20=20=20= The=20CONGESTION=20object=20is=20used=20to=20= report=20a=20PCE=20processing=20congestion=0A=20=20=20=20=20=20=20=20=20= message=20if=20the=20C=20bit=20of=20the=20MONITORING=20object=20carried=20= within=20the=20=20=20=20state.=20=20The=20CONGESTION=20object=20= MUST=20be=20present=20within=20a=20PCMonRep=20or=20a=0A=20=20=20=20=20=20=20=20=20= corresponding=20PCMonReq=20or=20PCReq=20message=20is=20set.=20=20The=20CONGESTION=20=20=20=20PCRep=20message=20if=20the=20C=20bit=20of=20= the=20MONITORING=20object=20carried=20within=0A=20=20=20=20=20=20=20=20= =20object=20is=20used=20to=20= report=20a=20PCE=20processing=20= congestion=20state.=20=20The=20=20=20=20the=20corresponding=20PCMonReq=20or=20PCReq=20= message=20is=20set=20and=20the=20PCE=20= is=0A=20=20=20=20=20= =20=20=20=20CONGESTION=20Object-Class=20is=20to=20be=20= assigned=20by=20IANA=20(recommended=20=20=20=20experiencing=20= a=20congested=20state.=20=20The=20= CONGESTION=20Object-Class=20is=20to=20be=0A=20=20=20=20=20=20=20=20=20value=3D22)=20The=20= CONGESTION=20Object-Type=20is=20to=20be=20assigned=20by=20IANA=20= =20=20=20assigned=20by=20IANA=20(recommended=20= value=3D22)=20The=20CONGESTION=20Object-Type=20is=0A=20=20=20=20=20=20=20=20=20= (recommended=20value=3D1)=20=20=20=20= to=20be=20assigned=20by=20IANA=20(recommended=20value=3D1)=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20The=20format=20of=20= the=20CONGESTION=20object=20body=20is=20as=20follows:=20= =20=20=20The=20format=20of=20the=20CONGESTION=20= object=20body=20is=20as=20follows:=0A=20=20=20=20=20=20=20=20=200=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=201=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=202=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =203=20=20=20=200=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=201=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=202=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=203=0A=20=20=20= =20=20=20=20=20=200=201=202=203=204=205=206=207=208=209=200=201=20= 2=203=204=205=206=207=208=209=200=201=202=203=204=205=206=207=208=209=20= 0=201=20=20=20=200=201=202=203=204=20= 5=206=207=208=209=200=201=202=203=204=205=206=207=208=209=200=201=202=20= 3=204=205=206=207=208=209=200=201=0A=20=20=20=20=20=20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= =20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= =20= =20=20|C|=20=20=20=20=20=20=20=20Reserved=20=20=20= =20=20=20=20=20=20=20=20=20=20|=20=20=20=20Congestion=20Duration=20=20= =20=20=20=20=20=20|=20=20=20=20= |=20=20=20Flags=20=20=20=20=20=20=20|=20=20=20= Reserved=20=20=20=20|=20=20=20=20=20=20Congestion=20Duration=20=20= =20=20=20=20|=0A=20= =20=20=20=20=20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= =20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= C=20(Congestion)=20-=201=20bit:=20when=20set,=20this=20indicates=20that=20= PCE=20is=20=20=20=20Flags:=208=20bits=20-=20No=20flag=20is=20currently=20defined:=0A=20=20=20=20=20=20=20=20=20congested,=20in=20which=20case=20the=20congestion=20= duration=20may=20be=20non=20nul.=20=0A= =20=20=20=20=20=20=20=20=20When=20cleared=20this=20= indicates=20that=20the=20PCE=20is=20not=20congested=20and=20= the=20=0A=20=20=20=20=20=20=20=20=20"Congestion=20Duration"=20field=20MUST=20be=20= set=20to=200x0000.=20=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= Congestion=20duration=20-=2016=20bits:=20This=20field=20indicates=20in=20= seconds=20the=20=20=20=20Congestion=20= duration=20-=2016=20bits:=20This=20field=20indicates=20in=20the=20amount=20of=0A=20=20=20=20=20=20=20=20=20estimated=20congestion=20duration.=20=20=20=20time=20in=20= seconds=20that=20the=20responding=20PCE=20= expects=20that=20it=20may=20continue=0A=20=20=20=20=20=20=20=20=20=20to=20be=20congested=20= from=20the=20time=20that=20the=20response=20message=20was=0A=20=20=20=20=20=20=20= =20=20=20generated.=20= =20The=20receiver=20MAY=20use=20this=20value=20to=20decide=20whether=20= or=20not=0A= =20=20=20=20=20=20=20=20=20=20so=20send=20further=20requests=20to=20the=20= same=20PCE.=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20It=20is=20worth=20= noting=20that=20a=20PCE=20along=20a=20PCE=20chain=20involved=20in=20= the=0A=20=20= =20=20=20=20=20=20=20=20monitoring=20request=20may=20decide=20to=20= learn=20from=20the=20congestion=0A=20=20=20=20=20=20=20=20=20=20information=20= received=20by=20one=20of=20downstream=20PCE=20in=20the=20= chain.=0A=20= =20=20=20=20=20=20=0A=20=20=20=20=20=205.=20=20= Policy=205.=20=20Policy=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20The=20receipt=20of=20a=20= PCMonReq=20message=20may=20trigger=20a=20policy=20violation=20= on=20=20=20=20The=20receipt=20of=20a=20= PCMonReq=20message=20may=20trigger=20a=20policy=20violation=20on=0A=20=20=20=20=20=20=20=20=20= some=20PCE=20in=20which=20case=20the=20PCE=20MUST=20send=20a=20PCErr=20= message=20with=20Error-=20=20=20=20= some=20PCE=20in=20which=20case=20the=20PCE=20MUST=20send=20a=20PCErr=20= message=20with=20Error-=0A=20=20=20=20=20=20=20=20=20Type=3D5=20and=20= Error-value=3D3=20(To=20be=20Confirmed=20by=20IANA).=20=20=20=20Type=3D5=20and=20Error-value=3D3=20(To=20be=20= Confirmed=20by=20IANA).=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=206.=20=20Elements=20of=20Procedure=206.=20=20Elements=20of=20Procedure=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20I=20bit=20processing:=20= as=20indicated=20in=20section=20Section=204.1,=20if=20a=20PCE=20= =20=20=20I=20bit=20processing:=20as=20= indicated=20in=20section=20Section=204.1,=20if=20a=20PCE=0A=20=20=20=20=20=20=20=20=20= supports=20a=20received=20PCMonReq=20message=20and=20that=20message=20= does=20not=20=20=20=20supports=20a=20= received=20PCMonReq=20message=20and=20that=20message=20does=20= not=0A=20=20=20=20= =20=20=20=20=20trigger=20any=20policy=20violation,=20but=20the=20= PCE=20cannot=20provide=20any=20of=20the=20=20=20=20trigger=20any=20policy=20violation,=20but=20the=20= PCE=20cannot=20provide=20any=20of=20the=0A=20=20=20=20=20=20=20=20=20set=20of=20requested=20= performance=20metrics=20for=20unspecified=20reasons,=20the=20= PCE=20=20=20=20set=20of=20requested=20= performance=20metrics=20for=20unspecified=20reasons,=20the=20PCE=0A=20=20=20=20=20=20=20=20=20= MUST=20set=20the=20I=20bit.=20=20Once=20set,=20the=20I=20bit=20MUST=20= NOT=20be=20changed=20by=20a=20=20=20=20= MUST=20set=20the=20I=20bit.=20=20Once=20set,=20the=20I=20bit=20MUST=20= NOT=20be=20changed=20by=20a=0A=20=20=20=20=20=20=20=20=20receiving=20= PCE.=20=20=20=20receiving=20= PCE.=0A=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= =20= =20=20Reception=20of=20a=20PCMonReq=20message:=20= upon=20receiving=20a=20PCMonReq=20message:=20=20=20=20Upon=20= receiving=20a=20PCMonReq=20message:=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=201)=20As=20specified=20in=20[I-D.ietf-pce-pcep],=20= if=20the=20PCE=20does=20not=20support=20=20=20=201)=20As=20specified=20in=20[I-D.ietf-pce-pcep],=20= if=20the=20PCE=20does=20not=20support=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= the=20PCMonReq=20message,=20the=20PCE=20peer=20must=20send=20a=20PCErr=20message=20= with=20=20=20=20the=20PCMonReq=20= message,=20the=20PCE=20peer=20MUST=20= send=20a=20PCErr=20message=20with=0A=20=20=20=20=20=20=20=20=20Error-value=3D2=20= (capability=20not=20supported).=20=20= =20=20Error-value=3D2=20(capability=20not=20supported).=20=20According=20to=20the=20procedure=0A=20=20=20=20=20=20=20= =20=20=20defined=20= in=20section=206.9=20of=20[I-D.ietf-pce-pcep],=20if=20a=20PCC/PCE=20= receives=0A= =20=20=20=20=20=20=20=20=20=20unrecognized=20messages=20at=20a=20rate=20= equal=20of=20greater=20than=20specified=20rate,=0A=20=20=20=20=20=20=20= =20=20=20the=20= PCC/PCE=20must=20send=20a=20PCEP=20CLOSE=20message=20with=20= close=0A=20= =20=20=20=20=20=20=20=20=20value=3D"Reception=20of=20an=20unacceptable=20= number=20of=20unknown=20PCEP=20message.=0A=20=20=20=20=20=20=20=20=20=20In=20this=20case,=20= the=20PCC/PCE=20must=20also=20close=20the=20TCP=20session=20and=20= must=0A=20=20= =20=20=20=20=20=20=20=20not=20send=20any=20further=20PCEP=20messages=20= on=20the=20PCEP=20session.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=202)=20If=20the=20PCE=20supports=20the=20= PCMonReq=20message=20but=20the=20request=20is=20=20=20=202)=20If=20the=20PCE=20supports=20the=20= PCMonReq=20message=20but=20the=20monitoring=0A=20=20=20=20=20=20=20=20=20prohibited=20by=20= policy,=20the=20PCE=20MUST=20send=20a=20= PCErr=20message=20with=20Error-=20= =20=20=20request=20is=20prohibited=20by=20= policy,=20the=20PCE=20must=20follow=20the=20= procedure=0A= =20=20=20=20=20=20=20=20=20Type=3D5=20and=20= Error-value=3D3.=20=20=20=20specified=20in=20section=205.=20=20As=20= pointed=20out=20in=20section=204.3,=20a=20PCE=20may=0A=20=20=20=20=20=20=20= =20=20=20still=20= partially=20satisfy=20a=20request,=20= leaving=20out=20some=20of=20the=20required=0A=20=20=20=20=20=20=20= =20=20=20data=20if=20= not=20allowed=20by=20policy.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=203)=20If=20the=20PCE=20supports=20the=20PCMonReq=20= and=20the=20monitoring=20request=20is=20not=20=20=20=203)=20If=20the=20PCE=20supports=20the=20PCMonReq=20= and=20the=20monitoring=20request=20is=20not=0A=20=20=20=20=20=20=20=20=20prohibited=20by=20= policy,=20the=20receiving=20PCE=20MUST=20first=20determine=20= whether=20=20=20=20prohibited=20by=20= policy,=20the=20receiving=20PCE=20MUST=20first=20determine=20= whether=0A=20=20=20= =20=20=20=20=20=20it=20is=20the=20last=20PCE=20of=20the=20path=20= computation=20chain.=20=20If=20the=20PCE=20is=20not=20=20=20=20it=20is=20the=20last=20PCE=20of=20the=20path=20= computation=20chain.=20=20If=20the=20PCE=20is=20not=0A=20=20=20=20=20=20=20=20=20the=20= last=20element=20of=20the=20path=20computation=20chain,=20the=20PCMonReq=20= message=20=20=20=20the=20last=20= element=20of=20the=20path=20computation=20chain,=20the=20PCMonReq=20= message=0A=20=20=20= =20=20=20=20=20=20is=20relayed=20to=20the=20next=20hop=20PCE:=20= such=20next-hop=20may=20either=20be=20specified=20=20=20=20is=20relayed=20to=20the=20next=20hop=20PCE:=20= such=20next-hop=20may=20either=20be=20specified=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= by=20means=20of=20a=20PCEP-ID=20object=20= present=20in=20the=20PCMonReq=20message=20or=20=20=20=20by=20means=20of=20a=20PCE-ID=20object=20= present=20in=20the=20PCMonReq=20message=20or=0A=20=20=20=20=20=20=20=20=20dynamically=20= determined=20by=20means=20of=20a=20procedure=20outside=20of=20the=20= scope=20=20=20=20dynamically=20= determined=20by=20means=20of=20a=20procedure=20outside=20of=20the=20= scope=0A=20=20=20=20= =20=20=20=20=20of=20this=20document.=20=20Conversely,=20if=20= the=20PCE=20is=20the=20last=20PCE=20of=20the=20path=20=20=20=20of=20this=20document.=20=20Conversely,=20if=20= the=20PCE=20is=20the=20last=20PCE=20of=20the=20path=0A=20=20=20=20=20=20=20=20=20= computation=20chain,=20the=20PCE=20originates=20a=20PCMonRep=20message=20= that=20=20=20=20computation=20chain,=20= the=20PCE=20originates=20a=20PCMonRep=20message=20that=0A=20=20=20=20=20=20=20=20=20= contains=20the=20requested=20objects=20according=20to=20the=20set=20of=20= requested=20PCE=20=20=20=20contains=20= the=20requested=20objects=20according=20to=20the=20set=20of=20requested=20= PCE=0A=20=20=20=20= =20=20=20=20=20states=20metrics=20listed=20in=20the=20= MONITORING=20object=20carried=20in=20the=20=20=20=20states=20metrics=20listed=20in=20the=20= MONITORING=20object=20carried=20in=20the=0A=20=20=20=20=20=20=20=20=20corresponding=20= PCMonReq=20message.=20=20=20=20= corresponding=20PCMonReq=20message.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20=20Upon=20receiving=20a=20PCReq=20message=20that=20carries=20= a=20MONITORING=20and=0A=20=20=20=20=20=20=20=20=20=20potentially=20other=20= monitoring=20objects=20(e.g.=20=20PCE-ID=20object):=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20= =20=20=201)=20As=20= specified=20in=20[I-D.ietf-pce-pcep],=20if=20the=20PCE=20does=20not=20= support=0A=20= =20=20=20=20=20=20=20=20=20(in=20band)=20monitoring,=20the=20PCE=20peer=20= MUST=20send=20a=20PCErr=20message=20with=0A=20=20=20=20=20=20=20= =20=20=20= Error-value=3D2=20(capability=20not=20supported).=20=20According=20to=20= the=20procedure=0A=20=20=20=20=20=20=20=20=20=20defined=20in=20= section=206.9=20of=20[I-D.ietf-pce-pcep],=20if=20a=20PCC/PCE=20= receives=0A= =20=20=20=20=20=20=20=20=20=20unrecognized=20messages=20at=20a=20rate=20= equal=20of=20greater=20than=20specified=20rate,=0A=20=20=20=20=20=20=20= =20=20=20the=20= PCC/PCE=20must=20send=20a=20PCEP=20CLOSE=20message=20with=20= close=0A=20= =20=20=20=20=20=20=20=20=20value=3D"Reception=20of=20an=20unacceptable=20= number=20of=20unknown=20PCEP=20message.=0A=20=20=20=20=20=20=20=20=20=20In=20this=20case,=20= the=20PCC/PCE=20must=20also=20close=20the=20TCP=20session=20and=20= must=0A=20=20= =20=20=20=20=20=20=20=20not=20send=20any=20further=20PCEP=20messages=20= on=20the=20PCEP=20session.=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=202)=20If=20= the=20PCE=20supports=20the=20monitoring=20request=20but=20the=20= monitoring=0A= =20=20=20=20=20=20=20=20=20=20request=20is=20prohibited=20by=20policy,=20the=20= PCE=20must=20follow=20the=20procedure=0A=20=20=20=20=20=20=20=20=20=20specified=20in=20= section=205.=20=20As=20pointed=20out=20in=20section=204.3,=20a=20PCE=20= may=0A=20=20= =20=20=20=20=20=20=20=20still=20partially=20satisfy=20a=20request,=20= leaving=20out=20some=20of=20the=20required=0A=20=20=20=20=20=20=20= =20=20=20data=20if=20= not=20allowed=20by=20policy.=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=203)=20If=20= the=20PCE=20supports=20the=20monitoring=20request=20and=20that=20request=20= is=20not=0A= =20=20=20=20=20=20=20=20=20=20prohibited=20by=20policy,=20the=20receiving=20= PCE=20MUST=20first=20determine=20whether=0A=20=20=20=20=20=20=20= =20=20=20it=20is=20= the=20last=20PCE=20of=20the=20path=20computation=20chain.=20=20If=20the=20= PCE=20is=20not=0A=20=20=20=20=20=20=20=20=20=20the=20last=20element=20= of=20the=20path=20computation=20chain,=20the=20PCReq=20= message=0A=20= =20=20=20=20=20=20=20=20=20(with=20the=20MONITORING=20object=20and=20= potentially=20other=20monitoring=20objects=0A=20=20=20=20=20=20=20= =20=20=20such=20as=20= the=20PCE-ID)=20is=20relayed=20to=20the=20next=20hop=20PCE:=20such=20= next-hop=20may=0A=20=20=20=20=20=20=20=20=20=20either=20be=20= specified=20by=20means=20of=20a=20PCE-ID=20object=20present=20in=20the=20= PCReq=0A=20= =20=20=20=20=20=20=20=20=20message=20or=20dynamically=20determined=20by=20= means=20of=20a=20procedure=20outside=20of=0A=20=20=20=20=20=20=20= =20=20=20the=20= scope=20of=20this=20document.=20=20Conversely,=20if=20the=20PCE=20is=20= the=20last=20PCE=0A=20=20=20=20=20=20=20=20=20=20of=20the=20path=20= computation=20chain,=20the=20PCE=20originates=20a=20PCRep=20= message=0A=20= =20=20=20=20=20=20=20=20=20that=20contains=20the=20requested=20objects=20= according=20to=20the=20set=20of=20requested=0A=20=20=20=20=20=20=20= =20=20=20PCE=20= states=20metrics=20listed=20in=20the=20MONITORING=20and=20potentially=20= other=0A=20= =20=20=20=20=20=20=20=20=20monitoring=20objects=20carried=20in=20the=20= corresponding=20PCReq=20message.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=0A=20= =20=20=20=20=20=20=20=20Upon=20receiving=20a=20PCMonRep=20message:=20= upon=20receiving=20a=20PCMonRep=20message,=20=20=20=20Upon=20receiving=20a=20PCMonRep=20message:=20= upon=20receiving=20a=20PCMonRep=20message,=0A=20=20=20=20=20=20=20=20=20the=20PCE=20processes=20= the=20request,=20adds=20the=20relevant=20objects=20to=20the=20= =20=20=20the=20PCE=20processes=20the=20= request,=20adds=20the=20relevant=20objects=20to=20the=0A=20=20=20=20=20=20=20=20=20= PCMonRep=20message=20and=20forwards=20the=20PCMonRep=20message=20to=20= the=20upstream=20=20=20=20PCMonRep=20= message=20and=20forwards=20the=20PCMonRep=20message=20to=20the=20= upstream=0A=20=20=20= =20=20=20=20=20=20requesting=20PCE=20or=20PCC.=20=20=20=20requesting=20PCE=20or=20PCC.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20Upon=20= receiving=20a=20PCRep=20message=20that=20carrries=20monitoring=20data,=20= the=0A=20=20= =20=20=20=20=20=20=20=20message=20is=20processed,=20additional=20= monitoring=20data=20is=20added=20according=0A=20=20=20=20=20=20=20= =20=20=20to=20this=20= specification=20and=20the=20message=20is=20forwarded=20upstream=20to=20= the=0A=20=20= =20=20=20=20=20=20=20=20requesting=20PCE=20or=20PCC.=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20Special=20case=20of=20= Multi-destination=20monitoring:=20monitoring=20request=20= =20=20=20Special=20case=20of=20= Multi-destination=20monitoring:=20monitoring=20request=0A=20=20=20=20=20=20=20=20=20= related=20to=20more=20than=20one=20destinations=20may=20involve=20a=20= set=20of=20path=20=20=20=20related=20= to=20more=20than=20one=20destinations=20may=20involve=20a=20set=20of=20= path=0A=20=20=20=20= =20=20=20=20=20computation=20chains.=20=20In=20that=20case,=20a=20= PCE=20sends=20each=20copy=20of=20the=20=20=20=20computation=20chains.=20=20In=20that=20case,=20= a=20PCE=20sends=20each=20copy=20of=20the=0A=20=20=20=20=20=20=20=20=20PCMonReq=20message=20= to=20each=20downstream=20PCE=20of=20each=20path=20computation=20= =20=20=20PCMonReq=20message=20to=20each=20= downstream=20PCE=20of=20each=20path=20computation=0A=20=20=20=20=20=20=20=20=20= chain.=20=20=20=20chain.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=207.=20=20Manageability=20= Considerations=207.=20=20= Manageability=20Considerations=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=207.1.=20=20Control=20of=20Function=20and=20Policy=20= 7.1.=20=20Control=20of=20Function=20and=20= Policy=0A=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20=20=20=20It=20= MUST=20be=20possible=20to=20configure=20the=20activation/deactivation=20= of=20PCEP=20=20=20=20It=20MUST=20be=20= possible=20to=20configure=20the=20activation/deactivation=20of=20= PCEP=0A=20=20=20=20= =20=20=20=20=20monitoring=20on=20a=20PCEP=20speaker.=20=20In=20= addition=20to=20the=20parameters=20already=20=20=20=20monitoring=20on=20a=20PCEP=20speaker.=20=20In=20= addition=20to=20the=20parameters=20already=0A=20=20=20=20=20=20=20=20=20listed=20in=20section=20= 8.1=20of=20[I-D.ietf-pce-pcep],=20a=20PCEP=20implementation=20= =20=20=20listed=20in=20section=208.1=20of=20= [I-D.ietf-pce-pcep],=20a=20PCEP=20implementation=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= =20= =20=20SHOULD=20allow=20configuring=20on=20a=20PCE=20whether=20specific,=20= generic,=20in-band=20=20=20=20SHOULD=20allow=20configuring=20on=20a=20PCE=20= whether=20specific,=20generic,=20in=20= band=0A=20=20= =20=20=20=20=20=20=20and=20out-of-band=20monitoring=20requests=20are=20= allowed=20or=20not.=20=20Also=20a=20PCEP=20=20=20=20and=20out=20of=20= band=20monitoring=20requests=20are=20allowed=20or=20not.=20=20= Also=20a=20PCEP=0A= =20=20=20=20=20=20=20=20=20implementation=20SHOULD=20allow=20configuring=20= on=20a=20PCE=20a=20list=20of=20authorized=20=20=20=20implementation=20SHOULD=20allow=20configuring=20= on=20a=20PCE=20a=20list=20of=20authorized=0A=20=20=20=20=20=20=20=20=20state=20metrics=20= (aliveness,=20congestion,=20processing=20time,=20etc).=20=20= This=20=20=20=20state=20metrics=20= (aliveness,=20congestion,=20processing=20time,=20etc).=20=20This=0A=20=20=20=20=20=20=20=20=20may=20= apply=20to=20any=20session=20the=20PCEP=20speaker=20participates=20in,=20= to=20a=20=20=20=20may=20apply=20to=20= any=20session=20the=20PCEP=20speaker=20participates=20in,=20to=20= a=0A=20=20=20=20=20= =20=20= =20=20specific=20session=20with=20a=20given=20PCEP=20peer=20or=20to=20a=20= specific=20group=20of=20=20=20=20= specific=20session=20with=20a=20given=20PCEP=20peer=20or=20to=20a=20= specific=20group=20of=0A=20=20=20=20=20=20=20=20=20sessions=20with=20a=20= specific=20group=20of=20PCEP=20peers,=20for=20instance=20the=20= PCEP=20=20=20=20sessions=20with=20a=20= specific=20group=20of=20PCEP=20peers,=20for=20instance=20the=20= PCEP=0A=20=20=20=20= =20=20=20=20=20peers=20of=20a=20neighbor=20AS.=20= =20=20=20peers=20of=20a=20neighbor=20= AS.=0A=20=20=20=20= =20=20=20=0A=20=20=20=20=20=207.2.=20=20= Information=20and=20Data=20Models=207.2.=20=20Information=20and=20Data=20Models=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20A=20= new=20MIB=20Module=20MAY=20be=20defined=20= that=20provides=20local=20PCE=20state=20=20=20=20A=20new=20MIB=20Module=20may=20be=20defined=20that=20provides=20local=20= PCE=20state=0A=20=20= =20=20=20=20=20=20=20metrics,=20as=20well=20as=20state=20metrics=20of=20= other=20PCEs=20gathered=20using=20=20= =20=20metrics,=20as=20well=20as=20state=20metrics=20of=20other=20PCEs=20= gathered=20using=0A= =20=20=20=20=20=20=20=20=20mechanisms=20defined=20in=20this=20= document.=20=20=20=20mechanisms=20= defined=20in=20this=20document.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=207.3.=20=20Liveness=20Detection=20and=20= Monitoring=207.3.=20=20Liveness=20= Detection=20and=20Monitoring=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20This=20document=20provides=20mechanisms=20to=20= monitor=20the=20liveliness=20and=20=20= =20=20This=20document=20provides=20mechanisms=20to=20monitor=20the=20= liveliness=20and=0A= =20=20=20=20=20=20=20=20=20performances=20of=20a=20given=20PCE=20= chain.=20=20=20=20performances=20of=20= a=20given=20PCE=20chain.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=207.4.=20=20Verify=20Correct=20Operations=20= 7.4.=20=20Verify=20Correct=20= Operations=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20= skipping= =20to=20change=20at=20page=2016,=20line=20= 5=20skipping=20= to=20change=20at=20page=2020,=20line=20= 29=0A=20=20=20=20=20=20=20=20=20= other=20protocols=20in=20addition=20to=20those=20already=20listed=20= in=20=20=20=20other=20protocols=20in=20= addition=20to=20those=20already=20listed=20in=0A=20=20=20=20=20=20=20=20=20= [I-D.ietf-pce-pcep].=20=20=20=20= [I-D.ietf-pce-pcep].=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=207.6.=20=20Impact=20On=20Network=20Operations=20= 7.6.=20=20Impact=20On=20Network=20= Operations=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20The=20= frequency=20of=20PCMonReq=20messages=20may=20impact=20the=20operations=20= of=20PCEs.=20=20=20=20The=20= frequency=20of=20PCMonReq=20messages=20may=20impact=20the=20operations=20= of=20PCEs.=0A=20=20= =20=20=20=20=20=20=20An=20implementation=20SHOULD=20allow=20a=20limit=20= to=20be=20placed=20on=20the=20rate=20of=20=20=20=20An=20implementation=20SHOULD=20allow=20a=20= limit=20to=20be=20placed=20on=20the=20rate=20of=0A=20=20=20=20=20=20=20=20=20= PCMonReq=20messages=20sent=20by=20a=20PCEP=20speaker=20and=20processed=20= from=20a=20peer.=20=20=20=20PCMonReq=20= messages=20sent=20by=20a=20PCEP=20speaker=20and=20processed=20from=20a=20= peer.=0A=20=20=20=20= =20=20=20=20=20It=20SHOULD=20also=20allow=20sending=20a=20= notification=20when=20a=20rate=20threshold=20is=20=20=20=20It=20SHOULD=20also=20allow=20sending=20a=20= notification=20when=20a=20rate=20threshold=20is=0A=20=20=20=20=20=20=20=20=20= reached.=20=20An=20implementation=20SHOULD=20allow=20handling=20PCReq=20= messages=20with=20=20=20=20reached.=20= =20An=20implementation=20SHOULD=20allow=20handling=20PCReq=20messages=20= with=0A=20=20=20=20= =20=20=0A=20=20=20=20=20=20= =20= =20=20a=20higher=20priority=20than=20PCMonReq=20messages.=20= =20=20=20a=20higher=20priority=20than=20= PCMonReq=20messages.=20=20An=20implementation=20= SHOULD=0A=20= =20=20=20=20=20=20=20=20=20allow=20the=20configuration=20of=20a=20second=20= limit=20for=20the=20PCReq=20message=0A=20=20=20=20=20=20=20=20=20=20requesting=20= monitoring=20data.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=208.=20=20IANA=20Considerations=208.=20=20IANA=20Considerations=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=208.1.=20=20New=20PCEP=20Message=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20Each=20PCEP=20message=20= has=20a=20message=20type=20value.=20=20= =20=20Each=20PCEP=20message=20has=20a=20message=20type=20value.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20Two=20new=20PCEP=20= (specified=20in=20[I-D.ietf-pce-pcep])=20messages=20are=20= defined=20=20=20=20Two=20new=20PCEP=20= (specified=20in=20[I-D.ietf-pce-pcep])=20messages=20are=20= defined=0A=20=20=20= =20=20=20=20=20=20in=20this=20document:=20=20=20=20in=20this=20document:=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20Value=20=20=20=20Meaning=20=20= Value=20=20=20=20Description=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20Reference=0A=20=20=20=20=20=20=20=20=20=20=208=20=20=20=20=20= =20Path=20Computation=20Monitoring=20Request=20(PCMonReq)=20= =20=20=208=20=20=20=20=20=20Path=20= Computation=20Monitoring=20Request=20(PCMonReq)=20=20=20This=20document=0A=20=20=20=20=20=20=20=20=20=20=209=20=20=20=20=20= =20Path=20Computation=20Monitoring=20Reply=20(PCMonRep)=20= =20=20=209=20=20=20=20=20=20Path=20= Computation=20Monitoring=20Reply=20(PCMonRep)=20=20=20=20=20This=20document=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= 8.2.=20=20New=20= PCEP=20Objects=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20Each=20PCEP=20object=20has=20an=20Object-Class=20= and=20an=20Object-Type.=20=20The=20=20= =20=20Each=20PCEP=20object=20has=20an=20Object-Class=20and=20an=20= Object-Type.=20=20The=0A=20=20=20=20=20=20=20=20=20following=20new=20PCEP=20= objects=20are=20defined=20in=20this=20document.=20=20=20=20following=20new=20PCEP=20objects=20are=20= defined=20in=20this=20document.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20Object-Class=20=20=20=20= =20=20Name=20=20=20=20= Object-Class=20Value=20Name=20=20=20=20=20=20=20= =20Object-Type=20=20=20=20=20=20=20=20=20=20=20=20=20= Reference=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= =20= =20=20=20=20=20=20=20=20=2019=20=20=20=20=20=20=20=20=20= MONITORING=20=20=20=20=20=20=20=20=20= =20=2019=20=20=20=20=20=20=20=20=20=20MONITORING=20=201=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20This=20document=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20Object-Type=20=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=201=20=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=2020=20=20=20=20=20=20=20=20=20PCEP-ID=20=20= =20=20=20=20=20=20=20=20=2020=20=20=20=20=20=20=20=20=20=20PCE-ID=20=20=20=20=20=201:=20IPv4=20addresses=20=20= =20=20=20=20=20This=20document=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20Object-Type=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=202:=20IPv6=20addresses=20=20=20=20=20=20=20This=20document=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=201:=20IPv4=20addresses=20= =0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=202:=20IPv6=20addresses=20= =0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=2021=20=20=20=20=20=20=20=20= =20PROC-TIME=20=20=20=20=20=20=20=20= =20=20=2021=20=20=20=20=20=20=20=20=20PROC-TIME=20=20=20=201=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20This=20document=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20Object-Type=20=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=201=20=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=2022=20=20=20=20=20=20=20=20=20CONGESTION=20= =20=20=20=20=20=20=20=20=20=2022=20=20=20=20=20= =20=20=20=20CONGESTION=20=20=201=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20This=20= document=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20Object-Type=20=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=201=20= 8.3.=20=20New=20= Error-Type=20and=20Error-Values=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20A=20registry=20has=20been=20created=20for=20the=20= Error-type=20and=20Error-value=20of=20the=20=20=20=20A=20registry=20has=20been=20created=20for=20the=20= Error-type=20and=20Error-value=20of=20the=0A=20=20=20=20=20=20=20=20=20PCEP=20Error=20= Object.=20=20=20=20PCEP=20Error=20= Object.=0A=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20=20=20=20A=20= new=20Error-value=20for=20the=20PCErr=20message=20Error-types=3D5=20= (Policy=20=20=20=20A=20new=20= Error-value=20for=20the=20PCErr=20message=20Error-types=3D5=20= (Policy=0A=20=20=20= =20=20=20=20=20=20Violation)=20(see=20[I-D.ietf-pce-pcep])=20is=20= defined=20in=20this=20document=20=20=20= =20Violation)=20(see=20[I-D.ietf-pce-pcep])=20is=20defined=20in=20this=20= document=0A=20=20=20= =20=20=20=0A=20=20=20=20=20=20= =20= =20=20(Error-Type=20and=20Error-value=20= to=20be=20assigned=20by=20IANA).=20=20= =20=20(Error-value=20to=20be=20assigned=20by=20IANA).=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20= =20Error-type=20=20=20=20=20=20=20=20= Meaning=20=20=20Error-Type=20=20=20Meaning=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Error-value=20=20=20=20Reference=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=205=20=20=20=20=20=20=20=20=20=20=20=20=20=20Policy=20= violation=20=20=20=20=20=205=20=20=20= =20=20=20=20=20=20Policy=20violation=20=20=20=20=20=20=20=20=20=20=20=20=20= =203=20=20=20=20=20=20=20=20=20=20=20=20=20=20= This=20document=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Error-value=3D3=20=20=20=20=20=20=20=20=20=20=20=20=20=20= [This=20document]=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20Monitoring=20message=20= supported=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20Monitoring=20message=20supported=20but=20= rejected=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20but=20rejected=20due=20to=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20due=20to=20= policy=20violation=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20policy=20violation=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20A=20new=20Error-value=20= for=20the=20PCErr=20message=20Error-types=3D6=20(Mandatory=20= =20=20=20A=20new=20Error-value=20for=20the=20= PCErr=20message=20Error-types=3D6=20(Mandatory=0A=20=20=20=20=20=20=20=20=20Object=20missing)=20= (see=20[I-D.ietf-pce-pcep])=20is=20defined=20in=20this=20= document=20=20=20=20Object=20= missing)=20(see=20[I-D.ietf-pce-pcep])=20is=20defined=20in=20this=20= document=0A=20=20=20= =20=20=20=20=20=20(Error-Type=20and=20Error-value=20to=20be=20= assigned=20by=20IANA).=20=20=20=20= (Error-Type=20and=20Error-value=20to=20be=20assigned=20by=20= IANA).=0A=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= =20= =20=20=20=20Error-type=20=20=20=20=20=20=20=20Meaning=20= =20=20Error-type=20=20=20Meaning=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Error-value=20=20=20=20Reference=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=206=20=20=20=20=20=20=20=20=20=20=20=20=20=20Mandatory=20= Object=20missing=20=20=20=20=20=206=20= =20=20=20=20=20=20=20=20Mandatory=20Object=20missing=20=20=20=20=20=20= 4=20=20=20=20=20=20=20=20=20=20=20=20=20=20This=20= document=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20Error-value=3D4=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20[This=20document]=20= =0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20MONITORING=20Object=20= missing=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20MONITORING=20= Object=20missing=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= =208.4.=20=20MONITORING=20Object=20Flag=20= Field=0A=20= =20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20IANA=20is=20requested=20= to=20create=20a=20registry=20to=20manage=20the=20Flag=20field=20= of=0A=20=20= =20=20=20=20=20=20=20=20the=20MONITORING=20object.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20= =20=20=20New=20bit=20= numbers=20may=20be=20allocated=20only=20by=20an=20IETF=20Consensus=20= action.=0A=20= =20=20=20=20=20=20=20=20=20Each=20bit=20should=20be=20tracked=20with=20= the=20following=20qualities:=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20o=20=20Bit=20= number=20(counting=20from=20bit=200=20as=20the=20most=20significant=20= bit)=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20o=20=20Capability=20= Description=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20o=20=20Defining=20= RFC=0A=20=20= =20=20=20=20=20=20=20=20Several=20bits=20are=20defined=20for=20the=20= MONITORING=20Object=20flag=20field=20in=20this=0A=20=20=20=20=20=20=20= =20=20=20= document:=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20Codespace=20of=20the=20= Flag=20field=20(MONITORING=20Object)=0A=20=20=20=20=20=20=20=20=20=20=20=20Bit=20=20=20=20=20= =20Description=20=20=20=20=20=20=20=20=20Reference=0A=20=20=20=20=20=20=20= =20=20=20=20=200-18=20= =20=20=20=20Unassigned=0A=20=20=20=20=20=20=20=20=20=20=20=20=2019=20=20=20=20= =20=20Incomplete=20=20=20=20=20=20=20=20=20=20This=20= document=0A= =20=20=20=20=20=20=20=20=20=20=20=20=2020=20=20=20=20=20=20Congestion=20=20=20= =20=20=20=20=20=20=20This=20document=0A=20=20=20=20=20=20=20=20=20=20=20=20=2021=20=20=20=20= =20=20Processing=20Time=20=20=20=20=20This=20document=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20= 22=20=20=20=20=20=20General=20=20=20=20=20=20=20=20=20=20=20=20=20This=20= document=0A= =20=20=20=20=20=20=20=20=20=20=20=20=2023=20=20=20=20=20=20Liveness=20=20=20=20= =20=20=20=20=20=20=20=20This=20document=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= 8.5.=20=20PROC-TIME=20= Object=20Flag=20Field=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20IANA=20is=20= requested=20to=20create=20a=20registry=20to=20manage=20the=20Flag=20= field=20of=0A= =20=20=20=20=20=20=20=20=20=20the=20PROC-TIME=20object.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20= =20=20=20New=20bit=20= numbers=20may=20be=20allocated=20only=20by=20an=20IETF=20Consensus=20= action.=0A=20= =20=20=20=20=20=20=20=20=20Each=20bit=20should=20be=20tracked=20with=20= the=20following=20qualities:=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20o=20=20Bit=20= number=20(counting=20from=20bit=200=20as=20the=20most=20significant=20= bit)=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20o=20=20Capability=20= Description=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20o=20=20Defining=20= RFC=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20One=20bit=20is=20= defined=20for=20the=20PROC-TIME=20Object=20flag=20field=20in=20= this=0A=20=20= =20=20=20=20=20=20=20=20document:=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20Codespace=20= of=20the=20Flag=20field=20(PROC-TIME=20Object)=0A=20=20=20=20=20=20=20= =20=20=20=20=20Bit=20= =20=20=20=20=20Description=20=20=20=20=20=20=20=20=20=20=20=20=20= Reference=0A= =20=20=20=20=20=20=20=20=20=20=20=200-14=20=20=20=20=20= Unassigned=0A= =20=20=20=20=20=20=20=20=20=20=20=20=2015=20=20=20=20=20=20Estimated=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20This=20document=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20= 8.6.=20=20= CONGESTION=20Object=20Flag=20field=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20IANA=20is=20= requested=20to=20create=20a=20registry=20to=20manage=20the=20Flag=20= field=20of=0A= =20=20=20=20=20=20=20=20=20=20the=20CONGESTION=20object.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20= =20=20=20New=20bit=20= numbers=20may=20be=20allocated=20only=20by=20an=20IETF=20Consensus=20= action.=0A=20= =20=20=20=20=20=20=20=20=20Each=20bit=20should=20be=20tracked=20with=20= the=20following=20qualities:=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20o=20=20Bit=20= number=20(counting=20from=20bit=200=20as=20the=20most=20significant=20= bit)=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20o=20=20Capability=20= Description=0A= =20=20=20=20=20=20=20=20=20=20o=20=20Defining=20RFC=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20= =20=20=20One=20bit=20= is=20defined=20for=20the=20CONGESTION=20Object=20flag=20field=20in=20= this=0A=20=20= =20=20=20=20=20=20=20=20document:=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20Codespace=20= of=20the=20Flag=20field=20(CONGESTION=20Object)=0A=20=20=20=20=20=20=20= =20=20=20=20=20Bit=20= =20=20=20=20=20Description=20=20=20=20=20=20=20=20=20=20=20=20=20= Reference=0A= =20=20=20=20=20=20=20=20=20=20=20=200-6=20=20=20=20=20=20= Unassigned=0A= =20=20=20=20=20=20=20=20=20=20=20=20=207=20=20=20=20=20=20=20Congestion=20=20= =20=20=20=20=20=20=20=20=20=20=20=20This=20document=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=0A=20=20=20=20=20=209.=20=20Security=20= Considerations=209.=20=20Security=20= Considerations=0A=20= =20=20=20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= =20= =20=20Mechanisms=20discussed=20in=20= [I-D.ietf-pce-pcep]=20to=20secure=20a=20PCEP=20session=20= =20=20=20The=20use=20= of=20monitoring=20data=20can=20be=20used=20for=20various=20attacks=20= such=20as=0A= =20=20=20=20=20=20=20=20=20(authenticity,=20integrity,=20privacy,=20DoS=20= protection,=20etc)=20can=20be=20= used=20=20=20=20denail=20of=20service=20attacks=20(for=20= example=20by=20setting=20the=20C=20bit=20and=0A=20=20=20=20=20=20=20=20=20= to=20secure=20the=20PCMonReq,=20PCMonRep=20messages=20and=20PCE=20state=20= metric=20=20= =20=20congestion=20during=20field=20of=20the=20CONGESTION=20object=20to=20= stop=20PCCs=20from=0A=20=20=20=20=20=20=20=20=20objects=20defined=20= in=20this=20document=20as=20well.=20=20A=20PCE=20= may=20face=20a=20denial=20of=20=20=20=20using=20a=20PCE).=20=20= Thus=20it=20is=20recommended=20to=20make=20use=20of=20the=20= security=0A= =20=20=20=20=20=20=20=20=20service=20attack=20= with=20PCMonReq=20messages.=20=20An=20implementation=20= SHOULD=20=20= =20=20mechanisms=20discussed=20in=20[I-D.ietf-pce-pcep]=20to=20= secure=20a=20PCEP=20session=0A=20=20=20=20=20=20=20=20=20allow=20limiting=20= the=20rate=20at=20which=20PCMonReq=20messages=20received=20from=20= a=20=20=20=20(authenticity,=20= integrity,=20privacy,=20DoS=20protection,=20etc)=20to=20secure=20= the=0A=20=20=20=20= =20=20=20=20=20specific=20peer=20are=20processed=20(input=20= shapping),=20or=20from=20another=20domain=20=20=20=20PCMonReq,=20PCMonRep=20messages=20and=20PCE=20= state=20metric=20objects=20defined=20in=0A=20=20=20=20=20=20=20=20=20(see=20also=20= section=207.6).=20=20=20=20this=20= document.=20=20An=20implementation=20= SHOULD=20allow=20limiting=20the=20rate=20at=0A=20=20=20=20=20=20=20=20=20=20which=20PCMonReq=20or=20= PCReq=20messages=20carrying=20monitoring=20= requests=0A= =20=20=20=20=20=20=20=20=20=20= received=20from=20a=20specific=20peer=20are=20processed=20(input=20= shapping),=20or=20from=0A=20=20=20=20=20=20=20=20=20=20another=20domain=20(see=20also=20section=20= 7.6).=0A=20=20=20=20= =20=20=20=0A=20=20=20=20=20=2010.=20=20= Acknowledgements=2010.=20=20= Acknowledgements=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= =20= =20=20The=20authors=20would=20like=20to=20thank=20Eiji=20Oki,=20Mach=20= Chen=20and=20Dimitri=20=20=20=20The=20authors=20would=20like=20to=20thank=20= Eiji=20Oki,=20Mach=20Chen,=20Fabien=20= Verhaeghe=0A= =20=20=20=20=20=20=20=20=20Papadimitriou=20for=20their=20useful=20= comments.=20=20Special=20thank=20to=20Adrian=20=20=20=20and=20Dimitri=20Papadimitriou=20for=20their=20= useful=20comments.=20=20Special=20thank=0A=20=20=20=20=20=20=20=20=20Farrel=20for=20his=20= detailed=20review.=20=20=20=20to=20= Adrian=20Farrel=20for=20his=20detailed=20review.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=2011.=20=20References=20= 11.=20=20References=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=2011.1.=20=20Normative=20References=2011.1.=20=20Normative=20References=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20[I-D.farrel-rtg-common-bnf]=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20= =20=20=20=20=20=20=20Farrel,=20A.,=20"Reduced=20Backus-Naur=20Form=20= (RBNF)=20A=20Syntax=20Used=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20in=20Various=20Protocol=20=20Specifications",=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20= =20=20=20=20=20=20=20draft-farrel-rtg-common-bnf-07=20(work=20in=20= progress),=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20November=20= 2008.=0A=20= =20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20= [I-D.ietf-pce-of]=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20Roux,=20J.,=20Vasseur,=20J.,=20and=20Y.=20Lee,=20"Encoding=20of=20= Objective=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Functions=20= in=20the=20Path=20Computation=20Element=20=20= Communication=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20Protocol=20(PCEP)",=20draft-ietf-pce-of-06=20(work=20in=20= progress),=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20December=20= 2008.=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= [I-D.ietf-pce-pcep]=20=20=20=20= [I-D.ietf-pce-pcep]= =0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Ayyangar,=20A.,=20= Farrel,=20A.,=20Oki,=20E.,=20Atlas,=20A.,=20Dolganow,=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20= Ayyangar,=20A.,=20Farrel,=20A.,=20Oki,=20E.,=20Atlas,=20A.,=20= Dolganow,=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20A.,=20Ikejiri,=20= Y.,=20Kumaki,=20K.,=20Vasseur,=20J.,=20and=20J.=20Roux,=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20A.,=20= Ikejiri,=20Y.,=20Kumaki,=20K.,=20Vasseur,=20J.,=20and=20J.=20= Roux,=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20"Path=20= Computation=20Element=20(PCE)=20Communication=20Protocol=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20= "Path=20Computation=20Element=20(PCE)=20Communication=20Protocol=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= =20= =20=20=20=20=20=20=20=20=20=20=20=20=20(PCEP)",=20= draft-ietf-pce-pcep-18=20(work=20in=20= progress),=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20(PCEP)",=20draft-ietf-pce-pcep-19=20(work=20in=20progress),=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20November=202008.=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20November=20= 2008.=0A=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= =20=20=20=20[I-D.ietf-pce-pcep-xro]=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20= =20=20=20=20=20=20=20Takeda,=20T.,=20Oki,=20E.,=20and=20A.=20Farrel,=20= "Extensions=20to=20the=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20Path=20Computation=20Element=20Communication=20Protocol=20= (PCEP)=20for= =0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Route=20= Exclusions",=20draft-ietf-pce-pcep-xro-06=20(work=20in=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20= =20=20=20=20=20=20=20progress),=20July=202008.=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20[RFC2119]=20=20= Bradner,=20S.,=20"Key=20words=20for=20use=20in=20RFCs=20to=20= Indicate=20=20=20=20[RFC2119]=20=20= Bradner,=20S.,=20"Key=20words=20for=20use=20in=20RFCs=20to=20= Indicate=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Requirement=20= Levels",=20BCP=2014,=20RFC=202119,=20March=201997.=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Requirement=20= Levels",=20BCP=2014,=20RFC=202119,=20March=201997.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20[RFC4655]=20=20Farrel,=20= A.,=20Vasseur,=20J.,=20and=20J.=20Ash,=20"A=20Path=20= Computation=20=20=20=20[RFC4655]=20=20= Farrel,=20A.,=20Vasseur,=20J.,=20and=20J.=20Ash,=20"A=20Path=20= Computation=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Element=20= (PCE)-Based=20Architecture",=20RFC=204655,=20August=202006.=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20= Element=20(PCE)-Based=20Architecture",=20RFC=204655,=20August=20= 2006.=0A=20=20=20=20= =20=20=20=0A=20=20=20=20=20=2011.2.=20=20= Informative=20References=2011.2.=20=20= Informative=20References=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20[I-D.ietf-pce-brpc]=20=20=20=20[I-D.ietf-pce-brpc]=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20Vasseur,=20J.,=20Zhang,=20R.,=20Bitar,=20N.,=20and=20J.=20Roux,=20= "A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20Vasseur,=20J.,=20Zhang,=20R.,=20Bitar,=20N.,=20and=20J.=20Roux,=20= "A=0A=20=20=20=20=20= =20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20Backward=20Recursive=20PCE-based=20= Computation=20(BRPC)=20Procedure=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20Backward=20Recursive=20PCE-based=20= Computation=20(BRPC)=20Procedure=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20To=20Compute=20=20Shortest=20Constrained=20Inter-domain=20= Traffic=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20To=20Compute=20=20Shortest=20Constrained=20Inter-domain=20= Traffic=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Engineering=20= Label=20Switched=20Paths",=20draft-ietf-pce-brpc-09=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Engineering=20= Label=20Switched=20Paths",=20draft-ietf-pce-brpc-09=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20(work=20in=20progress),=20April=20= 2008.=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20(work=20in=20progress),=20April=202008.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= [I-D.ietf-pce-disco-proto-isis]=20= =0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20Roux,=20J.,=20"IS-IS=20Protocol=20= Extensions=20for=20Path=20Computation=20=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20Element=20(PCE)=20Discovery",=20=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20draft-ietf-pce-disco-proto-isis-08=20(work=20in=20= progress),=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20September=20= 2007.=20=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20[I-D.ietf-pce-of]=20=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20Roux,=20J.,=20Vasseur,=20J.,=20and=20Y.=20Lee,=20"Encoding=20of=20= Objective=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Functions=20= in=20the=20Path=20Computation=20Element=20=20= Communication=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Protocol=20= (PCEP)",=20draft-ietf-pce-of-05=20(work=20in=20= progress),=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20September=20= 2008.=20=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20[I-D.ietf-pce-pcep-xro]=20= =0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20Takeda,=20T.,=20Oki,=20E.,=20and=20= A.=20Farrel,=20"Extensions=20to=20the=20=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20Path=20Computation=20Element=20Communication=20Protocol=20= (PCEP)=20for=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Route=20= Exclusions",=20draft-ietf-pce-pcep-xro-06=20(work=20in=20= =0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20progress),=20July=20= 2008.=20=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20[RFC5088]=20=20Le=20= Roux,=20JL.,=20Vasseur,=20JP.,=20Ikejiri,=20Y.,=20and=20R.=20= Zhang,=20=20=20=20[RFC5088]=20=20Le=20= Roux,=20JL.,=20Vasseur,=20JP.,=20Ikejiri,=20Y.,=20and=20R.=20= Zhang,=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20"OSPF=20= Protocol=20Extensions=20for=20Path=20Computation=20Element=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20= "OSPF=20Protocol=20Extensions=20for=20Path=20Computation=20= Element=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(PCE)=20= Discovery",=20RFC=205088,=20January=202008.=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(PCE)=20= Discovery",=20RFC=205088,=20January=202008.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20[RFC5089]=20=20Le=20Roux,=20JL.,=20Vasseur,=20= JP.,=20Ikejiri,=20Y.,=20and=20R.=20Zhang,=20=20=20=20[RFC5089]=20=20Le=20Roux,=20JL.,=20Vasseur,=20= JP.,=20Ikejiri,=20Y.,=20and=20R.=20Zhang,=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20"IS-IS=20Protocol=20Extensions=20for=20Path=20Computation=20= Element=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20"IS-IS=20Protocol=20Extensions=20for=20Path=20Computation=20= Element=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(PCE)=20= Discovery",=20RFC=205089,=20January=202008.=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(PCE)=20= Discovery",=20RFC=205089,=20January=202008.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20Authors'=20Addresses=20Authors'=20Addresses=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20skipping=20= to=20change=20at=20page=2020,=20line=207=20= skipping=20to=20change=20= at=20page=2026,=20line=207=0A=20=20= =20=20=20=20=20=20=20Yuichi=20Ikejiri=20=20=20=20Yuichi=20Ikejiri=0A=20=20=20=20=20=20=20=20=20NTT=20Communications=20= Corporation=20=20=20=20NTT=20= Communications=20Corporation=0A=20=20=20=20=20=20=20=20=201-1-6,=20= Uchisaiwai-cho,=20Chiyoda-ku=20=20=20= =201-1-6,=20Uchisaiwai-cho,=20Chiyoda-ku=0A=20=20=20=20=20=20=20=20=20Tokyo,=20=20=20= 100-8019=20=20=20=20Tokyo,=20=20=20= 100-8019=0A=20=20=20= =20=20=20=20=20=20Japan=20=20=20= =20Japan=0A=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20=20=20=20= Email:=20:=20y.ikejiri@ntt.com=20=20=20= =20Email:=20:=20y.ikejiri@ntt.com=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20Full=20Copyright=20Statement=20Full=20Copyright=20Statement=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20Copyright=20(C)=20The=20IETF=20Trust=20= (2008).=20=20=20=20Copyright=20(C)=20The=20IETF=20Trust=20= (2009).=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20This=20document=20is=20subject=20to=20the=20= rights,=20licenses=20and=20restrictions=20=20=20=20This=20document=20is=20subject=20to=20the=20= rights,=20licenses=20and=20restrictions=0A=20=20=20=20=20=20=20=20=20contained=20in=20BCP=20= 78,=20and=20except=20as=20set=20forth=20therein,=20the=20= authors=20=20=20=20contained=20in=20= BCP=2078,=20and=20except=20as=20set=20forth=20therein,=20the=20= authors=0A=20=20=20= =20=20=20=20=20=20retain=20all=20their=20rights.=20= =20=20=20retain=20all=20their=20= rights.=0A=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20=20=20=20= This=20document=20and=20the=20information=20contained=20herein=20are=20= provided=20on=20an=20=20=20=20This=20= document=20and=20the=20information=20contained=20herein=20are=20provided=20= on=20an=0A=20=20=20= =20=20=20=20=20=20"AS=20IS"=20basis=20and=20THE=20CONTRIBUTOR,=20= THE=20ORGANIZATION=20HE/SHE=20REPRESENTS=20=20=20=20"AS=20IS"=20basis=20and=20THE=20CONTRIBUTOR,=20= THE=20ORGANIZATION=20HE/SHE=20REPRESENTS=0A=20=20=20=20=20=20=20=20=20OR=20IS=20SPONSORED=20= BY=20(IF=20ANY),=20THE=20INTERNET=20SOCIETY,=20THE=20IETF=20TRUST=20= AND=20=20=20=20OR=20IS=20SPONSORED=20= BY=20(IF=20ANY),=20THE=20INTERNET=20SOCIETY,=20THE=20IETF=20TRUST=20= AND=0A=20=20=20=20= =20=20=20=20=20THE=20INTERNET=20ENGINEERING=20TASK=20FORCE=20= DISCLAIM=20ALL=20WARRANTIES,=20EXPRESS=20=20=20=20THE=20INTERNET=20ENGINEERING=20TASK=20FORCE=20= DISCLAIM=20ALL=20WARRANTIES,=20EXPRESS=0A=20=20=20=20=20=20=20=20=20OR=20IMPLIED,=20= INCLUDING=20BUT=20NOT=20LIMITED=20TO=20ANY=20WARRANTY=20THAT=20THE=20USE=20= OF=20=20=20=20OR=20IMPLIED,=20= INCLUDING=20BUT=20NOT=20LIMITED=20TO=20ANY=20WARRANTY=20THAT=20THE=20USE=20= OF=0A=0A=20=20=20=20= =20=20=0A=20=20=20=20=20=C2=A0End=20of=20changes.=2071=20change=20= blocks.=C2=A0=0A=20=20=20=20=20199=20lines=20changed=20or=20= deleted=20408=20lines=20changed=20or=20= added=0A=20=20=20=20=20
This=20html=20diff=20was=20= produced=20by=20rfcdiff=201.35.=20The=20latest=20version=20is=20= available=20from=20http://tools.ietf.org/to= ols/rfcdiff/=20=0A=20=20=20=0A=20=20=20=0A=20= =20=20=0AP=00=00=08=00=00=0B= =00=00=1D=00=00(=00=007=00=00U=00=00k=00=00}=00=00=94=00=00=B4=00=00=BA=00= =00=C4=03=B8=E6=00=00=00=00=00=00=03=01=00=00=00=00=00=00=00=0D= =00=00=00=00=00=00=00=00=00=00=00=00=00=03=B8=E7= --Apple-Mail-5-725339526 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cheers. JP. > Cheers, > Adrian --Apple-Mail-5-725339526 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --Apple-Mail-5-725339526-- From pce-bounces@ietf.org Mon Jan 19 23:14:12 2009 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B80AE28C1B0; Mon, 19 Jan 2009 23:14:12 -0800 (PST) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88D1428C1B0 for ; Mon, 19 Jan 2009 23:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.536 X-Spam-Level: X-Spam-Status: No, score=-10.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iM+zgs0ELyaJ for ; Mon, 19 Jan 2009 23:14:11 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 21BB428C186 for ; Mon, 19 Jan 2009 23:14:09 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,294,1231113600"; d="scan'208";a="31337297" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 20 Jan 2009 07:13:50 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n0K7DoCj012408; Tue, 20 Jan 2009 08:13:50 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0K7Dota002383; Tue, 20 Jan 2009 07:13:50 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jan 2009 08:13:50 +0100 Received: from ams-jvasseur-8711.cisco.com ([10.55.201.130]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jan 2009 08:13:49 +0100 Message-Id: From: JP Vasseur To: Fabien Verhaeghe In-Reply-To: <003f01c97a35$391bd330$b407a8c0@marbenproducts.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 20 Jan 2009 08:13:34 +0100 References: <003f01c97a35$391bd330$b407a8c0@marbenproducts.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 20 Jan 2009 07:13:49.0996 (UTC) FILETIME=[A496AEC0:01C97ACE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4118; t=1232435630; x=1233299630; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Pce]=20PCE=20Monitoring=20=3A=20wrong= 20version=20last=20called |Sender:=20; bh=HwyQ2geSpma0WrgIbxW9+fs6zHM2Frry7eDMjqsF0hs=; b=wndQ0oRt0BWgl3RRs5vw8NExvu9/OnVLL5QhzNCp089KKWzYk4rJo1jkLj hY8wRvXoRJ/w1lV0+EpD21bet7HrsYzQUBdmS5mxoALBG11iW1MyjS2VIv1c FvMDmsel6O; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: pce@ietf.org Subject: Re: [Pce] PCE Monitoring : wrong version last called X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Hi Fabien, On Jan 19, 2009, at 1:55 PM, Fabien Verhaeghe wrote: > Hi JP, > > Thanks for the update. > Everything seems fine to me except 2 minor comments. > See inline > Thanks , see below, >>> That is my fault :-( >>> >>> The I-D is at revision -03 >>> >>> http://www.ietf.org/internet-drafts/draft-ietf-pce-monitoring-03.txt >>> >>> You still have until Monday next week if you want to make comments. >>> >>> As my punishment, I have gone through Fabien's email to check >>> which of >>> his coments still apply... >>> >>> >>> Below my comments on monitoring draft: >>> >>> Section 3.1: >>> >>> Example 3: The request must also contain a MONITORING object. >>> >>> Issue stands. >>> >> That was "in addition to" but the text had been clarified, thanks. >> >> > > Ok > >>> Section 3.2: >>> >>> The format of a PCReq message is as follows: >>> >>> Must be >>> >>> The format of a PCMonRep message is as follows: >>> >>> Issue stands >> >> Fixed. >> > > Format of a PCMonReq (out of band request): > > Must be replaced by > > Format of a PCMonRep (out of band request): Fixed. > > > >>> >>> Section 4.1: >>> >>> Seems the first sentence is repeated twice. >>> >>> Fixed in revision -03 >>> >>> >>> Besides it is said that the Monitoring object MAY be included in >>> PCReq and PCRep so I think it would be good to add the enhanced >>> PCReq and PCRep BNF description. >>> >>> Issue stands >>> >> Added. >> > > Ok > >>> >>> Also in 4.1 >>> s/PCEReq/PCReq/ >>> >> Fixed. >> > > Ok > >>> >>> General comment: >>> >>> The in-band monitoring request is not fully clear to me. >>> >> >> You are right that this is not clearly explained in the current text. >> >>> >>> If there are several path computation requests in the PCReq >>> which one is targeting? >>> i.e. Must the PCE return the processing time for each request >>> seperatly >>> or a single processing time for all requests? >> >> We could decide to have one MONITORING object per request in the >> bundle >> case >> but this does >> introduce some complexity and is not likely to be that useful. I'd >> rather >> propose to keep the current >> mode with one MONITORING object per PCMonReq or PCReq message. When >> present >> the >> monitoring request applies to all requests of the bundle. Text >> added in >> section 3.2. >> > > Seems good to me except maybe I would rather put the text in section > 3.1 > that deals with PCReq. > Indeed. >> " >> As pointed out in [PCEP] we can have several situations: >> o Bundle of a set of independent and non-synchronized path >> computation requests, >> >> o Bundle of a set of independent and synchronized path computation >> requests (SVEC object defined below required), >> >> o Bundle of a set of dependent and synchronized path computation >> requests (SVEC object defined below required). >> >> In the case of a bundle of a set of request, the MONITORING object >> SHOULD >> only be present in the >> first PCReq or PCMonReq message and the monitoring request applies >> to all >> the request of the bundle, >> even in the case of dependent and/or synchronized requests sent >> using more >> than one PCReq or >> PCMonReq message. >> >> >> >> >> >>> In first case what happens if there is an SVEC object and Path >>> Requests >>> are spread in multiple PCRep messages. Must the Monitoring object be >>> repeated? >> >> >> See above. >> > > Ok > >> >>> If a PCRep contains a Monitoring object, is it possible that >>> this PCRep contains Path replies not related to the Monitoring >>> request? >> >> Yes because in the BNF, the is per in the >> >> > > Ok Thanks. JP. > > >> Thanks for the comments. >> >> Cheers, >> >> JP. >> >> >> >> >> Issue stands. >> >> Happy New Year >> >> Adrian >> >> _______________________________________________ >> Pce mailing list >> Pce@ietf.org >> https://www.ietf.org/mailman/listinfo/pce > > _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Tue Jan 20 03:03:56 2009 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E2BC28C127; Tue, 20 Jan 2009 03:03:56 -0800 (PST) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EB313A6950 for ; Tue, 20 Jan 2009 03:03:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYr1dqGaqEaG for ; Tue, 20 Jan 2009 03:03:54 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 72E993A6A42 for ; Tue, 20 Jan 2009 03:03:53 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n0KB37k8010013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 20 Jan 2009 12:03:08 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n0KB36ur020190; Tue, 20 Jan 2009 12:03:06 +0100 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Jan 2009 12:03:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 20 Jan 2009 12:03:04 +0100 Message-ID: In-Reply-To: <3FBAA33B-D92D-4A9D-862A-BA2F936208F1@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Working Group Last Call:draft-ietf-pce-inter-layer-frwk-09.txt thread-index: AclwFs5qK8e8PfhhRSGigiOEUED4dQK1uwuA References: <3FBAA33B-D92D-4A9D-862A-BA2F936208F1@cisco.com> From: "Rambach, Franz (NSN - DE/Munich)" To: , , , , X-OriginalArrivalTime: 20 Jan 2009 11:03:06.0044 (UTC) FILETIME=[ABD507C0:01C97AEE] Subject: Re: [Pce] Working Group Last Call:draft-ietf-pce-inter-layer-frwk-09.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Dear WG, Some comments/questions regarding draft-ietf-pce-inter-layer-frwk-09.txt: Page 5, section "2. Inter-Layer Path Computation": The document enumerats the different PCE-based path computation models, i.e= . single PCE, multiple PCE with and without inter-PCE communication. If the multi-layer path computation only incorporates two layers, the enume= ration is fine. However, if a path traversing three (or more) layers is com= puted, also combinations of the three mentioned approaches are possible. An example for such a combination of the different approaches: A network wi= th three layers is given. Single PCE computation is applied for the two hig= hest layers, i.e. for layer 3 and layer 2. Multiple PCE computation with in= ter-PCE communication is deployed for layer 1 and layer 2. Therefore, two P= CEs - one PCE for layer 3 and layer 2 and one PCE responsible for layer 1 -= are deployed in this network. For a path computation over the three layers= the single PCE approach in combination with the multiple PCE computation a= pproach is used. I propose to add one sentence about the combination of the approaches. Page 5/6, section "2. Inter-Layer Path Computation", paragraph about mono-l= ayer path: Document says: "The second case is that the PCE computes a path that includ= es a loose hop that spans the lower-layer network." If a loose hop is specified, does this automatically mean, that the node be= fore is the entry to the lower layer? This would be in contradiction to the= case that a single layer path computation can include loose hops in the re= sponse and this computed path is completely setup in a single layer, i.e. t= he hop before the loose hop does not specify an entry point to the lower la= yer. = Let's assume that a loose hop does not automatically indicate that a lower = layer path should be used: This means for the multi-layer case that the node before the loose hop, i.e= . the node which expands the loose hop, does not necessarily know that it h= as to go into lower-layer. So, it will first ask the PCE in the higher laye= r and if it receives a "NO-PATH" object from the PCE, it will ask the PCE r= esponsible for the lower layer. Of course, another option is that in the signalling message the node before= the loose hop is marked explicitly as an entry point to the lower layer. (= Is such a feature already defined in the RSVP-TE protocol?) Page 6, section "3. Inter-Layer Path Computation Models": Document says: "As stated in Section 2, two PCE modes defined in the PCE ar= chitecture can be used to perform inter-layer path computation." In Section "2. Inter-Layer Path Computation" three different PCE approaches= were introduced (single PCE, multiple PCE with and multiple PCE without in= ter-PCE communication). You are summarizing the two "multiple PCE approache= s (with or without inter-PCE communication)" in section two into one. Perha= ps one sentence in the introduction of section 3 should state this. Page 12, section "4.2.2 Higher-Layer Signaling Trigger Model", typo: "Note that these actions depends on a policy being applied at the border LS= R." Should be: "depend" instead of "depends" Page 15, section "4.2.3. NMS-VNTM Cooperation Model": "Note that multiple PCE path computation with inter-PCE communication does = not fit in with this model." Why does this model or the single PCE model not fit to the NMS-VNTM coopera= tion model? An example how the multiple PCE with inter-PCE communication in combination= with the NMS-VNTM cooperation model can look like is as follows: Step 1: NMS requests a path computation from PCE Hi. = Step 2: PCE Hi and PCE Lo collaborate to compute a ML path. The result (H1= -H2-L1-L2-H3-H4) is sent back to the NMS. = Step 3: NMS discovers that lower layer links are used. NMS suggests (or re= quests) to VNTM that a new TE link connecting H2 and H3 would be useful. F= urthermore, it provides one solution (H2-L1-L2-H3) for such a TE link. The = NMS notifies VNTM that it will be waiting for the TE link to be created. V= NTM considers whether the suggested lower-layer LSP or any alternative LSP = connecting H2 and H3 should be established if necessary and if acceptable = within VNTM's policy constraints. = Step 4: VNTM requests the ingress LSR in the lower-layer network (H2) to e= stablish a lower-layer LSP. The request message includes the suggested low= er-layer LSP route obtained from the NMS. = Step 5: H2 signals the lower-layer LSP. Step 6: If the lower-layer LSP setup is successful, H2 notifies VNTM that = the LSP is complete and supplies the tunnel information. Step 7: H2 advertises the new LSP as a TE link in the higher-layer network= routing instance. Step 8: VNTM notifies NMS that the underlying lower-layer LSP has been set= up, and NMS notices the new TE link advertisement. Step 9: NMS requests H1 to set up a higher-layer LSP between H1 and H4 wit= h the path computed in Step 2. The lower layer links are replaced by the c= orresponding higher layer TE link. Hence, the NMS sends the path H1-H2-H3-H= 4 to H1. Step 10: H1 initiates signaling with the path H2-H3-H4 to establish the hi= gher-layer LSP. Instead of Step 9 and 10 there is of course the possibility that analog to = the example described in the draft the procedure goes on, i.e. Step 9': NMS again requests H1 to set up a higher-layer LSP between H1 and= H4. Step 10': H1 requests the higher-layer PCE to compute a path and obtain= s a successful result that includes the higher-layer route that is specifie= d as H1-H2-H3-H4, where all hops are strict. Step 11': H1 initiates signaling with the computed path H2-H3-H4 to establ= ish the higher-layer LSP. Quite similar to the above could the single PCE approach fit with this path= control model. (The only difference would be in step 2.) Page 15, section "4.2.3. NMS-VNTM Cooperation Model": "When the PCE fails to compute a path, it informs the PCC (i.e., head-end L= SR) that notifies the NMS. The notification may include the information tha= t there is no TE link between the border LSRs." What happens if the PCE just returns a "NO-PATH" object and the PCE does no= t include any indication why no path could be found? In this case the NMS i= s missing the information which lower layer path is needed to establish a p= ath between H1 and H4. So, what should the NMS do in this case? Page 15, section "4.2.3. NMS-VNTM Cooperation Model": If no path could be found and the request included additional constraints, = e.g. the maimux delay, it is not enough that the PCE indicates which TE lin= k in the higher layer is missing, but the PCE must also indicate which cons= traints such a new TE link must fullfill. (Let's assume that in the example described in the draft a maximum delay fo= r the path is given. In this case the PCE must indicate H1 (or NMS) which T= E link is missing and it must additional indicate how much delay such a new= TE link can have. If the delay is not taken into account during the path c= omputation and path establishment of the lower layer path, it can be that e= ven with the new TE link in the higher layer the path computation of PCE Hi= fails.) Hence, PCE Hi must exactly indicate what problems it encountered during the= path computation. Perhaps one sentence about additional constraints should be added in the de= scription of the NMS-VNTM cooperation model Page 18, section "5. Choosing between Inter-Layer Path Control Models": "This section compares the cooperation model between PCE and VNTM, and the = higher-layer signaling trigger model, in terms of ..." In this chapter also the NMS-VNTM cooperation model is compared, e.g. in se= ction "5.1 VNTM Functions". = Add in the above sentence something like = "This section compares the cooperation model between PCE and VNTM, the high= er-layer signaling trigger model and the NMS-VNTM cooperation model in term= s of ..." Page 19, section "5.3. Complete Inter-Layer LSP Setup Time", typo: "between PCC and PCE, PCE and VNTM, NSM and VNTM" Instead of "NSM" it should be "NMS" Page 20, section "5.4. Network Complexity": "Where PCEs cooperate to determine a path, an iterative computation model s= uch as [BRPC] can be used to select an optimal path across layers." That's fine, but one should keep in mind that BRPC assumes that a domain se= quence is given, i.e. in this case the "layer sequence". For an optimal pat= h you must do a brute force over all possible "layer sequences" using BRPC.= Since one doesn't know in advance how often the layers will be changed, th= e path computation can be cumbersome. Page 21, section "5.5. Separation of Layer Management", 2nd line: "and security concerns (see next section)." The next section is "6. Stability Considerations". You should reference sec= tion "9. Security Considerations". Page 22, 7. IANA Considerations, typo: "This informaitonal" should be = "This informational" Page 28, in section references: " JP. Vasseur et al, "Path Computation Element (PCE) communication Protocol= (PCEP) - Version 1 -" draft-ietf-pce-pcep, work in progress. " Title of the draft is: "Path Computation Element (PCE) Communication Protoc= ol (PCEP)" without "- Version 1 -" Other general comment: I can think of at least one other approache for a path control model sketch= ed in the following: Step 1: PCE(s) calculate multi-layer path. = Step 2: Path is signalled up to the border node of the lower layer. = Step 3: This border node asks VNTM to setup the lower layer path. The borde= r node can provide the VNTM the exact path defined by strict hops. = Step 4: VNTM configures the nodes of the lower layer path. = Step 5: A new TE link is established and announced in the higher layer. = Step 6: The border node continues to signal the path in the higher layer us= ing the newly established TE link. = The main point in this approach is that a network node can request a lower = layer path setup from the VNTM. This approach can can be useful if the lower-layer does not support the fea= ture to setup a path using the control plane. = Best regards, = Franz Rambach = = Nokia Siemens Networks GmbH & Co. KG = COO RTP RT TAF Multi-Layer Networks & Resilience = St.-Martin-Str. 53, Room 63.404 = D-81669 Munich, Germany = Phone: +49-89-636-44188 = Fax: +49-89-636-45814 = franz.rambach@nsn.com = http://www.nokiasiemensnetworks.com/global/ = Nokia Siemens Networks GmbH & Co. KG = Sitz der Gesellschaft: M=FCnchen / Registered office: Munich = Registergericht: M=FCnchen / Commercial registry: Munich, HRA 88537 = WEEE-Reg.-Nr.: DE 52984304 = Pers=F6nlich haftende Gesellschafterin / General Partner: Nokia Siemens Net= works Management GmbH = Gesch=E4ftsleitung / Board of Directors: Lydia Sommer, Olaf Horsthemke = Vorsitzender des Aufsichtsrats / Chairman of supervisory board: Lauri Kivin= en = Sitz der Gesellschaft: M=FCnchen / Registered office: Munich = Registergericht: M=FCnchen / Commercial registry: Munich, HRB 163416 = = ________________________________ From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of ext J= P Vasseur Sent: Tuesday, January 06, 2009 4:53 PM To: pce@ietf.org Subject: [Pce] Working Group Last Call:draft-ietf-pce-inter-layer-frwk-09.t= xt Dear WG, = First of all, happy new year to all of you. This email starts a 2-week Working Group Last Call on draft-ietf-pce-inter-= layer-frwk-09.txt, which will end on January 20 at noon ET. Please send your comment on the Mailing list and to the authors. Thanks. JP. _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Tue Jan 20 04:30:02 2009 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EBCE3A6BD9; Tue, 20 Jan 2009 04:30:02 -0800 (PST) X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5E6A43A6BD8; Tue, 20 Jan 2009 04:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090120123001.5E6A43A6BD8@core3.amsl.com> Date: Tue, 20 Jan 2009 04:30:01 -0800 (PST) Cc: pce@ietf.org Subject: [Pce] I-D Action:draft-ietf-pce-monitoring-04.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : A set of monitoring tools for Path Computation Element based Architecture Author(s) : J. Vasseur, et al. Filename : draft-ietf-pce-monitoring-04.txt Pages : 25 Date : 2009-01-20 A Path Computation Element (PCE) based architecture has been specified for the computation of Traffic Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks in the context of single or multiple domains (where a domain refers to a collection of network elements within a common sphere of address management or path computational responsibility such as IGP areas and Autonomous Systems). Path Computation Clients (PCCs) send computation requests to PCEs, and these may forward the requests to and cooperate with other PCEs forming a "path computation chain". In PCE-based environments, it is thus critical to monitor the state of the path computation chain for troubleshooting and performance monitoring purposes: liveness of each element (PCE) involved in the PCE chain, detection of potential resource contention states and statistics in term of path computation times are examples of such metrics of interest. This document specifies procedures and extensions to the Path Computation Element Protocol (PCEP) in order to gather such information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-monitoring-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pce-monitoring-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-01-20042643.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@ietf.org Tue Jan 20 07:47:19 2009 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C8DB28C1F5; Tue, 20 Jan 2009 07:47:19 -0800 (PST) X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 4BBA63A6B23; Tue, 20 Jan 2009 07:47:16 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090120154717.4BBA63A6B23@core3.amsl.com> Date: Tue, 20 Jan 2009 07:47:17 -0800 (PST) Cc: Internet Architecture Board , pce mailing list , pce chair , RFC Editor Subject: [Pce] Protocol Action: 'Diff-Serv Aware Class Type Object for Path Computation Element Communication Protocol' to Proposed Standard X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org The IESG has approved the following document: - 'Diff-Serv Aware Class Type Object for Path Computation Element Communication Protocol ' as a Proposed Standard This document is the product of the Path Computation Element Working Group. The IESG contact persons are Ross Callon and David Ward. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-dste-02.txt Technical Summary This document specifies a CLASSTYPE object to support Diff-Serve Aware Traffic Engineering (DS-TE) where path computation is performed with an aid of Path Computation Element (PCE). Working Group Summary Good consensus reported (see PROTO writeup by JP Vasseur). The document specifies fairly straightforward protocol extensions to support diff serve when using PCE. Document Quality No known implementation of the I-D but several mentioned that they were planning to implement the protocol extensions specifies in the document. Furthermore, the protocol extensions are very straightforward. Personnel JP Vasseur is the Document Shepherd for this document. Ross Callon is the Responsible Area Director. RFC Editor Note The title and abstract spell diff-serv differently (Diff-Serv versus Diff-Serve). Please change these to be "Diff-Serv". Section 3.3, paragraph 6 please reword as follows: OLD A PCE that recognizes the CLASSTYPE object finds that P flag is not set in the CLASSTYPE object, it MUST send PCE error message towards the sender with the with the error type and error value specified in [PCEP-ID]. NEW A PCE that recognizes the CLASSTYPE object, but finds that the P flag is not set in the CLASSTYPE object, MUST send a PCE error message towards the sender with the error type and error value specified in [PCEP-ID]. _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From jeremy2@afco.demon.co.uk Wed Jan 21 00:59:53 2009 Return-Path: X-Original-To: ietfarch-pce-archive@core3.amsl.com Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 983043A687A for ; Wed, 21 Jan 2009 00:59:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.295 X-Spam-Level: X-Spam-Status: No, score=-16.295 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75xIFkRCUEvY for ; Wed, 21 Jan 2009 00:59:52 -0800 (PST) Received: from aa4df.com (unknown [88.224.71.34]) by core3.amsl.com (Postfix) with SMTP id 8F6943A6AA3 for ; Wed, 21 Jan 2009 00:59:45 -0800 (PST) To: Subject: Administrator, BRANDKEYWORD From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090121085947.8F6943A6AA3@core3.amsl.com> Date: Wed, 21 Jan 2009 00:59:45 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Not see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.ofpitch.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://methoddegree.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BRANDKEYWORD Ltd.
Tower Bridge Business Complex. Unit 8, B940. 478 Clements Road. London. SE79 1DG

© 2006-2008 BRANDKEYWORD, Ltd. All Rights Reserved

From pce-bounces@ietf.org Fri Jan 23 01:46:18 2009 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 561AD3A6A29; Fri, 23 Jan 2009 01:46:18 -0800 (PST) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1BD83A6A29 for ; Fri, 23 Jan 2009 01:46:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.708 X-Spam-Level: X-Spam-Status: No, score=-0.708 tagged_above=-999 required=5 tests=[AWL=-0.420, BAYES_00=-2.599, SARE_URGBIZ=0.725, STOX_REPLY_TYPE=0.001, URG_BIZ=1.585] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0CbLZCt6IGE for ; Fri, 23 Jan 2009 01:46:16 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id EC8FF3A6807 for ; Fri, 23 Jan 2009 01:46:15 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id n0N9jp1W013194; Fri, 23 Jan 2009 09:45:51 GMT Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id n0N9jod6013172; Fri, 23 Jan 2009 09:45:51 GMT Message-ID: From: "Adrian Farrel" To: , Date: Fri, 23 Jan 2009 09:39:54 -0000 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: [Pce] Fw: Nominating Committee call for Internet and Routing AD Nominees X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org FYI. Please consider any additional candidates. Adrian ----- Original Message ----- From: "NomCom Chair" To: "IETF Announcement list" Sent: Wednesday, January 21, 2009 10:33 PM Subject: Nominating Committee call for Internet and Routing AD Nominees > The nominating committee asks for your urgent assistance. > Please nominate additional individuals you think would be good folks to > consider for the Internet and Routing AD slots we are responsible for > filling. > Nominations should be sent to nomcom08@ietf.org. > Nominations will be accepted through Friday, February 6, although the > sooner they are submitted the better, as nominees will not have very long > to provide questionnaires to the committee. > Self nomination is permitted. > > Thank you for your assistance, > Joel M. Halpern > IETF 2008 / 2009 nominating committee chair > > PS: There is no need to resubmit nominations you are sure were submitted > earlier. There is no harm in submitting one if you are not sure. > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From jermaine.mitchell.ctr@afosr.af.mil Mon Jan 26 04:51:57 2009 Return-Path: X-Original-To: ietfarch-pce-archive@core3.amsl.com Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF36F3A6964 for ; Mon, 26 Jan 2009 04:51:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.578 X-Spam-Level: X-Spam-Status: No, score=-13.578 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZsPnv9jPq9P for ; Mon, 26 Jan 2009 04:51:51 -0800 (PST) Received: from net138-212.mclink.it (net138-212.mclink.it [195.110.138.212]) by core3.amsl.com (Postfix) with SMTP id 1B8B93A6A9F for ; Mon, 26 Jan 2009 04:51:48 -0800 (PST) To: Subject: Smile your way through 2009 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090126125150.1B8B93A6A9F@core3.amsl.com> Date: Mon, 26 Jan 2009 04:51:48 -0800 (PST)
Tell a friend · Download latest version See this email as a webpage

Hello pce-archive

Shipped Privately And Discreetly To Your Door!
See this email as a webpage
  We want to put a great big grin on your face in 2009. You'll be to rejoice all year.  

Unsubscribe · Lost Password · Account Settings · Help · Terms of Service · Privacy

© 2003-2009 SASI Limited. SASi Communications S.a.r.l., 22/24 Green St, Amsterdam L1823.

SASi, SASiIn, SASiOut, SASicasts, SASi Certified, SASiMe!, SASi Pro, SASiFind, SASi Prime, SASi To Go, associated logos and the ‘S’-symbol are trademarks of SASi Limited.
From pce-bounces@ietf.org Mon Jan 26 16:15:04 2009 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A48623A6841; Mon, 26 Jan 2009 16:15:04 -0800 (PST) X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 845433A6841; Mon, 26 Jan 2009 16:15:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090127001502.845433A6841@core3.amsl.com> Date: Mon, 26 Jan 2009 16:15:02 -0800 (PST) Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-pcep-mib-00.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : PCE communication protocol(PCEP) Management Information Base Author(s) : K. Koushik, E. Stephan Filename : draft-ietf-pce-pcep-mib-00.txt Pages : 22 Date : 2009-1-21 This memo defines an experimental portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Path Computation Element communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-mib-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pce-pcep-mib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-1-26160208.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --NextPart-- From pcduran@btinternet.com Wed Jan 28 00:22:40 2009 Return-Path: X-Original-To: ietfarch-pce-archive@core3.amsl.com Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70E1E3A6BE3 for ; Wed, 28 Jan 2009 00:22:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -35.863 X-Spam-Level: X-Spam-Status: No, score=-35.863 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_H_CANADIAN=0.5, GB_H_PHARMACY=1, GB_I_LETTER=-2, GB_PHARMACY=1, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, SARE_UNI=0.591, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7P4d3j4ZRKe3 for ; Wed, 28 Jan 2009 00:22:38 -0800 (PST) Received: from amerblind.outbound.ed10.com (athedsl-4537040.home.otenet.gr [94.70.6.216]) by core3.amsl.com (Postfix) with SMTP id 7EB9F3A685D for ; Wed, 28 Jan 2009 00:22:37 -0800 (PST) Content-Return: allowed X-Mailer: devMail.Net (3.0.1854.22234-2) To: pce-archive@ietf.org Subject: RE: Canadian Pharmacy Message 8181948 From: pce-archive@ietf.org MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 7bit Message-Id: <20090128082237.7EB9F3A685D@core3.amsl.com> Date: Wed, 28 Jan 2009 00:22:37 -0800 (PST)
Click Here!
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052
From johnsmithsvt@ahmc.com Wed Jan 28 01:26:57 2009 Return-Path: X-Original-To: ietfarch-pce-archive@core3.amsl.com Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6634D3A6803 for ; Wed, 28 Jan 2009 01:26:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.196 X-Spam-Level: X-Spam-Status: No, score=-6.196 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDVNNuhQqbsG for ; Wed, 28 Jan 2009 01:26:54 -0800 (PST) Received: from ppp91-76-28-160.pppoe.mtu-net.ru (ppp91-76-28-160.pppoe.mtu-net.ru [91.76.28.160]) by core3.amsl.com (Postfix) with SMTP id 440963A67EA for ; Wed, 28 Jan 2009 01:26:51 -0800 (PST) To: Subject: January 73% OFF From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090128092652.440963A67EA@core3.amsl.com> Date: Wed, 28 Jan 2009 01:26:51 -0800 (PST)
Tell a friend · Download latest version See this email as a webpage

Hello pce-archive

Shipped Privately And Discreetly To Your Door!
See this email as a webpage
  We want to put a great big grin on your face in 2009. You'll be to rejoice all year.  

Unsubscribe · Lost Password · Account Settings · Help · Terms of Service · Privacy

© 2003-2009 SASI Limited. SASi Communications S.a.r.l., 22/24 Green St, Amsterdam L9416.

SASi, SASiIn, SASiOut, SASicasts, SASi Certified, SASiMe!, SASi Pro, SASiFind, SASi Prime, SASi To Go, associated logos and the ‘S’-symbol are trademarks of SASi Limited.
From pce-nerul@drbatras.com Wed Jan 28 10:42:06 2009 Return-Path: X-Original-To: ietfarch-pce-archive@core3.amsl.com Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78A6D3A6BF7 for ; Wed, 28 Jan 2009 10:42:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -51.587 X-Spam-Level: X-Spam-Status: No, score=-51.587 tagged_above=-999 required=5 tests=[AWL=27.506, BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_H_CANADIAN=0.5, GB_H_PHARMACY=1, GB_I_LETTER=-2, GB_PHARMACY=1, HELO_MISMATCH_COM=0.553, HTML_EXTRA_CLOSE=2.809, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_UNI=0.591, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9JTCyjLllCza for ; Wed, 28 Jan 2009 10:42:06 -0800 (PST) Received: from amerblind.outbound.ed10.com (163-222-113-92.pool.ukrtel.net [92.113.222.163]) by core3.amsl.com (Postfix) with SMTP id 7A7AD3A69E7 for ; Wed, 28 Jan 2009 10:42:05 -0800 (PST) Content-Return: allowed X-Mailer: devMail.Net (3.0.1854.22234-2) To: pce-archive@ietf.org Subject: RE: Canadian Pharmacy Message 04594 From: pce-archive@ietf.org MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 7bit Message-Id: <20090128184205.7A7AD3A69E7@core3.amsl.com> Date: Wed, 28 Jan 2009 10:42:05 -0800 (PST)
Click Here!
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2009 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052
From nadeem.fiaz@alfuttaim.ae Thu Jan 29 13:34:08 2009 Return-Path: X-Original-To: ietfarch-pce-archive@core3.amsl.com Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0F883A685E for ; Thu, 29 Jan 2009 13:34:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.226 X-Spam-Level: X-Spam-Status: No, score=-14.226 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LN3mcetAjHPp for ; Thu, 29 Jan 2009 13:34:08 -0800 (PST) Received: from aguakan.com (unknown [78.114.194.70]) by core3.amsl.com (Postfix) with SMTP id 6938D3A687E for ; Thu, 29 Jan 2009 13:34:01 -0800 (PST) To: Subject: hi, my friend! From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090129213403.6938D3A687E@core3.amsl.com> Date: Thu, 29 Jan 2009 13:34:01 -0800 (PST)
Tell a friend · Download latest version See this email as a webpage

Hello!

Shipped Privately And Discreetly To Your Door!
See this email as a webpage
  We want to put a great big grin on your face in 2009. You'll be to rejoice all year.  

Unsubscribe · Lost Password · Account Settings · Help · Terms of Service · Privacy

© 2003-2009 CopS Limited.CopS Communications S.a.r.l., 22/24 Green St, Amsterdam L5460.

CopS, CopSIn, CopSOut, CopScasts, CopS Certified, CopSMe!, CopS Pro, CopSFind, CopS Prime, CopS To Go, associated logos and the Cop-symbol are trademarks of CopS Limited.
From oxupport@amazonherb.com Thu Jan 29 18:28:18 2009 Return-Path: X-Original-To: ietfarch-pce-archive@core3.amsl.com Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55F273A6B20 for ; Thu, 29 Jan 2009 18:28:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -30.909 X-Spam-Level: X-Spam-Status: No, score=-30.909 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcuPjFdPB7cP for ; Thu, 29 Jan 2009 18:28:17 -0800 (PST) Received: from afaq.org (unknown [189.224.54.49]) by core3.amsl.com (Postfix) with SMTP id C575B3A6898 for ; Thu, 29 Jan 2009 18:28:11 -0800 (PST) To: Subject: Your order From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090130022813.C575B3A6898@core3.amsl.com> Date: Thu, 29 Jan 2009 18:28:11 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From pcducati-996@dynojet.com Thu Jan 29 23:22:23 2009 Return-Path: X-Original-To: ietfarch-pce-archive@core3.amsl.com Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFEE93A6358 for ; Thu, 29 Jan 2009 23:22:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -67.672 X-Spam-Level: X-Spam-Status: No, score=-67.672 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, FH_HOST_EQ_D_D_D_D=0.765, GB_H_CANADIAN=0.5, GB_H_PHARMACY=1, GB_PHARMACY=1, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNiIBHHvX0F3 for ; Thu, 29 Jan 2009 23:22:23 -0800 (PST) Received: from amerblind.outbound.ed10.com (ppp-58-10-155-14.revip2.asianet.co.th [58.10.155.14]) by core3.amsl.com (Postfix) with SMTP id 92F773A698A for ; Thu, 29 Jan 2009 23:22:20 -0800 (PST) Content-Return: allowed X-Mailer: devMail.Net (3.0.1854.22234-2) To: pce-archive@ietf.org Subject: RE: Canadian Pharmacy Message 7750280 From: pce-archive@ietf.org MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 7bit Message-Id: <20090130072221.92F773A698A@core3.amsl.com> Date: Thu, 29 Jan 2009 23:22:20 -0800 (PST)


From pceap@atune.biz Fri Jan 30 10:04:52 2009 Return-Path: X-Original-To: ietfarch-pce-archive@core3.amsl.com Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E30D028C2E7 for ; Fri, 30 Jan 2009 10:04:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -74.947 X-Spam-Level: X-Spam-Status: No, score=-74.947 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_VERIZON_P=2.144, GB_H_CANADIAN=0.5, GB_H_PHARMACY=1, GB_I_LETTER=-2, GB_PHARMACY=1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_EXTRA_CLOSE=2.809, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjvMHnSNM35o for ; Fri, 30 Jan 2009 10:04:45 -0800 (PST) Received: from amerblind.outbound.ed10.com (pool-98-115-71-253.chi01.dsl-w.verizon.net [98.115.71.253]) by core3.amsl.com (Postfix) with SMTP id BCCB93A6A53 for ; Fri, 30 Jan 2009 10:04:43 -0800 (PST) Content-Return: allowed X-Mailer: devMail.Net (3.0.1854.22234-2) To: pce-archive@ietf.org Subject: RE: Canadian Pharmacy Message 80318 From: pce-archive@ietf.org MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 7bit Message-Id: <20090130180444.BCCB93A6A53@core3.amsl.com> Date: Fri, 30 Jan 2009 10:04:43 -0800 (PST)
Click Here!
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2009 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052
From oaxygjgfeiwlb@21-pub.co.jp Fri Jan 30 11:04:56 2009 Return-Path: X-Original-To: ietfarch-pce-archive@core3.amsl.com Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A54FB28C132 for ; Fri, 30 Jan 2009 11:04:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -25.208 X-Spam-Level: X-Spam-Status: No, score=-25.208 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OD2uIn87Fn6u for ; Fri, 30 Jan 2009 11:04:56 -0800 (PST) Received: from dslb-088-071-194-038.pools.arcor-ip.net (dslb-088-071-194-038.pools.arcor-ip.net [88.71.194.38]) by core3.amsl.com (Postfix) with SMTP id 02CD13A6885 for ; Fri, 30 Jan 2009 11:04:53 -0800 (PST) To: Subject: Throughout mail From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090130190455.02CD13A6885@core3.amsl.com> Date: Fri, 30 Jan 2009 11:04:53 -0800 (PST)
Tell a friend · Download latest version See this email as a webpage

Hello!

Shipped Privately And Discreetly To Your Door!
See this email as a webpage
  We want to put a great big grin on your face in 2009. You'll be to rejoice all year.  

Unsubscribe · Lost Password · Account Settings · Help · Terms of Service · Privacy

© 2003-2009 CopS Limited.CopS Communications S.a.r.l., 22/24 Green St, Amsterdam L8823.

CopS, CopSIn, CopSOut, CopScasts, CopS Certified, CopSMe!, CopS Pro, CopSFind, CopS Prime, CopS To Go, associated logos and the Cops-symbol are trademarks of CopS Limited.