From julien.meuric@orange-ftgroup.com Thu Jul 1 05:37:43 2010 Return-Path: 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 6D9973A6B31 for ; Thu, 1 Jul 2010 05:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.167 X-Spam-Level: X-Spam-Status: No, score=-1.167 tagged_above=-999 required=5 tests=[AWL=0.482, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_32=0.6] 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 TBBuwDbVoOwU for ; Thu, 1 Jul 2010 05:37:42 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 88DC43A6B19 for ; Thu, 1 Jul 2010 05:37:42 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 81C876C0019 for ; Thu, 1 Jul 2010 14:36:47 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 74B456C0013 for ; Thu, 1 Jul 2010 14:30:03 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Jul 2010 14:29:53 +0200 Received: from [10.193.67.78] ([10.193.67.78]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Jul 2010 14:29:52 +0200 Message-ID: <4C2C8A40.4000407@orange-ftgroup.com> Date: Thu, 01 Jul 2010 14:29:52 +0200 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11pre) Gecko/20100626 Lightning/1.0b1 Shredder/3.0.6pre MIME-Version: 1.0 To: pce@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Jul 2010 12:29:52.0643 (UTC) FILETIME=[1AE73D30:01CB1919] Subject: [Pce] Building PCE Agenda for IETF 78 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: , X-List-Received-Date: Thu, 01 Jul 2010 12:37:43 -0000 Hi PCE'rs. The draft agenda for IETF 78 has been available for a while, the final version should be published tomorrow, July 2nd. The PCE session is currently planned on Monday at 1 PM (unfortunately again at the same time as RTGWG). If you would like to get a slot in the PCE agenda, send your requests to the chairs and secretary not later than Monday 12th July. Please, include the name of the draft(s), the presenter name and the requested duration. Beware of the cut-off dates: 2010-07-05 (Monday): Internet Draft Cut-off for initial document (-00) submission by 17:00 PDT (24:00 UTC). 2010-07-12 (Monday): Internet Draft final submission cut-off by 17:00 PDT (24:00 UTC). Thanks, JP & Julien From julien.meuric@orange-ftgroup.com Mon Jul 5 02:08:57 2010 Return-Path: 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 9B8BD3A6812 for ; Mon, 5 Jul 2010 02:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=0.35] 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 hmQtIhBRWzev for ; Mon, 5 Jul 2010 02:08:56 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 9D4F93A67AB for ; Mon, 5 Jul 2010 02:08:56 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E82946C000F for ; Mon, 5 Jul 2010 11:08:58 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id CA4236C000C for ; Mon, 5 Jul 2010 11:08:58 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Jul 2010 11:08:46 +0200 Received: from [10.193.75.182] ([10.193.75.182]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Jul 2010 11:08:45 +0200 Message-ID: <4C31A11C.5080900@orange-ftgroup.com> Date: Mon, 05 Jul 2010 11:08:44 +0200 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11pre) Gecko/20100626 Lightning/1.0b1 Shredder/3.0.6pre MIME-Version: 1.0 To: pce@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jul 2010 09:08:45.0313 (UTC) FILETIME=[ABDDCF10:01CB1C21] Subject: [Pce] Fwd: Internet Draft Initial Version (-00) Cut-Off Monday, July 5 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: , X-List-Received-Date: Mon, 05 Jul 2010 09:08:57 -0000 Hi. Today is cut-off day for ID-00. In case you need to use manual submission and got publication delayed, it is expected behaviour, no need to retry multiple times. Regards, Julien -------- Message original -------- De : Alexa Morris This is a reminder that the Internet Draft Initial Version (-00) cut- off is this coming, Monday, July 5, 2010. Please note that, because the AMS office is closed this Monday, manual submissions will not be processed until Tuesday, July 6. All Initial Version (-00) submissions are due by 17:00 PDT (00:00 Tuesday, July 6 UTC). All drafts can be uploaded using the ID submission tool located here: https://datatracker.ietf.org/idst/upload.cgi Regards, Alexa ----------- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amorris@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From daniel@olddog.co.uk Mon Jul 5 07:52:11 2010 Return-Path: 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 9E3C83A6828 for ; Mon, 5 Jul 2010 07:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 xdbKk-OOyoaz for ; Mon, 5 Jul 2010 07:52:10 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id 43F5B3A67EE for ; Mon, 5 Jul 2010 07:52:10 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id o65EqAJd022624 for ; Mon, 5 Jul 2010 15:52:10 +0100 Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id o65Eq9Qo022609 for ; Mon, 5 Jul 2010 15:52:09 +0100 From: "Daniel King" To: References: <20100702222442.67C3B3A68A3@core3.amsl.com> In-Reply-To: <20100702222442.67C3B3A68A3@core3.amsl.com> Date: Mon, 5 Jul 2010 15:52:10 +0100 Message-ID: <000901cb1c51$a5bac2c0$f1304840$@co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsaNWdeoB1GDRWRRCyYzfgWCu8sBgCG35Ag Content-Language: en-gb Subject: Re: [Pce] New Version Notification for draft-king-pce-hierarchy-fwk-04 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: , X-List-Received-Date: Mon, 05 Jul 2010 14:52:11 -0000 Hi All,=20 The authors of H-PCE recently submitted a new version of the draft.=20 http://tools.ietf.org/html/draft-king-pce-hierarchy-fwk-04 Updates include: - We have reviewed and documented the applicability of H-PCE to = traversing multiple Antonymous Systems and Areas.=20 - We have begun to document some of the required PCEP extensions for = H-PCE. This work will probably be broken out into a separate document in = the future. - Indentified an additional PCEP MIB to report parent PCE and child PCE = information. - Fixed various nits.=20 Br, Dan. -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 Sent: 02 July 2010 23:25 To: daniel@olddog.co.uk Cc: adrian@olddog.co.uk; qzhao@huawei.com; zhangfatai@huawei.com Subject: New Version Notification for draft-king-pce-hierarchy-fwk-04 A new version of I-D, draft-king-pce-hierarchy-fwk-04.txt has been = successfully submitted by Daniel King and posted to the IETF repository. Filename: draft-king-pce-hierarchy-fwk Revision: 04 Title: The Application of the Path Computation Element Architecture to = the Determination of a Sequence of Domains in MPLS & GMPLS Creation_date: 2010-07-02 WG ID: Independent Submission Number_of_pages: 25 Abstract: Computing optimum routes for Label Switched Paths (LSPs) across multiple domains in Multiprotocol Label Switching Traffic Engineering (MPLS-TE) and Generalized MPLS (GMPLS) networks presents a problem because no single point of path computation is aware of all of the links and resources in each domain. A solution may be achieved using the Path Computation Element (PCE) architecture. Where the sequence of domains is known a priori, various techniques can be employed to derive an optimum path. If the domains are simply-connected, or if the preferred points of interconnection are also known, the Per-Domain Path Computation technique can be used. Where there are multiple connections between domains and there is no preference for the choice of points of interconnection, the Backward Recursive Path Computation Procedure (BRPC) can be used to derive an optimal path. This document examines techniques to establish the optimum path when the sequence of domains is not known in advance. The document shows how the PCE architecture can be extended to allow the optimum sequence of domains to be selected, and the optimum end-to-end path to be derived. = =20 The IETF Secretariat. From root@core3.amsl.com Tue Jul 6 00:45:03 2010 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 772493A6816; Tue, 6 Jul 2010 00:45:03 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100706074503.772493A6816@core3.amsl.com> Date: Tue, 6 Jul 2010 00:45:02 -0700 (PDT) Cc: pce@ietf.org Subject: [Pce] I-D Action:draft-ietf-pce-gmpls-aps-req-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: , X-List-Received-Date: Tue, 06 Jul 2010 07:45:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Document: draft-ietf-pce-gmpls-aps-req-02.txt Author(s) : T. Otani, et al. Filename : draft-ietf-pce-gmpls-aps-req-02.txt Pages : 11 Date : 2010-07-06 The initial effort of PCE WG is specifically focused on MPLS (Multi- protocol label switching). As a next step, this draft describes functional requirements for GMPLS (Generalized MPLS) application of PCE (Path computation element). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-gmpls-aps-req-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-gmpls-aps-req-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-06003949.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Tue Jul 6 09:00:02 2010 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 538413A69DB; Tue, 6 Jul 2010 09:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100706160002.538413A69DB@core3.amsl.com> Date: Tue, 6 Jul 2010 09:00:02 -0700 (PDT) Cc: pce@ietf.org Subject: [Pce] I-D Action:draft-ietf-pce-pcep-mib-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: , X-List-Received-Date: Tue, 06 Jul 2010 16:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : PCE communication protocol(PCEP) Management Information Base Author(s) : K. Koushik, et al. Filename : draft-ietf-pce-pcep-mib-02.txt Pages : 25 Date : 2010-07-06 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-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-pcep-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-06085706.I-D@ietf.org> --NextPart-- From daniel@olddog.co.uk Tue Jul 6 09:08:39 2010 Return-Path: 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 283A03A680D for ; Tue, 6 Jul 2010 09:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 nku9RoJV8yY5 for ; Tue, 6 Jul 2010 09:08:38 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id ECC5B3A63C9 for ; Tue, 6 Jul 2010 09:08:37 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id o66G8cu2010359 for ; Tue, 6 Jul 2010 17:08:38 +0100 Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id o66G8cci010353 for ; Tue, 6 Jul 2010 17:08:38 +0100 From: "Daniel King" To: References: <20100706160002.538413A69DB@core3.amsl.com> In-Reply-To: <20100706160002.538413A69DB@core3.amsl.com> Date: Tue, 6 Jul 2010 17:08:39 +0100 Message-ID: <006501cb1d25$7f536b80$7dfa4280$@co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsdJE9/O7dAALc4Q9eH+06OTp1ZGQAAHrow Content-Language: en-gb Subject: Re: [Pce] I-D Action:draft-ietf-pce-pcep-mib-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: , X-List-Received-Date: Tue, 06 Jul 2010 16:08:39 -0000 Hi all, Obviously, the authors of pce-pcep-mib recently submitted a new version. The document includes the following updates: - Compilation errors have been fixed. - Imports have been cleaned up, unnecessary imports removed. - Additional introduction text. - Added relations to other MIB modules. - Added example of the PCEP MIB module usage. - Added vulnerable tables and objects and their sensitivity/vulnerability to Security Considerations section. At this point it would be immensely useful to hear from anyone who has implemented or part-implemented a/the PCEP MIB. Br, Dan. -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: 06 July 2010 17:00 To: i-d-announce@ietf.org Cc: pce@ietf.org Subject: [Pce] I-D Action:draft-ietf-pce-pcep-mib-02.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 : PCE communication protocol(PCEP) Management Information Base Author(s) : K. Koushik, et al. Filename : draft-ietf-pce-pcep-mib-02.txt Pages : 25 Date : 2010-07-06 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-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. From Simon.Wingrove@metaswitch.com Tue Jul 6 09:46:56 2010 Return-Path: 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 759AF3A693D for ; Tue, 6 Jul 2010 09:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=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 Jyxeip6QsJOE for ; Tue, 6 Jul 2010 09:46:52 -0700 (PDT) Received: from enfiets1.dataconnection.com (enfiets1.dataconnection.com [192.91.191.38]) by core3.amsl.com (Postfix) with ESMTP id 81DBB3A684B for ; Tue, 6 Jul 2010 09:46:29 -0700 (PDT) Received: from ENFIMBOX1.ad.datcon.co.uk (172.18.10.27) by enfiets1.dataconnection.com (172.18.4.21) with Microsoft SMTP Server (TLS) id 8.1.436.0; Tue, 6 Jul 2010 17:48:19 +0100 Received: from ENFIMBOX1.ad.datcon.co.uk ([172.18.10.27]) by ENFIMBOX1.ad.datcon.co.uk ([172.18.10.27]) with mapi; Tue, 6 Jul 2010 17:46:19 +0100 From: Simon Wingrove To: "pce@ietf.org" Date: Tue, 6 Jul 2010 17:44:56 +0100 Thread-Topic: Concerns with PCE MIB Drafts Thread-Index: AcsdKpDmiSq+0rZsT7W0m3L9XGHftg== Message-ID: <11DE3EEC54A8A44EAD99D8C0D3FD72079A3804A703@ENFIMBOX1.ad.datcon.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_11DE3EEC54A8A44EAD99D8C0D3FD72079A3804A703ENFIMBOX1adda_" MIME-Version: 1.0 Subject: [Pce] Concerns with PCE MIB Drafts 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: , X-List-Received-Date: Tue, 06 Jul 2010 16:46:56 -0000 --_000_11DE3EEC54A8A44EAD99D8C0D3FD72079A3804A703ENFIMBOX1adda_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I've been examining the MIB drafts currently in the PCE WG and have a few c= oncerns on some specific parts (see below). I'm hoping to get some feedbac= k from the WG on these. Best wishes, Simon Wingrove Network Technologies Division Metaswitch Networks simon.wingrove@metaswitch.com www.metaswitch.com Concerns: (C1) PcePcepIdentifier is an LDP identifier The PcePcepIdentifier object is used as the index for a PCE peer, and is de= scribed with the text "The LDP identifier is a six octet quantity which is = used to identify a PCE client." I think an IP address should be used inste= ad. - The PCEP Peer MIB table uses this object as the index for peers, but whe= re would the ID have been learnt from? - The PCE discovery protocol identifies a PCE purely by IP address: this s= eems to be an easier way to identify a PCC/PCE throughout the MIBs. (C2) There is no PCEP MIB for a PCE, only a PCC The PCEP MIB seems to concern a PCEP implementation for a PCC. We need a M= IB table for a PCEP implementation for a PCE. I believe that the original = intention of the pcePcepClientTable was to serve both roles (see http://www= .ietf.org/proceedings/73/slides/pce-9/pce-9.htm). Is this the case? - If so, I think that we should clarify this in the table's description. - Indeed if this is the case, I'm not sure why the table is so named. Per= haps pcePcepEntityTable or pcePcepSpeakerTable would be more suitable; do p= eople agree? (C3) Use of IP Addresses on the MIB The PCE Discovery MIB table provides two objects to describe the IP address= es of a PCE, pceDiscoveryIPv4Address and pceDiscoveryIPv6Address. I sugges= t that this should be represented by two MIB objects pceDiscoveryIPAddressT= ype and pceDiscoveryIPAddress instead. - Since the PCE discovery RFC (4674) i= dentifies a PCE purely by IP address, a discovered PCE will only ever have = exactly one address, either IPv4 or IPv6, never both. - There are examples of this way of representing IP addresses in the MGMD = MIB, RFC 5519. (C4) Stats in the PCEP Session MIB Table do not persist The PCEP MIB contains session information in pcePcepSessionTable. I think = this information should belong on the peer table instead. - My understanding is that an entry in this table exists when a session to= a peer exists. - However, this table contains stats objects such as pcePcepSesssionCorrup= tedMsgs, the number of corrupted messages received during session. - I think that this information would be helpful to a MIB user after the s= ession has ended, and the table entry gone away. (C5) Gauges and Counters The stats fields pceDiscoveryKnownPCEs and pceDiscoveryActivePCEs are of ty= pe Counter32, but should be of type Gauge32. Counters should increase, nev= er decrease, and are allowed to wrap (see RFC 2578, sections 7.1.6-7). A Gauge is more appropriate for a statisti= c that can increase or decrease. --_000_11DE3EEC54A8A44EAD99D8C0D3FD72079A3804A703ENFIMBOX1adda_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi all,
 
I’ve been examining the MIB drafts currently in the PCE WG and h= ave a few concerns on some specific parts (see below).  I’m hopi= ng to get some feedback from the WG on these.
 
Best wishes,
Simon Wingrove
Network Technologies Division
Metaswitch Networks
 
Concerns:
 
(C1) PcePcepIdentifier<= /font> is an L= DP identifier
The PcePcepIdentifier= object is used as the index for a PCE peer, and is described with t= he text "The LDP identifier is a six octet quantity which is used to i= dentify a PCE client."  I think an IP address should be used instead.
-  The PCEP Peer MIB table uses this object as the index for peer= s, but where would the ID have been learnt from?
-  The PCE discovery protocol identifies a PCE purely by IP addre= ss: this seems to be an easier way to identify a PCC/PCE throughout the MIB= s.
 
(C2)  There is no PCEP MIB for a PCE, only a PCC
The PCEP MIB seems to concern a PCEP implementation for a PCC.  W= e need a MIB table for a PCEP implementation for a PCE.  I believe tha= t the original intention of the pcePcepClientTable was to serve both roles (see http://www.ietf.org/proceedings/73/slides/= pce-9/pce-9.htm).  Is this the case?
-  If so, I think that we should clarify this in the table’= s description.
-  Indeed if this is the case, I’m not sure why the table i= s so named.  Perhaps = pcePcepEntityTable or pcePcepSpeakerTable would be more suitable; do people agree?
 
(C3)  Use of IP Addresses on the MIB
The PCE Discovery MIB table provides two objects to describe the IP ad= dresses of a PCE, pceDisco= veryIPv4Address and pceDiscoveryIPv6Address.  I suggest that this should be represented by two MIB objects pceDiscoveryIPAddressType and pceDiscoveryIPAddress instead.
-  Since the PCE discovery RFC (4674) identifies a = PCE purely by IP address, a discovered PCE will only ever have exactly one = address, either IPv4 or IPv6, never both.
-  There are examples of this way of representing IP addresses in= the MGMD MIB, RFC 5519.
 
(C4)  Stats in the PCEP Session MIB Table do not persist
The PCEP MIB contains session information in pcePcepSessionTable.  I think this info= rmation should belong on the peer table instead.
-  My understanding is that an entry in this table exists when a = session to a peer exists.
-  However, this table contains stats objects such as pcePcepSesssionCorruptedMsgs,= the number of corrupted messages received during session.
-  I think that this information would be helpful to a MIB user a= fter the session has ended, and the table entry gone away.
 
(C5) Gau= ges and Counters
The stats fields pceD= iscoveryKnownPCEs and pceDiscoveryActivePCEs are of type Counter32, but should be of ty= pe Gauge32.  Counters should increase, never decrease, and are allowed to wrap (see RFC 2578, sections 7.1= .6-7).  A Gauge is more appropriate for a statistic that can increase = or decrease.
 
 
 --_000_11DE3EEC54A8A44EAD99D8C0D3FD72079A3804A703ENFIMBOX1adda_-- From jpv@cisco.com Tue Jul 6 10:05:59 2010 Return-Path: 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 404133A6A44 for ; Tue, 6 Jul 2010 10:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.07 X-Spam-Level: X-Spam-Status: No, score=-10.07 tagged_above=-999 required=5 tests=[AWL=0.529, 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 1A5PwhZA8U6x for ; Tue, 6 Jul 2010 10:05:56 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id D59EF3A690F for ; Tue, 6 Jul 2010 10:05:56 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAN7+MkyrR7Ht/2dsb2JhbACgAnGnK5pOhSUEiDqCLA X-IronPort-AV: E=Sophos;i="4.53,547,1272844800"; d="scan'208";a="154482892" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 06 Jul 2010 17:05:59 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o66H5wWd009172; Tue, 6 Jul 2010 17:05:58 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Jul 2010 19:05:58 +0200 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Jul 2010 19:05:57 +0200 Message-Id: From: JP Vasseur To: Daniel King In-Reply-To: <006501cb1d25$7f536b80$7dfa4280$@co.uk> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 6 Jul 2010 19:05:56 +0200 References: <20100706160002.538413A69DB@core3.amsl.com> <006501cb1d25$7f536b80$7dfa4280$@co.uk> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 06 Jul 2010 17:05:58.0033 (UTC) FILETIME=[80B5E810:01CB1D2D] Cc: pce@ietf.org Subject: Re: [Pce] I-D Action:draft-ietf-pce-pcep-mib-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: , X-List-Received-Date: Tue, 06 Jul 2010 17:05:59 -0000 I'd like to second Dan's request here (and thanks to the authors). All, please review and comment this important piece of work. Thanks. JP. On Jul 6, 2010, at 6:08 PM, Daniel King wrote: > Hi all, > > Obviously, the authors of pce-pcep-mib recently submitted a new > version. The > document includes the following updates: > > - Compilation errors have been fixed. > - Imports have been cleaned up, unnecessary imports removed. > - Additional introduction text. > - Added relations to other MIB modules. > - Added example of the PCEP MIB module usage. > - Added vulnerable tables and objects and their sensitivity/ > vulnerability to > Security Considerations section. > > At this point it would be immensely useful to hear from anyone who has > implemented or part-implemented a/the PCEP MIB. > > Br, Dan. > > -----Original Message----- > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: 06 July 2010 17:00 > To: i-d-announce@ietf.org > Cc: pce@ietf.org > Subject: [Pce] I-D Action:draft-ietf-pce-pcep-mib-02.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 : PCE communication protocol(PCEP) Management > Information Base > Author(s) : K. Koushik, et al. > Filename : draft-ietf-pce-pcep-mib-02.txt > Pages : 25 > Date : 2010-07-06 > > 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-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. > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From zhangfatai@huawei.com Tue Jul 6 18:10:18 2010 Return-Path: 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 445993A6403 for ; Tue, 6 Jul 2010 18:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.806 X-Spam-Level: X-Spam-Status: No, score=0.806 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 2zOk8Nh2WGcq for ; Tue, 6 Jul 2010 18:10:07 -0700 (PDT) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 6BD0D3A6816 for ; Tue, 6 Jul 2010 18:10:04 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5500LIRXWKTS@szxga05-in.huawei.com> for pce@ietf.org; Wed, 07 Jul 2010 09:09:56 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5500IGEXWKPQ@szxga05-in.huawei.com> for pce@ietf.org; Wed, 07 Jul 2010 09:09:56 +0800 (CST) Received: from Z41162C ([10.70.76.96]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L550079VXWJCQ@szxml04-in.huawei.com> for pce@ietf.org; Wed, 07 Jul 2010 09:09:56 +0800 (CST) Date: Wed, 07 Jul 2010 09:09:55 +0800 From: Fatai Zhang To: pce@ietf.org Message-id: <021a01cb1d71$1c8f62a0$604c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: multipart/alternative; boundary="Boundary_(ID_ugwPxpQ/KlyZAbIMXkVAGg)" X-Priority: 3 X-MSMail-priority: Normal References: <20100706074503.772493A6816@core3.amsl.com> Subject: Re: [Pce] I-D Action:draft-ietf-pce-gmpls-aps-req-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: , X-List-Received-Date: Wed, 07 Jul 2010 01:10:18 -0000 This is a multi-part message in MIME format. --Boundary_(ID_ugwPxpQ/KlyZAbIMXkVAGg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi All, We just submitted an updated version of this draft: http://www.ietf.org/id/draft-ietf-pce-gmpls-aps-req-02.txt The major updates are as follows: (1) Added Section 3.3 to address unnumbered endpoints (2) Added Section 3.4 to address Asymmetric Bandwidth Path Computation (3) Updated Section 4.1 to extend switching capability to cover DCSC, PBB-TE and added two items for supportting unnumbered interfaces and asymmetric bandwidth path computation. Best Regards Fatai ----- Original Message ----- From: To: Cc: Sent: Tuesday, July 06, 2010 3:45 PM Subject: [Pce] I-D Action:draft-ietf-pce-gmpls-aps-req-02.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 : Document: draft-ietf-pce-gmpls-aps-req-02.txt > Author(s) : T. Otani, et al. > Filename : draft-ietf-pce-gmpls-aps-req-02.txt > Pages : 11 > Date : 2010-07-06 > > The initial effort of PCE WG is specifically focused on MPLS (Multi- > protocol label switching). As a next step, this draft describes > functional requirements for GMPLS (Generalized MPLS) application of > PCE (Path computation element). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pce-gmpls-aps-req-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. > -------------------------------------------------------------------------------- > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > --Boundary_(ID_ugwPxpQ/KlyZAbIMXkVAGg) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi All,
 
We just submitted an updated version of this draft:
 
 
The major updates are as follows:
(1) Added Section 3.3 to address unnumbered endpoints
(2) Added Section 3.4 to address Asymmetric Bandwidth Path Computation
(3) Updated Section 4.1 to extend switching capability to cover DCSC, PBB-TE and added two items for supportting unnumbered interfaces and asymmetric bandwidth path computation.
 
 
 
Best Regards
 
Fatai
 
----- Original Message -----
Sent: Tuesday, July 06, 2010 3:45 PM
Subject: [Pce] I-D Action:draft-ietf-pce-gmpls-aps-req-02.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           : Document: draft-ietf-pce-gmpls-aps-req-02.txt
> Author(s)       : T. Otani, et al.
> Filename        : draft-ietf-pce-gmpls-aps-req-02.txt
> Pages           : 11
> Date            : 2010-07-06
>
> The initial effort of PCE WG is specifically focused on MPLS (Multi-
> protocol label switching). As a next step, this draft describes
> functional requirements for GMPLS (Generalized MPLS) application of
> PCE (Path computation element).
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pce-gmpls-aps-req-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.
>

> _______________________________________________
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
> --Boundary_(ID_ugwPxpQ/KlyZAbIMXkVAGg)-- From cyril.margaria@nsn.com Wed Jul 7 06:05:21 2010 Return-Path: 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 0101B3A67B6 for ; Wed, 7 Jul 2010 06:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.299 X-Spam-Level: X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_EXTNSN=2.3] 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 9q9Q9LaVcB-m for ; Wed, 7 Jul 2010 06:05:17 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 972383A67CF for ; Wed, 7 Jul 2010 06:05:13 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o67D5ENo000532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 7 Jul 2010 15:05:14 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o67D4m3D021491 for ; Wed, 7 Jul 2010 15:05:14 +0200 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Jul 2010 15:04:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Jul 2010 14:55:00 +0200 Message-ID: In-Reply-To: <20100701110002.5740D3A68D9@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-margaria-pce-gmpls-pcep-extensions-01.txt Thread-Index: AcsZDL1PgtReb2F3QPWUnctvORj78QEsOuSg References: <20100701110002.5740D3A68D9@core3.amsl.com> From: "Margaria, Cyril (NSN - DE/Munich)" To: X-OriginalArrivalTime: 07 Jul 2010 13:04:57.0925 (UTC) FILETIME=[003A4750:01CB1DD5] Subject: Re: [Pce] I-D Action:draft-margaria-pce-gmpls-pcep-extensions-01.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: , X-List-Received-Date: Wed, 07 Jul 2010 13:05:21 -0000 Hi all,=20 We submitted an updated version of this draft=20 http://www.ietf.org/internet-drafts/draft-margaria-pce-gmpls-pcep-extens ions-01.txt The major updates are:=20 - merge of draft-margaria-pce-gmpls-pcep-extensions-00.txt and=20 - Improved endpoints specification - Improved Label specification=20 One topic raised in the last meeting was the use of TLV for generalized bandwidth, for this we would like to get feedback from the WG=20 A first point is that according to RFC5440 section 7.7 the bandwidth object has a fixed body size of 4 Byte,=20 and does not define TLV. Following a strict interpretation its not possible to add any TLV. A more relaxed interpretation could allow TLV with new C-Types : is it possible with new C-Type to change the BANDWIDTH object length and allow TLVs? A second point is that the new C-Type would contains only TLV and no fixed body.=20 Processing could be more complicated, is there arguments for or against TLV-only object body? Best Regards Cyril Margaria =20 > -----Original Message----- > From: i-d-announce-bounces@ietf.org=20 > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of ext=20 > Internet-Drafts@ietf.org > Sent: Thursday, July 01, 2010 1:00 PM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-margaria-pce-gmpls-pcep-extensions-01.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 > Title : PCEP extensions for GMPLS > Author(s) : C. Margaria, et al. > Filename :=20 > draft-margaria-pce-gmpls-pcep-extensions-01.txt > Pages : 29 > Date : 2010-07-01 >=20 > This memo provides extensions for the Path Computation=20 > Element communication Protocol (PCEP) for the support of=20 > GMPLS control plane. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-margaria-pce-gmpls-p > cep-extensions-01.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail=20 > reader implementation to automatically retrieve the ASCII=20 > version of the Internet-Draft. >=20 From jpv@cisco.com Fri Jul 9 00:40:06 2010 Return-Path: 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 2C4D93A6359 for ; Fri, 9 Jul 2010 00:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.296 X-Spam-Level: X-Spam-Status: No, score=-10.296 tagged_above=-999 required=5 tests=[AWL=0.302, 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 jYo+FAfeV2od for ; Fri, 9 Jul 2010 00:40:04 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 4F5EC3A67A3 for ; Fri, 9 Jul 2010 00:40:03 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKdvNkyrR7H+/2dsb2JhbACBRJ50caN8mlOFJwSISYIu X-IronPort-AV: E=Sophos;i="4.53,562,1272844800"; d="scan'208,217";a="556475411" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 09 Jul 2010 07:40:06 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o697e3kG023818 for ; Fri, 9 Jul 2010 07:40:06 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Jul 2010 09:40:03 +0200 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Jul 2010 09:40:03 +0200 Message-Id: <16DEB77E-ED6B-4E5B-9B53-64C03C49A2D1@cisco.com> From: JP Vasseur To: pce@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-300--293708180 Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 9 Jul 2010 09:40:02 +0200 References: <20100708192931.479143A689F@core3.amsl.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 09 Jul 2010 07:40:03.0121 (UTC) FILETIME=[F13EC210:01CB1F39] Subject: [Pce] Fwd: IETF 78 - Registration Cut-off Dates 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: , X-List-Received-Date: Fri, 09 Jul 2010 07:40:06 -0000 --Apple-Mail-300--293708180 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Begin forwarded message: > From: IETF Secretariat > Date: July 8, 2010 9:29:31 PM CEDT > To: IETF Announcement list > Cc: wgchairs@ietf.org > Subject: IETF 78 - Registration Cut-off Dates > > 78th IETF Meeting > Maastricht, Netherlands > July 25-30, 2010 > > 1. Registration Cut-off Dates > 2. Social Event > ======================================================= > 1) Registration Cut-off Dates > You can register on line at: http://www.ietf.org/meeting/78/index.html > Please note the following registration cut-off dates: > * 2010-07-16 (Friday): Early Bird registration and payment cut-off at > 17:00 PDT (24:00 UTC). > * 2010-07-19 (Monday): Registration cancellation cut-off at 17:00 PDT > (24:00 UTC). > * 2010-07-23 (Friday): Final Pre-Registration and Pre-Payment cut-off > at 17:00 local Maastricht time (08:00 PDT, 15:00 UTC). > > 2) Social Event > General Information: http://www.ietf78.nl/social-event.html > Where: On the banks of the Meuse River > Date: Tuesday 27 July 2010 > Time: 19:30 - 22:30 (Note: this is a new time) > Host: Ministry of Economic Affairs, the Province of Limburg and the > Municipality of Maastricht > > Maastricht, one of the Netherlands oldest and most beautiful cities, > is > the backdrop to this spectacular social event, exclusively for > visitors to > the 78th IETF meeting. It is a lighthearted break in the IETF78 > Maastricht > program - an event you do not want to miss! > > You must register for the IETF meeting before you can purchase social > event tickets. > > Only 17 days until IETF 78! --Apple-Mail-300--293708180 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

Begin = forwarded message:

From: = IETF Secretariat <ietf-secretariat@ietf.org>= ;
Date: July 8, 2010 9:29:31 PM = CEDT
To: IETF Announcement list <ietf-announce@ietf.org>
Subject: = IETF 78 - Registration Cut-off Dates 

78th IETF = Meeting
Maastricht, Netherlands
July 25-30, 2010

1. = Registration Cut-off Dates
2. Social = Event
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
1) Registration Cut-off Dates
You can = register on line at: http://www.ietf.org/mee= ting/78/index.html
Please note the following registration = cut-off dates:
 * 2010-07-16 (Friday): Early Bird registration = and payment cut-off at
17:00 PDT (24:00 UTC).
 * 2010-07-19 = (Monday): Registration cancellation cut-off at 17:00 PDT
(24:00 = UTC).
 * 2010-07-23 (Friday): Final Pre-Registration and = Pre-Payment cut-off
at 17:00 local Maastricht time (08:00 PDT, 15:00 = UTC).

2) Social Event
General Information: http://www.ietf78.nl/socia= l-event.html
Where: On the banks of the Meuse River
Date: = Tuesday 27 July 2010
Time: 19:30 - 22:30 (Note: this is a new = time)
Host: Ministry of Economic Affairs, the Province of Limburg and = the
Municipality of Maastricht

Maastricht, one of the = Netherlands oldest and most beautiful cities, is
the backdrop to this = spectacular social event, exclusively for visitors to
the 78th IETF = meeting. It is a lighthearted break in the IETF78 Maastricht
program = - an event you do not want to miss!

You must register for the = IETF meeting before you can purchase social
event = tickets.

Only 17 days until IETF = 78!

= --Apple-Mail-300--293708180-- From jpv@cisco.com Sat Jul 10 01:10:42 2010 Return-Path: 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 3E70F3A6993 for ; Sat, 10 Jul 2010 01:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.35 X-Spam-Level: X-Spam-Status: No, score=-10.35 tagged_above=-999 required=5 tests=[AWL=0.249, 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 5qELeDRwFL3B for ; Sat, 10 Jul 2010 01:10:41 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 73FF53A659C for ; Sat, 10 Jul 2010 01:10:41 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgHAHrHN0yrRN+J/2dsb2JhbACUC4xAcaMJmiGFJwSITIIu X-IronPort-AV: E=Sophos;i="4.55,179,1278288000"; d="scan'208";a="156614149" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 10 Jul 2010 08:10:47 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o6A8AhQL000316; Sat, 10 Jul 2010 08:10:47 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 10 Jul 2010 10:10:43 +0200 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 10 Jul 2010 10:10:43 +0200 Message-Id: <188B2A67-12D2-4D73-BA07-CA876ECC6774@cisco.com> From: JP Vasseur To: pce@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 10 Jul 2010 10:10:42 +0200 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 10 Jul 2010 08:10:43.0323 (UTC) FILETIME=[64810CB0:01CB2007] Subject: [Pce] PCE Charter Update 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: , X-List-Received-Date: Sat, 10 Jul 2010 08:10:42 -0000 Dear all, We have updated our charter milestone with two new WG items that have been completed (both on P2MP)" http://datatracker.ietf.org/wg/pce/charter/ Julien and I are working on the PCE agenda, we'll have a slot to discuss the PCE charter at the next PCE WG meeting in Maastricht. Thanks. JP. From jpv@cisco.com Sat Jul 10 01:10:51 2010 Return-Path: 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 CB6943A6993 for ; Sat, 10 Jul 2010 01:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.434 X-Spam-Level: X-Spam-Status: No, score=-9.434 tagged_above=-999 required=5 tests=[AWL=-0.695, BAYES_20=-0.74, 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 m6r-mjxmlyZQ for ; Sat, 10 Jul 2010 01:10:50 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 8543F3A6981 for ; Sat, 10 Jul 2010 01:10:49 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIFAPLHN0xAZnwM/2dsb2JhbACBQ58IcaMMmiGFJwSITIIu X-IronPort-AV: E=Sophos;i="4.55,179,1278288000"; d="scan'208,217";a="130715522" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 10 Jul 2010 08:10:54 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6A8AsMa020632; Sat, 10 Jul 2010 08:10:54 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 10 Jul 2010 10:10:54 +0200 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 10 Jul 2010 10:10:53 +0200 Message-Id: From: JP Vasseur To: pce@ietf.org In-Reply-To: <0AABDB80-8FC5-4E87-B682-B2014D770EF0@cisco.com> Content-Type: multipart/alternative; boundary=Apple-Mail-6--205457698 Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 10 Jul 2010 10:10:52 +0200 References: <20100623193239.90B363A696B@core3.amsl.com> <0AABDB80-8FC5-4E87-B682-B2014D770EF0@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 10 Jul 2010 08:10:53.0402 (UTC) FILETIME=[6A82FBA0:01CB2007] Cc: Adrian Farrel Subject: Re: [Pce] Fwd: IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-pce-pcep-p2mp-extensions-11 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: , X-List-Received-Date: Sat, 10 Jul 2010 08:10:52 -0000 --Apple-Mail-6--205457698 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Dear all, Since we have not received any objection about that (late) IPR disclosure, the document can move forward. Thanks. JP. On Jun 24, 2010, at 9:45 AM, JP Vasseur wrote: > Dear all, > > We have just been informed of that IPR disclosure (late in the > process) while the document (draft-ietf-pcep-pcep-p2mp- > extensions-11) is in the RFC editor queue. > Please let me know by July 9 if you have any objection moving > forward knowing of that IPR. > > Thanks. > > JP. > > Begin forwarded message: > >> From: IETF Secretariat >> Date: June 23, 2010 9:32:39 PM CEDT >> To: Jeanlouis.Leroux@orange-ftgroup.com, zali@cisco.com, takeda.tomonori@lab.ntt.co.jp >> , julien.meuric@orange-ftgroup.com, qzhao@huawei.com, daniel@olddog.co.uk >> , fabien.verhaeghe@gmail.com, mohamad.chaitou@gmail.com >> Cc: stbryant@cisco.com, adrian.farrel@huawei.com, pce@ietf.org, jpv@cisco.com >> , julien.meuric@orange-ftgroup.com, ipr-announce@ietf.org >> Subject: IPR Disclosure: Huawei Technologies Co.,Ltd's Statement >> about IPR related to draft-ietf-pce-pcep-p2mp-extensions-11 >> >> Dear Jean-Louis Le Roux, Zafar Ali, Tomonori Takeda, Julien Meuric, >> Quintin Zhao, Daniel King, Fabien Verhaeghe, Mohamad Chaitou: >> >> An IPR disclosure that pertains to your Internet-Draft entitled >> "Extensions to >> the Path Computation Element Communication Protocol (PCEP) for >> Point-to-Multipoint Traffic Engineering Label Switched Paths" >> (draft-ietf-pce-pcep-p2mp-extensions) was submitted to the IETF >> Secretariat on >> 2010-06-23 and has been posted on the "IETF Page of Intellectual >> Property Rights >> Disclosures" (https://datatracker.ietf.org/ipr/1339/). The title of >> the IPR >> disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR >> related to >> draft-ietf-pce-pcep-p2mp-extensions-11." >> >> The IETF Secretariat >> >> > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce --Apple-Mail-6--205457698 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Dear = all,

Since we have not received any objection about = that (late) IPR disclosure, the document can move = forward.

Thanks.

JP.

On Jun 24, 2010, at 9:45 AM, JP Vasseur = wrote:

Dear = all,

We have just been informed of that IPR = disclosure (late in the process) while the document = (draft-ietf-pcep-pcep-p2mp-extensions-11) is in the RFC editor = queue.
Please let me know by July 9 if you have any objection = moving forward knowing of that = IPR.

Thanks.

JP.

Begin forwarded message:

From: = IETF Secretariat <ietf-ipr@ietf.org>
Date: = June 23, 2010 9:32:39 PM CEDT
Cc: stbryant@cisco.com, adrian.farrel@huawei.com, = pce@ietf.org, jpv@cisco.com, julien.meuric@orange-ftgr= oup.com, ipr-announce@ietf.org
Subject: = IPR Disclosure: Huawei Technologies Co.,Ltd's Statement = about IPR related to = draft-ietf-pce-pcep-p2mp-extensions-11

Dear = Jean-Louis Le Roux, Zafar Ali, Tomonori Takeda, Julien Meuric, Quintin = Zhao, Daniel King, Fabien Verhaeghe, Mohamad Chaitou:

An IPR = disclosure that pertains to your Internet-Draft entitled "Extensions = to
the Path Computation Element Communication Protocol (PCEP) = for
Point-to-Multipoint Traffic Engineering Label Switched = Paths"
(draft-ietf-pce-pcep-p2mp-extensions) was submitted to the = IETF Secretariat on
2010-06-23 and has been posted on the "IETF Page = of Intellectual Property Rights
Disclosures" (https://datatracker.ietf.o= rg/ipr/1339/). The title of the IPR
disclosure is "Huawei = Technologies Co.,Ltd's Statement about IPR related = to
draft-ietf-pce-pcep-p2mp-extensions-11."

The IETF = Secretariat



__________= _____________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mail= man/listinfo/pce

= --Apple-Mail-6--205457698-- From helia.pouyllau@alcatel-lucent.com Mon Jul 12 08:37:30 2010 Return-Path: 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 95AEA3A6BC2 for ; Mon, 12 Jul 2010 08:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGKqpnMq0xdc for ; Mon, 12 Jul 2010 08:37:29 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 081033A6B87 for ; Mon, 12 Jul 2010 08:36:56 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o6CFZiO1011584 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 12 Jul 2010 17:35:44 +0200 Received: from FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Mon, 12 Jul 2010 17:35:44 +0200 From: "POUYLLAU, HELIA (HELIA)" To: "pce@ietf.org" Date: Mon, 12 Jul 2010 17:35:43 +0200 Thread-Topic: I-D Update draft-pouyllau-pce-enhanced-errors-02 Thread-Index: AcsgB2xmJIWhR6sMR+W84ngr5UaSUABzsQAA Message-ID: <2D26984ED849C94A8C7D6276DA008FF2125C43D150@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> References: <188B2A67-12D2-4D73-BA07-CA876ECC6774@cisco.com> In-Reply-To: <188B2A67-12D2-4D73-BA07-CA876ECC6774@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Subject: [Pce] I-D Update draft-pouyllau-pce-enhanced-errors-02 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: , X-List-Received-Date: Mon, 12 Jul 2010 15:37:30 -0000 Hi all, We have submitted an updated version of draft http://www.ietf.org/id/draft-= pouyllau-pce-enhanced-errors-02.txt The major update is - as mentioned during IETF 77 meeting - a new section d= escribing some potential scenarios of usages of the error and notification = types specified by the draft.=20 Before detailing further these scenarios, we would like to have feedback fr= om the mailing-list. Obviously, feedback on other sections is also welcomed= . Best regards H=E9lia Pouyllau From daniel@olddog.co.uk Tue Jul 13 06:06:13 2010 Return-Path: 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 5E4D83A6954 for ; Tue, 13 Jul 2010 06:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.665 X-Spam-Level: X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599, J_CHICKENPOX_32=0.6] 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 QMppSiTAwz2n for ; Tue, 13 Jul 2010 06:06:12 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by core3.amsl.com (Postfix) with ESMTP id 502FD3A67ED for ; Tue, 13 Jul 2010 06:06:12 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id o6DD6IdF007437 for ; Tue, 13 Jul 2010 14:06:18 +0100 Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id o6DD6HYn007405 for ; Tue, 13 Jul 2010 14:06:17 +0100 From: "Daniel King" To: References: <20100712211504.475353A6B87@core3.amsl.com> In-Reply-To: <20100712211504.475353A6B87@core3.amsl.com> Date: Tue, 13 Jul 2010 14:06:20 +0100 Message-ID: <000a01cb228c$3063be00$912b3a00$@co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsiB1gy1yNkkxn2TLqyRySj2G/lMQAhC1XQ Content-Language: en-gb Subject: Re: [Pce] I-D Action:draft-king-pce-inter-area-as-applicability-01.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: , X-List-Received-Date: Tue, 13 Jul 2010 13:06:13 -0000 Hi PCE'rs, Please find a new version of our pce-inter-area-as-applicability draft: http://tools.ietf.org/html/draft-king-pce-inter-area-as-applicability-01 Our document examines the applicability of the PCE architecture, protocols, and protocol extensions for computing multi-area and multi-AS paths in MPLS and GMPLS networks. This revision combines the addition of new co-authors and updates to the following sections: - Applicability of the PCE to Inter-AS Traffic Engineering - Strict Explicit Path and Loose Path - AS Inclusion and Exclusion - Inter-AS Recovery - Inter-AS PCE Peering Policies - Traffic Engineering Database - Provisioning Techniques - Point-to-Multipoint - Optical Domains and ASON See you in Maastricht! Br, Dan -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: 12 July 2010 22:15 To: i-d-announce@ietf.org Subject: I-D Action:draft-king-pce-inter-area-as-applicability-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Applicability of the Path Computation Element to Inter-Area and Inter-AS MPLS and GMPLS Traffic Engineering Author(s) : D. King, et al. Filename : draft-king-pce-inter-area-as-applicability-01.txt Pages : 16 Date : 2010-07-12 The Path Computation Element (PCE) may be used for computing services that traverse multi-area and multi-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) networks. This document examines the applicability of the PCE architecture, protocols, and protocol extensions for computing multi-area and multi-AS paths in MPLS and GMPLS networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-king-pce-inter-area-as-applicabili ty-01.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. From julien.meuric@orange-ftgroup.com Tue Jul 13 06:35:19 2010 Return-Path: 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 D499E3A67DA for ; Tue, 13 Jul 2010 06:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.855 X-Spam-Level: X-Spam-Status: No, score=-0.855 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_05=-1.11, HELO_EQ_FR=0.35] 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 7+4ZzTtxZf28 for ; Tue, 13 Jul 2010 06:35:19 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id C617B3A694E for ; Tue, 13 Jul 2010 06:35:18 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id BCCC86C0151 for ; Tue, 13 Jul 2010 15:35:27 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 830B76C00E9 for ; Tue, 13 Jul 2010 15:24:22 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Jul 2010 15:24:04 +0200 Received: from [10.193.71.77] ([10.193.71.77]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Jul 2010 15:24:04 +0200 Message-ID: <4C3C68F4.4030409@orange-ftgroup.com> Date: Tue, 13 Jul 2010 15:24:04 +0200 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11pre) Gecko/20100626 Lightning/1.0b1 Shredder/3.0.6pre MIME-Version: 1.0 To: pce@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jul 2010 13:24:04.0286 (UTC) FILETIME=[A9FD95E0:01CB228E] Subject: [Pce] PCE Agenda in Maastricht 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: , X-List-Received-Date: Tue, 13 Jul 2010 13:35:19 -0000 Hi all. The 1st version of the PCE WG agenda is available: http://www.ietf.org/proceedings/78/agenda/pce.html Comments MUST be sent to the chairs not later than next Sunday, 18th; complaints SHOULD be sent to JP, as usual. Since our meeting is on Monday, if you have a slot, your slides are expected for Thursday, 22nd (or before). Our laptops MAY be unable to support memory sticks on the meeting day... Cheers, JP & Julien From root@core3.amsl.com Wed Jul 14 11:15:01 2010 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 910DC3A696F; Wed, 14 Jul 2010 11:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100714181501.910DC3A696F@core3.amsl.com> Date: Wed, 14 Jul 2010 11:15:01 -0700 (PDT) Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-manageability-requirements-10.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: , X-List-Received-Date: Wed, 14 Jul 2010 18:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Inclusion of Manageability Sections in PCE Working Group Drafts Author(s) : A. Farrel Filename : draft-ietf-pce-manageability-requirements-10.txt Pages : 12 Date : 2010-7-14 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. The Operations Area has developed "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions" (RFC 5706), and those guidelines have been adopted by the PCE Working Group. Previously, the PCE Working Group used the recommendations contained in this document to guide authors of Internet-Drafts on the contents of "Manageability Considerations" sections in their work. This document is retained for historic reference. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-manageability-requirements-10.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-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-7-14110027.I-D@ietf.org> --NextPart-- From adrian@olddog.co.uk Thu Jul 15 08:53:20 2010 Return-Path: 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 D26D03A6B69 for ; Thu, 15 Jul 2010 08:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.299, 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 C+9-4hNEVsN9 for ; Thu, 15 Jul 2010 08:53:20 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by core3.amsl.com (Postfix) with ESMTP id A1E423A6B66 for ; Thu, 15 Jul 2010 08:53:19 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id o6FFrRe2012554 for ; Thu, 15 Jul 2010 16:53:27 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id o6FFrQxE012546 for ; Thu, 15 Jul 2010 16:53:27 +0100 Message-ID: From: "Adrian Farrel" To: Date: Thu, 15 Jul 2010 16:53:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Subject: [Pce] Fw: New Version Notification - draft-ietf-pce-manageability-requirements-10.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: , X-List-Received-Date: Thu, 15 Jul 2010 15:53:21 -0000 Hi, Minor updates after Stewart's AD review. Changes are mainly to make sure that the text is backward-looking rather than directive. Cheers, Adrian ----- Original Message ----- From: "ID Tracker" To: ; ; Sent: Wednesday, July 14, 2010 7:15 PM Subject: New Version Notification - draft-ietf-pce-manageability-requirements-10.txt > New version (-10) has been submitted for > draft-ietf-pce-manageability-requirements-10.txt. > http://www.ietf.org/internet-drafts/draft-ietf-pce-manageability-requirements-10.txt > > Sub state has been changed to AD Follow up from New Id Needed > > IETF Secretariat. > > From julien.meuric@orange-ftgroup.com Mon Jul 19 06:43:08 2010 Return-Path: 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 BCDCA3A6829 for ; Mon, 19 Jul 2010 06:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-1] 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 QZXPurikUttl for ; Mon, 19 Jul 2010 06:43:07 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id AE4E63A6813 for ; Mon, 19 Jul 2010 06:43:07 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3B985760004 for ; Mon, 19 Jul 2010 15:45:30 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 36ED2760003 for ; Mon, 19 Jul 2010 15:45:30 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Jul 2010 15:43:21 +0200 Received: from [10.193.71.77] ([10.193.71.77]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Jul 2010 15:43:21 +0200 Message-ID: <4C445679.3000404@orange-ftgroup.com> Date: Mon, 19 Jul 2010 15:43:21 +0200 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11pre) Gecko/20100626 Lightning/1.0b1 Shredder/3.0.6pre MIME-Version: 1.0 To: pce@ietf.org References: <4C3C68F4.4030409@orange-ftgroup.com> In-Reply-To: <4C3C68F4.4030409@orange-ftgroup.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 19 Jul 2010 13:43:21.0485 (UTC) FILETIME=[5A36A3D0:01CB2748] Subject: Re: [Pce] PCE Agenda in Maastricht 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: , X-List-Received-Date: Mon, 19 Jul 2010 13:43:08 -0000 Hi PCE'rs. Our agenda for the Maastricht meeting has been updated: http://www.ietf.org/proceedings/78/agenda/pce.html Presenters, do not forget to send your slide for Thursday. Thanks JP & Julien Le 13/07/2010 15:24, Julien Meuric a écrit : > Hi all. > > The 1st version of the PCE WG agenda is available: > http://www.ietf.org/proceedings/78/agenda/pce.html > > Comments MUST be sent to the chairs not later than next Sunday, 18th; > complaints SHOULD be sent to JP, as usual. > > Since our meeting is on Monday, if you have a slot, your slides are > expected for Thursday, 22nd (or before). Our laptops MAY be unable to > support memory sticks on the meeting day... > > Cheers, > > JP & Julien > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > From ramon.casellas@cttc.es Thu Jul 22 03:30:39 2010 Return-Path: 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 4DFBE3A67F0 for ; Thu, 22 Jul 2010 03:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_82=0.6] 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 byFbBXccM9OQ for ; Thu, 22 Jul 2010 03:30:37 -0700 (PDT) Received: from aquila.cttc.es (aquila.cttc.es [84.88.62.230]) by core3.amsl.com (Postfix) with ESMTP id 2CA0E3A6B1E for ; Thu, 22 Jul 2010 03:30:28 -0700 (PDT) Received: from castor (postfix@castor.cttc.es [84.88.62.196]) by aquila.cttc.es (8.14.3/8.14.3/Debian-9ubuntu1) with ESMTP id o6MATqMV003721 for ; Thu, 22 Jul 2010 12:29:52 +0200 Received: from [84.88.61.50] (pcrcasellas.cttc.es [84.88.61.50]) by castor (Postfix) with ESMTP id 003B72FC2BB for ; Thu, 22 Jul 2010 12:29:28 +0200 (CEST) Message-ID: <4C481E93.4020207@cttc.es> Date: Thu, 22 Jul 2010 12:33:55 +0200 From: Ramon Casellas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: pce@ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (castor); Thu, 22 Jul 2010 12:29:29 +0200 (CEST) X-Scanned-By: MIMEDefang 2.67 on 84.88.62.230 Subject: [Pce] Preliminary feedback on I.-D. draft-pouyllau-pce-enhanced-errors-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: , X-List-Received-Date: Thu, 22 Jul 2010 10:30:39 -0000 > We have submitted an updated version of draft http://www.ietf.org/id/draft-pouyllau-pce-enhanced-errors-02.txt > The major update is - as mentioned during IETF 77 meeting - a new section describing some potential scenarios of usages of the error and notification types specified by the draft. Dear Draft authors, all As requested, please find below some preliminary feedback on the draft. I am not aware of previous comments so apologies in advance if some of the questions I raise have been addressed. I considered that some early feedback may be appropriate in view of Maastricht, but some of the points may not be valid be due to my yet limited comprehension of the draft. Some comments also reflect my subjective views :) As a short executive summary =========================== I would agree that extending PCEP to convey error / notification processing indications (fatal, not fatal, transient, and to be forwarded) and secondarily related information (ncluding a list of potential targets) could useful but I see a few open issues in its current form, as detailed below. I also agree that the fact that different PCEs have different support for errors is a good use case for the applicability of the proposed extensions * First, is the fact that the error hierarchy type/value as found in RFC5440 and other normative documents is no longer maintained. In those aforementioned docs, the error type indicates a "family" of errors and the value is a "refinement". Instead, in the proposed I.-D. a given error type indicates a "processing indication" rather than the actual error cause, which is delegated to the only the error value itself? did I miss something? (see point in Section 4) * Second, I would think (as it seems the case in other errors) that the notion of "unrecoverable" and whether an error should cause the shutdown of the connection, is an attribute of every particular concrete error pair, and belongs to its description. For example, receiving a message with protocol version ">1" triggers an error and causes the PCEP connection to close. I would also think that closing the TCP/PCEP connection is a local decision, and I am not sure of the idea of "this is a serious error and _you_ should close the connection", rather "this is a serious error and _I_'ll be closing the connection" (on a side note, I always thought that the implication that the endpoint receiving a CLOSE message should close the connection does not prevent the PCE from closing it itself.) * Third, the DLO seems a means to indicate the set of destinations for an error/notification but raises questions on how to map data (or even control) plane resources to PCEs responsible for them and the fact that in a chain of requests, the history is lost. I still fail to see concrete cases for DLO other than ("all your other peers") which is still not clear to me and could lead to flooding and more complex procedures. In short, in my particular humble view, giving "context" to errors where "context" means "processing indications" or "destination targets" or "conveys more detailed fine grained information" could use for example TLVs rather than blocking several error types for this purpose (as an illustrating example, we often add a ASCII_TLV to PCEP_ERROR objects to add some descriptive error cause). Ideally, the actual error (x/y) should be descriptive enough to state whether a) the error needs to be forwarded as is or not b) the error should cause the connection to be shutdown and c) the error/notification could, eventually, be interpreted as a warning without implying that the request has been canceled. Detailed review ========================= Section 2.2. ---------------- * Section 2.2 is, in my opinion, a bit misleading and confusing, when discussing the dead-timer (although it does not impact the rest of the I.-D). The dead-timer is not related to the latency to get a response to a request (PCRep message), but the ability to detect a dead connection, which can be kept alive by means of KeepAlives. It is possible to have latencies in path computations higher than deadtimers, where KeepAlives are used accordingly. Thus, the text "If the PCC does not receive any reply before the dead timer is out" and the text “it supposes that the deadtimer is long enough to support end to end distributed path computation” is, imho, not right. The latency to get a Reply is implementation defined. These are two orthogonal aspects, the deadtimer is local to a given adjacency, and can be very low yet the end to end path computation be notably higher. * I would suggest changing PCEReq and PCERep by PCReq and PCRep (seems to be the common notation) * Rather than stating “there are two types of Notifications”, I would suggest “[RFC5440] defines two types of notifications”. Section 2.3 ---------------- * Also related to a bullet in Section 4, note that the RP (rplist) bound to PCEP_ERROR object is also optional, as the I-D says is the case for notifications. Section 4 ------------ * “PCE errors are always request specific”. Why are you assuming this? The RP list is optional and nothing prevents you from adding new error types and new error values for, for example, PCE status. Clearly, RFC5440 states “The PCErr message is sent…in response… or unsolicited manner” (for what is worth, the parsing and treatment of PCNtf and PCErr messages is quite similar in our case) * Minor detail: Error Types 16 / 17 are already assigned to P2MP – could be worth adding a IANA TBD * Typo: must backward -> must send backwards / forwards * One of my main concerns of using error types 16-19 is the following: in all other cases the error type conveys some kind of meaning/semantics. Error “X” means that e.g. “P2MP” has failed. Error types are a “family of errors” and error values are a “refinement”. Using OOP terms one could conceive a hierarchy with a base class, error types inheriting base class and error types/values (“concrete errors”) another refinement. In the proposed approach this is no longer the case. Personally, I would be for the idea of extending PCEP for support of “status quo” / “propagation” as proposed in the draft, but by means of TLVs. Since PCEP_ERROR objects support optional TLVs, Errors can be tagged with TLVs specifying error processing rules (which, in turn, could be applied to existing error pairs). In other words: processing indications can be conveyed by other means, while leaving error type/value pairs to indicate concrete errors (with a two level hierarchy). * If an error / notification is a "warning" and a response is still to be expected, I don't know whether an alternative means could be to extend the RBNF of PCRep to allow for such a warning to be "embedded" in the response, rather than a separate PCErr message that is sent previously. Likewise, I would think that whether the fact of sending an error or a notification "cancels" or "implies that no response is to be expected" or, on the contrary "a response is to be expected" is either a property of a concrete error or notification pair, or, in a more strict manner, PCEP mantains the motto : "a request causes a reponse or an error or a notification. The response can be positive (1+ paths) or negative(no path). An error always implies a no response (and as far as i know, also the notification bound to a RP) and warnings are embedded in the response (as when adding an object with the I flag which means "warning I was not able to take this into account". Diffusion List object (DLO) ------------------------------ The purpose of a DLO seems to be to indicate the a generic set of "destinations" for a given error / notification. I am still not sure of this (I may need more time to digest the use cases). At first sight, I would say that this is a good example of the need of generalizing the use of PCEid identifiers (using IPv4 / IPv6 addresses) that refer to PCEs regardless of their actual IP addresses (or addresses used in the actual TCP connection), playing a similar role to router addresses / node Ids/ router ids/ loopbacks, etc. A DLO could indeed be, in its simplest form, the list of PCEs to be notified (something similar to the MONITORING document). the I.-D. proposes using ERO-like objects for the DLO, which raises the questions of : a) mixes data a control plane entities and b) mapping data plane resources (e.g. an unnumbered interface ID) to the one (or more) PCEs responsible for the domain where that resource is found. Another of my main concerns is that I still fail to see the use cases where a given PCE could send an error including a DLO with a set of peers for which it has no visibility (typically, a given PCE involved in a PCE or domain chain does not have the information of the “history” of the end-to-end request. At most, one could keep the original endpoints, but that’s all. Finally, I am not sure of the procedure regarding DLO when a deployment opts for “non persistant” connections, in which the TCP/PCEP connection is closed after every request. The reception of a DLO including a peer for which there is no PCEP session in the UP state should : a) trigger the establishment of the connection for the sole purposes of forwarding an error? B) trigger an error to the peer sending the ERROR with the DLO (this imho should not be the case to avoid the error on error) How do you plan to recognize that the remote endpoint of a TCP/PCEP connection is a PCC or a PCE? (this is implied by the use of TT field in DLO). PCEP does not easily provide a means to recognize it unless somehow pre-configured. Section 5 --------------- * Section 5.1 In the description of Error Type 16, it is said that Error type 16, not critical, implies that the PCEP session needs not to be shutdown. I tend to think this is a property of every concrete error pair. Also I don’t agree with the example: a Metric with a bound value of -1 is an encoding error, it is a “contract” a PCE may not be able to fulfill (especially if processing bit is set to 1) and must trigger an error, it should not be allowed to “expect a response”. In general there are two different aspects: whether an TCP/PCEP connection must be shutdown after a given error (it is somehow related to the “severity” of the error: a malformed message, a different PCEP version, etc) and whether the error is a “warning” or not. I would agree with the extension of “warnings” meaning that the response “may follow”. I don’t agree with the example. However, warnings could also be conveyed by (yet to be defined) notifications. * Section 5.2 like mentioned before, the ability to “propagate upstream” an error is a good addition, but it may be a property of a given error (modified by policies of the PCEs in the chain) Typos ---------- * Section 2.1.1 – maybe the word “throw” is too exception-specific, I would suggest “returns” * If PCE… (unfinished sentence/typo) * … and sends back / and send back (could send back) • in details -> in detail I hope this is somehow useful, and open to discussion. Thanks for reading and best regards Ramon. -- Ramon Casellas, Ph.D. Research Associate - Optical Networking Area -- http://wikiona.cttc.es CTTC - Centre Tecnològic de Telecomunicacions de Catalunya, PMT Ed B4 Av. Carl Friedrich Gauss 7 08860 Castelldefels (Barcelona) - Spain Tel.: +34 93 645 29 16 -- Fax. +34 93 645 29 01 From wwwrun@core3.amsl.com Thu Jul 22 07:49:30 2010 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 168C73A6BBE; Thu, 22 Jul 2010 07:49:29 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20100722144930.168C73A6BBE@core3.amsl.com> Date: Thu, 22 Jul 2010 07:49:30 -0700 (PDT) Cc: pce@ietf.org Subject: [Pce] Last Call: draft-ietf-pce-manageability-requirements (Inclusion of Manageability Sections in PCE Working Group Drafts) to Historic X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 14:49:30 -0000 The IESG has received a request from the Path Computation Element WG (pce) to consider the following document: - 'Inclusion of Manageability Sections in PCE Working Group Drafts ' as a Historic 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 2010-08-05. 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-ietf-pce-manageability-requirements-10.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15619&rfc_flag=0 From jpv@cisco.com Thu Jul 22 12:34:23 2010 Return-Path: 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 89ADE3A6998 for ; Thu, 22 Jul 2010 12:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.31 X-Spam-Level: X-Spam-Status: No, score=-9.31 tagged_above=-999 required=5 tests=[AWL=-1.012, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_ONLINE=2.3, 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 q6aewi49CrPS for ; Thu, 22 Jul 2010 12:34:15 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 317953A684A for ; Thu, 22 Jul 2010 12:33:57 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFAI85SExAZnwM/2dsb2JhbACBRJ4wcadqinWQJoU2BIhZgjk Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 22 Jul 2010 19:34:13 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6MJYD8o029243 for ; Thu, 22 Jul 2010 19:34:13 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Jul 2010 21:34:13 +0200 Received: from [192.168.1.12] ([10.55.90.47]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Jul 2010 21:34:12 +0200 Message-Id: <27AD6C4B-51D4-40DD-A1C8-586A323E32EC@cisco.com> From: JP Vasseur To: pce@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-3-872342170 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 22 Jul 2010 21:34:12 +0200 References: <20100722111034.747793A6B2E@core3.amsl.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 22 Jul 2010 19:34:13.0003 (UTC) FILETIME=[DD229DB0:01CB29D4] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17522.001 X-TM-AS-Result: No--29.344700-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Subject: [Pce] Fwd: IETF 78 - Registration Cut-off 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: , X-List-Received-Date: Thu, 22 Jul 2010 19:34:23 -0000 --Apple-Mail-3-872342170 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Begin forwarded message: > From: IETF Secretariat > Date: July 22, 2010 1:10:30 PM CEDT > To: IETF Announcement list > Cc: wgchairs@ietf.org > Subject: IETF 78 - Registration Cut-off > > 78th IETF Meeting > Maastricht, Netherlands > July 25-30, 2010 > > 1. Registration: Final Pre-Registration and Pre-Payment Cut-off is > TOMORROW Friday, 1 July > 2. Social Event > > Please note: Breakfast will -NOT- be provided at the MECC (IETF > meeting > venue). Internet access is not included in the IETF hotel guest room > rates. > =================================================== > 1) Registration: Final Pre-Registration and Pre-Payment cut-off is > Friday, > 23 July 2010 at 17:00 local Maastricht time (08:00 PDT, 15:00 UTC). > Registration and payment will resume on site on Sunday 25 July 2010 at > 11:00am; your registration fee will be $785 USD. You can register on > line > at: http://www.ietf.org/meeting/78/index.html > > On site registration will be located in the Trajectum Foyer at the > MECC. > > > 2) Social Event > Social event tickets purchased on line prior to 17:00 local Maastricht > time (08:00 PDT, 15:00 UTC) Friday, 23 July 2010 will be $25.00 USD > Starting at 11:00am Sunday 25 July 2010, social event tickets > purchased on > site will be $27.50 USD for credit card payment or 25.00 Euro cash. > > Ticket sales for the social event will end at 12:00 noon on Tuesday, > 27 > July 2010. > > General Information: http://www.ietf78.nl/social-event.html > Where: On the banks of the Meuse River > Date: Tuesday 27 July 2010 > Time: 19:30 - 22:30 > Host: Ministry of Economic Affairs, the Province of Limburg and the > Municipality of Maastricht > > Maastricht, one of the Netherlands oldest and most beautiful cities, > is > the backdrop to this spectacular social event, exclusively for > visitors to > the 78th IETF meeting. It is a lighthearted break in the IETF78 > Maastricht > program - an event you do not want to miss! > > You must register for the IETF meeting before you can purchase social > event tickets. > > Only 3 days until IETF 78! > http://www.ietf.org/meeting/78/index.html > > --Apple-Mail-3-872342170 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

Begin = forwarded message:

From: = IETF Secretariat <ietf-secretariat@ietf.org>= ;
Date: July 22, 2010 1:10:30 PM = CEDT
To: IETF Announcement list <ietf-announce@ietf.org>
Subject: = IETF 78 - Registration Cut-off 

78th IETF = Meeting
Maastricht, Netherlands
July 25-30, 2010

1. = Registration: Final Pre-Registration and Pre-Payment Cut-off = is
TOMORROW Friday, 1 July
2. Social Event

Please note: = Breakfast will -NOT- be provided at the MECC (IETF meeting
venue). =  Internet access is not included in the IETF hotel guest = room
rates.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
1) Registration: Final Pre-Registration and = Pre-Payment cut-off is Friday,
23 July 2010 at 17:00 local Maastricht = time (08:00 PDT, 15:00 UTC).
Registration and payment will resume on = site on Sunday 25 July 2010 at
11:00am; your registration fee will be = $785 USD. You can register on line
at: http://www.ietf.org/mee= ting/78/index.html

On site registration will be located in = the Trajectum Foyer at the MECC.


2) Social Event
Social = event tickets purchased on line prior to 17:00 local Maastricht
time = (08:00 PDT, 15:00 UTC) Friday, 23 July 2010 will be $25.00 = USD
Starting at 11:00am Sunday 25 July 2010, social event tickets = purchased on
site will be $27.50 USD for credit card payment or 25.00 = Euro cash.

Ticket sales for the social event will end at 12:00 = noon on Tuesday, 27
July 2010.

General Information: http://www.ietf78.nl/socia= l-event.html
Where: On the banks of the Meuse River
Date: = Tuesday 27 July 2010
Time: 19:30 - 22:30
Host: Ministry of = Economic Affairs, the Province of Limburg and the
Municipality of = Maastricht

Maastricht, one of the Netherlands oldest and most = beautiful cities, is
the backdrop to this spectacular social event, = exclusively for visitors to
the 78th IETF meeting. It is a = lighthearted break in the IETF78 Maastricht
program - an event you do = not want to miss!

You must register for the IETF meeting before = you can purchase social
event tickets.

Only 3 days until IETF = 78!
http://www.ietf.org/mee= ting/78/index.html



= --Apple-Mail-3-872342170-- From helia.pouyllau@alcatel-lucent.com Fri Jul 23 04:43:13 2010 Return-Path: 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 2F6FA3A69F0 for ; Fri, 23 Jul 2010 04:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_82=0.6, 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 Ptj8UStN2zuC for ; Fri, 23 Jul 2010 04:43:11 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by core3.amsl.com (Postfix) with ESMTP id 96E0F3A6A62 for ; Fri, 23 Jul 2010 04:43:10 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o6NBhREh021606 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 23 Jul 2010 13:43:27 +0200 Received: from FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com ([135.120.45.38]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Fri, 23 Jul 2010 13:43:27 +0200 From: "POUYLLAU, HELIA (HELIA)" To: "pce@ietf.org" Date: Fri, 23 Jul 2010 13:43:26 +0200 Thread-Topic: [Pce] Preliminary feedback on I.-D. draft-pouyllau-pce-enhanced-errors-02.txt Thread-Index: AcspiQR5OGrjx8jZQXyJR9g6OYtWHAABuFFw Message-ID: <2D26984ED849C94A8C7D6276DA008FF2125CC5AD2C@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> References: <4C481E93.4020207@cttc.es> In-Reply-To: <4C481E93.4020207@cttc.es> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Subject: Re: [Pce] Preliminary feedback on I.-D. draft-pouyllau-pce-enhanced-errors-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: , X-List-Received-Date: Fri, 23 Jul 2010 11:43:13 -0000 Dear Ramon, Thank you for your feedback. I will try to comment the main points you rais= e in your mail and will study later your detailed comments: 1) If I understand well, one of your concerns is about the use of error and= notification type codes rather than TLVs. On that point you argue that in = other documents, error-type is more related to a family of errors and the v= alue to a "refinement", in the draft it is related to a kind of processing = indication. The proposal intends to allow the definition of specific errors and notific= ations but in the frame of normalized processing information. So you propos= ition about the definition of objects which could be combined in order to d= efine this specific process is inline with the I-D objectives. I see no str= ong argument against it. Flags of PCEP-ERROR and NOTIFICATION object could = also be used. Any other opinion on that point? 2) You first comment that "an error should cause the shutdown=20 of the connection, is an attribute of every particular concrete error=20 pair, and belongs to its description". In the I-D, we have indeed defined s= ome kind of "warning". Well, this is because when you read RFC5440 the fact= that an error causes the shutdown of the connection is not always mentione= d. But, as you say further, the error-type which cause the connection to cl= ose is rather an information that the connection will be closed by the PCE = which sent the error messages (see section 5.3 and 5.4 as illustrations). B= ut you are right about your comment on section 5: it is not clear whether a= "warning" should be defined as an error or a notification specific to a re= quest. Hence, we have kept both options in the I-D but it is certainly true= that maybe only one option should suffice. 3) Actually the use of the DLO is related to notification-type 5 of the I-D= (propagation of the notification) and its purpose to avoid flooding. In se= ction 4.3.2 it is explained that it must be used with this type. The use wi= th other types is optional and maybe some "SHOULD NOT" could be added for s= ome types. About you last remark on how PCC could be identified, it could b= e indeed achieved by pre-configuration. The purpose of the "not to PCC" opt= ion is to avoid flooding the routers of a routing domain - which would appe= ar in the DLO -, which have the PCC feature but not the PCE. Any other feedback on these issues and others is welcomed, Thanks again Ramon for your detailed comments, it will help to launch discu= ssions in Maastricht and to progress on the I-D. Best regards, H=E9lia -----Message d'origine----- De=A0: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] De la part de Ram= on Casellas Envoy=E9=A0: jeudi 22 juillet 2010 12:34 =C0=A0: pce@ietf.org Objet=A0: [Pce] Preliminary feedback on I.-D. draft-pouyllau-pce-enhanced-e= rrors-02.txt > We have submitted an updated version of draft=20 http://www.ietf.org/id/draft-pouyllau-pce-enhanced-errors-02.txt > The major update is - as mentioned during IETF 77 meeting - a new=20 section describing some potential scenarios of usages of the error and=20 notification types specified by the draft. Dear Draft authors, all As requested, please find below some preliminary feedback on the draft.=20 I am not aware of previous comments so apologies in advance if some of=20 the questions I raise have been addressed. I considered that some early feedback may be appropriate in view of=20 Maastricht, but some of the points may not be valid be due to my yet=20 limited comprehension of the draft. Some comments also reflect my=20 subjective views :) As a short executive summary =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D I would agree that extending PCEP to convey error / notification=20 processing indications (fatal, not fatal, transient, and to be=20 forwarded) and secondarily related information (ncluding a list of=20 potential targets) could useful but I see a few open issues in its=20 current form, as detailed below. I also agree that the fact that=20 different PCEs have different support for errors is a good use case for=20 the applicability of the proposed extensions * First, is the fact that the error hierarchy type/value as found in=20 RFC5440 and other normative documents is no longer maintained. In those=20 aforementioned docs, the error type indicates a "family" of errors and=20 the value is a "refinement". Instead, in the proposed I.-D. a given=20 error type indicates a "processing indication" rather than the actual=20 error cause, which is delegated to the only the error value itself? did=20 I miss something? (see point in Section 4) * Second, I would think (as it seems the case in other errors) that the=20 notion of "unrecoverable" and whether an error should cause the shutdown=20 of the connection, is an attribute of every particular concrete error=20 pair, and belongs to its description. For example, receiving a message=20 with protocol version ">1" triggers an error and causes the PCEP=20 connection to close. I would also think that closing the TCP/PCEP=20 connection is a local decision, and I am not sure of the idea of "this=20 is a serious error and _you_ should close the connection", rather "this=20 is a serious error and _I_'ll be closing the connection" (on a side=20 note, I always thought that the implication that the endpoint receiving=20 a CLOSE message should close the connection does not prevent the PCE=20 from closing it itself.) * Third, the DLO seems a means to indicate the set of destinations for=20 an error/notification but raises questions on how to map data (or even=20 control) plane resources to PCEs responsible for them and the fact that=20 in a chain of requests, the history is lost. I still fail to see=20 concrete cases for DLO other than ("all your other peers") which is=20 still not clear to me and could lead to flooding and more complex=20 procedures. In short, in my particular humble view, giving "context" to errors where=20 "context" means "processing indications" or "destination targets" or=20 "conveys more detailed fine grained information" could use for example=20 TLVs rather than blocking several error types for this purpose (as an=20 illustrating example, we often add a ASCII_TLV to PCEP_ERROR objects to=20 add some descriptive error cause). Ideally, the actual error (x/y)=20 should be descriptive enough to state whether a) the error needs to be=20 forwarded as is or not b) the error should cause the connection to be=20 shutdown and c) the error/notification could, eventually, be interpreted=20 as a warning without implying that the request has been canceled. Detailed review =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Section 2.2. ---------------- * Section 2.2 is, in my opinion, a bit misleading and confusing, when=20 discussing the dead-timer (although it does not impact the rest of the=20 I.-D). The dead-timer is not related to the latency to get a response to=20 a request (PCRep message), but the ability to detect a dead connection,=20 which can be kept alive by means of KeepAlives. It is possible to have=20 latencies in path computations higher than deadtimers, where KeepAlives=20 are used accordingly. Thus, the text "If the PCC does not receive any=20 reply before the dead timer is out" and the text "it supposes that the=20 deadtimer is long enough to support end to end distributed path=20 computation" is, imho, not right. The latency to get a Reply is=20 implementation defined. These are two orthogonal aspects, the deadtimer=20 is local to a given adjacency, and can be very low yet the end to end=20 path computation be notably higher. * I would suggest changing PCEReq and PCERep by PCReq and PCRep (seems=20 to be the common notation) * Rather than stating "there are two types of Notifications", I would=20 suggest "[RFC5440] defines two types of notifications". Section 2.3 ---------------- * Also related to a bullet in Section 4, note that the RP (rplist) bound=20 to PCEP_ERROR object is also optional, as the I-D says is the case for=20 notifications. Section 4 ------------ * "PCE errors are always request specific". Why are you assuming this?=20 The RP list is optional and nothing prevents you from adding new error=20 types and new error values for, for example, PCE status. Clearly,=20 RFC5440 states "The PCErr message is sent.in response. or unsolicited=20 manner" (for what is worth, the parsing and treatment of PCNtf and PCErr=20 messages is quite similar in our case) * Minor detail: Error Types 16 / 17 are already assigned to P2MP - could=20 be worth adding a IANA TBD * Typo: must backward -> must send backwards / forwards * One of my main concerns of using error types 16-19 is the following:=20 in all other cases the error type conveys some kind of=20 meaning/semantics. Error "X" means that e.g. "P2MP" has failed. Error=20 types are a "family of errors" and error values are a "refinement".=20 Using OOP terms one could conceive a hierarchy with a base class, error=20 types inheriting base class and error types/values ("concrete errors")=20 another refinement. In the proposed approach this is no longer the case.=20 Personally, I would be for the idea of extending PCEP for support of=20 "status quo" / "propagation" as proposed in the draft, but by means of=20 TLVs. Since PCEP_ERROR objects support optional TLVs, Errors can be=20 tagged with TLVs specifying error processing rules (which, in turn,=20 could be applied to existing error pairs). In other words: processing=20 indications can be conveyed by other means, while leaving error=20 type/value pairs to indicate concrete errors (with a two level hierarchy). * If an error / notification is a "warning" and a response is still to=20 be expected, I don't know whether an alternative means could be to=20 extend the RBNF of PCRep to allow for such a warning to be "embedded" in=20 the response, rather than a separate PCErr message that is sent=20 previously. Likewise, I would think that whether the fact of sending an=20 error or a notification "cancels" or "implies that no response is to be=20 expected" or, on the contrary "a response is to be expected" is either a=20 property of a concrete error or notification pair, or, in a more strict=20 manner, PCEP mantains the motto : "a request causes a reponse or an=20 error or a notification. The response can be positive (1+ paths) or=20 negative(no path). An error always implies a no response (and as far as=20 i know, also the notification bound to a RP) and warnings are embedded=20 in the response (as when adding an object with the I flag which means=20 "warning I was not able to take this into account". Diffusion List object (DLO) ------------------------------ The purpose of a DLO seems to be to indicate the a generic set of=20 "destinations" for a given error / notification. I am still not sure of=20 this (I may need more time to digest the use cases). At first sight, I=20 would say that this is a good example of the need of generalizing the=20 use of PCEid identifiers (using IPv4 / IPv6 addresses) that refer to=20 PCEs regardless of their actual IP addresses (or addresses used in the=20 actual TCP connection), playing a similar role to router addresses /=20 node Ids/ router ids/ loopbacks, etc. A DLO could indeed be, in its=20 simplest form, the list of PCEs to be notified (something similar to the=20 MONITORING document). the I.-D. proposes using ERO-like objects for the=20 DLO, which raises the questions of : a) mixes data a control plane=20 entities and b) mapping data plane resources (e.g. an unnumbered=20 interface ID) to the one (or more) PCEs responsible for the domain where=20 that resource is found. Another of my main concerns is that I still fail to see the use cases=20 where a given PCE could send an error including a DLO with a set of=20 peers for which it has no visibility (typically, a given PCE involved in=20 a PCE or domain chain does not have the information of the "history" of=20 the end-to-end request. At most, one could keep the original endpoints,=20 but that's all. Finally, I am not sure of the procedure regarding DLO when a deployment=20 opts for "non persistant" connections, in which the TCP/PCEP connection=20 is closed after every request. The reception of a DLO including a peer=20 for which there is no PCEP session in the UP state should : a) trigger=20 the establishment of the connection for the sole purposes of forwarding=20 an error? B) trigger an error to the peer sending the ERROR with the DLO=20 (this imho should not be the case to avoid the error on error) How do you plan to recognize that the remote endpoint of a TCP/PCEP=20 connection is a PCC or a PCE? (this is implied by the use of TT field in=20 DLO). PCEP does not easily provide a means to recognize it unless=20 somehow pre-configured. Section 5 --------------- * Section 5.1 In the description of Error Type 16, it is said that Error=20 type 16, not critical, implies that the PCEP session needs not to be=20 shutdown. I tend to think this is a property of every concrete error=20 pair. Also I don't agree with the example: a Metric with a bound value=20 of -1 is an encoding error, it is a "contract" a PCE may not be able to=20 fulfill (especially if processing bit is set to 1) and must trigger an=20 error, it should not be allowed to "expect a response". In general there=20 are two different aspects: whether an TCP/PCEP connection must be=20 shutdown after a given error (it is somehow related to the "severity" of=20 the error: a malformed message, a different PCEP version, etc) and=20 whether the error is a "warning" or not. I would agree with the=20 extension of "warnings" meaning that the response "may follow". I don't=20 agree with the example. However, warnings could also be conveyed by (yet=20 to be defined) notifications. * Section 5.2 like mentioned before, the ability to "propagate upstream"=20 an error is a good addition, but it may be a property of a given error=20 (modified by policies of the PCEs in the chain) Typos ---------- * Section 2.1.1 - maybe the word "throw" is too exception-specific, I=20 would suggest "returns" * If PCE. (unfinished sentence/typo) * . and sends back / and send back (could send back) . in details -> in detail I hope this is somehow useful, and open to discussion. Thanks for=20 reading and best regards Ramon. --=20 Ramon Casellas, Ph.D. Research Associate - Optical Networking Area -- http://wikiona.cttc.es CTTC - Centre Tecnol=F2gic de Telecomunicacions de Catalunya, PMT Ed B4 Av. Carl Friedrich Gauss 7 08860 Castelldefels (Barcelona) - Spain Tel.: +34 93 645 29 16 -- Fax. +34 93 645 29 01 _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From g.carrozzo@nextworks.it Sat Jul 24 04:46:41 2010 Return-Path: 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 D4D213A69B1 for ; Sat, 24 Jul 2010 04:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.119 X-Spam-Level: X-Spam-Status: No, score=-0.119 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_82=0.6] 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 Y-rTYzQ2BTVi for ; Sat, 24 Jul 2010 04:46:39 -0700 (PDT) Received: from mercurio.nextworks.it (mercurio.nextworks.it [195.250.30.136]) by core3.amsl.com (Postfix) with ESMTP id 3E2753A698C for ; Sat, 24 Jul 2010 04:46:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercurio.nextworks.it (Postfix) with ESMTP id 452F4304002 for ; Sat, 24 Jul 2010 13:47:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at nextworks.it Received: from mercurio.nextworks.it ([127.0.0.1]) by localhost (mercurio.nextworks.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpAYnB1AGeSg for ; Sat, 24 Jul 2010 13:47:26 +0200 (CEST) Received: from [1.92.119.33] (unknown [94.165.53.119]) by mercurio.nextworks.it (Postfix) with ESMTP id 1827E304001 for ; Sat, 24 Jul 2010 13:47:22 +0200 (CEST) Message-ID: <4C4AD2A4.1030404@nextworks.it> Date: Sat, 24 Jul 2010 13:46:44 +0200 From: Gino Carrozzo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.7) Gecko/20100713 Lightning/1.0b2 Thunderbird/3.1.1 MIME-Version: 1.0 To: pce@ietf.org References: <4C481E93.4020207@cttc.es> <2D26984ED849C94A8C7D6276DA008FF2125CC5AD2C@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> In-Reply-To: <2D26984ED849C94A8C7D6276DA008FF2125CC5AD2C@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Pce] Preliminary feedback on I.-D. draft-pouyllau-pce-enhanced-errors-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: , X-List-Received-Date: Sat, 24 Jul 2010 11:46:42 -0000 Dear H=E9lia, authors your proposal for augmenting processing-related informations among=20 multiple PCEs is very interesting and may help to improve the PC task in = multi-domain or hierarchical PCE contexts. However, I share Ramon's concerns about (1) the use of PCErr for sending = non-failure (processing) related notifications/warnings, and (2) the=20 mixing of data plane and PCE identifiers in DLO. Concerning PCErr semantic, I'd prefer to use processing warnings=20 conveyed in PCEP-ERROR TLVs by delegating the propagation scope of the=20 warning contents to specific flags. TLVs may also specify details on the = processing failure cause (e.g. a missing switching resource in the data=20 plane, PCE congestions, etc.) About DLO contents, I'm not so convinced about the applicability of the=20 'Unnumbered Interface ID' for notifications as in case of IRO (path=20 requests/responses). It is a topology detail, not necessarily meaningful = for all the PCEs, and its resolution would imply complex lookups in the=20 topology map for each object and for each notification. Other comments I have on the ID are briefly listed below. * In case of notification type 5 (fwd to all or a list of PCEP peers)=20 you mention a max number of PCEP peers to be notified to avoid flooding. = Due to the potential interest of all the known PCEs in that info and its = hopefully limited changing frequency, it'd be probably better to make=20 use of the IGP instead (e.g. previously used for PCE discovery). This=20 could benefit of an inherent flooding mechanism and avoid the max number = of notify recipients (who's in, who's out?). * Concerning propagation restrictions (section 4.3), may an=20 aggregation/correlation mechanisms for errors/notifications be also=20 useful/needed? It=92d be used to aggregate multiple concurrent errors and= =20 notifications reaching a PCE in the same multi-domain request context in = a given time window. * in section 2, multi-vendor and homogeneous multi-domain PCEs are=20 mentioned as possible motivation scenarios for the ID. Does =91homogeneous=92 stand here for =91the same PCE in all domains/ASes= =92? If=20 yes, may the behaviour variation in error/notification processing depend = on the different topological views by PCEs in this case? * section 2.2 seems to presents just PCEP foundations which should be=20 known to the reader through RFC5440 citation. Maybe it is redundant in=20 this ID. Hope this can help during the upcoming IETF meeting. Best regards Gino --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr. Gino Carrozzo R&D Project Manager Ph : +39 050 3871679 Fax : +39 050 3871601 e-mail : g.carrozzo@nextworks.it address: Nextworks s.r.l. via Turati, 43/45 56125 Pisa, ITALY (IT) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On 23/07/2010 13.43, POUYLLAU, HELIA (HELIA) wrote: > Dear Ramon, > > Thank you for your feedback. I will try to comment the main points you = raise in your mail and will study later your detailed comments: > > 1) If I understand well, one of your concerns is about the use of error= and notification type codes rather than TLVs. On that point you argue tha= t in other documents, error-type is more related to a family of errors an= d the value to a "refinement", in the draft it is related to a kind of pr= ocessing indication. > > The proposal intends to allow the definition of specific errors and not= ifications but in the frame of normalized processing information. So you = proposition about the definition of objects which could be combined in or= der to define this specific process is inline with the I-D objectives. I = see no strong argument against it. Flags of PCEP-ERROR and NOTIFICATION o= bject could also be used. > > Any other opinion on that point? > > 2) You first comment that "an error should cause the shutdown > of the connection, is an attribute of every particular concrete error > pair, and belongs to its description". In the I-D, we have indeed defin= ed some kind of "warning". Well, this is because when you read RFC5440 th= e fact that an error causes the shutdown of the connection is not always = mentioned. But, as you say further, the error-type which cause the connec= tion to close is rather an information that the connection will be closed= by the PCE which sent the error messages (see section 5.3 and 5.4 as illu= strations). But you are right about your comment on section 5: it is notc= lear whether a "warning" should be defined as an error or a notification = specific to a request. Hence, we have kept both options in the I-D but it= is certainly true that maybe only one option should suffice. > > 3) Actually the use of the DLO is related to notification-type 5 of the= I-D (propagation of the notification) and its purpose to avoid flooding.I= n section 4.3.2 it is explained that it must be used with this type. The = use with other types is optional and maybe some "SHOULD NOT" could be add= ed for some types. About you last remark on how PCC could be identified, = it could be indeed achieved by pre-configuration. The purpose of the "not= to PCC" option is to avoid flooding the routers of a routing domain - wh= ich would appear in the DLO -, which have the PCC feature but not the PCE= =2E > > > Any other feedback on these issues and others is welcomed, > > Thanks again Ramon for your detailed comments, it will help to launch d= iscussions in Maastricht and to progress on the I-D. > > Best regards, > H=E9lia > > -----Message d'origine----- > De : pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] De la part de R= amon Casellas > Envoy=E9 : jeudi 22 juillet 2010 12:34 > =C0 : pce@ietf.org > Objet : [Pce] Preliminary feedback on I.-D. draft-pouyllau-pce-enhanced= -errors-02.txt > > > We have submitted an updated version of draft > http://www.ietf.org/id/draft-pouyllau-pce-enhanced-errors-02.txt > > The major update is - as mentioned during IETF 77 meeting - a new > section describing some potential scenarios of usages of the error and > notification types specified by the draft. > > Dear Draft authors, all > > As requested, please find below some preliminary feedback on the draft.= > I am not aware of previous comments so apologies in advance if some of > the questions I raise have been addressed. > I considered that some early feedback may be appropriate in view of > Maastricht, but some of the points may not be valid be due to my yet > limited comprehension of the draft. Some comments also reflect my > subjective views :) > > > As a short executive summary > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > > I would agree that extending PCEP to convey error / notification > processing indications (fatal, not fatal, transient, and to be > forwarded) and secondarily related information (ncluding a list of > potential targets) could useful but I see a few open issues in its > current form, as detailed below. I also agree that the fact that > different PCEs have different support for errors is a good use case for= > the applicability of the proposed extensions > > * First, is the fact that the error hierarchy type/value as found in > RFC5440 and other normative documents is no longer maintained. In those= > aforementioned docs, the error type indicates a "family" of errors and > the value is a "refinement". Instead, in the proposed I.-D. a given > error type indicates a "processing indication" rather than the actual > error cause, which is delegated to the only the error value itself? did= > I miss something? (see point in Section 4) > > * Second, I would think (as it seems the case in other errors) that the= > notion of "unrecoverable" and whether an error should cause the shutdow= n > of the connection, is an attribute of every particular concrete error > pair, and belongs to its description. For example, receiving a message > with protocol version ">1" triggers an error and causes the PCEP > connection to close. I would also think that closing the TCP/PCEP > connection is a local decision, and I am not sure of the idea of "this > is a serious error and _you_ should close the connection", rather "this= > is a serious error and _I_'ll be closing the connection" (on a side > note, I always thought that the implication that the endpoint receiving= > a CLOSE message should close the connection does not prevent the PCE > from closing it itself.) > > * Third, the DLO seems a means to indicate the set of destinations for > an error/notification but raises questions on how to map data (or even > control) plane resources to PCEs responsible for them and the fact that= > in a chain of requests, the history is lost. I still fail to see > concrete cases for DLO other than ("all your other peers") which is > still not clear to me and could lead to flooding and more complex > procedures. > > In short, in my particular humble view, giving "context" to errors wher= e > "context" means "processing indications" or "destination targets" or > "conveys more detailed fine grained information" could use for example > TLVs rather than blocking several error types for this purpose (as an > illustrating example, we often add a ASCII_TLV to PCEP_ERROR objects to= > add some descriptive error cause). Ideally, the actual error (x/y) > should be descriptive enough to state whether a) the error needs to be > forwarded as is or not b) the error should cause the connection to be > shutdown and c) the error/notification could, eventually, be interprete= d > as a warning without implying that the request has been canceled. > > > > Detailed review > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > > Section 2.2. > ---------------- > * Section 2.2 is, in my opinion, a bit misleading and confusing, when > discussing the dead-timer (although it does not impact the rest of the > I.-D). The dead-timer is not related to the latency to get a response t= o > a request (PCRep message), but the ability to detect a dead connection,= > which can be kept alive by means of KeepAlives. It is possible to have > latencies in path computations higher than deadtimers, where KeepAlives= > are used accordingly. Thus, the text "If the PCC does not receive any > reply before the dead timer is out" and the text "it supposes that the > deadtimer is long enough to support end to end distributed path > computation" is, imho, not right. The latency to get a Reply is > implementation defined. These are two orthogonal aspects, the deadtimer= > is local to a given adjacency, and can be very low yet the end to end > path computation be notably higher. > > * I would suggest changing PCEReq and PCERep by PCReq and PCRep (seems > to be the common notation) > > * Rather than stating "there are two types of Notifications", I would > suggest "[RFC5440] defines two types of notifications". > > Section 2.3 > ---------------- > > * Also related to a bullet in Section 4, note that the RP (rplist) boun= d > to PCEP_ERROR object is also optional, as the I-D says is the case for > notifications. > > Section 4 > ------------ > * "PCE errors are always request specific". Why are you assuming this? > The RP list is optional and nothing prevents you from adding new error > types and new error values for, for example, PCE status. Clearly, > RFC5440 states "The PCErr message is sent.in response. or unsolicited > manner" (for what is worth, the parsing and treatment of PCNtf and PCEr= r > messages is quite similar in our case) > > * Minor detail: Error Types 16 / 17 are already assigned to P2MP - coul= d > be worth adding a IANA TBD > > * Typo: must backward -> must send backwards / forwards > > * One of my main concerns of using error types 16-19 is the following: > in all other cases the error type conveys some kind of > meaning/semantics. Error "X" means that e.g. "P2MP" has failed. Error > types are a "family of errors" and error values are a "refinement". > Using OOP terms one could conceive a hierarchy with a base class, error= > types inheriting base class and error types/values ("concrete errors") > another refinement. In the proposed approach this is no longer the case= =2E > Personally, I would be for the idea of extending PCEP for support of > "status quo" / "propagation" as proposed in the draft, but by means of > TLVs. Since PCEP_ERROR objects support optional TLVs, Errors can be > tagged with TLVs specifying error processing rules (which, in turn, > could be applied to existing error pairs). In other words: processing > indications can be conveyed by other means, while leaving error > type/value pairs to indicate concrete errors (with a two level hierarch= y). > > * If an error / notification is a "warning" and a response is still to > be expected, I don't know whether an alternative means could be to > extend the RBNF of PCRep to allow for such a warning to be "embedded" i= n > the response, rather than a separate PCErr message that is sent > previously. Likewise, I would think that whether the fact of sending an= > error or a notification "cancels" or "implies that no response is to be= > expected" or, on the contrary "a response is to be expected" is either = a > property of a concrete error or notification pair, or, in a more strict= > manner, PCEP mantains the motto : "a request causes a reponse or an > error or a notification. The response can be positive (1+ paths) or > negative(no path). An error always implies a no response (and as far as= > i know, also the notification bound to a RP) and warnings are embedded > in the response (as when adding an object with the I flag which means > "warning I was not able to take this into account". > > > Diffusion List object (DLO) > ------------------------------ > > The purpose of a DLO seems to be to indicate the a generic set of > "destinations" for a given error / notification. I am still not sure of= > this (I may need more time to digest the use cases). At first sight, I > would say that this is a good example of the need of generalizing the > use of PCEid identifiers (using IPv4 / IPv6 addresses) that refer to > PCEs regardless of their actual IP addresses (or addresses used in the > actual TCP connection), playing a similar role to router addresses / > node Ids/ router ids/ loopbacks, etc. A DLO could indeed be, in its > simplest form, the list of PCEs to be notified (something similar to th= e > MONITORING document). the I.-D. proposes using ERO-like objects for the= > DLO, which raises the questions of : a) mixes data a control plane > entities and b) mapping data plane resources (e.g. an unnumbered > interface ID) to the one (or more) PCEs responsible for the domain wher= e > that resource is found. > > Another of my main concerns is that I still fail to see the use cases > where a given PCE could send an error including a DLO with a set of > peers for which it has no visibility (typically, a given PCE involved i= n > a PCE or domain chain does not have the information of the "history" of= > the end-to-end request. At most, one could keep the original endpoints,= > but that's all. > > Finally, I am not sure of the procedure regarding DLO when a deployment= > opts for "non persistant" connections, in which the TCP/PCEP connection= > is closed after every request. The reception of a DLO including a peer > for which there is no PCEP session in the UP state should : a) trigger > the establishment of the connection for the sole purposes of forwarding= > an error? B) trigger an error to the peer sending the ERROR with the DL= O > (this imho should not be the case to avoid the error on error) > > How do you plan to recognize that the remote endpoint of a TCP/PCEP > connection is a PCC or a PCE? (this is implied by the use of TT field i= n > DLO). PCEP does not easily provide a means to recognize it unless > somehow pre-configured. > > > Section 5 > --------------- > > * Section 5.1 In the description of Error Type 16, it is said that Erro= r > type 16, not critical, implies that the PCEP session needs not to be > shutdown. I tend to think this is a property of every concrete error > pair. Also I don't agree with the example: a Metric with a bound value > of -1 is an encoding error, it is a "contract" a PCE may not be able to= > fulfill (especially if processing bit is set to 1) and must trigger an > error, it should not be allowed to "expect a response". In general ther= e > are two different aspects: whether an TCP/PCEP connection must be > shutdown after a given error (it is somehow related to the "severity" o= f > the error: a malformed message, a different PCEP version, etc) and > whether the error is a "warning" or not. I would agree with the > extension of "warnings" meaning that the response "may follow". I don't= > agree with the example. However, warnings could also be conveyed by (ye= t > to be defined) notifications. > > * Section 5.2 like mentioned before, the ability to "propagate upstream= " > an error is a good addition, but it may be a property of a given error > (modified by policies of the PCEs in the chain) > > > Typos > ---------- > * Section 2.1.1 - maybe the word "throw" is too exception-specific, I > would suggest "returns" > > * If PCE. (unfinished sentence/typo) > > * . and sends back / and send back (could send back) > > . in details -> in detail > > > > I hope this is somehow useful, and open to discussion. Thanks for > reading and best regards > > Ramon. > > > From ramon.casellas@cttc.es Sun Jul 25 11:40:02 2010 Return-Path: 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 40DDD3A6947 for ; Sun, 25 Jul 2010 11:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[AWL=1.600, 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 KrSLOmOrP1Ge for ; Sun, 25 Jul 2010 11:40:00 -0700 (PDT) Received: from aries.cttc.es (aries.cttc.es [84.88.62.194]) by core3.amsl.com (Postfix) with ESMTP id D6E103A68B7 for ; Sun, 25 Jul 2010 11:39:59 -0700 (PDT) Received: from webmail.cttc.es (web.cttc.es [84.88.62.199]) (authenticated bits=0) by aries.cttc.es (8.13.8/8.13.8) with ESMTP id o6PIbq66020067 for ; Sun, 25 Jul 2010 20:37:53 +0200 Received: from 62.83.140.132 (SquirrelMail authenticated user rcasellas) by webmail.cttc.es with HTTP; Sun, 25 Jul 2010 20:42:35 +0200 (CEST) Message-ID: <33931.62.83.140.132.1280083355.squirrel@webmail.cttc.es> In-Reply-To: References: Date: Sun, 25 Jul 2010 20:42:35 +0200 (CEST) From: "Ramon Casellas" To: pce@ietf.org User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: [Pce] Preliminary feedback on draft-pouyllau-pce-enhanced-errors-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: , X-List-Received-Date: Sun, 25 Jul 2010 18:40:02 -0000 Hélia, all, Thank you for your comments, please see inline. > Message: 2 > Date: Fri, 23 Jul 2010 13:43:26 +0200 > From: "POUYLLAU, HELIA (HELIA)" > Subject: Re: [Pce] Preliminary feedback on I.-D. > draft-pouyllau-pce-enhanced-errors-02.txt > > 1) If I understand well, one of your concerns is about the use of error > and notification type codes rather than TLVs. On that point you argue that > in other documents, error-type is more related to a family of errors and > the value to a "refinement", in the draft it is related to a kind of > processing indication. Correct. I would have a (weak) personal preference for a method that extends errors and notifications by means of e.g. flags or TLVs so that: a) it could be applied to existing errors; b) it does not imply that, for an error whose intended treatment/process could be mapped to one of your scenarios must have a given error type (e.g. 16,17,18) and c) it still leaves 8+8 (hierarchical) error encoding space > The proposal intends to allow the definition of specific errors and > notifications but in the frame of normalized processing information. So > you proposition about the definition of objects which could be combined in > order to define this specific process is inline with the I-D objectives. I > see no strong argument against it. Flags of PCEP-ERROR and NOTIFICATION > object could also be used. Fair enough; maybe a potential issue with current approach is that if someone extends PCEP for some function, it may not be easy to define error conditions, and whether to map those to the error types in your I-D or to request the allocation of new ones. I had not thought of flags as you mention which also seems an interesting idea. > 2) You first comment that "an error should cause the shutdown > of the connection, is an attribute of every particular concrete error > pair, and belongs to its description". In the I-D, we have indeed defined I may have not expressed myself well, but just in case, I did not imply that all errors should cause the shutdown :) but *if* a given normative document specifies that a given error is severe enough (e.g. to force a shutdown) this should be mentioned in the description and related procedures, rather than because it's an error type X (to avoid, for example, the ambiguity of other errors that also would require a connection shutdown which are not of type X). As mentioned, this is personal preference too. Do we really need a way (whatever encoding) to indicate "this error is bad enough that it forces the connection to be shutdown" (by any of the peers)? maybe not. > some kind of "warning". Well, this is because when you read RFC5440 the > fact that an error causes the shutdown of the connection is not always > mentioned. But, as you say further, the error-type which cause the In line with the above, I always interpreted that the shutdown is only "mandatory" (for some definition of mandatory) if the the RFC specifies it. > as illustrations). But you are right about your comment on section 5: it > is not clear whether a "warning" should be defined as an error or a > notification specific to a request. Hence, we have kept both options in > the I-D but it is certainly true that maybe only one option should > suffice. This comment was raised thinking of a possible implementation. A given PCC may have a per-PCE-peer backlog where requests are stored when sent, e.g. in a hashed map requestid->request, with a timer to re-send the request or to send it to another PCE, etc. Upon reception of a response (path/nopath), or an error, the "request" is considered answered, the timer stopped and the request is removed from the backlog. This is a well defined criterion that seems to hold until now for most wg docs, afaik. If we allow that, from now on, the reception on an error no longer implies this and that a "response" (positive/negative) may come later, this is no longer true. Maybe not a big concern, but still one :) I would (also again personal preference) rather suggest e.g. a new message or, if needed, only the usage of notifications to indicate "transient", "warnings" or "in the meantime" messages. > > 3) Actually the use of the DLO is related to notification-type 5 of the > I-D (propagation of the notification) and its purpose to avoid flooding. > In section 4.3.2 it is explained that it must be used with this type. The > use with other types is optional and maybe some "SHOULD NOT" could be > added for some types. About you last remark on how PCC could be > identified, it could be indeed achieved by pre-configuration. The purpose > of the "not to PCC" option is to avoid flooding the routers of a routing > domain - which would appear in the DLO -, which have the PCC feature but > not the PCE. This is clearer now, indeed. Although I still need to think about it a bit more, in order to identify particular scenarios. In my humble view, most use cases seem to reduce to either I) this is an error whose scope is 'this specific PCEP adjacency' defined by the PCE originating the error and the peer or II) this is an error that should be forwarded "up the chain" towards the original requester (even without knowing which they are). Possibly, other use cases could be identified, but it seems to me like a mechanism to (multi)cast a given PCE message to a set of targets, probably related to a RP object that may not be known to all destinations. It's like using a "mesh" of adjacencies to announce something. Any example of use cases would be appreciated, and how they complement e.g. using the IGP. Thank you for your clarifications and consideration Best regards, Ramon From root@core3.amsl.com Mon Jul 26 05:15:02 2010 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 13BC83A6BAE; Mon, 26 Jul 2010 05:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100726121502.13BC83A6BAE@core3.amsl.com> Date: Mon, 26 Jul 2010 05:15:02 -0700 (PDT) Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-inter-layer-ext-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: , X-List-Received-Date: Mon, 26 Jul 2010 12:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Extensions to the Path Computation Element communication Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering Author(s) : E. Oki, T. Takeda, J. Le Roux, A. Farrel Filename : draft-ietf-pce-inter-layer-ext-04.txt Pages : 15 Date : 2010-7-26 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-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-inter-layer-ext-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-7-26051350.I-D@ietf.org> --NextPart-- From kkoushik@cisco.com Mon Jul 26 09:48:12 2010 Return-Path: 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 8F8543A67B6 for ; Mon, 26 Jul 2010 09:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWbf-Ynm9Bpo for ; Mon, 26 Jul 2010 09:48:11 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id BD69C3A6816 for ; Mon, 26 Jul 2010 09:48:10 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAFpZTUxAZnwM/2dsb2JhbACBRIcqhleQG3Gocppxgm6CSASIZII6 X-IronPort-AV: E=Sophos;i="4.55,262,1278288000"; d="scan'208,217";a="139303606" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 26 Jul 2010 16:48:31 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6QGmUrj027589; Mon, 26 Jul 2010 16:48:31 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Jul 2010 18:48:30 +0200 Received: from kkoushikwxp02 ([10.61.107.184]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Jul 2010 18:48:30 +0200 Message-ID: <136601cb2ce2$60ceaea0$88bf6540@cisco.com> From: "Agrahara S Kiran Koushik" To: "Simon Wingrove" , References: <11DE3EEC54A8A44EAD99D8C0D3FD72079A3804A703@ENFIMBOX1.ad.datcon.co.uk> Date: Mon, 26 Jul 2010 18:48:30 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1361_01CB2CF3.2446B5C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3664 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3664 X-OriginalArrivalTime: 26 Jul 2010 16:48:30.0712 (UTC) FILETIME=[60B86780:01CB2CE2] Subject: Re: [Pce] Concerns with PCE MIB Drafts 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: , X-List-Received-Date: Mon, 26 Jul 2010 16:48:12 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_1361_01CB2CF3.2446B5C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Simon, Thanks for the review and comments. We will try to address most of these in our next revision. Thanks Kiran.=20 ----- Original Message -----=20 From: Simon Wingrove=20 To: pce@ietf.org=20 Sent: Tuesday, July 06, 2010 6:44 PM Subject: [Pce] Concerns with PCE MIB Drafts Hi all, I've been examining the MIB drafts currently in the PCE WG and have a = few concerns on some specific parts (see below). I'm hoping to get some = feedback from the WG on these. Best wishes, Simon Wingrove Network Technologies Division Metaswitch Networks=20 simon.wingrove@metaswitch.com www.metaswitch.com Concerns: (C1) PcePcepIdentifier is an LDP identifier The PcePcepIdentifier object is used as the index for a PCE peer, and = is described with the text "The LDP identifier is a six octet quantity = which is used to identify a PCE client." I think an IP address should = be used instead. - The PCEP Peer MIB table uses this object as the index for peers, = but where would the ID have been learnt from? - The PCE discovery protocol identifies a PCE purely by IP address: = this seems to be an easier way to identify a PCC/PCE throughout the = MIBs. (C2) There is no PCEP MIB for a PCE, only a PCC The PCEP MIB seems to concern a PCEP implementation for a PCC. We = need a MIB table for a PCEP implementation for a PCE. I believe that = the original intention of the pcePcepClientTable was to serve both roles = (see http://www.ietf.org/proceedings/73/slides/pce-9/pce-9.htm). Is = this the case? - If so, I think that we should clarify this in the table's = description. - Indeed if this is the case, I'm not sure why the table is so named. = Perhaps pcePcepEntityTable or pcePcepSpeakerTable would be more = suitable; do people agree? (C3) Use of IP Addresses on the MIB The PCE Discovery MIB table provides two objects to describe the IP = addresses of a PCE, pceDiscoveryIPv4Address and pceDiscoveryIPv6Address. = I suggest that this should be represented by two MIB objects = pceDiscoveryIPAddressType and pceDiscoveryIPAddress instead. - Since the PCE discovery RFC (4674) identifies a PCE purely by IP = address, a discovered PCE will only ever have exactly one address, = either IPv4 or IPv6, never both. - There are examples of this way of representing IP addresses in the = MGMD MIB, RFC 5519. (C4) Stats in the PCEP Session MIB Table do not persist The PCEP MIB contains session information in pcePcepSessionTable. I = think this information should belong on the peer table instead. - My understanding is that an entry in this table exists when a = session to a peer exists. - However, this table contains stats objects such as = pcePcepSesssionCorruptedMsgs, the number of corrupted messages received = during session. - I think that this information would be helpful to a MIB user after = the session has ended, and the table entry gone away. (C5) Gauges and Counters The stats fields pceDiscoveryKnownPCEs and pceDiscoveryActivePCEs are = of type Counter32, but should be of type Gauge32. Counters should = increase, never decrease, and are allowed to wrap (see RFC 2578, = sections 7.1.6-7). A Gauge is more appropriate for a statistic that can = increase or decrease. -------------------------------------------------------------------------= ----- _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce ------=_NextPart_000_1361_01CB2CF3.2446B5C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Simon,
Thanks for the review and comments. We = will try to=20 address
most of these in our next = revision.
 
Thanks
Kiran.
----- Original Message -----
From:=20 Simon Wingrove =
Sent: Tuesday, July 06, 2010 = 6:44=20 PM
Subject: [Pce] Concerns with = PCE MIB=20 Drafts

Hi all,
 
I=92ve been examining the MIB drafts currently in the PCE WG and = have a few=20 concerns on some specific parts (see below).  I=92m hoping to get = some=20 feedback from the WG on these.
 
Best wishes,
Simon = Wingrove
Network=20 Technologies Division
Metaswitch=20 Networks
 
Concerns:
 
(C1) PcePcepIdentifier is an LDP=20 identifier
The PcePcepIdentifier=20 object is used as the index for a PCE peer, and is described with the = text=20 "The LDP identifier is a six octet quantity which is used to identify = a PCE=20 client."  I think an IP address should be used instead.
-  The PCEP Peer MIB table uses this object as the index for = peers,=20 but where would the ID have been learnt from?
-  The PCE discovery protocol identifies a PCE purely by IP = address:=20 this seems to be an easier way to identify a PCC/PCE throughout the=20 MIBs.
 
(C2)  There is no PCEP MIB for a PCE, only a = PCC
The PCEP MIB seems to concern a PCEP implementation for a = PCC.  We=20 need a MIB table for a PCEP implementation for a PCE.  I believe = that the=20 original intention of the pcePcepClientTable was to serve = both=20 roles (see http://www.ietf.org/proceedings/73/slides/pce-9/pce-9.= htm). =20 Is this the case?
-  If so, I think that we should clarify this in the = table=92s=20 description.
-  Indeed if this is the case, I=92m not sure why the table = is so=20 named.  Perhaps pcePcepEntityTable or pcePcepSpeakerTable would be = more=20 suitable; do people agree?
 
(C3)  Use of IP Addresses on the MIB
The PCE Discovery MIB table provides two objects to describe the = IP=20 addresses of a PCE, pceDiscoveryIPv4Address and = pceDiscoveryIPv6Address.  = I suggest=20 that this should be represented by two MIB objects pceDiscoveryIPAddressType and = pceDiscoveryIPAddress=20 instead.
-  Since the PCE discovery RFC (4674) identifies a PCE purely by IP = address, a=20 discovered PCE will only ever have exactly one address, either IPv4 or = IPv6,=20 never both.
-  There are examples of this way of representing IP = addresses in=20 the MGMD MIB, RFC 5519.
 
(C4)  Stats in the PCEP Session MIB Table do not=20 persist
The PCEP MIB contains session information in pcePcepSessionTable.  I = think this=20 information should belong on the peer table instead.
-  My understanding is that an entry in this table exists = when a=20 session to a peer exists.
-  However, this table contains stats objects such as pcePcepSesssionCorruptedMsgs, = the number=20 of corrupted messages received during session.
-  I think that this information would be helpful to a MIB = user=20 after the session has ended, and the table entry gone away.
 
(C5) = Gauges and=20 Counters
The stats fields pceDiscoveryKnownPCEs and pceDiscoveryActivePCEs are of = type=20 Counter32, but should be of type Gauge32.  Counters should = increase,=20 never decrease, and are allowed to wrap (see RFC 2578, sections 7.1.6-7).  A = Gauge is more=20 appropriate for a statistic that can increase or decrease.
 
 

_______________________________________________
Pce mailing=20 = list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
------=_NextPart_000_1361_01CB2CF3.2446B5C0-- From Attila.Takacs@ericsson.com Thu Jul 29 05:20:31 2010 Return-Path: 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 3189F28C150 for ; Thu, 29 Jul 2010 05:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 8oQHTYgYy6gR for ; Thu, 29 Jul 2010 05:20:30 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 9FD7E28C1E0 for ; Thu, 29 Jul 2010 05:20:29 -0700 (PDT) X-AuditID: c1b4fb39-b7b91ae000001aef-41-4c5172244ab4 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 34.E2.06895.422715C4; Thu, 29 Jul 2010 14:20:52 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.86) by esessmw0197.eemea.ericsson.se (153.88.115.87) with Microsoft SMTP Server (TLS) id 8.2.234.1; Thu, 29 Jul 2010 14:20:51 +0200 Received: from ESESSCMS0365.eemea.ericsson.se ([169.254.1.174]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Thu, 29 Jul 2010 14:20:37 +0200 From: Attila Takacs To: "POUYLLAU, HELIA (HELIA)" , "pce@ietf.org" Date: Thu, 29 Jul 2010 14:20:36 +0200 Thread-Topic: I-D Update draft-pouyllau-pce-enhanced-errors-02 Thread-Index: AcsgB2xmJIWhR6sMR+W84ngr5UaSUABzsQAAA0/30nA= Message-ID: <6477E10CC7D76444A479B9AC31F262A90100DC76@ESESSCMS0365.eemea.ericsson.se> References: <188B2A67-12D2-4D73-BA07-CA876ECC6774@cisco.com> <2D26984ED849C94A8C7D6276DA008FF2125C43D150@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> In-Reply-To: <2D26984ED849C94A8C7D6276DA008FF2125C43D150@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [Pce] I-D Update draft-pouyllau-pce-enhanced-errors-02 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: , X-List-Received-Date: Thu, 29 Jul 2010 12:20:31 -0000 Hi Helia, As far as I understood there are two main points in the id 1) clarifying er= ror and notification usage and 2) allowing remote (non direct peer PCEs) to= send errors/notifications to the originating PCC. I have no feelings about 1), it might be needed if the description in 5440 = is indeed unclear or if additional details on processing would clarify proc= edures of 5440.=20 On the other hand, 2) is a bit confusing to me. If I remember correctly a P= CC will not know about other PCEs involved in the path computation except i= ts direct peer PCE. So I do not see a reason why a remote PCE should be abl= e to force PCC's peer PCE to forward any error/notification information. To= me its seems that error/notification propagation is a local matter of the = direct peer PCE since that is handling the request and it is the only PCE t= hat the PCC has a relation with for a particular request. Do I miss somethi= ng? Thanks, Attila=20 > -----Original Message----- > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On=20 > Behalf Of POUYLLAU, HELIA (HELIA) > Sent: Monday, July 12, 2010 5:36 PM > To: pce@ietf.org > Subject: [Pce] I-D Update draft-pouyllau-pce-enhanced-errors-02 >=20 >=20 > Hi all, >=20 > We have submitted an updated version of draft=20 > http://www.ietf.org/id/draft-pouyllau-pce-enhanced-errors-02.txt >=20 > The major update is - as mentioned during IETF 77 meeting - a=20 > new section describing some potential scenarios of usages of=20 > the error and notification types specified by the draft.=20 >=20 > Before detailing further these scenarios, we would like to=20 > have feedback from the mailing-list. Obviously, feedback on=20 > other sections is also welcomed. >=20 > Best regards > H=E9lia Pouyllau >=20 > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > = From meral.shirazipour@polymtl.ca Thu Jul 29 10:57:53 2010 Return-Path: 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 D9D763A682F for ; Thu, 29 Jul 2010 10:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 JSwHH2Bn5t1e for ; Thu, 29 Jul 2010 10:57:52 -0700 (PDT) Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by core3.amsl.com (Postfix) with ESMTP id 80F703A6768 for ; Thu, 29 Jul 2010 10:57:52 -0700 (PDT) Received: from localhost (imp-4-3.polymtl.ca [132.207.4.78]) by smtp.polymtl.ca (8.14.3/8.14.3) with ESMTP id o6THwDRW032155; Thu, 29 Jul 2010 13:58:14 -0400 Received: from lmcprb.ericsson.ca (lmcprb.ericsson.ca [192.75.88.232]) by www.imp.polymtl.ca (IMP) with HTTP for ; Thu, 29 Jul 2010 13:58:12 -0400 Message-ID: <1280426292.4c51c1348e532@www.imp.polymtl.ca> Date: Thu, 29 Jul 2010 13:58:12 -0400 From: Meral Shirazipour To: "POUYLLAU, HELIA (HELIA)" References: <188B2A67-12D2-4D73-BA07-CA876ECC6774@cisco.com> <2D26984ED849C94A8C7D6276DA008FF2125C43D150@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> In-Reply-To: <2D26984ED849C94A8C7D6276DA008FF2125C43D150@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.3 X-Originating-IP: 192.75.88.232 X-Poly-FromMTA: (imp-4-3.polymtl.ca [132.207.4.78]) at Thu, 29 Jul 2010 17:58:13 +0000 Cc: "pce@ietf.org" Subject: Re: [Pce] I-D Update draft-pouyllau-pce-enhanced-errors-02 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: , X-List-Received-Date: Thu, 29 Jul 2010 17:57:54 -0000 Hi, I have a few comments about errors and notifications specific to a given (or a set of) path request(s) : I believe any error, related to a specific path request that caused the failure in finding a path should be returned in the PCRep message's NO-PATH object, and not as a separate PCErr. Moreover, any information that should be conveyed but that did not cause the failure of a request should be sent as a PCNtf message and not a PCErr message. I explain: First in section 5.3. Error-type 18 Usage: -------------------------------------------- the example given is an IRO which can not be satisfied by the next PCE. As per RFC5440 section 7.5, such information may already be carried in the PCRep's NO-PATH object: Recall RFC5440 section 7.5:"the NO-PATH object MAY contain an optional NO-PATH-VECTOR TLV defined below and used to provide more information on the reasons that led to a negative reply." Then in section 5.4 Error-type 19 Usage: -------------------------------------------- the example is "the next PCE in the path computation chain is no more active, and thus the PCC is notified." I believe in this case too as per RFC5440, the NO-PATH object should carry the information. **Moreover, I also think this specific failure information should reach the PCC only IF the PCC specifically requested the failed PCE to be in the PCE sequence. Now that begs the question of needing some sort of policy to control the reach of the Error and Notification messages.** The rest of the examples describe cases where a path is found but with minor modifications to the constraints. For these, the draft's proposition is correct since RFC5440 only allows information to be added to the PCRep message IF it caused the failure of the request (i.e. NO-PATH): -LSPA (LSP Attributes) object can be included in the PCRep message only if it caused an unsuccessful path computation,(recall the LSPA object is used to indicate the set of constraints that could not be satisfied) -NO-PATH Object, NO-PATH-VECTOR TLV applies only to an unsuccessful path computation Thus, the draft is completely correct in conveying this type of information in a separate message since the information DID not cause the failure of the request. However, I suggest conveying such information in a notification message (PCNtf) and not an Error message (PCErr) as proposed. I would thus reconsider the examples in: 5.1. Error-type 16 Usage --------------------------- "..a PCE receiving a request does not understand a parameter value...This error is not critical.." and 5.2. Error-type 17 Usage ------------------------- "..a parameter is not supported by one of the PCE ...this error is not critical" and send the information in a notification messages (PCNtf). Regards, Meral PS: some more comments are on the way Quoting "POUYLLAU, HELIA (HELIA)" : > > Hi all, > > We have submitted an updated version of draft > http://www.ietf.org/id/draft-pouyllau-pce-enhanced-errors-02.txt > > The major update is - as mentioned during IETF 77 meeting - a new section > describing some potential scenarios of usages of the error and notification > types specified by the draft. > > Before detailing further these scenarios, we would like to have feedback from > the mailing-list. Obviously, feedback on other sections is also welcomed. > > Best regards > Hélia Pouyllau > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > >