From daniel@olddog.co.uk Thu Mar 1 09:37:59 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0850F21E80D0 for ; Thu, 1 Mar 2012 09:37:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fupv1HHGynsN for ; Thu, 1 Mar 2012 09:37:58 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 396DB21E80BC for ; Thu, 1 Mar 2012 09:37:57 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q21HbsTc003042; Thu, 1 Mar 2012 17:37:54 GMT Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q21Hbp7w002997; Thu, 1 Mar 2012 17:37:53 GMT From: "Daniel King" To: Date: Thu, 1 Mar 2012 17:37:45 -0000 Message-ID: <014401ccf7d2$047d5fe0$0d781fa0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-language: en-gb Thread-index: Acz30cd/wuVB0F2vQi+cYhgVGb4v0w== Cc: jpv@cisco.com Subject: [Pce] PCE Agenda Requests for IETF83 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 17:37:59 -0000 Hi All, IETF 83 is rapidly approaching so it's time to create the PCE agenda. If you would like to request a slot for the PCE working group session please email me (CC'ing our Chairs) with the topic/draft name and the amount of time you would like. Please let us have your requests no later than Tuesday, March 13th. Key cut-off dates: http://www.ietf.org/meeting/cutoff-dates-2012.html#IETF83 2012-03-05 (Monday): Internet Draft Cut-off for initial document (-00) 2012-03-12 (Monday): Internet Draft final submission (>00) Draft Agenda (subject to change - final agenda to be posted on 2012-03-02): http://datatracker.ietf.org/meeting/83/agenda.txt Br, Dan. From g.carrozzo@nextworks.it Sun Mar 4 00:21:41 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4032421F8571 for ; Sun, 4 Mar 2012 00:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id siURrSxZpjYm for ; Sun, 4 Mar 2012 00:21:40 -0800 (PST) Received: from mercurio.nextworks.it (mercurio.nextworks.it [213.182.68.141]) by ietfa.amsl.com (Postfix) with SMTP id 11ECC21F8574 for ; Sun, 4 Mar 2012 00:21:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercurio.nextworks.it (Postfix) with ESMTP id 4E49C304006 for ; Sun, 4 Mar 2012 09:21:53 +0100 (CET) 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 6p7kDvefOoiz for ; Sun, 4 Mar 2012 09:21:41 +0100 (CET) Received: from [127.0.0.1] (unknown [94.167.21.77]) by mercurio.nextworks.it (Postfix) with ESMTP id 9CBE5304004 for ; Sun, 4 Mar 2012 09:21:40 +0100 (CET) Message-ID: <4F532621.6070601@nextworks.it> Date: Sun, 04 Mar 2012 09:21:53 +0100 From: Gino Carrozzo User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: pce@ietf.org References: <20120304080654.9554.1053.idtracker@ietfa.amsl.com> In-Reply-To: <20120304080654.9554.1053.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Pce] I-D Action: draft-carrozzo-pce-pcep-route-price-00.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2012 08:21:41 -0000 Dear all we've just posted a new I-D about extending PCEP with a new route information, the price. As explained in the I-D, the route price is an additional info with respect to the route cost(s) currently well covered by existing PCE RFCs And this extension seems to us quite useful in those scenarios where a Service Plane interfaces to PCE for elaborating its route offers. Your feedbacks and comments would be very much appreciated. br Gino On 04/03/2012 9.06, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : PCEP extensions for the computation of route offers with price > Author(s) : Gino Carrozzo > Giacomo Bernini > Giada Landi > Filename : draft-carrozzo-pce-pcep-route-price-00.txt > Pages : 17 > Date : 2012-03-04 > > The PCE defined in RFC4655 is a functional entity generally confined > in the control plane to elaborate explicit optimal routes with > related costs to be installed as [G]MPLS tunnels/LSPs. The resulting > route cost(s)/metric(s) are Traffic Engineering indicators used by > the network administrator (carrier) to optimize the usage of its > network resources. > > In this document a framework for the usage of PCE in cooperation with > the Network Service and Business Plane (NSBP) is proposed, along with > related PCEP extensions. The NSBP invokes this extended PCE (service > PCE) to trigger the computation of network service offers with > related price information. The price of a network connectivity > service generally depends on strategic factors, but it could also be > influenced by the amount of mobilized network resources (along the > route), the ingress/egress interfaces/PoPs, etc. Therefore, it could > be provided by an extended service-PCE as an additional route > information. > > This document focuses on the extensions to the PCEP protocol in > support of the computation of route prices for intra- and inter- > domain network connectivity services. Mechanisms for elaborating and > retrieving price information in the PCE are vendor-specific and out > of the scope of this document. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-carrozzo-pce-pcep-route-price-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-carrozzo-pce-pcep-route-price-00.txt > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From ietf-ipr@ietf.org Fri Mar 2 14:30:27 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FFF321E8065; Fri, 2 Mar 2012 14:30:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.43 X-Spam-Level: X-Spam-Status: No, score=-102.43 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1HqYZ3y1HrY; Fri, 2 Mar 2012 14:30:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F16821F8496; Fri, 2 Mar 2012 14:30:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: zali@cisco.com, daniel@olddog.co.uk, fabien. verhaeghe@gmail.com, takeda.tomonori@lab.ntt.co.jp, julien.meuric@orange-ftgroup.com, qzhao@huawei.com X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120302223026.3919.38370.idtracker@ietfa.amsl.com> Date: Fri, 02 Mar 2012 14:30:26 -0800 X-Mailman-Approved-At: Mon, 05 Mar 2012 05:45:29 -0800 Cc: jpv@cisco.com, pce@ietf.org, ipr-announce@ietf.org Subject: [Pce] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to RFC 6006 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 22:30:27 -0000 Dear Zafar Ali, Daniel King, Fabien Verhaeghe, Tomonori Takeda, Julien Meur= ic, Quintin Zhao: An IPR disclosure that pertains to your RFC entitled "Extensions to the Pa= th Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths" (RFC6006) was submitted to the IE= TF Secretariat on 2012-02-24 and has been posted on the "IETF Page of Intellec= tual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1686/). The = title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to RFC 6006.""); The IETF Secretariat From zhang.xian@huawei.com Mon Mar 5 16:50:18 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64DD221E8017 for ; Mon, 5 Mar 2012 16:50:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.783 X-Spam-Level: X-Spam-Status: No, score=-7.783 tagged_above=-999 required=5 tests=[AWL=-1.184, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Q+JkaUeyB0R for ; Mon, 5 Mar 2012 16:50:17 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id D4F6121E800E for ; Mon, 5 Mar 2012 16:50:09 -0800 (PST) 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 <0M0F00MVCUBETA@szxga05-in.huawei.com> for pce@ietf.org; Tue, 06 Mar 2012 08:50:02 +0800 (CST) Received: from szxrg01-dlp.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 <0M0F00DGHUBEAT@szxga05-in.huawei.com> for pce@ietf.org; Tue, 06 Mar 2012 08:50:02 +0800 (CST) Received: from szxeml210-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHG25880; Tue, 06 Mar 2012 08:50:02 +0800 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by szxeml210-edg.china.huawei.com (172.24.2.183) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 06 Mar 2012 08:49:32 +0800 Received: from SZXEML535-MBX.china.huawei.com ([169.254.3.159]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.01.0323.003; Tue, 06 Mar 2012 08:49:56 +0800 Date: Tue, 06 Mar 2012 00:49:55 +0000 From: "Xian Zhang (Xian)" In-reply-to: <20120305070740.12221.2017.idtracker@ietfa.amsl.com> X-Originating-IP: [10.70.76.149] To: "pce@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: New Version Notification for draft-zhang-pce-stateful-pce-app-00.txt Thread-index: AQHM+p6ubtZJ0uXRnEGIO6apEK4KGpZbSQiA X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20120305070740.12221.2017.idtracker@ietfa.amsl.com> Subject: [Pce] FW: New Version Notification for draft-zhang-pce-stateful-pce-app-00.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 00:50:18 -0000 Dear PCErs, We have submitted a new draft entitled " Applicability of Stateful Path Computation Element (PCE)", and it is available at http://tools.ietf.org/id/draft-zhang-pce-stateful-pce-app-00.txt. Your comments/suggestions are welcome. Regards, Xian ------- A new version of I-D, draft-zhang-pce-stateful-pce-app-00.txt has been successfully submitted by Xian Zhang and posted to the IETF repository. Filename: draft-zhang-pce-stateful-pce-app Revision: 00 Title: Applicability of Stateful Path Computation Element (PCE) Creation date: 2012-03-05 WG ID: Individual Submission Number of pages: 20 Abstract: The Path Computation Element (PCE) provides a solution for Traffic Engineering (TE) based path calculation in large, multi-domain, multi-region, or multi-layer networks. Depending on whether a PCE keeps information about LSPs and reserved resource usage in the network or not, it can be categorized as either stateful or stateless. This memo describes general considerations for stateful PCE(s) and examines its applicability through a number of typical scenarios. It shows how stateful PCE(s) can be applied to facilitate these applications. The IETF Secretariat From zhangfatai@huawei.com Thu Mar 8 17:35:54 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2A611E8072 for ; Thu, 8 Mar 2012 17:35:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.452 X-Spam-Level: X-Spam-Status: No, score=-5.452 tagged_above=-999 required=5 tests=[AWL=1.146, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UqMls0D1z0Kp for ; Thu, 8 Mar 2012 17:35:53 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id B9CD611E8076 for ; Thu, 8 Mar 2012 17:35:52 -0800 (PST) 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 <0M0L0027CGFQIE@szxga05-in.huawei.com> for pce@ietf.org; Fri, 09 Mar 2012 09:35:50 +0800 (CST) Received: from szxrg01-dlp.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 <0M0L0035TGFQG5@szxga05-in.huawei.com> for pce@ietf.org; Fri, 09 Mar 2012 09:35:50 +0800 (CST) Received: from szxeml211-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHI54201; Fri, 09 Mar 2012 09:35:48 +0800 Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by szxeml211-edg.china.huawei.com (172.24.2.182) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 09 Mar 2012 09:35:04 +0800 Received: from SZXEML520-MBS.china.huawei.com ([169.254.2.227]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.003; Fri, 09 Mar 2012 09:35:44 +0800 Date: Fri, 09 Mar 2012 01:35:43 +0000 From: Zhangfatai X-Originating-IP: [10.70.76.157] To: "pce@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_fs+aQG0G+FGHvtVHnTOStw)" Content-language: en-US Accept-Language: zh-CN, en-US Thread-topic: Status summary for three WG drafts Thread-index: Acz9lPEMQlK2L3LbQaKO0vL80gV2ag== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Cc: JP Vasseur Subject: [Pce] Status summary for three WG drafts X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 01:35:54 -0000 --Boundary_(ID_fs+aQG0G+FGHvtVHnTOStw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi all, For these updates, I notified these updates on the mailing list a few months ago. These drafts have been stable for quite long time and the authors think they are ready for LC. Per Chairs' suggestion, I would like to summarize the updates of the following three WG drafts to collect feedback. Any comments and suggestions are welcome. (1) draft-ietf-pce-vendor-constraints-05.txt A VENDOR-CONSTRAINT TLV was introduced based on Cyril's comment and I had off-line discuss with Cyril for this update. (2) draft-ietf-pce-inter-layer-ext-06.txt Refined some sentences in Section 3.2 to clarify the dependency between SWITCH-LAYER object and INTER-LAYER object based on Cyril's and Oscar's comment. (3) draft-ietf-pce-gmpls-aps-req-05.txt Just refined some editorial wording and re-organized the references, ie., no new requirements have been introduced. Thanks Fatai --Boundary_(ID_fs+aQG0G+FGHvtVHnTOStw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi all,

 

For these updates, I notified these updates on the mailing list a few months ago.

 

These drafts have been stable for quite long time and the authors think they are ready for LC.

 

Per Chairs’ suggestion, I would like to summarize the updates of the following three WG drafts to collect feedback.

 

Any comments and suggestions are welcome.

 

(1) draft-ietf-pce-vendor-constraints-05.txt

 

  A VENDOR-CONSTRAINT TLV was introduced based on Cyril’s comment and I had off-line discuss with Cyril for this update.

 

(2) draft-ietf-pce-inter-layer-ext-06.txt

 

Refined some sentences in Section 3.2 to clarify the dependency between SWITCH-LAYER object and INTER-LAYER object based on Cyril’s and Oscar’s comment.

 

(3) draft-ietf-pce-gmpls-aps-req-05.txt

 

Just refined some editorial wording and re-organized the references, ie., no new requirements have been introduced.

 

 

 

 

 

Thanks
 
Fatai

 

--Boundary_(ID_fs+aQG0G+FGHvtVHnTOStw)-- From internet-drafts@ietf.org Fri Mar 9 04:46:26 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBB7F21F864F; Fri, 9 Mar 2012 04:46:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.508 X-Spam-Level: X-Spam-Status: No, score=-102.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+autAyDEg9W; Fri, 9 Mar 2012 04:46:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4763321F8576; Fri, 9 Mar 2012 04:46:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120309124626.1587.89447.idtracker@ietfa.amsl.com> Date: Fri, 09 Mar 2012 04:46:26 -0800 Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-gmpls-pcep-extensions-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 12:46:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Path Computation Element Working Grou= p of the IETF. Title : PCEP extensions for GMPLS Author(s) : Cyril Margaria Oscar Gonzalez de Dios Fatai Zhang Filename : draft-ietf-pce-gmpls-pcep-extensions-05.txt Pages : 41 Date : 2012-03-09 This memo provides extensions for the Path Computation Element communication Protocol (PCEP) for the support of GMPLS control plane. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-gmpls-pcep-extensions-05= .txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pce-gmpls-pcep-extensions-05.= txt From cyril.margaria@nsn.com Fri Mar 9 04:54:41 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB0621F85DA for ; Fri, 9 Mar 2012 04:54:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1JqiNpGQoRb for ; Fri, 9 Mar 2012 04:54:41 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 9B11921F84D6 for ; Fri, 9 Mar 2012 04:54:40 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q29Csdqj032566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 9 Mar 2012 13:54:39 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q29CsWUO001565 for ; Fri, 9 Mar 2012 13:54:39 +0100 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Mar 2012 13:54:37 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Mar 2012 13:54:36 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New version of draft-ietf-pce-gmpls-pcep-extensions (05) Thread-Index: Acz988h3EyVQ9yfFTaGZaTYf7tUwEg== From: "Margaria, Cyril (NSN - DE/Munich)" To: X-OriginalArrivalTime: 09 Mar 2012 12:54:37.0845 (UTC) FILETIME=[C906D450:01CCFDF3] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1520 X-purgate-ID: 151667::1331297679-000033AC-80DC21DE/0-0/0-0 Subject: [Pce] New version of draft-ietf-pce-gmpls-pcep-extensions (05) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 12:54:41 -0000 Hi PCEers,=20 A new version of draft-ietf-pce-gmpls-pcep-extensions (version -05) was = published = (http://tools.ietf.org/html/draft-ietf-pce-gmpls-pcep-extensions-05)=20 The changes address the comments raised. This revision remove LABEL_SET object in PCEP request and response, = introduces Labels subobject in IRO and XRO object and finaly allows for = reoptimization request to specify the existing label on the endpoints. I would like to solicit your input on the document and its changes. Your review and comments are greatly appreciated. =20 Mit freundlichen Gr=FC=DFen / Best Regards Cyril Margaria Nokia Siemens Networks GmbH & Co. KG NWS DWDM RD St.Martin-Str. 76 D-81541 M=FCnchen Germany mailto:cyril.margaria@nsn.com Phone: +49-89-5159-16934 Fax: +49-89-5159-44-16934 ---------------------------------------------------------------- Nokia Siemens Networks GmbH & Co. KG=20 Sitz der Gesellschaft: M=FCnchen / Registered office: Munich=20 Registergericht: M=FCnchen / Commercial registry: Munich, HRA 88537=20 WEEE-Reg.-Nr.: DE 52984304=20 Pers=F6nlich haftende Gesellschafterin / General Partner: Nokia Siemens = Networks Management GmbH=20 Gesch=E4ftsleitung / Board of Directors: Dr. Hermann Rodler, Lydia = Sommer, Olaf Horsthemke=20 Vorsitzender des Aufsichtsrats / Chairman of supervisory board: Herbert = Merz=20 Sitz der Gesellschaft: M=FCnchen / Registered office: Munich=20 Registergericht: M=FCnchen / Commercial registry: Munich, HRB 163416=20 From internet-drafts@ietf.org Sun Mar 11 12:42:11 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F97E21F86F4; Sun, 11 Mar 2012 12:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OautG-wAl6F6; Sun, 11 Mar 2012 12:42:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A176421F85F9; Sun, 11 Mar 2012 12:42:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120311194210.20634.98242.idtracker@ietfa.amsl.com> Date: Sun, 11 Mar 2012 12:42:10 -0700 Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-hierarchy-fwk-01.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 19:42:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Path Computation Element Working Grou= p of the IETF. Title : The Application of the Path Computation Element Architec= ture to the Determination of a Sequence of Domains in MPLS and GMPLS Author(s) : Daniel King Adrian Farrel Filename : draft-ietf-pce-hierarchy-fwk-01.txt Pages : 31 Date : 2012-03-11 Computing optimum routes for Label Switched Paths (LSPs) across multiple domains in MPLS Traffic Engineering (MPLS-TE) and 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 through the use of a hierarchical relationship between domains. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-hierarchy-fwk-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pce-hierarchy-fwk-01.txt From daniel@olddog.co.uk Sun Mar 11 12:51:12 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49E9A21F872E for ; Sun, 11 Mar 2012 12:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5L2Lg3fDaHlM for ; Sun, 11 Mar 2012 12:51:11 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 514CF21F873A for ; Sun, 11 Mar 2012 12:51:11 -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 q2BJp7Bc022523 for ; Sun, 11 Mar 2012 19:51:07 GMT 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 q2BJp640022517 for ; Sun, 11 Mar 2012 19:51:06 GMT From: "Daniel King" To: Date: Sun, 11 Mar 2012 19:51:05 -0000 Message-ID: <001501ccffc0$4bfdf500$e3f9df00$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Acz/v1FZOvzGZQ2ZSi26JvVN6R1W5w== Content-Language: en-gb Subject: Re: [Pce] draft-ietf-pce-hierarchy-fwk-01.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 19:51:12 -0000 Hi PCE'rs, Please find a new version of our H-PCE architecture draft. In summary the new version has the following updates: - A few changes mainly for typos and readability. - A short section discussing the applicability of BGP-TE. - Completely updated Security Considerations. We have no plans to present this work in Paris, but we would be happy to have discussions, especially with the H-PCE solution authors. We now consider this to be the "final" version of the document and unless we see discussion on or off the list that requires updates, we will ask the chairs to take the I-D to WG last call shortly after Paris. See you in Paris! 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: 11 March 2012 19:42 To: i-d-announce@ietf.org Cc: pce@ietf.org Subject: I-D Action: draft-ietf-pce-hierarchy-fwk-01.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 : The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS Author(s) : Daniel King Adrian Farrel Filename : draft-ietf-pce-hierarchy-fwk-01.txt Pages : 31 Date : 2012-03-11 Computing optimum routes for Label Switched Paths (LSPs) across multiple domains in MPLS Traffic Engineering (MPLS-TE) and 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 through the use of a hierarchical relationship between domains. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-hierarchy-fwk-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pce-hierarchy-fwk-01.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From ogondio@tid.es Mon Mar 12 01:48:01 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB37821F870A for ; Mon, 12 Mar 2012 01:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4xCtMAXEsPB for ; Mon, 12 Mar 2012 01:48:00 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 5F68921F86EF for ; Mon, 12 Mar 2012 01:48:00 -0700 (PDT) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0R009E8KFY44@tid.hi.inet> for pce@ietf.org; Mon, 12 Mar 2012 09:47:58 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id B7.E9.02643.E38BD5F4; Mon, 12 Mar 2012 09:47:58 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0M0R009E5KFY44@tid.hi.inet> for pce@ietf.org; Mon, 12 Mar 2012 09:47:58 +0100 (MET) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad2.hi.inet ([192.168.0.2]) with mapi; Mon, 12 Mar 2012 09:47:58 +0100 Date: Mon, 12 Mar 2012 09:47:57 +0100 From: =?utf-8?B?T3NjYXIgR29uesOhbGV6IGRlIERpb3M=?= To: "pce@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: es-ES Content-transfer-encoding: base64 Accept-Language: es-ES, en-US Thread-topic: New Version of draft-gonzalezdedios-pce-reservation-state-01 Thread-index: Ac0ALMY5KhVvn50xTm2QLMRrusji6Q== acceptlanguage: es-ES, en-US X-AuditID: 0a5f4e69-b7f6b6d000000a53-f8-4f5db83e1c69 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDIsWRmVeSWpSXmKPExsXCFe9nqGu3I9bfYM1vPYum+zfYHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8e7+W5aCA/wVn4/uZWlg7OHvYuTkkBAwkTi5/AE7hC0mceHe erYuRi4OIYFtjBLnt/cwQzjfGCW2dX9hhXAaGSWmt90Ha2ERUJVYPnM6M4jNJuAs8eBYEyOI LSzgKrHr+VImEFtEQFHi+43VbCA2r4CnxO6/HVC2oMSPyfdYuhg5OJgF1CWmTMkFCTMLiEvM +TWRFcJWlJi2qAFsJKOArMTK86cZIUZ6SSxdepodwtaTmLlmCxtEjYzE/+V7WSC+EZBYsuc8 M4QtKvHy8T/WCYwis5BsnoWweRaSzbOQbF7AyLKKUaw4qSgzPaMkNzEzJ93ASC8jUy8zL7Vk EyMk+DN3MC7fqXKIUYCDUYmHN8Myyl+INbGsuDL3EKMkB5OSKG/N9lh/Ib6k/JTKjMTijPii 0pzU4kOMEhzMSiK8WbOBcrwpiZVVqUX5MCkZDg4lCd6zIG2CRanpqRVpmTnAGIdJM3FwgrTz ALU/2wbSXlyQmFucmQ6RP8WoyjHh49pLjEIsefl5qVLivJtBBgmAFGWU5sHNecUoDnSwMO88 kCwPMEnBTXgFNJwJaPhnrmiQ4SWJCCmpBsZZb1YlujsuL1/4+ETNl5dCmvbfps+/tEAqa8OS k2sUjtfv/i8rsUfha1NfbKZhwIyAuUcUKv8xv7KtrzhwZfayF99+rH6xbt36Hz9XvWuU1JB8 t6Njx2LRryambM9Lnx6+sCvzvLLgidgj7U8EZB4Vf7ta1zd7YfuteUlMt/9mxtSeM5lpaj7X VImlOCPRUIu5qDgRAJmR8+MPAwAA Subject: [Pce] New Version of draft-gonzalezdedios-pce-reservation-state-01 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 08:48:02 -0000 RGVhciBQQ0VycywNCg0KICAgICAgICBXZSBoYXZlIHVwZGF0ZWQgYW5kIHN1Ym1pdHRlZCBhIG5l dyB2ZXJzaW9uIG9mIFBDRVAgRXh0ZW5zaW9ucyBmb3IgVGVtcG9yYXJ5IFJlc2VydmF0aW9uIG9m IENvbXB1dGVkIFBhdGggUmVzb3VyY2VzIGFuZCBTdXBwb3J0IGZvciBMaW1pdGVkIENvbnRleHQg U3RhdGUgaW4gUENFLCB0cnlpbmcgdG8gYWRkcmVzcyB0aGUgY29tbWVudHMgcmVjZWl2ZWQgaW4g dGhlIGxhc3QgSUVURiBtZWV0aW5ncyBhbmQgaW4gb25nb2luZyBkaXNjdXNzaW9ucy4NCg0KICAg ICAgICBUaGUgbWFpbiBjaGFuZ2VzIGluIHRoZSBkb2N1bWVudCBhcmUgY2xhcmlmeWluZyB0aGUg YXBwbGljYWJpbGl0eSBvZiB0aGUgVGVtcG9yYXJ5IFJlc2VydmF0aW9uIGFuZCBhIGFkZCBvbmdv aW5nIGRpc2N1c3Npb25zIGluIHRoZSBzb2x1dGlvbi4gU3VtbWluZyB1cDoNCg0KICAgICAgICAt IENsYXJpZnkgd2hhdCBoYXBwZW5zIHdoZW4gVEVEIGlzIHVwZGF0ZWQgYnkgaXRzIG5vcm1hbCBw cm9jZWR1cmUgYW5kIGRpc3Rpbmd1aXNoIGFtb25nIHR3byBjYXNlcywgb25lIHdoZXJlIHRoZSBy ZXNlcnZlZCByZXNvdXJjZSBpcyB1bmlxdWVseSBpZGVudGlmaWVkIGluIHRoZSAgdG9wb2xvZ3kg dXBkYXRlLCBhbmQgb3RoZXIgd2hlcmUgaXQgY2Fubm90IGJlIHVuaXF1ZWx5IGlkZW50aWZpZWQu DQogICAgICAgIC0gRWRpdG9yJ3Mgbm90ZTogUXVlc3Rpb24gdGhlIG5lZWQgb2Ygc2VuZGluZyBQ Q0MtSUQtUkVRDQogICAgICAgIC0gRWRpdG9yJ3Mgbm90ZTogUXVlc3Rpb24gdGhlIG5lZWQgb2Yg aGF2aW5nIGEgZGlmZmVyZW50IG9iamVjdCBmb3IgdGhlIHJlc2VydmF0aW9uIHJlc3BvbnNlLg0K DQogICAgICAgIFBsZWFzZSBjb25zaWRlciB0YWtpbmcgYSBsb29rIGF0IHRoZSBkb2N1bWVudCBh bmQgZ2l2aW5nIHVzIGZlZWRiYWNrLg0KDQogICAgICAgIFlvdSBjYW4gZmluZCB0aGUgZG9jdW1l bnQgaW46IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdvbnphbGV6ZGVkaW9zLXBj ZS1yZXNlcnZhdGlvbi1zdGF0ZS0wMQ0KDQogICAgICAgIEJlc3QgUmVnYXJkcywNCg0KICAgICAg ICAgICAgICAgIMOTc2Nhcg0KDQoNCg0KRXN0ZSBtZW5zYWplIHNlIGRpcmlnZSBleGNsdXNpdmFt ZW50ZSBhIHN1IGRlc3RpbmF0YXJpby4gUHVlZGUgY29uc3VsdGFyIG51ZXN0cmEgcG9sw610aWNh IGRlIGVudsOtbyB5IHJlY2VwY2nDs24gZGUgY29ycmVvIGVsZWN0csOzbmljbyBlbiBlbCBlbmxh Y2Ugc2l0dWFkbyBtw6FzIGFiYWpvLg0KVGhpcyBtZXNzYWdlIGlzIGludGVuZGVkIGV4Y2x1c2l2 ZWx5IGZvciBpdHMgYWRkcmVzc2VlLiBXZSBvbmx5IHNlbmQgYW5kIHJlY2VpdmUgZW1haWwgb24g dGhlIGJhc2lzIG9mIHRoZSB0ZXJtcyBzZXQgb3V0IGF0DQpodHRwOi8vd3d3LnRpZC5lcy9FUy9Q QUdJTkFTL2Rpc2NsYWltZXIuYXNweA0K From leeyoung@huawei.com Mon Mar 12 08:55:52 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E41BA21E804C for ; Mon, 12 Mar 2012 08:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8A-+iwjsYrcE for ; Mon, 12 Mar 2012 08:55:51 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id F056921F8714 for ; Mon, 12 Mar 2012 08:55:50 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEA14780; Mon, 12 Mar 2012 11:55:50 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 12 Mar 2012 08:54:06 -0700 Received: from dfweml511-mbx.china.huawei.com ([169.254.16.249]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Mon, 12 Mar 2012 08:53:57 -0700 From: Leeyoung To: "pce@ietf.org" Thread-Topic: new draft Thread-Index: Ac0AaFTyiUse7+iKQwK896fOea9bbg== Date: Mon, 12 Mar 2012 15:53:56 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1720C82C7F@dfweml511-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.150.200] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1720C82C7Fdfweml511mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: LUIS MIGUEL CONTRERAS MURILLO Subject: [Pce] new draft X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 15:55:52 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E1720C82C7Fdfweml511mbxchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi PCErs, We have published a new draft that discusses how Stateful PCE can be used i= n the data center networking environments in the spirit of cooperative comp= utation across network and application. http://datatracker.ietf.org/doc/draft-dhody-pce-cso-enabled-path-computatio= n/ Thanks for posting your comments and suggestion. Best Regards, Young --_000_7AEB3D6833318045B4AE71C2C87E8E1720C82C7Fdfweml511mbxchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi PCErs,

 

We have published a new draft that discusses how Sta= teful PCE can be used in the data center networking environments in the spi= rit of cooperative computation across network and application.

 

http://datatracker.ietf.org/doc/draft= -dhody-pce-cso-enabled-path-computation/

 

Thanks for posting your comments and suggestion.

 

Best Regards,

Young

--_000_7AEB3D6833318045B4AE71C2C87E8E1720C82C7Fdfweml511mbxchi_-- From olivier.dugeon@orange.com Mon Mar 12 11:03:50 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A010721F8970 for ; Mon, 12 Mar 2012 11:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.022 X-Spam-Level: X-Spam-Status: No, score=-6.022 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B08iz+rrrj2M for ; Mon, 12 Mar 2012 11:03:50 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id B378521F8888 for ; Mon, 12 Mar 2012 11:03:40 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 717C25D897F for ; Mon, 12 Mar 2012 19:03:39 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 69B9B5D897E for ; Mon, 12 Mar 2012 19:03:39 +0100 (CET) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Mar 2012 19:03:39 +0100 Received: from [10.193.11.220] ([10.193.11.220]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Mar 2012 19:03:39 +0100 Message-ID: <4F5E3A7A.5010006@orange.com> Date: Mon, 12 Mar 2012 19:03:38 +0100 From: Olivier Dugeon Organization: Orange Labs User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "pce@ietf.org" References: <20120312174859.23725.27786.idtracker@ietfa.amsl.com> In-Reply-To: <20120312174859.23725.27786.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 12 Mar 2012 18:03:39.0231 (UTC) FILETIME=[73CB0EF0:01CD007A] Subject: Re: [Pce] New Version Notification for draft-dugeon-pce-ted-reqs-01.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 18:03:50 -0000 Dear all, We've just posted a new I-D about TED requirements for the PCE. As explained in the I-D, we aim at identify the specific information to=20 be stored in the TED and how it may be populated. We skip the 00 version due to lack of time. You could find the I-D as usual place here:=20 http://www.ietf.org/id/draft-dugeon-pce-ted-reqs-01.txt Your feedbacks and comments would be very much appreciated. Best Regards, Olivier et al. Le 12/03/2012 18:48, internet-drafts@ietf.org a =C3=A9crit : > A new version of I-D, draft-dugeon-pce-ted-reqs-01.txt has been success= fully submitted by Olivier Dugeon and posted to the IETF repository. > > Filename: draft-dugeon-pce-ted-reqs > Revision: 01 > Title: Path Computation Element (PCE) Traffic Engineering Database (T= ED) Requirements > Creation date: 2012-03-09 > WG ID: Individual Submission > Number of pages: 12 > > Abstract: > The Path Computation Element (PCE) working group (WG) has produced = a > set of RFCs to standardize the behavior of the Path Computation > Element as a tool to help MPLS-TE and GMPLS LSP tunnels placement. > In the PCE architecture, a main assumption has been done concerning= > the information that the PCE needs to perform its computation: the > Traffic Engineering Database (TED) contains all pertinent and > suitable information regarding the network that is in the scope of = a > PCE. Nevertheless, the TED requirements as well as the TED > information have not yet been formalized. In addition, some recent= > RFC (like the Backward Recursive Path Computation procedure) or WG > draft (like draft-ietf-pce-hierarchy ...) suffer from a lack of > information in the TED, leading to a non optimal result or to some > difficulties to deploy them. This memo tries to identity some TED > requirements for the PCE. It is split in two main section: the > identification of the specific information to be stored in the TED > and how it may be populated. > > > > > > The IETF Secretariat -- ** Olivier Dugeon From zhang.fei3@zte.com.cn Thu Mar 22 02:08:27 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B97E521F85BD; Thu, 22 Mar 2012 02:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.485 X-Spam-Level: X-Spam-Status: No, score=-97.485 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DH27tnoUndUe; Thu, 22 Mar 2012 02:08:26 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 9C53121F85EF; Thu, 22 Mar 2012 02:08:25 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 523733280467362; Thu, 22 Mar 2012 17:00:21 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 84000.4959434983; Thu, 22 Mar 2012 17:08:14 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q2M988NQ027359; Thu, 22 Mar 2012 17:08:08 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: <4F532621.6070601@nextworks.it> To: Gino Carrozzo MIME-Version: 1.0 X-KeepSent: 9E1BB3D4:2DE91195-482579C9:002F6494; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Thu, 22 Mar 2012 17:08:04 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-03-22 17:08:10, Serialize complete at 2012-03-22 17:08:10 Content-Type: multipart/alternative; boundary="=_alternative 00322C54482579C9_=" X-MAIL: mse01.zte.com.cn q2M988NQ027359 Cc: pce-bounces@ietf.org, pce@ietf.org Subject: Re: [Pce] I-D Action: draft-carrozzo-pce-pcep-route-price-00.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 09:08:27 -0000 This is a multipart message in MIME format. --=_alternative 00322C54482579C9_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgR2lubw0KDQpBbiBpbnRlcmVzdGluZyBpZGVhLg0KDQpJZiBteSB1bmRlcnN0YW5kaW5nIGlz IG5vdCB3cm9uZywgdGhlIGRyYWZ0IGRlc2NyaWJlcyB0aGUgYXJjaGl0ZWN0dXJlIGFuZCANClBD RVAgZXh0ZW5zaW9ucyB0aGF0IHRoZSBOU0JQIChQQ0MpIHNlbmRzIG91dCB0aGUgcm91dGUgb2Zm ZXIgY29tcHV0YXRpb24gDQpyZXF1ZXN0IHRvIFNlcnZpY2UtUENFLg0KDQpTaW5jZSB0aGF0IHRo ZSBOTVMgKFBDQykgc2VuZHMgb3V0IHRoZSBQQ1JlcSBtZXNzYWdlcyB0byBQQ0UgaXMgZGVzY3Jp YmVkIA0KaW4gUkZDNDY1NSwgV2hhdCB0aGUgcHJvY2VkdXJlIGxvb2tzIGxpa2UgaWYgTk1TIGlz IGFsc28gaW52b2x2ZWQ/IG9yIE5NUyANCndpbGwgbm90IGFwcGVhciB3aGVuIHRoZSByb3V0ZSBv ZmZlciBjb21wdXRhdGlvbiBpcyBhZG9wdGVkPyANCg0KU29ycnkgdGhhdCBJIGFtIG5vdCBmYW1p bGFyIHdpdGggdGhlIFRNRiBJUFNQSEVSRSBGcmFtZXdvcmssIGhvcGUgeW91ciANCmNsYXJpZmlj YXRpb24uDQoNClJlZ2FyZHMNCg0KRmVpDQoNCg0KDQpHaW5vIENhcnJvenpvIDxnLmNhcnJvenpv QG5leHR3b3Jrcy5pdD4gDQq3orz+yMs6ICBwY2UtYm91bmNlc0BpZXRmLm9yZw0KMjAxMi0wMy0w NCAxNjoyMQ0KDQrK1bz+yMsNCnBjZUBpZXRmLm9yZw0Ks63LzQ0KDQrW98ziDQpSZTogW1BjZV0g SS1EIEFjdGlvbjogZHJhZnQtY2Fycm96em8tcGNlLXBjZXAtcm91dGUtcHJpY2UtMDAudHh0DQoN Cg0KDQoNCg0KDQpEZWFyIGFsbA0KDQp3ZSd2ZSBqdXN0IHBvc3RlZCBhIG5ldyBJLUQgYWJvdXQg ZXh0ZW5kaW5nIFBDRVAgd2l0aCBhIG5ldyByb3V0ZSANCmluZm9ybWF0aW9uLCB0aGUgcHJpY2Uu DQpBcyBleHBsYWluZWQgaW4gdGhlIEktRCwgdGhlIHJvdXRlIHByaWNlIGlzIGFuIGFkZGl0aW9u YWwgaW5mbyB3aXRoIA0KcmVzcGVjdCB0byB0aGUgcm91dGUgY29zdChzKSBjdXJyZW50bHkgd2Vs bCBjb3ZlcmVkIGJ5IGV4aXN0aW5nIFBDRSBSRkNzDQoNCkFuZCB0aGlzIGV4dGVuc2lvbiBzZWVt cyB0byB1cyBxdWl0ZSB1c2VmdWwgaW4gdGhvc2Ugc2NlbmFyaW9zIHdoZXJlIGEgDQpTZXJ2aWNl IFBsYW5lIGludGVyZmFjZXMgdG8gUENFIGZvciBlbGFib3JhdGluZyBpdHMgcm91dGUgb2ZmZXJz Lg0KDQpZb3VyIGZlZWRiYWNrcyBhbmQgY29tbWVudHMgd291bGQgYmUgdmVyeSBtdWNoIGFwcHJl Y2lhdGVkLg0KDQpicg0KR2lubw0KDQpPbiAwNC8wMy8yMDEyIDkuMDYsIGludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZyB3cm90ZToNCj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZy b20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIA0KZGlyZWN0b3JpZXMuDQo+DQo+ICAgICAg ICAgICAgICAgIFRpdGxlICAgICAgICAgICA6IFBDRVAgZXh0ZW5zaW9ucyBmb3IgdGhlIGNvbXB1 dGF0aW9uIG9mIA0Kcm91dGUgb2ZmZXJzIHdpdGggcHJpY2UNCj4gICAgICAgICAgICAgICAgQXV0 aG9yKHMpICAgICAgIDogR2lubyBDYXJyb3p6bw0KPiAgICAgICAgICAgICAgICAgICAgICAgICAg ICBHaWFjb21vIEJlcm5pbmkNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgR2lhZGEgTGFu ZGkNCj4gICAgICAgICAgICAgICAgRmlsZW5hbWUgICAgICAgIDogDQpkcmFmdC1jYXJyb3p6by1w Y2UtcGNlcC1yb3V0ZS1wcmljZS0wMC50eHQNCj4gICAgICAgICAgICAgICAgUGFnZXMgICAgICAg ICAgIDogMTcNCj4gICAgICAgICAgICAgICAgRGF0ZSAgICAgICAgICAgIDogMjAxMi0wMy0wNA0K Pg0KPiAgICAgVGhlIFBDRSBkZWZpbmVkIGluIFJGQzQ2NTUgaXMgYSBmdW5jdGlvbmFsIGVudGl0 eSBnZW5lcmFsbHkgY29uZmluZWQNCj4gICAgIGluIHRoZSBjb250cm9sIHBsYW5lIHRvIGVsYWJv cmF0ZSBleHBsaWNpdCBvcHRpbWFsIHJvdXRlcyB3aXRoDQo+ICAgICByZWxhdGVkIGNvc3RzIHRv IGJlIGluc3RhbGxlZCBhcyBbR11NUExTIHR1bm5lbHMvTFNQcy4gIFRoZSANCnJlc3VsdGluZw0K PiAgICAgcm91dGUgY29zdChzKS9tZXRyaWMocykgYXJlIFRyYWZmaWMgRW5naW5lZXJpbmcgaW5k aWNhdG9ycyB1c2VkIGJ5DQo+ICAgICB0aGUgbmV0d29yayBhZG1pbmlzdHJhdG9yIChjYXJyaWVy KSB0byBvcHRpbWl6ZSB0aGUgdXNhZ2Ugb2YgaXRzDQo+ICAgICBuZXR3b3JrIHJlc291cmNlcy4N Cj4NCj4gICAgIEluIHRoaXMgZG9jdW1lbnQgYSBmcmFtZXdvcmsgZm9yIHRoZSB1c2FnZSBvZiBQ Q0UgaW4gY29vcGVyYXRpb24gDQp3aXRoDQo+ICAgICB0aGUgTmV0d29yayBTZXJ2aWNlIGFuZCBC dXNpbmVzcyBQbGFuZSAoTlNCUCkgaXMgcHJvcG9zZWQsIGFsb25nIA0Kd2l0aA0KPiAgICAgcmVs YXRlZCBQQ0VQIGV4dGVuc2lvbnMuICBUaGUgTlNCUCBpbnZva2VzIHRoaXMgZXh0ZW5kZWQgUENF IA0KKHNlcnZpY2UNCj4gICAgIFBDRSkgdG8gdHJpZ2dlciB0aGUgY29tcHV0YXRpb24gb2YgbmV0 d29yayBzZXJ2aWNlIG9mZmVycyB3aXRoDQo+ICAgICByZWxhdGVkIHByaWNlIGluZm9ybWF0aW9u LiAgVGhlIHByaWNlIG9mIGEgbmV0d29yayBjb25uZWN0aXZpdHkNCj4gICAgIHNlcnZpY2UgZ2Vu ZXJhbGx5IGRlcGVuZHMgb24gc3RyYXRlZ2ljIGZhY3RvcnMsIGJ1dCBpdCBjb3VsZCBhbHNvIGJl DQo+ICAgICBpbmZsdWVuY2VkIGJ5IHRoZSBhbW91bnQgb2YgbW9iaWxpemVkIG5ldHdvcmsgcmVz b3VyY2VzIChhbG9uZyB0aGUNCj4gICAgIHJvdXRlKSwgdGhlIGluZ3Jlc3MvZWdyZXNzIGludGVy ZmFjZXMvUG9QcywgZXRjLiAgVGhlcmVmb3JlLCBpdCANCmNvdWxkDQo+ICAgICBiZSBwcm92aWRl ZCBieSBhbiBleHRlbmRlZCBzZXJ2aWNlLVBDRSBhcyBhbiBhZGRpdGlvbmFsIHJvdXRlDQo+ICAg ICBpbmZvcm1hdGlvbi4NCj4NCj4gICAgIFRoaXMgZG9jdW1lbnQgZm9jdXNlcyBvbiB0aGUgZXh0 ZW5zaW9ucyB0byB0aGUgUENFUCBwcm90b2NvbCBpbg0KPiAgICAgc3VwcG9ydCBvZiB0aGUgY29t cHV0YXRpb24gb2Ygcm91dGUgcHJpY2VzIGZvciBpbnRyYS0gYW5kIGludGVyLQ0KPiAgICAgZG9t YWluIG5ldHdvcmsgY29ubmVjdGl2aXR5IHNlcnZpY2VzLiAgTWVjaGFuaXNtcyBmb3IgZWxhYm9y YXRpbmcgDQphbmQNCj4gICAgIHJldHJpZXZpbmcgcHJpY2UgaW5mb3JtYXRpb24gaW4gdGhlIFBD RSBhcmUgdmVuZG9yLXNwZWNpZmljIGFuZCBvdXQNCj4gICAgIG9mIHRoZSBzY29wZSBvZiB0aGlz IGRvY3VtZW50Lg0KPg0KPg0KPiBBIFVSTCBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczoNCj4g DQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1jYXJyb3p6by1wY2Ut cGNlcC1yb3V0ZS1wcmljZS0wMC50eHQNCg0KPg0KPiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28g YXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvDQo+DQo+IFRoaXMgSW50ZXJuZXQtRHJhZnQgY2FuIGJlIHJldHJpZXZlZCBh dDoNCj4gDQpmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWNhcnJvenpv LXBjZS1wY2VwLXJvdXRlLXByaWNlLTAwLnR4dA0KDQo+DQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEktRC1Bbm5vdW5jZSBtYWlsaW5nIGxpc3QN Cj4gSS1ELUFubm91bmNlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaS1kLWFubm91bmNlDQo+IEludGVybmV0LURyYWZ0IGRpcmVjdG9yaWVzOiBodHRw Oi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQo+IG9yIGZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRm LzFzaGFkb3ctc2l0ZXMudHh0DQo+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KUGNlIG1haWxpbmcgbGlzdA0KUGNlQGlldGYub3JnDQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BjZQ0KDQoNCg0K --=_alternative 00322C54482579C9_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEdpbm88L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkFuIGludGVyZXN0aW5nIGlkZWEu PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JZiBteSB1 bmRlcnN0YW5kaW5nIGlzIG5vdCB3cm9uZywgdGhlDQpkcmFmdCBkZXNjcmliZXMgdGhlIGFyY2hp dGVjdHVyZSBhbmQgUENFUCBleHRlbnNpb25zIHRoYXQgdGhlIE5TQlAgKFBDQykNCnNlbmRzIG91 dCB0aGUgcm91dGUgb2ZmZXIgY29tcHV0YXRpb24gcmVxdWVzdCB0byBTZXJ2aWNlLVBDRS48L2Zv bnQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mz5TaW5jZSA8L2ZvbnQ+PC90dD48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+dGhhdA0KdGhlIE5NUyAoUENDKSBzZW5kcyBvdXQgdGhl IFBDUmVxIG1lc3NhZ2VzIHRvIFBDRSBpcyBkZXNjcmliZWQgaW4gUkZDNDY1NSwNCldoYXQgdGhl IHByb2NlZHVyZSBsb29rcyBsaWtlIGlmIE5NUyBpcyBhbHNvIGludm9sdmVkPyBvciBOTVMgd2ls bCBub3QNCmFwcGVhciB3aGVuIHRoZSByb3V0ZSBvZmZlciBjb21wdXRhdGlvbiBpcyBhZG9wdGVk PyAmbmJzcDs8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PlNvcnJ5IHRoYXQgSSBhbSBub3QgZmFtaWxhciB3aXRoIHRoZQ0KVE1GIElQU1BIRVJFIEZyYW1l d29yazwvZm9udD48dHQ+PGZvbnQgc2l6ZT0zPiwgPC9mb250PjwvdHQ+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPmhvcGUNCnlvdXIgY2xhcmlmaWNhdGlvbi48L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlJlZ2FyZHM8L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkZlaTwvZm9udD4NCjxicj4NCjxicj4N Cjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzYl Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5HaW5vIENhcnJvenpvICZsdDtnLmNh cnJvenpvQG5leHR3b3Jrcy5pdCZndDs8L2I+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPreivP7IyzogJm5ic3A7cGNlLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+ DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMi0wMy0wNCAxNjoyMTwvZm9u dD4NCjx0ZCB3aWR0aD02MyU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0K PHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8 /sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5wY2VA aWV0Zi5vcmc8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPlJlOiBbUGNlXSBJLUQgQWN0aW9uOiBkcmFmdC1jYXJyb3p6by1wY2UtcGNlcC1y b3V0ZS1wcmljZS0wMC50eHQ8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxp Z249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPkRlYXIgYWxsPGJyPg0KPGJyPg0Kd2UndmUganVzdCBwb3N0ZWQg YSBuZXcgSS1EIGFib3V0IGV4dGVuZGluZyBQQ0VQIHdpdGggYSBuZXcgcm91dGUgPGJyPg0KaW5m b3JtYXRpb24sIHRoZSBwcmljZS48YnI+DQpBcyBleHBsYWluZWQgaW4gdGhlIEktRCwgdGhlIHJv dXRlIHByaWNlIGlzIGFuIGFkZGl0aW9uYWwgaW5mbyB3aXRoIDxicj4NCnJlc3BlY3QgdG8gdGhl IHJvdXRlIGNvc3QocykgY3VycmVudGx5IHdlbGwgY292ZXJlZCBieSBleGlzdGluZyBQQ0UgUkZD czxicj4NCjxicj4NCkFuZCB0aGlzIGV4dGVuc2lvbiBzZWVtcyB0byB1cyBxdWl0ZSB1c2VmdWwg aW4gdGhvc2Ugc2NlbmFyaW9zIHdoZXJlIGENCjxicj4NClNlcnZpY2UgUGxhbmUgaW50ZXJmYWNl cyB0byBQQ0UgZm9yIGVsYWJvcmF0aW5nIGl0cyByb3V0ZSBvZmZlcnMuPGJyPg0KPGJyPg0KWW91 ciBmZWVkYmFja3MgYW5kIGNvbW1lbnRzIHdvdWxkIGJlIHZlcnkgbXVjaCBhcHByZWNpYXRlZC48 YnI+DQo8YnI+DQpicjxicj4NCkdpbm88YnI+DQo8YnI+DQpPbiAwNC8wMy8yMDEyIDkuMDYsIGlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZyB3cm90ZTo8YnI+DQomZ3Q7IEEgTmV3IEludGVybmV0LURy YWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cw0KZGlyZWN0 b3JpZXMuPGJyPg0KJmd0Ozxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUaXRsZQ0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyA6IFBDRVAgZXh0ZW5zaW9ucyBmb3IgdGhlIGNvbXB1dGF0aW9uDQpv ZiByb3V0ZSBvZmZlcnMgd2l0aCBwcmljZTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtBdXRob3IocykNCiZuYnNw OyAmbmJzcDsgJm5ic3A7IDogR2lubyBDYXJyb3p6bzxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtHaWFjb21vIEJlcm5pbmk8YnI+DQomZ3Q7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7R2lhZGEgTGFuZGk8YnI+DQomZ3Q7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7RmlsZW5hbWUNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogZHJhZnQtY2Fycm96 em8tcGNlLXBjZXAtcm91dGUtcHJpY2UtMDAudHh0PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1BhZ2VzDQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogMTc8YnI+DQomZ3Q7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7RGF0ZQ0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6IDIwMTItMDMtMDQ8YnI+ DQomZ3Q7PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IFRoZSBQQ0UgZGVmaW5lZCBpbiBSRkM0NjU1 IGlzIGEgZnVuY3Rpb25hbCBlbnRpdHkgZ2VuZXJhbGx5DQpjb25maW5lZDxicj4NCiZndDsgJm5i c3A7ICZuYnNwOyBpbiB0aGUgY29udHJvbCBwbGFuZSB0byBlbGFib3JhdGUgZXhwbGljaXQgb3B0 aW1hbCByb3V0ZXMNCndpdGg8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgcmVsYXRlZCBjb3N0cyB0 byBiZSBpbnN0YWxsZWQgYXMgW0ddTVBMUyB0dW5uZWxzL0xTUHMuDQombmJzcDtUaGUgcmVzdWx0 aW5nPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IHJvdXRlIGNvc3QocykvbWV0cmljKHMpIGFyZSBU cmFmZmljIEVuZ2luZWVyaW5nIGluZGljYXRvcnMNCnVzZWQgYnk8YnI+DQomZ3Q7ICZuYnNwOyAm bmJzcDsgdGhlIG5ldHdvcmsgYWRtaW5pc3RyYXRvciAoY2FycmllcikgdG8gb3B0aW1pemUgdGhl DQp1c2FnZSBvZiBpdHM8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgbmV0d29yayByZXNvdXJjZXMu PGJyPg0KJmd0Ozxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBJbiB0aGlzIGRvY3VtZW50IGEgZnJh bWV3b3JrIGZvciB0aGUgdXNhZ2Ugb2YgUENFIGluDQpjb29wZXJhdGlvbiB3aXRoPGJyPg0KJmd0 OyAmbmJzcDsgJm5ic3A7IHRoZSBOZXR3b3JrIFNlcnZpY2UgYW5kIEJ1c2luZXNzIFBsYW5lIChO U0JQKSBpcyBwcm9wb3NlZCwNCmFsb25nIHdpdGg8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgcmVs YXRlZCBQQ0VQIGV4dGVuc2lvbnMuICZuYnNwO1RoZSBOU0JQIGludm9rZXMgdGhpcw0KZXh0ZW5k ZWQgUENFIChzZXJ2aWNlPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IFBDRSkgdG8gdHJpZ2dlciB0 aGUgY29tcHV0YXRpb24gb2YgbmV0d29yayBzZXJ2aWNlIG9mZmVycw0Kd2l0aDxicj4NCiZndDsg Jm5ic3A7ICZuYnNwOyByZWxhdGVkIHByaWNlIGluZm9ybWF0aW9uLiAmbmJzcDtUaGUgcHJpY2Ug b2YgYSBuZXR3b3JrDQpjb25uZWN0aXZpdHk8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgc2Vydmlj ZSBnZW5lcmFsbHkgZGVwZW5kcyBvbiBzdHJhdGVnaWMgZmFjdG9ycywgYnV0DQppdCBjb3VsZCBh bHNvIGJlPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IGluZmx1ZW5jZWQgYnkgdGhlIGFtb3VudCBv ZiBtb2JpbGl6ZWQgbmV0d29yayByZXNvdXJjZXMNCihhbG9uZyB0aGU8YnI+DQomZ3Q7ICZuYnNw OyAmbmJzcDsgcm91dGUpLCB0aGUgaW5ncmVzcy9lZ3Jlc3MgaW50ZXJmYWNlcy9Qb1BzLCBldGMu ICZuYnNwO1RoZXJlZm9yZSwNCml0IGNvdWxkPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IGJlIHBy b3ZpZGVkIGJ5IGFuIGV4dGVuZGVkIHNlcnZpY2UtUENFIGFzIGFuIGFkZGl0aW9uYWwNCnJvdXRl PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IGluZm9ybWF0aW9uLjxicj4NCiZndDs8YnI+DQomZ3Q7 ICZuYnNwOyAmbmJzcDsgVGhpcyBkb2N1bWVudCBmb2N1c2VzIG9uIHRoZSBleHRlbnNpb25zIHRv IHRoZSBQQ0VQDQpwcm90b2NvbCBpbjxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBzdXBwb3J0IG9m IHRoZSBjb21wdXRhdGlvbiBvZiByb3V0ZSBwcmljZXMgZm9yIGludHJhLQ0KYW5kIGludGVyLTxi cj4NCiZndDsgJm5ic3A7ICZuYnNwOyBkb21haW4gbmV0d29yayBjb25uZWN0aXZpdHkgc2Vydmlj ZXMuICZuYnNwO01lY2hhbmlzbXMNCmZvciBlbGFib3JhdGluZyBhbmQ8YnI+DQomZ3Q7ICZuYnNw OyAmbmJzcDsgcmV0cmlldmluZyBwcmljZSBpbmZvcm1hdGlvbiBpbiB0aGUgUENFIGFyZSB2ZW5k b3Itc3BlY2lmaWMNCmFuZCBvdXQ8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgb2YgdGhlIHNjb3Bl IG9mIHRoaXMgZG9jdW1lbnQuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IEEgVVJMIGZv ciB0aGlzIEludGVybmV0LURyYWZ0IGlzOjxicj4NCiZndDsgaHR0cDovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtY2Fycm96em8tcGNlLXBjZXAtcm91dGUtcHJpY2UtMDAudHh0 PGJyPg0KJmd0Ozxicj4NCiZndDsgSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBi eSBhbm9ueW1vdXMgRlRQIGF0Ojxicj4NCiZndDsgZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy88YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGlzIEludGVybmV0LURyYWZ0IGNhbiBiZSBy ZXRyaWV2ZWQgYXQ6PGJyPg0KJmd0OyBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LWNhcnJvenpvLXBjZS1wY2VwLXJvdXRlLXByaWNlLTAwLnR4dDxicj4NCiZndDs8YnI+ DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KJmd0OyBJLUQtQW5ub3VuY2UgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyBJLUQtQW5ub3VuY2VA aWV0Zi5vcmc8YnI+DQomZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aS1kLWFubm91bmNlPGJyPg0KJmd0OyBJbnRlcm5ldC1EcmFmdCBkaXJlY3RvcmllczogaHR0cDov L3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbDxicj4NCiZndDsgb3IgZnRwOi8vZnRwLmlldGYub3Jn L2lldGYvMXNoYWRvdy1zaXRlcy50eHQ8YnI+DQomZ3Q7PGJyPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpQY2UgbWFpbGluZyBsaXN0PGJyPg0K UGNlQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9w Y2U8YnI+DQo8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCg== --=_alternative 00322C54482579C9_=-- From julien.meuric@orange.com Fri Mar 23 07:36:39 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4208621F8518 for ; Fri, 23 Mar 2012 07:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.981 X-Spam-Level: X-Spam-Status: No, score=-5.981 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GlY3En8e1+Xe for ; Fri, 23 Mar 2012 07:36:35 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1F921F8555 for ; Fri, 23 Mar 2012 07:36:35 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5DF264110C1; Fri, 23 Mar 2012 15:36:34 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 56A314110C0; Fri, 23 Mar 2012 15:36:34 +0100 (CET) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Mar 2012 15:36:34 +0100 Received: from [10.193.71.73] ([10.193.71.73]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Mar 2012 15:36:33 +0100 Message-ID: <4F6C8A71.1020700@orange.com> Date: Fri, 23 Mar 2012 15:36:33 +0100 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Lightning/1.0b2 Thunderbird/3.1.19 MIME-Version: 1.0 To: "pce@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Mar 2012 14:36:33.0880 (UTC) FILETIME=[58403580:01CD0902] Cc: 'JP Vasseur' Subject: [Pce] Slide Request X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Julien Meuric List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 14:36:39 -0000 Hi all. If a slot has been allocated for you in the agenda for our meeting in Paris (http://www.ietf.org/proceedings/83/agenda/agenda-83-pce.htm), please send your corresponding slides to Dan _and_ chairs by Tuesday 27. In order to have a fruitful meeting, keep in mind that you are not supposed to present the details of your I-D, but expected to focus on changes/issues/discussions/controversies... See some of you on Monday, Julien From g.carrozzo@nextworks.it Mon Mar 26 06:50:20 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38A5721E809B for ; Mon, 26 Mar 2012 06:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.732 X-Spam-Level: * X-Spam-Status: No, score=1.732 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KAt23fB6ptlq for ; Mon, 26 Mar 2012 06:50:19 -0700 (PDT) Received: from mercurio.nextworks.it (mercurio.nextworks.it [213.182.68.141]) by ietfa.amsl.com (Postfix) with SMTP id DBFE221E809A for ; Mon, 26 Mar 2012 06:50:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercurio.nextworks.it (Postfix) with ESMTP id 71041308007; Mon, 26 Mar 2012 15:50:22 +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 hvC32dA-7i4q; Mon, 26 Mar 2012 15:50:10 +0200 (CEST) Received: from [130.129.21.68] (dhcp-1544.meeting.ietf.org [130.129.21.68]) by mercurio.nextworks.it (Postfix) with ESMTP id 1617E304004; Mon, 26 Mar 2012 15:50:09 +0200 (CEST) Message-ID: <4F7073F2.3010303@nextworks.it> Date: Mon, 26 Mar 2012 15:49:38 +0200 From: Gino Carrozzo User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: zhang.fei3@zte.com.cn References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000306010900050703050708" Cc: pce@ietf.org Subject: Re: [Pce] I-D Action: draft-carrozzo-pce-pcep-route-price-00.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 13:50:20 -0000 This is a multi-part message in MIME format. --------------000306010900050703050708 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi Fei thanks for your comments. You captured the core I-D concept: a Service-PCE for route offers plus (bare minimum) PCEP extensions to describe prices for those offers. You're right, management-based PCE usage by NMS has also been sketched in RFC4655 sec. 5.5, but in a context which seems to us still more applicable to the final service provisioning than the preliminary service offering (for negotiation). Our I-D aims at targeting this second case, by adding a route price for the customer into the PCE response: thus, the ERO is not the sole computation result of interest at PCC. In terms of framework, surely the NSBP can include functionalities typically provided by NMS/OSS for a single routing domain (e.g. the FCAPS). It'd not be the case in multi-domain cases. To this purpose, TMF IPSphere can be just a reference abstract service framework, and the Service PCE can provide a routing functionality also for the route offering/negotiation phase. Hope this clarifies a bit. br Gino On 22/03/2012 10:08, zhang.fei3@zte.com.cn wrote: > > Hi Gino > > An interesting idea. > > If my understanding is not wrong, the draft describes the architecture > and PCEP extensions that the NSBP (PCC) sends out the route offer > computation request to Service-PCE. > > Since that the NMS (PCC) sends out the PCReq messages to PCE is > described in RFC4655, What the procedure looks like if NMS is also > involved? or NMS will not appear when the route offer computation is > adopted? > > Sorry that I am not familar with the TMF IPSPHERE Framework, hope your > clarification. > > Regards > > Fei > > > *Gino Carrozzo * > =B7=A2=BC=FE=C8=CB: pce-bounces@ietf.org > > 2012-03-04 16:21 > > =09 > =CA=D5=BC=FE=C8=CB > pce@ietf.org > =B3=AD=CB=CD > =09 > =D6=F7=CC=E2 > Re: [Pce] I-D Action: draft-carrozzo-pce-pcep-route-price-00.txt > > > > =09 > > > > > > Dear all > > we've just posted a new I-D about extending PCEP with a new route > information, the price. > As explained in the I-D, the route price is an additional info with > respect to the route cost(s) currently well covered by existing PCE RFC= s > > And this extension seems to us quite useful in those scenarios where a > Service Plane interfaces to PCE for elaborating its route offers. > > Your feedbacks and comments would be very much appreciated. > > br > Gino > > On 04/03/2012 9.06, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > Title : PCEP extensions for the computation of route offers with pric= e > > Author(s) : Gino Carrozzo > > Giacomo Bernini > > Giada Landi > > Filename : draft-carrozzo-pce-pcep-route-price-00.txt > > Pages : 17 > > Date : 2012-03-04 > > > > The PCE defined in RFC4655 is a functional entity generally confined > > in the control plane to elaborate explicit optimal routes with > > related costs to be installed as [G]MPLS tunnels/LSPs. The resulting > > route cost(s)/metric(s) are Traffic Engineering indicators used by > > the network administrator (carrier) to optimize the usage of its > > network resources. > > > > In this document a framework for the usage of PCE in cooperation with= > > the Network Service and Business Plane (NSBP) is proposed, along with= > > related PCEP extensions. The NSBP invokes this extended PCE (service > > PCE) to trigger the computation of network service offers with > > related price information. The price of a network connectivity > > service generally depends on strategic factors, but it could also be > > influenced by the amount of mobilized network resources (along the > > route), the ingress/egress interfaces/PoPs, etc. Therefore, it could > > be provided by an extended service-PCE as an additional route > > information. > > > > This document focuses on the extensions to the PCEP protocol in > > support of the computation of route prices for intra- and inter- > > domain network connectivity services. Mechanisms for elaborating and > > retrieving price information in the PCE are vendor-specific and out > > of the scope of this document. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-carrozzo-pce-pcep-route-price= -00.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > This Internet-Draft can be retrieved at: > > > ftp://ftp.ietf.org/internet-drafts/draft-carrozzo-pce-pcep-route-price-= 00.txt > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > --------------000306010900050703050708 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi Fei

thanks for your comments.

You captured the core I-D concept:  a Service-PCE for route offe= rs plus (bare minimum) PCEP extensions to describe prices for those offers.

You're right, management-based PCE usage by NMS has also been sketched in RFC4655 sec. 5.5, but in a context which seems to us still more applicable to the final service provisioning than the preliminary service offering (for negotiation).
Our I-D aims at targeting this second case, by adding  a route p= rice for the customer into the PCE response: thus, the ERO is not the sole computation result of interest at PCC.

In terms of framework, surely  the NSBP can include functionalit= ies typically provided by NMS/OSS for a single routing domain (e.g. the FCAPS). It'd not be the case in multi-domain cases.
To this purpose, TMF IPSphere can be just a reference abstract service framework, and the Service PCE can provide a routing functionality  also for the route offering/negotiation phase.
Hope this clarifies a bit.

br
Gino
On 22/03/2012 10:08, zhang.fei3@zte.com.cn wrote:

Hi Gino

An interesting idea.

If my understanding is not wro= ng, the draft describes the architecture and PCEP extensions that the NSBP (PCC) sends out the route offer computation request to Service-PCE.

Since that the NMS (PCC) sends out the PCReq messages to PCE is described in RFC4655, What the procedure looks like if NMS is also involved? or NMS will not appear when the route offer computation is adopted?  =

Sorry that I am not familar wi= th the TMF IPSPHERE Framework, <= font face=3D"sans-serif" size=3D"2">hope your clarification.

Regards

Fei


Gin= o Carrozzo <g.carrozzo@nextworks.it>
=B7=A2=BC=FE=C8=CB:  pce-bounces@ietf.org

2012-03-04 16:21

=CA=D5=BC=FE=C8=CB
 pce@ietf.org
=B3=AD=CB=CD
=D6=F7=CC=E2
 Re: [Pce] I-= D Action: draft-carrozzo-pce-pcep-route-price-00.txt=







Dear all

we've just posted a new I-D about extending PCEP with a new route
information, the price.
As explained in the I-D, the route price is an additional info with
respect to the route cost(s) currently well covered by existing PCE RFCs

And this extension seems to us quite useful in those scenarios where a
Service Plane interfaces to PCE for elaborating its route offers.

Your feedbacks and comments would be very much appreciated.
=
br
Gino

On 04/03/2012 9.06, internet-drafts@ietf.org wrote:
= > A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>                 &n= bsp;Title           : PCEP extensions for the co= mputation of route offers with price
>                 &n= bsp;Author(s)       : Gino Carrozzo
>                 &n= bsp;          Giacomo Bernini
>                 &n= bsp;          Giada Landi
>                 &n= bsp;Filename        : draft-carrozzo-pce-pcep-route-pric= e-00.txt
>                 &n= bsp;Pages           : 17
>                 &n= bsp;Date            : 2012-03-04
>
>     The PCE defined in RFC4655 is a functional e= ntity generally confined
>     in the control plane to elaborate explicit o= ptimal routes with
>     related costs to be installed as [G]MPLS tunnels/LSPs.  The resulting
>     route cost(s)/metric(s) are Traffic Engineer= ing indicators used by
>     the network administrator (carrier) to optim= ize the usage of its
>     network resources.
>
>     In this document a framework for the usage o= f PCE in cooperation with
>     the Network Service and Business Plane (NSBP= ) is proposed, along with
>     related PCEP extensions.  The NSBP invo= kes this extended PCE (service
>     PCE) to trigger the computation of network s= ervice offers with
>     related price information.  The price o= f a network connectivity
>     service generally depends on strategic facto= rs, but it could also be
>     influenced by the amount of mobilized networ= k resources (along the
>     route), the ingress/egress interfaces/PoPs, = etc.  Therefore, it could
>     be provided by an extended service-PCE as an= additional route
>     information.
>
>     This document focuses on the extensions to t= he PCEP protocol in
>     support of the computation of route prices f= or intra- and inter-
>     domain network connectivity services.  = Mechanisms for elaborating and
>     retrieving price information in the PCE are vendor-specific and out
>     of the scope of this document.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/int= ernet-drafts/draft-carrozzo-pce-pcep-route-price-00.txt
>
> Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/inter= net-drafts/draft-carrozzo-pce-pcep-route-price-00.txt
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinf= o/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt<= /a>
>
_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
--------------000306010900050703050708-- From ramon.casellas@cttc.es Tue Mar 27 07:19:46 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3408521F888F for ; Tue, 27 Mar 2012 07:19:46 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id odzfcRj7XeHM for ; Tue, 27 Mar 2012 07:19:45 -0700 (PDT) Received: from Scorpius.cttc.es (scorpius.cttc.es [84.88.62.197]) by ietfa.amsl.com (Postfix) with ESMTP id 3A05721F8855 for ; Tue, 27 Mar 2012 07:19:44 -0700 (PDT) Received: from castor (postfix@castor.cttc.es [84.88.62.196]) by Scorpius.cttc.es (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q2REJBZ5022251 for ; Tue, 27 Mar 2012 16:19:16 +0200 Received: from [130.129.23.86] (dhcp-1756.meeting.ietf.org [130.129.23.86]) by castor (Postfix) with ESMTP id D09D82FC269 for ; Tue, 27 Mar 2012 16:19:25 +0200 (CEST) Message-ID: <4F71CC6B.6090804@cttc.es> Date: Tue, 27 Mar 2012 16:19:23 +0200 From: Ramon Casellas Organization: CTTC User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: pce@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (castor); Tue, 27 Mar 2012 16:19:26 +0200 (CEST) X-Scanned-By: MIMEDefang 2.67 on 84.88.62.197 Subject: [Pce] Comments and questions of draft-ietf-pce-stateful-pce-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 14:19:46 -0000 Dear Edward, co-authors, all, Although a bit later than I had hoped, please find below some comments / questions on your stateful PCE draft (draft-ietf-pce-stateful-pce-00) I hope they are useful, and your answers / clarifications are much appreciated. We can discuss after the PCE session specially if I don't make any sense :) General Comments / Questions =============================== * A first question / comment is whether you plan to focus exclusively on MPLS networks or whether you would also consider including GMPLS in general. In my humble opinion, there is no strong reason to exclude GMPLS, although this may have some implications on the proposed protocol extensions (e.g. notably, the use of the RFC5440 4-byte floating point PCEP BANDWIDTH object could be replaced by e.g. a GENERALIZED_BANDWIDTH, or the fixed-size RSVP-TE ERROR_SPEC). As it is now, it cannot be directly implemented / deployed in e.g our WSON. * Minor comment: although at the end it is a matter of taste ;-) I am not fond of the naming scheme for your proposed messages. Reporting about LSP state or Updating an LSP is, to some extent, not directly related to "Path Computation". For example, your message named "Path Computation State Report", that reports the status of an LSP, is confusing IMHO and the prefix "Path Computation" could be removed. Would you consider a naming scheme more in the lines of, e.g. "LSP State Report" (LSPRpt) or "LSP Update Request" (LSPUpd)?. As a side note, it would be slightly less error prone since we have now PCReq / PCRep / PCRpt / PCUpd. In my personal preference, I would only qualify messages with Path Computation if they are actually related to the Path Computation procedure itself (although I admit that it is not always the case, for example, PCNtf messages that do not refer to a given request). State Cleanup ----------------------- * I guess you will address state cleanup more deeply in a newer version (in $5.8 you mention state cleanup after session termination) although I am not sure how this coexists with maintaining state between sessions - In short, what would be the suggested procedure? after the (persistent) connection is terminated for some reason, a PCC/PCE is supposed to maintain the state for a given period of time, which is greater than the Delegation Timeout? Also, how do you recognize a given PCC that reconnects after a (persistent) connection was terminated? I am not sure whether some kind of PCC identifier would be needed, since in a given host, several entities may behave as PCCs at different times from the same IP address using ephemeral ports. Recognizing a (Reconnecting) PCC by its IP address may not be a good idea (and for multi-homed hosts, it may change). Do you think a say TLV in the OPEN message or a PCC_REQ_ID as in Monitoring could be necessary to unambiguously identify a PCC? -- I believe that the tuple (PCC_REQ_ID, Session-internal LSPid) may be needed to unambiguously identify an LSP. I would not rely on the IP address of the TCP connection to identify a client. Delegation and Revocation ------------------------- * $5.2.2 "When a PCC's PCEP session with the PCE terminates, the PCC SHALL wait a time interval specified in 'Delegation Timeout Interval' and then revoke all LSP delegations to the PCE" -> I am not sure I understand this part. If the session is terminated, how does the PCC revoke? it just assumes that the PCE is no longer responsible for the LSPs and a PCE will do something similar? In other words, I was confused by the sentence "A PCC may revoke this delegation at any point during the lifetime of the PCEP session", yet the timer refers to a procedure that happens after the termination of the connection. If the connection is reestablished before the Delegation Timeout Interval runs out, and sync is skipped, delegations are assumed to stay as they were and the timer is stopped? what if the timer runs out while the PCEP peers are handshaking? don't we risk cases where the actual delegation could be undefined? Object ordering ---------------------------- * The draft mandates a given object ordering but it does not specify the position of the LSP object within PCReq and PCRep messages (stated in $7.2). Where would you suggest adding the LSP object? LSP identifiers ---------------------------- * I am a bit lost by Figures 18 and 19: it looks like a merge of SENDER_TEMPLATE and SESSION objects, but I am not sure it is correct. When using LSP_TUNNEL session from RFC3209, the Extended tunnel id is typically either set to 0 or using the ingress node. Your object also refers to the Tunnel Sender Address, which is also again the LSP ingress node. Did you mean IPv4 tunnel endpoint (i.e. Session address)? 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=[TBD] | Length=12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Tunnel Sender Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP ID | Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Address / IPv4 tunnel Endpoint (??) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Extended tunnel ID: mentions 128 bits for v4? Extended Tunnel ID: contains the 128-bit 'Extended Tunnel ID' identifier defined in [RFC3209] --> Contains the 32 bit Session Address / IPv4 tunnel endpoint. Other & misc --------------------------- * Would you consider (variable sized) IF_ID ERROR_SPEC with TLVs rather than fixed Ects RROR_SPEC objeto 8 bytes? I believe that having TLVs to identify not only the failed (unnumbered) interface id but stacking failed elements as stated in RFC4920 (cranckback) is useful information for a stateful PCE which may be able to react faster than relying on the TED update mechanism (e.g. in the case of failure) * For $7.2.2 what happens if a LSP is re-routed and the LSPid chages due to, for example, make-before-break with SE and a new lspid? Can we change the LSPid in successive PCRpt messages as long as we mantain the 20-bit LSP identifier? * What is the semantic of the IRO object in a PCUpd message? * "Session-internal LSP-ID (20 bits): Per-PCEP session identifier for an LSP". I am confused by the qualification of "Per-PCEP session" identifier. In case of connection termination and reconnect, skipping sync, the identifier is kept the same. In other words, the id has to be kept the same for the lifetime of the connection, but it can go past that, right? OTOH nothing precludes a PCC to assign the same ses-internal LSP-ID to several PCEs, right? could you please clarify? -- in other words, I am not sure of the need to qualify on a per-PCEP session basis. Typos and other nits =============================== $3.1.2 capitalize TED -> Out-of-band TED synchronization ... $3.1.2 grammar -> "and the and" $5.2 The PCRep message is described in $6.1 -> The PCRpt message is. ... $5.3 The PCEP protocol exensions for stateful PCEs MAY - would this be a MUST? $5.4 Incomplete sentence (see ) Figures 6,7,8 refer to a PCOpen message. I take it you mean Open? $5.6.1 mentions a "PC Reply" -> PCRep ? $5.6.2 the passive stateful PCE is the model for stateful PCE is described in ... -> as? $/.8 page 35 delegating the LSP the PCE -> to the PCE? - Align Figure 14 to 32 bits? why are you limiting to 16? padding needs to be included in any case. - Below Figure 18 caption: "the type of TLV is... and has a fixed length of 8 octets. It also says two fields? -> 4 fields, different size - Below Figure 19 caption: "the type of TLV is... and has a fixed length of 20 octets. It also says two fields) -> 4 fields, different size Thanks and best regards Ramon From julien.meuric@orange.com Wed Mar 28 09:59:16 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6ED621E8258; Wed, 28 Mar 2012 09:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.841 X-Spam-Level: X-Spam-Status: No, score=-5.841 tagged_above=-999 required=5 tests=[AWL=0.409, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKaWZJKtbj2i; Wed, 28 Mar 2012 09:59:16 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5AA21E8254; Wed, 28 Mar 2012 09:59:16 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 055BE16C065; Wed, 28 Mar 2012 18:59:15 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id EFBFD16C064; Wed, 28 Mar 2012 18:59:14 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Mar 2012 18:59:14 +0200 Received: from [10.193.116.59] ([10.193.116.59]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Mar 2012 18:59:14 +0200 Message-ID: <4F734361.8020000@orange.com> Date: Wed, 28 Mar 2012 18:59:13 +0200 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Lightning/1.0b2 Thunderbird/3.1.19 MIME-Version: 1.0 To: "ccamp@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Mar 2012 16:59:14.0813 (UTC) FILETIME=[1B07AAD0:01CD0D04] Cc: "pce@ietf.org" Subject: [Pce] PCE Work in CCAMP X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 16:59:17 -0000 Hi CCAMPers. Following the meeting this morning, I would like to comment on the numerous references to PCE with my chair hat on. First, I am glad to see the PCE architecture being encompassed as a relevant part of various proposals. Nevertheless, as said during several PCE meetings, when it comes to make PCEP support a CCAMP feature, it is most of the time driven by RSVP-TE capabilities and/or (IGP-driven) path computation capabilities. As reminded during the PCE meeting in Taipei, this obviously applies to flexi-grid work: when GMPLS protocol extensions will be mature enough, PCEP extensions will become rather straightforward and PCE-specific frameworks may be useless. I also know how tempting it is for the optical world to address problems with centralized entities, however the current PCE charter is not to solve all issues which may benefit from a centralized entity (which is a very _specific_ use case of PCE). At this stage, my suggestion to CCAMP draft authors (mainly on flexi-grid) is to tackle the work step by step without "chasing 2 hares" at the same time; i.e. keep the PCE material on hold till the work is mature enough, and, then, consider the opportunity to submit this material to the _PCE WG_. Let me also take the opportunity to remind that: - the PCE WG does not standardize a path computation entity, does not standardize any structural architecture, but *protocols* relevant to its _functional_ architecture; - even if the PCE WG has started to work on some stateful features, it does not automatically imply that anything tagged "stateful" is (nor will be) in scope (please read again RFCs and WG I-Ds). Best regards, Julien From jpv@cisco.com Thu Mar 29 09:28:19 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75A4F21F88AF for ; Thu, 29 Mar 2012 09:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.36 X-Spam-Level: X-Spam-Status: No, score=-110.36 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKP6UCtTgeuu for ; Thu, 29 Mar 2012 09:28:14 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8331621F88B0 for ; Thu, 29 Mar 2012 09:28:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=364; q=dns/txt; s=iport; t=1333038494; x=1334248094; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=CgrOAYaqhpyZGhh2QhAqfZFrAYl/o7Czdy1s9ZtbP0k=; b=IPCuYN9Gxv+PkflSBn5MfKs/pF+N8npqlXoEgcpmIPSYrZypiB79c9lB E+FXMpoU/z2S5Zy0a0xb4ECQ7a3jPtsZUkQ4B7e6szTb75I1W2IkOqJNO K3lQQqs6j+Pk4r7D1/swxEl0Ad5WCfCOEUCUrtXvOi7tCxxCMILo1bez+ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAP2MdE+Q/khL/2dsb2JhbABFuROBB4IiASc0gX6HaJplgSefK417gkFjBJVhjkaBaIJp X-IronPort-AV: E=Sophos;i="4.73,669,1325462400"; d="scan'208";a="133748335" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 29 Mar 2012 16:28:12 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2TGSCER003550 for ; Thu, 29 Mar 2012 16:28:12 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Mar 2012 18:28:12 +0200 Received: from dhcp-15c4.meeting.ietf.org ([10.55.82.79]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Mar 2012 18:28:12 +0200 From: JP Vasseur Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Mar 2012 18:28:11 +0200 Message-Id: To: pce@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-OriginalArrivalTime: 29 Mar 2012 16:28:12.0148 (UTC) FILETIME=[EF354B40:01CD0DC8] Subject: [Pce] Adoption of draft-pouyllau-pce-enhanced-errors-03.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 16:28:19 -0000 Dear all, We had a pretty strong support for adopting = draft-pouyllau-pce-enhanced-errors a PCE Working Group during our PCE WG = meeting but as usual we'd like to confirm on the mailing list. Could you please let us know if you are in favor/opposed to adopting = draft-pouyllau-pce-enhanced-errors as a PCE WG Document ? Thanks. JP and Julien.= From jpv@cisco.com Thu Mar 29 09:29:56 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C28A21F88C7 for ; Thu, 29 Mar 2012 09:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.373 X-Spam-Level: X-Spam-Status: No, score=-110.373 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHPFloLvHOZ8 for ; Thu, 29 Mar 2012 09:29:55 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id E6D7E21F88C6 for ; Thu, 29 Mar 2012 09:29:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=1418; q=dns/txt; s=iport; t=1333038595; x=1334248195; h=from:subject:date:message-id:to:mime-version; bh=0o+RWGLAoD3h3fsKoy3kaEnGkK9+xxhuz5Fbl76BorM=; b=mtmvY38xSBu6CdX2B1GSa83nGxJVQhrbAEieTPNKyvDDzL+SQTO5Y8rt Ks3iYlhN0fCsWwww1odf5n7J30F9RK6p8E0k8lfYiLTyyPOO3BU2TWsLg I36iCPFagz2TEYoOhzy9/q5YfvrcpT9p9iHm2abXNkFaXr3oMJHcGb4qn w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAP2MdE+Q/khN/2dsb2JhbABFuROBB4IAIgFbKQGBVIdommWBJ58rjXuCQWMElWGORoFogmk X-IronPort-AV: E=Sophos;i="4.73,669,1325462400"; d="scan'208,217";a="69673355" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 29 Mar 2012 16:29:53 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2TGTqOl006461 for ; Thu, 29 Mar 2012 16:29:53 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); Thu, 29 Mar 2012 18:29:52 +0200 Received: from dhcp-15c4.meeting.ietf.org ([10.55.82.79]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Mar 2012 18:29:52 +0200 From: JP Vasseur Content-Type: multipart/alternative; boundary="Apple-Mail=_5DA16158-66AB-4EC5-8EA3-0C3724375729" Date: Thu, 29 Mar 2012 18:29:52 +0200 Message-Id: <5B30AA9C-FB42-4216-8B3B-854F13A0B93D@cisco.com> To: pce@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-OriginalArrivalTime: 29 Mar 2012 16:29:52.0873 (UTC) FILETIME=[2B3EB590:01CD0DC9] Subject: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 16:29:56 -0000 --Apple-Mail=_5DA16158-66AB-4EC5-8EA3-0C3724375729 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear all, We had a pretty strong support for adopting = draft-dhody-pce-pcep-domain-sequence-02 a PCE Working Group during our = PCE WG meeting but as usual we'd like to confirm on the mailing list. Could you please let us know if you are in favor/opposed to adopting = draft-dhody-pce-pcep-domain-sequence-02 as a PCE WG Document ? Thanks. JP and Julien.= --Apple-Mail=_5DA16158-66AB-4EC5-8EA3-0C3724375729 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Dear all,

We had a pretty strong support for adopting draft-dhody-pce-pcep-domain-sequence-02 a PCE Working Group during our PCE WG meeting but
as usual we'd like to confirm on the mailing list.

Could you please let us know if you are in favor/opposed to adopting draft-dhody-pce-pcep-domain-sequence-02 as a PCE WG Document ?

Thanks.

JP and Julien.
--Apple-Mail=_5DA16158-66AB-4EC5-8EA3-0C3724375729-- From ramon.casellas@cttc.es Thu Mar 29 09:38:13 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9CCF21F84FB for ; Thu, 29 Mar 2012 09:38:13 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmtGhD0s2RsS for ; Thu, 29 Mar 2012 09:38:13 -0700 (PDT) Received: from Scorpius.cttc.es (scorpius.cttc.es [84.88.62.197]) by ietfa.amsl.com (Postfix) with ESMTP id 710D521F84EB for ; Thu, 29 Mar 2012 09:38:12 -0700 (PDT) Received: from castor (postfix@castor.cttc.es [84.88.62.196]) by Scorpius.cttc.es (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q2TGbdRi016737 for ; Thu, 29 Mar 2012 18:37:44 +0200 Received: from [130.129.23.86] (dhcp-1756.meeting.ietf.org [130.129.23.86]) by castor (Postfix) with ESMTP id DB11F2FC22D for ; Thu, 29 Mar 2012 18:37:55 +0200 (CEST) Message-ID: <4F748FE2.6070108@cttc.es> Date: Thu, 29 Mar 2012 18:37:54 +0200 From: Ramon Casellas Organization: CTTC User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: pce@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (castor); Thu, 29 Mar 2012 18:37:56 +0200 (CEST) X-Scanned-By: MIMEDefang 2.67 on 84.88.62.197 Subject: Re: [Pce] Adoption of draft-pouyllau-pce-enhanced-errors-03.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 16:38:14 -0000 On 03/29/2012 06:28 PM, JP Vasseur wrote: > Could you please let us know if you are in favor/opposed to adopting draft-pouyllau-pce-enhanced-errors as a PCE WG Document ? > Yes / support R. From ramon.casellas@cttc.es Thu Mar 29 09:41:54 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 856A121F84FB for ; Thu, 29 Mar 2012 09:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tzAT5kzOJme for ; Thu, 29 Mar 2012 09:41:54 -0700 (PDT) Received: from Scorpius.cttc.es (scorpius.cttc.es [84.88.62.197]) by ietfa.amsl.com (Postfix) with ESMTP id AD19221F84EB for ; Thu, 29 Mar 2012 09:41:53 -0700 (PDT) Received: from castor (postfix@castor.cttc.es [84.88.62.196]) by Scorpius.cttc.es (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q2TGfLKl016775 for ; Thu, 29 Mar 2012 18:41:26 +0200 Received: from [130.129.23.86] (dhcp-1756.meeting.ietf.org [130.129.23.86]) by castor (Postfix) with ESMTP id D13302FC22D for ; Thu, 29 Mar 2012 18:41:37 +0200 (CEST) Message-ID: <4F7490C1.5030500@cttc.es> Date: Thu, 29 Mar 2012 18:41:37 +0200 From: Ramon Casellas Organization: CTTC User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: pce@ietf.org References: <5B30AA9C-FB42-4216-8B3B-854F13A0B93D@cisco.com> In-Reply-To: <5B30AA9C-FB42-4216-8B3B-854F13A0B93D@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (castor); Thu, 29 Mar 2012 18:41:37 +0200 (CEST) X-Scanned-By: MIMEDefang 2.67 on 84.88.62.197 Subject: Re: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 16:41:54 -0000 On 03/29/2012 06:29 PM, JP Vasseur wrote: > > Could you please let us know if you are in favor/opposed to adopting > draft-dhody-pce-pcep-domain-sequence-02 as a PCE WG Document ? > Yes / support (as a co-author) R. PS: There is an IPR disclosure https://datatracker.ietf.org/ipr/1690/ covering this draft. I am not aware of other IPRs From dhruv.dhody@huawei.com Thu Mar 29 10:03:32 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C72221F8983 for ; Thu, 29 Mar 2012 10:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKF-+nrgkUpY for ; Thu, 29 Mar 2012 10:03:31 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7D10421F88D8 for ; Thu, 29 Mar 2012 10:03:27 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEM42391; Thu, 29 Mar 2012 13:03:27 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Mar 2012 10:01:44 -0700 Received: from SZXEML422-HUB.china.huawei.com (10.82.67.161) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Mar 2012 10:01:50 -0700 Received: from V00904246L (10.47.136.14) by szxeml422-hub.china.huawei.com (10.82.67.161) with Microsoft SMTP Server id 14.1.323.3; Fri, 30 Mar 2012 01:01:40 +0800 From: Dhruv Dhody To: 'Ramon Casellas' , References: <4F748FE2.6070108@cttc.es> In-Reply-To: <4F748FE2.6070108@cttc.es> Date: Thu, 29 Mar 2012 19:01:31 +0200 Organization: Htipl Message-ID: <006601cd0dcd$99a497d0$ccedc770$@dhody@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0NyokzirAY1/7vQCmsT7EDp9ESPgAAvFIg Content-Language: en-us X-Originating-IP: [10.47.136.14] X-CFilter-Loop: Reflected Subject: Re: [Pce] Adoption of draft-pouyllau-pce-enhanced-errors-03.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dhruv.dhody@huawei.com List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 17:03:32 -0000 Support! (With a promise to provide text for P2MP/HPCE etc) Regards, Dhruv -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Ramon Casellas Sent: Thursday, March 29, 2012 6:38 PM To: pce@ietf.org Subject: Re: [Pce] Adoption of draft-pouyllau-pce-enhanced-errors-03.txt On 03/29/2012 06:28 PM, JP Vasseur wrote: > Could you please let us know if you are in favor/opposed to adopting draft-pouyllau-pce-enhanced-errors as a PCE WG Document ? > Yes / support R. _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From ogondio@tid.es Thu Mar 29 10:06:18 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 119E221E80C2 for ; Thu, 29 Mar 2012 10:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIPEQONuagHn for ; Thu, 29 Mar 2012 10:06:17 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 11ADF21F89DB for ; Thu, 29 Mar 2012 10:06:17 -0700 (PDT) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M1N00D19OUF2F@tid.hi.inet> for pce@ietf.org; Thu, 29 Mar 2012 19:06:15 +0200 (MEST) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id D7.FB.02597.786947F4; Thu, 29 Mar 2012 19:06:15 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0M1N00D15OUF2F@tid.hi.inet> for pce@ietf.org; Thu, 29 Mar 2012 19:06:15 +0200 (MEST) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad2.hi.inet ([192.168.0.2]) with mapi; Thu, 29 Mar 2012 19:06:15 +0200 Date: Thu, 29 Mar 2012 19:06:14 +0200 From: =?utf-8?B?T3NjYXIgR29uesOhbGV6IGRlIERpb3M=?= In-reply-to: To: JP Vasseur Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: es-ES Content-transfer-encoding: base64 Accept-Language: es-ES, en-US Thread-topic: [Pce] Adoption of draft-pouyllau-pce-enhanced-errors-03.txt Thread-index: Ac0Nzj+rHLWJCzOGSdWJKQ0O50NZ5g== acceptlanguage: es-ES, en-US X-AuditID: 0a5f4e69-b7f4d6d000000a25-d7-4f749687075e X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEKsWRmVeSWpSXmKPExsXCFe9nqNs+rcTf4MIMaYum+zfYHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8fhzO1PBMq6K7b/aWBoYW7i6GDk5JARMJPoevmWGsMUkLtxb z9bFyMUhJLCdUWL+1jUsEM53RonZPf+gnEZGic37u1hAWlgEVCWeNR5kBLHZBJwlHhxrArOF BTwkLi77yNTFyMHBKWArcb85GCQsIiAncePMRDaQMLOAosS727wgYV4BS4kLS+exQdiCEj8m 32OBKFGXmDIlFyTMLCAuMefXRFYIW1Fi2qIGsEWMArISK8+fZoSY7ilx6scjVghbT+Lq0kVM EDUyEv+X72WB+FFAYsme81D/ikq8fPwPrF5IwEbi8v4/7BMYxWchuWIWwhWzkFwxC8kVCxhZ VjGKFScVZaZnlOQmZuakGxjpZWTqZeallmxihERQ5g7G5TtVDjEKcDAq8fAytJf4C7EmlhVX 5h5ilORgUhLl7ZkEFOJLyk+pzEgszogvKs1JLT7EKMHBrCTCezwCKMebklhZlVqUD5OS4eBQ kuDNnwqUEixKTU+tSMvMAaYJmDQTBydIOw9QezhIDW9xQWJucWY6RP4Uo6SUOESzAEgiozQP rvcVozjQkcK83iBZHmBCg+t6BTSQCWggMy/YwJJEhJRUA+PR17fCUsTnLlVbOm3aCpakSo3o lH2X+ufknGYxfFkQ8GzT89jfno4KBcvMeSI8FM4d1jsV5LKGUz8yTqW9lNPA5Iy3JNMq7UsB n7XfXLFK61mueizKi6HA6qbBXl4ZFo0nXZuvcUjYP+ux1dWI/z1Nb6364YMHlwm9lzfzr/92 aEtGb+oWdSWW4oxEQy3mouJEAOpztG4lAwAA References: Cc: "pce@ietf.org" Subject: Re: [Pce] Adoption of draft-pouyllau-pce-enhanced-errors-03.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 17:06:18 -0000 U3VwcG9ydC4NCg0KT3NjYXINCg0KRW52aWFkbyBkZXNkZSBtaSBpUGFkDQoNCkVsIDI5LzAzLzIw MTIsIGEgbGFzIDE4OjI4LCAiSlAgVmFzc2V1ciIgPGpwdkBjaXNjby5jb20+IGVzY3JpYmnDszoN Cg0KPiBEZWFyIGFsbCwNCj4NCj4gV2UgaGFkIGEgcHJldHR5IHN0cm9uZyBzdXBwb3J0IGZvciBh ZG9wdGluZyBkcmFmdC1wb3V5bGxhdS1wY2UtZW5oYW5jZWQtZXJyb3JzIGEgUENFIFdvcmtpbmcg R3JvdXAgZHVyaW5nIG91ciBQQ0UgV0cgbWVldGluZyBidXQNCj4gYXMgdXN1YWwgd2UnZCBsaWtl IHRvIGNvbmZpcm0gb24gdGhlIG1haWxpbmcgbGlzdC4NCj4NCj4gQ291bGQgeW91IHBsZWFzZSBs ZXQgdXMga25vdyBpZiB5b3UgYXJlIGluIGZhdm9yL29wcG9zZWQgdG8gYWRvcHRpbmcgZHJhZnQt cG91eWxsYXUtcGNlLWVuaGFuY2VkLWVycm9ycyBhcyBhIFBDRSBXRyBEb2N1bWVudCA/DQo+DQo+ IFRoYW5rcy4NCj4NCj4gSlAgYW5kIEp1bGllbi4NCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gUGNlIG1haWxpbmcgbGlzdA0KPiBQY2VAaWV0Zi5v cmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wY2UNCg0KRXN0ZSBt ZW5zYWplIHNlIGRpcmlnZSBleGNsdXNpdmFtZW50ZSBhIHN1IGRlc3RpbmF0YXJpby4gUHVlZGUg Y29uc3VsdGFyIG51ZXN0cmEgcG9sw610aWNhIGRlIGVudsOtbyB5IHJlY2VwY2nDs24gZGUgY29y cmVvIGVsZWN0csOzbmljbyBlbiBlbCBlbmxhY2Ugc2l0dWFkbyBtw6FzIGFiYWpvLg0KVGhpcyBt ZXNzYWdlIGlzIGludGVuZGVkIGV4Y2x1c2l2ZWx5IGZvciBpdHMgYWRkcmVzc2VlLiBXZSBvbmx5 IHNlbmQgYW5kIHJlY2VpdmUgZW1haWwgb24gdGhlIGJhc2lzIG9mIHRoZSB0ZXJtcyBzZXQgb3V0 IGF0DQpodHRwOi8vd3d3LnRpZC5lcy9FUy9QQUdJTkFTL2Rpc2NsYWltZXIuYXNweA0K From leeyoung@huawei.com Thu Mar 29 10:06:28 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6339621E8137 for ; Thu, 29 Mar 2012 10:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.379 X-Spam-Level: X-Spam-Status: No, score=-2.379 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0RcX1n2JKcQ for ; Thu, 29 Mar 2012 10:06:27 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id BAA9421E8101 for ; Thu, 29 Mar 2012 10:06:27 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEU44739; Thu, 29 Mar 2012 13:06:27 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Mar 2012 10:03:58 -0700 Received: from dfweml511-mbx.china.huawei.com ([169.254.16.128]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Thu, 29 Mar 2012 10:03:53 -0700 From: Leeyoung To: JP Vasseur , "pce@ietf.org" Thread-Topic: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG Thread-Index: AQHNDckZVCQ5lBARJUmtVFgrer16cJaBgDpQ Date: Thu, 29 Mar 2012 17:03:52 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1720C8FAD0@dfweml511-mbx.china.huawei.com> References: <5B30AA9C-FB42-4216-8B3B-854F13A0B93D@cisco.com> In-Reply-To: <5B30AA9C-FB42-4216-8B3B-854F13A0B93D@cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.145.189] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1720C8FAD0dfweml511mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 17:06:28 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E1720C8FAD0dfweml511mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support, Young From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of JP Va= sseur Sent: Thursday, March 29, 2012 11:30 AM To: pce@ietf.org Subject: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PC= E WG Dear all, We had a pretty strong support for adopting draft-dhody-pce-pcep-domain-seq= uence-02 a PCE Working Group during our PCE WG meeting but as usual we'd like to confirm on the mailing list. Could you please let us know if you are in favor/opposed to adopting draft-= dhody-pce-pcep-domain-sequence-02 as a PCE WG Document ? Thanks. JP and Julien. --_000_7AEB3D6833318045B4AE71C2C87E8E1720C8FAD0dfweml511mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support,

 <= /p>

Young

 <= /p>

From: pce-boun= ces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of JP Vasseur
Sent: Thursday, March 29, 2012 11:30 AM
To: pce@ietf.org
Subject: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a= new PCE WG

 

Dear all,

 

We had a pretty strong support for adopting draft-dhody-pce-pcep-domain-sequence-02 a PCE Working Group during our PCE WG meeting but

as usual we'd like to confirm on the mailing list.

 

Could you please let us know if you are in favor/opp= osed to adopting draft-dhody-pce-pcep-domain-sequence-02 as a PCE WG D= ocument ?

 

Thanks.

 

JP and Julien.

--_000_7AEB3D6833318045B4AE71C2C87E8E1720C8FAD0dfweml511mbxchi_-- From leeyoung@huawei.com Thu Mar 29 10:06:59 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ECFA21F89DD for ; Thu, 29 Mar 2012 10:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.387 X-Spam-Level: X-Spam-Status: No, score=-2.387 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4XOQzFSGOMY for ; Thu, 29 Mar 2012 10:06:59 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8A621F89DB for ; Thu, 29 Mar 2012 10:06:59 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEU44788; Thu, 29 Mar 2012 13:06:58 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Mar 2012 10:04:59 -0700 Received: from dfweml511-mbx.china.huawei.com ([169.254.16.128]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Thu, 29 Mar 2012 10:05:03 -0700 From: Leeyoung To: JP Vasseur , "pce@ietf.org" Thread-Topic: [Pce] Adoption of draft-pouyllau-pce-enhanced-errors-03.txt Thread-Index: AQHNDcj5BytZrSKoxkODXQZ+UPe2w5aBgElQ Date: Thu, 29 Mar 2012 17:05:02 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1720C8FADE@dfweml511-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.145.189] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Pce] Adoption of draft-pouyllau-pce-enhanced-errors-03.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 17:06:59 -0000 Support - With specifying the default value for new TLV's defined Young -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of JP Va= sseur Sent: Thursday, March 29, 2012 11:28 AM To: pce@ietf.org Subject: [Pce] Adoption of draft-pouyllau-pce-enhanced-errors-03.txt Dear all, We had a pretty strong support for adopting draft-pouyllau-pce-enhanced-err= ors a PCE Working Group during our PCE WG meeting but as usual we'd like to confirm on the mailing list. Could you please let us know if you are in favor/opposed to adopting draft-= pouyllau-pce-enhanced-errors as a PCE WG Document ? Thanks. JP and Julien. _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From dhruv.dhody@huawei.com Thu Mar 29 10:08:16 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F82221F892A for ; Thu, 29 Mar 2012 10:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N978ShRvvxSX for ; Thu, 29 Mar 2012 10:08:15 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7E28621F8929 for ; Thu, 29 Mar 2012 10:08:15 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEU44875; Thu, 29 Mar 2012 13:08:10 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Mar 2012 10:05:46 -0700 Received: from SZXEML424-HUB.china.huawei.com (10.82.67.163) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Mar 2012 10:05:42 -0700 Received: from V00904246L (10.47.136.14) by szxeml424-hub.china.huawei.com (10.82.67.163) with Microsoft SMTP Server id 14.1.323.3; Fri, 30 Mar 2012 01:05:36 +0800 From: Dhruv Dhody To: 'Ramon Casellas' , References: <5B30AA9C-FB42-4216-8B3B-854F13A0B93D@cisco.com> <4F7490C1.5030500@cttc.es> In-Reply-To: <4F7490C1.5030500@cttc.es> Date: Thu, 29 Mar 2012 19:05:27 +0200 Organization: Htipl Message-ID: <006701cd0dce$26131020$72393060$@dhody@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0Nyt0+BoEQoqDATLC25vD00S55CgAAr1Ng Content-Language: en-us X-Originating-IP: [10.47.136.14] X-CFilter-Loop: Reflected Subject: Re: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dhruv.dhody@huawei.com List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 17:08:16 -0000 Support (Co-author :)) One IPR has been disclosed. (https://datatracker.ietf.org/ipr/1690/) As per my knowledge no other IPR exist. Regards, Dhruv -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Ramon Casellas Sent: Thursday, March 29, 2012 6:42 PM To: pce@ietf.org Subject: Re: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG On 03/29/2012 06:29 PM, JP Vasseur wrote: > > Could you please let us know if you are in favor/opposed to adopting > draft-dhody-pce-pcep-domain-sequence-02 as a PCE WG Document ? > Yes / support (as a co-author) R. PS: There is an IPR disclosure https://datatracker.ietf.org/ipr/1690/ covering this draft. I am not aware of other IPRs _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From huaimo.chen@huawei.com Thu Mar 29 10:14:03 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF24E21F8A0B for ; Thu, 29 Mar 2012 10:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6J6CnlygGtX for ; Thu, 29 Mar 2012 10:14:03 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1505D21F8A0A for ; Thu, 29 Mar 2012 10:14:03 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEM43035; Thu, 29 Mar 2012 13:14:02 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Mar 2012 10:12:06 -0700 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Thu, 29 Mar 2012 10:11:12 -0700 From: Huaimo Chen To: JP Vasseur , "pce@ietf.org" Thread-Topic: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG Thread-Index: AQHNDckz/KD9qA8oBUCu5kXRORmRvJaBgeZA Date: Thu, 29 Mar 2012 17:11:57 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D4325F4520@dfweml505-mbx> In-Reply-To: <5B30AA9C-FB42-4216-8B3B-854F13A0B93D@cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.138.193] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D4325F4520dfweml505mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 17:14:03 -0000 --_000_5316A0AB3C851246A7CA5758973207D4325F4520dfweml505mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, support. Huaimo ________________________________ From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of JP Va= sseur Sent: Thursday, March 29, 2012 12:30 PM To: pce@ietf.org Subject: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PC= E WG Dear all, We had a pretty strong support for adopting draft-dhody-pce-pcep-domain-seq= uence-02 a PCE Working Group during our PCE WG meeting but as usual we'd like to confirm on the mailing list. Could you please let us know if you are in favor/opposed to adopting draft-= dhody-pce-pcep-domain-sequence-02 as a PCE WG Document ? Thanks. JP and Julien. --_000_5316A0AB3C851246A7CA5758973207D4325F4520dfweml505mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes, suppor= t.

  = ;

Huaimo=

From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of JP Vasseur
Sent: Thursday, March 29, 20= 12 12:30 PM
To: pce@ietf.org
Subject: [Pce] Adopting draf= t-dhody-pce-pcep-domain-sequence-02 as a new PCE WG

 

Dear all,

 

We had a pretty strong support for ad= opting draft-dhody-pce-pcep-domain-sequence-02 a PCE Working Group during our PCE WG meeting but

as usual we'd like to confirm on the = mailing list.

 

Could you please let us know if you a= re in favor/opposed to adopting draft-dhody-pce-pcep-domain-sequence-02&nbs= p;as a PCE WG Document ?

 

Thanks.

 

JP and Julien.

--_000_5316A0AB3C851246A7CA5758973207D4325F4520dfweml505mbx_-- From huaimo.chen@huawei.com Thu Mar 29 10:45:47 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B667321F86EE for ; Thu, 29 Mar 2012 10:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLT3rkswWcTv for ; Thu, 29 Mar 2012 10:45:47 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 32AD221F86AF for ; Thu, 29 Mar 2012 10:45:47 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEU47185; Thu, 29 Mar 2012 13:45:46 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Mar 2012 10:44:11 -0700 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Thu, 29 Mar 2012 10:44:03 -0700 From: Huaimo Chen To: JP Vasseur , "pce@ietf.org" Thread-Topic: [Pce] Adoption of draft-pouyllau-pce-enhanced-errors-03.txt Thread-Index: AQHNDcj5Wlz3WUvtL06Sk/2j/Vz9S5aBikOw Date: Thu, 29 Mar 2012 17:44:02 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D4325F456D@dfweml505-mbx> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.138.193] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Pce] Adoption of draft-pouyllau-pce-enhanced-errors-03.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 17:45:47 -0000 Yes, support. Can authors explain the history mechanism presented today? The history of the messages should have been done/kept through using messag= e IDs generally. Huaimo -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of JP Va= sseur Sent: Thursday, March 29, 2012 12:28 PM To: pce@ietf.org Subject: [Pce] Adoption of draft-pouyllau-pce-enhanced-errors-03.txt Dear all, We had a pretty strong support for adopting draft-pouyllau-pce-enhanced-err= ors a PCE Working Group during our PCE WG meeting but as usual we'd like to confirm on the mailing list. Could you please let us know if you are in favor/opposed to adopting draft-= pouyllau-pce-enhanced-errors as a PCE WG Document ? Thanks. JP and Julien. _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From durga_uunet@yahoo.com Thu Mar 29 10:48:08 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3D8221F880D for ; Thu, 29 Mar 2012 10:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.398 X-Spam-Level: * X-Spam-Status: No, score=1.398 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6l+gtVKFgoWf for ; Thu, 29 Mar 2012 10:48:08 -0700 (PDT) Received: from nm24-vm0.bullet.mail.bf1.yahoo.com (nm24-vm0.bullet.mail.bf1.yahoo.com [98.139.213.161]) by ietfa.amsl.com (Postfix) with SMTP id 5498921F8809 for ; Thu, 29 Mar 2012 10:48:08 -0700 (PDT) Received: from [98.139.212.153] by nm24.bullet.mail.bf1.yahoo.com with NNFMP; 29 Mar 2012 17:48:07 -0000 Received: from [98.139.212.222] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 29 Mar 2012 17:48:07 -0000 Received: from [127.0.0.1] by omp1031.mail.bf1.yahoo.com with NNFMP; 29 Mar 2012 17:48:07 -0000 X-Yahoo-Newman-Id: 888277.35968.bm@omp1031.mail.bf1.yahoo.com Received: (qmail 20402 invoked from network); 29 Mar 2012 17:48:07 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=DKIM-Signature:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:References:In-Reply-To:Mime-Version:Content-Type:Message-Id:Content-Transfer-Encoding:Cc:X-Mailer:From:Subject:Date:To; b=dKglFFRsv+HuSy3whoSQqIbeVGhm28v4br/PXM8NhWVYRFcKhATeTZBd/pUqUg1T0AtsgEu2SQkY/qJR/h5ZGW7CI79RqB/haI0sYaLXQCQ8zP/8MDJ/xrI7MFhXOl0La4OjDF0W0wOxwF6FhrHuKPJ2xKA7OMWx/2u8lREI1As= ; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1333043287; bh=wYFcyR/kFxFYCWknNTI4VN2QrlyOZ+8WC8Tj0xdaglg=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:References:In-Reply-To:Mime-Version:Content-Type:Message-Id:Content-Transfer-Encoding:Cc:X-Mailer:From:Subject:Date:To; b=Ffx2vUQ9+gfFHYTsaxf8Lll+BbbMgK/805q3lQzTET6+YwG/K594VJZ3OSjr0vo7Afzpk7Yol/IyrIF3BFX3nEUwQuI4iMUvo2Rb39gIZWZeKm6xQeblQ5NAo2yYEWHtdvUQ/ed4e609CJkdU8lx218Q3pdPiRalZ0yQxEgBXxI= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: XpUtvgoVM1npxP4JY0wZDksDrKVc1b.vuOSgp2UAdEKUqKs bU3eSZJ9O22rBIRKE5XUpacRiVie3n95qO5hOt_VswV7_CXlVSEsgXrMJqx3 DNwTyqpI86IGE4vXep7z7ADX1jfJ.aVbm.UF9F86Pelh9xAht0KvgOYyejVS PyK9hzygpPZLsw286rxe9baonJUlkR6m4kp0E1yk9e.yP7U0xe8if1Vm8sZ0 JgdkrvBf0lgcTAM.paZa92lhsc8q5UD17bPKrJZs9M1uNpJNiiAG7Si0v67L BJ4SFg6oWmCAezBOzp9IBHp.YtNfuJSORn_0cDzMX0uCphRQbDHpCPtfgdOR vxezKSyOMKdAAOeoh2gExViwVGLdFb7E_MNI2hLLGA.ljuPRlh9kHVQA1brQ T83e1LW7eAAlgyHTH1Ad0KGAWtj_Bbpl4i9DJWp2ErgqB4lgB0UhnEfJvmw- - X-Yahoo-SMTP: goRBQzeswBDNZPtYJ.b_yCcu55YQOo1t Received: from [10.231.113.147] (Durga_uunet@174.252.97.150 with xymcookie) by smtp115-mob.biz.mail.bf1.yahoo.com with SMTP; 29 Mar 2012 10:48:07 -0700 PDT References: <5B30AA9C-FB42-4216-8B3B-854F13A0B93D@cisco.com> In-Reply-To: <5B30AA9C-FB42-4216-8B3B-854F13A0B93D@cisco.com> Mime-Version: 1.0 (1.0) Content-Type: multipart/alternative; boundary=Apple-Mail-63BC61A4-A0C5-434C-9EDE-BE0CF67AA5A7 Message-Id: <8EE7D224-766E-42F1-8303-0856C75CCD01@yahoo.com> Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (9A405) From: Durga_uunet@yahoo.com Date: Thu, 29 Mar 2012 13:48:02 -0400 To: JP Vasseur Cc: "pce@ietf.org" Subject: Re: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 17:48:09 -0000 --Apple-Mail-63BC61A4-A0C5-434C-9EDE-BE0CF67AA5A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii JP & team, Yes, I too support. Brgds, Durgaprasad Gangisetti. Sent from my iPhone On Mar 29, 2012, at 12:29 PM, JP Vasseur wrote: > Dear all, >=20 > We had a pretty strong support for adopting draft-dhody-pce-pcep-domain-se= quence-02 a PCE Working Group during our PCE WG meeting but > as usual we'd like to confirm on the mailing list. >=20 > Could you please let us know if you are in favor/opposed to adopting draft= -dhody-pce-pcep-domain-sequence-02 as a PCE WG Document ? >=20 > Thanks. >=20 > JP and Julien. > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce --Apple-Mail-63BC61A4-A0C5-434C-9EDE-BE0CF67AA5A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
JP & = team,
Yes, I too support.

Brgds, Durgaprasad = Gangisetti.

Sent = from my iPhone

On Mar 29, 2012, at 12:29 = PM, JP Vasseur <jpv=40cisco.com> = wrote:

Dear = all,

We had a pretty strong support for = adopting draft-dhody-pce-pcep-domain-sequence-02 a PCE Working Group = during our PCE WG meeting but
as usual we'd like to confirm on = the mailing list.

Could you please let us know if = you are in favor/opposed to adopting = draft-dhody-pce-pcep-domain-sequence-02 as a PCE WG Document = ?

Thanks.

JP and = Julien.
______________________________________________= _
Pce mailing list
Pce=40ietf.org
https://www.ietf.org= /mailman/listinfo/pce
= --Apple-Mail-63BC61A4-A0C5-434C-9EDE-BE0CF67AA5A7-- From meral.shirazipour@ericsson.com Thu Mar 29 10:55:48 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4135121E80BC for ; Thu, 29 Mar 2012 10:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7pOQKN0tchK for ; Thu, 29 Mar 2012 10:55:47 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id A030C21F8912 for ; Thu, 29 Mar 2012 10:55:47 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q2THtMaS028604 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Mar 2012 12:55:47 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.158]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Thu, 29 Mar 2012 13:55:34 -0400 From: Meral Shirazipour To: JP Vasseur Date: Thu, 29 Mar 2012 13:55:33 -0400 Thread-Topic: draft-gonzalezdedios-pce-reservation-state-01 next step ? Thread-Index: Ac0N1QUWCVnP+JNvQ7K2bM1mBY9b4A== Message-ID: <25DC600D0CC1F2479C7053ADEB93004E67C2A03277@EUSAACMS0703.eamcs.ericsson.se> 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_25DC600D0CC1F2479C7053ADEB93004E67C2A03277EUSAACMS0703e_" MIME-Version: 1.0 Cc: "pce@ietf.org" Subject: [Pce] draft-gonzalezdedios-pce-reservation-state-01 next step ? X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 17:55:48 -0000 --_000_25DC600D0CC1F2479C7053ADEB93004E67C2A03277EUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi JP, I may have missed part of the discussion today after Oscar presented. Wha= t was the next step for draft: http://tools.ietf.org/html/draft-gonzalezded= ios-pce-reservation-state-01 ? Thanks, Meral --_000_25DC600D0CC1F2479C7053ADEB93004E67C2A03277EUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi JP,

  I may have missed part of the discussion t= oday after Oscar presented. What was the next step for draft: http://tools.ietf.org/ht= ml/draft-gonzalezdedios-pce-reservation-state-01 ?

 

Thanks,

Meral

= --_000_25DC600D0CC1F2479C7053ADEB93004E67C2A03277EUSAACMS0703e_-- From ina@juniper.net Thu Mar 29 11:31:19 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD7FB21E814E for ; Thu, 29 Mar 2012 11:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.293 X-Spam-Level: X-Spam-Status: No, score=-6.293 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKc-uREhqcxB for ; Thu, 29 Mar 2012 11:31:18 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABF721E8145 for ; Thu, 29 Mar 2012 11:31:14 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKT3Sqb1umE+10nV/jxhlL2x0U6VJgKZYQ@postini.com; Thu, 29 Mar 2012 11:31:18 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 29 Mar 2012 11:31:06 -0700 From: Ina Minei To: Ramon Casellas , "pce@ietf.org" , Edward Crabbe , Jan Medved , "robert.varga@pantheon.sk" , Ina Minei Date: Thu, 29 Mar 2012 11:31:05 -0700 Thread-Topic: [Pce] Comments and questions of draft-ietf-pce-stateful-pce-00 Thread-Index: Ac0MJKyK4v4BN7URR9GedKtTvoKxcgBso18A Message-ID: <189716C74BBB9C4095FE8CA503B1FC3A59218048A3@EMBX02-HQ.jnpr.net> References: <4F71CC6B.6090804@cttc.es> In-Reply-To: <4F71CC6B.6090804@cttc.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Pce] Comments and questions of draft-ietf-pce-stateful-pce-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 18:31:19 -0000 Ramon, Thank you for the thorough review and feedback. Please find the consolidate= d answers from the authors inline below, look for ###. Thank you,=20 Ina=20 -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Ramon= Casellas Sent: Tuesday, March 27, 2012 7:19 AM To: pce@ietf.org Subject: [Pce] Comments and questions of draft-ietf-pce-stateful-pce-00 [snip] General Comments / Questions =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 * A first question / comment is whether you plan to focus exclusively on MP= LS networks or whether you would also consider including GMPLS in general. = In my humble opinion, there is no strong reason to exclude GMPLS, although = this may have some implications on the proposed protocol extensions (e.g. n= otably, the use of the RFC5440 4-byte floating point PCEP BANDWIDTH object = could be replaced by e.g. a GENERALIZED_BANDWIDTH, or the fixed-size RSVP-T= E ERROR_SPEC). As it is now, it cannot be directly implemented / deployed i= n e.g our WSON. ### You are right, we do not want to exclude GMPLS, and this was brought up= during the last review as well. Addressing different profiles (e.g. MPLS, = GMPLS) should be possible within the same framework, and should probably be= addressed in separate drafts. * Minor comment: although at the end it is a matter of taste ;-) I am not f= ond of the naming scheme for your proposed messages. Reporting about LSP st= ate or Updating an LSP is, to some extent, not directly related to "Path Co= mputation". For example, your message named "Path Computation State Report"= , that reports the status of an LSP, is confusing IMHO and the prefix "Path= Computation" could be removed. Would you consider a naming scheme more in = the lines of, e.g. "LSP State Report" (LSPRpt) or "LSP Update Request" (LSP= Upd)?. As a side note, it would be slightly less error prone since we have = now PCReq / PCRep / PCRpt / PCUpd. In my personal preference, I would only = qualify messages with Path Computation if they are actually related to the = Path Computation procedure itself (although I admit that it is not always t= he case, for example, PCNtf messages that do not refer to a given request). ### This is a good suggestion, will update in the next version.=20 State Cleanup ----------------------- * I guess you will address state cleanup more deeply in a newer version (in= $5.8 you mention state cleanup after session termination) although I am no= t sure how this coexists with maintaining state between sessions - In short= , what would be the suggested procedure? after the (persistent) connection = is terminated for some reason, a PCC/PCE is supposed to maintain the state = for a given period of time, which is greater than the Delegation Timeout? A= lso, how do you recognize a given PCC that reconnects after a (persistent) = connection was terminated? I am not sure whether some kind of PCC identifie= r would be needed, since in a given host, several entities may behave as PC= Cs at different times from the same IP address using ephemeral ports. Recog= nizing a (Reconnecting) PCC by its IP address may not be a good idea (and f= or multi-homed hosts, it may change). Do you think a say TLV in the OPEN me= ssage or a PCC_REQ_ID as in Monitoring could be necessary to unambiguously = identify a PCC? -- I believe that the tuple (PCC_REQ_ID, Session-internal L= SPid) may be needed to unambiguously identify an LSP. I would not rely on t= he IP address of the TCP connection to identify a client. ### Your suggestion for an identifier for the PCC makes sense. State cleanu= p will be addressed more fully in the next version.=20 Delegation and Revocation ------------------------- * $5.2.2 "When a PCC's PCEP session with the PCE terminates, the PCC SHALL = wait a time interval specified in 'Delegation Timeout Interval'=20 and then revoke all LSP delegations to the PCE" -> I am not sure I understa= nd this part. If the session is terminated, how does the PCC revoke? it jus= t assumes that the PCE is no longer responsible for the LSPs and a PCE will= do something similar? In other words, I was confused by the sentence "A PC= C may revoke this delegation at any point during the lifetime of the PCEP s= ession", yet the timer refers to a procedure that happens after the termina= tion of the connection. If the connection is reestablished before the Deleg= ation Timeout Interval runs out, and sync is skipped, delegations are assum= ed to stay as they were and the timer is stopped? what if the timer runs ou= t while the PCEP peers are handshaking? don't we risk cases where the actua= l delegation could be undefined? ### The delegation timeout is for state cleanup on a session failure. The t= imer should be stopped the moment there is another delegation request on th= is LSP. We need a better name for this timer too, the current name is confu= sing. Object ordering ---------------------------- * The draft mandates a given object ordering but it does not specify the po= sition of the LSP object within PCReq and PCRep messages (stated in $7.2). = Where would you suggest adding the LSP object? ### Good point. This is for the passive stateful PCE - the PCE should be ab= le to correlate path computation requests with status updates coming from t= he PCC. Will update in the next version.=20 LSP identifiers ---------------------------- * I am a bit lost by Figures 18 and 19: it looks like a merge of SENDER_TEM= PLATE and SESSION objects, but I am not sure it is correct.=20 When using LSP_TUNNEL session from RFC3209, the Extended tunnel id is typic= ally either set to 0 or using the ingress node. Your object also refers to = the Tunnel Sender Address, which is also again the LSP ingress node. Did yo= u mean IPv4 tunnel endpoint (i.e. Session address)? ### Yes, thank you for catching this.=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=3D[TBD] | Length=3D12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Tunnel Sender Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP ID | Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Address / IPv4 tunnel Endpoint (??) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Extended tunnel ID: mentions 128 bits for v4? ### Good catch, this is a typo Extended Tunnel ID: contains the 128-bit 'Extended Tunnel ID'=20 identifier defined in [RFC3209] --> Contains the 32 bit Session Address / I= Pv4 tunnel endpoint. Other & misc --------------------------- * Would you consider (variable sized) IF_ID ERROR_SPEC with TLVs rather=20 than fixed Ects RROR_SPEC objeto 8 bytes? I believe that having TLVs to=20 identify not only the failed (unnumbered) interface id but stacking=20 failed elements as stated in RFC4920 (cranckback) is useful information=20 for a stateful PCE which may be able to react faster than relying on the=20 TED update mechanism (e.g. in the case of failure) ### It's a good idea. We need to think some more how exactly to structure i= t.=20 * For $7.2.2 what happens if a LSP is re-routed and the LSPid chages due=20 to, for example, make-before-break with SE and a new lspid? Can we=20 change the LSPid in successive PCRpt messages as long as we mantain the=20 20-bit LSP identifier? * What is the semantic of the IRO object in a PCUpd message? ### It should not be there :-), will be updated * "Session-internal LSP-ID (20 bits): Per-PCEP session identifier for an=20 LSP". I am confused by the qualification of "Per-PCEP session"=20 identifier. In case of connection termination and reconnect, skipping=20 sync, the identifier is kept the same. In other words, the id has to be=20 kept the same for the lifetime of the connection, but it can go past=20 that, right? OTOH nothing precludes a PCC to assign the same=20 ses-internal LSP-ID to several PCEs, right? could you please clarify? --=20 in other words, I am not sure of the need to qualify on a per-PCEP=20 session basis. ### Right. What we wanted to say is that it has meaning and stays the same = for the duration of the PCEP session. Note that there is also an LSP Name, = which is supposed to be persistent (i.e. survive between PCEP sessions). Typos and other nits =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 $3.1.2 capitalize TED -> Out-of-band TED synchronization ... $3.1.2 grammar -> "and the and" $5.2 The PCRep message is described in $6.1 -> The PCRpt message is. ... $5.3 The PCEP protocol exensions for stateful PCEs MAY - would this be a=20 MUST? $5.4 Incomplete sentence (see ) Figures 6,7,8 refer to a PCOpen message. I take it you mean Open? $5.6.1 mentions a "PC Reply" -> PCRep ? $5.6.2 the passive stateful PCE is the model for stateful PCE is=20 described in ... -> as? $/.8 page 35 delegating the LSP the PCE -> to the PCE? - Align Figure 14 to 32 bits? why are you limiting to 16? padding needs=20 to be included in any case. - Below Figure 18 caption: "the type of TLV is... and has a fixed length=20 of 8 octets. It also says two fields? -> 4 fields, different size - Below Figure 19 caption: "the type of TLV is... and has a fixed length=20 of 20 octets. It also says two fields) -> 4 fields, different size ### Thank you for catching these, will fix in the next revision.=20 Thanks and best regards Ramon _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From adrian@olddog.co.uk Thu Mar 29 15:11:48 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA2321F863B for ; Thu, 29 Mar 2012 15:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LZUiBNcBhkH for ; Thu, 29 Mar 2012 15:11:47 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id DC6FF21F84EA for ; Thu, 29 Mar 2012 15:11:46 -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 q2TMBhma030244; Thu, 29 Mar 2012 23:11:43 +0100 Received: from 950129200 (dhcp-4431.meeting.ietf.org [130.129.68.49]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q2TMBftu030228 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 29 Mar 2012 23:11:42 +0100 From: "Adrian Farrel" To: "'JP Vasseur'" , Date: Thu, 29 Mar 2012 23:11:41 +0100 Message-ID: <0e5d01cd0df8$ebed2450$c3c76cf0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0E5E_01CD0E01.4DFC50F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac0N+HOcj1jsJ9t7TwqYufxmQg4ezQ== Content-Language: en-gb Subject: Re: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 22:11:48 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0E5E_01CD0E01.4DFC50F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Please accept this comment as an individual comment like all the rest. I have some reservations about adopting this document as a WG draft, but will not register to stand in its way. I understand the motive for this work and, indeed, it fills a hole in the protocol spec. I do hope that the authors are building it for shipping equipment and deployment. If not, would they please consider whether it should be experimental? Here are some comments based on a very light review. I should probably read the document properly some day. I am concerned that this document changes the definition and intent contained in RFC 5440. In my opinion the authors of 5440, and the WG at the time, wen to some lengths to tie the content of objects in PCEP to the same definitions found in RFCs 3209, 3473 and 3477. At the same time, definitions of subobjects for path definition, should also pay attention to RFCs 4874 and 4920. The intention is to not define more subobjects than needed and to keep registries aligned. It is also worth noting how 4920 handles 2 and 4 octet AS numbers and that there is overlap in the definition of AS number subobjects with draft-zhang-pce-hierarchy-extensions-01 In this light and on careful reading, the IANA section is somewhat broken and confused about what should be in the registry it is creating. But I am also unsure why a new IRO type is needed. Surely the domain sequence that is used in the computation is also the domain sequence for the path that the LSP will take. This feeds on the points below. The algorithm in 3.4: - assumes only area IDs and AS numbers - assumes that a PCE knows at least one PCE responsible for each of its neighboring domains I would like the authors to take care that the identity of a boundary node does not uniquely identify a next-hop domain (even if it may be successfully used for domain routing given the knowledge of the next domain, next boundary node, or egress node) and the text should not imply that it does. This is hidden at the end of 3.4 some time after the boundary node/link discussion. Shouldn't you allow "loose" hops in the domain path? (i.e. gaps between domains). Can I also mix other concepts with the domain path? What about a consistent lambda, or a core node that needs to be on the path? In 3.5.7 I don't see that the domain sequence is necessarily an alternative to the PCE sequence. There are cases where even with a domain sequence, a PCE sequence is important. In 3.5.7 you have: All PCE must be aware of all other PCEs in all domain for PCE- Sequence. This is false. Although it is true that a PCE in one domain must be able to route to the IP address of a PCE in a neighboring domain. In 3.5.7 you have: There maybe multiple PCE in a domain, the selection of PCE should not be made at the PCC/PCE(1). This decision is made only at the neighboring PCE which is aware of state of PCEs via notification messages There are four points here: 1. These are unsubstantiated assertions rather than reasons. 2. All neighboring PCEs are sending each other notification messages? 3. PCE choice may be based on capabilities, not just being up 4. In HPCE, it is quite reasonable for the parent to select the children Section 5 will need loads of work because the domain sequence (even for inclusion, not reporting) provides information valuable to an attacker. I am sure the management considerations can be added within the WG process. Thanks, Adrian From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of JP Vasseur Sent: 29 March 2012 17:30 To: pce@ietf.org Subject: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG Dear all, We had a pretty strong support for adopting draft-dhody-pce-pcep-domain-sequence-02 a PCE Working Group during our PCE WG meeting but as usual we'd like to confirm on the mailing list. Could you please let us know if you are in favor/opposed to adopting draft-dhody-pce-pcep-domain-sequence-02 as a PCE WG Document ? Thanks. JP and Julien. ------=_NextPart_000_0E5E_01CD0E01.4DFC50F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please accept this comment as = an individual comment like all the rest.

 

I have some reservations about = adopting this document as a WG draft, but will not register to stand in = its way.

 

I understand the motive for = this work and, indeed, it fills a hole in the protocol = spec.

 

I do hope that the authors are = building it for shipping equipment and deployment. If not, would they = please consider whether it should be = experimental?

 

Here are some comments based = on a very light review. I should probably read the document properly = some day.

 

I am concerned that this = document changes the definition and intent contained in RFC 5440. In my = opinion the authors of 5440, and the WG at the time, wen to some lengths = to tie the content of objects in PCEP to the same definitions found in = RFCs 3209, 3473 and 3477. At the same time, definitions of subobjects = for path definition, should also pay attention to RFCs 4874 and 4920. = The intention is to not define more subobjects than needed and to keep = registries aligned.

 

It is also worth noting how = 4920  handles 2 and 4 octet = AS numbers and that there is overlap in the definition of AS number = subobjects with = draft-zhang-pce-hierarchy-extensions-01

 

In this light and on careful = reading, the IANA section is somewhat broken and confused about what = should be in the registry it is creating.

 

But I am also unsure why a new = IRO type is needed. Surely the domain sequence that is used in the = computation is also the domain sequence for the path that the LSP will = take. This feeds on the points below.

 

The algorithm in = 3.4:

- assumes only area IDs and AS = numbers

- assumes that a PCE knows at = least one PCE responsible for each of

   its neighboring = domains

 

I would like the authors to = take care that the identity of a boundary node does not uniquely = identify a next-hop domain (even if it may be successfully used for = domain routing given the knowledge of the next domain, next boundary = node, or egress node) and the text should not imply that it does. This = is hidden at the end of 3.4 some time after the  boundary node/link = discussion.

 

Shouldn't you allow = "loose" hops in the domain path? (i.e. gaps between = domains).

 

Can I also mix other concepts = with the domain path? What about a consistent lambda, or a core node = that needs to be on the path?

 

In 3.5.7 I don't see that the = domain sequence is necessarily an alternative to the PCE sequence. There = are cases where even with a domain sequence, a PCE sequence is = important.

 

In 3.5.7 you = have:

      All PCE = must be aware of all other PCEs in all domain for = PCE-

      = Sequence.

This is false. Although it is = true that a PCE in one domain must be able to route to the IP address of = a PCE in a neighboring domain.

 

In 3.5.7 you = have:

      There = maybe multiple PCE in a domain, the selection of PCE = should

      not be = made at the PCC/PCE(1).  = This decision is made only at the

      = neighboring PCE which is aware of state of PCEs via = notification

      = messages

There are four points = here:

1. These are unsubstantiated = assertions rather than reasons.

2. All neighboring PCEs are = sending each other notification messages?

3. PCE choice may be based on = capabilities, not just being up

4. In HPCE, it is quite = reasonable for the parent to select the children

 

Section 5 will need loads of = work because the domain sequence (even for inclusion, not reporting) = provides information valuable to an attacker.

 

I am sure the management = considerations can be added within the WG = process.

 

Thanks,

Adrian

 

 

From: = pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of = JP Vasseur
Sent: 29 March 2012 17:30
To: = pce@ietf.org
Subject: [Pce] Adopting = draft-dhody-pce-pcep-domain-sequence-02 as a new PCE = WG

 

Dear = all,

 

We had a pretty strong support for adopting draft-dhody-pce-pcep-domain-sequence-02 = a PCE Working Group during our PCE WG meeting = but

as usual we'd like = to confirm on the mailing list.

 

Could you please let us know if you are in favor/opposed to = adopting draft-dhody-pce-pcep-domain-sequence-02 as a PCE WG = Document ?

 

Thanks.

 

JP and = Julien.

------=_NextPart_000_0E5E_01CD0E01.4DFC50F0-- From zhangfatai@huawei.com Thu Mar 29 16:20:12 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5A121F8684 for ; Thu, 29 Mar 2012 16:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.687 X-Spam-Level: **** X-Spam-Status: No, score=4.687 tagged_above=-999 required=5 tests=[AWL=-1.762, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjwIBBO1h-4U for ; Thu, 29 Mar 2012 16:20:11 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id C7D4A21F8531 for ; Thu, 29 Mar 2012 16:20:08 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEM62981; Thu, 29 Mar 2012 19:20:08 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Mar 2012 16:19:14 -0700 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Mar 2012 16:19:19 -0700 Received: from SZXEML520-MBS.china.huawei.com ([169.254.2.181]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.003; Fri, 30 Mar 2012 07:19:15 +0800 From: Fatai Zhang To: JP Vasseur , "pce@ietf.org" Thread-Topic: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG Thread-Index: AQHNDck0MbyaJUOdEUCFlpNeJyV3B5aB6Qrq Date: Thu, 29 Mar 2012 23:19:14 +0000 Message-ID: References: <5B30AA9C-FB42-4216-8B3B-854F13A0B93D@cisco.com> In-Reply-To: <5B30AA9C-FB42-4216-8B3B-854F13A0B93D@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.67] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [Pce] =?gb2312?b?tPC4tDogIEFkb3B0aW5nIGRyYWZ0LWRob2R5LXBjZS1wY2Vw?= =?gb2312?b?LWRvbWFpbi1zZXF1ZW5jZS0wMiBhcyBhIG5ldyBQQ0UJV0c=?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 23:20:12 -0000 DQpZZXMsIHN1cHBvcnQuDQoNCg0KVGhhbmtzDQoNCkZhdGFpDQoNCg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IHBjZS1ib3VuY2VzQGlldGYub3Jn IFtwY2UtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBKUCBWYXNzZXVyIFtqcHZAY2lzY28uY29tXQ0K t6LLzcqxvOQ6IDIwMTLE6jPUwjMwyNUgMDoyOQ0Ktb06IHBjZUBpZXRmLm9yZw0K1vfM4jogW1Bj ZV0gQWRvcHRpbmcgZHJhZnQtZGhvZHktcGNlLXBjZXAtZG9tYWluLXNlcXVlbmNlLTAyIGFzIGEg bmV3IFBDRSBXRw0KDQpEZWFyIGFsbCwNCg0KV2UgaGFkIGEgcHJldHR5IHN0cm9uZyBzdXBwb3J0 IGZvciBhZG9wdGluZyBkcmFmdC1kaG9keS1wY2UtcGNlcC1kb21haW4tc2VxdWVuY2UtMDIgYSBQ Q0UgV29ya2luZyBHcm91cCBkdXJpbmcgb3VyIFBDRSBXRyBtZWV0aW5nIGJ1dA0KYXMgdXN1YWwg d2UnZCBsaWtlIHRvIGNvbmZpcm0gb24gdGhlIG1haWxpbmcgbGlzdC4NCg0KQ291bGQgeW91IHBs ZWFzZSBsZXQgdXMga25vdyBpZiB5b3UgYXJlIGluIGZhdm9yL29wcG9zZWQgdG8gYWRvcHRpbmcg ZHJhZnQtZGhvZHktcGNlLXBjZXAtZG9tYWluLXNlcXVlbmNlLTAyIGFzIGEgUENFIFdHIERvY3Vt ZW50ID8NCg0KVGhhbmtzLg0KDQpKUCBhbmQgSnVsaWVuLg0K From Suresh.b.r@huawei.com Thu Mar 29 20:52:38 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF1B721F855B for ; Thu, 29 Mar 2012 20:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SjRQeaJv8So0 for ; Thu, 29 Mar 2012 20:52:38 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 32B8221F855A for ; Thu, 29 Mar 2012 20:52:38 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEM75878; Thu, 29 Mar 2012 23:52:38 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Mar 2012 20:51:39 -0700 Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Mar 2012 20:51:35 -0700 Received: from blrprnc03ns (10.18.96.92) by szxeml418-hub.china.huawei.com (10.82.67.157) with Microsoft SMTP Server id 14.1.323.3; Fri, 30 Mar 2012 11:51:29 +0800 From: Suresh To: 'JP Vasseur' , References: In-Reply-To: Date: Fri, 30 Mar 2012 09:21:19 +0530 Message-ID: <003e01cd0e28$63a8cce0$2afa66a0$@b.r@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0NyPZF1U2ilzqxRiCfkOgP6yFwnwAX1+MQ Content-Language: en-us X-Originating-IP: [10.18.96.92] X-CFilter-Loop: Reflected X-Mailman-Approved-At: Thu, 29 Mar 2012 21:22:14 -0700 Subject: Re: [Pce] Adoption of draft-pouyllau-pce-enhanced-errors-03.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 03:52:39 -0000 I support. Regards Suresh -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of JP Vasseur Sent: Thursday, March 29, 2012 9:58 PM To: pce@ietf.org Subject: [Pce] Adoption of draft-pouyllau-pce-enhanced-errors-03.txt Dear all, We had a pretty strong support for adopting draft-pouyllau-pce-enhanced-errors a PCE Working Group during our PCE WG meeting but as usual we'd like to confirm on the mailing list. Could you please let us know if you are in favor/opposed to adopting draft-pouyllau-pce-enhanced-errors as a PCE WG Document ? Thanks. JP and Julien. _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pshastry@huawei.com Fri Mar 30 00:19:22 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF0B021E8056 for ; Fri, 30 Mar 2012 00:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id elhNPRhRh6Cl for ; Fri, 30 Mar 2012 00:19:21 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6E69E21E8097 for ; Fri, 30 Mar 2012 00:19:21 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEM85860; Fri, 30 Mar 2012 03:19:21 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 30 Mar 2012 00:16:13 -0700 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 30 Mar 2012 00:16:08 -0700 Received: from BLRNSHTIPL11NC (10.18.1.41) by szxeml404-hub.china.huawei.com (10.82.67.59) with Microsoft SMTP Server id 14.1.323.3; Fri, 30 Mar 2012 15:16:05 +0800 From: Pradeepa Shastry To: 'JP Vasseur' , References: <5B30AA9C-FB42-4216-8B3B-854F13A0B93D@cisco.com> In-Reply-To: <5B30AA9C-FB42-4216-8B3B-854F13A0B93D@cisco.com> Date: Fri, 30 Mar 2012 12:46:28 +0530 Organization: htipl Message-ID: <000001cd0e45$06b9bae0$142d30a0$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01CD0E73.2071F6E0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0NyTFHRYwpTl6LSMiEqR+MsLIxiAAe79xg Content-Language: en-us X-Originating-IP: [10.18.1.41] X-CFilter-Loop: Reflected Subject: Re: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: pshastry@huawei.com List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 07:19:22 -0000 ------=_NextPart_000_0001_01CD0E73.2071F6E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I support From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of JP Vasseur Sent: Thursday, March 29, 2012 10:00 PM To: pce@ietf.org Subject: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG Dear all, We had a pretty strong support for adopting draft-dhody-pce-pcep-domain-sequence-02 a PCE Working Group during our PCE WG meeting but as usual we'd like to confirm on the mailing list. Could you please let us know if you are in favor/opposed to adopting draft-dhody-pce-pcep-domain-sequence-02 as a PCE WG Document ? Thanks. JP and Julien. ------=_NextPart_000_0001_01CD0E73.2071F6E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I support

 

From:= = pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of = JP Vasseur
Sent: Thursday, March 29, 2012 10:00 = PM
To: pce@ietf.org
Subject: [Pce] Adopting = draft-dhody-pce-pcep-domain-sequence-02 as a new PCE = WG

 

Dear = all,

 

We had a pretty strong support for adopting draft-dhody-pce-pcep-domain-sequence-02 = a PCE Working Group during our PCE WG meeting = but

as usual we'd like to = confirm on the mailing list.

 

Could you please let us know if you are in = favor/opposed to adopting = draft-dhody-pce-pcep-domain-sequence-02 as a PCE WG Document = ?

 

Thanks.

 

JP and Julien.

------=_NextPart_000_0001_01CD0E73.2071F6E0-- From pe-jiang@kddilabs.jp Fri Mar 30 00:41:03 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9522A21F872D for ; Fri, 30 Mar 2012 00:41:03 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6Og7p6YqtMU for ; Fri, 30 Mar 2012 00:41:03 -0700 (PDT) Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by ietfa.amsl.com (Postfix) with ESMTP id 7EDCF21F86EC for ; Fri, 30 Mar 2012 00:41:02 -0700 (PDT) Received: from localhost (mandala.kddilabs.jp [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 81FA2174815C; Fri, 30 Mar 2012 16:41:01 +0900 (JST) X-Virus-Scanned: amavisd-new at kddilabs.jp Received: from mandala.kddilabs.jp ([127.0.0.1]) by localhost (mandala.kddilabs.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iq6b1tMfSema; Fri, 30 Mar 2012 16:41:00 +0900 (JST) Received: from mail.cn.kddilabs.jp (yellow.lan.kddilabs.jp [172.19.98.10]) by mandala.kddilabs.jp (Postfix) with ESMTP id BCE7C1748112; Fri, 30 Mar 2012 16:40:59 +0900 (JST) Received: from [172.19.112.10] (ova010.vpn.kddilabs.jp [172.19.112.10]) by mail.cn.kddilabs.jp (Postfix) with ESMTP id 2A2291E0002; Fri, 30 Mar 2012 16:40:55 +0900 (JST) Message-ID: <4F756396.6020105@kddilabs.jp> Date: Fri, 30 Mar 2012 16:41:10 +0900 From: Peng JIANG User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: pce@ietf.org References: <5B30AA9C-FB42-4216-8B3B-854F13A0B93D@cisco.com> <000001cd0e45$06b9bae0$142d30a0$@com> In-Reply-To: <000001cd0e45$06b9bae0$142d30a0$@com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 07:41:03 -0000 Support! Peng JIANG KDDI R&D LABS (2012/03/30 16:16), Pradeepa Shastry wrote: > I support > > *From:*pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] *On Behalf Of > *JP Vasseur > *Sent:* Thursday, March 29, 2012 10:00 PM > *To:* pce@ietf.org > *Subject:* [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a > new PCE WG > > Dear all, > > We had a pretty strong support for adopting > *draft-dhody-pce-pcep-domain-sequence-02 *a PCE Working Group during our > PCE WG meeting but > > as usual we'd like to confirm on the mailing list. > > Could you please let us know if you are in favor/opposed to adopting > draft-dhody-pce-pcep-domain-sequence-02 as a PCE WG Document ? > > Thanks. > > JP and Julien. > > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce -- ‚ˆ‚—ŠéĦ˜„致—™€‚ ċ§œ€€éµĴïĵˆ‚¸ƒ£ƒ³€€ƒƒ³ïĵ‰€€ KDDI研çİĥĉ‰€ IPċ“è³ŞċˆĥċĦ‚·‚ıƒ†ƒ G TEL: +81-49-278-7879 E-mail: pe-jiang@kddilabs.jp From dhruv.dhody@huawei.com Fri Mar 30 02:16:29 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D87921F886F for ; Fri, 30 Mar 2012 02:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSZaCpVuZoiY for ; Fri, 30 Mar 2012 02:16:25 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8948621F8828 for ; Fri, 30 Mar 2012 02:16:25 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEU94669; Fri, 30 Mar 2012 05:16:25 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 30 Mar 2012 02:14:27 -0700 Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 30 Mar 2012 02:14:23 -0700 Received: from V00904246L (10.47.139.115) by szxeml419-hub.china.huawei.com (10.82.67.158) with Microsoft SMTP Server id 14.1.323.3; Fri, 30 Mar 2012 17:14:14 +0800 From: Dhruv Dhody To: , 'JP Vasseur' , References: <0e5d01cd0df8$ebed2450$c3c76cf0$@olddog.co.uk> In-Reply-To: <0e5d01cd0df8$ebed2450$c3c76cf0$@olddog.co.uk> Date: Fri, 30 Mar 2012 11:14:04 +0200 Organization: Htipl Message-ID: <011601cd0e55$76c2cf60$64486e20$@dhody@huawei.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0117_01CD0E66.3A4B9F60" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0N+HOcj1jsJ9t7TwqYufxmQg4ezQAVVRsw Content-Language: en-us X-Originating-IP: [10.47.139.115] X-CFilter-Loop: Reflected Subject: Re: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dhruv.dhody@huawei.com List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 09:16:29 -0000 ------=_NextPart_000_0117_01CD0E66.3A4B9F60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear Adrian, Thanks for your comments. Please find response inline. Regards, Dhruv From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Friday, March 30, 2012 12:12 AM To: 'JP Vasseur'; pce@ietf.org Subject: Re: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG Please accept this comment as an individual comment like all the rest. I have some reservations about adopting this document as a WG draft, but will not register to stand in its way. I understand the motive for this work and, indeed, it fills a hole in the protocol spec. I do hope that the authors are building it for shipping equipment and deployment. If not, would they please consider whether it should be experimental? [Dhruv Dhody] We will discuss among the co-authors and WG chairs on this. Here are some comments based on a very light review. I should probably read the document properly some day. I am concerned that this document changes the definition and intent contained in RFC 5440. In my opinion the authors of 5440, and the WG at the time, wen to some lengths to tie the content of objects in PCEP to the same definitions found in RFCs 3209, 3473 and 3477. At the same time, definitions of subobjects for path definition, should also pay attention to RFCs 4874 and 4920. The intention is to not define more subobjects than needed and to keep registries aligned. [Dhruv Dhody] We did try to make sure to reuse already defined subobjects but found some gaps which were handled in our document. RFC 4920 defines TLV that can be carried in IF_ID ERROR_SPEC Object to specify the AS and area, but using the TLV as a subobject breaks the definition of IRO Object. It is also worth noting how 4920 handles 2 and 4 octet AS numbers and that there is overlap in the definition of AS number subobjects with draft-zhang-pce-hierarchy-extensions-01 [Dhruv Dhody] zhang-pce-hierarchy-extensions provide this information as TLV where we define the information in subobjects format. There is an editor note in the draft in section 3.1.3 stating this. We are working closely with HPCE authors and would make sure to avoid overlaps and redefinations. In this light and on careful reading, the IANA section is somewhat broken and confused about what should be in the registry it is creating. [Dhruv Dhody] Dully Noted. But I am also unsure why a new IRO type is needed. Surely the domain sequence that is used in the computation is also the domain sequence for the path that the LSP will take. This feeds on the points below. [Dhruv Dhody] We added a new type in this revision after discussion within the WG (http://www.ietf.org/mail-archive/web/pce/current/msg02580.html) for following reasons - Better application of rules w.r.t domain sequence - define clear order of SubObjects - Different Scope within IRO - Clear Mode of Operations and handling The algorithm in 3.4: - assumes only area IDs and AS numbers - assumes that a PCE knows at least one PCE responsible for each of its neighboring domains I would like the authors to take care that the identity of a boundary node does not uniquely identify a next-hop domain (even if it may be successfully used for domain routing given the knowledge of the next domain, next boundary node, or egress node) and the text should not imply that it does. This is hidden at the end of 3.4 some time after the boundary node/link discussion. Shouldn't you allow "loose" hops in the domain path? (i.e. gaps between domains). [Dhruv Dhody] We will refine the algorithm and text to make sure above points are considerd. Can I also mix other concepts with the domain path? What about a consistent lambda, or a core node that needs to be on the path? In 3.5.7 I don't see that the domain sequence is necessarily an alternative to the PCE sequence. There are cases where even with a domain sequence, a PCE sequence is important. In 3.5.7 you have: All PCE must be aware of all other PCEs in all domain for PCE- Sequence. This is false. Although it is true that a PCE in one domain must be able to route to the IP address of a PCE in a neighboring domain. In 3.5.7 you have: There maybe multiple PCE in a domain, the selection of PCE should not be made at the PCC/PCE(1). This decision is made only at the neighboring PCE which is aware of state of PCEs via notification messages There are four points here: 1. These are unsubstantiated assertions rather than reasons. 2. All neighboring PCEs are sending each other notification messages? 3. PCE choice may be based on capabilities, not just being up 4. In HPCE, it is quite reasonable for the parent to select the children Section 5 will need loads of work because the domain sequence (even for inclusion, not reporting) provides information valuable to an attacker. [Dhruv Dhody] We would refine this section to clearly state that both PCE-Sequence and Domain-Sequence can co-exist. But there are some benefits in using domain-sequence esp when such a thing needed to be configured at PCC. I am sure the management considerations can be added within the WG process. [Dhruv Dhody] Dully Noted! Thanks, Adrian From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of JP Vasseur Sent: 29 March 2012 17:30 To: pce@ietf.org Subject: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG Dear all, We had a pretty strong support for adopting draft-dhody-pce-pcep-domain-sequence-02 a PCE Working Group during our PCE WG meeting but as usual we'd like to confirm on the mailing list. Could you please let us know if you are in favor/opposed to adopting draft-dhody-pce-pcep-domain-sequence-02 as a PCE WG Document ? Thanks. JP and Julien. ------=_NextPart_000_0117_01CD0E66.3A4B9F60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Adrian,

 

Thanks for your comments. Please find response inline. =

 

Regards,

Dhruv

 

From:= = pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of = Adrian Farrel
Sent: Friday, March 30, 2012 12:12 = AM
To: 'JP Vasseur'; pce@ietf.org
Subject: Re: [Pce] = Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE = WG

 

Please accept this comment as an individual comment like all the = rest.

 

I have some reservations about adopting this document as a WG draft, = but will not register to stand in its way.

 

I understand the motive for this work and, indeed, it fills a hole in = the protocol spec.

 

I do hope that the authors are building it for shipping equipment and = deployment. If not, would they please consider whether it should be = experimental?

 

[Dhruv Dhody] We will discuss among the co-authors and WG chairs on = this.

 

Here are some comments based on a very light review. I should = probably read the document properly some day.

 

I am concerned that this document changes the definition and intent = contained in RFC 5440. In my opinion the authors of 5440, and the WG at = the time, wen to some lengths to tie the content of objects in PCEP to = the same definitions found in RFCs 3209, 3473 and 3477. At the same = time, definitions of subobjects for path definition, should also pay = attention to RFCs 4874 and 4920. The intention is to not define more = subobjects than needed and to keep registries = aligned.

 

[Dhruv Dhody] We did try to make sure to reuse already defined = subobjects but found some gaps which were handled in our document. RFC = 4920 defines TLV that can be carried in IF_ID ERROR_SPEC Object to = specify the AS and area, but using the TLV as a subobject breaks the = definition of IRO Object.   

 

It is also worth noting how 4920  handles 2 and 4 octet AS = numbers and that there is overlap in the definition of AS number = subobjects with draft-zhang-pce-hierarchy-extensions-01

 

[Dhruv Dhody] zhang-pce-hierarchy-extensions provide this information = as TLV where we define the information in subobjects format. There is an = editor note in the draft in section 3.1.3 stating this. We are working = closely with HPCE authors and would make sure to avoid overlaps and = redefinations.

 

In this light and on careful reading, the IANA section is somewhat = broken and confused about what should be in the registry it is = creating.

[Dhruv Dhody] Dully Noted.

 

But I am also unsure why a new IRO type is needed. Surely the domain = sequence that is used in the computation is also the domain sequence for = the path that the LSP will take. This feeds on the points = below.

[Dhruv Dhody] We added a new type in this revision after discussion = within the WG (h= ttp://www.ietf.org/mail-archive/web/pce/current/msg02580.html) for = following reasons –

Better application of rules w.r.t domain = sequence

- define clear order of SubObjects

- Different Scope within IRO

- Clear Mode of Operations and = handling

 

The algorithm in 3.4:

- assumes only area IDs and AS numbers

- assumes that a PCE knows at least one PCE responsible for each = of

   its neighboring domains

 

I would like the authors to take care that the identity of a boundary = node does not uniquely identify a next-hop domain (even if it may be = successfully used for domain routing given the knowledge of the next = domain, next boundary node, or egress node) and the text should not = imply that it does. This is hidden at the end of 3.4 some time after = the  boundary node/link discussion.

 

Shouldn't you allow "loose" hops in the domain path? (i.e. = gaps between domains).

[Dhruv Dhody] We will refine the algorithm and text to make sure = above points are considerd.

 

Can I also mix other concepts with the domain path? What about a = consistent lambda, or a core node that needs to be on the = path?

 

In 3.5.7 I don't see that the domain sequence is necessarily an = alternative to the PCE sequence. There are cases where even with a = domain sequence, a PCE sequence is important.

 

In 3.5.7 you have:

      All PCE must be aware of all other = PCEs in all domain for PCE-

      Sequence.

This is false. Although it is true that a PCE in one domain must be = able to route to the IP address of a PCE in a neighboring domain. =

 

In 3.5.7 you have:

      There maybe multiple PCE in a domain, = the selection of PCE should

      not be made at the PCC/PCE(1).  = This decision is made only at the

      neighboring PCE which is aware of = state of PCEs via notification

      messages

There are four points here:

1. These are unsubstantiated assertions rather than = reasons.

2. All neighboring PCEs are sending each other notification = messages?

3. PCE choice may be based on capabilities, not just being = up

4. In HPCE, it is quite reasonable for the parent to select the = children

 

Section 5 will need loads of work because the domain sequence (even = for inclusion, not reporting) provides information valuable to an = attacker.

[Dhruv Dhody] We would refine this section to clearly state that both = PCE-Sequence and Domain-Sequence can co-exist. But there are some = benefits in using domain-sequence esp when such a thing needed to be = configured at PCC.

 

I am sure the management considerations can be added within the WG = process.

[Dhruv Dhody] Dully Noted!

 

Thanks,

Adrian

 

 

From:= = pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of = JP Vasseur
Sent: 29 March 2012 17:30
To: = pce@ietf.org
Subject: [Pce] Adopting = draft-dhody-pce-pcep-domain-sequence-02 as a new PCE = WG

 

Dear all,

 

We had a pretty strong support for = adopting draft-dhody-pce-pcep-domain-sequence-02 = a PCE Working Group during our PCE WG meeting = but

as usual we'd like to confirm on the mailing = list.

 

Could you please let us know if you = are in favor/opposed to adopting = draft-dhody-pce-pcep-domain-sequence-02 as a PCE WG Document = ?

 

Thanks.

 

JP and = Julien.

------=_NextPart_000_0117_01CD0E66.3A4B9F60-- From jpv@cisco.com Fri Mar 30 04:15:58 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6F6E21F87CB for ; Fri, 30 Mar 2012 04:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.598 X-Spam-Level: X-Spam-Status: No, score=-108.598 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8gm+B3G0t-D for ; Fri, 30 Mar 2012 04:15:57 -0700 (PDT) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 3019F21F8786 for ; Fri, 30 Mar 2012 04:15:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=31935; q=dns/txt; s=iport; t=1333106155; x=1334315755; h=from:mime-version:subject:date:in-reply-to:to:references: message-id; bh=lL1UVKuiPhwMoFfsJP7yzUiYpsZMDk99cSv337Stb+g=; b=CSnpWwQgeLR1ukEsNDQKXWFAScgT8uewnl8/11pTEgDSRJfAr7WaIXuM DVFXibgScgcXuD091o+w7ALdKMjw/IyVfMRfjNmpPnWkWLSQKkhemlGkm /KEw/fguqpXdttws48YBJhGSKI91V6BKhKv7cLwvNxB21sPHf8sehhFM1 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao4FAKWUdU9Io8UY/2dsb2JhbAA6AQmCRUm2X4IJAQEBAwESAVsQCwsRBAEBIQEGB0YJCAYBEAIih2IFm1OfFop2AYU2YwSVY4VwiFaBaIJpPA X-IronPort-AV: E=Sophos;i="4.75,342,1330905600"; d="scan'208,217";a="8973017" Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 30 Mar 2012 11:15:53 +0000 Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2UBFqTf005553; Fri, 30 Mar 2012 11:15:52 GMT Received: from xfe-hkg-412.apac.cisco.com ([64.104.123.71]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Mar 2012 19:15:52 +0800 Received: from [10.60.114.237] ([10.60.114.237]) by xfe-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Mar 2012 19:15:50 +0800 From: JP Vasseur Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_E854A672-2F19-4103-8FE8-4B6B7C9C1694" Date: Fri, 30 Mar 2012 13:15:48 +0200 In-Reply-To: <0e5d01cd0df8$ebed2450$c3c76cf0$@olddog.co.uk> To: pce@ietf.org, Adrian Farrel References: <0e5d01cd0df8$ebed2450$c3c76cf0$@olddog.co.uk> Message-Id: <0ABEE34E-BD75-44B9-BF04-B3A2D28635AE@cisco.com> X-Mailer: Apple Mail (2.1257) X-OriginalArrivalTime: 30 Mar 2012 11:15:51.0224 (UTC) FILETIME=[7728FB80:01CD0E66] Subject: Re: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 11:15:59 -0000 --Apple-Mail=_E854A672-2F19-4103-8FE8-4B6B7C9C1694 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Many Thanks Adrian - Authors, could you please address the points listed = below ? Thanks. JP. On Mar 30, 2012, at 12:11 AM, Adrian Farrel wrote: > Please accept this comment as an individual comment like all the rest. > =20 > I have some reservations about adopting this document as a WG draft, = but will not register to stand in its way. > =20 > I understand the motive for this work and, indeed, it fills a hole in = the protocol spec. > =20 > I do hope that the authors are building it for shipping equipment and = deployment. If not, would they please consider whether it should be = experimental? > =20 > Here are some comments based on a very light review. I should probably = read the document properly some day. > =20 > I am concerned that this document changes the definition and intent = contained in RFC 5440. In my opinion the authors of 5440, and the WG at = the time, wen to some lengths to tie the content of objects in PCEP to = the same definitions found in RFCs 3209, 3473 and 3477. At the same = time, definitions of subobjects for path definition, should also pay = attention to RFCs 4874 and 4920. The intention is to not define more = subobjects than needed and to keep registries aligned. > =20 > It is also worth noting how 4920 handles 2 and 4 octet AS numbers and = that there is overlap in the definition of AS number subobjects with = draft-zhang-pce-hierarchy-extensions-01 > =20 > In this light and on careful reading, the IANA section is somewhat = broken and confused about what should be in the registry it is creating. > =20 > But I am also unsure why a new IRO type is needed. Surely the domain = sequence that is used in the computation is also the domain sequence for = the path that the LSP will take. This feeds on the points below. > =20 > The algorithm in 3.4: > - assumes only area IDs and AS numbers > - assumes that a PCE knows at least one PCE responsible for each of > its neighboring domains > =20 > I would like the authors to take care that the identity of a boundary = node does not uniquely identify a next-hop domain (even if it may be = successfully used for domain routing given the knowledge of the next = domain, next boundary node, or egress node) and the text should not = imply that it does. This is hidden at the end of 3.4 some time after the = boundary node/link discussion. > =20 > Shouldn't you allow "loose" hops in the domain path? (i.e. gaps = between domains). > =20 > Can I also mix other concepts with the domain path? What about a = consistent lambda, or a core node that needs to be on the path? > =20 > In 3.5.7 I don't see that the domain sequence is necessarily an = alternative to the PCE sequence. There are cases where even with a = domain sequence, a PCE sequence is important. > =20 > In 3.5.7 you have: > All PCE must be aware of all other PCEs in all domain for PCE- > Sequence. > This is false. Although it is true that a PCE in one domain must be = able to route to the IP address of a PCE in a neighboring domain. > =20 > In 3.5.7 you have: > There maybe multiple PCE in a domain, the selection of PCE = should > not be made at the PCC/PCE(1). This decision is made only at = the > neighboring PCE which is aware of state of PCEs via notification > messages > There are four points here: > 1. These are unsubstantiated assertions rather than reasons. > 2. All neighboring PCEs are sending each other notification messages? > 3. PCE choice may be based on capabilities, not just being up > 4. In HPCE, it is quite reasonable for the parent to select the = children > =20 > Section 5 will need loads of work because the domain sequence (even = for inclusion, not reporting) provides information valuable to an = attacker. > =20 > I am sure the management considerations can be added within the WG = process. > =20 > Thanks, > Adrian > =20 > =20 > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of = JP Vasseur > Sent: 29 March 2012 17:30 > To: pce@ietf.org > Subject: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a = new PCE WG > =20 > Dear all, > =20 > We had a pretty strong support for adopting = draft-dhody-pce-pcep-domain-sequence-02 a PCE Working Group during our = PCE WG meeting but > as usual we'd like to confirm on the mailing list. > =20 > Could you please let us know if you are in favor/opposed to adopting = draft-dhody-pce-pcep-domain-sequence-02 as a PCE WG Document ? > =20 > Thanks. > =20 > JP and Julien. --Apple-Mail=_E854A672-2F19-4103-8FE8-4B6B7C9C1694 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi,

Many Thanks Adrian - = Authors, could you please address the points listed below = ?

Thanks.

JP.
On Mar 30, 2012, at 12:11 AM, Adrian Farrel = wrote:

Please accept this = comment as an individual comment like all the = rest.
I = have some reservations about adopting this document as a WG draft, but = will not register to stand in its way.
I = understand the motive for this work and, indeed, it fills a hole in the = protocol spec.
I do = hope that the authors are building it for shipping equipment and = deployment. If not, would they please consider whether it should be = experimental?
Here = are some comments based on a very light review. I should probably read = the document properly some day.
I am = concerned that this document changes the definition and intent contained = in RFC 5440. In my opinion the authors of 5440, and the WG at the time, = wen to some lengths to tie the content of objects in PCEP to the same = definitions found in RFCs 3209, 3473 and 3477. At the same time, = definitions of subobjects for path definition, should also pay attention = to RFCs 4874 and 4920. The intention is to not define more subobjects = than needed and to keep registries = aligned.

<= br>

It is = also worth noting how 4920  handles 2 and 4 = octet AS numbers and that there is overlap in the definition of AS = number subobjects with = draft-zhang-pce-hierarchy-extensions-01
In = this light and on careful reading, the IANA section is somewhat broken = and confused about what should be in the registry it is = creating.
But I = am also unsure why a new IRO type is needed. Surely the domain sequence = that is used in the computation is also the domain sequence for the path = that the LSP will take. This feeds on the points = below.
The = algorithm in 3.4:
- = assumes only area IDs and AS numbers
- assumes that a PCE knows at = least one PCE responsible for each of
   its neighboring = domains
I = would like the authors to take care that the identity of a boundary node = does not uniquely identify a next-hop domain (even if it may be = successfully used for domain routing given the knowledge of the next = domain, next boundary node, or egress node) and the text should not = imply that it does. This is hidden at the end of 3.4 some time after = the  boundary node/link = discussion.
Can I = also mix other concepts with the domain path? What about a consistent = lambda, or a core node that needs to be on the = path?
In = 3.5.7 I don't see that the domain sequence is necessarily an alternative = to the PCE sequence. There are cases where even with a domain sequence, = a PCE sequence is important.
In = 3.5.7 you have:
 All PCE must be = aware of all other PCEs in all domain for = PCE-
 Sequence.
This is false. Although = it is true that a PCE in one domain must be able to route to the IP = address of a PCE in a neighboring domain.
In = 3.5.7 you have:
 There maybe multiple = PCE in a domain, the selection of PCE should
 not be made at the = PCC/PCE(1).  This decision is = made only at the
 neighboring PCE = which is aware of state of PCEs via = notification
 messages
There are four points = here:
1. = These are unsubstantiated assertions rather than = reasons.
2. = All neighboring PCEs are sending each other notification = messages?
3. = PCE choice may be based on capabilities, not just being = up
4. In HPCE, = it is quite reasonable for the parent to select the = children
I am = sure the management considerations can be added within the WG = process.
 pce-bounces@ietf.org [mailto:pce-bounces@ietf.org]=  On Behalf Of JP = Vasseur
Sent: 29 March 2012 = 17:30
To: pce@ietf.org
Subject: [Pce] Adopting = draft-dhody-pce-pcep-domain-sequence-02 as a new PCE = WG
Dear = all,
We had a = pretty strong support for adopting draft-dhody-pce-pcep-domain-sequence-02 a PCE Working = Group during our PCE WG meeting = but
as usual we'd like = to confirm on the mailing list.
 
Could you please let us know if you are in = favor/opposed to adopting = draft-dhody-pce-pcep-domain-sequence-02 as a PCE WG Document = ?
 
JP and = Julien.

= --Apple-Mail=_E854A672-2F19-4103-8FE8-4B6B7C9C1694-- From reeja.paul@huawei.com Fri Mar 30 04:19:10 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21F8421F86AB for ; Fri, 30 Mar 2012 04:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oCDBwQe+cbCy for ; Fri, 30 Mar 2012 04:19:08 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id A6C9421F869A for ; Fri, 30 Mar 2012 04:19:08 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEM97424; Fri, 30 Mar 2012 07:19:06 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 30 Mar 2012 04:17:56 -0700 Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 30 Mar 2012 04:18:03 -0700 Received: from blrprnc08ns (10.18.96.97) by szxeml413-hub.china.huawei.com (10.82.67.152) with Microsoft SMTP Server id 14.1.323.3; Fri, 30 Mar 2012 19:17:57 +0800 From: Reeja Paul To: References: In-Reply-To: Date: Fri, 30 Mar 2012 16:47:56 +0530 Message-ID: <000001cd0e66$c22e9c20$468bd460$@paul@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: Ac0OVd+Z5khvJomhQEyH3yacdgBhewAELxRw Content-Language: en-us X-Originating-IP: [10.18.96.97] X-CFilter-Loop: Reflected Subject: Re: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG (Reeja Paul) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 11:19:10 -0000 I Support. Thanks & Regards Reeja Paul ---------------------------------------------------------------------------- --------------------------------------------------------- This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of pce-request@ietf.org Sent: Friday, March 30, 2012 2:46 PM To: pce@ietf.org Subject: Pce Digest, Vol 91, Issue 16 If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to https://www.ietf.org/mailman/listinfo/pce Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send Pce mailing list submissions to pce@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/pce or, via email, send a message with subject or body 'help' to pce-request@ietf.org You can reach the person managing the list at pce-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Pce digest..." Today's Topics: 1. ??: Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG (Fatai Zhang) 2. Re: Adoption of draft-pouyllau-pce-enhanced-errors-03.txt (Suresh) 3. Re: Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG (Pradeepa Shastry) 4. Re: Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG (Peng JIANG) 5. Re: Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG (Dhruv Dhody) ---------------------------------------------------------------------- Message: 1 Date: Thu, 29 Mar 2012 23:19:14 +0000 From: Fatai Zhang To: JP Vasseur , "pce@ietf.org" Subject: [Pce] ??: Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG Message-ID: Content-Type: text/plain; charset="gb2312" Yes, support. Thanks Fatai ________________________________________ ???: pce-bounces@ietf.org [pce-bounces@ietf.org] ?? JP Vasseur [jpv@cisco.com] ????: 2012?3?30? 0:29 ?: pce@ietf.org ??: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG Dear all, We had a pretty strong support for adopting draft-dhody-pce-pcep-domain-sequence-02 a PCE Working Group during our PCE WG meeting but as usual we'd like to confirm on the mailing list. Could you please let us know if you are in favor/opposed to adopting draft-dhody-pce-pcep-domain-sequence-02 as a PCE WG Document ? Thanks. JP and Julien. ------------------------------ Message: 2 Date: Fri, 30 Mar 2012 09:21:19 +0530 From: Suresh To: 'JP Vasseur' , Subject: Re: [Pce] Adoption of draft-pouyllau-pce-enhanced-errors-03.txt Message-ID: <003e01cd0e28$63a8cce0$2afa66a0$@b.r@huawei.com> Content-Type: text/plain; charset="us-ascii" I support. Regards Suresh -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of JP Vasseur Sent: Thursday, March 29, 2012 9:58 PM To: pce@ietf.org Subject: [Pce] Adoption of draft-pouyllau-pce-enhanced-errors-03.txt Dear all, We had a pretty strong support for adopting draft-pouyllau-pce-enhanced-errors a PCE Working Group during our PCE WG meeting but as usual we'd like to confirm on the mailing list. Could you please let us know if you are in favor/opposed to adopting draft-pouyllau-pce-enhanced-errors as a PCE WG Document ? Thanks. JP and Julien. _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce ------------------------------ Message: 3 Date: Fri, 30 Mar 2012 12:46:28 +0530 From: Pradeepa Shastry To: 'JP Vasseur' , Subject: Re: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG Message-ID: <000001cd0e45$06b9bae0$142d30a0$@com> Content-Type: text/plain; charset="us-ascii" I support From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of JP Vasseur Sent: Thursday, March 29, 2012 10:00 PM To: pce@ietf.org Subject: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG Dear all, We had a pretty strong support for adopting draft-dhody-pce-pcep-domain-sequence-02 a PCE Working Group during our PCE WG meeting but as usual we'd like to confirm on the mailing list. Could you please let us know if you are in favor/opposed to adopting draft-dhody-pce-pcep-domain-sequence-02 as a PCE WG Document ? Thanks. JP and Julien. -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 4 Date: Fri, 30 Mar 2012 16:41:10 +0900 From: Peng JIANG To: pce@ietf.org Subject: Re: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG Message-ID: <4F756396.6020105@kddilabs.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Support! Peng JIANG KDDI R&D LABS (2012/03/30 16:16), Pradeepa Shastry wrote: > I support > > *From:*pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] *On Behalf Of > *JP Vasseur > *Sent:* Thursday, March 29, 2012 10:00 PM > *To:* pce@ietf.org > *Subject:* [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a > new PCE WG > > Dear all, > > We had a pretty strong support for adopting > *draft-dhody-pce-pcep-domain-sequence-02 *a PCE Working Group during our > PCE WG meeting but > > as usual we'd like to confirm on the mailing list. > > Could you please let us know if you are in favor/opposed to adopting > draft-dhody-pce-pcep-domain-sequence-02 as a PCE WG Document ? > > Thanks. > > JP and Julien. > > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce -- ???????????? ???????????? KDDI??? IP????????G TEL: +81-49-278-7879 E-mail: pe-jiang@kddilabs.jp ------------------------------ Message: 5 Date: Fri, 30 Mar 2012 11:14:04 +0200 From: Dhruv Dhody To: , 'JP Vasseur' , Subject: Re: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG Message-ID: <011601cd0e55$76c2cf60$64486e20$@dhody@huawei.com> Content-Type: text/plain; charset="us-ascii" Dear Adrian, Thanks for your comments. Please find response inline. Regards, Dhruv From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Friday, March 30, 2012 12:12 AM To: 'JP Vasseur'; pce@ietf.org Subject: Re: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG Please accept this comment as an individual comment like all the rest. I have some reservations about adopting this document as a WG draft, but will not register to stand in its way. I understand the motive for this work and, indeed, it fills a hole in the protocol spec. I do hope that the authors are building it for shipping equipment and deployment. If not, would they please consider whether it should be experimental? [Dhruv Dhody] We will discuss among the co-authors and WG chairs on this. Here are some comments based on a very light review. I should probably read the document properly some day. I am concerned that this document changes the definition and intent contained in RFC 5440. In my opinion the authors of 5440, and the WG at the time, wen to some lengths to tie the content of objects in PCEP to the same definitions found in RFCs 3209, 3473 and 3477. At the same time, definitions of subobjects for path definition, should also pay attention to RFCs 4874 and 4920. The intention is to not define more subobjects than needed and to keep registries aligned. [Dhruv Dhody] We did try to make sure to reuse already defined subobjects but found some gaps which were handled in our document. RFC 4920 defines TLV that can be carried in IF_ID ERROR_SPEC Object to specify the AS and area, but using the TLV as a subobject breaks the definition of IRO Object. It is also worth noting how 4920 handles 2 and 4 octet AS numbers and that there is overlap in the definition of AS number subobjects with draft-zhang-pce-hierarchy-extensions-01 [Dhruv Dhody] zhang-pce-hierarchy-extensions provide this information as TLV where we define the information in subobjects format. There is an editor note in the draft in section 3.1.3 stating this. We are working closely with HPCE authors and would make sure to avoid overlaps and redefinations. In this light and on careful reading, the IANA section is somewhat broken and confused about what should be in the registry it is creating. [Dhruv Dhody] Dully Noted. But I am also unsure why a new IRO type is needed. Surely the domain sequence that is used in the computation is also the domain sequence for the path that the LSP will take. This feeds on the points below. [Dhruv Dhody] We added a new type in this revision after discussion within the WG (http://www.ietf.org/mail-archive/web/pce/current/msg02580.html) for following reasons - Better application of rules w.r.t domain sequence - define clear order of SubObjects - Different Scope within IRO - Clear Mode of Operations and handling The algorithm in 3.4: - assumes only area IDs and AS numbers - assumes that a PCE knows at least one PCE responsible for each of its neighboring domains I would like the authors to take care that the identity of a boundary node does not uniquely identify a next-hop domain (even if it may be successfully used for domain routing given the knowledge of the next domain, next boundary node, or egress node) and the text should not imply that it does. This is hidden at the end of 3.4 some time after the boundary node/link discussion. Shouldn't you allow "loose" hops in the domain path? (i.e. gaps between domains). [Dhruv Dhody] We will refine the algorithm and text to make sure above points are considerd. Can I also mix other concepts with the domain path? What about a consistent lambda, or a core node that needs to be on the path? In 3.5.7 I don't see that the domain sequence is necessarily an alternative to the PCE sequence. There are cases where even with a domain sequence, a PCE sequence is important. In 3.5.7 you have: All PCE must be aware of all other PCEs in all domain for PCE- Sequence. This is false. Although it is true that a PCE in one domain must be able to route to the IP address of a PCE in a neighboring domain. In 3.5.7 you have: There maybe multiple PCE in a domain, the selection of PCE should not be made at the PCC/PCE(1). This decision is made only at the neighboring PCE which is aware of state of PCEs via notification messages There are four points here: 1. These are unsubstantiated assertions rather than reasons. 2. All neighboring PCEs are sending each other notification messages? 3. PCE choice may be based on capabilities, not just being up 4. In HPCE, it is quite reasonable for the parent to select the children Section 5 will need loads of work because the domain sequence (even for inclusion, not reporting) provides information valuable to an attacker. [Dhruv Dhody] We would refine this section to clearly state that both PCE-Sequence and Domain-Sequence can co-exist. But there are some benefits in using domain-sequence esp when such a thing needed to be configured at PCC. I am sure the management considerations can be added within the WG process. [Dhruv Dhody] Dully Noted! Thanks, Adrian From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of JP Vasseur Sent: 29 March 2012 17:30 To: pce@ietf.org Subject: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG Dear all, We had a pretty strong support for adopting draft-dhody-pce-pcep-domain-sequence-02 a PCE Working Group during our PCE WG meeting but as usual we'd like to confirm on the mailing list. Could you please let us know if you are in favor/opposed to adopting draft-dhody-pce-pcep-domain-sequence-02 as a PCE WG Document ? Thanks. JP and Julien. -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce End of Pce Digest, Vol 91, Issue 16 *********************************** From ramon.casellas@cttc.es Sat Mar 31 02:27:38 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 885BA21F84A7 for ; Sat, 31 Mar 2012 02:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1opZfjM4Vw4 for ; Sat, 31 Mar 2012 02:27:37 -0700 (PDT) Received: from Scorpius.cttc.es (scorpius.cttc.es [84.88.62.197]) by ietfa.amsl.com (Postfix) with ESMTP id 113E021F849D for ; Sat, 31 Mar 2012 02:27:35 -0700 (PDT) Received: from castor (postfix@castor.cttc.es [84.88.62.196]) by Scorpius.cttc.es (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q2V9RBh0002890 for ; Sat, 31 Mar 2012 11:27:16 +0200 Received: from [192.168.0.100] (62.57.44.55.dyn.user.ono.com [62.57.44.55]) by castor (Postfix) with ESMTP id 7C6852FC250 for ; Sat, 31 Mar 2012 11:27:21 +0200 (CEST) Message-ID: <4F76CDFC.6010704@cttc.es> Date: Sat, 31 Mar 2012 11:27:24 +0200 From: Ramon Casellas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "pce@ietf.org" References: <0e5d01cd0df8$ebed2450$c3c76cf0$@olddog.co.uk> <0ABEE34E-BD75-44B9-BF04-B3A2D28635AE@cisco.com> In-Reply-To: <0ABEE34E-BD75-44B9-BF04-B3A2D28635AE@cisco.com> Content-Type: multipart/alternative; boundary="------------070605010205050602040907" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (castor); Sat, 31 Mar 2012 11:27:21 +0200 (CEST) X-Scanned-By: MIMEDefang 2.67 on 84.88.62.197 Subject: Re: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 09:27:38 -0000 This is a multi-part message in MIME format. --------------070605010205050602040907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit El 30/03/2012 13:15, JP Vasseur escribió: > Many Thanks Adrian - Authors, could you please address the points > listed below ? > Adrian, JP, all Thank you for your review and comments. They do indeed point out areas that need substantial work. Please find inline my thoughts, in addition to the ones Dhruv sent. Sorry for the length of the mail and my tendency to be too verbose... > On Mar 30, 2012, at 12:11 AM, Adrian Farrel wrote: > >> I have some reservations about adopting this document as a WG draft, >> but will not register to stand in its way. >> I understand the motive for this work and, indeed, it fills a hole in >> the protocol spec. [Ramon] if you could elaborate a bit more on which hole(s) exactly, I would make sure that we can come up with a more satisfactory proposal, e.g a) the lack of (some?) route sub-objects for domain encodings, b) the ordering constraints, c) decoupling and relationship between PCE-sequences and domain-sequences? (personally, I find a) and b) more important.) >> >> I do hope that the authors are building it for shipping equipment and >> deployment. If not, would they please consider whether it should be >> experimental? [Ramon] I have no objection at being experimental, what option the WG things more appropriate is fine for me. >> I am concerned that this document changes the definition and intent >> contained in RFC 5440. In my opinion the authors of 5440, and the WG >> at the time, wen to some lengths to tie the content of objects in >> PCEP to the same definitions found in RFCs 3209, 3473 and 3477. At >> the same time, definitions of subobjects for path definition, should >> also pay attention to RFCs 4874 and 4920. The intention is to not >> define more subobjects than needed and to keep registries aligned > [Ramon] agreed, and this is the intention. See also my other comments below [Ramon] I would really appreciate your thoughts on whether [E/X/R/I]RO sub-objects for OSPF-TE areas and IS-IS areas are needed, as well as 4-byte AS (unlike TLVs, 4 byte AS and 2-byte AS sub-objects cannot share the encoding). This is in line with your concern whether more sub-objects are needed or not, which should also be brought to ccamp attention as well. Some (initial, loose) discussions on the need for IGP sub-objects were indirectly discussed in http://www.ietf.org/mail-archive/web/pce/current/msg02561.html > >> It is also worth noting how 4920handles 2 and 4 octet AS numbers and >> that there is overlap in the definition of AS number subobjects with >> draft-zhang-pce-hierarchy-extensions-01 [Ramon] We had considered 4920 for this, although the proposed encodings are as TLVs (for IF_ID ERROR_SPEC objects) and this i.-d. work was (arguably) regarding route objects. I agree that, as TLV encodings, a single 4 byte encoding for both 2-4 bytes AS makes a lot of sense, specially since the 16-bit sub-registry is common. This would also solve the problems regarding IGP areas. If I may, what kind of encoding would you suggest? In previous discussions it was suggested that we should use the IRO for the problem we were trying to solve , which somehow precludes the use of TLVs unless wrapped in a ERO subobject (had we been given the green light for a new object, which is not necessarily the right thing to do, I would be happy to use 4920 tlv encodings for this) [Ramon] AS number subobjects and all common IANA registry requests between this draft and draft-zhang-pce-hierarchy-extensions-01 MUST be unified and being involved in both we make sure they will. >> In this light and on careful reading, the IANA section is somewhat >> broken and confused about what should be in the registry it is creating. [Ramon] agreed, and most importantly, it must also be brought to ccamp attention as well. >> But I am also unsure why a new IRO type is needed. Surely the domain >> sequence that is used in the computation is also the domain sequence >> for the path that the LSP will take. This feeds on the points below. [Ramon] The main rationale behind this discriminator is the ordering constraint, since (my guess) no ordering assumption could be inferred from rfc5440. IIRC this was confirmed (I am sorry I wasn't in Taipei, I may be wrong). Quoted from a past mail: http://www.ietf.org/mail-archive/web/pce/current/msg02580.html "Unfortunately RFC5440 does not mention anything regarding sub-object ordering, it only says "to specify that the computed path MUST traverse a set of specified network elements" and does not include some text in the spirit of "Objects within an IRO object MUST appear in the resulting ERO in the same order that they appear in the IRO". Unless I am mistaken, this means that, at least in theory, we should not make assumptions whether the sub-objects included in the IRO shall appear in the resulting ERO in the same relative ordering". As an RFC 5440 co-author maybe you can comment on this? is the ordering implicit? In any case, the actual solution and encoding is open to discussion. IF the ordering inclusion is implicit, I have no objection for using the existing IRO and this includes your subsequent concerns with its contents. >> The algorithm in 3.4: >> - assumes only area IDs and AS numbers >> - assumes that a PCE knows at least one PCE responsible for each of >> its neighboring domains [Ramon] afaik, the algorithm was added recently in order to simplify the (apparently overkill and over-)specification of the IRO sub-objects which was also proposed by me in the aforementioned mail web/pce/current/msg02580.html (which tried, as a informational exercise, to also capture intra-domain objects). The motivation behind both is to clarify its usage. Depending on the outcomes of this and further discussions they can be elaborated, removed (by relying on the existing documents) or clarified. >> I would like the authors to take care that the identity of a boundary >> node does not uniquely identify a next-hop domain (even if it may be >> successfully used for domain routing given the knowledge of the next >> domain, next boundary node, or egress node) and the text should not >> imply that it does. This is hidden at the end of 3.4 some time after >> theboundary node/link discussion. [Ramon] point taken. we will review the text accordingly. >> Shouldn't you allow "loose" hops in the domain path? (i.e. gaps >> between domains). I don't see any special reason why we shouldn't, although one concern I have is how would this relate to RFC5440 statement "The L bit of such sub-object has no meaning within an IRO"? >> Can I also mix other concepts with the domain path? What about a >> consistent lambda, or a core node that needs to be on the path? [Ramon] IMHO, there are two (decoupled) points here: a) whether the current IRO has ordering constraints or not b) If a new IRO is needed whether only domain-related info is conveyed. An (authoritative ;-) ) answer for a) would be much appreciated. There was also the concern of separating the roles of intra-domain path computation IRO and the resolution of PCEs in a collaborative setting. For b), if we agree on the idea "the new object type imposes ordering constraints" I would not be against being like any other IRO. With a new IRO type we can be more concrete regarding the role of the must-process p-bit, what to do with unknown objects (locally to a PCE) i.e., nothing is said in IRO and XRO objects what the procedures are when a sub-object is "not found" (in the TED?). From the mail: "it is not clear to me what should be the default procedure for an unkonwn IRO subobject. It could be ignored or it could trigger an error. If we apply this to the domain sequence, I would say that an unknown subobject at this level should trigger some kind of high level error, like "PCE domain chain broken" or similar" >> In 3.5.7 I don't see that the domain sequence is necessarily an >> alternative to the PCE sequence. There are cases where even with a >> domain sequence, a PCE sequence is important. [Ramon] Personally, (although we still need to discuss it more) I don't see domain-sequence and pce-sequence as exclusive and I agree they can coexist. The whole 3.5.7 needs to be revisted, including J.P. comments during the meeting that some assertions were false (which is true, brpc may benefit from a domain sequence but does not require it) >> Section 5 will need loads of work because the domain sequence (even >> for inclusion, not reporting) provides information valuable to an >> attacker. [Ramon] agreed. Thanks again, Ramon --------------070605010205050602040907 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit El 30/03/2012 13:15, JP Vasseur escribió:
Many Thanks Adrian - Authors, could you please address the points listed below ?


Adrian, JP, all

Thank you for your review and comments. They do indeed point out areas that need substantial work.

Please find inline my thoughts, in addition to the ones Dhruv sent. Sorry for the length of the mail and my tendency to be too verbose...


On Mar 30, 2012, at 12:11 AM, Adrian Farrel wrote:

 
I have some reservations about adopting this document as a WG draft, but will not register to stand in its way.
 
I understand the motive for this work and, indeed, it fills a hole in the protocol spec.
[Ramon] if you could elaborate a bit more on which hole(s) exactly, I would make sure that we can come up with a more satisfactory proposal, e.g a) the lack of (some?) route sub-objects for domain encodings, b) the ordering constraints, c) decoupling and relationship between PCE-sequences and domain-sequences? (personally, I find a) and b) more important.)


 
I do hope that the authors are building it for shipping equipment and deployment. If not, would they please consider whether it should be experimental?
 
[Ramon] I have no objection at being experimental, what option the WG things more appropriate is fine for me.

 
I am concerned that this document changes the definition and intent contained in RFC 5440. In my opinion the authors of 5440, and the WG at the time, wen to some lengths to tie the content of objects in PCEP to the same definitions found in RFCs 3209, 3473 and 3477. At the same time, definitions of subobjects for path definition, should also pay attention to RFCs 4874 and 4920. The intention is to not define more subobjects than needed and to keep registries aligned

[Ramon] agreed, and this is the intention. See also my other comments below

[Ramon] I would really appreciate your thoughts on whether  [E/X/R/I]RO sub-objects for OSPF-TE areas and IS-IS areas are needed, as well as 4-byte AS (unlike TLVs, 4 byte AS and 2-byte AS sub-objects cannot share the encoding). This is in line with your concern whether more sub-objects are needed or not, which should also be brought to ccamp attention as well.

Some (initial, loose) discussions on the need for IGP sub-objects were indirectly discussed in http://www.ietf.org/mail-archive/web/pce/current/msg02561.html



 
It is also worth noting how 4920  handles 2 and 4 octet AS numbers and that there is overlap in the definition of AS number subobjects with draft-zhang-pce-hierarchy-extensions-01
[Ramon] We had considered 4920 for this, although the proposed encodings are as TLVs (for IF_ID ERROR_SPEC objects) and this i.-d. work was (arguably) regarding route objects. I agree that, as TLV encodings, a single 4 byte encoding for both 2-4 bytes AS makes a lot of sense, specially since the 16-bit sub-registry is common. This would also solve the problems regarding IGP areas.

If I may, what kind of encoding would you suggest? In previous discussions it was suggested that we should use the IRO for the problem we were trying to solve , which somehow precludes the use of TLVs unless wrapped in a ERO subobject (had we been given the green light for a new object, which is not necessarily the right thing to do, I would be happy to use 4920 tlv encodings for this)


[Ramon] AS number subobjects and all common IANA registry requests between this draft and draft-zhang-pce-hierarchy-extensions-01 MUST be unified and being involved in both we make sure they will.

 
In this light and on careful reading, the IANA section is somewhat broken and confused about what should be in the registry it is creating.
 
[Ramon] agreed, and most importantly, it must also be brought to ccamp attention as well.

But I am also unsure why a new IRO type is needed. Surely the domain sequence that is used in the computation is also the domain sequence for the path that the LSP will take. This feeds on the points below.
 
[Ramon] The main rationale behind this discriminator is the ordering constraint, since (my guess) no ordering assumption could be inferred from rfc5440. IIRC this was confirmed (I am sorry I wasn't in Taipei, I may be wrong).
Quoted from a past mail: http://www.ietf.org/mail-archive/web/pce/current/msg02580.html

"Unfortunately RFC5440 does not mention anything regarding sub-object ordering, it only says "to specify that the computed path MUST traverse  a set of specified network elements" and does not include some text in the spirit of "Objects within an IRO object MUST appear in the resulting ERO in the same order that they appear in the IRO". Unless I am mistaken, this means that, at least in theory, we should not make assumptions whether the sub-objects included in the IRO shall appear in the resulting ERO in the same relative ordering". As an RFC 5440 co-author  maybe you can comment on this? is the ordering implicit?

In any case, the actual solution and encoding is open to discussion. IF the ordering inclusion is implicit, I have no objection for using the existing IRO and this includes your subsequent concerns with its contents.


The algorithm in 3.4:
- assumes only area IDs and AS numbers
- assumes that a PCE knows at least one PCE responsible for each of
   its neighboring domains
 
[Ramon] afaik, the algorithm was added recently in order to simplify the (apparently overkill and over-)specification of the IRO sub-objects which was also proposed by me in the aforementioned mail web/pce/current/msg02580.html (which tried, as a informational exercise, to also capture intra-domain objects). The motivation behind both is to clarify its usage. Depending on the outcomes of this and further discussions they can be elaborated, removed (by relying on the existing documents) or clarified.

I would like the authors to take care that the identity of a boundary node does not uniquely identify a next-hop domain (even if it may be successfully used for domain routing given the knowledge of the next domain, next boundary node, or egress node) and the text should not imply that it does. This is hidden at the end of 3.4 some time after the  boundary node/link discussion.
[Ramon] point taken. we will review the text accordingly.


 
Shouldn't you allow "loose" hops in the domain path? (i.e. gaps between domains).
I don't see any special reason why we shouldn't, although one concern I have is how would this relate to RFC5440 statement "The L bit of such sub-object has no meaning within an IRO"?

 
Can I also mix other concepts with the domain path? What about a consistent lambda, or a core node that needs to be on the path?
 
[Ramon] IMHO, there are two (decoupled) points here:

a) whether the current IRO has ordering constraints or not

b) If a new IRO is needed whether only domain-related info is conveyed.

An (authoritative ;-) ) answer for a) would be much appreciated. There was also the concern of separating the roles of intra-domain path computation IRO and the resolution of PCEs in a collaborative setting. For b), if we agree on the idea "the new object type imposes ordering constraints" I would not be against being like any other IRO. With a new IRO type we can be more concrete regarding the role of the must-process p-bit, what to do with unknown objects (locally to a PCE) i.e., nothing is said in IRO and XRO objects what the procedures are when a sub-object is "not found" (in the TED?). From the mail: "it is not clear to me what should be the default procedure for an unkonwn IRO subobject. It could be ignored or it could trigger an error. If we apply this to the domain sequence, I would say that an unknown subobject at this level should trigger some kind of high level error, like "PCE domain chain broken" or similar"

In 3.5.7 I don't see that the domain sequence is necessarily an alternative to the PCE sequence. There are cases where even with a domain sequence, a PCE sequence is important.
[Ramon] Personally, (although we still need to discuss it more) I don't see domain-sequence and pce-sequence as exclusive and I agree they can coexist. The whole 3.5.7 needs to be revisted, including J.P. comments during the meeting that some assertions were false (which is true, brpc may benefit from a domain sequence but does not require it)

Section 5 will need loads of work because the domain sequence (even for inclusion, not reporting) provides information valuable to an attacker.
[Ramon] agreed.


Thanks again,

Ramon
--------------070605010205050602040907--