From pce-bounces@lists.ietf.org Thu Feb 02 15:50:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4lPK-0006vy-Lp; Thu, 02 Feb 2006 15:50:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4lP2-0006lP-8g; Thu, 02 Feb 2006 15:50:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08088; Thu, 2 Feb 2006 15:48:26 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4laS-0002km-Ah; Thu, 02 Feb 2006 16:01:53 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1F4lOz-0002eB-Gg; Thu, 02 Feb 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 02 Feb 2006 15:50:01 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-04.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : PCE Communication Protocol Generic Requirements Author(s) : J. Le Roux, J. Ash Filename : draft-ietf-pce-comm-protocol-gen-reqs-04.txt Pages : 21 Date : 2006-2-2 The PCE model is described in the "PCE Architecture" document and facilitates path computation requests from Path Computation Clients (PCCs) to Path Computation Elements (PCEs). This document specifies generic requirements for a communication protocol between PCCs and PCEs, and also between PCEs where cooperation between PCEs is desirable. Subsequent documents will specify application-specific requirements for the PCE communication protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-reqs-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-comm-protocol-gen-reqs-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-comm-protocol-gen-reqs-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-2-2141518.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-comm-protocol-gen-reqs-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-comm-protocol-gen-reqs-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-2-2141518.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@lists.ietf.org Sun Feb 05 12:24:57 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5ndB-00054L-Id; Sun, 05 Feb 2006 12:24:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5nd9-00051f-Kw for pce@megatron.ietf.org; Sun, 05 Feb 2006 12:24:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27362 for ; Sun, 5 Feb 2006 12:23:16 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F5npA-00009A-FJ for pce@ietf.org; Sun, 05 Feb 2006 12:37:21 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 05 Feb 2006 09:24:43 -0800 X-IronPort-AV: i="4.02,89,1139212800"; d="scan'208"; a="400937936:sNHT1860923506" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k15HOgjt026937 for ; Sun, 5 Feb 2006 09:24:42 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 5 Feb 2006 12:24:41 -0500 Received: from [192.168.1.101] ([10.86.240.249]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 5 Feb 2006 12:24:41 -0500 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: <46B7ACE1-3768-4BD7-9A58-CB833F3204B6@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: pce@ietf.org From: JP Vasseur Date: Sun, 5 Feb 2006 12:24:13 -0500 X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 05 Feb 2006 17:24:41.0242 (UTC) FILETIME=[0C4CFFA0:01C62A79] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: Subject: [Pce] Working Group Last Call on draft-ietf-pce-comm-protocol-gen-reqs-04.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org WG, After extensive discussion and the fruitful collaboration of many of you on draft-ietf-pce-comm-protocol-gen-reqs-04.txt, the document is now ready ready for WG Last Call. Thanks to the DT for the qualitative work! This email initiates a Working Group Last Call on draft-ietf-pce-comm- protocol-gen-reqs-04.txt. The last call will end on February the 19th at noon EST. Please send your comments to the mailing list and copy the chairs. Thanks. JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Feb 08 10:36:12 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6rMa-0004f2-ES; Wed, 08 Feb 2006 10:36:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6rMY-0004cy-Ug for pce@megatron.ietf.org; Wed, 08 Feb 2006 10:36:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01800 for ; Wed, 8 Feb 2006 10:34:20 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6rZ2-0000bI-GY for pce@ietf.org; Wed, 08 Feb 2006 10:49:05 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 08 Feb 2006 07:35:53 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,98,1139212800"; d="scan'208,217"; a="21439306:sNHT38958528" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k18FZC6l021985; Wed, 8 Feb 2006 10:35:51 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Feb 2006 10:35:22 -0500 Received: from [192.168.1.101] ([10.86.242.189]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Feb 2006 10:35:22 -0500 Mime-Version: 1.0 (Apple Message framework v746.2) References: <1F4E4DB7-2D48-45CC-B9F1-232F32D8D043@cisco.com> Message-Id: From: JP Vasseur Date: Wed, 8 Feb 2006 10:34:53 -0500 To: pce@ietf.org X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 08 Feb 2006 15:35:22.0472 (UTC) FILETIME=[46355E80:01C62CC5] X-Spam-Score: 0.2 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: Subject: [Pce] Fwd: Next WG meeting ... X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0561287150==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org --===============0561287150== Content-Type: multipart/alternative; boundary=Apple-Mail-18-44419969 --Apple-Mail-18-44419969 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Begin forwarded message: > From: JP Vasseur > Date: January 28, 2006 1:46:59 PM EST > To: pce@ietf.org > Cc: Adrian Farrel > Subject: Next WG meeting ... > > Hi, > > We have requested a 2-hour slot for our next meeting in Dallas. > Since we'll start working soon on the agenda, if you have plan to > request a slot, thanks to let us know. > > Thanks. > > JP and Adrian. --Apple-Mail-18-44419969 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

Begin = forwarded message:

From: = JP Vasseur <jvasseur@cisco.com>
=
Date: = January 28, 2006 1:46:59 PM EST
Cc: Adrian = Farrel <adrian@olddog.co.uk>
Subject: = Next WG meeting ...


We have requested a 2-hour slot for our next meeting = in Dallas. Since we'll start working soon on the agenda, if you have = plan to request a slot, thanks to let us know.


JP and Adrian.
=

= --Apple-Mail-18-44419969-- --===============0561287150== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0561287150==-- From pce-bounces@lists.ietf.org Fri Feb 10 18:50:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7i1o-0001QG-OM; Fri, 10 Feb 2006 18:50:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7i1c-0001BZ-T6; Fri, 10 Feb 2006 18:50:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14930; Fri, 10 Feb 2006 18:48:19 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7iEg-00078M-RG; Fri, 10 Feb 2006 19:03:35 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1F7i1Z-0002no-RP; Fri, 10 Feb 2006 18:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 10 Feb 2006 18:50:01 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-discovery-reqs-03.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Requirements for Path Computation Element (PCE) Discovery Author(s) : J. Le Roux Filename : draft-ietf-pce-discovery-reqs-03.txt Pages : 15 Date : 2006-2-10 This document presents a set of requirements for a Path Computation Element (PCE) discovery mechanism that would allow a Path Computation Client (PCC) to discover dynamically and automatically a set of PCEs along with certain information relevant for PCE selection. It is intended that solutions that specify procedures and protocols or extensions to existing protocols for such PCE discovery satisfy these requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-discovery-reqs-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-discovery-reqs-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-discovery-reqs-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-2-10155304.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-discovery-reqs-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-discovery-reqs-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-2-10155304.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@lists.ietf.org Sat Feb 11 15:01:09 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F80vd-0000mz-3n; Sat, 11 Feb 2006 15:01:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F80vb-0000lW-P7 for pce@megatron.ietf.org; Sat, 11 Feb 2006 15:01:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25831 for ; Sat, 11 Feb 2006 14:59:24 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F818s-0006vt-BI for pce@ietf.org; Sat, 11 Feb 2006 15:14:50 -0500 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F80vZ-000NCm-Up for pce@ietf.org; Sat, 11 Feb 2006 20:01:06 +0000 Message-ID: <43EE4281.4030901@psg.com> Date: Sat, 11 Feb 2006 21:01:05 +0100 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: pce@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit Cc: Subject: [Pce] [Fwd: I-D ACTION:draft-oki-pce-inter-layer-app-00.txt] X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org folks, i'm not necessarily sure to understand the scenario 5.2 wrt to section 4.2 are you saying that in order to manage inter-layer relationship there is a need to have a separate functional entity (in addition to the PCE) ? i'm a bit confused here because the requirement document does not consider such model - more generically i still believe this effort should concentrate on path computation (role of the PCE functionality) thanks, - dimitri. -------- Original Message -------- Subject: I-D ACTION:draft-oki-pce-inter-layer-app-00.txt Date: Thu, 09 Feb 2006 15:50:02 -0500 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : PCE Applicability for Inter-Layer MPLS and GMPLS Traffic Engineering Author(s) : E. Oki, et al. Filename : draft-oki-pce-inter-layer-app-00.txt Pages : 16 Date : 2006-2-9 A network may comprise of multiple layers. It is important to globally optimize network resources utilization, taking into account all layers, rather than optimizing resource utilization at each layer independently. This allows better network efficiency to be achieved through a process that we call inter-layer traffic engineering. The Path Computation Element (PCE) can be a powerful tool to achieve inter-layer traffic engineering. This document describes the applicability of the PCE-based path computation architecture to inter-layer MPLS and GMPLS traffic engineering. It provides suggestions for the deployment of PCE in support of multi-layer networks. This document also describes network models where PCE performs inter-layer traffic engineering, and the relationship between PCE and a functional component called the Virtual Network Topology Manager (VNTM). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-oki-pce-inter-layer-app-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-oki-pce-inter-layer-app-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-oki-pce-inter-layer-app-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Feb 13 04:23:12 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8ZvL-0000Ny-Vx; Mon, 13 Feb 2006 04:23:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8ZvJ-0000MJ-Lw for pce@megatron.ietf.org; Mon, 13 Feb 2006 04:23:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28402 for ; Mon, 13 Feb 2006 04:21:24 -0500 (EST) Received: from protext01.itu.ch ([156.106.192.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8a8m-0000Pn-Ou for pce@ietf.org; Mon, 13 Feb 2006 04:37:12 -0500 Received: from protext01.itu.ch ([156.106.192.41]) by protext01.itu.ch with Microsoft SMTPSVC(5.0.2195.6713); Mon, 13 Feb 2006 10:22:52 +0100 Received: From mail5.itu.ch ([156.106.192.21]) by protext01.itu.ch (WebShield SMTP v4.5 MR1a); id 1139822571660; Mon, 13 Feb 2006 10:22:51 +0100 Received: from Puppy ([156.106.205.35]) by mail5.itu.ch (8.13.5/8.13.5) with SMTP id k1D9MojY257262; Mon, 13 Feb 2006 10:22:51 +0100 (MET) Message-ID: <04af01c6307f$a19404d0$36cd6a9c@Puppy> From: "Adrian Farrel" To: References: <43EE4281.4030901@psg.com> Subject: Re: [Pce] [Fwd: I-D ACTION:draft-oki-pce-inter-layer-app-00.txt] Date: Mon, 13 Feb 2006 09:24:23 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (mail5.itu.ch [156.106.192.21]); Mon, 13 Feb 2006 10:22:51 +0100 (MET) X-OriginalArrivalTime: 13 Feb 2006 09:22:52.0238 (UTC) FILETIME=[107F0EE0:01C6307F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Dimitri, > i'm not necessarily sure to understand the scenario 5.2 wrt to section 4.2 > > are you saying that in order to manage inter-layer relationship there is > a need to have a separate functional entity (in addition to the PCE) ? "Need" may be a strong term for what we have in mind. I think the text in 5.1 is clear. And most important is the sentence that says... To describe each function clearly, VNTM is considered as a functional element in this draft. The implication is that this entity might not exist, and the function may be distributed. However, since the function *does* exist, it is convenient and clearer to describe it as a separate unit. > i'm a bit confused here because the requirement document > > does not consider such model - The requirement document is titled "PCC-PCE Communication Requirements for Inter-Layer Traffic Engineering" and so should not be expected to cover this model unless it has an impact on the PCC-PCE communications. > more generically i still believe this effort should concentrate on path > computation (role of the PCE functionality) Absolutely. However, it is surely important to show how PCE may be used to compute paths in a multi-layer environment. Cheers, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Feb 13 11:10:41 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8gHh-000374-Fm; Mon, 13 Feb 2006 11:10:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8gHf-00036w-RR for pce@megatron.ietf.org; Mon, 13 Feb 2006 11:10:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03674 for ; Mon, 13 Feb 2006 11:08:54 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8gVH-0005XS-Qs for pce@ietf.org; Mon, 13 Feb 2006 11:24:46 -0500 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F8gHc-000FP4-7I; Mon, 13 Feb 2006 16:10:36 +0000 Message-ID: <43F0AF80.2090700@psg.com> Date: Mon, 13 Feb 2006 17:10:40 +0100 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel Subject: Re: [Pce] [Fwd: I-D ACTION:draft-oki-pce-inter-layer-app-00.txt] References: <43EE4281.4030901@psg.com> <04af01c6307f$a19404d0$36cd6a9c@Puppy> In-Reply-To: <04af01c6307f$a19404d0$36cd6a9c@Puppy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org adrian, Adrian Farrel wrote: > Hi Dimitri, > > >>i'm not necessarily sure to understand the scenario 5.2 wrt to section > > 4.2 > >>are you saying that in order to manage inter-layer relationship there is >>a need to have a separate functional entity (in addition to the PCE) ? > > > "Need" may be a strong term for what we have in mind. > > I think the text in 5.1 is clear. And most important is the sentence that > says... > To describe each > function clearly, VNTM is considered as a functional element in > this draft. > > The implication is that this entity might not exist, and the function may > be distributed. However, since the function *does* exist, it is convenient > and clearer to describe it as a separate unit. > > >>i'm a bit confused here because the requirement document >> > > >>does not consider such model - > > > The requirement document is titled "PCC-PCE Communication Requirements for > Inter-Layer Traffic Engineering" and so should not be expected to cover > this model unless it has an impact on the PCC-PCE communications. > > >>more generically i still believe this effort should concentrate on path >>computation (role of the PCE functionality) > > > Absolutely. However, it is surely important to show how PCE may be used to > compute paths in a multi-layer environment. in such a case i call for asking the specifics being first worked out in CCAMP concerning the aspects not related to path computation it looks like this document put the car before the horses in some sense thanks, - dimitri, > Cheers, > Adrian > > > . > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Feb 13 11:10:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8gHw-00037f-R5; Mon, 13 Feb 2006 11:10:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8gHu-00037a-Ru for pce@megatron.ietf.org; Mon, 13 Feb 2006 11:10:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03679 for ; Mon, 13 Feb 2006 11:09:09 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8gVX-0005Xw-Um for pce@ietf.org; Mon, 13 Feb 2006 11:25:01 -0500 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F8gHs-000FRC-NK for pce@ietf.org; Mon, 13 Feb 2006 16:10:52 +0000 Message-ID: <43F0AF90.8070104@psg.com> Date: Mon, 13 Feb 2006 17:10:56 +0100 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: pce@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: Subject: [Pce] comments on draft-ietf-pce-pcecp-interarea-reqs-00.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org folks, the document mentions "A solution for computing inter-area TE-LSP path relies on a per domain path computation ([PD-COMP]). It is based on loose hop routing with an ERO expansion on each ABR. This can allow setting up a constrained path, but faces two major limitations: -This does not allow computing an optimal constrained path -This may lead to several signalling crankback messages and hence delay the LSP setup, and invoke routing activities. " optimal computation does not imply resource reservation, hence a PCE functionality does not prevent from crankback section 5 present two models, would it be possible to consider that homogeneity is not necessarily verified, e.g. an area having a single ABR does not a PCE to reach the local exit point section 7.13 should discuss scaling wrt to the TEDB wrt to single PCE model it is stated that such consideration is beyond the scope of the document i would more than certainly re-consider this since this a necessary condition for supporting the "all area" PCE model (is this not a single point of failure ? or are specifics in terms of resilience outside the scope of this document) thanks, - dimitri. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Feb 13 12:44:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8hkL-0003no-Iw; Mon, 13 Feb 2006 12:44:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8hkJ-0003mX-0g for pce@megatron.ietf.org; Mon, 13 Feb 2006 12:44:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10576 for ; Mon, 13 Feb 2006 12:42:33 -0500 (EST) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8hxt-00005j-KU for pce@ietf.org; Mon, 13 Feb 2006 12:58:26 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Feb 2006 18:44:10 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] comments on draft-ietf-pce-pcecp-interarea-reqs-00.txt Date: Mon, 13 Feb 2006 18:44:31 +0100 Message-ID: Thread-Topic: [Pce] comments on draft-ietf-pce-pcecp-interarea-reqs-00.txt thread-index: AcYwuJDg/FEGupd3QJSLszqSO5ffoAAC6WFg From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , , X-OriginalArrivalTime: 13 Feb 2006 17:44:10.0209 (UTC) FILETIME=[185D3510:01C630C5] X-Spam-Score: 2.0 (++) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Dimitri Please see inline,=20 > -----Message d'origine----- > De : pce-bounces@lists.ietf.org=20 > [mailto:pce-bounces@lists.ietf.org] De la part de dimitri=20 > papadimitriou > Envoy=E9 : lundi 13 f=E9vrier 2006 17:11 > =C0 : pce@ietf.org > Objet : [Pce] comments on draft-ietf-pce-pcecp-interarea-reqs-00.txt >=20 > folks, >=20 > the document mentions >=20 > "A solution for computing inter-area TE-LSP path relies on a per > domain path computation ([PD-COMP]). It is based on loose=20 > hop routing > with an ERO expansion on each ABR. This can allow setting up a > constrained path, but faces two major limitations: > -This does not allow computing an optimal constrained path > -This may lead to several signalling crankback messages and > hence delay the LSP setup, and invoke routing activities. " >=20 > optimal computation does not imply resource reservation,=20 > hence a PCE functionality does not prevent from crankback Sure, but it drastically reduces crankback probability. Btw, the above text never say that a PCE prevents from crankback... >=20 > section 5 present two models, would it be possible to=20 > consider that homogeneity is not necessarily verified, e.g.=20 > an area having a single ABR does not a PCE to reach the local=20 > exit point Could you clarify please? >=20 > section 7.13 should discuss scaling wrt to the TEDB wrt to=20 > single PCE model it is stated that such consideration is=20 > beyond the scope of the document i would more than certainly=20 > re-consider this since this a necessary condition for=20 > supporting the "all area" PCE model (is this not a single=20 > point of failure ? or are specifics in terms of resilience=20 > outside the scope of this document) Note that this draft discusses PCECP requirements and hence this section = is dedicated to PCECP scalability. This is why TEDB size is out of the = scope. By the way, please note that we are going to move models description = (section 5) to an applicability statement draft to be posted soon. Thanks JL >=20 > thanks, > - dimitri. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Feb 13 13:41:06 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8idG-0005tP-O3; Mon, 13 Feb 2006 13:41:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8idD-0005p4-Kd for pce@megatron.ietf.org; Mon, 13 Feb 2006 13:41:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14001 for ; Mon, 13 Feb 2006 13:39:17 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8iqr-0001mO-NG for pce@ietf.org; Mon, 13 Feb 2006 13:55:11 -0500 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F8id8-000ONS-4c; Mon, 13 Feb 2006 18:40:58 +0000 Message-ID: <43F0D2BD.6080604@psg.com> Date: Mon, 13 Feb 2006 19:41:01 +0100 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: LE ROUX Jean-Louis RD-CORE-LAN Subject: Re: [Pce] comments on draft-ietf-pce-pcecp-interarea-reqs-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Spam-Score: 2.0 (++) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id NAA14001 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org hi jean-louis LE ROUX Jean-Louis RD-CORE-LAN wrote: > Hi Dimitri >=20 > Please see inline, >=20 >=20 >> -----Message d'origine----- De : pce-bounces@lists.ietf.org=20 >> [mailto:pce-bounces@lists.ietf.org] De la part de dimitri=20 >> papadimitriou Envoy=E9 : lundi 13 f=E9vrier 2006 17:11 =C0 : pce@ietf.= org >> Objet : [Pce] comments on >> draft-ietf-pce-pcecp-interarea-reqs-00.txt >>=20 >> folks, >>=20 >> the document mentions >>=20 >> "A solution for computing inter-area TE-LSP path relies on a per=20 >> domain path computation ([PD-COMP]). It is based on loose hop >> routing with an ERO expansion on each ABR. This can allow setting >> up a constrained path, but faces two major limitations: -This does >> not allow computing an optimal constrained path -This may lead to >> several signalling crankback messages and hence delay the LSP >> setup, and invoke routing activities. " >>=20 >> optimal computation does not imply resource reservation, hence a >> PCE functionality does not prevent from crankback >=20 > Sure, but it drastically reduces crankback probability. Btw, the > above text never say that a PCE prevents from crankback... just wanted to avoid confusion in one way or the other, i guess slight rephrasing may help here >> section 5 present two models, would it be possible to consider that >> homogeneity is not necessarily verified, e.g. an area having a >> single ABR does not a PCE to reach the local exit point >=20 > Could you clarify please? the proposed models assume that there are always multiple exit points per area (two) ... hence the question even if there is only ABR hence not much to do in terms of selection the exit point, is the path comp. sequence identical ? >> section 7.13 should discuss scaling wrt to the TEDB wrt to single >> PCE model it is stated that such consideration is beyond the scope >> of the document i would more than certainly re-consider this since >> this a necessary condition for supporting the "all area" PCE model >> (is this not a single point of failure ? or are specifics in terms >> of resilience outside the scope of this document) >=20 > Note that this draft discusses PCECP requirements and hence this > section is dedicated to PCECP scalability. This is why TEDB size is > out of the scope. By the way, please note that we are going to move > models description (section 5) to an applicability statement draft to > be posted soon. does it mean you are going to discuss the scalability issues in the=20 latter document ? thanks, - dimitri. > Thanks >=20 > JL >=20 >=20 >> thanks, - dimitri. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ Pce mailing list=20 >> Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce >>=20 >=20 >=20 > . >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Feb 13 13:58:25 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8iu1-0003da-Qi; Mon, 13 Feb 2006 13:58:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8itz-0003aq-Qx for pce@megatron.ietf.org; Mon, 13 Feb 2006 13:58:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15192 for ; Mon, 13 Feb 2006 13:56:37 -0500 (EST) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8j7b-0002IO-1Y for pce@ietf.org; Mon, 13 Feb 2006 14:12:31 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Feb 2006 19:58:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] comments on draft-ietf-pce-pcecp-interarea-reqs-00.txt Date: Mon, 13 Feb 2006 19:58:41 +0100 Message-ID: Thread-Topic: [Pce] comments on draft-ietf-pce-pcecp-interarea-reqs-00.txt thread-index: AcYwzQja/XlABvkeTJW+y/Qm35kVRQAAMawQ From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , X-OriginalArrivalTime: 13 Feb 2006 18:58:16.0755 (UTC) FILETIME=[72B64830:01C630CF] X-Spam-Score: 2.0 (++) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Content-Transfer-Encoding: quoted-printable Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Dimitri,=20 > -----Message d'origine----- > De : dimitri papadimitriou [mailto:dpapadimitriou@psg.com]=20 > Envoy=E9 : lundi 13 f=E9vrier 2006 19:41 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN > Cc : dimitri.papadimitriou@alcatel.be; pce@ietf.org > Objet : Re: [Pce] comments on=20 > draft-ietf-pce-pcecp-interarea-reqs-00.txt >=20 > hi jean-louis >=20 > LE ROUX Jean-Louis RD-CORE-LAN wrote: >=20 > > Hi Dimitri > >=20 > > Please see inline, > >=20 > >=20 > >> -----Message d'origine----- De : pce-bounces@lists.ietf.org=20 > >> [mailto:pce-bounces@lists.ietf.org] De la part de dimitri=20 > >> papadimitriou Envoy=E9 : lundi 13 f=E9vrier 2006 17:11 =C0 :=20 > pce@ietf.org =20 > >> Objet : [Pce] comments on=20 > draft-ietf-pce-pcecp-interarea-reqs-00.txt > >>=20 > >> folks, > >>=20 > >> the document mentions > >>=20 > >> "A solution for computing inter-area TE-LSP path relies on a per=20 > >> domain path computation ([PD-COMP]). It is based on loose=20 > hop routing=20 > >> with an ERO expansion on each ABR. This can allow setting up a=20 > >> constrained path, but faces two major limitations: -This does not=20 > >> allow computing an optimal constrained path -This may lead=20 > to several=20 > >> signalling crankback messages and hence delay the LSP setup, and=20 > >> invoke routing activities. " > >>=20 > >> optimal computation does not imply resource reservation,=20 > hence a PCE=20 > >> functionality does not prevent from crankback > >=20 > > Sure, but it drastically reduces crankback probability.=20 > Btw, the above=20 > > text never say that a PCE prevents from crankback... >=20 > just wanted to avoid confusion in one way or the other, i=20 > guess slight rephrasing may help here OK, this will be done. >=20 > >> section 5 present two models, would it be possible to=20 > consider that=20 > >> homogeneity is not necessarily verified, e.g. an area=20 > having a single=20 > >> ABR does not a PCE to reach the local exit point > >=20 > > Could you clarify please? >=20 > the proposed models assume that there are always multiple=20 > exit points per area (two) ... hence the question even if=20 > there is only ABR hence not much to do in terms of selection=20 > the exit point, is the path comp. > sequence identical ? I would say yes. Even if there is a single ABR, one may prefer to rely = on PCEs to compute the path, rather than ERO expansion. This avoids = invoking the signaling when there is no path to the destination (from = the single ABR to the destination). If there is no path from the ABR to the destination, the PCE replies = "NO-PATH", and the signaling is not invoked. >=20 > >> section 7.13 should discuss scaling wrt to the TEDB wrt to=20 > single PCE=20 > >> model it is stated that such consideration is beyond the=20 > scope of the=20 > >> document i would more than certainly re-consider this since this a=20 > >> necessary condition for supporting the "all area" PCE=20 > model (is this=20 > >> not a single point of failure ? or are specifics in terms of=20 > >> resilience outside the scope of this document) > >=20 > > Note that this draft discusses PCECP requirements and hence this=20 > > section is dedicated to PCECP scalability. This is why TEDB size is=20 > > out of the scope. By the way, please note that we are=20 > going to move=20 > > models description (section 5) to an applicability=20 > statement draft to=20 > > be posted soon. >=20 > does it mean you are going to discuss the scalability issues=20 > in the latter document ? Yes, Regards JL >=20 > thanks, > - dimitri. >=20 > > Thanks > >=20 > > JL > >=20 > >=20 > >> thanks, - dimitri. > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >> _______________________________________________ Pce mailing list=20 > >> Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce > >>=20 > >=20 > >=20 > > . > >=20 >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Feb 14 03:37:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8vh2-0003IN-6P; Tue, 14 Feb 2006 03:37:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8vh1-0003Hr-FH for pce@megatron.ietf.org; Tue, 14 Feb 2006 03:37:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08100 for ; Tue, 14 Feb 2006 03:36:04 -0500 (EST) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8vun-0001UG-Vb for pce@ietf.org; Tue, 14 Feb 2006 03:52:06 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Feb 2006 09:37:47 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] I-D ACTION:draft-ietf-pce-discovery-reqs-03.txt Date: Tue, 14 Feb 2006 09:38:11 +0100 Message-ID: Thread-Topic: [Pce] I-D ACTION:draft-ietf-pce-discovery-reqs-03.txt thread-index: AcYunvpe7YKiq0MURC6GAjSLX8zA7ACoLUog From: "LE ROUX Jean-Louis RD-CORE-LAN" To: X-OriginalArrivalTime: 14 Feb 2006 08:37:47.0964 (UTC) FILETIME=[EF0957C0:01C63141] X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi folks, As agreed in Vancouver, the PCE Discovery Requirements ID has been = updated. Here are the major changes since last version: -Added Section 6.2.1 that points out inter-AS specific requirements=20 -Added Section 6.5 that discusses policy requirements -Some rewording for the sake of clarity. Best Regards JL et al. > -----Message d'origine----- > De : pce-bounces@lists.ietf.org=20 > [mailto:pce-bounces@lists.ietf.org] De la part de=20 > Internet-Drafts@ietf.org > Envoy=E9 : samedi 11 f=E9vrier 2006 00:50 > =C0 : i-d-announce@ietf.org > Cc : pce@ietf.org > Objet : [Pce] I-D ACTION:draft-ietf-pce-discovery-reqs-03.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Path Computation Element=20 > Working Group of the IETF. >=20 > Title : Requirements for Path Computation=20 > Element (PCE) Discovery > Author(s) : J. Le Roux > Filename : draft-ietf-pce-discovery-reqs-03.txt > Pages : 15 > Date : 2006-2-10 > =09 > This document presents a set of requirements for a Path=20 > Computation Element (PCE) discovery mechanism that would=20 > allow a Path Computation Client (PCC) to discover dynamically=20 > and automatically a set of PCEs along with certain=20 > information relevant for PCE selection. It is intended that=20 > solutions that specify procedures and protocols or extensions=20 > to existing protocols for such PCE discovery satisfy these=20 > requirements. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pce-discovery-r eqs-03.txt >=20 > To remove yourself from the I-D Announcement list, send a=20 > message to i-d-announce-request@ietf.org with the word=20 > unsubscribe in the body of the message. =20 > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 >=20 > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username "anonymous" and a password of your e-mail=20 > address. After logging in, type "cd internet-drafts" and then > "get draft-ietf-pce-discovery-reqs-03.txt". >=20 > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-pce-discovery-reqs-03.txt". > =09 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant=20 > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > =09 > =09 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Feb 14 07:57:40 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8zkS-0007bW-Bx; Tue, 14 Feb 2006 07:57:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8zkQ-0007bM-Up for pce@megatron.ietf.org; Tue, 14 Feb 2006 07:57:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22767 for ; Tue, 14 Feb 2006 07:55:52 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8zyF-0000Vc-JX for pce@ietf.org; Tue, 14 Feb 2006 08:11:55 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 14 Feb 2006 04:57:29 -0800 X-IronPort-AV: i="4.02,113,1139212800"; d="scan'208"; a="404789525:sNHT30081446" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k1ECvSjt011477; Tue, 14 Feb 2006 04:57:29 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Feb 2006 07:57:28 -0500 Received: from [192.168.1.101] ([10.86.242.147]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Feb 2006 07:57:27 -0500 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Tue, 14 Feb 2006 07:56:54 -0500 To: pce@ietf.org X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 14 Feb 2006 12:57:27.0865 (UTC) FILETIME=[35619290:01C63166] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: Subject: [Pce] Working Group Last Call on draft-ietf-pce-discovery-reqs-03.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Dear WG, draft-ietf-pce-discovery-reqs-03.txt has been discussed in details and is now ready for Working Group Last Call. This email initiates a Working Group Last Call on draft-ietf-pce- discovery-reqs-03.txt. The last call will end on February the 28th at noon EST. Please send your comments to the mailing list and copy the chairs. Thanks. JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Feb 15 09:59:07 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9O7W-0005Bj-W3; Wed, 15 Feb 2006 09:59:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9O7V-00051b-0n for pce@megatron.ietf.org; Wed, 15 Feb 2006 09:59:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15240 for ; Wed, 15 Feb 2006 09:57:17 -0500 (EST) Received: from ms01.sssup.it ([193.205.80.99] helo=sssup.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9OLR-00055Q-Nv for pce@ietf.org; Wed, 15 Feb 2006 10:13:35 -0500 Received: from [193.205.81.2] (HELO Platini) by sssup.it (CommuniGate Pro SMTP 4.1.8) with ESMTP id 19697951; Wed, 15 Feb 2006 15:58:33 +0100 Message-ID: <01fc01c63240$540f1c50$ad021e0a@Platini> From: "Filippo Cugini" To: , "LE ROUX Jean-Louis RD-CORE-LAN" Date: Wed, 15 Feb 2006 15:58:49 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.8 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: pce@ietf.org Subject: [Pce] Objective functions in PCECP (draft-ietf-pce-comm-protocol-gen-reqs-04.txt) X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1029504148==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1029504148== Content-Type: multipart/alternative; boundary="----=_NextPart_000_01F9_01C63248.B5CEF070" This is a multi-part message in MIME format. ------=_NextPart_000_01F9_01C63248.B5CEF070 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, In section 3 (Introduction): [..] The path computation request [..] MAY also include an objective = function. In the rest of the document, MUST is always used instead of MAY One comment about the use of "MUST" related to objective functions. In my view some information are request-specific (source, dest, = bandwidth..),others are general (e.g., objective functions), i.e. they = should be the same for every request. For example, what about the = overall network resource utilization (i.e. optimization) if PCC requires = different objective functions for different requests? As a general comment: is it really a must to include in a communication = protocol information that may be common for all requests? maybe = something could be better done through configuration Thank you Filippo ------=_NextPart_000_01F9_01C63248.B5CEF070 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
In section 3 = (Introduction):
[..] The path computation request [..] = MAY also=20 include an objective function.
In the rest of the document, MUST is = always used=20 instead of MAY
 
One comment about the use of "MUST" = related=20 to objective functions.
In my view some information are = request-specific=20 (source, dest, bandwidth..),others are general (e.g., objective = functions), i.e.=20 they should be the same for every request. For example, what about the = overall=20 network resource utilization (i.e. optimization) if PCC requires = different=20 objective functions for different requests?
 
As a general comment: is it = really a must to=20 include in a communication protocol information that may be common=20 for all requests? maybe something could be better done through=20 configuration
 
Thank you
  = Filippo
------=_NextPart_000_01F9_01C63248.B5CEF070-- --===============1029504148== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1029504148==-- From pce-bounces@lists.ietf.org Thu Feb 16 06:13:08 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9h4O-0008Cr-6Q; Thu, 16 Feb 2006 06:13:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9h4N-0008Cm-8Y for pce@megatron.ietf.org; Thu, 16 Feb 2006 06:13:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11545 for ; Thu, 16 Feb 2006 06:11:20 -0500 (EST) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9hIW-0008N9-6M for pce@ietf.org; Thu, 16 Feb 2006 06:27:48 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Feb 2006 12:12:57 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 16 Feb 2006 12:13:24 +0100 Message-ID: Thread-Topic: Objective functions in PCECP (draft-ietf-pce-comm-protocol-gen-reqs-04.txt) thread-index: AcYyQFhNKlm1YYbTRgONwSh1iubMggAqMIRg From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Filippo Cugini" , X-OriginalArrivalTime: 16 Feb 2006 11:12:57.0766 (UTC) FILETIME=[F0EFE460:01C632E9] X-Spam-Score: 0.6 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: pce@ietf.org Subject: [Pce] RE: Objective functions in PCECP (draft-ietf-pce-comm-protocol-gen-reqs-04.txt) X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0019837770==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0019837770== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C632E9.F0B8BF77" This is a multi-part message in MIME format. ------_=_NextPart_001_01C632E9.F0B8BF77 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Filippo =20 Please note that "MAY include" =3D/=3D "MUST support the inclusion"... =20 >As a general comment: is it really a must to include in a communication = protocol information that may be common for all requests?=20 >maybe something could be better done through configuration =20 No the inclusion is a MAY, but the protocol MUST allow you to do it if = you want... =20 =20 Regards, =20 JL ________________________________ De : Filippo Cugini [mailto:filippo.cugini@cnit.it]=20 Envoy=E9 : mercredi 15 f=E9vrier 2006 15:59 =C0 : gash@att.com; LE ROUX Jean-Louis RD-CORE-LAN Cc : pce@ietf.org Objet : Objective functions in PCECP = (draft-ietf-pce-comm-protocol-gen-reqs-04.txt) =09 =09 Hi, =20 In section 3 (Introduction): [..] The path computation request [..] MAY also include an objective = function. In the rest of the document, MUST is always used instead of MAY =20 One comment about the use of "MUST" related to objective functions. In my view some information are request-specific (source, dest, = bandwidth..),others are general (e.g., objective functions), i.e. they = should be the same for every request. For example, what about the = overall network resource utilization (i.e. optimization) if PCC requires = different objective functions for different requests? =20 As a general comment: is it really a must to include in a communication = protocol information that may be common for all requests? maybe = something could be better done through configuration =20 Thank you Filippo ------_=_NextPart_001_01C632E9.F0B8BF77 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Filippo
 
Please note that "MAY include" =3D/=3D "MUST = support the=20 inclusion"...
 
>As=20 a general comment: is it really a must to include in a = communication=20 protocol information that may be common for all requests?=20
>maybe something could be better = done through=20 configuration
 
No the=20 inclusion is a MAY, but the protocol MUST allow you to do it if you = want...
 
 
Regards,
 
JL

De : Filippo Cugini=20 [mailto:filippo.cugini@cnit.it]
Envoy=E9 : mercredi 15 = f=E9vrier=20 2006 15:59
=C0 : gash@att.com; LE ROUX Jean-Louis=20 RD-CORE-LAN
Cc : pce@ietf.org
Objet : = Objective=20 functions in PCECP=20 (draft-ietf-pce-comm-protocol-gen-reqs-04.txt)

Hi,
 
In section 3 = (Introduction):
[..] The path computation request = [..] MAY also=20 include an objective function.
In the rest of the document, MUST is = always used=20 instead of MAY
 
One comment about the use of "MUST" = related=20 to objective functions.
In my view some information are=20 request-specific (source, dest, bandwidth..),others are general (e.g., = objective functions), i.e. they should be the same for every request. = For=20 example, what about the overall network resource utilization (i.e.=20 optimization) if PCC requires different objective functions for = different=20 requests?
 
As a general comment: is it = really a must to=20 include in a communication protocol information that may be = common=20 for all requests? maybe something could be better done through=20 configuration
 
Thank you
 =20 Filippo
------_=_NextPart_001_01C632E9.F0B8BF77-- --===============0019837770== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0019837770==-- From pce-bounces@lists.ietf.org Thu Feb 16 10:17:11 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9ksZ-0001EV-AM; Thu, 16 Feb 2006 10:17:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9ksX-0001EL-DC for pce@megatron.ietf.org; Thu, 16 Feb 2006 10:17:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01589 for ; Thu, 16 Feb 2006 10:15:21 -0500 (EST) Received: from ms01.sssup.it ([193.205.80.99] helo=sssup.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9l6f-0000nD-JU for pce@ietf.org; Thu, 16 Feb 2006 10:31:52 -0500 Received: from [193.205.81.2] (HELO Platini) by sssup.it (CommuniGate Pro SMTP 4.1.8) with ESMTP id 19734165; Thu, 16 Feb 2006 16:16:32 +0100 Message-ID: <008e01c6330c$055ad1e0$ad021e0a@Platini> From: "Filippo Cugini" To: "LE ROUX Jean-Louis RD-CORE-LAN" References: Date: Thu, 16 Feb 2006 16:16:54 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.3 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd Cc: pce@ietf.org Subject: [Pce] Re: Objective functions in PCECP (draft-ietf-pce-comm-protocol-gen-reqs-04.txt) X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0705564037==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0705564037== Content-Type: multipart/alternative; boundary="----=_NextPart_000_008B_01C63314.6712DDD0" This is a multi-part message in MIME format. ------=_NextPart_000_008B_01C63314.6712DDD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi JL, =20 Ok for the distinction, however, I still think objective functions = should not be included in PCECP.=20 It is not clear to me why PCC should require different objective = functions for different requests.=20 Moreover, in case of PCE-PCE request, a PCE could affect TE optimization = also within other domains. Thank you=20 =20 Filippo ----- Original Message -----=20 From: LE ROUX Jean-Louis RD-CORE-LAN=20 To: Filippo Cugini ; gash@att.com=20 Cc: pce@ietf.org=20 Sent: Thursday, February 16, 2006 12:13 PM Subject: RE: Objective functions in PCECP = (draft-ietf-pce-comm-protocol-gen-reqs-04.txt) Hi Filippo Please note that "MAY include" =3D/=3D "MUST support the inclusion"... >As a general comment: is it really a must to include in a = communication protocol information that may be common for all requests?=20 >maybe something could be better done through configuration No the inclusion is a MAY, but the protocol MUST allow you to do it if = you want... Regards, JL -------------------------------------------------------------------------= --- De : Filippo Cugini [mailto:filippo.cugini@cnit.it]=20 Envoy=E9 : mercredi 15 f=E9vrier 2006 15:59 =C0 : gash@att.com; LE ROUX Jean-Louis RD-CORE-LAN Cc : pce@ietf.org Objet : Objective functions in PCECP = (draft-ietf-pce-comm-protocol-gen-reqs-04.txt) Hi, In section 3 (Introduction): [..] The path computation request [..] MAY also include an objective = function. In the rest of the document, MUST is always used instead of MAY One comment about the use of "MUST" related to objective functions. In my view some information are request-specific (source, dest, = bandwidth..),others are general (e.g., objective functions), i.e. they = should be the same for every request. For example, what about the = overall network resource utilization (i.e. optimization) if PCC requires = different objective functions for different requests? As a general comment: is it really a must to include in a = communication protocol information that may be common for all requests? = maybe something could be better done through configuration Thank you Filippo ------=_NextPart_000_008B_01C63314.6712DDD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi JL,

 

Ok for the=20 distinction, however, I still think objective functions should = not=20 be included in PCECP.

It is not=20 clear to me why PCC should require different objective functions for = different=20 requests.

Moreover, in=20 case of PCE-PCE request, a PCE could affect TE=20 optimization also within other domains.

Thank you=20

 

 =20 Filippo

 
 
----- Original Message -----
From:=20 LE ROUX Jean-Louis=20 RD-CORE-LAN
To: Filippo Cugini ; gash@att.com =
Sent: Thursday, February 16, = 2006 12:13=20 PM
Subject: RE: Objective = functions in PCECP=20 (draft-ietf-pce-comm-protocol-gen-reqs-04.txt)

Hi Filippo
 
Please note that "MAY include" =3D/=3D "MUST = support the=20 inclusion"...
 
>As a general comment: is it = really a=20 must to include in a communication protocol information that may = be=20 common for all requests?
>maybe something could be better = done=20 through configuration
 
No=20 the inclusion is a MAY, but the protocol MUST allow you to do it = if you=20 want...
 
 
Regards,
 
JL

De : Filippo Cugini=20 [mailto:filippo.cugini@cnit.it]
Envoy=E9 : mercredi = 15 f=E9vrier=20 2006 15:59
=C0 : gash@att.com; LE ROUX Jean-Louis=20 RD-CORE-LAN
Cc : pce@ietf.org
Objet :=20 Objective functions in PCECP=20 (draft-ietf-pce-comm-protocol-gen-reqs-04.txt)

Hi,
 
In section 3 = (Introduction):
[..] The path computation request = [..] MAY also=20 include an objective function.
In the rest of the document, MUST = is always=20 used instead of MAY
 
One comment about the use of "MUST" = related=20 to objective functions.
In my view some information are=20 request-specific (source, dest, bandwidth..),others are general = (e.g.,=20 objective functions), i.e. they should be the same for every = request. For=20 example, what about the overall network resource utilization (i.e.=20 optimization) if PCC requires different objective functions for = different requests?
 
As a general comment: is it = really a must=20 to include in a communication protocol information that may be = common=20 for all requests? maybe something could be better done through=20 configuration
 
Thank you
 =20 Filippo
------=_NextPart_000_008B_01C63314.6712DDD0-- --===============0705564037== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0705564037==-- From pce-bounces@lists.ietf.org Thu Feb 16 11:20:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9lrw-0007sm-Rt; Thu, 16 Feb 2006 11:20:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9lrv-0007sb-C9 for pce@megatron.ietf.org; Thu, 16 Feb 2006 11:20:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09040 for ; Thu, 16 Feb 2006 11:18:47 -0500 (EST) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9m65-0003po-5D for pce@ietf.org; Thu, 16 Feb 2006 11:35:19 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Feb 2006 17:20:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 16 Feb 2006 17:20:47 +0100 Message-ID: Thread-Topic: Objective functions in PCECP (draft-ietf-pce-comm-protocol-gen-reqs-04.txt) thread-index: AcYzDHNmOfifdTDqRsyfuYLe1TfFjQABEMyA From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Filippo Cugini" X-OriginalArrivalTime: 16 Feb 2006 16:20:21.0428 (UTC) FILETIME=[E2375F40:01C63314] X-Spam-Score: 0.3 (/) X-Scan-Signature: 9178bae9f85419fdc08e9f2c86e345d0 Cc: pce@ietf.org Subject: [Pce] RE: Objective functions in PCECP (draft-ietf-pce-comm-protocol-gen-reqs-04.txt) X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0385705163==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0385705163== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C63314.E18B4BF7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C63314.E18B4BF7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Filippo =20 Please see inline ________________________________ De : Filippo Cugini [mailto:filippo.cugini@cnit.it]=20 Envoy=E9 : jeudi 16 f=E9vrier 2006 16:17 =C0 : LE ROUX Jean-Louis RD-CORE-LAN Cc : pce@ietf.org; gash@att.com Objet : Re: Objective functions in PCECP = (draft-ietf-pce-comm-protocol-gen-reqs-04.txt) =09 =09 Hi JL, =20 Ok for the distinction, however, I still think objective functions = should not be included in PCECP.=20 It is not clear to me why PCC should require different objective = functions for different requests. =20 =20 JLLR> This depends on the application. For some applications you may = want a path with a minimum delay, for other applications you may want a = shortest cost delay bounded path, for other applications you may want a = delay bounded widest path (e.g. upon blocking case, if the requested = bandwidth cannot be fit one may want the widest path), etc.... =20 Moreover, in case of PCE-PCE request, a PCE could affect TE = optimization also within other domains.=20 =20 JLLR> This is up to the PCE to apply local policies and to filter = request parameters. The PCE can reject a request if the requested = objective function is not allowed. Also note that inter-AS specific aspects are beyond the scope of this = draft. This should be covered in the PCECP inter-AS requirement draft. =20 Best Regards =20 JL =20 Thank you=20 =20 Filippo =20 =20 ----- Original Message -----=20 From: LE ROUX Jean-Louis RD-CORE-LAN = =20 To: Filippo Cugini ; gash@att.com=20 Cc: pce@ietf.org=20 Sent: Thursday, February 16, 2006 12:13 PM Subject: RE: Objective functions in PCECP = (draft-ietf-pce-comm-protocol-gen-reqs-04.txt) Hi Filippo =20 Please note that "MAY include" =3D/=3D "MUST support the inclusion"... =20 >As a general comment: is it really a must to include in a = communication protocol information that may be common for all requests?=20 >maybe something could be better done through configuration =20 No the inclusion is a MAY, but the protocol MUST allow you to do it if = you want... =20 =20 Regards, =20 JL ________________________________ De : Filippo Cugini [mailto:filippo.cugini@cnit.it]=20 Envoy=E9 : mercredi 15 f=E9vrier 2006 15:59 =C0 : gash@att.com; LE ROUX Jean-Louis RD-CORE-LAN Cc : pce@ietf.org Objet : Objective functions in PCECP = (draft-ietf-pce-comm-protocol-gen-reqs-04.txt) =09 =09 Hi, =20 In section 3 (Introduction): [..] The path computation request [..] MAY also include an objective = function. In the rest of the document, MUST is always used instead of MAY =20 One comment about the use of "MUST" related to objective functions. In my view some information are request-specific (source, dest, = bandwidth..),others are general (e.g., objective functions), i.e. they = should be the same for every request. For example, what about the = overall network resource utilization (i.e. optimization) if PCC requires = different objective functions for different requests? =20 As a general comment: is it really a must to include in a = communication protocol information that may be common for all requests? = maybe something could be better done through configuration =20 Thank you Filippo ------_=_NextPart_001_01C63314.E18B4BF7 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Filippo
 
Please see inline

De : Filippo Cugini=20 [mailto:filippo.cugini@cnit.it]
Envoy=E9 : jeudi 16 = f=E9vrier 2006=20 16:17
=C0 : LE ROUX Jean-Louis = RD-CORE-LAN
Cc :=20 pce@ietf.org; gash@att.com
Objet : Re: Objective = functions in=20 PCECP = (draft-ietf-pce-comm-protocol-gen-reqs-04.txt)

Hi JL,

 

Ok for=20 the distinction, however, I still think objective functions = should=20 not be included in PCECP.

It is=20 not clear to me why PCC should require different objective functions = for=20 different requests.  

 

JLLR> This depends = on the=20 application. For some applications you may want a path with a minimum = delay,=20 for other applications you may want a shortest cost = delay=20 bounded path, for other applications you may want=20 a delay bounded widest path (e.g. upon blocking case, if the = requested=20 bandwidth cannot be fit one may want the widest path),=20 etc....

 

Moreover, in=20 case of PCE-PCE request, a PCE could affect TE=20 optimization also within other domains. 

 

JLLR> This is up = to the PCE=20 to apply local policies and to filter request parameters. The PCE = can=20 reject a request if the requested objective function is not=20 allowed.

Also note that = inter-AS specific=20 aspects are beyond the scope of this draft. This should be covered in = the=20 PCECP inter-AS requirement draft.

 

Best=20 Regards

 

JL

 

Thank=20 you

 

 =20 Filippo

 
 
----- Original Message -----
From:=20 LE ROUX = Jean-Louis=20 RD-CORE-LAN
To: Filippo Cugini ; gash@att.com =
Sent: Thursday, February 16, = 2006 12:13=20 PM
Subject: RE: Objective = functions in=20 PCECP (draft-ietf-pce-comm-protocol-gen-reqs-04.txt)

Hi Filippo
 
Please note that "MAY include" =3D/=3D = "MUST support the=20 inclusion"...
 
>As a general comment: is it=20 really a must to include in a communication protocol = information=20 that may be common for all requests?
>maybe something could be = better done=20 through configuration
 
No=20 the inclusion is a MAY, but the protocol MUST allow you to do = it if you=20 want...
 
 
Regards,
 
JL

De : Filippo Cugini=20 [mailto:filippo.cugini@cnit.it]
Envoy=E9 : = mercredi 15=20 f=E9vrier 2006 15:59
=C0 : gash@att.com; LE ROUX Jean-Louis=20 RD-CORE-LAN
Cc : = pce@ietf.org
Objet :=20 Objective functions in PCECP=20 = (draft-ietf-pce-comm-protocol-gen-reqs-04.txt)

Hi,
 
In section 3 = (Introduction):
[..] The path computation request = [..] MAY=20 also include an objective function.
In the rest of the document, MUST = is always=20 used instead of MAY
 
One comment about the use of = "MUST" related=20 to objective functions.
In my view some information are=20 request-specific (source, dest, bandwidth..),others are general = (e.g.,=20 objective functions), i.e. they should be the same for every = request. For=20 example, what about the overall network resource utilization (i.e. = optimization) if PCC requires different objective functions = for=20 different requests?
 
As a general comment: is it = really a=20 must to include in a communication protocol information = that may be=20 common for all requests? maybe something could be better done = through=20 configuration
 
Thank you
 =20 = Filippo
= ------_=_NextPart_001_01C63314.E18B4BF7-- --===============0385705163== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0385705163==-- From pce-bounces@lists.ietf.org Thu Feb 16 13:54:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9oH5-0008IX-H8; Thu, 16 Feb 2006 13:54:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9oH3-0008HU-UK for pce@megatron.ietf.org; Thu, 16 Feb 2006 13:54:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21766 for ; Thu, 16 Feb 2006 13:52:54 -0500 (EST) Received: from ms01.sssup.it ([193.205.80.99] helo=sssup.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9oVH-0000uv-VA for pce@ietf.org; Thu, 16 Feb 2006 14:09:27 -0500 Received: from [193.205.81.2] (HELO Platini) by sssup.it (CommuniGate Pro SMTP 4.1.8) with ESMTP id 19742707; Thu, 16 Feb 2006 19:54:12 +0100 Message-ID: <003e01c6332a$6d9f0960$ad021e0a@Platini> From: "Filippo Cugini" To: "LE ROUX Jean-Louis RD-CORE-LAN" References: Date: Thu, 16 Feb 2006 19:54:34 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.3 (/) X-Scan-Signature: 8ba8529e77affe49b0f315db98a262ee Cc: pce@ietf.org Subject: [Pce] Re: Objective functions in PCECP (draft-ietf-pce-comm-protocol-gen-reqs-04.txt) X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1544826587==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1544826587== Content-Type: multipart/alternative; boundary="----=_NextPart_000_003B_01C63332.CF5EDD80" This is a multi-part message in MIME format. ------=_NextPart_000_003B_01C63332.CF5EDD80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, JLLR> This depends on the application. For some applications you may = want a path with a minimum delay.. I absolutely agree. Indeed delay (like bandwidth..) is a QoS requirment = and could be different for every request. However, in section 6.1.17 it is mentioned for example: "Maximize the residual bandwidth on the most loaded link" that deals with Traffic Engineering optimization, and it not related to = QoS application requirements =20 JLLR> The PCE can reject a request..=20 Agree, however, do you think that some objective functions indicated in = section 6.1.17 will be ever accepted by a PCE belonging to a different = domain?=20 =20 Best regards Filippo =20 =20 =20 ----- Original Message -----=20 From: LE ROUX Jean-Louis RD-CORE-LAN=20 To: Filippo Cugini=20 Cc: pce@ietf.org ; gash@att.com=20 Sent: Thursday, February 16, 2006 5:20 PM Subject: RE: Objective functions in PCECP = (draft-ietf-pce-comm-protocol-gen-reqs-04.txt) Hi Filippo Please see inline -------------------------------------------------------------------------= --- De : Filippo Cugini [mailto:filippo.cugini@cnit.it]=20 Envoy=E9 : jeudi 16 f=E9vrier 2006 16:17 =C0 : LE ROUX Jean-Louis RD-CORE-LAN Cc : pce@ietf.org; gash@att.com Objet : Re: Objective functions in PCECP = (draft-ietf-pce-comm-protocol-gen-reqs-04.txt) Hi JL, =20 Ok for the distinction, however, I still think objective functions = should not be included in PCECP.=20 It is not clear to me why PCC should require different objective = functions for different requests. =20 JLLR> This depends on the application. For some applications you may = want a path with a minimum delay, for other applications you may want a = shortest cost delay bounded path, for other applications you may want a = delay bounded widest path (e.g. upon blocking case, if the requested = bandwidth cannot be fit one may want the widest path), etc.... Moreover, in case of PCE-PCE request, a PCE could affect TE = optimization also within other domains.=20 JLLR> This is up to the PCE to apply local policies and to filter = request parameters. The PCE can reject a request if the requested = objective function is not allowed. Also note that inter-AS specific aspects are beyond the scope of = this draft. This should be covered in the PCECP inter-AS requirement = draft. Best Regards JL Thank you=20 =20 Filippo ----- Original Message -----=20 From: LE ROUX Jean-Louis RD-CORE-LAN=20 To: Filippo Cugini ; gash@att.com=20 Cc: pce@ietf.org=20 Sent: Thursday, February 16, 2006 12:13 PM Subject: RE: Objective functions in PCECP = (draft-ietf-pce-comm-protocol-gen-reqs-04.txt) Hi Filippo Please note that "MAY include" =3D/=3D "MUST support the = inclusion"... >As a general comment: is it really a must to include in a = communication protocol information that may be common for all requests?=20 >maybe something could be better done through configuration No the inclusion is a MAY, but the protocol MUST allow you to do = it if you want... Regards, JL ------------------------------------------------------------------------ De : Filippo Cugini [mailto:filippo.cugini@cnit.it]=20 Envoy=E9 : mercredi 15 f=E9vrier 2006 15:59 =C0 : gash@att.com; LE ROUX Jean-Louis RD-CORE-LAN Cc : pce@ietf.org Objet : Objective functions in PCECP = (draft-ietf-pce-comm-protocol-gen-reqs-04.txt) Hi, In section 3 (Introduction): [..] The path computation request [..] MAY also include an = objective function. In the rest of the document, MUST is always used instead of MAY One comment about the use of "MUST" related to objective = functions. In my view some information are request-specific (source, dest, = bandwidth..),others are general (e.g., objective functions), i.e. they = should be the same for every request. For example, what about the = overall network resource utilization (i.e. optimization) if PCC requires = different objective functions for different requests? As a general comment: is it really a must to include in a = communication protocol information that may be common for all requests? = maybe something could be better done through configuration Thank you Filippo ------=_NextPart_000_003B_01C63332.CF5EDD80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 

JLLR> This depends = on the=20 application. For some applications you may want a path with a minimum=20 delay..

I=20 absolutely agree. Indeed delay (like bandwidth..) is a=20 QoS requirment and could be different for=20 every request.

However, in section 6.1.17 it is mentioned for=20 example:

"Maximize=20 the residual bandwidth on the most loaded link"
that deals with Traffic Engineering optimization, and it = not related=20 to QoS application requirements
 
JLLR> The PCE can = reject a=20 request.. 
Agree, however, do you think that some objective functions = indicated=20 in section 6.1.17 will be ever accepted by a PCE belonging to a = different=20 domain?
 
Best regards
 Filippo  
 
 
----- Original Message -----
From:=20 LE ROUX Jean-Louis=20 RD-CORE-LAN
Sent: Thursday, February 16, = 2006 5:20=20 PM
Subject: RE: Objective = functions in PCECP=20 (draft-ietf-pce-comm-protocol-gen-reqs-04.txt)

Hi Filippo
 
Please see inline

De : Filippo Cugini=20 [mailto:filippo.cugini@cnit.it]
Envoy=E9 : jeudi 16 = f=E9vrier=20 2006 16:17
=C0 : LE ROUX Jean-Louis=20 RD-CORE-LAN
Cc : pce@ietf.org; gash@att.com
Objet : = Re:=20 Objective functions in PCECP=20 (draft-ietf-pce-comm-protocol-gen-reqs-04.txt)

Hi JL,

 

Ok for=20 the distinction, however, I still think objective = functions should=20 not be included in PCECP.

It is=20 not clear to me why PCC should require different objective functions = for=20 different requests.  

 

JLLR> This = depends on the=20 application. For some applications you may want a path with a = minimum delay,=20 for other applications you may want a shortest cost = delay=20 bounded path, for other applications you may = want=20 a delay bounded widest path (e.g. upon blocking case, if the = requested=20 bandwidth cannot be fit one may want the widest path),=20 etc....

 

Moreover, in=20 case of PCE-PCE request, a PCE could affect TE=20 optimization also within other domains. 

 

JLLR> This is up = to the PCE=20 to apply local policies and to filter request parameters. The = PCE can=20 reject a request if the requested objective function is not=20 allowed.

Also note that = inter-AS=20 specific aspects are beyond the scope of this draft. This should be = covered=20 in the PCECP inter-AS requirement draft.

 

Best=20 Regards

 

JL

 

Thank=20 you

 

 =20 Filippo

 
 
----- Original Message ----- =
From:=20 LE ROUX = Jean-Louis=20 RD-CORE-LAN
To: Filippo Cugini ; gash@att.com =
Sent: Thursday, February = 16, 2006=20 12:13 PM
Subject: RE: Objective = functions in=20 PCECP (draft-ietf-pce-comm-protocol-gen-reqs-04.txt)

Hi Filippo
 
Please note that "MAY include" =3D/=3D = "MUST support the=20 inclusion"...
 
>As a general comment: is it=20 really a must to include in a communication protocol = information=20 that may be common for all requests? =
>maybe something could be = better done=20 through configuration
 
No the inclusion is a MAY, but the protocol MUST = allow you to=20 do it if you want...
 
 
Regards,
 
JL

De : Filippo Cugini=20 [mailto:filippo.cugini@cnit.it]
Envoy=E9 : = mercredi 15=20 f=E9vrier 2006 15:59
=C0 : gash@att.com; LE ROUX = Jean-Louis=20 RD-CORE-LAN
Cc : = pce@ietf.org
Objet :=20 Objective functions in PCECP=20 = (draft-ietf-pce-comm-protocol-gen-reqs-04.txt)

Hi,
 
In section 3 = (Introduction):
[..] The path computation = request [..] MAY=20 also include an objective function.
In the rest of the document, = MUST is always=20 used instead of MAY
 
One comment about the use of = "MUST" related=20 to objective functions.
In my view some information are=20 request-specific (source, dest, bandwidth..),others are general = (e.g.,=20 objective functions), i.e. they should be the same for every = request.=20 For example, what about the overall network resource utilization = (i.e.=20 optimization) if PCC requires different objective functions = for=20 different requests?
 
As a general comment: is it = really a=20 must to include in a communication protocol information = that may be=20 common for all requests? maybe something could be better = done=20 through configuration
 
Thank you
 =20 = Filippo
<= /BODY> ------=_NextPart_000_003B_01C63332.CF5EDD80-- --===============1544826587== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1544826587==-- From pce-bounces@lists.ietf.org Fri Feb 17 10:25:11 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA78A-00084I-Vj; Fri, 17 Feb 2006 10:02:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA72i-0004it-7v for pce@megatron.ietf.org; Fri, 17 Feb 2006 09:57:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03241 for ; Fri, 17 Feb 2006 09:04:50 -0500 (EST) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9zWK-00061u-Rj for pce@ietf.org; Fri, 17 Feb 2006 01:55:16 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Feb 2006 07:40:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 17 Feb 2006 07:40:41 +0100 Message-ID: Thread-Topic: Objective functions in PCECP (draft-ietf-pce-comm-protocol-gen-reqs-04.txt) thread-index: AcYzKm/x8rzqXzgGSRq8QWx/LCODTQAYNWjQ From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Filippo Cugini" X-OriginalArrivalTime: 17 Feb 2006 06:40:15.0781 (UTC) FILETIME=[02D8DD50:01C6338D] X-Spam-Score: 0.4 (/) X-Scan-Signature: c6c6a408c8e09c950064e70d807ac007 Cc: pce@ietf.org Subject: [Pce] RE: Objective functions in PCECP (draft-ietf-pce-comm-protocol-gen-reqs-04.txt) X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0220957358==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0220957358== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6338D.0299F557" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6338D.0299F557 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Filippo, =20 Please see inline, ________________________________ De : Filippo Cugini [mailto:filippo.cugini@cnit.it]=20 Envoy=E9 : jeudi 16 f=E9vrier 2006 19:55 =C0 : LE ROUX Jean-Louis RD-CORE-LAN Cc : pce@ietf.org; gash@att.com Objet : Re: Objective functions in PCECP = (draft-ietf-pce-comm-protocol-gen-reqs-04.txt) =09 =09 Hi, =20 JLLR> This depends on the application. For some applications you may = want a path with a minimum delay.. I absolutely agree. Indeed delay (like bandwidth..) is a QoS requirment = and could be different for every request. However, in section 6.1.17 it is mentioned for example: "Maximize the residual bandwidth on the most loaded link" that deals with Traffic Engineering optimization, and it not related to = QoS application requirements=20 =20 One may want to sent a request message including a set of path request, = to be computed in a synchronized manner, with as objective to maximize = the residual bandwidth... =20 JLLR> The PCE can reject a request..=20 Agree, however, do you think that some objective functions indicated in = section 6.1.17 will be ever accepted by a PCE belonging to a different = domain? =20 =20 When domains are areas, sub-ASs or ASs of the same provider, then the = answser is YES... When domains are ASs of distinct network providers, then it will depend = on metric normalization aspects and on the level of trust between = network providers, and I would say yes, at least for the shortest path = and max bandwidth path.=20 Anyway, note that this is a generic requirement draft, not related to a = specific PCE application. =20 Best Regards, =20 JL =20 =20 Best Regards =20 JL=20 =20 Best regards Filippo =20 =20 =20 ----- Original Message -----=20 From: LE ROUX Jean-Louis RD-CORE-LAN = =20 To: Filippo Cugini =20 Cc: pce@ietf.org ; gash@att.com=20 Sent: Thursday, February 16, 2006 5:20 PM Subject: RE: Objective functions in PCECP = (draft-ietf-pce-comm-protocol-gen-reqs-04.txt) Hi Filippo =20 Please see inline ________________________________ De : Filippo Cugini [mailto:filippo.cugini@cnit.it]=20 Envoy=E9 : jeudi 16 f=E9vrier 2006 16:17 =C0 : LE ROUX Jean-Louis RD-CORE-LAN Cc : pce@ietf.org; gash@att.com Objet : Re: Objective functions in PCECP = (draft-ietf-pce-comm-protocol-gen-reqs-04.txt) =09 =09 Hi JL, =20 Ok for the distinction, however, I still think objective functions = should not be included in PCECP.=20 It is not clear to me why PCC should require different objective = functions for different requests. =20 =20 JLLR> This depends on the application. For some applications you may = want a path with a minimum delay, for other applications you may want a = shortest cost delay bounded path, for other applications you may want a = delay bounded widest path (e.g. upon blocking case, if the requested = bandwidth cannot be fit one may want the widest path), etc.... =20 Moreover, in case of PCE-PCE request, a PCE could affect TE = optimization also within other domains.=20 =20 JLLR> This is up to the PCE to apply local policies and to filter = request parameters. The PCE can reject a request if the requested = objective function is not allowed. Also note that inter-AS specific aspects are beyond the scope of this = draft. This should be covered in the PCECP inter-AS requirement draft. =20 Best Regards =20 JL =20 Thank you=20 =20 Filippo =20 =20 ----- Original Message -----=20 From: LE ROUX Jean-Louis RD-CORE-LAN = =20 To: Filippo Cugini ; gash@att.com=20 Cc: pce@ietf.org=20 Sent: Thursday, February 16, 2006 12:13 PM Subject: RE: Objective functions in PCECP = (draft-ietf-pce-comm-protocol-gen-reqs-04.txt) Hi Filippo =20 Please note that "MAY include" =3D/=3D "MUST support the = inclusion"... =20 >As a general comment: is it really a must to include in a = communication protocol information that may be common for all requests?=20 >maybe something could be better done through configuration =20 No the inclusion is a MAY, but the protocol MUST allow you to do it = if you want... =20 =20 Regards, =20 JL ________________________________ De : Filippo Cugini [mailto:filippo.cugini@cnit.it]=20 Envoy=E9 : mercredi 15 f=E9vrier 2006 15:59 =C0 : gash@att.com; LE ROUX Jean-Louis RD-CORE-LAN Cc : pce@ietf.org Objet : Objective functions in PCECP = (draft-ietf-pce-comm-protocol-gen-reqs-04.txt) =09 =09 Hi, =20 In section 3 (Introduction): [..] The path computation request [..] MAY also include an = objective function. In the rest of the document, MUST is always used instead of MAY =20 One comment about the use of "MUST" related to objective functions. In my view some information are request-specific (source, dest, = bandwidth..),others are general (e.g., objective functions), i.e. they = should be the same for every request. For example, what about the = overall network resource utilization (i.e. optimization) if PCC requires = different objective functions for different requests? =20 As a general comment: is it really a must to include in a = communication protocol information that may be common for all requests? = maybe something could be better done through configuration =20 Thank you Filippo ------_=_NextPart_001_01C6338D.0299F557 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Filippo,
 
Please see inline,

De : Filippo Cugini=20 [mailto:filippo.cugini@cnit.it]
Envoy=E9 : jeudi 16 = f=E9vrier 2006=20 19:55
=C0 : LE ROUX Jean-Louis = RD-CORE-LAN
Cc :=20 pce@ietf.org; gash@att.com
Objet : Re: Objective = functions in=20 PCECP = (draft-ietf-pce-comm-protocol-gen-reqs-04.txt)

Hi,
 

JLLR> This depends = on the=20 application. For some applications you may want a path with a minimum=20 delay..

I=20 absolutely agree. Indeed delay (like bandwidth..) is a=20 QoS requirment and could be different for=20 every request.

However, in section 6.1.17 it is mentioned for=20 example:

"Maximize=20 the residual bandwidth on the most loaded link"
that deals with Traffic Engineering = optimization, and=20 it not related to QoS application requirements 
 
=
One may=20 want to sent a request message including a set of path request, to be = computed=20 in a synchronized manner,  with as objective to maximize the = residual bandwidth...
 
JLLR> The PCE can = reject a=20 request.. 
Agree, however, do you think that some = objective=20 functions indicated in section 6.1.17 will be ever accepted by a PCE = belonging=20 to a different domain?  
 
=
When=20 domains are areas, sub-ASs or ASs of the same provider, then the = answser is=20 YES...
When=20 domains are ASs of distinct network providers, then it will depend on = metric=20 normalization aspects and on the level of trust between network = providers,=20 and I would say yes, at least for the shortest path = and max=20 bandwidth path. 
Anyway,=20 note that this is a generic requirement draft, not related to a = specific PCE=20 application.
 
=
Best=20 Regards,
 
=
JL
 
=
 
=
Best = Regards
 
=
JL 
 
Best regards
 Filippo  
 
 
----- Original Message -----
From:=20 LE ROUX = Jean-Louis=20 RD-CORE-LAN
Sent: Thursday, February 16, = 2006 5:20=20 PM
Subject: RE: Objective = functions in=20 PCECP (draft-ietf-pce-comm-protocol-gen-reqs-04.txt)

Hi Filippo
 
Please see inline

De : Filippo Cugini=20 [mailto:filippo.cugini@cnit.it]
Envoy=E9 : jeudi = 16 f=E9vrier=20 2006 16:17
=C0 : LE ROUX Jean-Louis=20 RD-CORE-LAN
Cc : pce@ietf.org; gash@att.com
Objet : Re: = Objective functions in PCECP=20 = (draft-ietf-pce-comm-protocol-gen-reqs-04.txt)

Hi JL,

 

Ok=20 for the distinction, however, I still think objective = functions=20 should not be included in PCECP.

It=20 is not clear to me why PCC should require different objective = functions=20 for different requests.  

 

JLLR> This = depends on the=20 application. For some applications you may want a path with a = minimum=20 delay, for other applications you may want a = shortest cost=20 delay bounded path, for other applications you = may=20 want a delay bounded widest path (e.g. upon blocking case, if = the=20 requested bandwidth cannot be fit one may want the widest path),=20 etc....

 

Moreover, in=20 case of PCE-PCE request, a PCE could affect TE=20 optimization also within other domains. 

 

JLLR> This is = up to the=20 PCE to apply local policies and to filter request parameters. = The PCE=20 can reject a request if the requested objective function is not=20 allowed.

Also note that = inter-AS=20 specific aspects are beyond the scope of this draft. This should = be=20 covered in the PCECP inter-AS requirement = draft.

 

Best=20 Regards

 

JL

 

Thank=20 you

 

 =20 Filippo

 
 
----- Original Message ----- =
From:=20 LE ROUX = Jean-Louis=20 RD-CORE-LAN
To: Filippo Cugini ; gash@att.com
Sent: Thursday, February = 16, 2006=20 12:13 PM
Subject: RE: Objective = functions in=20 PCECP (draft-ietf-pce-comm-protocol-gen-reqs-04.txt)

Hi Filippo
 
Please note that "MAY include" =3D/=3D = "MUST support=20 the inclusion"...
 
>As a general comment: is = it=20 really a must to include in a communication protocol = information=20 that may be common for all requests? =
>maybe something could be = better done=20 through configuration
 
No the inclusion is a MAY, but the protocol MUST = allow you=20 to do it if you want...
 
 
Regards,
 
JL

De : Filippo Cugini=20 [mailto:filippo.cugini@cnit.it]
Envoy=E9 : = mercredi 15=20 f=E9vrier 2006 15:59
=C0 : gash@att.com; LE ROUX = Jean-Louis=20 RD-CORE-LAN
Cc : = pce@ietf.org
Objet :=20 Objective functions in PCECP=20 = (draft-ietf-pce-comm-protocol-gen-reqs-04.txt)

Hi,
 
In section 3 = (Introduction):
[..] The path computation = request [..]=20 MAY also include an objective function.
In the rest of the document, = MUST is=20 always used instead of MAY
 
One comment about the use of = "MUST"=20 related to objective functions.
In my view some = information=20 are request-specific (source, dest, bandwidth..),others are = general=20 (e.g., objective functions), i.e. they should be the same for = every=20 request. For example, what about the overall network resource=20 utilization (i.e. optimization) if PCC requires different = objective functions for different requests?
 
As a general comment: is it = really a=20 must to include in a communication protocol information = that may=20 be common for all requests? maybe something could be = better done=20 through configuration
 
Thank you
 =20 = Filippo
<= /BLOCKQUOTE> ------_=_NextPart_001_01C6338D.0299F557-- --===============0220957358== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0220957358==-- From pce-bounces@lists.ietf.org Fri Feb 17 12:46:15 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA9gM-0001gr-UI; Fri, 17 Feb 2006 12:46:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA9gL-0001gX-1f for pce@megatron.ietf.org; Fri, 17 Feb 2006 12:46:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15801 for ; Fri, 17 Feb 2006 12:44:25 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FA9uo-0007GV-05 for pce@ietf.org; Fri, 17 Feb 2006 13:01:10 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 17 Feb 2006 09:46:03 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k1HHjpWV014550 for ; Fri, 17 Feb 2006 09:46:03 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 17 Feb 2006 12:45:56 -0500 Received: from [192.168.1.100] ([10.86.240.237]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 17 Feb 2006 12:45:55 -0500 Mime-Version: 1.0 (Apple Message framework v746.2) To: pce@ietf.org Message-Id: <82CA043D-B4A8-400C-A173-35B4D02CF865@cisco.com> From: JP Vasseur Date: Fri, 17 Feb 2006 12:45:23 -0500 X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 17 Feb 2006 17:45:56.0070 (UTC) FILETIME=[011D5060:01C633EA] X-Spam-Score: 2.3 (++) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Cc: Subject: [Pce] Interested in working on a new ID ? X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1163967887==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org --===============1163967887== Content-Type: multipart/alternative; boundary=Apple-Mail-10-829849734 --Apple-Mail-10-829849734 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Dear WG, We discussed some time ago about the use of existing objects (e.g. RSVP) in PCEP messages so as to specify constraints, return computed paths and so on. There were two possible approaches: (1) Define a PCEP object that would carry non PCEP object. (2) Specify an identical object with a PCEP codepoint. (1) was rejected because of potential ambiguity in the interpretation of the non PCEP object in a PCEP context, thus we elected to adopt the (2) approach. For example, in the current PCEP ID: 7.8. ERO Object The ERO object is used to encode a TE LSP path. If can either be carried within a PCReq message to specify the existing path of a TE LSP to be reoptimize or within a PCRep message to provide a computed TE LSP. The contents of this object are identical in encoding to the contents of the Explicit Route Object defined in [RSPV-TE], [GRSVP] and [RSVP- UNNUM]. That is, the object is constructed from a series of sub- objects. Any RSVP ERO sub-object already defined or that could be defined in the future for use in the ERO is acceptable in this object. PCEP ERO sub-object types correspond to RSVP ERO sub-object types. Since the explicit path is available for immediate signaling by the MPLS or GMPLS control plane, the meanings of all of the sub- objects and fields in this object are identical to those defined for the ERO. ERO Object-Class is to be assigned by IANA (recommended value=7) ERO Object-Type is to be assigned by IANA (recommended value=1) 7.9. RRO Object The RRO object is used to record the route followed by a TE LSP. The PCEP RRO object is exclusively carried within a PCReq message so as to specify the route followed by a TE LSP for which a reoptimization is desired. The contents of this object are identical in encoding to the contents of the Route Record Object defined in [RSPV-TE], [G-RSVP] and [RSVP- UNNUM]. That is, the object is constructed from a series of sub- objects. Any RSVP RRO sub-object already defined or that could be defined in the future for use in the RRO is acceptable in this object. The meanings of all of the sub-objects and fields in this object are identical to those defined for the RRO. PCEP RRO sub-object types correspond to RSVP RRO sub-object types. RRO Object-Class is to be assigned by IANA (recommended value=8) RRO Object-Type is to be assigned by IANA (recommended value=1) There are other examples such as the PROTECTION object (draft-ietf- ccamp-gmpls-recovery-e2e-signaling-03.txt ), (RFC4124), ... It would be a good idea to have a separate ID to get PCEP codepoint for these objects (for which the format is likely to remain unchanged) and potentially (if needed) clarify the interpretation of these objects in a PCEP context. Any volunteer to drive this ? Thanks, JP and Adrian. --Apple-Mail-10-829849734 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear WG,

We discussed some time ago = about the use of existing objects (e.g. RSVP) in PCEP messages so as to = specify constraints, return computed paths and so on. There were two = possible approaches:

(1) Define a PCEP object = that would carry non PCEP object.
(2) Specify an identical = object with a PCEP codepoint.

(1) was rejected because of = potential ambiguity in the interpretation of the non PCEP object in a = PCEP context, thus we elected to adopt the (2) approach. For example, in = the current PCEP ID:

=A07.8. ERO Object =
=A0 =A0 =A0 =A0
=A0 =A0 =A0=A0 The = ERO object is used to encode a TE LSP path. If can either be =
=A0 =A0 =A0=A0 carried within a PCReq message to = specify the existing path of a TE
=A0 =A0 =A0=A0 LSP = to be reoptimize or within a PCRep message to provide a computed =
=A0 =A0 =A0=A0 TE LSP.
=A0 =A0 =A0 =A0=
=A0 =A0 =A0=A0 The contents of this object are = identical in encoding to the contents
=A0 =A0 =A0=A0 = of the Explicit Route Object defined in [RSPV-TE], [GRSVP] and = [RSVP-
=A0 =A0 =A0=A0 UNNUM]. That is, the object is = constructed from a series of sub-
=A0 =A0 =A0=A0 = objects. Any RSVP ERO sub-object already defined or that could be =
=A0 =A0 =A0=A0 defined in the future for use in the = ERO is acceptable in this
=A0 =A0 =A0=A0 object. =
=A0 =A0 =A0 =A0
=A0 =A0 =A0=A0 PCEP = ERO sub-object types correspond to RSVP ERO sub-object types. =
=A0 =A0 =A0 =A0
=A0 =A0 =A0=A0 Since = the explicit path is available for immediate signaling by the =
=A0 =A0 =A0=A0 MPLS or GMPLS control plane, the = meanings of all of the sub-objects
=A0 =A0 =A0=A0 and = fields in this object are identical to those defined for the ERO. =
=A0 =A0 =A0 =A0
=A0 =A0 =A0=A0 ERO = Object-Class is to be assigned by IANA (recommended value=3D7) =
=A0 =A0 =A0=A0 ERO Object-Type is to be assigned by = IANA (recommended value=3D1)
=A0 =A0 =A0 =A0 =
=A0 =A0 =A0=A0 7.9. RRO Object
=A0 =A0= =A0 =A0
=A0 =A0 =A0=A0 The RRO object is used to = record the route followed by a TE LSP. The
=A0 =A0 =A0=A0= PCEP RRO object is exclusively carried within a PCReq message so as =
=A0 =A0 =A0=A0 to specify the route followed by a TE = LSP for which a reoptimization
=A0 =A0 =A0=A0 is = desired.=A0
=A0 =A0 =A0 =A0
=A0 =A0 = =A0=A0 The contents of this object are identical in encoding to the = contents
=A0 =A0 =A0=A0 of the Route Record Object = defined in [RSPV-TE], [G-RSVP] and [RSVP-
=A0 =A0 =A0=A0 = UNNUM]. That is, the object is constructed from a series of = sub-
=A0 =A0 =A0=A0 objects. Any RSVP RRO sub-object = already defined or that could be
=A0 =A0 =A0=A0 = defined in the future for use in the RRO is acceptable in this =
=A0 =A0 =A0=A0 object.
=A0 =A0 =A0 =A0=
=A0 =A0 =A0=A0 The meanings of all of the sub-objects = and fields in this object are
=A0 =A0 =A0=A0 identical = to those defined for the RRO.
=A0 =A0 =A0 =A0 =
=A0 =A0 =A0=A0 PCEP RRO sub-object types correspond to = RSVP RRO sub-object types.
=A0 =A0 =A0 =A0 =
=A0 =A0 =A0=A0 RRO Object-Class is to be assigned by = IANA (recommended value=3D8)
=A0 =A0 =A0=A0 RRO = Object-Type is to be assigned by IANA (recommended value=3D1) =
=A0 =A0 =A0
There are other examples such as = the PROTECTION object = (draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt = ),=A0<CLASSTYPE> (RFC4124), ...

It would be a good idea to = have a separate ID to get PCEP codepoint for these objects (for which = the format is likely to remain unchanged) and potentially (if needed) = clarify the interpretation of these objects in a PCEP = context.

Any = volunteer to drive this ?

Thanks,

JP and = Adrian.
= --Apple-Mail-10-829849734-- --===============1163967887== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1163967887==-- From pce-bounces@lists.ietf.org Sun Feb 19 10:52:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAqrV-0001zX-G6; Sun, 19 Feb 2006 10:52:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAqrV-0001zR-6G for pce@ietf.org; Sun, 19 Feb 2006 10:52:37 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAqrT-0005nw-Qx for pce@ietf.org; Sun, 19 Feb 2006 10:52:37 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 19 Feb 2006 07:52:35 -0800 X-IronPort-AV: i="4.02,127,1139212800"; d="scan'208"; a="407312338:sNHT29366954" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k1JFqXgY012701 for ; Sun, 19 Feb 2006 07:52:33 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 19 Feb 2006 10:52:32 -0500 Received: from [192.168.1.100] ([10.86.240.106]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 19 Feb 2006 10:52:32 -0500 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: <4A1D4D6F-F233-400A-B0C0-2B1A7A224EAE@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: pce@ietf.org From: JP Vasseur Date: Sun, 19 Feb 2006 10:51:58 -0500 X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 19 Feb 2006 15:52:32.0536 (UTC) FILETIME=[7EB7E980:01C6356C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Subject: [Pce] WG Agenda X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi, FYI, a "draft" meeting agenda for the next IETF has been published. We'll soon published the draft agenda for the PCE WG Meeting. If you haven't requested a slot you'd like to have, please do it asap. Thanks. JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Feb 20 08:12:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBAqN-00089z-KP; Mon, 20 Feb 2006 08:12:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBAqM-00089u-Qt for pce@ietf.org; Mon, 20 Feb 2006 08:12:46 -0500 Received: from relay3.mail.uk.clara.net ([80.168.70.143]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBAqL-0006fl-IY for pce@ietf.org; Mon, 20 Feb 2006 08:12:46 -0500 Received: from du-069-0234.access.clara.net ([217.158.132.234] helo=Puppy) by relay3.mail.uk.clara.net with esmtp (Exim 4.46) id 1FBAqJ-00059D-G2 for pce@ietf.org; Mon, 20 Feb 2006 13:12:44 +0000 Message-ID: <020201c6361f$eb850fd0$33849ed9@Puppy> From: "Adrian Farrel" To: Date: Mon, 20 Feb 2006 13:16:44 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Subject: [Pce] Communication received from the OIF X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi, We have received the attached communication from the OIF. I am currently checking with the IAB to see what the correct procedure should be. Adrian ====== To: Adrian Farrel and J.P. Vasseur, IETF PCE WG Co-Chairs From: Jim Jones, OIF TC Chair Copy: Alex Zinin and Bill Fenner, IETF Routing Area Directors Subject: Proposal to establish a liaison to IETF PCE WG Dear Adrian and JP, The OIF is interested in initiating a cooperative liaison with the PCE WG, in the spirit of fostering cooperation for achieving interoperability of intelligent optical networks. The mission of the Optical Internetworking Forum (OIF) is to foster the development and deployment of interoperable products and services for data switching and routing using optical networking technologies. To date OIF has had issued Interoperability Agreements (IAs) in the areas of physical link layer interoperability and network control plane interoperability. OIF has also been successful with multiple interoperability demonstrations using OIF IAs and ITU-T Recommendations as the basis for the interoperability demonstrations. We would like to propose that Richard Bradford of Cisco act as liaison between the two organizations. Best regards, Jim Jones OIF Technical Committee Chair _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Feb 20 08:17:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBAud-00006s-9j; Mon, 20 Feb 2006 08:17:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBAuc-00006n-FH for pce@ietf.org; Mon, 20 Feb 2006 08:17:10 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBAub-0006wE-80 for pce@ietf.org; Mon, 20 Feb 2006 08:17:10 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 20 Feb 2006 08:17:10 -0500 X-IronPort-AV: i="4.02,130,1139202000"; d="scan'208,217"; a="82765033:sNHT45016380" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k1KDGcPo024080 for ; Mon, 20 Feb 2006 08:17:07 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Feb 2006 08:16:57 -0500 Received: from [192.168.1.100] ([10.86.241.47]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Feb 2006 08:16:57 -0500 Mime-Version: 1.0 (Apple Message framework v746.2) To: pce@ietf.org Message-Id: <054B6FCE-0C6C-42D0-A35F-7EF78512E2CE@cisco.com> From: JP Vasseur Date: Mon, 20 Feb 2006 08:16:22 -0500 X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 20 Feb 2006 13:16:57.0197 (UTC) FILETIME=[ECD5F9D0:01C6361F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Subject: [Pce] Working Group Last Call on draft-ietf-pce-comm-protocol-gen-reqs-04.txt ended X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0067695576==" Errors-To: pce-bounces@lists.ietf.org --===============0067695576== Content-Type: multipart/alternative; boundary=Apple-Mail-19-1072908791 --Apple-Mail-19-1072908791 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed WG, Working Group Last call on draft-ietf-pce-comm-protocol-gen- reqs-04.txt has ended on Feb 19. Since there are no unresolved issues, we can move forward with this ID. Thanks for the hard work. Thanks. JP. --Apple-Mail-19-1072908791 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
WG,

Working = Group Last call on=A0draft-ietf-pce-comm-protocol-gen-reqs-04.txt has ended on Feb 19. Since there are no unresolved issues, we can = move forward with this ID.

Thanks for = the hard work.

Thanks.

JP.
= --Apple-Mail-19-1072908791-- --===============0067695576== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0067695576==-- From pce-bounces@lists.ietf.org Mon Feb 20 14:30:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBGjY-0004wt-J6; Mon, 20 Feb 2006 14:30:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBGjX-0004wa-9J; Mon, 20 Feb 2006 14:30:07 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBGjW-0002Av-1O; Mon, 20 Feb 2006 14:30:07 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 20 Feb 2006 14:29:56 -0500 X-IronPort-AV: i="4.02,131,1139202000"; d="scan'208,217"; a="82789717:sNHT27286165228" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k1KJT7M1011721; Mon, 20 Feb 2006 14:29:51 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Feb 2006 14:29:30 -0500 Received: from [192.168.1.100] ([10.86.241.47]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Feb 2006 14:29:29 -0500 Mime-Version: 1.0 (Apple Message framework v746.2) To: Alex Zinin , Bill Fenner Message-Id: <8EEEFAED-4268-4876-8190-D10504942231@cisco.com> From: JP Vasseur Date: Mon, 20 Feb 2006 14:28:55 -0500 X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 20 Feb 2006 19:29:29.0941 (UTC) FILETIME=[F81C0850:01C63653] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: iesg-secretary@ietf.org, pce@ietf.org Subject: [Pce] Publication Request: draft-ietf-pce-comm-protocol-gen-reqs-04.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1132879521==" Errors-To: pce-bounces@lists.ietf.org --===============1132879521== Content-Type: multipart/alternative; boundary=Apple-Mail-29--1052221713 --Apple-Mail-29--1052221713 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, draft-ietf-pce-comm-protocol-gen-reqs-04.txt has completed Working Group Last Call and is now ready according to the WG chairs' judgement. Please consider it for publication as an Informational RFC. Thanks, JP. --Apple-Mail-29--1052221713 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
Hi,

draft-ietf-pce-comm-protocol-gen-reqs-04.txt=A0has completed Working Group Last Call and is now ready according = to the WG chairs' judgement.

Please consider it for = publication as an Informational RFC.

Thanks,


= --Apple-Mail-29--1052221713-- --===============1132879521== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1132879521==-- From pce-bounces@lists.ietf.org Wed Feb 22 09:01:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBuYZ-0005c2-QP; Wed, 22 Feb 2006 09:01:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBuYY-0005bp-Vc; Wed, 22 Feb 2006 09:01:26 -0500 Received: from relay1.mail.uk.clara.net ([80.168.70.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBuYW-0004MO-Kx; Wed, 22 Feb 2006 09:01:26 -0500 Received: from du-069-0121.access.clara.net ([217.158.132.121] helo=Puppy) by relay1.mail.uk.clara.net with esmtp (Exim 4.46) id 1FBuYV-000NTX-Gw; Wed, 22 Feb 2006 14:01:24 +0000 Message-ID: <071c01c637b9$0b5009b0$33849ed9@Puppy> From: "Adrian Farrel" To: , , Date: Wed, 22 Feb 2006 13:33:28 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Subject: [Pce] Fw: Last Call: draft-fenner-zinin-rtg-standard-reqts-01.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org All, You should probably be aware of this I-D in last call on the routing area mailing list. It proposes some changes to the procedures and hurdles for taking an I-D forward on the Standards Track. Since this will change how your I-Ds are processed in the future you should review the draft and express your support or raise your concerns on the routing area mailing list. Cheers, Adrian ----- Original Message ----- From: "Alex Zinin" To: Sent: Thursday, February 16, 2006 6:02 PM Subject: Last Call: draft-fenner-zinin-rtg-standard-reqts-01.txt > This is to start a Routing Area-wide two-week Last Call on this document > for submission to the IESG for publication as BCP. The Last Call ends on > March 2nd, 2006. > > The document is available here: > > http://www.ietf.org/internet-drafts/draft-fenner-zinin-rtg-standard-reqts-01.txt > > Abstract: > > > This document provides guidance for the advancement of the protocols > > produced within the IETF Routing Area. It places implementation and > > interoperability constraints on protocols earlier in the standards > > process than RFC 2026, based on RFC 2026's provision that the IESG > > may require implementation and/or operational experience prior to > > granting Proposed Standard status to a specification that materially > > affects the core Internet protocols or that specifies behavior that > > may have significant operational impact on the Internet. > > > > We also discuss the applicability of these rules to protocols and > > their extensions. > > > -- > Alex > http://www.psg.com/~zinin > > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Feb 22 15:51:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC0wu-0005vV-Mv; Wed, 22 Feb 2006 15:51:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC0w2-000544-J8; Wed, 22 Feb 2006 15:50:06 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC0w2-00071u-Gy; Wed, 22 Feb 2006 15:50:06 -0500 Received: from [156.154.24.129] (helo=willow.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FC0vy-00034R-RY; Wed, 22 Feb 2006 15:50:06 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k1MKo29W009093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Feb 2006 20:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FC0vy-0004Sf-HL; Wed, 22 Feb 2006 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 22 Feb 2006 15:50:02 -0500 X-Spam-Score: -5.9 (-----) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-pcecp-interarea-reqs-01.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : PCE Communication Protocol (PCECP) Specific Requirements for Inter-Area (G)MPLS Traffic Engineering Author(s) : J. Le Roux Filename : draft-ietf-pce-pcecp-interarea-reqs-01.txt Pages : 10 Date : 2006-2-22 For scalability purposes a network may comprise multiple IGP areas. An inter-area TE-LSP is an LSP that transits through at least two IGP areas. In a multi-area network, topology visibility remains local to a given area, and a head-end LSR cannot compute alone an inter-area shortest constrained path. One key application of the Path Computation Element (PCE) based architecture is the computation of inter-area TE-LSP paths. This document lists a detailed set of PCE Communication Protocol (PCECP) specific requirements for support of inter-area TE-LSP path computation. It complements generic requirements for a PCE Communication Protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-pcecp-interarea-reqs-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-pcecp-interarea-reqs-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-pcecp-interarea-reqs-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-2-22144802.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-pcecp-interarea-reqs-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-pcecp-interarea-reqs-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-2-22144802.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@lists.ietf.org Thu Feb 23 02:51:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCBGJ-0007u0-0p; Thu, 23 Feb 2006 02:51:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCBGH-0007ts-9K for pce@ietf.org; Thu, 23 Feb 2006 02:51:41 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCBGF-0004Hx-Rk for pce@ietf.org; Thu, 23 Feb 2006 02:51:41 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Feb 2006 08:51:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] I-D ACTION:draft-ietf-pce-pcecp-interarea-reqs-01.txt Date: Thu, 23 Feb 2006 08:52:14 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] I-D ACTION:draft-ietf-pce-pcecp-interarea-reqs-01.txt thread-index: AcY38hNZxvJT378kT8SahBfqnOXdMAAWqNdw From: "LE ROUX Jean-Louis RD-CORE-LAN" To: X-OriginalArrivalTime: 23 Feb 2006 07:51:38.0846 (UTC) FILETIME=[FA3B37E0:01C6384D] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi all, This new revision accounts for points discussed in Vancouver and on the = list. Here are the main changes: -Removed all text related to the applicability of PCEs for inter-area = path computation. This will be moved to an applicability statement draft = to be posted soon. -Requirements for reoptimization, load balancing, objective functions, = metrics, cost recording and re-routing have been moved to the generic = ID. -Added a requirement for area recording in a reply (see section 5.2). -Added one co-author. -Some rewordings for the sake of clarity. Any comment on this new version would be welcome. Best Regards, JL et al. > -----Message d'origine----- > De : Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Envoy=E9 : mercredi 22 f=E9vrier 2006 21:50 > =C0 : i-d-announce@ietf.org > Cc : pce@ietf.org > Objet : [Pce] I-D ACTION:draft-ietf-pce-pcecp-interarea-reqs-01.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Path Computation Element=20 > Working Group of the IETF. >=20 > Title : PCE Communication Protocol (PCECP)=20 > Specific Requirements for Inter-Area (G)MPLS Traffic Engineering > Author(s) : J. Le Roux > Filename : draft-ietf-pce-pcecp-interarea-reqs-01.txt > Pages : 10 > Date : 2006-2-22 > =09 > For scalability purposes a network may comprise multiple IGP areas.=20 > An inter-area TE-LSP is an LSP that transits through at least=20 > two IGP areas. In a multi-area network, topology visibility=20 > remains local to a given area, and a head-end LSR cannot=20 > compute alone an inter-area shortest constrained path. One=20 > key application of the Path Computation Element (PCE) based=20 > architecture is the computation of inter-area TE-LSP paths.=20 > This document lists a detailed set of PCE Communication=20 > Protocol (PCECP) specific requirements for support of=20 > inter-area TE-LSP path computation. It complements generic=20 > requirements for a PCE Communication Protocol. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pce-pcecp-inter > area-reqs-01.txt >=20 > To remove yourself from the I-D Announcement list, send a=20 > message to i-d-announce-request@ietf.org with the word=20 > unsubscribe in the body of the message. =20 > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 >=20 > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username "anonymous" and a password of your e-mail=20 > address. After logging in, type "cd internet-drafts" and then > "get draft-ietf-pce-pcecp-interarea-reqs-01.txt". >=20 > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE=20 > /internet-drafts/draft-ietf-pce-pcecp-interarea-reqs-01.txt". > =09 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant=20 > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > =09 > =09 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Feb 28 12:41:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE8ql-0003VQ-DH; Tue, 28 Feb 2006 12:41:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE8qj-0003VD-O5 for pce@ietf.org; Tue, 28 Feb 2006 12:41:25 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE8qi-0003mp-Gy for pce@ietf.org; Tue, 28 Feb 2006 12:41:25 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 28 Feb 2006 09:41:25 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,153,1139212800"; d="scan'208"; a="22731195:sNHT21269588" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k1SHfNqQ001582; Tue, 28 Feb 2006 12:41:24 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Feb 2006 12:41:23 -0500 Received: from [10.86.104.179] ([10.86.104.179]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Feb 2006 12:41:23 -0500 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Tue, 28 Feb 2006 12:40:46 -0500 To: pce@ietf.org X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 28 Feb 2006 17:41:23.0162 (UTC) FILETIME=[30FE1BA0:01C63C8E] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Subject: [Pce] Draft PCE WG Agenda X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi, A draft agenda for our next PCE WG meeting in Dallas can be found in: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=65 Please let us know if you have any comment. Moreover, thanks for sending your slides by March the 12th so that we could publish them prior to the meeting. And the usual note ... please focus on the issues to be discussed during the meeting, no presentation please. Thanks. JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Feb 28 12:43:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE8t5-000457-B5; Tue, 28 Feb 2006 12:43:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE8t4-00044a-R5 for pce@ietf.org; Tue, 28 Feb 2006 12:43:50 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE8t3-0003sp-IQ for pce@ietf.org; Tue, 28 Feb 2006 12:43:50 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 28 Feb 2006 09:43:49 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k1SHhlVd005419; Tue, 28 Feb 2006 09:43:48 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Feb 2006 12:43:48 -0500 Received: from [10.86.104.179] ([10.86.104.179]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Feb 2006 12:43:47 -0500 Mime-Version: 1.0 (Apple Message framework v746.2) To: pce@ietf.org Message-Id: From: JP Vasseur Date: Tue, 28 Feb 2006 12:43:12 -0500 X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 28 Feb 2006 17:43:47.0770 (UTC) FILETIME=[872F89A0:01C63C8E] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Subject: [Pce] Working Group Last Call on draft-ietf-pce-discovery-reqs-03.txt ended X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1489788767==" Errors-To: pce-bounces@lists.ietf.org --===============1489788767== Content-Type: multipart/alternative; boundary=Apple-Mail-52--367365138 --Apple-Mail-52--367365138 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed WG, Working Group Last call on draft-ietf-pce-discovery-reqs-03.txt has ended without unresolved issues. We can move forward with this ID. Thanks. JP. --Apple-Mail-52--367365138 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
WG,

Working Group = Last call on=A0draft-ietf-pce-discovery-reqs-03.txt = has ended without unresolved issues. We can move forward with this = ID.